Réparer ou reconstruire une facture électronique ?

Un contrôle échoue. L’interface propose aussitôt de « régénérer la facture ». Cette réponse paraît rassurante : repartir de zéro donnerait un document propre. En réalité, une reconstruction complète peut supprimer des conditions de paiement déjà fiables, aplatir une hiérarchie de lignes, perdre un identifiant utile ou transformer une valeur calculée en donnée prétendument source.

L’erreur inverse existe aussi : appliquer un patch local à un porteur ou à une structure trop dégradés pour produire un résultat contrôlable.

L’opération cible doit être la moins destructive capable de produire un résultat fiable, traçable et revalidable. Conserver si rien ne doit changer ; normaliser la représentation sans toucher au sens ; réparer un défaut déterministe ; enrichir depuis une source fiable ; reconstruire seulement lorsque la structure l’impose ; demander une information uniquement lorsqu’elle est réellement absente et indéductible.

Cet ordre est une recommandation d’architecture. Ce n’est pas une hiérarchie normative universelle, et il ne prouve aucune capacité runtime non recettée de FacturX API.

En bref

Conserver la source et produire un candidat distinct : ne pas écraser silencieusement l’artefact reçu.
Six opérations distinctes : conserver, normaliser, réparer, enrichir, reconstruire, demander.
La reconstruction réflexe détruit souvent de la valeur : données fiables perdues, totaux doublés, identité commercialisée.
Valider le candidat (XSD, Schematron, profil) ne prouve pas à elle seule la fidélité source→candidat.
/scan reste un diagnostic documentaire ; /convert une transformation. Ni l’un ni l’autre n’est une transmission officielle ni une acceptation PA.

Réparer ne signifie pas écraser la source

En France, l’article 289 du code général des impôts exige que l’authenticité de l’origine, l’intégrité du contenu et la lisibilité de la facture soient assurées de son émission jusqu’à la fin de sa conservation. Le BOFiP précise que l’intégrité signifie notamment que les mentions de la facture d’origine n’ont pas été modifiées et que celle-ci est conservée dans son contenu originel (article 289 du CGI, BOI-TVA-DECLA-30-20-30-10).

La conséquence d’architecture est importante : un système de transformation ne devrait pas remplacer silencieusement l’artefact reçu. Il doit conserver la source, produire un candidat distinct, puis relier les deux par un journal de transformation. Cette séparation ne donne pas automatiquement au candidat le statut juridique d’une facture émise, corrigée ou acceptée ; elle rend seulement l’opération documentaire vérifiable.

La publication Factur-X 1.09 / ZUGFeRD 2.5 (10 juin 2026), corrigée en 1.09.2 / 2.5.2 le 4 août 2026, décrit une facture hybride : une représentation lisible et des données XML structurées, embarquées dans un PDF/A-3 (FNFE-MPE, FeRD). Le FeRD recommande l’utilisation de ZUGFeRD 2.5 à partir du 1er juillet 2026 ; cela n’équivaut pas à une obligation légale française à cette date exacte. Modifier le XML, le PDF ou le porteur peut donc affecter des couches différentes. « Réparer la facture » n’est pas une opération unique.

Six opérations à ne pas confondre

Le moteur devrait descendre dans l’échelle suivante seulement lorsque l’étape précédente ne permet pas d’obtenir un résultat fiable.

Opération	Ce qui change	Exemple de décision correcte	Risque à éviter
Conserver	Rien	Le document est exploitable pour l’objectif demandé	Régénérer pour le seul plaisir de produire un nouveau fichier
Normaliser	La représentation, pas l’intention économique	Canoniser une date, un encodage ou une notation décimale équivalente	Faire passer un arrondi économique pour une simple mise en forme
Réparer	Un défaut local, avec une règle déterministe	Retirer un élément facultatif vide ou corriger une précision calculable	Étendre le patch à des champs non concernés
Enrichir	Ajouter une donnée déjà disponible et traçable	Reprendre une référence concordante depuis le rendu et un référentiel lié	Inventer une valeur ou traiter le PDF comme autorité universelle
Reconstruire	Le porteur, la structure ou les relations internes	Produire un nouveau conteneur lorsque le packaging source est incompatible	Réécrire toutes les données métier sans nécessité
Demander	Une décision humaine explicitement attribuée	Faire confirmer une valeur absente de toutes les sources fiables	Transformer chaque règle technique en formulaire utilisateur

La frontière la plus délicate sépare normalisation et réparation. Passer de 2026-08-03 à une représentation canonique équivalente est une normalisation. Modifier un montant après recalcul est une réparation : même déterministe, elle touche la sémantique économique et doit être déclarée comme telle.

Pour le traitement détaillé des contradictions entre représentation visible et XML, voir PDF et XML embarqué se contredisent : quelle représentation croire ?. Ici, le sujet est le choix de l’opération, pas l’arbitrage de chaque conflit.

Pourquoi la reconstruction réflexe détruit de la valeur

Une reconstruction à partir d’un modèle appauvri peut :

perdre une condition de paiement ou une référence utile ;
additionner un groupe et ses sous-lignes, donc doubler un total ;
remplacer une identité légale par un libellé commercial ;
abandonner une donnée valide parce qu’un autre champ est erroné ;
présenter comme « source » une valeur recalculée ou issue d’un référentiel ;
créer un fichier syntaxiquement valide mais économiquement infidèle.

Le bon critère n’est donc pas « combien d’erreurs le validateur affiche ? », mais « quelle modification minimale résout la cause sans détériorer le reste ? ».

Ce point prolonge Pourquoi valider une facture électronique ne se résume pas à « valide / invalide » : un diagnostic multi-couches aide à cibler l’opération, pas seulement à afficher un badge.

Trois cas synthétiques, trois opérations différentes

