La revue de code est souvent lente et inégale : les diffs s’accumulent dans les files d’attente, et les retours dépendent des personnes connectées.

La revue de code par IA n’est utile que lorsque le relecteur dispose d’un véritable contexte de la base de code.

La revue de code par IA est plus efficace lorsque le relecteur a déjà accès au dépôt complet, aux changements récents, aux tests et à un ensemble de règles clair. Dans ce contexte, elle détecte des problèmes qu’un bot autonome limité à un seul diff ne verra jamais. La revue est particulièrement utile lorsqu’elle s’inscrit dans le même système que celui qui a produit la modification.

#Ce qui a changé dans la revue de code

Les agents de codage n’ont pas inventé les longues pull requests, mais ils ont fait voler en éclats, plus vite, les anciens équilibres de la revue.

Les développeurs qui travaillent avec des agents de codage livrent des changements plus volumineux. Les données issues de millions de sessions Cursor indiquent que le nombre de lignes ajoutées par PR (p75) a augmenté d’environ 2,5× sur un an. Les méga PR de plus de 1 000 lignes modifiées représentent une part croissante des fusions, avec une nette accélération en janvier 2026, à mesure que les agents et les modèles se sont améliorés. Les sessions Agent sont également devenues plus approfondies : le nombre moyen d’appels d’outils par session a augmenté d’environ 30 % sur une récente période de deux mois. Une plus grande part du code rédigé par IA est conservée. La part des lignes IA acceptées toujours présentes après 60 minutes est passée d’environ 76 % à 81 % depuis le début de 2026. Les changements générés par Agent qui aboutissent à des commits sans étape distincte d’acceptation manuelle du diff ont augmenté de plus de 5× sur cette période.

La capacité de revue humaine n’a pas suivi cette évolution. Les recommandations classiques sur la revue par les pairs considèrent depuis longtemps que quelques centaines de lignes lues avec attention constituent la plage dans laquelle la qualité se maintient.

La revue de code par IA permet de maintenir un garde-fou de qualité lorsque le volume de changements dépasse le nombre d’ingénieurs seniors capables de lire chaque diff.

Une part croissante du code examiné a été écrite avec une assistance IA. Les humains sont doués pour repérer « ce n’est pas comme ça qu’on construit ici ». Ils le sont moins face à un patch d’agent volumineux, crédible et globalement correct, lorsqu’il faut déceler la subtile rupture, et c’est là qu’un relecteur disposant d’un vrai contexte du dépôt aide. Écrire un changement d’ampleur et le vérifier sont deux compétences différentes, et la revue est ce contrôle.

#Questions avant de lancer une revue de code par IA

Si vous évaluez des outils de revue de code par IA, commencez par vous familiariser avec ces notions.

#Qu’est-ce que la revue de code par IA ?

La revue de code par IA est un logiciel qui lit une modification (généralement une pull request, parfois un diff local) et signale des bugs, des régressions et des risques avant la fusion. Les versions les plus utiles analysent bien plus que les seules lignes modifiées qu’elles ont sous les yeux. Elles prennent aussi en compte les fichiers associés, les tests, la config et les règles d’équipe. Les versions médiocres se contentent de reformuler le diff en prose ou de ressasser des remarques sur les commentaires et le nommage.

#En quoi est-ce différent du linting ou de la CI ?

Les linters et les vérificateurs de types formalisent des règles que vous savez déjà écrire. La CI exécute les vérifications que vous avez automatisées. La revue par IA sert à repérer tout le reste : erreurs de logique, conditions de concurrence, erreurs d’authentification, régressions quelques dossiers plus loin, et décalages entre la documentation et le comportement. Elle recoupe la CI. Elle ne la remplace pas.

#La revue de code par IA remplace-t-elle la revue humaine ?

Non. Elle change surtout la façon dont les humains utilisent leur temps. Environ la moitié seulement des commentaires issus d’une revue humaine aboutissent de toute façon à une modification dans la même PR. Les bonnes pratiques de revue incluent des remarques à corriger plus tard et du contexte donné à titre informatif. L’objectif est d’écarter les bugs détectés avec un haut niveau de confiance et traitables par la machine, afin que les équipes puissent se concentrer sur l’architecture, le risque produit et les connaissances tacites que le modèle n’a pas encore.

#Qu’est-ce qui rend la revue par IA bruyante ?

Le bruit vient de commentaires que personne n’a envie de recevoir d’un bot. Les remarques insistantes sur le style, les vagues notes « ajoutez des tests » sans test défaillant et les suggestions de réécriture qui ne repèrent aucun bug apprennent toutes aux gens à ignorer la revue. Distinguez ce que le modèle peut repérer de ce que les gens veulent réellement qu’il signale. La revue de code par IA doit signaler de vrais bugs, des commits accidentels, des problèmes de performance et de sécurité, ainsi que les endroits où la documentation et le code ne concordent pas. Lorsque Graphite a cadré ses revues par IA sur ce recoupement, environ 52 % des commentaires ont conduit à une modification du code (à peu près le même taux que pour les relecteurs humains), avec moins de 4 % de votes négatifs.

#Que devrions-nous mesurer ?

Taux de résolution : lors de la fusion, l’issue signalée a-t-elle réellement été corrigée dans le code final ? Le taux de résolution est plus important que le volume de commentaires.

