La décision, prise en comité de direction un an plus tôt, avait de quoi inquiéter une partie de l’équipe technique : migrer progressivement l’ensemble du portefeuille de sites vitrines et de blogs de l’agence, alors majoritairement construits en Next.js headless sur WordPress, vers Astro, jugé plus adapté à des sites à contenu majoritairement statique et moins gourmand en complexité de build. Le pari portait sur quarante sites clients, une équipe de huit développeurs, et un horizon de douze mois.
Ce texte revient sur ce bilan, un an après le lancement du chantier, avec les chiffres réellement observés plutôt qu’un discours commercial sur la réussite du projet.
Le coût de la formation initiale
Les deux premiers mois ont été consacrés exclusivement à la montée en compétence de l’équipe, dont la majorité n’avait jamais touché à Astro auparavant. Un projet pilote à faible enjeu, le site vitrine interne de l’agence elle-même, a servi de premier terrain d’apprentissage, suivi de la migration de trois sites clients volontaires, choisis pour leur structure de contenu simple.
Le temps de livraison sur ces trois premiers projets migrés a dépassé de 60 % le temps habituellement constaté sur un projet Next.js équivalent, un dépassement anticipé et budgété en amont, présenté clairement aux clients concernés comme faisant partie d’un investissement de transition plutôt que dissimulé.
L’accélération observée ensuite
| Période | Temps de livraison moyen (site vitrine standard) | Tickets de maintenance performance / mois |
|---|---|---|
| Avant migration (Next.js headless) | 3,5 semaines | 6,2 |
| Trois premiers projets Astro | 5,6 semaines | 4,8 |
| Après le dixième projet Astro | 2,4 semaines | 1,9 |
Le temps de livraison moyen a fini par descendre nettement en dessous du temps constaté avant migration, une fois la courbe d’apprentissage franchie. La raison principale : Astro, avec son approche par îlots (le contenu reste statique par défaut, seuls des composants explicitement marqués deviennent interactifs côté client), correspond structurellement mieux à la nature des sites vitrines majoritairement statiques que gère l’agence, comparé à Next.js qui impose davantage de décisions de configuration pour obtenir un résultat équivalent.
Ce qui n’a pas fonctionné aussi bien que prévu
Sur les six sites clients disposant de fonctionnalités fortement interactives (un configurateur de produit, un espace membre avec tableau de bord), la migration vers Astro s’est révélée plus complexe que celle des sites purement vitrine. L’approche par îlots, pensée pour des interactions ponctuelles, demande une gestion plus fine du partage d’état entre plusieurs îlots interactifs sur une même page, un problème que Next.js ou Nuxt résolvent plus naturellement grâce à leur modèle applicatif complet.
<!-- Exemple de composant Astro avec île interactive -->
<ConfigurateurProduit client:load produit={produit} />
<RecommandationsAssociees client:visible produits={recommandes} />Deux de ces six projets ont finalement été maintenus sur leur stack Next.js d’origine, une décision assumée plutôt que forcée, après une évaluation montrant que le gain de la migration ne compensait pas l’effort de réécriture pour ces cas précis.
La satisfaction client mesurée
Une enquête de satisfaction envoyée aux trente-huit clients ayant effectivement migré a recueilli un taux de satisfaction global en légère hausse par rapport à l’enquête précédente, portée principalement par des retours positifs sur la vitesse de chargement perçue des sites, un critère explicitement cité par vingt-deux des vingt-neuf répondants.
Les coûts non anticipés
- La formation continue de trois nouveaux développeurs recrutés en cours d’année a représenté un coût supplémentaire non budgété initialement, l’agence n’ayant pas anticipé son propre taux de recrutement lors du calcul initial du retour sur investissement.
- Certaines intégrations tierces (un widget de chat client, un module d’A/B testing) ont nécessité des adaptations spécifiques pour fonctionner correctement avec le modèle d’hydratation partielle d’Astro, un temps de développement non prévu dans l’estimation initiale.
- La documentation interne de l’agence, entièrement construite autour de Next.js, a dû être réécrite en parallèle du chantier de migration, un effort administratif sous-estimé au départ.
Une migration technologique à l’échelle d’une agence entière ne se mesure jamais sur le premier projet, ni même sur les trois premiers ; le vrai bilan n’apparaît qu’après avoir dépassé la courbe d’apprentissage collective, ce qui prend plus de temps qu’un plan initial ne l’anticipe généralement.
Notre verdict, un an après
Le pari est jugé globalement gagnant par la direction technique de l’agence, avec un temps de livraison moyen désormais inférieur à celui d’avant migration et une charge de maintenance liée à la performance nettement réduite. Le bilan reste toutefois nuancé sur les projets aux besoins fortement interactifs, où Astro ne s’est pas imposé comme un choix évident, et où l’agence conserve désormais volontairement deux stacks actives selon la nature du projet, plutôt qu’une migration totale et sans exception.
