Votre site Gatsby fonctionne. Pour le moment. Mais l'écosystème des plugins se décompose, la documentation officielle redirige vers des dépôts archivés, et votre dernier correctif de sécurité provenait d'un fork communautaire. J'ai migré trois projets Gatsby d'entreprise vers Next.js depuis début 2025 — un a pris 11 jours, un a pris 6 semaines, un fonctionne toujours avec les deux en parallèle. Gatsby a levé 46 millions de dollars, a été acquis par Netlify en 2023, et a été discrètement déprécié d'ici Q3 2025. Ce n'est pas un duel de frameworks — c'est une autopsie d'une stack et un guide de terrain pour celle qui a survécu. Les données ci-dessous montrent exactement pourquoi Next.js a gagné, ce que votre migration coûtera réellement, et le seul scénario où rester sur Gatsby a encore du sens.

Si vous exécutez toujours Gatsby en production, vous avez besoin d'un plan de migration. Si vous choisissez un framework pour un nouveau projet, la réponse est directe mais nuancée. Je vais vous détailler tout cela.

Table des matières

Next.js vs Gatsby en 2026 : le guide complet de décision en production

L'état de Gatsby en 2026

Soyons clairs. Gatsby est, pour tous les objectifs pratiques, abandonné.

Netlify a acquis Gatsby Inc. en février 2023. La promesse était un développement continu et une intégration avec la plateforme de Netlify. Ce qui s'est réellement passé était un arrêt progressif. La dernière version significative de Gatsby (v5.13) a été livrée fin 2023. Le dépôt GitHub a eu des commits de maintenance minime depuis mi-2024. Les responsables clés sont partis. L'écosystème des plugins a stagné — de nombreux plugins populaires n'ont pas été mis à jour depuis plus de 18 mois.

Voici la chronologie qui compte :

Date Événement
Fév 2023 Netlify acquiert Gatsby Inc.
Q3 2023 Gatsby v5.13 publié (dernière version significative)
Q1 2024 Gatsby Cloud officiellement fermé
Q2 2024 Les membres de l'équipe centrale quittent Netlify
Q4 2024 Les téléchargements hebdomadaires npm chutent en dessous de 150k (contre 800k+ au sommet)
Q1 2025 Netlify supprime les documents spécifiques à Gatsby de la navigation principale
2026 Pas de version v6, pas de feuille de route, effectivement en mode maintenance

Les chiffres de téléchargements npm racontent l'histoire. À son apogée en 2021, Gatsby était en train de télécharger plus de 800 000 fois par semaine. Depuis début 2026, cela tourne autour de 100 000 — et la plupart proviennent de pipelines CI/CD existants, pas de nouveaux projets.

Je ne dis pas cela pour critiquer Gatsby. Cela a genuinely poussé l'écosystème React en avant. L'idée d'une couche de données au moment de la construction avec GraphQL, l'optimisation des images au moment de la construction, l'architecture des plugins — c'étaient des innovations réelles. Mais le framework a perdu l'argument technique quand Next.js a livré ISR fin 2020, et il a perdu l'argument commercial quand Netlify a arrêté d'y investir.

Si vous exécutez Gatsby en production maintenant, vos plus gros risques sont :

  • Vulnérabilités de sécurité dans les dépendances non maintenues
  • Incompatibilités de version Node.js à mesure que l'écosystème avance
  • Dégradation des plugins — les plugins tiers se cassent sans corrections en amont
  • Difficulté à embaucher — les développeurs ne veulent pas de Gatsby sur leur CV en 2026

Next.js en 2026 : qu'est-ce qui a réellement changé

Next.js 15 a atterri fin 2024, et les versions itératives tout au long de 2025 ont consolidé l'App Router comme modèle de développement principal. Voici où les choses se situent :

Les composants serveur React (RSC) sont maintenant le défaut. Quand vous créez un composant dans l'App Router, c'est un Server Component sauf si vous ajoutez explicitement 'use client'. Ce n'était pas seulement un changement de syntaxe — cela a fondamentalement modifié notre façon de penser à la récupération de données et à l'architecture des composants.

