Qu'est-ce que PDF/A-3 et pourquoi c'est essentiel pour l'e-facturation

Si vous avez côtoyé l’e-facturation européenne ces deux dernières années, vous avez probablement vu le terme PDF/A-3 employé comme si tout le monde savait déjà ce qu’il signifie. La plupart des articles supposent que le lecteur connaît la différence entre PDF, PDF/A et PDF/A-3, puis passent à autre chose. Les différences ne sont pas académiques. Elles déterminent si une facture émise aujourd’hui sera encore ouvrable, vérifiable et juridiquement valide en 2036.

Voici la version que nous aurions aimé lire quand nous avons commencé.

PDF, PDF/A, PDF/A-3 : trois choses différentes

Un PDF standard est un format de présentation. Il peut contenir tout ce qu’un designer veut : références de polices externes, JavaScript, vidéo embarquée, liens vers des ressources distantes. Cette flexibilité est merveilleuse pour les brochures marketing et désastreuse pour les archives. Un PDF écrit en 2005 peut déjà s’afficher différemment dans une visionneuse de 2025 parce qu’une police a été substituée, qu’une ressource externe est devenue un 404, ou qu’une extension propriétaire a été dépréciée.

PDF/A (ISO 19005) est un sous-ensemble strict du PDF, conçu pour s’afficher à l’identique pour toujours. Il bannit les fonctions dynamiques. Toute police doit être embarquée. Tout profil colorimétrique doit être autoportant. Pas de JavaScript, pas de contenu externe, pas de chiffrement. Le résultat est un fichier garanti ouvrable et visuellement identique des décennies plus tard.

PDF/A-3 est la troisième révision de cette norme, publiée en 2012. Elle a changé exactement une chose : elle permet d’embarquer des pièces jointes arbitraires à l’intérieur du PDF. Les versions antérieures (PDF/A-1, PDF/A-2) n’autorisaient que des pièces jointes elles-mêmes conformes PDF/A. PDF/A-3 lève cette restriction. Vous pouvez désormais embarquer un fichier XML, un CSV, un document JSON ou n’importe quoi d’autre comme pièce jointe structurée.

Ce changement unique est ce qui a rendu possible l’e-facturation moderne.

Pourquoi l’e-facturation avait précisément besoin de cela

Une facture électronique européenne conforme doit être deux choses à la fois :

1. Lisible par machine. Le système comptable de l’acheteur doit ingérer les lignes, les taux de TVA et les conditions de paiement sans intervention humaine.
2. Lisible par un humain, pendant des années. La législation fiscale dans la plupart des pays de l’UE exige que la facture soit archivée sous une forme qu’un auditeur humain puisse ouvrir et lire, pendant 7 à 10 ans selon le pays.

Un fichier UBL XML pur satisfait la première exigence mais échoue à la seconde. Un PDF pur satisfait la seconde mais pas la première. Un PDF/A-3 avec UBL embarqué satisfait les deux, dans un seul conteneur infalsifiable, et la couche visuelle est bit-identique à la couche structurée.

C’est l’architecture derrière à la fois Factur-X (le standard hybride franco-allemand) et ZUGFeRD (son ancêtre allemand). Les deux sont du PDF/A-3 avec une pièce jointe XML spécifique, à un emplacement spécifique, avec un nom de fichier spécifique. Une fois enlevés les noms marketing, ce qu’ils sont vraiment, c’est “du PDF/A-3, plus un contrat sur le XML que vous mettez dedans”.

Ce que PDF/A-3 ne vous donne pas

PDF/A-3 est un format d’archivage. Ce n’est pas un certificat de conformité, et ce n’est pas une signature. Trois choses qu’il ne fait précisément pas :

• Il ne valide pas le XML embarqué. Vous pouvez mettre un UBL malformé dans un PDF/A-3 et le fichier passera quand même la validation PDF/A-3. Le format ne garantit que le conteneur, pas la cargaison.
• Il ne prouve pas quand le fichier a été créé. Un fichier PDF/A-3 peut être enregistré à nouveau, retimbré et réexpédié sans laisser de trace. Si vous devez prouver “cette facture existait à cette date”, il vous faut un horodatage RFC 3161 par-dessus.
• Il ne garantit pas la livraison. La conformité au format et la conformité à un mandat national (Peppol, KSeF, Chorus Pro) sont des problèmes différents. PDF/A-3 est nécessaire mais pas suffisant.

C’est pour cela que le pipeline SealDoc émet un PDF/A-3 plus un horodatage RFC 3161 plus un evidence pack contenant les hashs de manifeste. Chaque couche répond à une question différente, et un audit réel les voudra toutes les trois.

Erreurs courantes des pipelines avec PDF/A-3

Nous voyons les cinq mêmes erreurs revenir dans les pipelines clients :

1. PDF à moitié convertis. Une bibliothèque prétend “produire du PDF/A-3” mais saute l’embarquement des polices système, qui se résolvent ensuite différemment sur la machine de l’auditeur.
2. Mauvaise relation de pièce jointe. PDF/A-3 distingue Source, Data, Alternative, Supplement et Unspecified. Factur-X exige Alternative. Beaucoup d’embarqueurs choisissent par défaut Unspecified et le fichier échoue à la validation stricte.
3. Métadonnées XMP manquantes. PDF/A exige des métadonnées autodescriptives en XMP. Un fichier sans les clés obligatoires pdfaid:part et pdfaid:conformance n’est techniquement pas du PDF/A-3, peu importe la structure.
4. Dérive de profil colorimétrique. Un PDF/A-3 doit déclarer chaque espace colorimétrique utilisé. Les pipelines qui laissent passer des images RGB arbitraires sans profil embarqué produisent silencieusement des fichiers non conformes.
5. Re-rendu d’un PDF existant. Certains pipelines rastérisent le PDF d’entrée avant de réembarquer le XML. Visuellement ça marche, mais ça détruit la couche texte recherchable et casse l’accessibilité.

Vous pouvez vérifier chacun de ces points avec notre validateur public à /check. Déposez un fichier, obtenez un verdict en quelques secondes, sans inscription. Si un fichier échoue, le rapport vous indique précisément quelle clause de quelle spécification a été violée.

Quand PDF/A-3 est le bon choix (et quand ce ne l’est pas)

PDF/A-3 est le bon choix quand vous devez conserver pendant des années une copie lisible par un humain d’un document structuré et que vous voulez les deux couches dans un seul conteneur. Cela couvre l’e-facturation, les e-reçus, les contrats structurés, et de plus en plus les e-billets et les documents douaniers.

C’est le mauvais choix pour les documents éphémères (un bon de livraison qui expire dans une semaine), pour les documents où la charge structurée est la seule chose qui compte (EDI pur), ou ceux dont la couche lisible humaine est purement décorative et ne sera jamais auditée.

Pour tout le reste du B2B européen en 2026, PDF/A-3 est le format. Les détails techniques ci-dessus sont la raison pour laquelle ça marche, et la raison pour laquelle une mauvaise implémentation produira silencieusement des fichiers qui passent la QA interne et échouent sur le bureau de l’auditeur trois ans plus tard.