Après l'IA qui parle, l'IA qui tranche : Jev, un modèle pas comme les autres

Depuis bientôt quatre ans, quand on parle de « faire de l'IA » on entend « discuter avec un modèle ». On lui écrit, il nous répond. On lui demande de réfléchir, il raisonne, et chaque étape de sa réflexion se paie en tokens et en secondes. Même pour une question simple telle que « ce ticket parle-t-il de facturation ? », on mobilise une IA générative et sa « Chain-of-Thoughts » faite de tokens, afin d'obtenir une réponse.

Le 15 septembre, TypeSafe AI a lancé Jev, un modèle qui ne dit rien. On lui pose une question fermée, il rend une probabilité. Pas de phrase, pas de JSON à parser, pas d'explication : un chiffre, en quelques centaines de millisecondes, pour une fraction de centime. Ce n'est pas un LLM de plus. C'est un autre type d'IA, et c'est exactement ce qui le rend intéressant.

Un modèle qui ne parle pas

TypeSafe parle de « modèle System One », en référence au Système 1 de Daniel Kahneman. C'est la pensée rapide et intuitive, par opposition au Système 2, lent et délibéré, qui est aujourd'hui le terrain des LLM qui « raisonnent ». On peut aussi parler de modèle de décision : une IA qui ne rédige pas de réponse, mais rend un verdict chiffré à une question fermée posée en langage naturel.

Concrètement, on lui envoie trois choses :

un état : du texte ou du JSON, comme un email, un ticket ou une page web ;
une question ;
des critères, c'est-à-dire les réponses possibles et leur définition.

Il répond sous l'une de ces trois formes :

Noul : la probabilité que la réponse soit « oui ». Dans le code, c'est un if.
Choice : une option parmi une liste, avec une probabilité pour chacune. C'est un switch.
Score : une position sur une échelle de niveaux décrits en clair. C'est un tri, ou un seuil.

Pour une question binaire (noul), la réponse brute se résume par exemple à ceci :

{
  "is_urgent": {
    "type": "noul",
    "noul": 0.999
  }
}

Le tout en 70 à 500 ms selon l'éditeur, pour 0,042 $ par million de tokens en entrée, la sortie étant gratuite. Une requête accepte jusqu'à 64 000 tokens de contexte, et plusieurs questions à la fois, traitées en parallèle.

« Si un modèle réussit une tâche 95 % du temps mais ne dit pas quand il est dans les 5 %, il ne peut pas automatiser cette tâche. » Diogo Almeida, billet de lancement de Jev

Tout est dans cette phrase. TypeSafe ne vend pas seulement une réponse, mais une réponse accompagnée d'un degré de certitude calibré, c'est-à-dire fidèle à la réalité. Quand Jev annonce 80 %, il devrait avoir raison environ huit fois sur dix.

Pourquoi ça ouvre de nouvelles perspectives

L'intérêt de Jev n'est pas d'être plus intelligent qu'un LLM. Il ne l'est pas, on le verra. Son intérêt est d'être une brique plutôt qu'un interlocuteur, et une brique presque gratuite.

Le coût change d'échelle.

Juger un texte de 1 000 tokens coûte 0,000042 $. Un million de décisions reviennent donc à une quarantaine de dollars.
Des jugements qu'on n'aurait jamais confiés à un LLM, faute de budget, deviennent envisageables sur chaque email, chaque requête, chaque ligne de log.
Le nom même de Jev est un clin d'œil au paradoxe de Jevons : quand une ressource devient moins chère, on finit par en consommer beaucoup plus [6:29].
Diogo Almeida, son fondateur, est passé par les équipes d'OpenAI à l'origine d'InstructGPT et de ChatGPT. Il résume l'objectif en trois mots : optimiser « l'intelligence par dollar » [6:27].

La décision entre dans le code. Une probabilité se branche directement sur des seuils :

au-dessus de 0,9, on agit ;
entre 0,5 et 0,9, on vérifie ;
en dessous, on passe la main à un humain.

Ces seuils varient selon la gravité de l'action. On tolère plus d'incertitude pour étiqueter un email que pour bloquer un paiement.

Pour les architectures d'intégration et d'agents, c'est une pièce qui manquait. Quelques exemples dans notre domaine :

une gateway d'API ou MCP qui juge chaque appel en temps réel : tentative d'injection ? données sensibles ? bon outil ?
un workflow d'intégration (iPaaS) qui route, valide ou filtre un message sans appeler un LLM à chaque étape ;
un agent qui garde son LLM pour réfléchir (Système 2) et délègue ses réflexes à un modèle de décision (Système 1), plus rapide et moins cher ;
l'extraction fiable. Plutôt que de laisser un modèle générer une valeur, le code repère les candidats et Jev choisit le bon, avec une option « aucun » si rien ne convient : TypeSafe appelle cette recette « choisir plutôt que générer ». Pour relever des prix sur les pages officielles des fournisseurs, par exemple, Jev ne pourrait retenir qu'un montant réellement écrit sur la page, jamais en inventer un.

