jev et les System One Models : quand l'IA décide au lieu de parler

Les grands modèles de langage savent rédiger, coder et raisonner. Pourtant, dès qu'on les branche dans un processus automatisé, c'est lent, cher, et parfois illisible pour le programme qui attend la réponse. Un ancien chercheur d'OpenAI pense que le problème vient du format même de la réponse.

Depuis trois ans, les LLM ont appris à tout faire. Et pourtant, essayez d'en utiliser un pour trier des tickets de support, valider l'action d'un agent ou classer cent mille lignes d'un export : le constat est souvent le même. Chaque appel prend plusieurs secondes, la facture grimpe avec le volume, et de temps en temps le modèle répond « Bien sûr ! Voici la catégorie : » là où votre code attendait un simple identifiant.

Le 15 septembre 2026, une startup de San Francisco, TypeSafe AI, est sortie de deux ans de développement discret avec une proposition radicale pour ce problème : un modèle qui ne génère pas de texte du tout. Il s'appelle jev, et son fondateur n'est pas n'importe qui.

L'homme derrière jev

Diogo Almeida est co-fondateur et CEO de TypeSafe AI, qu'il a créée en 2024 avec Erik Gafni et Sasha Sheng. Avant cela, il a été chercheur chez Google Brain, puis chez OpenAI de 2020 à 2024. Il y a co-signé le papier InstructGPT (2022), celui qui a montré qu'un modèle de 1,3 milliard de paramètres entraîné avec du retour humain pouvait être préféré par des évaluateurs à GPT-3 et ses 175 milliards de paramètres. Cette méthode, le RLHF (Reinforcement Learning from Human Feedback), est celle qui a rendu ChatGPT possible. Il figure aussi parmi les contributeurs du rapport technique de GPT-4.

Autrement dit, l'un des inventeurs de la recette qui a fait des LLM des interlocuteurs crédibles est aujourd'hui celui qui explique pourquoi cette recette est mal adaptée à l'automatisation. Sa question de départ tient en une phrase : « Les modèles sont surhumains en conversation depuis des années. Alors où est toute l'automatisation ? »

Sa réponse : le RLHF optimise des modèles pour plaire à un humain qui lit. Il produit des réponses sûres, consensuelles, et surtout des certitudes mal calibrées. Le modèle affirme avec le même aplomb ce qu'il sait et ce qu'il devine. Pour un lecteur humain, c'est agaçant. Pour un programme qui doit prendre une décision sur la base de cette réponse, c'est disqualifiant.

L'annonce de jev s'accompagne d'un tour d'amorçage de 40 millions de dollars mené par DCVC. Almeida résume l'ambition ainsi : « La plus grande partie de l'intelligence devrait à terme vivre à l'intérieur des logiciels, en tâche de fond. »

Système 1, Système 2 : d'où vient le nom

Le terme « System One Model » emprunte au psychologue Daniel Kahneman et à son livre Système 1 / Système 2. Le Système 1, c'est la pensée rapide et intuitive : reconnaître un visage, sentir qu'un e-mail est agressif, savoir d'un coup d'œil qu'un ticket parle de facturation. Le Système 2, c'est la pensée lente et délibérée : poser un calcul, dérouler un raisonnement, rédiger un argumentaire.

Les LLM actuels, surtout dans leurs modes « raisonnement », jouent de plus en plus le rôle du Système 2. jev prend le parti inverse : être excellent, rapide et bon marché sur les décisions de Système 1. Celles qui se comptent par millions dans un système d'information, et que l'on confie aujourd'hui à des règles métier fragiles, à des expressions régulières, ou à un LLM surdimensionné pour la tâche.

Ce que fait jev, concrètement

TypeSafe décrit jev comme « un appel de fonction à intelligence frontière : un état non structuré en entrée, des décisions typées et probabilistes en sortie ». En pratique, vous lui donnez deux choses :

