Jev : 7 cas d'usage où un modèle de décision remplace un appel LLM

La plupart des applications d'IA générative utilisent un LLM pour tout : générer du texte, mais aussi prendre des décisions. Or une large part des tâches en production ne demande pas de la génération — elle demande une classification. Le 15 septembre 2026, TypeSafe AI a publié Jev, premier d'une nouvelle classe de modèles qu'elle appelle « System One models » : des modèles conçus non pas pour écrire, mais pour renvoyer des décisions structurées et probabilistes que votre code peut utiliser directement.

TypeSafe annonce 70 à 500 ms de bout en bout et 0,042 $ par million de tokens d'entrée — des chiffres d'éditeur, à vérifier en production, mais qui suffisent à repenser l'architecture de sept familles de décisions qui saturent aujourd'hui vos LLM. Voici ces sept cas d'usage, et le pattern commun à en tirer pour vos propres architectures.

1. Le problème : votre LLM écrit quand il devrait décider

Vous envoyez du contexte à un LLM et il génère une réponse token par token. Ce mode a du sens quand il faut rédiger, résumer, raisonner ou coder.

Mais beaucoup de charges de travail en production ne demandent qu'une décision bornée :

Ce ticket est-il urgent ?
Quelle équipe doit le traiter ?
Cette transaction est-elle risquée ?
Quel document est le plus pertinent ?
Quel outil l'agent doit-il appeler au prochain tour ?

Faire tourner un modèle génératif complet pour chacune de ces questions, c'est payer de la latence et de l'argent à chaque appel — sur des volumes qui se comptent en milliers de requêtes par heure. L'asymétrie devient criante : vous louez un rédacteur pour qu'il réponde par oui ou par non.

2. Qu'est-ce que Jev ? Un « System One model » qui renvoie des décisions, pas du texte

TypeSafe appelle Jev un System One model, en référence aux deux systèmes de pensée popularisés par Daniel Kahneman : le Système 1, rapide et intuitif, et le Système 2, lent et délibératif. Là où un LLM excelle dans les tâches de Système 2 — rédiger, raisonner, coder —, Jev est optimisé pour le Système 1 : les jugements rapides et bornés qu'un logiciel doit prendre en continu.

LLM :  information → réponse générée
Jev :  information → décision probabiliste

Concrètement, le modèle prend un état et renvoie des sorties structurées et typées, définies à l'avance dans un schéma, chacune accompagnée de probabilités calibrées. Les réponses arrivent en parallèle, en un seul appel.

	LLM génératif	Jev (System One)
Sortie	texte généré, à parser et valider	valeurs structurées typées, définies à l'avance
Échantillonnage	séquentiel, token par token	parallèle, toutes les réponses en un appel
Vitesse de bout en bout	secondes à minutes selon les modèles	70 à 500 ms annoncées
Coût annoncé	~0,20 à 10 $ par million de tokens d'entrée, sortie plus chère	0,042 $ par million de tokens d'entrée, sortie gratuite

Ces performances sont annoncées par TypeSafe au lancement — à relativiser tant qu'aucune évaluation indépendante n'est disponible. Le fondateur de l'entreprise, Diogo Almeida (ancien d'OpenAI, où il a contribué aux travaux sur RLHF et InstructGPT devenus la base de ChatGPT), résume le positionnement : « une fonction call d'intelligence de frontière — de l'état non structuré en entrée, des décisions probabilistes typées en sortie ». TypeSafe affirme même que Jev ne peut pas halluciner : comme les réponses possibles sont définies avant l'appel, le modèle ne peut ni produire de type erreur, ni sortir du schéma. Une affirmation de l'éditeur, à vérifier en production.

Le pattern est toujours le même : le modèle interprète, votre code décide.

Note : les exemples ci-dessous utilisent un pseudocode illustratif et des chiffres inventés. Ils montrent la forme de l'intégration, pas l'API exacte de Jev.

3. Cas d'usage 1 — Router les tickets support par urgence et équipe

Chaque ticket entrant a besoin, avant qu'un humain ne le voie, d'une équipe, d'un niveau d'urgence et d'une vérification de ton.

"My payouts have been failing for three days."

department   billing 82% | technical 18%
urgent       96%
frustration  high

Ensuite, du code tout ce qu'il y a de plus classique prend le relais :

if result.urgent > 0.9 and customer.plan == "enterprise":
    queue = "priority"

Un ticket mal routé coûte un aller-retour de première ligne ; un ticket urgent mal priorisé coûte un client. C'est exactement le type de décision répétitive à fort volume où une couche de décision dédiée se rembourse en quelques semaines.

4. Cas d'usage 2 — Choisir le bon outil à chaque étape d'un agent IA

À chaque étape, un agent choisit quoi faire ensuite. C'est un problème de classification, pas de raisonnement.

next_tool   sql 83% | python 5% | crm 6% | search 4% | email 2%
next_action continue | retry | ask_user | switch_agent | stop

L'orchestrateur exécute l'outil choisi. Le routage arrive bien plus souvent que le raisonnement de long format : un agent qui boucle vingt fois sur ses outils fait vingt décisions de ce type, contre une ou deux vraies synthèses rédigées. Une couche de décision rapide paie donc directement ici.

Deux précautions d'architecture : d'abord, le choix des outils exposés à l'agent — skills vs MCP — reste un problème distinct, qui conditionne la qualité de cette classification ; ensuite, la décision rapide ne dispense pas de structurer le harnais qui l'entoure, comme nous le détaillions dans notre article sur l'agent harness engineering.

5. Cas d'usage 3 — Détecter la fraude et le risque de compte en temps réel