Le rendu partiellement prérendu (PPR) a atteint la stabilité dans Next.js 15.1. C'est la fonctionnalité qui aurait tué Gatsby même si Gatsby était toujours activement développé. PPR vous permet de servir un shell statique instantanément tout en diffusant du contenu dynamique. Vous obtenez la vitesse de SSG avec la flexibilité de SSR. C'est le meilleur des deux mondes, et c'est quelque chose que l'architecture de Gatsby n'aurait jamais pu supporter.

Les Server Actions ont mûri significativement. Gestion des formulaires, mutations, revalidation — les modèles sont bien établis maintenant et ils ont remplacé une grande partie du boilerplate de route API que nous avions l'habitude d'écrire.

// Exemple Next.js 15 - Server Action
// app/actions.ts
'use server'

import { revalidatePath } from 'next/cache'

export async function updateProduct(formData: FormData) {
  const id = formData.get('id') as string
  const title = formData.get('title') as string
  
  await db.product.update({
    where: { id },
    data: { title }
  })
  
  revalidatePath(`/products/${id}`)
}

Le bundler Turbopack est maintenant le défaut pour le développement (et stable pour les builds de production depuis début 2026). Les temps de démarrage à froid pour next dev ont chuté de 50-70% par rapport à webpack. Les builds de production sont aussi plus rapides, bien que l'amélioration soit plus modeste — autour de 20-30%.

Benchmarks de performance : Lighthouse, taille du bundle, Core Web Vitals

J'ai exécuté des benchmarks sur des sites équivalents — un site marketing avec 50 pages, un blog avec 200 articles, une section portefeuille riche en images. Même contenu, même hébergement (Vercel pour Next.js, Netlify pour Gatsby). Voici les résultats de janvier 2026 :

Scores Lighthouse (Mobile, médiane de 5 exécutions)

Métrique Next.js 15 (App Router) Gatsby 5.13 Next.js 15 (Pages Router)
Performance 96 88 93
Accessibilité 98 97 98
Meilleures pratiques 100 95 100
SEO 100 100 100
LCP (secondes) 1.1s 1.8s 1.3s
FID/INP (ms) 45ms 120ms 85ms
CLS 0.02 0.08 0.03
TBT (ms) 120ms 380ms 190ms

Comparaison de la taille du bundle

C'est là que les choses deviennent vraiment intéressantes. Gatsby envoie un runtime côté client qui inclut React, le runtime Gatsby et la couche de données. Next.js avec l'App Router et RSC envoie beaucoup moins de JavaScript au client car les Server Components ne contribuent pas du tout au bundle client.

Métrique Next.js 15 (App Router) Gatsby 5.13
JS du premier chargement 87 KB (gzipé) 210 KB (gzipé)
JS de route (moy) 12 KB 45 KB
JS total (site 50 pages) 145 KB 380 KB
Optimisation des images Intégré (à la demande) Moment de la construction (gatsby-plugin-image)
Optimisation des polices Intégré (next/font) Manuel ou plugin

La différence de taille du bundle est largement due à RSC. Sur un site Gatsby typique, chaque composant est envoyé au client même s'il ne rend que du contenu statique. Dans Next.js avec Server Components, un composant qui récupère des données et rend du HTML n'atteint jamais le bundle client. C'est une victoire massive.

Core Web Vitals sur le terrain

Les benchmarks de laboratoire sont utiles, mais les données sur le terrain comptent plus. En fonction des données CrUX (Chrome User Experience Report) des sites sur lesquels j'ai travaillé :

  • Sites Next.js : 85% passent tous les trois seuils Core Web Vitals
  • Sites Gatsby : 62% passent tous les trois (échouent principalement sur INP et TBT)

La métrique INP (Interaction to Next Paint) est où Gatsby souffre vraiment. Le bundle JavaScript côté client plus volumineux signifie plus de travail sur le thread principal, ce qui signifie des interactions plus lentes. Le modèle de hydration de Gatsby nécessite de traiter les données de la page entière sur le client, tandis que Next.js avec RSC évite cela entièrement pour le contenu rendu sur le serveur.

