Votre site créé avec v0 ou une IA utilise Next.js ? Vérifiez sa version aujourd’hui

Vous avez demandé à une IA de créer votre site. Mais savez-vous quelle version du logiciel le fait tourner ? Le 25 août 2026, Next.js a publié les versions 16.3.3 et 15.5.24 pour traiter deux failles critiques. Pour les propriétaires de petits SaaS, de boutiques ou de portails clients, la première urgence n’est pas de demander à l’agent de « tout sécuriser » : c’est d’identifier ce qui est réellement déployé.

La publication officielle de sécurité d’août confirme la disponibilité des correctifs. Nous proposons ici une méthode de vérification, pas le compte rendu d’un test d’intrusion. Comptez dix minutes pour un premier diagnostic si vous avez accès au dépôt et à l’hébergement ; la mise à jour, ses tests et son déploiement peuvent demander davantage de temps.

Un site créé avec une IA n’utilise pas forcément Next.js

Le nom du builder n’est pas une preuve technique. v0 indique utiliser Next.js par défaut, tout en pouvant travailler avec d’autres frameworks. À l’inverse, la documentation d’hébergement de Lovable décrit des applications Vite, dont le frontend est compilé en fichiers statiques. Il serait donc faux de présenter tous les sites Lovable comme concernés par cette alerte.

Un projet importé, personnalisé ou accompagné d’un autre service peut avoir une architecture différente. La bonne question est : « Le composant qui sert mon application utilise-t-il le paquet next ? » React, à lui seul, ne signifie pas Next.js. Et une application générée automatiquement reste un logiciel à maintenir, comme le rappelle notre analyse de Hostinger AI Builder lorsque le site devient une véritable application.

Deux failles critiques, mais pas les mêmes conditions

Ces alertes portent sur une possible exécution de code à distance sans authentification. Cela ne signifie pas que chaque site Next.js a été compromis : l’exposition dépend aussi des fonctions utilisées et de l’environnement du serveur.

Les détails figurent dans les avis officiels sur l’optimisation AVIF et sur les serveurs Windows. Attention à la confusion : développer sur un PC Windows n’implique pas que le serveur de production tourne sous Windows. Inversement, un serveur Linux n’est pas automatiquement épargné par le problème AVIF.

Le diagnostic en dix minutes : trois preuves à récupérer

1. Trouver Next.js dans le bon projet

Ouvrez le fichier package.json de l’application et recherchez une dépendance nommée next. Des scripts tels que next dev ou next build constituent d’autres indices. Dans un dépôt contenant plusieurs applications, répétez l’opération pour chacune : le fichier situé à la racine n’est pas forcément celui du site.

Si vous n’avez qu’un accès à l’éditeur visuel, demandez au prestataire ou au support le framework, sa version exacte et l’identifiant du dernier déploiement. Une capture de la page d’accueil ou un détecteur de technologies ne suffit pas à établir la version exécutée.

2. Distinguer version autorisée, installée et déployée

Une ligne comme "next": "^16.3.0" est une plage de versions, pas la preuve que le correctif est installé. Dans une copie locale de confiance du projet utilisant npm, vous pouvez lancer :

npm ls next --all
npm ls next --all --package-lock-only

La première commande décrit les dépendances installées ; la seconde lit l’arborescence du fichier de verrouillage npm. Ce comportement est documenté dans la référence de npm ls. Un résultat vide ou une erreur ne permet pas de conclure si les dépendances ne sont pas installées ou si vous êtes dans le mauvais dossier. Avec pnpm ou Yarn, utilisez l’inspection du gestionnaire déjà employé par le projet, sans créer un deuxième lockfile.

Enfin, rapprochez cette version du commit et de l’artefact actuellement en production : journal de construction, image du conteneur ou informations du déploiement. Corriger votre ordinateur ne modifie pas le serveur. Ne publiez pas de fichier de diagnostic exposant ces informations ou vos variables d’environnement sur une URL accessible à tous.

3. Identifier l’hébergement réel

Relevez la plateforme, le système du serveur et le mode d’exécution : serveur Next.js, conteneur, fonctions gérées ou export statique. Un domaine personnalisé ou un CDN devant le site ne dit pas où l’application s’exécute. Si un export est entièrement statique, recherchez aussi les services séparés qui pourraient utiliser Next.js : ne généralisez pas la conclusion à toute votre architecture.

Sur Vercel, ne transformez pas une éventuelle protection de plateforme en dispense de mise à jour. Le bulletin officiel consulté demande de corriger les dépendances et ne donne pas d’exemption générale pour tous les déploiements Vercel. Si votre hébergeur annonce une mesure de protection, vérifiez qu’elle couvre précisément ces avis et votre application. En auto-hébergement, la reconstruction et le remplacement de la version vulnérable relèvent de votre équipe ou de votre prestataire.

