Réviser le code IA en toute sécurité

Un assistant ne rédige pas du code qu'il sait correct. Il prédit le prochain token à partir de tout ce qui est dans son contexte, donc il produit du code qui semble être correct pour votre demande. La plupart du temps, cela coïncide avec du code fonctionnel. Le danger réside dans les cas où la sortie plausible et la sortie correcte divergent, et que la sortie semble suffisamment propre pour passer inaperçue.

Imaginez une développeuse, Maya, demandant à un assistant d'ajouter un export paginé à un point de terminaison des commandes. La réponse du chat est confiante et bien structurée. Elle la parcourt, voit une fonction qui semble sensée, et accepte. Deux erreurs n'ont jamais été mentionnées dans le résumé. Le diff a discrètement ajouté import fast_csv from 'fast-csv-stream', un paquet qui n'existe pas dans le registre. Et la pagination utilisait une taille de page par défaut qui chargeait chaque ligne en mémoire sur la dernière page. Le chat disait "pagination efficace ajoutée". Le correctif faisait l'inverse sur l'unique entrée qui comptait.

Ce premier échec n'est pas rare. Une étude de 2025 présentée à USENIX Security a généré 576 000 échantillons de code à travers 16 modèles Python et 14 modèles JavaScript, référant 2,23 millions de paquets, et a trouvé qu'environ un sur cinq (19,7 %) de ces paquets n'existait pas. Les modèles open source hallucinaient à 21,7 %, les modèles commerciaux à 5,2 %, et 58 % de ces hallucinations se reproduisaient sur le même prompt. Les attaquants enregistrent maintenant les noms d'hallucinations les plus courants et publient des logiciels malveillants sous ces noms, une tactique de chaîne d'approvisionnement que l'industrie appelle slopsquatting. Une seule commande d'installation acceptée peut tirer un paquet malveillant dans votre build.

Le deuxième échec pointe vers la réalité plus large de 2026. Les équipes livrent beaucoup plus de code écrit par l'IA qu'avant, mais un humain lit encore à peu près le même nombre de lignes par heure. Une analyse industrielle de millions de pull requests a révélé que le temps de révision des PR augmentait fortement même si le volume de fusion montait, et les développeurs qui se sentaient plus rapides étaient mesurablement plus lents une fois la révision comptée. La contrainte est passée de l'écriture de code à sa révision. Votre levier est la porte de révision, et le mécanisme qui fait fonctionner cette porte est le diff lui-même, que la section suivante décompose.

Réviser du code IA, c'est lire un diff avec un ensemble spécifique de questions, sur un changement suffisamment petit pour que les questions puissent réellement être répondues. Quatre éléments déterminent si la révision est réelle.

• Le diff, pas le résumé. La réponse du chat décrit l'intention. Le diff est ce qui compile et s'exécute. Lisez les lignes modifiées directement, morceau par morceau, car la divergence entre les deux est précisément là où se cache le défaut.
• Les hypothèses. Chaque bloc de code suppose quelque chose à propos de ses entrées, de son état, et de la façon dont il échoue. Un code plausible fait des hypothèses plausibles qui sont fausses aux limites. Demandez-vous pour chaque changement : qu'est-ce que cela suppose, et que se passe-t-il lorsque cette hypothèse échoue ?
• Les dépendances. Un nouvel import est une nouvelle frontière de confiance. Confirmez que chaque paquet existe, est celui que vous vouliez, et n'est pas un nom proche d'une bibliothèque populaire. C'est la vérification de slopsquatting.
• La taille. Un réviseur est efficace jusqu'à quelques centaines de lignes modifiées, puis commence à survoler. La révision n'a lieu que si le changement est suffisamment petit pour être lu par un humain.

La distinction qui décide du succès est mécanique versus intention. Les problèmes mécaniques sont des erreurs de décalage, un contrôle de null manquant, une promesse non gérée, un opérateur de comparaison incorrect. Les problèmes d'intention concernent si le changement résout le bon problème, s'il s'intègre à l'architecture, et s'il n'élargit pas discrètement la portée. Les outils automatisés sont bons pour les mécaniques et éliminent rapidement la couche de routine, ce qui permet à votre attention précieuse de se concentrer sur l'intention. L'ordre inverse, où un humain cherche un point-virgule manquant et un linter est laissé pour juger de l'architecture, gaspille la partie de la révision qu'une personne seule peut faire.

