Bonjour Bernard

Je crois que l'on a globalement compris ta marotte... C'est ton opinion. Ce 
n'est pas pour autant un fait incontestable. Je crois qu'Isabeau a essayé de te 
répondre point à point.

De mon côté, je te propose de lever un peu le nez, de tourner 7 fois tes mains 
autour du clavier... Donc de prendre du recul... De revenir dans la "vraie vie".
Et comme je préfère éviter le débat interminable je ne completerai pas plus 
quelle que soit ton éventuelle réponse. 

1-A moins que la cible de ta documentation longue soit un ordinateur, une 
intelligence artificielle, le seul aspect technique ne peut se suffire à lui 
même et il existe toujours des alternatives. Le seul bémol est qu'elles peuvent 
être plus ou moins abordables, plus ou moins connues et demander plus ou moins 
de créativité.
2-Une documentation cherche à informer l'utilisateur pour lui permettre de 
trouver comment un produit peut répondre à son besoin 
2bis- De fait un produit n'a de valeur et d'existence que s'il répond à un 
besoin. L'informatique qui modifie usage et besoin de l'utilisateur car il ne 
cherche pas le besoin utilisateur mais ce qui arrange le développeur, n'a pas 
d'avenir (ou à minima ne devrait pas en avoir).
2ter- Il peut donc exister plusieurs supports de documentation selon le profil 
de l'utilisateur, et le besoin. C'est justement le cas pour la documentation 
LibreOffice qui comprend (notamment) une version HTML, un wiki, des guides 
utilisateurs. Et selon l'utilisateur ou son besoin du moment, le support ne 
sera pas le même. Et les contenus ne sont pas identiques... Chacun est 
différent, et la documentation s'efforce de le prendre en compte
3- L'idée est donc de concilier les besoins de l'utilisateur final, des 
rédacteurs, des relecteurs. Cela inclut la maintenabilite du support (puisqu'en 
fait c'est ton sujet aujourd'hui) mais pas seulement. 
4-C'est bien parce que les besoins et les utilisateurs sont différents que 
certains vont écrire un roman, une thèse, un rapport avec Writer, en odt, et de 
façon structurée, propre, maintenable.
D'autres utiliseront LateX  directement, d'autres encore avec une interface 
WYSIWYM comme LyX ou WYSIWYG (comme SwiftLateX, que je ne connais pas hein..)
D'autres encore trouveront plus efficace de créer un projet git et de le 
documenter en Markdown.
Le monde (du libre) est pas si mal fait : il y a de la place pour tout le 
monde, pour plusieurs outils, chacun choisit en fonction des alternativesv 
qu'il préfère. Aucune solution ne peut-être parfaite d'autant qu'à un moment il 
y a des humains dans le processus. Mais chacune a son intérêt. 


Rien ne t'oblige à utiliser Writer et/ou l'odt dans tes propres cas d'usages si 
une solution te paraît préférable. Retiens que ton choix, même de façon 
inconsciente n'est pas guidé que par des paramètres techniques et que tes cas 
d'usages s'adaptent à ton profil.
LibreOffice et l'ODF ne sont pas des concurrents à LateX, MD, etc. Je suis sûre 
que tu en es convaincu. Il te reste à entendre que tes paramètres, tes critères 
ne sont pas forcément pondérés pareil chez d'autres, et que ce n'est pas moins 
valable. Le tout c'est le résultat obtenu. 

Comme je ne suis pas un ordinateur, quand je lis une documentation je lis le 
résultat produit par un outil qui a utilisé un langage. Mon paramètre à moi, et 
celui du RGAA c'est que ce document doit être structuré car il en facilitera la 
lecture. Que la structuration ait été apportée par de l'xml via l'ODF, lateX, 
ou MD ou autre chose encore peu importe, du moins dans la vie réelle. ;-)

⁣Claire

