Audite ton dernier projet vibecodé : 30 minutes, trois signaux

À la fin de cet article, tu auras passé un vrai projet (le tien, celui que tu as construit en dialoguant avec une IA) au crible des trois pièges les plus fréquents du vibecoding. Trente minutes, trois passes, et une liste écrite de ce qu’il faut corriger. Pas un audit de sécurité professionnel : le minimum vital que personne ne fait jamais.

J’ai expliqué ailleurs pourquoi le vibecoding n’est pas dangereux à cause des erreurs de l’IA, mais à cause de l’impression qu’on n’a plus besoin de vigilance. Trois signaux y revenaient : un secret qui traîne, une boucle de correction sans fin, du code accepté sans être compris. Voici comment les chercher pour de vrai, dans ton dépôt, aujourd’hui.

Ce qu’il te faut

Un projet que tu as réellement construit avec une IA, idéalement un que tu n’as pas rouvert depuis quelques semaines, c’est là que les surprises dorment. Une session d’IA ouverte dans ce dossier. Et un fichier vide à côté, appelons-le AUDIT.md : tout ce que tu trouves y va, rien ne se corrige de tête.

Passe 1 — Les secrets qui traînent (10 minutes)

C’est la plus rentable, et la seule qui peut te coûter cher si tu la sautes.

Demande d’abord l’inventaire, sans corriger quoi que ce soit :

Parcours ce dépôt et liste toute chaîne qui ressemble à un secret : clé API, mot de passe,
jeton d'accès, chaîne de connexion, identifiant de service. Donne-moi fichier et ligne.
Ne modifie rien, liste seulement.

Le « ne modifie rien » compte : tu veux voir l’ampleur avant que ça se répare tout seul sous tes yeux.

Deuxième endroit, celui qu’on oublie systématiquement : l’historique. Un secret retiré d’un fichier reste dans les versions précédentes :

# macOS, Linux, ou Git Bash sous Windows
git log -p | grep -iE "api[_-]?key|password|secret|token" | head -50

# PowerShell (Windows)
git log -p | Select-String -Pattern "api[_-]?key|password|secret|token" | Select-Object -First 50

Troisième endroit : ta propre conversation. Si tu as collé une clé dans un échange avec l’IA à un moment, elle est dans l’historique de session. Cherche-la.

Pour chaque trouvaille, une seule règle, et elle n’est pas négociable : un secret exposé est un secret mort. Tu le révoques et tu en génères un nouveau. Le déplacer dans un fichier .env ne le désexpose pas : ça empêche seulement la prochaine fuite. Fais les deux :

echo ".env" >> .gitignore

Passe 2 — La boucle de correction (10 minutes)

Celle-ci ne se cherche pas dans le code, elle se cherche dans ta mémoire : y a-t-il un bug que tu as « corrigé » trois fois et qui revient sous une forme légèrement différente ? Un test qui passe puis casse ? Un comportement bizarre que tu as fini par contourner sans comprendre ?

S’il y en a un, ne demande surtout pas un quatrième correctif. Change de mode. Dans Claude Code, appuie sur Shift+Tab jusqu’à voir apparaître le mode plan : l’IA explore alors et te propose un plan écrit, sans toucher à ton code, et tu dois l’approuver avant qu’elle agisse (Claude Code — Interactive mode). Sous Windows, si Shift+Tab ne fait rien dans ton terminal, Alt+M fait le même travail.

Puis pose la question qui casse la boucle :

Ne corrige rien pour l'instant. Explique-moi la cause racine de ce comportement, et
propose-moi deux approches différentes avec leurs inconvénients respectifs.

Une boucle de correction, c’est presque toujours le symptôme traité à la place de la cause. J’ai vécu trois itérations sur un problème d’horodatage dans un projet de traitement vidéo, la correction déplaçant le bug plutôt que le supprimant. Le jour où j’ai demandé la cause au lieu du correctif, ça s’est réglé en une fois.

Note dans ton AUDIT.md la cause identifiée, pas seulement le correctif appliqué. C’est elle qui te servira dans trois semaines.

