Jev : le modèle qui décide en 70 ms et ne sait pas écrire

Un client écrit à votre support à 23h12. Avant qu'une réponse parte, votre produit doit trancher quatre choses : demande commerciale ou technique, urgent ou pas, faut-il réveiller quelqu'un, le ton du message annonce-t-il un départ.

Quatre questions à choix fermé. Quatre appels à un modèle de raisonnement, deux secondes et un centime chacun. Huit secondes et quatre centimes pour arriver au point où le vrai travail commence, c'est-à-dire écrire la réponse.

Aucune de ces quatre questions ne demandait d'écrire quoi que ce soit. Elles demandaient de choisir dans une liste.

TypeSafe vient de publier Jev, premier représentant d'une classe de modèles qu'ils appellent System One. Sa particularité tient en une phrase : il ne sait pas écrire. Jamais de texte en sortie. À la place, une valeur typée accompagnée d'une probabilité. Annoncé entre 70 et 500 millisecondes de bout en bout, 0,042 $ le million de tokens en entrée, sortie gratuite.

Cet article regarde ce que ce déplacement change au cadrage d'un produit IA. D'abord ce que la promesse « ne peut pas halluciner » veut dire exactement, parce qu'elle est plus étroite qu'elle n'en a l'air. Ensuite trois endroits où le calcul bascule. Enfin ce qu'on peut faire dès aujourd'hui, avec les modèles qu'on a déjà, pour être prêt le jour où on branche l'autre.

Trois mots avant de commencer

• système 1 et système 2 : le vocabulaire vient de Daniel Kahneman et de Thinking, Fast and Slow. Le système 1 juge vite et sans effort conscient, reconnaître un visage, sentir qu'une phrase sonne faux. Le système 2 raisonne lentement, poser une division, comparer deux contrats. Les modèles de langage actuels sont des machines système 2 qu'on emploie massivement à des tâches système 1 ;
• une sortie structurée, c'est une réponse dont la forme est connue d'avance : une valeur parmi cinq, un booléen, un nombre entre 0 et 100. Aujourd'hui on l'obtient en réclamant du JSON à un modèle qui produit du texte, par exemple avec generateObject, puis en validant ce texte. La forme est espérée, pas garantie ;
• la calibration, c'est la propriété qui donne un sens au score de confiance. Un modèle calibré qui annonce 80% se trompe environ deux fois sur dix. Un modèle non calibré peut annoncer 95% et se tromper une fois sur trois.

Ce troisième point est celui qui compte pour un produit. Sans calibration, le score ne sert qu'à décorer l'interface. Avec, il devient un seuil, donc une règle d'automatisation.

Comptez la part décision de votre produit

Prenez une session utilisateur type et rangez vos appels de modèle en deux colonnes. D'un côté ceux qui produisent du texte destiné à un humain. De l'autre ceux qui produisent une valeur que seul votre code va lire : router vers le bon agent, choisir un outil, classer une pièce jointe, décider s'il faut relancer une recherche, noter une réponse avant de l'afficher, extraire six champs d'un document.

Sur les produits agentiques que je livre, la seconde colonne est la plus longue. Un tour de boucle contient une génération et plusieurs décisions.

La colonne de droite est le point. Une génération a le droit d'être lente, le streaming occupe l'utilisateur pendant ce temps. Une décision n'a pas ce luxe : elle se place avant ou après le moment visible, elle ajoute sa latence sans rien donner à regarder. On paie donc le prix fort, en secondes et en centimes, précisément là où l'utilisateur ne voit aucune contrepartie.

Ce que Jev abandonne et ce qu'il achète avec

Le troc est brutal et c'est ce qui le rend lisible. Jev renonce à produire du texte. Pas « il en produit moins bien », il n'en produit pas du tout. En échange, il gagne trois choses qu'un modèle génératif ne peut pas offrir.

Il calcule tout d'un coup. Un modèle de langage écrit token par token, chacun conditionné par les précédents. Une sortie de quarante tokens, ce sont quarante passes séquentielles. Jev produit l'ensemble de sa sortie en une seule passe parallèle. L'essentiel de l'écart de latence vient de là, pas d'un modèle plus petit.

