Jev

Jev est un modèle d’IA de TypeSafe AI conçu pour prendre des décisions structurées dans un logiciel. Il lit un contexte, choisit parmi des options, évalue un critère ou estime la probabilité d’une réponse oui/non. Il peut ainsi orienter une demande, classer un document ou aider à contrôler une étape d’un agent. Il ne rédige pas la réponse destinée à l’utilisateur. (Introduction et primitives TypeSafe [6])

Fiche vérifiée le 22 septembre 2026. Recherche documentaire fondée sur les sources primaires ci-dessous. Les performances attribuées à TypeSafe ou à une étude restent celles de leurs auteurs : NXUS n’a pas réalisé de benchmark d’inférence pour cette fiche. Les exemples pédagogiques et recommandations d’intégration sont identifiés comme tels.

Sommaire du dossier

1. Origine, positionnement et fonctionnement
2. Choice, Score, Noul et confiance
3. Vitesse : promesses et preuves disponibles
4. Où utiliser Jev et quel accès choisir
5. Versions, contexte et contraintes techniques
6. Tarifs et simulations de coûts
7. Cas d’usage et architectures utiles
8. Jev, LLM ou règles classiques ?
9. Limites, sécurité et confidentialité
10. Protocole de test avant adoption
11. Tutoriels HTTP, Python, JavaScript et n8n
12. Bibliographie complète

1. Qui développe Jev, et qu’est-ce qu’un modèle System One ?

TypeSafe AI a annoncé Jev en accès anticipé le 15 septembre 2026. L’équipe présente ce lancement comme l’aboutissement de deux années de développement discret. Le 18 septembre affiché sur OpenRouter correspond à son référencement sur cette plateforme, pas à la première annonce du produit. (Annonce de Jev, 15 septembre 2026 [2] ; Jev 1.13 sur OpenRouter : prix et disponibilité [32])

La société est installée à San Francisco. Sa page équipe présente trois fondateurs : Diogo Almeida, CEO, passé notamment par OpenAI et Google Brain ; Sasha Sheng, COO, auparavant chez Meta/FAIR ; Erik Gafni, CTO. Ce parcours éclaire le projet, sans constituer une preuve de performance du modèle. (Équipe et fondateurs de TypeSafe [3])

Le terme System One renvoie à la distinction popularisée par Daniel Kahneman entre jugement rapide et raisonnement délibéré. Dans Jev, il désigne une spécialisation technique : fournir une décision bornée à un programme. Cela ne démontre ni une conscience, ni une reproduction du cerveau, ni une intelligence générale supérieure. (Comprendre les modèles System One [4])

TypeSafe décrit un entraînement appelé RLCD, Reinforcement Learning for Calibrated Decisions, orienté vers les décisions et leurs probabilités. L’objectif diffère de celui d’un assistant optimisé pour produire une réponse appréciée par un humain. Une bonne calibration signifie, à l’échelle d’un ensemble de prédictions, que les événements estimés à 80 % se produisent environ huit fois sur dix. Elle ne certifie pas un résultat individuel. (RLCD et calibration : présentation technique [5])

L’éditeur annonce également une architecture et un échantillonnage parallèles spécifiques. La documentation produit consultée ne suffit cependant pas à reconstituer l’entraînement ni à auditer les poids. Nous ne renseignons donc pas un nombre de paramètres, une base d’entraînement exhaustive ou une quantité de VRAM qui ne sont pas établis dans ces sources. (Annonce de Jev, 15 septembre 2026 [2])

Exemple original NXUS : dans un logiciel de support, Jev peut renvoyer « facturation » et un niveau d’incertitude. Le logiciel attribue alors le ticket au bon service. Si un texte de réponse est nécessaire, un LLM peut le rédiger à l’étape suivante. L’attribution et la rédaction sont deux opérations distinctes.

2. Le fonctionnement : un contexte partagé et trois types de questions

Une requête contient un state, qui rassemble les données utiles, et des questions, qui décrivent les jugements à effectuer. Le contexte peut être une chaîne de texte, un objet JSON ou un tableau. Des champs explicites, par exemple message_client et politique_retour, rendent plus clair ce que chaque question doit examiner. (Préparer le state [7])