Donnez-lui les signaux bruts :

{
  "failed_logins": 6,
  "usual_country": "France",
  "current_country": "Romania",
  "device": "new",
  "password_recently_changed": true
}

Vous récupérez account_compromised, transaction_risk, manual_review_required.

La bonne intégration consiste à utiliser cette sortie comme une entrée parmi d'autres de votre moteur de risque, à côté des règles dures et des signaux historiques, pour aboutir à allow / challenge / review. Pour les décisions à fort impact, elle ne doit jamais être la seule autorité : un score probabiliste informe une décision, il ne la prend pas.

6. Cas d'usage 4 — Des garde-fous avant et après l'appel au LLM

Jev peut se placer avant ou après un autre modèle.

user input → Jev → prompt_injection 97%, sensitive_data 12%, spam 2% → policy engine
LLM output → Jev → format OK? policy violation? regenerate?

C'est une couche de classification légère autour du modèle coûteux — exactement le rôle que nous assignons aux garde-fous dans un harnais de production, aux côtés de la porte d'approbation humaine dont nous parlions dans le cas LangChain. La différence : ici, le filtre lui-même reste bon marché, donc il peut tourner sur chaque requête plutôt que sur échantillon.

7. Cas d'usage 5 — Transformer des millions de textes en colonnes structurées

Vous avez des millions d'enregistrements non structurés : tickets, notes CRM, avis clients, transcriptions. Jev peut les transformer en colonnes structurées.

message                     topic     urgency
"My card keeps failing"     payment   0.91
"Can I upgrade?"            upgrade   0.12
"I want a refund"           refund    0.73

Ensuite, SQL et vos outils d'analyse habituels reprennent la main. Le gain n'est pas dans la classification d'un document — c'est de faire tourner la même classification, à bas coût, sur tout le dataset. Des données jusque-là non interrogeables deviennent agrégables, filtrables, joignables.

8. Cas d'usage 6 — Reranking RAG avant l'appel au LLM

Le retrieval vous donne 20 documents candidats. Le reranking choisit les 5 qui méritent d'aller au LLM.

query → vector search → 20 docs → Jev scores → top 5 → LLM

"How do I rotate an API key?"
Doc A  0.98
Doc B  0.72
Doc C  0.09

Moins de bruit dans le prompt, et surtout pas d'appel coûteux au LLM juste pour répondre à la question « ce document est-il pertinent ? ». Vous pouvez aussi scorer plusieurs dimensions : pertinence, fraîcheur, autorité, spécificité.

9. Cas d'usage 7 — Qualifier un événement avant de déclencher un workflow

Les règles gèrent les cas précis :

IF payment fails 3 times THEN start recovery workflow

Elles peinent sur les cas flous : « escalade si ça semble anormalement grave et que c'est lié à un problème de paiement. »

event + context → Jev → importance, risk, urgency, workflow → automation

Pensez à Jev comme à une couche probabiliste entre les événements bruts et le logiciel déterministe. C'est aussi un seuil de qualification utile pour décider ce qui reste un workflow agentique et ce qui mérite un agent autonome complet : si un simple score suffit à déclencher le bon chemin, n'instanciez pas un agent pour ça.

10. Le pattern : l'IA générative crée et raisonne, Jev décide, votre code agit

Jev n'est pas un remplacement du LLM. Il suggère un partage des responsabilités différent :

Modèle génératif   que devons-nous écrire ou sur quoi raisonner ?
Jev                dans quelle situation connue sommes-nous ?
Votre logiciel     que doit-il se passer ensuite ?

Ouvert : « Explique pourquoi ce paiement a échoué. » → modèle génératif.
Borné : « Cet échec de paiement nécessite-t-il une escalade ? » → modèle de décision.

La plus grande opportunité est probablement hors du chatbot. Les modèles de type Jev peuvent tourner discrètement à l'intérieur de votre application et prendre des millions de petites décisions : router, scorer, signaler, sélectionner, escalader, classifier, déclencher.

L'IA générative crée et raisonne. Jev décide. Votre code agit.

11. Comment Brainum architecture vos couches de décision en production

Ce que nous faisons avec les équipes qui industrialisent leurs agents IA :

Cartographier les décisions Système 1 de votre pipeline : chaque appel LLM qui ne fait au fond que classifier, router ou scorer parmi un nombre fini d'options est candidat à une couche de décision dédiée — qu'elle s'appuie sur Jev ou sur un classifieur maison.
Intégrer cette couche dans le harnais existant, jamais en autorité seule : le score probabiliste alimente vos règles métier, vos garde-fous et votre porte d'approbation humaine sur les décisions à fort impact — jamais l'inverse.
Valider les chiffres de l'éditeur sur votre propre trafic avant d'architecturer autour : latence, coût et taux d'erreur mesurés en conditions réelles, pas sur la démo.

Question à vous poser dès cette semaine : combien de vos appels LLM en production ne font, en réalité, que classifier, router ou scorer — et pourraient tourner cent fois plus vite pour une fraction du coût ?

Pour aller plus loin

TypeSafe — Introducing System One Models & Jev : l'annonce du lancement, par le fondateur.
Brainum — Skills vs MCP : quand utiliser quoi ? : donner les bonnes capacités à vos agents avant de leur faire choisir.
Brainum — Harnais agentique en production : le cas LangChain : ce que l'architecture du harnais change sur le ROI, chiffres à l'appui.
Brainum — Agent Harness Engineering : la couche technique qui fiabilise vos agents IA : structurer la couche qui héberge vos décisions.

Envie de faire décider votre logiciel avant de le faire générer ? Nous architecturons ces couches de décision en production. Discutons de votre cas.