I was “just” a CMS developer.
Then came AI

Je suis développeur et j’ai fait des CMS.

J’y ai consacré une bonne partie des vingt dernières années. CMS voulait souvent dire WordPress, et WordPress voulait dire sites web. L’association se comprend, mais elle ne raconte qu’une partie du travail.

Un titre, une photo et un bouton « Publier » peuvent être tout ce que l’on voit. Derrière, il peut y avoir des rédactions, des traductions, des permissions, des intégrations et des années de contenus qui doivent survivre à la prochaine mise à jour. C’est en travaillant sur ces problèmes que j’ai le plus appris.

Aujourd’hui, l’IA permet à bien plus de personnes de se construire une application, un outil de gestion, voire leur propre CMS. Je trouve cela enthousiasmant. Et je reconnais, dans ces projets, beaucoup des problèmes sur lesquels nous avons travaillé pendant des années.

Plus il devient facile de générer du logiciel, plus il devient utile de savoir ce que ce logiciel doit pouvoir faire dans la durée. C’est de cette expérience que je voudrais parler.

Le logiciel commence par ceux qui l’utilisent

La personne qui ouvre un CMS a généralement un travail à terminer : publier un article, mettre à jour un catalogue, organiser un événement. Notre modèle de données doit rencontrer ce travail. Un champ obligatoire peut être parfaitement logique dans la base et impossible à remplir quand on esquisse à peine un contenu. Tôt ou tard, quelqu’un y écrira « à définir », et la contrainte aura dégradé les données.

C’est une leçon de produit qui devient immédiatement de l’architecture : distinguer un brouillon d’un contenu publiable, demander les informations au bon moment, rendre l’erreur compréhensible et la récupération possible.

Dans les logiciels d’entreprise, l’acheteur et l’utilisateur sont souvent deux personnes différentes. Un salarié peut devoir vivre des années avec une interface pénible. Dans le grand public, où il est plus facile de quitter un produit, cette même difficulté peut coûter un client. Beaucoup de CMS se situent entre les deux : ce sont des outils de travail utilisés par des personnes aux compétences, habitudes et patiences très différentes. Une bonne école pour concilier structure et facilité d’usage.

On retrouve cet air de famille dans les applications actuelles. Un CRM, un logiciel immobilier, une interface d’administration : je filtre des informations, je choisis leur présentation, j’agis. Requête, vue, action. Le tableau, le calendrier et le kanban peuvent être trois façons de travailler sur les mêmes données.

Cette grammaire a aussi des racines dans les bases de données et les logiciels de gestion. Les CMS l’ont pratiquée longtemps auprès de personnes qui devaient s’en servir quotidiennement sans connaître les clés étrangères. L’IA permet désormais de générer une vue pour une seule tâche, peut-être pour dix minutes. En dessous, le sens des données et les règles de modification doivent rester reconnaissables.

Anatomie d’un CMS

Prenons Directus, parce que je travaille avec et peux l’examiner de près. Dire « une base de données avec des API et une interface » est aussi juste que décrire un animal comme quelque chose doté d’une peau et d’organes. Pour comprendre ce que nous achetons, réutilisons ou envisageons de reconstruire avec l’IA, il faut en séparer les responsabilités.

Je commence par l’extérieur. La peau, c’est le Data Studio : formulaires, vues et tableaux de bord rendent le système utilisable. Mais masquer un champ dans le formulaire ne le protège pas sur le serveur. Le squelette, c’est le modèle de données : tables et relations SQL, avec les métadonnées par lesquelles Directus décrit champs, interfaces et configurations. À nous de définir « client », « projet » ou « approuvé ». Puis nous ouvrons le lapin.

La distinction essentielle sépare ce que Directus sait faire des décisions qui nous reviennent. Il propose collections, relations, permissions, versions et automatisations. Déterminer qui peut approuver une dépense, quand un brouillon est publiable ou comment reconnaître le même client dans deux systèmes exige un modèle de notre travail. Le produit fournit les outils pour l’exprimer ; sa justesse reste notre responsabilité.

Suivons une modification concrète : un rédacteur change le prix d’un produit. Le Data Studio recueille la valeur ; l’API reçoit la requête ; les services l’exécutent dans le contexte de l’utilisateur et de ses permissions. La base applique ses contraintes. L’historique, s’il est configuré, conserve la modification. Un Flow peut déclencher la mise à jour d’un catalogue externe. Ces responsabilités sont distinctes : si ce dernier service ne répond pas, le prix enregistré et celui affiché ailleurs peuvent diverger. Il faut une règle de récupération et un moyen de s’en apercevoir.

