EmDash : et si une extension n’avait pas les clés de tout le site ?
Une petite extension peut avoir de grands pouvoirs sur un site. Avec EmDash, Cloudflare propose de mieux les délimiter : une autre façon de penser la confiance dans nos outils web.
La confiance mérite aussi des frontières.
Un nouvel outil promet de reprendre l’idée de WordPress en limitant ce que les extensions peuvent faire. C’est ce qui m’attire dans EmDash, présenté par Korben le 2 avril 2026. Pas tant la perspective d’un champion qui chasserait l’ancien, mais une question toute simple : pourquoi ajouter une petite fonction devrait-il parfois revenir à faire confiance à quelqu’un pour toute la maison ?
Le projet a été annoncé la veille, un 1er avril, mais il est bien réel. En creusant sa documentation de lancement, je trouve une idée intéressante et une réserve importante. La promesse dépend aussi de la manière dont on héberge le logiciel. Le détail est moins spectaculaire que « remplacer WordPress ». Il me paraît pourtant plus utile.
Repartir de zéro ne remplace pas un écosystème
EmDash est un CMS, c’est-à-dire un logiciel pour organiser et publier des contenus. Dans son annonce du 1er avril, Cloudflare présente un projet écrit en TypeScript, fondé sur Astro et publié sous licence MIT. Il ne s’agit pas d’une nouvelle version officielle de WordPress, mais d’un autre outil, construit sans reprendre son code selon l’entreprise.
Au lancement, Cloudflare parle d’une version 0.1.0 en prévisualisation pour développeurs. Je garde cette étiquette en tête. Une première version publique peut montrer une direction très convaincante sans disposer du recul, des intégrations et des habitudes accumulées autour d’un outil plus ancien.
Une extension n’est d’ailleurs pas seulement une ligne dans un catalogue. Elle peut porter un formulaire, une boutique, une manière de présenter des contenus ou un fonctionnement auquel une équipe tient. Refaire le moteur ne remplace pas instantanément tout ce qui s’est organisé autour de lui.
C’est pourquoi je n’entends pas « successeur » comme « remplacement prêt pour tous ». Le mot ouvre une ambition. Il ne fournit pas encore l’inventaire de ce qui continuera à fonctionner après un déménagement.
Le chiffre qui mérite son dénominateur
Un nombre revient dans la présentation : 96 % des vulnérabilités se situeraient dans les extensions. En suivant la référence de Cloudflare, on arrive au rapport State of WordPress Security 2025 de Patchstack. Il porte sur les vulnérabilités découvertes dans l’écosystème en 2024, pas sur une mesure directe de tous les sites piratés.
C’est une différence majeure. Cette proportion ne signifie ni que 96 % des extensions seraient dangereuses, ni qu’un site aurait 96 % de chances d’être compromis. Elle renseigne sur la répartition des failles recensées dans un ensemble de logiciels. Elle ne donne pas le risque personnel d’un site donné.
Le rapport distingue lui-même les conditions d’exploitation et les niveaux de priorité. Une faille qui exige déjà un compte très privilégié ne raconte pas exactement la même menace qu’une attaque accessible sans connexion. Patchstack commercialise aussi des services de sécurité : sa connaissance du sujet est utile, son point de vue doit rester identifié.
Cela ne rend pas le problème imaginaire. Cela évite simplement de transformer un chiffre pertinent en alarme universelle. Ce que je veux comprendre ensuite, c’est la façon de limiter les conséquences d’une extension défaillante, plutôt que de désigner une technologie comme coupable par nature.
Une extension, une autorisation précise
La documentation d’EmDash disponible au lancement distingue un mode isolé, dit sandboxed, et un mode de confiance. Dans le premier, le programme supplémentaire s’exécute à part. Ses échanges avec le site passent par une interface qui vérifie les permissions annoncées.
Le principe peut se traduire sans jargon : être autorisé à lire des contenus ne devrait pas donner automatiquement le droit de les réécrire. Les connexions réseau peuvent aussi être limitées à des destinations déclarées. Ce sont des frontières techniques, pas seulement une promesse de bonne conduite de l’auteur du plugin.
L’analogie de la maison a toutefois une limite. Si j’accorde volontairement le droit de lire et celui d’envoyer certaines informations, la cloison ne décidera pas à ma place si cet échange est souhaitable. Un accès restreint peut encore être trop large pour le besoin réel.
Je ne lis donc pas cette architecture comme une immunité. Il reste à examiner les permissions demandées, les données concernées et la confiance dans le mécanisme qui fait respecter les limites. Je décris ici le modèle documenté ; je n’ai pas réalisé un audit de sécurité ni tenté de forcer son isolation.
L’auto-hébergement a une ligne en petits caractères
Le README de lancement annonce un fonctionnement sur Cloudflare ou sur un serveur Node.js avec SQLite. L’auto-hébergement n’est donc pas une promesse inventée. Mais faire tourner le CMS et bénéficier du même cloisonnement des extensions sont deux questions différentes.
La documentation de cette première version indique que le mode isolé s’appuie sur les Dynamic Worker Loaders de Cloudflare. Sur Node.js, les extensions fonctionnent en mode de confiance : leurs déclarations de capacités ne constituent pas une barrière d’exécution équivalente. Le README précise également que les Dynamic Workers nécessitent alors un compte Cloudflare payant.
Cette nuance change ma lecture. On peut apprécier l’ouverture du code et la possibilité de partir ailleurs, tout en constatant que l’une des protections mises en avant dépend, à ce stade, d’un environnement particulier. Ce n’est pas la même chose que dire « impossible à auto-héberger » ; ce n’est pas non plus une indépendance identique sur tous les plans.
Je situe bien cette observation au lancement d’avril 2026, pas comme un verdict définitif sur le projet. Avant tout choix concret, la bonne question serait : quelles garanties sont effectivement actives dans la configuration retenue ? Le nom du logiciel ne répond pas, à lui seul, pour toutes ses installations.
Migrer les textes n’est pas déménager tout le site
La documentation de migration de cette version prévoit notamment l’import d’un export WordPress WXR, avec articles, pages, médias et taxonomies. Elle décrit aussi la conversion de blocs Gutenberg et la conservation de blocs inconnus sous forme de HTML à examiner. C’est un passage organisé pour les contenus, pas une baguette magique pour chaque fonction.
Un article peut être bien importé alors qu’un formulaire, un shortcode ou une présentation sur mesure demande encore du travail. Les extensions et les thèmes WordPress ne deviennent pas des extensions et des thèmes EmDash par le simple déplacement d’un fichier. Il faut distinguer récupération des informations et reconstruction du comportement attendu.
Le lancement ajoute d’autres pistes : authentification par passkeys, outils pour piloter les contenus avec des agents et paiement à la demande via x402. Je les prends comme des fonctions proposées, pas comme la preuve qu’un média trouvera automatiquement son public ou son modèle économique. Une prise de courant ne choisit pas non plus l’appareil utile à brancher.
Ce que j’aimerais voir durer dans cette initiative dépasse finalement la compétition entre deux noms. C’est l’idée qu’ajouter une fonction ne devrait pas obliger à abandonner toute maîtrise sur ce qu’elle peut faire. Même un outil qui ne devient pas dominant peut déplacer les attentes dans le bon sens.
Je ne suis pas en train de préparer le déménagement d’un site sur la foi d’une annonce. Je retiens plutôt une question à poser à chaque nouvelle extension : de quoi a-t-elle réellement besoin, et qu’est-ce qui l’empêche d’aller plus loin ?