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 <[email protected]> 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 <[email protected]> 
> Envoyé : jeudi 8 janvier 2026 10:51
> À : [email protected]
> 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 à [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


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