Les frontières comptent aussi quand nous étendons la plateforme. La documentation des services demande de prêter attention au contexte d’autorisation, appelé accountability : l’omettre peut donner au service des permissions administratives.³ Et masquer un champ dans le Data Studio ne remplace pas une politique sur les données.⁴ La valeur de la plateforme dépend aussi du respect de ses frontières.

Hors de l’animal restent l’exploitation et la maintenance : base de données et stockage, secrets, sauvegardes vérifiées, surveillance, mises à jour et compatibilité des clients. Nous pouvons en déléguer une partie à un service géré, mais devons savoir qui s’en charge. Migrer le schéma ou restaurer une révision ne résout qu’une partie du problème et ne constitue pas un plan de reprise complet.

Les choix de licence ramènent aussi au coût de cet ensemble. Directus adopte aujourd’hui la MSCL, une licence source-available : le code est consultable, l’usage dépend des conditions applicables.⁵ Pour qui envisage une alternative, le calcul comprend le coût durable des responsabilités qu’il choisit d’assumer.

La facilité d’usage, au-delà du navigateur

Le même soin doit bénéficier à ceux qui travaillent avec du code, des scripts et des automatisations. La developer experience, ou DevEx, est une autre forme de facilité d’usage : documentation claire, types explicites, commandes prévisibles, erreurs compréhensibles. Elle permet la précision et la répétition d’une opération en sachant à quoi s’attendre.

Chez Directus, cette attention est concrète. Le SDK JavaScript et TypeScript propose un client composable pour les API, l’authentification et le temps réel, avec les types de son propre schéma.⁶ La CLI de synchronisation des environnements permet d’exporter schéma et configuration, d’examiner les différences et de les appliquer à des instances compatibles, y compris dans une pipeline.⁷ Le serveur MCP expose, via le Model Context Protocol, données et opérations aux assistants IA en respectant les permissions de l’identité utilisée pour se connecter.⁸

Cela offre une liberté concrète : utiliser l’interface, écrire une intégration, lancer une commande ou travailler avec son propre agent dans son environnement. On choisit son mode d’interaction et retrouve le même modèle de données, avec les autorisations requises par chaque opération. L’IA entre dans un système qui possède déjà une structure et des règles.

Pour moi, « beau et pratique » comprend aussi un logiciel qu’une personne peut orchestrer, y compris par son agent. Je peux composer un flux, déléguer certaines étapes, contrôler le résultat et intervenir. L’automatisation devient une manière de mieux maîtriser le travail. Une DevEx soignée rend cela accessible dès aujourd’hui.

« Ce n’est qu’une galerie d’images »

Prenons une demande ordinaire : l’image principale d’un article doit devenir une galerie ordonnée. Nous ajoutons quelques vignettes déplaçables dans le formulaire. L’après-midi s’annonce tranquille.

Mais le modèle passe d’une référence unique à une relation avec plusieurs images et un ordre. Les articles existants doivent garder leur photo. API et templates doivent comprendre la nouvelle structure. Les permissions doivent permettre aux rédacteurs de gérer la relation sans ouvrir d’accès indésirable aux fichiers. Pendant ce temps, les rédacteurs continuent de travailler.

Nous pouvons avancer par étapes : ajouter la relation, convertir les références existantes en première image de chaque galerie, adapter les lectures puis retirer l’ancien champ. Pendant la transition, il faut aussi décider du traitement des nouvelles écritures : si quelqu’un change l’ancienne image après la migration initiale, cette modification doit atteindre la galerie. Une livraison compatible se conçoit aussi pour ce qui arrive pendant son déploiement.

Schéma, données, fichiers et code doivent fonctionner ensemble à chaque étape du changement. Ils peuvent évoluer à des moments différents, à condition qu’un parcours préserve leur compatibilité.

C’est pourquoi promouvoir le schéma du développement vers la production et transférer les contenus sont deux opérations distinctes.⁹ Revenir au code d’hier peut laisser le système cassé si les données ont été transformées entre-temps. Une sauvegarde de la base seule peut aussi être insuffisante : si elle référence des images supprimées du stockage, nous avons restauré des liens vers quelque chose qui n’existe plus.

