Blog

PDF/A-3 expliqué : et comment vérifier qu’un fichier est vraiment conforme

PDF/A-3 est le profil PDF/A courant qui autorise les pièces jointes légales, base des e-factures Factur-X / ZUGFeRD. Différences, points de contrôle et double validation.

PDF/A est la variante archivistique de PDF : la promesse 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 niveaux de conformité. PDF/A-3 est le profil qui porte discrètement la facture é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 workflow “PDF + structured data”, PDF/A-3 est la spécification que vous croiserez. Voici ce qu’elle signifie, ce qui la distingue et comment vérifier un fichier en pratique.

La famille PDF/A en bref

ProfilISO partAnnéeFonction déterminante
PDF/A-119005-12005Premier profil d’archivage. Pas de transparence, pas de JavaScript, polices intégrées.
PDF/A-219005-22011Ajoute JPEG2000, transparence et calques. Meilleure fidélité d’impression.
PDF/A-319005-32012Ajoute les embedded file attachments. L’enveloppe de Factur-X / ZUGFeRD.
PDF/A-419005-42020Ré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, sans garantie de structure sémantique.
  • a (accessible) : balisage structurel et mappage Unicode pour les lecteurs d’écran.
  • u (Unicode) : mappage Unicode sans structure complète.
  • 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 le cas courant en facturation.

Ce qui rend PDF/A-3 spécial

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

PDF/A-3 assouplit cette règle sous 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 une metadata XMP décrivant le fichier.

Autrement dit : PDF/A-3 autorise les pièces jointes, mais oblige à déclarer 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 e-facture : 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 progressivement à partir de 2026) : PDF/A-3 + CII XML, avec namespace XMP urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#.
  • ZUGFeRD 2.x (Allemagne, réception obligatoire depuis 2025) : PDF/A-3 + CII XML, avec namespace 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 payloads XML, par exemple FDA submissions ou rapports ESEF de sociétés cotées dans l’UE.

Dans tous ces cas, l’enveloppe n’est pas seulement un conteneur. C’est un contrat : ce PDF et ce fichier joint sont le même document, et les deux doivent valider.

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 passent.

Pour une e-facture, il faut une couche supplémentaire : Mustang (mustangproject.org), le vérificateur de fait pour Factur-X / ZUGFeRD. Mustang valide le CII XML embarqué contre 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 veraPDF CLI, installent Mustang et écrivent un shell script pour agréger les sorties. Cela marche, mais ajoute de la friction.

validator lance les trois dans le navigateur :

  1. veraPDF : référence officielle pour la conformité PDF/A-3.
  2. gPdf Rust+WASM edge engine : implémentation indépendante, second avis.
  3. Mustang : EN 16931 CII XML Schematron pour les payloads d’e-facture embarqués.

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

Que regarder dans le rapport

Les erreurs se regroupent souvent ainsi :

  • Embedded file metadata missing : le tableau /AF manque, ou le fichier joint n’y est pas listé.
  • AFRelationship missing or wrong : pour une e-facture, il doit être Alternative; beaucoup de bibliothèques PDF mettent Source ou Data par défaut.
  • XMP namespace missing or wrong : Factur-X et ZUGFeRD ont des URI précises ; un caractère erroné suffit.
  • Fonts not subsetted or not embedded : PDF/A exige que tous les glyphs utilisés soient intégrés avec la police.
  • Output intent missing : PDF/A exige une intention couleur (sRGB ou autre ICC profile), même pour du texte noir et blanc.
  • Document metadata incomplete : /Title, /Producer, /CreationDate doivent être présents dans l’information dictionary.

Le rapport renvoie généralement à la section de spécification concernée. Corrigez à la source ; si vous générez avec gPdf, l’API gère ces points et le validator devient votre reçu public.

TL;DR

PDF/A-3 = PDF/A-2 + la capacité d’embarquer légalement des fichiers arbitraires. C’est ce qui rend la e-facture européenne praticable : facture lisible + XML CII EN 16931 structuré dans une seule enveloppe d’archivage. L’enveloppe PDF/A-3 et le XML joint doivent tous deux passer.

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