C’est aussi la métrique que nous avons utilisée pour améliorer Bugbot : le taux de résolution est passé de 52 % à plus de 70 % au fil de 40 expérimentations, les bugs signalés à chaque exécution de 0,4 à 0,7, et les bugs résolus par PR d’environ 0,2 à environ 0,5, sur plus de deux millions de PR examinées par mois. En mai 2026, le taux de résolution avec l’effort par défaut avait atteint environ 80 % de bugs résolus lors de la fusion. Si votre taux de résolution baisse alors que le volume de commentaires augmente, le bot génère du bruit.

Le tableau de bord de Bugbot affiche l’évolution du taux de résolution pour chaque dépôt, ainsi que le volume d’issues détectées et corrigées, afin de vous permettre de vérifier si les revues détectent de vrais problèmes et si ceux-ci sont résolus avant d’élargir le périmètre des commentaires du bot.

#Quand lancer la revue : en local, sur la PR, ou les deux ?

Les deux, mais pas pour les mêmes rôles. La revue locale (après une tâche d’agent, avant le push) détecte les issues tant que le contexte est encore frais et que le fil n’existe pas encore. La revue de PR constitue le cadre de l’équipe : règles partagées, historique partagé, point de contrôle commun avant la fusion. Les vérifications axées sur la sécurité peuvent se faire d’un côté comme de l’autre, selon votre façon de livrer.

#Avons-nous besoin que l’outil de revue soit intégré au même produit que l’agent ?

Vous pouvez acheter un outil de revue autonome. Beaucoup d’équipes le font. Le coût, ce sont les changements de contexte et une vue plus limitée de la façon dont le code a été produit. Lorsque la revue s’exécute dans le même système que celui qui a écrit la modification, il connaît déjà les fichiers ouverts, la structure du dépôt et les règles que vous maintenez à côté du code. Les correctifs peuvent renvoyer directement vers l’éditeur ou lancer un agent avec le problème déjà chargé. Cette boucle est difficile à reproduire avec une solution greffée.

#Comment exécuter une revue de code par IA dans Cursor

Avec Cursor, commencez par une revue locale dans l’éditeur, utilisez ensuite Bugbot sur la pull request, puis corrigez les problèmes dans la même chaîne d’outils.

En local. Après le travail de l’agent, exécutez Agent Review. Vous pouvez saisir /agent-review dans le champ de saisie de l’agent, l’exécuter depuis l’onglet Source Control pour comparer les modifications locales à votre branche principale, ou activer les revues automatiques après chaque commit. Avant d’effectuer un push, vous pouvez également exécuter Bugbot ou un Security Agent localement avec les skills /review-bugbot et /review-security. Vous pouvez ainsi corriger les problèmes évidents tant que la session conserve son contexte.

Sur la PR. Bugbot examine les pull requests sur GitHub, GitLab et Bitbucket. Définissez les invariants de l’équipe dans .cursor/BUGBOT.md, ainsi que les règles d’équipe et du dépôt. Les règles apprises (@cursor remember) intègrent les retours dans les exécutions futures. Surveillez le taux de résolution dans Bugbot Automations avant d’élargir les catégories de commentaires.

Boucle de correction. Les résultats apparaissent sur la PR avec des liens vers Cursor (Fix in Cursor et Fix in Web). Bugbot Autofix peut lancer un Cloud Agent pour proposer des correctifs. Pour la sécurité, les Security Agents de Cursor couvrent les deux cas d’usage : Security Reviewer vérifie les PR avant la fusion, et Vulnerability Scanner analyse la base de code au repos.

Démarrer. La documentation couvre toute la configuration : connexion de votre dépôt, choix des dépôts et des personnes qui déclenchent les revues, niveau d’effort et .cursor/BUGBOT.md. Suivez le guide sur cursor.com/docs/bugbot.

#Automatisez le routage et la validation

La détection des bugs ne couvre pas l'ensemble du travail de revue. Deux automatisations Cursor prennent en charge les tâches mécaniques.

Approuvez automatiquement les modifications à faible risque. Les Approval Agents évaluent le risque de chaque pull request et approuvent celles qui atteignent le seuil que vous définissez. Une retouche de texte ou une mise à jour de configuration peut être fusionnée sans attendre l'intervention d'une personne. Toute modification dépassant votre seuil de risque est mise en attente. Les résultats de Bugbot et de Security Agent alimentent cette décision afin qu'une modification risquée ne soit pas approuvée sans contrôle.

Orientez vers les bons réviseurs. Lorsqu'une PR nécessite l'intervention d'une personne, les Approval Agents attribuent des réviseurs selon la partie de la base de code concernée, à l'aide de règles de routage par zone que vous définissez. La modification est envoyée à l'équipe responsable de ce code plutôt que dans une file d'attente partagée.

#Gardez la revue près du code

La revue de code par IA permet aux équipes de maintenir un garde-fou de qualité, tandis que les agents augmentent l’ampleur et la vitesse des changements. Les approches qui fonctionnent s’appuient sur le contexte du dépôt, une politique de commentaires stricte et une métrique qui suit si les résultats relevés sont effectivement corrigés.

La revue doit se faire au plus près de l’endroit où le code a été produit, avec les mêmes règles et le même circuit de correction. Activez Bugbot sur un dépôt très actif, observez le taux de résolution dans Bugbot Automations pendant une semaine, puis décidez seulement à ce moment-là quelles catégories méritent plus de volume.