Pourquoi on a abandonné WordPress pour Astro sur nos sites

WordPress, on l’a beaucoup utilisé. Pour des sites institutionnels, des landing pages, des blogs corporate, des plateformes éditoriales. Et pendant des années, c’était le bon choix : un client peut publier sans toucher au code, l’écosystème de plugins est immense, et les hébergeurs proposent du mutualisé pas cher.

Mais en 2026, sur la plupart de nos nouveaux projets, on choisit Astro. Et on migre progressivement les anciens. Voici pourquoi.

Le problème WordPress en 2026

Le souci principal, ce n’est pas WordPress en lui-même, c’est l’écosystème qui le entoure. Un site WordPress moyen embarque :

• 25 à 40 plugins, dont la moitié maintenus par des freelances qui abandonnent leur projet tous les 18 mois
• 8 à 12 Mo de JavaScript chargés sur chaque page (jQuery, Slick, Owl, plus du custom)
• Des thèmes premium qui injectent leur propre framework par-dessus le framework du builder visuel
• Une attaque par minute sur wp-login.php dès que le site est en ligne
• Des backups MySQL de 200 Mo qui prennent 10 minutes à dumper

Sur un site vitrine de 12 pages avec un blog, c’est de l’overkill complet. On charge un CMS dynamique qui rejoue la base à chaque visite, alors que le contenu change peut-être une fois par semaine. Le rapport ressources/utilité est mauvais.

Astro, c’est quoi vraiment

Astro est un framework de site statique qui se distingue par deux choix techniques importants :

1. Zero-JS par défaut. Une page Astro produit du HTML pur si vous n’ajoutez pas de composant interactif. Pas de runtime React qui s’hydrate, pas de bundle de 200 Ko pour afficher un titre.
2. Islands architecture. Si vous voulez de l’interactif (un slider, un formulaire, un dashboard), vous l’isolez dans un “island” qui ne charge que là où il est utilisé. React, Svelte, Vue, Solid — vous mixez selon les besoins, et chaque island est indépendant.

Le résultat sur nos benchmarks : un site Astro moyen pèse 30 à 80 Ko de JS critique, contre 800 Ko à 2 Mo pour l’équivalent WordPress. Le Lighthouse Performance passe de 35-50 à 95-100, sans avoir à optimiser quoi que ce soit.

Le pivot pour les agences

Le vrai sujet, c’est l’expérience développeur et le coût de maintenance.

Versionnement Git natif

Tout est dans Git. Le contenu (markdown), les composants, les styles, les configs. Pas de base de données qui drift entre la prod et le staging. Pas de migration de DB foireuse parce qu’un éditeur a importé un PDF de 50 Mo dans la médiathèque. Une PR = une review = un déploiement reproductible.

CI/CD qui marche du premier coup

- run: npm install
- run: npm run build
- run: rsync -az dist/ prod:/var/www/site/

C’est tout. Pas de pipeline qui synchronise la DB, pas de step qui purge le cache d’un objet WordPress dans Redis, pas de rolling deployment compliqué. Le build produit un dossier dist/, vous l’uploadez, c’est fini.

Sécurité gratuite

Un site statique n’a pas de surface d’attaque applicative. Pas de wp-admin à protéger, pas de PHP qui tourne, pas de SQL injection possible. La seule chose à sécuriser, c’est le serveur web (nginx) et la chaîne de build. Sur les sites institutionnels qu’on gère, le nombre d’incidents de sécurité a chuté à zéro depuis la migration Astro.

Les cas où WordPress reste pertinent

On n’est pas dogmatiques. WordPress reste le bon choix dans deux scénarios :

1. Le client publie quotidiennement et veut une UI graphique. Sur un journal en ligne avec dix éditeurs, Astro + un workflow Git/markdown demande de la formation. WordPress avec Gutenberg reste plus naturel pour les non-tech.
2. WooCommerce. Si vous avez besoin d’un e-commerce avec catalogue, panier, checkout, gestion fine des variantes… WooCommerce ou Shopify, pas autre chose. Astro fait du e-commerce headless avec une API externe (Stripe, Snipcart), mais c’est un autre projet.

Pour tout le reste — sites vitrine, sites institutionnels, blogs corporate, documentation produit, portfolios, landing pages campagne — Astro est meilleur en 2026.

La migration en pratique

On a un workflow rodé sur les migrations WP → Astro :

1. Export du contenu via WP REST API vers du markdown. Un script Python qui parcourt /wp-json/wp/v2/posts et génère les fichiers .md avec frontmatter. Comptez 20 minutes pour 200 articles.
2. Audit du thème actuel pour identifier les composants à porter (carrousel, accordéon, tabs, etc.). On les recrée en Astro avec la stack du client si elle est imposée, sinon en composants Astro purs avec un peu de JS vanilla.
3. Reverse proxy temporaire. Pendant la phase de migration, on monte le nouveau site en staging.client.fr et on bascule progressivement les routes via nginx. Pas de big-bang, pas de jour J risqué.
4. 301 systématique des anciennes URLs vers les nouvelles. SEO sauvé à 100% si c’est fait dans la semaine de bascule.
5. Décommissionnement WP. Le serveur PHP/MySQL est éteint, l’hébergement passe sur du statique servi par nginx ou un CDN. Les économies d’hébergement sont immédiates.

Sur un site moyen (50-200 pages), la migration prend 2 à 5 semaines selon la complexité du design et la quantité de fonctionnalités custom.

Les pièges à connaître

Astro 6 a changé l’API des Content Collections par rapport à Astro 4. Si vous trouvez des tutos en ligne, vérifiez la version. La nouvelle API glob loader + defineCollection est plus claire mais incompatible avec l’ancienne. On utilise la v6 sur tous nos nouveaux projets.

View Transitions sont géniales mais demandent un peu de discipline côté CSS pour éviter les flashs entre routes. Documentez vos view-transition-name dans le design system.

Les images : Astro a un excellent composant <Image> qui fait le lazy-loading et la conversion en WebP/AVIF. Utilisez-le partout, ne chargez jamais une JPG brute en <img>.

Le bilan

Quinze ans de WordPress nous ont appris à respecter ce CMS, mais aussi à en connaître les limites. Astro résout les vrais problèmes de maintenance, de performance et de sécurité qu’on rencontrait. Pour nos clients qui n’ont pas besoin d’une UI éditoriale lourde, c’est devenu notre choix par défaut.

Le site que vous lisez actuellement, par exemple, est un site Astro 6. Build en 8 secondes, déploiement en 30 secondes, et un Lighthouse 100/100 sans avoir touché à un seul plugin de cache.