Migrer Gatsby vers Next.js

Pourquoi les sites Gatsby migrent vers Next.js

Gatsby était un bon choix quand la génération de site statique était la seule véritable option. Mais le web a évolué, et Gatsby n'a pas suivi. Votre site est verrouillé dans un rendu uniquement au moment de la compilation, enchevêtré dans une couche de données GraphQL dont vous n'aviez probablement pas besoin, et souffre de temps de compilation qui s'aggravent à mesure que votre contenu grandit.

Next.js vous donne tout ce que Gatsby fait — génération statique, composants React, routage basé sur les fichiers — plus le rendu côté serveur, la régénération statique incrémentale, les routes API et les middlewares. Le même écosystème React, sans les contraintes.

Comme les deux frameworks sont basés sur React, vos composants actuels changent à peine. La migration concerne principalement les modèles de récupération de données et le routage. Vous ne réécrivez pas votre interface utilisateur.

Les vrais problèmes avec Gatsby

GraphQL pour tout, c'est du surengineering

Gatsby route chaque interaction de données via GraphQL. Vous voulez récupérer une liste d'articles de blog depuis votre CMS ? Requête GraphQL. Vous avez besoin de métadonnées du site ? Requête GraphQL. Vous voulez lire un fichier JSON ? Requête GraphQL. C'était malin en 2018. Maintenant c'est juste du frottement.

Vous maintenez des fichiers gatsby-node.js avec la logique createPages, écrivez des requêtes de page, des requêtes statiques et des définitions de fragments pour ce qui devrait être un simple appel fetch(). Chaque nouveau développeur dans votre équipe doit apprendre les conventions GraphQL de Gatsby avant de pouvoir contribuer quelque chose de significatif.

Des temps de compilation qui s'échelonnent mal

Gatsby reconstruit tout au moment de la compilation. Un site de 500 pages pourrait prendre 5-10 minutes. Un site de 5 000 pages ? Vous regardez 20-45 minutes. Chaque mise à jour de contenu déclenche une recompilation complète. Votre équipe marketing attend une demi-heure pour voir un article de blog en direct.

Next.js avec la régénération statique incrémentale (ISR) résout cela entièrement. Les pages se régénèrent en arrière-plan selon un calendrier que vous définissez. Le nouveau contenu apparaît en quelques secondes, pas en minutes.

L'enfer de la dépendance des plugins

L'écosystème de plugins de Gatsby était autrefois son plus grand atout. Maintenant c'est une responsabilité. Les plugins cassent à chaque mise à jour majeure. Certains sont abandonnés. Vous êtes trois couches profondément dans les dépendances gatsby-plugin-* pour obtenir ce que Next.js livre nativement — optimisation des images, gestion des CSS, chargement des polices, gestion des métadonnées.

Quand gatsby-plugin-image casse après une mise à jour et que vous déboguez les source maps à 23h, c'est généralement le moment où les équipes décident qu'il est temps de migrer.

Pas de rendu côté serveur

Gatsby est statique uniquement. Vous avez besoin de pages authentifiées ? Rendu côté client avec des spinners de chargement. Avez-vous besoin de données en temps réel ? Récupération côté client après hydratation. Avez-vous besoin de personnalisation ? Des contournements lourds en JavaScript qui tuent vos Core Web Vitals.

Next.js vous permet de choisir par page : génération statique, rendu côté serveur ou un hybride avec ISR. Vous choisissez le bon outil pour chaque route.

Ce que vous obtenez avec Next.js

Stratégies de rendu flexibles

Chaque page dans Next.js peut utiliser une stratégie de rendu différente. Les pages marketing utilisent getStaticProps pour la génération statique. Votre tableau de bord utilise le rendu côté serveur. Votre blog utilise l'ISR pour rester frais sans recompilations. Un framework, chaque modèle.

Récupération de données sans GraphQL

Remplacez chaque requête GraphQL par un fetch() standard, SWR ou n'importe quelle bibliothèque de données que vous préférez. getStaticProps remplace les requêtes de page. getStaticPaths remplace createPages dans gatsby-node.js. Le modèle mental est plus simple et le code est plus portable.

// Avant : gatsby-node.js
exports.createPages = async ({ graphql, actions }) => {
  const result = await graphql(`
    query { allMarkdownRemark { edges { node { frontmatter { slug } } } } }
  `);
  result.data.allMarkdownRemark.edges.forEach(({ node }) => {
    actions.createPage({
      path: node.frontmatter.slug,
      component: path.resolve('./src/templates/post.js'),
    });
  });
};

// Après : pages/posts/[slug].tsx
export const getStaticPaths: GetStaticPaths = async () => {
  const posts = await getAllPosts();
  return {
    paths: posts.map((post) => ({ params: { slug: post.slug } })),
    fallback: 'blocking',
  };
};

export const getStaticProps: GetStaticProps = async ({ params }) => {
  const post = await getPostBySlug(params.slug);
  return { props: { post }, revalidate: 60 };
};

La version Next.js est plus explicite, plus facile à déboguer, et ajoute l'ISR avec une seule propriété revalidate.

Optimisation d'images intégrée

