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

Réponse courte : parce que la spécification est assez vaste pour que deux implémentations correctes divergent sur les cas limites, et qu’un flux soumis à audit traite un « Pass » venant d’un seul moteur comme un feu orange, pas un feu vert. Voici la version longue.

PDF/A est une pile de règles négociées, pas un algorithme unique

PDF/A est défini sur plusieurs parties de l’ISO 19005 (PDF/A-1, PDF/A-2, PDF/A-3, PDF/A-4), chacune avec des sous-niveaux de conformité (b, a, u, e, f), et chacune s’appuie sur la spécification PDF sous-jacente (ISO 32000). La surface combinée représente plusieurs milliers de pages de texte normatif.

Quelques exemples de zones où des implémentations conformes ont historiquement divergé :

Transparence en PDF/A-2/3 : autorisée sous conditions spécifiques ; ces conditions sont écrites de manière procédurale, et les validateurs n’implémentent pas toujours le contrôle de la même façon.
Profils couleur embarqués : quand un profil ICC est-il « requis » plutôt que « recommandé » ? Différents validateurs ont déjà classé le même fichier en « Pass » et « Fail » sur cet axe.
Métadonnées de fichiers embarqués en PDF/A-3 : AFRelationship, références /AF, XMP embarqué ; les règles sont bien spécifiées, mais la sévérité d’application varie.
Sous-ensembles de polices : PDF/A exige que toutes les polices soient embarquées avec leur encodage réel. Les cas limites autour des polices CID avec sous-ensembles partiels ont déjà produit des désaccords entre validateurs.

Ce ne sont pas nécessairement des bugs. C’est la conséquence naturelle d’une spécification complexe implémentée par des équipes indépendantes à partir d’un texte normatif. La position prudente — et celle de la plupart des secteurs régulés — consiste donc à demander plusieurs confirmations indépendantes.

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

veraPDF est l’implémentation de référence maintenue par la PDF Association, l’organisme de standardisation qui publie PDF/A. Le projet est open source, audité par des groupes de travail de l’industrie, et son jeu de règles est l’interprétation canonique du texte ISO 19005. Si veraPDF indique « Pass », c’est le signal le plus fort qu’un moteur unique puisse donner.

Mais le « meilleur signal à moteur unique » n’est pas la même chose qu’une « preuve qui passe l’audit ». Les auditeurs d’institutions régulées — banques, archives de dossiers médicaux, administrations — demandent fréquemment une deuxième confirmation indépendante parce que :

l’interprétation d’une règle par veraPDF peut différer de celle d’un autre validateur utilisé en interne par l’entité auditée, avec un risque de rejet en aval ;
un bug dans un moteur unique, même de référence, ne peut pas être détecté en lançant deux fois ce même moteur ;
le principe d’achat « deux confirmations indépendantes » est largement appliqué dans les domaines de conformité ; PDF/A hérite de cette attente via ses cas d’usage d’archivage.

Le choix du deuxième moteur dépend de ce qui est disponible :

Adobe Acrobat Preflight est payant et fermé ; il convient comme moteur de confirmation, mais limite la re-vérification indépendante.
callas pdfaPilot est payant et constitue un choix d’entreprise de fait, mais limite lui aussi la re-vérification indépendante.
Un second moteur open source ; il en existe quelques-uns, souvent moins complets que veraPDF.

Ce que nous avons fait chez gPdf : construire notre propre moteur en Rust + WebAssembly comme « réimplémentation indépendante » délibérée. Même spécification, mêmes règles, écrit depuis zéro par une équipe différente. Quand les deux moteurs passent sur le même fichier, la conclusion est bien plus solide que celle de chacun pris isolément. Quand ils divergent, vous avez un bug clair à investiguer, dans l’un des moteurs ou dans le fichier.

Le validateur qui met les deux sur une seule URL

Nous hébergeons les deux sur gpdf.com/validator/ : gratuit, sans connexion, avec exécution du fichier dans veraPDF et dans notre moteur à l’edge en parallèle, puis restitution des deux rapports côte à côte. Les cas d’usage :

Vous générez un PDF/A et voulez l’expédier : déposez-le dans le validateur, les deux moteurs passent, joignez les rapports JSON comme preuve QA. Terminé.
Un moteur échoue, l’autre passe : vous avez un bug précis ; comparez les rapports et trouvez le champ en cause. Souvent, c’est un détail comme un timestamp XMP mal aligné ou une référence /AF manquante dans un PDF/A-3.
Les deux échouent : le fichier est réellement cassé ; corrigez à la source.
Audit d’un lot d’archives entrant : déposez des PDF échantillonnés aléatoirement, journalisez les URL de rapport, joignez-les au dossier de travail d’audit. « Nous avons vérifié avec veraPDF et un moteur indépendant » est une affirmation plus forte que « nous avons lancé le vérificateur de notre fournisseur ».

Le fichier que vous téléversez ne quitte jamais la requête : les moteurs s’exécutent en mémoire sur Cloudflare Workers, puis le fichier est supprimé après le rendu du rapport. Pas de connexion, pas de persistance, pas de quota.

Le même schéma, généralisé

Ce n’est pas seulement une question de PDF/A. Le modèle des « deux confirmations indépendantes » s’étend à :

Factur-X / ZUGFeRD pour les factures électroniques : gpdf.com/validator/ exécute Mustang (mustangproject.org) pour le XML CII EN 16931 embarqué, aux côtés du contrôle PDF/A ci-dessus. (Validating ZUGFeRD with Mustang — what passes, what fails couvre ce flux.)
Certificats TLS : chaque journal CA moderne est recoupé par plusieurs moniteurs.
Reproductibilité des builds : deux reconstructions indépendantes à partir de la même source doivent produire des sorties identiques au niveau des octets.

Le monde de la conformité le fait depuis des décennies. PDF/A ne fait que rattraper cette pratique.

TL;DR

Un « Pass » à moteur unique est un feu orange. Un double « Pass » est vert. Les deux moteurs sont gratuits sur validator : déposez votre fichier, récupérez deux rapports, joignez-les à vos preuves QA. Si gPdf a généré le fichier, le validateur devient le reçu public qui montre que l’API a tenu sa promesse de conformité.

Si vous construisez sur l’API gPdf, la référence de l’E-invoice API (§5) montre comment émettre directement un PDF/A-3 Factur-X / ZUGFeRD. Le validateur le confirme ensuite de manière externe. Deux moteurs, un téléversement : c’est le modèle adapté à l’audit.