Candidat Factur-X : quelles preuves exiger d’une API ?

Une API répond generated: true. L’interface affiche un verdict vert. Un identifiant apparaît dans le rapport. Pourtant, aucun fichier n’est téléchargeable, l’empreinte ne précise pas ce qu’elle couvre et les erreurs affichées sont encore celles de la source. Le document a-t-il réellement été généré ? A-t-il été validé ? Des données ont-elles disparu ? À ce stade, l’intégrateur ne peut pas le savoir.

Un succès déclaré est une affirmation de système. Une preuve exige des objets vérifiables et une chaîne reliant la source, l’opération exécutée et le résultat. C’est le prolongement naturel de Réparer ou reconstruire une facture électronique : une fois l’opération choisie, encore faut-il démontrer ce qu’elle a produit.

En bref

• Sept états distincts : préflight, candidat annoncé, artefact matérialisé, validation technique, fidélité source→candidat, transmission, réception/acceptation.
• La première preuve est l’existence des octets : fichier récupérable + SHA-256 recalculable sur le même périmètre.
• Le hash identifie les octets ; il ne prouve ni conformité, ni fidélité, ni acceptation externe.
• Le diff sémantique classe conservation, normalisation, correction, enrichissement et omission.
• scan = diagnostic ; convert = transformation ; profil non exécuté = non évalué. Aucune promesse PA ni de conformité fiscale finale.

« Généré » peut désigner sept états différents

Sans artefact final, il est impossible de vérifier le packaging, le profil, la fidélité des données, les pertes silencieuses ou le comportement réel après une action de génération. Une API ou une GED devrait séparer au minimum les états suivants :

Une même opération peut s’arrêter à chacun de ces niveaux. Aucun état ne doit emprunter la preuve du suivant. Cette séparation prolonge « Générable maintenant » ne veut pas dire « prêt à transmettre ».

La première preuve est l’existence des octets

Un candidat devrait être un objet immuable distinct de la source, doté au minimum d’un identifiant stable. Sa preuve d’existence comprend :

• un candidate_id non réutilisé ;
• le fichier lui-même ou une URL de téléchargement bornée par une durée et une autorisation ;
• le type de média réellement servi ;
• la taille en octets ;
• la date de matérialisation ;
• l’empreinte SHA-256 du périmètre exact téléchargé.

« Hash du candidat » reste ambigu si le système ne précise pas s’il a hashé le PDF complet, le seul XML embarqué, une archive, un payload JSON ou un fichier avant une étape de packaging. L’intégrateur doit pouvoir télécharger l’artefact, recalculer l’empreinte sur les mêmes octets et obtenir la même valeur.

Le Secure Hash Standard FIPS 180-4 du NIST définit les fonctions de hachage comme un moyen de produire une empreinte permettant de détecter si un message a changé depuis son calcul. Dans un proof bundle, SHA-256 sert donc à identifier le contenu binaire contrôlé et à détecter sa modification.

Il ne répond pas aux autres questions. Le hash ne lit pas la facture, ne choisit pas un profil, ne vérifie pas les règles métier, ne compare pas la source au candidat et ne constate aucune acceptation externe. Deux fichiers économiquement faux peuvent chacun avoir une empreinte parfaitement stable. Un SHA-256 est indispensable à l’identité de l’artefact ; il n’est ni un certificat de conformité, ni une preuve de fidélité.

Relier le candidat à sa source et à l’opération

Un fichier isolé, même hashé, ne dit pas d’où il vient. Le dossier doit donc enregistrer aussi :

• l’identifiant de la source et son SHA-256, avec le même niveau de précision sur le périmètre ;
• l’opération réellement exécutée : génération, réparation, enrichissement, normalisation ou reconstruction ;
• la version du moteur ou du pipeline qui l’a exécutée ;
• les entrées utilisées, leur provenance et les éventuelles confirmations humaines ;
• le profil, la syntaxe et la version cibles.

Le lien de lignée doit être immuable : source_id + source_sha256 + operation_id → candidate_id + candidate_sha256. Si une confirmation change, si une règle est mise à jour ou si l’artefact est reconditionné, il s’agit d’une nouvelle exécution et potentiellement d’un nouveau candidat. Écraser le fichier sous le même identifiant rend l’audit non reproductible.

Cette lignée empêche aussi une confusion fréquente : le rapport de validation de la source ne doit pas devenir celui du candidat. La source peut être non conforme précisément parce qu’elle doit être réparée ; le candidat doit recevoir sa propre validation, exécutée après matérialisation.

Dire exactement ce qui a été validé

Au 4 août 2026, la FNFE-MPE a publié Factur-X 1.09.2 / ZUGFeRD 2.5.2 (après la 1.09 / 2.5 du 10 juin 2026). Son dossier officiel comprend notamment une aide d’implémentation, un exemple d’extension XMP pour le PDF/A-3, une représentation CII D22B, des listes de codes, ainsi que des XSD et Schematron pour les profils MINIMUM, BASIC_WL, BASIC, EN 16931 et EXTENDED (contenu du dossier Factur-X 1.09).

Le mot « validé » doit donc être accompagné de la cible exacte. Un proof bundle sérieux indique :

• le type d’artefact et la syntaxe contrôlée ;
• le profil et la version annoncés ;
• le nom, la version et idéalement l’empreinte des artefacts de validation ;
• le moteur ou service de validation réellement exécuté ;
• l’horodatage et les résultats propres au candidat ;
• les contrôles non exécutés, non applicables ou interrompus.

