Votre logiciel de facturation génère du Factur-X. Très bien. Mais sait-il exactement quelle norme ISO il applique, et pourquoi ? Derrière chaque fichier Factur-X se cache une architecture technique précise : un conteneur PDF soumis à la norme ISO 19005-3, conçue non pas pour la facturation, mais pour la préservation de documents sur un siècle. Comprendre ce socle change la façon dont on évalue un logiciel, on configure un archivage, et on valide une conformité. Cet article décortique PDF/A-3 - son histoire, sa structure, ses contraintes - et explique pourquoi Factur-X en a fait sa fondation technique.
PDF/A-3 : une norme d'archivage, pas de facturation#
L'ISO/TC 171, comité technique dédié à la gestion de documents, publie ISO 19005-3 en 2012 avec un objectif sans ambiguïté : garantir qu'un fichier électronique reste lisible et exploitable dans 100 ans, sans dépendance à un logiciel propriétaire ou à une infrastructure externe. La facturation électronique n'est mentionnée nulle part dans le texte de la norme.
Pour situer cette troisième itération dans son contexte : PDF/A-1 (2005) avait posé les fondations de l'archivage PDF longue durée ; PDF/A-2 (2011) avait élargi les capacités en intégrant les fonctionnalités de PDF 1.7, notamment la transparence et les couches. PDF/A-3 représente une évolution architecturale plus limitée en apparence, mais décisive en pratique.
Le paradoxe fondateur de Factur-X est là : les créateurs du standard franco-allemand ont choisi une norme d'archivage centenaire précisément parce qu'elle garantit la lisibilité humaine perpétuelle. Une facture émise aujourd'hui doit pouvoir être lue par un commissaire aux comptes dans 50 ans sans installer de plugin. PDF/A-3 offre cette garantie par construction.
La différence structurelle clé : les pièces jointes libres#
C'est une unique clause qui distingue PDF/A-3 de ses prédécesseurs, et elle change tout. PDF/A-1 et PDF/A-2 n'autorisent que des pièces jointes elles-mêmes conformes PDF/A - un PDF d'archive ne peut contenir qu'un autre PDF d'archive. PDF/A-3 lève cette restriction et accepte des fichiers joints de n'importe quel format : XML, CSV, JSON, ou tout autre format de données structurées.
Cette unique différence architecturale transforme le conteneur PDF en enveloppe hybride. Un même fichier binaire peut désormais contenir un document visuellement fidèle à sa version imprimée et un fichier de données structurées exploitable directement par un ERP ou un système comptable, sans que ces deux couches ne se gênent mutuellement.
C'est exactement ce mécanisme d'attachement libre que Factur-X exploite. Le PDF visible - avec logo, mise en page, coordonnées bancaires - et le XML exploitable par la machine coexistent dans le même fichier. Supprimer l'un ou l'autre détruit la conformité Factur-X ; les deux sont contractuellement indissociables.
Les trois niveaux de conformance : a, b et u#
ISO 19005-3 définit trois niveaux de conformance, qui déterminent jusqu'où va l'exigence structurelle du document. Le niveau 'a' (accessible) est le plus exigeant : il requiert une structure logique complète avec balises sémantiques, garantissant l'accessibilité aux lecteurs d'écran et la recomposabilité du contenu. Le niveau 'b' (basic) se limite à la conformance visuelle - le rendu pixel doit être identique à la réception, mais aucune structure logique n'est requise. Le niveau 'u' garantit quant à lui que tout le texte est mappé en Unicode, sans aller jusqu'à la structuration sémantique du niveau 'a'.
Factur-X retient PDF/A-3b, le niveau minimal. Ce choix, arrêté conjointement par le FNFE-MPE côté français et FeRD côté allemand, est un arbitrage délibéré : le niveau 'b' assure la compatibilité maximale avec les outils de génération PDF existants et réduit le coût d'implémentation pour les éditeurs de logiciels. Imposer le niveau 'a' aurait exigé un balisage sémantique précis pour chaque champ de facture - techniquement réalisable, mais prohibitif pour la majorité des éditeurs en 2014.
Un fichier Factur-X conforme est PDF/A-3b, pas PDF/A-3a. Vérifiez que votre outil de génération déclare explicitement le profil 'b' dans les métadonnées XMP du fichier - cherchez la balise pdfaid:conformance avec la valeur "B". Une déclaration absente ou incorrecte rend la conformance ISO 19005-3 invalide, même si le reste du fichier est techniquement correct.
Deux normes dans un fichier : ISO 19005-3 rencontre CII D16B#
Le XML embarqué dans un Factur-X n'est pas un format maison ou une invention franco-allemande. Il suit la norme UN/CEFACT Cross Industry Invoice D16B, standard international élaboré sous l'égide de l'ONU pour les échanges commerciaux électroniques entre entreprises. CII D16B définit précisément les champs, leur hiérarchie, leurs types de données et leurs codes autorisés - numéro de TVA, unités de mesure, codes devise, identifiants de lignes.
Un fichier Factur-X est donc formellement l'hybridation de deux écosystèmes normatifs indépendants dans une seule enveloppe binaire : la norme ISO 19005-3:2012 pour le conteneur PDF et ses règles d'archivage, la norme ONU CII D16B pour la sémantique des données commerciales embarquées. Ces deux organismes - ISO et UN/CEFACT - n'ont aucun lien institutionnel entre eux.
Cette dualité a une conséquence pratique directe pour quiconque valide des fichiers Factur-X : deux vérifications distinctes sont nécessaires. La conformance PDF/A-3b du conteneur s'évalue avec des outils comme VeraPDF. La validité du schéma XML CII D16B embarqué exige un validateur XML distinct, pointant vers le schéma XSD officiel UN/CEFACT. Un fichier peut être un PDF/A-3b parfait et contenir un XML CII invalide - les deux niveaux de validation sont indépendants. La spécification Factur-X publiée par le FNFE-MPE détaille cette double exigence.
Pour aller plus loin sur la comparaison entre CII et UBL, les deux formats XML en jeu dans la facturation électronique européenne, consultez notre guide Factur-X, UBL et CII : comprendre les formats XML.
Les contraintes d'archivage qui changent le comportement du fichier#
ISO 19005-3 impose trois interdictions absolues pour garantir l'autonomie centenaire du document. Le chiffrement est prohibé : un document chiffré dépend d'une clé, et personne ne peut garantir que cette clé sera disponible dans 100 ans. Les références à des ressources externes sont interdites : pas de police chargée depuis un serveur, pas d'image pointant vers une URL. Les polices non embarquées sont bannies : chaque police utilisée dans le document doit être physiquement incluse dans le fichier binaire.
La conséquence directe pour tout fichier Factur-X est mécanique : les polices de caractères - même une simple Arial ou Helvetica - doivent être intégralement embarquées dans le fichier. Un PDF classique peut se contenter d'indiquer "utilise la police Helvetica installée sur ce système" ; un PDF/A-3 doit transporter la police entière avec lui. C'est la première source de surpoids.
La seconde source est le XML CII joint, plus les métadonnées XMP étendues que la norme requiert dans l'en-tête du fichier. L'ensemble produit des fichiers sensiblement plus lourds que leurs équivalents PDF ordinaires.
Un Factur-X pèse souvent 3 à 5 fois plus qu'un PDF ordinaire comparable. La cause est structurelle : polices embarquées obligatoires, XML CII D16B joint, métadonnées XMP étendues requises par ISO 19005-3. Toute "optimisation" qui supprimerait ces éléments pour réduire la taille ferait perdre la conformance ISO et invaliderait le caractère hybride de la facture. Ne pas confondre légèreté et conformité.
Ce que cela signifie concrètement pour l'archivage en PME#
Archiver un Factur-X, c'est archiver deux documents en un seul geste : la facture lisible par l'humain et les données structurées exploitables par la machine, les deux liés dans le même fichier immuable. Pour un DAF, cela simplifie la gestion documentaire - pas besoin de conserver séparément un PDF pour le litige et un XML pour la comptabilité.
La garantie centenaire de PDF/A-3 est particulièrement pertinente au regard des obligations françaises de conservation fiscale. Le Code général des impôts impose une durée de conservation de 6 ans pour les factures. PDF/A-3 dépasse largement cette exigence par construction, et garantit qu'un fichier Factur-X généré aujourd'hui pourra être ouvert, lu et présenté à l'administration sans dépendance à un logiciel spécifique - un argument solide en cas de contrôle fiscal à long terme.
La question pratique pour un responsable informatique ou un dirigeant qui choisit son outil est simple et binaire : le logiciel de facturation conforme en 2026 utilisé génère-t-il un PDF/A-3b valide avec la bonne déclaration de profil XMP et un XML CII D16B conforme au schéma officiel, ou se contente-t-il d'un PDF avec une pièce jointe XML non validée qui ressemble à du Factur-X sans en être ? La différence ne se voit pas à l'oeil nu - elle se détecte à la validation. Pour tester concrètement cette distinction, téléchargez un exemple de fichier Factur-X et soumettez-le à VeraPDF : le résultat est sans ambiguïté.
La documentation technique de FeRD, l'organisation allemande co-autrice du standard ZUGFeRD/Factur-X, détaille l'ensemble des métadonnées XMP requises et constitue la référence pour tout éditeur qui implémente la génération côté serveur. Pour les notions qui restent floues, le glossaire de ce site couvre les termes techniques de la facturation électronique.
Sources officielles
- [1]ISO - ISO 19005-3:2012 - Document management - Electronic document file format for long-term preservation - Part 3: Use of ISO 32000-1 with support for embedded files (PDF/A-3)(consulte le )
- [2]FNFE-MPE - Spécification Factur-X - profil PDF/A-3b et schéma XML CII D16B(consulte le )
- [3]FeRD - ZUGFeRD / Factur-X Technical Documentation - structure hybride et métadonnées XMP(consulte le )
- [4]UN/CEFACT - Cross Industry Invoice XML Schema D16B(consulte le )
Notre methodologie editoriale consiste a citer systematiquement nos sources et a dater chaque verification. Consultez notre methodologie de citation complete pour comprendre comment nous evaluons la fiabilite des informations.