Modulariser son contenu pour mieux le valoriser

Construire des documents modulaires à partir de blocs d’information partagés permet de gagner en productivité et en qualité. Mais, pour obtenir une valorisation du contenu optimale, gérer un réseau de modules d’information ne s’improvise pas.

Tous les supports de communication marketing ou technique publiés par l’entreprise partagent des blocs de contenu identiques : adresse de la société sur tous les documents, liste des événements prochains sur le site web et dans le magazine d’entreprise, description de la société dans les communiqués de presse, notes et avertissements dans les notices techniques, etc. L’outil principal utilisé dans les entreprises pour gérer du contenu est le traitement de texte ; chaque document correspond donc en général à un fichier unique, contenant tout le texte, les images et les informations de mise en page. Seul le site web, dans le meilleur des cas, échappe à ce modèle, le contenu étant géré par un CMS de style WordPress ou Drupal.

Ce modèle est répandu parce qu’il est compris par tous les intervenants de l’entreprise. C’est le fameux paradigme du wysiwyg : comme saint Thomas, l’utilisateur ne croit que ce qu’il voit. Il est pourtant très inefficace.

Les modules d'information sont de structure homogène mais ont un contenu différent

Tout d’abord, si vous utilisez un CMS, vous savez qu’il est beaucoup plus facile de déléguer toute la mise en page à une feuille de style externe au contenu. La mise en page est homogène sur tout le site et pour la changer, il suffit de remplacer un seul fichier, comme le site CSS Zen Garden en fait l’éclatante démonstration. Le contenu entré sous le CMS se contente de comporter quelques balises structurantes de type titre, citation, etc., auxquelles sera appliquée la mise en page de la feuille de style. Un exemple tout bête de la différence entre les deux modèles : si vous séparez accidentellement deux mots par deux espaces au lieu d’une - oui, on dit une espace en typographie ;-) - le texte imprimé à partir d’un traitement de texte contiendra une double espace. Celui affiché sur le site web, non.

Ensuite, si les images se trouvent incluses dans le fichier, vous êtes obligé de les extraire puis de les réinsérer manuellement si vous désirez les modifier. Si vous avez mis à jour des captures d’écran dans un document Word, vous savez de quoi je parle. Si les images sont des fichiers externes, c’est évidemment beaucoup plus simple.

Enfin, si chaque document contient tout le contenu textuel, les mêmes blocs d’information sont dupliqués à de multiples exemplaires. Leur modification demande alors une mise à jour manuelle hasardeuse par copier-coller. Le risque d’erreurs est important et le coût, très élevé. Si la société déménage, par exemple, c’est une multitude de fichiers qu’il faut modifier pour changer l’adresse. Et pour les versions multilingues des documents, est-il utile de faire traduire à chaque fois le même avertissement qui se répète tout au long de la documentation technique ?

Un module d’information unique peut être publié à de multiples exemplaires, sous différents formats

Il est beaucoup plus efficace de construire des documents modulaires. Le document est alors comme un jeu de Lego, où ce sont des combinaisons de modules partagés qui créent des documents différents. Le format DocBook fournit un tel modèle. Les traitements de texte également, avec la notion de document maître, mais en théorie seulement : je n’utiliserais jamais cette fonctionnalité, tellement elle est boguée. Le modèle le plus efficace est celui où la structure des documents est externe aux modules d’information.

Sous le format DITA XML, par exemple, la structure de table des matières d’un document lui est totalement externe. Il s’agit d’un fichier .ditamap qui comporte une série hiérarchisée de liens pointant vers différents fichiers. Chaque fichier correspond à une section avec un titre, un corps de texte, etc. Avantage de la solution : les sections qui se répètent d’un document à l’autre, la section contenant les coordonnées de l’entreprise, par exemple, sont en fait un fichier unique, appelé dans différentes structures .ditamap. Quant aux unités d’information atomiques qui ne forment pas une section à part, telles qu’une note, le mécanisme des conref permet de les inclure dynamiquement dans une section donnée.

Format source de rédaction technique modulaire

L’avantage d’un tel système est certain. La difficulté est que chaque document devient en fait un réseau d’unités d’information. Il est donc nécessaire d’administrer ce réseau en tant que tel, notamment lors des mises à jour des modules de base : si la note n du document A doit être modifiée, cette note doit-elle ou non être également modifiée dans le document B où elle apparaît aussi ? (Si la réponse est non, il vous faudra, selon l'ampleur des différences entre les deux versions, soit créer deux blocs d'information différents, soit faire varier le contenu de ce bloc avec un mécanisme de texte conditionnel.) La définition de la taille des blocs d’information de base et l’articulation de ces derniers devient un aspect primordial de la valorisation du contenu d’entreprise, et le responsable de la communication technique se mue en architecte du contenu.

À l’échelle de l’histoire, ce modèle de document en réseau semble nouveau. Pendant des siècles, c’est le modèle du document linéaire et monolithique qui a prévalu. Le rouleau et le livre ne se prêtaient pas à une réorganisation dynamique du contenu. Seules, peut-être, certaines documentations techniques du XXe siècle organisées en classeur (et où l’on pouvait donc remplacer des pages) se rapprochaient, mais si peu, du nouveau modèle. Toute notre culture et notre éducation étant basées sur ce modèle linéaire, il n’est pas étonnant que nous éprouvions quelques difficultés à en appréhender le nouveau. C’est pourtant le modèle même de l’Internet, avec lequel nous commençons à nous familiariser. Si l’informatique a permis l’émergence de ce modèle, elle nous fournit également les outils pour le maîtriser. Ainsi du projet Componize, qui se propose de gérer les grappes de fichiers DITA XML sous le système de gestion de contenu Alfresco. Pour les réseaux de contenu très complexes, la société Magillem propose un modèle élégant. Le problème est que vous placez alors votre contenu sous un logiciel propriétaire au format opaque, mais c’est souvent déjà le cas.

Je gère pour ma part des fichiers DITA XML sous les systèmes de gestion de version Subversion et Git. J’avoue qu’une interface graphique montrant à un instant t la carte des liens composant un document donné me faciliterait tout de même la tâche. Mais même sans, je ne reviendrais au modèle monolithique pour rien au monde.

Voir aussi : Didacticiel DITA XML : publier son 1er PDF en 5 minutes avec DITA Open Toolkit





Ajouter un commentaire

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
CAPTCHA
Si vous êtes un robot, ne remplissez pas ce champ.
6 + 3 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.