De WordPress à Astro : la fausse simplification du web moderne

On voit passer régulièrement des articles enthousiastes de développeurs ou de responsables IT expliquant pourquoi ils ont enfin franchi le pas : quitter ce « bon vieux » WordPress pour migrer vers un générateur de site statique comme Astro. Le discours est souvent le même. On nous parle d’assainissement, de performance retrouvée, de sécurité absolue et, surtout, de simplification de l’infrastructure. Après la vague du headless, dont j’avais déjà analysé la tendance surévaluée, voici donc la vague du statique intégral.

Mais quand on regarde d’un peu plus près l’architecture mise en place pour remplacer un simple WordPress, on a de quoi rester perplexes.

L’architecture « simplifiée » en pratique

Prenons le schéma classique de cette nouvelle stack en vogue :

1. Les contenus ne sont plus enregistrés dans une base de données avec une interface visuelle, mais rédigés en JSON ou Markdown et versionnés dans un dépôt Git.
2. Un moteur de rendu (Astro) récupère ces fichiers lors d’une étape de compilation (build) pour générer des fichiers HTML statiques.
3. Le site est déployé sur un réseau mondial comme Cloudflare Pages.
4. Les images et médias ne sont plus téléversés directement dans la médiathèque, mais stockés à part sur un bucket d’objet comme Cloudflare R2 avec son propre domaine dédié.
5. Pour la moindre fonction dynamique (comme un simple formulaire de contact), il faut faire appel à une mini-brique d’API ou une fonction serverless à côté.

On nous présente cette mécanique comme le sommet de la modernité et du bon sens. En réalité, c’est un exemple typique de sur-ingénierie portée par un effet de mode.

Déplacer la complexité n’est pas simplifier

Dans l’ancien monde, WordPress concentrait tout au même endroit : un serveur, une base de données PHP/MySQL, une interface d’administration où n’importe quel collaborateur pouvait rédiger un article, ajouter une image et cliquer sur « Publier ».

Dans le nouveau monde soi-disant simplifié, pour corriger une coquille ou ajouter une actualité, il faut manipuler des fichiers de données, gérer des commits Git, déclencher des pipelines d’intégration continue, surveiller des buckets de stockage et maintenir des fonctions serverless pour la partie dynamique.

Ce basculement a aussi un coût organisationnel dont personne ne parle : toute la chaîne de publication repose désormais sur les épaules de ceux qui savent utiliser Git. La stagiaire en communication qui publiait ses actualités en autonomie doit maintenant ouvrir un ticket. Le responsable marketing qui corrigeait une faute en trente secondes attend le prochain déploiement. On n’a pas seulement déplacé la complexité technique : on a transformé chaque collaborateur en demandeur, et chaque développeur en goulot d’étranglement.

Pour un développeur qui passe sa journée dans un terminal et sur GitHub, ce flux de travail semble naturel. Mais prétendre qu’il s’agit d’une simplification pour la gestion globale d’une entreprise est une illusion. On n’a pas supprimé la complexité, on l’a simplement fragmentée en une demi-douzaine de services cloud tiers et d’outils de build.

On me rétorquera qu’il existe une variante plus confortable : brancher Astro sur un CMS headless visuel de type Sanity ou Storyblok, afin de rendre l’admin à ceux qui n’ont pas de terminal. C’est vrai, et c’est révélateur : pour retrouver le back-office que WordPress offrait nativement, il faut désormais souscrire un abonnement SaaS supplémentaire, apprendre son modèle de contenu propriétaire et maintenir la couche d’intégration qui le relie au build. On n’a pas éliminé le CMS, on l’a externalisé, facturé au mois et rendu dépendant d’un troisième fournisseur.

La vitesse à tout prix, mais pour qui ?

L’argument de la performance et du SEO revient systématiquement. Un site statique est incontestablement plus rapide à servir qu’un WordPress mal configuré, bourré de dizaines de plugins superflus, plombé par une table wp_options en roue libre et alourdi d’un constructeur de page comme Elementor.

Soyons honnêtes : ces WordPress-là existent, ils sont même majoritaires, et j’ai déjà écrit tout le mal que je pensais de la dérive du projet. Mais attribuer la lenteur d’un site à WordPress lui-même est un raccourci facile. Un WordPress propre, hébergé sur un serveur décent avec une couche de cache efficace (WP Rocket ou Nginx FastCGI cache), sert exactement la même chose qu’un site statique : des pages HTML pré-générées, expédiées en quelques dizaines de millisecondes. Sans usine à gaz Jamstack.

Les billets de migration comparent d’ailleurs rarement à armes égales. D’un côté, un WordPress sur hébergement mutualisé, écrasé par un page builder, dont les pages hors cache mettent plusieurs secondes à sortir. De l’autre, un site statique servi par le réseau anycast mondial de Cloudflare. On compare la pire installation possible au meilleur réseau de distribution de la planète, et on en conclut que le coupable, c’est le CMS. Le même WordPress, débarrassé de son constructeur de page et posé derrière le même CDN, aurait affiché des scores Lighthouse tout aussi flatteurs.

