Migrer un site WordPress vers Astro : ce que ça change, ce que ça coûte

Une migration vers Astro se décide sur deux questions, dans cet ordre : est-ce que votre problème est bien celui qu'Astro règle, et est-ce que vos URLs positionnées survivront à la bascule. Le reste est de l'exécution. Cette page donne les critères que nous appliquons, les chiffres que nous avons mesurés sur notre propre site, et ce que la migration ne réglera pas.

Quand la migration se justifie, et quand elle ne se justifie pas

Astro règle un problème précis : un site de contenu qui expédie le runtime d'un framework applicatif sur chaque page, y compris celles qui ne contiennent aucune interaction. Si ce n'est pas votre situation, la migration coûtera cher pour rien.

Les cas où nous recommandons d'y aller :

• Un site de contenu de 20 à 60 pages, quelques formulaires, aucune application derrière.
• Un WordPress dont la dette est dans le thème et les extensions, pas dans le contenu, et dont l'équipe édite peu.
• Un site déjà reconstruit une fois sans résultat, où le poids servi a été mesuré et non supposé.
• Un projet neuf, où la question du coût de sortie ne se pose pas encore.

Les cas où nous déconseillons :

• Votre outil d'acquisition est une vraie application : moteur de scoring, espace client, back-office, file de traitement. Le site n'est alors que la façade.
• Votre équipe publie plusieurs fois par semaine dans un back-office qu'elle maîtrise. Le confort éditorial vaut plus que 166 Ko.
• Vous cherchez un gain de vitesse sans avoir mesuré d'où vient votre retard d'affichage.
• Vos positions sont fragiles et personne ne veut porter le plan de redirections.

Ce que vous gagnez réellement, en octets et en Core Web Vitals

Le gain d'Astro est certain en octets et incertain en Core Web Vitals. C'est la nuance que la plupart des argumentaires escamotent, et c'est celle qui décide de la rentabilité du chantier.

Sur notre propre site, le retard d'affichage représentait 86 à 96 % du LCP mobile. Ce retard vient du CSS et des polices, identiques dans les deux frameworks. Autrement dit : la migration aurait allégé le transfert sans accélérer l'affichage. Si personne ne vous a montré cette décomposition sur votre site, la promesse de vitesse n'est pas fondée.

Le piège qui annule le gain : le composant de shell

Votre site a un en-tête interactif : menu déroulant, tiroir mobile, gestion du focus au clavier. Ce composant est sur toutes les pages. Gardé en React avec une directive d'hydratation, il fait repartir React et son moteur de rendu sur chaque page.

Le gain tombe alors à zéro, et vous avez réécrit 40 pages pour rien. La condition du gain n'est pas de choisir Astro, c'est d'écrire le shell sans framework d'interface.

Ce travail est faisable en restant sur votre framework actuel, et il délivre le même gain sans toucher à vos URLs. Nous le disons avant de chiffrer une migration, parce que c'est souvent la recommandation la moins chère.

Ce qui porte tel quel, ce qui se réécrit

Vérifié contre la documentation officielle d'Astro 7 le 30 juillet 2026. Cette table est notre base de chiffrage.

Les quatre points qui pèsent le plus dans un chiffrage sont documentés par l'éditeur. Les lire avant de signer évite les mauvaises surprises : les collections de contenu, le routage internationalisé, le middleware et les actions serveur. Le modèle d'ensemble est décrit dans la page architecture en îlots.

Le plan de redirections, écrit avant la bascule

C'est le seul poste où une erreur ne se rattrape pas en une semaine. Un site de contenu qui se positionne depuis des années porte des URLs que Google connait mieux que vous. L'ordre de travail est toujours le même.

• Extraction de la liste complète des URLs servies, depuis le sitemap et depuis les logs, pas depuis le menu.
• Croisement avec les positions et les pages qui reçoivent du trafic, pour savoir ce qui doit absolument survivre.
• Cartographie ancienne URL vers nouvelle URL, une ligne par page, y compris les pages que personne ne revendique.
• Redirections 301 posées et testées sur l'environnement de préproduction, avant la mise en ligne.
• Recette de non-régression après bascule : titres, descriptions, données structurées, balises de langue, sitemap.

Une migration technique réussie qui perd la moitié du trafic organique reste un échec. Notre méthode de cadrage traite ce point en premier, avant même les maquettes.

Ce que vous perdez en quittant WordPress

Autant le dire avant le devis. Une bascule vers Astro vous fait perdre des choses réelles, et elles comptent plus que le poids servi pour beaucoup d'équipes.

• L'écosystème d'extensions : ce qui se réglait en installant un module se code désormais.
• Le confort d'édition d'un back-office que votre équipe connait, sauf à brancher un système de gestion de contenu découplé, qui est un projet en soi.
• La facilité de recrutement : trouver un intégrateur WordPress est plus simple que trouver un développeur qui connait Astro.
• La prévisualisation immédiate d'un brouillon, qui demande une configuration dédiée sur un site prérendu.

Si ces quatre points vous arrêtent, la bonne décision est probablement une remise à plat de votre WordPress plutôt qu'une migration. Nous le disons quand c'est le cas, et cela arrive souvent.

Notre propre arbitrage : nous n'avons pas migré

En juillet 2026, nous avons audité notre propre site pour décider s'il devait passer sur Astro. Nous avons mesuré le poids réellement servi en navigateur, décomposé les chunks, isolé le retard d'affichage, et regardé ce que le rendu produisait vraiment au build.

Verdict : non. Nos pages étaient déjà prérendues à 100 %, donc Astro aurait changé l'outil de build sans changer le modèle de rendu. Et notre outil d'audit est une vraie application, avec moteur de scoring, stockage et back-office à jeton, ce qui remplit deux des conditions qui font pencher vers un framework applicatif.

Nous racontons ce cas parce qu'il dit ce qu'il faut savoir sur notre façon de travailler : l'arbitrage repose sur des mesures, et il peut conclure contre la technologie que nous vendons par ailleurs.

Délai, budget, et ce qui fait vraiment varier la facture

Notre repère pour un site de contenu est de 6 à 12 semaines pour 10 à 25 pages, du cadrage à la mise en ligne. Une migration ajoute l'inventaire des URLs, le plan de redirections et la recette de non-régression. Au-delà de 25 pages, le délai suit le volume de contenu à reprendre et la disponibilité de vos équipes, pas le choix technique.

Ce qui fait varier la facture, par ordre d'impact : le nombre de composants interactifs à réécrire, la présence d'un site bilingue avec repli partiel, la complexité de votre politique de sécurité, et l'état de vos contenus. Le nombre de pages arrive loin derrière.