EmDash CMS : ce que les agences doivent savoir sur le CMS de Cloudflare

Le 1er avril 2026, Cloudflare a lancé EmDash v0.1.0. Sous licence MIT. TypeScript et Astro. Se présentant comme le « successeur spirituel de WordPress ».

Si vous gérez des sites WordPress pour des clients, qu’il s’agisse de 20 ou de 200 sites, cette nouvelle est apparue dans votre fil d’actualité en l’espace de quelques heures. Votre première réaction s’est sans doute située quelque part entre un soupir et une question : qu’est-ce que cela signifie pour mes contrats de maintenance, mes formules d’assistance et l’activité que j’ai mis des années à développer sur WordPress ?

Vous avez déjà entendu parler du « WordPress killer ».

Ghost a été lancé en 2013 dans un immense battage médiatique et grâce à une campagne Kickstarter qui a battu tous les records. Aujourd'hui, Ghost détient 0,1 % des parts du marché des CMS.

Webflow, la coqueluche de la communauté des designers : 1,2 %. Squarespace : 2,4 %. Wix, soutenu par des milliards de dollars de capitaux boursiers : 4,1 %. Aucun n'a dépassé les 5 %.

Alors que ces concurrents se lançaient, se développaient puis atteignaient un plateau, WordPress est passé de 21 % à 43,4 % de l'ensemble des sites web sur Internet.

Le discours « meurtrier » n'a pas fait ses preuves.

On peut comprendre qu'on ait envie de rejeter EmDash d'emblée, mais Cloudflare n'est pas une start-up en phase d'amorçage avec un dossier de présentation.

Cloudflare est une entreprise d'infrastructure dont le chiffre d'affaires s'élève à 2,17 milliards de dollars et qui se positionne déjà entre une part importante du trafic Web et ses serveurs d'origine, notamment un grand nombre de sites WordPress fonctionnant derrière son proxy.

Les précédents « concurrents de WordPress » étaient des produits de la couche applicative qui se disputaient les utilisateurs un par un. Cloudflare opère au niveau de la couche réseau, et dispose d'un réseau de distribution déjà en place, de relations établies avec les développeurs et de solides réserves financières.

Ainsi, lorsque Cloudflare pénètre un marché, l'infrastructure est déjà en place.

Cette différence est importante. EmDash, de Cloudflare, n'a pas besoin de convaincre les propriétaires de sites d'adopter une nouvelle infrastructure. EmDash doit les convaincre d'utiliser différemment l'infrastructure pour laquelle ils paient déjà.

Cloudflare suit une stratégie bien établie : pénétrer un marché avec une offre gratuite ou à bas prix, atteindre une certaine envergure grâce à sa clientèle existante, puis développer ses activités de monétisation.

Cloudflare a réalisé cela grâce à Workers.

Elle a récidivé avec R2 (qui a supprimé les frais de sortie pour proposer des tarifs plus compétitifs que S3), et EmDash suit la même stratégie.

L'avantage en termes de distribution est bien réel, même si l'issue reste incertaine. Cloudflare n'a pas besoin de faire du porte-à-porte pour convaincre les agences d'essayer un nouveau CMS. L'entreprise entretient déjà des relations avec les développeurs qui créent et gèrent ces sites.

Tout site WordPress hébergé derrière le CDN de Cloudflare constitue une cible potentielle pour la conversion à EmDash. Aucun des précédents « tueurs de WordPress » ne disposait d’un tel canal de distribution déjà en place pour atteindre précisément le public visé.

Ce qu'est réellement le tiret long (et ce qu'il n'est pas)

EmDash est un CMS sans serveur basé sur TypeScript et développé avec Astro 6.0, conçu pour fonctionner en mode natif sur l'infrastructure en périphérie de Cloudflare.

Il ne s'agit ni d'une version dérivée de WordPress ni d'un simple substitut. Il s'agit d'une refonte complète d'un système de gestion de contenu, conçu pour l'informatique en périphérie sans serveur plutôt que pour l'hébergement traditionnel sur une pile LAMP.

La pile technologique

