Jev : le modèle de décision IA qui ne génère pas une seule phrase

Depuis trois ans, tous les modèles que nous branchons dans les projets de nos clients partagent le même réflexe : ils écrivent. On leur pose une question, ils répondent en texte, et nous passons ensuite un temps considérable à transformer ce texte en quelque chose que le code peut exploiter — parsing de JSON approximatif, schémas de validation, relances quand le modèle a décidé d’ajouter une phrase d’introduction avant son accolade ouvrante.

Le 16 septembre 2026, TypeSafe AI a ouvert l’accès anticipé à Jev, un modèle qui prend le problème par l’autre bout. Jev ne rédige pas. Il ne sait pas expliquer son raisonnement. Il reçoit un état et des questions typées, et il renvoie des décisions structurées assorties de probabilités calibrées, en 70 à 500 millisecondes. La société parle d’une nouvelle catégorie : les modèles System One.

Pour une agence comme la nôtre, qui construit des sites et des applications métier où chaque appel à un LLM coûte du temps et de l’argent, ce déplacement mérite un examen sérieux. Voici ce que fait réellement ce modèle de décision IA, ce que valent les chiffres annoncés, et comment l’intégrer concrètement dans une application existante.

Jev expliqué en moins d’une minute

Cette vidéo présente simplement la différence entre un LLM qui génère du texte et Jev qui renvoie une décision structurée.

Un modèle qui ne génère pas de texte : le pari des « System One »

Le nom vient directement de Daniel Kahneman et de son Système 1 / Système 2. Le système 1, c’est le jugement immédiat, intuitif, celui qui reconnaît un visage ou détecte une anomalie sans délibérer. Le système 2, c’est le raisonnement lent, séquentiel, coûteux.

L’argument de TypeSafe tient en une phrase : tous les grands modèles de langage actuels tentent d’être le système 2. Ils raisonnent à voix haute, un token après l’autre, y compris pour trancher des questions qui ne méritent aucune délibération. Classer un ticket entrant dans l’une de quatre catégories ne demande pas une chaîne de pensée de huit cents tokens.

Ce que TypeSafe appelle RLCD

Là où les LLM classiques sont entraînés sur les préférences humaines — le fameux RLHF — Jev repose sur ce que l’entreprise nomme Reinforcement Learning for Calibrated Decisions (RLCD). L’objectif d’entraînement n’est plus de produire une réponse qui plaise à un évaluateur humain, mais de produire une décision dont la probabilité annoncée soit honnête.

La nuance est importante et souvent mal comprise. Un modèle bien calibré qui annonce 70 % de confiance doit se tromper dans 30 % des cas. Ni plus, ni moins. C’est précisément ce qui manque aux LLM généralistes, dont l’excès de confiance est documenté : ils affirment avec le même aplomb ce qu’ils savent et ce qu’ils inventent.

Derrière Jev, on trouve Diogo Almeida, ancien chercheur d’OpenAI ayant contribué à ChatGPT. Le pedigree explique une partie de l’attention portée au lancement.

Pourquoi l’absence de tokens en sortie change tout

Jev ne possède pas de boucle auto-régressive. Vous envoyez un état — une chaîne de caractères, un objet JSON, un tableau — accompagné d’un ensemble de questions typées, et le modèle les évalue toutes en parallèle contre ce même état, en un seul appel.

Trois conséquences directes :

• La latence s’effondre, puisqu’il n’y a plus de génération séquentielle à attendre.
• Les erreurs de type deviennent structurellement impossibles : la réponse ne peut sortir du schéma que vous avez défini. TypeSafe revendique un taux d’hallucination de 0 %, mais entendons-nous bien sur le sens — nous y revenons plus bas.
• Le coût de sortie disparaît. TypeSafe facture les tokens d’entrée et déclare la sortie gratuite, « trop bon marché pour être mesurée ».

Choice, Score, Noul : trois primitives, une seule requête

L’API se limite volontairement à trois types de questions. Cette économie de moyens est ce qui rend le modèle utilisable en production sans documentation de cinquante pages.

