Article publié par la revue homo-numericus
sous licence creative commons,
Publier sur le web des textes longs, fortement structurés, accompagnés de notes, farcis de graphiques et d’illustrations. Quiconque est confronté à ce type de tâches, sait pertinemment que les difficultés sont nombreuses pour la réaliser dans des conditions satisfaisantes.
Car le meilleur outil pour écrire ce type de textes, celui qui en tout cas est le plus utilisé, à tort ou à raison, c’est un logiciel de traitement de texte, de type Word ou Open Office. Le problème est que ces logiciels produisent des textes où l’information de mise en forme, de structuration ou d’enrichissement du texte est comme intégrée au texte lui-même, incrustée dans l’information textuelle [1], alors que le langage du Web, le langage html, est un langage dit "de balises", où l’information de structuration marque extérieurement le texte sur lequel elle s’applique. Pour le dire vite, Word produit ce texte, tandis que pour arriver au même résultat, le langage html doit en passer par cette étape.
Dès lors, la publication de textes sur le Web, en particulier par l’intermédiaire d’un logiciel de publication automatisé (content management system) comme Spip, ne peut que passer par des formulaires qui ne peuvent transmettre que du texte brut, éventuellement balisé, mais jamais enrichi comme dans un logiciel de traitement de texte. Il suffit pour s’en convaincre de prendre un texte dans Word, de lui appliquer une série d’enrichissement (styles, mises en forme directes), et de copier-coller le résultat dans un formulaire Web. On voit immédiatement que toutes les informations de mise en forme sont perdues d’un format à l’autre. Spip pallie à cet inconvénient ou bien en reconnaisant les balises html, ou bien en utilisant son propre langage de balises simplifiées. Il en va de même par exemple dans les logiciels de gestion de forum (PhpBB par exemple qui s’appuie sur le BBcode) ou encore les systèmes de wiki, qui ont leur syntaxe propre. Dans tous les cas, il faut ou bien écrire et mettre en forme le texte directement dans les formulaires d’édition, ou bien travailler dans Word et ensuite appliquer des moulinettes, généralement des macros qui interprètent les mise en forme de Word pour générer les balises correspondantes à copier-coller dans le formulaire web. Toutes solutions relativement lourdes ou complexes dans un contexte où les producteurs de textes ont écrit sans s’inquiéter du support par lequel ils les diffuseraient, et donc, majoritairement, dans Word. Par ailleurs, dans le cadre d’une publication multi-supports, il est relativement difficile de partir de la version html d’une publication pour produire une version papier par exemple. On préférera disposer d’une version au format traitement de texte qui sera utilisée pour les étapes suivantes de mise en page et d’impression.
Bref, quoiqu’on en pense, le format traitement de texte reste souvent à la fois la source et le format pivot incontournable de l’édition de textes en ligne. C’est pourquoi certains logiciels de publication, comme Lodel, s’intéressent à prendre en charge de manière relativement automatisée l’opération de conversion du format Word (ou Open Office), vers un langage de balises comme xml, html ou xhtml. Et comme cette opération est relativement lourde et complexe (beaucoup plus qu’on ne le pense en général en tout cas, car les problèmes d’interprétation des styles sont importants), certains se sont tournés vers la solution d’une "délocalisation" de l’opération à l’extérieur du logiciel de publication qui y a recours. Le tout nouveau système de prise en charge de cette opération de conversion s’appelle Servoo [2]. Servoo, c’est le système qui peut être adapté à n’importe quel outil de publication web pour lui fournir, de manière déportée, une solution de publication des textes directement à partir du fichier traitement de texte.
L’idée essentielle qui anime le développement du projet, est que la fonction de conversion ne peut et ne doit être prise en charge par le logiciel de publication. Celui-ci a déjà suffisamment à faire en gérant les différents intervenants, les différents étapes de production et la structuration d’une publication, tout en conservant une légèreté et une simplicité lui permettant d’être installé partout et utilisé par tous. Il faut donc que le travail de conversion soit assuré par un autre serveur qui peut d’ailleurs, puisqu’il ne fait que cela, effectuer le travail pour un grand nombre d’utilisateurs.
Cette structuration du fonctionnement logiciel proposé par Servoo manifeste la réalité d’une tendance dont il n’est pas le seul exemple. Rien que pour Spip ,les fonctions de correction orthographique pour la future version 1.8, et de génération de formules mathématiques pour une des contributions en cours de développement, reposent sur le même principe. On voit émerger la réalité d’une architecture logicielle de type "web services" dont l’avantage essentiel est de permettre de concilier la simplicité d’utilisation à la richesse des fonctionnalités. Le Graal informatique en quelque sorte.
Pour passionnante et riche de promesses qu’elle soit, cette évolution n’est pas sans poser quelques questions : tout d’abord celle de la confidentialité ; car l’architecture répartie des fonctionnalités logicielles suppose une circulation démultipliée de l’information, et donc une certaine confiance envers les opérateurs entre les mains desquels cette information circule, sans même évoquer les risques d’indiscrétion sur le chemin qui conduit d’un serveur à un autre. La deuxième question posée est celle de la mutualisation des ressources. Car pour qu’un grand nombre de système de publication "clients" puisse utiliser un système servoo, il faut bien qu’un plus petit nombre d’acteurs offre les ressources de serveurs, plus lourds et complexes à gérer, à l’ensemble d’une communauté dont ils doivent cerner les contours. Il faut donc nécessairement, outre des ressources techniques, un fonctionnement social de type communautaire où certains acteurs offrent des services sans contrepartie immédiate à la communauté dans laquelle ils s’insèrent. [3] Gageons que c’est sur ce point que les différentes communautés du logiciel libre sauront montrer leur évidente supériorité, en mettant en oeuvre, une fois de plus, le mode de fonctionnement mutualisé dont elles ont coutume.
Servoo se présente pour l’essentiel sous la forme d’une API. Ghislain Picard, le concepteur et principal développeur du logiciel attend explicitement que chaque communauté constituée autour de son logiciel de publication s’en empare pour l’implémenter dans son propre système, à l’instar de Lodel. Il semble évident que la communauté des utilisateurs de Spip (ou plutôt les différents sous-communautés qui la constituent) va se montrer très vite intéressée, en publiant rapidement une "contrib" permettant de l’utiliser avec son CMS préféré. La première version de la partie "client" de Servoo, vient d’être diffusée. Il est important de savoir que le projet est en plein développement, en attendant la diffusion sous peu de la partie "serveur" du système, dont on espère qu’elle provoquera une véritable efflorescence de servoo ouverts au moins à certaines communautés, et, pourquoi pas, à tous. Il y aurait, pour ceux qui auront fait le choix de cette dernière option, l’occasion d’un véritable engagement en faveur d’une expression collective et démocratique sur le réseau.