Le W3C décrit XSD comme un langage permettant de décrire la structure et de contraindre le contenu des documents XML. Schematron est un langage de validation fondé sur des règles et des assertions ; l’édition courante est référencée par ISO/IEC 19757-3:2025. La Commission européenne publie un registre d’artefacts de support à EN 16931, comprenant bindings de syntaxe, règles et fichiers Schematron.

Ces couches sont complémentaires : passer un schéma ne signifie pas avoir passé toutes les règles métier applicables. Inversement, un rapport Schematron sans identification du fichier, de la syntaxe et de la version testés est difficilement reproductible. La Commission recommande d’utiliser les versions disponibles des artefacts et prévient que des résultats peuvent différer au fil de leur évolution dans son service de test de conformité. Le bundle doit donc épingler ce qui a réellement tourné, pas écrire simplement « validateur EN 16931 ».

Un profil non exécuté doit apparaître comme non évalué, pas comme un succès implicite. Ce point rejoint Pourquoi valider une facture électronique ne se résume pas à « valide / invalide ».

Le diff sémantique prouve ce que le hash ne peut pas prouver

Un système peut produire un fichier techniquement valide tout en supprimant une donnée source exploitable, en aplatissant une hiérarchie ou en remplaçant une valeur par une convention non déclarée. Le proof bundle devrait distinguer six catégories, champ par champ :

Le diff utile n’est pas seulement un diff de caractères entre deux XML. Il doit rapprocher les termes métier, conserver les chemins source et cible, indiquer les dépendances de calcul et signaler les données sans destination. Une omission peut être légitime (information interne hors du périmètre de la facture cible). Elle cesse d’être une perte silencieuse seulement si elle est nommée, justifiée et laissée accessible dans la source.

Pour l’arbitrage champ par champ entre PDF et XML, voir PDF et XML embarqué se contredisent.

Exemple unique — proof bundle conceptuel, non exécuté

L’exemple suivant est entièrement synthétique et conceptuel. Aucun fichier n’a été généré, aucun hash n’a été calculé et aucune validation n’a été exécutée. Il illustre la forme de la preuve attendue, pas une capacité runtime de FacturX API.

Une source ERP synthétique contient une devise, une hiérarchie de deux lignes, une quantité écrite avec une précision non canonique et une étiquette interne de workflow. L’opération projetée consiste à produire un candidat Factur-X EN 16931 : la devise et la hiérarchie sont conservées ; la représentation décimale de la quantité est normalisée sans changer sa valeur ; l’étiquette interne, qui ne constitue pas une donnée de facture cible, est volontairement omise et déclarée comme telle.

Ce bundle conceptuel ne mérite donc aucun badge « généré » ou « valide ». Il devient une preuve uniquement lorsque les placeholders sont remplacés par un artefact récupérable, des empreintes recalculables, des résultats réellement exécutés et un diff couvrant toutes les données de la source.

Ce qu’un CTO ou un intégrateur doit demander

Avant d’acheter ou d’intégrer une API de génération, quelques questions éliminent rapidement les preuves insuffisantes :

1. Puis-je télécharger exactement le fichier déclaré comme candidat ?
2. Puis-je recalculer son SHA-256, avec un périmètre et une taille explicites ?
3. Le bundle identifie-t-il la source, l’opération et la version du moteur ?
4. Les validations appartiennent-elles au candidat, avec syntaxe, profil, version et artefacts épinglés ?
5. Le mapping et le diff distinguent-ils conservation, normalisation, correction, enrichissement et omission ?
6. Les contrôles non exécutés sont-ils visibles au lieu d’être assimilés à des succès ?
7. Les statuts de transmission et d’acceptation reposent-ils sur des preuves externes séparées ?

Un simple success: true ne répond à aucune de ces questions. Un hash isolé n’en répond qu’à une partie de la deuxième.

Positionnement FacturX API — sans promesse runtime non prouvée

FacturX API se positionne comme brique de préparation documentaire. Un scan public est un diagnostic ; une conversion, lorsqu’elle s’applique, est une transformation. Un profil non exécuté reste non évalué. FacturX API n’est pas une Plateforme Agréée et ne revendique ni transmission officielle ni conformité fiscale finale.

Le principe d’achat reste simple : ne demandez pas seulement à une API si elle a généré un document. Demandez-lui de vous livrer l’objet, son identité, sa validation et le compte rendu complet de ce qu’elle en a fait. Le proof bundle de cet article est un contrat de preuve à exiger ; les preuves runtime complètes (candidat téléchargeable, hash recalculable, validation propre, diff sémantique, parité API/Web/rapport) doivent être évaluées sur staging puis en production, cas par cas, avant toute démonstration commerciale conditionnelle.

Sources officielles

• NIST — FIPS 180-4 Secure Hash Standard
• FNFE-MPE — Factur-X
• FNFE-MPE — Contenu du dossier Factur-X 1.09 / 1.09.2
• W3C — XML Schema Definition Language (XSD) 1.1
• ISO — ISO/IEC 19757-3:2025 (Schematron)
• Commission européenne — Relevant tools for EN 16931
• Commission européenne — eInvoicing Conformance Testing

Les artefacts et publications évoluent : épingler la version réellement utilisée au moment du contrôle.

Articles liés

• Réparer ou reconstruire une facture électronique
• PDF et XML embarqué se contredisent : quelle représentation croire ?
• Pourquoi valider une facture électronique ne se résume pas à « valide / invalide »
• « Générable maintenant » ne veut pas dire « prêt à transmettre »
• Convertir un PDF en Factur-X
• Lire un rapport de scan Factur-X