Comment ça marche : ce qu'on sait, ce qu'on ignore

TypeSafe décrit un post-entraînement baptisé RLCD (reinforcement learning for calibrated decisions). Il le présente comme une troisième voie, après deux méthodes plus connues :

le RLHF, qui récompense ce qui plaît aux humains ;
le RLVR, qui récompense les réponses vérifiables.

Le diagnostic de TypeSafe : récompenser la préférence humaine pousse les modèles à la complaisance et aux erreurs énoncées avec assurance. Ce n'est pas qu'une intuition. Dès 2023, le rapport technique de GPT-4 montrait qu'un modèle pré-entraîné est bien calibré, et que le post-entraînement dégrade cette calibration. RLCD revient à optimiser directement ce que le RLHF abîme.

Pour le reste, Jev est une boîte noire à l'interface limpide :

aucun article scientifique n'a été publié (« pas encore », dit Almeida [26:34]), et la récompense utilisée n'est pas décrite ;
le modèle de base n'est pas nommé. Almeida laisse entendre un assemblage de modèles existants, qu'on lui a conseillé de ne pas appeler « un monstre de Frankenstein » [45:36] ;
Jev n'est pas entraîné sur les données des clients, et aucun affinage (fine-tuning) n'est proposé : tout le monde utilise les mêmes poids.

Ce que disent les chiffres

TypeSafe ne publie aucune mesure de calibration. Son fondateur se dit « extrêmement opposé aux benchmarks publics » [19:30] et renvoie chacun à l'évaluation de son propre cas d'usage. Deux séries de chiffres permettent pourtant de se faire une idée.

L'évaluation publiée par TypeSafe elle-même porte sur l'extraction de données de factures.

Jev réussit 61,8 % des cas et se classe 8e sur 9. Il devance Claude Haiku 4.5 (42,9 %), mais reste loin du meilleur système (79,1 %).
Il coûte 0,0011 $ et répond en 0,5 s par cas. Les autres coûtent au moins 0,008 $ et mettent au moins 17 s.

Un banc d'essai indépendant, publié le 17 septembre, confronte Jev à Claude Haiku 4.5 sur 2 000 emails, dont la moitié de phishing :

	Jev	Claude Haiku 4.5
Précision	62,6 %	81,3 %
Phishing détecté	43,2 %	76,4 %
Erreur de calibration (ECE, plus bas = mieux)	0,154	0,097
Coût pour 1 000 emails	0,038 $	0,462 $
Latence médiane, depuis la France	239 ms	687 ms

Son auteur en affiche lui-même les limites :

les emails ont été générés par un LLM ;
la vérité terrain vient de listes d'URL malveillantes, pas d'une lecture humaine ;
chaque système n'a été interrogé que d'une seule façon.

Les résultats dépendent donc de la tâche. Sur les factures, Jev devance Haiku 4.5 ; sur le phishing, c'est l'inverse, et nettement. Il y laisse passer plus de la moitié des emails piégés, et sa calibration, sa promesse centrale, y est moins bonne. Son avantage constant est ailleurs : un coût divisé par 7 à 12, une latence divisée par 3 à 35.

Autrement dit, Jev n'est pas un meilleur juge. C'est un juge beaucoup moins cher, dont il faut vérifier la parole avant de le laisser décider seul.

Et le machine learning, dans tout ça ?

La question vient naturellement : classer un texte, le machine learning le fait depuis vingt ans. Qu'apporte un modèle généraliste face à un classifieur entraîné sur des données propres ?

Tout tient à la façon de définir la tâche.

Un modèle de ML apprend la décision par l'exemple. Il lui faut des centaines, voire des milliers d'exemples étiquetés, propres et représentatifs, et il faut le réentraîner quand les données dérivent. En échange, il est imbattable sur une tâche stable à gros volume, surtout sur des données tabulaires, et il tourne chez soi pour presque rien.
Jev applique la décision par la description. On écrit la question et les critères, et il répond sans avoir jamais vu vos données.

	ML classique	LLM	Jev
La tâche est définie par	des exemples étiquetés	une consigne	une question et des critères
Pour démarrer	des centaines d'exemples	rien	rien
Probabilités	à recalibrer	peu fiables	annoncées calibrées, à vérifier
Coût et vitesse	quasi nul, en millisecondes	le plus cher, en secondes	très bas, en centaines de ms
Où ça tourne	chez soi	API ou local	API hébergée aux États-Unis

