CMS headless vs workflow Markdown

Deux projets web peuvent tous les deux être « headless » ou tous les deux « monolithiques » et différer pourtant sur une question qui détermine autant de la réalité éditoriale : où le contenu vit-il physiquement, et qui peut le modifier.

Deux réponses viables existent pour la plupart des projets pilotés par le contenu. La première, c’est le markdown dans votre dépôt git : chaque page, chaque article de blog, chaque description produit est un fichier .md sous gestion de version, édité dans un éditeur de code ou un outil d’édition compatible git, relu en pull request, et compilé dans le site au moment du déploiement. La seconde, c’est un système de gestion de contenu hébergé : le même contenu vit dans une base de données (la vôtre, ou celle d’un fournisseur SaaS), est édité via une interface web, et est récupéré par le frontend à la requête ou via revalidation par webhook.

Les deux sont des options réelles et matures. Les deux livrent des sites sérieux. Le bon choix pour un projet dépend presque entièrement de qui écrit le contenu, qui le publie, et à quelle fréquence il livre. La question du découplage architectural (headless ou non) est traitée dans l’article sur l’architecture headless ; celui-ci se situe un niveau en dessous, sur la couche source du contenu.

Cinq caractéristiques font systématiquement du markdown la bonne source de contenu.

Les auteurs sont techniques, ou sont prêts à utiliser un outil d’édition compatible git. Ingénieurs, rédacteurs techniques, devrels, product managers qui travaillent déjà en pull requests. La friction de « ouvre l’éditeur, écris du markdown, commit, push, fais relire, merge » est une fonctionnalité pour ces auteurs, pas un défaut.

La cadence de publication est modérée, pas haute vélocité. Plusieurs mises à jour par semaine, parfois par jour. Pas « l’éditeur veut pousser un correctif à un communiqué de presse dans les dix prochaines minutes ». La publication au build s’insère bien dans une cadence de déploiement quotidienne ou horaire ; elle ne convient pas à un workflow où dix minutes entre l’édition et la publication, c’est trop long.

Le versioning, le branching et la relecture font déjà partie du fonctionnement de l’équipe. Une branche refonte peut porter six semaines de changements de contenu qui sortent ensemble avec le nouveau template, sans affecter la production. Une correction de coquille peut être une PR d’une ligne. L’historique du contenu est un historique git, avec auteur, horodatage, et la conversation de relecture attachée.

L’infrastructure de contenu n’est pas la bienvenue. Aucun CMS à héberger, aucun compte utilisateur admin à gérer, aucun écosystème de plugins à maintenir à jour, aucune histoire de sauvegarde séparée. Le contenu est dans le même dépôt que le code, et le même déploiement qui livre le code livre le contenu.

Le modèle de contenu est raisonnablement stable. Ajouter un nouveau champ à tous les 400 articles de blog est une exécution de script, pas une migration CMS. Le markdown récompense la stabilité et pénalise un modèle de contenu qui change souvent et qui aurait été un simple « éditer ce type de contenu » dans un CMS.

Quand les cinq sont réunies, le markdown dans git est la source de contenu la moins coûteuse en friction pour l’équipe et la moins chère à opérer dans la durée.

À l’inverse, cinq caractéristiques font d’un CMS hébergé le bon choix plutôt qu’un choix de mode.

Des éditeurs non techniques font la majeure partie des publications. Équipes de communication, responsables marketing, chargés de programme d’ONG qui rédigent des mises à jour terrain. Des personnes pour qui « ouvrir une pull request pour corriger une coquille » est rédhibitoire. Un CMS leur donne un éditeur de texte familier, un bouton « sauvegarder » évident, et une action « publier » claire.

Le modèle de contenu est riche et change régulièrement. Plusieurs types de contenu, des champs structurés par type, des références entre entrées, des galeries d’images avec métadonnées, des champs multi-langues. Modéliser cela dans un frontmatter markdown est possible mais devient vite fragile ; un schéma CMS le rend explicite et requêtable.

La publication doit être rapide et découplée des déploiements. L’équipe marketing doit pouvoir pousser une mise à jour de campagne à 21h sans réveiller un ingénieur. Les éditeurs doivent pouvoir programmer un contenu pour une heure précise. Corriger en urgence un mauvais chiffre dans un article publié ne peut pas attendre un pipeline d’intégration continue.

Plusieurs éditeurs avec des rôles différents travaillent en parallèle. Auteurs, relecteurs, valideurs, traducteurs. Permissions par rôle, workflows de brouillon-et-relecture, planification. Un CMS gère cela nativement ; reproduire la même chose par-dessus un flux markdown-et-PR est possible mais en vaut rarement la peine.