• un état : le texte ou le JSON à évaluer (un ticket, un e-mail, une transcription, la sortie d'un autre modèle) ;
• une ou plusieurs questions typées, de trois sortes seulement.

Prenons un message de support : « À l'aide ! Mes paiements échouent depuis trois jours. » En un seul appel, jev peut répondre que c'est urgent, que c'est pour l'équipe facturation, et que la frustration du client est élevée, chaque réponse accompagnée de sa probabilité. Le tout en quelques centaines de millisecondes, pour quelques millièmes de centime. Votre code reçoit des valeurs typées qu'il peut utiliser immédiatement dans une condition, sans analyser une phrase.

Pour les profils techniques, voici la forme d'un appel via OpenRouter, où jev est disponible sous l'identifiant typesafe/jev-1.13 (valeurs de réponse illustratives) :

{
  "model": "typesafe/jev-1.13",
  "state": "À l'aide ! Mes paiements échouent depuis trois jours.",
  "questions": {
    "equipe": {
      "type": "choice",
      "instructions": "Quelle équipe doit traiter ce ticket ?",
      "criteria": {
        "facturation": "Paiements, factures, remboursements",
        "technique": "Bugs, pannes, erreurs applicatives",
        "commercial": "Devis, abonnements, évolutions d'offre"
      }
    },
    "bloquant": {
      "type": "noul",
      "instructions": "Le client est-il empêché de travailler ?"
    }
  }
}

Et la réponse :

{
  "answers": {
    "equipe": {
      "type": "choice",
      "choice": "facturation",
      "probabilities": { "facturation": 0.91, "technique": 0.08, "commercial": 0.01 },
      "confidence": 0.91
    },
    "bloquant": { "type": "noul", "noul": 0.97 }
  },
  "usage": { "input_tokens": 212, "output_tokens": 38, "cost": 0.0000089 }
}

Aucune phrase à interpréter, aucun JSON à réparer : answers.equipe.choice vaut "facturation", point.

Une façon simple de résumer l'outil : un « IF intelligent ». Nos systèmes accumulent depuis des années des conditions pour catégoriser, trier et router : si le sujet contient « facture », alors équipe facturation ; si le montant dépasse tel seuil, alors validation manuelle ; si l'expéditeur est dans telle liste, alors priorité haute. Ces règles sont rapides et prévisibles, mais elles se multiplient, se contredisent, cassent dès que la réalité sort du cas prévu, et personne n'ose plus les toucher. jev propose de remplacer la condition par une question posée en langage naturel, avec le même contrat qu'un if : une réponse fermée, immédiate, exploitable dans le code. La règle devient lisible par un non-développeur, s'adapte aux formulations imprévues, et se maintient en changeant une phrase plutôt qu'une forêt de conditions.

En quoi c'est différent d'un LLM

Trois différences structurelles expliquent tout le reste.

1. Il ne génère pas de texte. Un LLM produit sa réponse token par token, chacun dépendant du précédent. jev évalue toutes les questions en parallèle, en une seule passe. C'est ce qui explique la latence annoncée de 70 à 500 ms contre plusieurs secondes, et le prix : 0,042 $ par million de tokens en entrée, et les tokens de sortie sont gratuits puisqu'il n'y en a presque pas.

2. Il ne peut pas sortir du cadre. La réponse est forcément l'une des options déclarées. Pas de JSON mal formé, pas de préambule poli. TypeSafe parle de « 0 % d'erreurs de type, garanti mathématiquement ». Attention à bien comprendre la nuance : jev ne peut pas inventer une catégorie, mais il peut tout à fait choisir la mauvaise. C'est un problème de justesse, pas de format.

3. Il dit quand il ne sait pas. L'entraînement, baptisé RLCD (Reinforcement Learning for Calibrated Decisions), vise des probabilités calibrées : quand jev répond 0,6, il se trompe grosso modo quatre fois sur dix. Un Noul autour de 0,5 n'est donc pas une réponse vague, c'est un signal exploitable : « cas ambigu, à traiter autrement ».

Ce que jev ne fait pas, et ce qu'on ne sait pas encore

Un premier regard honnête doit aussi lister les limites, et TypeSafe est plutôt transparente sur le sujet.

• Il ne rédige rien. Pas de résumé, pas d'e-mail, pas de code. C'est le prix de la vitesse.
• Pas d'images pour l'instant : l'état est textuel ou structuré.
• Points faibles documentés : l'arithmétique est peu fiable, les comparaisons de dates dans des formats différents échouent, les consignes sont lues au pied de la lettre plutôt qu'interprétées, et la précision baisse quand l'état est encombré de détails hors sujet.
• Un modèle propriétaire, servi uniquement par API (TypeSafe en accès anticipé, ou OpenRouter), avec un contexte de 32 000 tokens. Pas de poids publiés, pas de déploiement sur votre infrastructure aujourd'hui.
• Des chiffres à relativiser. Les gains spectaculaires mis en avant (193 fois plus rapide, 444 fois moins cher) viennent d'évaluations construites par TypeSafe, sur des workflows choisis par TypeSafe, face à GPT-6 Astra et Fable 5.1 passés à travers leur propre adaptateur. L'entreprise le reconnaît elle-même. Les retours indépendants rapportent des gains réels mais plus modestes : l'équipe Spring AI mesure par exemple un facteur 10 à 125 en vitesse selon le modèle comparé.

La règle de prudence tient en une phrase, que l'on doit à une analyse indépendante : tout ce qui coûte cher quand c'est faux et qui est difficile à remarquer doit rester chez un humain ou chez un modèle frontière.

Les cas d'usage : seul, ou en binôme avec un LLM

Seul : les décisions que l'on prend par millions

Ce sont les cas où un LLM est aujourd'hui soit trop lent, soit trop cher, soit pas assez fiable dans son format.

• Routage et triage : tickets de support, e-mails entrants, alertes de supervision. Une question Choice et une question Score par élément, et le bon canal est choisi en moins d'une seconde.
• Classification et étiquetage à grande échelle : l'un des cookbooks publiés par OpenRouter montre comment étiqueter un corpus entier avec des catégories et des tags, ligne par ligne, pour un coût dérisoire.
• Scoring et modération : un autre cookbook score des commentaires Reddit et YouTube sur leur pertinence et leur sentiment, en couplant jev à un outil de collecte.
• Extraction de champs à valeurs fermées : pays, type de document, intention, niveau de priorité.
• Logique conditionnelle « intelligente » : le « IF intelligent » évoqué plus haut. Remplacer une expression régulière ou une cascade de conditions fragiles dans un workflow par une question posée en langage naturel, avec un seuil de probabilité pour décider quand basculer vers un humain.

En binôme : jev comme garde-fou et aiguilleur

C'est là que l'outil devient vraiment intéressant pour qui construit des agents. Le principe est simple : le LLM pense et rédige, jev tranche. L'un est le Système 2, l'autre le Système 1. Et parce que jev est assez rapide et assez bon marché pour être appelé à chaque étape, on peut se permettre de vérifier systématiquement là où l'on se contentait d'espérer.

• Garde-fou des appels d'outils (cookbook Gate Agent Tool Calls) : avant d'exécuter l'action proposée par un LLM, demander à jev si cet appel correspond bien à la demande de l'utilisateur et s'il est réversible. Une question Noul, une centaine de millisecondes, et une liste d'interdictions déterministe placée devant pour les cas qui ne se discutent pas.
• Cascade vérifiée (cookbook Cut LLM Cost with a Jev-Verified Cascade) : un petit modèle bon marché rédige une réponse, jev vérifie qu'elle répond à la question et respecte la politique. Si la probabilité est basse, on escalade vers un modèle frontière. Vous ne payez le gros modèle que quand il est nécessaire.
• Vérification de sortie : un LLM rédige un e-mail client, jev vérifie qu'il ne promet rien que l'entreprise ne peut tenir et que le ton est approprié, avant envoi.
• Approbation des permissions d'un agent de code (cookbook dédié à Claude Code, Codex, Cursor et OpenCode) : chaque demande de permission est analysée par jev, approuvée automatiquement si elle est réversible et dans le périmètre, remontée à l'humain sinon.
• Filtrage avant lecture : sur un grand volume de documents, jev écarte en quelques minutes ceux qui ne sont pas pertinents, et le LLM ne lit que les quelques centaines restants.

Ce qu'il faut retenir

jev n'est pas un concurrent de Claude, de GPT ou de DeepSeek. C'est une autre catégorie d'outil, qui vient se placer autour d'eux : devant pour aiguiller, entre pour contrôler, derrière pour vérifier.

Pensez-y quand la décision est fermée, qu'elle se répète, que la latence et le coût comptent, et que vous avez besoin d'une confiance exploitable par le code. N'y pensez pas quand il faut produire du texte, raisonner en plusieurs étapes, calculer, ou quand une erreur serait à la fois coûteuse et difficile à détecter.

Le modèle est testable dès maintenant via OpenRouter, en quelques lignes et sans compte dédié. Si vous avez un cas de routage ou de garde-fou d'agent sous la main, c'est un bon moment pour l'essayer et comparer avec ce que vous faites aujourd'hui.

Au-delà de jev lui-même, c'est un signal plus large : l'époque du modèle unique qui fait tout touche à sa fin. Composer plusieurs modèles spécialisés, chacun à sa place dans la chaîne, devient une compétence d'architecture à part entière.

Pour aller plus loin

• Introducing System One Models and jev, l'annonce officielle de TypeSafe AI, avec les évaluations et leurs réserves.
• jev sur OpenRouter, le guide d'intégration, les identifiants de modèle et les cinq cookbooks cités dans cet article.
• What Is Jev? TypeSafe's Decision Model Explained for Developers, la présentation du format de requête et des bonnes pratiques de seuillage.
• Diogo Almeida à l'AI Engineer World's Fair 2026, sa bio et son talk « What's next after RLHF? ».
• TypeSafe AI Emerges From Stealth With $40M in Funding, le communiqué de levée de fonds.
• What "System One Models" Actually Are, une analyse indépendante des forces, limites et réserves sur les benchmarks.
• Where Jev Fits in an Agent Harness, les patrons d'architecture pour intégrer jev dans la boucle d'un agent.
• Spring AI and TypeSafe Jev, un exemple de routage de tickets avec mesures de latence indépendantes.