Sa sortie est typée par construction. Le schéma n'est plus une consigne glissée dans le prompt qu'on espère voir respectée, c'est la structure même de ce que le modèle produit. Zéro erreur de type, garantie mathématique plutôt que statistique. Le try/catch autour du JSON.parse disparaît.

Il annonce sa confiance et cette confiance est entraînée. TypeSafe a construit une méthode dédiée, RLCD pour Reinforcement Learning for Calibrated Decisions, là où l'industrie optimise sur RLHF et ses variantes vérifiables. L'objectif n'est plus de plaire à un évaluateur humain, il est de sortir des probabilités honnêtes.

Sur leur banc de workflows, TypeSafe revendique 193,6x plus rapide et 444,6x moins cher que GPT-6 Astra et Fable 5.1 pris comme références. Ces chiffres sont auto-publiés, sur des workflows écrits par leur propre équipe, mesurés depuis des portables de la côte ouest. Ils le disent eux-mêmes dans le billet, ce qui est déjà une indication de sérieux. Ça reste une raison de ne pas les inscrire dans un business plan. Retenez l'ordre de grandeur, deux zéros, puis attendez une réplication indépendante pour la décimale.

Pourquoi ce nom

Jev vient de William Stanley Jevons, l'économiste qui a observé en 1865 que l'amélioration du rendement des machines à vapeur avait fait grimper la consommation de charbon au lieu de la réduire. C'est le paradoxe de Jevons et TypeSafe parie ouvertement dessus.

Pour un fondateur, c'est l'idée à retenir de tout le billet. Rendre une décision cent fois moins chère ne fera pas baisser votre facture, ça multipliera le nombre de décisions que vous vous autorisez. Les usages de la section suivante n'attendaient pas une percée technique, ils attendaient que le prix les laisse passer.

« Ne peut pas halluciner » : la promesse exacte

La formule circule déjà hors de son contexte, il faut la border.

Ce que Jev garantit, c'est que sa réponse appartient au schéma. Si vous demandez un choix parmi urgent, normal et basse, vous recevrez l'une de ces trois valeurs, toujours. Aucun texte parasite, aucun champ inventé, aucun JSON tronqué.

Ce que Jev ne garantit pas, c'est que la réponse soit juste. Un ticket urgent classé normal reste une erreur, que le schéma laisse passer sans broncher parce qu'elle a la bonne forme. TypeSafe est explicite sur ce point : l'absence d'hallucination est une garantie de structure, pas une mesure empirique.

La distinction change ce que vous avez à construire. Un modèle qui ne peut pas mal se former vous dispense de la validation syntaxique. Il ne vous dispense d'aucune évaluation métier. Le jeu de cas de test que le playbook MVP réclame dès le premier jour reste exactement aussi nécessaire, avec les mêmes vingt à cinquante cas réels.

La calibration apporte autre chose, à mon sens plus utile qu'une garantie de vérité qui n'existe pour aucun système : elle vous donne la taille de la zone d'erreur, à l'avance. Si le modèle est calibré, vous savez que les décisions annoncées au-dessus de 0,9 se trompent une fois sur dix ou moins. Vous pouvez donc arbitrer en connaissance de cause le volume que vous laissez passer sans relecture humaine.

Trois endroits où le calcul bascule

1. Le if qu'aucun if ne sait écrire

Ce lead est-il qualifié ? Cette note de frais mérite-t-elle un contrôle ? Ce message annonce-t-il un départ client ? Réponse floue, sortie fermée : la pire combinaison pour un développeur.

Aujourd'hui, deux options. Écrire trois cents règles à la main, qui vieillissent mal et que plus personne n'ose toucher au bout d'un an. Ou appeler un modèle, trop lent et trop cher pour un enchaînement qui tourne mille fois par heure.

Une décision calibrée ouvre une troisième voie. Ce qu'elle apporte tient dans le seuil, plus que dans la justesse du verdict. Au-dessus de 0,9 la machine tranche seule. En dessous de 0,6 un humain regarde. Entre les deux, vous choisissez selon le coût de l'erreur. Surtout, vous connaissez d'avance la proportion de volume qui tombe dans chaque bac, donc vous savez combien d'heures humaines votre automatisation réclame avant même de la déployer. C'est le chiffre que votre client vous demande et qu'aucun moteur de règles ne sait produire.

