# Votre propre design PDF en Factur-X/ZUGFeRD

> https://billhorse.com/fr/guides/pdf-personnalise-zugferd-factur-x/

Beaucoup d'équipes disposent d'un PDF de facture soigneusement mis en page — logo, typographie maison, pied de page avec conditions de règlement — et doivent désormais en faire une facture électronique sans renoncer au design. C'est précisément la raison d'être de Factur-X et de ZUGFeRD : des factures hybrides, lisibles par l'humain comme avant, et porteuses d'un XML structuré pour les machines. Le chemin est bien spécifié, mais il échoue régulièrement en pratique sur une poignée de détails.

## Anatomie : un PDF/A-3 avec un XML CII intégré

Une facture Factur-X/ZUGFeRD se compose de trois couches :

**Le conteneur est un PDF/A-3.** Ni PDF 1.4, ni PDF 1.7, mais la norme d'archivage ISO 19005-3 — la seule variante PDF/A qui autorise des pièces jointes arbitraires. Le PDF/A-3 interdit par ailleurs le chiffrement, le JavaScript et les dépendances externes comme les polices non embarquées.

**Le XML intégré** est un fichier UN/CEFACT CII dont le nom est normalisé et dépend du standard et de la version : `factur-x.xml` pour Factur-X 1.0 et ZUGFeRD 2.1+ (`xrechnung.xml` dans le profil XRECHNUNG), `zugferd-invoice.xml` pour ZUGFeRD 2.0, `ZUGFeRD-invoice.xml` pour l'ancien ZUGFeRD 1.0. La pièce jointe doit porter une entrée `AFRelationship` — en général `Alternative` pour les profils complets (le XML est une représentation alternative de la même facture), mais `Data` ou `Source` pour les profils réduits MINIMUM et BASIC WL.

**Les métadonnées XMP** du PDF déclarent, via le schéma d'extension Factur-X, ce qui est intégré : `DocumentType` (INVOICE), `DocumentFileName` (exactement le nom de la pièce jointe), `Version` et `ConformanceLevel` — c'est-à-dire le profil, de MINIMUM à EXTENDED. Les systèmes destinataires lisent cette déclaration avant même de toucher au XML.

## Les pièges classiques

Presque toutes les factures hybrides défectueuses relèvent de l'un de ces schémas :

- **Un PDF ordinaire au lieu d'un PDF/A-3.** Le moteur de rendu produit du PDF 1.4/1.7 et le XML est joint « tant bien que mal ». Certains destinataires l'extraient malgré tout ; les contrôles conformes rejettent le fichier.
- **Déclaration XMP absente ou erronée.** Le XML est là, mais les métadonnées XMP manquent ou désignent un autre nom de fichier — pour les destinataires stricts, ce n'est pas une Factur-X.
- **Mauvais nom de pièce jointe.** `facture.xml` ou `invoice.xml` au lieu de `factur-x.xml`. Le contenu a beau être parfait, il ne sera pas trouvé partout.
- **Incohérence de profil.** Le XML déclare le profil EN 16931 via la CustomizationID ([BT-24](/fr/termes/bt-24/)) tandis que le XMP indique BASIC — deux vérités auxquelles les destinataires accordent une confiance variable. Quels profils valent facture électronique, c'est l'objet du [guide des profils](/fr/guides/profils-zugferd-factur-x/) ; MINIMUM et BASIC WL sont signalés par le validateur comme [BH-PROFILE-01](/fr/regles/bh-profile-01/).
- **PDF chiffrés.** La protection par mot de passe ressemble à de la sécurité, mais elle rend le XML intégré illisible — et le chiffrement est de toute façon interdit en PDF/A-3. Billhorse le signale explicitement comme [BH-PDF-02](/fr/regles/bh-pdf-02/).

## Les outils, en bref

Inutile de réinventer la roue. Dans l'écosystème Java, mustangproject et PDFBox sont des voies éprouvées pour convertir un PDF existant en PDF/A-3 et y joindre le XML avec `AFRelationship` et XMP ; des bibliothèques comparables existent pour .NET et Python. Le principe reste toujours le même : rendre le PDF au design habituel, puis, dans une seconde étape, convertir le conteneur, intégrer le XML, écrire le XMP.

Une priorité doit rester claire : la partie lisible par machine est ce que les destinataires traitent réellement — le design n'est là que pour l'œil. C'est au XML qu'il faut consacrer le soin : arithmétique des totaux correcte, champs obligatoires complets, bon profil. Un beau PDF avec un XML cassé n'est pas une facture électronique ; un PDF sobre avec un XML propre, si.

## Le circuit de vérification : contre-vérifier le résultat

Avant tout envoi, le PDF généré passe par le [validateur Billhorse](/fr/validateur-factur-x/) : il extrait le XML intégré directement du conteneur PDF et le valide contre l'EN 16931 et les règles propres au profil — entièrement dans le navigateur, sans téléversement. Si aucun XML de facture n'est trouvé dans le PDF, le résultat est [BH-PDF-01](/fr/regles/bh-pdf-01/) — le symptôme le plus fréquent d'une chaîne de génération qui a simplement oublié l'étape d'intégration. Si le PDF est chiffré, cela est signalé explicitement comme BH-PDF-02, et non comme une vague erreur d'analyse. Testez avec de vrais cas limites : une facture avec remise, un avoir, une facture à plusieurs taux de TVA — c'est là qu'apparaissent les erreurs de mapping que l'exemple nominal ne déclenche jamais.

## Obligation : la partie visible et le XML doivent concorder

Un point n'est pas une question de style mais une obligation : le PDF visible et le XML intégré doivent décrire la même facture. Juridiquement, c'est la partie structurée qui fait foi — si le rendu visuel s'en écarte, c'est le XML qui prévaut. Les divergences naissent presque toujours quand PDF et XML sont produits par des chemins de code séparés : le PDF arrondit autrement, le XML ignore la remise, une ligne manque. L'architecture robuste rend les deux représentations depuis la même source de données — un modèle de facture, deux sorties. Construit ainsi dès le départ, la cohérence n'a plus jamais besoin d'être vérifiée à la main.