Si vous êtes ingénieur et qu’on vient de vous dire « les factures doivent être en PDF/A-3 avec Factur-X d’ici le prochain trimestre », alors que votre seul contexte est quelqu’un du juridique qui a prononcé ces mots, cet article est pour vous.

Nous écartons le ton des documents de standardisation pour expliquer ce que ces profils contraignent réellement, pourquoi les administrations ont commencé à les imposer, et le plus petit pipeline pratique pour émettre un PDF conforme depuis un moteur de rendu alimenté par des données structurées.

PDF/A en deux paragraphes

PDF est un format flexible. Trop flexible : la même spécification PDF permet d’embarquer du JavaScript, de pointer vers des ressources externes qui pourraient ne plus exister dans 50 ans, de chiffrer du contenu avec une cryptographie réversible, de référencer des polices externes, et une centaine d’autres possibilités qui rendent un document non autonome.

PDF/A (« A » pour Archival) est un profil de PDF qui interdit les éléments susceptibles d’empêcher le document de s’afficher de manière identique dans 50 ans. Les règles de haut niveau :

Toutes les polices doivent être embarquées.
Pas de JavaScript, pas de liens externes, pas d’audio/vidéo.
Pas de chiffrement.
Toute transparence doit être aplatie ou supportée par la version du profil.
Les couleurs doivent être indépendantes du périphérique (profil ICC requis).
Tout le contenu doit être dans le fichier : aucune référence dépendante du réseau.

Il existe plusieurs versions, chacune ajoutant la tolérance pour des fonctionnalités plus récentes :

Profil	Année	Ce qu’il ajoute
PDF/A-1b	2005	Socle d’origine, le plus strict
PDF/A-2b	2011	Autorise JPEG2000, la transparence et les calques
PDF/A-3b	2012	Autorise des pièces jointes arbitraires (le fondement de Factur-X)
PDF/A-4	2020	Base ISO 32000-2 (PDF 2.0), niveaux de conformité simplifiés

Le suffixe « b » signifie conformité « basic » (fidélité visuelle). Il existe aussi des variantes « u » (mappage Unicode) et « a » (balisage d’accessibilité) ; pour la plupart des flux facture/reçu, « b » est le bon niveau, car l’archivage fiscal vise d’abord la reproductibilité visuelle, pas la sémantique pour lecteurs d’écran.

À retenir en pratique : si votre moteur de rendu annonce PDF/A-3b, cela devrait être un seul paramètre de configuration ({ profile: "PDF/A-3b" } ou équivalent). Si vous devez lancer un second outil (Ghostscript, qpdf, Acrobat) pour convertir après coup, c’est une lacune de processus à intégrer dans votre exploitation.

Pourquoi PDF/A-3 spécifiquement compte : c’est le porteur des factures électroniques

PDF/A-3 a ajouté une capacité qui s’est avérée décisive : des pièces jointes arbitraires à l’intérieur du PDF.

Cela semble anodin. Ça ne l’est pas. C’est tout le socle technique des obligations de facturation électronique qui se déploient actuellement en Europe.

L’architecture : un seul fichier PDF qui est à la fois :

Une facture lisible par l’humain (mise en page visuelle, totaux, branding) — la partie que l’humain lit.
Une facture XML lisible par la machine — la partie analysée par le logiciel de l’autorité fiscale.

Les deux dans un seul fichier, les deux représentant la même facture, et l’enveloppe PDF/A-3 garantit que le fichier restera analysable dans des décennies.

Les deux principaux formats XML :

Factur-X (France) — profil XML basé sur UN/CEFACT Cross Industry Invoice
ZUGFeRD (Allemagne) — substantiellement identique à Factur-X (les deux standards ont techniquement fusionné en 2018)
EN 16931 — la norme européenne à laquelle les deux implémentations se conforment

Pour la plupart des flux, « Factur-X » et « ZUGFeRD » sont des termes interchangeables : ils partagent un schéma, le même mécanisme d’embarquement, et un PDF conforme à l’un est généralement conforme à l’autre.

Ce qui est obligatoire, où, quand

Un instantané non exhaustif pour les ingénieurs qui planifient des déploiements T2/T3 2026 :

Pays	Statut	Format requis
Allemagne	B2B obligatoire pour la réception depuis 2025-01-01 ; à partir de 2027 aussi pour l’émission	EN 16931 (ZUGFeRD / Factur-X / XRechnung)
France	Émission obligatoire pour les grandes entreprises 2026-09 ; PME 2027-09	Factur-X via Chorus Pro
Italie	B2B obligatoire depuis 2019	FatturaPA via SDI
Pologne	Obligatoire depuis 2024-07	KSeF
Espagne	Obligatoire à partir de 2026 (B2B)	Facturae via FACe
Belgique	Obligatoire à partir de 2026-01	Peppol BIS 3

Le schéma général : chaque État membre de l’UE met en œuvre une variante de facturation électronique conforme EN 16931 sur un calendrier 2024-2027. Si vos clients opèrent dans l’un de ces marchés, votre générateur PDF devra émettre du XML attaché à côté de la facture visuelle.

