Convertir un PDF de facture en Factur-X — comment ça marche vraiment
Oui, la conversion existe — mais elle ne ressemble pas à ce que vous imaginez.
La question revient régulièrement : peut-on convertir automatiquement un PDF de facture classique en Factur-X ? La réponse honnête est : oui, mais pas comme vous l'imaginez. La conversion magique « OCR + bouton convertir = facture EN 16931 complète et exacte » n'existe pas. En revanche, on peut faire bien mieux qu'une simple ressaisie : c'est exactement ce que fait notre Convertisseur PDF → Factur-X. Cet article explique le compromis qu'il applique, pourquoi il est honnête, et pourquoi il suffit à 90 % des cas.
Pourquoi la conversion « 100 % automatique » est un mythe
Un PDF de facture classique est un document de présentation : il contient du texte positionné, des images, parfois des tableaux. Il ne contient aucune donnée structurée que la norme Factur-X / EN 16931 attend. Pour produire un XML CII conforme, il faut récupérer des champs nominatifs (vendeur, acheteur, totaux, SIRET, identifiants TVA) — et ces champs ne sont jamais marqués comme tels dans le PDF source.
Trois obstacles rendent une conversion purement automatique peu fiable :
- L'OCR est probabiliste. Reconnaître « 1 234,56 » comme un montant TTC plutôt que comme une référence article, ou distinguer une adresse de livraison d'une adresse de facturation, demande une compréhension sémantique que les moteurs OCR généralistes n'ont pas.
- La structure visuelle varie. Deux factures du même émetteur peuvent avoir des mises en page différentes selon la prestation, ce qui casse les heuristiques de positionnement.
- Les identifiants normés manquent. Un PDF n'impose pas de déclarer le code pays vendeur, le
schemeIDdu SIREN, ou le code devise ISO 4217. Sans ces métadonnées, le XML produit serait invalide au regard du profil MINIMUM.
N'importe quel outil qui prétend « convertir » un PDF en Factur-X devra, en pratique, demander à l'utilisateur de confirmer ou corriger les champs critiques. La différence entre un bon et un mauvais convertisseur, c'est combien il en demandeet combien il en suggère.
L'approche de notre Convertisseur : honnête par construction
Notre Convertisseur applique un compromis assumé en trois principes, dont chacun a une conséquence visible sur l'UX.
Principe 1 — On garde votre PDF d'origine comme couche visuelle
Le PDF que vous déposez n'est pas re-rendu. On le convertit en PDF/A-3b via Ghostscript (étape technique nécessaire pour pouvoir y embarquer un fichier XML), mais sa présentation — vos lignes de détail, votre logo, votre mise en page — reste rigoureusement identique. Ce choix résout deux problèmes : vous gardez exactement la facture que votre client connaît, et on évite d'avoir à reconstituer les lignes structurées (que le profil MINIMUM ne demande pas de toute façon).
Principe 2 — On vise MINIMUM ou BASIC WL, pas plus
On embarque un XML CII profil MINIMUM v1.0.08 (≈ 12 champs d'entête : parties, totaux, devise, dates) — ou, automatiquement, BASIC WL (Without Lines, ≈ 20 champs) dès que votre facture contient un acompte ou un détail TVA multi-taux. BASIC WL ajoute trois éléments structurels essentiels au-dessus de MINIMUM :
- L'acompte porté. Si vous avez déjà payé une partie (cas EDF avec prélèvement automatique, factures professions libérales acquittées en séance), BASIC WL écrit
TotalPrepaidAmountdans le XML, etDuePayableAmountdevient le vrai reste à payer (pas le total TTC aplati comme en MINIMUM). - Le multi-taux TVA ventilé. Si votre facture a 5,5 % sur une partie et 20 % sur le reste (cas SOWEE, Free Mobile, factures telco/énergie), BASIC WL crée une
ApplicableTradeTaxpar taux avec sa base et son montant. En MINIMUM, on aurait une TVA agrégée — un lecteur comptable destinataire perdrait la granularité. - Les conditions de paiement. Échéance, mode (chèque/virement/CB), référence — utiles pour les flux automatisés côté receveur.
Pas de BASIC complet (avec lignes structurées) ni EN 16931 ni EXTENDED : pour produire les profils supérieurs, il faudrait reconstituer les lignes de facture détaillées, ce qui est exactement la promesse impossible ci-dessus. MINIMUM et BASIC WL suffisent légalement à recevoir et à émettre dans la grande majorité des cas B2B français en transition (cf. profil MINIMUM : les 18 champs obligatoires).
Principe 3 — Vous confirmez chaque champ détecté
L'extracteur applique des regex et des heuristiques (Luhn pour le SIRET, MOD 97 pour le numéro de TVA, cross-validation HT + TVA = TTC), puis vous présente un formulaire pré-rempli avec un badge de confiance par champ : vert si haute confiance (≥ 70 %), ambre si à vérifier (40 à 70 %), vide si on n'a rien trouvé de fiable. Vous corrigez, vous validez, on génère. On ne devine pas dans votre dos : si on trouve plusieurs candidats pour le total TTC, on les signale tous au lieu d'en choisir un au hasard.
Le pipeline technique en 6 étapes
Pour les curieux, voici ce qui se passe entre votre drag-drop et le téléchargement final :
- Garde-fous PDF. Taille < 15 Mo, magic bytes
%PDF, nombre de pages < 1 000. - Détection d'un Factur-X déjà embarqué. Si votre PDF contient déjà un
factur-x.xml, on refuse la conversion (codeALREADY_FACTURX) et on vous renvoie vers le visualiseur ou le validateur. - Extraction du texte. pdfplumber d'abord (texte déterministe), puis fallback Tesseract OCR (langue fra+eng, DPI 200, limite 10 pages) si la couche texte fait moins de 200 caractères — typique d'un PDF scanné.
- Conversion PDF/A-3b. Ghostscript avec
-dPDFA=3 -dPDFACompatibilityPolicy=1. C'est ce qui rend le PDF archivable et capable de porter une pièce jointe normée. - Choix automatique MINIMUM ou BASIC WL et construction du XML CII.
pick_profileregarde si vous avez un acompte (paid_amount > 0) ou un détail multi-taux TVA — si oui, BASIC WL ; sinon MINIMUM. À partir des champs que vous avez confirmés. On réutilise les mêmes briques que notre générateur (xml_builder, validation Pydantic, calculsBR-CO-*). - Embed du XML + validation finale. Via la lib factur-x d'Akretion. Si la validation Schematron post-embed échoue, on refuse — on ne livre jamais un fichier non-conforme avec un faux succès.
Convertisseur vs Générateur : quel outil pour quel besoin ?
Nous avons deux outils distincts pour produire un Factur-X, parce qu'ils répondent à deux usages différents.
| Critère | Convertisseur | Générateur |
|---|---|---|
| Quand l'utiliser | Vous avez déjà un PDF (vieux logiciel, modèle Word, sortie ERP) | Dépannage ponctuel : aucun PDF, vous saisissez tout |
| Couche visuelle | PDF d'origine conservé tel quel | PDF généré depuis le formulaire (mise en page sobre) |
| Champs à saisir | ~12 confirmations (pré-remplies via OCR) | 18 champs MINIMUM intégralement |
| Lignes de détail | Restent dans le PDF visuel | Pas portées en XML (MINIMUM seul) |
| Cas idéal | Vous avez un logiciel qui sort des PDFs mais pas du Factur-X | Vous facturez 1 à 2 fois par an depuis un tableur ou Word |
En clair : si vous avez déjà un PDF, utilisez le Convertisseur. C'est plus rapide, votre client reçoit exactement la facture qu'il connaît, et vous évitez toute ressaisie. Le Générateur reste là pour les cas où il n'existe aucun PDF source.
Limites du profil MINIMUM (à connaître avant de choisir)
- Pas de TVA ventilée. Un seul total de TVA est porté. Si vous avez plusieurs taux ou des exonérations à déclarer, il faut viser BASIC ou EN 16931 (non couverts par cette V1).
- Pas de lignes structurées. Vos articles, quantités, prix unitaires restent dans le PDF visuel mais ne sont pas réutilisables côté ERP destinataire pour rapprochement automatique.
- Adresses postales absentes. Les champs
PostalTradeAddressdétaillés ne font pas partie de MINIMUM. - Acceptation réduite par certaines plateformes. Les grandes entreprises (CAC 40, secteur public) exigent souvent BASIC ou EN 16931 pour l'automatisation comptable. Pour la transition 2026 et la majorité du B2B PME, MINIMUM suffit.
Détails dans notre comparaison des profils Factur-X.
Et après la conversion ?
Le PDF/A-3 Factur-X téléchargé est utilisable immédiatement, mais nous recommandons systématiquement de le passer ensuite au validateur pour confirmer la triple conformité : XSD CII D16B, Schematron EN 16931 + CIUS FR (FNFE-MPE), et PDF/A-3b veraPDF. C'est rapide, c'est gratuit et sans compte, et ça vous évite un retour désagréable de votre client ou de sa plateforme de réception.
Pour la transmission elle-même, rappelons que nous ne sommes pas une PDP : vous devez passer par une plateforme agréée (PDP ou PPF). Le fichier produit par notre Convertisseur est bien le bon format — c'est juste qu'il ne circule pas par nos serveurs.
Ce qu'il faut retenir
- La conversion automatique « magique » n'existe pas, mais une conversion assistée (extraction + confirmation utilisateur) fonctionne très bien — c'est ce que fait notre Convertisseur.
- Le compromis : on garde votre PDF d'origine comme couche visuelle (lignes, présentation), on embarque uniquement un XML profil MINIMUM (~12 champs d'entête).
- Vous confirmez chaque champ détecté. Pas d'hallucination : si plusieurs candidats sont trouvés pour un total, on vous laisse choisir.
- Utilisez le Convertisseur si vous avez un PDF, le Générateur uniquement pour les cas où vous partez de zéro (dépannage ponctuel).
- Validez systématiquement la sortie avec notre validateur avant diffusion.