Le premier éditeur de documents : un pari simple, mais risqué

Alors qu’ONLYOFFICE fête ses 16 ans en juillet, nous revenons sur les décisions qui ont façonné le produit. Celle-ci a été prise avant même le choix du nom, avant la licence open source et avant les 21 millions d’utilisateurs. Elle est le fruit d’une équipe suffisamment frustrée pour créer quelque chose que personne d’autre n’avait encore tenté.

Avant qu’il y ait un éditeur, il y avait un problème

En 2010 l’équipe d’Ascensio System SIA, qui travaillait alors sur une plateforme collaborative appelée TeamLab, avait besoin de permettre aux utilisateurs de travailler sur des documents au sein de son produit. La plateforme proposait des outils de gestion de projet, de CRM, un wiki, des blogs et un espace de partage de fichiers. Mais lorsqu’un utilisateur devait modifier un document Word, le processus était, pour le dire gentiment, peu élégant.

La première option d’édition de documents ajoutée était un cauchemar. Lorsque vous cliquiez sur Ouvrir le fichier, un fichier exe était téléchargé sur votre PC via OpenOffice avec un plugin préinstallé. Le document du portail était ouvert dans OpenOffice et, après modification, enregistré de nouveau dans le cloud.

C’est ainsi que l’édition de documents fonctionnait sur le web en 2010. Vous quittiez le navigateur. Vous ouvriez une application de bureau. Vous modifiiez. Vous sauvegardiez. Vous reveniez à ce que vous faisiez. Chaque étape était source de friction. Chaque étape constituait un point de défaillance potentiel : la mauvaise version, le mauvais format, l’envoi du mauvais document.

L’équipe détestait cela. Pas d’une manière légère et professionnelle, du genre « nous pourrions probablement améliorer cela », mais d’une manière viscérale, au quotidien, en se disant que c’était tout simplement absurde. Ils ont donc pris la décision qui définit une entreprise ou peut la faire échouer : écrire leur propre éditeur.

Le pari : HTML5 Canvas

En 2010, construire un éditeur de documents dans le navigateur n’était pas une chose raisonnable à faire. Google Docs avait été lancé en 2006 et était le point de référence évident, mais il fonctionnait en laissant le navigateur rendre le document en utilisant du HTML standard. Cela signifiait que la sortie imprimée avait une apparence différente de ce que vous voyiez à l’écran. Le formatage était rompu entre les navigateurs. Les mises en page complexes s’effondraient. Le web n’était tout simplement pas prêt à reproduire la précision d’un traitement de texte de bureau.

L’équipe d’ONLYOFFICE a choisi une approche fondamentalement différente. Au lieu de demander au navigateur de rendre le document, ils le rendraient eux-mêmes, en peignant chaque pixel directement à l’aide de l’élément HTML5 Canvas.

Le Canvas fait partie d’HTML5 et permet de rendre dynamiquement et de manière scriptable des formes 2D et des images bitmap. La technologie est connue pour préserver le formatage initial quel que soit le navigateur ou le système d’exploitation.

Les implications étaient significatives. Si vous peignez le document pixel par pixel, vous contrôlez exactement à quoi il ressemble, sur n’importe quel navigateur, sur n’importe quel système d’exploitation, qu’il soit affiché à l’écran, exporté au format PDF, ou envoyé à une imprimante. L’entrée est toujours identique à la sortie : un fichier traité conserve le même style, les mêmes paragraphes, symboles et interlignages. Le document que vous voyez est le document que vous obtenez.

Mais le risque technique était réel. HTML5 Canvas n’avait pas été conçu pour l’édition de documents. Personne n’avait fait cela auparavant. L’équipe n’adaptait pas une approche existante ; elle en construisait une. Si cela ne fonctionnait pas au niveau d’échelle et de performance requis pour une véritable suite bureautique, deux ans de travail d’ingénierie seraient perdus.

Fait intéressant : Canvas n’était pas la première tentative. Avant d’opter pour HTML5 Canvas, l’équipe avait essayé CKEditor, un éditeur de texte riche basé sur le navigateur et construit sur le rendu HTML standard. Cela avait échoué pour la même raison que l’approche de Google Docs était insuffisante : le HTML standard ne pouvait tout simplement pas délivrer la précision de formatage et la cohérence inter-navigateur requises par l’équipe.

