EmDash : le CMS que Cloudflare a d’abord construit pour les agents IA

En 2014, j’ai acheté une BMW M3 E36 pour retrouver des sensations que les voitures modernes ne procurent plus. Progressivité, bidouillabilité, cette impression que la machine vous appartient vraiment : vous pouvez la démonter, la régler, la comprendre. Dix ans plus tard, j’écris sur WordPress avec exactement le même sentiment. Une architecture née avant qu’AWS existe, tournant sur un LAMP vieillissant, truffée de plugins douteux, et pourtant capable de faire tourner 43 % du web parce qu’elle est organique, appropriable, fondamentalement humaine.

Le 1er avril 2026 (et non, ce n’est pas un poisson), Cloudflare a annoncé EmDash, un CMS open source présenté comme « le successeur spirituel de WordPress ». L’annonce a provoqué l’effet attendu dans la communauté des développeurs web. Certains ont applaudi. D’autres ont ricané. Presque tous ont raté l’essentiel.

Ce qui suit n’est pas un test produit. C’est une tentative de comprendre ce que cette annonce révèle sur la direction que prend le web, et ce qu’on risque de perdre en route.

Ce que Cloudflare a vraiment construit

Commençons par les faits, parce que beaucoup d’articles ont titré trop vite sans vérifier les détails techniques.

Le problème qu’EmDash prétend résoudre est réel et documenté. Un plugin WordPress est un script PHP qui s’exécute dans le même contexte que le CMS lui-même, avec un accès direct à la base de données et au système de fichiers. L’immense majorité des vulnérabilités sévères de l’écosystème WordPress proviennent des plugins, et 2025 a battu le record des deux années précédentes combinées, selon les rapports de WPScan. Ce n’est pas un bug corrigeable : c’est une conséquence directe de l’architecture fondamentale, et WordPress ne peut pas y remédier sans tout reconstruire.

EmDash reconstruit précisément ça. Chaque plugin tourne dans son propre isolat (un Dynamic Worker) et doit déclarer dans un manifeste JSON ce dont il a besoin : read:content, email:send, le hostname exact auquel il souhaite accéder réseau. Rien de plus. C’est le modèle de permissions des applications mobiles appliqué aux extensions CMS, et c’est élégant.

La stack technique : TypeScript end-to-end, Astro en frontend, Kysely pour le SQL, API S3 pour le stockage. Le CMS peut tourner sur Cloudflare Workers, mais aussi sur n’importe quel serveur Node.js avec SQLite, PostgreSQL ou des fichiers en local. Ce point est capital, et je vais y revenir.

Un mot sur le système de monétisation intégré : EmDash supporte nativement x402, un standard basé sur le code HTTP 402 Payment Required permettant de faire payer l’accès au contenu directement, sans abonnement, sans ingénierie. Cela paraît anecdotique en 2026, mais ça ne l’est pas, et je vais expliquer pourquoi c’est en réalité la clé de lecture de tout le projet.

Licence MIT, code sur GitHub, aucun code WordPress utilisé. Sur le papier, c’est propre. L’exécution technique est admirablement cohérente. On est loin du fiasco Gutenberg, ce chantier interminable qui a fracturé la communauté WordPress pendant des années en prétendant moderniser sans rien reconstruire.

Le paradoxe de l’open source sous attraction gravitationnelle

Soyons précis là où beaucoup d’analyses ont été paresseuses : EmDash n’est pas une prison Cloudflare. MIT license, auto-hébergeable sur Node.js, aucune dépendance technique forcée à l’infrastructure de Cloudflare. Affirmer le contraire serait inexact.

Mais voilà ce qui est vrai, et plus subtil. Comme le note lucidement un commentateur sur Hacker News, si EmDash n’était pas architecturalement optimisé pour vendre des Workers Cloudflare, ils ne l’auraient probablement pas construit ainsi. Ce n’est pas de la malveillance, c’est de la physique économique. L’infrastructure Cloudflare (CDN mondial, Workers, D1, R2) rend EmDash nativement meilleur lorsqu’il tourne sur Cloudflare que partout ailleurs. Vous êtes techniquement libres de partir. Vous partez en côte.

J’ai écrit en 2026 que le Cloud Act américain ne disparaît pas parce qu’un outil est open source. La question n’est jamais la licence seule : c’est où tournent les instances en production, qui contrôle l’infrastructure sous-jacente, et quelle est la friction réelle pour en changer. Or EmDash est optimisé pour un opérateur qui héberge aujourd’hui une fraction significative du web mondial et qui a déjà réfléchi à monétiser les requêtes des agents IA via son projet Net Dollar.

La licence MIT offre aux développeurs de plugins la liberté de les licencier comme ils l’entendent, sans hériter des contraintes GPL de l’écosystème WordPress. En apparence libérateur, et c’est sincèrement un progrès sur certains points, comme l’illustre bien le conflit WordPress/WP Engine sur ACF. En réalité, cela signifie aussi que les plugins EmDash peuvent être fermés et propriétaires dès le premier jour, ce qui change fondamentalement la nature de l’écosystème.

