PDF/A est le format d’archivage long terme du PDF. La plupart des développeurs le connaissent dans sa version originale — PDF/A-1 — parce que c’est celle que demandent les archives publiques, les cabinets d’avocats et les systèmes de GED depuis 2005. Quand la question Factur-X arrive sur la table, la première réaction est souvent : “on génère déjà du PDF/A, on est bons”.
Non. Factur-X 1.08 / ZUGFeRD 2.4 exige PDF/A-3 — pas PDF/A-1, pas PDF/A-2. La différence n’est pas cosmétique. Elle touche à une capacité fondamentale du format : le droit d’embarquer des fichiers arbitraires dans le conteneur PDF. Sans cette capacité, le concept même de facture hybride (lisible par l’humain et par la machine) est impossible.
Cet article explique pourquoi, en remontant à la source : les trois générations de la norme ISO 19005 et ce que chacune autorise ou interdit.
Pour le contexte complet de la réforme de facturation électronique, voir Facturation électronique 2026 : le guide technique complet pour développeurs.
Les trois générations de PDF/A
La norme PDF/A (ISO 19005) a été publiée en trois parties successives. Chaque partie hérite des contraintes de la précédente et ajoute des fonctionnalités. Toutes partagent le même objectif : garantir qu’un document PDF reste lisible et reproductible de manière identique dans 10, 50 ou 100 ans, sans dépendance à un logiciel spécifique.
PDF/A-1 — ISO 19005-1 (2005)
La première génération. Basée sur PDF 1.4, elle pose les fondations de l’archivage numérique :
- Polices embarquées obligatoirement (ou sous-ensembles)
- JavaScript interdit — aucun code exécutable dans le document
- Pas de chiffrement — le contenu doit rester accessible sans clé
- Profil colorimétrique ICC requis si des espaces non calibrés sont utilisés
- Métadonnées XMP obligatoires
- Aucune pièce jointe autorisée — le PDF doit être autosuffisant
C’est ce dernier point qui élimine PDF/A-1 pour Factur-X. Le standard interdit purement et simplement les fichiers embarqués (EmbeddedFiles dans le catalogue PDF). Un PDF/A-1 est un conteneur hermétique : il ne transporte que le rendu visuel du document.
PDF/A-1 existe en deux niveaux de conformité : 1a (accessibilité complète avec structure logique et Unicode) et 1b (rendu visuel garanti, sans exigence de structure logique).
PDF/A-2 — ISO 19005-2 (2011)
Six ans plus tard, la deuxième génération modernise le format. Basée sur PDF 1.7, elle ajoute :
- Compression JPEG2000 pour les images (meilleure qualité à taille réduite)
- Transparence et calques (layers/OCGs)
- Signatures numériques PAdES
- Pièces jointes PDF/A autorisées — mais uniquement des fichiers eux-mêmes conformes PDF/A
Ce dernier point est crucial. PDF/A-2 ouvre une brèche dans l’interdiction de PDF/A-1, mais une brèche étroite : on peut embarquer un fichier PDF/A dans un autre fichier PDF/A. On ne peut pas embarquer un fichier XML, un CSV, un tableur ou tout autre format non-PDF/A.
Pour Factur-X, cela ne suffit pas. Le XML CII (factur-x.xml) est un fichier texte structuré au format UN/CEFACT Cross-Industry Invoice — pas un PDF/A. PDF/A-2 le rejette.
PDF/A-2 existe en trois niveaux : 2a, 2b et 2u (comme 2b mais avec mappage Unicode garanti).
PDF/A-3 — ISO 19005-3 (2012)
La troisième génération reprend tout ce que PDF/A-2 apporte et lève la dernière restriction : les fichiers embarqués peuvent être de n’importe quel type. XML, CSV, JSON, tableurs, fichiers CAO — tout est autorisé, à condition que chaque fichier embarqué soit déclaré avec un attribut /AFRelationship qui qualifie sa relation avec le document hôte.
C’est cette capacité qui rend possible le format hybride Factur-X : un PDF contenant à la fois le rendu visuel de la facture et le fichier XML structuré qui la décrit.
Tableau comparatif
| Caractéristique | PDF/A-1 (2005) | PDF/A-2 (2011) | PDF/A-3 (2012) |
|---|---|---|---|
| Norme ISO | 19005-1 | 19005-2 | 19005-3 |
| Base PDF | 1.4 | 1.7 | 1.7 |
| Polices embarquées | Oui | Oui | Oui |
| JavaScript interdit | Oui | Oui | Oui |
| Profil ICC requis | Oui | Oui | Oui |
| Compression JPEG2000 | Non | Oui | Oui |
| Transparence / calques | Non | Oui | Oui |
| Pièces jointes PDF/A | Non | Oui | Oui |
| Pièces jointes arbitraires (XML, CSV…) | Non | Non | Oui |
| Compatible Factur-X | Non | Non | Oui |
La colonne de droite résume la situation : seul PDF/A-3 autorise les pièces jointes non-PDF, et donc seul PDF/A-3 peut servir de conteneur pour Factur-X.
Pourquoi PDF/A-3 spécifiquement pour Factur-X
Le concept de Factur-X repose sur un format hybride : un seul fichier transporte deux représentations de la même facture. Le PDF fournit le rendu visuel pour l’humain. Le XML CII fournit les données structurées pour la machine. Les deux sont indissociables — le XML n’est pas une pièce jointe séparée envoyée par email, il est embarqué dans le flux PDF lui-même.
Cette architecture impose trois exigences techniques que seul PDF/A-3 satisfait :
1. Le XML doit être un fichier embarqué (EmbeddedFile)
Le fichier factur-x.xml est enregistré dans le name tree EmbeddedFiles du catalogue PDF. Ce mécanisme est interdit en PDF/A-1 et restreint aux seuls fichiers PDF/A en PDF/A-2.
2. Le fichier embarqué doit avoir un AFRelationship
PDF/A-3 exige que chaque fichier embarqué déclare sa relation avec le document hôte via l’attribut /AFRelationship. L’AFRelationship dépend de la relation réelle entre le PDF lisible et le XML : Data, Source ou Alternative. Dans certains contextes réglementaires, Alternative est imposé — c’est le cas de la spécification Factur-X 1.x / ZUGFeRD 2.1+, qui recommande /Alternative pour signifier que le XML est une représentation alternative du même contenu.
3. Le conteneur doit être archivable à long terme
Factur-X est conçu pour l’archivage fiscal. Les factures doivent être conservées 10 ans minimum (Code de commerce, article L123-22). PDF/A-3 garantit que le document restera lisible indéfiniment, sans dépendance à un logiciel ou une police externe.
Pour comprendre comment les profils Factur-X (MINIMUM à EXTENDED) déterminent le niveau de détail du XML embarqué, voir Profils Factur-X : MINIMUM, BASIC, EN16931, EXTENDED.
Ce que ça change en pratique pour les développeurs
La conséquence directe pour les développeurs : les outils qui produisent du PDF/A-1 ou du PDF standard ne suffisent pas. Générer un conteneur Factur-X valide exige une chaîne d’outils capable de produire du PDF/A-3 et d’embarquer le XML avec les bons attributs.
Les bibliothèques PDF classiques ne suffisent pas
Des outils comme WeasyPrint, wkhtmltopdf ou Puppeteer/Chromium ne génèrent pas nativement du PDF/A-3 avec pièces jointes. Prince, en revanche, supporte les profils PDF/A-3 avec attachments, mais la gestion correcte des métadonnées Factur-X (XMP, AFRelationship, profil) reste à la charge de l’intégrateur.
Ghostscript convertit mais n’embarque pas
Ghostscript sait gérer la conversion PDF/A-3 et peut participer à la création d’un fichier Factur-X conforme, mais pas en une seule commande. Le profil -dPDFA=3 convertit un PDF existant en PDF/A-3 (profil ICC, polices, métadonnées XMP). Il faut ensuite piloter explicitement l’embarquement du XML et l’ajout des métadonnées XMP (namespace fx:, AFRelationship) — typiquement via une bibliothèque comme pikepdf (Python) ou PDFBox (Java).
Le pipeline réaliste en deux étapes
En pratique, produire un Factur-X conforme implique au minimum :
- Convertir le PDF en PDF/A-3 — Ghostscript, ou une bibliothèque qui génère directement du PDF/A-3
- Embarquer le XML CII avec le bon
AFRelationship, le type MIMEtext/xml, et les métadonnées XMP Factur-X (namespacefx:, GuidelineID correspondant au profil)
Ces deux étapes doivent être coordonnées. Un PDF/A-3 valide sans XML embarqué n’est pas un Factur-X. Un PDF standard avec un XML embarqué n’est pas conforme PDF/A-3.
Le guide complet de cette conversion est couvert dans Convertir une facture PDF en Factur-X 1.08 conforme (PDF/A-3 + XML CII D22B).
Les erreurs veraPDF les plus courantes liées à la confusion PDF/A-1 vs PDF/A-3
Quand une bibliothèque produit du PDF/A-1 ou du PDF/A-2 alors que le workflow attend du PDF/A-3, les validateurs comme veraPDF signalent des erreurs spécifiques. En voici les plus fréquentes.
pdfaid:part incorrect dans le XMP
<!-- Attendu pour Factur-X -->
<pdfaid:part>3</pdfaid:part>
<pdfaid:conformance>B</pdfaid:conformance>
<!-- Trouvé dans un PDF/A-1 -->
<pdfaid:part>1</pdfaid:part>
<pdfaid:conformance>B</pdfaid:conformance>Si pdfaid:part vaut 1 ou 2, le fichier n’est pas déclaré PDF/A-3 dans ses métadonnées. Même si un XML est embarqué, la structure est incohérente et sera rejetée.
Fichier embarqué interdit en PDF/A-1
ERROR: The embedded file is not allowed in PDF/A-1 documents (ISO 32000-1:7.11)Cette erreur signifie que le PDF se déclare PDF/A-1 mais contient un fichier embarqué. PDF/A-1 interdit purement et simplement les EmbeddedFiles. La solution n’est pas de supprimer le XML — c’est de passer le conteneur en PDF/A-3.
AFRelationship absent
ERROR: An embedded file does not have an associated AFRelationship keyPDF/A-3 exige que chaque entrée dans le name tree EmbeddedFiles soit accompagnée d’un attribut /AFRelationship. Cette erreur survient quand le XML est embarqué avec un outil qui ne connaît pas les spécificités PDF/A-3 — il insère le fichier dans le flux PDF mais sans les métadonnées requises.
Profil ICC absent ou incorrect
ERROR: If device-specific color space is used, OutputIntent shall be present (ISO 19005-3:2012, 6.2.3)Cette erreur n’est pas spécifique à PDF/A-3 — elle touche les trois niveaux. Mais elle apparaît fréquemment dans les conversions PDF/A-3 parce que les outils configurés pour “juste convertir en PDF/A” omettent parfois la configuration du profil ICC dans OutputIntents. L’article PDF/A-3 pour Factur-X : checklist de conformité et pièges courants détaille les configurations Ghostscript et mPDF pour éviter ce piège.
JavaScript résiduel
ERROR: The document catalog shall not contain the key named JavaScript (ISO 19005-3:2012, 6.1.6)Un PDF source contenant du JavaScript (formulaires interactifs, scripts Adobe) ne sera pas conforme après conversion en PDF/A-3 si le convertisseur ne nettoie pas les entrées /JavaScript et /JS du catalogue. Ghostscript le fait généralement, mais certaines bibliothèques de manipulation PDF (pikepdf, PyPDF) qui modifient un PDF existant peuvent laisser ces entrées intactes.
Aller plus loin
Le choix de PDF/A-3 pour Factur-X n’est pas arbitraire — c’est la conséquence logique d’un format qui fusionne document visuel et données structurées dans un seul fichier. PDF/A-1 et PDF/A-2 ont été conçus pour des conteneurs hermétiques ou semi-ouverts. Seul PDF/A-3 accepte le principe d’un PDF qui transporte des données de nature différente.
Pour approfondir :
- PDF/A-3 pour Factur-X : checklist de conformité et pièges courants — diagnostic et correction des erreurs ISO 19005-3
- Convertir une facture PDF en Factur-X 1.08 conforme — le pipeline complet PDF vers PDF/A-3 + XML CII
- Factur-X vs UBL vs CII : quel format choisir — pourquoi Factur-X (et donc PDF/A-3) plutôt qu’un format purement XML
- Extraire l’XML d’un PDF Factur-X reçu — comment exploiter le XML embarqué que PDF/A-3 rend possible
- Valider EN16931 / Factur-X en pratique — la validation complète au-delà du conteneur PDF/A-3