URL: https://linuxfr.org/users/scls19fr/journaux/progressive-web-office-et-si-une-suite-bureautique-n-avait-tout-simplement-pas-besoin-de-serveur Title: Progressive Web Office : et si une suite bureautique n’avait tout simplement pas besoin de serveur ? Authors: s-celles Date: 2026-10-05T11:11:20+02:00 License: CC By-SA Tags: slop, bureautique, libreoffice, word, excel, access et powerpoint Score: -14 Salut Nal, Il y a quelque temps, un journal intitulé [Hexagone : une suite collaborative souveraine… pour quoi faire ?](https://linuxfr.org/users/space_e_man/journaux/hexagone-une-suite-collaborative-souveraine-pour-quoi-faire) avait suscité ici pas mal de discussions. Une remarque m'était particulièrement restée : on peut être sensible aux questions de maîtrise des données et continuer à utiliser Google Sheets ou Google Slides simplement parce que… ça marche bien. Et au fond, c'est difficile de répondre à ça. La plupart des utilisateurs ne choisissent pas leur traitement de texte parce que son architecture est souveraine, local-first, décentralisée ou conforme à tel principe. Ils veulent ouvrir leur document, le modifier, l'enregistrer et passer à autre chose. Je développe depuis quelque temps une autre expérimentation autour de cette question : **Progressive Web Office** (PWO) https://progressive-web-office.github.io/ Code source : https://github.com/progressive-web-office/progressive-web-office.github.io Le projet est libre, sous AGPL-3.0-or-later, et encore jeune, actuellement en 0.1.x. ## Encore une suite bureautique Web ? C'est justement la question que je me pose. Il existe déjà LibreOffice, Collabora, OnlyOffice, CryptPad, Microsoft 365, Google Workspace, etc. L'idée de Progressive Web Office n'est donc pas de prendre LibreOffice ou OnlyOffice, de les mettre derrière un nouveau portail, d'ajouter un stockage, un système de comptes et quelques services autour. L'approche est assez différente. **Il n'y a pas de serveur Progressive Web Office.** Le site distribue une application statique. Une fois chargée, le navigateur fait le travail. Quand j'ouvre un fichier `.odt`, `.docx`, `.ods`, `.xlsx`, `.odp`, `.pptx`, `.pdf`, Markdown, LaTeX ou autre, le document est lu et traité directement dans le navigateur. Pour modifier un document local, il n'est donc pas nécessaire de : * créer un compte ; * envoyer le fichier sur un serveur ; * installer un serveur chez soi ; * installer une application native. On ouvre la page, on ouvre le fichier, on travaille. L'application peut ensuite être installée comme PWA (Progressive Web App) et continuer à fonctionner hors connexion. Dit autrement, je vois moins Progressive Web Office comme une "suite bureautique en ligne" que comme une **application locale dont la plateforme d'exécution est le navigateur**. ## Et la "souveraineté" là-dedans ? Elle n'est finalement peut-être pas le bon argument. J'ai d'abord eu tendance à considérer comme essentiel le fait que les documents ne soient pas envoyés ailleurs. Techniquement, je continue à trouver cela très important. Mais je doute que quelqu'un se mette à utiliser PWO simplement pour cette raison. Le bénéfice utilisateur est peut-être beaucoup plus banal : > Je reçois un DOCX. Je l'ouvre dans mon navigateur. Je le modifie. Je l'enregistre. C'est tout. L'absence de backend devient alors une conséquence intéressante de l'architecture, pas forcément le slogan commercial. Et bien sûr, certaines fonctions ont besoin du réseau. Si l'utilisateur configure GitHub, GitLab, WebDAV, Nextcloud, Grist ou un fournisseur d'IA, l'application communique avec le service choisi. La différence est qu'il n'y a pas de backend PWO obligatoire au milieu. ## Formats ouverts, mais pas exclusivement Les nouveaux documents utilisent par défaut OpenDocument : ODT, ODS, ODP. Mais l'objectif n'est pas de vivre dans un monde où les DOCX/XLSX/PPTX n'existent pas. Ils sont donc aussi lus et écrits directement par l'application. C'est probablement l'un des morceaux les plus difficiles du projet. Et je préfère être clair : PWO est encore jeune et je ne prétends évidemment pas assurer aujourd'hui la fidélité de LibreOffice ou Microsoft Office sur tous les documents OOXML/ODF produits depuis vingt ans. C'est d'ailleurs l'une des raisons de ce journal : **je cherche des vrais documents qui cassent.** Un `rapport_final_v7_definitif_corrigé.docx` avec sections, tableaux, images mal ancrées et quelques bizarreries historiques m'intéresse davantage qu'un document de démonstration parfaitement propre. ## Pas uniquement Word + Excel + PowerPoint À force de développer le projet, une autre différence est apparue. Un document peut contenir des équations, des diagrammes Mermaid, mais aussi des **cellules de code Python ou JavaScript**. Elles s'exécutent localement dans un bac à sable sans accès réseau. Cela permet par exemple d'avoir : 1. des mesures dans un document ; 2. un calcul Python (numérique et/ou formel); 3. un graphique ; 4. le commentaire du résultat ; 5. les équations ; 6. puis d'exporter le tout en document bureautique ou en PDF. Python tourne avec Pyodide dans le navigateur. Les cellules peuvent aussi être réactives : une cellule dépend d'une autre, les dépendances forment un graphe et les résultats concernés peuvent être recalculés. Il existe également un support des widgets interactifs, notamment anywidget. À cet endroit, PWO commence donc à se situer quelque part entre la suite bureautique, le notebook et l'environnement scientifique léger. Je ne sais pas encore si c'est une excellente idée ou le début d'un gigantesque problème de périmètre :-) ## Et les fichiers restent des fichiers C'est un point auquel je tiens beaucoup. Je ne voudrais pas que PWO devienne un système où l'on "importe" ses données dans une base opaque propre à l'application. Un fichier Markdown doit rester un fichier Markdown. Un document ODT doit rester un ODT. Une base SQLite peut être ouverte comme un document et enregistrée de nouveau comme fichier SQLite. Un dossier de notes Markdown reste un dossier de fichiers Markdown. Le stockage du navigateur existe pour les brouillons, fichiers récents, préférences ou documents que l'utilisateur décide explicitement d'y placer, mais il ne doit pas devenir une prison à données. Cela rend aussi possible l'utilisation avec Git, WebDAV ou simplement le système de fichiers local. ## Collaboration sans transformer PWO en SaaS Il y a également de la collaboration temps réel entre navigateurs. Les navigateurs se découvrent puis échangent directement les modifications, avec Yjs et WebRTC. Je travaille aussi depuis quelque temps sur [QRShare](https://s-celles.github.io/QRShare/), intégré à PWO. Cela permet de transférer un document entre deux appareils en montrant une succession de QR codes à l'écran (fountain code). Pas de Wi-Fi, pas de Bluetooth, pas de câble. C'est probablement inutile pour la majorité des gens qui disposent d'AirDrop, de messagerie ou d'un stockage en ligne. En revanche, dans certains environnements isolés ou industriels, cela peut devenir intéressant. Je préfère donc le considérer comme une possibilité particulière plutôt que comme la raison d'utiliser PWO. ## Pourquoi une PWA ? Cette expérience m'a aussi amené à prendre le navigateur un peu plus au sérieux comme plateforme applicative. Aujourd'hui on y trouve notamment : * stockage local structuré ; * accès au système de fichiers sur certains navigateurs ; * WebAssembly ; * workers ; * WebRTC ; * WebAuthn/passkeys ; * service workers et fonctionnement hors connexion ; * accès caméra ; * presse-papiers ; * partage avec les autres applications ; * gestion de fichiers associée à une PWA. Une bonne partie de ce que j'aurais historiquement écrit comme application desktop peut donc fonctionner sans backend directement dans le navigateur. Cela a évidemment des limites et les différences entre Chromium, Firefox et Safari restent parfois sportives. Mais je trouve l'expérience intéressante. ## Et le périmètre commence justement à m'inquiéter Le projet sait maintenant traiter documents, tableurs, présentations, PDF, notes, fichiers source, bases SQLite… Il y a également des expérimentations autour du calendrier, des contacts, des coffres KDBX et d'autres fonctions. À ce rythme, on peut assez facilement réinventer Emacs, mais avec 300 Mo de JavaScript :-) C'est pourquoi je commence à réfléchir sérieusement à une séparation entre : * un **socle PWO** : fichiers, stockage, PWA, sécurité, commandes, synchronisation, sandbox ; * des modules bureautiques ; * des modules notes/connaissance ; * des outils développeur/scientifiques ; * éventuellement des extensions optionnelles. Une architecture de plugins fait partie des pistes de travail. ## Comment c'est fait ? Pour ceux que cela intéresse : * TypeScript ; * Vite ; * pas de gros framework UI ; * ProseMirror pour l'édition structurée ; * pdf.js pour les PDF ; * Pyodide pour Python ; * MathLive pour les équations ; * Mermaid pour les diagrammes ; * Yjs pour certaines fonctions collaboratives ; * tests unitaires avec Vitest ; * tests navigateur avec Playwright ; * spécifications écrites en EARS, avec des identifiants repris dans les tests. * développement avec l'aide d'IA (oui honte à moi ;-) ... je n'aurai pas eu le temps de développer cela seul) Tout le parsing et la sérialisation des documents sont faits côté client. Ce dernier point représente d'ailleurs une quantité de travail assez déraisonnable. ## Pourquoi j'en parle maintenant ? Pas parce que le logiciel est "terminé". Il ne l'est clairement pas. Et pas non plus parce que je pense avoir trouvé le remplaçant de LibreOffice, Microsoft Office ou Google Docs. Je commence plutôt à arriver au moment où développer seul dans son coin devient dangereux. Je peux ajouter des fonctionnalités que personne ne souhaite, tester uniquement mes propres documents et finir par optimiser une architecture pour des cas d'usage imaginaires. J'aimerais donc confronter le projet à autre chose. En particulier : * Est-ce que la proposition "j'ouvre simplement mon fichier dans le navigateur" vous semble avoir un intérêt ? * Qu'est-ce qui vous empêcherait réellement d'utiliser ce genre d'outil ? * Quels formats ou fonctions sont indispensables pour vos documents courants ? * Où trouvez-vous que PWO réinvente inutilement quelque chose qui existe déjà ? * Si vous lui donnez des documents réels, qu'est-ce qui casse ? Je suis particulièrement intéressé par cette dernière question. Le test est ici : https://progressive-web-office.github.io/ Et le code : https://github.com/progressive-web-office/progressive-web-office.github.io Les critiques, y compris les "ça existe déjà et en mieux ici", sont les bienvenues. C'est précisément le genre de retour qui m'intéresse à ce stade.