L’IA comme couche d’abstraction, la vraie rupture

C’est l’angle que presque tous les articles ont raté, et c’est pourtant le plus important. Revenons à x402.

Un site EmDash peut facturer automatiquement l’accès à son contenu à n’importe quel agent IA qui vient le consommer, sans intervention humaine, transaction par transaction. Cloudflare a donc construit un CMS qui parle nativement aux agents, les authentifie, les facture, et leur répond via des interfaces structurées. Ce n’est pas un CMS pour webmasters avec des features IA en bonus. C’est une infrastructure pour agents avec une interface webmaster en option.

EmDash expose nativement un serveur MCP (Model Context Protocol) et ce que Cloudflare appelle des Agent Skills : des interfaces permettant aux agents IA de créer du contenu, gérer les médias, modifier le schéma du site, porter des thèmes. Sans toucher au dashboard. Sans intervention humaine. WebMCP, le standard W3C en cours de finalisation, s’inscrit exactement dans cette direction : le web qui apprend à parler aux agents plutôt qu’aux humains.

J’ai posé la question dans un article sur la dépossession des développeurs par l’IA : que reste-t-il au développeur humain quand les couches d’abstraction sont absorbées une par une ? EmDash franchit une marche supplémentaire, et la vraie question n’est pas là.

La vraie question est celle du rapport de force qui se constitue silencieusement. Imaginez la configuration qui va rapidement devenir standard : un agent IA (Claude, GPT, peu importe) pilote votre instance EmDash, hébergée sur les Workers Cloudflare, stockée sur D1 et R2. Vous avez, techniquement, la main sur tout. Vous pouvez migrer, débrancher, auto-héberger. Mais en pratique, vous avez externalisé la gestion de votre CMS à un agent dont vous ne maîtrisez pas l’entraînement, tournant sur une infrastructure que vous ne contrôlez pas, dans un écosystème dont les mises à jour dépendent des priorités d’un opérateur américain soumis au Cloud Act.

Ce n’est pas une situation de danger immédiat. C’est une situation de dépendance progressive, exactement celle que j’ai décrite à propos des boutiques WooCommerce face à la réforme de la facturation électronique : on ne perd pas la main brutalement, on la cède par confort, couche après couche, jusqu’à ce que la migration soit théoriquement possible et pratiquement impensable.

WordPress, lui, ne parle pas aux agents. Il parle aux humains. Maladroitement parfois, douloureusement souvent, mais directement.

Le gouffre de l’écosystème

Revenons à ce qui va poser problème concrètement à quiconque envisage une migration aujourd’hui.

EmDash repart de zéro. Aucun des 60 000 plugins WordPress ne tourne nativement dans un isolat EmDash. L’architecture sandbox rend cette compatibilité fondamentalement impossible sans réécriture complète. La migration de contenu est prévue et documentée : l’export WXR fonctionne, le plugin dédié crée un endpoint sécurisé. La migration d’écosystème est une autre histoire.

Pour les sites en greenfield, portés par des développeurs TypeScript sans dette plugin : EmDash est une proposition sérieuse dès aujourd’hui. Pour les sites WooCommerce avec des années de personnalisation (et il y en a des millions), la question ne se pose pas en 2026. Roger Williams, community manager chez Kinsta, résume sobrement la situation : EmDash est trop complexe pour la majorité des utilisateurs WordPress d’aujourd’hui, mais il pousse la barre plus haut pour le projet WordPress lui-même. C’est peut-être là l’impact réel à court terme : pas une migration de masse, mais une pression salutaire sur Automattic pour accélérer une modernisation repoussée depuis des années, notamment sur l’approche headless qui peine encore à convaincre.

Et quand nous ne coderons plus, que restera-t-il de l’open source au sens où nous l’entendons aujourd’hui ? EmDash anticipe la réponse de Cloudflare à cette question. Elle mérite qu’on la lise attentivement.

Le choix qui se profile

La M3 E36 était imparfaite d’une façon qui m’appartenait. La voiture électrique moderne est objectivement supérieure sur presque tous les indicateurs mesurables. Elle est aussi silencieuse, opaque, et sa prise de recharge vous oriente vers un réseau d’infrastructure que vous n’avez pas choisi, exactement comme Air France avec Starlink : le meilleur choix technique n’est pas toujours le choix souverain.

EmDash est la Tesla du CMS : propre, silencieuse, ultra-efficace, et livrée avec une prise qui attire naturellement vers le réseau Cloudflare. WordPress est la vieille thermique vivante et imparfaite : elle cale parfois, elle consomme, elle demande de l’attention, et elle démarre n’importe où, sans réseau, avec un hébergeur à 5 euros par mois et un tournevis.

EmDash mérite qu’on le suive de près. Son architecture de sécurité est la bonne réponse à un vrai problème. Mais avant de sauter dans la voiture électrique, posez-vous la question directement : acceptez-vous que votre site devienne un nœud propre et efficace dans une infrastructure pensée pour les agents, administrée par une IA, hébergée chez un opérateur américain ?

Vérifiez la prise. Et demandez-vous qui possède le réseau de recharge.