Vous ne payez pas pour des revues de code. Vous payez pour des chaises.

Faites la division sur votre facture de revue de code IA. Pas le prix affiché, la vraie division : ce que vous avez payé le mois dernier, divisé par le nombre de pull requests qu’elle a examinées. Je l’ai fait pour notre équipe et le nombre était tellement pire que celui de la page de tarification que j’ai cru avoir fait une erreur.

Je n’avais pas fait d’erreur. J’avais simplement acheté le produit comme on me le vendait, et non comme nous l’utilisions.

Voici la thèse, et tout ce qui suit en est la preuve. La revue de code IA est vendue par développeur et consommée par pull request. Ces deux nombres n’ont rien à voir l’un avec l’autre, et l’écart entre eux est là où va votre argent. Par ailleurs, et c’est pire, l’outil pour lequel nous payions a lu une diff contenant six véritables défauts et n’en a trouvé qu’un.

Nous l’avons remplacé par quelque chose que nous avons construit. Je vais vous montrer les reçus pour les deux affirmations, y compris les parties qui nous font paraître moins bien.

Six défauts sont entrés. Un seul est ressorti.

La pull request était un refactor de la sauvegarde automatique dans notre plateforme. Ordinaire, de taille moyenne, le genre qui est ouvert un mardi et dont personne ne perd le sommeil. Greptile l’a examinée, a laissé deux commentaires, et est passé à autre chose.

Ensuite, un de nos ingénieurs a parcouru la diff à la main et l’a évaluée correctement, notant chaque défaut réel sans regarder quel outil avait signalé quoi. Six défauts. Quatre d’entre eux étaient de niveau P1, le genre qui corrompt les données utilisateur plutôt que d’ennuyer quelqu’un.

La sauvegarde automatique se réarmait indéfiniment après la normalisation des valeurs. Une sauvegarde échouée réessayait en boucle infinie. La sauvegarde automatique écrasait ce que l’utilisateur tapait activement dans un autre onglet. Une promesse de sauvegarde était jetée sans être gérée. Quitter la page abandonnait tout ce qui était en attente. Le bouton de sauvegarde ne s’affichait que lorsque l’étape ne pouvait pas être sauvegardée.

Un de ces six a été signalé.

Aucun de ces six n’est arrivé en production, et je veux être précis sur la raison, car cette raison est le cœur du sujet. Ils ont été attrapés parce qu’un humain a lu la diff. Pas parce que le reviewer les a arrêtés. Nous payions pour un filet de sécurité qui attrapait une chose sur six, et ce qui attrapait les cinq autres était un ingénieur lisant le code ligne par ligne, ce qui est exactement l’activité que le produit est censé réduire.

Être confiant à l’envers est pire que de ne rien dire

Il y avait une septième constatation. Elle n’était pas réelle.

On nous a dit « la sauvegarde automatique échouée n’a pas de nouvelle tentative. » Le défaut réel, situé dans la même fonction, était l’inverse : la sauvegarde automatique échouée réessayait indéfiniment. Pas un bug manqué. Un bug inversé.

J’ai réfléchi à celui-là plus qu’aux cinq ratés combinés. Un raté est un silence, et le silence est supportable, car vous supposez déjà que votre reviewer n’est pas omniscient. Une inversion est pire que le silence. Elle envoie un ingénieur dans le bon fichier à la recherche de la mauvaise chose, et quand il ne trouve pas la chose qui n’a jamais été là, il ferme le fichier et le marque comme relu. Un faux rapport ne se contente pas de ne pas vous aider. Il dépense votre attention, et il la dépense exactement à l’endroit où se cachait le vrai bug.

Une vraie constatation. Une constatation inversée. Six défauts dans la diff.

Un modèle signifie un angle mort, et vous n’en apprendrez jamais la forme

Ma première réaction a été que nous avions acheté le mauvais outil. Cette réaction était erronée, et m’en remettre a pris plus de temps que je ne voudrais l’admettre.

Chaque modèle de pointe a des angles morts, et ce ne sont pas les mêmes angles morts. Ce n’est pas un défaut du produit d’un fournisseur particulier, c’est ce que sont ces systèmes. Ce qui signifie que si vous construisez votre processus de revue sur un seul modèle, vous le construisez sur un seul schéma de cécité, et vous n’apprendrez jamais la forme de ce schéma, car le seul instrument qui pourrait vous le montrer est l’instrument qui est aveugle.