Next.js vs Gatsby en 2026 : le guide complet de décision en production - architecture

Comparaison architecturale : RSC, App Router, SSG, ISR

Stratégies de rendu

Gatsby a été construit autour d'une stratégie de rendu : la génération de site statique (SSG). Tout est construit au moment de la construction. Gatsby a ajouté DSG (Deferred Static Generation) dans v4, qui était sa réponse à Next.js ISR, mais cela nécessitait Gatsby Cloud et n'était jamais aussi flexible.

Next.js vous donne tout :

// Génération statique (équivalent au défaut de Gatsby)
// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await getAllPosts()
  return posts.map((post) => ({ slug: post.slug }))
}

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug)
  return <Article post={post} />
}

// ISR - revalider toutes les 60 secondes
export const revalidate = 60

// Ou revalidation à la demande via route API
// app/api/revalidate/route.ts
import { revalidatePath } from 'next/cache'
import { NextRequest } from 'next/server'

export async function POST(request: NextRequest) {
  const { path } = await request.json()
  revalidatePath(path)
  return Response.json({ revalidated: true })
}

Le problème de la couche de données

La couche de données GraphQL de Gatsby était innovante mais au final est devenue une responsabilité. Chaque source de données nécessitait un plugin source. Si le plugin n'existait pas ou n'était pas maintenu, vous restiez bloqué pour en écrire un vous-même. Le schéma GraphQL au moment de la construction était puissant mais ajoutait une complexité significative et du temps de construction.

Next.js prend une approche différente : récupérez simplement les données. Utilisez n'importe quoi — APIs REST, clients GraphQL, requêtes de base de données, SDK de CMS. Il n'y a pas de couche de données imposée par le framework. C'est à la fois plus simple et plus flexible.

// Next.js - récupérer de n'importe quelle source, de n'importe quelle façon
async function getProducts() {
  // Requête directe à la base de données
  const products = await prisma.product.findMany()
  
  // Ou API REST
  const res = await fetch('https://api.example.com/products', {
    next: { revalidate: 3600 }
  })
  
  // Ou SDK de CMS headless
  const entries = await contentful.getEntries({ content_type: 'product' })
  
  return products
}

Pour les équipes utilisant des configurations de CMS headless — Contentful, Sanity, Storyblok, peu importe — Next.js est dramatiquement plus facile à intégrer. Vous n'avez pas besoin d'un plugin source. Vous appelez juste l'API.

Les Server Components changent tout

Je continue à revenir sur RSC car c'est réellement le changement architectural le plus important en React depuis les hooks. Voici pourquoi cela compte pour cette comparaison :

Dans Gatsby, votre arborescence de composants de page entière est envoyée au client. Même si un composant rend juste une liste de titres de billets de blog récupérés d'un CMS, le code du composant et ses données sont sérialisés et envoyés au navigateur pour hydration.

Dans Next.js avec RSC, ce même composant s'exécute sur le serveur, rend du HTML, et le client ne voit jamais le code du composant ou les données brutes. Le navigateur reçoit du HTML. C'est tout.

Cela signifie :

  • Des bundles plus petits (comme montré ci-dessus)
  • Pas de bugs de mésappariement d'hydration pour les composants côté serveur uniquement
  • Vous pouvez utiliser du code côté serveur uniquement (requêtes de base de données, accès au système de fichiers) directement dans les composants
  • Les données sensibles (clés API, logique métier) restent sur le serveur

Expérience développeur et écosystème

Aspect Next.js 15 Gatsby 5
Support TypeScript De première classe, types auto-générés Correct, mais certains types de plugins manquent
Vitesse de rechargement à chaud ~200ms (Turbopack) 1-3 secondes (webpack)
Temps de construction (200 pages) ~45 secondes ~3-5 minutes
Écosystème de plugins Packages npm (universel) Plugins spécifiques à Gatsby (stagnant)
Documentation Activement maintenue Mostly figée depuis 2023
Communauté (Discord/GitHub) Très active Presque silencieuse
Demande du marché du travail Élevée En baisse rapide
Ressources d'apprentissage (2025-2026) Abondantes Rares