2. Le backlog que vous n'avez jamais traité

Il existe dans toutes les entreprises que je croise : quatre cent mille tickets de support, deux millions de fiches produit sans catégorie propre, dix ans d'archives commerciales. Le projet est cadré depuis longtemps et il ne sort jamais, parce que le devis fait plusieurs milliers d'euros et plusieurs jours de traitement.

Le calcul avec les tarifs affichés, hypothèses posées : 400 000 tickets à 800 tokens font 320 millions de tokens en entrée. À 0,042 $ le million, la passe complète revient à 13,44 $. Le même volume sur un modèle frontier à 3 $ le million d'entrée coûte 960 $, sortie non comprise. Deux tarifs publics et une division, refaites-la avec votre volume réel avant de me croire.

Ce qui se débloque n'est pas le budget, c'est la permission de se tromper. À 13 $ la passe, vous relancez l'enrichissement complet trois fois dans la semaine parce que votre taxonomie a bougé mardi. À 960 $, vous la lancez une fois et vous vivez avec le résultat pendant deux ans.

3. La décision qui tient dans l'interface

Sous 100 millisecondes, une décision cesse d'être une requête réseau et devient un comportement d'interface. Réordonner une liste pendant que l'utilisateur tape. Pré-remplir un champ à partir de ce qui vient d'être collé. Signaler qu'un formulaire va probablement être rejeté, avant l'envoi. Trier une boîte de réception à mesure qu'elle se remplit.

Le seuil est documenté depuis les années 1990 par le Nielsen Norman Group : au-delà de 100 millisecondes environ, une réaction ne se lit plus comme instantanée. À partir d'une seconde, il faut afficher un indicateur d'attente. Or un indicateur d'attente coûte plus que de l'élégance. Une suggestion instantanée s'accepte sans y penser. La même suggestion précédée d'un spinner devient une demande : l'utilisateur l'attend, la juge, puis souvent la refuse.

C'est la catégorie la plus difficile à imaginer sur le papier. C'est là que l'écart de qualité perçue se voit le plus. Rien n'y ressemble à une fonctionnalité IA, l'écran réagit simplement mieux. C'est le terrain où une interface soignée et le modèle cessent d'être deux sujets séparés.

Deux autres méritent une ligne, pour les équipes qui ont déjà un agent en production. Le juge d'abord : noter les sorties d'un modèle coûte à peu près aussi cher que les produire, donc tout le monde échantillonne quelques pour cent du trafic en différé. À sortie gratuite, les scorers du guide agentique rentrent dans la requête et couvrent tout. Le routeur ensuite : choisir deux outils parmi cinquante ou le bon sous-agent reste un appel frontier à chaque tour de boucle, qu'il s'agisse du catalogue d'outils, du superviseur de l'architecture multi-agent ou de la découverte d'agents dans MCP et A2A. Dans les deux cas, le gain est celui décrit plus haut, déplacé à l'intérieur de la boucle.

Ce que ça ne règle pas

Vous ne pouvez pas l'essayer. Accès anticipé, liste d'attente. Tout ce qui précède est un raisonnement sur des chiffres annoncés. Je n'ai pas fait tourner Jev.

Les mesures sont maison. Workflows choisis et écrits par l'équipe du fournisseur, modèles de référence choisis par lui aussi, mesures prises depuis des portables. Aucune réplication indépendante à ce jour.

La sortie gratuite est une position commerciale. « Trop bon marché pour être facturé » décrit une stratégie d'entrée sur un marché, pas une structure de coût. Bâtir des unit economics sur cette ligne revient à refaire l'erreur du quatrième principe du playbook MVP, avec un fournisseur de plus.

C'est une dépendance supplémentaire. Un modèle propriétaire, fermé, chez un acteur jeune, placé au cœur de vos enchaînements.

Et l'essentiel du travail reste système 2. Rédiger, résumer, raisonner sur plusieurs étapes, écrire du code, tenir une conversation. Jev ne remplace pas votre modèle de langage, il lui retire une tâche pour laquelle il était surdimensionné.

S'y préparer sans attendre la liste d'attente

Le plus utile à faire maintenant ne dépend d'aucun accès anticipé : sortir vos décisions de vos prompts et leur donner une interface à elles.

