Qu'est-ce que Jev et comment l'appliquer : le modèle de jugement de TypeSafe

Jev est le modèle de jugement de TypeSafe, ce que la société appelle son modèle System One : une IA qui ne génère pas de texte, mais répond à des questions fermées et renvoie des probabilités. Il existe pour trancher la question qui apparaît dans presque tous les projets d'IA qui s'enlisent et que presque personne ne formule à voix haute : qui décide. Pas qui écrit le prompt, ni qui choisit le modèle. Qui décide si ce ticket escalade, si cette facture passe, si cette demande continue.

Depuis trois ans, la réponse par défaut a été de demander à un modèle génératif de renvoyer un JSON contenant la décision, en croyant que le format tiendrait. Il tient, en général. Ce qui ne tient pas, c'est l'audit.

Jev est la proposition inverse, et le nom n'est pas décoratif : System One renvoie à la pensée rapide, cette réponse qu'une personne compétente donne en une seconde sans avoir à délibérer. Au lieu d'une prose, il renvoie une distribution de probabilité sur les options que vous avez définies à l'avance. La version en vigueur est jev-1.13 et la documentation des primitives est la source de tout ce qui suit.

Trois formes de réponse, et pas une de plus

C'est toute la surface du modèle. La brièveté est délibérée.

• Choice : la réponse est l'une des options d'un ensemble connu et sans ordre interne, comme la catégorie d'un ticket. Le code agit avec une branche par option.
• Score : la réponse est une position sur un spectre que vous pouvez décrire par niveaux, comme la gravité d'un incident. Le code agit avec un seuil, un ordre ou un poids.
• Noul : la réponse est un oui ou un non franc, et ce qui compte, c'est la probabilité, pas l'étiquette. Le code agit avec un if.

Les trois renvoient toujours quelque chose que votre code consomme sans avoir à interpréter de la prose, et c'est la propriété qui compte vraiment ici, parce qu'elle élimine d'un coup toute la couche défensive de lecture, de relances et de validation de format qui accompagne toute intégration sérieuse avec un modèle génératif. Un Choice renvoie l'option choisie, les probabilités de toutes et une confiance. Un Score renvoie la moyenne pondérée des niveaux. Un Noul renvoie un nombre entre zéro et un.

La règle de conception qui ordonne tout le reste tient en une phrase : une bonne question pour Jev est une question à laquelle une personne compétente répondrait en une seconde si elle avait le bon contexte devant elle. Ce message transmet-il de l'urgence ? Ça va. Analysez ce message et décidez quoi faire, ça ne va pas. La seconde n'est pas une question. C'est une commande, et il faut la découper en petites questions et recomposer les réponses dans le code.

La différence avec demander la décision à un LLM

Elle est dans l'endroit où vit la politique. Cela ressemble à un détail d'architecture. C'est ce qui décide si le système pourra être audité six mois plus tard.

Quand vous demandez à un modèle génératif de classer et de décider, la règle métier finit écrite dans le prompt, mélangée à l'instruction, au format de sortie et aux exceptions ajoutées au fil du temps. Modifier un seuil signifie alors réécrire un paragraphe en prose et tout réévaluer depuis le début, sans aucune garantie que le changement n'ait pas déplacé au passage le comportement de trois autres cas que personne ne regardait, et le résultat est que personne ne sait avec certitude ce que fait le système, parce que le système est un texte.

Le partage de Jev est explicite : le modèle apporte le jugement, le code garde le contrôle de flux, l'arithmétique et la politique. Les poids et les seuils vivent dans le code. La documentation insiste sur un point qui mérite d'être souligné parce qu'il contredit l'instinct de presque tout le monde : quand la décision finale est incorrecte alors que chaque réponse individuelle est correcte, ce qui est en cause, c'est la politique, donc on change les poids et on laisse les questions tranquilles.

Il y a un second contraste, moins philosophique et plus opérationnel. Jev ne compte pas. Il ne somme pas non plus, et il ne compare pas de dates. La documentation le dit sans détour et propose le motif de remplacement : pour compter des éléments, on lance un Noul par élément dans la même requête et on somme dans le code les réponses qui dépassent le seuil. Qui a déjà vu un modèle génératif échouer sur un comptage de sept lignes reconnaîtra le problème immédiatement.

Quatre motifs qui couvrent presque tout

Le premier est le fan-out spéculatif. Toutes les questions qui partagent le même état partent dans une seule requête, y compris celles qui ne comptent que sur certaines branches. Elles sont traitées en parallèle, donc poser plus de questions ajoute très peu de latence et très peu de tokens au coût total de la requête, et le code ignore tout simplement les réponses dont il n'a pas besoin sur cette branche précise. Une seconde requête ne se justifie que lorsque la réponse de la première détermine quelles données aller chercher.

Le deuxième est le routage par confiance, et c'est celui qui ressemble le plus à diriger une équipe. La réponse dit quoi. La confiance dit si l'on agit.

Ces valeurs sont celles que la documentation sur la confiance donne comme point de départ, avec la consigne explicite de commencer conservateur et de les ajuster sur vos propres données.

