Je travaille avec beaucoup de vibe coders au bureau, et cela m’a fait réfléchir à la maintenance. Un logiciel demande de l’attention une fois livré, les paquets vieillissent, des vulnérabilités sont découvertes, et quand on débute dans la création avec l’IA, il est facile de ne penser à rien de tout cela.
Puis j’ai compris que je devais appliquer le même raisonnement à mes propres projets, alors j’ai parcouru leur historique git. J’ai trouvé pas mal de choses, mais pas celles que j’attendais, et l’une d’elles était encore ouverte le jour où j’ai regardé.
Cet article ne parle donc plus de ce que les autres oublient. Il parle de moi.
Une alerte, trois apps
Le 14 octobre, Next.js a publié des correctifs pour deux vulnérabilités critiques et une de gravité élevée. « Critique » signifie ici exécution de code à distance, c’est-à-dire que, dans certaines conditions, un inconnu sur internet pourrait exécuter son propre code sur ton serveur sans se connecter. Le correctif est arrivé dans la version 16.4.1.
Je fais tourner trois apps sur Next.js, toutes construites avec des outils de code IA et toutes sous la responsabilité de la même personne, c’est-à-dire moi. Voici ce qui s’est passé :
| App | Quand le code est passé à une version corrigée | Délai après l’alerte | En production |
|---|---|---|---|
| chandlernguyen.com | 18 octobre | 4 jours | 18 octobre |
| DIALØGUE | 29 octobre | 15 jours | 29 octobre |
| Prova | 3 novembre | 20 jours | 3 novembre |
Quand j’ai regardé le 3 novembre, Prova était encore verrouillé sur Next.js 16.2.6, la version qu’il utilisait depuis mai, et c’est elle qui tournait en production. pnpm audit --prod listait 5 alertes critiques, toutes dans Next.js.
Ce chiffre paraît plus grave que ce que j’ai trouvé, alors je veux rester juste. En les passant en revue une par une avec mes outils d’IA, j’ai vu que la plupart des alertes critiques ne s’appliquaient pas à Prova. Il n’a pas de fonctions use cache, il ne tourne pas sous Windows, et je n’ai trouvé aucune entrée contrôlable par un attaquant qui atteigne le code next/og. Celles qui concernent l’optimisation d’images ne s’appliquent probablement pas non plus sur Vercel, mais c’est une déduction tirée du comportement de la plateforme, car je n’ai pas trouvé de déclaration de Vercel à ce sujet. Ce qui s’appliquait clairement, c’était un problème de déni de service de gravité élevée dans les Server Actions : quelqu’un aurait pu perturber l’app, et cela est resté en ligne jusqu’au correctif.
J’ai fait passer la production à Next.js 16.4.5 le jour même. L’audit est passé de 5 alertes critiques à 0, et la plupart de celles de gravité élevée ont aussi disparu. Ce qui reste se trouve en dehors de Next.js et je dois encore m’en occuper. C’est donc mieux, mais pas propre.
Je ne peux pas appeler tout cela une bonne maintenance. Les pires alertes ont surtout manqué Prova à cause de la façon dont il se trouve être construit, pas parce que quelqu’un avait vérifié. C’est de la chance, et je ne le sais que parce que j’ai fini par regarder.
Je ne peux pas non plus m’attribuer beaucoup de mérite pour la première ligne. Le commit de mon site du 18 octobre était une mise à niveau générale de la chaîne d’outils, depuis Next.js 16.1.6, et son message ne mentionne pas l’alerte. C’était peut-être simplement un bon timing.
Pourquoi être occupé n’a pas aidé
L’explication facile serait que Prova avait été négligé, et il y a du vrai là-dedans. Il y a eu un écart de 41 jours entre deux commits en août et septembre.
Mais cette explication s’effondre en octobre. Prova a eu 175 commits ce mois-là. J’ai livré des correctifs pour iOS, la facturation, les e-mails et les traductions, et la version de Next.js n’a pas bougé. Le 30 octobre, j’ai même rédigé un plan de maintenance des dépendances. Sa ligne de statut indique : « planifié ; mise en œuvre non commencée. »
L’activité n’est donc pas la maintenance, et je pense que c’est le point le plus important pour quiconque construit avec l’IA. Quand tu crées une fonctionnalité, tu as un retour immédiat. Tu vois le bouton, tu cliques dessus et tu le vois fonctionner. Quand une vulnérabilité est annoncée dans un paquet installé il y a cinq mois, tu n’as rien. L’app continue de servir ses pages, les tests restent au vert et le build passe. Rien n’est cassé, et c’est exactement pour cela que personne ne regarde.
C’est comme un détecteur de fumée qui ne sonnerait que si tu allais lui poser la question. Les outils d’IA rendent la construction de la maison bien moins chère. Ils n’installent pas le détecteur.
Cela m’était aussi déjà arrivé. DIALØGUE n’a eu aucun commit entre le 6 octobre 2025 et le 11 janvier 2026. React2Shell, une vulnérabilité critique de Next.js et React, a été rendue publique début décembre. Mon commit de correction date du 11 janvier, plus de cinq semaines plus tard, et le plus ancien déploiement de production que je peux encore voir date du 18 janvier, donc je ne peux pas te dire exactement ce qui tournait en décembre. Ce qui m’a probablement le plus aidé n’avait rien à voir avec moi : Vercel dit avoir déployé des règles de pare-feu pour tous ses clients, tout en disant clairement de ne pas s’y fier à la place d’un correctif.
Je veux être clair sur un point, parce que l’expression « vibe coder » peut sonner comme une insulte. J’ai appris à coder dans des cours structurés, dont un certificat en cybersécurité, ces dépôts ont des tests et des étapes de revue, et cela s’est quand même produit. Je ne pense donc pas que ce soit un problème de débutant. Je pense que c’est ce qui arrive par défaut quand créer un logiciel coûte peu et que personne n’est chargé de le surveiller.
À quoi ressemble le détecteur
La bonne nouvelle, c’est qu’une toute petite vérification change beaucoup de choses.
Le 27 octobre, j’ai ajouté pnpm audit --prod à la CI de mon site, c’est-à-dire simplement l’ensemble de vérifications automatiques lancées quand du code est poussé. Le 28 octobre, elle a échoué à cause d’une alerte dans une bibliothèque de rendu d’e-mails que mon site embarquait sans jamais l’utiliser, et le 29 octobre j’ai retiré cette bibliothèque. Cela a pris deux jours et je n’ai eu à me souvenir de rien.
Il n’y avait là rien de malin. Il faut simplement que quelqu’un, ou quelque chose, ait pour consigne de regarder.
Mettre à jour les paquets ne m’aurait pas sauvé
Si cet article s’arrêtait là, il te donnerait un faux réconfort, car certains des correctifs assez inconfortables que j’ai faits en octobre n’avaient rien à voir avec des paquets obsolètes. C’étaient des erreurs dans mon propre produit.
Dans DIALØGUE, par exemple :
- Des fonctions privilégiées de la base de données pouvaient être appelées avec la seule clé publique, et un utilisateur connecté pouvait atteindre des fonctions réservées à mon backend.
- Un podcast remboursé pouvait revenir à la vie et se terminer sans être facturé de nouveau, et c’est arrivé sur un petit nombre de podcasts.
Dans Prova, des rôles publics de la base de données avaient hérité de permissions que personne n’avait choisies, comme TRUNCATE, parce qu’elles venaient d’un réglage par défaut de la plateforme. Aucun chemin de l’app ne les utilisait, mais elles étaient là.
Aucune mise à niveau de version ne corrige cela. Ces apps tournaient avec ces problèmes, et là non plus rien n’a cassé. Ils ne sont apparus que parce qu’une revue de sécurité est allée les chercher, et j’avais déjà fait sur ces produits des revues de sécurité qui ne les avaient pas tous repérés.
Une partie de tout cela a-t-elle été détournée ? Je ne sais pas, et je ne peux pas le découvrir entièrement. Mes logs de base de données ne remontent qu’à environ 90 jours, et certains de ces problèmes sont plus anciens. Sur la période que je peux voir, je n’ai trouvé aucun appel extérieur à ces fonctions. Cela ne couvre qu’une fenêtre limitée et ne montre pas qu’il ne s’est rien passé. Je ne peux pas non plus dire qui ou quoi a relancé ces podcasts remboursés, même si une nouvelle tentative dans mon propre code est ma meilleure hypothèse.
Cette liste n’est pas complète non plus. Je travaille encore sur d’autres problèmes, et je ne les décrirai pas tant qu’ils restent ouverts.
La question des modèles n’est pas celle que je croyais
Je m’attendais à écrire que les anciens modèles d’IA coûtent plus cher. Je ne peux pas le soutenir. J’ai cherché, et je n’ai de comparaison de coûts avant/après dans aucun de ces dépôts, donc ce ne serait qu’une supposition.
Ce que j’ai trouvé est plus étrange. Les modèles de brouillon de script et de revue de DIALØGUE étaient réglés sur gemini-3.5-flash jusqu’au 12 octobre. La documentation de Google indique désormais que ce point de terminaison ne sera pas arrêté et redirige automatiquement les requêtes vers gemini-3.6-flash. Je ne sais pas quand cette redirection a commencé, donc je ne peux pas te dire quel modèle répondait, ni pendant combien de temps. Un nom de modèle dans ta configuration ne fige pas le modèle.
Les prix bougent aussi. Gemini 3.8 Flash, vers lequel j’ai migré Prova et DIALØGUE en octobre, est affiché à $0.75 par million de tokens en entrée et $3.75 par million de tokens en sortie jusqu’au 31 décembre. À partir du 1er janvier 2027, cela double pour passer à $1.50 et $7.50. Je n’y suis passé que le mois dernier, et je dois encore calculer ce que cela change pour mes coûts.
Mettre à niveau n’est pas sans risque non plus, et je ne veux pas faire comme si c’était le cas :
- Peu après avoir fait passer Ask Sydney à DeepSeek Flash, au moins une question a échoué en production parce que le modèle voulait plus de tours de recherche que mon code n’en autorisait.
- Quand j’ai migré les embeddings de Prova, les premières exécutions ont échoué après que la table de la base de connaissances avait été vidée, et la recherche est restée dégradée jusqu’à ce que je la rétablisse.
- Cette même migration a révélé un réglage de production qui aurait envoyé un nom de modèle Claude à l’API de Google.
Ce qui a rendu la migration de Prova digne de confiance était banal. J’avais une évaluation enregistrée avant le changement, 22 décisions de revue de sprint correctes sur 24, et j’ai obtenu le même score ensuite. Sans cela, je n’aurais fait qu’espérer.
Faut-il vraiment la maintenir ?
La question la plus difficile est celle que j’ai failli laisser de côté. Chaque app que tu livres est un petit abonnement que tu dois continuer à payer avec ton attention, et l’IA a rendu très facile d’en souscrire d’autres.
Avec STRAŦUM, j’ai fait l’autre choix. Je l’ai retiré et j’ai publié la v1 comme implémentation de référence. Le dépôt indique qu’il n’est pas maintenu comme service de production, et son fichier de sécurité liste les alertes que je connais, dont des problèmes de dépendances au moment du build sans correctif disponible, qu’il évalue comme présentant un faible risque pratique. Je trouve que c’est une issue parfaitement honnête. La version malhonnête, c’est une app qui accepte encore des inscriptions alors que personne ne la surveille.
Ce que je ferais lundi
Si tu as livré quelque chose avec l’IA et que des gens l’utilisent, voici la liste par laquelle je commencerais. Rien de tout cela n’a besoin d’être parfait.
- Lance l’audit une fois, aujourd’hui.
npm audit --omit=devoupnpm audit --prod, dans chaque dépôt en ligne. Demande ensuite à ton outil d’IA quels résultats s’appliquent à la façon dont ton app est construite, car ce ne sera pas le cas de tous. - Rends cette vérification automatique. Ajoute-la à la CI pour qu’elle puisse échouer sans que tu aies à y penser. Pour une app que tu touches rarement, ajoute aussi une exécution planifiée, car une vérification lancée seulement à chaque push ne t’aidera pas pendant un mois calme.
- Lis tes permissions, pas seulement tes paquets. Demande-toi ce que quelqu’un peut faire avec ta seule clé publique et sans compte. Puis teste-le sur une copie locale au lieu de le supposer.
- Cherche des secrets dans ton historique. Si une vraie clé a déjà été commitée, révoque-la. Supprimer la ligne ne suffit pas.
- Découvre jusqu’où remontent tes logs avant d’en avoir besoin. C’est ce qui décide si tu pourras un jour répondre à la question de savoir si quelque chose a été détourné.
- Garde un petit jeu d’évaluation pour chaque fonctionnalité d’IA. Même 20 exemples réels avec de bonnes réponses connues te diront si un changement de modèle a empiré les choses.
- Consulte régulièrement les pages d’obsolescence et de tarifs de ton fournisseur d’IA. Mets-le dans ton agenda. Si tu utilises Gemini 3.8 Flash, le 1er janvier est déjà une bonne date pour commencer.
- Décide de garder ou de retirer chaque app. Si tu ne vas pas la surveiller, mets-la hors ligne ou dis-le.
Je cherche encore à savoir quelle part de tout cela peut être confiée à un agent de façon planifiée. Je sais en revanche qu’écrire le plan le 30 octobre n’a rien corrigé.
Si tu construis avec l’IA, quand as-tu vérifié pour la dernière fois quelque chose que tu avais déjà livré, et qu’as-tu trouvé ? J’aimerais vraiment le savoir, surtout si tu as un meilleur détecteur que le mien.