PDF/A est un sous-ensemble de PDF normalisé par l’ISO (ISO 19005), conçu pour l’archivage à long terme : un fichier doit avoir dans dix ans exactement l’aspect qu’il a aujourd’hui, quel que soit le programme qui l’ouvre. PDF/A-3 — la troisième partie, ISO 19005-3 — ajoute une seule capacité, et c’est elle qui rend les factures hybrides possibles.
Ce qu’exige PDF/A
La norme retire du PDF tout ce qui rend un document dépendant de son environnement :
- Les polices doivent être incorporées. Un fichier ne peut pas compter sur la présence de la police chez le lecteur — sinon la composition change et les montants se déplacent.
- Les couleurs doivent être auto-descriptives, par un profil colorimétrique incorporé et non par un réglage de l’écran.
- Aucune dépendance externe : pas de JavaScript, pas de chiffrement, aucun renvoi à des fichiers situés ailleurs.
- Des métadonnées en XMP, lisibles par machine et contenues dans le document lui-même.
Pour une facture, ce n’est pas du formalisme : en Allemagne, la conservation est de huit ans, et un document dont l’apparence dépend d’une police installée n’est plus une pièce fiable au bout de huit ans.
Pourquoi la troisième partie précisément
PDF/A-1 et PDF/A-2 n’admettent pas de pièces jointes quelconques — PDF/A-2 n’accepte que d’autres fichiers PDF/A. Seul PDF/A-3 permet d’incorporer n’importe quel fichier dans le PDF et de le marquer comme partie intégrante du document.
Tout le format hybride tient là-dessus. Un fichier Factur-X ou ZUGFeRD est un PDF/A-3 avec exactement une pièce jointe particulière : un fichier XML, généralement factur-x.xml, portant la même facture en structure CII. L’humain voit la page, le logiciel lit la pièce jointe — et les deux restent ensemble au fil des transferts, du classement et de l’archivage, parce que c’est un seul fichier.
Les niveaux de conformité A, B et U
À l’intérieur de PDF/A-3, trois niveaux exigent des choses différentes :
| Niveau | Ce qu’il exige en plus |
|---|---|
| B (Basic) | l’apparence est garantie — le document a toujours le même aspect |
| U (Unicode) | en plus : le texte peut être extrait de façon fiable en Unicode |
| A (Accessible) | en plus : un balisage de structure pour l’accessibilité et l’ordre de lecture |
Pour les factures électroniques, PDF/A-3B est le niveau habituel et suffisant — les données lisibles par machine se trouvent de toute façon dans la pièce jointe XML, pas dans le texte de la page. E-Rechnung Pro produit des fichiers à ce niveau.
Une pièce jointe ne suffit pas
C’est là que les fichiers fabriqués à la main échouent le plus souvent — et c’est invisible tant qu’on ne regarde que le PDF. La spécification exige que la pièce jointe soit déclarée, à deux endroits :
AFRelationshipsur l’objet incorporé. Pour le XML de facture, c’estData: cela indique au destinataire que la pièce jointe est la donnée du document, et non un accessoire.- Des métadonnées XMP dans le PDF, nommant le format, la version et le profil.
Un PDF auquel « on a joint un XML » n’est pas encore une facture électronique. Sans la déclaration, le logiciel du destinataire ne trouvera même pas la pièce jointe — ou la trouvera sans savoir ce qu’elle signifie. Le fichier s’ouvre parfaitement, la page est lisible, et il échoue pourtant au contrôle. C’est la surprise la plus fréquente avec un premier fichier fabriqué soi-même.
Les espaces de noms dans le XML embarqué
Qui ouvre le XML pour la première fois bute sur de longues URI en tête du document. Ce sont des espaces de noms : ils disent de quel vocabulaire vient un élément et empêchent que des éléments homonymes issus de normes différentes se mélangent.
Dans un fichier Factur-X, deux sont surtout en jeu :
urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100— le vocabulaire racine de la facture ;urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100— les briques réutilisables qu’il contient.
Cela compte surtout pour qui écrit son propre analyseur : le mélange de versions d’espaces de noms est une cause fréquente d’illisibilité d’un fichier venu d’un autre système. Qui utilise une bibliothèque existante n’a pas à s’en soucier — elle gère les espaces de noms elle-même, et y toucher à la main est presque toujours une erreur.
Ce qui déraille à la génération
| Constat du contrôle | Cause |
|---|---|
| Police non incorporée | police par défaut du générateur, traitée comme « présente de toute façon » |
| Profil colorimétrique absent | sortie en RVB sans profil incorporé |
| Transparence ou calques | un logo rendu avec transparence dans le PDF |
| Pièce jointe sans relation | AFRelationship non renseigné |
| Métadonnées XMP absentes ou discordantes | PDF retraité ensuite par un autre outil |
La dernière ligne est la plus sournoise : un fichier valide qui passe ensuite par un outil ignorant de PDF/A — pour fusionner, tamponner ou compresser — en ressort en PDF ordinaire. La pièce jointe est peut-être encore là ; la déclaration, elle, a disparu.
Archivage : pourquoi un fichier vaut mieux que deux
Ce qu’il faut conserver, c’est la partie structurée, inaltérée et traçable — huit ans en Allemagne. C’est précisément là que le format hybride paie : il n’existe pas de partie structurée susceptible d’être séparée et perdue. Classer un PDF et un XML comme deux fichiers, c’est garantir soi-même leur appartenance — par les noms de fichiers, par un système d’archivage, par de la discipline. Un PDF/A-3 porte les deux en lui.
S’y ajoute la lisibilité : dans huit ans, n’importe quel lecteur courant affichera encore le PDF. Que votre logiciel comptable actuel existe encore est une autre question — la page, elle, reste lisible.
Questions fréquentes
Tout PDF/A-3 est-il une facture électronique ?
Non. PDF/A-3 est l’enveloppe. Le fichier ne devient facture électronique que par le XML EN 16931 embarqué et sa déclaration correcte.
Puis-je convertir a posteriori un PDF existant en PDF/A-3 ?
Techniquement oui, et c’est précisément ce que font les convertisseurs. La réussite dépend du PDF d’origine : si les polices ne sont pas incorporées ou s’il contient de la transparence, le document doit être repris. Le chemin détaillé est dans Convertir une facture PDF.
De quel niveau de conformité ai-je besoin ?
B suffit pour les factures électroniques. A devient intéressant si vous devez de toute façon respecter l’accessibilité — cela exige un balisage de structure complet, qui n’apparaît pas tout seul.
Comment savoir si mon PDF est réellement un PDF/A-3 ?
Le plus sûr est un contrôle : la couche conteneur vérifie exactement cela. Le lecteur ne l’indique pas de façon fiable — il affichera volontiers un document qui rate la norme.
Puis-je joindre d’autres fichiers ?
PDF/A-3 le permet. Sur une facture, réfléchissez-y à deux fois : chaque pièce jointe supplémentaire est quelque chose que le destinataire doit interpréter, et le XML de facture doit rester identifiable sans ambiguïté.
PDF/A-3 est-il reconnu partout ?
Comme format d’archivage, oui : c’est une norme ISO. Mais qu’un destinataire accepte votre facture dépend du profil et de la complétude des données, pas du conteneur.
En résumé
- PDF/A garantit la lisibilité dans la durée : polices incorporées, profils colorimétriques propres, aucune dépendance externe.
- La partie 3 autorise des pièces jointes quelconques — sans elle, pas de facture hybride.
- Le niveau B suffit ; U et A exigent davantage sans être nécessaires à une facture.
- La pièce jointe doit être déclarée —
AFRelationship : Dataplus XMP. Sans cela, c’est un PDF contenant un fichier, pas une facture électronique. - Le retraitement détruit la conformité. Tamponner, fusionner, compresser après génération : le tueur silencieux.
- Un fichier plutôt que deux : c’est le vrai gain pour une conservation de huit ans.
Vérifier si votre fichier passe la couche conteneur ? Déposez-le sans inscription — ou créez un compte gratuit et produisez d’emblée des factures en PDF/A-3 valide.