C'est pourquoi le modèle pratique en 2026 est stratifié. Un linter et un scanner s'exécutent d'abord. Un deuxième réviseur IA (Copilot code review, Cursor Bugbot, Claude Code /security-review) s'exécute ensuite et met en évidence les candidats mécaniques et de sécurité. Les équipes rapportent que ce filtre frontal réduit le temps de révision humaine de 30 à 50 %. L'humain lit en dernier, concentré sur les questions qu'un modèle ne peut pas répondre : est-ce le bon changement, ces hypothèses sont-elles sûres, a-t-il touché quelque chose qu'il n'aurait pas dû. Une mise en garde essentielle prépare le scénario travaillé : le deuxième IA est lui-même un brouillon. Copilot code review laisse un "Commentaire", jamais une "Approbation", et ses documents disent clairement qu'il manquera des bogues, des problèmes de sécurité, et la plupart des préoccupations architecturales. C'est une liste de contrôle qui signale les mécaniques, et un humain prend toujours la décision finale.

Revenons à Maya et à l'exportation des commandes, cette fois correctement révisée. La tâche était définie : ajouter une pagination côté serveur à l'exportation des commandes et conserver le format CSV existant. L'assistant a produit un diff de 140 lignes touchant src/api/orders.ts et deux helpers. Voici le passage qu'elle effectue.

1. Lire le comportement à voix haute. Maya énonce ce qu'elle a demandé en une ligne en haut de la vue diff : "paginer l'exportation, mêmes colonnes CSV, rien d'autre ne change." Maintenant, tout changement qui ne sert pas cette ligne est suspect.
2. Ouvrir le diff complet. Elle lit chaque morceau, pas le résumé du chat. Deux des trois fichiers modifiés correspondent à la demande. Le troisième, un nouveau bloc d'importation src/api/orders.ts, ne le fait pas.
3. Vérifier les imports. Le diff a ajouté fast-csv-stream. Elle recherche dans le registre et le fichier lock du projet. Il n'existe pas. La vraie bibliothèque est fast-csv, déjà une dépendance. C'est un nom halluciné, et l'installer aveuglément est un risque de slopsquatting. Elle retire la ligne et pointe le code vers le fast-csv existant.
4. Sonder les hypothèses. Elle demande directement à l'assistant : "quelles sont les hypothèses de cette pagination sur la dernière page et un ensemble de résultats vide ?" La réponse honnête révèle que la taille de page par défaut de 0 signifie non bornée, donc un paramètre de page vide ou absent charge chaque ligne. Elle définit une vraie valeur par défaut et une limite stricte de 1000.
5. Exécuter les cas limites. Elle exécute la build et les tests, puis teste manuellement le résultat vide, la dernière page partielle, et un numéro de page négatif. Le cas de la dernière page échouait avant sa correction et passe après.
6. Committer petit et enregistrer. Le changement est intégré en tant que pull request ciblée bien en dessous de 400 lignes, avec une description qui nomme l'assistant, le prompt, et ce qu'elle a vérifié.

Le avant-après est concret. Avant la révision : une dépendance hallucinée et un chemin hors mémoire sur l'entrée exacte que la fonctionnalité existe pour gérer. Après une lecture de quinze minutes : une vraie dépendance, une requête bornée, trois cas limites couverts, et une pull request que le prochain réviseur peut réellement lire. Le résumé seul aurait caché chacun de ces éléments. Maya passe directement aux pièges ci-dessous, car le même diff offre plusieurs façons de se sentir terminé tout en laissant le travail inachevé.

Chacun de ces pièges donne l'impression de progresser tout en sautant discrètement la partie de la révision qui comptait.

