For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/fr/articles/claude-code-review-ai-checks-human-approv-629ae884.md.
Anthropic affirme que Claude écrit environ 90 % du code de Claude Code. Son équipe d’ingénierie pose la question suivante : comment une équi...
Anthropic affirme que Claude écrit environ 90 % du code de Claude Code. Son équipe d’ingénierie pose la question suivante : comment une équipe doit-elle examiner les modifications lorsque les agents peuvent les produire plus vite que les humains ne peuvent les lire ?
La réponse est un processus par niveaux qui avance les contrôles de routine, utilise les agents pour enquêter sur les bugs et réserve l’attention humaine aux décisions présentant davantage de risques. Anthropic indique que le nombre de pull requests fusionnées a plus que doublé entre juin et septembre, tandis que la proportion nécessitant une réversion a diminué de plus de 40 %.
Ces observations décrivent le processus d’une équipe. Le chiffre de 90 % concerne la création du code, et non la proportion de modifications autorisées à contourner les humains. Une validation humaine obligatoire ne peut pas être fournie par un agent.
L’équipe considère la lecture humaine ligne par ligne comme un moyen de détecter les problèmes, et non comme l’objectif même de la revue. Une meilleure question consiste à déterminer quels modes de défaillance une modification introduit et quels contrôles peuvent les détecter.
Cette approche transforme la revue, qui n’est plus un simple point de contrôle après l’ouverture d’une pull request, mais une activité continue. Les tests, les builds et les revues effectuées par des agents disposant d’un contexte vierge peuvent détecter les problèmes avant qu’un autre ingénieur ne soit interrompu.
Le calcul des coûts inclut à la fois le temps consacré à la revue et celui consacré à la réparation des incidents. Réduire le nombre de validations n’est pas une optimisation réussie si les défaillances sont simplement déplacées en aval. Les taux de réversion et d’incidents servent donc de garde-fous, au même titre que les mesures concernant les commentaires humains, les validations et le temps d’attente.
Le monorepo distinct d’Anthropic est passé d’environ 2 500 modifications fusionnées par jour en mai à plus de 30 000 en septembre. Claude Code possède son propre dépôt ; ces chiffres du monorepo ne doivent pas être attribués directement à sa base de code.
Le rapport fourni met en avant trois étapes d’un processus en sept niveaux. Le compte rendu officiel présente la séquence complète :
Graphique du processus traduit et reproduit dans le rapport fourni ; l’article officiel présente la version originale en anglais.
Avant une pull request, les preuves sont plus importantes qu’un agent affirmant que la tâche est terminée. Une commande de test accompagnée de son résultat, ou une capture d’écran vérifiée par rapport à une maquette, fournit aux réviseurs un élément qu’ils peuvent examiner. Les problèmes récurrents peuvent ensuite être transformés en règles de linting, en compétences ou en instructions de projet concises dans CLAUDE.md et REVIEW.md.
Le réviseur IA se concentre sur les défauts substantiels plutôt que sur des recommandations de style sans limites. Anthropic indique que la proportion de pull requests internes recevant des commentaires substantiels est passée de 16 % à 54 % pendant la phase de préversion de recherche. Les commentaires peuvent signaler séparément les problèmes préexistants, afin d’éviter de laisser entendre que chaque problème a été introduit par la nouvelle modification.
| Niveau de risque | Politique de validation interne décrite par l’équipe |
|---|---|
| Faible | Aucune validation humaine requise une fois les contrôles automatisés applicables réussis, sous réserve des règles de confiance et de chemin. |
| Moyen | Une validation humaine. |
| Élevé | Deux validations humaines. |
Les chemins sensibles et les fichiers de workflow de la CI sont soumis à des exigences supplémentaires. Seuls les auteurs de confiance peuvent bénéficier des parcours allégés ; les autres contributeurs doivent obtenir la validation d’une autre personne. Des classificateurs évaluent la modification au lieu de faire simplement confiance à l’identité de la personne qui la soumet.
Pour les travaux écrits par un agent, la personne qui dirige l’agent est considérée comme un réviseur responsable. La validation d’un agent ne remplace jamais une place réservée à un humain, et les validations peuvent devoir être renouvelées lorsque des commits ultérieurs modifient ce qui a été examiné.
Le parcours interne sans intervention humaine de l’équipe se distingue également du produit public de revue. Le produit publie des résultats ; il ne fournit pas de manière indépendante la validation humaine exigée par les règles d’un dépôt.
Une pull request de l’interface en ligne de commande a connu plus de 50 cycles de revue et de correction au cours d’une nuit avant que son propriétaire ne l’arrête. Un agent auteur corrigeait un commentaire mineur, générait un nouveau commit et déclenchait un réviseur qui trouvait un autre problème.
L’examen rétrospectif de l’équipe a révélé qu’environ 59 % du code signalé à plusieurs reprises existait déjà lors de la première revue. Les passages ultérieurs découvraient souvent davantage d’anciens problèmes plutôt que des défauts nouvellement introduits par chaque correction.
Le processus révisé limite les boucles ordinaires de revue à trois tours avant de demander à l’auteur de reconsidérer son approche. Il restreint également les passages ultérieurs au nouveau diff, masque les problèmes répétés et demande aux auteurs de traiter une catégorie de bugs plutôt qu’un seul cas à la fois.
Decrivez votre idee une fois, et We0 AI peut generer un site vitrine, des pages et un CMS, puis vous aider a attirer clients et trafic apres le lancement.
Une génération de projet complète pour une inscription gratuite
Idéal pour essayer un flux de génération complet et voir rapidement une première ébauche de projet.
| Mesure interne | Avant | Après les changements de convergence |
|---|---|---|
| Passage après un cycle de revue et de correction | 65 % | 78 % |
| Nécessitent au moins cinq tours | 8,9 % | 1,5 % |
| Nombre moyen de revues avant validation | 2,08 | 1,32 |
Mesures internes d’Anthropic, reproduites dans le rapport source.
Trouver davantage de commentaires ne signifie pas nécessairement améliorer une revue. Anthropic teste les réviseurs sur des cas d’incidents confirmés par des experts et sur des modifications connues comme correctes, en suivant à la fois les bugs manqués et les faux positifs nuisibles.
Les humains restent responsables de décider si une fonctionnalité doit intégrer le produit, d’examiner les choix d’architecture ayant des conséquences importantes et d’inspecter les zones à risque telles que la facturation, la CI et le programme de mise à jour. Ils doivent également comprendre ce que les contrôles automatisés peuvent manquer.
L’auteur et l’ingénieur d’astreinte observent le résultat après la fusion. Les indicateurs de fonctionnalité, l’utilisation en interne et les canaux de déploiement progressif facilitent la récupération, mais n’éliminent pas les incidents. Le compte rendu officiel indique que les coupe-circuits automatiques qui renforcent les exigences de validation lorsque les métriques se détériorent restent une amélioration souhaitée.
La responsabilité durable est de prendre en charge la modification déployée. Une implémentation plus rapide facilite l’abandon d’une pull request inutile, mais ne transfère pas à une boucle de revue non contrôlée la décision de ce qui doit être mis en production.
Non, la création du code et la validation sont deux mesures distinctes. Le processus interne adapte la revue humaine au niveau de risque et conserve une validation obligatoire pour certaines modifications et certains chemins.
Le compte rendu officiel indique explicitement que non. Une revue automatisée peut autoriser des travaux à faible risque qui remplissent les conditions, mais elle ne peut pas occuper une place désignée pour une personne.
Les agents enquêtent sur différents défauts potentiels et des vérificateurs distincts évaluent leurs résultats. Cela ajoute un contrôle avant qu’un commentaire ne parvienne à l’auteur, même si l’accord entre les agents ne prouve pas que chaque résultat est correct.
Des boucles auteur-réviseur illimitées peuvent consommer du temps tout en faisant remonter à plusieurs reprises d’anciens problèmes. La limite incite à reconsidérer l’approche au lieu de poursuivre automatiquement le même cycle.
Il s’agit de la réduction relative de la proportion de pull requests Claude Code fusionnées nécessitant une réversion entre juin et septembre. Ce n’est pas l’affirmation que l’ensemble des défauts logiciels a diminué de 40 %.
Commencez par des contrôles vérifiables, des règles de risque explicites et une restauration fiable. Mesurez conjointement l’effort de revue, les incidents et les réversions avant de réduire l’intervention humaine obligatoire.
L’équipe de Claude Code combine une vérification précoce, une revue multi-agents, des contrôles de sécurité, des règles de validation explicites et une récupération rapide. Elle encadre également les boucles de revue afin que les agents ne continuent pas à se solliciter mutuellement sans améliorer la modification.
L’automatisation modifie les personnes qui lisent le diff ; les humains restent responsables de la décision et du résultat.
Partez d’une phrase et obtenez un site complet en quelques minutes.