Les formats détaillés sont documentés séparément. (Référence Choice [8] ; Référence Score [9] ; Référence Noul [10])

Choice : choisir dans un espace fermé

Tu définis les choix et leur signification. Pour trier des demandes : « accès au compte », « facturation », « panne » et « autre ». Le champ choice désigne l’option ayant la probabilité la plus forte. Jusqu’à 255 options sont documentées par question. Prévoir « autre » ou « information insuffisante » évite de forcer chaque entrée dans une catégorie inadaptée. (Référence Choice [8])

Exemple illustratif : si les probabilités sont 0,70 pour facturation, 0,25 pour panne et 0,05 pour autre, la sélection est facturation. Ce résultat exprime une préférence relative entre les catégories proposées. Pour détecter plusieurs problèmes simultanés, on peut poser plusieurs questions binaires distinctes.

Score : une échelle décrite, pas un nombre deviné

Les niveaux sont ordonnés et numérotés à partir de zéro. Trois niveaux donnent une échelle de 0 à 2. Le score est une moyenne pondérée par les probabilités ; il peut donc être décimal. La documentation accepte jusqu’à dix niveaux et recommande d’en définir au moins deux. (Référence Score [9])

Exemple calculé : avec 10 % sur « faible » (0), 60 % sur « moyen » (1) et 30 % sur « fort » (2), le score vaut 1,2. Il ne représente ni une gravité objective de 60 %, ni une probabilité de réussite. Une échelle doit rester compréhensible et ne mesurer qu’une dimension.

Noul : estimer oui ou non

Un Noul proche de 1 penche vers oui ; proche de 0, vers non ; autour de 0,5, le modèle hésite entre les deux. Il ne comporte pas de champ confidence séparé. Les critères facultatifs true et false permettent de préciser le sens des deux réponses. (Référence Noul [10])

Pour une boîte de support, « le message demande-t-il explicitement à parler à une personne ? » est plus exploitable que « ce client est-il important ? ». La première question renvoie à un signal observable ; la seconde mélange plusieurs jugements et une politique commerciale implicite.

Probabilité, confiance et exactitude : trois notions différentes

Dans Choice et Score, la confiance résume la forme de la distribution. Elle n’est pas simplement la probabilité du choix retenu. Une distribution étalée indique une hésitation ; une distribution concentrée indique une décision plus nette. Une confiance de 0,9 ne signifie pas automatiquement « 90 % de chances d’avoir raison » dans ton application. Cette relation se vérifie sur un jeu de données représentatif. (Différence entre probabilité et confiance [11])

Notre conseil : conserve séparément le résultat, les probabilités, la confiance et la décision prise par ton logiciel. Tu pourras expliquer si une erreur vient de la classification, d’un seuil mal choisi ou d’une règle métier incorrecte.

3. Pourquoi Jev est rapide, et comment lire les chiffres

Jev évalue plusieurs questions indépendantes sur le même contexte dans un seul appel. Il évite une longue génération de texte et les allers-retours d’une interrogation séquentielle. Les questions ne lisent pas les réponses de leurs voisines : lorsqu’une question dépend réellement d’une réponse précédente, une étape supplémentaire reste nécessaire. (Questions indépendantes en parallèle [19])

TypeSafe annonce des réponses de l’ordre de 70 à 500 ms et affiche 193,6 fois plus rapide et 444,6 fois moins cher pour ses évaluations de workflows. L’éditeur précise que ces facteurs se situent probablement dans la partie haute des gains réels et que les mesures ont généralement été faites depuis la côte ouest américaine. (Annonce de Jev, 15 septembre 2026 [2])

Ce que mesure le benchmark de l’éditeur

Le site d’évaluation couvre quatre familles : incidents de sécurité, observation de traces d’agents, traitement de factures et service client. Chaque système exécute un workflow structuré. Les réponses de référence proviennent d’un consensus de GPT-6 Astra et Claude Fable 5.1, plutôt que d’une vérité terrain humaine exhaustive. Les configurations comparées utilisent les réglages de raisonnement indiqués par le protocole. (Benchmarks de workflows publiés par TypeSafe [24])