Quant à la sécurité, parlons-en franchement, car l’actualité s’invite dans le débat : la faille wp2shell, révélée le 17 juillet 2026, permettait une exécution de code à distance sans authentification dans le cœur même de WordPress, sans le moindre plugin. C’est le scénario cauchemar, et il plaide en apparence pour le camp du statique. Sauf que la suite de l’histoire plaide dans l’autre sens : correctif publié en urgence, mises à jour automatiques forcées déployées sur l’ensemble du parc mondial en quelques heures. C’est précisément ce qu’un écosystème centralisé et mature de vingt ans permet. En face, l’écosystème npm dont dépend le moindre projet Astro subit ses attaques de supply chain de façon chronique, paquets compromis et mainteneurs piratés, sans aucun mécanisme de remédiation forcée équivalent. La leçon honnête de wp2shell n’est pas « fuyez WordPress », c’est « laissez les mises à jour automatiques activées ». Et pour le reste, un WordPress correctement durci, à commencer par les headers HTTP que personne ne configure, ne présente pas un profil de risque qui justifie de réinventer l’intégralité de la chaîne de publication d’un site vitrine.

La maintenance n’a pas disparu, elle a changé de langue

Autre promesse récurrente : « moins de maintenance ». C’est sans doute l’argument le plus fragile de tous.

Un projet Astro, c’est un package.json qui tire plusieurs centaines de dépendances npm transitives, des versions majeures qui se succèdent à un rythme soutenu, des intégrations tierces qui cassent au gré des breaking changes, et un lockfile qui devient radioactif au bout de dix-huit mois d’inattention. Quiconque a rouvert un projet front-end laissé en jachère deux ans sait ce que coûte un simple npm install de retrouvailles.

En face, la rétrocompatibilité de WordPress sur vingt ans est précisément ce que le milieu lui reproche par snobisme. Un site monté en 2010 tourne encore aujourd’hui après ses mises à jour. On peut détester le code hérité qui rend cela possible ; on ne peut pas prétendre en même temps que la stack qui exige une rotation permanente de ses dépendances est celle qui demande « moins de maintenance ». La maintenance n’a pas disparu : elle est passée de l’écran de mise à jour de wp-admin aux entrailles de l’écosystème npm.

Et la souveraineté dans tout ça ?

Il y a enfin un angle que ces billets de migration n’abordent jamais : chez qui atterrit-on ?

La stack « simplifiée » type, c’est Cloudflare Pages pour l’hébergement, Cloudflare R2 pour les médias, le CDN Cloudflare devant, et des Workers pour le dynamique. Autrement dit, l’intégralité du site, contenus, médias, distribution et logique applicative, entre les mains d’un unique fournisseur américain soumis au Cloud Act. On quitte un logiciel libre qu’on peut héberger chez n’importe quel prestataire français ou européen, migrer en une soirée avec un export SQL et un rsync, pour une architecture sur mesure dont chaque brique est propriétaire d’un écosystème. Cloudflare l’a d’ailleurs bien compris, au point de construire désormais son propre CMS : l’attraction gravitationnelle est la stratégie, pas un effet de bord.

La réversibilité a une valeur. Un WordPress s’exporte, se déménage, se reprend par n’importe quelle agence. Un assemblage bespoke de fichiers Markdown, de pipelines CI et de fonctions Edge se reprend par la personne qui l’a construit, et par personne d’autre.

Un choix technique dicté par la mode

Astro est un excellent outil technique, agréable à utiliser pour les développeurs frontend et très performant pour ce qu’il sait faire. Précisons d’ailleurs le périmètre de ce billet, pour couper court à une objection prévisible : Astro n’est plus un simple générateur statique, il gère très bien le rendu à la volée sur le Edge. Mais ce n’est pas Astro que je critique, c’est le récit du statique intégral comme simplification universelle. Que l’outil sache aussi faire du dynamique ne change rien à ce récit, cela montre juste qu’on finit souvent par réintroduire, brique par brique, la dynamique qu’on prétendait avoir supprimée. Et rendons aux migrants ce qui leur appartient : quand une société d’infogérance dont les équipes vivent dans Git bascule son propre site vitrine en statique, le choix est cohérent avec son métier et son quotidien. Chacun est libre d’aligner son outillage sur sa culture interne.

Le problème ne vient donc pas de la technologie, ni même de ces cas particuliers. Il vient de la narration qui les accompagne, et de sa généralisation : ce récit du statique libérateur devient la doctrine servie à des entreprises dont aucun collaborateur ne fera jamais un commit, exactement comme Docker et Kubernetes ont été vendus à des projets de trois pages HTML. Changer d’architecture pour le plaisir d’utiliser les derniers outils à la mode est un choix assumé dans le milieu des passionnés. Le présenter comme une « simplification » universelle, c’est faire preuve d’un bel aveuglement.

Parfois, un simple CMS éprouvé, auto-hébergé, réversible et administrable par tous fait très bien le travail. Sans déployer une infrastructure distribuée chez un géant américain pour afficher trois pages d’actualités et un formulaire de contact. La vraie modernité, en 2026, ce n’est plus d’empiler les services cloud : c’est de savoir encore s’en passer.