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

Bonjour Monsieur Pourchez,

Merci pour votre message, qui met des mots précis sur le cœur du sujet.

Vous avez parfaitement raison : ce que je décris correspond bien aux **limites intrinsèques de 
l’approche WYSIWYG** appliquée à des documents longs, évolutifs, multilingues, et destinés à une 
maintenance dans le temps.
Et oui, l’opposition WYSIWYG / WYSIWYM est exactement l’axe de lecture pertinent.

Mon propos dans ce fil n’est pas de disqualifier les outils bureautiques en général — ils répondent 
très bien à des besoins de production ponctuelle ou de mise en page — mais de **documenter ce qui 
se passe lorsqu’on leur demande de jouer le rôle de source documentaire**, ce pour quoi ils n’ont 
pas été conçus.

Le point qui me semblait important à rendre visible ici est le suivant :

* dans un outil WYSIWYG, **la structure réelle du document peut devenir implicite, fragmentée ou 
déplacée** (cadres, objets graphiques, styles automatiques),
* tant que l’on reste dans l’éditeur, cette dette structurelle est invisible,
* elle n’apparaît que lorsqu’on sort de l’outil (conversion, audit XML, traduction, versionnement).

Le cas concret analysé dans ce fil illustre précisément ce phénomène :
un document parfaitement lisible dans Writer, mais dont le contenu principal est stocké dans des 
objets graphiques (`draw:text-box`), rendant toute exploitation WYSIWYM impossible sans 
reconstruction.

Vous évoquez à juste titre les **chaînes éditoriales**, et c’est effectivement là que se situe la 
réponse de fond.
Des solutions comme SCENARI, DocBook, DITA, Markdown + Pandoc, ou équivalents, posent explicitement 
la structure comme source, et relèguent le rendu à une étape ultérieure — ce qui correspond 
exactement au besoin exprimé.

Mon intention sur cette liste était surtout de :

* **nommer clairement la limite**,
* la **documenter techniquement**,
* et éviter que le débat reste cantonné au niveau de l’éditeur ou du format “qui s’ouvre”.

Merci en tout cas pour votre intervention, qui permet de recadrer la discussion sur des bases 
conceptuelles solides.

Bien cordialement,

Bernard Schoenacker

----- Antoine POURCHEZ <antoine.pourchez@gmail.com> a écrit :
> Bonjour Mr Schoenacker,
> Vous notez là les caractéristiques (limites) de l'approche WYSIWYG des writers bureautiques 
> (centrés sur l'apparence avec une structuration sémantique faible) et posez les bases de ce 
> qu'est un outil WYSIWYM (centrés sur la structure documentaire, la mise en forme ne venant que 
> dans une seconde étape).
> Chaque approche répond à des besoins différents, avec pour chacune d'elles des contraintes et des 
> limites intrinsèques.
> Dans le monde WYSIWYM, je vous invite à étudier le concept de chaine éditoriale, surement plus 
> proche de votre besoin exprimé dans ce fil (ex dans la sphère openSource : 
> https://scenari.software/fr/ ).
> Bonne soirée 
> Antoine
>
>
> -----Message d'origine-----
> De : Bernard Schoenacker <bernard.schoenacker@free.fr> 
> Envoyé : jeudi 8 janvier 2026 10:51
> À : users@fr.libreoffice.org
> Objet : [fr-users] Documentation longue durée, traduction et maintenance : constat technique 
> (TINA)
>
> 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.
>
> Le contenu est indissociablement mêlé à la mise en 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.
>
> 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.
>
> Autrement dit, chaque version devient un fork mort.
>
> 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.
>
> Traiter le PDF comme un produit de référence est une erreur méthodologique.
>
> Point critique : la traduction
>
> Une documentation multilingue durable impose :
>
> une source textuelle unique,
>
> une granularité fine (phrases / paragraphes),
>
> la possibilité de traductions incrémentales.
>
> Cela n’est pas possible avec un document ODT riche.  Cela est nativement possible avec des 
> formats texte structurés et des outils de type gettext / po4a.
>
> Sans cela, la traduction ne passe pas à l’échelle et devient chronophage, coûteuse et 
> décourageante.
>
> Argument temps long
>
> Un document qui ne peut pas être :
>
> versionné par diff,
>
> audité sans interface graphique,
>
> traduit sans duplication,
>
> maintenu indépendamment d’un logiciel donné,
>
> n’est pas un document pérenne.
>
> Conclusion opérationnelle (TINA)
>
> Pour une documentation longue durée, collective, traduite et maintenue :
>
> la source doit être un format texte structuré (Markdown, AsciiDoc, HTML),
>
> la traduction doit s’appuyer sur un workflow type po4a,
>
> les rendus (PDF, HTML, EPUB) doivent être générés, non édités.
>
> La bureautique lourde peut convenir à un usage individuel ponctuel.
> Il n’est pas une alternative viable dans le temps pour une documentation de référence.
>
> TINA — There Is No Alternative.
>
> Pas par idéologie.  Par mécanique.
>
>
> Cordialement
>
> Bernard Schœnacker
> 57930 Fénétrange
>
> Rédacteur technique industriel
> Technicien méthodes
>
> --
> 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


-- 
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