Astro 6.0 s'est classé n° 1 en matière de satisfaction des développeurs dans la dernière enquête « State of JS » et enregistre 900 000 téléchargements hebdomadaires sur npm.

Cloudflare a racheté Astro en janvier 2026, offrant ainsi au projet EmDash le contrôle direct de son infrastructure de base et l'accès à une communauté de développeurs déjà établie.

EmDash s'exécute en mode natif sur Cloudflare Workers (calcul en périphérie sans serveur) et utilise trois primitives de stockage Cloudflare : D1 (une base de données distribuée basée sur SQLite), R2 (un stockage d'objets compatible S3) et KV (un magasin clé-valeur global). Aucun serveur traditionnel à provisionner, mettre à jour ou faire évoluer.

La fonctionnalité phare est l'exécution des plugins en mode sandbox via des isolats. Chaque plugin s'exécute dans son propre environnement grâce aux Dynamic Workers de Cloudflare. Un plugin compromis ou malveillant ne peut accéder ni à la base de données, ni au système de fichiers, ni à la mémoire d'aucun autre plugin ou du CMS lui-même.

WordPress utilise un modèle PHP à processus partagé dans lequel chaque plugin s'exécute au sein du même processus et dispose d'un accès complet à la base de données et au système de fichiers. Un plugin de formulaire de contact vulnérable peut ainsi servir de vecteur de compromission à l'échelle de l'ensemble du site.

Le modèle d'isolation d'EmDash élimine d'emblée toute cette surface d'attaque. Pour quiconque a déjà été confronté au piratage d'un site dont l'origine remontait à un simple plugin abandonné, l'intérêt est immédiat.

L'authentification est un autre domaine dans lequel EmDash se distingue. La prise en charge de Passkey est intégrée par défaut. Ce n'est ni un plugin, ni une extension. C'est la configuration par défaut.

69 % des consommateurs ont désormais configuré des clés d'accès. Celles-ci affichent un taux de réussite de connexion de 93 %, contre 63 % pour les mots de passe traditionnels, mais WordPress continue d'utiliser par défaut le nom d'utilisateur et le mot de passe, la prise en charge des clés d'accès n'étant disponible que via des plugins.

