EmDash est-il un véritable remplaçant de WordPress ?

EmDash peut dès aujourd’hui remplacer WordPress pour des sites axés sur le contenu, aux besoins modestes en plugins, avec une équipe à l’aise pour développer avec Astro. En revanche, ce n’est pas encore un remplaçant direct pour les sites qui dépendent de thèmes PHP, de plugins WordPress spécifiques ou d’extensions payantes.

Tous les clients dont le site WordPress a été compromis via un plugin ont un jour demandé s’il existait une solution plus sûre. Lorsqu’EmDash a atteint la version 1.0 en se présentant comme le « successeur spirituel de WordPress », de nombreuses agences ont recommencé à se poser la question.

Cet article compare EmDash et WordPress sur quatre points : le modèle de sécurité des plugins, les exigences d’hébergement, la migration et ce à quoi vous renoncez.

Qu’est-ce que le CMS EmDash ?

EmDash est un CMS open source écrit en TypeScript et construit sur Astro. Il est distribué sous licence MIT et fonctionne sur Cloudflare ou sur un serveur Node.js. L’annonce d’EmDash 1.0 par Cloudflare le présente comme un CMS stable, gratuit et open source, « prêt à faire tourner un site web en production ».

Chaque profil dispose de son propre point d’accès. Les développeurs construisent le site avec Astro. Les rédacteurs travaillent dans le panneau d’administration d’EmDash. Les agents IA peuvent lire et modifier le contenu via l’API, la CLI ou le serveur Model Context Protocol (MCP) intégré. Pour générer la structure d’un nouveau site :

npm create emdash@latest

Cloudflare indique avoir migré son propre blog vers EmDash en août, avant la sortie de la version 1.0.

En quoi le modèle de plugins d’EmDash diffère-t-il de celui de WordPress ?

Le modèle de plugins constitue la principale différence entre les deux systèmes. Dans WordPress, chaque plugin s’exécute dans le même processus PHP que le site et peut accéder à la base de données, au système de fichiers et au réseau. Un plugin EmDash en sandbox démarre isolé et doit demander chacune des capacités dont il a besoin.

Selon l’article de Cloudflare consacré à EmDash 1.0, un plugin en sandbox dispose de son propre stockage privé, et de rien d’autre. Le contenu du site, les médias, les utilisateurs, les secrets, les variables d’environnement, le système de fichiers et le réseau lui sont tous fermés par défaut. Un plugin n’obtient un accès supplémentaire qu’après avoir déclaré ce besoin et obtenu l’approbation de l’administrateur du site, un peu comme les autorisations d’une application mobile. Cloudflare prend l’exemple d’un optimiseur d’images : il demande à lire et à gérer les médias, mais ne peut pas lire le contenu des utilisateurs.

Le registre de plugins d’EmDash est décentralisé. Il repose sur AT Protocol, et les éditeurs signent et stockent leurs propres enregistrements de paquets et de versions dans leur propre compte Atmosphere. Si le catalogue EmDash masque une fiche à la suite d’une modération, l’éditeur reste propriétaire du plugin et de son historique de versions.

Il existe une exception à la sandbox. La référence de configuration précise que le tableau plugins est destiné aux plugins qui partagent le processus du site Astro : c’est là que se placent les plugins natifs. Ces plugins s’exécutent sans isolation. Les plugins installés depuis le registre passent toujours par la sandbox.

Faut-il héberger EmDash sur Cloudflare ou sur Node.js ?

Vous pouvez héberger EmDash sur Cloudflare ou sur Node.js, mais la sandbox fonctionne différemment dans chaque cas. Cloudflare est payant et applique davantage de limites. Le runner Node.js ne coûte rien de plus, mais en applique moins.

La documentation de la sandbox des plugins détaille ces prérequis. Sans runner, EmDash ignore tous les plugins listés dans sandboxed: []. Vous pouvez toujours parcourir un registre que vous avez vous-même configuré, mais l’installation ou la mise à jour d’un plugin en sandbox s’interrompt avec une erreur SANDBOX_NOT_AVAILABLE. Le reste du site continue de fonctionner.

Sur Node.js, installez l’adaptateur Node et le runner de sandbox, puis indiquez le runner dans la configuration :

npm install @astrojs/node @emdash-cms/sandbox-workerd workerd

// astro.config.mjs
import { defineConfig } from "astro/config";
import node from "@astrojs/node";
import emdash from "emdash/astro";
import { sqlite } from "emdash/db";

export default defineConfig({
  output: "server",
  adapter: node({ mode: "standalone" }),
  integrations: [
    emdash({
      database: sqlite({ url: "file:./data/emdash.db" }),
      sandboxRunner: "@emdash-cms/sandbox-workerd/sandbox",
    }),
  ],
});

La documentation sur les capacités confirme que le runner Node.js n’applique que la limite de 30 secondes de temps d’exécution réel. Si un site définit des limites de CPU, de mémoire ou de sous-requêtes, le runner journalise un avertissement, car workerd en mode autonome ne peut pas les appliquer. Sur Node.js, un plugin trop gourmand en CPU n’est interrompu qu’une fois la limite de temps d’exécution réel atteinte.

Comment migrer de WordPress vers EmDash ?

EmDash migre le contenu, pas le code. La documentation sur l’import de contenu propose deux méthodes : un fichier WordPress eXtended RSS (WXR) ou une connexion à un site sur lequel est installé le plugin EmDash Exporter. WordPress.com ne dispose pas de source d’import dédiée : ces sites passent donc eux aussi par un export WXR ou par EmDash Exporter.