Les exemples suivants sont entièrement fictifs.

1. Défaut local déterministe : réparer

État de la source. Un hybride correctement identifié contient un élément XML facultatif vide. Les autres données et le rendu sont cohérents.

La documentation FeRD de la version 2.5 signale que les éléments XML vides, souvent créés lorsqu’un champ facultatif est écrit sans valeur, ne doivent pas être générés et doivent être omis (publication officielle).

Opération choisie. Réparer localement en supprimant cet élément, après avoir confirmé qu’il est facultatif dans le profil et la version détectés.

Preuve attendue. Empreintes SHA-256 de la source et du candidat, règle appliquée, chemin du nœud supprimé et diff montrant l’absence de toute autre modification. Reconstruire toute la facture serait disproportionné.

2. Donnée déjà disponible : enrichir

État de la source. L’XML ne contient pas une référence de commande utile au rapprochement. Le PDF la présente lisiblement et le bon de commande enregistré dans l’ERP, déjà relié à la facture par des éléments concordants, contient la même valeur.

Opération choisie. Enrichir le candidat avec cette référence, avec une provenance double (visible + externe ERP). Si le PDF et l’ERP divergent, l’enrichissement automatique s’arrête : une confirmation ciblée remplace l’invention.

3. Porteur incompatible : reconstruire

État de la source. Un PDF ordinaire contient un XML comme simple pièce jointe, mais ne constitue pas le porteur hybride attendu. Les données économiques récupérables sont cohérentes.

Opération choisie. Reconstruire un nouveau candidat conforme au packaging et au profil ciblés, sans réécrire les faits métier non concernés. Un patch de champ ne peut pas transformer une relation de pièce jointe incompatible en conteneur Factur-X correctement construit.

Preuve attendue. Deux artefacts distincts, deux empreintes SHA-256, matrice de mapping et liste explicite des données conservées, transformées ou omises.

À quoi ressemble un repair plan exploitable ?

Le modèle suivant est conceptuel ; il ne reproduit pas un contrat runtime figé de FacturX API.

source:
  artifact_id: source-…
  sha256: …
  kind: …
observed_defect:
  code: …
  evidence: …
proposal:
  operation: preserve | normalize | repair | enrich | rebuild | ask
  justification: …
inputs:
  - value: …
    provenance: structured | visible | calculated | external | user_confirmed
transformations:
  - rule_id: …
    deterministic: true
data_effects:
  preserved: […]
  normalized: […]
  modified: […]
  enriched: […]
  omitted: […]
  requested_from_user: […]
target:
  artifact_kind: …
  profile: …
  version: …
validations_to_run: […]
stop_conditions: […]

La justification doit expliquer pourquoi une opération plus légère ne suffit pas et pourquoi une opération plus lourde serait inutile. Profil non résolu, sources contradictoires, valeur matérielle sans autorité ou validation indisponible doivent empêcher un faux succès.

Valider le candidat sans confondre conformité et fidélité

Le dossier Factur-X / ZUGFeRD (1.09.x) fournit des artefacts XSD et Schematron par profil. La Commission européenne recommande d’utiliser conjointement le schéma de syntaxe et le Schematron : le premier contrôle la structure, le second peut exprimer des relations, calculs et conditions entre éléments (FeRD, Commission européenne — Validations).

La version doit être explicite. Un simple statut valid sans version, syntaxe, profil et artefacts exécutés est insuffisant. Un profil non exécuté doit apparaître comme non évalué, pas comme conforme par défaut.

Mais réussir XSD et Schematron ne prouve pas que le candidat a conservé toutes les données fiables de la source. Ces validations portent sur le message candidat. La fidélité exige en plus un rapprochement source→candidat, un contrôle des calculs et une revue des omissions.

Ce qu’un candidat doit prouver

Le dossier minimal pour rendre une réparation vérifiable :

identifiant et SHA-256 du candidat ;
profil et version ciblés ;
résultats de validation propres au candidat ;
diff de la source vers le candidat ;
données conservées, normalisées, corrigées, enrichies et omises ;
journal des règles et confirmations appliquées.

Le NIST décrit les empreintes SHA comme un moyen de détecter si un message a changé (FIPS 180-4). Le hash établit l’identité des octets contrôlés ; il ne démontre ni la conformité normative, ni la fidélité économique, ni l’acceptation externe.

Le dossier de preuve complet est développé dans Un candidat généré sans fichier, hash, diff ni omissions explicites n’est pas une preuve.

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 à un cas donné, est une transformation documentaire. Un profil non exécuté doit rester non évalué. FacturX API n’est pas une Plateforme Agréée et ne revendique ni transmission officielle ni conformité fiscale finale.

Les six opérations de cet article forment un modèle de décision à exiger d’une architecture. Elles ne constituent pas l’attestation que chaque chemin est déjà exposé de façon identique sur toutes les surfaces publiques. La génération d’un candidat local utile n’équivaut pas à « prêt à transmettre ». Voir « Générable maintenant » ne veut pas dire « prêt à transmettre ».

Sources officielles

Légifrance — Article 289 du CGI
BOFiP — BOI-TVA-DECLA-30-20-30-10
FNFE-MPE — Factur-X
FeRD — ZUGFeRD 2.5
Commission européenne — Validations
NIST — FIPS 180-4

Les publications Factur-X / ZUGFeRD et le cadre fiscal évoluent : revérifiez les versions au moment de la lecture.

Vous voulez un diagnostic avant de reconstruire ?

Voici ce que vous allez obtenir :

Scan = diagnostic documentaire, pas réparation silencieuse
Profils exécutés vs non évalués explicitement
Prochaine action utile sans promesse de transmission
Aucune revendication d’acceptation PA ou de conformité fiscale finale

Scanner un document Créer une clé API