Sur quoi faire tourner un site web en 2026

Pendant des années, choisir un système de gestion de contenu était une affaire de personnes : qui, dans l’entreprise, modifierait le site web, et quels dégâts cette personne pourrait y faire. En 2026, un second lecteur s’y ajoute. Assistants et agents de code écrivent désormais des pages, les traduisent et les modifient, et chaque type de système est repensé, ou vendu, en fonction de la manière dont il travaille avec eux. Voici où en est le marché, ce que l’IA a changé dans chacun de ses recoins, et comment nous choisirions.

WordPress, toujours le choix par défaut

Selon les chiffres de W3Techs au 13 octobre 2026, WordPress fait tourner 40,1 pour cent de tous les sites web, et 58,6 pour cent des sites dont W3Techs peut identifier le système. Suivent Shopify avec 5,4 pour cent, Wix avec 4,2 et Squarespace avec 2,4. Près d’un tiers de tous les sites, 31,6 pour cent, ne présentent aucun système de gestion de contenu que W3Techs puisse détecter.

WordPress a fait entrer l’IA dans son noyau. La version 7.0, publiée le 20 mai, a ajouté un AI Client qui permet à un site de dialoguer avec des modèles génératifs, les connexions étant gérées depuis un seul écran, et l’associe à l’Abilities API, par laquelle les extensions décrivent ce qu’elles savent faire. Une extension IA optionnelle rédige titres et extraits, génère et retouche des images et propose des textes alternatifs.

L’ancien fardeau demeure. Patchstack a recensé 11'334 nouvelles vulnérabilités dans l’écosystème WordPress en 2025, soit 42 pour cent de plus qu’en 2024. 91 pour cent se trouvaient dans des extensions et six seulement dans le noyau, et 46 pour cent n’avaient pas de correctif prêt au moment de leur divulgation.

Le conflit au sommet n’est pas réglé non plus. Il a éclaté en septembre 2024, lorsque Matt Mullenweg, qui dirige le projet et la société Automattic, a publiquement critiqué l’hébergeur WP Engine, lui reprochant de trop peu contribuer, et l’a coupé de WordPress.org. WP Engine a porté plainte en octobre, et en décembre, un tribunal a ordonné le rétablissement de son accès. Le 28 septembre 2026, Search Engine Journal a rapporté que la juge avait autorisé la poursuite des quatre plaintes antitrust de WP Engine, tandis que les demandes reconventionnelles d’Automattic subsistent elles aussi, au moins en partie. Deux ans plus tard, toujours pas d’issue, seulement une affaire qui s’allonge.

Headless, et pensé pour les agents

Un CMS headless sépare le contenu du site web : des entrées structurées dans un seul référentiel, livrées par une API à un site, à une application ou à tout ce qui les demande. Sanity, Contentful, Storyblok et Payload sont les noms les plus connus. W3Techs situe Sanity, Storyblok et Payload chacun sous les 0,1 pour cent des sites web, mais ce type de comptage les repère mal, car un système headless laisse peu de traces sur la page finale.

L’IA a offert un nouvel argument à ces systèmes. En mars, le directeur général de Sanity, Magnus Hillestad, écrivait : « Le contenu est devenu du contexte. Et le contexte est devenu une infrastructure. » Les agents qui répondent aux clients ou donnent des prix ont besoin de faits exacts, avance-t-il, pas de pages à interpréter, et le contenu devrait leur parvenir par des API et des serveurs MCP autant que par des sites web. C’est le texte d’un fournisseur, mais d’après notre expérience, l’argument tient : un agent travaille bien mieux avec des champs propres qu’avec une page de texte mis en forme.

Le secteur se consolide aussi. En juin 2025, Payload, un CMS open source conçu pour Next.js, a rejoint Figma. Payload affirme rester open source et pouvoir toujours être auto-hébergé.

Des constructeurs qui partent d’une phrase

Les constructeurs de sites se partagent une bonne partie du reste : Wix et Squarespace pour les petites entreprises, Webflow à 0,8 pour cent et Framer à 0,2 pour cent pour les équipes portées par le design, la plupart désormais dotés d’une IA qui ébauche mises en page et textes. Un groupe plus récent part d’une description plutôt que d’un modèle, et Wix en possède aujourd’hui un, Base44.

En août, Wix a indiqué que Base44 portait la croissance de son chiffre d’affaires, mais aussi que l’outil avait entamé l’année avec une marge brute ajustée proche de zéro. Son propre modèle, Base 1, doit réduire le coût de fonctionnement de l’IA, et Wix table sur une marge d’environ 60 pour cent au second semestre. Pour un acheteur, c’est un signal utile. À notre avis, ces constructeurs sont le chemin le plus rapide vers un premier site, et leurs prix suivront la puissance de calcul qui les fait tourner. Avant que le site ne grandisse, vérifiez ce que vous pouvez emporter avec vous.

Pas de CMS du tout

À l’autre extrémité, certaines équipes ont abandonné le CMS. En décembre 2025, Lee Robinson, qui travaille chez Cursor, a fait passer cursor.com d’un CMS headless à du code pur et à des fichiers Markdown. Il comptait sur une à deux semaines. Avec des agents, il lui a fallu trois jours, 344 requêtes d’agent et 260,32 dollars de tokens.

Sa raison : « Avec l’IA et les agents de code, le coût d’une abstraction n’a jamais été aussi élevé. » Dans un dépôt, un agent peut modifier n’importe quel fichier. Derrière un CMS, il doit passer par l’interface de quelqu’un d’autre.

Sanity, le système qu’il a quitté, a répondu qu’il en avait reconstruit un : un écran pour gérer images et fichiers, une gestion des utilisateurs par les permissions GitHub, un contrôle de version par git, des outils de localisation et un modèle de contenu dans le front matter Markdown. « Le paradoxe, c’est que nous partageons plus ou moins l’avis de Lee », a écrit Knut Melvær, de Sanity.

Les deux ont raison. Pour un site géré par des développeurs, avec peu de rédacteurs et une courte liste de pages, un dépôt et un agent suffisent souvent. Pour vingt rédacteurs dans cinq langues, les fonctions qu’énumère Sanity, c’est précisément le travail.

Ce que nous choisirions

Commencez par trois questions. Qui modifie le site, et à quelle fréquence. Comment une modification est vérifiée avant sa mise en ligne, qu’elle vienne d’une personne ou d’un agent. Et à qui appartient le contenu le jour où vous partez.

Pour un petit site avec un seul rédacteur, un constructeur fait l’affaire, pourvu que le contenu puisse partir avec vous. Si WordPress vous convient, avec peu d’extensions et une personne nommée qui les tient à jour, rien ne presse pour en changer. Là où le contenu traverse canaux, rédacteurs et langues, un contenu structuré dans un système headless sert aussi bien les personnes que les agents. Et un site géré par des développeurs peut vivre dans le code : un agent fait les modifications, une personne relit chaque version.

Nous avons conçu Studio pour le cas intermédiaire : une équipe marketing qui modifie le site chaque jour, avec des agents qui l’aident. C’est un CMS posé sur des sites construits en Next.js, Vite ou TanStack, sans extensions ni PHP sur le site public. Les rédacteurs cliquent sur un mot pour le modifier, l’assistant propose un premier jet et une personne décide. Chaque publication est vérifiée, compilée une fois, testée, mise en ligne, contrôlée, puis annulée d’elle-même si quelque chose échoue, et elle enregistre le contenu dans le propre dépôt de l’entreprise. Studio est en accès anticipé.