ODF doit être reconnu pour ce qu’il a apporté : un format ouvert, documenté, normalisé, librement implémentable, qui a constitué une alternative essentielle aux formats bureautiques propriétaires. De ce point de vue, son importance politique, administrative et patrimoniale est réelle.
Mais cette reconnaissance ne doit pas empêcher une critique technique ferme. ODF n’est pas né comme une architecture documentaire conçue ex nihilo à partir des meilleurs standards spécialisés disponibles. Il est né de la standardisation progressive du modèle documentaire d’OpenOffice.org, lui-même issu de la lignée StarOffice. Ce fait historique n’invalide pas le standard, mais il en marque profondément la structure.
La conséquence est que ODF n’est pas simplement un format neutre de documents. C’est aussi la formalisation ouverte d’un modèle interne de suite bureautique. Cette origine se voit dans plusieurs domaines : le dessin vectoriel, les équations, les formules de tableur, les bases de données, les macros, les objets incorporés, le suivi des modifications et la mise en page.
La critique centrale peut donc être formulée ainsi :
ODF est un standard ouvert issu d’un logiciel réel ; ce n’est pas une architecture documentaire idéale issue d’une décomposition rigoureuse des standards existants. Sa valeur est politique et pratique, mais son héritage logiciel limite son optimalité technique.
Cette critique doit cependant être formulée de manière non partisane. Le problème n’est pas propre à ODF. Microsoft a procédé, avec OOXML, à une démarche comparable : transformer le modèle documentaire interne de sa propre suite bureautique en standard documentaire. La différence est que Microsoft a poussé beaucoup plus loin la logique de réimplémentation complète de son univers logiciel, avec une masse normative considérable et de nombreux comportements hérités, parfois explicitement liés à la compatibilité avec les anciennes versions de Microsoft Office. De ce point de vue, OOXML illustre une version encore plus problématique du même mécanisme.
ODF et OOXML partagent donc une limite commune : ce sont des formats de standardisation de suites bureautiques existantes. Mais ODF reste, relativement à OOXML, plus lisible, plus sobre, plus politiquement défendable et plus compatible avec l’idée d’un standard ouvert. La critique d’ODF ne doit donc pas être comprise comme une réhabilitation d’OOXML. Elle permet au contraire de poser une exigence plus haute : ni la standardisation de StarOffice/OpenOffice, ni celle de Microsoft Office, ne doivent être confondues avec la définition optimale d’un format documentaire universel.
1. Une origine logicielle, non une architecture documentaire idéale
ODF est historiquement issu du format XML d’OpenOffice.org, lui-même lié à StarOffice. Cela signifie que son point de départ n’est pas une décomposition abstraite des besoins documentaires modernes, mais la formalisation d’un modèle bureautique déjà existant.
Cela ne le rend pas illégitime. Au contraire, un standard utile doit souvent naître de pratiques réelles. Mais cela empêche de le considérer comme optimal au sens architectural. ODF hérite de choix internes, de compromis anciens, de structures pensées pour une suite bureautique précise, puis généralisées comme standard.
La difficulté est la suivante : un standard issu d’un logiciel peut être ouvert, documenté et utile, tout en restant conceptuellement dépendant du logiciel qui lui a donné naissance.
2. Le parallèle avec OOXML : même logique, aggravation par réimplémentation massive
La critique d’ODF doit éviter un piège : donner l’impression que le problème serait propre au logiciel libre, ou que Microsoft aurait proposé avec OOXML une alternative plus rigoureuse. C’est l’inverse.
OOXML procède lui aussi d’une standardisation rétrospective d’un modèle logiciel existant : celui de Microsoft Office. Comme ODF, il ne part pas d’une architecture documentaire neutre, construite domaine par domaine à partir des standards existants. Il encode l’histoire, les contraintes, les comportements et les compatibilités internes d’une suite bureautique dominante.
La différence est que OOXML pousse cette logique beaucoup plus loin. Là où ODF réutilise partiellement certains standards existants tout en les intégrant dans son propre modèle, OOXML tend à réimplémenter un univers complet : texte, styles, dessin, équations, tableurs, graphiques, compatibilités historiques, comportements de rendu et objets hérités. Le résultat est un standard extrêmement volumineux, difficile à implémenter complètement, et dont l’interopérabilité réelle dépend fortement de Microsoft Office lui-même.
OOXML montre donc, de manière encore plus nette qu’ODF, le danger de transformer le modèle interne d’un logiciel dominant en standard international. Le fait qu’un format soit normalisé ne suffit pas à en faire un bon format universel. Il peut rester la documentation monumentale d’un logiciel particulier.
Ce parallèle permet de positionner la critique d’ODF de façon équilibrée :
ODF n’est pas optimal, car il hérite fortement d’OpenOffice/StarOffice ;
OOXML est généralement pire du point de vue architectural, car il hérite encore plus massivement de Microsoft Office et de ses compatibilités historiques ;
la bonne exigence n’est donc pas de choisir un camp logiciel, mais de demander une architecture documentaire réellement modulaire, interopérable et alignée sur les standards spécialisés.
3. Dessin vectoriel : ODG n’est pas SVG
Le cas du dessin vectoriel est l’un des plus révélateurs. ODF Draw utilise son propre modèle de formes : rectangles, lignes, connecteurs, gradients, zones de texte, objets de dessin, etc. Il réemploie certains attributs ou concepts proches de SVG, mais il ne fait pas de SVG le modèle natif complet du dessin vectoriel.
Il y a donc une ambiguïté structurelle : ODF emprunte du vocabulaire SVG, mais sans reprendre toute la sémantique SVG. Cela rend les conversions ODG ↔ SVG ↔ PDF potentiellement non bijectives.
Le cas des gradients est emblématique. Si le modèle de gradient d’un dessin ODF ne correspond pas exactement au modèle SVG ou au modèle PDF, l’export doit choisir entre approximation, transformation ou rasterisation. Même lorsque le rendu écran paraît correct, le passage vers PDF peut perdre la structure vectorielle initiale.
Le problème n’est donc pas seulement qu’un logiciel particulier exporte parfois mal. Le problème plus profond est qu’ODF n’a pas fait de SVG ou de PDF un modèle géométrique canonique. Il a défini son propre modèle de dessin, ce qui rend la fidélité vectorielle dépendante de conversions partielles.
4. Équations : MathML est standard, mais LaTeX reste la langue scientifique de fait
Sur les équations, ODF ne s’est pas simplement inventé un langage isolé. Il s’appuie sur MathML, qui est un standard pertinent du point de vue XML, accessibilité et représentation structurée des mathématiques.
Mais cela ne répond pas complètement au besoin scientifique. Dans la pratique, LaTeX reste la langue dominante pour écrire, échanger, relire, versionner et publier des formules dans les communautés scientifiques.
La difficulté est donc la suivante :
MathML est pertinent comme représentation XML structurée ;
LaTeX est pertinent comme langage humain d’auteur ;
LibreOffice Math ajoute encore une couche avec sa propre syntaxe d’édition.
ODF a privilégié une représentation compatible avec l’univers XML bureautique, mais il n’a pas fait de LaTeX une source canonique ou un citoyen de première classe du format. Pour des usages scientifiques, cela crée une rupture entre le monde bureautique et le monde de la publication scientifique.
La critique n’est donc pas que MathML serait mauvais. La critique est qu’ODF ne s’aligne pas pleinement sur la pratique réelle des auteurs scientifiques.
5. Tableurs : OpenFormula comme correction tardive
Le cas des tableurs montre que l’ouverture syntaxique ne suffit pas. Un tableur n’est interopérable que si ses formules, ses types, ses erreurs, ses fonctions, ses arrondis et son modèle de recalcul sont précisément définis.
Les premières versions d’ODF ne spécifiaient pas suffisamment les formules de tableur. L’arrivée d’OpenFormula avec ODF 1.2 a constitué une amélioration importante, mais elle montre aussi que la sémantique calculatoire a été stabilisée après coup.
Cela illustre bien la limite d’un format issu d’une suite logicielle : le fichier peut être ouvert, lisible et structuré, sans que la reproductibilité complète du calcul soit immédiatement garantie.
Un document tableur n’est pas seulement un conteneur de cellules. C’est un programme de calcul implicite. Si ce programme n’est pas spécifié de manière exhaustive, l’interopérabilité reste partielle.
6. Base de données : .odb comme frontal bureautique, pas comme standard relationnel
Le cas de LibreOffice Base est encore plus net. Un fichier .odb est d’abord un frontal bureautique : il peut contenir des formulaires, requêtes, rapports, connexions, paramètres et éventuellement des données embarquées.
Mais ce n’est pas un standard universel de base de données. Il ne remplace ni SQL, ni un schéma relationnel portable, ni un format d’export robuste des données, contraintes, types, index et procédures.
Lorsque .odb embarque un moteur comme HSQLDB ou Firebird, il devient en pratique un paquet documentaire autour d’un moteur de base particulier. Lorsque .odb référence une base externe, il devient un fichier de connexion et de présentation.
Dans les deux cas, ODF standardise plutôt l’usage bureautique de la base de données qu’un modèle relationnel portable et indépendant.
7. Macros : le contenant est ouvert, le comportement ne l’est pas nécessairement
ODF peut contenir des scripts et des macros, mais il ne définit pas un environnement d’exécution commun équivalent entre suites bureautiques.
Un document peut donc être conforme, valide et ouvrable, tout en perdant une partie essentielle de son comportement. Or, dans beaucoup d’organisations, les documents ne sont pas seulement des pages : ce sont des outils, avec boutons, formulaires, automatisations, traitements de données et workflows.
La portabilité du fichier ne garantit donc pas la portabilité de l’usage.
C’est une limite fondamentale de tous les formats bureautiques actifs, y compris OOXML. Mais elle est d’autant plus problématique que le format prétend servir d’archive, d’échange et de support de travail interopérable.
8. Suivi des modifications et collaboration : un modèle hérité du document local
ODF a évolué pour améliorer le suivi des modifications, les commentaires et les capacités collaboratives. Mais cette évolution montre aussi que le modèle initial était davantage celui du document bureautique local que celui d’un document collaboratif moderne.
Les usages contemporains exigent :
une granularité fine des modifications ;
une fusion robuste ;
une représentation explicite des intentions d’édition ;
une bonne interopérabilité des commentaires, suggestions, validations et historiques ;
une compatibilité avec des workflows distribués.
ODF a ajouté des mécanismes pour répondre à ces besoins, mais il reste marqué par un modèle de document édité dans une suite bureautique classique.
Là encore, OOXML n’échappe pas à la critique. Il encode lui aussi un modèle collaboratif largement dépendant de Microsoft Office, de SharePoint, de OneDrive et de l’écosystème Microsoft. Mais cela ne rend pas ODF parfait : cela montre plutôt que les formats bureautiques traditionnels ont du mal à devenir des formats collaboratifs modernes.
9. Mise en page, ancrages, cadres et rendu exact
Un document bureautique n’est pas seulement une structure logique. C’est aussi un rendu : pagination, styles, ancrages, flottants, notes, tableaux, cadres, images, objets incorporés, index, champs dynamiques.
Ces éléments dépendent fortement du moteur de mise en page. Deux logiciels peuvent interpréter un même fichier ODF de manière légèrement différente tout en restant raisonnablement conformes.
Pour un format d’édition, cette variabilité est compréhensible. Pour un format d’échange ou d’archivage, elle devient problématique.
Un format optimal devrait distinguer plus clairement :
le document source éditable ;
le rendu figé ;
l’archive pérenne ;
le document collaboratif ;
le document calculatoire ou interactif.
ODF tente de couvrir tous ces usages dans un même modèle généraliste.
10. Paquet ZIP et objets incorporés : un conteneur ouvert peut cacher des îlots non portables
ODF repose sur un paquet ZIP structuré contenant des fichiers XML, des ressources, des images, des objets, des métadonnées et des sous-documents.
C’est une solution pratique et relativement transparente. Mais elle permet aussi d’embarquer des objets dont la sémantique n’est pas pleinement portable : images, objets OLE ou équivalents, binaires, scripts, ressources externes, représentations de secours.
Plus le conteneur accepte d’objets hétérogènes, plus il est capable de préserver un document réel. Mais moins il garantit que ce document sera interprétable de manière identique ailleurs.
C’est une tension classique : fidélité à l’usage réel contre pureté de l’interopérabilité.
11. Une architecture monolithique là où il aurait fallu des profils spécialisés
La faiblesse profonde d’ODF n’est pas tel ou tel défaut isolé. C’est son ambition monolithique.
ODF veut couvrir :
le texte ;
le dessin vectoriel ;
les présentations ;
les tableurs ;
les formules mathématiques ;
les bases de données ;
les styles ;
les métadonnées ;
les formulaires ;
les macros ;
le packaging ;
l’archivage ;
l’échange ;
l’édition.
Il y parvient en partie, mais au prix d’un modèle très vaste, hérité d’une suite bureautique complète.
Une architecture plus moderne aurait probablement distingué plusieurs profils stricts :
un profil texte proche d’un modèle sémantique clair ;
un profil vectoriel réellement SVG ;
un profil mathématique MathML avec source LaTeX associée ;
un profil tableur avec langage de formule strictement testé ;
un profil base de données fondé sur SQL standard et exports portables ;
un profil macro soit interdit, soit fondé sur un runtime standardisé ;
un profil archivage strict, proche d’un PDF/A enrichi ou d’un paquet documentaire figé.
ODF a fait un autre choix : standardiser l’univers d’une suite bureautique.
Ce choix était historiquement défendable. Mais il n’est pas architecturalement optimal.
La conclusion n’est pas que ODF serait un mauvais format. Ce serait injuste et techniquement excessif.
ODF est un bon format historique, ouvert et utile. Il a joué un rôle essentiel dans la défense de l’interopérabilité, de la souveraineté documentaire et de l’accès durable aux documents bureautiques.
Mais il ne faut pas confondre cette réussite avec une optimalité technique.
ODF reste le produit d’une époque où l’urgence était de libérer les documents bureautiques, non de reconstruire l’ensemble de l’écosystème documentaire autour de standards spécialisés, composables et bijectifs.
OOXML montre que le problème peut être encore pire lorsque la standardisation sert à documenter l’univers complet d’une suite propriétaire dominante. Mais cette comparaison ne doit pas conduire à exonérer ODF de toute critique. Elle permet simplement de clarifier le niveau d’exigence : le véritable enjeu n’est pas ODF contre OOXML, mais la différence entre standardiser un logiciel existant et concevoir une architecture documentaire réellement neutre.
ODF est probablement l’un des meilleurs compromis historiques disponibles contre les formats fermés, mais il reste un compromis. Sa défense politique ne doit pas empêcher une critique technique exigeante de son architecture.
# Critique bienveillante mais ferme d’ODF comme format bureautique
Posté par freejeff . En réponse à la dépêche ODF est l’avenir, OOXML le passé. Évalué à 9.
Sommaire
.odbcomme frontal bureautique, pas comme standard relationnelThèse générale
ODF doit être reconnu pour ce qu’il a apporté : un format ouvert, documenté, normalisé, librement implémentable, qui a constitué une alternative essentielle aux formats bureautiques propriétaires. De ce point de vue, son importance politique, administrative et patrimoniale est réelle.
Mais cette reconnaissance ne doit pas empêcher une critique technique ferme. ODF n’est pas né comme une architecture documentaire conçue ex nihilo à partir des meilleurs standards spécialisés disponibles. Il est né de la standardisation progressive du modèle documentaire d’OpenOffice.org, lui-même issu de la lignée StarOffice. Ce fait historique n’invalide pas le standard, mais il en marque profondément la structure.
La conséquence est que ODF n’est pas simplement un format neutre de documents. C’est aussi la formalisation ouverte d’un modèle interne de suite bureautique. Cette origine se voit dans plusieurs domaines : le dessin vectoriel, les équations, les formules de tableur, les bases de données, les macros, les objets incorporés, le suivi des modifications et la mise en page.
La critique centrale peut donc être formulée ainsi :
Cette critique doit cependant être formulée de manière non partisane. Le problème n’est pas propre à ODF. Microsoft a procédé, avec OOXML, à une démarche comparable : transformer le modèle documentaire interne de sa propre suite bureautique en standard documentaire. La différence est que Microsoft a poussé beaucoup plus loin la logique de réimplémentation complète de son univers logiciel, avec une masse normative considérable et de nombreux comportements hérités, parfois explicitement liés à la compatibilité avec les anciennes versions de Microsoft Office. De ce point de vue, OOXML illustre une version encore plus problématique du même mécanisme.
ODF et OOXML partagent donc une limite commune : ce sont des formats de standardisation de suites bureautiques existantes. Mais ODF reste, relativement à OOXML, plus lisible, plus sobre, plus politiquement défendable et plus compatible avec l’idée d’un standard ouvert. La critique d’ODF ne doit donc pas être comprise comme une réhabilitation d’OOXML. Elle permet au contraire de poser une exigence plus haute : ni la standardisation de StarOffice/OpenOffice, ni celle de Microsoft Office, ne doivent être confondues avec la définition optimale d’un format documentaire universel.
1. Une origine logicielle, non une architecture documentaire idéale
ODF est historiquement issu du format XML d’OpenOffice.org, lui-même lié à StarOffice. Cela signifie que son point de départ n’est pas une décomposition abstraite des besoins documentaires modernes, mais la formalisation d’un modèle bureautique déjà existant.
Cela ne le rend pas illégitime. Au contraire, un standard utile doit souvent naître de pratiques réelles. Mais cela empêche de le considérer comme optimal au sens architectural. ODF hérite de choix internes, de compromis anciens, de structures pensées pour une suite bureautique précise, puis généralisées comme standard.
La difficulté est la suivante : un standard issu d’un logiciel peut être ouvert, documenté et utile, tout en restant conceptuellement dépendant du logiciel qui lui a donné naissance.
2. Le parallèle avec OOXML : même logique, aggravation par réimplémentation massive
La critique d’ODF doit éviter un piège : donner l’impression que le problème serait propre au logiciel libre, ou que Microsoft aurait proposé avec OOXML une alternative plus rigoureuse. C’est l’inverse.
OOXML procède lui aussi d’une standardisation rétrospective d’un modèle logiciel existant : celui de Microsoft Office. Comme ODF, il ne part pas d’une architecture documentaire neutre, construite domaine par domaine à partir des standards existants. Il encode l’histoire, les contraintes, les comportements et les compatibilités internes d’une suite bureautique dominante.
La différence est que OOXML pousse cette logique beaucoup plus loin. Là où ODF réutilise partiellement certains standards existants tout en les intégrant dans son propre modèle, OOXML tend à réimplémenter un univers complet : texte, styles, dessin, équations, tableurs, graphiques, compatibilités historiques, comportements de rendu et objets hérités. Le résultat est un standard extrêmement volumineux, difficile à implémenter complètement, et dont l’interopérabilité réelle dépend fortement de Microsoft Office lui-même.
OOXML montre donc, de manière encore plus nette qu’ODF, le danger de transformer le modèle interne d’un logiciel dominant en standard international. Le fait qu’un format soit normalisé ne suffit pas à en faire un bon format universel. Il peut rester la documentation monumentale d’un logiciel particulier.
Ce parallèle permet de positionner la critique d’ODF de façon équilibrée :
3. Dessin vectoriel : ODG n’est pas SVG
Le cas du dessin vectoriel est l’un des plus révélateurs. ODF Draw utilise son propre modèle de formes : rectangles, lignes, connecteurs, gradients, zones de texte, objets de dessin, etc. Il réemploie certains attributs ou concepts proches de SVG, mais il ne fait pas de SVG le modèle natif complet du dessin vectoriel.
Il y a donc une ambiguïté structurelle : ODF emprunte du vocabulaire SVG, mais sans reprendre toute la sémantique SVG. Cela rend les conversions ODG ↔ SVG ↔ PDF potentiellement non bijectives.
Le cas des gradients est emblématique. Si le modèle de gradient d’un dessin ODF ne correspond pas exactement au modèle SVG ou au modèle PDF, l’export doit choisir entre approximation, transformation ou rasterisation. Même lorsque le rendu écran paraît correct, le passage vers PDF peut perdre la structure vectorielle initiale.
Le problème n’est donc pas seulement qu’un logiciel particulier exporte parfois mal. Le problème plus profond est qu’ODF n’a pas fait de SVG ou de PDF un modèle géométrique canonique. Il a défini son propre modèle de dessin, ce qui rend la fidélité vectorielle dépendante de conversions partielles.
4. Équations : MathML est standard, mais LaTeX reste la langue scientifique de fait
Sur les équations, ODF ne s’est pas simplement inventé un langage isolé. Il s’appuie sur MathML, qui est un standard pertinent du point de vue XML, accessibilité et représentation structurée des mathématiques.
Mais cela ne répond pas complètement au besoin scientifique. Dans la pratique, LaTeX reste la langue dominante pour écrire, échanger, relire, versionner et publier des formules dans les communautés scientifiques.
La difficulté est donc la suivante :
ODF a privilégié une représentation compatible avec l’univers XML bureautique, mais il n’a pas fait de LaTeX une source canonique ou un citoyen de première classe du format. Pour des usages scientifiques, cela crée une rupture entre le monde bureautique et le monde de la publication scientifique.
La critique n’est donc pas que MathML serait mauvais. La critique est qu’ODF ne s’aligne pas pleinement sur la pratique réelle des auteurs scientifiques.
5. Tableurs : OpenFormula comme correction tardive
Le cas des tableurs montre que l’ouverture syntaxique ne suffit pas. Un tableur n’est interopérable que si ses formules, ses types, ses erreurs, ses fonctions, ses arrondis et son modèle de recalcul sont précisément définis.
Les premières versions d’ODF ne spécifiaient pas suffisamment les formules de tableur. L’arrivée d’OpenFormula avec ODF 1.2 a constitué une amélioration importante, mais elle montre aussi que la sémantique calculatoire a été stabilisée après coup.
Cela illustre bien la limite d’un format issu d’une suite logicielle : le fichier peut être ouvert, lisible et structuré, sans que la reproductibilité complète du calcul soit immédiatement garantie.
Un document tableur n’est pas seulement un conteneur de cellules. C’est un programme de calcul implicite. Si ce programme n’est pas spécifié de manière exhaustive, l’interopérabilité reste partielle.
6. Base de données :
.odbcomme frontal bureautique, pas comme standard relationnelLe cas de LibreOffice Base est encore plus net. Un fichier
.odbest d’abord un frontal bureautique : il peut contenir des formulaires, requêtes, rapports, connexions, paramètres et éventuellement des données embarquées.Mais ce n’est pas un standard universel de base de données. Il ne remplace ni SQL, ni un schéma relationnel portable, ni un format d’export robuste des données, contraintes, types, index et procédures.
Lorsque
.odbembarque un moteur comme HSQLDB ou Firebird, il devient en pratique un paquet documentaire autour d’un moteur de base particulier. Lorsque.odbréférence une base externe, il devient un fichier de connexion et de présentation.Dans les deux cas, ODF standardise plutôt l’usage bureautique de la base de données qu’un modèle relationnel portable et indépendant.
7. Macros : le contenant est ouvert, le comportement ne l’est pas nécessairement
ODF peut contenir des scripts et des macros, mais il ne définit pas un environnement d’exécution commun équivalent entre suites bureautiques.
Un document peut donc être conforme, valide et ouvrable, tout en perdant une partie essentielle de son comportement. Or, dans beaucoup d’organisations, les documents ne sont pas seulement des pages : ce sont des outils, avec boutons, formulaires, automatisations, traitements de données et workflows.
La portabilité du fichier ne garantit donc pas la portabilité de l’usage.
C’est une limite fondamentale de tous les formats bureautiques actifs, y compris OOXML. Mais elle est d’autant plus problématique que le format prétend servir d’archive, d’échange et de support de travail interopérable.
8. Suivi des modifications et collaboration : un modèle hérité du document local
ODF a évolué pour améliorer le suivi des modifications, les commentaires et les capacités collaboratives. Mais cette évolution montre aussi que le modèle initial était davantage celui du document bureautique local que celui d’un document collaboratif moderne.
Les usages contemporains exigent :
ODF a ajouté des mécanismes pour répondre à ces besoins, mais il reste marqué par un modèle de document édité dans une suite bureautique classique.
Là encore, OOXML n’échappe pas à la critique. Il encode lui aussi un modèle collaboratif largement dépendant de Microsoft Office, de SharePoint, de OneDrive et de l’écosystème Microsoft. Mais cela ne rend pas ODF parfait : cela montre plutôt que les formats bureautiques traditionnels ont du mal à devenir des formats collaboratifs modernes.
9. Mise en page, ancrages, cadres et rendu exact
Un document bureautique n’est pas seulement une structure logique. C’est aussi un rendu : pagination, styles, ancrages, flottants, notes, tableaux, cadres, images, objets incorporés, index, champs dynamiques.
Ces éléments dépendent fortement du moteur de mise en page. Deux logiciels peuvent interpréter un même fichier ODF de manière légèrement différente tout en restant raisonnablement conformes.
Pour un format d’édition, cette variabilité est compréhensible. Pour un format d’échange ou d’archivage, elle devient problématique.
Un format optimal devrait distinguer plus clairement :
ODF tente de couvrir tous ces usages dans un même modèle généraliste.
10. Paquet ZIP et objets incorporés : un conteneur ouvert peut cacher des îlots non portables
ODF repose sur un paquet ZIP structuré contenant des fichiers XML, des ressources, des images, des objets, des métadonnées et des sous-documents.
C’est une solution pratique et relativement transparente. Mais elle permet aussi d’embarquer des objets dont la sémantique n’est pas pleinement portable : images, objets OLE ou équivalents, binaires, scripts, ressources externes, représentations de secours.
Plus le conteneur accepte d’objets hétérogènes, plus il est capable de préserver un document réel. Mais moins il garantit que ce document sera interprétable de manière identique ailleurs.
C’est une tension classique : fidélité à l’usage réel contre pureté de l’interopérabilité.
11. Une architecture monolithique là où il aurait fallu des profils spécialisés
La faiblesse profonde d’ODF n’est pas tel ou tel défaut isolé. C’est son ambition monolithique.
ODF veut couvrir :
Il y parvient en partie, mais au prix d’un modèle très vaste, hérité d’une suite bureautique complète.
Une architecture plus moderne aurait probablement distingué plusieurs profils stricts :
ODF a fait un autre choix : standardiser l’univers d’une suite bureautique.
Ce choix était historiquement défendable. Mais il n’est pas architecturalement optimal.
12. Conclusion : valeur historique, limite conceptuelle
La conclusion n’est pas que ODF serait un mauvais format. Ce serait injuste et techniquement excessif.
ODF est un bon format historique, ouvert et utile. Il a joué un rôle essentiel dans la défense de l’interopérabilité, de la souveraineté documentaire et de l’accès durable aux documents bureautiques.
Mais il ne faut pas confondre cette réussite avec une optimalité technique.
ODF reste le produit d’une époque où l’urgence était de libérer les documents bureautiques, non de reconstruire l’ensemble de l’écosystème documentaire autour de standards spécialisés, composables et bijectifs.
OOXML montre que le problème peut être encore pire lorsque la standardisation sert à documenter l’univers complet d’une suite propriétaire dominante. Mais cette comparaison ne doit pas conduire à exonérer ODF de toute critique. Elle permet simplement de clarifier le niveau d’exigence : le véritable enjeu n’est pas ODF contre OOXML, mais la différence entre standardiser un logiciel existant et concevoir une architecture documentaire réellement neutre.