L’ironie n’échappe pas à l’équipe : « Google et Microsoft ont finalement adopté la même technologie que celle que nous utilisons, peut-être après s’être inspirés de notre approche. » Qu’il s’agisse d’une coïncidence ou d’une convergence, l’industrie est finalement parvenue à la même conclusion que l’équipe d’ONLYOFFICE avait déjà tirée en 2010. Elle y était simplement arrivée avant les autres.

Fait intéressant : en mai 2021, près d’une décennie après les débuts d’ONLYOFFICE au CeBIT, Google a annoncé que Google Docs passerait d’un moteur de rendu basé sur HTML à un moteur basé sur Canvas, invoquant de meilleures performances et une plus grande cohérence entre les plateformes. L’approche sur laquelle ONLYOFFICE avait misé dès 2010 était devenue la norme du secteur, du moins pour l’un des deux principaux acteurs du marché.

CeBIT 2012 : la première apparition publique

En mars 2012, l’équipe a rendu son pari public. Au CeBIT à Hanovre, l’une des plus grandes foires commerciales de technologie au monde, TeamLab a présenté les premiers éditeurs de documents basés sur HTML5. La version bêta était disponible pour être testée à html5.teamlab.com.

TeamLab a apporté le tout premier éditeur de documents basé sur HTML5 au logiciel de bureau. Grâce à cette nouvelle technologie de pointe, TeamLab affichait les fichiers correctement dans n’importe quel navigateur, sur n’importe quel système d’exploitation, même lors de l’impression ou de l’importation. En outre, il propose des options puissantes pour le traitement des tableaux, l’interligne, la numération multilevel et les styles de texte et de titre.

Le produit, à ce stade, n’était qu’un éditeur de documents. Pas d’éditeur de classeurs, pas d’éditeur de présentation. Juste l’éditeur de texte, construit sur Canvas, démontrant que l’approche fonctionnait.

L’équipe comprenait également que la collaboration n’était pas une fonctionnalité bonus ; c’était le but même de construire un éditeur basé sur le navigateur en premier lieu. Un document qui apparaît identique sur tous les écrans n’est utile que si plusieurs personnes peuvent y travailler ensemble. Ils ont ajouté le mode de coédition stricte, où vous verrouillez la partie du document sur laquelle vous travaillez, et personne ne voit ce que vous tapez jusqu’à ce que vous cliquiez sur Enregistrer. Ce mode était conçu pour les équipes qui devaient travailler sur un document simultanément sans écraser les modifications des autres.

Le tableur qui a tout déclenché

C’est une étape particulière que la chronologie a généralement tendance à omettre. L’éditeur de documents obtient le titre, et le CeBIT 2012 est le lancement public officiel. Mais l’origine réelle des éditeurs d’ONLYOFFICE est plus étrange et moins linéaire que cela.

Le projet n’a pas commencé avec un éditeur de documents mais avec un éditeur de classeurs, et il n’utilisait pas encore Canvas. La version initiale calculait les formules sur le serveur, ce qui créait son propre ensemble de problèmes de performance. Avant même que l’éditeur de documents ne soit terminé, le projet fut complètement abandonné. Comme le rappelait Alex, responsable du développement : « C’était fini, nous ne travaillions plus dessus. »

Ce qui s’est passé ensuite est le genre de détail qui est souvent omis des histoires officielles. L’équipe continua de travailler discrètement en arrière-plan, corrigeant les bugs qui avaient conduit à l’abandon du projet. Finalement, ils relancèrent. Et ce n’est qu’alors que l’éditeur de documents apparut, le produit qui deviendrait le centre de tout ce qui suivrait.

Le pari sur Canvas était audacieux. Mais l’histoire qui l’entoure est faite d’un départ, d’une pause, d’une reprise discrète et d’un relancement dont la majeure partie de l’industrie n’a jamais eu connaissance. C’est la partie moins connue de l’histoire de la naissance des éditeurs d’ONLYOFFICE.

