Remplacer WordPress en 2027

En date de novembre 2026. Les deux projets évoluent vite. Les versions citées ci-dessous servent d'illustration ; ce sont les arguments d'architecture qui comptent.

Selon W3Techs, WordPress propulse 39,4 % de tous les sites web et 58,1 % de ceux qui utilisent un système de gestion de contenu (CMS). En avril, le même outil le plaçait à 42,5 %. Trois points en sept mois, ce n'est pas un effondrement, et W3Techs ne compte que les dix millions de sites les mieux classés, mais c'est une tendance, et je l'entends chaque mois dans la même conversation : le site est lent, une extension a cassé le paiement, l'agence qui l'a construit a disparu, et le scanner de sécurité s'est illuminé comme un sapin de Noël. « On veut partir. On va où ? »

Pendant des années, ma réponse a été Wagtail. Depuis avril 2026, il y a un nouveau candidat : EmDash, le CMS que Cloudflare a écrit en TypeScript et présente comme le « successeur spirituel de WordPress ». C'est un travail d'ingénierie sérieux, et il mérite un examen sérieux.

Cet article n'est pas une liste de fonctionnalités. C'est la comparaison que je fais avant de valider une migration, et elle répond à trois questions, dans l'ordre : qu'achetez-vous réellement, combien cela vous coûtera-t-il sur cinq ans, et qu'implique vraiment le déménagement ?

L'essentiel

• Quittez WordPress pour reprendre le contrôle, pas pour des fonctionnalités. Ses risques sont le modèle d'extensions et la gouvernance, pas l'éditeur.
• Choisissez Wagtail quand le contenu doit durer des années, quand le modèle de contenu doit être relu et versionné comme du code, quand vous avez des règles sur l'emplacement des données, ou quand votre équipe parle Python.
• Choisissez EmDash quand vous êtes déjà sur Cloudflare avec une équipe TypeScript, que votre contenu prend la forme de campagnes ou d'événements, qu'un hébergement quasi gratuit compte, et que vous pouvez vivre avec un produit en 0.x.
• Le coût, ce sont les gens, pas l'hébergement. Sur cinq ans, l'écart d'hébergement entre les deux se chiffre en quelques milliers de dollars. La migration et la maintenance se mesurent en semaines de développement.
• La gouvernance tranche. La feuille de route de Wagtail appartient à une équipe principale répartie entre plusieurs entreprises, au-dessus de Django et de Python, chacun dirigé par sa propre fondation à but non lucratif. EmDash, son framework et sa plateforme appartiennent tous à Cloudflare.

Où se situe WordPress sur la carte

Avant de comparer quoi que ce soit, dessinez la carte, car la plupart des mauvaises décisions de CMS viennent de la comparaison de produits de familles différentes comme s'il s'agissait de la même chose.

Le marché classe les CMS de deux façons. Selon qui l'exploite : open source que vous hébergez, propriétaire sous licence, SaaS que vous louez. Et selon l'architecture : traditionnel, où le CMS génère lui-même les pages ; headless, où il ne sert le contenu que par une API ; et hybride, qui fait les deux. Ces étiquettes vous disent qui vous payez et où vit le front-end. Elles ne disent rien de la question qui décide si vos rédacteurs seront heureux la troisième année et si votre contenu survivra à la prochaine refonte : comment le contenu est rédigé.

Sur cet axe, il y a deux familles. Les constructeurs de pages (Wix, Squarespace, Webflow, et WordPress avec Divi ou Elementor) vous laissent concevoir la page pendant que vous l'écrivez. La page est le contenu. C'est un document Word : vous placez les choses où vous voulez, ce que vous voyez est ce que vous obtenez, jusqu'au jour où vous avez besoin de la même chose dans une autre mise en page et découvrez qu'il n'y a pas de « chose », seulement une mise en page. Les CMS structurés (Wagtail, EmDash, Umbraco, Drupal, Statamic, les produits headless) obligent un développeur à définir ce qu'est une page : un titre, une introduction, une liste de blocs, un auteur, une date. Un rédacteur remplit les champs et le design s'applique ensuite. C'est une base de données avec une feuille de style. Le contenu est une donnée, la mise en page en est une vue, et vous pouvez changer la vue de toutes les pages d'un coup sans toucher à aucune d'elles. Karen McGrane appelait les deux camps les « blobs » et les « chunks » : les masses et les morceaux. Plus difficile le premier jour, plus facile la troisième année, et la seule façon pour le contenu de survivre à une refonte, à un deuxième canal ou à un agent IA qui le réclame.