• Réviser le résumé. L'explication du chat semble correcte, donc le diff reste non lu. La solution est une règle stricte : pas d'acceptation sans faire défiler les lignes modifiées, car le résumé est la revendication de l'assistant et le diff est la preuve.
• Passer la vérification des imports. Un nouveau nom de paquet semble ordinaire, donc il est installé. Avec un échantillon sur cinq nommant un paquet fantôme, traitez chaque nouvelle dépendance comme non vérifiée jusqu'à ce que vous la confirmiez sur le registre et confirmiez qu'il s'agit de la bibliothèque que vous vouliez, pas d'un sosie.
• Le diff trop grand pour être lu. Un changement IA de 900 lignes ne peut pas obtenir une vraie révision, donc le réviseur survole et approuve. La solution est de limiter les pull requests, de les garder sous 400 lignes, et de diviser un grand changement généré en étapes révisables avant que quiconque ne le regarde.
• Lire pour "semble raisonnable". Un code plausible passe cette barre par conception. Remplacez-le par "quelles hypothèses cela fait-il et où échouent-elles ?", ce qui force les cas de liste vide, null, et de demande en double à apparaître.
• Faire confiance au deuxième IA comme approbation. Un passage propre de Copilot ou Bugbot semble être une approbation. C'est une liste de contrôle des mécaniques. Bugbot lui-même est documenté pour trouver de vrais bogues même après l'approbation humaine, ce qui fonctionne dans les deux sens : les outils attrapent des choses que vous manquez, et vous attrapez l'intention et l'architecture qu'ils manquent.

Deux véritables cas limites se situent au-delà des règles simples. Le grand diff que vous ne pouvez pas diviser. Une migration générée ou un renommage mécanique peut légitimement toucher des centaines de lignes. Ici, la démarche est de réviser par catégorie plutôt que ligne par ligne : confirmer que la transformation est uniforme, vérifier un échantillon représentatif des changements, et s'appuyer sur une suite de tests qui prouve que le comportement est maintenu, plutôt que de prétendre lire chaque modification identique.

L'agent non déterministe. Lorsqu'un agent a exécuté une boucle de modifications et de commandes, le diff peut ne pas être reproductible à partir du même prompt, et l'assistant ne peut pas vous dire de manière fiable pourquoi il a fait un choix donné. Ne lui demandez pas de justifier l'intention après coup et faites confiance à la réponse. Révisez l'artefact qui existe, le diff et les résultats des tests, et traitez la narration de l'agent comme un indice à vérifier plutôt qu'un enregistrement fiable. Ces pressions s'intensifient une fois qu'un changement quitte votre machine et rencontre une équipe, c'est là que l'échelle entre en jeu.

Un développeur peut garder un standard de révision en tête. Dès qu'une équipe génère du code IA dans un dépôt partagé, le standard doit vivre dans les artefacts et les habitudes, sinon le volume de révision l'enterre. Une responsable, Priya, est en charge de cette vision, et son travail est de faire en sorte que la porte survive au contact de trente pull requests par jour.

Le premier artefact durable est un modèle de PR qui enregistre le rôle de l'assistant. Chaque description nomme quel outil a généré le changement, le prompt ou le plan derrière, les nouvelles dépendances (idéalement aucune), et ce que l'auteur a vérifié. Cela transforme la révision d'une conjecture en une vérification d'une revendication, et permet à la personne suivante de répéter le passage au lieu de commencer à froid. Cela rend également les changements rédigés par l'IA visibles dans l'historique, ce qui est important lorsqu'un défaut est retracé des mois plus tard.

Le deuxième est une discipline de taille partagée. Garder les pull requests sous 400 lignes est une politique d'équipe, pas une habitude personnelle, car la recherche est cohérente : la densité de défauts trouvée par ligne chute fortement une fois qu'une révision dépasse quelques centaines de lignes, et les petits changements fusionnent nettement plus rapidement. Associer ce plafond à un pipeline stratifié (un linter, un scanner, puis un deuxième réviseur IA pour les mécaniques) garde l'attention humaine sur l'intention, où l'économie de temps de 30 à 50 % provient de la mise en place du filtre IA en premier et de la personne en dernier.

Le troisième est une liste de contrôle de révision partagée que tout le monde applique de la même manière : lire le diff, pas le résumé, vérifier chaque nouvel import, nommer les hypothèses, signaler les changements non demandés, et confirmer que les cas limites ont été testés. Une liste de contrôle d'équipe rend la révision répétable entre les personnes et résiliente à une journée chargée, comme le présente la AI Code Review Checklist sur ce site.

Le principe durable, quelle que soit la taille de l'équipe, est constant : le code écrit par l'IA est une proposition, et une lecture humaine du diff réel est ce qui transforme une proposition en code engagé que vous êtes prêt à assumer. Commencez par une petite chose lors de votre prochain changement IA. Ouvrez le diff complet, confirmez que chaque nouvel import est réel, et gardez la pull request suffisamment petite pour que la personne après vous puisse faire de même.