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

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

PDF/A en deux paragraphes

PDF est un format flexible. Trop flexible — la même spécification PDF vous permet d’embarquer du JavaScript, de lier à des ressources externes qui pourraient ne pas exister dans 50 ans, de chiffrer du contenu avec de la cryptographie réversible, de référencer des polices externes, et une centaine d’autres choses qui rendent un document non-autonome.

PDF/A (« A » pour Archival) est un profil de PDF qui interdit les parties qui empêcheraient le document de se rendre identiquement dans 50 ans. Les règles 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 — pas de références qui dépendent 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	Baseline d’origine — la plus stricte
PDF/A-2b	2011	Permet JPEG2000, transparence, layers
PDF/A-3b	2012	Permet des attachements de fichiers arbitraires (la fondation 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 » (mappées Unicode) et « a » (taggées accessibilité) — pour la plupart des workflows facture/reçu, « b » est ce que vous voulez, parce que l’archivage fiscal se soucie de la reproductibilité visuelle, pas de la sémantique pour lecteurs d’écran.

À retenir en pratique : si votre moteur de rendu dit qu’il supporte PDF/A-3b, ce devrait être un seul flag de configuration ({ profile: "PDF/A-3b" } ou équivalent). Si vous devez faire tourner un second outil (Ghostscript, qpdf, Acrobat) pour convertir après coup, c’est une lacune de workflow à intégrer dans votre ops.

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 transformer le monde : les attachements de fichiers arbitraires à l’intérieur du PDF.

Cela semble ennuyeux. Ça ne l’est pas. C’est la fondation technique entière des mandats de facturation électronique qui se déploient à travers l’Europe en ce moment.

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 que le logiciel de l’autorité fiscale parse.

Les deux dans un fichier, les deux représentant la même facture, et l’enveloppe PDF/A-3 garantit que le fichier sera encore parsable 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 fusionné techniquement en 2018)
EN 16931 — la norme européenne à laquelle les deux implémentations se conforment

Pour la plupart des workflows, « Factur-X » et « ZUGFeRD » sont des termes interchangeables — ils partagent un schéma, partagent le mécanisme d’embarquement, et un seul 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 planifiant des rollouts Q2/Q3 2026 :

Pays	Statut	Format requis
France	Émission obligatoire pour grandes entreprises 2026-09 ; PME 2027-09	Factur-X via Chorus Pro
Allemagne	B2B obligatoire pour la réception depuis 2025-01-01 ; à partir de 2027 aussi pour l’émission	EN 16931 (ZUGFeRD / Factur-X / XRechnung)
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 pattern : chaque État membre de l’UE met en œuvre une variante de facturation électronique conforme EN 16931 sur une timeline 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.

Pour les équipes françaises spécifiquement : la réforme de la facturation électronique (loi de finances 2024) est la base légale. En pratique, cela signifie que toute entreprise française B2B doit, à partir de septembre 2026 (puis septembre 2027 pour les PME), émettre des factures électroniques structurées — pas seulement des PDFs comme images, mais des fichiers PDF/A-3 avec XML Factur-X intégré, soumis via la Plateforme de Dématérialisation Partenaire (PDP) de votre choix ou directement via Chorus Pro.

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 / PDP / │
   │  Peppol / etc       │
   └─────────────────────┘

Les deux étapes non triviales :

Étape 1 : construire le XML

C’est ennuyeux mais mécanique. Vous mappez vos données de facture (lignes, taxes, totaux, parties) sur les noms de champs XML EN 16931. Plusieurs librairies Java/Node/Python font cela pour vous — cherchez « factur-x library » dans votre langage. Ne l’écrivez pas à partir de zéro à moins que vous n’aimiez 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 post-processez avec un outil qui convertit en PDF/A-3 et attache le XML comme fichier embarqué. Stacks courants : 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-processing ne fait pas dériver la mise en page visuelle.

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

curl -X POST https://gpdf.com/api/v1/e-invoice/render \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "document": {
      "pages": [{ "size": "a4", "elements": [...] }]
    },
    "einvoice": {
      "format": "factur-x",
      "profile": "BASIC",
      "xml": "<rsm:CrossIndustryInvoice>...</rsm:CrossIndustryInvoice>"
    }
  }' \
  --output facture-avec-factur-x.pdf

C’est tout le pipeline. Le moteur émet PDF/A-3b, attache votre XML comme 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 a 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 contrôleurs fiscaux les diff-eront. Si votre code émet du XML avec total: 119,00 et que le PDF visuel montre Total : 120,00 (à cause d’un bug d’arrondi ou d’un template obsolète), vous avez une divergence fiscale dans le dossier. Générez les deux depuis la même source-de-vérité, 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 requiert spécifiquement plus — il couvre codes fiscaux, lignes, parties, totaux, ce qui suffit pour ~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é contre un validateur PDF/A (veraPDF est le standard open source) et validez le XML contre 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é chez le 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 flag de configuration, la migration est mécanique. S’il ne le fait pas, vous construisez un pipeline ops multi-étapes. Le /api/v1/e-invoice/render de gPdf est la version à un seul flag — la référence API a le schéma complet, ou essayez un rendu d’exemple dans le Playground.