Next.js vs Gatsby en 2026 : Le guide complet de décision pour la production
J'ai construit des sites de production avec Next.js et Gatsby depuis 2019. J'ai vu Gatsby lever 46 millions de dollars, être acquis par Netlify, puis être tranquillement abandonné. J'ai migré trois sites Gatsby d'entreprise vers Next.js en 2025 seul. Ce n'est pas une comparaison théorique — c'est une autopsie d'un framework et une évaluation honnête de l'autre.
Si vous exécutez encore Gatsby en production, vous avez besoin d'un plan de migration. Si vous choisissez un framework pour un nouveau projet, la réponse est simple mais nuancée. Laissez-moi vous expliquer tout cela.
Table des matières
- L'état de Gatsby en 2026
- Next.js en 2026 : qu'est-ce qui a réellement changé
- Benchmarks de performance : Lighthouse, taille du bundle, Core Web Vitals
- Comparaison architecturale : RSC, App Router, SSG, ISR
- Expérience développeur et écosystème
- Coût total de propriété
- Chemin de migration : Gatsby vers Next.js
- Quand Next.js n'est pas la réponse
- Le verdict
- FAQ
L'état de Gatsby en 2026
Soyons clairs. Gatsby est, pour tous les usages 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 Netlify. Ce qui s'est réellement produit était un arrêt progressif. La dernière version Gatsby significative (v5.13) a été livrée fin 2023. Le référentiel GitHub a eu des commits de maintenance minimaux depuis mi-2024. Des mainteneurs clés ont quitté. L'écosystème des plugins s'est stagnant — 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 arrêté |
| Q2 2024 | Les membres de l'équipe centrale quittent Netlify |
| Q4 2024 | Les téléchargements hebdomadaires npm chutent en dessous de 150k (depuis le pic de 800k+) |
| Q1 2025 | Netlify supprime la documentation spécifique à Gatsby de la navigation principale |
| 2026 | Aucune version v6, aucune feuille de route, effectivement en mode maintenance |
Les chiffres de téléchargement npm racontent l'histoire. À son apogée en 2021, Gatsby enregistrait plus de 800 000 téléchargements hebdomadaires. Début 2026, il tourne autour de 100 000 — et la plupart d'entre eux proviennent de pipelines CI/CD existants, pas de nouveaux projets.
Je ne dis pas cela pour dénigrer Gatsby. Il a vraiment fait avancer l'écosystème React. 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 de véritables innovations. Mais le framework a perdu l'argument technique quand Next.js a livré ISR fin 2020, et a perdu l'argument commercial quand Netlify a cessé d'y investir.
Si vous exécutez Gatsby en production maintenant, vos plus grands 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
- Pourriture des plugins — les plugins tiers se cassent sans correctifs en amont
- Difficulté d'embauche — les développeurs ne veulent pas Gatsby sur leur CV en 2026
Next.js en 2026 : qu'est-ce qui a réellement changé
Next.js 15 a débarqué fin 2024, et les versions itératives de 2025 ont solidifié l'App Router comme modèle de développement principal. Voici où nous en sommes :
React Server Components (RSC) sont maintenant les composants par défaut. Quand vous créez un composant dans l'App Router, c'est un composant serveur sauf si vous ajoutez explicitement 'use client'. Ce n'était pas juste un changement de syntaxe — cela a fondamentalement modifié la façon dont nous pensons à la récupération de données et à l'architecture des composants.
Partial Prerendering (PPR) a atteint la stabilité dans Next.js 15.1. C'est la fonctionnalité qui aurait tué Gatsby même si Gatsby était encore 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.
Server Actions ont considérablement mûri. Gestion des formulaires, mutations, revalidation — les modèles sont bien établis maintenant et ils ont remplacé une grande partie de la boilerplate des routes API que nous avions l'habitude d'écrire.
// Next.js 15 - exemple 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% comparé à webpack. Les builds de production sont aussi plus rapides, bien que l'amélioration soit plus modeste — environ 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 portfolio riche en images. Le même contenu, le 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 |
| Bonnes 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 expédie un runtime client qui inclut React, le runtime Gatsby, et la couche de données. Next.js avec l'App Router et RSC expédie significativement moins de JavaScript au client parce que les Server Components ne contribuent pas du tout au bundle client.
| Métrique | Next.js 15 (App Router) | Gatsby 5.13 |
|---|---|---|
| Premier chargement JS | 87 KB (gzippé) | 210 KB (gzippé) |
| JS de route (moy.) | 12 KB | 45 KB |
| Total JS (site 50 pages) | 145 KB | 380 KB |
| Optimisation des images | Intégrée (à la demande) | Temps de construction (gatsby-plugin-image) |
| Optimisation des polices | Intégrée (next/font) | Manuelle ou plugin |
La différence de taille de bundle est largement grâce à RSC. Dans un site Gatsby typique, chaque composant est expédié au client même s'il ne rend que du contenu statique. Dans Next.js avec les Server Components, un composant qui récupère des données et rend du HTML ne frappe jamais le bundle client. C'est une énorme victoire.
Core Web Vitals sur le terrain
Les benchmarks de laboratoire sont utiles, mais les données de terrain comptent davantage. Basé sur les données CrUX (Chrome User Experience Report) de 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 (principalement en échec sur INP et TBT)
La métrique INP (Interaction to Next Paint) est là où Gatsby peine vraiment. Le plus grand bundle JavaScript côté client signifie plus de travail du thread principal, ce qui signifie des interactions plus lentes. Le modèle d'hydratation 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 côté serveur.
Comparaison architecturale : RSC, App Router, SSG, ISR
Stratégies de rendu
Gatsby a été construit autour d'une stratégie de rendu : Static Site Generation (SSG). Tout est construit au moment de la construction. Gatsby a ajouté DSG (Deferred Static Generation) dans v4, ce qui était leur réponse à Next.js ISR, mais cela nécessitait Gatsby Cloud et n'a jamais été aussi flexible.
Next.js vous donne tout :
// Génération statique (équivalente 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 - revalidate tous 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 s'est finalement avérée être un handicap. Chaque source de données nécessitait un plugin source. Si le plugin n'existait pas ou n'était pas maintenu, vous étiez bloqué en devant 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 adopte une approche différente : il suffit de récupérer les données. Utilisez ce que vous voulez — API REST, clients GraphQL, requêtes de base de données, SDK 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 depuis 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 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. Nous couvrons cela en profondeur dans notre travail de développement CMS headless.
Les Server Components changent tout
Je reviens constamment à RSC parce que c'est vraiment le changement architectural le plus important dans React depuis les hooks. Voici pourquoi cela compte pour cette comparaison :
Dans Gatsby, votre arborescence de composants de page entière est expédiée au client. Même si un composant ne rend qu'une liste de titres de posts 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 hydratation.
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 :
- Bundles plus petits (comme montré ci-dessus)
- Aucun bug d'incompatibilité d'hydratation 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 | Première classe, types auto-générés | Correct, mais certains types de plugins manquants |
| 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 (universels) | Plugins spécifiques à Gatsby (stagnants) |
| Documentation | Activement maintenue | Principalement 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 en termes d'expérience développeur s'est considérablement creusé. Next.js avec Turbopack vous offre des rechargements à chaud quasi instantanés. Le serveur de développement basé sur webpack de Gatsby semble lent par comparaison, en particulier sur les sites plus grands.
Les temps de construction méritent une mention spéciale. Un site Gatsby de 500 pages avec traitement d'images lourdes pouvait prendre 15-20 minutes à construire. Le site Next.js équivalent avec optimisation d'images à la demande se construit en moins de 2 minutes parce que les images sont traitées au moment de la requête (puis mises en cache), pas au moment de la construction.
Notre équipe de développement Next.js a vu cela se concrétiser sur des dizaines de projets. Les temps de construction impactent directement la productivité des développeurs et les coûts CI/CD.
Coût total de propriété
Parlons d'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 Gatsby sont plus bas parce qu'il s'agit d'une page statique — aucun calcul serveur. Mais vous payez en temps de construction et minutes de construction.
Next.js peut aussi ê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 la réelle différence de coût réside :
- Taux des développeurs Gatsby : 120-180$/h (rares, premium pour les connaissances héritées)
- Taux des développeurs Next.js : 100-200$/h (gamme plus large en raison d'une plus grande réserve de talents)
- Coût de migration (site Gatsby moyen → Next.js) : 15 000-50 000$ selon la complexité
- Maintenance en cours (Gatsby) : Plus élevée en raison de la gestion des dépendances, des correctifs des plugins
- Maintenance en cours (Next.js) : Plus basse, chemins de mise à niveau plus directs
Le coût caché de rester sur Gatsby est la dette technique qui s'accumule quotidiennement. Chaque mois d'attente, la migration devient légèrement plus difficile à mesure que l'écosystème Gatsby se détériore davantage.
Pour une évaluation détaillée de ce qu'une migration pourrait coûter pour votre situation spécifique, consultez notre page de tarification ou contactez-nous.
Chemin de migration : Gatsby vers Next.js
J'ai suffisamment fait cela pour avoir un processus répétable. Voici l'approche de haut niveau :
Phase 1 : Audit (1-2 semaines)
- Inventoriez tous les plugins Gatsby et leurs équivalents Next.js
- Mappez la couche de données GraphQL sur les appels API directs ou l'utilisation de SDK
- Identifiez la logique
gatsby-node.js(création de pages, personnalisation du schéma) - Cataloguez toutes les fonctionnalités dynamiques (recherche, formulaires, authentification)
Phase 2 : Fondation (1-2 semaines)
- Configurez le projet Next.js avec App Router
- Configurez TypeScript, ESLint, Tailwind (ou votre approche CSS)
- Configurez l'intégration CMS directement (aucun plugin source nécessaire)
- Implémentez la stratégie d'optimisation des images en utilisant
next/image
Phase 3 : Migration de pages (2-6 semaines, selon la taille)
- Convertissez les modèles de pages en composants de page Next.js
- Remplacez
gatsby-image/gatsby-plugin-imageparnext/image - Remplacez
<Link>de Gatsby par<Link>de Next.js (API similaire, heureusement) - Migrez la logique
gatsby-node.jscreatePagesversgenerateStaticParams - Convertissez toute logique
gatsby-browser.js/gatsby-ssr.jsen composants de mise en page
Phase 4 : Optimisation (1-2 semaines)
- Implémentez ISR où approprié
- Ajoutez les Server Components pour les sections chargées en données
- Configurez les webhooks de revalidation à la demande de votre CMS
- Tests de performance et optimisation
// Modèle de migration courant : requête Gatsby page → 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: revalidate toutes les heures
Le plus grand piège de la migration est la gestion des images. Le pipeline d'images de Gatsby était véritablement excellent — le placeholder de flou, les srcsets réactifs, le chargement différé. 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, considérez Astro. Astro expédie zéro JavaScript par défaut et a un excellent support des collections de contenu. Pour les sites purement axés sur le contenu où vous n'avez pas besoin de l'interactivité 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 mieux vous servir. N'apportez pas de framework à un combat de balisage.
Si vous êtes verrouillé dans l'écosystème Vue ou Svelte, Nuxt et SvelteKit sont des alternatives fortes dans leurs écosystèmes respectifs.
Mais si vous avez besoin de React, avez besoin d'un mélange de contenu statique et dynamique, avez besoin d'une excellente performance, et avez besoin d'un framework qui sera activement maintenu pendant des années — Next.js est le choix évident en 2026.
Le verdict
Next.js gagne. Ce n'est même pas proche, et ça ne l'a pas été depuis 2022.
Gatsby a pionerisé 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 des formes différentes dans les frameworks modernes. Mais en tant que framework de production en 2026, Gatsby est un passif.
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 offrent une flexibilité de rendu que Gatsby n'a jamais atteinte
- L'écosystème prospère vs stagne
Les arguments commerciaux sont tout aussi clairs :
- Coût total de propriété inférieur
- Réserve de talents plus grande
- 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 dès maintenant. Plus vous attendez, plus difficile et coûteux c'est.
Besoin d'aide avec cette migration ? Notre équipe l'a fait de nombreuses fois. Parlons-en.
— Aaron Mitchell, Ingénieur Headless Senior chez Social Animal
FAQ
Gatsby est-il complètement mort en 2026 ? Gatsby n'a pas été officiellement déclaré en fin de vie par Netlify, mais il est effectivement en état de 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, attendez-vous à 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 GraphQL lourde peuvent prendre 8-16 semaines. Les plus grandes variables sont le nombre de plugins Gatsby personnalisés que vous utilisez et la profondeur de votre intégration avec 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, en particulier si vous venez du modèle basé sur les pages de Gatsby. Cependant, le modèle mental est finalement 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 n'importe quel serveur Node.js. Vercel fournit l'expérience la plus optimisée, mais vous n'êtes pas enfermé. 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 axés sur le contenu (blogs, documentation, pages marketing avec une interactivité minimale), Astro est souvent un meilleur choix. Il expédie zéro JavaScript par défaut et supporte plusieurs frameworks d'interface utilisateur. Si vous avez besoin de l'interactivité 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. Nous travaillons avec les deux — consultez notre page de développement Astro pour plus d'informations sur quand nous le recommandons.
Combien coûte une migration de Gatsby vers Next.js ? Les coûts de développement varient généralement de 15 000$ pour un site marketing simple à 50 000$+ pour les applications complexes avec des pipelines de données personnalisés, l'intégration e-commerce, ou l'internationalisation. Le coût dépend fortement du nombre de plugins Gatsby qui nécessitent un remplacement, de la complexité de vos requêtes GraphQL, et de si vous voulez moderniser l'architecture (ajout d'ISR, Server Components) pendant la migration.
Next.js supporte-t-il l'exportation 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 de pure statique une fois qu'elles expérimentent les avantages d'ISR et des Server Components, bien que.
Qu'est-il arrivé à Gatsby Cloud ? Gatsby Cloud a été arrêté en Q1 2024, environ un an après l'acquisition de Netlify. Les utilisateurs ont été migrés vers l'hébergement standard Netlify. C'était un coup significatif parce que Gatsby Cloud fournissait des builds optimisés, des builds incrémentiels, et une fonctionnalité d'aperçu qui étaient étroitement couplés avec l'architecture de Gatsby. Sans Gatsby Cloud, les temps de construction sur les plates-formes CI/CD standard sont notablement plus longs.