Selon les étiquettes du marché, WordPress est un CMS traditionnel, open source et auto-hébergé, et la presse le range à côté de Drupal plutôt que de Wix. Selon l'axe qui compte, c'est un moteur de blog de 2003 avec un constructeur de pages boulonné par-dessus et une boutique d'applications boulonnée sur le côté. Il promet les deux familles et livre mal les deux, avec un contenu stocké dans sa mise en page (blocs HTML, shortcodes ou JSON d'un constructeur) que ni un designer ni une machine ne peut réutiliser sans risque.

Voici donc la réponse honnête à une question qu'on me pose souvent : pourquoi un utilisateur de Divi passerait-il à Wagtail plutôt qu'à Wix ? Souvent, il ne devrait pas. Si vous gérez un site vitrine et que vous aimez concevoir vos pages dans le navigateur, un constructeur hébergé fait ce que fait WordPress-plus-Divi, avec l'hébergement, la sécurité et les mises à jour gérés par quelqu'un dont l'activité en dépend. Allez-y sans regarder en arrière. Le lecteur de cet article est celui qui a dépassé ce stade : contenu réutilisé entre pages ou canaux, intégrations, multilingue, règles sur l'emplacement des données, un site qui fait partie de l'activité plutôt que d'en être la vitrine. Que ce lecteur soit un seul rédacteur ou vingt, il a besoin de structure, et le reste de cet article est pour lui.

Les raisons de quitter WordPress

Soyons justes envers WordPress : il a gagné ses parts de marché parce que n'importe qui peut l'installer, trouver un thème et greffer une extension pour n'importe quoi. Mais aujourd'hui, c'est aussi exactement pour cela que les gens partent.

• Les extensions partagent tout. Une extension tourne dans le même processus PHP que le cœur, avec un accès complet à la base de données et au système de fichiers. Cloudflare affirme que 96 % des problèmes de sécurité de WordPress viennent des extensions. Les données 2025 de Patchstack parlent de 91 % des nouvelles vulnérabilités. Le chiffre varie, la conclusion non.
• Le contenu est une soupe HTML. Gutenberg stocke les blocs en HTML, avec des commentaires comme marqueurs. Dès que vous voulez ce contenu ailleurs (une application, une API, un deuxième site, un LLM), vous analysez du HTML.
• Le modèle économique, c'est la pile d'extensions. Cache, SEO, formulaires, sécurité, sauvegarde : cinq dépendances avec cinq cycles de publication, cinq licences et cinq surfaces d'attaque avant d'avoir écrit une ligne de contenu.
• L'administration est un panneau publicitaire. Chaque extension ajoute un menu, un écran de réglages et une bannière qui quémande une mise à niveau ou une note cinq étoiles. Vos rédacteurs travaillent dans les tunnels de vente d'une douzaine d'éditeurs, et le seul avertissement de sécurité qui comptait est enfoui sous les publicités.

En règle générale, les problèmes qu'on reproche à WordPress sont des problèmes de pile d'extensions mal entretenue. Un site WordPress bien entretenu va très bien, techniquement. Le problème, c'est que « bien entretenu » est l'exception, et que l'architecture ne vous aide en rien.

La cinquième raison n'est pas technique

En septembre 2024, le fondateur du projet WordPress, Matt Mullenweg, s'en est pris à WP Engine, l'un des plus grands hébergeurs WordPress, au sujet de redevances de licence de marque. En quelques semaines, wordpress.org avait coupé l'accès des serveurs de WP Engine aux mises à jour d'extensions et de sécurité, et remplacé Advanced Custom Fields, une extension installée sur des millions de sites, par un fork d'Automattic portant le même nom : les sites ont changé de propriétaire d'extension à leur mise à jour suivante, que leurs administrateurs le veuillent ou non. Il a fallu une injonction préliminaire fédérale, en décembre 2024, pour rétablir l'accès.

Aucun de ces sites n'avait rien fait de mal. Ils étaient entretenus, chez un hébergeur réputé, et ils ont perdu leur canal de mises à jour à cause d'un différend entre deux entreprises sur lequel ils n'avaient aucune prise. Les séquelles se font encore sentir : WordPress est passé à une seule version majeure par an en 2025, invoquant des « ressources détournées en raison de procédures judiciaires en cours », le propre conseil d'administration d'Automattic a brièvement mis Mullenweg en congé en septembre 2026, et le tribunal a laissé avancer les accusations de monopolisation portées par WP Engine. Aucune date de procès n'est fixée.

