Dix ans de WordPress : pourquoi nous n'avons toujours pas trouvé mieux

Une question qui revient à chaque réunion

Depuis quelques mois, une question revient régulièrement dans nos échanges avec nos clients, qu’ils soient PME, institutions publiques ou grands comptes : « avec ce que fait l’IA aujourd’hui, est-ce qu’on a encore besoin d’un CMS ? »

La question est légitime. On lit partout que telle agence a migré ses sites hors de WordPress en dix jours grâce à Claude Code, que tel créateur d’un plugin emblématique a quitté WordPress pour un générateur statique, qu’une nouvelle génération d’outils « AI-native » rendrait les CMS traditionnels obsolètes. Le discours est tentant, et il contient une part de vérité.

Mais il mélange deux questions très différentes : est-ce que tous les sites ont besoin d’un CMS ? (non, et ce n’est pas nouveau), et faut-il migrer tous les sites CMS existants vers un stack JavaScript piloté par IA ? C’est un tout autre débat, et nous pensons que la réponse par défaut est non.

Cet article est notre position, après dix ans passés à construire, livrer et maintenir des sites WordPress pour des clients aux contraintes très diverses. Il s’inspire notamment d’une réflexion récente de Chris Van Patten sur le même sujet, que nous recommandons en complément.

Ce que l’argument « le CMS est mort » a de juste

Commençons par être honnêtes sur ce qui est vrai dans le discours ambiant.

Tous les sites n’ont pas besoin d’un CMS. C’est un fait, et ça l’est depuis vingt ans. Une landing page produit, un portfolio, un site vitrine à contenu quasi-statique : un générateur statique fait le travail, souvent mieux qu’un CMS en termes de performance et de surface d’attaque. Quand le contexte s’y prête nous créons aussi des sites sans WordPress (ex: Calculateur Elantis).

L’IA accélère réellement le scaffolding initial (le scaffolding, c’est la mise en place de la structure de base d’un projet : pages, composants, routes, configuration). Ce n’est pas du marketing. Générer la première version d’un site vitrine en quelques heures avec un assistant de code est devenu tangible, et c’est une avancée réelle sur la productivité.

Les interfaces d’édition des CMS traditionnels ont vieilli. Il y a une tension légitime entre la flexibilité offerte par Gutenberg et la simplicité que demandent les éditeurs non-techniques. Cette critique existe, elle est entendue, et elle anime la communauté WordPress depuis plusieurs années.

Ces trois constats sont vrais mais ils ne mènent pas pour autant à la conclusion qu’il faut migrer tout un parc de sites en production vers un stack JavaScript généré par IA. Voici pourquoi.

Dix ans d’évaluation : ce que nous avons essayé, ce qui a cassé

Nous ne sommes pas restés sur WordPress par inertie. Au fil des années, nous avons sérieusement évalué (et souvent mis en production sur des projets réels) plusieurs alternatives. Aucune n’a coché toutes les cases que nos clients nous imposent.

Contentful et les CMS SaaS propriétaires. Ces solutions proposent une excellente DX, une API soignée, un time-to-first-content rapide. Mais dès qu’on passe à l’échelle (plusieurs langues, plusieurs environnements, plusieurs éditeurs, plusieurs content types comme les pages événement, fiches produit ou formulaires), la grille tarifaire devient prohibitive. Pour un client du secteur public ou une PME qui veut maîtriser son budget sur dix ans, c’est un non structurel. Et la portabilité des données est, au mieux, théorique.

Ghost. Un très bon outil pour ce qu’il fait : la publication éditoriale et la newsletter. Dès qu’on sort de ce périmètre (un site institutionnel avec des content types variés, des workflows complexes, des intégrations tierces), l’extensibilité n’est pas au rendez-vous. Ce n’est pas un défaut de Ghost, c’est son positionnement. Il n’a simplement pas vocation à remplacer un CMS généraliste.

Strapi. L’espoir open source qui a beaucoup promis. En pratique, trois difficultés récurrentes : un écosystème de plugins mince comparé à celui de WordPress, une gestion de la localisation longtemps traitée en seconde classe, et des migrations majeures douloureuses. À cela s’ajoute ce que nous appellerions « l’open source avec une tournure » (sur lequel nous revenons juste après).

