En bref
- Un CMS traditionnel stocke le contenu et construit la page. WordPress, Webflow et Wix fonctionnent ainsi.
- Un CMS headless ne fait que stocker le contenu. Le site qui l'affiche est un code à part : c'est plus rapide, et une seule source peut alimenter plusieurs écrans.
- L'IA prend la partie éditeur. Les builders pensés autour d'un chat comme Lovable ont grandi très vite, et les CMS ont répondu avec des MCP qui permettent de modifier le site depuis Claude ou ChatGPT.
- Vous n'avez peut-être pas besoin de CMS du tout, si vous êtes une petite équipe tech. Vous en avez besoin avec des données en temps réel, des milliers de pages, ou des personnes qui ne doivent jamais toucher à GitHub.
Khod est une agence partenaire certifiée Webflow. En juillet, elle a migré son propre site de 180 pages hors de Webflow, vers Next.js et Sanity.
Deux mois plus tard, à la Webflow Conf de Boston, Webflow a présenté Source : une nouvelle plateforme où le site vit dans le code. L'éditeur visuel qui a fait la réputation de Webflow n'est plus au centre de son propre produit.
Webflow était l'outil que tout le monde citait comme précurseur. Sur l'IA, il a eu beaucoup de mal à s'imposer sur les sujets agentiques, et Source ressemble à sa réponse.
Webflow était la stack parfaite pour un site tech : un éditeur visuel, un CMS, l'hébergement. L'IA est en train de prendre la partie éditeur. La question mérite donc d'être reposée pour le reste : a-t-on encore besoin d'un CMS aujourd'hui ? Et si oui, headless ou traditionnel ?
Comment les CMS ont évolué, et pourquoi on en a eu besoin
Pour comprendre la situation actuelle, il faut comprendre dans quel contexte les CMS sont apparus et comment les exigences du web ont changé.
Le web statique (années 1990)
Au tout début du web, les sites sont complexes à créer et à maintenir. Pour modifier une phrase, il faut ouvrir le fichier de la page, modifier le HTML et le renvoyer sur le serveur par FTP.
Autrement dit, même une petite modification passe par le développeur.
Oui, c'est bien le site d'Apple.
La révolution WordPress (2003)
WordPress arrive en 2003 et sépare le design (les thèmes, puis les page builders Divi et Elementor) du contenu, désormais stocké dans une base de données.
C'est cette séparation qui permet à des non-techniciens de publier sur un site sans passer par les développeurs. C'est le CMS : le Content Management System, ou système de gestion de contenu.
Les CMS modernes (de 2006 aux années 2010)
Mais WordPress produit des sites lents, et gérer un serveur reste compliqué pour la plupart des gens.
De nouvelles solutions plus rapides, plus modernes et qui gèrent le serveur pour vous apparaissent : Wix et Shopify en 2006, puis Webflow en 2013. Même philosophie, avec une meilleure expérience pour la personne qui modifie le site.
Les CMS headless et les sites statiques (depuis les années 2010)
Puis le trafic sur smartphone explose, la vitesse de chargement compte encore plus, et les bases de données des CMS sont jugées trop lentes. Deux nouvelles catégories apparaissent.
- Le CMS headless. On sépare de nouveau le front-end et le back-end. Strapi, Contentful et Sanity fonctionnent ainsi, et WordPress a aussi une version headless. Concrètement : le CMS garde le contenu, et le site qui l'affiche est un code à part.
- Le générateur de site statique (SSG). Toutes les pages du site sont générées à l'avance, donc elles s'affichent instantanément, comme dans les années 90, mais avec des outils modernes (Astro, ou des frameworks comme Next.js et Nuxt qui savent aussi le faire). C'est comme imprimer chaque page une fois pour toutes au lieu de l'assembler à chaque visite. Personne n'attend la base de données, puisqu'il n'y a plus rien à assembler.
Voilà le cœur du match CMS headless vs CMS traditionnel : dans un CMS traditionnel, un seul système stocke le contenu et construit la page. Dans un CMS headless, le système ne fait que stocker le contenu, et chaque front-end a son propre code.
Ce que l'IA change pour les CMS
Depuis l'arrivée de l'IA, les outils pour gérer un site web se sont répartis en deux groupes.
1. Les AI natives
Ce sont des entreprises qui construisent leur produit autour d'un chat, ou qui le transforment complètement dans ce sens. Le chat est l'expérience par défaut. On peut toujours modifier le reste, mais le chat est l'élément principal : ce sont eux qui se rapprochent le plus de ChatGPT.
Dans ce groupe :
- Les site builders qui ne demandent aucune expérience. Lovable, le plus connu, dit avoir dépassé 500 millions de dollars de revenu annualisé en juin, avec un million de nouveaux projets par semaine.
- Les outils de code avec IA. Pour les profils plus expérimentés, des outils comme Cursor, Claude ou Codex permettent de travailler directement dans tout son code et de voir une vraie interface.
2. Ceux qui ont dû s'adapter
- Les CMS et les CMS headless. Ces entreprises ont gardé leur produit tel quel et ont ajouté un MCP par-dessus.
Un MCP est un connecteur : vous demandez la modification dans Claude ou ChatGPT, et elle arrive dans votre CMS sans que personne n'ouvre le CMS. Webflow et WordPress en ont un. Webflow annonce que plus de 30 % de ses clients entreprise utilisent son MCP.
Ce que je fais aujourd'hui : un site web sans CMS
Pour mes propres projets, je préfère clairement le premier groupe, les AI natives. Et pour ça, je n'ai même pas besoin de CMS.
Pour tout gérer, les IA utilisent un format qui date de 2004 : le Markdown. C'est le format dans lequel les grands modèles de langage (ChatGPT, Claude ou les modèles locaux) rédigent nativement. C'est du texte simple avec quelques symboles : au lieu d'écrire <h1>Mon titre</h1>, on écrit # Mon titre. Un humain peut le lire, une machine aussi.
Voici comment Web Anatomy est organisé :
- Une partie du code est en React, avec les composants et les templates de pages (
/app). - L'autre partie, ce sont des fichiers Markdown (du MDX, pour être précis), le format des IA (
/content). - Une base de connaissance contient mes bonnes pratiques et mon historique. J'utilise Obsidian, mais Notion marche tout aussi bien. Elle aussi est en Markdown, et reliée au site et à la documentation.
- Un fichier
AGENTS.mdà la racine du projet. L'IA le lit avant d'écrire quoi que ce soit.
Concrètement, quand je demande 10 pages produit, l'IA crée 10 fichiers Markdown, les enregistre, applique le design et les déploie en quelques minutes. Le texte est traité avec la même rigueur et les mêmes outils d'automatisation que le code. En septembre 2026, cela représentait 322 fichiers Markdown sur Web Anatomy, en anglais et en français.
Je peux créer des milliers de pages, les traduire instantanément et les modifier très vite. Je ne pense pas pour autant que cet usage doive devenir la norme pour tout le monde.
A-t-on besoin d'un CMS ? Quatre questions à se poser
J'utilise pour mon site la stack la plus agile que je connaisse pour publier et itérer. Je ne la recommanderais pas à tout le monde. Posez-vous ces quatre questions avant de vous passer de CMS, pour votre site ou celui d'un client :
1. Avez-vous des dépendances externes ? Si vous avez besoin de données en temps réel, d'une API connectée comme Firebase, ou d'un e-commerce où le stock doit être à jour, il vous faut un CMS ou du sur-mesure.
2. Combien de pages avez-vous ? On ne gère pas un site de 20 à 30 pages comme un site de plusieurs milliers de pages. Au-delà de quelques milliers, les fichiers deviennent beaucoup plus difficiles à maintenir. Sanity, un CMS headless, l'a dit sans détour quand Cursor est passé au Markdown : ces fichiers « fonctionnent pour de petits volumes de données. Ils deviennent un cauchemar à maintenir à grande échelle. »
3. Votre équipe est-elle à l'aise avec le format ? Le Markdown est le fichier commun entre l'humain, le code et l'IA. Mais tout le monde ne travaille pas dans la tech. Une entreprise locale qui n'est pas dans la bulle de l'IA n'aura pas envie de passer par ce type d'interface, et préférera une interface claire et simple à utiliser.
4. Qui a accès au site ? Cette stack fonctionne quand une petite équipe touche au site. Si chaque correction de faute de frappe demande un commit sur GitHub, une compilation de tout le code et la validation d'une PR, c'est disproportionné. Le CMS a été inventé pour rendre les équipes autonomes, et il ne faut pas revenir en arrière là-dessus.
Voici quand je choisirais chaque option :
| Site builder | CMS | CMS headless | SSG + Markdown | |
|---|---|---|---|---|
| Exemples | Wix, Lovable | WordPress, Webflow | Sanity, Contentful, Strapi | Astro, Next.js |
| Pour qui | Artisans, petites entreprises, restaurateurs | Équipes marketing non techniques | Équipes tech avec un gros site et plusieurs éditeurs | Fondateurs solo et petites équipes tech |
| Pages | Quelques-unes | Des dizaines à des centaines | Des milliers | Des dizaines à des centaines |
| Qui modifie | Le propriétaire | Plusieurs personnes non techniques | Les éditeurs dans le CMS, les développeurs dans le code | Vous et votre IA, via GitHub |
| Ce que vous obtenez | Un site rapidement, un abonnement mensuel avec l'hébergement | L'autonomie de l'équipe, un MCP pour modifier avec l'IA | La vitesse et une vraie interface d'édition | Un contrôle total, des pages créées par l'IA en quelques minutes |
Un dernier critère à côté : beaucoup de CMS et de CMS headless ont maintenant un MCP, donc même une équipe sur un CMS traditionnel peut modifier son contenu en langage naturel depuis un chat.
Le site web compte plus que jamais, et il va bien au-delà du « site vitrine ». Choisissez la stack que votre équipe peut vraiment modifier.
Identifiez les opportunités de revenus de votre site, étayées par des données réelles. Recevez vos 3 opportunités gratuites par email.
Adapté de CMS, headless CMS or nothing?, publié dans la newsletter Web Anatomy le 23 septembre 2026.
Écrit par
Gabriel Amzallag , Fondateur, Web Anatomy
5 ans CRO + SEO chez Qonto (2021–2025). Après avoir conseillé 15+ SaaS sur leurs sites (Payfit, Pigment…), les mêmes patterns cassaient — alors j'ai décidé de construire la source de vérité sur ce qui fonctionne sur le web : la couche d'intelligence que chaque outil, builder et équipe utilise pour créer des sites qui performent.
À lire aussi
Playbooks
Nous avons analysé les publicités des plus gros éditeurs de logiciels RH. Voici ce qui fonctionne.
Les publicités des logiciels RH qui ont duré en 2026, les huit angles qu'elles utilisent et les pages derrière elles. Les enseignements, avec les publicités à regarder.
Gabriel Amzallag29 min de lecturePlaybooks
Nous avons analysé les publicités des plus gros logiciels marketing. Voici ce qui fonctionne.
Les publicités des logiciels marketing qui durent en 2026, les angles qu'elles utilisent et les pages derrière elles. Sept angles qui tiennent, cinq que presque personne n'utilise.
Gabriel Amzallag24 min de lectureGuides
SEO programmatique : le guide pratique, de 10 pages villes à 300
Comment Staycation est passé de 10 pages villes faites à la main à 300 grâce au SEO programmatique, avec 90 % d'achats en plus venus du référencement : trouver ses sujets, quatre règles, le template, produire et mesurer.
Gabriel Amzallag13 min de lecture