Le composant <Image> de Next.js gère le chargement différé, le dimensionnement réactif et la conversion de format (WebP/AVIF) sans plugins. Fini de lutter avec les configurations de gatsby-plugin-image et gatsby-transformer-sharp.

Routes API et middlewares

Vous avez besoin d'un point de terminaison de formulaire de contact ? Un gestionnaire de webhook ? Une logique d'authentification ? Les routes API Next.js vivent dans le même codebase. Le middleware gère les redirections, les tests A/B et la géolocalisation à la limite. Gatsby n'a pas d'équivalent.

Notre processus de migration

Phase 1 : Audit et architecture (semaine 1)

Nous inventorions chaque page Gatsby, plugin, requête GraphQL et route dynamique. Chacun est mappé à son équivalent Next.js. Nous identifions les plugins qui nécessitent un remplacement personnalisé et documentons votre structure d'URL actuelle pour la préservation du SEO.

Phase 2 : Scaffolding du projet (semaine 1-2)

Nous initialisons le projet Next.js avec TypeScript, configurons votre connexion CMS headless et mettons en place votre solution de style — en migrant votre CSS existant qu'il s'agisse de styled-components, Tailwind ou CSS Modules. Ensuite, nous établissons l'architecture des composants.

Les deux frameworks utilisent React, donc vos composants existants se transfèrent avec des changements minimes. Nous mettrons à jour les imports, remplaçons gatsby-link par next/link, échangeons gatsby-image pour next/image, et déplacerons les CSS globales de gatsby-browser.js à _app.tsx.

Phase 3 : Migration de la récupération de données (semaine 2-3)

C'est le travail principal. Chaque requête GraphQL devient un appel API direct ou une méthode du SDK CMS à l'intérieur de getStaticProps ou getServerSideProps. Chaque appel createPages dans gatsby-node.js devient une fonction getStaticPaths. Nous remplaçons gatsby-plugin-react-helmet par le composant <Head> natif de Next.js ou l'API de métadonnées du routeur d'application.

Phase 4 : Fonctionnalités dynamiques (semaine 3-4)

C'est où Next.js tire l'avantage. Nous ajoutons l'ISR aux pages de contenu afin que les mises à jour du CMS apparaissent en quelques secondes. Nous implémentons les routes API pour les formulaires et les intégrations. Nous ajoutons un middleware pour les redirections, l'authentification ou la personnalisation — des fonctionnalités qui étaient soit impossibles soit terriblement hacky dans Gatsby.

Phase 5 : Test et lancement (semaine 4-5)

Test de régression complet sur tous les appareils. Audits Lighthouse sur chaque modèle. Test de diff visuel par rapport à votre site actuel. Nous vérifions que chaque URL se résout correctement, que chaque redirection fonctionne et que chaque balise meta est préservée.

Stratégie de préservation du SEO

Migrer les frameworks est un risque pour le SEO si vous êtes négligents à ce sujet. Nous éliminons ce risque.

• Parité d'URL : Chaque URL existante correspond 1:1 au nouveau site. Pas de changements de structure à moins que vous ne les demandiez.
• Redirections 301 : Nous configurons les redirections Next.js dans next.config.js pour tout changement d'URL, avec un plan de redirection complet.
• Audit des balises meta : Nous vérifions que les balises titre, méta-descriptions, balises Open Graph et URL canoniques se transfèrent correctement en utilisant le composant <Head> de Next.js.
• Données structurées : Tout balisage JSON-LD de votre site Gatsby est porté aux nouveaux modèles.
• Sitemap et robots.txt : Générés automatiquement via next-sitemap ou des routes API personnalisées.
• Gains de performance : Les scores TTFB plus rapides et les meilleurs Core Web Vitals s'améliorent généralement après la migration, et non l'inverse.

Déploiement et hébergement

Nous déployons sur Vercel pour la meilleure expérience Next.js — déploiements d'aperçu automatiques, fonctions edge, analyse intégrée et ISR sans configuration. Sinon, nous pouvons déployer sur Cloudflare Pages, AWS Amplify ou n'importe quel environnement d'hébergement Node.js qui correspond à votre infrastructure.

Chronologie et tarification

Une migration Gatsby vers Next.js typique prend 3-5 semaines selon la complexité du site :

• Petits sites (moins de 50 pages, blog ou site marketing) : 2-3 semaines, à partir de 6 000 $
• Sites moyens (50-500 pages, piloté par CMS, modèles multiples) : 3-5 semaines, à partir de 12 000 $
• Grands sites (500+ pages, sources de données complexes, e-commerce) : 5-8 semaines, à partir de 20 000 $

Chaque migration inclut une période de support gratuite post-lancement pour attraper les cas limites et affiner les performances.

L'avantage React

Ce n'est pas une réécriture — c'est une mise à niveau. Votre équipe connaît déjà React. Vos composants fonctionnent déjà. Nous changeons la couche du framework dessous tout en conservant tout ce qui compte : votre conception, votre contenu, vos URLs et vos classements de recherche.

Le résultat est un site qui est plus rapide, plus flexible et capable de choses que Gatsby simplement ne peut pas livrer.