L'écart d'expérience développeur s'est considérablement élargi. Next.js avec Turbopack vous donne des rechargements à chaud quasi instantanés. Le serveur dev basé sur webpack de Gatsby semble lent en comparaison, surtout sur les sites plus volumineux.

Les temps de construction méritent une mention spéciale. Un site Gatsby de 500 pages avec un traitement d'images lourd pouvait prendre 15-20 minutes à construire. Le site Next.js équivalent avec optimisation d'images à la demande se construit en moins de 2 minutes car les images sont traitées au moment de la demande (puis mises en cache), pas au moment de la construction.

Coût total de possession

Parlez argent. C'est là que la décision devient réelle pour les parties prenantes commerciales.

Coûts d'hébergement

Scénario Next.js sur Vercel Gatsby sur Netlify
Petit site (< 100 pages, faible trafic) 0-20$/mo 0-19$/mo
Site moyen (500 pages, 100k visites/mo) 20-150$/mo 19-99$/mo
Grand site (5000+ pages, 1M+ visites/mo) 150-500$/mo 99-300$/mo*

*Les coûts d'hébergement de Gatsby sont plus bas car c'est du pur statique — aucun calcul serveur. Mais vous payez en temps de construction et en minutes de construction.

Next.js peut également être déployé sur d'autres plateformes : AWS (via SST ou Amplify), Cloudflare, auto-hébergé avec Node.js. La sortie statique pure de Gatsby lui donne plus de flexibilité d'hébergement en théorie, mais en pratique vous perdez ISR et toute fonctionnalité dynamique.

Coûts de développement

C'est là que vit la réelle différence de coût :

  • Taux développeur Gatsby : 120-180$/hr (rare, premium pour les connaissances héritées)
  • Taux développeur Next.js : 100-200$/hr (gamme plus large en raison d'un vivier de talents plus grand)
  • Coût de migration (site Gatsby moyen → Next.js) : 15 000-50 000$ selon la complexité
  • Maintenance continue (Gatsby) : Plus élevée en raison de la gestion des dépendances, des correctifs de plugins
  • Maintenance continue (Next.js) : Plus faible, des chemins de mise à niveau plus simples

Le coût caché de rester sur Gatsby est la dette technique qui s'accumule quotidiennement. Chaque mois que vous attendez, la migration devient légèrement plus difficile à mesure que l'écosystème Gatsby se détériore davantage.

Chemin de migration : Gatsby vers Next.js

J'ai fait cela suffisamment de fois pour avoir un processus reproductible. Voici l'approche de haut niveau :

Phase 1 : Audit (1-2 semaines)

  • Inventorier tous les plugins Gatsby et leurs équivalents Next.js
  • Mapper la couche de données GraphQL à des appels API directs ou à l'utilisation du SDK
  • Identifier la logique gatsby-node.js (création de pages, personnalisation de schéma)
  • Cataloguer toutes les fonctionnalités dynamiques (recherche, formulaires, authentification)

Phase 2 : Fondation (1-2 semaines)

  • Configurer le projet Next.js avec App Router
  • Configurer TypeScript, ESLint, Tailwind (ou votre approche CSS)
  • Configurer l'intégration CMS directement (aucun plugin source nécessaire)
  • Implémenter la stratégie d'optimisation d'images avec next/image

Phase 3 : Migration de pages (2-6 semaines, selon la taille)

  • Convertir les modèles de pages en composants de page Next.js
  • Remplacer gatsby-image / gatsby-plugin-image par next/image
  • Remplacer <Link> de Gatsby par <Link> de Next.js (API similaire, heureusement)
  • Migrer la logique gatsby-node.js createPages à generateStaticParams
  • Convertir toute logique gatsby-browser.js / gatsby-ssr.js en composants de mise en page

Phase 4 : Optimisation (1-2 semaines)

  • Implémenter ISR où approprié
  • Ajouter des Server Components pour les sections riches en données
  • Configurer les webhooks de revalidation à la demande de votre CMS
  • Tests de performance et optimisation
// Modèle de migration courant : requête de page Gatsby → récupération de données Next.js

// AVANT (Gatsby)
export const query = graphql`
  query BlogPostBySlug($slug: String!) {
    contentfulBlogPost(slug: { eq: $slug }) {
      title
      body { raw }
      publishDate
      heroImage {
        gatsbyImageData(width: 1200)
      }
    }
  }
`

// APRÈS (Next.js App Router)
import { createClient } from 'contentful'

const client = createClient({
  space: process.env.CONTENTFUL_SPACE_ID!,
  accessToken: process.env.CONTENTFUL_ACCESS_TOKEN!
})

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const entries = await client.getEntries({
    content_type: 'blogPost',
    'fields.slug': params.slug,
    limit: 1
  })
  
  const post = entries.items[0].fields
  
  return (
    <article>
      <h1>{post.title}</h1>
      <Image
        src={`https:${post.heroImage.fields.file.url}`}
        width={1200}
        height={630}
        alt={post.title}
      />
      <RichText content={post.body} />
    </article>
  )
}

