Je ne voulais pas d’un autre CMS générique greffé sur mon site. D’après mon expérience, ce type de configuration crée toujours des frictions. Je voulais un mcp cms qui ressemble à une partie du produit, pas à un système externe contre lequel je dois me battre chaque jour.
Cet article explique comment j’ai construit mon mcp cms avec Next.js, Supabase, MCP et agent flows. Je couvre l’architecture, la couche d’outils, le tableau de bord d’administration et le pipeline de contenu afin que vous voyiez comment l’ensemble du système fonctionne concrètement.
Pourquoi j’ai construit un MCP CMS plutôt que d’utiliser une stack headless générique
J’ai construit le site et le CMS dans la même application Next.js parce que je voulais un seul codebase, un seul modèle de données et un seul flux de publication. J’ai utilisé suffisamment de stacks déconnectées pour savoir à quelle vitesse elles se transforment en dette de maintenance. Quand le front-end, le CMS et la couche d’automatisation vivent dans des endroits séparés, chaque changement coûte plus de temps que ce qui devrait être nécessaire.
Mon mcp cms garde le site public, l’interface d’administration, les routes API et les outils d’IA à l’intérieur d’une même frontière produit. Cela signifie que je peux modifier les métadonnées SEO, la localisation ou la logique d’un article sans passer d’un système à l’autre. J’évite aussi le problème habituel de “sync”, où le contenu vit dans un outil tandis que la logique réelle vit ailleurs.
En pratique, cela m’a donné des itérations plus rapides et moins de bords cassés. Le système est aussi plus facile à observer, parce que chaque action d’écriture passe par la même couche. Si vous voulez plus de contexte sur ma façon de penser les systèmes de contenu opérationnels, mon article sur Multi-Agent Content Pipeline in Next.js With Search Console montre la partie recherche de ce workflow.
L’idée centrale derrière le système
L’idée centrale est simple : le CMS doit se comporter comme un produit, pas comme un générateur de formulaires. Je voulais du contenu typé, des écritures contrôlées, et une couche d’automatisation capable de m’aider à publier plus vite sans perdre la supervision. C’est pour cela que j’ai gardé l’architecture stricte et les frontières clairement définies.
Ce que j’ai changé par rapport à un CMS traditionnel
Un CMS traditionnel sépare généralement l’édition du contenu du code du produit. Cela peut sembler flexible, mais cela ralentit souvent les équipes quand le site devient plus sur mesure. Mon mcp cms supprime cette séparation. Je peux désormais gérer le contenu, le SEO et la logique de workflow au même endroit, ce qui me donne plus de levier avec moins de surcharge.
Comment le MCP CMS utilise MCP comme couche de contrôle
La décision la plus importante a été de placer MCP au milieu du système. Je ne voulais pas que les fonctionnalités IA soient enfermées dans une seule fenêtre de chat ou dans un seul tableau de bord. Je voulais une couche de commandes réutilisable qui puisse parler aux mêmes règles backend depuis différents clients.
C’est pourquoi j’ai construit à la fois un serveur MCP autonome et une route MCP dans l’application. Les outils exposés via le mcp cms incluent CRUD de blog, publication, analyse SEO, génération d’articles, recherche, génération d’images et vérifications de sitemap. En d’autres termes, la couche agent ne devine pas quoi faire. Elle appelle de vrais outils avec un vrai état.
Cette approche s’aligne avec la spécification Model Context Protocol et avec la façon dont j’aime structurer les systèmes internes : un contrat, plusieurs clients, pas de duplication. Elle a aussi rendu facile la réutilisation des mêmes actions dans le tableau de bord d’administration et depuis des clients MCP externes.
Outils que j’ai exposés via MCP
La surface d’outils est volontairement large. Je voulais que les agents fassent un travail utile, pas seulement discuter.
La conception de ces outils est l’épine dorsale du mcp cms. Elle rend le système composable et rend chaque opération observable.
Pourquoi cette architecture compte dans le travail réel
Dans mon travail de création de sites et de systèmes de contenu, le plus gros goulot d’étranglement n’est que rarement l’écriture. Le goulot, c’est la coordination. MCP réduit ce coût de coordination parce que la même action peut être appelée depuis le tableau de bord, l’interface de chat ou un autre agent flow. Résultat : je passe moins de temps à répéter des étapes et plus de temps à améliorer le rendu.
Le tableau de bord d’administration transforme le MCP CMS en salle de contrôle
Je ne voulais pas que la zone d’administration ressemble à un écran CRUD ennuyeux. Je l’ai construite comme une salle de contrôle. Elle inclut la gestion des articles pour les brouillons, les traductions, les images, le SEO et la publication, ainsi qu’une couche opérationnelle où je peux exécuter des workflows d’IA et les suivre pendant qu’ils avancent.
Dans le tableau de bord, le chat MCP expose les mêmes outils de contenu que le reste du système. Je peux lister les articles, inspecter un brouillon, déclencher une analyse SEO, lancer une recherche, ou exécuter le pipeline complet avec une demande en langage naturel. La partie importante, c’est que le chat n’est pas magique. Il s’appuie sur les mêmes actions typées que le reste du mcp cms.
Ce design fait gagner du temps dans la pratique. Je n’ai pas besoin de reconstruire des interfaces pour chaque nouveau workflow. J’expose simplement un outil supplémentaire ou un autre chemin de contrôle. Si vous voulez voir comment je pense l’automatisation au niveau du système, How I Built My CMS With MCP and Agent Flows est l’article plus général autour de cette configuration.
Ce que je peux faire depuis le tableau de bord
Le tableau de bord me permet d’aller vite sans perdre le contrôle.
Pourquoi j’utilise une salle de contrôle plutôt qu’un simple éditeur
Un éditeur simple fonctionne quand vous n’avez besoin que d’écrire et de publier. J’avais besoin de plus. Je voulais un endroit où je pouvais observer les workflows, approuver les changements et intervenir quand un modèle s’écarte de la trajectoire. C’est la vraie valeur du mcp cms : il me donne un contrôle opérationnel, pas seulement une saisie de contenu.
Comment le MCP CMS Agent Flow fonctionne réellement
Le agent flow n’est pas un seul prompt géant. Je le découpe en étapes pour pouvoir contrôler la qualité à chaque moment. Cela compte parce que le travail de contenu est “sale”. La recherche, le SEO, la structure et l’édition nécessitent chacun un raisonnement différent.
Voici le flow que j’utilise le plus souvent :
J’ai testé ce flow à plusieurs reprises parce que je ne voulais pas un pipeline de démo fictif. Je voulais un système où une étape peut renvoyer des retours vers une autre étape. Cette boucle de feedback est une des raisons pour lesquelles le mcp cms fonctionne mieux qu’un assistant d’écriture en une seule passe.
Pourquoi je découpe le flow en étapes
Chaque étape résout un problème différent. La recherche réduit les hallucinations. Le SEO affine la structure. L’édition protège la qualité. La publication nettoie la sortie finale. En séparant ces tâches, on rend l’ensemble du système plus fiable et plus facile à améliorer au fil du temps.
Comment j’empêche les agents de dériver
Je garde les agents sous contrôle avec des entrées typées, des sorties explicites et des vérifications de qualité. Cela me donne un meilleur résultat qu’une chaîne de prompts vague. Cela rend aussi les échecs plus faciles à diagnostiquer, ce qui compte quand vous comptez sur l’automatisation pour un travail de production.
Search Console rend le MCP CMS plus intelligent
L’une des parties les plus solides du système, c’est que je ne me repose pas uniquement sur des prompts. Je branche les données de Search Console dans le processus de recherche, de sorte que les agents travaillent à partir de signaux de demande réels plutôt que d’hypothèses. Cela améliore l’étape de sélection des sujets et m’aide à prioriser un contenu qui peut réellement se positionner.
La couche Search Console stocke des snapshots dans Supabase et calcule des opportunités de mots-clés, des pages à faible CTR et des manques de contenu. J’utilise ces informations dans le mcp cms pour orienter à la fois la recherche et le SEO. Cela signifie que le système ne fait pas que générer des articles. Il m’aide à prendre de meilleures décisions de publication.
La propre documentation Search Console de Google confirme pourquoi c’est important : les données de performance de recherche doivent guider l’optimisation, pas seulement l’intuition. J’applique directement ce principe dans le pipeline.
Ce que la couche de données m’apporte
Pourquoi les données battent l’intuition ici
J’aime le travail créatif, mais la stratégie de contenu a besoin de preuves. Quand j’utilise les signaux de Search Console, je peux voir quelles pages ont besoin d’aide et quels sujets méritent de nouveaux articles. Le mcp cms devient alors bien plus utile qu’un panneau d’administration statique.
Pourquoi je sépare les chemins de lecture et les chemins d’écriture
J’ai intentionnellement séparé le côté lecture et le côté écriture du blog. Les pages publiques ne lisent que via la couche de contenu, tandis que les actions d’administration écrivent via la couche de mutation. Cela maintient le rendu rapide et la publication sûre.
Cette séparation compte parce que chaque côté a un rôle différent. La couche de lecture a besoin de cache, de métadonnées et d’un comportement de repli propre. La couche d’écriture a besoin d’authentification, de validation et de mutations contrôlées. Dans le mcp cms, les deux couches partagent les mêmes contrats, mais elles ne se mélangent jamais.
Cette séparation rend aussi les interfaces futures plus faciles à ajouter. Si je construis un autre tableau de bord, ou si je connecte un autre client MCP, je n’ai pas besoin de redessiner tout le système. Je pointe simplement de nouveaux outils vers la même frontière d’écriture.
Ce que cette séparation protège
Pourquoi je préfère cette structure
J’ai vu des systèmes échouer parce que tout parle à tout. Cette architecture réduit ce risque. Elle donne au mcp cms un cœur stable et garde le produit facile à faire évoluer.
Résultats concrets et compromis pratiques
Le résultat le plus important n’était pas un tableau de bord sophistiqué. C’était le levier. Je peux maintenant passer d’une idée à un plan validé par la recherche, puis à un brouillon, puis à une revue SEO, sans rebondir entre des outils. Cela fait gagner du temps et conserve le contexte.
J’obtiens aussi une meilleure visibilité sur ce que fait le système. Je peux suivre le pipeline, inspecter les décisions des agents et ajuster le flow quand il le faut. Cela compte plus que la vitesse brute de l’automatisation. Un bon mcp cms devrait renforcer votre processus, pas le rendre plus opaque.
Il y a toutefois des compromis. Un système sur mesure demande plus d’efforts d’ingénierie qu’un CMS prêt à l’emploi. Vous gérez les bugs, les fonctionnalités et la maintenance. Pour moi, ce coût en vaut la peine parce que le workflow correspond à mon site et à ma stratégie de contenu.
Ce que j’ai gagné
Ce que j’ai encore à gérer
Comment je pense désormais les systèmes d’exploitation de contenu
Ce projet a changé ma façon de voir l’infrastructure de contenu. Je ne vois plus le logiciel CMS comme un endroit pour stocker des articles. Je le vois comme un système d’exploitation pour la création de contenu, la revue et la publication. C’est ce changement de mentalité qui fait que ce mcp cms me semble utile plutôt que décoratif.
Si vous construisez quelque chose de similaire, commencez par le workflow. Ensuite, définissez la frontière d’écriture. Après cela, ajoutez des outils MCP uniquement pour les actions qui méritent d’être automatisées. Cet ordre garde le système sain.
Je recommande aussi de lire mes articles liés sur AI agents, scaling e-commerce with Next.js, et my SEO dashboard. Ces éléments expliquent les briques de construction derrière cette configuration et montrent comment les morceaux s’assemblent.
Conclusion
Les leçons principales de cette construction sont simples :
J’ai construit ce mcp cms pour me donner du levier, une meilleure visibilité et un workflow de publication plus propre. Si vous concevez votre propre système de contenu, commencez par le workflow, puis façonnez les outils autour de celui-ci.
Si vous voulez, lisez les articles liés ci-dessus ou laissez un commentaire avec la façon dont vous structureriez votre propre CMS.