Next.js seul. Ce n’est pas un CMS, c’est un framework de présentation. Pour atteindre l’ergonomie d’édition qu’offre WordPress en sortie de boîte, il faut reconstruire ce que vingt ans de développement communautaire ont apporté : gestion des médias, workflows de publication, rôles et permissions, révisions, aperçu, internationalisation. Le coût est invisible dans la démo. Il devient très visible en phase de maintenance et de formation utilisateur.

La tendance « open source avec tournure ». C’est le point qui nous semble le moins discuté et le plus important. La majorité des alternatives modernes se présentent comme open source, mais placent derrière un plan payant les fonctionnalités que nos clients considèrent non-négociables : gestion fine des rôles et permissions, multilingue sérieux, environnements multiples, SSO, audit trail, support.

Pour un client public soumis à des obligations de marchés, ou pour une grande entreprise avec des exigences de conformité, ces fonctionnalités ne sont pas des options premium. Elles sont le socle. Payer un SaaS par utilisateur et par mois pour accéder à la gestion des permissions d’un CMS, après avoir acheté l’argument « c’est open source », a quelque chose d’un peu malhonnête.

WordPress, avec toutes ses imperfections, reste profondément open source au sens originel : le code est là, la communauté est là, la documentation est là, et les fonctionnalités fondamentales ne sont pas derrière un paywall.

Notre grille d’évaluation

Voici les critères importants pour la majorité de nos clients, concrètement, et comment les solutions que nous avons évaluées s’y comportent selon notre expérience.

Le problème vient du thème WordPress qui applique un fond sombre sur les lignes alternées, rendant le texte clair invisible. Il faut forcer les couleurs dans le code.
Remplace le code précédent par celui-ci, qui force explicitement les couleurs du texte et des fonds :
html

Cette grille n’est pas un plaidoyer. WordPress y récolte plusieurs ⚠️, notamment sur la courbe d’apprentissage de l’édition pour les utilisateurs non-techniques. C’est une critique légitime que nous traitons projet par projet, souvent en s’appuyant sur ACF pour simplifier l’expérience d’édition plutôt qu’en laissant Gutenberg brut.

Mais sur l’ensemble des critères pondérés par ce que nos clients demandent réellement, aucune alternative n’a fait mieux.

L’IA ne remplace pas le CMS, elle le rend plus puissant

C’est peut-être le point le plus contre-intuitif de notre position : nous pensons que l’arrivée massive de l’IA renforce WordPress plus qu’elle ne le menace.

Premier point, rarement nommé : le corpus d’entraînement. Les grands modèles de langage (LLM, ces IA génératives de texte type ChatGPT, Claude ou Gemini) sont massivement meilleurs sur WordPress que sur n’importe quel framework émergent. Vingt ans de documentation, de code open source, de questions Stack Overflow, de tutoriels, de dépôts publics.

Quand un agent IA doit résoudre un conflit de plugins, écrire un template, déboguer un hook ou expliquer un comportement étrange à un éditeur, il a de la matière. Sur un CMS récent ou un framework sorti il y a dix-huit mois, la même requête produit des réponses approximatives.

Pour un client qui pense durabilité sur dix ans, c’est un argument de maintenabilité que personne ne met en avant dans les pitchs de migration.

Deuxième point : MCP arrive dans le cœur de WordPress. Le Model Context Protocol, combiné à l’Abilities API et à la REST API déjà mature, fait de WordPress un substrat particulièrement adapté à l’édition assistée par IA. Un utilisateur peut déjà, et pourra de plus en plus, demander à un assistant de mettre à jour des horaires, publier un article, reformuler une page, pendant que la couche d’administration reste disponible pour ceux qui préfèrent cliquer. WordPress n’est pas une cible de remplacement pour l’IA : c’est un socle naturel.

Troisième point, qui nous concerne directement : la traduction assistée, en production chez nous. Nous avons développé un plugin interne qui utilise l’API DeepL pour traduire les contenus de nos clients multilingues.

Pourquoi un plugin maison plutôt que le plugin officiel DeepL pour WordPress ? Parce que la majorité de nos projets s’appuient sur ACF avec des pages contenant parfois plusieurs centaines de champs, et que le plugin officiel gère mal ces structures. Notre plugin, lui, parcourt proprement la structure ACF, respecte les relations entre champs, et s’intègre au flux Polylang.

Il est encore en version beta, mais il tourne déjà sur des projets réels.

