# La facturation par siège transforme une revue de code à 60¢ en 4$ > Vous êtes facturé par développeur et vous consommez des revues par pull request. Voici la répartition, ainsi que la pull request arbitrée où notre réviseur IA a détecté un défaut sur six. - Source: https://jays.fyi/fr/blog/facturation-par-siege-revue-code - Author: Jay Derinbogaz - Published: 2026-08-08 - Language: fr - Tags: tooling, code-review, pricing - Reading time: 11 min - Machine translated: yes — original: https://jays.fyi/blog/how-i-removed-greptile ---
Reçu de Greptile pour 861,00 $, payé le 3 août 2026.
Un mois de Greptile, août 2026. La page de tarification indique 30 $.
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 chiffre é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'utilisons. 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 chiffres 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 que nous payions a lu un 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 le diff à la main et l'a évalué 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 de déranger 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'a atteint la 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 le diff. Pas parce que le reviewer les a arrêtés. Nous payions pour un filet de sécurité qui a attrapé une chose sur six, et ce qui a attrapé 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-ci plus qu'aux cinq manqués combinés. Un manquement 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 fait pas que 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 le 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 la dépasser m'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'en apprendrez jamais la forme, car le seul instrument qui pourrait vous la montrer est l'instrument qui est aveugle. Laissez-moi clarifier. 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 le 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 sont fusionnées, 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 seul commentaire. 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 jeté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 supprimer cette section. Je la garde parce que c'est *l'argument*. Différents modèles attrapent différentes choses. Ce n'est pas une réserve gênante ajouté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 possible que l'utilisation d'un seul reviewer est l'erreur. Le jour où cela cesse d'arriver est le jour où je commencerai à m'inquiéter que notre jury se soit réduit à une seule opinion portant quatre chapeaux. ## Vous ne payez pas pour des revues. Vous payez pour des sièges. Maintenant la facture, c'est là que cela cesse d'être à propos d'une seule pull request. Le [plan Pro de Greptile](https://www.greptile.com/pricing) 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 peu cher. Environ soixante centimes, si vous utilisez chaque crédit qui vous est accordé. 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 allocation devrait acheter les sièges, et je ne vais pas prétendre le contraire. Personne ne consomme entièrement son allocation. 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 a jamais existé. Vingt ingénieurs sur Pro coûtent 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 centimes 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. Elle est invisible sur la page de tarification, elle évolue avec les embauches plutôt qu'avec l'utilisation, et c'est le poste de dépense 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 centime 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. Lorsqu'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é ». Ce n'est pas une lacune dans mes recherches. L'outil ne vous dit pas ce qu'une révision a coûté, parce qu'il n'est pas obligé. 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](https://github.com/juror-ai/juror/blob/main/docs/benchmarking.md) 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 à l'échelle du dépôt où un relecteur indexé devrait bien performer, pourrait plausiblement inverser cela. 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, c'est 600 $ que cela me plaise ou non, et 150 révisions contre mille crédits, c'est 15 % d'utilisation dans 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 fonctionner 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 évaluer à 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 : ```bash 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 fournissez, et il liste chaque échec par nom. Le nôtre inclus. Je ne pense pas que le modèle de sièges 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 effectue ce calcul un jour. Quand il le fait, la réponse ne sera pas soixante centimes. 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](https://github.com/juror-ai/juror). Les tarifs de Greptile sont cités depuis [greptile.com/pricing](https://www.greptile.com/pricing) en date d'août 2026.*