Re: Re : Re: [fr-users] Documentation longue durée, traduction et maintenance : constat technique (TINA)

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 <bernard.schoenacker@free.fr> 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 <ysabeau@libreoffice.org> 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 à users+unsubscribe@fr.libreoffice.org 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 à users+unsubscribe@fr.libreoffice.org pour vous désinscrire
Les archives de la liste sont disponibles à https://listarchives.libreoffice.org/fr/users/
Privacy Policy: https://www.documentfoundation.org/privacy