Lorsque les éditeurs ont été lancés pour la première fois, l’équipe marketing d’ONLYOFFICE utilisait une formule qui résumait mieux leur positionnement que n’importe quelle fiche technique : « Et si Google Docs et Microsoft Office avaient un enfant ? Il s’appellerait TeamLab. »

Cette formule résumait parfaitement ce que l’approche Canvas permettait réellement d’accomplir : associer la collaboration en ligne de Google Docs à la fidélité de mise en page de Microsoft Office. Aucune de ces approches, prise isolément, n’était suffisante. Le pari sur HTML5 Canvas consistait précisément à réunir le meilleur des deux mondes.

2013 : dire adieu aux formats propriétaires

Le pari sur Canvas était d’ordre technique. Celui de 2013 concernait la compatibilité et, à bien des égards, il était encore plus ambitieux.

À l’époque, ONLYOFFICE utilisait ses propres formats internes (.doct, .xlst, .pptt). En 2013, l’équipe les a complètement abandonnés pour adopter l’OOXML, le standard Open XML sur lequel reposent les formats DOCX, XLSX et PPTX.

Ce n’était pas le choix le plus simple. Adopter les formats de Microsoft signifiait en accepter toute la complexité : chaque particularité d’un document Word vieux de dix ans, chaque formule Excel obscure, chaque animation PowerPoint devait être prise en charge correctement, car les utilisateurs importeraient des fichiers créés dans Microsoft Office et s’attendraient à ce qu’ils s’ouvrent sans problème. L’alternative — demander aux utilisateurs de convertir leurs documents — était une impasse. Le monde fonctionne avec les formats DOCX et XLSX, et ONLYOFFICE devait être capable de travailler avec les fichiers que les utilisateurs possédaient déjà.

C’est cette décision qui a conduit TechCrunch à écrire, en janvier 2014, que TeamLab « prétend combiner le meilleur des fonctionnalités de collaboration en ligne de Google avec la haute qualité de mise en forme de Microsoft Word ». C’est aussi ce qui explique le titre affirmant que le produit « veut renvoyer Microsoft Office 365 à la planche à dessin ».

2014 : la décision de l’open source et le nouveau nom

À la mi-2014, l’équipe disposait d’une suite bureautique pleinement opérationnelle : des documents texte, des feuilles de calcul et des présentations fonctionnant directement dans le navigateur, compatibles avec les formats Microsoft Office et dotés d’une coédition en temps réel. Quatre années s’étaient écoulées depuis cette première décision, prise dans la frustration, de repartir de zéro.

En juillet 2014, TeamLab Office est devenu ONLYOFFICE, et son code source a été publié sur GitHub et SourceForge sous licence AGPLv3. Ce nouveau nom reflétait clairement l’ambition du projet : se consacrer entièrement à la bureautique. La publication du code source a transformé ce qui était jusque-là un pari technologique en un projet ouvert, transparent et vérifiable par tous.

Cette décision s’est également révélée, rétrospectivement, être le fondement de tout ce qui suivit. Les plus de 40 connecteurs d’intégration, les plugins Moodle, le connecteur Confluence et le serveur DocSpace MCP, tous trouvent leur origine dans le jour où le code est devenu public.

La réécriture du serveur dont personne ne parle

Le pari sur Canvas attire généralement toute l’attention. Pourtant, une seconde décision technique, prise à peu près à la même époque, s’est révélée tout aussi audacieuse à sa manière.

Lorsque l’équipe a commencé à développer l’édition collaborative dans le navigateur, un nouveau problème est apparu, souvent oublié lorsqu’on raconte l’histoire des éditeurs. Le Document Server d’origine reposait sur .NET, tout comme le reste de TeamLab. Or, pour un produit collaboratif fonctionnant dans le navigateur et nécessitant une coédition en temps réel, cette architecture montrait rapidement ses limites.

En 2014, l’équipe a donc pris une décision radicale : abandonner entièrement le serveur qu’elle développait depuis quatre ans et le réécrire intégralement en Node.js. À l’époque, cette technologie était encore rarement utilisée en production à grande échelle. Comme l’expliquait Alex, responsable du développement : « Choisir Node.js était presque aussi inhabituel que choisir Canvas. Personne ne faisait tourner des applications fortement sollicitées sur cette technologie. »

