L'article me semble très apologétique avec plusieurs traits d'autosatisfaction, l'analyse est légère. C'est dommage et j'aimerai bien lire l'analyse d'une personne neutre avec de l'expérience en outils de bureautique. Ou l'analyse de l'équipe OnlyOffice.
En effet, je veux bien qu'un format soit volontairement obscurci, pourquoi pas vu l'enjeu financier? mais qu'on nous montre aussi lequel des formats est le plus solide, le plus résilient, le moins sensible aux accidents de stockage, le plus rapide à ouvrir et afficher, … mon expérience perso parie pour OpenDocument et LibreOffice, mais sur des parcs importants et des conditions différentes je n'en szis rien.
Je vois pas en quoi plus de fichiers XML apporterait une quelconque robustesse supplémentaire. Concernant la vitesse d'ouverture ce n'est pas vraiment comparable puisque qu'il n'y a pas que ça qui rentre en jeu.
Un fichier xml par diapo, avec les styles associés, ça peut-être plus costaud qu'un seul fichier pour toutes les diapos. De même, l'analyse ou l'enregistrement diapo par diapo a pu être privilégiée à cause de la conception même de MsOffice dont le code est très ancien — à moins que Microsoft ait tout réécrit, il doit trainer des archaïsmes.
Je critique l'article, je ne défend pas le format OOXML, mais ce format mérite un débat contradictoire et une analyse plus poussée.
Parce que, dès le tout premier de la série je lis des affirmations sans références, affirmations qui servent ensuite à "prouver" l'inanité du format OOXML et la volonté de nuire de Ms.
mais ça va pas ? et c'est quoi ce procédé qui consiste à faire un procès d'intention ?
j'ai cité en raccourci parce que je tape dans des conditions inconfortables et pour indiquer à laquelle de tes 2 phrases je répondais. tu as bien écris "tu sous entend qu'il est incompétent"?
Tu sous-entends quand même qu'il n'est pas compétent.
je n'ai rien lu de tel dans ses propos, tu sur-interprètes.
Cependant en lisant les notes bas de page de l'article on peut quand même se poser des questions sur la profondeur de l'analyse de l'auteur.
Il se plaint que certains noms dans le code XML soient en italien alors que son système et son navigateur sont en anglais.
Oui c'est très étrange d'autant plus que l'auteur Italo Vignoli, je ne parierai pas qu'il soit allemand 😁
Bon c'est quand même une coïncidence troublante et il aurait du vérifier si le problème était reproductible et tester avec d'autres utilisateurs dans d'autres langues.
3.In some cases, the XML tags are incomprehensible and contain serious errors. For instance, in the case of green fill colours, the tag is <a:srgbClr val=”00FF00″>, which clearly references the RGB colour model despite the value being hexadecimal
À la première lecture je ne comprends ni son incompréhension ni où est l'erreur.
Et la spécification sur ce point qu'il n'y a aucune erreur et pas lieu de s'étonner.
Je suis a peu près persuadée de la supériorité d'ODF sur OOXML et que ce dernier est probablement inutilement alambiqué.
Cependant cette série d’articles ne démontre rien, elle ne fait que montrer et affirmer. Avec du code XML in extenso, ce qui est particulièrement indigeste car l'œil humain un très mauvais analyseur syntaxique du XML, surtout en vrac, non indenté.
En vrai on s’en fout de sa nationalité et de celle de son système :) C’est un vrai problème quand quand on utilise des mélanges d’idiomes pour du balisage et surtout quand on prétend faire du XML normalisé. D’où l’incompréhension. Imagine le casse tête si, pour ta page web, le balisage pouvait être aussi bien <bold> que <gras> et plein d’autres idiomes ? Même pour µS qui a normalement toutes les cartes en main, le code sera difficile à maintenir et faire évoluer àmha.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Ah oui, au temps pour moi, il s’agissait de valeur d’attribut…
Je crois que ça vient de ce que le logiciel se mélange les pinceaux dans la gestion des langues ? J’ai vu ça récemment avec un collègue dont le correcteur orthographique voit des passages en français et d’autres en allemand le tout en partant d’un modèle qui serait en anglais à ce qu’il m’a dit.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Merci pour le lien !
En expliquant d'où vient la complexité des formats binaires de Ms Office (l'histoire, la rétrocompatibilité et la puissance des outils), l'article permet de mieux expliquer la complexité des formats OOXML. Avis à la populaschtroumpf ! c'est infiniment plus explicatif et enrichissant que les articles sur OOXML.
L'article est intéressant, mais il parle des formats avant OOXML et qui datent effectivement d'une époque où la mémoire disponible se comptait en kilooctets.
Quand le format ODF a été créé, c'était une époque où les fichiers s'échangeaient déjà beaucoup grâce à Internet et où le Web était déjà bien présent et avait montré l'importance de l'interopérabilité entre les machines, les versions des logiciels et des normes…
Dans ce cadre, et du part le fait que ODF allait être une norme ISO, pourquoi Microsoft n'a pas fait attention à rendre son format de fichier interopérable correctement avec une spécification de taille raisonnable et implémentable ?
Les ordinateurs étaient déjà bien plus puissant, l'argument de la vitesse de chargement et de sauvegarde ne tenait pas la route. L'échange de fichiers étaient commun et l'interopérabilité entre les différentes versions d'Office lui-même posait déjà probléme.
Microsoft devait casser la compatibilité ascendante de toute façon avec ce nouveau format, il n'y avait pas de raison de rester compatible avec l'ancien…
Du coup, j'ai trouvé l'article sur le format des spreadsheets intéressant dans qu'il montre que, concrètement, le format ODF semble plus simple à interpréter que OOXML.
Dans ce cadre, et du part le fait que ODF allait être une norme ISO, pourquoi Microsoft n'a pas fait attention à rendre son format de fichier interopérable correctement avec une spécification de taille raisonnable et implémentable ?
Souvent, quand je regarde ce que fait cette entreprise, excepté son premier BASIC peut-être, j’ai l’impression que ce sont des français/shadocks/etc. : pourquoi faire simple quand on peut faire compliqué ?
Les ordinateurs étaient déjà bien plus puissant, l'argument de la vitesse de chargement et de sauvegarde ne tenait pas la route.
Même sur ce point, le constat est que leurs produits consomment plus de mémoire et veulent toujours plus de vitesse processeur, à avec cela vous n’avez pas de garantie que ça ne vous chie pas dans la colle à un moment.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Faut pas déconner, j'ai déjà travaillé sur d'énormes fichiers word avec plusieurs milliers de pages, des graphismes, des feuilles de calcul intégrées… ça se manipulait sans problème, sans lenteur perceptible, et l'enregistrement sur des disques durs à 2500 tours durait le temps de le dire.
Encore aujourd'hui LibreOffice sous Linux avec SSD et plein de Ram est plus lent sur des documents plus petits.
Word a des défauts, on peut critiquer plein de choses chez Microsoft, mais raconter n'importe quoi juste pour dénigrer ne sert pas la cause du logiciel libre.
Posté par raphj (site web personnel) .
Évalué à 6 (+4/-0).
Dernière modification le 13 octobre 2025 à 17:43.
Complexité volontaire de la part de MS ? Pas sûr. Probablement pas directement. Ça ressemble plutôt à une dette technique monumentale avec aucun effort pour simplifier les choses. Je croirais plutôt à une absence de volonté de simplifier, voire à une volonté de ne pas simplifier, combinée à un haut niveau de désintérêt pour une conception élégante, potentiellement combinée à un peu d'incompétence ou de complexité liée à l'organisation du travail au sein de MS.
Par contre, et aussi par conséquent, un tel merdier n'aurait jamais dû s'appeler "open" et devenir une norme / un standard, surtout quand il y avait une norme déjà existante pour faire la même chose. Si on cherche de la malice, je pense que c'est plutôt de ce côté qu'il faudrait s'attarder et le message serait plus fort.
Un processus de normalisation sain, ça marche rarement comme ça : « Wouala, 10 000 pages écrites unilatéralement, basées sur notre dette technique ! Au fait, il y a des parties protégées par des brevets, et aussi spécifiques à notre implémentation - elles sont "optionnelles", mais bon si elles ne sont pas implémentées ça ne marchera pas. Ah, et au fait, on ne l'implémente pas nous-même, personne ne le fait pour le moment ! Allez, bonne lecture ! Et ne vous inquiétez pas, hein, on "coopérera" avec les gens un peu contre la normalisation, et avec les potentielles investigations. »
En revanche, que ça soit lié à une énorme dette technique, ça ne fait absolument pas l'ombre d'un doute et il a dû falloir pas mal de bricolage pour y arriver. Une volonté de simplification, notamment pour le traitement de texte l'aurait grandement modifié au risque de faire perdre pas mal de clients.
Il y a certainement de la complexité de l'UI qui transpire dans le format, mais je pense que le format aurait pu être grandement simplifié déjà sans (trop) toucher l'UI.
Je ne pense pas que ça aurait fait perdre des client·e·s : ça aurait été transparent pour elles et eux.
Par contre, ça aurait probablement coûté (beaucoup) de fric.
# À compléter par
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 10 (+9/-0).
Je ne me souviens pas les avoir vu passer (en tout cas, pas tous). Donc la série :
Plus :
Je n’ai aucun avis sur systemd
[^] # Re: À compléter par
Posté par orfenor . Évalué à 6 (+5/-1).
L'article me semble très apologétique avec plusieurs traits d'autosatisfaction, l'analyse est légère. C'est dommage et j'aimerai bien lire l'analyse d'une personne neutre avec de l'expérience en outils de bureautique. Ou l'analyse de l'équipe OnlyOffice.
En effet, je veux bien qu'un format soit volontairement obscurci, pourquoi pas vu l'enjeu financier? mais qu'on nous montre aussi lequel des formats est le plus solide, le plus résilient, le moins sensible aux accidents de stockage, le plus rapide à ouvrir et afficher, … mon expérience perso parie pour OpenDocument et LibreOffice, mais sur des parcs importants et des conditions différentes je n'en szis rien.
[^] # Re: À compléter par
Posté par ff9097 . Évalué à 4 (+2/-0).
Je vois pas en quoi plus de fichiers XML apporterait une quelconque robustesse supplémentaire. Concernant la vitesse d'ouverture ce n'est pas vraiment comparable puisque qu'il n'y a pas que ça qui rentre en jeu.
[^] # Re: À compléter par
Posté par orfenor . Évalué à 6 (+5/-1).
Un fichier xml par diapo, avec les styles associés, ça peut-être plus costaud qu'un seul fichier pour toutes les diapos. De même, l'analyse ou l'enregistrement diapo par diapo a pu être privilégiée à cause de la conception même de MsOffice dont le code est très ancien — à moins que Microsoft ait tout réécrit, il doit trainer des archaïsmes.
Je critique l'article, je ne défend pas le format OOXML, mais ce format mérite un débat contradictoire et une analyse plus poussée.
[^] # Re: À compléter par
Posté par orfenor . Évalué à 3 (+2/-1).
Parce que, dès le tout premier de la série je lis des affirmations sans références, affirmations qui servent ensuite à "prouver" l'inanité du format OOXML et la volonté de nuire de Ms.
[^] # Re: À compléter par
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 3 (+1/-1). Dernière modification le 11 octobre 2025 à 11:12.
Tu sous-entends quand même qu'il n'est pas compétent. Et la complexité d'OOXML a été critiquée dès le début.
Je n’ai aucun avis sur systemd
[^] # Re: À compléter par
Posté par orfenor . Évalué à 1 (+2/-3).
non non pas du tout, mais je trouve que c'est un mauvais article
[^] # Re: À compléter par
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 1 (+3/-5).
C'est quoi ce procédé consistant à faire croire qu'on cite pour prendre un mot qui n'est même pas dans le texte le commentaire auquel tu réponds ?
Je n’ai aucun avis sur systemd
[^] # Re: À compléter par
Posté par orfenor . Évalué à 4 (+5/-3).
mais ça va pas ? et c'est quoi ce procédé qui consiste à faire un procès d'intention ?
j'ai cité en raccourci parce que je tape dans des conditions inconfortables et pour indiquer à laquelle de tes 2 phrases je répondais. tu as bien écris "tu sous entend qu'il est incompétent"?
[^] # Re: À compléter par
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 4 (+3/-2).
Ce n'est pas un procès d'intention, mais quand on cite, il faut le faire correctement.
Je n’ai aucun avis sur systemd
[^] # Re: À compléter par
Posté par Tit . Évalué à 2 (+2/-2).
ah oui, tu as écrit "pas compétent" et il écrit "incompétent", c'est sûr que c'est vachement différent…
[^] # Re: À compléter par
Posté par Voltairine . Évalué à 5 (+3/-0).
je n'ai rien lu de tel dans ses propos, tu sur-interprètes.
Cependant en lisant les notes bas de page de l'article on peut quand même se poser des questions sur la profondeur de l'analyse de l'auteur.
Oui c'est très étrange d'autant plus que l'auteur Italo Vignoli, je ne parierai pas qu'il soit allemand 😁
Bon c'est quand même une coïncidence troublante et il aurait du vérifier si le problème était reproductible et tester avec d'autres utilisateurs dans d'autres langues.
À la première lecture je ne comprends ni son incompréhension ni où est l'erreur.
Et la spécification sur ce point qu'il n'y a aucune erreur et pas lieu de s'étonner.
Je suis a peu près persuadée de la supériorité d'ODF sur OOXML et que ce dernier est probablement inutilement alambiqué.
Cependant cette série d’articles ne démontre rien, elle ne fait que montrer et affirmer. Avec du code XML in extenso, ce qui est particulièrement indigeste car l'œil humain un très mauvais analyseur syntaxique du XML, surtout en vrac, non indenté.
[^] # Re: À compléter par
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
En vrai on s’en fout de sa nationalité et de celle de son système :) C’est un vrai problème quand quand on utilise des mélanges d’idiomes pour du balisage et surtout quand on prétend faire du XML normalisé. D’où l’incompréhension. Imagine le casse tête si, pour ta page web, le balisage pouvait être aussi bien
<bold>que<gras>et plein d’autres idiomes ? Même pour µS qui a normalement toutes les cartes en main, le code sera difficile à maintenir et faire évoluer àmha.“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: À compléter par
Posté par Voltairine . Évalué à 3 (+1/-0).
Je suis bien d'accord mais on ignore d'une part par quelles manipulations il arrivé à ce résultat, d'autre par si le problème est reproductible.
Et c'est bien moins grave que ce que tu ne penses puisque c'est dans des valeurs d'attribut de balise qu'il trouve un nom en italien :
[^] # Re: À compléter par
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0). Dernière modification le 12 octobre 2025 à 03:46.
Ah oui, au temps pour moi, il s’agissait de valeur d’attribut…
Je crois que ça vient de ce que le logiciel se mélange les pinceaux dans la gestion des langues ? J’ai vu ça récemment avec un collègue dont le correcteur orthographique voit des passages en français et d’autres en allemand le tout en partant d’un modèle qui serait en anglais à ce qu’il m’a dit.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: À compléter par
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2 (+3/-3).
Après un demi-siècle, certains en sont encore là ! Faut-il aussi démontrer que la Terre n’est pas plate ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: À compléter par
Posté par orfenor . Évalué à 3 (+1/-0).
Ah oui ma phrase est un peu courte ; je voulais dire prouver l'inanité du format OOXML pour montrer la volonté de nuire de Ms.
Évidemment je n'ai pas besoin qu'on me la démontre, mais si je devais argumenter contre l'un ou l'autre, je préparerai des références.
[^] # Re: À compléter par
Posté par Julien Jorge (site web personnel) . Évalué à 8 (+6/-0). Dernière modification le 11 octobre 2025 à 22:13.
Même sentiment ici. L'article affirme des trucs sans rien sourcer. Dès l'intro :
Allez, il faut croire l'auteur sur parole.
Je suis allé voir les précédents articles et c'est la même chose. Ça me fait penser à une critique répétée en boucle il y a quelques années sur le fait que les documents Word gardaient des infos qui avaient été supprimées. Une intention malveillante bien sûr, sauf si on remet ces choix dans leur époque https://www.joelonsoftware.com/2008/02/19/why-are-the-microsoft-office-file-formats-so-complicated-and-some-workarounds/
[^] # Re: À compléter par
Posté par orfenor . Évalué à 3 (+1/-0).
Merci pour le lien !
En expliquant d'où vient la complexité des formats binaires de Ms Office (l'histoire, la rétrocompatibilité et la puissance des outils), l'article permet de mieux expliquer la complexité des formats OOXML. Avis à la populaschtroumpf ! c'est infiniment plus explicatif et enrichissant que les articles sur OOXML.
[^] # Re: À compléter par
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 5 (+3/-0).
L'article est intéressant, mais il parle des formats avant OOXML et qui datent effectivement d'une époque où la mémoire disponible se comptait en kilooctets.
Quand le format ODF a été créé, c'était une époque où les fichiers s'échangeaient déjà beaucoup grâce à Internet et où le Web était déjà bien présent et avait montré l'importance de l'interopérabilité entre les machines, les versions des logiciels et des normes…
Dans ce cadre, et du part le fait que ODF allait être une norme ISO, pourquoi Microsoft n'a pas fait attention à rendre son format de fichier interopérable correctement avec une spécification de taille raisonnable et implémentable ?
Les ordinateurs étaient déjà bien plus puissant, l'argument de la vitesse de chargement et de sauvegarde ne tenait pas la route. L'échange de fichiers étaient commun et l'interopérabilité entre les différentes versions d'Office lui-même posait déjà probléme.
Microsoft devait casser la compatibilité ascendante de toute façon avec ce nouveau format, il n'y avait pas de raison de rester compatible avec l'ancien…
Du coup, j'ai trouvé l'article sur le format des spreadsheets intéressant dans qu'il montre que, concrètement, le format ODF semble plus simple à interpréter que OOXML.
[^] # Re: À compléter par
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Souvent, quand je regarde ce que fait cette entreprise, excepté son premier BASIC peut-être, j’ai l’impression que ce sont des
français/shadocks/etc. : pourquoi faire simple quand on peut faire compliqué ?Même sur ce point, le constat est que leurs produits consomment plus de mémoire et veulent toujours plus de vitesse processeur, à avec cela vous n’avez pas de garantie que ça ne vous chie pas dans la colle à un moment.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: À compléter par
Posté par orfenor . Évalué à 3 (+2/-1).
Faut pas déconner, j'ai déjà travaillé sur d'énormes fichiers word avec plusieurs milliers de pages, des graphismes, des feuilles de calcul intégrées… ça se manipulait sans problème, sans lenteur perceptible, et l'enregistrement sur des disques durs à 2500 tours durait le temps de le dire.
Encore aujourd'hui LibreOffice sous Linux avec SSD et plein de Ram est plus lent sur des documents plus petits.
Word a des défauts, on peut critiquer plein de choses chez Microsoft, mais raconter n'importe quoi juste pour dénigrer ne sert pas la cause du logiciel libre.
[^] # Re: À compléter par
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
C’est vraiment pas de bol pour les gens dont je suis témoin des déboires (:
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: À compléter par
Posté par orfenor . Évalué à 2 (+0/-0).
eh ben explique-les! :-) je ne demandes qu'à avoir des précisions
# Complexité volontaire ?
Posté par raphj (site web personnel) . Évalué à 6 (+4/-0). Dernière modification le 13 octobre 2025 à 17:43.
Complexité volontaire de la part de MS ? Pas sûr. Probablement pas directement. Ça ressemble plutôt à une dette technique monumentale avec aucun effort pour simplifier les choses. Je croirais plutôt à une absence de volonté de simplifier, voire à une volonté de ne pas simplifier, combinée à un haut niveau de désintérêt pour une conception élégante, potentiellement combinée à un peu d'incompétence ou de complexité liée à l'organisation du travail au sein de MS.
Par contre, et aussi par conséquent, un tel merdier n'aurait jamais dû s'appeler "open" et devenir une norme / un standard, surtout quand il y avait une norme déjà existante pour faire la même chose. Si on cherche de la malice, je pense que c'est plutôt de ce côté qu'il faudrait s'attarder et le message serait plus fort.
Un processus de normalisation sain, ça marche rarement comme ça : « Wouala, 10 000 pages écrites unilatéralement, basées sur notre dette technique ! Au fait, il y a des parties protégées par des brevets, et aussi spécifiques à notre implémentation - elles sont "optionnelles", mais bon si elles ne sont pas implémentées ça ne marchera pas. Ah, et au fait, on ne l'implémente pas nous-même, personne ne le fait pour le moment ! Allez, bonne lecture ! Et ne vous inquiétez pas, hein, on "coopérera" avec les gens un peu contre la normalisation, et avec les potentielles investigations. »
https://fr.wikipedia.org/wiki/Office_Open_XML#Norme_ISO/CEI_IS_29500
[^] # Re: Complexité volontaire ?
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 3 (+0/-0).
Je dirais pas complètement volontaire.
En revanche, que ça soit lié à une énorme dette technique, ça ne fait absolument pas l'ombre d'un doute et il a dû falloir pas mal de bricolage pour y arriver. Une volonté de simplification, notamment pour le traitement de texte l'aurait grandement modifié au risque de faire perdre pas mal de clients.
Je n’ai aucun avis sur systemd
[^] # Re: Complexité volontaire ?
Posté par raphj (site web personnel) . Évalué à 2 (+0/-0).
Il y a certainement de la complexité de l'UI qui transpire dans le format, mais je pense que le format aurait pu être grandement simplifié déjà sans (trop) toucher l'UI.
Je ne pense pas que ça aurait fait perdre des client·e·s : ça aurait été transparent pour elles et eux.
Par contre, ça aurait probablement coûté (beaucoup) de fric.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.