Aller au contenu principal

Deux chemins, un objectif : comparaison entre CCMS et Docs-as-Code

Docs-as-code vs. CCMS

Bien que les CCMS (Component Content Management System, systèmes de gestion de contenu par composants) empruntent souvent des principes à la méthodologie docs-as-code — comme la modularité, la réutilisation et le contenu structuré — ils restent, sur le plan philosophique et opérationnel, bien plus proches de la rédaction technique classique.

Voici pourquoi je considère les CCMS comme plus alignés avec la rédaction technique traditionnelle.

Pourquoi les CCMS penchent vers la rédaction technique classique​

  • Rédaction structurée vs. contrôle de version – Les plateformes CCMS se concentrent sur la rédaction en XML ou par sujets (DITA, DocBook) dans un environnement graphique. Contrairement aux workflows docs-as-code qui utilisent Git et Markdown dans des IDE ou éditeurs en texte brut, les utilisateurs de CCMS rédigent souvent dans des éditeurs spécialisés conçus pour les non-développeurs.
  • Documentation à l’échelle de l’entreprise – Les CCMS sont conçus pour les grandes équipes qui gèrent du contenu complexe à travers plusieurs produits et publics — une approche historiquement ancrée dans la rédaction technique traditionnelle pour les secteurs aéronautique, médical et industriel.
  • Fonctionnalités de workflow – Cycles de relecture, gestion des versions, traduction, automatisation de la publication — ces éléments sont centraux dans les outils CCMS et reflètent les processus intégrés aux méthodologies classiques de communication technique.
  • Séparation des rôles – Les CCMS impliquent souvent des architectes de l’information, des éditeurs, des relecteurs et des traducteurs — contrairement aux workflows docs-as-code, généralement plus plats et orientés développeurs.

Où ils se rejoignent​

  • Modularité du contenu – Docs-as-code et CCMS défendent tous deux le contenu réutilisable et à source unique.
  • Automatisation & CI – Certains CCMS ont évolué pour s’intégrer à Git ou à des pipelines de publication continue, empruntant ainsi aux philosophies docs-as-code.

Les outsiders (outils historiques)​

FrameMaker et RoboHelp sont des outils classiques de la suite Adobe que j’ai utilisés il y a plusieurs années. Ils ont été — et sont encore — utilisés par les rédacteurs techniques traditionnels, mais ne peuvent pas être qualifiés de véritables CCMS.

Voici comment ils se positionnent.

FrameMaker​

Un puissant outil de publication desktop conçu pour la rédaction structurée et non structurée — particulièrement adapté à la documentation longue et imprimable comme les manuels utilisateur, les guides de référence et les documents réglementaires. Il prend en charge XML et DITA, ce qui lui donne un aspect structuré proche du CCMS, mais il ne propose ni dépôt centralisé de contenu ni gestion de workflow, éléments clés d’un CCMS.

RoboHelp​

Un outil de rédaction d’aide (HAT) axé sur la création de systèmes d’aide en ligne, de bases de connaissances et de contenus web responsive. Il est idéal pour la documentation d'interface utilisateur, les guides procéduraux et les centres d’aide. Comme FrameMaker, il ne dispose pas d’une architecture modulaire robuste ni d’un workflow basé sur les rôles comme on l’attend d’un CCMS.

Leur positionnement​

  • Les deux outils prennent en charge la réutilisation, le contenu conditionnel et la publication multi-format — ce qui rappelle certaines capacités des CCMS.
  • Aucun ne propose de gestion centralisée du contenu, de coordination complexe des workflows ou de versioning à l’échelle de l’entreprise — des caractéristiques fondamentales des CCMS.

En résumé : FrameMaker et RoboHelp sont des outils de rédaction traditionnels avec des fonctionnalités proches des CCMS, mais ils n’incarnent pas pleinement la philosophie CCMS. Ils se situent quelque part entre des outils desktop autonomes et des environnements de rédaction modulaire allégés.

Considérez-les comme des compagnons fiables pour les rédacteurs techniques — pratiques, puissants et familiers — mais pas tout à fait adaptés à la gestion de documentation massive, multilingue et multi-produit.

Perspectives​

Comme l’illustre ce schéma, les outils et workflows varient largement dans le paysage de la documentation — mais la tendance est claire. D’après mon expérience, je vois le docs-as-code comme l’avenir de la rédaction technique. Sa simplicité, sa flexibilité et son approche adaptée aux développeurs en font une solution de plus en plus naturelle pour les équipes produit modernes. Il ne s’agit pas de remplacer les méthodes traditionnelles, mais d’adopter un workflow qui évolue avec la technologie que nous documentons.

©Auteur : Florence Venisse, STW — Première version du 22/07/2025.