veilletech.frCe qui se passe
Annoncé le 1er avril comme successeur de WordPress, ce qui avait fait douter de son sérieux, EmDash sort en 1.0 : CMS gratuit, sous licence MIT, construit sur Astro. Les développeurs écrivent le site en Astro, les rédacteurs passent par l'interface d'administration, les agents par l'API, la CLI ou le serveur MCP intégré. Le blog de Cloudflare tourne dessus depuis août, avec des pointes à 5 000 requêtes par seconde. Le projet revendique plus de 175 contributeurs, 1 800 commits et 25 langues.
Deux choses intéressent quiconque écrit ou installe des plugins : le modèle d'exécution, et le registre.
Des plugins isolés, à capacités déclarées
Dans WordPress, un plugin vit dans le processus PHP du site, avec la base, le disque et le réseau. Un formulaire de contact peut techniquement lire les brouillons ou exfiltrer des données ; on fait confiance à l'auteur, et à chacune de ses mises à jour.
Un plugin EmDash « sandboxé » s'exécute isolé, avec son propre stockage et rien d'autre : ni contenu, ni médias, ni utilisateurs, ni secrets, ni variables d'environnement, ni système de fichiers, ni réseau. Chaque capacité supplémentaire est déclarée dans son manifeste, montrée avant l'installation, approuvée par l'administrateur, puis appliquée par le runtime. Les capacités sont indépendantes les unes des autres :
| Le plugin sert à… | Il obtient | Il ne peut toujours pas |
|---|---|---|
| indexer pour la recherche | lire le contenu, joindre le service de recherche | modifier un article, joindre un autre hôte |
| optimiser les images | lire et gérer les médias | lire les contenus des utilisateurs |
| notifier à la publication | observer la publication, envoyer un e-mail | changer le contenu publié |
| exposer des webhooks | lire certains événements, joindre des adresses publiques | atteindre un réseau privé ou le stockage d'un autre plugin |
L'isolation ne dépend pas de Cloudflare : sur Workers, chaque plugin devient un
Dynamic Worker chargé par le Worker Loader ; sur Node.js, EmDash lance
workerd, le runtime open source des Workers, dans un processus séparé, un
service isolé par plugin. Mêmes manifestes, mêmes API.
Un registre qui ne possède pas les plugins
Un registre classique cumule trois rôles : il fournit le compte de l'éditeur, détient la fiche officielle du paquet et tient le catalogue. S'il suspend un compte ou ferme, l'éditeur perd son identité et son historique de versions.
Le registre d'EmDash repose sur AT Protocol, le protocole de Bluesky. L'auteur publie avec un compte Atmosphere ; les fiches de paquet et de version sont signées par lui et stockées dans son propre compte. Le catalogue par défaut modère ce qu'il affiche (noms, descriptions, liens, images) mais ne peut ni réécrire ni retirer une publication. Avant d'installer, EmDash vérifie la preuve d'inclusion jusqu'au commit signé de l'éditeur, puis l'empreinte, le nom, la version, les accès demandés et la provenance de build exigée, et contrôle que le paquet téléchargé correspond à la fiche signée.
L'agrégateur, le service de modération et un loader Astro pour afficher les listes de plugins sont publiés en open source.
Les limites
- Seuls les plugins gratuits sont pris en charge ; le payant est prévu, sans date.
- L'écosystème démarre : un premier plugin e-commerce, 44 thèmes Astro chez un éditeur tiers. Rien de comparable à WordPress.
Comment s'y prendre
npm create emdash@latestLe guide du premier plugin montre le manifeste et la publication sur le registre. Pour un auteur de plugins Payload ou WordPress, c'est surtout un modèle à lire : quelles capacités votre plugin réclamerait-il, et lesquelles pourrait-il perdre ?
Source : EmDash 1.0: the stable CMS with a secure plugin registry, Cloudflare, 28 septembre 2026.