par DITA Molière Qu’est-ce qu’un CCMS ?
Pour gérer du contenu DITA, certaines équipes se tournent vers GitHub par habitude, parce que c’est gratuit et qu’il gère très bien les versions. Mais aussi puissant soit-il pour les développeurs, GitHub montre ses limites dès qu’il s’agit de gestion de contenu structuré.
Commençons par définir « Qu’est-ce qu’un CCMS ? » et pourquoi c’est important. Un système de gestion de contenu par composants (CCMS ou Component Content Management System), comme MadCap IXIA CCMS, organise le contenu en éléments réutilisables (phrases, paragraphes…) plutôt qu’en documents complets. Résultat : des mises à jour simplifiées, une cohérence préservée, et un contenu facilement déclinable sur tous les formats et plateformes
Il ne fait aucun doute que GitHub est une très bonne ressource. Je l’utilise d’ailleurs pour héberger des exemples de fichiers DITA que je référence depuis DITAWriter.com. Il s’agit d’un bon outil pour stocker le code. De plus, il permet de stocker du contenu rédigé au format DITA. Ceci dit, GitHub n’est pas un système de gestion de contenu par composant (CCMS) ni une alternative correcte à un tel système. Je dirais même que GitHub est loin d’être le meilleur référentiel pour stocker du contenu DITA XML.
Pour réutiliser du contenu efficacement, il est nécessaire de pouvoir le trouver
L’un des principaux avantages de DITA du point de vue de l’efficacité est la possibilité de réutiliser du contenu, dont la réutilisation de cartes ou de rubriques entières, ou encore la possibilité de procéder à un niveau plus granulaire en utilisant des conrefs et des clés. Un des points clés (pardonnez le jeu de mots) de la réutilisation efficace du contenu est avant tout le fait de pouvoir trouver le contenu à réutiliser.
De ce point de vue, la fonctionnalité de recherche native de GitHub est épouvantable. Cette fonctionnalité permet de trouver des noms de fichiers similaires à ce que vous recherchez, mais c’est à peu près tout. D’un point de vue du processus, cela signifie que vous obligez vos rédacteurs à stocker localement tout le contenu pour pouvoir le retrouver de manière efficace afin de le réutiliser, tout en espérant que tout ira pour le mieux. Le seul processus efficace pour un rédacteur technique dans cette situation est de rechercher le contenu en local. Plus le contenu stocké sur GitHub est volumineux, moins il est utile.
Un bon CCMS offre des fonctions de recherche étendue pour trouver du contenu à réutiliser. Non seulement vous pouvez rechercher du contenu de manière sélective parmi les cartes, les rubriques et les images, mais vous pouvez aussi affiner les recherches de contenu au sein de la carte active sur laquelle vous travaillez, rechercher des balises ou des attributs DITA spécifiques et bien plus encore.
Si vos rédacteurs ne peuvent pas trouver le contenu, ils ne peuvent pas le réutiliser.
GitHub ne comprend pas fondamentalement le format XML
La seule chose que GitHub fait bien, c’est de stocker et gérer les versions des fichiers. Cependant, il ne possède aucune « compétence » supplémentaire lorsqu’il s’agit de travailler avec le format XML ou de le manipuler. Aucune validation inhérente à GitHub ne garantit que le contenu qui lui est soumis est bien formé, ce qui signifie qu’il n’y a pour GitHub aucune différence entre un bon contenu DITA valide et un contenu mal formé.
Un bon CCMS ne vous autorisera pas à sauvegarder un support XML non valide, et s’assurera qu’il est bien formé et qu’il ne présente aucun problème avant qu’un rédacteur puisse l’envoyer. S’il est vrai qu’un bon éditeur XML repèrera un code non valide, il laissera toujours le rédacteur technique sauvegarder le contenu en local, en estimant que cette version n’est pour l’instant qu’un simple brouillon amené à être corrigé ultérieurement. Rien n’empêche ce rédacteur de télécharger ce contenu sur GitHub. Les choses commencent à devenir intéressantes dès lors qu’une autre personne télécharge ce « brouillon » et essaie de l’utiliser dans sa sortie (ce qui ne sera pas possible).
Les problèmes dépassent le simple cadre des rédacteurs qui essaient de soumettre des données XML mal formées. Si vous réalisez une quelconque forme de localisation, vous devez veiller à ce que le support renvoyé par le prestataire de services de localisation soit conforme à la norme DITA. GitHub ne peut pas vérifier ce point pour vous, mais un bon CCMS peut le faire. Un référentiel sensible au format XML comme TEXTML (qui sert de base à MadCap IXIA CCMS) permet de réaliser plusieurs actions, telles que les contrôles de validation, la possibilité d’effectuer des recherches approfondies de contenu efficace et la manipulation rapide de transformations XML pour convertir et produire des sorties. Sans oublier les flux de travail.
Un éditeur XML et GitHub n’ont pas de flux de travail.
La clé de tout processus de documentation mature est le flux de travail. Il s’agit de faire passer le contenu du statut de brouillon au statut de révision, puis au statut d’achèvement. Entre-temps, vous pouvez envoyer des rubriques à des experts techniques pour qu’ils les révisent, à d’autres rédacteurs pour qu’ils les corrigent, et obtenir leurs validations respectives quant à l’exactitude et à l’exhaustivité du contenu avant de le publier. Le flux de travail est une fonctionnalité standard intégrée dans tout bon CCMS.
Celle-ci ne figure pas du tout dans GitHub ni dans aucun éditeur XML.
Il est possible de créer quelque chose qui ressemble à un flux de travail en utilisant une série de programmes tiers qui fonctionnent avec GitHub. Or, cela implique un travail de programmation et de personnalisation pour obtenir ce dont vous avez besoin. Pourquoi réinventer la roue alors que les flux de travail existent déjà dans un CCMS ?
Un manque de métadonnées associées
En plus de garder une trace des rubriques, un bon CCMS DITA contient également d’autres métadonnées associées qui sont utiles pour mieux comprendre comment, quand et par qui le contenu a été rédigé. Un bon CCMS inclura, par exemple, des informations sur les champs des métadonnées associées en couvrant tous les aspects, de la date de création d’une rubrique à la dernière personne ayant travaillé dessus, en passant par le fait d’indiquer si la rubrique fait l’objet d’un travail actif ou non, sa version, les mots clés qui lui sont associés et bien plus encore. Tandis que certains éditeurs XML peuvent inclure ce type d’information, ils ne le font pas par défaut et sans un effort considérable de configuration préalable.
Ces métadonnées sont essentielles non seulement pour mettre en place un flux de travail efficace, mais aussi pour effectuer des recherches. Par exemple, les métadonnées dans MadCap IXIA CCMS veillent à ce que plusieurs rédacteurs ne travaillent jamais simultanément sur le même contenu, grâce à un flux de travail intégré qui informe les autres rédacteurs lorsqu’une rubrique est « verrouillée » et en cours de traitement (elle peut néanmoins toujours être consultée dans sa version prééditée).
En termes de recherche, vous pouvez rechercher des rubriques qui ont été créées à une certaine date, par un rédacteur spécifique ou pour un projet en particulier. Ces métadonnées sont aussi essentielles pour obtenir des mesures de production, afin que vous puissiez vous faire une idée du nombre de rubriques créées ou modifiées sur un laps de temps précis, pour ne citer qu’un exemple.
Encore une fois, aucune de ces fonctionnalités n’est disponible dans GitHub.
Quels sont les avantages de GitHub du point de vue de la documentation ?
Ce que GitHub fait le mieux, c’est ce pour quoi il a été conçu : stocker et gérer les versions des contenus logiciels. Lorsque j’ai commencé à utiliser un système de contrôle de version pour conserver mes publications assistées par ordinateur (il y a très très longtemps), je trouvais génial de pouvoir archiver des contenus mis à jour pour que d’autres rédacteurs puissent travailler dessus, puis de pouvoir revenir à une version précédente en cas d’erreurs lors d’une édition ultérieure. La plupart de ces fonctionnalités ont été reprises dans l’interface de GitHub, et c’est un très bon moyen pour stocker, gérer des versions et, dans mon cas, partager des fichiers publiquement.
En ce moment, je partage quelques projets DITA sur GitHub via mon compte DITAWriter. L’un des problèmes que je rencontre actuellement est le fait de devoir coordonner grossièrement par e-mail les modifications avec mes collaborateurs. À plusieurs reprises, une personne a écrasé du contenu sur lequel j’avais travaillé, et inversement. Pour faire court, il m’est souvent arrivé de regretter de ne pas avoir utilisé un CCMS avec mes collaborateurs. Bien que le processus d’utilisation d’un éditeur XML visant à résoudre les différences entre les versions contradictoires d’une rubrique se soit amélioré, il n’est pas à la hauteur d’un CCMS qui sait par essence comment gérer les opérations de jonction et de fusion, surtout lorsque plusieurs lignes et versions de produits sont impliquées.
Bien que GitHub soit un bon outil pour stocker du code et que les éditeurs XML soient excellents dans ce qu’ils font, un CCMS solide qui maîtrise le format XML offre une meilleure expérience globale en matière de rédaction et de publication.
Cet article a été rédigé en anglais par Keith Schengili-Roberts, Senior Content Strategist DITA au sein de l’équipe MadCap IXIA CCMS et traduit Meryem MURAT, étudiante en master TSM à l’université de Grenoble, avec l’aimable autorisation de MadCap.