Next.js 16.2 a publié une API Adaptateur stable la semaine dernière. En surface, cela ressemble à un refactoring interne. Ce n'est pas le cas. C'est le résultat de deux ans de collaboration entre l'équipe Next.js, OpenNext, Netlify, Cloudflare, AWS Amplify et Google Cloud — et cela signifie une chose concrète : Next.js dispose maintenant d'un contrat public, typé et versionné que toute plateforme peut implémenter pour exécuter correctement votre application.
Ce qu'est réellement l'API Adaptateur
Lorsque Next.js build, il produit une description de votre application : routes, pré-rendus, assets statiques, cibles runtime, dépendances, règles de caching et décisions de routage. L'API Adaptateur fait de cette sortie une interface stable que les adaptateurs consomment et mappent sur l'infrastructure d'un provider.
Les adaptateurs implémentent deux hooks : modifyConfig au chargement de la configuration et onBuildComplete quand la sortie complète est disponible. Les breaking changes nécessitent une nouvelle version majeure de Next.js. Le contrat est public, versionné et open source — l'adaptateur propre à Vercel utilise ce même contrat public sans hooks privés.
Comment on en est arrivé là
L'histoire commence avec l'équipe engineering de Netlify qui passait beaucoup d'efforts à contourner des hypothèses non documentées dans la sortie de build Next.js. Quand l'équipe Next.js les a contactés pour comprendre leurs pain points, un fil commun est apparue dans 90% des problèmes : il n'y avait aucun mécanisme documenté et stable pour configurer et lire la sortie de build.
OpenNext avait déjà comblé ce manque pour AWS, Cloudflare et Netlify en traduisant la sortie de build Next.js en quelque chose que chaque plateforme pouvait consommer. Cette expérience a montré à l'équipe Next.js que la sortie de build pouvait servir d'interface stable. La collaboration qui a suivi a produit le RFC publié en avril 2025, qui a mené directement à l'API Adaptateur stable dans 16.2.
Ce qui change pour les développeurs
Si vous déployez sur Vercel, rien ne change — tout fonctionne comme avant. Si vous déployez ailleurs, la situation s'améliore considérablement. OpenNext, Netlify, Cloudflare, AWS Amplify et Google Cloud implémentent tous ce même contrat, ce qui signifie que les fonctionnalités Next.js comme le streaming, les Server Components, le Partial Prerendering, le middleware et la revalidation à la demande devraient fonctionner correctement sur toutes ces plateformes.
Le groupe de travail écosystème Next.js — incluant des représentants des cinq plateformes — coordonnera les changements futurs pour empêcher le type de divergence qui rendait le support multi-plateforme si difficile auparavant.
L'avantage pratique
Pour les auteurs de frameworks et les équipes de plateformes, l'API Adaptateur signifie que vous n'avez plus besoin de reverse-engineerer les internals de Next.js pour le supporter correctement. Pour les développeurs qui choisissent une plateforme, cela signifie que le framework lui-même s'engage sur le comportement de votre application — pas seulement le provider d'hébergement.
tldr
- Next.js 16.2 livre une API Adaptateur publique et stable — un contrat typé entre le framework et les plateformes de déploiement
- OpenNext, Netlify, Cloudflare, AWS Amplify et Google Cloud implémentent tous le même contrat ; Vercel l'utilise aussi (pas de hooks privés)
- Le groupe de travail écosystème avec toutes les cinq plateformes signifie que les prochains changements Next.js seront coordonnés, pas silencieusement cassants
faq
- Dois-je changer quelque chose ? Si vous êtes sur Vercel, non. Si vous déployez ailleurs, votre plateforme mettra à jour son adaptateur pour utiliser la nouvelle API.
- Qu'en est-il des apps Next.js 15 ? L'API Adaptateur est disponible maintenant ; vérifiez la compatibilité de l'adaptateur de votre plateforme.
- Est-ce lié au projet OpenNext ? Oui — les mainteneurs d'OpenNext ont co-conçu l'API Adaptateur et ça remplace le rôle d'OpenNext en tant que couche de compatibilité non officielle.