Next.js 16.3.3 ou 15.5.24 : choisir la bonne mise à jour

Les deux versions publiées le 25 août correspondent aux branches maintenues : 16.3.3 pour la branche 16.3 et 15.5.24 pour la branche 15.5. Ce sont les points de correction de cette alerte, pas une promesse qu’ils resteront les meilleurs choix indéfiniment. Au moment d’intervenir, relisez les avis officiels pour vérifier si un correctif plus récent est recommandé.

Ne considérez pas une ancienne branche comme sûre parce qu’elle n’apparaît pas dans les commandes ci-dessous. L’avis Windows inclut notamment les versions de 13.4 jusqu’avant 15.5.24, ainsi que celles de 16.0 jusqu’avant 16.3.3. L’avis AVIF remonte à des versions plus anciennes encore. Une migration depuis Next.js 13 ou 14 demande une analyse de compatibilité ; ce n’est pas une simple mise à jour corrective de la branche existante.

Pour un projet déjà en 16.3 avec npm, commencez par vérifier les modifications en cours, puis créez une branche dédiée :

git status --short
git switch -c security/nextjs-aout-2026
npm install next@16.3.3
npm ls next --all

Si le projet est en 15.5, utilisez npm install next@15.5.24 à la place : n’exécutez pas les deux installations successivement. Préservez les modifications non liées, examinez le diff de package.json et du lockfile, puis vérifiez les contraintes de compatibilité. Évitez un npm audit fix --force lancé sans lecture : élargir brutalement les changements complique le diagnostic des régressions.

Un build vert ne suffit pas à valider la réparation

Faites exécuter à l’agent les contrôles réellement présents dans le projet : tests, lint, vérification des types et build de production. Il doit signaler les tests absents ou impossibles à lancer, pas les compter comme réussis. Dans une copie propre destinée à la validation, vérifiez aussi que l’installation à partir du lockfile reproduit bien le résultat.

La prévisualisation doit couvrir quelques parcours concrets :

• ouvrir une page publique et une page nécessitant une connexion ;
• vérifier qu’un visiteur non autorisé reste bloqué ;
• soumettre un formulaire avec des données de test ;
• charger les images et contrôler particulièrement les usages AVIF après la mise à jour ;
• tester les fonctions serveur et les routes essentielles au service.

Ces contrôles cherchent les régressions fonctionnelles ; ils ne prouvent pas à eux seuls l’absence d’une vulnérabilité. La preuve de correction de cette alerte passe aussi par la version effectivement embarquée. Notre guide TDD-Agent explique comment sécuriser une mise à jour avec des tests avant déploiement, sans laisser l’agent supprimer un test gênant pour obtenir artificiellement un résultat vert.

Après validation, déployez l’artefact corrigé, remplacez les anciennes instances et confirmez la version active dans votre système de déploiement. Préparez une procédure de retour arrière, mais souvenez-vous qu’un retour à la version vulnérable rétablit aussi le risque. Si des signes de compromission sont déjà présents, une mise à jour seule ne constitue pas une réponse à incident complète.

Le prompt à donner à votre agent avant de le laisser modifier le site

Copiez ce cadre, puis adaptez-le à votre dépôt. L’objectif n’est pas de faire déclarer l’application « sécurisée », mais d’obtenir des preuves et un périmètre de changement contrôlé.

« Ne modifie rien et ne déploie rien pour l’instant. Identifie les applications de ce dépôt qui utilisent Next.js. Pour chacune, distingue la version déclarée, verrouillée, installée et déployée ; marque comme inconnue toute donnée non vérifiable. Consulte le bulletin officiel Next.js du 25 août 2026 et ses deux avis, puis recherche leurs éventuelles mises à jour. Évalue les conditions d’exposition AVIF et Windows sans lancer d’exploitation. Ne lis ni n’affiche les secrets.

Propose la version corrigée adaptée à la branche, les fichiers à changer, les tests existants, les parcours à vérifier en prévisualisation et le plan de déploiement. Attends mon accord avant les modifications. Après accord, travaille dans une branche, conserve les tests légitimes et fournis les résultats réels, y compris les contrôles non exécutés. Aucun déploiement en production sans validation explicite. »

Ce cadre protège aussi contre les autres risques d’une chaîne de développement pilotée par IA : instructions non fiables, scripts trop permissifs et accès inutiles aux secrets. Une alerte sur Next.js n’autorise pas l’agent à installer n’importe quel outil de « réparation » trouvé en ligne.

Le bon livrable tient sur une fiche : application concernée, version déployée, hébergement identifié, conditions d’exposition, version cible, contrôles exécutés et responsable du déploiement. Si votre prestataire peut remplir cette fiche, vous avez une base pour agir. S’il répond seulement « l’IA s’en est occupée », demandez les preuves.