Cloudflare a présenté le 1er avril 2026 un projet que beaucoup ont d’abord pris pour un poisson : EmDash, un système de gestion de contenu open source décrit comme le « successeur spirituel » de WordPress. Le produit est bien réel, publié sous licence MIT, écrit en TypeScript et bâti sur Astro. Cinq mois plus tard, il reste en version 0.1.0, une préversion pour développeurs. Assez pour juger l’architecture, trop tôt pour parler d’écosystème.
Ce qu’est EmDash, et ce qu’il n’est pas
EmDash n’est pas un fork de WordPress. Aucune ligne de code du CMS historique n’a été reprise : le projet a été réécrit depuis zéro, avec l’aide d’agents de codage, pour viser une compatibilité de fonctionnalités plutôt qu’une compatibilité de code. Techniquement, EmDash s’installe comme une intégration Astro et fournit un panneau d’administration, une bibliothèque de médias, une API REST et un système d’extensions.
La cible d’exécution est Cloudflare Workers et son architecture d’isolats V8, avec une compatibilité Node.js. Le déploiement reste ouvert : Workers, mais aussi Netlify ou Vercel. Une nuance compte toutefois, et elle est structurante : la fonctionnalité qui distingue EmDash — le bac à sable des extensions — ne fonctionne pleinement que sur l’infrastructure de Cloudflare.
Le pari central : isoler chaque extension
La proposition de valeur d’EmDash tient en une statistique que Cloudflare met en avant : l’immense majorité des incidents de sécurité sur les sites WordPress provient des extensions. La réponse retenue est architecturale. Chaque extension déclare ses capacités dans un manifeste et s’exécute dans son propre isolat, sans accès direct à la base de données ni au système de fichiers.
{
"name": "newsletter-widget",
"version": "1.0.0",
"capabilities": {
"content": ["read"],
"network": ["api.example.com"],
"storage": ["kv:newsletter"]
}
}Le principe est celui des permissions déclaratives : une extension ne peut toucher que ce que son manifeste autorise explicitement. Sur le papier, le modèle referme la porte d’entrée la plus fréquente des compromissions WordPress. En pratique, il repose sur les Dynamic Workers de Cloudflare, ce qui explique pourquoi le bac à sable ne tient pas sa promesse sur un hébergement classique.
Isoler chaque extension dans son propre bac à sable répond au problème qui coûte le plus cher à WordPress : ses plugins.
EmDash face à WordPress
Le tableau suivant confronte les deux approches sur les points qui décident réellement d’un choix de CMS.
| Critère | EmDash | WordPress |
|---|---|---|
| Langage | TypeScript | PHP |
| Socle | Astro 6, intégration | Cœur monolithique |
| Extensions | Isolées, capacités déclarées | Accès direct au cœur |
| Exécution | Isolats (Workers), bac à sable | Processus PHP partagé |
| Licence | MIT | GPL |
| Intégration IA | Serveur MCP natif | Via extensions tierces |
| Écosystème | Quasi inexistant | Immense, mûr |
| Maturité | 0.1.0, préversion | Éprouvée depuis 20 ans |
Point de vigilance : EmDash est une préversion 0.1.0. Pas d’écosystème d’extensions, pas de constructeur visuel de pages, et un argument de sécurité qui suppose un hébergement Cloudflare pour être pleinement effectif. Rien de tout cela n’en fait un candidat pour migrer un site de production aujourd’hui.
Migrer depuis WordPress : ce qui passe
EmDash ne demande pas de repartir d’une page blanche. Le projet accepte les fichiers d’export WXR de WordPress et fournit une extension d’export côté WordPress. La bibliothèque de médias est importée automatiquement, et les types de contenu personnalisés sont convertis en collections de contenu Astro. L’opération se pilote en ligne de commande, ce qui la rend rejouable et intégrable à un script de reprise, un confort appréciable lorsqu’une migration doit être répétée sur plusieurs environnements.
# Créer un projet Astro puis y ajouter EmDash
npm create astro@latest site-demo
cd site-demo
npx astro add emdash
# Importer un export WordPress (fichier WXR)
npx emdash import ./export-wordpress.xmlSur un site éditorial simple, la reprise du contenu se compte en minutes. La difficulté n’est pas là : elle est dans tout ce qu’un site WordPress réel embarque autour du contenu — extensions métier, thème sur mesure, réglages SEO, formulaires. Ces éléments n’ont pas d’équivalent prêt à l’emploi dans un écosystème encore vide.
Un CMS pensé pour les agents
Là où WordPress a greffé l’intelligence artificielle par extensions successives, EmDash l’intègre au socle. Le CMS embarque un serveur MCP natif : un agent peut lire, créer ou mettre à jour du contenu sans outillage supplémentaire, en dialoguant directement avec l’administration. S’y ajoutent des Agent Skills et une interface en ligne de commande pensée pour l’automatisation, qui rendent le pilotage par script ou par agent aussi naturel que le clic dans le panneau.
Deux choix par défaut prolongent cette orientation. L’authentification repose sur des clés d’accès plutôt que sur un couple identifiant-mot de passe, ce qui coupe court aux attaques par force brute visant la page de connexion. Et un support de paiement x402 est prévu au niveau du cœur, pour facturer un accès ou un contenu sans extension e-commerce. Autant de briques qui, ensemble, dessinent un CMS conçu pour un web où les agents comptent autant que les visiteurs.
Ce qui manque encore
La liste des absents est aussi instructive que celle des présents. EmDash n’offre pas de constructeur visuel de pages, alors que c’est précisément ce qui a assis la domination de WordPress auprès des non-développeurs. Le catalogue d’extensions et de thèmes est à peu près vide, ce qui reporte sur l’équipe tout ce qu’un greffon résolvait en un clic. Le référencement, la gestion fine des rôles et l’internationalisation avancée restent à éprouver sur le terrain.
Reste enfin la dépendance à Cloudflare pour le bac à sable. Le CMS se déploie ailleurs, mais son argument de vente le plus fort perd de sa force hors de l’infrastructure qui l’a vu naître. Un point à garder en tête avant d’en faire un pilier d’architecture.
Pour qui, et à partir de quand
EmDash intéresse d’abord les équipes déjà installées dans l’univers TypeScript et Astro, à l’aise avec un déploiement sur Workers, et sensibles à l’argument de sécurité. Pour un prototype, une maquette de blog ou une veille technologique sérieuse, l’essai a du sens dès maintenant. Pour un site client en production, la prudence commande d’attendre : une version 0.1.0 sans écosystème n’offre pas les garanties qu’un projet facturé exige. La question du choix de CMS reste, elle, entière et mérite d’être posée projet par projet.
Ce qu’il faut retenir
EmDash apporte des idées d’architecture sérieuses : TypeScript de bout en bout, extensions isolées par capacités, serveur MCP intégré pour les agents. Ses limites sont tout aussi nettes : préversion 0.1.0, écosystème inexistant, bac à sable dépendant de Cloudflare. À ce stade, c’est un projet à surveiller et à prototyper, pas une base de production. La direction, elle, mérite l’attention de quiconque vit avec les failles d’extensions au quotidien.
Sur mes projets, WordPress reste le choix par défaut pour une bonne raison : son écosystème. Mais l’idée d’EmDash me parle, parce que je passe un temps déraisonnable à surveiller des plugins tiers. Un modèle où une extension ne peut toucher que ce qu’elle a déclaré, c’est exactement la garantie qui manque à WordPress. Je ne migrerai rien en 0.1.0, mais je garde le projet ouvert dans un onglet — et je le teste sur un side-project avant tout le monde. — Simon Janvier
Pour aller plus loin
Source primaire : EmDash, the open-source spiritual successor to WordPress (blog Cloudflare).