Choice — choisir dans une liste fermée

Vous fournissez des options, le modèle en retient une et renvoie la distribution de probabilités sur l’ensemble, plus une valeur de confiance. C’est la primitive du routage et de la classification : quel service doit traiter ce ticket, quelle catégorie pour cet article, quel modèle appeler ensuite. La cardinalité monte jusqu’à 255 options.

Score — noter sur une échelle décrite

Vous décrivez des niveaux ordonnés — « cosmétique », « gênant mais contournable », « bloquant » — et le modèle place l’état sur cette échelle, fractions comprises. C’est la primitive de l’évaluation par grille : sévérité d’un incident, qualité d’une fiche produit, niveau d’agacement d’un client.

Noul — une probabilité booléenne

Une affirmation, une probabilité entre 0 et 1 qu’elle soit vraie. « Ce message exprime-t-il une urgence ? », « Cette commande présente-t-elle un risque de fraude ? ». Ce n’est pas un booléen sec : c’est un nombre sur lequel vous posez vos propres seuils.

La philosophie affichée dans la documentation mérite d’être soulignée, parce qu’elle va à rebours de l’usage courant des LLM : décomposez le raisonnement complexe en questions atomiques séparées, puis recombinez les résultats avec de la logique dans votre code. Autrement dit, on ne demande pas au modèle de réfléchir à votre place ; on lui demande des jugements élémentaires que votre code orchestre.

Voici à quoi ressemble un appel réel, ici via la proposition d’intégration au SDK IA de Vercel :

import { experimental_evaluate } from 'ai';
import { typeSafeAi } from '@ai-sdk/typesafe-ai';

const result = await experimental_evaluate({
  model: typeSafeAi.evaluationModel('jev-latest'),
  state: {
    message: 'I was charged twice. Please refund the duplicate.',
  },
  questions: {
    department: {
      type: 'choice',
      instructions: 'Which team should handle this?',
      criteria: {
        billing: 'Charges, invoices, and refunds',
        technical: 'Bugs, outages, and integrations',
        other: 'Anything else',
      },
    },
    severity: {
      type: 'score',
      instructions: 'How severe is this issue?',
      criteria: [
        'Cosmetic; functionality works',
        'Functionality impaired; workaround exists',
        'Blocking; no workaround',
      ],
    },
    requestsRefund: {
      type: 'boolean',
      instructions: 'Is the customer requesting a refund?',
      criteria: {
        true: 'Explicitly requests money back',
        false: 'Does not request money back',
      },
    },
  },
});

result.answers.department.choice;        // 'billing' | 'technical' | 'other'
result.answers.department.probabilities; // distribution complète
result.answers.severity.score;           // nombre dans [0, 2]
result.answers.requestsRefund.probability; // P(true) dans [0, 1]

Trois questions de nature différente, un seul aller-retour réseau. Notez que Vercel a retenu le nom neutre boolean pour la primitive que TypeSafe appelle Noul.

Latence et coût : les chiffres annoncés, et ce qu’ils valent

Les chiffres publiés par TypeSafe sont spectaculaires. Ils méritent d’être cités avec leurs réserves, ce que fait rarement l’enthousiasme ambiant.

Sur les évaluations de workflows publiées par l’éditeur, Jev atteint 76,0 % de précision pour environ 0,0001 $ par appel et 0,4 seconde, contre 76,1 % pour GPT-5.6 Luna à 0,0025 $ et 14,5 secondes, et 78,4 % pour Claude Opus 5 à 0,4856 $ et 92,1 secondes.

Quatre réserves, et elles comptent :

