PDF/A est la variante d’archivage de PDF : la garantie qu’un document s’affichera en 2050 comme il s’affiche en 2026. Il existe quatre grands profils (PDF/A-1, 2, 3, 4), chacun avec ses sous-niveaux de conformité. PDF/A-3 est le profil qui porte discrètement la facturation électronique européenne, et le seul profil PDF/A largement utilisé qui autorise des pièces jointes arbitraires dans l’enveloppe d’archivage.

Si vous travaillez sur des factures, des dépôts réglementaires ou tout flux « PDF + données structurées », PDF/A-3 est la spécification que vous croiserez. Voici ce qu’elle signifie, ce qui la distingue de ses profils voisins, et comment vérifier qu’un fichier est réellement conforme.

La famille PDF/A en bref

Profil	Partie ISO	Année	Fonction déterminante
PDF/A-1	19005-1	2005	Premier profil d’archivage. Pas de transparence, pas de JavaScript, polices embarquées.
PDF/A-2	19005-2	2011	Ajoute JPEG2000, transparence et calques. Meilleure fidélité d’impression.
PDF/A-3	19005-3	2012	Ajoute les pièces jointes embarquées. L’enveloppe de Factur-X / ZUGFeRD.
PDF/A-4	19005-4	2020	Révision moderne ; modèle de conformité plus propre, sans séparation `b` vs `a`.

Les sous-niveaux :

b (basic) : fidélité visuelle préservée. Tout le monde peut lire le fichier, sans garantie de contenu sémantique.
a (accessible) : balisage structurel et mappage Unicode. Les lecteurs d’écran peuvent extraire le texte dans le bon ordre.
u (Unicode) : mappage Unicode sans structure complète. Un niveau intermédiaire.
e / f (PDF/A-4 seulement) : contenu 3D d’ingénierie et formulaires complets.

« PDF/A-3b » signifie donc : profil d’archivage 3, avec pièces jointes permises, niveau basic sans exigence de balisage d’accessibilité. C’est la variante la plus courante en facturation.

Ce qui rend PDF/A-3 spécial

PDF/A-1 et PDF/A-2 interdisent les fichiers embarqués arbitraires. La logique est simple : un PDF d’archive doit être autonome ; si un data.xlsx joint vieillit séparément du PDF, la garantie d’archivage se fragilise.

PDF/A-3 assouplit explicitement cette règle sous une condition stricte : chaque fichier embarqué doit déclarer AFRelationship, l’attribut qui décrit son lien avec le contenu PDF visible. Les valeurs valides sont Source, Data, Alternative, Supplement, Unspecified. Le PDF doit aussi lister la pièce jointe dans le tableau /AF et émettre des métadonnées XMP décrivant le fichier.

Autrement dit : PDF/A-3 autorise les pièces jointes, mais seulement si vous déclarez précisément ce qu’elles sont et comment elles se rattachent à ce que l’humain voit. C’est ce qui en a fait le véhicule de la facturation électronique : la facture lisible reste dans le PDF, le XML CII EN 16931 dans la pièce jointe, et AFRelationship="Alternative" indique que les deux sont deux représentations de la même facture.

Où PDF/A-3 vit en production

Factur-X (France, B2B obligatoire à partir de 2026) : PDF/A-3 + CII XML, avec l’espace de noms XMP urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#.
ZUGFeRD 2.x (Allemagne, réception obligatoire depuis 2025) : PDF/A-3 + CII XML, avec l’espace de noms XMP urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0#.
Archivage CAD d’ingénierie : PDF/A-3 avec le fichier CAD natif joint. Le PDF est le rendu ; le CAD est la source.
Dépôts réglementaires : PDF/A-3 avec charges utiles XML jointes, par exemple les dépôts FDA ou les rapports ESEF des émetteurs cotés dans l’UE.

Dans tous ces cas, l’enveloppe n’est pas seulement un conteneur : c’est un contrat qui indique que ce PDF et ce fichier joint sont le même document, et que les deux doivent être validés.

Comment vérifier la conformité PDF/A-3

Le vérificateur officiel est veraPDF (verapdf.org), maintenu par la PDF Association. Il implémente les règles ISO 19005-3 ; si veraPDF indique « Pass — PDF/A-3b », c’est le signal le plus fort qu’un moteur unique peut donner.

Mais un « Pass » à moteur unique n’est pas un standard d’audit (Why two PDF/A validators are better than one explique pourquoi). Le schéma robuste consiste à exécuter deux moteurs indépendants et à considérer le fichier conforme seulement si les deux réussissent.

Pour une facture électronique, il faut aussi un second moteur spécialisé : Mustang (mustangproject.org), le vérificateur de fait pour Factur-X / ZUGFeRD. Mustang valide le CII XML embarqué avec EN 16931 Schematron. La conformité PDF/A-3 seule ne suffit pas ; le XML joint doit aussi être valide EN 16931, sinon le système AP du destinataire rejettera la facture.

Beaucoup d’équipes installent Java, configurent la CLI veraPDF, installent Mustang et écrivent un script shell pour agréger les sorties. Cela fonctionne, mais ajoute de la friction.

validator lance les trois dans le navigateur :

veraPDF : référence officielle pour la conformité PDF/A-3.
gPdf Rust+WASM edge engine : implémentation indépendante, second avis.
Mustang : EN 16931 CII XML Schematron pour les charges utiles de facture électronique embarquées.

Déposez le fichier : les trois moteurs tournent en parallèle, les rapports reviennent côte à côte, et le JSON est téléchargeable comme preuve QA. Pas de login, pas de quota.

Que regarder dans le rapport

Quand vous lancez le validateur et qu’un moteur signale une erreur, les échecs se regroupent souvent ainsi :

Métadonnées de fichier embarqué manquantes : le tableau /AF manque, ou le fichier joint n’y est pas listé.
AFRelationship manquant ou incorrect : pour une facture électronique, il doit être Alternative ; beaucoup de bibliothèques PDF mettent Source ou Data par défaut.
Espace de noms XMP manquant ou incorrect : Factur-X et ZUGFeRD ont des URI précises ; un caractère erroné suffit.
Polices non sous-ensemble ou non embarquées : PDF/A exige que tous les glyphes utilisés dans le document soient embarqués avec la police.
Output intent manquant : PDF/A exige une intention couleur (sRGB ou autre profil ICC), même pour du texte noir et blanc.
Métadonnées de document incomplètes : /Title, /Producer, /CreationDate doivent être présents dans le dictionnaire d’informations du document.

Chacun de ces points renvoie à une section précise de la spécification dans le rapport du validateur. Corrigez à la source ; si vous générez avec gPdf, l’API gère automatiquement ces points et le validateur devient votre reçu public.

TL;DR

PDF/A-3 = PDF/A-2 + la capacité d’embarquer des fichiers arbitraires dans le cadre du profil. C’est ce qui rend la facturation électronique européenne praticable : une facture lisible par l’humain + le XML CII EN 16931 structuré, dans une seule enveloppe d’archivage. La conformité exige que l’enveloppe PDF/A-3 et le XML joint passent tous les deux.

Générez avec POST /api/v1/e-invoice/render. Vérifiez sur validator. Trois moteurs (veraPDF + gPdf edge + Mustang), un upload, gratuit.