Intégrer Factur-X dans votre outil interne : guide développeur

Votre entreprise a un outil de facturation maison, et la réforme 2026-2027 impose de produire du Factur-X. Ce guide couvre ce qu'il faut savoir avant d'écrire la première ligne de code — et comment éviter de lire les 200 pages de la norme.

L'anatomie d'un fichier Factur-X

Un Factur-X = un PDF/A-3 + un fichier factur-x.xml embarqué en pièce jointe, avec trois exigences structurelles :

le XML suit la syntaxe CII (CrossIndustryInvoice, namespaces ONU/CEFACT) ;
les métadonnées XMP du PDF déclarent la conformité PDF/A-3 et référencent le XML ;
le XML est déclaré en fichier associé (/AF + AFRelationship).

Le XML lui-même se structure en trois blocs : le contexte (ExchangedDocumentContext, qui déclare le profil via une URN), l'en-tête (ExchangedDocument : numéro, date, type 380/381) et la transaction (SupplyChainTradeTransaction : lignes, parties, TVA, totaux).

Là où tout le monde échoue : les règles BR-*

La validation XSD (grammaire) est la partie facile. Le vrai gardien, c'est le Schematron EN 16931 : ~200 règles métier identifiées BR-XX, BR-CO-XX, BR-S-XX… Les pièges classiques :

BR-CO-15 — TTC = HT + TVA. Évident, jusqu'à ce qu'un arrondi flottant produise 1 198,99 au lieu de 1 199,00. Travaillez en décimal (jamais en float), arrondissez chaque ventilation de TVA à 2 décimales, puis sommez.
BR-S-08 — la base d'imposition par taux doit être la somme exacte des lignes au même taux. Le calcul doit être fait par taux de TVA, pas globalement.
BR-CO-25 — si un montant est dû, il faut une date d'échéance ou des conditions de paiement.
BR-CO-26 — le vendeur doit être identifiable : SIREN (SpecifiedLegalOrganization/ID avec schemeID="0002") ou numéro de TVA (schemeID="VA").
Élément vide — un ApplicableHeaderTradeDelivery vide est rejeté par certains validateurs (règle PEPPOL R008). Mettez-y la date de livraison.

Build vs buy : le calcul honnête

Implémenter soi-même = maîtriser la syntaxe CII, embarquer les XSD officiels, exécuter le Schematron (XSLT 2.0, donc Saxon ou équivalent), produire du PDF/A-3 valide, et suivre les mises à jour de la norme. Comptez plusieurs semaines d'ingénierie, puis de la maintenance à chaque évolution.

L'alternative : déléguer la partie normative à une API et garder votre logique métier chez vous.

# Générer un Factur-X depuis votre backend
curl -X POST https://facturx.app/api/v1/generate \
  -H "Authorization: Bearer fxk_votre_cle" \
  -H "Content-Type: application/json" \
  -d '{ "invoice": { "invoice_number": "FA-2026-042", ... } }' \
  --output facture.pdf

# Valider ce que produit déjà votre outil
curl -X POST https://facturx.app/api/v1/validate \
  -H "Authorization: Bearer fxk_votre_cle" \
  -F "[email protected]"

La réponse de validation liste chaque règle en échec avec son identifiant (BR-CO-15), le message normatif anglais, et une explication française avec piste de correction — exploitable directement dans vos logs ou votre UI.

Architecture recommandée

Votre outil garde la donnée métier (clients, lignes, taux) ;
à l'émission, il appelle POST /generate avec le payload JSON et récupère le PDF Factur-X ;
en CI, une poignée de factures de test passent par POST /validate pour détecter toute régression de conformité ;
les fichiers ne sont jamais stockés côté API — votre conformité RGPD reste simple.

La référence complète de l'API (schémas, codes d'erreur, OpenAPI) est disponible, avec 1 000 appels mensuels inclus dans le plan API.