• Ces workflows ont été conçus par l’équipe de TypeSafe. Un benchmark maison mesure d’abord ce que son auteur a choisi de mesurer. Les multiplicateurs affichés en page d’accueil — 193,6× plus rapide, 444,6× moins cher — correspondent de l’aveu même de l’éditeur au haut de la fourchette.
• Le prix est peut-être subventionné, TypeSafe le reconnaît. Construire une architecture de coûts sur un tarif d’accès anticipé serait imprudent.
• Les 0 % d’hallucination ne sont pas un résultat empirique, mais une garantie de schéma. Le modèle ne peut pas répondre en dehors des options fournies. Il peut parfaitement choisir la mauvaise option : la garantie porte sur la forme, jamais sur la justesse.
• Sur les tâches complexes, un grand modèle reste devant. Jev assume de ne pas être un modèle généraliste. Pour de la rédaction, de la synthèse ou du raisonnement en plusieurs étapes, il n’est tout simplement pas candidat.

Cinq cas d’usage concrets pour un site ou une application métier

C’est là que le sujet devient intéressant pour nos projets. Voici où un modèle de décision IA apporte un gain immédiat, par ordre de simplicité de mise en œuvre.

• Modération de commentaires et d’avis. Deux questions Noul — toxicité, spam — sur chaque soumission, avec des seuils qui décident entre publication, mise en attente et rejet. À 0,4 seconde, cela tient dans le cycle de requête.
• Qualification de formulaires et de leads. Un Choice pour router vers le bon interlocuteur, un Score pour la maturité du besoin, un Noul pour détecter une demande hors périmètre. Le formulaire de contact cesse d’être une boîte noire que quelqu’un dépouille le lundi matin.
• Triage du support. Priorité, service destinataire, présence d’une échéance contractuelle : trois questions, un seul appel, et un ticket qui arrive déjà étiqueté dans l’outil.
• Contrôles e-commerce. Un score de risque à la validation de commande, une détection d’incohérence entre adresse de livraison et de facturation, une pré-qualification des demandes de remboursement.
• Garde-fou d’agent. C’est le cas le plus sous-estimé. Si vous faites tourner des agents IA en production, chaque vérification de sécurité confiée aujourd’hui à un sous-agent coûteux peut devenir un appel à 0,4 seconde. Idem pour le routage de modèles : faire trancher par Jev quel modèle lourd appeler ensuite.

Le critère de décision est simple. Posez-vous la question suivante pour chaque appel LLM de votre système : est-ce que j’exploite réellement le texte produit, ou est-ce que j’en extrais seulement une valeur ? Dans le second cas, vous payez un système 2 pour un travail de système 1.

Intégrer un modèle de décision dans une application existante

L’API est volontairement minimale : un seul endpoint, un état, un ensemble de questions. Aucun SDK n’est nécessaire pour commencer — un appel HTTP suffit, depuis n’importe quel langage.

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-latest",
    "state": "Je tente de connecter mon compte Stripe depuis 3 jours, sans succès. Je perds des ventes.",
    "questions": {
      "urgence": {
        "type": "noul",
        "instructions": "Ce message exprime-t-il une urgence ?"
      },
      "service": {
        "type": "choice",
        "instructions": "Quel service doit traiter cette demande ?",
        "criteria": {
          "facturation": "Paiements, factures, remboursements",
          "technique": "Bugs, pannes, intégrations",
          "autre": "Tout le reste"
        }
      }
    }
  }'

Une requête, deux questions de nature différente, une réponse typée exploitable directement par votre code.

Quatre décisions d’architecture à prendre avant la mise en production :

• Synchrone ou asynchrone. À 400 millisecondes, un appel tient dans un cycle de requête HTTP sans dégrader l’expérience. Dès que vous enchaînez plusieurs décisions, ou que vous traitez un lot, passez par une file d’attente — la latence médiane ne dit rien de la latence au 99e centile.
• Le comportement en cas de panne, décidé à l’avance. Pour de la modération, on bloque et on met en attente humaine. Pour un scoring de commande, on laisse passer et on signale, sous peine d’arrêter les ventes le jour où l’API tombe. Ce choix est fonctionnel, pas technique : il se tranche avec le métier.
• Les seuils, externalisés. Les valeurs de bascule — 0,5, 0,9 — n’ont aucune raison de vivre en dur dans le code. Elles vont bouger après les premières semaines d’observation, et vous voudrez les ajuster sans redéployer.
• La clé d’API dans l’environnement. Jamais dans un fichier versionné, jamais dans une table de configuration exposée côté client.

