Jev : un modèle d’IA pour classer, noter et automatiser des décisions
Un article possède déjà un résumé ; il reste à décider s’il mérite d’être lu maintenant. Un ticket est déjà enregistré dans le système ; il reste à déterminer à quelle équipe le confier. Ces questions demandent de comprendre le langage, mais leur réponse peut se limiter à quelques options. Ce dont le logiciel a besoin, c’est d’un jugement exploitable pour classer ou orienter les éléments.
Jev s’adresse à ce type de travail. Proposé par TypeSafe AI, il reçoit les informations à évaluer et des questions définies à l’avance, puis renvoie des choix, des scores ou des probabilités que le programme peut traiter. Il ne produit ni résumés, ni explications, ni code : il peut servir d’étape de décision dans un logiciel existant.
Cet article présente Jev tel qu’il existe au 18 septembre 2026 : comment lui poser des questions, comment interpréter ses résultats, sur quoi reposent les affirmations de vitesse et de coût, et ce qu’il convient de laisser au code classique ou aux personnes dans une application réelle.
Que signifie System One ?
TypeSafe a présenté Jev au public en septembre 2026 et appelle cette catégorie de modèles « System One ». Ce nom emprunte à la distinction de Kahneman entre intuition rapide et raisonnement lent ; Jev doit quant à lui son nom à l’économiste William Stanley Jevons. Le fournisseur espère qu’une capacité de jugement moins chère rendra davantage d’automatisations économiquement viables. Son annonce de lancement présente aussi l’échantillonnage en parallèle et une approche de l’entraînement orientée vers la décision.
« System One » désigne ici un produit et une orientation de recherche. Pour le comprendre, on peut partir de la forme des tâches : fournir suffisamment de contexte, puis demander au modèle un jugement bien délimité et rapide à formuler. Si la tâche exige d’explorer un sujet inconnu, de planifier une longue suite d’actions ou de développer une argumentation complète, il faut organiser séparément la recherche d’informations, le raisonnement et la génération.
TypeSafe appelle sa méthode d’entraînement RLCD, pour « apprentissage par renforcement pour des décisions calibrées ». Selon son introduction technique, l’objectif est d’associer aux décisions des informations probabilistes utilisables. Les documents publics décrivent cet objectif, mais ne suffisent pas à reproduire l’ensemble de l’entraînement ; cet article n’en déduit donc ni le nombre de paramètres ni la structure interne du réseau.
Que faut-il fournir pour obtenir un jugement ?
Une requête comporte deux parties : les éléments à examiner et les questions. L’interface les nomme respectivement state et questions. La première contient les informations dont le modèle a besoin ; la seconde précise ce qu’il doit évaluer et quelles réponses sont autorisées. Une même requête peut poser plusieurs questions, évaluées indépendamment à partir des mêmes éléments. La définition des questions décrit cette organisation. Si une question doit utiliser la réponse à la précédente, c’est au programme d’enchaîner les étapes.
Pour une recommandation de lecture, les éléments fournis peuvent être un résumé accompagné des sujets qui intéressent actuellement le lecteur. La question serait alors « Ce contenu mérite-t-il d’être lu maintenant ? », avec les réponses suivantes :
- Lire maintenant : aide directement à résoudre le problème actuel.
- Conserver : apporte un contexte utile, sans urgence immédiate.
- Passer : n’a pas de rapport avec les préoccupations actuelles.
- Indéterminé : les informations ne permettent pas un jugement fiable.
Ces options doivent être clairement définies. Si « Conserver » et « Lire maintenant » signifient simplement « utile », le modèle aura du mal à les distinguer. Sans option « Indéterminé », le manque d’informations risque aussi d’être absorbé par une autre catégorie.
Le modèle ne peut juger qu’à partir de ce qu’il reçoit. Si on lui transmet un titre, sa conclusion porte uniquement sur ce titre ; si on lui transmet un résumé, il n’a pas pour autant lu le texte complet. La récupération des pages web, l’extraction des sous-titres et la fidélité du résumé restent du ressort du programme qui fournit les éléments.
Trois types de sorties, pour quelles questions ?
La valeur d’un Score est la moyenne des positions des niveaux, pondérée par leurs probabilités. Si l’on définit par exemple trois niveaux, « sans rapport », « contexte pertinent » et « directement pertinent », une valeur décimale situe le jugement du modèle entre ces niveaux. Ce n’est pas, par nature, une note sur cent : changer la description des niveaux change aussi le sens de la valeur.
Une faible probabilité Noul peut être tout aussi utile. Un résultat de 0.02 à la question « Le contenu ne comporte-t-il pas de texte principal ? » signifie que le modèle tend à considérer que ce texte ne manque pas. Lire ce nombre comme « le modèle n’est sûr qu’à 2 % » confond la probabilité de la proposition avec l’incertitude du jugement.
Dans une conversation ordinaire, « donne-moi une note » laisse souvent ces définitions de côté. Jev demande à l’application d’expliciter d’abord les critères d’évaluation. Cela oblige aussi le développeur à répondre à une question plus concrète : que compte-t-il faire de cette note ?
Probabilité, confidence et exactitude
Un Choice peut attribuer 0.51 à « Lire maintenant » et 0.49 à « Conserver », ou leur attribuer respectivement 0.97 et 0.03. Le premier choix est le même dans les deux cas, mais son avance est presque inexistante dans le premier. Ne conserver que la catégorie finale fait perdre cette distinction.
Le champ confidence de TypeSafe est une statistique comprise entre 0 et 1, calculée à partir de la distribution complète d’un Choice ou d’un Score, qui résume son degré de concentration. Ce n’est ni un second jugement indépendant ni la probabilité de l’option la plus probable. Noul ne comporte pas ce champ supplémentaire.
Voir à la fois une probabilité élevée et un confidence élevé ne fournit donc pas deux preuves indépendantes. Ces valeurs décrivent la même distribution de sortie. Les afficher avec de nombreuses décimales ne leur donne pas davantage de fondement factuel.
La notion de « probabilités calibrées » se comprend, elle, sur un ensemble de prédictions dont on connaît les résultats. Si un groupe de prédictions attribue à des événements une probabilité d’environ 80 %, une bonne calibration signifie que la proportion d’événements effectivement survenus dans ce groupe est elle aussi proche de 80 %. Une sortie isolée ne peut pas établir cette propriété.
Un outil de lecture peut commencer par conserver côte à côte les suggestions du modèle et les choix humains, observer les contenus souvent mal classés, puis déterminer quel degré de certitude suffit pour modifier l’ordre de lecture. Reléguer à tort un contenu intéressant et le supprimer automatiquement n’ont pas les mêmes conséquences ; rien ne justifie de leur appliquer le même seuil.
De même, afficher « Indéterminé » quand la probabilité maximale passe sous une certaine valeur n’est qu’une règle fixée par l’application. Il faut ajuster ce seuil sur des contenus réels. Le fait que le modèle fournisse des probabilités ne transforme pas un nombre choisi arbitrairement en critère validé.
Comment comprendre « zéro hallucination » ?
Définir l’espace des réponses à l’avance élimine une catégorie de difficultés : si le programme exige une option existante, le modèle ne peut pas inventer un texte à la place. L’interface est ainsi plus facile à vérifier, et les erreurs plus faciles à localiser.
Une réponse du bon type peut néanmoins être fausse. Un classificateur peut parfaitement respecter le format et envoyer une plainte à la mauvaise équipe. La contrainte de format vérifie que le résultat respecte l’interface ; l’application doit encore déterminer s’il est pertinent. C’est aussi la différence entre un contrat d’outil et la justesse du travail accompli.
Les limites connues de Jev 1.13, publiées par TypeSafe, recensent notamment des difficultés avec les nombres, le comptage, la comparaison de dates, la compréhension nécessitant plusieurs étapes, les longs contextes non pertinents et les textes adversariaux. Posées séparément, une proposition et sa négation ne garantissent pas non plus les identités probabilistes attendues.
Cela a des conséquences directes sur l’utilisation du modèle. On peut confier au code la comparaison de montants et au modèle la pertinence d’un texte. Une phrase fournie par un lecteur ne peut pas autoriser le modèle à réécrire les règles de classification. Pour expliquer un résultat, il faut aussi revenir aux éléments d’entrée, plutôt que laisser un autre modèle improviser une justification qui semble plausible.
Les expériences derrière les promesses de vitesse
La page d’accueil de TypeSafe a affiché des comparaisons annonçant une vitesse multipliée par 193.6 et un coût divisé par 444.6. Ces chiffres doivent être lus avec les tâches et la méthode de comparaison ; ils ne se traduisent pas directement en gains pour chaque application.
Son évaluation de workflows couvre quatre familles de tâches — incidents de sécurité, traces d’exécution d’agents, factures et service client — agrégées à poids égaux. Les réponses de référence sont la moyenne des jugements de GPT-6 Astra et de Claude Fable 5.1 avec des configurations de raisonnement élevé. Il s’agit donc d’une comparaison conçue par le fournisseur, dont les références sont d’autres modèles.
Elle étaye une piste qui mérite d’être testée : décomposer une tâche complexe en jugements explicites, puis les combiner dans le code, peut être plus approprié que de générer une longue réponse à chaque étape. Mais un consensus entre modèles ne constitue pas automatiquement une vérité de terrain. Si les modèles de référence partagent des biais, des réponses proches des leurs peuvent reproduire ces mêmes biais.
La latence réelle dépend aussi de la distance réseau, de la longueur des entrées, de la passerelle, de la concurrence entre requêtes et du traitement côté client. Pour un outil personnel, la mesure la plus utile est le temps d’attente après un clic. Pour un système de traitement en lot, il faut aussi examiner le débit soutenu, le taux d’échec et l’attente que les requêtes les plus lentes imposent au travail suivant.
Prix, capacité d’entrée et prise en charge du chinois
Le jour de la vérification, le catalogue public de Vercel indiquait pour Jev un prix d’entrée exact de 0.042 dollar par million de tokens, avec un prix de sortie nul. La page de présentation du modèle l’affichait sous la forme abrégée de 0.04 dollar. Le token est l’unité utilisée pour mesurer le texte traité par le modèle ; il ne correspond pas directement à un caractère chinois.
Un exemple purement arithmétique : si dix mille requêtes consomment au total vingt millions de tokens d’entrée, leur coût d’entrée au tarif indiqué est d’environ 0.84 dollar. Ce calcul ne porte que sur l’utilisation du modèle. Des requêtes supplémentaires, des contenus plus longs, l’infrastructure et le traitement humain modifient le coût réel. Même un jugement peu coûteux à l’unité peut devenir une dépense récurrente lorsque les appels se multiplient.
La documentation actuelle des modèles TypeSafe indique les limites suivantes :
Même avec une fenêtre suffisamment grande, il vaut mieux ne transmettre que les informations nécessaires au jugement. Lorsqu’une exigence essentielle se cache dans un long compte rendu de réunion, repérer d’abord le passage pertinent facilite souvent davantage la vérification que de tout confier au modèle.
L’utilisation en chinois demande tout particulièrement des échantillons représentatifs de l’usage visé. Le fait que le modèle accepte du chinois et propose une option plausible montre seulement que l’interface et un exemple particulier fonctionnent. Les abréviations métier, l’ironie, les doubles négations et le contexte implicite doivent figurer dans les véritables contenus de validation.
Comment l’intégrer à un logiciel existant ?
L’accès direct à TypeSafe et le passage par une passerelle sont deux voies d’intégration différentes. Cette section porte sur l’interface evaluation de Vercel AI Gateway, utilisée dans cet essai : elle demande AI SDK 7, le nom de modèle typesafe-ai/jev et la fonction experimental_evaluate. Ce n’est pas une interface de génération conversationnelle ; remplacer seulement le nom d’un modèle de chat ne permet pas de conserver le même mode d’appel.
L’interface permet de définir des questions choice, score et boolean, cette dernière forme servant aux jugements oui/non. La documentation evaluation d’AI SDK en décrit le contrat complet. Avec Gateway, la confiance supplémentaire de TypeSafe se lit dans providerMetadata.typesafe.confidence ; elle doit être distinguée des distributions de probabilités présentes dans answers. Cette API reste expérimentale : il convient de revérifier son comportement lors des mises à jour des dépendances.
L’exemple suivant illustre la structure d’une requête à partir d’un scénario de lecture fictif. La clé est fournie par la variable d’environnement serveur AI_GATEWAY_API_KEY, et l’option interdisant l’utilisation des données pour l’entraînement est activée :
import { experimental_evaluate as evaluate } from 'ai';
const result = await evaluate({
model: 'typesafe-ai/jev',
state: {
interest: 'Local speech tools and privacy',
excerpt: 'A fictional offline speech tool caches audio locally.',
},
questions: {
reading: {
type: 'choice',
instructions: 'How relevant is this excerpt to the current interest?',
criteria: {
read: 'Directly useful now',
keep: 'Useful background for later',
skip: 'Unrelated',
unsure: 'Not enough information',
},
},
},
maxRetries: 0,
providerOptions: {
gateway: { disallowPromptTraining: true },
},
});
console.log(result.answers.reading);
Après avoir reçu la réponse à reading, l’application peut afficher directement la suggestion ou ajuster l’ordre de lecture selon les probabilités. Les critères de classification restent ceux que fournit le programme : avec d’autres thèmes d’intérêt, un même contenu peut obtenir un résultat différent.
Interdire l’entraînement et ne conserver aucune donnée sont deux choses distinctes
La passerelle, le fournisseur du modèle et l’application elle-même peuvent tous traiter une même requête. Pour parler de confidentialité, il faut identifier la couche à laquelle s’applique chaque exigence.
L’option disallowPromptTraining de Vercel impose de ne router la requête que vers des fournisseurs satisfaisant à l’interdiction d’entraînement ; elle est disponible avec toutes les offres. Elle ne garantit pas l’absence totale de conservation du contenu. Les requêtes BYOK, qui utilisent une clé fournisseur apportée par l’utilisateur, obéissent en outre à des règles d’application particulières.
L’option zeroDataRetention exige en plus que le fournisseur ne conserve aucune donnée. Le ZDR par requête de Vercel est actuellement réservé aux équipes Pro et Enterprise. La présence d’un modèle dans le catalogue public ne signifie pas qu’un compte peut activer toutes les options de confidentialité.
Utiliser Jev pour orienter les lectures
Cet essai utilisait une présentation fictive d’un outil, rédigée en chinois, accompagnée d’un thème de lecture correspondant. Les sorties possibles étaient « Lire maintenant », « Conserver », « Passer » et « Indéterminé ». Après un envoi via Gateway en mode standard, Jev a choisi « Lire maintenant », avec une probabilité de 1.0. Cette requête a pris environ 0.8 seconde, appel à la passerelle et traitement du résultat compris.
Le thème de cet exemple était bien défini, et le résultat correspondait aux attentes. L’essai a surtout rendu concret le rôle du modèle dans un logiciel : on lui transmet un contenu, il renvoie un choix assorti d’une probabilité, et l’interface peut l’utiliser directement, sans devoir extraire une catégorie d’une longue explication.
Les cas difficiles à départager méritent davantage d’attention pour la suite. Un contenu au sujet pertinent mais creux devrait-il être classé « Lire maintenant » ou « Conserver » ? Avec seulement un titre accrocheur, le modèle peut-il choisir « Indéterminé » de manière fiable ? On peut construire un ensemble d’exemples autour de ces situations, puis comparer les résultats aux choix humains. C’est à travers ces comparaisons que l’on pourra progressivement apprécier la stabilité des jugements en chinois et l’utilité des probabilités.
Dans quels cas l’adopter ?
Un bon point de départ consiste à choisir, dans un système existant, un jugement fréquent, bien délimité et dont les erreurs sont corrigibles. On peut alors vérifier s’il réduit de manière régulière le travail humain avant d’élargir son usage. Plutôt que laisser une seule phrase du modèle décider de tout le workflow, mieux vaut garder dans le programme les opérations calculables avec précision et réserver la compréhension du langage à l’étape qui en a réellement besoin.
Cette répartition peut s’articuler avec une boucle d’agent et aide aussi à comprendre le choix des modèles : le destinataire de la sortie et les conséquences d’une erreur déterminent souvent mieux l’adéquation d’un modèle au travail que la question de savoir s’il est « le plus puissant ».