Cela permet d’étudier un compromis qualité/coût/temps sur ces workflows. Cela ne donne pas une mesure universelle de l’intelligence. Il faut regarder les décisions finales, la préparation du contexte, les modes de raisonnement, la qualité du système comparé et les cas d’erreur. Une requête de classification isolée n’a pas nécessairement le même gain qu’une chaîne complète.

Une première étude externe, à interpréter avec prudence

Une prépublication du 21 septembre 2026 compare douze configurations sur 20 choix sémantiques répartis dans 10 cas scientifiques, répétés cinq fois. Jev 1.13 y obtient toutes les sélections attendues, comme cinq autres configurations, avec une latence médiane de 335 ms et un p95 de 442 ms sur les réponses réussies. Le coût rapporté est de 0,0595 $ pour 1 000 requêtes de ce test. (Étude externe : Jev for Scientific Decisions, 21 septembre 2026 [25])

C’est un résultat externe intéressant, pas un taux de fiabilité généralisable : le corpus est petit, préparé en anglais, les mêmes cas sont répétés et la préparation des sources n’entre pas dans le coût. L’étude ne démontre pas la robustesse sur des documents français, des entrées adversariales ou des catégories inconnues.

Le regroupement des questions peut compter autant que le modèle

Un cookbook TypeSafe compare treize questions regroupées à treize appels successifs sur un même document. Il rapporte 12,2 fois moins de coût et 10 fois moins de temps. Il utilise Jev 1.12 : ce n’est pas une nouvelle comparaison Jev 1.13 contre tous les LLM. Surtout, l’avantage de temps diminue si les appels séparés sont lancés simultanément. Le partage du contexte conserve son intérêt économique. (Cookbook : comparer questions groupées et appels séparés [26])

À mesurer dans ton projet : durée de bout en bout depuis ton serveur, médiane et p95, taux d’erreur, nouvelles tentatives, coût du secours vers un LLM et qualité finale. Les tokens par seconde, souvent mis en avant pour les chats, ne suffisent pas à comparer un modèle qui renvoie des décisions.

4. Où utiliser Jev aujourd’hui ?

Ces accès sont documentés par l’éditeur ou par les plateformes distributrices elles-mêmes. Ils n’impliquent pas les mêmes quotas, conditions de données ou interfaces. (Démarrage officiel et playground [13] ; OpenRouter Jev Lab : essais interactifs [33] ; Jev dans le catalogue Cloudflare AI [36])

Le Jev Lab propose notamment le tri de messages, le contrôle d’actions d’un agent et la sélection de valeurs déjà présentes dans un texte. C’est une bonne porte d’entrée visuelle pour quelqu’un qui veut comprendre le principe sans commencer par un SDK. Les prix et durées affichés sont ceux de ces démonstrations. (OpenRouter Jev Lab : essais interactifs [33])

Pour OpenRouter, pars de la fiche dédiée et des exemples du Lab : la présence du modèle au catalogue ne signifie pas qu’un client de chat standard sait consommer son interface de décision. Nous ne présentons pas un endpoint expérimental non confirmé comme une intégration stable. (Jev 1.13 sur OpenRouter : prix et disponibilité [32] ; OpenRouter Lab : tri de messages [34])

Cloudflare documente un appel env.AI.run("typesafe/jev", ...) et un accès REST. Sa fiche indique un contexte de 32 000 tokens et renvoie vers le tableau de bord pour le prix. Ne recopie donc pas automatiquement le tarif ou la limite globale de l’API TypeSafe dans un budget Cloudflare. (Jev dans le catalogue Cloudflare AI [36])

Accès local et open source : les références consultées donnent accès à un service hébergé et à des SDK. Elles ne fournissent pas de poids officiels permettant d’exécuter Jev dans Ollama ou LM Studio. Un SDK public n’est pas le modèle lui-même. Les sites communautaires portant « Jev » dans leur nom ne sont pas automatiquement des services TypeSafe.

5. Versions et limites techniques à connaître