Le plus petit pipeline pratique

Oubliez ce que les documents de standardisation prescrivent. Voici la vue ingénieur :

   ┌─────────────────────┐
   │  Données de votre   │  (déjà un objet JSON quelque part)
   │      facture        │
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │ Construire le XML   │  (mappage déterministe ; libs éprouvées existent)
   │     EN 16931        │
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │ Rendre PDF/A-3b +   │
   │ attacher le XML     │  (un seul appel API à gPdf — ou deux étapes ailleurs)
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │  Remettre à         │
   │  Chorus Pro / SDI / │
   │  Peppol / etc       │
   └─────────────────────┘

Les deux étapes non triviales :

Étape 1 : construire le XML

C’est fastidieux, mais mécanique. Vous mappez vos données de facture (lignes, taxes, totaux, parties) vers les noms de champs XML EN 16931. Plusieurs bibliothèques Java/Node/Python le font pour vous ; cherchez une bibliothèque Factur-X dans votre langage. Ne l’écrivez pas à partir de zéro sauf si vous aimez vraiment les spécifications de schéma XML.

Étape 2 : rendre PDF/A-3 et attacher le XML

C’est ici que le choix du moteur de rendu compte.

Sans support intégré : vous rendez un PDF ordinaire, puis vous le post-traitez avec un outil qui convertit en PDF/A-3 et attache le XML comme fichier embarqué. Piles courantes : Ghostscript + qpdf, ou un outil payant comme Aspose. Deux étapes supplémentaires, deux points de défaillance supplémentaires, et vous devez vous assurer que le post-traitement ne fait pas dériver la mise en page visuelle.

Avec support intégré (l’approche de gPdf) : un appel.

curl -X POST https://api.gpdf.com/api/v1/e-invoice/render \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "settings": {
      "profile": "pdfa-3b",
      "e_invoice": {
        "standard": "factur_x",
        "profile": "en16931",
        "document_type": "invoice",
        "xml": {
          "format": "cii",
          "encoding": "utf8",
          "content": "<?xml version=\"1.0\"?><rsm:CrossIndustryInvoice>...</rsm:CrossIndustryInvoice>"
        }
      }
    },
    "pages": [{ "size": "a4", "elements": [/* invoice layout */] }]
  }' \
  --output invoice-with-einvoice.pdf

C’est tout le pipeline. Le moteur émet PDF/A-3b, attache votre XML sous le nom factur-x.xml (ou zugferd-invoice.xml, les deux étant reconnus par chaque consommateur), et renvoie les octets.

Pièges courants

Quelques choses que les gens apprennent à la dure :

« PDF/A » et « avec polices conformes PDF/A » ne sont pas la même chose

Un fichier PDF/A-3 exige que toutes les polices soient embarquées avec couverture complète des glyphes utilisés. Si votre facture contient un nom de client japonais et que le moteur de rendu retombe sur une police qui n’est pas pleinement embarquable, les outils de validation la rejetteront. Vérifiez que votre moteur embarque les polices CJK en mode PDF/A : beaucoup ne le font pas par défaut.

Visuel + XML doivent s’accorder

La facture XML et la facture visuelle sont censées représenter la même facture. Les auditeurs fiscaux les compareront. Si votre code émet du XML avec total: 119.00 et que le PDF visuel affiche Total: 120.00 (à cause d’un bug d’arrondi ou d’un modèle obsolète), vous avez une divergence fiscale dans le dossier. Générez les deux depuis la même source de référence, idéalement dans le même chemin de code.

Niveaux de « profil » dans EN 16931

Factur-X a des profils : MINIMUM, BASIC, EN 16931, EXTENDED. Ils diffèrent par la quantité de données dans le XML. Utilisez BASIC sauf si votre client demande explicitement plus : il couvre les codes fiscaux, les lignes, les parties et les totaux, ce qui suffit pour environ 95 % de la facturation B2B. Le profil EN 16931 ajoute des détails supplémentaires pour les cas limites.

Validation avant soumission

Validez toujours le PDF généré avec un validateur PDF/A (veraPDF est le standard open source) et validez le XML avec le schéma EN 16931 avant de l’envoyer à l’autorité fiscale. Les soumissions échouées à Chorus Pro / SDI comptent contre vos métriques de fiabilité auprès du régulateur.

TL;DR

PDF/A est un profil de document autonome. PDF/A-3 vous laisse attacher des fichiers. Factur-X / ZUGFeRD est « un XML EN 16931 attaché dans un PDF/A-3 ». Les mandats de facturation électronique à travers l’UE font de cette combinaison le format de facture B2B de facto de 2025–2027.

Si votre moteur de rendu traite PDF/A-3 + Factur-X comme un seul paramètre de configuration, la migration est mécanique. S’il ne le fait pas, vous construisez un pipeline d’exploitation en plusieurs étapes. Le /api/v1/e-invoice/render de gPdf est la version à un seul paramètre : la référence API contient le schéma complet, ou vous pouvez essayer un rendu d’exemple dans le Playground.