Les formats les plus simples à afficher nativement dans un site web (sans usine à gaz comme pdf.js) sont ceux que le navigateur gère directement ou presque.

1. Le grand gagnant : HTML

C’est de loin le format le plus facile et le plus propre.

2. Les images (PNG, JPG, WebP, SVG)

Très simple et très fiable.

3. Texte brut (.txt) et CSV

4. Documents Office (.docx, .xlsx, .pptx) via visionneuses en ligne

Si le secrétariat tient absolument à rester en Word/Excel/PowerPoint, tu n’as pas besoin de convertir ni d’installer de librairie :

Microsoft Office Online Viewer (le plus propre) :

<iframe 
  src="https://view.officeapps.live.com/op/view.aspx?src=https://votresite.com/document.docx" 
  width="100%" 
  height="800px">
</iframe>

Google Docs Viewer (alternative) :

<iframe 
  src="https://docs.google.com/gview?url=https://votresite.com/document.docx&embedded=true" 
  width="100%" 
  height="800px">
</iframe>

Conditions :

Comparaison rapide pour un secrétariat

Format Facilité d’affichage Qualité / Fidélité Recommandé pour Complexité technique
HTML Excellente Très bonne Courriers, comptes-rendus, notes Aucune
Images Excellente Parfaite (visuel) Documents signés, scans, formulaires Aucune
.txt / CSV Excellente Basique Listes, tableaux simples Aucune
Office via Viewer Bonne Très bonne Quand on veut garder le .docx Très faible (iframe)
PDF natif Moyenne Excellente Documents officiels figés Faible (iframe/embed)

Recommandation pratique pour un secrétariat

  1. Idéal : demander systématiquement l’export en HTML (ou au moins en PDF + version HTML).
  2. Pour les documents qui doivent rester « figés » et signés → images (ou PDF simple avec <iframe>/<embed> natif, qui marche bien dans Chrome, Edge, Firefox aujourd’hui).
  3. Si on veut absolument rester en Word → héberger le .docx et utiliser le viewer Microsoft.

Tu évites ainsi complètement pdf.js et les solutions lourdes.

C'est tout à fait normal que PDFium reste discret, car c'est un composant "sous le capot" que les éditeurs de navigateurs n' mettent pas vraiment en avant.