Ces limites sont celles de la référence du fournisseur direct. Les revendeurs peuvent appliquer un autre contrat. (Versions, prix, quotas et contexte [12])

Pour traiter un PDF scanné, une capture ou une conversation audio, il faut d’abord produire du texte avec un outil adapté. Cette étape ajoute son propre coût et ses propres erreurs. Une démo de jeu utilisant un état textuel ne prouve pas une perception visuelle native. (Préparer le state [7])

L’anglais est la langue d’entraînement principale indiquée par TypeSafe. Le français est accepté, mais aucune parité de qualité n’est garantie. Teste séparément les messages français, les fautes, les expressions familières et les mélanges de langues. (Versions, prix, quotas et contexte [12])

6. Tarifs : combien coûte réellement une intégration ?

Le tarif public TypeSafe et la fiche OpenRouter affichent 0,042 dollar par million de tokens d’entrée, soit 42 dollars par milliard. Les tokens de sortie sont affichés à 0 dollar. C’est un prix de consommation API, pas un abonnement grand public donnant un usage illimité. (Versions, prix, quotas et contexte [12] ; Jev 1.13 sur OpenRouter : prix et disponibilité [32])

Simulation NXUS : coût d’inférence en dollars = nombre de requêtes × tokens d’entrée facturés par requête ÷ 1 000 000 × 0,042. Le tableau suppose un prix constant et exclut frais de plateforme, taxes, conversion monétaire, infrastructure, prétraitement et appels supplémentaires.

Les tokens facturés comprennent le contexte et les questions, pas uniquement le message utilisateur. Appuie les calculs réels sur usage.input_tokens et sur la facturation du fournisseur. Dix petites questions n’équivalent pas à dix requêtes complètes si elles partagent un seul contexte. (Référence HTTP TypeSafe [14] ; Cookbook : comparer questions groupées et appels séparés [26])

Autre simulation : sur 100 000 dossiers, Jev coûte théoriquement 4,20 $ avec 1 000 tokens par dossier. Si 10 % des dossiers basculent vers un traitement de secours coûtant, par hypothèse, 0,01 $ chacun, ce secours ajoute 100 $. Le taux d’escalade peut donc peser davantage que le prix du premier modèle. Le montant de 0,01 $ est une hypothèse pédagogique, pas le tarif attribué à un fournisseur.

Pour choisir, calcule le coût par dossier correctement traité. Une solution plus rapide sur les cas simples peut devenir moins intéressante si elle augmente les corrections manuelles. Inversement, un contrôle très peu coûteux peut être rentable même s’il n’automatise qu’une petite partie d’un processus.

7. Cas d’usage : ce que l’on peut construire avec Jev

Les scénarios suivants sont des pistes d’intégration, pas des fonctionnalités NXUS déjà déployées. Le logiciel reste responsable des autorisations, des calculs et des actions.

Support client et routage métier

Classer un ticket par intention, détecter une demande de contact humain et évaluer la complexité. Les requêtes simples peuvent suivre une procédure, les réponses rédactionnelles être confiées à un LLM et les cas ambigus à une personne. Le schéma officiel de routage sépare justement l’interprétation de la requête de son traitement. (Routage par intention [20])

Exemple NXUS : une demande de programme de formation, un problème de connexion et une question de facture alimentent trois files différentes. L’indicateur « urgence explicite » peut modifier la priorité sans changer le service destinataire.

Contrôles avant et après un agent

Un outil de décision peut examiner une action proposée : est-elle liée à l’objectif, demande-t-elle une opération sensible, doit-elle passer en relecture ? Le Lab OpenRouter montre ce type de contrôle sur une série d’appels d’outils. Cela aide à rendre visibles les situations à revoir ; les permissions réelles doivent rester imposées dans le code. (OpenRouter Lab : contrôle des actions d’un agent [35])

Recherche documentaire et RAG

Après la recherche de documents, Jev peut évaluer la pertinence des passages, distinguer un élément de preuve d’une contradiction et signaler du texte qui cherche à donner des instructions au modèle. Le générateur reçoit ensuite un contexte mieux organisé. Ce filtre ne remplace ni la recherche initiale ni la vérification finale de la réponse. (Cookbook : filtrer les passages RAG [27])

