Revue de code par IA : garder un contrôle humain sans tout relire

Réduire le nombre de validations humaines d’une revue de code assistée par IA peut sembler être un simple gain de capacité. La décision est plus exigeante : il faut définir quelles modifications peuvent passer sans approbation, comment détecter les erreurs répétées et ce qui se passe lorsque l’explication produite par le modèle est fausse. Le retour publié par InfoQ sur le fonctionnement de l’équipe Claude Code fournit un cas documenté pour examiner ces choix, sans en faire une recette universelle.

InfoQ rapporte que Claude écrit environ 90 % de Claude Code et que l’équipe vise des pull requests fusionnées avec au plus une personne dans la boucle, auteur compris, sans hausse des retours arrière ou des incidents.

Le compte rendu d’InfoQ sur la revue de code chez Anthropic décrit à la fois les règles de validation et des difficultés rencontrées.

Pour une PME, l’intérêt n’est pas de copier ce dispositif : c’est de séparer ses principes de contrôle des conditions propres à une équipe qui développe son propre outil.

Remplacer la connaissance globale par des explications ciblées

L’équipe indique que personne ne conserve une représentation complète de Claude Code en tête. Lorsqu’une personne doit comprendre une partie du dépôt, elle demande au modèle une explication de ce périmètre, fondée sur l’état actuel du code. Ce choix réduit le besoin de mémoriser tout le système, mais il ne supprime pas le besoin de vérifier une explication quand elle sert à décider si un changement est sûr.

La distinction est importante pour une entreprise qui maintient une application métier. Une explication générée peut aider à repérer les fichiers concernés ou à préparer une revue ; elle ne constitue pas, à elle seule, une preuve que le comportement est compris. Si une erreur touche une règle métier, une intégration ou une opération de production, l’équipe doit encore pouvoir examiner le changement et ses effets sans dépendre d’une réponse du même système qui a produit ou revu le code.

Ce point n’oblige pas chaque développeur à connaître l’intégralité d’un logiciel. Il invite plutôt à rendre accessibles les connaissances utiles à une décision : responsabilités d’un module, contrats d’interface, scénarios sensibles et procédures de retour arrière. Une décision d’architecture documentée peut ainsi conserver le raisonnement derrière une frontière ou une règle, tandis que l’explication générée aide à examiner le code présent.

Ce que les itérations de revue révèlent

Le compte rendu décrit une difficulté opérationnelle : les remarques d’un agent ne sont pas toujours des améliorations utiles. Une personne peut écarter rapidement une remarque mineure ; un agent, lui, peut la corriger, créer un nouveau commit et déclencher un autre cycle de revue.

Selon l’article, une pull request liée à l’interface en ligne de commande a dépassé cinquante cycles de revue et de correction au cours d’une nuit avant que son auteur ne l’arrête. L’équipe a constaté que lancer davantage de cycles par défaut aggravait le problème et a plafonné leur nombre.

Le même retour rapporte qu’environ 59 % des éléments signalés par le réviseur étaient déjà présents lors de sa première passe. Autrement dit, les cycles supplémentaires remontaient souvent d’anciens problèmes plutôt que de nouvelles erreurs. C’est une raison concrète de mesurer la valeur d’une boucle de revue, et pas seulement le nombre de remarques traitées.

Un arrêt après plusieurs corrections infructueuses peut aussi servir de signal : il faut alors réexaminer l’hypothèse ou le contexte de l’agent, au lieu de lui demander de répéter la même modification.

Le niveau de risque doit commander l’approbation

Dans le dispositif décrit, un classificateur attribue un niveau de risque à la modification. Les changements documentaires, de texte ou certaines évolutions additives protégées par un indicateur peuvent relever du niveau faible ; des changements comme le cache, le programme de mise à jour ou les instructions système relèvent du niveau moyen et demandent une personne.

Deux limites sont explicites : l’approbation d’un agent ne compte pas comme celle d’une personne et l’auteur ayant demandé le changement compte dans le nombre de réviseurs requis.

Cette organisation montre pourquoi une règle fondée seulement sur l’identité de l’auteur est insuffisante : c’est le type de changement qui détermine le niveau de contrôle. Elle laisse toutefois une question de cadrage. InfoQ rapporte que l’article d’Anthropic ne précise pas le niveau attribué à CLAUDE.md, alors que le réviseur charge ce fichier à chaque revue.

