Comment nous utilisons Jev en revue de code par IA
Le modèle de décision Jev répond en chiffres, pas en texte. Nous l’utilisons pour deux tâches ; selon nos mesures, il compare et ne juge pas.
En bref. Un modèle de décision (decision model) est un modèle d’IA qui n’écrit pas de texte et répond par un nombre à des questions typées. diffox ultra utilise le modèle Jev de TypeSafe à la quatrième étape d’une review, au moment de choisir ce qui est publié. En septembre 2026, nous avons mesuré où il est utile et où il ne l’est pas ; cet article présente ces mesures et les leçons que nous en avons tirées.
- Deux tâches. Avant la sélection, il répond à dix questions sur chaque constat candidat. Après la sélection, il repère les constats qui remontent à la même cause et n’en garde qu’un.
- Là où il aide : comparer. Quand on lui demande si deux constats décrivent le même bug, 46 des 47 paires qu’il a signalées étaient bien le même bug.
- Là où il n’aide pas : juger. Sur « ce constat est-il réel ? », il ne distinguait pas mieux que le score de confiance du modèle qui a écrit le constat.
- La règle. Demandez à un modèle de décision de choisir, pas de juger : « ces deux-là sont-ils identiques », « lequel », « quel niveau ».
Comment répond un modèle de décision
Les trois premiers articles ont présenté les résultats de diffox, son prix et les quatre étapes d’une review. Celui-ci parle d’un modèle qui intervient à l’une de ces étapes sans écrire une seule phrase.
Posez une question à un modèle de langage : il vous répond par un texte. Un modèle de décision, lui, reçoit un état et des questions typées, et répond à chacune par un seul nombre : une probabilité de oui, une distribution sur des options ou un niveau sur une échelle. Il répond d’un coup à toutes les questions d’une requête. Jev, de TypeSafe, est un tel modèle ; TypeSafe parle de modèle « System One ».
Parce que la réponse n’est pas un texte, deux choses deviennent plus simples : décider avec un seuil, et combiner la réponse avec d’autres signaux. Une chose devient plus difficile : le modèle répond seulement à la question posée et ne dit jamais qu’elle était mal posée. Les questions qui valent la peine d’être posées, nous avons donc dû les trouver en mesurant.
Ce que fait Jev dans diffox ultra
Une review passe par quatre étapes : contexte, analyse spécialisée, vérification des preuves, puis choix et publication. Jev n’intervient que dans diffox ultra et qu’à la quatrième étape. Les vérifications de preuves restent du simple code ; diffox, le produit principal, n’utilise aucun modèle de décision.
La première tâche vient avant la sélection. Dans diffox ultra, deux modèles distincts lisent le changement. Pour chaque constat candidat issu de ces deux reviews, le modèle de décision reçoit deux séries de questions, et ses dix réponses entrent dans le score de la sélection avec les signaux propres du constat. Un constat dont le score dépasse le seuil est publié. À lui seul, le modèle de décision ne publie ni ne supprime aucun constat ; ses réponses sont l’une des entrées du score.
La seconde tâche vient après la sélection. Les constats à publier sont soumis au modèle de décision par paires : « ces deux-là décrivent-ils la même cause ? » Si la réponse vaut 0,5 ou plus, le constat suivant est écarté et le mieux noté reste. Un candidat qui attendait la place libérée la prend s’il passe le même test. Dans la vérification des preuves, Second Witness fusionne la même objection faite au même endroit ; le modèle de décision, lui, repère des constats placés sur des lignes différentes mais qui remontent au même bug.
Si le modèle de décision ne répond pas, la review continue : la sélection se fait sans ses réponses, la recherche de doublons est sautée, et le journal de la review l’indique.
Ce que nous demandons au modèle de décision
Les questions de la première tâche ne demandent pas si un constat est juste ; elles demandent de quel type d’affirmation il s’agit et sur quoi elle repose. Pour chaque constat candidat, le modèle de décision reçoit quatre choses : le titre de la pull request, l’agent qui a écrit le constat et sa description, le changement dans le fichier du constat (au plus 15.000 caractères) et le texte du constat.
| Question | Ce qu’elle examine | Réponse |
|---|---|---|
| Sur le chemin principal ? | Le bug survient-il avec une entrée ordinaire et valide, ou seulement quand autre chose échoue, avec une entrée malveillante ou un réglage inhabituel ? | probabilité de oui |
| Une précaution ? | Le constat signale-t-il un résultat faux, ou propose-t-il une précaution : une validation, un contrôle défensif, un autre type d’erreur ? | probabilité de oui |
| Un effet visible ? | Sans correction, un utilisateur ou un appelant verrait-il une différence ? Du code mort, un import inutilisé ou une doc obsolète n’en font aucune. | probabilité de oui |
| Repose sur ce qui n’est pas montré ? | L’affirmation s’appuie-t-elle sur du code, un appelant ou un réglage qui ne sont pas montrés ici ? | probabilité de oui |
| Causé par ce changement ? | Le problème vient-il des lignes que ce diff ajoute ou modifie, ou existait-il déjà ? | probabilité de oui |
| Un relecteur commenterait-il ? | Un relecteur expérimenté commenterait-il ce point ? L’échelle va de « ne pas le mentionner » à « bloquer le merge ». | niveau de 1 à 5 |
| Comparé à un code voisin ? | Le constat repose-t-il sur un code voisin du même changement qui fait la même chose autrement et montre la forme voulue ? | probabilité de oui |
| Une petite correction ? | Changer un nom, une valeur, un opérateur ou une condition suffirait-il à corriger le code ? | probabilité de oui |
| Prudent ? | L’affirmation dit-elle « peut-être, pourrait », ou dit-elle avec certitude ce qui ne va pas ? | probabilité de oui |
| Voulu ? | D’après le titre de la pull request et la forme du diff, le comportement contesté est-il le but de ce changement : un retrait voulu, une nouvelle limite ? | probabilité de oui |
Neuf des dix sont des questions oui/non, auxquelles le modèle répond par une probabilité de oui ; l’autre, la question du relecteur, demande un niveau de 1 à 5. Les dix réponses entrent dans le score de la sélection avec les signaux propres du constat : sa gravité, son type, le résultat des vérifications de preuves et le fait que d’autres constats désignent ou non le même endroit. C’est ensuite le score qui décide quels constats sont publiés. Chaque agent reçoit aussi une ou deux questions propres à son sujet, mais seules ces dix réponses entrent dans le score.
Ce que ces questions ont en commun, c’est que la réponse est sous les yeux du modèle. Que le bug soit sur le chemin principal est écrit dans le scénario du constat ; que l’affirmation soit prudente se lit dans la phrase elle-même. On ne demande pas au modèle de décision de rejuger le constat, seulement de lire le texte devant lui et de le ranger dans une case.
Là où le modèle de décision est utile
En septembre 2026, nous avons mesuré où le modèle de décision est utile. Nous l’avons fait sur des constats produits par quatre configurations de review différentes dans des pull requests de projets open source, chacun rapproché de bugs que des personnes avaient marqués au préalable. Le résultat le plus net portait sur une question : deux constats décrivent-ils le même bug ? C’est elle qui évite à un bug un second commentaire.
Nous avons demandé « même cause ? » pour 374 paires de constats ; 58 d’entre elles décrivaient bien le même bug. Au seuil de 0,5, le modèle de décision a signalé 47 paires, dont 46 à raison. Son score de séparation était de 0,99 ; une règle qui demande seulement « même fichier ? » obtient 0,73. Le score de séparation est la probabilité qu’une paire de même bug prise au hasard passe devant une paire de bugs différents prise au hasard : 0,5 équivaut à pile ou face, 1 est parfait.
Le même type de question a servi ailleurs : placer la gravité d’un constat sur l’un de quatre niveaux. L’accord exact avec la gravité donnée par des personnes était de 49,5 % pour le jugement propre du moteur et de 56,8 % avec la correction du modèle de décision (222 constats). Nous l’avons mesuré, mais ce n’est aujourd’hui activé dans aucun des deux produits.
Là où il n’est pas utile
Le même modèle était faible sur « ce constat est-il réel ? ». 315 des 656 constats correspondaient à un bug connu. Le score de séparation du modèle de décision était de 0,64, contre 0,65 pour la confiance du modèle qui a écrit le constat : pas mieux qu’un signal que nous avions déjà.
Resserrer la question n’y a rien changé : douze questions étroites et un modèle appris qui les combine n’ont porté le score de séparation qu’à 0,67.
La différence tient à la question elle-même. Pour comparer deux textes, le modèle a tous les éléments sous les yeux. Que le code se comporte vraiment ainsi n’y est écrit nulle part ; pour le savoir, il faut lire le code et construire un scénario. Dans diffox, c’est le travail des agents spécialisés, et l’affirmation est prouvée par une citation du fichier.
Quel outil pour quelle tâche ?
Quatre types d’outils interviennent dans une review, et chacun est bon pour une tâche différente.
| Outil | Produit | Même entrée, même réponse | Rôle dans diffox |
|---|---|---|---|
| Simple code | un oui ou un non net | toujours | vérifications de preuves, détecteurs à base de règles |
| Modèle de décision | une probabilité, un choix ou un niveau | presque : interrogé à nouveau, au plus 0,07 d’écart | dans diffox ultra, dix questions et la recherche de doublons |
| Modèle de langage (LLM) | du texte | non | agents spécialisés ; titres et suggestions de correction |
| Sélecteur appris | un score | toujours | quels constats sont publiés |
La répartition des rôles découle du tableau. Une question à laquelle une règle fixe peut répondre va au code. Comparer deux éléments qu’on a sous les yeux, ou choisir parmi quelques options, revient au modèle de décision. Lire du code, construire un scénario et l’expliquer à un lecteur revient au modèle de langage. Transformer tous ces signaux en une décision « publier ou non » revient au sélecteur appris.
Sept leçons pour utiliser un modèle de décision
Ce que nos propres expériences nous ont appris en intégrant un modèle de décision au produit :
- Demandez-lui de choisir, pas de juger. La réponse à « ces deux-là sont-ils identiques », « quel niveau », « lequel » est sous ses yeux ; celle à « est-ce juste » ne l’est pas.
- Envoyez en une seule requête les questions qui partagent un état. Une question de plus ne ralentit presque pas la réponse. L’une de nos étapes ne le faisait pas : elle envoyait une requête par constat, avec le même diff à chaque fois. Passer à une seule requête a réduit l’état envoyé de 55 %.
- Figez la version. Les seuils se mesurent sur les probabilités d’une version. diffox ultra utilise une version fixe, pas un alias « latest » ; quand la version change, le seuil est mesuré à nouveau.
- Avant d’ajouter un signal, comparez-le à ce que vous avez. Un nouveau signal vaut ce qu’il ajoute à ceux que vous avez déjà. Notre question « est-il réel » n’a rien ajouté au score de confiance propre du constat.
- Faites-en une entrée, pas un barrage. Dans diffox ultra, les réponses du modèle de décision ne suppriment ni ne publient à elles seules aucun constat ; elles entrent dans le score de la sélection. La seule chose qu’il supprime, c’est un second commentaire sur le même bug.
- Choisissez le seuil pour le lecteur. Le seuil de la recherche de doublons est 0,5 : 46 des 47 paires signalées sont justes. À 0,9, il n’y aurait aucune erreur, mais seuls 36 % des doublons seraient trouvés.
- Si la réponse ne vient pas, la review continue sans elle. Et elle le note dans son journal : une étape manquante vaut mieux qu’une étape sautée en silence.
Questions fréquentes
Qu’est-ce qu’un modèle de décision (decision model) ?
Un modèle d’IA qui n’écrit pas de texte. Vous lui donnez un état et des questions typées, et il répond à chacune par un nombre : une probabilité de oui, une distribution sur des options ou un niveau sur une échelle. Il répond d’un coup à toutes les questions d’une requête. Jev, de TypeSafe, est un tel modèle ; diffox ultra l’utilise à l’étape de sélection d’une review.
En quoi un modèle de décision diffère-t-il de LLM-as-a-judge ?
Avec LLM-as-a-judge, un modèle de langage lit une sortie et écrit son verdict sous forme de texte, souvent avec son raisonnement. Un modèle de décision n’écrit pas de texte : il renvoie pour chaque question une probabilité de oui, un choix ou un niveau, et répond d’un coup à toutes les questions d’une requête. Sa réponse se compare donc facilement à un seuil et se combine facilement avec d’autres signaux ; c’est ainsi que diffox ultra l’utilise.
diffox utilise-t-il aussi un modèle de décision ?
Non. Le modèle de décision n’intervient que dans diffox ultra. Dans diffox, les constats publiés sont choisis d’après leurs propres signaux, et du simple code fusionne la même objection faite au même endroit.
Le modèle de décision voit-il mon code ?
Pour chaque constat candidat, il voit son texte, le changement dans son fichier (au plus 15.000 caractères), le titre de la pull request et la description de l’agent qui l’a écrit. Ces données vont à TypeSafe, qui fournit le modèle, directement ou via OpenRouter ; notre page de confidentialité indique les services utilisés.
Le modèle de décision peut-il supprimer un constat ?
Pas à lui seul. Ses réponses entrent dans le score de la sélection, et c’est le score qui décide quels constats sont publiés. La seule chose qu’il supprime, c’est le second constat d’une même cause ; le mieux noté est publié.
Pourquoi ne pas demander au modèle de décision si un constat est réel ?
Nous l’avons mesuré : sur cette question, il ne distinguait pas mieux que le score de confiance du modèle qui a écrit le constat. Savoir si le code se comporte vraiment ainsi demande de le lire et de construire un scénario ; dans diffox, ce sont les agents spécialisés qui le font, et l’affirmation est prouvée par une citation du fichier.
Donne-t-il toujours la même réponse à la même question ?
Presque. Interrogé à nouveau sur les mêmes questions, ses réponses ont varié d’au plus 0,07. C’est pourquoi nous mesurons les seuils sur les probabilités d’une version et figeons la version.