OpenOffice.org

Certes, OpenOffice.org permet de générer du HTML... Le problème est que le code HTML généré est franchement sous-optimal (pour ne pas être plus méchant) et que les fonctionnalités d'édition collaborative sont très limitées. Par ailleurs, l'outil est abscon, surtout si l'on veut faire les choses proprement (gestion des styles dans des templates, etc. ); les héritages entre les styles se font bizarrement, surtout dans la hiérarchie des titres dont la numérotation et l'indentation est parfois étrange et nécessite donc un contrôle constant. Enfin, OpenOffice ne gère pas (apparement) les images flottantes et oblige à gérer à la main cet aspect-là de la mise en page ce qui peut se révéler pénible lorsque on a beaucoup de schémas ou des schémas de grandes dimensions.

Du point de vue de l'édition concurrente, rien n'est prévu dans le logiciel et le format des données ne permet pas de gérer les versions via un système de gestion de sources.

En conclusion, OOo, s'il présente l'avantage de travailler en wysiwyg, ne me semble utilisable que pour des documents relativement courts, sans mise en page complexe et qui ne seront pas édités par plus de deux auteurs (qui devront cependant être bien coordonnés). À défaut d'être convertibles au format HTML, les documents peuvent être servis en documents joints via un CMS ou un wiki.

Wikis

À l'opposé de la méthode OpenOffice.org, j'ai essayé de cogiter à ce qu'on pourrait faire en partant d'un wiki. Après tout, avec cette méthode on a directement l'aspect publication web et la gestion collaborative. Malheureusement cette dernière nécessite un travail connecté (même si les wikis FS-based comme Dokuwiki ou PMWiki permettent quelques trucs un peu geeks). Surtout, cette approche rend difficile la génération d'une version imprimable de qualité, sauf à développer un exporteur/convertisseur maison vers un format comme LaTeX ou DocBook.

Toutefois, si l'équipe est prête à investir du temps dans le développement d'une telle moulinette, la méthode peut-être fructueuse et je n'exclue pas de creuser un jour cette piste...

LaTeX et al.

La force reconnue de LaTeX est d'être capable de produire des mises en page au cordeau, au risque d'être très (trop ?) standardisées. Bien sûr il est possible de développer soit même ses feuilles de styles mais celà demande un investissement non négligeable dans la maîtrise de l'outil. La maîtrise de la syntaxe LaTeX nécessite d'ailleurs elle-même un certain apprentissage, est donc moins immédiate que celle d'un éditeur wysiwyg et peut rebuter certains de par la présence des balises au milieu du texte.

Il est également facile de gérer l'édition collaborative puisque les documents LaTeX sont intégrables en l'état dans un système de gestion de sources. Un tel système nécessite cependant de disposer d'un serveur ce qui rend cette méthode inaccessible à ceux qui ne disposent que d'un serveur en hébergement mutualisé. Il est peut être possible de s'affranchir de cette limite en utilisant des outils distribués comme darcs, avec mise à disposition de patch-sets, etc. Ne connaissant pas ce genre d'outils je ne peux porter un jugement sur ce qu'il est possible de faire (mais j'ai ça sur ma todo-list).

Si la génération de versions imprimables est le cœur de métier de LaTeX, il n'est pour autant guère problématique de générer du HTML via un outil comme HeVeA.

Tout ceci s'applique aussi sans doute à lout qui ne semble malheureusement plus trop maintenu, son développeur semblant être occupé à une réécriture complète. Je n'ai donc pas poussé plus loin que ça mes recherches sur ce logiciel.

DocBook

En revanche, bien que similaire dans son approche, l'emploi de DocBook est bien moins intéressant dans la pratique que LateX. je dis bien dans la pratique car sur le papier DocBook semble un concurrent sérieux à LaTeX puisqu'il présente à peu près les mêmes avantages : fichiers textes, facilement gérable via un SCM (encore que la nature et la verbosité du balisage complique quelquefois singulièrement les merges), source unique capable de générer des sorties variées, ... avantages auxquels il rajoute une sémantique très forte. Malheureusement, si il n'y a pas trop de problèmes pour la génération des versions HTML, la génération des versions imprimables n'est concrètement possible qu'au travers de l'utilisation de FOP qui, tristement, ne donne pas des résultats satisfaisants; ce sont d'ailleurs mes déconvenues avec le rendu de FOP qui m'ont poussé à mener cette réflexion. Alors bien sûr on peut envisager utiliser une conversion DocBook -> LaTeX, soit au travers d'outils comme Dblatex, soit via des feuilles XSLT maison, mais dans tous les cas il faut s'interroger sur l'intérêt de DocBook par rapport à LaTeX. Si il est nécessaire de conserver des éléments sémantiques très précis, couverts par le schéma DocBook (en gros si l'on rédige une documentation technique informatique, quoi), alors l'investissement peut-être rentable. Si ce n'est pas le cas, non seulement il n'y a pas à mes yeux d'utilité à utiliser DocBook mais, sauf peut-être à utiliser des outils comme Etna, la verbosité assez gigantesque de DocBook me semble par trop décourageante, surtout pour d'éventuels non spécialistes.

XHTML + XSLT

Dernière approche sur laquelle je me suis penché, celle de travailler directement en HTML. Cette solution est en quelque sorte la symétrique de LaTeX par rapport à l'axe DocBook. Par définition la version HTML est obtenue directement, la version imprimable devant elle être obtenue par un logiciel existant (cf. cette page), soit par une feuille maison (j'avais essayé cette méthode avec un certain succès il y a quelques années). L'avantage est que le balisage XHTML est bien moins verbeux que celui de DocBook tout en restant XML, (i.e. facile à manipuler) et sémantiquement cohérent. De plus, un éditeur comme NVu permet aux plus récalcitrants de travailler en wysiwyg sans trop de problèmes.

Cette approche est intéressante si la version web doit être très utilisée dès la phase initiale de la rédaction et que l'équipe préfère utiliser un SCM plutôt qu'un wiki. Elle marquera en revanche vite ses limites si les styles viennent à devenir trop nombreux pour couvrir des besoins de mise en page complexes puisqu'on retrouvera dans ce cas, à peu de choses près, les défauts de la solution basée sur DocBook.

Récapitulation

On voit bien qu'il n'existe pas vraiment de solution idéale au problème envisagé. Il faudra donc faire un choix en fonction des moyens disponibles, des compétences existantes ou qu'il sera possible d'acquérir ainsi que des priorités et qualités voulus pour les rendus. Peut-être est-il même envisageable de combiner plusieurs de ces approches en fonction des différents types de documents produits par l'équipe.

Je me suis amusé pour finir à présenter les résultats de manière tabulaire, en notant chaque solution sur différents critères. Évidemment, cette notation ne peut être complètement subjective. Par exemple, s'il vous ne disposez que d'un serveur web en hébergement mutualisé et qu'il vous est impossible d'utiliser un logiciel de gestion de sources, alors la note de OOo devra être réhaussée, tout comme s'il vous suffit que le document soit seulement téléchargeable et pas nécessairement affiché directement ; ou encore si DocBook est votre langue maternelle et que vous utilisez nxml les yeux bandés, augmentez alors sa note d'utilisabilité... YMMV!

Qualité/ facilité d'impression Qualité / facilité de la génération web Facilité d'usage / technicité Richesse et facilité d'édition collaborative Extensibilité Moyenne
OpenOffice.org ***** ** ***** * ** 2,8
Wikis * ***** **** **** ***** 3,8
Latex **** **** *** **** **** 3,8
DocBook ** **** * *** **** 2,8
XHTML + XSLT ** ***** *** **** ** 3,2