C’est exactement le type d’adaptation que l’écosystème WordPress rend possible : quand un outil existant ne couvre pas un besoin spécifique, la surface d’extension est assez riche pour qu’on puisse construire la pièce manquante. Sur un CMS fermé ou un SaaS propriétaire, cette extension n’existe pas, et elle ne peut pas exister.

L’IA ne rend pas WordPress obsolète. Elle en fait, au contraire, l’une des plateformes les mieux outillées pour absorber cette transformation.

Le bon outil pour le bon usage : ce que nous faisons réellement

Notre position n’est pas « WordPress pour tout ». Elle ne l’a jamais été. C’est précisément ce qui rend le discours « migrez tout vers un seul stack moderne » suspect à nos yeux : nous faisons déjà, au quotidien, du mélange de technologies, parce que c’est ce qui sert nos clients.

Concrètement :

• WordPress headless pour les sites où l’UX front justifie un framework dédié, tout en gardant l’interface d’édition riche et familière côté client.
• Shopify pour le e-commerce, pas WooCommerce. Nous assumons que Shopify fait mieux le commerce, et nous savons faire cohabiter un site de contenu en WordPress headless avec une expérience d’achat en Shopify, de manière fluide pour l’utilisateur final.
• Générateurs statiques pour les sites vraiment simples, sans besoin éditorial récurrent.
• WordPress classique pour les sites où l’admin WordPress native est, tout simplement, l’outil le plus efficace pour le client.

Le choix ne se fait pas par idéologie de stack. Il se fait par audit des besoins, des compétences du client, de la durée de vie attendue du projet et du budget de maintenance. C’est exactement ce débat que le discours « le CMS est mort » cherche à court-circuiter, et c’est précisément pour ça qu’il faut y résister.

À qui profite la migration ?

Une question saine à se poser devant n’importe quel discours de rupture technologique : qui a intérêt à ce que je change d’outil ?

Quand un client migre d’une stack WordPress mature vers un site bespoke généré par IA sur un framework JavaScript, il ne supprime pas sa dépendance technologique. Il la déplace.

Hier, il pouvait faire appel à des milliers de développeurs WordPress sur le marché européen pour faire évoluer son site. Demain, il appelle l’agence qui a construit le site, parce qu’elle est la seule à connaître l’architecture particulière qui a été générée. Le cas Builder.ai (cette entreprise qui promettait de construire des applications sur mesure par IA et dont l’effondrement en 2025 a laissé ses clients sans accès à leurs propres outils) est l’illustration extrême d’un risque qui, à plus petite échelle, existe dans toute migration vers un système sur mesure mal documenté.

Les coûts de maintenance ne disparaissent pas non plus. Ils changent de forme. Hier, des mises à jour de plugins et de versions de PHP. Demain, des montées de version de dépendances npm qui cassent, des frameworks front qui changent de paradigme tous les dix-huit mois, des runtimes Node à faire évoluer, des agents IA dont le comportement dérive avec les nouvelles versions de modèles. La complexité se déplace vers une partie de la stack souvent moins bien comprise par le client final.

Et puis il y a la dimension européenne, qui pèse pour une partie importante de nos clients. Souveraineté des données, hébergement en Union Européenne, auditabilité RGPD, indépendance vis-à-vis des grandes plateformes américaines : tous ces critères sont plus faciles à honorer sur une stack WordPress auto-hébergée que sur un SaaS propriétaire ou une architecture dépendante d’APIs IA américaines. Ce n’est pas un détail, c’est un critère structurant pour nos clients du secteur public et pour beaucoup de grandes entreprises.

La question honnête, pour conclure

La question n’est pas « le CMS est-il mort ». Elle ne l’a jamais été.

La vraie question, celle que nous posons à chaque début de projet, est : quel est le bon outil pour les dix prochaines années de ce site précis, compte tenu de ses utilisateurs, de son budget, de ses contraintes réglementaires et de l’équipe qui va le faire vivre ?

Pour les sites de nos clients (PME, secteur public, grandes entreprises multilingues), aucune alternative n’a encore passé notre grille d’évaluation. Le jour où ce sera le cas, nous migrerons sans regret. D’ici là, nous continuons à construire sur WordPress, en y intégrant l’IA là où elle apporte une vraie valeur (la traduction assistée aujourd’hui, l’édition via MCP demain), plutôt qu’en remplaçant l’ensemble par un stack dont nous savons déjà que les tradeoffs ne sont pas meilleurs, simplement différents et moins bien compris.

Si vous êtes en phase d’évaluation et que cette grille vous est utile, parlons-en.