D’une galerie, nous sommes passés à la reprise après sinistre. Il faut savoir quels fichiers conserver, quelles versions du code peuvent relire les données et comment relancer les intégrations sans répéter des actions déjà exécutées. Un courriel envoyé ou une opération sur un service externe ne revient pas en arrière avec la base.

C’est ici qu’intervient l’atelier construit autour du CMS : infrastructure, pipelines CI/CD, observabilité, exercices de restauration. Il permet de livrer dans un ordre précis, de distinguer une mauvaise permission d’un service arrêté et d’évaluer le travail qu’un incident pourrait faire perdre. Puis il y a les personnes : qui approuve le changement, qui intervient, qui sait pourquoi cette règle étrange existe.

Chez welance, notre cloud et les processus bâtis autour font partie de cette expérience collective. Ceux qui ont accompagné des CMS complexes emportent souvent toute une manière de travailler, bien moins visible qu’un écran.

L’IA peut aussi nous aider à écrire migrations, tests et procédures de reprise. L’expérience sert à savoir lesquels demander et si les vérifications démontrent réellement ce qui nous importe. Le prototype montre qu’une chose peut fonctionner ; le travail suivant établit à quelles conditions elle continuera.

Le C signifie contenu

J’ai parlé jusqu’ici d’articles et de photos. Mais un contenu peut aussi être une exigence, un bien immobilier, une disponibilité, une décision ou la relation entre un projet et une personne. Cette ouverture m’a toujours intéressé dans les CMS.

Un système assez souple peut devenir la base d’un logiciel immobilier, d’un CRM ou de parties d’un ERP. Il fournit déjà un lieu pour décrire les entités, les relier, attribuer des accès et construire des interfaces. On y ajoute la connaissance métier : une réservation doit empêcher les chevauchements même si deux demandes arrivent simultanément ; une décision comptable impose des contraintes qu’un article n’a pas.

Le CMS m’intéresse précisément comme réceptacle de ces possibilités. Une grande part du « logiciel de gestion » consiste à structurer les informations et permettre aux bonnes personnes d’agir dessus. Avec l’IA, un nouvel interlocuteur s’ajoute, capable de lire, proposer et agir. La qualité de la structure devient encore plus importante.

Quand la mémoire devient opérationnelle

Une mémoire partagée devient opérationnelle quand nous pouvons remonter d’une donnée à sa source, d’une décision à ses raisons et d’une action aux règles qui l’autorisent.

La connaissance devient rationnelle dans la mesure où nous pouvons la reconstruire et la vérifier. Une transaction enregistrée, une estimation et une conclusion du modèle doivent rester distinctes. Les règles de calcul et les liens doivent pouvoir être inspectés. Cette base permet à différentes personnes, avec différents agents, de travailler sur les mêmes faits et d’en discuter les interprétations.

J’y vois un lien avec la LLM Wiki proposée par Andrej Karpathy : un modèle lit les sources et entretient une connaissance persistante, faite de synthèses et de liens qui évoluent dans le temps.¹¹ Dans un CMS, nous pouvons la relier à des projets, des responsabilités et des états : quelle exigence est approuvée, qui peut la modifier, quelle tâche en dépend.

Les sources peuvent être un document, un enregistrement ou une photo. Les outils qui les interprètent doivent préserver leur provenance pour permettre à une personne de vérifier et corriger la synthèse. Le modèle peut changer ; données, décisions et relations doivent pouvoir rester. En ce sens, le système devient une partie de l’intelligence de l’entreprise.

Passer à l’action exige des autorisations précises. Lire une exigence ne donne pas automatiquement le droit de modifier le projet ou d’envoyer quelque chose à un client. Chaque connecteur doit vérifier l’action demandée et utiliser les identifiants appropriés sur le service externe. MCP offre une manière commune de relier les outils ; la correspondance des permissions entre systèmes reste à concevoir. Même une synthèse issue de documents confidentiels doit respecter ces limites.¹²

C’est l’évolution que j’imagine avec un AI Management System, ou AI MS : un outil de gestion où personnes et agents travaillent sur la même mémoire opérationnelle. Chacun peut interagir à sa manière, tandis que règles, responsabilités et historique restent vérifiables. Un nom de travail pour une direction qui me semble prometteuse.

Le CMS pourrait être la pièce à retirer

L’objection la plus sérieuse à ma thèse est que l’IA pourrait rendre données et règles plus importantes, et le CMS qui les rassemble moins nécessaire. Les responsabilités de la planche anatomique peuvent s’assembler autrement. Les compétences décrites appartiennent au génie logiciel. Les avoir apprises sur des CMS ne prouve pas qu’un CMS reste le meilleur choix.