Almeida a une jolie formule pour ça : régler ses seuils sur des exemples réels, « c'est du ML sans le ML » [1:07:43]. Elle est juste, mais à moitié. Car Jev ne supprime pas le besoin de données étiquetées : il le déplace, de l'entraînement vers l'évaluation. Pour savoir si ses probabilités tiennent sur votre cas et où placer vos seuils, il vous faut encore une centaine d'exemples vérifiés. Une centaine, pas des milliers : c'est là qu'est le gain.

La frontière avec le ML tient d'ailleurs moins à l'architecture qu'à l'entraînement. Quelques jours après Jev est apparu Laya, un modèle open source aux mêmes primitives (noul, choice, score). Il repose sur un encodeur de la famille BERT (ModernBERT-large, pour 421 millions de paramètres au total), autrement dit le même type de modèle qu'un classifieur classique.

Entraîné sur une seule tâche avec vos données, un tel encodeur donne un classifieur spécialisé.
Entraîné sur une multitude de décisions décrites en langage naturel, avec une récompense qui paie la calibration, il devient un modèle de décision généraliste.

Son auteur, Nandakishor M., affirme d'ailleurs avoir publié ce concept dès 2025, et reproche à TypeSafe de le présenter comme une percée sans article, sans poids ouverts ni données.

Les deux approches se combinent plus qu'elles ne s'opposent :

Jev en premier filtre, qui renvoie ses cas douteux vers un LLM ou un humain ;
ses notes utilisées comme variables d'entrée d'un petit modèle de ML, entraîné sur vos résultats réels ;
ses étiquettes, une fois vérifiées, pour entraîner un modèle local quand le volume ou la souveraineté l'exigent.

Les limites à connaître

TypeSafe documente lui-même les faiblesses de jev-1.13, et elles sont instructives :

il lit littéralement : il répond à la question écrite, pas à l'intention. Négations, conditions implicites, cas limites : tout doit être dit ;
il ne sait pas compter : les chiffres, les comptages et les comparaisons de dates restent le travail du code ;
il se perd dans le bruit et dans les raisonnements en plusieurs étapes. Plus le contexte contient d'éléments inutiles, plus il se trompe : mieux vaut filtrer en amont et poser des questions directes ;
il ne se méfie pas : un texte piégé, qui glisse des consignes dans les données, peut orienter sa réponse ;
il n'écrit pas : ni résumé, ni argument libre à passer à un outil.

Les premiers utilisateurs ajoutent d'autres réserves :

« Jev ne peut pas halluciner », promet le billet de lancement. C'est vrai du format (pas de JSON cassé, pas d'étiquette inventée), pas du fond : une réponse bien typée peut être fausse.
Ses réponses peuvent varier d'un appel à l'autre sur les cas limites, comme l'a observé Sam Witteveen. Almeida assume d'échanger le déterminisme contre un meilleur coût [44:45].
L'anglais d'abord. Les autres langues sont prises en charge « mais pas aussi bien », selon la documentation, et le français n'y est pas cité.
Un hébergement américain. Pour des données clients européennes, la question de la souveraineté se pose. C'est l'un des arguments de Laya, qui tourne en local.
Un changement d'habitude. Découper une décision en petites questions est « super pénible », reconnaît Almeida [1:04:45]. Beaucoup de premiers utilisateurs « ne comprennent pas », parce qu'ils ne programment pas [38:07]. Jev est un outil de développeur, pas un chatbot.

Ce qu'on en retient

Jev ouvre une nouvelle catégorie : à côté de l'IA qui parle, l'IA qui tranche. Son intérêt n'est pas sa justesse, comparable à celle d'un petit LLM et très variable selon la tâche. Son intérêt, c'est son économie : un jugement devient assez rapide et assez bon marché pour être posé partout, dans le code, en temps réel. C'est une brique de plus dans la boîte à outils de l'architecte, et elle change ce qu'on peut se permettre d'automatiser.

À condition de l'utiliser pour ce qu'elle est :

poser des questions étroites, une décision à la fois ;
laisser les calculs, les dates et les règles au code ;
mesurer sur une centaine d'exemples réels avant de fixer ses seuils ;
prévoir l'escalade vers un LLM ou un humain quand la confiance est basse.

C'est ce que nous allons faire dans un projet de test dédié, sur des cas concrets. Rendez-vous dans un prochain article.

Article préparé avec l'aide d'une IA, relu et validé par Luca. Les citations de l'interview de Diogo Almeida (Latent Space) sont traduites de l'anglais ; les horodatages renvoient à la vidéo.