EmDash est le premier CMS conçu pour considérer les agents IA comme des utilisateurs à part entière, plutôt que comme de simples interfaces destinées aux humains. Il intègre des « Agent Skills » (une documentation structurée qui apprend aux modèles d'IA à créer des thèmes et des plugins), une interface en ligne de commande (CLI) avec sortie JSON pour une interaction programmatique, ainsi qu'un serveur MCP intégré. L'ensemble de l'expérience développeur est conçu dès le départ pour être lisible par les machines.

Joost de Valk, créateur de Yoast SEO et l’une des figures les plus influentes de l’histoire de WordPress, a testé ce flux de travail et a qualifié EmDash de « chose la plus intéressante dans le domaine de la gestion de contenu depuis des années ». Il prévoit de s’appuyer sur ce projet, mais son récent désaccord avec le fondateur de WordPress au sujet de l’initiative FAIR rend cette déclaration moins convaincante.

EmDash a également été lancé parallèlement au protocole de paiement x402, soutenu par Stripe, Visa, Mastercard, Google, AWS et Microsoft en tant que membres fondateurs. Ce protocole permet d'effectuer des micropaiements via des agents IA pour moins de 0,001 $ par transaction. Bien qu'il s'agisse pour l'instant d'un projet spéculatif, la liste des fondateurs témoigne d'un engagement institutionnel sérieux.

89 commits sur GitHub et 6 800 étoiles en deux mois de développement assisté par l'IA. C'est une progression impressionnante et un vif intérêt de la part des développeurs dès le début. Mais cela soulève aussi une préoccupation légitime quant à la maturité du projet.

Deux mois de développement assisté par l'IA contre 22 ans de renforcement de la sécurité de WordPress, d'application de correctifs de sécurité et de tests de résistance en conditions réelles sur des centaines de millions d'installations. La rapidité de développement et la rigueur des tests en conditions réelles sont deux atouts distincts. EmDash possède le premier. WordPress possède le second. Les agences ont besoin des deux.

La réalité du verrouillage fournisseur

Les agences doivent-elles s'inquiéter d'une dépendance vis-à-vis des fournisseurs d'EmDash ?

Oui. Les fonctionnalités les plus performantes d'EmDash ne fonctionnent que sur l'infrastructure Cloudflare, ce qui rend impossible, à ce stade, une véritable portabilité entre plateformes.

Le sandboxing des plugins d'EmDash s'appuie sur le modèle « isolate » de Cloudflare Workers. D1, R2 et KV sont des services propriétaires de Cloudflare. Il n'est pas possible d'exécuter D1 sur AWS. Il n'est pas possible de migrer des compartiments R2 vers Azure sans réécrire votre couche de stockage.

Sur les hébergements n'utilisant pas Cloudflare, EmDash se rabat sur SQLite et le stockage sur le système de fichiers local, et le sandboxing disparaît complètement. Le code du CMS est sous licence MIT et entièrement open source. Ce n'est pas le cas de l'environnement d'exécution qui permet ses fonctionnalités clés.

Un code sous licence MIT associé à un moteur d'exécution propriétaire n'est pas synonyme de véritable portabilité. Matt Mullenweg l'a dit sans détour : EmDash « vous empêche pratiquement de changer de fournisseur ».

Si un client dépasse les limites tarifaires de Cloudflare, se heurte à une exigence de conformité imposant un hébergement sur site, ou souhaite simplement regrouper ses fournisseurs, le processus de migration supprime le sandboxing, la base de données distribuée et les performances natives en périphérie. Vous utiliseriez alors EmDash sans les fonctionnalités qui justifient son choix.

Les agences qui ont passé une décennie à mettre en place des flux de travail WordPress indépendants de l'hébergement devraient savoir exactement ce qu'elles évaluent ici.

EmDash redirige les utilisateurs vers plus de cinq produits Cloudflare facturables : Workers (ressources de calcul), D1 (base de données), R2 (stockage), KV (clé-valeur) et Workers AI. Chaque site EmDash est un client Cloudflare qui génère des revenus récurrents liés aux ressources de calcul et au stockage, lesquels évoluent en fonction du trafic.

Mullenweg a déclaré qu'EmDash avait été « créé pour vendre davantage de services Cloudflare ». Sa crédibilité sur ce sujet est discutable (nous y reviendrons plus loin), mais l'analyse structurelle reste valable quelle que soit la source. Le modèle de Cloudflare est bien connu : accès gratuit, monétisation via l'infrastructure.

La société a enregistré un chiffre d'affaires de 2,17 milliards de dollars en 2025 et vise les 5 milliards de dollars d'ici 2028. Le plus gros contrat de Cloudflare a dépassé les 100 millions de dollars, grâce à l'adoption de la plateforme Workers.

EmDash correspond exactement à ce modèle.

Ce n'est pas une critique.

Google a développé Chrome pour protéger ses revenus issus de la recherche. AWS a créé des dizaines d'outils open source pour favoriser l'adoption du cloud. Cloudflare, en développant un CMS pour accroître l'utilisation de Workers et de D1, suit exactement la même stratégie.

Les agences doivent bien comprendre le mécanisme d'incitation et en tenir compte dans leur évaluation. EmDash est un produit véritablement intéressant, et EmDash a pour vocation de faire croître les revenus de la plateforme Cloudflare. Ce n'est ni de la philanthropie, ni du cynisme. C'est du business.

Le débat sur la sécurité des plugins

Les chiffres sont réels

L'argument le plus convaincant avancé par EmDash contre WordPress concerne la sécurité des plugins, et les données le confirment. D'après les données de Patchstack pour 2025/2026, 11 334 nouvelles vulnérabilités ont été signalées dans l'écosystème WordPress, soit une augmentation de 42 % par rapport à l'année précédente.

91 % provenaient de plugins, et non du cœur de WordPress. Le cœur de WordPress est lui-même remarquablement sécurisé. Ce n'est pas le cas de l'écosystème des plugins.

1 966 vulnérabilités ont été classées comme présentant un niveau de gravité élevé (CVSS 7.0+). Le délai médian pondéré entre la divulgation publique et l'exploitation massive était de 5 heures.

Et 46 % de toutes les vulnérabilités signalées n'avaient pas encore fait l'objet d'un correctif au moment où elles ont été rendues publiques. Aucun correctif n'existait lorsque les pirates ont découvert cette vulnérabilité. Ce chiffre de 46 % devrait empêcher les responsables d'agences de dormir et les inciter à adopter Site-Protect, notre technologie de correctifs virtuels. Pour près de la moitié des vulnérabilités nouvellement découvertes, il n'existe aucun correctif disponible.

L'exécution en bac à sable d'EmDash limite l'impact d'une vulnérabilité donnée à l'environnement isolé du plugin concerné. Un plugin de galerie compromis ne pourrait pas obtenir un accès complet à la base de données. Un générateur de formulaires malveillant ne pourrait pas extraire l'intégralité de la table des utilisateurs. Chaque plugin fonctionne dans son propre bac à sable, et une faille dans l'un d'entre eux ne peut pas se propager aux autres.

Il s'agit là d'un véritable avantage architectural par rapport au modèle actuel de WordPress.

Sandboxing vs. Opérations

Mais le sandboxing ne fait que limiter l'étendue des dégâts. Il ne s'attaque pas à la cause profonde.

Le problème central en matière de sécurité sous WordPress n'est pas que les plugins partagent un même processus. Le problème réside dans un déficit de mise à jour et de maintenance qu'aucune architecture ne peut résoudre complètement. Les plugins comportent des failles de sécurité. Les correctifs arrivent trop tard, voire jamais. Les propriétaires de sites ne les mettent pas à jour. Personne ne surveille la situation.

La chaîne de défaillance est d'ordre opérationnel, et non architectural. Un plugin isolé dans un bac à sable qui présente une faille d'injection SQL reste exposé à cette faille. Les données relevant de la portée de ce plugin sont toujours en danger. Le périmètre d'impact est plus restreint. La faille reste la même.

Les améliorations architecturales et la rigueur opérationnelle sont des stratégies complémentaires, et non concurrentes. Le « sandboxing » constitue une architecture plus efficace pour limiter l'étendue des dommages. Mais les sites WordPress que votre agence gère actuellement ne peuvent pas attendre la mise en place d'une nouvelle architecture.

Ils ont désormais besoin d'une gestion active : surveiller chaque plugin pour détecter les failles connues, automatiser les mises à jour sécurisées avec retour en arrière en cas d'échec, envoyer des alertes en cas de problème et veiller à ce qu'aucun site ne passe entre les mailles du filet.

La surveillance des vulnérabilitésWP Umbrella assure cette couche opérationnelle sur tous les sites que vous gérez. Lorsqu’une vulnérabilité est rendue publique, vous devez en être informé pour l’ensemble de votre portefeuille en quelques minutes, et non en quelques heures.

Avec une fenêtre d'exploitation médiane de 5 heures, la différence entre la surveillance automatisée et la vérification manuelle revient à choisir entre une protection proactive et une réaction aux incidents. Les 46 % de vulnérabilités qui sont exploitées sans correctif nécessitent de surveiller la menace, d'évaluer l'exposition et d'appliquer une règle WAF ou de désactiver le plugin avant que l'exploitation ne commence. Ce processus ne peut fonctionner à l'échelle d'une agence que s'il est automatisé et centralisé.

Les arguments économiques contre la précipitation

L'économie WordPress est gigantesque

596,7 milliards de dollars.

C'est la valeur estimée de l'économie de l'écosystème WordPress : hébergement, agences, thèmes, extensions, formation et conseil, tous secteurs confondus. À lui seul, le marché des extensions génère 2,38 milliards de dollars par an.

WordPress alimente 43,4 % de tous les sites web. Plus de 60 000 plugins. Des dizaines de milliers d'agences. Des centaines de sociétés d'hébergement. Des millions de professionnels qui en tirent leur gagne-pain. Il ne s'agit pas d'un acteur établi fragile qui attend d'être bouleversé.

Au moment de son lancement, EmDash compte 89 commits sur GitHub. Aucune boutique de plugins. Aucun écosystème de thèmes. Aucun réseau de partenaires d'hébergement en dehors de Cloudflare lui-même. Aucun programme de formation. Aucune offre d'outils pour les agences. Aucune communauté de freelances bien établie.

Le fossé entre une « architecture prometteuse » et une « plateforme commerciale viable » se mesure en années et en milliards de dollars d'investissements dans l'écosystème.

L'enquête 2026 de l'Admin Bar (622 répondants, 51 pays) met en évidence le caractère structurel de la situation économique des agences. Une agence WordPress compte en moyenne 2,4 personnes et 12,8 ans d'expérience. Il s'agit de petites équipes expérimentées opérant avec des marges très serrées.

Le chiffre le plus révélateur : les agences dont au moins 25 % du chiffre d'affaires provient de sources récurrentes (forfaits de services, contrats de maintenance, honoraires forfaitaires) sont nettement plus rentables que celles qui n'en bénéficient pas. Lorsque le chiffre d'affaires récurrent est nul, 58,3 % des agences déclarent ne pas être rentables. Lorsque ce chiffre d'affaires récurrent est supérieur à 25 %, moins d'une agence sur dix se trouve dans cette situation.

Les revenus générés par les formules d'assistance constituent le pilier financier des agences WordPress prospères.

Dans l'univers d'EmDash, ces revenus récurrents n'existent pas. L'absence d'écosystème de plugins signifie qu'il n'y a pas d'économie de maintenance. Pas de cycles de mise à jour à gérer, pas de surveillance des vulnérabilités à assurer, pas de contrats de maintenance à vendre. Cloudflare se charge de l'infrastructure. Le « serverless » signifie qu'il n'y a pas de gestion de serveurs.

Quel montant une agence facture-t-elle chaque mois pour un site EmDash ?

Faites le calcul pour votre propre entreprise. Si vous gérez 40 sites clients à 100 $ par mois pour des contrats de maintenance, cela représente 48 000 $ de chiffre d'affaires annuel récurrent. Avec des marges de 60 à 80 %, cela correspond à un bénéfice de 29 000 à 38 000 $ rien qu'avec la maintenance.

Pour une agence de 2,4 personnes, cette source de revenus fait souvent la différence entre embaucher un prestataire externe ou non, entre investir dans le marketing ou faire du surplace. Imaginez maintenant que vous deviez annoncer à ces 40 clients que vous les transférez vers une plateforme où le concept de plan de maintenance n'existe pas encore, car l'écosystème de plugins qui génère ces tâches de maintenance n'existe pas encore.

La discussion ne porte pas uniquement sur des aspects techniques. Elle porte à la fois sur le chiffre d'affaires, la fidélisation des clients et le modèle économique.

Vos contrats de maintenance permettent de payer les salaires. Vos contrats d'entretien financent la croissance. Pour supprimer ces sources de revenus, il faudrait les remplacer par quelque chose d'aussi fiable, et cette solution n'existe pas encore.

Les chiffres de la migration

Les migrations de CMS comptent parmi les projets les plus coûteux, les plus perturbateurs et les plus sujets aux échecs qu'une agence puisse entreprendre. Les agences qui en ont déjà vécu une le savent d'expérience. Celles qui n'en ont pas encore fait l'expérience ont tendance à sous-estimer le coût d'un ordre de grandeur.

Les coûts visibles (heures de développement, migration du contenu) ne représentent qu'une partie du problème. Plus de 50 % des migrations de CMS ne parviennent pas à atteindre leurs objectifs en matière de délais, de budget, de parité des fonctionnalités, voire les trois à la fois.

Le coût par site varie entre 10 000 et 50 000 dollars, voire plus, en fonction de la complexité, des intégrations, du volume de contenu et des fonctionnalités personnalisées. Durée : 4 à 9 mois par projet. La formation des équipes, la refonte des processus, les frais liés à la communication avec le client et les imprévus techniques entraînent généralement une augmentation de 15 à 20 % des dépenses de réserve.

Pour une agence gérant 25 sites clients, même en se basant sur des estimations prudentes, cela représente entre 250 000 et 1,25 million de dollars rien qu’en coûts de migration. Calendrier : un à trois ans de fonctionnement parallèle des plateformes pendant la transition.

Chaque site en cours de migration est un site qui ne peut pas bénéficier de nouvelles fonctionnalités, un client dont les demandes sont reléguées au second plan, et une source de revenus menacée si la migration entraîne des régressions ou des temps d'arrêt. Une équipe de 2,4 personnes, forte de 12,8 années d'expertise spécifique à WordPress, ne peut pas assumer ce type de risque lié à la plateforme sur un produit en version 0.1.0.

Shopify, l'une des plateformes les plus prospères de ces vingt dernières années, a mis plus de dix ans à se doter d'un écosystème d'applications significatif. Le répertoire des plugins de WordPress compte plus de 60 000 entrées.

Même si le développement assisté par l'IA accélère la création de plugins, la mise en place d'un écosystème comprenant des générateurs de formulaires prêts à l'emploi, des plateformes de référencement, des intégrations e-commerce, des systèmes de réservation et des passerelles de paiement nécessite des années d'itérations, de corrections de bogues, de documentation et de confiance de la part de la communauté.

Chacun de ces plugins existe parce qu’un développeur ou une entreprise s’est engagé à le maintenir à jour malgré les mises à jour de WordPress, les changements d’environnement d’hébergement et l’évolution des exigences en matière de sécurité. C’est sur cet engagement de maintenance que s’appuient les agences lorsqu’elles recommandent un plugin à un client. Cela ne s’improvise pas du jour au lendemain.

Cloudflare peut accélérer certains de ces processus grâce à des investissements financiers et à des outils d'intelligence artificielle. Cloudflare ne peut toutefois pas remplacer les tests en conditions réelles et l'historique de maintenance qui garantissent la fiabilité des plugins pour les projets clients.

Pourquoi EmDash existe aujourd'hui

Le vide de gouvernance

Le choix du moment par Cloudflare n'était pas fortuit. Le lancement d'EmDash est indissociable de la crise de gouvernance qui a divisé la communauté WordPress à partir de la fin de l'année 2024.

Un différend entre Automattic (la société à l'origine de WordPress.com) et WP Engine, qui avait d'abord porté sur des questions de marque déposée, a conduit à l'exclusion de WP Engine des mises à jour de plugins sur WordPress.org, le principal canal de distribution des plugins WordPress.

159 employés d'Automattic ont quitté l'entreprise dans le cadre d'une offre de rachat, et 79,2 % de ces départs concernaient la division WordPress. Des contributeurs de la communauté ont été bannis de WordPress.org. La confiance dans le modèle de gouvernance s'est effritée selon des lignes de fracture qui n'existaient pas auparavant.

Le projet FAIR, lancé sous l'égide de la Linux Foundation avec 300 contributeurs, vise à mettre en place un référentiel de plugins alternatif ainsi qu'un modèle de gouvernance conçu pour empêcher toute entité unique d'exercer un contrôle unilatéral sur la distribution des plugins.

Un procès devant jury est prévu pour février 2027. Son issue aura des répercussions sur le statut juridique et la structure de gouvernance de WordPress.org, qui toucheront toutes les agences utilisant le répertoire de plugins comme infrastructure.

Cloudflare a saisi l'occasion. La communauté WordPress remettait publiquement en question son propre modèle de gouvernance, sa structure de direction constituant un point de défaillance unique, ainsi que la fiabilité à long terme de WordPress.org en tant qu'infrastructure neutre.

Lorsque l'entité qui contrôle la distribution des plugins peut bloquer unilatéralement l'accès à un hébergeur majeur, toutes les agences qui dépendent de ce répertoire ont des raisons de remettre en question leurs certitudes quant à la stabilité de la plateforme.

La licence MIT d'EmDash (plus permissive que la licence GPL de WordPress, sans obligations de copyleft et avec moins de restrictions quant à l'utilisation commerciale) constituait une réponse directe à ces préoccupations.

Pour les développeurs de plugins, les conditions de licence sont cruciales. La licence GPL de WordPress exige que toutes les œuvres dérivées héritent de la licence GPL, ce qui crée une tension permanente sur le marché des plugins commerciaux. La licence MIT élimine totalement cette friction. Les développeurs commerciaux peuvent créer des plugins propriétaires, les vendre selon leurs propres conditions et intégrer du code sans être soumis aux obligations du copyleft.

Pour les organismes chargés d'évaluer où se dirigeront les flux commerciaux de l'écosystème au cours des 5 à 10 prochaines années, il s'agit là d'un facteur structurel qu'il convient de surveiller. Ce n'est pas déterminant aujourd'hui. Mais si EmDash parvient à la version 1.0 avec une place de marché de plugins viable, le cadre des licences pourrait attirer les développeurs commerciaux d'une manière que la licence GPL ne permet pas.

Le cadre décisionnel de l'Agence

EmDash est-il un concurrent redoutable pour WordPress ?

Non.

Pas aujourd'hui, et probablement pas dans les trois à cinq prochaines années.

Mais EmDash est un concurrent sérieux à long terme que les agences devraient surveiller, et non ignorer. La bonne stratégie à adopter dépend de la taille de votre équipe, de votre clientèle, de votre tolérance au risque et de la composition de votre chiffre d'affaires.

Niveau 1 : Attendre et observer.

Idéal pour : la plupart des agences gérant entre 5 et plus de 50 sites WordPress pour leurs clients, dont l'expertise et le chiffre d'affaires dépendent de WordPress. EmDash en est à la version 0.1.0. Restez sur WordPress. Misez sur l'excellence opérationnelle : surveillance des vulnérabilités, mises à jour sécurisées automatisées, optimisation des performances, rapports clients. Réévaluez EmDash 12 à 18 mois après la sortie de la version 1.0.

À l'heure actuelle, c'est l'investissement opérationnel, et non architectural, qui offre le meilleur retour sur investissement. Réduisez le délai moyen de réponse face aux vulnérabilités des plugins. Automatisez les processus de mise à jour qui nécessitent des heures de travail manuel. Mettez en place un système de reporting qui démontre votre valeur ajoutée au moment du renouvellement.

Ces investissements s'avèrent rentables, quelle que soit l'évolution d'EmDash ou de tout autre CMS. Et leurs effets se cumulent : une agence dotée d'un système de surveillance de sécurité infaillible, de mises à jour sécurisées automatisées et de rapports clients professionnels est plus difficile à quitter pour les clients, inspire davantage confiance aux prospects et s'avère plus résistante face à l'évolution du paysage des CMS d'ici 2028.

Niveau 2 : Expérimenter dans le cadre de projets internes.

Idéal pour : les agences disposant de ressources suffisantes pour la R&D. Lancez un projet personnel ou interne sur EmDash. Testez les outils d'IA. Les compétences des agents et le serveur MCP sont vraiment intéressants pour améliorer la productivité des développeurs.

Définissez un thème. Évaluez comment l'expérience d'édition de contenu se compare à celle de Gutenberg pour le type de sites dont vos clients ont réellement besoin. Forgez-vous votre propre opinion plutôt que de vous fier à des témoignages de seconde main. Mais continuez à travailler pour vos clients sur WordPress. Une expérience personnelle ne comporte aucun risque pour le client. Une migration prématurée comporte en revanche un risque énorme pour le client.

Niveau 3 : Suivre en vue d'une diversification future.

Idéal pour : les agences dont les clients utilisent massivement Cloudflare, les produits d'infrastructure ou celles disposant de capacités de R&D dédiées. Ajoutez EmDash à votre cycle d'évaluation pour 2027. Étudiez l'exécution des plugins en environnement sandbox et la manière dont ce modèle pourrait inspirer vos propres pratiques de sécurité.

Vérifier si l'approche du serveur MCP pourrait être adaptée aux processus de développement WordPress. Suivre l'adoption du protocole de paiement x402. Si les transactions effectuées par des agents IA autonomes deviennent la norme, WordPress aura besoin d'une infrastructure équivalente, et les agences qui auront compris cette tendance dès le début seront bien placées pour la mettre en place.

L'intérêt stratégique ne réside pas ici dans l'adoption d'EmDash. Il s'agit plutôt de comprendre les modèles architecturaux qui finiront par s'imposer dans WordPress via des plugins, des innovations au niveau de l'hébergement ou des mises à jour du cœur du système. Les agences qui se sont intéressées très tôt au WordPress headless sont celles qui ont remporté des contrats avec les grandes entreprises lorsque le marché a évolué. La même dynamique s'applique ici.

Les données sur le sentiment recueillies sur WordPress fournissent un aperçu de la situation à tous les niveaux. Le taux de satisfaction global s'établit à 63,3 %, contre 68 % auparavant. Ce recul est bien réel. Cependant, les agences ayant adopté des processus de travail favorisant l'IA ont enregistré une croissance de 58,5 %, ce qui suggère que la voie à suivre réside dans la modernisation opérationnelle, et non dans l'abandon de la plateforme.

La solution n'est pas de tout reconstruire à partir de zéro. La solution consiste à gérer l'infrastructure existante avec la rigueur opérationnelle qu'exige la plateforme.

Si votre agence gère un grand nombre de sites WordPress, WP Umbrella la solution qu'il vous faut: une infrastructure opérationnelle qui garantit la fiabilité, le professionnalisme et l'évolutivité de vos offres de maintenance WordPress.

Vos sites WordPress ont besoin d'être gérés dès aujourd'hui

11 334 vulnérabilités. Des fenêtres d'exploitation de 5 heures. 46 % non corrigées au moment de la divulgation. Que EmDash réussisse ou échoue au cours des cinq prochaines années, les données de Patchstack ont déjà démontré une chose : les sites WordPress qui ne font pas l'objet d'une gestion active ne sont qu'à un cheveu de la catastrophe.

La question n'est pas de savoir s'il faut gérer votre portfolio WordPress. La question est de savoir si vous le faites avec l'infrastructure adéquate.

WP Umbrella directement aux problèmes mis en évidence par l'architecture d'EmDash, avec des solutions disponibles dès aujourd'hui. La surveillance des vulnérabilités sur l'ensemble des sites depuis un seul tableau de bord, avant l'expiration du délai de 5 heures.

Des mises à jour en toute sécurité, avec contrôle visuel de la régression et restauration automatique, pour que vous n'ayez plus à choisir entre « mettre à jour en croisant les doigts » et « ne jamais mettre à jour ».

Gestion de plusieurs sites (10, 50 ou plus de 200) avec des actions groupées, des contrôles de disponibilité et un suivi des performances. Rapports clients en marque blanche qui démontrent votre valeur ajoutée et justifient vos contrats de maintenance, le tout en mode automatique.

La discussion sur EmDash porte sur l'évolution probable du marché des CMS d'ici 3 à 5 ans. Vos sites WordPress génèrent déjà des revenus pour votre agence. Gérez mieux ce que vous avez.

Commencez votre essai gratuit. Aucune carte bancaire requise.

En résumé

EmDash est un projet ambitieux qui s'appuie sur une infrastructure solide. Plugins en environnement sandbox, authentification par mot de passe, outils de développement natifs pour l'IA : voilà de véritables innovations proposées par une entreprise qui dispose des ressources nécessaires pour s'engager sur le long terme. Il faut rendre à César ce qui appartient à César.

Mais l'attention n'est pas synonyme d'action. WordPress alimente 43,4 % du Web, soutient une économie de 596,7 milliards de dollars, et les sites de vos clients fonctionnent actuellement grâce à lui, générant les revenus qui permettent à votre agence de survivre.

Les agences qui prospéreront en 2026 ne seront pas celles qui se seront lancées à la poursuite d'une plateforme en version 0.1.0.

Ce sont eux qui auront géré leur infrastructure WordPress avec rigueur pendant que tout le monde était distrait par la dernière actualité.

Suivez EmDash. Appréciez le savoir-faire technique. Et gérez ce qui se présente à vous.