La réécriture a été réalisée par un seul ingénieur en l’espace de quatre mois. L’équipe travaillait alors avec les versions 0.10 et 0.12 de Node.js. Comme elle l’a elle-même résumé avec son sens habituel de l’autodérision : « Le zéro dans le numéro de version signifiait essentiellement : “N’attendez rien de vraiment sérieux, les gars.” »

Deux paris technologiques atypiques, pris la même année par une équipe qui avait perdu patience face aux solutions conventionnelles.

2016 : la coédition rapide et les éditeurs de bureau

Deux autres étapes importantes sont venues compléter ce premier chapitre de l’histoire des éditeurs.

Le mode de coédition rapide a été introduit en 2016 avec un objectif clair : rendre la collaboration documentaire véritablement fluide pour tous les utilisateurs. Alors que le mode strict verrouillait un paragraphe pendant sa modification et n’affichait les changements qu’au moment de l’enregistrement, le mode rapide permettait de voir les modifications en temps réel — le comportement que la plupart des utilisateurs associent aujourd’hui à l’édition collaborative de documents.

ONLYOFFICE proposait désormais les deux approches : un mode d’édition plus contrôlé et structuré, ainsi qu’un mode de collaboration en temps réel. Le choix dépendait des besoins et des méthodes de travail de chaque équipe, et non des limites de la technologie.

Également en mars 2016, les développeurs d’ONLYOFFICE ont lancé une application de bureau, ONLYOFFICE Desktop Editors, présentée comme une alternative open source à Microsoft Office. Le même éditeur basé sur HTML5 Canvas qui fonctionnait dans le navigateur était désormais disponible sous la forme d’une application de bureau pour Windows, Linux et macOS.

L’approche technique qui était née comme un pari exclusivement tourné vers le web démontrait désormais sa pertinence sur toutes les plateformes.

Mobile : le même éditeur, partout

L’application de bureau lancée en 2016 a permis à l’éditeur basé sur Canvas de dépasser le cadre du navigateur. Les applications mobiles ont ensuite étendu cette même expérience aux smartphones et aux tablettes, des appareils sur lesquels une part croissante du travail documentaire était désormais réalisée.

ONLYOFFICE Documents pour iOS et Android a apporté le même moteur d’édition aux smartphones et aux tablettes : édition complète des fichiers DOCX, XLSX et PPTX, coédition en temps réel, suivi des modifications et gestion des commentaires. Il ne s’agit pas d’un simple visualiseur doté de fonctions d’édition limitées, mais bien du même éditeur complet, adapté à une utilisation tactile.

La version 9.4, publiée en 2026, a introduit la prise en charge de l’IA Mistral sur mobile, un contrôle manuel de l’enregistrement des documents stockés dans le cloud, un onglet dédié aux formulaires dans l’éditeur de feuilles de calcul pour Android ainsi que l’insertion de plusieurs images à la fois sur iOS.

L’approche Canvas, née d’un pari technologique dans un navigateur en 2010, fonctionne désormais sur toutes les plateformes où les utilisateurs ont réellement besoin de travailler.

À quoi ressemblait réellement ce pari

Quatorze ans plus tard, il est facile de considérer le choix de HTML5 Canvas comme visionnaire. À l’époque, pourtant, il ressemblait davantage à un pari risqué fait par une équipe qui avait perdu patience face aux solutions existantes.

En 2010, les options étaient les suivantes : utiliser OpenOffice avec un plugin (une solution testée puis rapidement abandonnée), adopter une approche de rendu dans le navigateur comme Google Docs (avec des différences de comportement selon les navigateurs et des limites en matière de mise en page), ou développer une solution propriétaire nécessitant l’installation d’une application de bureau, ce qui allait à l’encontre de l’objectif d’une plateforme cloud. Aucune de ces options n’était satisfaisante. L’équipe a donc décidé d’en créer une quatrième, qui n’existait pas encore.