La gestion d’assets fait partie du travail éditorial. Les éditeurs uploadent des images, le CMS les stocke, le frontend rend les variantes responsives. Faire cela par-dessus git produit des dépôts énormes et des éditeurs qui font transiter des captures d’écran via Slack vers un développeur. Une bibliothèque d’images de CMS est ce qu’ils veulent réellement.

Quand la plupart de ces points sont réunis, un CMS est ce dont l’équipe éditoriale a besoin, et essayer de la pousser vers du markdown est la manière dont le workflow se fait silencieusement contourner (l’éditeur écrit dans Word, envoie le document à un développeur, le développeur commit le markdown).

Les deux choix viennent avec de vrais compromis qui surprennent souvent les équipes six mois après.

Avec le markdown, les surprises sont généralement éditoriales. Le contributeur non technique censé rédiger des mises à jour mensuelles en écrit une et arrête, parce que la friction est trop forte. L’équipe juridique a besoin de modifier une seule phrase et trois ingénieurs sont mobilisés un vendredi après-midi. Le workflow de traduction s’avère exiger un outil git sur mesure parce qu’aucun service de traduction standard ne comprend la structure du dépôt. Aucun de ces points n’est rédhibitoire quand l’équipe est technique ; ils le sont quand elle ne l’est pas.

Avec un CMS hébergé, les surprises sont généralement structurelles. Le modèle de contenu qui paraissait propre au lancement a besoin de trois migrations dans la première année. La tarification du fournisseur croît de manière inattendue avec l’usage. Un export de « tout le contenu » s’avère lossy quand il doit quitter le système propriétaire. L’environnement de preview ne correspond jamais tout à fait à la production, donc les éditeurs publient une fois pour voir à quoi cela ressemble et une seconde pour corriger ce que cela rend. Aucun de ces points n’est rédhibitoire quand la valeur éditoriale est réelle ; ils le sont quand l’équipe aurait pu livrer en markdown et a sur-investi dans un CMS pour un site de 50 pages.

Le test honnête, c’est de faire passer un changement de contenu représentatif de bout en bout dans les deux options, avec les personnes qui feront réellement le travail, avant de s’engager.

La bonne réponse pour beaucoup de projets n’est pas l’un ou l’autre mais les deux, chacun portant le contenu qui lui convient.

Un arrangement courant : les pages marketing et le blog en markdown (faible volume, mainteneurs techniques, vrais bénéfices de gestion de version), le catalogue produits ou la base de connaissances dans un CMS (champs structurés, éditeurs non techniques, mises à jour fréquentes), et un frontend qui consomme les deux de façon transparente. Les générateurs de site statique et les frameworks full-stack soutiennent tous les deux ce mode hybride : un build peut lire à la fois du markdown du système de fichiers et une API de contenu externe, et l’utilisateur voit un seul site.

La discipline qui fait que cela marche, c’est de tracer la frontière par type de contenu, pas par préférence d’équipe. Chaque type de contenu a une source. L’équipe se met d’accord à l’avance sur les types qui vivent où, et les migrations entre les deux sont des décisions explicites, pas une dérive silencieuse. Sans cette discipline, les dispositifs hybrides deviennent « nous avons du contenu dans deux systèmes, aucun des deux n’est complet, et personne ne sait lequel fait foi ».

La décision d’architecture headless, c’est « la couche de contenu doit-elle être découplée du frontend ». La décision de source de contenu, c’est « où vit réellement le contenu ». Le markdown dans git gagne sur la simplicité opérationnelle, la gestion de version, l’expérience auteur technique, et l’infrastructure inexistante. Un CMS hébergé gagne sur l’UX éditeur non technique, les modèles de contenu riches, la publication rapide et indépendante, et les workflows éditoriaux structurés. Le mauvais choix coûte de la vélocité éditoriale dans un sens et de la complexité opérationnelle dans l’autre, et le moyen le moins cher de le découvrir, c’est de faire passer un changement de contenu représentatif dans les deux options avant de s’engager.

Le contexte plus large, dont la manière dont le choix de source de contenu se relie au reste de la décision d’architecture, est rassemblé dans le cluster architecture web et plateformes. Et lorsque la question passe de « où le contenu doit-il vivre » à « nous avons décidé, et il nous faut maintenant quelqu’un pour concevoir le workflow éditorial, la cadence de publication et la gouvernance qui viennent avec », c’est exactement ce sur quoi mon accompagnement communication digitale et stratégie de contenu est centré.