Qodo compare les LLM pour la revue de code : bugs trouvés, bruit et coût de la vérification

Les modèles de pointe sortent aujourd'hui presque chaque mois, et chacun déplace l'équilibre entre qualité, prix et vitesse. Le 12 octobre 2026, Qodo, qui développe des produits de revue de code et de governance, a publié sur son blog un article intitulé « Which LLM should review your code? ». L'entreprise y compare les modèles selon trois paramètres : le nombre de bugs que le modèle trouve, la quantité de bruit qu'il génère et le coût d'une vérification. L'annonce accessible ne contient ni chiffres finaux ni classement. Nous examinons donc ci-dessous la manière dont la question est posée et ce qui compte dans cette approche.

Pourquoi la revue de code

La revue se prête bien à la comparaison de modèles, car les compromis y apparaissent immédiatement. Un bug manqué arrive en production et coûte cher. Les remarques superflues font perdre du temps aux développeurs et, à la longue, les habituent à ignorer le bot. La facture de tokens augmente avec la taille de la pull request et la profondeur de raisonnement du modèle. Les benchmarks de chat ne donnent pas cette image : ils ne tiennent pas compte du coût d'une erreur et n'impliquent aucune équipe réelle qui doit faire confiance au résultat.

La tâche présente en outre une issue vérifiable. Un bug était dans le diff ou ne l'était pas, et une remarque est soit acceptée par l'auteur, soit rejetée.

Trois axes de comparaison

Qodo place trois grandeurs au centre. La vitesse, mentionnée séparément dans l'annonce, s'y ajoute comme quatrième.

• Rappel (recall) : la part des défauts réels qui ont été trouvés. Une ventilation par type compte ici : erreurs de logique, sécurité, cas limites, violations des règles en vigueur dans l'équipe.
• Bruit (precision) : combien de remarques sont utiles, et combien sont absurdes, doublonnent le linter ou portent sur le style. Un modèle qui trouve plus de bugs mais produit trois fois plus de déchets peut perdre face à un modèle plus prudent.
• Coût de la revue : le prix d'un passage sur une PR typique, en tenant compte du contexte d'entrée et des tokens de raisonnement. Pour une équipe qui traite des centaines de PR par semaine, un écart de prix de plusieurs fois par vérification se transforme vite en poste budgétaire notable.
• Vitesse : le délai avant l'arrivée des commentaires. Une revue qui arrive au bout de 20 minutes s'intègre moins bien au processus que celle qui est prête en deux.

La principale difficulté tient au fait que ces axes tirent dans des directions opposées. Un modèle plus puissant trouve généralement plus de bugs, mais coûte plus cher et travaille plus lentement. Un modèle bon marché et rapide ménage le budget, mais laisse plus souvent passer les erreurs subtiles.

Ce que l'annonce ne dit pas

L'extrait du flux RSS s'arrête à l'introduction. Nous ignorons quels modèles ont participé, sur quel jeu de PR et de bugs le test a été mené, comment un « bug trouvé » a été défini et quels réglages de raisonnement ont été utilisés. Tous ces éléments pèsent lourd sur les conclusions. De plus, Qodo vend un produit de revue de code et a donc intérêt à ce que sa méthodologie paraisse convaincante. Ce n'est pas une raison de se méfier des données, mais c'en est une pour vérifier la méthodologie dans la version complète de l'article, dès que vous arriverez aux tableaux.

Comment choisir un modèle pour son équipe

Le classement d'un tiers donne un point de départ, pas une réponse. En pratique, la marche à suivre est la suivante.

1. Rassemblez 50–100 de vos propres PR closes dont les bugs sont déjà connus : issus de post-mortems, de rollbacks, de commits hotfix. Ce sera votre jeu de test.

2. Faites passer 2–3 modèles avec le même prompt et le même contexte. Comptez les bugs trouvés, la part de remarques acceptées et le coût total.

3. Envisagez un schéma à deux niveaux : un modèle peu coûteux examine toutes les PR, et un modèle puissant n'intervient que sur les changements à risque, par exemple l'authentification, les paiements et les migrations. 4.

Réexaminez votre choix chaque trimestre ou à la sortie d'une version marquante. Si votre pipeline n'est pas lié à un seul modèle, le changement prend quelques heures, pas des semaines. 5.

Suivez la part de remarques rejetées. Si elle augmente, l'équipe commence à ignorer le bot, et cela compte plus que n'importe quelle ligne d'un benchmark.

Le rapport complet de Qodo mérite d'être lu pour sa méthodologie et ses chiffres précis. Mieux vaut toutefois décider quel modèle vérifiera votre code d'après les résultats obtenus sur votre propre dépôt.