Content as code : l'une des approches les plus sous-estimées pour construire un site web durable

À un moment ou à un autre dans la vie de presque tous les sites institutionnels, un rédacteur reçoit la consigne de modifier une date. L'opération devrait prendre trente secondes. À la place, il ouvre un navigateur, s'identifie avec une authentification à deux facteurs, cherche dans une interface d'administration un élément de contenu dont le titre interne ne correspond plus au titre public, déplie une série de composants imbriqués, retrouve la bonne phrase, la corrige, enregistre un brouillon, attend l'aperçu, constate que celui-ci ne ressemble pas tout à fait à la page publiée, soumet la modification puis envoie un message à quelqu'un disposant des droits de publication. Il faudra peut-être encore vider un cache. Peut-être attendre un déploiement planifié. La date, qui n'était au départ qu'une douzaine de caractères d'information publique, a soudain acquis le poids cérémoniel d'un petit projet d'infrastructure. Tout le monde considère cela comme normal, parce que le système est un CMS d'entreprise et que les logiciels d'entreprise nous ont appris à confondre complexité et sérieux.

Cette même organisation qualifiera généralement son site de pérenne. Elle dispose d'un fournisseur, d'un contrat de maintenance, d'un système de droits, de workflows, de composants réutilisables, d'API, d'un design system et, quelque part dans une présentation, d'un schéma d'architecture parcouru de quelques flèches rassurantes. Pourtant, la véritable connaissance de l'organisation (ses pages, explications, politiques, définitions, avertissements et instructions sur lesquels les gens s'appuient) ne peut être lue ou modifiée qu'à travers la base de données, le modèle de contenu et l'interface de ce système précis. Lorsque le contrat expire, que la plateforme arrive en fin de vie, que l'intégrateur disparaît, que le schéma évolue ou qu'une refonte impose une migration, ce contenu prétendument pérenne se transforme en négociation autour d'otages. Nous avons construit un coffre-fort doté d'un écran tactile sur la porte, puis nous nous sommes félicités parce que l'écran avait des coins arrondis.

Il existe un modèle plus simple, et il reste étonnamment sous-utilisé en dehors de la documentation logicielle et de certaines petites équipes éditoriales : le content as code. Le terme paraît plus technique que la pratique. Il ne signifie pas que chaque rédacteur politique doit apprendre JavaScript ni qu'un chargé de communication doit déboguer une pipeline de build avant midi. Il signifie que la source canonique du contenu éditorial d'un site est stockée dans de simples fichiers texte (le plus souvent en Markdown, parfois précédés d'un petit bloc de métadonnées structurées) au sein d'un dépôt versionné. Un processus de build transforme ensuite ces fichiers en pages web. Le code gère la présentation et le comportement ; le contenu reste du contenu. Les formulaires, transactions, systèmes d'authentification et bases de données peuvent parfaitement subsister là où ils sont réellement nécessaires. Il ne s'agit pas de transformer tout service numérique en brochure statique. Il s'agit de cesser d'emprisonner des connaissances publiques durables dans l'application provisoire utilisée aujourd'hui pour les publier.

Markdown a précisément été conçu pour cette séparation. John Gruber l'a publié en 2004, avec une contribution importante d'Aaron Swartz, comme un format de texte brut lisible pouvant être converti en HTML valide. Son principe de conception était clair : un document Markdown doit rester compréhensible avant même l'intervention d'un logiciel. Gruber distinguait explicitement le format d'écriture du format de publication. Toute l'idée tient presque dans cette distinction. Un titre écrit sous la forme ## Conditions est déjà un titre pour un humain, un script, un moteur de recherche ou un système d'IA. Un lien reste visiblement un lien. Une liste reste visiblement une liste. La source ne se dissout pas dans une forêt de balises, de champs de base de données ou de blocs sérialisés. Elle n'est pas portable parce qu'un fournisseur promet quelque part un bouton d'export ; elle est portable parce qu'elle existe dès le départ sous une forme lisible par des outils plus simples que le site lui-même.

Le CMS moderne a inversé cette relation. À l'origine, il devait éviter aux rédacteurs d'écrire du HTML à la main, objectif tout à fait raisonnable. Il est progressivement devenu un environnement où les rédacteurs ne voient presque plus rien de la structure qui porte réellement leur contenu. L'interface graphique propose une simulation rassurante : une barre d'outils, une zone de texte, peut-être une pile de cartes que l'on peut déplacer. Mais le web n'est plus depuis longtemps un environnement où ce que l'on voit correspond réellement à ce que l'on obtient. Ce qu'un rédacteur voit sur son ordinateur portable n'est pas ce qu'un visiteur voit sur son téléphone, ce qu'un lecteur d'écran restitue, ce qu'un moteur de recherche indexe, ce qu'une API renvoie ou ce qu'un assistant extrait de la page. L'interface graphique ne supprime pas la complexité. Elle la déplace hors du champ de vision et rend le rédacteur dépendant de ceux qui comprennent ce que l'interface dissimule. Ce n'est pas une démocratisation. C'est une division du travail qui produit de la dépendance acquise.

Une interface graphique peut pourtant rester utile, à condition qu'elle soit une fenêtre ouverte sur des fichiers accessibles plutôt que le lieu où la connaissance de l'organisation est enfermée. Obsidian illustre particulièrement bien cette différence. L'application stocke les notes sous forme de fichiers Markdown dans un simple dossier local ; ces fichiers peuvent également être ouverts avec d'autres éditeurs de texte ou gérés avec Git. Obsidian lui-même est un logiciel propriétaire, ce qui rend l'exemple plus intéressant encore : l'application peut être propriétaire tandis que le contenu demeure structurellement indépendant. L'éditeur offre un aperçu, des liens, une navigation, une recherche et une expérience d'écriture agréable, sans demander à l'utilisateur d'abandonner les fichiers sous-jacents. Si Obsidian disparaissait demain, les notes ne deviendraient pas des pièces archéologiques. Elles resteraient du texte. Voilà ce qu'une bonne interface devrait faire : réduire les frictions sans fabriquer de captivité.

La seconde moitié du content as code, c'est Git, et c'est souvent là que les organisations deviennent inutilement timides. Tout rédacteur, auteur ou travailleur du savoir devrait connaître les notions élémentaires du contrôle de version : dépôt, commit, branche, diff, merge et revert. Non pas parce que tout le monde devrait aimer la ligne de commande, et encore moins parce que celle-ci serait moralement supérieure, mais parce que ces concepts relèvent désormais d'une forme élémentaire de culture institutionnelle. Nous attendons déjà des rédacteurs qu'ils sachent utiliser le suivi des modifications, les commentaires, l'historique des documents, les conventions de nommage et les processus d'approbation. Git propose une version plus stricte, plus fiable et beaucoup plus transférable de ces mêmes idées. Il enregistre précisément ce qui a changé, quand, par qui et pourquoi. Il permet de comparer deux versions ligne par ligne, de tester une modification sans écraser la source publiée, de revoir plusieurs changements liés en une seule fois et de revenir à un état antérieur sans devoir fouiller un dossier partagé à la recherche de final_v7_vraiment-definitif.docx.

Git est en outre un logiciel open source, publié sous licence GPLv2, et son histoire devrait être une lecture obligatoire pour quiconque considère la dépendance à un fournisseur comme un risque théorique. Le projet du noyau Linux utilisait autrefois un système propriétaire de contrôle de version distribué, BitKeeper. En 2005, la relation entre la communauté Linux et l'entreprise qui développait BitKeeper s'est détériorée, et l'accès gratuit au logiciel a été retiré. Linus Torvalds et la communauté ont alors créé Git, en visant notamment la vitesse, la simplicité, le fonctionnement distribué, la gestion de milliers de branches parallèles et la capacité à soutenir un projet de l'ampleur du noyau Linux. L'un des outils de collaboration les plus universels de l'informatique contemporaine existe donc précisément parce qu'un projet critique a découvert qu'un accès accordé par une entreprise n'est pas la même chose que le contrôle. La leçon pourrait difficilement être plus explicite.

Pour le travail éditorial, Git transforme la collaboration : on passe d'une succession de documents à une histoire des décisions. Un rédacteur propose une modification. Un expert métier commente une ligne précise. Un juriste valide une partie et en interroge une autre. Un développeur voit immédiatement qu'un changement de contenu nécessite aussi une adaptation du template. Des contrôles automatiques peuvent signaler avant publication un lien cassé, des métadonnées manquantes, une hiérarchie de titres incorrecte ou une date de révision dépassée. La discussion reste attachée à la modification au lieu de se disperser entre e-mails, chats et comptes rendus de réunion. La version publiée et les raisons pour lesquelles elle est devenue la version publiée appartiennent au même historique institutionnel. Cette collaboration est meilleure non parce que les développeurs l'auraient inventée, mais parce que la méthode est explicite. La plupart des outils de bureau sont très efficaces pour permettre aux gens de discuter autour d'un document. Le contrôle de version est efficace pour conserver ce qu'ils ont finalement décidé d'y changer.

Il ne s'agit pas d'un workflow théorique. GitLab traite la documentation comme une partie du produit : les modifications passent par des issues et des merge requests, les rédacteurs et les développeurs les examinent ensemble, et la documentation est censée être publiée en même temps que les changements de produit correspondants. La source de cette documentation vit dans des dépôts aux côtés du code du produit, tandis que le site public est généré avec Hugo et déployé sous forme statique. L'essentiel n'est pas GitLab ou Hugo en tant que marques. Les deux peuvent être remplacés. L'essentiel est que la source éditoriale, l'historique des révisions, le comportement du logiciel et le processus de publication partagent une même source de vérité. La documentation ne reste pas dans un CMS séparé jusqu'à ce que quelqu'un se souvienne que le produit a changé mardi dernier.

Dès que le contenu est stocké sous forme de fichiers, il devient réellement modulaire. Une page peut être un fichier. Un avertissement réutilisable, un autre. Les métadonnées peuvent contenir le titre, le propriétaire, l'URL canonique, la langue, l'intervalle de révision, le statut de publication et le thème. Une arborescence de dossiers peut soutenir une architecture de l'information sans prétendre qu'une arborescence constitue à elle seule cette architecture. Les liens peuvent être vérifiés automatiquement. Les contenus liés peuvent être générés. Les traductions peuvent être associées. Un inventaire éditorial peut être produit sans commander au fournisseur un export de base de données. Les CMS classiques revendiquent eux aussi la modularité, mais ils entendent généralement par là que le contenu a été découpé en entités comprises par ce CMS : nodes, blocks, fields, widgets, paragraphs, taxonomies, relations et identifiants internes. Une API ne supprime pas cette dépendance. Elle offre simplement une porte d'entrée documentée vers la couche d'abstraction de quelqu'un d'autre. Un CMS headless enlève la tête ; il n'enlève pas le verrouillage.

Les fichiers se prêtent aussi naturellement à l'automatisation parce que leur structure reste visible. Un simple script peut retrouver toutes les pages contenant une année obsolète, lister tous les contenus sans propriétaire, calculer quelles pages doivent être révisées, détecter les liens internes cassés, comparer les URL canoniques, générer un tableur destiné aux rédacteurs ou produire un corpus propre pour la recherche et les usages liés à l'IA. Il ne s'agit pas de projets exotiques de machine learning. Ce sont des tâches ordinaires en Python, en shell ou dans des dizaines d'autres langages largement enseignés. Je préfère apprendre une fois Markdown et cinq opérations Git à un collègue plutôt que lui enseigner successivement les particularités de Drupal, puis de WordPress, puis d'un CMS headless propriétaire, chacun avec son vocabulaire et son drame migratoire. Et oui, je préférerais aussi que davantage d'employés apprennent Python ; R est parfaitement respectable, Excel est utile et Power BI a certainement sa place, mais aucun de ces outils n'offre le même levier général qu'un langage capable de lire, transformer et publier les véritables fichiers sources d'une organisation.

La différence de coût ne se résume pas aux licences. Un CMS piloté par une base de données exige une application active, une base de données, des mises à jour, des correctifs de sécurité, une gestion des plugins, une gestion des environnements, des compétences spécialisées, des sauvegardes, du monitoring et des mises à niveau périodiques dont la description officielle ressemble souvent assez peu à la facture finale. Une agence peut être nécessaire pour modifier le modèle de contenu parce que ce modèle est devenu une infrastructure. Une deuxième agence peut ensuite être nécessaire pour migrer l'interprétation du premier prestataire du premier système vers le deuxième. Le content as code ne supprime ni l'ingénierie ni la gouvernance, mais il réduit considérablement la quantité de machinerie nécessaire pour publier du texte. Un build peut convertir des fichiers en HTML statique et en assets peu coûteux à héberger, faciles à mettre en cache et difficiles à casser en production. Les dépenses se déplacent alors vers des sujets qui méritent réellement qu'on y consacre de l'argent : architecture de l'information, accessibilité, écriture, design, recherche et véritables services numériques.

La fiabilité découle de cette même réduction du nombre de pièces mobiles. Une page statique n'a pas besoin d'interroger une base de données de contenu à chaque visite. Un build défaillant peut échouer avant la publication plutôt qu'après l'arrivée d'un utilisateur. Chaque version déployée peut correspondre à un commit, et revenir en arrière peut simplement signifier redéployer un état connu au lieu de restaurer une base de données et d'espérer que les fichiers téléversés, la configuration et les plugins partagent la même conception de l'histoire. Les concepts sont anciens, ennuyeux et universels : fichiers, hashes, texte, dossiers, transformations, copies. Cet ennui est un avantage stratégique. Git a été conçu pour supporter un projet de la taille et de la vitesse du noyau Linux. Une méthode capable de coordonner des changements dans un tel environnement n'est pas trop fragile pour un site institutionnel.

Lorsque l'on affirme qu'un site doit pouvoir évoluer à grande échelle, on pense généralement au trafic, parce que le trafic se prête bien aux schémas d'architecture et au langage des marchés publics. Le content as code évolue parfaitement dans ce sens classique : des pages préconstruites peuvent être distribuées via des caches et des réseaux de diffusion de contenu sans qu'une base de données éditoriale devienne le pouls du site public. Mais les formes de passage à l'échelle les plus intéressantes sont organisationnelles et temporelles. Cent personnes peuvent-elles contribuer sans écraser mutuellement leur travail ? Cinq langues peuvent-elles partager une même structure sans devenir cinq sites indépendants ? Le même contenu peut-il être réutilisé dans un site, un e-mail, un guide imprimé, un moteur de recherche, un jeu de données et un assistant ? Un nouveau fournisseur peut-il reconstruire la couche de présentation sans devoir d'abord faire de la rétro-ingénierie sur dix ans de conventions de base de données ? Le contenu peut-il encore être ouvert une fois que le framework actuel, le fournisseur et la stratégie de domaine ont disparu ? Un système qui supporte dix millions de pages vues mais nécessite six mois de migration pour changer de plateforme n'a grandi que dans la direction la moins intéressante.

C'est ici que la question de l'IA devient concrète plutôt que simplement à la mode. Les organisations se précipitent pour rendre leur information lisible par les assistants tout en continuant à stocker la version canonique dans des systèmes optimisés pour l'assemblage visuel de pages. Elles scrappent ensuite leur propre HTML rendu, retirent la navigation, les bandeaux de cookies, les composants dupliqués et les débris de mise en page, tentent de reconstituer les titres, reconstruisent les métadonnées et appellent le résultat une knowledge base prête pour l'IA. C'est une boucle absurde. Markdown et les autres formats texte propres séparent déjà le sens de la présentation. Titres, listes, liens, citations, code, métadonnées et relations sont explicites. La même source peut être rendue pour un humain, indexée pour la recherche, découpée pour la retrieval ou lue par un assistant sans devoir d'abord faire comme si une page web était une capture d'écran. L'IA n'est pas la raison d'adopter le content as code. Elle ne fait que rendre visible le gaspillage de nos architectures de contenu actuelles.

Pour les institutions et administrations européennes, l'argument est également politique. La stratégie européenne en matière d'open source place ce dernier au coeur de la souveraineté technologique et le relie explicitement à une moindre dépendance vis-à-vis des technologies propriétaires non européennes, à davantage de contrôle, à l'interopérabilité, à la réutilisation de biens numériques publics et au rôle des administrations comme utilisatrices et contributrices. Une administration qui conserve ses connaissances publiques dans des formats texte ouverts et les gère au moyen de standards ouverts de contrôle de version conserve des choix en matière d'hébergement, de fournisseurs, de juridiction et de réutilisation future. GitHub n'est pas Git. Une organisation peut utiliser GitHub, GitLab, Forgejo, un autre fournisseur ou son propre serveur. Le dépôt peut déménager. Les fichiers n'ont pas besoin de l'autorisation d'une plateforme étrangère pour continuer à être des fichiers.

Il existe aussi un avantage culturel, plus difficile à quantifier et plus important qu'une comparaison supplémentaire de fonctionnalités. Le content as code réduit la distance artificielle entre le métier, le contenu et la technologie. Les rédacteurs apprennent qu'une page possède une source, des métadonnées, des dépendances et un historique de publication. Les développeurs rencontrent le contenu comme une partie à part entière du système plutôt que comme du remplissage ajouté une fois la bibliothèque de composants terminée. Les analystes peuvent inspecter la même source sans devoir demander un export spécifique. Les designers peuvent comprendre quelles variantes existent réellement et lesquelles ont été improvisées un jour dans un champ de texte riche. Le frontend et le backend ressemblent moins à deux planètes reliées entre elles par des tickets. Tout le monde ne devient pas développeur, mais davantage de personnes comprennent réellement le fonctionnement du produit. Les systèmes deviennent durables lorsque la connaissance qui les concerne est distribuée ; ils deviennent lourds lorsque chaque modification ordinaire doit franchir une frontière professionnelle.

L'objection la plus forte est réelle : Git peut être désagréable. Sa terminologie est le résultat d'une histoire accumulée, les conflits de merge sont intimidants, les messages d'erreur de la ligne de commande ont parfois l'empathie d'un mathématicien déçu, et beaucoup de défenseurs du content as code décrivent le workflow avec la sérénité de gens qui ont oublié ce que le mot "rebase" peut évoquer pour une personne normale. La coédition en temps réel est souvent plus simple dans Google Docs ou Microsoft 365. Les grandes médiathèques, les droits fins, les workflows de localisation et les embargos exigent une conception attentive. Un dépôt peut devenir désordonné. Markdown peut être mal utilisé. Une mauvaise architecture de l'information reste mauvaise même lorsqu'elle est parfaitement versionnée dans des fichiers. Aucun de ces problèmes ne doit être balayé. Obliger chaque rédacteur occasionnel à travailler dans un terminal et appeler ensuite sa frustration de "l'empowerment" reproduirait la même erreur que le CMS traditionnel, simplement avec une palette de couleurs plus sombre.

Mais cette objection plaide pour de meilleures interfaces éditoriales, pas pour un stockage fermé. La grande opportunité de design consiste précisément à dissocier l'expérience d'édition du format canonique. Donnez aux rédacteurs une application proche d'Obsidian, un éditeur dans le navigateur, des formulaires pour les métadonnées, un bouton d'aperçu, des commentaires, des droits et, s'il le faut, un grand bouton rassurant intitulé "Publier". Cachez les commandes là où elles n'apportent rien. Gardez la source visible là où cette visibilité apprend quelque chose. Appelez un merge request une revue si cela aide. Laissez les équipes rédiger ensemble dans des outils familiers lorsque la simultanéité est réellement nécessaire, puis transférez le contenu approuvé dans le dépôt. Le point non négociable est que l'interface doit écrire dans des fichiers ouverts et inspectables, tout en conservant un historique standard. Le confort doit être remplaçable. Le contenu, non.

L'adoption ne nécessite pas de révision constitutionnelle. Commencez par une partie durable du site : directives, documentation, explications de politique publique, base de connaissances, pages de projet ou contenu de campagne à longue durée de vie. Stockez chaque page en Markdown avec un petit ensemble strict de métadonnées. Placez le dépôt sous Git. Ajoutez des contrôles automatiques pour les liens, les titres, les métadonnées et les dates de révision. Générez un aperçu pour chaque modification proposée. Apprenez aux rédacteurs uniquement les quelques concepts Git dont ils ont réellement besoin. Laissez les applications transactionnelles là où les transactions ont leur place, mais rendez le contenu explicatif adressable, testable et indépendant. Après la première refonte, l'avantage devient évident : le frontend peut être remplacé tandis que le contenu demeure. Après la première correction en masse, l'avantage devient presque embarrassant : un script accomplit en quelques minutes ce que l'ancien système transformait en semaines de clics coordonnés.

Des années après que ce premier rédacteur aura modifié cette date, l'organisation repensera de nouveau son site. Le CMS actuel sera devenu un système legacy, comme les plateformes modernes savent si bien le devenir. Le design system paraîtra daté. Un fournisseur proposera une étude de migration. Dans la version content as code de cet avenir, quelqu'un ouvrira le dépôt, lira les fichiers, adaptera les templates et reconstruira le site. L'ancienne interface pourra disparaître sans emporter avec elle la mémoire de l'organisation. Quelque part dans la source, cette date fera toujours douze caractères. Elle sera toujours lisible. Elle attendra toujours d'être modifiée.