WordPress est mort en tant que réponse automatique, pas en tant que logiciel.
Cette distinction est importante. Si vous dites « WordPress est mort » comme une affirmation littérale sur le marché, les données le rejettent. W3Techs rapporte que WordPress propulse 59,2 % des sites web avec un CMS connu et 41,5 % de tous les sites web en juin 2026. On ne peut pas qualifier cela de mort.
Mais si vous construisez des sites web en 2026, le vieux réflexe commence à sembler erroné. Un client veut un site rapide, une mise en page personnalisée, un SEO propre, quelques intégrations et un flux de travail d'édition qui n'a pas besoin de dix plugins. La réponse était autrefois WordPress parce que le code personnalisé était lent et coûteux. L'IA a changé ce calcul.
EmDash de Cloudflare rend ce changement plus difficile à ignorer. Cloudflare ne dit pas que WordPress n'a aucune valeur. Il dit que le prochain CMS peut être en TypeScript, serverless, propulsé par Astro, avec des plugins isolés (sandboxed) et conçu pour les agents IA dès le premier jour.
Je respecte toujours WordPress. Je l'utiliserais toujours pour le bon projet. Je ne pense plus qu'il mérite d'être la valeur par défaut.
Pourquoi WordPress est mort en tant que valeur par défaut
WordPress a gagné parce qu'il a donné le pouvoir de publier à des personnes non techniques. C'était une véritable percée. Vous pouviez installer un thème, ajouter un page builder, publier des articles de blog, ajouter des formulaires, ajouter des métadonnées SEO et remettre le site à un client.
Cet argument a mal vieilli pour de nombreux sites d'entreprise.
Un site simple devient souvent une pile de plugins : page builder, plugin de cache, plugin SEO, plugin de formulaire, plugin de sécurité, plugin d'image, plugin de cookies, plugin de redirection, plugin de schéma, et parfois un plugin de champs personnalisés pour rendre le page builder moins douloureux. Chaque pièce ajoute des mises à jour, des paramètres, des tables de base de données, des ressources et un autre point de défaillance.
Le problème n'est pas le cœur de WordPress. Le problème est la forme opérationnelle que prennent de nombreux projets WordPress après un an. Le site devient un petit système backend pour des pages qui auraient pu être livrées sous forme de HTML propre, d'un petit CMS et de quelques appels API.
Le rapport de sécurité WordPress 2026 de Patchstack rend le coût de maintenance plus difficile à ignorer. Le rapport indique que 11 334 nouvelles vulnérabilités ont été trouvées dans l'écosystème WordPress en 2025, soit une augmentation de 42 % par rapport à 2024. Il indique également que 91 % des nouvelles vulnérabilités ont été trouvées dans les plugins, 9 % dans les thèmes, et seulement 6 vulnérabilités ont été signalées dans le cœur de WordPress, toutes de faible priorité.
C'est là le point essentiel. WordPress lui-même n'est pas le méchant. La surface des plugins est l'endroit où réside le risque.
EmDash est le signal le plus pur
C'est la partie que j'aurais dû inclure dès le début. Cloudflare a introduit EmDash le 1er avril 2026 en tant qu'aperçu v0.1.0 et l'a décrit comme un successeur spirituel de WordPress.
Les détails s'alignent sur l'argument de cet article. EmDash est écrit en TypeScript, propulsé par Astro, open source sous licence MIT et conçu pour l'hébergement serverless. Il cible également le point douloureux spécifique de WordPress qui revient sans cesse : les plugins.
Dans WordPress, un plugin s'exécute dans le même monde que le site. Il peut toucher la base de données, le système de fichiers et le runtime d'une manière qui nécessite beaucoup de confiance. Le modèle EmDash de Cloudflare pousse les plugins dans des Dynamic Workers isolés et leur donne des capacités déclarées via des bindings. Un plugin devrait demander les permissions exactes dont il a besoin, comme la lecture de contenu ou l'envoi d'e-mails, avant de pouvoir effectuer ce travail.
C'est l'idée moderne du CMS : moins de confiance ambiante, plus de permissions explicites.
EmDash est également important car il traite les agents IA comme faisant partie du flux de travail. Cloudflare indique que chaque instance EmDash peut exposer un serveur MCP distant, ainsi que des outils CLI et des compétences d'agent. Cela signifie qu'un agent de codage peut gérer le contenu, les schémas, les médias et le travail de migration via des outils structurés au lieu de scraper un panneau d'administration ou de deviner où résident les données.
Je ne dirais pas à un client de migrer vers EmDash aveuglément aujourd'hui. C'est un aperçu. La partie importante est la direction : Cloudflare construit le remplacement de WordPress autour des mêmes choses que je veux maintenant pour les sites web : extensions isolées (sandboxed), architecture frontend propre, contrôle programmatique et opérations lisibles par les agents.
L'IA a changé le calcul des sites personnalisés
Il y a quelques années, personnalisé signifiait coûteux. Soit vous payiez un développeur pour construire chaque page et composant, soit vous utilisiez un page builder et acceptiez le poids.
L'IA rend la voie du milieu pratique. Vous pouvez décrire une mise en page, générer des composants, affiner l'espacement, rédiger du contenu, créer du contenu structuré, construire un petit flux d'administration et connecter les services exacts dont vous avez besoin. Des outils comme v0, Framer AI, Webflow AI, les constructeurs d'applications de style Lovable et les agents de codage modernes ont rendu la production d'interfaces personnalisées plus rapide.
Cela ne signifie pas que l'IA remplace le goût, l'assurance qualité (QA) ou le jugement technique. Cela signifie que la première ébauche ne prend plus tout le budget.
C'est là que WordPress perd sa position par défaut. Si je peux obtenir une construction personnalisée Next.js, Astro, EmDash ou Webflow qui correspond exactement à la marque, se charge rapidement, livre un schéma propre et évite un backend lourd, le compromis WordPress devient plus difficile à justifier.
Un page builder vous donne des boutons de réglage. Un flux de travail de code assisté par l'IA vous donne le système réel : composants, modèle de contenu, routes, métadonnées, gestion d'images, formulaires, analytique et règles de déploiement. Vous pouvez l'inspecter. Vous pouvez le versionner. Vous pouvez le tester.
Cela compte plus qu'un marché de thèmes.
Le backend doit correspondre au travail
Un site vitrine n'a pas besoin d'un panneau d'administration basé sur une base de données par défaut. Une landing page n'a pas besoin de PHP, MySQL, vingt écrans d'options et d'une couche de cache pour paraître rapide.
Utilisez un backend lorsque le projet en a besoin :
N'ajoutez pas un backend parce qu'un thème a besoin d'un endroit pour stocker des blocs.
Une stack moderne et légère peut être plus petite. Des pages statiques, des routes rendues côté serveur, un CMS headless, Supabase, un flux de contenu basé sur Git, des formulaires hébergés, Stripe, un fournisseur de recherche et une petite API couvrent un grand pourcentage de sites web. Vous obtenez moins de pièces mobiles et un meilleur contrôle sur les performances.
C'est la même raison pour laquelle je me soucie du HTML propre et d'un travail SEO mesuré. Dans mon étude de cas sur le score SEO Lighthouse→, la victoire est venue d'un balisage discipliné, de schémas, de la vitesse, de l'accessibilité et de la mise en cache. Un constructeur de site peut aider, mais le résultat final doit toujours être lisible par les navigateurs, les moteurs de recherche et les agents IA.
L'IA rend la conception exacte moins coûteuse
Le meilleur argument contre WordPress n'est plus seulement la vitesse. C'est le contrôle du design.
La plupart des projets WordPress commencent par un thème, puis plient la marque pour qu'elle s'y adapte. Vous changez les polices, les couleurs, les sections et l'espacement, mais le thème laisse toujours des empreintes. Le site ressemble à l'outil qui l'a construit.
L'IA inverse ce flux de travail. Vous pouvez commencer par la marque, l'offre, le public et le modèle d'interaction réel. Ensuite, vous générez l'interface autour de ces contraintes.
C'est un meilleur ordre.
Un site de consultant peut avoir la structure de preuve exacte dont il a besoin. Une page SaaS peut montrer une surface de produit dense au lieu d'un hero générique. Une page de produit musical peut ressembler à un véritable outil de studio plutôt qu'à un modèle. Une page d'entreprise locale peut rendre visibles la réservation, la confiance, l'emplacement et les informations de service sans combattre les hypothèses de mise en page d'un thème.
Le résultat a toujours besoin d'être révisé. L'IA peut générer du mauvais CSS, une accessibilité faible, du JavaScript gonflé et du contenu vague. Un humain doit toujours inspecter la page, tester sur mobile, vérifier les liens, vérifier les métadonnées, exécuter Lighthouse et garder l'écriture honnête.
Mais l'IA supprime l'excuse selon laquelle personnalisé signifie lent.
Quand WordPress gagne toujours
Je choisirais toujours WordPress lorsque le flux de travail d'édition est le produit.
Si une équipe publie de nombreux articles, utilise des habitudes éditoriales WordPress existantes, dépend de WooCommerce, a besoin de plugins matures spécifiques ou possède déjà des années d'historique SEO dans une configuration WordPress stable, reconstruire pour la mode est une mauvaise décision.
WordPress fonctionne également bien pour les équipes qui ont besoin d'une surface d'administration familière plus que d'un frontend personnalisé. Il y a de la valeur dans un outil que les gens connaissent déjà.
L'erreur est de choisir WordPress avant de demander ce que le site doit faire.
Pour de nombreuses nouvelles constructions, le site a besoin de vitesse, de structure, de design personnalisé, d'intégrations contrôlées et d'une maintenance faible. WordPress peut faire ces choses, mais il y parvient souvent par des couches supplémentaires. Les constructions personnalisées assistées par l'IA y parviennent plus directement.
Ma règle pratique
Je poserais trois questions avant de choisir WordPress aujourd'hui.
Premièrement, le client a-t-il spécifiquement besoin de l'expérience d'administration WordPress ?
Deuxièmement, un plugin résout-il un problème commercial difficile mieux qu'une petite intégration personnalisée ?
Troisièmement, le site sera-t-il toujours facile à maintenir après douze mois de mises à jour, de demandes marketing, de scripts de suivi et de changements de contenu ?
Si la réponse est oui, WordPress peut être le bon choix.
Si la réponse est non, je commencerais par une architecture plus légère et utiliserais l'IA pour construire l'interface exacte. Cela peut signifier un site statique, un CMS headless, un frontend React ou Astro, EmDash, Webflow, Framer ou une petite application full-stack. La stack doit correspondre au travail, pas à l'habitude.
C'est aussi là que les agents IA deviennent utiles. Un bon agent peut inspecter le site, vérifier les liens, vérifier les métadonnées, tester une construction, mettre à jour le contenu et laisser une trace. J'ai écrit sur cette couche de contrôle dans mon article sur les flux de travail des développeurs MCP→. La même idée s'applique aux sites web : les outils doivent exposer des actions claires, et non tout cacher derrière un écran de plugin.
Verdict
WordPress est mort en tant que réponse automatique. WordPress n'est pas mort en tant que logiciel.
EmDash est précoce, mais il montre où va la conversation sur les CMS : serverless par défaut, compatible TypeScript, natif frontend, limites de plugins plus sûres et flux de travail avec agents IA au lieu de tâches d'administration manuelles.
Le web s'est orienté vers des frontends plus rapides, des backends plus petits, un design assisté par l'IA et un contrôle plus explicite sur le résultat final. WordPress a toujours sa place, mais il doit gagner cette place projet par projet.
Si vous avez besoin d'une machine de publication, utilisez-en une. Si vous avez besoin d'un site web personnalisé qui semble exact, se charge rapidement et évite un backend lourd, l'IA a rendu le meilleur chemin plus facile à emprunter.