Vous pouvez avoir une pile d'extensions parfaite et ne toujours pas maîtriser ce risque. Règle empirique : si la feuille de route d'un projet dépend de l'humeur d'une seule personne, ce n'est pas votre feuille de route.

Où aller ?

Vous avez décidé de partir. La bonne destination dépend moins des fonctionnalités que de qui construit et entretient le site.

Les deux dernières lignes sont celles que compare cet article.

Les suites d'entreprise ne sont généralement pas là où atterrissent ceux qui quittent WordPress, mais la frontière est plus mince que ne le suggèrent les prix. Beaucoup d'organisations sur AEM ou Sitecore utilisent une fraction de la suite et la paient en entier. Wagtail gère déjà le contenu de la NASA, du NHS et de Google, et à cette échelle le schéma habituel est une pile composable : Wagtail comme hub de contenu, à côté de services dédiés de recherche, d'analytique ou de personnalisation. Savoir s'il peut remplacer une suite complète est une autre question, avec une autre réponse, et le sujet d'un autre article.

Ce que vous achetez

En une phrase chacun : Wagtail est un CMS open source éprouvé dont la structure de contenu vit dans votre code, et EmDash est un jeune CMS de Cloudflare dont la structure de contenu vit dans sa base de données et qui tourne au mieux sur le réseau de Cloudflare. Les détails suivent.

Wagtail est un CMS construit sur Django, créé par Torchbox en 2014 et utilisé, entre autres, par la NASA, Google, Mozilla, le NHS, le MIT et Oxfam. Licence BSD, plus de 1 000 contributeurs, une feuille de route publique, une version LTS tous les douze mois (actuellement la 7.4, la 8.1 étant la dernière version publiée). Votre modèle de contenu est un modèle Django : champs typés, StreamField pour des mises en page souples à base de blocs, chaque révision versionnée. Le schéma vit dans votre dépôt et évolue par pull request et migration, comme n'importe quel autre code. Un rédacteur ne peut pas « juste ajouter un champ » depuis l'administration, ce qui devient un avantage dès que plus d'une personne touche au site. Tout ce que Django offre (ORM, authentification, formulaires, vingt ans de paquets) est disponible à côté de votre contenu. Vous l'hébergez partout où Python tourne.

EmDash est un CMS écrit en TypeScript au-dessus d'Astro, que Cloudflare a racheté en janvier 2026. Il a été annoncé le 1er avril 2026 sous forme de préversion pour développeurs v0.1.0, construit en environ deux mois par Matt Kane, de l'équipe principale d'Astro, avec un recours intensif à des agents de codage IA et, insistent-ils, sans aucun code de WordPress. Licence MIT. Le contenu est du JSON structuré (Portable Text), un progrès énorme par rapport à WordPress, mais les types de contenu vivent dans la base de données, pas dans le code : le fichier d'amorçage d'un thème définit les collections initiales, et un administrateur peut ensuite créer et modifier des types depuis l'interface d'administration. C'est plus proche de Contentful que de Django : rapide pour prototyper, aucun déploiement pour ajouter un champ, et aucun schéma sous contrôle de version à moins d'instaurer cette discipline vous-même. Chaque extension tourne dans un bac à sable isolé avec des capacités déclarées, chaque instance embarque un serveur MCP pour les agents IA, et il est conçu pour Cloudflare Workers avec D1 et R2, même s'il tourne aussi sur n'importe quel serveur Node.js.

Autre décennie, autre philosophie, même cible.

Les extensions et le rayon d'impact

Le principal argument de Cloudflare est la sécurité par l'isolation, et c'est un bon argument. Chaque extension EmDash tourne dans son propre isolat V8 (un « Dynamic Worker ») et déclare ce dont elle a besoin dans un manifeste : read:content, email:send, etc. Une extension de newsletter compromise ne peut pas lire votre table d'utilisateurs, parce qu'elle n'en a jamais eu la capacité. C'est le modèle des scopes OAuth appliqué à un CMS, et c'est ainsi que les extensions auraient toujours dû fonctionner.

Deux réserves que l'annonce ne met pas en titre :

1. Le bac à sable n'existe que sur Cloudflare. Les Dynamic Workers exigent l'offre Workers Paid (à partir de 5 $ US par mois). L'auto-hébergement sur Node.js ne vous donne pour l'instant aucune extension isolée. La pique de Matt Mullenweg, selon qui la sécurité des extensions « ne fonctionne que sur Cloudflare », est aujourd'hui tout simplement vraie.
2. Il n'y a presque pas d'extensions. La place de marché emdashcms.org existe, et les extensions y sont auditées automatiquement avec Workers AI. L'adoption est minime ; il n'y a ni constructeur de pages ni couche commerce. WordPress compte plus de 60 000 extensions et 14 000 thèmes. Cet écart ne se comble pas parce que l'architecture est meilleure.

