Il est en effet très facile d'obtenir une présentation incohérente sur l'ensemble du document (taille des titres qui varie, choix des polices différent pour deux paragraphes de niveau similaire, positionnement des figures centrée au début du document puis ajustées à gauche à la fin, numérotation automatique mal paramétrée...). Que le premier qui utilise MS Word sans jamais que son logiciel lui fasse des blagues de présentation me jette la première pierre.
Si en plus une ou plusieurs parties de ce document doivent être réutilisées par la suite, dans un document d'un type différent (présentation Powerpoint, site web) ou dans un document Word utilisant un style différent, le bon vieux copier-coller va créer des problèmes de mise en page qu'il va falloir corriger à la main et qu'il est parfois plus long de traiter que le temps nécessaire à la réécriture du texte.
Il existe aujourd'hui des outils de rédaction structurée qui se différencient du traitement de texte classique, qui peuvent en corriger les inconvénients et qui sont potentiellement plus judicieux pour rédiger un document complexe.
Passons en revue ces outils.
WYSIWYG ou WYSIWYM ?
Derrière ces acronymes obscurs se cache une différence de conception de la rédaction d'un document.
WYSIWYG (What You See Is What You Get, en français : ce que vous voyez est ce que vous obtenez) désigne la conception actuellement dominante de la rédaction de documents. Un traitement de texte WYSIWYG permet à l'utilisateur en cours de rédaction de voir le document à l'écran tel qu'il s'imprimerait sur papier s'il lançait l'impression immédiatement. Une caractéristique qui semble évidente aujourd'hui, voire indispensable. Cette conception a été rendue possible par le développement des environnements graphiques sur les ordinateurs.
Je me rappelle encore les versions de Word pour MS-DOS (avant que Windows ne se généralise sur les PC) où l'affichage en mode caractère ne permettait l'affichage que d'une seule police à l'écran et d'une seule taille de caractères. Il fallait deviner l'apparence du texte final sur l'imprimante, tester et corriger si nécessaire.
Dans un autre fichier (ou éventuellement dans une partie spécifique du même document), on précisera comment telle fonction ou tel attribut se traduit en terme de présentation (la forme). C'est la séparation du fond et de la forme.
Cette conception est familière à toute personne qui créé des pages web (c'est le principe du HTML pour le contenu et le balisage, et du CSS pour la forme), ou qui rédige des articles dans des wikis (le wikitexte définit le contenu, la forme étant gérée par le moteur wiki). Mais elle est bien antérieure à la conception WYSIWYG et existait déjà dans les années 1970, bien avant qu'Internet n'existe.
La séparation du fond et de la forme a les intérêts suivants :
- cohérence de présentation : la présentation d'un même type de bloc de texte (exemple, citation, titre...) est la même tout le long du document ;
- réutilisation : comme il n'y a pas de formatage dans le fichier de contenu, un copier-coller permet facilement de réutiliser des blocs de texte dans un autre document, et la mise en page s'adapte sans intervention ;
- facilité de modification de la présentation : il suffit de changer les styles dans le fichier traitant de la présentation pour que l'ensemble du document soit mis à jour de manière cohérente ;
- respect d'une charte graphique : une charte graphique se traduit par un fichier unique définissant la forme, commun à tous les contenus, ce qui fait que tous les documents produits respecteront la charte indépendamment du contenu rédigé.
C'est à cause de ce manque d'intuitivité que LaTeX n'a sans doute jamais intéressé une autre population que les geeks et les scientifiques. Pourtant, il existe des solutions qui cachent le balisage LaTeX par une interface graphique relativement intuitive. Signalons par exemple Scientific Workplace, qui comme son nom l'indique est essentiellement destiné à la communauté scientifique, ou encore LyX, plutôt destiné aux geeks.
L'usage d'outils de rédaction structurée est plus pertinente lorsqu'on rédige des documents complexes comme des documentations. Pour ces besoins, il existe des outils plus spécialisés.
DITA, Docbook ou Scenari ?
D'abord, avant les outils, parlons des formats. Il y a aujourd'hui deux formats relativement répandus de formats standard pour la documentation : DITA et Docbook, tout deux basés sur XML. Pour mémoire, XML (eXtensible Markup Language) est un format très versatile de langage à balises qui permet de créer ses propres balises selon ses besoins. Chaque format est en fait un ensemble de balises déterminé et de règles d'utilisation de ces balises.
Docbook, comme son nom l'indique, est un format de contenu destiné à rédiger des documentations. Ce format est issu de la documentation informatique (d'où une pléthore de balises spécifiques à l'informatique, en plus des balises généralistes qui conviennent à la plupart des besoins). Un document Docbook conçu comme une entité unique, comme un livre ou un article.
Egalement originaire du milieu de la documentation informatique, DITA (Darwin Information Typing Architecture) est a contrario un format conçu comme un ensemble de fiches qui peuvent être consultées indépendamment. Sa structuration modulaire en fait un outil plus adapté à une transformation en documentation informatisée, adaptable notamment à un site web ou a un document informatiques à liens hypertextes.
Les deux formats ont des avantages et des inconvénients, et l'on peut choisir l'un ou l'autre en fonction de ses besoins.
Toutefois, un fichier Docbook ou DITA est un fichier XML qui ne contient que du contenu et des balises. Pour obtenir un document, il faut lui faire subir une transformation qui incorpore la mise en forme. Il existe un format de transformation de documents XML appelé XSL (eXtensible Stylesheet Language), mais l'investissement pour l'apprendre est important. Il en existe heureusement déjà quelques uns, mais produire un résultat personnalisé est difficile et demande un effort informatique important.
Notons encore que ces formats ont besoin d'outils informatiques pour les manipuler : un éditeur, si possible intuitif, et un ou plusieurs moteurs de transformation. Un excellent éditeur gratuit est XMLMind XML Editor (ou XXE ; oui, il y a bien deux fois XML dans son nom...), et il contient quelques moteurs de transformations basiques.
Une autre solution, un peu plus flexible quant aux types de documents produits et à leur finalité, est Scenari. Il s'agit d'un ensemble d'outils pour :
- créer un format personnalisé de contenu (basé sur XML),
- personnaliser une mise en forme de publication existante,
- créer un éditeur et un moteur de transformation adapté à ce format,
- éditer du contenu selon ce format,
- produire des documents.
Une solution intéressante, donc. D'autant plus que certains éditeurs spécifiques ont été créés par l'équipe de Scenari, et sont des outils de production. Ainsi, Opale est un outil pour créer des supports de formation, Dokiel est un outil de documentation, WebRadio permet de créer une émission de radio sur internet à partir d'enregistrements audio...
Par contre, la documentation de Scenari laisse à désirer, notamment pour la personnalisation de l'apparence des documents texte. Et la création de son propre éditeur est un travail difficile voire quasi impossible sans documentation plus fournie et sans support de l'équipe Scenari.
Quel outil idéal ?
Un outil tel que Scenari me paraît s'approcher de ce qui serait utile à un médiateur technique chargé de synthétiser des connaissances d'experts dans un document.
Mais il manque à mon goût quelques caractéristiques à cet outil pour être vraiment l'outil qui fera oublier Word :
- une documentation logicielle bien fournie : inutile d'être une solution Open Source si personne ne peut l'utiliser sans formation payante ;
- une interface de développement de formats plus intuitive : on devine trop le code XML ou XSL sous-jacent, ce qui réduit l'intérêt pour le néophyte ;
- un outil séparé de définition de la mise en forme : inutile de prétendre séparer fond et forme si la forme est quasiment fixée par le créateur du format de contenu ;
- et, accessoirement, l'usage d'une technologie informatique plus rapide que le moteur Java, car un éditeur qui rame est particulièrement désagréable.