Une modification de documentation peut donc avoir des effets opérationnels si elle change les consignes suivies par un agent. Pour une PME, les fichiers de configuration, les règles d’automatisation et les consignes d’agents méritent une classification explicite plutôt qu’une exemption automatique parce qu’ils ne sont pas du code applicatif.

Cette grille est une proposition de cadrage pour une PME, pas la description des règles d’Anthropic. Le périmètre de chaque niveau dépend du logiciel, des conséquences d’une erreur et de la capacité à revenir en arrière.

Un cas rapporté qui met à l’épreuve l’explication

Le compte rendu d’InfoQ rapporte un exemple concernant la fermeture automatique de tickets dans le dépôt de Claude Code.

Une réponse publiée avec la mention « Generated with Claude Code » expliquait que les tickets étaient fermés après une période sans activité lorsqu’il manquait des informations pour reproduire le problème, et précisait qu’ils n’étaient pas triés uniquement par comptage.

Mais le processus décrit dans le dépôt prévoyait quatorze jours avant le statut obsolète, puis quatorze jours supplémentaires avant la fermeture, avec une exception pour les tickets ayant au moins dix votes positifs.

InfoQ rapporte qu’un commentateur, marcindulak, a relevé plus de 6 000 tickets étiquetés comme contenant des étapes de reproduction qui avaient tout de même été fermés pour inactivité. La réponse suggérait de commenter pour rouvrir un ticket, alors que le processus verrouillait les tickets fermés après sept jours ; le sujet de discussion était lui-même verrouillé.

Ce cas ne mesure pas à lui seul la fiabilité générale d’un modèle. Il montre en revanche qu’une explication cohérente peut mal rendre compte d’un mécanisme réel, et qu’une procédure de correction doit être praticable.

Tester le dispositif avant d’élargir l’autonomie

Une situation fictive aide à préciser le test. Une PME demande à un agent de proposer et de revoir une modification de sa facturation. L’agent produit une correction, puis valide sa propre proposition. Avant de généraliser ce flux, l’équipe vérifie qui a le droit d’approuver le changement, si un test couvre la règle tarifaire concernée et si une personne peut reconstituer le comportement en cas de désaccord. Le scénario n’est pas un résultat observé : il sert à formuler les critères d’acceptation.

• Classer les changements par conséquences métier, réversibilité et sensibilité des données ; documenter les cas qui exigent une validation humaine.
• Limiter les cycles automatiques et fixer une condition d’arrêt en cas d’échecs répétés ou de corrections contradictoires.
• Vérifier un échantillon de changements acceptés sans intervention humaine et suivre les défauts, les retours arrière et les incidents pertinents pour le périmètre.
• Tester la procédure de reprise : retrouver les règles appliquées, identifier le responsable de la décision et rouvrir ou corriger un élément lorsque le processus le permet.

Le coût à comparer ne se limite pas à l’utilisation de l’agent. Il comprend aussi le temps de vérification, les corrections en chaîne et l’effort nécessaire pour enquêter sur une erreur. Il faut relever ces éléments sur un périmètre défini avant de décider d’élargir l’autonomie ; le cas rapporté ne fournit pas de résultat transposable à une PME.

InfoQ indique également que la revue de code de Claude Code est proposée sur les offres Team et Enterprise, et que l’action GitHub de revue de sécurité est publique. Son README avertit qu’elle n’est pas renforcée contre les attaques par injection de prompt et qu’elle doit servir uniquement à examiner des pull requests de confiance. La disponibilité d’un outil ne dispense donc pas de vérifier son périmètre d’emploi ni les conditions de sécurité applicables à ses dépôts.

Pour décider, une PME peut demander un périmètre pilote, les règles de classement du risque, les seuils d’arrêt, les preuves de revue et un bilan des corrections et incidents observés. L’objectif n’est pas de supprimer toute compréhension humaine du code, ni d’imposer une relecture exhaustive : c’est de savoir quelles décisions restent humaines, comment repérer une boucle qui n’apporte plus de valeur et comment reprendre la main lorsqu’une explication ne concorde pas avec le système.