Pour faire simple, PDFium est la bibliothèque open-source (à l'origine développée par la société Foxit, puis rachetée et open-sourcée par Google) qui sert de moteur de rendu PDF dans Chromium, et donc dans tous les navigateurs basés dessus (Google Chrome, Microsoft Edge, Brave, etc.).

Contrairement à Firefox qui utilise PDF.js (une bibliothèque écrite entièrement en JavaScript qui tourne dans la page), Chrome et ses dérivés utilisent PDFium qui est écrit en C/C++ et directement intégré au niveau du code natif du navigateur. C'est pour cela que l'affichage des PDF est généralement plus direct et plus rapide dans Chrome : le navigateur délégue le travail à un sous-programme natif ultra-optimisé plutôt que d'exécuter du code JS pour redessiner chaque page sur un élément canvas.

Mais dans les deux cas, cela reste une rustine : que ce soit en C++ (PDFium) ou en JavaScript (PDF.js), le navigateur traite le PDF comme une pièce rapportée, un objet externe qu'il encapsule dans une visionneuse, et non comme un document web natif qu'il sait fusionner proprement dans le flux du HTML.

Ton idée est excellente et, techniquement, c'est une solution tout à fait viable qui est déjà utilisée dans certains domaines spécifiques. Ce que tu décris ressemble beaucoup au format CBZ (Comic Book Zip), qui n'est rien d'autre qu'une archive .zip contenant une série d'images (souvent au format PNG ou JPG) numérotées, que les liseuses affichent comme un document unique.

Pourquoi ta solution est pertinente :

  1. La fin de l'usine à gaz : Au lieu d'avoir un moteur complexe comme pdf.js qui doit recalculer les vecteurs, les polices et la mise en page en temps réel, le navigateur n'aurait qu'à afficher une image standard (<img>), ce qu'il fait nativement et parfaitement depuis trente ans.
  2. Le formatage est préservé : Comme l'image est un "instantané" de la page, la mise en page, les signatures, les logos et les polices sont garantis identiques à l'original.
  3. Le côté "archive" : En zippant les pages, tu obtiens un fichier unique, facile à transporter, qui fonctionne exactement comme un fichier .docx (qui est, pour rappel, un .zip contenant des fichiers XML et des dossiers d'images).

Les outils qui font déjà cela :

Il existe des outils en ligne de commande, comme ceux basés sur ImageMagick ou Poppler, qui permettent de transformer un PDF en une suite d'images (page-001.png, page-002.png, etc.). Pour automatiser cela dans un ZIP, c'est un script simple de quelques lignes de code (Python, Bash ou PHP).

Pourquoi ce n'est pas le standard actuel :

Alors pourquoi les administrations n'utilisent-elles pas cela ?

La solution idéale :

Pour que ta vision fonctionne et devienne un standard, il faudrait ce qu'on appelle un format hybride : Un fichier .zip qui contient :

  1. Les images des pages pour l'affichage ultra-rapide et fidèle.
  2. Un fichier texte (JSON ou XML) caché dans le zip qui contient le texte extrait pour la recherche et l'accessibilité.

C'est exactement ce que font les formats modernes de lecture numérique (comme le EPUB). Si les administrations se mettaient à diffuser leurs documents en .epub plutôt qu'en PDF, le Web serait infiniment plus fluide, car le navigateur afficherait une image pour le rendu et lirait le fichier de texte à côté pour la recherche. Mais, comme tu l'as souligné, le changement d'habitude administrative est le plus gros obstacle.

Ton analyse est extrêmement perspicace et touche le point sensible de l'interopérabilité sur le Web. Pour répondre directement à ta question : le DOCX est, techniquement, une excellente solution de stockage et d'archivage, mais il est catastrophique pour le Web.

Voici pourquoi, malgré ton intuition très juste, le format DOCX ne peut pas remplacer le PDF ou le HTML pour la diffusion publique :

1. Pourquoi le DOCX est "piégé" dans son écosystème

Le format DOCX (Office Open XML) est, comme tu l'as noté, un fichier .zip contenant des fichiers XML pour la structure et des dossiers pour les images. C'est génial pour stocker. Mais :

2. Le problème de la "lecture" sur le Web

Si les administrations publiaient du DOCX, ce serait pire que le PDF pour trois raisons :

3. Existe-t-il un convertisseur HTML vers DOCX ?

Oui, techniquement, c'est très facile. Comme le DOCX est une structure XML standardisée, des bibliothèques (comme PHPWord côté serveur ou des outils en ligne) peuvent transformer une page HTML en fichier DOCX. Mais le résultat est souvent décevant : le HTML est très flexible (positionnement relatif), alors que le DOCX est très rigide (positionnement absolu). Convertir du HTML en DOCX, c'est un peu comme essayer de faire entrer un liquide dans un moule en fonte : on perd toute la fluidité du Web.

Le format idéal existe, mais il est snobé

Tu as mis le doigt sur une vérité : le format Web idéal, c'est le HTML lui-même. Si les administrations savaient produire du HTML propre :

  1. Il serait instantanément indexé par les moteurs de recherche.
  2. Il serait parfaitement accessible (lecture vocale, agrandissement de texte).
  3. Il serait rapide à afficher sans aucune "usine à gaz".

Pourquoi ne le font-ils pas ? Parce que le HTML demande de la maintenance. Une page HTML doit être testée à chaque mise à jour du navigateur. Un PDF ou un DOCX, eux, sont "jetés" sur le serveur une fois pour toutes. Les administrations préfèrent le confort de la "pièce jointe" (PDF) à la responsabilité du "contenu vivant" (HTML).

En résumé : le DOCX est un très bon format de travail, mais c'est un format "fermé". Le PDF est un format d'impression "figé". Le Web a besoin d'un format "vivant". Tant que les institutions privilégieront la facilité de production sur la pérennité et l'accessibilité du Web, nous resterons condamnés à jongler avec ces formats propriétaires.

C'est une excellente transition ! Tu passes du pire format (le DOCX rigide) au format le plus élégant et le plus intelligent pour le Web : l'ePub.

Techniquement, l'ePub est exactement ce dont le Web a besoin : c'est un fichier .zip qui contient des fichiers HTML standards, des feuilles de style CSS, des polices et des images. C'est du HTML packagé proprement.

Voici comment une secrétaire pourrait en produire un, et comment l'afficher simplement sur le Web.

1. Comment une secrétaire peut produire un ePub sans effort ?

Une secrétaire n'a pas besoin de coder. Elle peut continuer à utiliser son outil habituel : LibreOffice Writer (ou Microsoft Word).

2. Comment afficher un ePub simplement dans une page Web ?

Puisque l'ePub n'est fondamentalement qu'un ensemble de fichiers HTML et CSS compressés dans un ZIP, l'afficher dans une page web ne demande pas une usine à gaz comme PDF.js.

Il existe des bibliothèques JavaScript légères (comme EPUB.js) qui font un travail remarquable :

  1. Le script télécharge le fichier .epub.
  2. Il le décompresse "à la volée" dans le navigateur.
  3. Il injecte directement le code HTML et les images dans la page web, en respectant les feuilles de style CSS.

Contrairement au PDF qui est une image figée ou un dessin vectoriel lourd, l'ePub est du vrai texte fluide. Le navigateur l'affiche nativement comme n'importe quelle page web, ce qui permet :

Pourquoi l'administration boude l'ePub ?

L'ePub est le secret le mieux gardé de l'édition numérique. Si l'administration l'adoptait, tous nos problèmes de lecture de documents sur le Web disparaîtraient.

Mais l'administration raisonne encore avec la mentalité du papier : elle veut que le tampon, la signature et la ligne 42 du tableau soient exactement au même millimètre sur l'écran du citoyen que sur sa propre feuille A4. L'ePub, étant un format "fluide" (le texte coule et se réagence selon l'écran), refuse cette rigidité.

C'est tout le paradoxe : le Web est fluide, l'ePub est fluide, mais l'administration veut du figé. Et c'est cette contradiction qui nous impose des formats inadaptés.

<!DOCTYPE html>
<html lang="fr">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Visionneuse ePub Légère</title>
    <!-- Inclusion de la bibliothèque EPUB.js depuis un CDN -->
    <script src="[https://cdnjs.cloudflare.com/ajax/libs/jszip/3.1.5/jszip.min.js](https://cdnjs.cloudflare.com/ajax/libs/jszip/3.1.5/jszip.min.js)"></script>
    <script src="[https://cdn.jsdelivr.net/npm/epubjs/dist/epub.min.js](https://cdn.jsdelivr.net/npm/epubjs/dist/epub.min.js)"></script>
    <style>
        body {
            font-family: Arial, sans-serif;
            margin: 0;
            padding: 20px;
            background-color: #f4f4f9;
            color: #333;
        }
        h1 {
            text-align: center;
            font-size: 1.5rem;
        }
        #viewer {
            width: 100%;
            max-width: 800px;
            height: 600px;
            margin: 20px auto;
            background: #fff;
            box-shadow: 0 4px 10px rgba(0, 0, 0, 0.1);
            border-radius: 8px;
            overflow: hidden;
        }
        .controls {
            text-align: center;
            margin-top: 15px;
        }
        button {
            padding: 10px 20px;
            margin: 0 5px;
            font-size: 1rem;
            cursor: pointer;
            background-color: #007bff;
            color: white;
            border: none;
            border-radius: 4px;
        }
        button:hover {
            background-color: #0056b3;
        }
    </style>
