Réinventer l'exportation

Published October 9, 2026

Depuis mes premiers pas dans le monde numérique, j'entretiens un beef unilatéral avec le format PDF. J'ai pesté en essayant de sélectionner du texte pour le copier, j'ai pesté en essayant de chercher un mot-clé dans les centaines de pages d'un document scanné, et j'ai encore pesté quand, en devenant spécialiste en accessibilité, j'ai réalisé à quel point il était compliqué de le rendre sexy. Alors, pourquoi exporte-t-on encore en PDF, au final ?

Travailler dans l'accessibilité et être perfectionniste m'a, dès le début, mise face à un constat un peu risible : le plus gros obstacle dans ma pratique, à ce stade, était de faire en sorte que mes résultats soient accessibles. J'ai exploré bon nombre de pistes, enchaîné les idées et les tests, usé et abusé de VoiceOver, et la finalité restait la même. Produire un rapport qui rassemblait ce que je voulais (mes résultats, clairs et accessibles à tous les publics), ce qui est nécessaire (un format qui puisse être transmis entre les équipes, lu depuis plusieurs supports, stocké dans des bases de données, recherchable, dont on puisse extraire le contenu…) et ce qui est important pour moi (ouvert, lisible, robuste, adapté, joli), était juste trop difficile. Parce que LE format d'aujourd'hui, malgré tout ce que j'ai à lui reprocher, est et reste le PDF. Même si 94,75 % des PDF publics sont inaccessibles, d'après une étude d'Allyant portant sur 644 854 PDF. Ouch.

J'étais donc face à plusieurs solutions. Aucune ne m'emballait vraiment, et toutes me demandaient un sacrifice. Je n'aime pas les sacrifices, et je n'aime pas travailler sur quelque chose dont je ne serai pas fière à la fin. Alors j'ai pris un chemin qui me semblait raisonnable : trouver une alternative. Puisqu'à l'instant T, je n'étais pas techniquement capable de proposer mes résultats dans un PDF accessible, j'ai décidé de proposer un format supplémentaire, qui lui, le serait. Et une fois encore, la croix, la bannière, les soupirs, et la perspective de devoir encore rogner sur mes idées. Jusqu'à ce que je fasse (enfin) un rapprochement : mais en fait, le HTML, ce sont les mêmes balises, non ? Et ça, je sais faire, non ???

HTML, le couteau suisse

La page que vous lisez actuellement est écrite en HTML. Pour être précise, pour que vous lisiez ces mots, qu'ils soient lisibles par les technologies de lecture d'écran et recherchables par les moteurs de recherche, voici à quoi ressemble cette phrase dans le code :

<p>Pour être précise, pour que vous lisiez ces mots, qu'ils soient lisibles par les technologies de lecture d'écran et recherchables par les moteurs de recherche, voici à quoi ressemble cette phrase dans le code :</p>

L'élément <p> que vous voyez entourer ma phrase est une balise de paragraphe, qu'on appelle aussi tag. Si vous avez lu mon article sur les PDF, vous devriez commencer à reconnaître ce langage, et vous avez totalement raison de faire ce rapprochement : en HTML, on utilise des balises sémantiques pour transmettre au navigateur une couche d'informations supplémentaire. En utilisant <h1>, j'envoie le message que ce texte est le titre principal de ma page. En utilisant <img alt="Photo d'un poisson qui fait un salto arrière">, je place une image et j'en décris le contenu pour celles et ceux qui ne peuvent pas la voir (ou pour les IA, les logiciels…). Il existe même des balises invisibles, qui ne parlent qu'aux machines : <title> et <meta name="description"> disent au moteur de recherche comment s'appelle ma page et quelle accroche afficher dans ses résultats. Grâce à toutes ces informations, il comprend que cette page est un article de blog, que j'y parle d'accessibilité et de HTML, et il sait comment la présenter.

<h1>Bienvenue à toutes et tous</h1>
<h2>Vous êtes en train de lire du HTML !</h2>

<p>Si ce texte n'était pas une image (capture d'écran), vous pourriez le lire depuis n'importe quel support, avec la plupart des technologies d'assistance disponibles.</p>