Passe 3 — Le code que tu n’as jamais relu (10 minutes)

Le plus insidieux, parce qu’il ne fait aucun bruit. Choisis un fichier : le plus important du projet, celui qui gère l’authentification, les paiements, l’accès aux données. Un seul.

Explique-moi ce fichier ligne par ligne, comme si je ne connaissais pas ce langage.
Signale-moi ce qui se passe si une entrée est vide, invalide ou malveillante.

Puis le geste qui compte vraiment, et qui ne demande pas de savoir lire le code : teste le comportement. Entre une valeur vide dans le formulaire. Mets une lettre là où un nombre est attendu. Clique deux fois de suite sur le bouton d’envoi. Si le résultat te surprend, tu viens de trouver quelque chose qu’aucune relecture n’aurait donné.

Ça vaut la peine de prendre ce temps : le sondage 2025 de Stack Overflow, plus de 49 000 réponses dans 177 pays, montre un usage de l’IA à plus de 84 % des répondants pour une confiance envers ce qu’elle produit tombée à 29 %. Beaucoup de code accepté par des gens qui, eux-mêmes, disent ne pas lui faire confiance.

Vérifie que ton audit a servi à quelque chose

Ton AUDIT.md doit contenir trois sections remplies, même si l’une d’elles dit « rien trouvé », c’est un résultat valide et daté.

Puis fais le geste qui transforme un audit ponctuel en réflexe permanent : recopie ce que tu as appris dans le CLAUDE.md du projet. Deux ou trois lignes suffisent.

## Sécurité (appris à l'audit du 2026-07-26)
- Les secrets vont dans `.env` (déjà dans `.gitignore`), jamais en dur, jamais dans le chat.
- Le bug d'horodatage venait du fuseau, pas du format, ne pas re-corriger le format.

La prochaine session lira ça au démarrage. C’est la différence entre avoir fait un audit et avoir un projet qui se souvient de son audit. Le mécanisme complet est dans mon article sur la cascade de fichiers de contexte.

Les erreurs que j’ai faites en auditant

Corriger pendant que j’inventoriais. J’ai perdu le fil de ce qui restait à traiter. Liste d’abord, corrige ensuite : les deux gestes ne se mélangent pas.

Croire qu’un secret retiré du fichier était réglé. L’historique Git le gardait. Ce jour-là, c’est l’IA elle-même qui m’a arrêté avant que ça devienne un vrai problème ; j’en ai fait un article complet. Elle ne rattrape pas tout, tout le temps.

Vouloir tout relire. Trois fichiers plus tard, j’avais abandonné. Un seul fichier relu à fond bat dix fichiers survolés.

Ton audit est fait

Trente minutes, trois passes, un fichier de constats et deux lignes ajoutées à ton contexte projet. C’était la promesse : tu sais maintenant où sont tes secrets, quelle cause se cachait derrière ta boucle, et ce que fait vraiment ton fichier le plus sensible.

Refais-le à chaque fois que tu reprends un projet dormant. C’est plus court la deuxième fois.

En résumé

• Inventorie les secrets sans rien corriger : fichiers, historique Git, ta propre conversation. Un secret exposé se révoque, il ne se déplace pas.
• Casse les boucles de correction avec le mode plan (Shift+Tab, ou Alt+M sous Windows) et une question sur la cause, jamais un énième correctif.
• Relis un fichier à fond plutôt que dix en diagonale, et teste le comportement plutôt que le code.
• Recopie tes constats dans le CLAUDE.md du projet : un audit qui n’est pas écrit est un audit à refaire.

Toi, qu’est-ce que tu as trouvé dans la passe 1 ? Dis-le-moi en commentaire, sans coller la clé, évidemment.

---

Le concept derrière cette mise en pratique tient en 60 secondes sur TikTok : « vibecoder sans se faire piéger ». La vidéo est ici.

Cet article est la mise en pratique de Vibecoder sans se faire piéger. Abonne-toi au blog pour la suite de la série.

Source : Stack Overflow Developer Survey 2025