Le défi technique était bien réel. Le rendu basé sur Canvas est particulièrement exigeant en ressources. Le rendre suffisamment rapide pour permettre une véritable édition de documents — avec des tableaux complexes, des images intégrées, des formules et une coédition en temps réel — a nécessité un important travail d’ingénierie et d’optimisation qui s’est poursuivi pendant des années après la première démonstration au CeBIT.

ONLYOFFICE a ainsi développé une architecture assurant des échanges légers et en temps réel entre les participants, tout en limitant la charge côté serveur. Conçue pour permettre l’édition simultanée de documents sans créer de goulots d’étranglement, cette architecture constitue encore aujourd’hui le socle du système de coédition d’ONLYOFFICE.

D’un éditeur unique à une suite de sept outils

L’équipe qui présentait un unique éditeur de documents en version bêta au CeBIT 2012 propose aujourd’hui une suite coordonnée de sept outils au sein d’ONLYOFFICE Docs : un éditeur de documents, un éditeur de feuilles de calcul, un éditeur de présentations, un éditeur PDF, un créateur de formulaires, un visualiseur de diagrammes ainsi qu’un assistant IA intégré qui les accompagne tous.

Le produit a été conçu autour de Canvas, une technologie d’HTML5 permettant le rendu dynamique et programmable de formes 2D et d’images matricielles. Les formats natifs pris en charge par ONLYOFFICE Docs restent ceux de l’OOXML (DOCX, XLSX et PPTX). Cela n’a pas changé. L’approche de rendu choisie en 2010 est toujours au cœur de chaque document ouvert dans ONLYOFFICE aujourd’hui, quel que soit le navigateur, l’appareil utilisé ou la langue de l’interface parmi les 45 disponibles.

Le pari était simple : créer un éditeur capable d’afficher les documents exactement comme ils doivent apparaître, sur toutes les plateformes et dans toutes les situations. Le risque, lui, était bien réel : personne n’avait encore emprunté cette voie, et sa concrétisation a demandé des années de travail. Quatorze ans plus tard, un document conserve le même rendu, qu’il soit modifié dans un navigateur en France, sur un ordinateur au Japon, sur un smartphone au Kenya ou imprimé depuis un serveur installé dans le sous-sol d’un hôpital allemand.

L’éditeur PDF : un format qui n’avait jamais été conçu pour être modifié

L’une des évolutions les plus importantes issues du pari initial n’a pas consisté à créer un nouveau type d’éditeur, mais à transformer un format déjà existant.

Les fichiers PDF ont été conçus en 1993 pour être définitifs et figés. Ils représentaient l’aboutissement d’un document, et non une étape de son cycle de vie. Pendant des décennies, travailler avec un PDF signifiait le consulter, l’imprimer ou le convertir dans un autre format. Avec son éditeur PDF, ONLYOFFICE a directement remis en cause cette conception.

Aujourd’hui, l’éditeur PDF permet la modification directe du texte et des images sans conversion, l’annotation de documents avec des formes et des tampons, le masquage définitif des informations sensibles, les signatures numériques selon trois modes différents, les formulaires PDF remplissables avec des champs attribués selon les rôles, la gestion des pages avec réorganisation par glisser-déposer, la reconnaissance optique de caractères (OCR) pour les documents numérisés ainsi que l’annotation collaborative en temps réel.

Il ne s’agit pas d’un simple visualiseur auquel des fonctions d’édition auraient été ajoutées. C’est un véritable environnement d’édition conçu pour un format que l’industrie considérait depuis longtemps comme destiné à la seule consultation.

L’éditeur PDF est inclus dans ONLYOFFICE sans coût supplémentaire, sans licence Adobe distincte et sans abonnement additionnel. Cette décision reflète la même logique que le pari initial sur Canvas : lorsqu’un format de document existe, les utilisateurs doivent pouvoir travailler avec lui efficacement, dans le même environnement que celui qu’ils utilisent pour tous leurs autres documents.

Continuez à lire

Cet article est le deuxième post de notre série en 16 parties dédiée au 16ᵉ anniversaire d’ONLYOFFICE. Nous apprendrons encore plus sur les jalons clés, les décisions produit et les autres étapes qui ont façonné ONLYOFFICE. Jetons ensemble un coup d’œil en arrière.

Restez à l’écoute pour l’article trois !