Le guide de migration depuis WordPress avertit qu’une version de l’exporter antérieure à la 1.2.0 omet les commentaires, les menus, le logo et le favicon sans vous en informer. L’import se termine malgré tout et ne signale aucun élément manquant. Vérifiez donc la version de l’exporter avant de commencer. Pour les thèmes et les plugins, le README d’EmDash indique que des compétences d’agents (agent skills) facilitent leur portage. Même avec cette aide, prévoyez une reconstruction.

Sur quels points WordPress garde-t-il l’avantage ?

WordPress conserve quatre avantages concrets. Son écosystème de thèmes et de plugins est bien plus vaste, presque tous les hébergeurs le prennent en charge, les rédacteurs le connaissent déjà et il dispose d’un marché mature de plugins payants. Lors du lancement de la version 1.0, Cloudflare a précisé que le registre EmDash ne prenait en charge que les plugins gratuits, les plugins payants étant prévus ultérieurement.

L’hébergement constitue le deuxième écart. WordPress fonctionne sur quasiment n’importe quel hébergement PHP. La sandbox complète des plugins d’EmDash requiert soit un forfait Cloudflare payant, soit un serveur Node.js que vous administrez vous-même.

Les rédacteurs représentent le troisième coût. L’interface d’administration d’EmDash leur est inconnue : migrer un client implique donc de former les équipes, et pas seulement de déplacer le contenu. Si vous évaluez plusieurs alternatives à WordPress, la comparaison entre 11ty et WordPress montre comment ces compromis se traduisent pour une solution orientée statique.

Qui devrait essayer EmDash dès maintenant, et qui devrait attendre

Essayez-le dès maintenant si :

• Vous créez des sites de contenu, comme des blogs, de la documentation ou des pages marketing, et votre équipe travaille déjà avec Astro.
• Le risque lié à la chaîne d’approvisionnement des plugins est une préoccupation réelle pour vous ou vos clients.
• Vous souhaitez que des agents interagissent avec le contenu via l’API, la CLI ou le serveur MCP.

Attendez si :

• Le site dépend d’un plugin WordPress spécifique, d’un thème commercial ou de fonctionnalités de type WooCommerce.
• Vous avez besoin de plugins payants issus du registre.
• Votre hébergement doit être un hébergement PHP mutualisé à bas coût.

Si vous déployez sur Cloudflare, intéressez-vous à cf, la nouvelle CLI de Cloudflare entrée en bêta ouverte le 28 septembre 2026. Elle gère la configuration et les bindings des Workers via un fichier cloudflare.config.ts, tandis que Wrangler continue de prendre en charge les projets configurés avec wrangler.jsonc.

EmDash est un véritable remplaçant de WordPress pour un type de site bien précis : orienté contenu, peu dépendant des plugins et développé par une équipe maîtrisant Astro, qui privilégie l’isolation des plugins à la taille de l’écosystème. Pour tout le reste, il mérite un projet pilote, mais n’est pas encore prêt pour une migration. Une bonne prochaine étape consiste à passer l’export WXR d’un site client réel dans l’outil d’import et à dresser la liste de ce qui manque.

FAQ

EmDash peut-il importer un site WordPress à partir de sa seule URL ?

Non. Sans le plugin EmDash Exporter, l'URL d'un site permet uniquement à EmDash d'interroger l'API REST publique de WordPress. Cette vérification peut confirmer que le site tourne sous WordPress et dénombrer ses articles, pages et médias publics, mais elle ne permet aucun import. Pour importer, téléversez un fichier d'export WXR ou installez EmDash Exporter sur le site WordPress et connectez-vous avec un mot de passe d'application WordPress, qui donne également accès au contenu non exposé par l'API REST publique.

Que deviennent les blocs Gutenberg et les blocs de plugins lors de l'import dans EmDash ?

EmDash convertit le balisage Gutenberg en Portable Text et fait passer le HTML de l'éditeur Classic par le même convertisseur. Les blocs que WordPress génère côté serveur, comme Derniers articles ou de nombreux blocs de plugins, ne stockent aucun balisage dans l'article. L'outil d'import conserve chacun d'eux sous forme de bloc HTML contenant uniquement le commentaire de bloc d'origine, qui n'affiche rien sur le site : vous devez donc les reconstruire ou les supprimer. Les blocs réutilisables deviennent des sections EmDash.

Les articles WordPress en brouillon, planifiés et privés conservent-ils leur statut dans EmDash ?

Seuls les articles publiés restent publiés. L'outil d'import d'EmDash associe le statut WordPress publish au statut publié, tandis que les statuts draft, pending, private, future, trash et inconnus deviennent tous des brouillons. Les articles planifiés et privés doivent donc être revus manuellement après l'import. Le guide de migration d'EmDash recommande également de compter les entrées par statut et de vérifier que les brouillons restent invisibles pour les visiteurs non connectés avant de basculer le DNS ou de mettre hors service le site WordPress.

Quelles bases de données et quels systèmes de stockage EmDash prend-il en charge ?

EmDash utilise Kysely pour le SQL et l'API S3 pour le stockage. Il fonctionne donc avec SQLite, Cloudflare D1, Turso ou libSQL, et PostgreSQL pour les données, et avec Cloudflare R2, AWS S3, tout service compatible S3 ou le système de fichiers local pour les médias. Sur Cloudflare, les plugins en sandbox lisent et écrivent toujours via un binding D1 nommé DB, quel que soit l'adaptateur de base de données utilisé par le site lui-même.