Wagtail adopte la position inverse : il n'y a pas d'« extensions », il y a des paquets Python. Ils tournent dans le même processus avec un accès complet, exactement comme une extension WordPress. La différence est procédurale, pas architecturale : vous en installez beaucoup moins, parce que Django fait déjà l'essentiel, et vous les examinez comme n'importe quelle dépendance. Wagtail lui-même a une politique de sécurité publiée, corrige rapidement les vulnérabilités CVE (Common Vulnerabilities and Exposures) et prévoit un audit de sécurité indépendant dans sa feuille de route.

Vous pouvez aussi tester les mises à jour de WordPress sur un site de préproduction, et les bonnes agences le font. Mais la structure d'un site WordPress vit dans sa base de données : les extensions y conservent leurs réglages, leurs champs personnalisés et leurs mises en page, en lignes à côté de votre contenu. Pour tester une mise à jour, il vous faut une copie fraîche de la production, données personnelles comprises, à chaque fois. Sur Wagtail, le modèle de contenu est du code. Chaque type de page et chaque champ est défini dans le dépôt, de sorte qu'un développeur peut générer des données de test réalistes à partir de ces modèles et essayer la mise à jour sans jamais toucher aux données de production.

Aucune plateforme ne vous rend sûr. EmDash vous donne de meilleurs réglages par défaut, sur la plateforme d'un seul fournisseur. Wagtail vous en donne des éprouvés et ennuyeux, où vous voulez.

L'hébergement et la question de la dépendance

En bref : Wagtail tourne partout et reste toujours actif. EmDash coûte le moins cher sur Cloudflare et ne coûte presque rien quand personne ne visite le site.