Passer par un SDK pour rester neutre

Si vous préférez ne pas coder l’appel HTTP vous-même, Jev est disponible via Vercel AI Gateway sous l’identifiant typesafe-ai/jev. Une proposition d’intégration au SDK IA de Vercel, sous la forme d’une fonction experimental_evaluate(), est ouverte depuis le 16 septembre 2026 — c’est l’API montrée plus haut. Son intérêt principal n’est pas le confort d’écriture, mais la neutralité vis-à-vis du fournisseur : le jour où un concurrent sort son propre modèle de décision, le code d’appel ne bouge pas.

Dans les deux cas, isolez cet appel derrière une interface à vous. Une fonction evaluer(etat, questions) dans votre propre code, et le reste de l’application n’a jamais besoin de savoir qui rend la décision.

Les erreurs à éviter

Nous avons vu passer assez de projets IA mal cadrés pour anticiper les pièges.

• Ne pas mesurer la calibration sur vos propres données. Un modèle calibré sur les benchmarks de son éditeur ne l’est pas forcément sur vos tickets, dans votre secteur, en français. Constituez un jeu de cent cas étiquetés à la main et vérifiez que les seuils de confiance tiennent. C’est une demi-journée qui vous évitera six mois d’automatisation silencieusement fausse.
• Confondre confiance et justesse. Une probabilité de 0,92 n’est pas une garantie. Elle signifie que, sur cent cas semblables, huit devraient être faux. Votre logique doit prévoir ce que vous faites de ces huit-là.
• Oublier le RGPD. Envoyer le contenu d’un commentaire, d’un formulaire ou d’une commande à une API tierce, c’est un transfert de données personnelles. Traitement à inscrire au registre, sous-traitant à mentionner dans la politique de confidentialité, et vigilance sur la localisation des serveurs. Ce point se règle au début du projet, pas à la mise en ligne.
• Bâtir une dépendance sans porte de sortie. Le service est en accès anticipé, la tarification est jeune, l’entreprise a quelques mois. Isolez l’appel derrière une interface de votre cru et gardez une implémentation de repli, ne serait-ce qu’un jeu de règles simples.
• L’utiliser pour ce qu’il ne sait pas faire. Jev ne rédige pas, ne résume pas, n’explique pas ses choix. Si votre besoin comporte une part de génération, il vous faut les deux : un modèle de décision pour trancher, un modèle de langage pour produire.

Ce qu’il faut en retenir

L’intérêt de Jev ne tient pas à sa performance brute — sur la précision pure, les grands modèles restent légèrement devant. Il tient au rapport entre le coût d’une décision et sa valeur. Quand une classification passe de 2,5 centimes et quatorze secondes à un centième de centime et quatre dixièmes de seconde, ce ne sont pas les mêmes fonctionnalités qui deviennent possibles : ce sont des fonctionnalités que personne n’aurait envisagées, parce qu’elles étaient absurdes économiquement.

Notre recommandation, à ce stade : ne réécrivez rien. Identifiez dans vos applications existantes les deux ou trois flux de décision les plus coûteux — en euros, en latence, ou en temps humain de dépouillement — et testez-les sur un échantillon réel. Vous saurez en une journée si le gain est là.

Vous vous demandez quels flux de votre site ou de votre application métier gagneraient à passer sur ce type de modèle ? C’est exactement le genre de diagnostic que nous menons chez Partikuls. Parlons-en : un échange d’une heure suffit généralement à identifier les deux ou trois candidats évidents, et à écarter les faux amis.

Sources

• Introducing System One Models & Jev — Blog TypeSafe AI
• Documentation TypeSafe AI — Introduction
• Jev API, Pricing & Playground — Vercel AI Gateway
• Issue #20846 — experimental_evaluate with a TypeSafe provider, dépôt vercel/ai
• TypeSafe Jev: the First Decision-Only Model Class, Benchmarked and Priced — Developers Digest