Jev Agent Builder : préparer une décision typée sans écrire de JSON

Trois types de questions, d'après la documentation de TypeSafe. Choice choisit une option dans une liste que vous fournissez, jusqu'à 255, et renvoie l'option, la probabilité de chacune et une confiance. Score place l'état sur une échelle de 2 à 10 niveaux que vous décrivez, et la position peut tomber entre deux niveaux. Noul répond à une affirmation par une probabilité entre 0 et 1 : proche de 1, oui franc ; proche de 0, non franc ; autour de 0,5, le modèle ne sait pas.

Les questions d'un même appel sont évaluées en parallèle et isolément, sur le même état. Une question n'influence pas la réponse d'une autre. TypeSafe recommande donc des questions atomiques : un jugement complexe se découpe en plusieurs questions simples, et c'est votre code qui les combine.

Ce qui change pour une PME, c'est la probabilité. Un modèle de chat répond avec la même assurance qu'il ait raison ou non. Une décision accompagnée d'une probabilité calibrée permet d'écrire une règle honnête : au-dessus d'un seuil, le scénario continue ; en dessous, la demande va à une personne. C'est la couche « décision rapide et calibrée » décrite sur notre page ingénierie.

Ce qu'il ne fait pas. Il ne rédige pas de réponse au client, ne résume pas un document, n'explique pas sa décision en phrases. Il ne connaît pas vos données au-delà de l'état que vous lui passez. Et il ne corrige pas une liste d'options mal définie : si vos motifs se chevauchent, ses probabilités se partageront entre eux, ce qui est honnête mais inutilisable.

Un formulaire à gauche, la requête à droite. Vous nommez l'agent, choisissez le modèle (jev-latest pour la dernière version stable, ou un identifiant versionné pour figer le comportement), écrivez l'état, puis ajoutez vos questions. Le JSON pour POST /v1/systemone se met à jour à chaque frappe, avec une estimation des tokens et du coût pour 1 000 appels.

Les paramètres font le reste. Écrivez {{ticket}} dans l'état, {{motifs}} comme source des options d'un Choice, et le même agent sert pour chaque ticket et pour une liste de motifs qui évolue. L'onglet « Agent (template) » exporte cette définition avec ses paramètres intacts, à versionner avec votre code. L'onglet « Requête » montre la version résolue, avec des valeurs de test.

La validation suit la documentation : identifiant en double, paramètre utilisé mais jamais défini, paramètre défini mais inutilisé, Choice à une seule option (Jev la choisira toujours), Score dont un niveau n'est qu'un chiffre, dépassement des 64 000 tokens par requête ou des 32 000 par question. Une case ajoute l'option none_of_the_above, pour que Jev puisse dire que rien ne convient.

Pour sortir du navigateur : la requête brute, la définition réutilisable, une commande cURL, ou une fonction TypeScript qui remplit les paramètres et appelle l'API. Un bouton ouvre la requête dans le Playground de TypeSafe, pour tester sur le vrai modèle. L'outil lui-même n'envoie rien : c'est un seul fichier HTML, le brouillon reste dans le stockage local du navigateur, et votre clé d'API n'y est jamais saisie.

Reprenons le flux de notre cas type industrie et SAV : 120 demandes par semaine, six motifs qui couvrent 72 % du volume, et une personne qui lit chaque email pour l'orienter. L'état est l'email du client, passé en paramètre {{demande}}. Trois questions suffisent.

Un Choice « motif », avec les six motifs décrits en une phrase chacun et l'option none_of_the_above cochée : une demande hors liste doit pouvoir le dire, plutôt que d'être rangée de force dans le motif le plus proche. Un Score « urgence », sur quatre niveaux décrits comme des situations (« machine à l'arrêt, production bloquée »), pas comme des degrés (« très urgent ») : le builder le signale si un niveau n'est qu'un chiffre. Un Noul « demande_avoir » : le client demande-t-il explicitement un remboursement ou un avoir ?

La règle est écrite dans le scénario, pas dans le modèle. Si la confiance du motif dépasse le seuil retenu, la demande part dans la bonne file. Sinon, ou si la réponse est none_of_the_above, elle va à la personne qui triait jusque-là. Si demande_avoir dépasse 0,8, la demande est marquée pour le responsable SAV, qui reste le seul à créer un avoir. Le seuil ne se devine pas : il se fixe sur quelques centaines de demandes déjà triées à la main, en regardant où les erreurs commencent.

Rien dans ce flux n'est un agent. Le chemin est fixe, une étape de décision remplace une lecture humaine, et l'humain garde les cas incertains et l'action qui coûte. C'est exactement le schéma « IA dans une étape, puis une règle » de l'article précédent.

Les identifiants de question ne sont pas envoyés au modèle : ils servent à votre code. Toute la question doit donc tenir dans les instructions. « motif » ne dit rien à Jev ; « Quel est le motif principal de la demande du client ? » si.

Décrivez les options, pas seulement leur nom. « Retour » et « Échange » se confondent ; « Le client veut renvoyer le produit et être remboursé » et « Le client veut le même produit en état de marche » se séparent.

Pour un Score, décrivez une situation à chaque niveau. Pour un Noul, définissez ce qui compte comme oui et comme non si la frontière n'est pas évidente. Et n'utilisez pas un Noul pour une intensité : 0,5 veut dire que le modèle hésite, pas « moyennement ».

Jev est surtout entraîné en anglais. Le français est accepté, avec une précision un peu plus faible. Sur un flux en français, testez sur vos propres données avant de fixer un seuil, et comparez avec des instructions rédigées en anglais si l'écart vous gêne.

Notre position n'a pas changé depuis la page ingénierie : nous testons Jev sur nos cas, nous ne le déployons pas encore chez nos clients. Le modèle est en accès anticipé, sur liste d'attente, et un composant à ce stade n'a rien à faire dans un système de production sans solution de repli. Le builder sert justement à cette phase : écrire les questions, les tester sur des données réelles, mesurer, avant de décider quoi que ce soit.

Le coût annoncé par TypeSafe est de 0,042 $ par million de tokens en entrée, et la sortie n'est pas facturée. TypeSafe précise ne pas pouvoir garantir que ce prix n'est pas subventionné. La latence annoncée est de 70 à 500 ms de bout en bout, mesurée depuis la côte ouest des États-Unis. Ce sont des chiffres d'éditeur, à vérifier sur votre flux. La comparaison avec un modèle génératif léger, coût par appel compris, est dans notre comparatif Claude Haiku ou Jev.

Et la règle de nos autres articles vaut ici aussi : un modèle de décision sur une liste de motifs que personne ne maintient, ou sur des données que l'équipe conteste, reproduira le désordre plus vite. La liste d'options est un référentiel. Elle a besoin d'un propriétaire avant d'avoir besoin d'un modèle.

TypeSafe AI, « Introducing System One models and Jev », 15 septembre 2026 : accès anticipé sur liste d'attente, 0,042 $ par million de tokens en entrée, sortie non facturée, latence de 70 à 500 ms, probabilités calibrées. Article TypeSafe AI.

TypeSafe AI, documentation : introduction, types de questions Choice, Score et Noul, évaluation parallèle et isolée, recommandation de questions atomiques. Introduction, Primitives.

Jev Agent Builder, version 0.3, licence MIT, outil non officiel sans lien avec TypeSafe AI. Outil en ligne, code source.