Comment construire une alternative moins chère à Greptile

Faites la division sur votre facture de revue de code IA. Prenez ce que vous avez payé le mois dernier et divisez-le par le nombre de pull requests que l’outil a réellement revues. Le prix affiché est un autre chiffre, et c’est celui que vous avez mémorisé. J’ai fait la division pour notre équipe et j’ai obtenu un résultat tellement éloigné de la page de tarification que j’ai cru avoir fait une erreur.

L’arithmétique était bonne. J’achetais le produit tel qu’il est vendu et je l’utilisais comme nous travaillons réellement, et il s’avère que ce sont deux produits différents.

Voici la thèse, et tout ce qui suit en est la preuve. La revue de code IA se vend par développeur et se consomme par pull request. Ces deux chiffres n’ont rien à voir l’un avec l’autre, et c’est dans l’écart entre eux que votre argent s’en va. Et, séparément, ce qui est pire, l’outil que nous payions a lu un diff contenant six vrais 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 mal paraître.

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

La pull request était un refactor de l’autosave dans notre plateforme. Ordinaire, de taille moyenne, le genre qui s’ouvre un mardi et dont personne ne perd le sommeil. Greptile l’a revue, a laissé deux commentaires, et est passé à autre chose.

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

L’autosave se réarmait pour toujours après avoir normalisé les valeurs. Un échec de sauvegarde réessayait en boucle infinie. L’autosave écrasait ce que l’utilisateur était en train de taper dans un autre onglet. Une promesse de sauvegarde était jetée sans être gérée. Quitter la page perdait 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 pourquoi. Un ingénieur s’est assis et a lu le diff ligne par ligne. Le reviewer était déjà passé. Nous payions pour un filet de sécurité qui attrapait une chose sur six, et les cinq qu’il a laissées tomber ont été attrapées par l’activité exacte que le produit existe pour réduire.

Être confiant dans le mauvais sens est pire que ne rien dire

Il y avait un septième constat. Il n’était pas réel.

On nous a dit « l’autosave en échec n’a pas de nouvelle tentative. » Le défaut qui se trouvait dans cette même fonction pointait dans l’autre sens : l’autosave en échec réessayait pour toujours. L’outil avait la direction inversée.

J’ai réfléchi à celui-là plus qu’aux cinq ratés combinés. Un raté est un silence, et le silence est survivable, parce que 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 revu. Un faux rapport dépense votre attention, et il la dépense à l’endroit exact où le vrai bug se cachait.

Un vrai constat. Un constat inversé. Six défauts dans le diff.

Un seul modèle signifie un seul angle mort, et vous n’en connaîtrez jamais la forme

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

Chaque modèle de pointe a des angles morts, et aucun modèle n’a les mêmes. Chaque fournisseur livre cette propriété, parce que c’est ce que ces systèmes sont. Donc si vous construisez votre processus de revue sur exactement un modèle, vous l’avez construit sur exactement un motif de cécité, et vous n’en connaîtrez jamais la forme, parce que le seul instrument qui pourrait vous la montrer est l’instrument qui est aveugle.

Laissez-moi être explicite. Achetez le meilleur reviewer du marché et vous avez acheté un motif de cécité à plein prix. La revue de code fonctionnait au départ parce qu’une deuxième personne regardait le diff. C’était tout le mécanisme, et nous l’avons abandonné la semaine où nous l’avons automatisé.

Alors nous avons construit Juror. Plusieurs modèles de pointe revoient le même diff en parallèle, chacun via son propre harnais d’agent natif, chacun libre de chercher dans votre dépôt comme son fournisseur l’a prévu. Leurs constats se regroupent, donc trois rapports quasi identiques d’un même défaut arrivent sur la pull request comme un seul commentaire.

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

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

Voici la partie où nous perdons

Juror en a raté deux.

Greptile a attrapé la promesse de sauvegarde jetée et nous non. Aucun des deux outils n’a trouvé la boucle de nouvelle tentative 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 l’enterrer sous le tableau ci-dessus.

J’aurais pu couper cette section. Je la garde parce que c’est ça, l’argumentaire. Des modèles différents attrapent des choses différentes, et le fait qu’un modèle concurrent trouve quelque chose que le nôtre a raté est la démonstration la plus propre disponible que lancer 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 effondré en une seule opinion portant quatre chapeaux.

Votre facture suit le nombre de têtes. Vos revues suivent les merges.

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 review, c’est donné. Environ soixante cents, si vous utilisez chaque crédit qu’on vous accorde. Je veux être tout à fait honnête : à l’unité, c’est moins cher que ce que notre propre outil a coûté sur la pull request ci-dessus. Une petite équipe qui consomme entièrement son quota devrait acheter les sièges, et je ne vais pas prétendre le contraire.