Wagtail est une application web classique : un processus Python, PostgreSQL (s'il vous plaît), des médias compatibles S3, un cache. Un VPS avec gunicorn, des conteneurs, un PaaS, Azure App Service, sur site : rien dans tout cela ne se soucie de votre fournisseur. Il n'y a pas de mise à l'échelle jusqu'à zéro. Depuis la 8.0, il existe une option hybride crédible : faire tourner Wagtail uniquement comme API et placer un front-end JavaScript en périphérie. Le bakerydemo-headless officiel (5 novembre 2026) fait exactement cela avec Next.js, et atteint la parité fonctionnelle avec la démo classique uniquement grâce à l'API v3, avec des types TypeScript générés à partir du schéma OpenAPI et un aperçu en direct qui affiche la vue Next.js. Notez que l'API v3 est encore étiquetée comme préversion : parlez donc d'une démo officielle, pas encore d'un modèle pour la production.

EmDash est « conçu pour Cloudflare Workers », et ce n'est pas une formule marketing. La pile de référence est Workers + D1 (SQLite) + R2 + KV pour le cache, et elle est remarquablement bon marché : le propre blog de Cloudflare tourne dessus, à environ 75 requêtes par seconde un jour normal, avec des pics au-delà de 5 000, des tests de charge jusqu'à 7 000, et des temps de réponse au 95e centile qui restent stables. Vous descendez à zéro au repos et vous payez le temps CPU.

Mais regardez cette migration de près : Cloudflare n'a pas utilisé D1. Ils ont utilisé Hyperdrive pour atteindre une base de données PlanetScale, parce que SQLite en périphérie convient à un blog, et moins bien à tout ce qui est relationnel. La couche de stockage (Kysely) prend aussi en charge Turso et PostgreSQL, vous n'êtes donc pas coincé, mais chaque pas hors de la pile de référence est un pas que vous faites seul, sans documentation écrite pour vous.

EmDash est techniquement portable et pratiquement taillé pour Cloudflare. Si vous êtes déjà sur Cloudflare et que vous y êtes bien, ce n'est pas un problème. Si votre client a une politique sur l'emplacement des données (bonjour le secteur public québécois et les services financiers), c'est une discussion à avoir dès le premier jour.

Qui détient les clés

La gouvernance mérite le même examen que celui que nous venons de faire pour WordPress, et c'est là que les deux candidats diffèrent. EmDash est, aujourd'hui, le projet d'une seule entreprise dont le métier est de vendre Workers, sans modèle de gouvernance publié et sans encore aucun committer extérieur à Cloudflare. La licence MIT protège le code, pas la feuille de route. Wagtail a une feuille de route publique sur six mois, une équipe principale répartie entre plusieurs entreprises, un engagement LTS, un guide pour les mainteneurs de paquets et une licence BSD. Torchbox l'a créé et le parraine, mais ne peut couper personne d'un répertoire d'extensions, parce qu'il n'y en a pas. Après la débâcle de WordPress en 2024, ce n'est pas une distinction abstraite.

Les couches inférieures comptent autant que le CMS. Wagtail repose sur Django et Python, chacun doté de sa propre gouvernance indépendante. Python est dirigé par la Python Software Foundation et un conseil de direction élu par ses développeurs principaux. Django est dirigé par la Django Software Foundation, un organisme à but non lucratif qui rémunère des Fellows pour trier les bugs et publier les correctifs de sécurité, avec son propre conseil de direction élu. Si Torchbox disparaissait demain, Django et Python ne s'en apercevraient pas, et l'équipe principale de Wagtail compte déjà des personnes de plusieurs autres entreprises. Autour d'eux, une communauté vieille de deux décennies : des DjangoCon sur plusieurs continents, des événements Wagtail Space et un vivier de recrutement qui ne dépend pas d'un seul fournisseur. La pile d'EmDash est à l'opposé. Le CMS, Astro (le framework sous-jacent) et Workers (la plateforme pour laquelle il est conçu) appartiennent tous à Cloudflare. C'est efficace tant que les intérêts d'une seule entreprise rejoignent les vôtres, et c'est un point de défaillance unique le jour où ils divergent.

Pour être juste envers Cloudflare, le risque n'est pas celui de WordPress. Une entreprise cotée qui veut des développeurs sur sa plateforme a toutes les raisons de ne pas prendre leurs sites en otage. Le risque réaliste est le risque ordinaire d'un projet open source d'entreprise : les priorités changent, l'équipe passe à autre chose, et la communauté hors de l'entreprise n'est pas encore assez grande pour prendre le relais.

IA et agents : toujours le facteur différenciant ?

En bref : EmDash a été conçu pour les agents IA dès le premier jour. Wagtail a rattrapé son retard rapidement ces trois derniers mois, mais ses nouvelles briques sont encore étiquetées comme préversions.

C'est là qu'EmDash innove. Chaque instance embarque un serveur MCP, une CLI et des « Agent Skills » : une documentation qui apprend à un agent de codage à modifier l'installation, convertir un thème WordPress, écrire une extension. Votre CMS est un citoyen de première classe pour un agent, pas un site qu'il doit aspirer. Ajoutez les micropaiements x402 et vous pouvez, en théorie, facturer les agents à la requête. Joost de Valk (Yoast) y voit « la chose la plus intéressante en gestion de contenu depuis des années », et si vous croyez que les cinq prochaines années de trafic web incluront beaucoup d'agents, c'est un pari stratégique.

La réponse de Wagtail est arrivée en trois mois. La 8.0 (août) a introduit une API REST v3 sur Django Ninja, avec écritures authentifiées (créer, modifier, publier, rétablir) et des schémas OpenAPI 3.1 générés. Des agent skills officielles pour les développeurs Wagtail ont suivi en octobre. La 8.1 (2 novembre) a ajouté les opérations de flux de travail via l'API, les schémas des blocs StreamField, un prototype de CLI wagtail qui connecte des agents à un site en production, et la possibilité pour une même URL de servir du HTML, du JSON ou du Markdown selon l'en-tête Accept. La démo headless est arrivée trois jours plus tard. Lisez le blog du projet d'octobre et de novembre : il parle presque exclusivement d'agents, d'API et d'expérience développeur autour de l'IA. Quoi qu'ait voulu dire « complémentaire » en avril, ce mot ne décrit pas ceci.

Deux différences demeurent. L'API v3 est une préversion et la CLI « peut encore avoir quelques aspérités », selon les mots de l'équipe principale. Et Wagtail n'a pas de serveur MCP dans le cœur, là où EmDash en livre un par instance. EmDash a été conçu autour des agents dès le premier jour. Wagtail greffe la même idée sur une base de code de douze ans, prudemment, avec des avertissements de dépréciation. L'un vous coûte en maturité, l'autre en migration.

Règle empirique : si « des agents consommeront mon contenu » figure dans le plan d'affaires, les deux sont crédibles et EmDash mérite encore un prototype. Si c'est dans la présentation mais pas dans le budget, ce n'est pas une raison de choisir un CMS.

Ce que Wagtail vous fait payer

Avant le verdict, la partie qu'un spécialiste de Wagtail doit dire à voix haute, et dire avec exactitude.

Wagtail livre plus de choses de série que sa réputation ne le laisse croire : redirections (créées automatiquement quand un slug change), formulaires, plans de site, recherche, champs de titre et de description SEO avec contrôle de longueur, flux de validation éditoriale, prise en charge multilingue, déclinaisons d'images, une administration accessible. Ce qu'il ne livre pas, c'est un thème. Il n'y a pas de place de marché de front-ends à installer un samedi après-midi. Vous construisez les gabarits, ou un front-end JavaScript au-dessus de l'API, et ils vous appartiennent. Pour un propriétaire de site habitué à acheter un thème à 59 $, c'est là le changement culturel, et c'est un coût qui se mesure en jours de développement avant que la première page s'affiche. La recherche est l'autre lacune, honnêtement : le moteur basé sur la base de données convient pour quelques milliers de pages ; au-delà, vous faites tourner Elasticsearch ou OpenSearch, ce qui fait une chose de plus à exploiter.

Les mises à niveau sont du travail planifié, pas une suite de surprises. Une LTS de Wagtail arrive tous les douze mois et va de pair avec une LTS de Django. Django 5.2, requis par Wagtail 7.4, est pris en charge jusqu'en avril 2028. Un client sur une paire de LTS peut rester immobile pendant un an et ne recevoir que des correctifs de sécurité, et la mise à niveau annuelle représente généralement quelques jours de développement avec une suite de tests correcte. Quand Wagtail abandonne une version, il suit la fin de vie en amont (Django 4.2 a quitté le support étendu en avril 2026, Python 3.10 en octobre 2026), et les dépréciations viennent avec un délai : l'API v2, remplacée par la v3, continue de fonctionner pendant toute la série 8.x avec des avertissements, avant sa suppression en 9.0. C'est un seul arbre de dépendances coordonné avec un chemin documenté, pas vingt extensions de vingt éditeurs. Le coût est une ligne dans le budget annuel. Le scénario d'échec, c'est le client qui saute deux cycles LTS et transforme quelques jours en quelques semaines.

L'administration est un éditeur de contenu structuré, pas un constructeur de pages. Les rédacteurs ont des champs typés, des blocs StreamField et un aperçu en direct. Ils n'ont pas de « glissez une bannière ici ». Certains rédacteurs le préfèrent au bout d'une semaine, d'autres ne vous le pardonnent jamais. Sachez lesquels vous avez avant de promettre quoi que ce soit.

Recruter pour Wagtail, c'est recruter pour Django, ce qui est facile. Les spécificités de Wagtail demandent quelques semaines à un développeur Django, moins qu'il n'en faut à un développeur WordPress pour comprendre ce que fait le functions.php d'un thème. Et il n'y a pas de version serverless pour la partie Python : quelque chose tourne toujours, même à 3 h du matin avec zéro visiteur. À 20 $ par mois, c'est une ligne de dépense plutôt qu'un argument, mais c'est une différence, et la mise à l'échelle jusqu'à zéro d'EmDash en est une réelle.

Ce que cela coûte sur cinq ans

Ces fourchettes viennent de mes propres projets. Les vôtres différeront, mais la forme restera la même.

Lisez le tableau de bas en haut. L'hébergement est le plus petit chiffre : une seule semaine de développement coûte plus que cinq ans de VPS. La décision se joue sur les lignes équipe et maintenance.

Hébergement. Un site Wagtail pour une petite ou moyenne organisation tourne confortablement sur un VPS à 20 à 60 $ US par mois avec PostgreSQL et du stockage objet, ou à 100 à 300 $ par mois sur un PaaS géré si vous ne voulez rien exploiter. Ajoutez un hébergeur front-end si vous passez en headless. EmDash sur Cloudflare commence à 5 $ par mois pour Workers Paid, plus l'usage. Les niveaux gratuits de D1 et R2 couvrent la plupart des sites de contenu, et un site très fréquenté dépasse rarement 30 $ par mois. Sur l'hébergement seul, EmDash est deux à quatre fois moins cher qu'un VPS et jusqu'à dix fois moins cher qu'un PaaS géré dans le bas de la fourchette, et l'écart se réduit à mesure que le trafic augmente.

Migration. Un site vitrine ou un blog avec une structure de contenu propre : deux à quatre semaines pour l'une ou l'autre cible, l'essentiel étant du travail front-end. Un site riche en contenu ou multilingue, avec des types de publication personnalisés, des formulaires et quelques années d'historique éditorial : deux à quatre mois. Un site dont la logique métier vit dans des extensions (adhésions, catalogue, réservation, commerce) : c'est une reconstruction, pas une migration, et le CMS en est la plus petite moitié. Sur Wagtail, cette logique devient du code Django. Sur EmDash, elle devient des extensions que vous écrivez vous-même, aujourd'hui.

Maintenance. La mise à niveau LTS annuelle de Wagtail décrite plus haut représente deux à cinq jours de développement avec une suite de tests correcte, davantage si l'équipe précédente a sauté un cycle. Les correctifs de sécurité entre deux sont généralement un simple changement de version. EmDash est en 0.x, la réponse honnête est donc « inconnu, et attendez-vous à des changements incompatibles jusqu'à la v1 » : une mise à niveau en 0.x peut prendre un jour, ou une semaine.

Équipe. Wagtail, c'est un recrutement Django, dans un large vivier. EmDash, c'est un recrutement TypeScript et Cloudflare avec, à ce jour, personne qui l'ait fait tourner en production pendant un an. La question des cinq ans tient surtout à cette ligne.

Ce qu'une migration implique vraiment

L'import lui-même n'est plus la partie difficile, et ce n'est plus le travail d'un paquet. Wagtail a wagtail-wordpress-import et EmDash un assistant WXR qui convertit plus de 30 types de blocs Gutenberg. Les deux font un premier passage correct sur du contenu Gutenberg simple, et les deux calent sur ce qui fait de votre site le vôtre : shortcodes, champs personnalisés aux clés cryptiques, balisage de constructeur de pages. Un agent IA fait mieux ce travail de correspondance. Donnez-lui l'export WordPress et votre nouveau modèle de contenu : il transforme chaque article en champs typés et en blocs, liste ce qu'il n'a pas pu placer, et recommence quand vous changez le modèle. Relisez sa sortie comme n'importe quel autre script de migration. Les thèmes et les extensions sont réécrits dans les deux cas. Quiconque vous dit le contraire n'en a jamais fait. Voici où passe le temps.

Le modèle de contenu. WordPress a laissé l'agence précédente stocker n'importe quoi n'importe où : des champs personnalisés aux clés cryptiques, des shortcodes dans le corps des articles, une taxonomie que personne ne se souvient d'avoir créée. La première semaine, c'est de l'archéologie. Vous décidez de ce qui devient un champ typé, de ce qui devient un bloc et de ce qui disparaît. C'est l'étape qui détermine si le nouveau site sera meilleur ou simplement différent.

URL et redirections. Chaque slug qui change est une 301 à écrire, et celles que vous oubliez sont les pages vers lesquelles Google envoyait du trafic. Exportez l'inventaire des URL avant de toucher à quoi que ce soit, explorez l'ancien site, établissez la correspondance, et gardez la table de redirections sous contrôle de version. Attendez-vous à une baisse visible du référencement pendant quatre à huit semaines, même si vous faites tout correctement, et prévenez le client avant, pas après.

Médias. Des milliers d'images avec des variantes de taille générées par WordPress, liées directement depuis le corps du contenu, dont la moitié orphelines. Décidez tôt si vous migrez les originaux et laissez le nouveau CMS générer les déclinaisons (oui) ou si vous copiez les variantes (non).

Les formulaires et les cinq oubliés. Chaque site WordPress a une extension de formulaire de contact, un extrait de code d'analytique, une bannière de cookies, une intégration de newsletter et une extension que personne ne sait expliquer. Chacun est une conversation avec le client : la fonction survit-elle, et à qui appartient-elle ensuite ?

Les rédacteurs. Les personnes qui ont utilisé Gutenberg pendant six ans n'aimeront pas StreamField ou TipTap dès le premier jour. Prévoyez une demi-journée de formation et un guide écrit, et comptez deux semaines de questions « tu pourrais juste… ». Les migrations qui échouent sont rarement techniques. Ce sont celles où les rédacteurs retournent sur l'ancien site parce que personne ne leur a montré le nouveau.

La bascule. Faites tourner les deux sites en parallèle, gelez le contenu de l'ancien pendant 48 heures, importez, vérifiez la table de redirections, basculez le DNS, conservez l'ancienne base de données pendant six mois. La propre migration de Cloudflare vers EmDash a utilisé un proxy avec un cookie de version pour faire passer le trafic de 1 % à 100 % en une journée, avec un retour automatique en cas d'erreur. Vous pouvez faire la même chose avec n'importe quel reverse proxy, et vous devriez.

Alors, lequel ?

Faites abstraction de la pile technique, et le choix porte sur votre contenu : combien de temps il doit vivre, et qui contrôle ce qu'il signifie.

Combien de temps il vit. Certains contenus sont éphémères : une campagne, une page d'événement, un lancement oublié au bout de trois mois. D'autres sont saisonniers : un programme ou un catalogue reconstruit chaque année sur le même squelette. Et d'autres s'accumulent : la base de connaissances, les archives, les études de cas, les pages de référence qui grandissent un peu chaque jour et qui, au bout de dix ans, sont la propriété intellectuelle de l'organisation. Plus vous êtes à droite sur cette ligne, moins le CMS compte et plus son modèle de données importe.

Qui contrôle le modèle. C'est la vraie monnaie d'échange. Dans Wagtail, un événement a une date, un lieu et un intervenant parce qu'un développeur l'a écrit dans le code. Le modèle est versionné dans Git, modifié après relecture, et lisible par quiconque hérite du site. Dans EmDash, un administrateur peut remanier une collection depuis l'administration en une minute. C'est la liberté le premier jour et la dérive la troisième année, à moins que quelqu'un ne prenne en charge le modèle et ne le garde hors de portée de la base de données. Contentful montre qu'un schéma défini en base de données peut durer, mais il l'associe à des environnements séparés et à des migrations scriptées. EmDash propose aujourd'hui un écran Content Types réservé à l'administration et une commande qui exporte le schéma dans un fichier, et pas grand-chose de plus.

Ce que reçoit l'IA. Une IA n'est utile qu'à la mesure de ce que vous lui fournissez. Un modèle typé (ceci est un intervenant, ceci est une date, cette page remplace celle-là) donne à un agent ou à un pipeline RAG un contexte propre et fiable. Un tas de blocs lui donne une devinette. Les deux CMS stockent du contenu structuré, et EmDash embarque un serveur MCP pour le servir. Mais le modèle que vous contrôlez, documentez et gardez dans Git est celui que vous pourrez encore fournir à la prochaine IA, et à celle d'après, longtemps après que ce CMS aura été remplacé.

Où il vit vient en dernier, parce que cela peut changer. Wagtail tourne là où vous le décidez. EmDash est le plus à l'aise sur Cloudflare. Si vous avez des règles sur l'emplacement des données, réglez la question dès le premier jour. Sinon, c'est une facture d'hébergement.

On ne quitte pas WordPress pour des fonctionnalités. On le quitte parce qu'on a perdu le contrôle : des extensions qui tournent dans sa base de données, du canal de mises à jour, d'une feuille de route qu'une seule personne a retournée contre soi. Le remplaçant doit rendre ce contrôle.

Wagtail le fait, sur trois plans. Le modèle est du code dans votre dépôt, relu comme du code. La plateforme, c'est partout où Python tourne. La feuille de route appartient à une équipe principale répartie entre plusieurs entreprises, sur une pile dont aucune couche n'appartient à un seul fournisseur, sans répertoire dont quiconque pourrait vous couper. EmDash vous donne le code, sous licence MIT. Mais le modèle vit dans une base de données qu'un administrateur peut remanier, le bac à sable ne fonctionne que sur Workers, et la feuille de route appartient à une entreprise qui vend Workers. La v1 comblera l'écart de fonctionnalités. Elle ne changera pas qui détient les clés.

Cela ne fait pas d'EmDash le mauvais choix partout. Choisissez-le quand :

• vous êtes déjà sur Cloudflare et votre équipe écrit du TypeScript ;
• le contenu a une durée de vie courte : campagnes, événements, lancements ;
• un hébergement quasi gratuit compte davantage qu'une feuille de route sur cinq ans ;
• les agents qui consomment votre contenu figurent au budget, pas seulement dans la présentation ;
• vous pouvez absorber des changements incompatibles jusqu'à la v1.

Si vous ne partez pas encore. Rester sur WordPress ne vous rend rien. Traitez le site comme quelque chose à mettre hors service selon un calendrier, pas comme un endroit où s'installer :

1. Gelez le nombre d'extensions.
2. Gardez le contenu exportable.
3. Fixez la date de sortie avant que le prochain incident ne la fixe pour vous.

Quitter WordPress est l'occasion de reprendre possession de votre site. Wagtail est l'option avec laquelle vous le faites vraiment.

Si vous préparez une sortie de WordPress et souhaitez un deuxième avis sur l'architecture, le chemin de migration ou l'hébergement, n'hésitez pas à me contacter. J'en ai fait assez pour savoir où sont enterrés les cadavres, et la plupart se trouvent dans la table de redirections.