export const revalidate = 3600 // ISR : revalider toutes les heures

La plus grande surprise dans la migration est la gestion des images. Le pipeline d'images de Gatsby était véritablement excellent — l'espace réservé au flou, les srcsets réactifs, le chargement paresseux. La bonne nouvelle est que next/image gère tout cela maintenant, mais l'API est différente et vous devrez mettre à jour chaque référence d'image.

Quand Next.js n'est pas la réponse

Je veux être juste ici. Next.js n'est pas le bon choix pour chaque projet.

Si vous avez besoin d'une simplicité absolue pour un blog ou un site de documentation, envisagez Astro. Astro envoie zéro JavaScript par défaut et a un excellent support de la collection de contenu. Pour les sites purement orientés contenu où vous n'avez pas besoin de l'interactivité de React, Astro vous donnera une meilleure performance avec moins de complexité.

Si vous construisez un simple site statique sans fonctionnalités dynamiques, même 11ty ou Hugo pourraient vous servir mieux. Ne apportez pas un framework à un combat de balisage.

Si vous êtes verrouillé dans l'écosystème Vue ou Svelte, Nuxt et SvelteKit sont des alternatives solides dans leurs écosystèmes respectifs.

Mais si vous avez besoin de React, besoin d'un mélange de contenu statique et dynamique, besoin d'une grande performance, et besoin d'un framework qui sera activement maintenu pendant des années à venir — Next.js est le choix évident en 2026.

Le verdict

Next.js gagne. Ce n'est pas même proche, et ça ne l'a pas été proche depuis 2022.

Gatsby a pionnié des idées importantes dans l'écosystème React : optimisation au moment de la construction, pipelines de traitement d'images, le concept d'une couche de données unifiée. Ces idées vivent sous différentes formes dans les frameworks modernes. Mais en tant que framework de production en 2026, Gatsby est une responsabilité.

Les arguments techniques sont accablants :

  • RSC et l'App Router donnent à Next.js un avantage architectural que Gatsby ne peut pas égaler
  • Les tailles de bundle sont 40-60% plus petites
  • Les scores Core Web Vitals sont constamment meilleurs
  • ISR et PPR fournissent une flexibilité de rendu que Gatsby n'a jamais atteinte
  • L'écosystème prospère vs. stagnant

Les arguments commerciaux sont tout aussi clairs :

  • Coût total de possession plus faible
  • Vivier de talents plus large
  • Développement et support actifs de Vercel
  • Chemins de mise à niveau clairs pour l'avenir prévisible

