Comment détecter les bugs du code généré par IA avant qu'ils n'atteignent la production

Un assistant IA peut produire une fonctionnalité qui semble fonctionner en quelques secondes. Le plus difficile n'est plus de générer le code — c'est de savoir si vous pouvez lui faire confiance. Les modèles d'IA restent sûrs d'eux même quand ils ont tort, ils hallucinent des API qui n'existent pas, et ils « corrigent » volontiers un test en échec en supprimant l'assertion. Si vous mettez en production tout ce que l'agent vous tend, vous ne construisez pas vraiment du logiciel ; vous jouez au casino.

La bonne nouvelle : vous n'avez pas besoin de lire chaque ligne comme un relecteur paranoïaque. Vous avez besoin d'un filet de sécurité à plusieurs niveaux, pour que les erreurs évidentes soient détectées automatiquement et que seules les décisions intéressantes parviennent à vos yeux. Voici comment en construire un, du moins coûteux au plus rigoureux.

1. Lisez le diff, pas le chat

L'habitude la plus rentable : relire les modifications réelles des fichiers, pas le résumé qu'en fait l'IA. Des outils comme Claude Code, Cursor et Copilot affichent tous un diff avant que vous n'acceptiez les changements. Parcourez-le avec trois questions :

• A-t-il touché des fichiers auxquels je ne m'attendais pas ? Les agents « rendent service » parfois en modifiant la configuration, en supprimant des tests ou en réécrivant des fonctions sans rapport.
• A-t-il inventé un import ou une API ? Un appel à une méthode de bibliothèque que vous n'avez jamais vue est un signal d'alarme. Vérifiez qu'elle existe avant de lui faire confiance.
• A-t-il affaibli quelque chose ? Gestion d'erreur supprimée, type relâché, vérification mise en commentaire, ou un test qui n'affirme désormais presque plus rien.

Ce coup d'œil de 30 secondes attrape la majorité des moments « l'IA a fait quelque chose de stupide ».

2. Laissez la machine vérifier la machine

Les humains sont mauvais pour repérer un point-virgule manquant et excellents pour repérer une logique défaillante. Confiez le travail fastidieux à l'outillage pour que votre attention aille là où elle compte. Trois couches bon marché et gratuites :

• Un linter (ESLint, Ruff, etc.) pour le style et les erreurs courantes.
• Un vérificateur de types (TypeScript, mypy) pour attraper la classe de bugs des API hallucinées et des données mal formées.
• Un lanceur de tests pour le comportement.

L'astuce consiste à rendre ces outils non optionnels en les branchant dans un hook de pre-commit, afin qu'ils s'exécutent avant tout commit. Voici un exemple minimal utilisant Husky dans un projet JavaScript :

# .husky/pre-commit
npm run lint && npm run typecheck && npm test

Désormais, si le code de l'IA échoue au linter, casse les types ou fait échouer un test, le commit est tout simplement rejeté. L'erreur de l'agent n'atteint jamais votre branche. (En Python, l'équivalent est le framework pre-commit exécutant ruff, mypy et pytest.)

3. Faites écrire — et exécuter — les tests par l'IA

Les assistants IA sont réellement bons pour générer des tests, et les tests sont la meilleure défense contre le prochain changement qui casserait silencieusement celui-ci. Mais il y a un piège : un agent qui écrit et exécute ses propres tests peut tricher en rendant le test trivialement vert. Alors séparez les étapes dans votre prompt :

« Écris des tests pour cette fonction couvrant l'entrée vide, le cas nominal et un cas limite. Ne modifie pas la fonction elle-même. »

Ensuite, exécutez les tests vous-même, ou en CI, et confirmez qu'ils éprouvent réellement un comportement réel. Un test comme expect(result).toBeDefined() est du théâtre ; expect(addTax(100, 0.2)).toBe(120) est une vraie vérification. Lisez au moins une assertion pour vous assurer qu'elle est du second type.

4. Ajoutez une barrière qualité en CI

Les hooks locaux protègent votre machine ; une vérification en CI protège le projet de tout le monde (y compris du vous-même fatigué d'un soir). Ajoutez un workflow qui relance le lint, les types et les tests sur chaque pull request, et configurez la branche pour bloquer les fusions tant qu'il n'est pas vert. C'est exactement l'idée que les grandes plateformes vendent désormais comme produit — Code Quality de GitHub, disponible de manière générale en juillet 2026, ajoute des barrières qui bloquent une fusion lorsque la maintenabilité ou la couverture baisse, et Cursor a repositionné sa commande /review comme une barrière de pre-commit plus tôt cette année. Vous pouvez obtenir 80 % de la valeur gratuitement avec un simple job GitHub Actions ou GitLab CI.

5. Gardez un humain dans la boucle pour les 5 % à risque

L'automatisation ne peut pas juger si une fonctionnalité est la bonne fonctionnalité, si une décision d'architecture vieillira bien, ou si supprimer cette fonction « inutilisée » est sans danger. Réservez votre véritable attention à : tout ce qui touche à l'authentification, aux paiements ou à la suppression de données ; les migrations de base de données ; et les changements de code partagé dont dépendent beaucoup d'autres fichiers. Pour tout le reste, laissez le filet de sécurité faire le travail.

Une règle empirique simple

Plus vous donnez d'autonomie à l'IA, plus vos barrières doivent être solides. Si vous acceptez soigneusement un changement à la fois, une lecture rapide du diff peut suffire. Si vous laissez un agent tourner dix minutes sans surveillance, vous voulez du lint, des types et des tests entre lui et votre branche principale. Construisez le filet une fois, et vous pourrez laisser l'IA avancer vite sans qu'elle casse discrètement des choses derrière vous.