Depuis que les assistants de code sont devenus vraiment efficaces, on voit revenir une idée assez simple : « Puisque l’IA peut générer un site, autant faire mon CMS moi-même. » Sur le papier, c’est séduisant. En pratique, le sujet n’est pas la capacité à produire du code rapidement, mais la capacité à assumer le produit dans la durée : maintenance, sécurité, évolutivité, portabilité… et surtout un point souvent sous-estimé : où vivent tes contenus.

Dans cet article, je compare trois approches que l’on retrouve souvent pour un blog / site de contenus :

  • WordPress (CMS classique + base de données)
  • Approche “codevibe” (pas de base de données, les articles sont dans le dépôt du site)
  • CMS maison minimal, bien cadré (fonctionnel, sans chercher à “refaire WordPress”)

L’objectif n’est pas de dire « il y a une vérité », mais de clarifier les compromis, en particulier quand tu utilises l’IA au quotidien.

Le vrai sujet : l’IA accélère l’exécution, pas la responsabilité

L’IA change beaucoup de choses, mais elle ne change pas ce point : tu restes responsable de ce que tu mets en production. Générer une structure, un CRUD, un thème, une API ou un backoffice est devenu plus rapide. En revanche, le coût d’un mauvais choix se paie toujours plus tard, et l’IA ne “porte” ni la dette technique, ni les risques de sécurité, ni les migrations.

Autrement dit, elle peut te faire gagner du temps sur la construction, mais elle ne t’épargne pas le travail d’architecture.

Le critère le plus important : où vivent tes articles ?

Quand on parle de site de contenus, on pense vite à l’éditeur, au design, au SEO. Pourtant, le choix central est souvent ailleurs : dans la séparation (ou non) entre le code et le contenu.

  • Si tes articles vivent dans une base, tu peux les exporter, les migrer, changer le code sans toucher au contenu, et inversement.
  • Si tes articles vivent dans le dépôt, ton contenu devient une partie du code : ça peut être très confortable au début, et très contraignant quand le volume augmente, quand tu refactors, ou quand tu veux déléguer.

Avec l’IA, il y a un effet secondaire : plus le dépôt grossit (code + articles), plus tu es tenté d’injecter du contexte, et plus tu peux te retrouver avec un “coût” (en temps, en complexité, en confidentialité) qui augmente sans que tu t’en rendes compte. Ce n’est pas forcément bloquant, mais c’est un paramètre réel.

Option A — WordPress (base de données + écosystème)

WordPress reste, objectivement, l’outil le plus efficace si ton besoin principal est de publier et de gérer du contenu avec un environnement complet.

Quand WordPress est un bon choix

WordPress est particulièrement adapté si :

  • tu veux une interface d’administration mature, multi-utilisateurs, avec gestion des médias,
  • tu veux pouvoir déléguer facilement (rédaction, corrections, publication),
  • tu as besoin d’un écosystème de fonctionnalités prêtes à l’emploi (SEO, cache, formulaires, etc.),
  • tu acceptes une couche de complexité en échange de cette vitesse de mise en place.

Les limites à avoir en tête

Le revers est connu : WordPress peut devenir “lourd” selon les cas. Ce n’est pas une insulte, c’est une réalité structurelle :

  • surface d’attaque plus grande (parce que l’écosystème est vaste),
  • dépendances (plugins/thèmes) qui peuvent introduire de la dette,
  • mises à jour et compatibilités à suivre.

Pour un site simple, cette puissance peut être disproportionnée. Pour un site éditorial vivant (multi-auteurs, fonctionnalités), elle est souvent justifiée.

Option B — “Codevibe” sans base de données (articles dans le code)

J’appelle ici “codevibe” une approche très code-first : pas de base de données, le site est un projet (PHP, JS, autre) et les articles vivent dans le dépôt (fichiers Markdown, fichiers PHP, JSON, etc.). C’est propre, rapide, et très agréable quand on aime versionner.

Pourquoi c’est tentant

Cette approche coche beaucoup de cases au départ :

  • déploiement simple,
  • performances souvent bonnes,
  • aucune dépendance à un backoffice,
  • tout est versionné, donc reproductible.

Pour un petit site, ou un site vitrine enrichi de quelques articles, c’est souvent suffisant et même très confortable.

Le point qui finit par coûter

