Liste de vérification pour la révision de code IA

Un assistant ne rédige pas du code qu'il sait correct. Il prédit un code plausible pour votre demande, et plausible signifie exactement un code qui semble propre mais qui échoue sur l'entrée qui compte. Le résumé du chat décrit l'intention. Le diff est ce qui compile et s'exécute. Cette liste de vérification existe pour combler l'écart entre les deux, un changement à la fois, avant que le changement ne devienne quelque chose que vous devez déboguer en production.

Prenons Maya, qui ajoute un export paginé à un service interne de commandes. L'assistant renvoie une réponse confiante et bien structurée. Sans passer en revue, elle le survole, voit une fonction sensée et accepte. Deux défauts passent inaperçus que le résumé ne mentionne jamais. Le diff a discrètement ajouté import fast-csv-stream, un paquet qui n'existe pas, alors que la vraie bibliothèque fast-csv était déjà installée. Et la pagination était par défaut sans limite de taille de page, donc un paramètre de page vide ou absent chargeait chaque ligne en mémoire sur l'entrée exacte que la fonctionnalité est censée gérer. Le résumé disait "pagination efficace ajoutée". Le correctif a fait le contraire.

L'échec de dépendance n'est pas une exception. Une étude de 2025 présentée à USENIX Security a généré 576 000 échantillons de code à travers seize modèles et a constaté qu'environ un sur cinq (19,7 %) des 2,23 millions de paquets référencés n'existe pas. Pire pour les défenseurs, les hallucinations sont prévisibles : lorsque les chercheurs ont relancé des prompts identiques, 58 % des noms hallucinés sont réapparus lors de plus d'une exécution, et 43 % sont apparus à chaque exécution. Les attaquants enregistrent les noms fantômes les plus courants et publient des logiciels malveillants sous ces noms, une tactique de chaîne d'approvisionnement que l'industrie appelle slopsquatting. Une commande d'installation acceptée peut tirer un paquet malveillant directement dans votre build. L'élément Imports vérifiés est la ligne de défense, et il est non négociable à chaque changement.

L'échec de taille pointe vers la réalité de 2026. Les équipes génèrent maintenant beaucoup plus de code qu'avant, mais un humain lit à peu près le même nombre de lignes par heure. L'analyse de longue date de SmartBear sur les revues de Cisco a révélé que la densité de défauts (défauts trouvés par ligne) chute fortement une fois qu'une revue dépasse 400 lignes, et les données de Google montrent que le temps médian de revue double pour chaque tranche supplémentaire de 100 lignes modifiées. La contrainte est passée de l'écriture de code à sa révision. Une liste de vérification appliquée à un petit diff est un levier; la même liste agitée devant une demande de tirage de 900 lignes est du théâtre. C'est pourquoi Taille révisable se trouve près de la fin comme un obstacle, pas une suggestion.

Chaque élément est une affirmation que vous cochez honnêtement ou non. La discipline consiste à rendre chaque coche observable, liée à quelque chose que vous avez vu dans le diff ou exécuté dans le terminal, plutôt qu'à un sentiment que le code semble correct. La différence entre une véritable revue et un coup de tampon se manifeste élément par élément.

• Imports vérifiés. Une coche faible lit "les dépendances semblent standard". Une entrée forte lit "le diff a ajouté fast-csv-stream; il n'est pas dans le registre et la vraie bibliothèque est fast-csv, déjà installée, donc j'ai supprimé la ligne et réorienté le code." La version faible fait confiance au nom; la version forte a vérifié le registre et le fichier de verrouillage.
• Hypothèses nommées. Une coche faible est "la logique semble correcte". Une entrée forte est "la taille de page par défaut est 0, ce qui signifie sans limite, donc un paramètre de page vide charge chaque ligne; j'ai défini une valeur par défaut et une limite stricte de 1000 et ajouté les cas de page vide et de dernière page." Remarquez que la version forte nomme l'hypothèse spécifique et l'entrée qui la brise. "Semble raisonnable" est une barre que le code plausible passe par conception, donc remplacez-la par "qu'est-ce que cela suppose, et où cette hypothèse échoue-t-elle?"
• Portée honnête. Une coche faible est "rien ne semble incorrect". Une entrée forte est "deux des trois fichiers modifiés correspondent à la demande; le troisième était un nouveau bloc d'importation que je n'avais pas demandé, maintenant supprimé." Une revue qui ne recherche pas activement un changement non demandé ne le trouvera pas, car un élargissement de portée plausible ressemble à de l'aide.
• Sécurité vérifiée. Une coche faible est "l'authentification est gérée". Une entrée forte est "la route d'exportation est protégée par authentification, les paramètres de page sont convertis en entiers, et aucune chaîne contrôlée par l'utilisateur n'atteint la requête." Nommez la vérification, pas l'espoir.