Laissez-moi expliciter cela. Le problème n’est pas que votre reviewer est mauvais. Le problème est que votre reviewer est unique. Un second avis n’a jamais été un luxe dans la revue de code, c’était le mécanisme entier par lequel la revue de code fonctionnait, et nous l’avons discrètement abandonné dès que nous l’avons automatisé.

Nous avons donc construit Juror. Plusieurs modèles de pointe examinent la même diff en parallèle, chacun via son propre harnais d’agent natif, chacun libre de parcourir votre dépôt comme son fournisseur l’a prévu. Leurs constatations se regroupent, de sorte que trois rapports quasi identiques d’un même défaut deviennent une seule constatation plutôt que trois, et ce qui atterrit sur la pull request est un commentaire unique.

Nous l’avons exécuté sur le même commit.

Reviewer	Trouvé	Précision	Coût	Temps
Greptile	1 sur 6	50%	non divulgué	non divulgué
Juror	4 sur 6	100%	1,08 $	8m22s

Voici la partie où nous perdons

Juror en a manqué deux.

Greptile a attrapé la promesse de sauvegarde abandonnée et nous non. Aucun des deux outils n’a trouvé la boucle de réessai infinie. Mettez les deux reviewers ensemble et vous obtenez cinq sur six, ce qui est mieux que ce que chacun a réussi seul, et je ne vais pas enterrer cela sous le tableau ci-dessus.

J’aurais pu couper cette section. Je la garde parce que c’est le argument. Différents modèles attrapent différentes choses. Ce n’est pas une réserve gênante agrafée à notre argumentaire, c’est l’argumentaire, et le fait qu’un modèle concurrent trouve quelque chose que le nôtre a manqué est la démonstration la plus claire disponible qu’utiliser un seul reviewer est l’erreur. Le jour où cela cesse d’arriver est le jour où je commence à m’inquiéter que notre jury se soit réduit à une seule opinion portant quatre chapeaux.

Vous ne payez pas pour des revues

Maintenant la facture, c’est là que cela cesse d’être à propos d’une seule pull request.

Le plan Pro de Greptile est à 30 $ par siège par mois, en date d’août 2026. Cela inclut 50 crédits par siège, où un crédit achète une revue standard et trois en achètent une plus approfondie, et les crédits supplémentaires sont à 1 $ chacun.

Par révision, c’est bon marché. Environ soixante cents, si vous utilisez chaque crédit qui vous est attribué. Je veux être tout à fait honnête : sur une base unitaire, c’est moins cher que ce que notre propre outil a coûté pour la pull request ci-dessus. Une petite équipe qui consomme entièrement son crédit devrait acheter les sièges, et je ne vais pas prétendre le contraire.

Personne ne consomme entièrement son crédit.

Vous êtes facturé par développeur. Vous consommez des révisions par pull request. Ces deux chiffres cessent de correspondre dès que l’effectif croît plus vite que le taux de fusion, c’est-à-dire immédiatement, dans toute organisation d’ingénierie qui ait jamais existé. Vingt ingénieurs sur Pro, c’est 600 $ par mois et mille crédits. Si cette équipe fusionne 150 pull requests, un mois tout à fait normal, vous avez payé 4 $ par révision et laissé 850 crédits expirer.

Le prix catalogue n’a jamais bougé. Votre utilisation, si. Soixante cents sont devenus quatre dollars et personne ne vous a envoyé d’e-mail à ce sujet.

Appelez cela la taxe sur les sièges : de l’argent dépensé pour une licence par développeur pour un produit consommé par artefact. C’est invisible sur la page de tarification, ça évolue avec les embauches plutôt qu’avec l’utilisation, et c’est le poste le plus important dans ce que vous payez réellement.

Je peux vous dire ce que cela a coûté parce que nous imprimons le reçu

Juror n’a pas de sièges. Il s’exécute dans votre propre runner GitHub Actions, appelle les API des modèles avec vos propres clés, et la facture est l’inférence et rien d’autre. Cette révision de la PR autosave, quatre défauts réels et aucun faux positif, a coûté 1,08 $ et a pris huit minutes et vingt-deux secondes.

Je peux vous le dire au cent près parce que chaque révision Juror se termine par un tableau : chaque modèle, ses tokens d’entrée, ses tokens en cache, ses tokens de sortie, ses dollars. Chaque chiffre est étiqueté reported lorsque le fournisseur l’a calculé, ou estimated lorsque nous l’avons dérivé des prix catalogue publiés. Quand un harnais ne nous donne ni l’un ni l’autre, il affiche unknown et le total est marqué comme une borne inférieure. Nous ne devinons pas et nous n’arrondissons pas en notre faveur.