Vérification de citations

Un premier contrôle déterministe vérifie qu’une citation existe dans la source fournie. Jev peut ensuite aider à classer le rapport entre ce passage et l’affirmation : soutien, contradiction ou absence d’information. Ce découpage est utile pour une veille ou une base de connaissances. Il ne transforme pas une source médiocre en source fiable. (Cookbook : contrôler les citations [28])

Extraction sans réécriture des valeurs

Le code repère les montants, dates ou adresses candidats. Jev choisit celui qui correspond au rôle demandé. Le programme récupère ensuite la valeur originale, sans demander au modèle de la recopier librement. L’intérêt est de réduire les erreurs de transcription ; la sélection sémantique peut toujours être mauvaise. (Cookbook : sélectionner des valeurs déjà extraites [29])

Classement de produits ou de contenus

Pour un catalogue comportant beaucoup de catégories, une classification hiérarchique peut avancer par niveaux plutôt que mettre tout dans un unique choix. Le cookbook dédié décrit notamment le maintien de plusieurs chemins candidats. C’est une piste pour des catalogues ou archives, à évaluer sur leur propre taxonomie. (Cookbook : classification hiérarchique [31])

Notation selon plusieurs dimensions

Au lieu de demander une note globale de qualité, sépare clarté, complétude et adéquation au public. Les pondérations sont ensuite décidées dans le logiciel. Si l’objectif change, modifier les poids devient plus lisible que réécrire un long prompt mêlant toutes les règles. (Combiner plusieurs scores [21])

Exemple NXUS : pour prioriser des documents à relire, une note de complétude peut avoir plus de poids qu’une note de style. Cette formule reste un choix éditorial humain ; elle ne devient pas objective parce qu’un modèle fournit les valeurs.

Modération et contrôles de contenus

Le cookbook de garde-fous illustre des questions séparées sur plusieurs dimensions de risque, puis un routage vers acceptation, contrôle ou blocage. Le dispositif doit inclure des exemples difficiles, des contestations possibles et une mesure des faux positifs. Il ne faut pas confondre capacité à signaler un risque et garantie de protection. (Cookbook : contrôles autour des LLM [30])

8. Comparatif : quand choisir Jev, un LLM ou du code ?

Grille de choix NXUS : cette comparaison porte sur le rôle dans un produit, pas sur un classement général de modèles.

Les LLM savent aussi produire des sorties structurées. L’intérêt potentiel de Jev doit donc se vérifier contre un concurrent correctement configuré pour la même tâche, avec les mêmes données utiles. Une comparaison contre un long texte conversationnel n’isole pas l’effet du modèle.

Pour les agents de développement, TypeSafe précise que Jev ne remplace pas directement le modèle qui écrit le code. Le skill officiel aide un agent à construire une intégration Jev. Il ne transforme pas Jev en assistant de programmation conversationnel. (Jev dans les agents de développement [17])

Dans l’annuaire NXUS, tu peux aussi consulter Claude et ChatGPT pour la génération, ou n8n pour orchestrer les étapes. Ce sont des outils complémentaires dont les rôles diffèrent.

9. Limites, sécurité et confidentialité

Un schéma correct n’est pas une décision correcte

Le vocabulaire marketing sur l’absence d’hallucinations doit être compris dans le cadre des sorties contraintes : ne pas inventer une option n’empêche pas de choisir la mauvaise. TypeSafe documente notamment une lecture parfois trop littérale, des difficultés de calcul et de comparaison de dates, les raisonnements indirects et la dégradation liée au contexte inutile. (Limites connues de Jev 1.13 [23])

Autres limites publiées : un texte adversarial peut influencer le jugement ; deux questions reformulées ne garantissent pas toutes les identités logiques que l’on pourrait attendre ; des instructions et critères contradictoires diminuent la fiabilité. Noul et Choice ne doivent pas partager automatiquement le même seuil de décision. (Limites connues de Jev 1.13 [23])