<h2>Mais il y a un hic...</h2>
<p>Même si ce texte est entièrement balisé, je l'ai exporté en image : il n'est donc pas pleinement accessible.</p>

<h3>C'est ballot, non ?</h3>

Je ne compliquerai pas les choses en vous parlant de web, d'hébergement, de cloud… Tout ceci n'est pas la question, et ça n'a pas d'intérêt dans l'immédiat. Ce que vous devez retenir de cette démonstration, c'est en premier lieu la rapidité d'exécution. Il me suffit de mon clavier pour taper cette phrase dans mon logiciel de code (VS Code), et elle devient, sans étape supplémentaire, lisible en l'état. En ouvrant le fichier HTML tout juste écrit dans mon navigateur, toutes les technologies à ma disposition savent déjà que cette phrase est un paragraphe, et peuvent déjà la lire, la comprendre, faire des recherches dessus, l'étudier et l'utiliser.

En second lieu, c'est la robustesse de cette phrase qui devrait vous sauter aux yeux. Vous la lisez depuis n'importe quel navigateur, n'importe quel appareil. Vous la lisez en ligne parce que j'en ai décidé ainsi, mais vous pourriez très bien me lire depuis le milieu de la forêt : il vous suffirait d'avoir mon fichier HTML (téléchargé depuis mon GitHub, par exemple). Si vous décidez de zoomer, vous pouvez le faire sans perdre la moitié de la page. Vous pourriez copier-coller ma phrase dans un moteur de recherche pour vérifier si c'est bien vrai, ce que je raconte. Ou vous pourriez me diffuser en podcast, dans la voiture, parce que vous me trouvez drôle (merci). Pour vous permettre de faire tout ça de façon accessible, j'aurais mis une éternité en passant par un traitement de texte et une exportation PDF. Moins tenace que je ne le suis, j'aurais abandonné. Et c'est exactement le nœud du problème.

Le PDF mérite mieux

Si le format PDF nous semble un peu démodé aujourd'hui, dans nos vies ultra-connectées où on le lit depuis nos écrans et plus depuis nos imprimantes, c'est parce qu'il ne date pas d'hier. Il est né sous le nom de « Projet Camelot » dans les bureaux d'Adobe en 1991, à l'initiative de son cofondateur John Warnock, avec pour objectif d'être un papier numérique. Pari réussi : à ce jour, aucun équivalent n'est aussi utilisé dans nos communications. Mais ici encore, arrêtons-nous sur le terme papier. En 2026, à l'ère où même les documents officiels sont transmis numériquement, avons-nous encore besoin de papier numérique ? Ou du moins, devrions-nous le garder comme format universel pour communiquer, alors que nous avons clairement penché pour le numérique plutôt que pour le papier ?

Car aujourd'hui, la manière dont le PDF a suivi les innovations numériques ne suffit pas à le rendre performant avec nos outils actuels. Le PDF est un format d'impression, mais l'impression se meurt. Nous vivons dans l'immédiateté : nous recevons notre courrier en PDF dans notre boîte mail, parce que c'est plus rapide que d'attendre qu'il arrive par la poste dans notre boîte aux lettres. (Pour l'anecdote, depuis quatre mois que j'habite au Canada, ma boîte aux lettres en France n'a reçu que quatre prospectus. Rien d'autre.) Nous vivons à travers nos écrans, qui nous suivent partout, s'adaptent à nos envies et à nos besoins, nous informent sur le reste du monde et nous connectent en temps réel à tout ce qui nous entoure. Dans notre quotidien comme dans notre travail, nous lisons désormais majoritairement du contenu numérique, via ces écrans. Vous me lisez depuis un écran, et il y a fort à parier que vous ne jugez pas nécessaire d'imprimer cet article. Pour le conserver, vous pourriez l'ajouter à vos marque-pages, garder le lien quelque part, copier-coller les phrases importantes dans vos notes. Mais vous ne m'imprimerez pas. Et le comble dans tout ça, c'est que si j'avais écrit ces mots dans un PDF, même en le rendant aussi accessible que possible, vous auriez quand même pesté contre le format, quel que soit l'écran depuis lequel vous m'auriez lue. Parce que le monde ne tourne pas au format A4. Il tourne à travers des écrans.