Le troisième est le scoring composé. Un jugement complexe, de ceux qu'une réunion règle en disant que cela dépend, se découpe en un Score par dimension qui pèse vraiment dans la décision ; chacun se normalise par son nombre de niveaux, puis on les combine avec les poids que vous fixez dans le code. Quand les priorités du business changent, on touche un poids. On ne réécrit pas une question.

Le quatrième est le parcours de taxonomie : un Choice par niveau de l'arbre, parcouru dans le code, en donnant à chaque option comme critère ce qui pend d'elle, pour que le modèle voie ce qu'il y a sous chaque branche avant de la choisir, et en suivant plusieurs branches à la fois quand les probabilités sortent proches.

D'où vient cet état est une décision à part, et des équipes la résolvent en plaçant Model Context Protocol en amont, pour que le contexte arrive déjà filtré depuis les systèmes qui le détiennent.

Il vaut la peine de dire aussi ce qu'aucun des quatre ne répare. Si la précision chute quand les données d'entrée grandissent, le problème est que l'état transporte du détail non pertinent et qu'il faut le filtrer plus tôt dans le code. Si une question reformulée échange une erreur contre une autre, cette question pèse deux propriétés à la fois et il faut la découper. Et l'état n'est pas traité comme hostile par défaut : le texte que vous envoyez peut orienter la réponse, donc les cas adverses se testent avant de déployer.

Ce qui change pour les talents tech qui collaborent en missions

Une capacité nouvelle apparaît, et ce n'est pas savoir se servir d'un outil. Cette distinction sépare celui qui facture à l'heure de celui qui facture son jugement.

Concevoir un programme Jev, c'est cinq étapes, et aucune ne se résout en écrivant des prompts plus longs :

1. Énumérer les décisions que le système doit prendre, chacune comme une branche, un seuil ou un ordre.
2. Écrire une question atomique par jugement, et découper toute question qui pèse deux propriétés.
3. Choisir la primitive selon ce que le code va faire de la réponse.
4. Construire l'état minimal qui répond à toutes, en calculant dans le code ce que le code peut calculer.
5. Composer les réponses dans le code : branches, poids et portes de confiance.

C'est de l'analyse de décision et de la conception de système. C'est un muscle d'ingénierie, pas de rédaction, et c'est la continuité directe de ce qu'exige déjà monter un agent IA de bout en bout : la différence, c'est qu'ici la partie jugement cesse d'être cachée dans un prompt et devient une pièce que l'on peut montrer, mesurer et défendre.

La partie la plus sous-estimée, c'est l'évaluation. La documentation est catégorique : on révise une ou deux questions par itération, jamais plus, parce que les probabilités bougent de façon difficile à anticiper, et aucune révision ne compte pour bonne sans données étiquetées derrière. Une confiance plus élevée, à elle seule, ne démontre pas que la question se soit améliorée. Savoir monter ce banc d'essai, choisir les cas qui discriminent vraiment et défendre les résultats devant un comité qui interroge le risque avant la technologie, c'est un argument commercial que presque personne ne peut encore soutenir avec les preuves sur la table.

Le marché français donne une piste sur la direction que prend cela, même s'il ne nomme pas encore Jev. Selon l'analyse de marché de Shakers, 919 des 30 467 offres tech avec des skills étiquetées en France nomment LangChain, contre 10 958 qui nomment Python (n=36 907 offres actives, 30 467 avec skills étiquetées, de juin à octobre 2026). L'orchestration de modèles a déjà une demande déclarée et un nom propre dans le texte des offres, et c'est le premier endroit où une capacité nouvelle devient visible avant que quiconque ne lui mette une étiquette formelle dans un catalogue de rôles. La couche de jugement dans cette orchestration est la pièce qui n'a pas encore d'étiquette.

Ce chiffre mesure des mentions dans le texte des offres, pas des exigences vérifiées une à une. Et le dénominateur honnête est celui des offres avec skills étiquetées, pas le corpus entier, parce que le reste n'a pas de skills attribuées et que les compter gonflerait le pourcentage.

Ce qui change pour une entreprise

La question de comité cesse d'être quel est le meilleur modèle. Elle devient une autre : quelles décisions déléguons-nous, et avec quel seuil. C'est de la gouvernance, pas des achats, et c'est la conversation qui manque à la plupart des déploiements d'agents IA en entreprise.

Trois conséquences pratiques. La politique devient lisible, parce que les seuils sont dans le code et versionnés comme toute autre décision d'ingénierie, de sorte que l'on peut répondre avec exactitude, l'historique devant soi, à ce qui a été automatisé, sous quelle condition et depuis quelle date exacte. Un chemin de sortie conçu, et non improvisé, apparaît, parce que le routage par confiance oblige à définir dès le départ ce qui se passe quand le modèle n'est pas sûr, exactement le scénario que les démonstrations ne montrent jamais. Et le coût du changement d'avis baisse : si demain le business décide que la gravité pèse plus que l'urgence, c'est un poids dans une ligne de code.