Le 8 janv. 2026, 15:15, à 15:15, Bernard Schoenacker 
<[email protected]> a écrit:
>Quelques points de clarification :
>
>XML éditable “facilement”
>Oui, le XML est éditable quand on sait exactement que corriger.
>Dans les faits, sur des documents complexes, le volume, la verbosité,
>les styles automatiques générés et les ruptures d’héritage rendent
>cette édition :
>
>non réaliste à grande échelle,
>
>non sécurisée (absence de validation métier),
>
>non exploitable par une équipe non spécialisée.
>
>Il ne s’agit pas d’un cas ponctuel, mais d’un phénomène récurrent sur
>des documents ayant une longue durée de vie.
>
>Séparation fond / forme : théorie vs pratique
>En pratique, Writer :
>
>génère massivement des styles automatiques,
>
>casse les héritages lors de modifications ou de conversions,
>
>introduit des artefacts invisibles tant qu’on reste dans l’interface
>graphique.
>
>La structure logique réelle du document devient alors opaque hors de
>Writer, ce qui limite toute approche outillée externe (diff, audit
>structurel, traduction incrémentale).
>
>Cycle de vie documentaire
>Mon constat concerne une chaîne où :
>
>les corrections ne sont pas traçables finement,
>
>les traductions impliquent des duplications complètes,
>
>les exports PDF figent des problèmes structurels détectables trop tard.
>
>Je suis évidemment d’accord : le PDF est un format d’archive, pas de
>travail.
>Justement : quand l’archive révèle des défauts impossibles à corriger
>sans retour lourd en amont, c’est un symptôme de chaîne fragile.
>
>Ce qui n’est pas dit
>Je ne dis pas que LibreOffice est “mauvais”, ni que les utilisateurs
>sont incompétents.
>Je dis que pour certains usages (documentation longue durée,
>multilingue, maintenue collectivement), la chaîne ODT/Writer montre des
>limites structurelles, indépendamment de la bonne volonté des acteurs.
>
>Mon objectif n’est pas polémique mais technique : identifier ce qui
>permet une maintenance durable, "diffable", traduisible, auditée dans
>le temps — et ce qui ne le permet pas, ou difficilement.
>
>Cordialement,
>
>Bernard Schoenacker
>
>
>
>----- Ysabeau <[email protected]> a écrit :
>> Le 08/01/2026 à 10:50, Bernard Schoenacker a écrit :
>> > Bonjour,
>> >
>> >
>> > Les documents produits et maintenus sous LibreOffice Writer / ODT
>pour
>> > des longs ouvrages, multilingues et évolutifs présentent des
>limites
>> > structurelles intrinsèques :
>> >
>> > ODT est un conteneur ZIP contenant du XML verbeux, non maintenable
>> > humainement.
>> 
>> Oui et non. On peut corriger très facilement des données dans le XML 
>> quand on sait ce que l'on doit corriger.
>> 
>> > Le contenu est indissociablement mêlé à la mise en forme.
>> 
>> c'est complètement faux. Le format ODF a été fait dès le départ en
>vue 
>> d'avoir une séparation complète du fond et de la forme.
>> > La structure réelle (styles, héritages, ancres, TOC) est opaque
>hors
>> > de Writer.
>> >
>> > Les documents analysés montrent une prolifération de styles
>> > automatiques, des héritages rompus et des artefacts liés à des
>> > conversions successives (allemand → anglais → français).
>> >
>> > Il ne s’agit pas d’un problème d’usage ou de rigueur utilisateur,
>> > mais d’un problème de format et de chaîne de production.
>> 
>> Le format n'a que peu à voir là-dedans. Et les différentes versions
>de 
>> LibreOffice améliorent a prise en charge des documents de ce genre.
>> >
>> > Impact sur le cycle de vie
>> >
>> > Dans une chaîne bureautique classique :
>> >
>> > chaque correction est manuelle et non exploitables par "diff" ;
>> >
>> > chaque nouvelle version implique une relecture globale ;
>> >
>> > chaque traduction nécessite une duplication complète du document ;
>> >
>> > chaque export PDF fige des erreurs structurelles invisibles en
>amont.
>> Le PDF est un format d'archive pas un format de travail ! Et il garde
>le 
>> document tel quel à un instant T. Il n'est pas du tout fait pour être
>
>> modifié.
>> > Autrement dit, chaque version devient un fork mort.
>> Si on mélange tout format de travail et format d'archive, on peut 
>> raconter n'importe quoi en effet.
>> 
>> >
>> > Le PDF n’est pas une source
>> >
>> > Le PDF issu de Writer est un artefact final :
>> >
>> > non versionnable,
>> >
>> > non maintenable,
>> >
>> > non traduisible,
>> >
>> > révélateur des faiblesses de structure et de hiérarchie
>typographique.
>> 
>> C'est l'essence du PDF.
>> 
>> Je laisse tomber pour le reste surtout avec un courriel aussi
>maltraité 
>> sur la forme.
>> 
>> -- 
>> 
>> Ysabeau
>> 
>> « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry
>Pratchett, Déraillé.
>> 
>
>
>-- 
>Envoyez un mail à [email protected] pour vous
>désinscrire
>Les archives de la liste sont disponibles à
>https://listarchives.libreoffice.org/fr/users/
>Privacy Policy: https://www.documentfoundation.org/privacy

-- 
Envoyez un mail à [email protected] pour vous désinscrire
Les archives de la liste sont disponibles à 
https://listarchives.libreoffice.org/fr/users/
Privacy Policy: https://www.documentfoundation.org/privacy

Répondre à