Comment choisir un outil de revue de code IA pour votre équipe

La question n’est plus vraiment « devrait-on essayer la revue de code IA? ». C’est plutôt « laquelle, comment savoir si elle aide vraiment, et comment éviter de noyer l’équipe sous les commentaires de bot? »

Je ne nommerai aucun produit : le marché bouge trop vite. La méthode, elle, tient : savoir ce qu’on achète, tester sur son propre code, mesurer ce qui compte, déployer avec prudence.

Ce que la revue IA fait bien (et moins bien)

Calibrez avant d’évaluer. La revue IA est une deuxième paire d’yeux, pas un remplacement de la première.

Les quatre catégories d’outils

La catégorie vous dit où l’outil vit dans votre flux de travail et ce qu’il peut voir. Plusieurs fournisseurs en chevauchent deux.

Pour la plupart des équipes, le vrai choix se fait entre la 1 (acheter) et la 3 (quasi construire), avec la 2 en complément et la 4 quand la conformité l’impose.

Les critères d’évaluation qui comptent vraiment

À peu près dans l’ordre d’importance.

Le rapport signal-bruit

C’est tout l’enjeu. Un vrai bogue par semaine plus quarante commentaires inutiles, et l’outil est en sourdine en moins d’un mois. Vérifiez la proportion de commentaires qu’un senior jugerait « dignes d’être lus », la possibilité de fixer un seuil de sévérité, et s’il se répète à chaque push.

La conscience du contexte de la base de code

Voit-il seulement le diff, ou tout le repo? Peut-il suivre un appel dans un autre fichier, comprendre votre monorepo, lire vos conventions (un fichier de règles, un AGENTS.md)? Une revue limitée au diff attrape moins et hallucine davantage.

La configurabilité et les règles

La sécurité et la résidence des données

Pour les équipes au Québec et au Canada, vérifiez comment tout ça s’arrime à vos obligations sous la Loi 25 et aux contrats de vos clients. Certains clients interdisent contractuellement d’envoyer leur code à des services d’IA tiers, ce qui vous pousse directement vers la catégorie 4.

Intégration, coût, administration

Vérifiez le support de votre hébergeur git (y compris autogéré), le choix entre vérification requise ou non bloquante, le respect des CODEOWNERS et des protections de branches, et les forks, brouillons ou PR empilées si vous en utilisez.

La tarification peut être par siège, par PR, par token ou forfaitaire. Modélisez-la selon votre volume réel de PR : surveillez les sièges des contributeurs occasionnels, les pointes de tokens sur les grosses PR ou les fichiers générés, et les minutes de CI en plus du modèle. Côté administration, il vous faut la liste des repos activés, des logs de ce qui est envoyé au modèle et des métriques acceptés/rejetés. Sans ça, vous allez les bâtir vous-même.

Le protocole de bake-off de 2 semaines

Les démos ne servent à rien : tous les outils brillent sur un exemple choisi avec soin. Voici le protocole que j’applique avec les équipes.

1. 1

   Jour 0

   Présélection

   Deux ou trois outils, idéalement de catégories différentes. Au-delà de trois, impossible de comparer de façon significative.

2. 2

   Jour 0

   Choisir les repos

   Votre repo produit principal, un repo legacy et un avec un langage ou un framework différent.

3. 3

   Jour 0

   Constituer le jeu de PR

   20 à 30 PR fusionnées récemment, dont quelques-unes où vous savez qu'un bogue est passé. C'est votre vérité terrain.

4. 4

   Jour 0

   Nommer les évaluateurs et configurer équitablement

   Deux ou trois seniors et intermédiaires avec des heures protégées. Même fichier de règles et même seuil pour chaque outil.

5. 5

   Semaine 1

   Rejouer des PR historiques

   Chaque outil dans un bac à sable ou un fork, sans notifier personne. Étiquetez chaque commentaire et vérifiez chaque bogue échappé connu : attrapé ou non?

6. 6

   Semaine 2

   En direct, en mode fantôme

   Activez sur les PR en cours, commentaires cachés aux auteurs ou envoyés dans un canal privé. Les évaluateurs regardent chaque jour la vraie latence et le vrai volume.

Grille d’évaluation

Notez chaque critère de 1 à 5, multipliez par la pondération, additionnez. Ajustez les pondérations avant de commencer, pas après avoir vu les résultats.

Faites noter les évaluateurs indépendamment, puis discutez. Conservez les commentaires étiquetés bruts : quand quelqu’un demandera dans trois mois « pourquoi celui-là? », vous aurez les preuves.

Déployer sans irriter les développeurs

Choisir l’outil, c’est la moitié du travail. Le déploiement décide s’il va survivre.

Le premier mois, encodez aussi en règles les commentaires récurrents de vos réviseurs humains, et excluez les fichiers générés, les lockfiles, les migrations et le code vendored.

Suivez les suggestions acceptées vs rejetées

La métrique qui m’importe le plus : chaque commentaire IA a-t-il mené à un changement, été rejeté ou été ignoré? Si l’outil ne l’expose pas, une convention de réaction pouce en haut / pouce en bas fonctionne étonnamment bien, et vous pouvez récupérer les réactions via l’API de votre hébergeur git.

Révisez les chiffres aux deux semaines environ. Un taux de rejet croissant sur une règle veut dire qu’elle doit être reformulée ou retirée.

Comment la revue IA change le rôle du réviseur humain

C’est la partie que les gestionnaires sous-estiment. La revue IA n’ajoute pas seulement des commentaires; elle déplace l’attention des humains.

Écrivez-le dans vos lignes directrices de revue, sinon rien ne change.

De plus en plus de vos PR seront elles-mêmes écrites avec l’aide de l’IA, ce qui rend la revue humaine plus importante. Le code généré peut avoir l’air plausible tout en étant subtilement faux, et on peut raisonnablement penser qu’un réviseur de la même famille de modèles risque de rater les mêmes choses. C’est un argument pour réviser avec un modèle différent de celui avec lequel votre équipe code.

Quoi faire cette semaine