Maintenant, regardez à nouveau les deux cellules de ce tableau qui disent « non divulgué ». Ce n’est pas une lacune dans mes recherches. L’outil ne vous dit pas combien coûte une révision, parce qu’il n’a pas à le faire. Vous avez acheté un siège. L’économie unitaire est l’affaire du fournisseur, et le fournisseur préfère que vous continuiez à faire la multiplication à sa manière.

C’était la chose que je voulais vraiment et que je ne pouvais acheter à aucun prix. Pas un relecteur moins cher. Un relecteur qui me dit ce qu’il a dépensé.

Ce que je ne vais pas faire, c’est appeler cela un benchmark

Ceci est une seule pull request.

Notre propre protocole de benchmarking dit qu’une décision de remplacement nécessite 20 à 30 PRs jugées couvrant le frontend, le backend, les migrations, la concurrence, le code sensible à la sécurité, et des diffs petits et grands. Nous en avons une. Elle se trouve dans le dépôt avec un avertissement indiquant qu’elle ne doit pas être présentée comme une preuve statistiquement suffisante que l’un ou l’autre relecteur peut remplacer l’autre, et je ne vais pas violer notre propre avertissement dans un article de blog sur la façon dont nous rapportons soigneusement les chiffres.

Quatre sur six contre un sur six n’est pas un résultat de benchmark. C’est un cas jugé qui m’a rendu prêt à exécuter les deux côte à côte. Une pull request différente, qui s’appuie fortement sur le contexte du dépôt où un relecteur indexé devrait bien performer, pourrait plausiblement inverser la tendance. Si c’est le cas, ce cas entre aussi dans le corpus.

Ce qui n’est pas un échantillon de un, c’est l’arithmétique. Trente dollars par siège fois vingt ingénieurs, ça fait 600 $, que ça me plaise ou non, et 150 révisions contre mille crédits, c’est 15 % d’utilisation n’importe quel mois que vous voulez mesurer. Nous avons changé sur la structure de tarification, que je peux défendre avec une division, et sur un cas prometteur. Pas sur une affirmation de performance que nous n’avons pas encore méritée.

Venez nous mesurer

Ne me croyez pas sur parole pour tout cela. J’ai un intérêt commercial dans votre conclusion et vous devriez pondérer tout ce qui précède en conséquence.

Mettez les deux relecteurs en mode shadow sur votre propre dépôt. Laissez-les tourner quelques semaines sans qu’aucun ne bloque une fusion. Ensuite, prenez chaque résultat, retirez les étiquettes pour que personne ne sache quel outil a dit quoi, et faites juger chaque résultat à froid par un ingénieur senior par rapport au code. Comptez ce que chacun a trouvé. Comptez ce que chacun a inventé.

Nous avons livré l’outillage exactement pour cela, parce que nous en avions besoin nous-mêmes :

npx juror-ai benchmark --file your-corpus.json

Il rapporte le rappel, la précision, le taux de doublons, le coût et la latence pour chaque relecteur que vous lui donnez, et il liste chaque oubli par nom. Le nôtre inclus.

Je ne pense pas que le modèle de siège survive au contact de quiconque fait la division. Il survit maintenant parce que la division est légèrement ennuyeuse et que la page de tarification est arrangée pour que vous ne vous embêtiez pas. Quelqu’un dans votre organisation fera ce calcul un jour. Quand ce sera le cas, la réponse ne sera pas soixante cents.

Cette pull request autosave a été fusionnée ce matin, incidemment. Il a fallu deux commits de plus pour y arriver, un pour rendre les sauvegardes de navigation single-flight et un pour faire converger l’autosave et laisser le builder tranquille. De bons commits. Rien en feu.

Personne ne saura jamais qu’ils étaient nécessaires, car les bugs attrapés avant la fusion ne laissent aucune trace et ne génèrent aucun rapport d’incident. C’est la partie de cela qui devrait vous déranger. Le relecteur qui en a manqué cinq coûte le même prix qu’il en trouve six ou zéro, et il ne vous dira jamais lequel de ces deux mois vous venez de payer.

---

Juror est open source et sous licence MIT : github.com/juror-ai/juror. Tarification de Greptile citée depuis greptile.com/pricing en date d’août 2026.