Si l'on veut garder l'âme du PDF, et donc son format de papier numérique, la moindre des choses pour l'adapter au monde contemporain, c'est de le rendre accessible. Même si les technologies d'assistance ne vous intéressent pas du tout, vous n'y couperez pas si vous voulez le rendre pratique, recherchable, lisible… Mon article sur le PDF accessible fait déjà le travail sur cette dimension, je vous y renvoie. Sauf que le PDF ne suit pas : il reste imparfait, et même en y mettant tous les efforts du monde (ce qui n'est déjà pas toujours facile), vous pourriez quand même, malgré vous, exporter un PDF mal balisé.

Pourquoi ? Imaginons que vous ayez tout fait dans les règles de l'art : vos titres utilisent les styles, vos images ont leur texte alternatif, vos listes sont de vraies listes. Vous cliquez sur « Exporter en PDF », option accessibilité cochée. Et pourtant, au moment de l'export, votre logiciel doit encore traduire votre document dans un autre langage, et certaines choses se perdent en route. Votre tableau avec des cellules fusionnées ? Il ne sait plus quelle cellule dépend de quel en-tête. Votre encadré en marge ? Il le lit au mauvais moment, voire à la toute fin. Votre formule mathématique ? Ce n'est plus qu'une image muette. Et quand ça arrive, la correction se fait à la main, balise par balise, dans Acrobat Pro (payant) ou en s'aidant d'un vérificateur comme PAC (gratuit, mais uniquement sur Windows). Petit bonus : si vous modifiez ensuite votre document source et l'exportez à nouveau, toutes vos corrections partent à la poubelle. Youpi !

Récapitulons. Le format de document le plus répandu au monde, dont on estime l'existence à quelque 2 500 milliards d'exemplaires, est aussi l'un des moins accessibles : environ 90 % d'entre eux ne seraient même pas balisés, selon BCcampus. Les premiers concernés l'ont bien compris : en 2021, seuls 12,9 % des utilisatrices et utilisateurs de lecteurs d'écran désignaient le PDF comme le format le plus accessible, loin derrière Word et ses 68,9 %, d'après l'enquête de WebAIM. Bien triste score pour le vétéran. Si vous faites de votre mieux, il est possible qu'une partie du temps passé à rendre votre document accessible soit perdue, faute d'amélioration des logiciels que nous utilisons tous les jours. Et dans tous les cas, la personne qui lira votre document, même voyante, sans besoin d'accessibilité particulier et sans technologie tierce comme un assistant IA, devra de toute façon se battre avec l'écran pour le lire correctement : zoomer, défiler latéralement, changer l'orientation de son appareil… et pester. Quoi qu'il arrive. Et encore, je vous parle là de PDF tout neufs, exportés avec les meilleures intentions du monde. Mais qu'en est-il des milliers de documents qui dorment dans les bases de données des entreprises, scannés, photocopiés, empilés depuis des années ?

Vers une exportation plus robuste ?

À ce stade de l'article, vous devez me prendre pour une hater du PDF. Vous avez un peu raison, mais vous avez surtout tort. Ce que je déplore, ce n'est pas le format, mais la difficulté qu'on rencontre au quotidien, tant pour l'utiliser que pour le rendre utilisable.

Revenons au début de cet article : à la base, toute cette réflexion vient d'une question d'exportation. Dans mon cheminement personnel, j'ai donc décidé de proposer une alternative au PDF. D'une part parce que je voulais un format lisible et robuste. D'autre part parce qu'une observation commençait déjà à découler de ce travail : quand l'accessibilité n'est pas pratique à mettre en place, on ne la met pas en place, parce que c'est une étape supplémentaire compliquée. Je, vous, nous, ils, elles et toutes les personnes entre les deux n'avons ni le temps, ni l'envie, ni parfois les moyens de faire douze étapes supplémentaires pour quelque chose d'aussi simple que signaler à une technologie du quotidien (qui nous dépasse, à ce stade) qu'un titre est un titre. À l'échelle d'une entreprise, à l'échelle du capitalisme, à l'échelle d'une course contre la montre perpétuelle, je sais pertinemment que l'accessibilité sera sacrifiée au profit de la rapidité et de la praticité, parce que la rentabilité entre aussi en jeu. Dans ce contexte, proposer l'alliance d'un PDF pour rester dans la norme et d'un fichier HTML pour sa robustesse et son accessibilité pouvait être une solution à mon problème.

C'est en travaillant sur mes rapports et sur mon outil interne, Vesper Auditor, que j'ai commencé à mettre en pratique l'exportation en HTML. J'utilise mon outil pour remplir mes constats, mes tests, mes conclusions… Et j'exporte ces données, remplies manuellement, dans un template stylisé qui se met à jour automatiquement avec ce que je lui donne. J'ai conçu ce template pour qu'il soit accessible aux technologies d'assistance, mais le format m'a aussi permis de rendre mon rapport plus interactif et plus pratique : des liens pour sauter directement aux sections qui nous intéressent, des menus accordéons pour ne pas noyer la page sous le jargon, des liens vers des ressources complémentaires… De fil en aiguille, mon exportation HTML est devenue le pilier de ma communication, et l'un de mes principaux atouts, à mon sens : mes rapports sont lisibles sur tous les supports, par tout le monde. Un peu de travail en profondeur sur le style, l'accessibilité et le responsive, et le rendu final devient imbattable : ludique, interactif, il se transforme en outil de présentation, de démonstration, et en argument de vente. Pratique aussi : je n'ai eu à m'y pencher qu'une fois pour toutes, et je peux toujours l'adapter au besoin. La cerise sur le gâteau ? Quand j'ai fait le diagnostic de mon propre site, je n'ai eu qu'à intégrer l'export HTML dans son code, puisque c'est du format web. Les déclarations d'accessibilité que je produis sont donc publiables telles quelles par mes clients, sans étape de réécriture.

Mais alors, pourquoi avoir passé tout ce temps à vous convaincre que le PDF restait important dans cette histoire ? Eh bien, c'est justement en travaillant sur l'interactivité de mon export HTML que j'ai commencé à faire de nouveaux rapprochements. Je me suis dit que, quitte à proposer des boutons, autant proposer directement un bouton d'exportation en PDF. Après tout, les personnes qui feront appel à moi n'auront peut-être jamais besoin de ce PDF : ce serait une perte de temps de le produire moi-même à chaque fois. Autant laisser le choix depuis le HTML. Attendez, c'est ici que ça devient (encore plus) intéressant.

Jusqu'ici, la version PDF de mes rapports tenait en une commande : window.print(). Elle ouvre une boîte de dialogue, souvent celle d'impression, depuis laquelle on peut enregistrer le contenu au format PDF. Pour ce faire, le navigateur génère un PDF à partir de la page. Le texte y est bien présent, mais selon le navigateur, le PDF peut être dépourvu de balises : un bloc de mots sans titres, sans listes, sans ordre de lecture fiable. De facto, le PDF qui en ressortait jusqu'ici était quasiment inutilisable pour un lecteur d'écran. À noter cependant : depuis sa version 85, Chrome produit par défaut des PDF balisés via « Enregistrer au format PDF ». Ce n'est pas toujours précis, mais c'est appréciable, si on utilise Chrome. Avant ça, j'avais bien essayé de créer des templates accessibles dans des traitements de texte ou des tableurs, mais je butais toujours sur les sacrifices de design et le temps perdu, pour une exportation au final moyenne. J'étais insatisfaite au point qu'à ce stade, proposer un HTML hyper accessible et un PDF pas du tout accessible me semblait une solution à peu près acceptable. Bof.

J'étais un peu contrariée, donc, et au lieu de réutiliser exactement la même commande pour exporter au format PDF, j'ai commencé à me demander : puisque mon rapport contient des données reconnaissables par les autres technologies, est-ce que je ne pourrais pas utiliser les balises déjà présentes dans le code ? En creusant, je me suis rendu compte que ce n'est pas si facile (ni accessible) que ça. En bidouillant de mon côté, cependant, et grâce à l'exportation de Chrome (ou du moins, à son fonctionnement), j'ai pu serpenter vers de nouvelles pistes, et exporter mon premier rapport balisé. Grâce à mon export HTML, j'avais réussi à produire un rapport au format PDF bien plus accessible que tous mes essais précédents. En essayant de paramétrer un bouton. Totalement par hasard. Alors bien sûr, ce serait mentir de vous dire que ce PDF est incroyablement beau, totalement accessible et conforme à toutes les normes. À vrai dire, pas du tout : il est toujours plein de défauts, et je reste mitigée sur le résultat. Par exemple, bien que j'aie correctement indiqué un ordre de tabulation, il n'est pas (toujours) repris dans l'ordre de lecture, mes liens d'évitement ne fonctionnent pas, et la structure du document ne repère pas les différentes zones de mon HTML, ce qui en complique la navigation. Mais une perspective s'est ouverte : on peut peut-être faire mieux grâce au HTML, si on s'en donne les moyens.

Voyez plutôt : si on exporte du contenu à partir d'une page HTML, le logiciel n'a pas besoin de deviner. Il peut déjà repérer tous les éléments, s'ils sont correctement écrits, et les placer dans les bonnes balises. Les informations que mon exportation actuelle ne reflète pas, comme l'ordre de lecture, sont bien présentes dans le code. La technologie n'est simplement pas encore adaptée pour les comprendre. Si on le voulait, et avec les moyens nécessaires, on pourrait, à terme, paramétrer son PDF entièrement grâce au HTML. À l'instant T, derrière cet écran, je ne suis pas suffisamment compétente pour le faire, mais c'est possible.

En pratique

Alors, et si on repensait l'exportation sous un prisme nouveau ? Ou, plus simplement, si on changeait de format pour communiquer nos documents ? Si nous lisons et communiquons principalement sur nos écrans, le HTML devient un bon candidat pour produire un document robuste et lisible. Et si ce balisage HTML permet ensuite une exportation au format PDF plus robuste et plus accessible, elle aussi, pourquoi devrions-nous nous en priver ? Élargissons encore : nous avons vu plus tôt que le format jugé le plus accessible par les utilisatrices et utilisateurs de lecteurs d'écran est Word. Or, Word n'est pas entièrement gratuit, les alternatives open source existent mais sont moins faciles d'accès et demandent des étapes supplémentaires, il est fort probable que vous n'ayez pas l'application sur votre téléphone, etc., etc. Vous pourriez l'ouvrir avec Google Docs, mais il vous faudra souvent du réseau, ce qui n'est pas toujours le cas. En revanche, vous avez forcément un navigateur, et un fichier HTML se lit hors ligne. Un fichier Word s'adapte aussi difficilement à l'écran, là où un HTML peut être paramétré pour ça. En fait, le HTML ne faisait même pas partie des options proposées aux répondantes et répondants de ce sondage, alors que ces personnes consultent sûrement le web quotidiennement !

Imaginons un monde où l'exportation HTML serait reine : des logiciels conçus spécialement pour écrire du contenu et le traduire en HTML, via une interface simplifiée. Une couche d'accessibilité numérique sans étape supplémentaire, des scans automatiques facilités, des partages robustes lisibles sur tous les appareils. Au bout de la chaîne, quand c'est vraiment nécessaire, un document PDF qui utilise les balises du HTML, qui ne devine rien, et qui peut même être un peu joli au demeurant. Et si on n'a pas besoin de PDF, pas besoin de le créer, pas besoin de s'embêter : on peut simplement publier la page sur le web, l'envoyer par email ou la ranger dans son cloud.

S'y mettre maintenant

J'ai été honnête juste au-dessus : aucun des outils qui existent actuellement n'est comparable à un traitement de texte qui transformerait magiquement votre texte brut en HTML présentable et exportable en PDF dans la foulée. À vrai dire, j'essaie toujours de mettre ça en place dans mon outil interne, sans y être totalement parvenue à l'heure où j'écris ces lignes. On va donc beaucoup bidouiller. L'idée de cet article est d'ouvrir la voie, et c'est peut-être un sujet sur lequel je travaillerai moi-même de mon côté. En attendant, voici quelques pistes accessibles aux débutants.

LibreOffice Writer : pour exporter un document en HTML

Alternative open source à Word, Writer dispose d'une option pour exporter en HTML : Fichier > Envoyer > Créer un document HTML. Il a déjà une place spéciale dans mon cœur, car c'est à mon sens l'outil gratuit le plus compétent actuellement pour exporter un PDF correctement balisé. Mais comme pour un PDF, le secret de votre export HTML résidera dans votre utilisation des styles (Titre 1, listes…) et des options d'accessibilité à votre disposition. L'exportation ne sera pas parfaite, mais elle aura le mérite d'être relativement robuste.

Pandoc : pour convertir un document en HTML

Pandoc est le couteau suisse open source des convertisseurs de formats. Grossièrement, vous lui demandez de « traduire » votre document (un .docx, par exemple) en HTML, toujours à condition d'avoir utilisé des styles. Pour un résultat optimal, vous pouvez d'abord le convertir en markdown. C'est une solution un peu moins accessible aux novices, car elle demande de lire de la documentation, d'utiliser des lignes de commande… Mais elle peut vous permettre d'explorer différents formats et de faire vos premiers pas en HTML.

HTML pur : pour intervenir à la source

Se lancer dans le HTML peut être intimidant, car ce sont vos premiers pas dans le code. Mais pas de panique, plusieurs sites aident à apprendre le langage de manière ludique. Ici, il n'est pas question de coder un site, mais un document : la présentation est donc bien plus simple. Sur MDN Playground, vous pouvez taper votre HTML d'un côté et voir le résultat de l'autre, avec la documentation à portée de main. C'est la manière la plus rapide de débuter, sans télécharger de logiciel de code.

Pour expérimenter de manière plus durable et garder votre document sous le coude, vous pouvez télécharger VS Code ou un logiciel similaire. Au plus simple : créez un dossier et ouvrez-le dans VS Code. Créez un fichier index.html, c'est l'équivalent de la page de votre document. Il est totalement vide, alors commencez par lui donner un squelette en tapant ! puis Tab. Repérez les balises <body> et </body> : vous n'avez plus qu'à écrire entre les deux.

Là où vous auriez modifié les métadonnées de votre document pour en indiquer la langue, cherchez ici lang= tout en haut, juste après <html. Elle est souvent paramétrée en anglais (en) : adaptez-la (fr pour le français). Pour voir le résultat, enregistrez votre travail puis ouvrez votre fichier dans votre navigateur, en pensant à rafraîchir la page après chaque modification. Ou installez une extension de prévisualisation en direct, comme Live Preview (de Microsoft).

HTML vers PDF : quand c'est nécessaire

Une fois votre fichier HTML en main, vous pouvez l'exporter en PDF. Une fois encore, les outils ne sont pas tous précis, mais des pistes existent. Si vous ouvrez votre fichier dans Chrome, vous pouvez déjà exporter votre page en PDF balisé. C'est gratuit, et assez sympa pour être souligné. Si vous avez penché pour Pandoc plus haut, WeasyPrint inclut un support expérimental de PDF/A et PDF/UA depuis sa version 57, activable via l'option --pdf-variant=pdf/ua-1. C'est expérimental, mais gratuit, open source, et activable en une ligne de commande. Dans tous les cas, passez votre PDF dans un vérificateur comme PAC avant de l'envoyer.

Conclusion

Sans vous connaître, je sais que vous avez déjà tenu entre vos mains (virtuelles, peut-être) un document PDF. Je sais aussi, parce que vous me lisez, que vous avez déjà lu un document HTML. Je devine que le second est plus adapté à votre usage quotidien, et je devine aussi que le premier vous a déjà fait pester. J'ouvre donc la question : si nous utilisons le HTML tous les jours, s'il est plus pratique, robuste et accessible que les autres formats, et s'il pourrait nous permettre de créer des PDF de meilleure qualité… Qu'est-ce qui nous empêche de remettre la structure sémantique au début du processus, au lieu de l'improviser à la fin ?