Cloudflare a lancé emdash CMS début avril 2026 en tant qu'aperçu v0.1.0. La proposition : open-source, sous licence MIT, Astro-first, plugins avec permissions limitées, tables de base de données dédiées par type de contenu, agents IA comme constructeurs de première classe via MCP. Maciek Palmowski a écrit un avis précoce pertinent sur maciekpalmowski.dev qui a capturé la promesse architecturale aux côtés du compromis sur l'expérience éditeur. Voici mon avis honnête après avoir exploré le code source, la documentation, et ce que le projet essaie vraiment d'être.
Version courte : les choix architecturaux sont corrects. Le choix de l'éditeur est discutable. Les tarifs sont imbattables (gratuit, MIT). L'audience est plus étroite que ce que le marketing suggère, et c'est normal — la bonne alternative à WordPress pour certaines équipes n'est pas la bonne alternative pour toutes les équipes. Voici la version plus longue.
Ce que emdash est vraiment, en un paragraphe
emdash est un système de gestion de contenu écrit en TypeScript, construit sur Astro, déployé par défaut sur Cloudflare Workers (avec une alternative Node.js). Il se positionne comme un successeur de WordPress avec trois différences architecturales : (1) les permissions des plugins sont explicites et limitées plutôt qu'implicites et avec accès complet, (2) chaque type de contenu vit dans sa propre table de base de données dédiée au lieu d'être forcé dans le modèle wp_posts/wp_postmeta de WordPress, (3) l'intégration IA est de première classe via un serveur MCP intégré et une CLI JSON qui permet aux agents de lire et écrire du contenu proprement. Open-source, sous licence MIT, actuellement en aperçu v0.1.0 en avril 2026.
Ce qui fonctionne bien avec emdash
Le modèle de sécurité des plugins est une véritable amélioration architecturale
La sécurité des plugins WordPress est insoluble dans le modèle existant. Les plugins s'exécutent dans le même processus que le cœur, avec le même accès à la base de données, le même accès au système de fichiers, et la même capacité à s'injecter n'importe où dans le cycle de vie de la requête. Un plugin compromis compromet l'ensemble du site. emdash change cela : les plugins déclarent les permissions dont ils ont besoin en amont (read-content, write-content, send-email, etc.) et s'exécutent dans des limites de capacité explicites. Un plugin qui demande « send-email » ne peut soudainement pas commencer à écrire dans la base de données. Un plugin qui demande « read-content » ne peut pas exfiltrer les mots de passe des utilisateurs.
C'est la même idée que les permissions des applications iOS, les permissions des extensions de navigateur, et la Capability-Based Security en général. C'est la bonne réponse depuis 50 ans et WordPress l'a refusée pendant 22 ans pour des raisons de rétrocompatibilité. emdash en partant de cette position est la réinitialisation architecturale que le monde orienté WordPress attendait.
Tables dédiées par type de publication
WordPress entasse chaque publication, page, type de publication personnalisé et révision dans une seule table wp_posts avec un discriminateur de type. Les champs personnalisés vont à wp_postmeta sous forme de lignes clé-valeur. Le résultat : interroger un type de publication personnalisé avec trois taxonomies et 12 champs ACF interroge 4-5 tables avec plusieurs JOINs et est la principale source de ralentissement des compilations de pages WordPress. emdash donne à chaque type de publication sa propre table avec des colonnes appropriées. Le modèle de requête est naturellement plus rapide, la stratégie d'indexation est naturellement plus propre, et les sites de 50 000 lignes n'ont pas besoin des 17 plugins de cache que les sites WordPress utilisent pour compenser le choix de schéma.
Intégration IA-first via MCP
La plupart des CMS qui « supportent l'IA » en 2026 signifient qu'ils ont boulonné un appel à l'API OpenAI sur un WYSIWYG. emdash expédie un serveur MCP (Model Context Protocol) prêt à l'emploi plus une CLI JSON. Les agents peuvent lire et écrire du contenu par le biais d'un contrat structuré au lieu de scraper du HTML ou de simuler des sessions de navigateur. C'est l'abstraction appropriée pour les flux de travail de contenu basés sur l'IA qui émergent en 2026 ; traiter les agents comme des constructeurs de première classe plutôt que de les adapter rétrospectivement est un vrai différentiateur.
TypeScript de bout en bout + Astro
Stack moderne, outils modernes, pas de PHP. Sécurité des types de la définition de schéma à travers l'API jusqu'au frontend. Astro pour la couche de rendu apporte le motif rapide par défaut statique-avec-îles. Pour les équipes menées par des développeurs en 2026, c'est le bon stack pour commencer. WordPress n'a pas eu d'amélioration significative de l'expérience d'édition pendant des années ; emdash y arrive en recommençant de zéro.
Ce qui ne va pas (ou du moins vaut la peine d'être remis en question)
TinyMCE en 2026 n'est pas le bon choix d'éditeur
L'examen de Maciek a soulevé ce point et je suis d'accord. Le choix de TinyMCE plutôt qu'un éditeur basé sur des blocs comme Gutenberg ou Portable Text de Sanity ressemble à un pas en arrière. L'édition par blocs est vraiment meilleure pour les workflows de contenu structuré, la publication multi-canal et le contenu assisté par l'IA. L'argument en faveur de TinyMCE — « les utilisateurs le connaissent » — est le même argument que WordPress a utilisé pour retarder Gutenberg de cinq ans avant de le déployer mal. emdash avait la chance de commencer avec un éditeur basé sur des blocs ; choisir TinyMCE offre aux premiers adoptants moins que ce que Sanity, Storyblok et même le WordPress moderne peuvent offrir côté éditorial.
Cela ne résout pas les vrais problèmes des utilisateurs WordPress
Les utilisateurs WordPress ne restent pas sur WordPress à cause des permissions des plugins. Ils restent parce que (a) l'hébergement est bon marché et abondant, (b) l'écosystème de plugins résout les problèmes courants d'emblée, (c) embaucher des développeurs WordPress est facile. emdash ne rend pas encore l'hébergement moins cher (Cloudflare Workers c'est bien mais pas gratuit à l'échelle, et l'auto-hébergement Node.js demande plus de travail opérationnel qu'un hébergement WordPress à 4 $/mois). L'écosystème de plugins est vide à la v0.1.0. Les développeurs WordPress se comptent en millions ; les développeurs emdash se comptent en dizaines. Aucun de ces éléments ne s'améliorera rapidement.
C'est normal — emdash n'essaie pas d'être WordPress pour la longue traîne des créateurs de blogs Etsy-shop. Il essaie d'être la bonne fondation architecturale pour les équipes sérieuses menées par le contenu qui ont dépassé WordPress et veulent une stack moderne. Mais le positionnement marketing doit correspondre : emdash est la bonne réponse pour certaines équipes, pas la bonne réponse pour la majorité WordPress.
L'écosystème de plugins est vide (et le sera pendant 12-24 mois)
Les CMS greenfield font toujours face au problème d'amorçage : la valeur de la plateforme augmente avec la disponibilité des plugins, et les plugins ne sont construits qu'une fois que la plateforme a des utilisateurs, et les utilisateurs ne s'y convertissent qu'une fois que les plugins existent. emdash résoudra cela lentement. Pour les 12-24 prochains mois, les projets sur emdash signifieront écrire le plugin SEO, le plugin sitemap, le plugin multi-langue, le gestionnaire de formulaires et l'intégration de newsletter par email comme travail propriétaire. Budgétez pour cela.
Cloudflare Workers et la dépendance au fournisseur par défaut
Cloudflare Workers est la cible de déploiement principale. Node.js est supporté mais la documentation penche du côté Workers-first. Pour les équipes déjà sur Cloudflare, c'est une fonctionnalité. Pour les équipes qui veulent l'indépendance de stack, cela ressemble à un verrouillage architectural par défaut. Le compromis est réel dans les deux cas ; emdash être natif Cloudflare est cohérent avec ses origines mais signifie un investissement dans l'écosystème Cloudflare plutôt que dans une abstraction portable.
Où emdash s'adapte — et où il ne s'adapte pas
Où ça convient
Les projets greenfield orientés contenu sur Cloudflare Workers + Astro qui veulent la bonne architecture dès le départ. Les déploiements sensibles à la sécurité fatigués de la surface d'attaque des plugins WordPress. Les workflows de contenu IA-natifs où l'intégration MCP compte. Les équipes pilotées par des développeurs avec le cran de supporter une CMS en v0.x en échange d'être à la pointe.
Où ça ne convient pas
Les sites de production critique qui ont besoin de stabilité au moins jusqu'à la v1.0. Les projets pilotés par les équipes marketing où l'expérience éditeur est le facteur décisif (Sanity, Storyblok, Contentful gagnent tous là). Les migrations WordPress où l'écosystème des plugins fait vraiment le travail pour vous. Les blogs sensibles aux coûts avec beaucoup de visiteurs longue traîne où l'hébergement PHP partagé à 4$/mois est la bonne réponse. Les équipes qui ont besoin de recruter des développeurs dans un bassin profond — le bassin de développeurs emdash est petit.
Ma recommandation en 2026
Utilisez emdash d'abord sur un projet secondaire. Construisez quelque chose de réel avec — votre blog personnel, un outil interne, un site de documentation. Expérimentez le modèle de plugins, l'expérience éditeur, l'histoire du déploiement. Après 6-12 semaines vous saurez si les choix architecturaux qui semblent justes sur le papier se sentent vraiment justes en production. S'ils se sentent justes, emdash devient une option sérieuse pour les projets greenfield en 2027. Si la douleur éditeur ou le manque d'écosystème est le facteur décisif, l'expérience vous le dit rapidement.
Mon biais professionnel : je travaille avec des équipes qui ont besoin de choix CMS prêts à expédier aujourd'hui. Pour le travail client 2026, emdash est trop tôt. Pour greenfield 2027, ça pourrait être le défaut pour la bonne forme de projet. L'architecture est correcte ; la maturité n'est pas encore là. Cet écart se ferme un trimestre à la fois.
Où aller ensuite
Si vous voulez l'avis honnête original, l'article de Maciek Palmowski sur maciekpalmowski.dev est la référence canonique. Le projet emdash est sur emdashcms.dev avec la source sur GitHub. Si vous voulez discuter du choix d'une CMS pour votre projet spécifique — emdash, Sanity, Storyblok, Payload, Decap, Tina, Hygraph, WordPress headless, ou quelque chose d'autre — l'appel de 30 min est le bon point de départ. La page /developers/emdash/ sur ce site décrit ce qu'un engagement de développement emdash ressemble en pratique.