Un PDF issu d’un scan sans couche texte est un fichier muet pour un lecteur d’écran. JAWS, NVDA ou VoiceOver n’y lisent rien : pas de texte sélectionnable, pas de structure sémantique, pas d’ordre de lecture. L’OCR appliqué à un PDF reconstitue la couche texte, mais cette étape seule ne suffit pas à produire un document accessible. Nous distinguons ici les points techniques qui séparent un PDF « cherchable » d’un PDF réellement exploitable par les technologies d’assistance.
Couche texte OCR et balisage PDF/UA : deux étapes distinctes
L’OCR génère une couche texte invisible superposée à l’image du document. Cette couche permet la recherche plein texte et le copier-coller. Elle ne produit aucune structure sémantique.
Un lecteur d’écran ne se contente pas de lire du texte brut. Il s’appuie sur l’arbre de balisage (tag tree) du PDF pour restituer titres, paragraphes, listes, cellules de tableau et texte alternatif des images. Sans balisage conforme à PDF/UA (ISO 14289), l’OCR seul ne rend pas un PDF accessible.
La majorité des outils en ligne (Smallpdf, Adobe Acrobat online, Lumin) ajoutent la couche texte mais ne génèrent pas de tag tree. Le fichier obtenu est consultable, pas accessible. Nous recommandons de traiter l’OCR comme une première passe, suivie d’un balisage structurel dans un éditeur PDF qui gère les tags : Acrobat Pro, axesPDF ou CommonLook.
Ordre de lecture et artefacts : les pièges post-OCR dans les PDF scannés
Sur un document à mise en page complexe (colonnes, encadrés, notes de bas de page), le moteur OCR reconstitue le texte mais l’ordre de lecture logique est rarement correct. Le lecteur d’écran parcourt le tag tree de haut en bas. Si l’ordre des tags ne correspond pas à l’ordre visuel, l’utilisateur reçoit des phrases mélangées.
L’ordre de lecture logique se vérifie et se corrige manuellement dans le panneau « Ordre » d’Acrobat Pro ou via l’outil PAC (PDF Accessibility Checker). Ignorer cette vérification revient à livrer un document techniquement balisé mais inutilisable.
Autre piège fréquent : les éléments décoratifs (filets, logos, fonds de page) que l’OCR interprète comme du contenu. Ces éléments doivent être marqués comme artefacts pour que le lecteur d’écran les ignore. Un en-tête répété sur chaque page, s’il n’est pas tagué en artefact, sera lu à chaque changement de page, ce qui rend la navigation pénible.
Points de contrôle après traitement OCR
- Vérifier l’ordre de lecture logique avec PAC ou le panneau « Ordre » d’Acrobat Pro, page par page sur les mises en page à colonnes multiples
- Marquer en artefacts tous les éléments décoratifs, en-têtes et pieds de page répétitifs, filigranes
- Ajouter un texte alternatif à chaque image porteuse de sens (graphiques, schémas, photos informatives)
- Attribuer les tags appropriés aux tableaux de données : balises TH pour les en-têtes, TD pour les cellules, attribut Scope si nécessaire
WCAG 2.2, PDF/UA et cadre réglementaire français : ce qui s’applique aux PDF
Les organisations combinent désormais WCAG 2.2 avec la norme PDF/UA pour définir ce qu’est un PDF réellement accessible aux technologies d’assistance. PDF/UA impose un tag tree complet, un ordre de lecture défini, un titre de document dans les métadonnées et un texte de remplacement pour le contenu non textuel.
En France, le RGAA transpose les critères WCAG et impose aux administrations publiques que chaque document téléchargeable soit accessible ou qu’une alternative équivalente soit proposée. La directive européenne sur l’accessibilité (European Accessibility Act) étend progressivement cette obligation au secteur privé.
Aux États-Unis, la règle finale publiée en avril 2024 par le Department of Justice pour le Title II de l’ADA impose aux gouvernements locaux et d’État le respect de WCAG 2.1 niveau AA pour leur contenu web, y compris les PDF en ligne. Les grandes entités doivent être conformes au plus tard le 26 avril 2027, les plus petites au 26 avril 2028.
Nous observons que la contrainte juridique pousse les organisations à traiter le balisage des PDF en amont, dès la création du document, plutôt qu’en remédiation post-scan. Produire un PDF natif balisé depuis Word ou InDesign est nettement plus fiable que de rattraper un scan par OCR puis balisage manuel.
Vérification d’accessibilité PDF après OCR : outils et méthode
Le contrôle qualité ne peut pas reposer uniquement sur le vérificateur intégré d’Acrobat. Cet outil détecte les erreurs de structure évidentes (absence de titre, images sans texte alternatif) mais ne valide pas l’ordre de lecture réel ni la cohérence sémantique des tags.
PAC (PDF Accessibility Checker) reste la référence pour un audit PDF/UA. Il signale les erreurs de conformité ISO 14289 et permet de visualiser l’arbre de tags. En France, l’ANCT met à disposition Docaxess, un outil en ligne pour tester la conformité d’un PDF aux critères du RGAA.
La méthode que nous recommandons suit trois niveaux :
- Passe automatisée avec PAC ou Docaxess pour détecter les non-conformités structurelles
- Vérification manuelle de l’ordre de lecture sur les pages à mise en page complexe, en utilisant la restitution vocale d’un lecteur d’écran (NVDA est gratuit et suffisant pour ce test)
- Contrôle du texte OCR lui-même : relire les passages où le moteur a pu confondre des caractères (ligatures, caractères accentués, tableaux avec bordures fines)
Qualité OCR et caractères spéciaux
Les moteurs OCR actuels atteignent une bonne fiabilité sur les polices courantes et les documents bien numérisés. La précision chute sur les documents anciens, les polices décoratives ou les scans à faible résolution. Un scan à 300 dpi minimum est le seuil recommandé pour obtenir une reconnaissance fiable.
Les erreurs de reconnaissance passent souvent inaperçues visuellement, car la couche texte est masquée sous l’image. Un lecteur d’écran restitue pourtant le texte OCR, pas l’image. Un « é » reconnu comme « 6 » ou un « fl » fusionné en caractère inconnu produit un rendu vocal incompréhensible.
La production de PDF accessibles à partir de documents scannés reste un processus en deux temps que rien ne permet de raccourcir : OCR pour extraire le texte, puis balisage structurel pour donner un sens à ce texte. Les organisations qui traitent des volumes importants de fichiers numérisés gagnent à investir dans des workflows intégrant ces deux étapes, plutôt que de multiplier les corrections manuelles en aval.
