001 Migrer de Gatsby à Astro avec Gemini

L’IA comme agent de simplification d’un code legacy.

Mon site web actuel paulmoysan.io était jusque là implémenté en Gatsby avec un template particulier à base de Scss. En 2026, Gatsby est un peu dépassé, Sass est moins utilisé et le CSS est plus performant qu’il ne l’a jamais été. Mon code est trop verbeux pour être vraiment maintenable sur le long terme, la librairie Skel.scss est dépréciée.

Avec Google Antigravity et Gemini Flash, je vais tenter de le faire migrer vers Astro, un framework Web multi-pages qui a l’air assez simple à prendre en main.

  1. D’abord, créer une branche feature/migration pour la migration ;
  2. Mettre Gatsby dans un dossier ./legacy pour garder la source de vérité ;
  3. Demander à Gemini d’identifier les lourdeurs et les points d’optimisation potentiels.

L’agent se met au travail et réalise un premier jet qui est assez satisfaisant, mais le contenu des modales s’affiche sous le header, ce qui est une régression. A cette étape du projet et après quelques tentatives de correction je me rends compte que Sass va poser des problèmes et rend l’intégration du legacy plus complexe que prévu : il y a trop de fichiers, trop de variables et trop d’erreurs. La complexité de Skel crée un coût de compréhension qui est trop élevé pour un site web censé rester simple.

Je demande à Gemini de générer un fichier SPECS.md pour définir les premières specs fonctionnelles qui serviront de base à nos itérations. Je lui demande ensuite de trouver des alternatives à SCSS en tenant compte des specs définies plus haut dans le fichier. Les instructions sont volontairement lâches, très simples et assez haut niveau de manière à laisser l’agent faire certains choix techniques et implémenter une plomberie la plus standard possible.

Il m’indique d’abord que les choses seront compliquées et qu’il vaut mieux rester sur SCSS par prudence pour éviter les régressions. Je lui demande de continuer en lui expliquant que je préfère avoir un code simple et maintenable qu’un code complexe et difficile à maintenir.

Le rendu est assez bon mais quelques régressions mineures sont constatables :

  • Les images de chaque article apparaissent dans leur taille normale et prennent tout l’écran.
  • L’espace reste trop élevé entre les modales et le haut de la page ;
  • Le tableau dans la rubrique “Outils” a disparu ;
  • La police de l’ensemble peut être définie dans une taille légèrement supérieure ;
  • La navigation devrait retourner à ”/” une fois la modale fermée ;
  • Le rendu des articles est trop basique et mériterait un peu de mise en forme ;
  • Le sitemap.xml et le robots.txt ont disparu.

L’agent fera le plus gros du travail, j’interviendrai dans le code seulement pour corriger certains espacements mineurs.

En une à deux heures de supervision, le site est entièrement migré, j’ai rajouté ce blog et appris comment fonctionnait Astro au passage.

Le code passe de 23 dépendances à 10, le CSS s’allège d’une vingtaine de fichiers Scss éparpillés à la syntaxe tordue à seulement 6 fichiers aux standards CSS modernes. Exit la génération d’un bundle Javascript lourd, le payload initial a été drastiquement réduit.

J’utiliserai ensuite Lighthouse comme outil de diagnostic et de débug pour évaluer la qualité du rendu et identifier les points d’optimisation restants en générant un premier rapport sur la production “Gatsby” et trois autres sur la production “Astro”.

Les résultats Lighthouse parlent d’eux-mêmes : le Speed Index est passé de 15.4s à 1.6s (~10x plus rapide), et le Largest Contentful Paint (LCP) est passé de 5.1s à 1.6s grâce au préchargement et à l’optimisation des images.

Trois enseignements :

  • Atomicité : Procéder par itérations et incréments en maintenant une source de vérité permet de donner à l’agent un contexte de référence documenté et éprouvé en production ;
  • Finalité : L’IA peut vouloir maintenir un certain niveau de complexité, le refactoring demande précision et exigence – quand on a git, tout est permis 😉 ;
  • Feedback : Rien de tel que de nourrir l’agent avec des comptes rendus d’outils de diagnostic externes bruts et structurés (les rapports Lighthouse en json) pour évaluer la qualité du rendu.
Retour au blog