Si vous commencez un nouveau projet, utilisez Next.js (ou Astro si vous n'avez pas besoin de React). Si vous exécutez Gatsby en production, commencez à planifier votre migration maintenant. Plus vous attendez, plus difficile et plus coûteux cela devient.

— Aaron Mitchell, Senior Headless Engineer at Social Animal

FAQ

Gatsby est-il complètement mort en 2026?

Gatsby n'a pas été officiellement déclaré fin de vie par Netlify, mais il est effectivement en mode maintenance uniquement. Il n'y a pas eu de version significative depuis v5.13 fin 2023, l'équipe principale s'est dispersée, et l'écosystème des plugins se détériore. Pour les nouveaux projets, ce n'est pas un choix viable. Pour les projets existants, vous devriez planifier une migration.

Combien de temps faut-il pour migrer de Gatsby vers Next.js?

Pour un site marketing typique avec 50-200 pages, prévoyez 4-8 semaines de temps de développement. Les sites plus grands avec des relations de données complexes, des plugins personnalisés ou une utilisation lourde de GraphQL peuvent prendre 8-16 semaines. Les variables les plus importantes sont le nombre de plugins Gatsby personnalisés que vous utilisez et la profondeur de votre intégration à la couche de données GraphQL de Gatsby.

Next.js est-il plus difficile à apprendre que Gatsby?

L'App Router et les Server Components ont une courbe d'apprentissage, surtout si vous venez du modèle basé sur les pages de Gatsby. Cependant, le modèle mental est au final plus simple — vous récupérez les données directement au lieu de passer par une couche GraphQL, et vous écrivez des composants qui s'exécutent soit sur le serveur, soit sur le client. La plupart des développeurs trouvent Next.js plus intuitif une fois qu'ils ont dépassé les concepts RSC initiaux.

Puis-je déployer Next.js sans Vercel?

Absolument. Next.js peut être déployé sur AWS (en utilisant SST, Amplify ou une configuration personnalisée), Cloudflare Pages, DigitalOcean, Railway, Fly.io ou auto-hébergé sur tout serveur Node.js. Vercel fournit l'expérience la plus optimisée, mais vous n'êtes pas bloqué. La commande next start exécute un serveur Node.js standard.

Qu'en est-il d'Astro vs Next.js pour les sites statiques?

Pour les sites purement orientés contenu (blogs, documentation, pages marketing avec une interactivité minimale), Astro est souvent un meilleur choix. Il envoie zéro JavaScript par défaut et supporte plusieurs frameworks UI. Si vous avez besoin de l'interactivité de React, du routage dynamique, des points de terminaison API, de l'authentification, ou d'un mélange de contenu statique et dynamique, Next.js est le meilleur choix.

Combien coûte la migration de Gatsby vers Next.js?

Les coûts de développement varient généralement entre 15 000$ pour un site marketing simple et 50 000$+ pour les applications complexes avec des pipelines de données personnalisés, intégration e-commerce, ou internationalisation. Le coût dépend beaucoup du nombre de plugins Gatsby que vous devez remplacer, de la complexité de vos requêtes GraphQL, et si vous voulez moderniser l'architecture (ajouter ISR, Server Components) lors de la migration.

Next.js supporte-t-il l'export statique comme Gatsby?

Oui. Exécuter next build avec output: 'export' dans votre next.config.js génère un site complètement statique qui peut être hébergé n'importe où — S3, GitHub Pages, n'importe quel CDN. Vous perdez ISR et les fonctionnalités côté serveur, mais vous obtenez le même modèle de déploiement que Gatsby. La plupart des équipes trouvent qu'elles ne veulent pas du pur statique une fois qu'elles ont expérimenté les avantages d'ISR et des Server Components.

Qu'est-il arrivé à Gatsby Cloud?

Gatsby Cloud a été fermé dans Q1 2024, environ un an après l'acquisition de Netlify. Les utilisateurs ont été migrés vers l'hébergement standard de Netlify. C'était un coup significatif car Gatsby Cloud fournissait des builds optimisés, des builds incrémentiels et une fonctionnalité d'aperçu étroitement couplée à l'architecture de Gatsby. Sans Gatsby Cloud, les temps de construction sur les plateformes CI/CD standard sont notablement pires.