Un PDF est conforme PDF/A-3 ou ne l’est pas. Pourquoi donc faire passer le même fichier dans deux validateurs ?

Parce qu’en pratique la spécification est assez vaste pour que deux implémentations correctes divergent sur des cas limites. Dans un processus soumis à audit, un “Pass” venant d’un seul moteur reste un feu orange, pas un feu vert.

PDF/A n’est pas un algorithme unique

PDF/A couvre plusieurs parties de l’ISO 19005 : PDF/A-1, PDF/A-2, PDF/A-3 et PDF/A-4, avec des niveaux b, a, u, e et f. Le tout repose aussi sur la spécification PDF de base, ISO 32000. On parle de milliers de pages de texte normatif.

Les désaccords apparaissent souvent ici :

Transparence en PDF/A-2/3 : autorisée sous conditions, mais les frontières sont interprétées différemment.
Profils ICC : obligatoire, recommandé ou insuffisant selon la lecture du moteur.
Métadonnées des fichiers incorporés en PDF/A-3 : AFRelationship, références /AF et XMP doivent être cohérents.
Sous-ensembles de polices : les polices CID et subsets partiels créent de vrais cas limites.

Ce ne sont pas forcément des bugs. C’est la conséquence normale d’une norme complexe implémentée par des équipes indépendantes. Les secteurs régulés demandent donc souvent une confirmation indépendante.

Le moteur de référence et le second avis

veraPDF est l’implémentation de référence maintenue par la PDF Association. Si veraPDF indique “Pass”, c’est le signal individuel le plus fort pour PDF/A.

Mais le meilleur signal individuel ne suffit pas toujours comme preuve d’audit. Les banques, archives médicales, administrations et systèmes d’archivage long terme demandent souvent un second moteur parce que :

Le destinataire peut utiliser un autre validateur en interne.
Un bug dans un moteur ne se détecte pas en lançant deux fois le même moteur.
Deux confirmations indépendantes sont une pratique courante en conformité.

gPdf combine veraPDF avec son propre moteur Rust + WebAssembly. C’est une implémentation indépendante de la même spécification. Quand les deux passent, la conclusion est beaucoup plus solide ; lorsqu’ils divergent, l’enquête commence au bon endroit.

Deux rapports sur une seule URL

Le workflow est gratuit sur gpdf.com/validator/. Sans connexion : téléversez le fichier, veraPDF et le moteur edge de gPdf s’exécutent en parallèle, puis deux rapports s’affichent côte à côte.

Usages typiques :

Avant de livrer un PDF/A : téléverser, vérifier deux “Pass”, conserver les JSON comme preuve QA.
Un moteur passe, l’autre échoue : comparer les rapports ; le problème est souvent un XMP, une référence /AF ou une metadata d’attachement.
Les deux échouent : corriger la génération à la source.
Auditer un lot d’archives : valider des échantillons et joindre les résultats au dossier d’audit.

Le fichier n’est pas conservé. Il est traité en mémoire sur Cloudflare Workers puis supprimé après génération du rapport.

La même logique pour l’e-invoicing

Avec Factur-X / ZUGFeRD, il faut valider l’enveloppe PDF/A-3 mais aussi le XML CII EN 16931 embarqué. Le validator gPdf utilise Mustang pour cette partie et affiche le résultat avec le rapport PDF/A.

Ce n’est pas une question de méfiance envers un outil. C’est une manière de produire une preuve plus robuste avec deux implémentations indépendantes.

TL;DR

Un “Pass” unique est un feu orange. Deux “Pass” indépendants sont une preuve bien plus solide. Déposez le fichier dans validator, récupérez les deux rapports et joignez-les au QA ou à l’audit. Si le PDF vient de l’API gPdf, le validator devient le reçu public de sa conformité.