Travaillez la liste dans l'ordre, car l'ordre fait le travail. Vous énoncez d'abord le comportement prévu pour que chaque élément ultérieur ait quelque chose à mesurer. Vous lisez le diff complet avant de juger tout changement individuel. Vous vérifiez les imports avant de lancer quoi que ce soit, car le coût d'une mauvaise installation est payé dès que vous la tapez. Vous décidez de la taille avant d'investir une lecture approfondie, pour ne pas perdre vingt minutes dans un changement de 900 lignes qui aurait dû être trois demandes de tirage. L'exemple ci-dessus montre la forme réaliste : la plupart des éléments sont cochés, quelques-uns ne le sont pas, et ceux non cochés sont précisément le travail que la revue a trouvé. Une liste de vérification où chaque case est pré-cochée n'a rien révisé.

Une mise en garde sur la ligne deuxième IA. Exécuter d'abord la revue de code Copilot, Cursor Bugbot ou Claude Code /security-review est vraiment utile : Bugbot effectue des passes parallèles axées sur les bogues de logique et de sécurité tout en ignorant le style, et le réviseur de Claude envoie plusieurs agents spécialisés. Les équipes rapportent qu'un pipeline en couches réduit le temps de revue humaine de manière notable en éliminant les problèmes mécaniques avant qu'une personne ne regarde. Le piège est de lire un passage propre de la deuxième IA comme une approbation. La revue de code Copilot laisse un "Commentaire", jamais une "Approbation", reste silencieuse sur environ 29 % des revues, et sa propre documentation note qu'elle peut manquer les injections SQL, XSS, et toute décision architecturale. Cochez la case uniquement pour enregistrer que la couche mécanique a été exécutée, puis prenez vous-même la décision de conserver, corriger ou diviser.

La plupart des façons dont cette liste de vérification échoue donnent l'impression de progresser tout en sautant la partie qui comptait.

• Revoir le résumé. L'explication du chat semble correcte, donc le diff n'est pas lu et chaque élément ultérieur est coché par foi. La solution est la règle stricte derrière Lecture complète du diff : pas de coche sans faire défiler les lignes modifiées.
• Passer la vérification des imports sur un changement "ennuyeux". Un nouveau nom de paquet semble ordinaire, donc il est installé sans vérification. Avec un échantillon sur cinq nommant un paquet fantôme, les changements ennuyeux sont exactement là où le slopsquatting atterrit.
• Le diff trop grand pour être lu. Un changement généré de 900 lignes ne peut pas faire l'objet d'une véritable revue, donc le réviseur survole et approuve. Traitez Taille révisable comme un panneau d'arrêt : divisez d'abord, puis révisez les morceaux.
• Pré-cocher toute la liste. Une liste de vérification où rien n'est jamais décoché est un rituel. Les éléments non cochés sont le livrable; si une véritable revue n'en trouve jamais un, vous lisez trop légèrement.
• Faire confiance au bot comme approbation. Un passage vert de Bugbot ou Copilot est une liste de vérification des mécaniques, et des cas documentés montrent que ces outils signalent de vrais bogues même après qu'un humain a approuvé. Cela fonctionne dans les deux sens : appuyez-vous sur eux pour les mécaniques, et gardez l'intention et l'architecture pour l'humain.

Deux cas limites honnêtes 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, vous révisez par catégorie plutôt que ligne par ligne : confirmez que la transformation est uniforme, vérifiez par échantillonnage un échantillon représentatif, et appuyez-vous sur une suite de tests qui prouve que le comportement est maintenu, puis cochez Taille révisable avec cette approche notée. L'agent non déterministe. Lorsqu'un agent a exécuté une boucle de modifications et de commandes, le même prompt peut ne pas reproduire le diff, et l'agent ne peut pas expliquer de manière fiable pourquoi il a choisi un chemin donné. 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 à faire confiance.

En équipe, la norme d'une personne ne survit pas à trente demandes de tirage par jour, donc la liste de vérification doit vivre dans les artefacts. Adoptez un modèle de demande de tirage qui enregistre l'assistant, le prompt ou le plan, les nouvelles dépendances (idéalement aucune), et ce que l'auteur a vérifié, ce qui transforme chaque revue en vérification d'une affirmation plutôt qu'un départ à froid. Faites du plafond de taille une politique partagée, pas une habitude personnelle, puisque les données sur la densité des défauts et la vitesse de revue ne rapportent que lorsque tout le monde garde les changements petits. Et appliquez la même liste de vérification à travers l'équipe pour qu'une journée chargée ne baisse pas discrètement la barre. Pour la raison derrière chaque élément, envoyez les gens au guide Revoir le code IA en toute sécurité; pour les étapes qui précèdent et suivent cette barrière, consultez le Brief de session de codage IA et Tester le code généré par IA. Ensuite, commencez petit sur votre prochain vrai changement : ouvrez le diff complet, confirmez que chaque nouvel import est réel, et gardez la demande de tirage suffisamment petite pour que la prochaine personne puisse exécuter cette liste exacte.