World-Office : des progrès guidés par la conformité pour une suite bureautique indépendante
Les documents bureautiques constituent le problème d'interopérabilité le plus difficile d'un espace de travail numérique souverain. Le courrier, les fichiers et le clavardage ont des réponses open source matures ; la pile bureautique (éditer docx, xlsx et pptx de façon fiable dans le navigateur) reste l'endroit où les projets de souveraineté trébuchent. World-Office est la tentative d'openEduSuite de combler cet écart : une suite bureautique indépendante écrite en Rust, dont les progrès se mesurent à des tests de conformité plutôt qu'à des affirmations.
Du prototype à la production
Le projet a commencé par un prototype de serveur qui prouvait le concept, pas le niveau d'exigence d'ingénierie. Cette première implémentation a été retirée en septembre 2026. Le serveur documentaire de production est aujourd'hui une base de code Rust native (un moteur de rendu docx et ses propres crates de traitement OOXML) au service des éditeurs de la suite, avec WOPI comme contrat d'intégration avec OpenCloud : les fichiers s'ouvrent et s'enregistrent directement depuis le stockage en nuage dans lequel les utilisateurs travaillent déjà.
L'état actuel, en un coup d'œil :
| Composant | État |
|---|---|
Éditeur de documents (docx) |
En production |
Éditeur de tableur (xlsx) |
Migré vers la pile de production |
Éditeur de diapositives (pptx) |
Migré vers la pile de production |
| Export PDF | Implémentation native |
| Intégration au serveur de collaboration | WOPI avec OpenCloud |
Mesuré, pas affirmé
La règle déterminante du projet : aucune fonctionnalité n'est réputée terminée tant qu'un test automatisé ne compare pas sa sortie à une référence (oracle). Trois mécanismes portent cette règle :
Un registre de fonctionnalités à identifiants stables. Chaque comportement requis figure dans un registre versionné d'identifiants de fonctionnalités, et un garde-fou de dérive fait échouer l'IC quand le code produit et le registre divergent. Le registre suit actuellement un ensemble stable de fonctionnalités du format document.
Conformité inter-moteurs. La sortie du moteur de rendu est normalisée dans une représentation intermédiaire et notée par rapport à des rendus de référence. Sur les documents simples, la fidélité géométrique du texte atteint 1,0 par rapport au rendu de référence ; sur les documents riches en tableaux, elle avoisine 0,85, un chiffre honnête qui dit exactement où subsiste le travail de mise en page. Les portes pixel visuelles utilisent des lignes de base publiées plutôt que des seuils de vanité ; la porte en-têtes-et-pieds-de-page affiche par exemple son point de départ à 17,2 pour cent et se resserre à partir de là.
Un oracle différentiel de formules pour le tableur. Une suite croissante de cas de tableur compare le moteur de formules de World-Office à une implémentation de référence. La première base de 30 cas donne 8 sur 30 ; la base existe précisément pour rendre chaque amélioration visible, avec environ 450 fonctions de tableur sur la feuille de route.
Un périmètre tranché
Reconstruire une suite bureautique exige des limites autant que du code. Les décisions de périmètre prises à ce jour :
- Formats : OOXML (
docx,xlsx,pptx) et ODF (odt,ods,odp), les deux grandes familles de formats. - Référence de parité : l'interface web d'OnlyOffice® sert de cible de compatibilité visuelle et comportementale ; LibreOffice® reste un contre-vérification secondaire d'interopérabilité des formats.
- Hors périmètre : formats hérités exotiques et formats de diagrammes. La pile de fichiers environnante route déjà correctement ces fichiers, y compris une correction de type MIME qui a rendu les dessins Visio à nouveau fiables à l'ouverture.
Leçons d'une construction en ouvert
Trois leçons qui méritent d'être transmises :
- L'automatisation a besoin de garde-fous. Une tâche d'automatisation planifiée a une fois effacé du travail non validé sur le serveur de développement. Le travail a été récupéré en rejouant les transcriptions de session, et la tâche a été réparée. Les agents et minuteries qui touchent un dépôt ne doivent jamais pouvoir détruire un état non validé.
- L'infrastructure de test vit à part du code produit. Le harnais de conformité, le registre et les corpus vivent dans leur propre dépôt, afin que les crates de production restent propres et que le registre se versionne indépendamment.
- Des lignes de base honnêtes battent les métriques de vanité. Publier un 8/30 ou un 17,2 pour cent met mal à l'aise, et c'est exactement pourquoi cela fonctionne : le progrès devient un cliquet, pas une ligne marketing.
La suite
- Couverture des formules du tableur : grimper l'oracle différentiel vers l'ensemble complet des fonctions.
- Profondeur ODF : amener
odt,odsetodpau même standard de conformité qu'OOXML. - Conformité du tableur et des présentations : étendre le schéma registre-et-oracle au-delà des documents.
Appel à l'action
- Suivre le travail : la méthodologie de conformité et la conception du harnais sont documentées dans le dépôt du projet.
- Tester avec nous : les documents réels sont le corpus le plus instructif ; les fichiers cassés apprennent le plus à un moteur de rendu.
- Participer : rejoignez la communauté openEduSuite si la souveraineté documentaire figure à votre ordre du jour.
La souveraineté se gagne ou se perd sur les documents ; alors nous mesurons, au lieu de promettre.
Avis de marque : OnlyOffice® est une marque déposée d'Ascensio System SIA. LibreOffice® est une marque déposée de The Document Foundation. World-Office est un projet indépendant, sans affiliation ni approbation ni parrainage de ces parties. Tous les autres noms de produits sont des marques de leurs propriétaires respectifs.