Voici à quoi ressemble une décision dans la plupart des bases de code que je reprends. Elle est écrite en ligne, là où on en avait besoin, avec le SDK du fournisseur visible au milieu de la logique métier.

// Aujourd'hui : decision en ligne, fournisseur code en dur, forme esperee
import { generateObject } from 'ai'
import { anthropic } from '@ai-sdk/anthropic'
import { z } from 'zod'

const { object } = await generateObject({
  model: anthropic('claude-opus-5'),
  schema: z.object({
    urgence: z.enum(['urgent', 'normal', 'basse']),
  }),
  prompt: `Classe l'urgence de ce ticket :\n${ticket}`,
})

if (object.urgence === 'urgent') await reveillerAstreinte(ticket)

Trois problèmes, dont aucun n'attend Jev pour se poser. Le fournisseur est codé en dur au milieu du métier. La décision n'a pas de nom, donc elle n'a pas de jeu de tests. Et vous ignorez le degré de certitude du modèle, donc vous traitez un cas limite exactement comme un cas évident.

La même décision, nommée puis isolée :

// Le contrat, independant du moteur
export type Decision<T> = { valeur: T; confiance: number }

export interface MoteurDeDecision {
  decider<T extends string>(
    entree: string,
    choix: readonly T[],
    consigne: string,
  ): Promise<Decision<T>>
}

// L'appel, cote metier
const urgence = await moteur.decider(ticket, URGENCES, CONSIGNE_URGENCE)

// Le seuil existe des maintenant, meme si sa valeur bougera
if (urgence.confiance < 0.6) return fileDeRelectureHumaine(ticket)
if (urgence.valeur === 'urgent') await reveillerAstreinte(ticket)

Ce que vous gagnez tout de suite, avec les modèles d'aujourd'hui derrière l'interface : la décision porte un nom, donc elle a son propre jeu d'évaluations, dans l'esprit des scorers que Mastra et les autres frameworks intègrent maintenant en standard. Vous pouvez compter combien d'appels de décision fait une session, ce qu'ils coûtent et ce qu'ils ajoutent à la latence. Vous avez un endroit unique où poser un seuil et brancher une file de relecture humaine.

Une réserve à écrire noir sur blanc dans votre code : la confiance que vous renverrez dans cette implémentation intermédiaire, dérivée des logprobs du modèle ou d'une auto-évaluation, n'est pas calibrée. Traitez-la comme une valeur provisoire. Ce qui compte est que le seuil existe dans votre code, pas que sa valeur soit déjà la bonne.

Le jour où un moteur calibré devient disponible, vous remplacez une implémentation derrière une interface, vous relancez le même jeu d'évaluations et vous comparez deux colonnes de chiffres. C'est la version décision de la règle que ce blog applique au choix du modèle depuis le début : isoler la dépendance, ne pas s'enfermer tôt.

Ce qu'il faut retenir

• Une part importante de vos appels de modèle ne produit pas de texte, elle produit une valeur que seul votre code lit. Comptez-la, elle est plus grosse qu'on ne croit et elle se paie au tarif d'un moteur de raisonnement.
• Jev abandonne la génération de texte pour gagner trois choses : une passe parallèle au lieu d'un décodage séquentiel, une sortie typée par construction, une probabilité entraînée pour être honnête.
• « Ne peut pas halluciner » garantit la forme, jamais la justesse. Vos évaluations métier restent entièrement nécessaires.
• Les chiffres annoncés, deux ordres de grandeur en vitesse comme en prix, sont auto-publiés et non répliqués. Ordre de grandeur oui, business plan non.
• L'effet à anticiper est celui que Jevons a décrit : une décision cent fois moins chère ne fera pas baisser votre facture, elle multipliera le nombre de décisions que vous vous autorisez.
• L'action utile aujourd'hui ne demande aucun accès anticipé : nommer vos décisions, les placer derrière une interface avec un seuil de confiance, leur donner un jeu d'évaluations.

C'est le genre d'arbitrage qu'on tranche au cadrage, avant que la moitié du budget de latence parte dans des décisions que personne n'a comptées. Il se met ensuite en place sur une prestation d'agents et enchaînements pilotés par des modèles de langage ou dans la construction d'un produit web IA-first.