Si construire des outils spécialisés coûte moins cher, l’intérêt de s’adapter à une plateforme généraliste change. On peut préférer une petite application conçue autour de son travail à un CMS chargé d’extensions. SDK, CLI et MCP soutiennent aussi cette alternative : ils rendent chaque produit accessible et composable sans lui attribuer forcément un rôle central.

Le modèle commun a lui aussi un coût. Un projet pour la planification et une mission pour la facturation peuvent avoir des frontières différentes. Le domain-driven design aborde justement cette pluralité, en délimitant les modèles et en explicitant leurs relations.¹³ Les forcer dans une structure unique peut créer des traductions fragiles, des copies périmées et un passage obligé pour chaque changement.

Une alternative raisonnable conserve les systèmes faisant autorité dans leurs domaines et les relie par des contrats explicites. L’agent coordonne les opérations ; les services continuent d’appliquer leurs règles. Le CMS peut rester là où les rédacteurs en ont besoin ou sortir entièrement de ce flux. Je dois envisager cette possibilité, notamment pour ne pas reconnaître dans l’avenir surtout l’outil que je connais le mieux.

Pour moi, le CMS mérite sa place quand relations, permissions et circuits éditoriaux communs représentent une part substantielle du travail. Si son usage impose de dupliquer des règles déjà fiables ailleurs et de maintenir des synchronisations continues, l’avantage peut disparaître. Le test concret consiste à imaginer le retirer : quelles responsabilités faudrait-il reconstruire, quelles intégrations supprimer, et combien serait-il plus difficile de comprendre ou réparer une erreur ? Le meilleur choix réduit le travail global tout en préservant les garanties nécessaires.

Les outils que j’aimerais utiliser demain

Cette perspective influence les outils qui m’attirent. L’approche de Railway m’intéresse, avec des services et environnements visibles dans le projet. Lovable part de la construction de l’application et propose aussi un backend géré avec base de données, authentification et stockage.¹⁴ Ce sont différentes façons de rendre accessible un système qui conserve ses dépendances sous la surface.

Je préfère les plateformes qui rendent ces dépendances compréhensibles et nous aident à les maîtriser. J’imagine la construction conversationnelle comme une capacité d’une plateforme plus large, qui accompagne le logiciel au-delà de sa première livraison.

J’aimerais demander « transforme cette image en galerie » et voir quelles données changeront, comment seront traitées les anciennes, quels services interviendront et où une approbation sera nécessaire. Je voudrais aussi connaître la reprise possible en cas de problème. Dessiner des composants sur un canevas est un bon départ ; la valeur réside dans la gestion du changement qui les traverse.

Le prochain CMS pourrait naître ici, ou de l’évolution d’outils existants. Ce qui m’importe, c’est qu’une personne puisse choisir son interface et son agent tout en travaillant sur une base partagée. La différence sera la capacité à accompagner une modification depuis l’intention de celui qui la demande jusqu’à ses conséquences sur le système.

Vive le CMS

Dans le monde des CMS aussi, beaucoup de travail se fait par habitude : installer un thème, empiler des extensions et livrer sans se demander comment le système tiendra. Avoir travaillé avec des CMS n’est pas, en soi, un signe de soin ou de compétence. La facilité des premiers pas peut encourager aussi bien la curiosité que la paresse.

En regardant ce que nous construisons aujourd’hui avec l’IA, je retrouve surtout une évidence : un bon logiciel reste un bon logiciel. Il se reconnaît à l’aide qu’il apporte aux personnes qui l’utilisent et à sa capacité à durer et à évoluer. Les noms, les sigles et la technologie du moment en disent peu à eux seuls.

À ceux qui construisent aujourd’hui leur outil de gestion avec l’IA, je laisserais quatre questions, celles que je continuerais à me poser :

• Quelles règles doivent rester vraies pendant que le système change ?
• Qui peut agir, sur quelles données et avec quelles conséquences ?
• Qu’avons-nous réellement essayé de restaurer après une erreur ?
• Que sauront les personnes qui arriveront après nous ?

Les CMS ont été le contexte dans lequel j’ai appris à me poser ces questions. J’emporte ce que j’y ai appris, y compris lorsque cela m’aide à choisir une autre architecture.

CMS is dead. Long live the CMS.