Il vaut la peine de situer cela dans le problème de fond. L'étude de BCG sur plus de 1 250 entreprises chiffre l'écart sans détour : seuls 5 % obtiennent de la valeur à l'échelle et 60 % n'obtiennent pas de valeur matérielle malgré un investissement substantiel (BCG, septembre 2025). Une bonne partie de ce implementation gap n'est pas un problème de modèle. C'est que personne n'a défini quelle décision on automatisait, ni avec quelle confiance minimale, ni qui répond quand la réponse est douteuse.

Un modèle de jugement ne règle pas cela tout seul. Il oblige à l'écrire, ce qui est déjà bien plus que ce que la plupart des outils obtiennent, et le motif se répète dans tout système qui arrive vraiment en production : il en va de même pour amener une architecture RAG en production, où la récupération est rarement le goulot d'étranglement et où ce qui échoue, c'est de ne pas avoir décidé ce que l'on fait de ce qui a été récupéré.

Les limites, avant de les découvrir en production

• Il ne génère pas de texte. Si vous avez besoin d'une réponse rédigée, c'est un autre modèle. Jev se place devant pour décider lequel, ou derrière pour vérifier ce qui est sorti.
• Il ne raisonne pas en étapes. Un problème qui exige d'enchaîner trois inférences se découpe en trois questions littérales et se recoud dans le code.
• Il ne fait ni arithmétique, ni comptages, ni comparaison de dates. Pour les dates, le motif documenté consiste à extraire chaque partie avec un Choice sur des options énumérées, y compris une pour le cas où elle ne figure pas, et à assembler et comparer dans le code.
• Son échelle n'est pas une magnitude continue. Un Score de 1,0 peut signifier la certitude au niveau 1 ou une égalité entre les niveaux 0 et 2, donc on lit les probabilités à côté du chiffre et on utilise le résultat pour appliquer un seuil ou pour ordonner, jamais pour déduire une quantité.
• Le contexte a un plafond. L'état et toutes les questions partagent 64 000 tokens, et l'état plus la question la plus longue doivent tenir dans 32 000.

Tout cela est décrit pour jev-1.13. La documentation elle-même prévient que plusieurs de ces limites changeront dans des versions ultérieures, donc la page des irrégularités du modèle se relit à chaque changement de version. Pas une seule fois au début.

Par où commencer cette semaine

Prenez une décision qu'une personne prend aujourd'hui de façon répétitive, plusieurs fois par jour et presque toujours de la même façon, et dont vous savez décrire le critère en une seule phrase sans recourir à un schéma ni à une exception que seul connaît celui qui a cinq ans d'ancienneté dans l'équipe. Mettez-la par écrit comme question fermée. Choisissez la primitive selon ce que votre code va faire de la réponse, c'est le critère de sélection, pas l'élégance du format. Rassemblez trente cas déjà résolus avec leur réponse correcte, passez-les et regardez les probabilités des échecs.

Si le modèle échoue avec une confiance élevée, c'est presque toujours qu'il a lu votre instruction de façon strictement littérale, en tenant compte de chaque mot que vous avez écrit et d'aucun de ceux que vous teniez pour acquis, pendant que vous vouliez dire quelque chose de légèrement différent que vous n'avez jamais écrit. L'explication que vous donneriez en voyant cette erreur est, littéralement, la moitié manquante de l'instruction. Mettez-la dedans.

Questions fréquentes sur Jev

Jev remplace-t-il un LLM génératif ?

Non. Il couvre une fonction différente : décider entre des options que vous définissez, pas produire du texte. L'usage habituel est de les combiner, avec Jev qui classe et oriente devant, et un modèle génératif qui rédige derrière quand il faut rédiger.

Qu'est-ce qu'un Noul ?

L'une des trois primitives de réponse de Jev. Elle renvoie un nombre entre 0 et 1 pour une condition qui admet un oui ou un non franc, et le signal est la probabilité elle-même. Un 0,5 signifie que le modèle n'est pas sûr, pas que la réponse soit intermédiaire. Pour mesurer un degré, on utilise un Score.

Peut-on auditer une décision prise avec Jev ?

Mieux qu'une prise dans un prompt. Les questions, les critères de chaque option, les seuils et les poids sont des artefacts de code versionnés, et chaque réponse embarque sa distribution de probabilité complète.

Combien de questions vaut-il mieux envoyer ensemble ?

Toutes celles qui partagent le même état, dans une seule requête, y compris celles qui ne servent que sur certaines branches. Elles sont traitées en parallèle, donc poser plus de questions ajoute peu de latence et peu de tokens.

Y a-t-il une demande pour cela sur le marché français ?

Pour la couche d'orchestration, oui et avec nom propre : 919 des 30 467 offres tech avec des skills étiquetées nomment LangChain, selon l'analyse de marché de Shakers (n=36 907 actives, de juin à octobre 2026). Pour Jev en particulier, pas encore : c'est un modèle récent et aucune offre ne le nomme.