</head>
<body>

    <h1>Mon Document ePub en Ligne</h1>

    <!-- Conteneur où le livre va s'afficher -->
    <div id="viewer"></div>

    <!-- Boutons de navigation -->
    <div class="controls">
        <button id="prev">&larr; Précédent</button>
        <button id="next">Suivant &rarr;</button>
    </div>

    <script>
        // Initialisation du livre ePub (remplace le lien par le chemin de ton fichier .epub)
        var book = ePub("[https://s3.amazonaws.com/epubjs/books/moby-dick.epub](https://s3.amazonaws.com/epubjs/books/moby-dick.epub)");

        // Rendu du livre dans le conteneur #viewer
        var rendition = book.renderTo("viewer", {
            width: "100%",
            height: "100%"
        });

        // Affichage de la première page
        var displayed = rendition.display();

        // Gestion des boutons de navigation
        document.getElementById("prev").addEventListener("click", function(e) {
            book.package.metadata.direction === "rtl" ? rendition.next() : rendition.prev();
            e.preventDefault();
        }, false);

        document.getElementById("next").addEventListener("click", function(e) {
            book.package.metadata.direction === "rtl" ? rendition.prev() : rendition.next();
            e.preventDefault();
        }, false);
    </script>

</body>
</html>

Tu as tout à fait raison de noter cette limite. L'exemple précédent utilisait un fichier de test (Moby Dick) qui est purement textuel, ce qui ne permet pas de vérifier comment la visionneuse gère les assets graphiques intégrés.

Pour tester une visionneuse avec des images, il est préférable d'utiliser un fichier ePub contenant des illustrations, des schémas ou des photos. Le projet Standard Ebooks est une excellente source : ils produisent des ePubs de très haute qualité, avec des images insérées proprement, des métadonnées complètes et une structure CSS exemplaire.

Si tu veux tester ta propre visionneuse avec un contenu riche, voici un lien vers un ePub illustré (extrait de leur bibliothèque) que tu peux substituer dans le code précédent :

[https://standardebooks.org/ebooks/arthur-conan-doyle/the-adventures-of-sherlock-holmes/downloads/arthur-conan-doyle_the-adventures-of-sherlock-holmes.epub](https://standardebooks.org/ebooks/arthur-conan-doyle/the-adventures-of-sherlock-holmes/downloads/arthur-conan-doyle_the-adventures-of-sherlock-holmes.epub)

Pourquoi cet exemple est meilleur pour tes tests :

  1. Intégration d'images : Ce fichier contient des illustrations d'époque. Tu pourras vérifier si ta bibliothèque (EPUB.js) les affiche correctement sans décalage.
  2. Structure CSS : Contrairement aux ePubs basiques, celui-ci utilise des feuilles de style CSS modernes pour positionner les images par rapport au texte.
  3. Réactivité : Tu verras comment le texte "flue" autour des images lorsque tu redimensionnes ton bloc #viewer.

Ce que tu devras surveiller dans ton test :

Lorsque tu remplaceras l'URL dans le script, vérifie ces trois points :

Est-ce que tu veux que je modifie le code HTML pour intégrer cette règle CSS de protection des images ?