Une responsable juridique commande “un audit RGAA” pour les conditions générales de vente et les factures PDF de son entreprise. Trois semaines plus tard, elle reçoit un document qui ne contient jamais le mot RGAA. À la place : “PDF/UA-1”, “ISO 14289-1”, “106 critères”, des clauses numérotées comme 6.2 ou 7.2.22. Elle relit le devis initial, cherche le lien avec ce qu’elle a réellement commandé, et ne le trouve pas clairement écrit nulle part.
Ce n’est pas une erreur de livraison. C’est le symptôme d’une confusion terminologique qui traverse tout le marché de l’accessibilité PDF en France, des agences aux équipes achats en passant par les développeurs qui intègrent un contrôle automatisé dans leur pipeline documentaire.
Le devis parlait de RGAA, la livraison parle d’ISO 14289-1
Le scénario se répète avec des variantes mineures dans beaucoup d’entreprises soumises à l’European Accessibility Act. Une équipe juridique ou marketing, alertée sur l’obligation légale, cherche “un prestataire RGAA” pour ses PDF. Elle signe un devis qui mentionne l’accessibilité numérique en général, sans détailler la méthode technique employée. Le rapport final, lui, est rédigé dans un vocabulaire différent : norme ISO, critères numérotés, statuts binaires réussi/échoué par page.
Personne n’a menti dans cet échange. Le prestataire a probablement fait un travail technique sérieux. Mais le vocabulaire du devis et celui du rapport ne se recoupent jamais explicitement, et l’entreprise se retrouve à devoir deviner elle-même le lien entre les deux, sans grille de lecture fournie. Dans une équipe qui n’a ni juriste spécialisé accessibilité ni développeur familier du sujet, ce vide se traduit vite par une question simple et légitime : est-ce que ce rapport PDF/UA-1 prouve, ou non, que l’entreprise est en règle avec le RGAA ?
Le prix caché d’un mauvais réflexe : sur-promettre ou sous-estimer
Cette incertitude coûte cher dans les deux sens. Certaines entreprises, rassurées par un rapport PDF/UA-1 sans faille sur leurs documents, affirment publiquement être “100 % conformes RGAA” — une promesse que la norme technique seule ne permet pas de tenir, puisque le RGAA couvre aussi des aspects que notre validateur ne mesure pas : la pertinence réelle d’un texte alternatif au regard du contexte, la cohérence d’un parcours utilisateur complet entre le site, l’application et les documents téléchargés. À l’inverse, d’autres équipes achats, méfiantes après une première expérience confuse, exigent “un vrai audit RGAA humain” pour chaque document PDF déposé, alors qu’une bonne partie de ce qui est objectivement vérifiable dans un PDF peut l’être en quelques minutes plutôt qu’en semaines de facturation au forfait.
Les deux réflexes viennent de la même racine : personne n’a expliqué clairement où s’arrête ce qu’un outil peut mesurer automatiquement, et où commence ce qui reste, par nature, une appréciation humaine. Une entreprise qui ne fait pas cette distinction finit soit par sur-communiquer sur une conformité qu’elle ne peut pas garantir en totalité, soit par payer plusieurs fois pour vérifier ce qu’un contrôle technique avait déjà établi de façon fiable.
Ce que le RGAA couvre, ce que PDF/UA-1 vérifie précisément
Voici ce que recouvrent réellement ces deux termes, sans les confondre. Le RGAA (Référentiel Général d’Amélioration de l’Accessibilité) est un référentiel légal français qui évalue l’accessibilité d’un service numérique dans son ensemble : un site web, une application mobile, et les documents qu’ils mettent à disposition, PDF compris. Ses critères s’appuient en partie sur des normes techniques internationales, mais une démarche RGAA complète implique aussi des vérifications qu’un logiciel ne peut pas trancher seul — la qualité d’un texte alternatif au-delà de sa simple présence, ou la cohérence d’un parcours de navigation testé par un utilisateur réel.
PDF/UA-1, de son côté, est une norme technique précise, l’ISO 14289-1, qui définit noir sur blanc ce que doit contenir un PDF accessible : structure logique balisée, ordre de lecture cohérent, langue déclarée, titre de document renseigné, texte alternatif présent sur les images. C’est cette norme que notre validateur contrôle réellement, critère par critère, de façon automatisée et reproductible sur chaque document. Pour la partie strictement documentaire d’une démarche RGAA appliquée aux PDF, PDF/UA-1 en constitue la portion la plus objectivement mesurable — mais il n’existe pas de “moteur de contrôle RGAA” distinct qui tournerait à côté, sur un autre référentiel. Ce point de vocabulaire mérite d’être posé clairement une fois pour toutes, parce que la confusion inverse coûte tout autant : croire qu’un audit RGAA complet équivaut à un simple export PDF/UA-1, ou l’inverse. L’article sur ce que l’EAA change concrètement pour les PDF d’une entreprise pose les seuils et les sanctions qui rendent cette distinction urgente à comprendre, au-delà du seul vocabulaire.
106 critères binaires : ce que notre validateur regarde vraiment
Concrètement, un contrôle PDF/UA-1 ne rend jamais un jugement flou du type “plutôt accessible”. Chaque critère est soit respecté, soit non respecté. Le critère 6.2.1, par exemple, vérifie qu’un document déclare explicitement contenir une structure balisée (l’entrée Marked du dictionnaire MarkInfo) — sans ce simple marqueur, un lecteur d’écran ne sait même pas qu’une hiérarchie de titres et de paragraphes existe, et lit tout le contenu à plat. Le critère 7.1.9 vérifie qu’un titre de document est renseigné dans les métadonnées : sans lui, l’utilisateur d’un lecteur d’écran entend le nom du fichier (“doc_2847.pdf”) au lieu d’un intitulé compréhensible à l’ouverture. Le critère 7.2.22, plus fin, vérifie que la langue d’un texte alternatif est déterminable, pour que la synthèse vocale applique les bonnes règles de prononciation plutôt que de lire un mot anglais avec un accent français.
Ces trois exemples illustrent ce qui rend PDF/UA-1 vérifiable à grande échelle : ce sont des faits techniques présents ou absents dans le fichier, pas des jugements sur la qualité rédactionnelle d’un contenu. C’est précisément cette nature binaire, sur les 106 critères de la norme, qui permet à notre moteur de validation de contrôler un lot entier de documents en quelques minutes. Ce que ce contrôle ne fait pas, en revanche, c’est juger si le texte alternatif “photo de produit” décrit réellement bien le produit en question — cette appréciation reste, par nature, humaine, et relève d’une démarche RGAA plus large plutôt que d’un test automatisable.
Lire un rapport de conformité en connaissance de cause
Cette distinction change concrètement la façon de commander et de lire un rapport de conformité PDF. Face à un devis qui promet “un audit RGAA” pour des documents, la bonne question à poser est simple : quelle norme technique sert de base à la partie vérifiable automatiquement, et quel outil de référence l’exécute ? Un prestataire sérieux doit pouvoir répondre PDF/UA-1 et nommer un moteur de validation reconnu sans détour, plutôt que de rester vague sur sa méthode.
Vigie PDF atteste précisément ce périmètre-là, sans ambiguïté de vocabulaire. La plateforme tague les PDF, natifs comme scannés, puis valide chaque document sur l’intégralité des 106 critères PDF/UA-1 avec son moteur de validation — jamais un score RGAA maison qui laisserait croire à une couverture plus large que ce qui a réellement été vérifié. Le dashboard indique, document par document et critère par critère, ce qui a été contrôlé, avec un rapport de conformité généré à la demande pour l’entreprise qui doit justifier sa démarche. Savoir lire cette différence, avant même de commander un audit, évite à la fois de sur-promettre une conformité RGAA totale et de payer deux fois pour re-vérifier ce qu’un contrôle technique fiable avait déjà établi.