Conséquence pratique : ajoute des règles déterministes pour les montants, les droits d’accès et les transitions d’état. Une classification « demande de remboursement » ne prouve ni que le demandeur possède la commande, ni que le remboursement est autorisé.

Conserver une voie de repli

Une décision incertaine doit pouvoir être traitée autrement : nouvelle information, modèle plus adapté ou relecture. Les seuils varient selon les conséquences d’une erreur. Les exemples numériques de la documentation sont des points de départ pédagogiques, pas des seuils certifiés pour ton activité. (Routage selon la confiance [22])

En cas de panne ou de réponse manquante, définis une issue explicite. Pour une opération sensible, l’absence de réponse ne doit pas être interprétée comme une autorisation. Mesure aussi le coût opérationnel de cette stratégie : délai, file de relecture et nombre de dossiers non traités.

Données : distinguer entraînement et conservation

La politique TypeSafe indique que les entrées ne servent pas à entraîner ou affiner les modèles. Elle mentionne néanmoins une collecte des données nécessaires au service, une conservation selon les finalités et un hébergement aux États-Unis. Absence d’entraînement ne signifie donc pas absence de stockage. (Politique de confidentialité TypeSafe [38])

La documentation juridique propose une option zero data retention pour les clients entreprise, à discuter avec TypeSafe. Le DPA décrit le rôle de sous-traitant et les mécanismes contractuels de transfert. La présence de ces documents ne suffit pas à certifier la conformité de chaque usage, notamment lorsque des données personnelles sont transmises via une autre plateforme. (Documents contractuels et option ZDR [37] ; Accord de traitement des données TypeSafe [39])

Avant une intégration métier, clarifie les données envoyées, leur localisation, la durée de conservation, les sous-traitants et la suppression. Pour un prototype, un jeu de tickets fictifs ou anonymisés permet déjà d’évaluer le comportement sans exporter une base client entière. Ne transmets pas de clé API dans le contexte à analyser.

10. Comment évaluer Jev avant de l’adopter

Protocole proposé par NXUS. Il sert à prendre une décision d’intégration ; il ne remplace pas un audit spécialisé lorsqu’un usage l’exige.

1. Choisir une décision précise. Commence par une catégorie de support, un type de document ou la pertinence d’un passage. Évite d’évaluer simultanément un produit entier.
2. Définir la vérité terrain. Fais annoter des exemples réels et les désaccords par les personnes qui connaissent la tâche. Note explicitement les cas où aucune réponse n’est possible.
3. Séparer réglage et évaluation. Utilise un groupe d’exemples pour écrire les critères, un autre pour le contrôle final. Répéter les mêmes messages ne crée pas de nouveaux cas indépendants.
4. Inclure les cas difficiles. Message court, demande mixte, négation, faute, français familier, information absente, donnée périmée et instruction malveillante insérée dans le texte.
5. Comparer une référence pertinente. Règles existantes, petit LLM avec sortie structurée ou classifieur disponible. Conserve la même information utile et le même objectif.
6. Mesurer plusieurs dimensions. Exactitude par classe, faux positifs, faux négatifs, taux d’abstention, latences p50/p95, erreurs techniques et coût global. Un score moyen peut masquer une catégorie catastrophique.
7. Choisir les seuils sur les conséquences. Une mauvaise file de support et une mauvaise autorisation d’action n’ont pas le même coût. Évalue la couverture automatique obtenue au niveau de qualité souhaité.
8. Commencer en observation. Le système propose ses décisions pendant que le processus actuel continue. Les divergences montrent ce qu’il faut corriger avant d’agir automatiquement.
9. Journaliser sans accumuler les données sensibles. Conserve version du modèle, version des questions, décision, métriques et références minimales nécessaires à la relecture.
10. Prévoir les changements. Une nouvelle version, un nouveau public ou une nouvelle offre modifie la distribution des demandes. Rejoue le jeu d’évaluation avant d’étendre l’automatisation.

Pour une première exploration, quelques dizaines d’exemples peuvent révéler les défauts évidents. Ils ne permettent pas d’affirmer une fiabilité de 99,9 %. Le volume nécessaire dépend de la rareté des erreurs, du nombre de catégories et de l’usage prévu.