Personne ne consomme entièrement son quota.

Vous êtes facturé par développeur. Vous consommez des reviews par pull request. Ces deux chiffres cessent de suivre la même courbe dès que l’effectif croît plus vite que le rythme de merge, 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 merge 150 pull requests, un mois tout à fait normal, vous avez payé 4 $ par review et laissé 850 crédits expirer.

Votre taux d’utilisation a bougé et le prix catalogue n’a pas bougé, alors soixante cents sont devenus quatre dollars et personne ne vous a envoyé d’e-mail pour vous le dire.

Appelez ça 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 plus gros poste de ce que vous payez réellement.

Je peux vous dire ce que ça coûte parce que nous imprimons la facture

Juror n’a pas de sièges. Il tourne dans votre propre runner GitHub Actions, appelle les API de modèles avec vos propres clés, et la facture, c’est l’inférence et rien d’autre. Cette review de la PR autosave, quatre vrais défauts 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 review 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 quand le fournisseur l’a calculé, ou estimated quand 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.

Regardez maintenant les deux cellules de ce tableau qui disent « non divulgué ». J’ai cherché ces chiffres et ils ne sont publiés nulle part. L’outil ne vous dit pas ce qu’une review coûte parce qu’il n’y est pas obligé. Vous avez acheté un siège. L’économie unitaire, c’est l’affaire du vendeur, et le vendeur préférerait que vous continuiez à faire la multiplication à sa façon.

Un reviewer qui imprime sa propre facture, c’est ce que je voulais et que je ne pouvais acheter à aucun prix.

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

C’est une seule pull request.

Notre propre protocole de benchmarking dit qu’une décision de remplacement nécessite 20 à 30 PR arbitrées couvrant le frontend, le backend, les migrations, la concurrence, le code sensible à la sécurité, et des diffs à la fois petits et grands. Nous en avons une. Elle est 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 des reviewers peut remplacer l’autre, et je ne vais pas violer notre propre avertissement dans un article de blog sur la rigueur avec laquelle nous rapportons les chiffres.

Quatre sur six contre un sur six, c’est un seul cas arbitré. Ça m’a rendu disposé à faire tourner les deux reviewers côte à côte, et c’est tout le poids que ça peut porter. Une pull request différente, qui s’appuie fortement sur le contexte à l’échelle du dépôt où un reviewer indexé devrait bien performer, pourrait plausiblement inverser le résultat. Si c’est le cas, ce cas entre aussi dans le corpus.

L’arithmétique, c’est la partie qui survit à un échantillon de un. Trente dollars par siège fois vingt ingénieurs, ça fait 600 $ que ça me plaise ou non, et 150 reviews contre mille crédits, c’est 15 % d’utilisation quel que soit le mois que vous choisissez de mesurer. Nous avons basculé sur la structure de prix, ce que je peux défendre par une division, et sur un cas prometteur. La revendication de performance, c’est celle que nous n’avons pas gagnée, alors je ne la fais pas.

Mesurez-nous

Ne me croyez pas sur parole pour tout ça. 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 reviewers en mode shadow sur votre propre dépôt. Laissez-les tourner quelques semaines sans qu’aucun des deux ne bloque un merge. Ensuite, prenez chaque constat, retirez les étiquettes pour que personne ne sache quel outil a dit quoi, et faites arbitrer le tout à froid par un ingénieur senior face au code. Comptez ce que chacun a attrapé. Comptez ce que chacun a inventé.

Nous avons livré l’outillage exactement pour ça, 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 reviewer que vous lui donnez, et il liste chaque manque par son nom. Le nôtre inclus.

Je ne pense pas que le modèle des sièges survive au contact de quiconque fait la division. Il survit aujourd’hui parce que la division est légèrement pénible et que la page de tarification est agencée pour que vous ne vous embêtiez pas. Quelqu’un dans votre organisation finit par faire ce calcul. Quand ils le feront, la réponse ne sera pas soixante cents.

Cette pull request autosave a été mergée ce matin, soit dit en passant. 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 ne brûle.

Personne ne saura jamais qu’ils étaient nécessaires, parce que les bugs attrapés avant le merge ne laissent aucune trace et ne génèrent aucun rapport d’incident. C’est la partie de tout ça qui devrait vous déranger. Le reviewer 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 Greptile citée depuis greptile.com/pricing en date d’août 2026.