Le moteur de réparation

Repair Factur-X : corriger un XML CII sans inventer la facture

L'endpoint /repair prend un XML CII, applique seulement les corrections déterministes couvertes, puis propose le XML corrigé uniquement si la cible de validation demandée est vérifiée. Les PDF, la génération et le packaging passent par /convert.

Vérifier ma facture Pour les intégrateurs ERP

Le problème que personne ne résout publiquement

Valider un XML dit ce qui casse. Réparer doit rester plus strict : l'API ne modifie que les cas déterministes, trace le diff, puis revalide la sortie. Quand une décision métier ou un fichier PDF est nécessaire, le résultat reste un diagnostic ou bascule vers /convert.

❌ Outils classiques

— "Validation failed" sans indication du champ
— Rejet complet pour une erreur récupérable
— Pas de distinction entre erreur fatale et erreur réparable
— Logs applicatifs illisibles pour le support

Repair XML FacturX API

— Diagnostic machine-readable par champ (BT-XX)
— Classification : correction, normalisation ou vérification manuelle
— Correction appliquée uniquement si la règle est déterministe
— Diff traçable et validation de sortie avant livrable

Deux chemins, deux contrats

On sépare volontairement la réparation XML du pipeline de génération. Cela évite de promettre à un utilisateur Repair une capacité qui appartient à Convert.

Standalone /repair

XML CII en entrée, XML CII en sortie

— Corrige les cas XML déterministes couverts.
— Retourne un diff exploitable par votre support ou votre ERP.
— Propose un XML uniquement si la validation cible est vérifiée après correction.
— Ne reconstruit pas un PDF et ne complète pas une donnée métier absente.

Pipeline /convert

Transformation, données source et packaging

— Génère un XML CII depuis des données structurées validées.
— Peut produire un Factur-X PDF/A-3 quand le PDF source et les compléments requis sont fournis.
— Rejoue les contrôles de sortie sur le candidat généré.
— Signale les champs ou fichiers manquants au lieu de les inventer.

Ce que /repair peut corriger

Règles XML déterministes, aucune inférence statistique. Chaque correction reste traçable dans le diff.

Codes d'unité non conformes UN/ECE Rec 20

Déterministe

"For" (VISIOpaie), "Forfait", "pièce", "jour"… ces codes cassent la règle Schematron BR-CL-23. On les normalise vers le code UN/ECE valide correspondant (C62, H87, DAY, HUR, …).

unitCode="For" → unitCode="C62" // logged in normalizations_applied

Formats XML et namespaces couverts

Déterministe

Certains écarts de format XML ou de namespace peuvent être corrigés sans choix métier. Le diff indique le chemin XML, l'ancienne valeur et la valeur produite.

Points non mutés à vérifier manuellement

Pas une correction

Exemple : un identifiant dont le schemeID n'est pas reconnu peut être signalé dans le résultat, mais il n'est pas compté comme erreur corrigée.

Ce qu'on ne répare pas (franchise)

On ne réparera jamais ce qui nécessite une décision métier. Dans ces cas-là, on renvoie un diagnostic clair avec le champ concerné, pour que votre produit puisse demander l'info à l'utilisateur.

🚫

Conteneur PDF, XMP ou pièce jointe Factur-X

Repair ne reconstruit pas le PDF. Utilisez /convert avec le PDF source pour un livrable packagé.

🚫

Totaux, TVA ou arrondis métier incohérents

Un calcul de facture dépend de la source métier. L'API signale le problème au lieu de recalculer silencieusement.

🚫

SIRET / numéro de TVA manquant ou invalide

Donnée de référentiel, vérifiable mais pas inférable.

🚫

Compte de paiement vendeur absent

Coordonnée de paiement sensible (IBAN ou identifiant propriétaire), jamais inventée.

🚫

Adresse de l'acheteur structurellement absente

Obligatoire EN16931. Diagnostic renvoyé avec suggestion de zone de saisie.

🚫

Taux de TVA incohérent avec le pays

On signale mais on ne corrige pas — pourrait masquer une fraude ou une erreur de catégorisation métier.

🚫

Lignes de facturation entièrement absentes

Pas de reconstruction depuis le texte sans source structurée fiable.

Traçabilité audit-ready

Chaque appel à l'API retourne la liste exacte des normalisations appliquées. Vous pouvez rejouer, auditer, contester, versionner.

POST /api/v1/repair — réponse (extrait)

{
  "repairSuccessful": true,
  "diff_summary": [
    {
      "code": "UNIT_CODE_NORMALIZED",
      "path": "/.../ram:BilledQuantity/@unitCode",
      "beforeValue": "For",
      "afterValue": "C62",
      "changeCategory": "normalization"
    }
  ],
  "target": {
    "requested": "en16931",
    "executed": "en16931",
    "status": "verified"
  },
  "validation_after": {
    "valid": true,
    "summary": { "errorCount": 0, "warningCount": 0 }
  }
}

Aucun contenu PII (numéros clients, montants, noms) n'est loggé côté serveur. Seules les métadonnées techniques sont conservées pour observabilité.

Quota : chaque appel API traite une facture, quel que soit l'endpoint appelé. Voir le pricing détaillé.

Prêt à tester sur votre cas réel ?

Déposez un PDF ou un XML dans le scanner. Le rapport sépare ce qui relève d'une réparation XML, d'une génération /convert, ou d'une donnée métier à fournir.

Tester gratuitement Discuter d'un pilot ERP

Et après ?

Aller plus loin

Choisissez l'étape suivante pour activer FacturX API sur votre stack. Tous les liens sont internes pour garder le suivi clair.

→

Pour les intégrateurs ERP

Mode ERP-assisted, pilotes sur mesure, support technique async.

→

Pourquoi les validateurs diffèrent

Comprendre les écarts entre périmètres PDF, XML, EN16931 et France CTC.

→

Méthodologie de validation

Pipeline 4 étapes : PDF/A-3 → Factur-X → XSD → Schematron.

→

Documentation API

Référence OpenAPI, collection Postman, exemples curl et snippets Python/Node/PHP.