Jev par TypeSafe AI : Nouveautés, fonctionnement et alternatives (2026)
La plupart des lancements de modèles cette année visaient à en faire plus. Celui-ci vise à en faire moins, délibérément.
TypeSafe AI a lancé un modèle qui ne discute pas, n'écrit pas et ne s'explique pas. Il répond aux questions par des valeurs typées et des probabilités. C'est là toute l'interface du produit.
Ce guide présente ce qu'est le modèle et comment fonctionnent ses trois types de questions. Il aborde également les tarifs, ce pour quoi le fournisseur le juge peu performant, et sa place par rapport au travail que la plupart des équipes ont réellement à accomplir.
Ce qui a été lancé
Jev est le modèle phare de TypeSafe AI. Selon la documentation officielle du fournisseur, il s'agit également du « premier modèle System One ».
La présentation part d'un constat critique sur le fonctionnement du reste de la catégorie. Les grands modèles de langage, explique la documentation, « sont conçus pour produire du texte destiné à être lu par des humains ». Lorsque vous avez besoin d'un jugement destiné à être traité par votre code, « cela crée un décalage ».
La documentation détaille ce décalage. Vous devez « contraindre un système de génération de texte à produire des décisions structurées, puis analyser les résultats pour les convertir en un format exploitable par votre code ».
L'alternative proposée élimine cet aller-retour. Jev « évalue des questions typées par rapport à un état et renvoie directement des résultats structurés. Pas de génération de texte, pas d'analyse syntaxique ».
Le site de l'entreprise inscrit Jev dans une lignée historique. D'abord les premiers modèles de langage, puis les LLM pré-entraînés, puis les modèles de chat RLHF, puis les modèles de raisonnement RLVR. Aujourd'hui le RLCD, qu'elle définit comme « l'apprentissage par renforcement pour des décisions calibrées ».
Ce qu'est un modèle System One
Le nom est emprunté, et la documentation le précise directement. Il « provient du concept popularisé par Daniel Kahneman dans son livre Système 1 : la pensée rapide, Système 2 : la pensée lente ».
Le Système 1 est rapide et intuitif. Le Système 2 est plus lent et réfléchi. Ici, « l'accent est mis sur des jugements rapides et ciblés ».
La définition fonctionnelle est plus étroite que la métaphore. Il s'agit d'une « catégorie de modèles d'IA conçus pour prendre des décisions rapides et structurées que les logiciels peuvent utiliser directement ». Un tel modèle « évalue un état et renvoie des réponses typées ainsi que des probabilités ».
Une seule phrase distingue Jev de tout le reste du marché. « Comme un LLM, un modèle System One comprend les entrées en langage naturel. Il renvoie des décisions typées et des probabilités plutôt que du texte généré. »
Ce qu'il ne fait pas est également clairement énoncé par le fournisseur. Les modèles System One « n'écrivent pas de réponses, ne produisent pas de code et ne génèrent pas d'explications sur leur raisonnement ».
Les trois types de questions
Vous ne promptez pas Jev. Vous définissez un espace de réponses, et il choisit à l'intérieur de celui-ci.
Il existe trois primitives. La documentation fournit un exemple pour chacune d'elles.
| Primitive | Question | Espace de réponses | Sortie |
|---|---|---|---|
| Choice | Quelle équipe doit traiter ce ticket ? | billing, technical ou account | choice: "billing" |
| Score | À quel point ce client est-il frustré ? | 0 = calme, 1 = frustré, 2 = très frustré | score: 1.4 |
| Noul | Ce message demande-t-il un remboursement ? | Vrai ou faux | noul: 0.95 |
Choice sélectionne une option parmi un ensemble défini. Score évalue par rapport à des niveaux ordonnés et descriptifs. Noul renvoie la probabilité qu'une question de type oui/non soit vraie.
L'exemple de Score mérite qu'on s'y attarde. La réponse est 1.4, et non 1. Jev positionne le cas entre deux niveaux définis plutôt que de se caler sur le plus proche. C'est un format de sortie bien différent de tout ce qu'un modèle de texte peut renvoyer.
Ce qu'il coûte et ce qu'il accepte
La page des tarifs est d'une clarté inhabituelle. Ce n'est pas le genre de chose que l'on écrit souvent lors du lancement d'un modèle.
Le modèle actuel est jev-1.13.0. Le tarif est de $42 par milliard de tokens, ou $0.042 par million. La documentation précise explicitement que la facturation se fait « par token d'entrée » et que « les tokens de sortie sont gratuits ».
Les limites de débit publiées sont de 250 000 tokens par seconde et 1 200 requêtes par minute. La longueur du contexte est de 64k tokens par requête. Sur ce total, 32k sont disponibles pour l'état plus la question la plus longue.
L'entrée se fait uniquement sous forme de texte. La documentation indique que Jev « évalue des chaînes de caractères, des objets JSON et des tableaux de texte ». Elle ajoute que « les images, l'audio et la vidéo ne sont pas (encore) pris en charge ».
Tout passe par un point de terminaison unique, POST /v1/systemone. Un champ model permet de sélectionner le modèle qui gère l'appel.
| Propriété | Valeur |
|---|---|
| Modèle | jev-1.13.0 |
| Tarif | $42 par milliard de tokens / $0.042 par million de tokens, entrée uniquement |
| Tokens de sortie | Gratuits |
| Limites de débit | 250 000 tokens par seconde ; 1 200 requêtes par minute |
| Contexte | 64k par requête ; 32k pour l'état plus la question la plus longue |
| Types d'entrée | Texte uniquement |
La confiance est l'élément auquel il faut prêter attention
Les tarifs font les gros titres. La gestion de la confiance est la décision de conception la plus intéressante.
Chaque réponse de type Choice et Score comporte une propriété probabilities pour l'ensemble des options ou des niveaux. La documentation explique comment l'interpréter. Une distribution « concentrée sur un seul résultat signifie une réponse confiante, tandis qu'une distribution dispersée indique une réponse incertaine ».
Une propriété confidence distincte résume cette distribution en un chiffre unique de 0 à 1. L'objectif documenté est de « vous permettre de définir un seuil sans avoir à faire les calculs vous-même ».
Le raisonnement qui sous-tend la fourniture de ce chiffre est posé comme un principe. « Si un système intelligent, qu'il soit humain ou machine, ne peut pas exprimer une incertitude honnête, on ne peut pas lui faire confiance. »
Ce que cela vous apporte, c'est une règle d'aiguillage plutôt qu'une meilleure réponse. Une confiance élevée permet un traitement direct. Une confiance faible est redirigée vers un humain. La documentation présente cela comme le fait de décider « quand agir et quand transmettre à une personne ou à un modèle de raisonnement ».
Quiconque a déjà déployé un pipeline de classification comprend pourquoi cela est crucial. C'est le parcours d'escalade, et non le taux de précision, qui détermine si le système survit à la confrontation avec des données réelles.
Ce pour quoi le fournisseur le juge peu performant
TypeSafe publie une page intitulée « model jaggedness » (irrégularité du modèle), révisée le 17 septembre 2026. Elle répertorie les modes de défaillance connus de l'entreprise. Publier cela en même temps qu'un lancement est rare, et cela évite à tout le monde de devoir deviner.
La ligne de résumé est franche. Jev 1.13 « est rapide, calibré et doué pour le jugement de bon sens, mais il n'est pas parfait ».
Trois faiblesses sont directement nommées. Il « peut éprouver des difficultés avec les tâches qui nécessitent des niveaux d'indirection supplémentaires ». Il « peut être très littéral dans sa compréhension ». Et il « peine sur les tâches qui exigent de la précision numérique ».
Le tableau des modes de défaillance associe chacun d'eux à un remède. Deux d'entre eux méritent d'être soulignés pour quiconque évalue un projet pilote.
- Pour les mathématiques et les chiffres, le conseil documenté est de « garder l'arithmétique dans le code ».
- Pour un état volumineux rempli de détails non pertinents, il est de « filtrer d'abord ; n'envoyer que ce dont la question a besoin ».
Tous deux pointent vers la même hypothèse de conception. Il s'agit d'un moteur de jugement, pas d'une calculatrice ni d'un index de recherche. Il fonctionne de manière optimale lorsque le système environnant a déjà ciblé la question.
Sa place par rapport à vos processus existants
Une division claire du travail se cache dans l'exemple même du fournisseur. L'identifier permet de déterminer si ce lancement vous concerne ou non.
Le flux de travail de remboursement documenté construit un état et pose plusieurs questions indépendantes à la fois. Il combine ensuite les réponses « avec des vérifications déterministes dans le code » et oriente le dossier « pour action ou révision ».
Chaque étape suppose ici un développeur, une application et un volume de requêtes élevé. Le coût par token doit représenter un poste de dépense réel pour que tout cela devienne rentable.
La plupart des travaux de reporting se présentent sous une autre forme. Vous disposez d'un fichier plutôt que d'un flux de requêtes. Les jugements sont un moyen plutôt que le produit final. Ce qui doit exister au bout du compte, c'est un document lu par quelqu'un.
Classer quatre mille lignes de retours clients constitue le milieu de cette tâche. La fin consiste en un résumé identifiant les trois thèmes principaux et signalant les exceptions.
C'est cette seconde moitié qu'un espace de travail axé sur les fichiers prend en charge. Vous importez l'export et décrivez les catégories en langage naturel. Les lignes vous reviennent étiquetées, et le rapport explicatif est généré au cours de la même étape. Powerdrill Bloom fonctionne ainsi, et sa version gratuite couvre déjà les présentations, documents, feuilles de calcul et images de base.
Les deux ne rivalisent pas pour le même créneau. L'un est une API que vous intégrez à un produit. L'autre est l'endroit où l'on envoie une feuille de calcul quand on a besoin d'une réponse pour jeudi. Si votre version de ce problème se présente sous la forme d'un fichier, essayez Powerdrill Bloom.
Pour la version de la tâche d'étiquetage côté feuille de calcul, vous trouverez un guide sur la catégorisation des données Excel. Pour la recherche de thèmes, voici un comparatif des outils d'analyse des retours clients.
Des alternatives qui méritent d'être comparées
Trois approches couvrent le même besoin. Le bon choix dépend principalement du volume.
Modèles généralistes avec sortie structurée. Tous les grands fournisseurs contraignent désormais les réponses à un schéma. Vous disposez d'un seul modèle pour juger et générer. L'inconvénient est de payer le prix de la génération pour un travail de jugement, et de devoir effectuer votre propre calibrage.
Classificateurs classiques. Un petit modèle affiné ou un arbre de décision optimisé par gradient (gradient-boosted tree) est encore moins cher et totalement prévisible. Cela reste vrai à condition de disposer de données étiquetées et d'un ensemble d'étiquettes stable. Il ne comprendra pas une politique rédigée en prose.
Espaces de travail d'analyse axés sur les fichiers. Ceux-ci traitent le jugement comme une étape parmi d'autres dans la production d'un livrable. Pas d'API, pas de schéma, pas de budget par token. Mais ils ne peuvent pas non plus s'intégrer dans un flux de requêtes.
| Si votre situation est | Tournez-vous vers |
|---|---|
| Des millions de jugements au sein d'un produit | Un modèle dédié uniquement aux décisions |
| Mélange de jugement et de rédaction, faible volume | Un modèle généraliste avec sortie structurée |
| Étiquettes stables et données d'entraînement abondantes | Un classificateur classique |
| Un fichier qui doit devenir un rapport | Un espace de travail axé sur les fichiers |
Il existe un comparatif connexe sur les outils de génération de rapports couvrant ce dernier point.
Qui devrait s'y intéresser dès maintenant
Les équipes qui gèrent un volume élevé de jugements au sein d'un produit ont le cas d'usage le plus évident pour Jev. L'aiguillage des tickets, les files de modération, la qualification des leads et les pré-vérifications d'éligibilité s'y prêtent parfaitement. Le schéma type est une question précise posée des milliers de fois par jour, qui alimente une branche de code.
Les équipes qui effectuent des classifications occasionnelles dans le cadre d'analyses ont l'intérêt le moins évident. Les avantages économiques qui rendent Jev attractif à grande échelle sont invisibles sur quelques milliers de lignes. De plus, vous aurez toujours besoin de quelque chose pour rédiger le résumé par la suite.
Tous les autres ont plutôt un vocabulaire à emprunter qu'un outil à adopter. Séparer le jugement rapide de la synthèse lente offre une perspective utile sur votre propre pipeline. Cela reste pertinent, que vous envoyiez ou non une requête à cette API.
Une dernière note pratique pour quiconque évalue la solution. Lisez la page sur l'irrégularité du modèle (jaggedness) avant celle des tarifs. Connaître les faiblesses d'un modèle oriente bien plus le projet pilote que de savoir ce qu'il coûte.
Foire aux questions
Qu'est-ce qu'un modèle System One ?
Il s'agit d'une catégorie de modèles conçus pour prendre des décisions rapides et structurées que les logiciels peuvent utiliser directement. Il évalue un état et renvoie des réponses typées ainsi que des probabilités. Son nom fait référence au Système 1 de Kahneman, le mode de pensée rapide et intuitif. Contrairement à un modèle de chat, il n'écrit pas de réponses, ne produit pas de code et n'explique pas son raisonnement.
Combien coûte Jev ?
Le tarif publié pour jev-1.13.0 est de $42 par milliard de tokens, ou $0.042 par million. La facturation s'applique uniquement aux tokens d'entrée, et les tokens de sortie sont gratuits.
Que peut recevoir Jev en entrée ?
Uniquement du texte, sous forme de chaînes de caractères, d'objets JSON ou de tableaux de texte. La documentation précise que les images, l'audio et la vidéo ne sont pas encore pris en charge. Le contexte est de 64k tokens par requête, dont 32k pour l'état plus la question la plus longue.
En quoi est-ce différent de demander du JSON à un LLM ?
Les deux comprennent les entrées en langage naturel. La différence réside dans le résultat renvoyé et la méthode d'entraînement. Jev renvoie des décisions typées accompagnées d'une distribution de probabilité et d'une valeur de confiance. Le calibrage étant mesuré sur des groupes de prédictions, il ne garantit pas l'exactitude de chaque réponse individuelle.
Qu'est-ce que Jev ne fait pas bien ?
La page sur l'irrégularité du modèle (jaggedness) du fournisseur mentionne la lecture littérale, les mathématiques et les chiffres, ainsi que la comparaison de dates et d'heures. Elle cite également l'indirection, les états volumineux remplis de détails non pertinents, les contenus contradictoires et les critères contradictoires. Pour l'arithmétique, le conseil documenté est de garder l'arithmétique dans le code.
Sources : Documentation de TypeSafe AI — Introduction, System One, Models, Confidence, et Jev 1.13 jaggedness, docs.typesafe.ai, au 18 septembre 2026.