Le problème arrive quand le contenu devient un “vrai” contenu :

  • le dépôt grossit, et les refactors deviennent plus délicats (tu touches au code et aux articles),
  • la séparation des rôles est plus difficile (rédiger = toucher au repo),
  • la portabilité “contenu” est moins naturelle (tu exportes un projet, pas une base),
  • et dans un contexte où tu utilises l’IA, tu peux te retrouver à multiplier les échanges et le contexte à fournir pour conserver de la cohérence.

Ce n’est pas un modèle “mauvais”. C’est un modèle qui exige de rester lucide sur le fait que ton contenu est littéralement dans la même boîte que ton application.

Option C — CMS maison minimal, bien cadré (contenu dissocié du code)

Pour aller plus loin : j’avais déjà abordé ce dilemme (homemade vs framework vs CMS) dans un article plus général :
Homemade, Framework ou CMS ?
Ici, je le reprends avec le prisme IA + séparation code / contenu.

C’est la voie la plus intéressante quand tu veux éviter la lourdeur perçue de WordPress sans tomber dans le piège du contenu embarqué dans le code.

L’idée n’est pas de refaire WordPress. L’idée est de construire un CMS minimal qui fait très bien ce dont tu as besoin :

  • créer / modifier / publier,
  • catégoriser / tagger,
  • gérer les médias (si nécessaire),
  • indexer et rechercher,
  • exporter / sauvegarder.

Et surtout : garder le contenu séparé du code (souvent via une base de données, ou au minimum un stockage de contenu structuré, exportable).

Pourquoi ça marche bien (si c’est vraiment minimal)

Un CMS maison bien cadré peut être très sain :

  • tu maîtrises la surface fonctionnelle (donc tu maîtrises la maintenance),
  • tu évites l’empilement “plugins / thèmes / compatibilités”,
  • tu peux faire évoluer le code sans casser tes contenus,
  • tu peux concevoir des exports propres (HTML, JSON, Markdown) et donc migrer sereinement.

Le point important est le cadrage : si tu commences à vouloir ajouter un builder, un marketplace de plugins, des workflows complexes, tu recrées mécaniquement les problèmes d’une plateforme.

Comparaison stratégique (CMS maison minimal)

Critère WordPress Codevibe (articles dans le dépôt) CMS maison minimal
Mise en ligne rapide ⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐
Simplicité pour publier (non-dev) ⭐⭐⭐⭐ ⭐⭐⭐⭐ (à voir si bcp d'articles) ⭐⭐⭐ (dépend du niveau du backoffice)
Contenu séparé du code ⭐⭐⭐⭐ ❌ ⭐⭐⭐⭐
Maintenance long terme ⭐⭐ à ⭐⭐⭐ (selon plugins/MAJ) ⭐⭐ (si le dépôt grossit) ⭐⭐⭐⭐
Contrôle technique ⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐
Évolutivité “sur mesure” ⭐⭐⭐⭐ ⭐⭐ ⭐⭐⭐⭐

Ce tableau ne dit pas « WordPress est mauvais » ou « le codevibe est mauvais ». Il dit simplement : si ton objectif est un blog durable, la question de la séparation code / contenu est un pivot, et le CMS maison minimal a un avantage clair sur ce point.

Ma recommandation pragmatique

Si tu débutes ou si tu veux publier vite sans te poser trop de questions, WordPress est une solution très solide, surtout si tu veux déléguer et bénéficier d’un écosystème.

Si ton site est très petit, très technique, et que tu assumes un site “dans le dépôt”, l’approche codevibe peut être parfaite, à condition d’accepter que le contenu suivra le cycle du code.

Si tu veux un compromis durable, et que tu es prêt à investir un peu au départ pour être plus serein ensuite, je privilégie le CMS maison minimal : pas une usine à gaz, pas un clone de WordPress, mais un outil simple, maintenable, et surtout construit autour d’un principe sain : le contenu vit ailleurs que le code. Le site sera personnalisé et personnalisable sans dépendences externes (sans plugins payants par exemple) suivant votre niveau à gérer une IA pour développer un vrai CMS.

Pour finir

L’IA rend la création plus rapide, mais elle ne rend pas les mauvais choix “gratuits”. Dans un projet de contenu, le piège classique est de raisonner uniquement en vitesse de mise en ligne, alors que le vrai coût se révèle plus tard : maintenance, migrations, refonte, transmission, et cohérence éditoriale.