Jev de TypeSafe AI : cas d’usage et tutoriel

« Le produit est excellent, mais mon colis est arrivé avec quatre jours de retard. »

Pour une équipe expérience client, cet avis contient deux informations utiles : le produit satisfait l’acheteur ; la livraison pose problème. Encore faut-il transformer cette phrase en catégories exploitables dans un tableau de bord, puis retrouver les mêmes sujets dans des milliers d’autres commentaires.

C’est un bon exemple de ce que Jev, le modèle de TypeSafe AI, peut apporter à un département data et IA : lire du texte et répondre à des questions précises sous une forme que le code peut utiliser immédiatement. Classer un avis. Orienter une demande. Évaluer si un passage documentaire répond à une question. Vérifier un critère avant de poursuivre un traitement.

Présenté le 15 septembre 2026, Jev est encore récent. L’intérêt pour une entreprise française consiste à identifier les petites décisions répétitives où il mérite un essai, puis à mesurer ses résultats sur ses propres données. Cet article propose sept cas d’usage, plusieurs idées de classification et un tutoriel Python consacré aux avis clients. Annonce de TypeSafe AI.

Documentation et tarifs consultés le 19 septembre 2026. Les scénarios métier ci-dessous sont des exemples d’application, pas des références de déploiements clients.

Dans ce guide :

• Comprendre Jev et ses trois types de réponses
• Comparer un traitement avec un LLM et avec Jev
• Comprendre ce qu’on gagne à passer à Jev
• Choisir entre Jev, des règles et un autre modèle
• Classifier les avis clients et d’autres textes métier
• Explorer six autres cas d’usage
• Évaluer les coûts, les performances et les conditions d’utilisation
• Tutoriel : classifier ses premiers avis clients en Python

Qu’est-ce que Jev de TypeSafe AI ?

TypeSafe AI est l’éditeur ; Jev est son modèle d’IA préentraîné, spécialisé dans les décisions à partir de texte. Pour votre équipe data, il se présente comme un service que l’on appelle depuis un programme : on lui fournit un contenu et des critères, il renvoie des choix, des scores et des probabilités. TypeSafe appelle cette famille de modèles « System One ». La documentation de présentation décrit ce fonctionnement.

Concrètement, un développeur peut intégrer Jev dans le traitement nocturne d’un fichier d’avis, dans le service qui reçoit vos tickets ou dans une étape de votre assistant documentaire. Il obtient une clé API, installe le SDK ou utilise une requête HTTP, puis transmet les données à évaluer. Le Playground sert à essayer les questions avant cette intégration.

Vous définissez les critères au moment de l’appel, en langage naturel. Par exemple : « Cette demande concerne-t-elle un problème de paiement ? » Le démarrage ne nécessite pas d’entraîner votre propre modèle. TypeSafe indique que les comptes utilisent les mêmes poids ; l’adaptation à votre métier se fait par le contexte, les consignes et la description des réponses possibles. Un corpus annoté reste nécessaire pour vérifier la qualité sur votre domaine. Personnalisation du comportement de Jev.

Ce que vous envoyez, ce que vous recevez

Prenons un message : « J’ai été débité deux fois, merci de me rembourser ». Un appel à Jev contient trois éléments :

1. Le contenu à examiner, nommé state : ici, le message du client, éventuellement accompagné d’informations utiles issues du dossier.
2. Les questions : quel service devrait traiter la demande ? Un remboursement est-il demandé ?
3. Les réponses autorisées : par exemple, facturation, support technique, commercial ou autre pour le service destinataire.

Le state peut être une chaîne de texte ou un objet JSON. Il appartient à votre application de récupérer les données dans le CRM, l’ERP ou le stockage documentaire, puis de transmettre le contexte nécessaire. Préparation du contenu à évaluer.

En retour, votre programme récupère des valeurs qu’il peut lire directement : une catégorie parmi celles prévues, la probabilité qu’une propriété soit présente, une note sur une échelle définie. Il peut ensuite les enregistrer dans une base ou proposer une affectation dans l’outil de support.

Choice, Noul et Score : trois façons de poser une question

Type de question	Ce que Jev renvoie	Exemple métier
Choice	Un choix parmi vos options, avec leur distribution de probabilités	Affecter un ticket à la facturation, au support technique ou au service commercial
Noul	La probabilité que la réponse à une question soit « oui », entre 0 et 1	Déterminer si un avis mentionne la livraison
Score	Une position sur une échelle dont vous décrivez les niveaux	Évaluer la pertinence d’un document : hors sujet, partiellement utile, directement utile

Choice choisit une seule option. Pour un avis qui parle à la fois du produit et de la livraison, utilisez plusieurs questions Noul indépendantes. Un Score convient à une appréciation graduée ; sa valeur peut être décimale, car elle résume une distribution sur les niveaux décrits. Choice, Noul, Score.

Les questions d’un même appel sont évaluées sur le même contenu. Elles doivent pouvoir être comprises séparément : une question ne lit pas la réponse de sa voisine. Si une décision dépend d’un résultat précédent, votre code organise les étapes. Référence de l’API.

Ce que le modèle laisse à votre application

Jev ne rédige pas de réponse au client et ne fournit pas d’explication libre de son jugement. Il ne rembourse personne et ne modifie pas votre ERP. Votre application choisit l’action à partir des résultats.

Pour un avis client, la chaîne ressemble donc à ceci :

Avis collecté → Jev → thèmes et sentiment proposés
                   → règles de contrôle → tableau de bord ou file de relecture

Cette séparation permet de remplacer ou de réévaluer le modèle sans lui confier les règles métier qui décident d’un remboursement, d’un accès ou d’une publication.

LLM ou Jev : comment traite-t-on le même avis client ?

Reprenons l’avis du début : « Le produit est excellent, mais mon colis est arrivé avec quatre jours de retard. » Le besoin est simple : identifier les thèmes et le sentiment, puis remplir des colonnes dans une base de données.

Avec un LLM : demander une réponse dans un format défini

Vous envoyez au modèle l’avis, la définition des catégories et une consigne de classification. Une intégration adaptée peut imposer un schéma JSON et obtenir une réponse de cette forme :

{
  "themes": ["produit", "livraison"],
  "sentiment": "mixte"
}

C’est un exemple illustratif, pas le résultat d’un appel. Un LLM peut parfaitement effectuer ce travail, traiter plusieurs critères dans une même requête et produire une sortie contrainte. Les sorties structurées documentées par Anthropic en donnent un exemple. Une comparaison sérieuse doit utiliser ces possibilités.

Le modèle génératif produit sa réponse sous forme de tokens, les unités utilisées pour représenter le texte. Même lorsque la sortie est du JSON, la réponse reste générée. Sa durée dépend notamment du modèle, de la longueur de l’entrée et de la sortie, et de l’éventuel raisonnement activé. Cette souplesse permet aussi de demander une justification, un résumé ou une réponse à envoyer au client.

Avec Jev : définir les décisions à évaluer

Vous transmettez le même avis et des questions séparées : présence du thème produit, présence du thème livraison, choix du sentiment global. Pour chacune, le format possible est fixé par une primitive : Noul ou Choice dans cet exemple.

Question envoyée	Réponse illustrative de Jev	Ce que votre code peut en faire
L’avis parle-t-il du produit ?	Probabilité de « oui » : 0,98	Proposer l’étiquette produit
L’avis parle-t-il de la livraison ?	Probabilité de « oui » : 0,96	Proposer aussi l’étiquette livraison
Quel sentiment est exprimé ?	Choix : mixte, accompagné des probabilités de chaque option	Enregistrer le sentiment et repérer les cas ambigus

Les chiffres de ce tableau sont fictifs. Ils montrent ce que l’interface fournit ; les seuils de décision doivent être réglés sur des résultats réels.

Selon TypeSafe, Jev calcule les sorties en parallèle, au lieu de générer une suite de tokens de réponse. L’API restitue ensuite ces valeurs sous forme structurée. C’est cette spécialisation qui explique le potentiel de gain de temps lorsque votre application demande surtout des décisions courtes. Présentation technique de TypeSafe.

Ce qui change réellement entre les deux approches

Point de comparaison	LLM avec sortie structurée	Jev
Travail demandé	Générer une réponse qui respecte le schéma prévu	Évaluer les questions dans les formats Choice, Noul et Score
Résultat utilisable	Catégories et autres champs définis par votre schéma	Choix, scores et probabilités exposés par l’API
Plusieurs critères	Peuvent être regroupés dans un appel	Peuvent être regroupés et sont évalués en parallèle
Traitement de l’incertitude	À construire et à évaluer selon le modèle et la méthode choisis	Probabilités fournies nativement, à évaluer sur votre domaine
Explication et rédaction	Peut produire un raisonnement explicatif, un résumé ou une réponse client	Nécessite un autre composant pour produire ces textes
Qualité métier	À mesurer sur vos exemples	À mesurer sur les mêmes exemples

Les deux approches peuvent donc remplir les mêmes colonnes « thèmes » et « sentiment ». Le choix porte sur le coût, la rapidité et la qualité de cette opération, ainsi que sur ce dont votre application a besoin autour.

Pourquoi les probabilités sont une partie du produit

TypeSafe décrit un entraînement nommé RLCD, pour Reinforcement Learning for Calibrated Decisions. L’objectif annoncé est d’associer les décisions à des probabilités qui reflètent leur fiabilité. Si un modèle est bien calibré sur un domaine, des événements auxquels il attribue une probabilité de 0,80 devraient se réaliser dans environ 80 % des cas comparables. C’est une propriété qui se mesure sur un ensemble de prédictions. Explication de l’entraînement RLCD.

Pour une équipe data, cela fournit un signal à tester pour organiser la relecture : conserver les propositions suffisamment fiables, examiner les hésitations et suivre les erreurs. Demander à un LLM d’écrire « confiance : 0,80 » ne démontre pas, à lui seul, que ce nombre est calibré. La calibration de Jev sur vos textes français doit elle aussi être vérifiée.

Une sortie conforme au format attendu peut contenir une mauvaise classification. La qualité du schéma et la justesse du jugement sont deux critères distincts.

Qu’est-ce qu’on gagne à passer d’un LLM à Jev ?

Le bénéfice attendu dépend de la partie du traitement que vous remplacez. Pour un flux de classification, trois gains méritent d’être évalués.

Un coût d’inférence potentiellement plus bas. Le tarif de Jev et l’absence de facturation des tokens de sortie peuvent rendre intéressant le traitement de gros historiques ou leur reclassement après une modification de taxonomie. La comparaison doit utiliser votre facture réelle, y compris les remises de traitement par lots ou de cache dont bénéficie votre LLM. Le calcul de coût figure plus bas dans l’article.

Un délai plus court pour obtenir une décision. C’est utile lorsqu’un routage ou un contrôle bloque la suite d’un processus. Sur un traitement nocturne, l’indicateur sera plutôt la durée du lot et le volume traité dans le créneau disponible. Une latence par appel plus faible ne garantit pas un meilleur débit global : quotas, concurrence des appels et réseau interviennent aussi.

Davantage de critères évaluables dans le même parcours. Jev permet de poser ensemble plusieurs questions indépendantes sur le même contenu. Cela peut rendre abordable une qualification plus fine : thème, sous-thème, demande explicite, présence d’un blocage. Ajouter des questions consomme toujours des tokens et nécessite des tests. Un LLM peut lui aussi regrouper plusieurs critères ; l’avantage à vérifier concerne leur coût et leur délai d’évaluation. Questions évaluées en parallèle.

Les premiers résultats donnent un ordre de grandeur possible, sans constituer une promesse : dans le benchmark indépendant présenté plus bas, le coût est de 0,04 dollar pour 1 000 éléments avec Jev, contre 0,16 et 0,19 dollar pour les deux configurations du LLM comparé. Le temps serveur médian est de 105 ms contre 710 et 808 ms. Ces résultats concernent ce protocole, et la qualité varie selon la tâche. Résultats du benchmark.

Remplacer une étape précise dans votre système

Dans un support client, vous pouvez confier la classification à Jev et conserver un LLM pour rédiger la réponse. Dans un assistant documentaire, Jev peut évaluer des passages et le LLM formuler la réponse finale. Pour un reporting d’avis, Jev peut préparer les catégories puis un LLM rédiger une synthèse à partir des résultats contrôlés.

L’économie porte alors sur l’étape déplacée. Si votre LLM classe déjà le ticket et rédige une réponse dans un seul appel, ajouter Jev peut augmenter le nombre de requêtes. Il faut vérifier que cette séparation apporte un bénéfice réel, par exemple en évitant certains appels génératifs ou en réduisant leur contenu.

Le critère de bascule est un meilleur traitement à qualité acceptable pour le métier. Sur un petit volume déjà peu coûteux, l’économie d’API peut être inférieure au coût de migration. Et si davantage de résultats nécessitent une relecture, une baisse de la facture d’inférence peut être annulée par le travail supplémentaire.

Quand utiliser Jev plutôt que des règles, un classifieur ou un LLM ?

Le bon point de départ est une décision que vos équipes prennent déjà. Qui lit le texte ? Quelle catégorie choisit cette personne ? Qu’est-ce qui se passe ensuite ? Combien coûte une erreur ?

Votre besoin	Approche à comparer en priorité
Calculer une somme, vérifier une date, appliquer un seuil connu	Du code et des règles déterministes
Classer des textes dans une taxonomie stable avec beaucoup d’exemples déjà annotés	Un classifieur supervisé, comparé à Jev
Évaluer des critères textuels définis en langage naturel, qui peuvent évoluer	Jev sur un échantillon représentatif
Rédiger, résumer, expliquer une décision ou produire un raisonnement ouvert	Un modèle génératif
Exécuter un processus complet dans plusieurs applications	Une orchestration qui combine modèles, code, droits et validations

Un bon premier projet est une tâche fréquente et vérifiable : classer des avis dans une dizaine de catégories, par exemple. Une décision rare, ambiguë et lourde de conséquences fournit un terrain d’expérimentation beaucoup moins commode.

Cas d’usage : classifier les avis clients dans des catégories exploitables

Une entreprise retail, un réseau de magasins ou un éditeur SaaS collecte des avis sur plusieurs canaux. Les notes donnent une tendance. Les commentaires expliquent ce qui plaît et ce qui doit changer, mais leur lecture manuelle devient vite irrégulière.

L’objectif : transformer les avis en données que les équipes produit, logistique et service client peuvent suivre.

Séparer le sujet de l’avis et le sentiment exprimé

Pour chaque commentaire, posez deux familles de questions :

1. Quels thèmes sont présents ? Produit, livraison, service client, paiement, prix, expérience en magasin ou utilisation de l’application, selon votre activité.
2. Quel sentiment global est exprimé ? Positif, négatif, mixte, neutre ou indéterminé.

Voici trois annotations humaines illustratives, et non des résultats obtenus par l’API :

Avis	Thèmes à conserver	Sentiment global
« Produit très solide, mais livré avec quatre jours de retard. »	Produit, livraison	Mixte
« Débité deux fois. Le support ne répond pas depuis une semaine. »	Paiement, service client	Négatif
« Conforme à la description, je suis ravi de mon achat. »	Produit	Positif

Forcer le premier avis dans une seule catégorie ferait perdre une partie de l’information. Le réduire à « négatif » masquerait aussi la satisfaction sur le produit.

La classification multi-étiquette permet de conserver plusieurs thèmes. Pour savoir ce qui est précisément critiqué, ajoutez ensuite des questions par aspect : « Le client exprime-t-il une insatisfaction concernant la livraison ? », par exemple. La présence du thème « livraison » ne suffit pas : « Livraison impeccable » parle aussi de livraison.

À quoi servent ces catégories dans l’entreprise ?

Dans votre entrepôt de données, rattachez les résultats à l’identifiant de l’avis, au canal, à la date et, lorsque ces informations sont disponibles, au magasin ou au produit concerné. Vous pouvez alors suivre les critiques sur les délais, repérer un motif récurrent après un changement de transporteur ou identifier une fonctionnalité souvent citée favorablement.

Une règle peut créer une tâche de relecture lorsqu’un avis mentionne un problème de paiement. Un tableau de bord peut montrer l’évolution des thèmes par gamme. Un responsable produit peut consulter les verbatims associés à une catégorie avant de décider quoi améliorer.

L’indicateur de réussite est la qualité des catégories, puis le temps de préparation du reporting et son utilisation par les métiers. Mesurez aussi la proportion d’avis envoyés en relecture : une classification précise sur quelques avis faciles peut laisser beaucoup de travail manuel.

Deux précautions rendent les résultats plus lisibles. Un avis peut compter dans plusieurs thèmes : leurs pourcentages ne s’additionnent donc pas nécessairement à 100 %. Et une évolution des canaux de collecte peut modifier les résultats sans traduire une dégradation réelle du service.

Le gain à chercher si vous utilisez déjà un LLM

Si un LLM transforme déjà chaque avis en catégories, Jev peut remplacer cette étape de classification. Le gain visé est de classer et de reclasser davantage d’avis à budget donné, par exemple pour reprendre tout l’historique lorsqu’un nouveau motif apparaît. Les probabilités fournissent aussi un signal pour organiser la relecture.

Comparez le coût pour 1 000 avis au même niveau de précision et de rappel, puis le temps consacré aux corrections. Si vous produisez également une synthèse mensuelle, conservez cette rédaction dans le modèle génératif. Si quelques centaines d’avis vous coûtent déjà très peu à traiter, la migration doit apporter autre chose qu’une économie de tokens.

D’autres classifications utiles aux équipes data

Le même principe s’applique à de nombreux textes déjà présents dans l’entreprise :

Texte à traiter	Exemples de catégories	Usage concret
Verbatims NPS ou enquêtes de satisfaction	Onboarding, fiabilité, ergonomie, accompagnement, prix	Comprendre les raisons données derrière les notes
Motifs de retour produit	Taille, défaut, article différent, description trompeuse, changement d’avis	Alimenter les analyses qualité et réduire les causes évitables de retour
Demandes internes	Accès logiciel, matériel, paie, congés, achats	Proposer la bonne file de traitement dans un portail interne
E-mails entrants d’une boîte partagée	Devis, facture, réclamation, partenariat, candidature	Préparer le tri avant traitement par l’équipe compétente
Documents d’une GED	Contrat, facture, procédure, compte rendu, fiche technique	Préparer l’indexation et les circuits de traitement
Comptes rendus de maintenance	Panne électrique, problème mécanique, fuite, usure, cause indéterminée	Structurer les observations pour une analyse des incidents
Retours d’utilisateurs d’un logiciel	Bug, demande de fonctionnalité, difficulté d’usage, compliment	Alimenter le backlog produit et le suivi du support

La taxonomie doit prévoir les cas incomplets ou hors périmètre. « Cause indéterminée » est une information utile ; attribuer une cause mécanique à un compte rendu trop vague crée une fausse donnée.

Six autres cas d’usage de Jev pour les départements data et IA

1. Orienter les tickets vers la bonne équipe

Un ticket arrive dans le support : « Depuis la mise à jour, je ne peux plus exporter mes factures. » Le texte mélange un objet métier, la facturation, et un problème technique.

Transmettez le message et le contexte utile à Jev. Un Choice peut proposer l’équipe responsable ; d’autres questions identifient le produit concerné, le type de demande ou l’existence d’un blocage déclaré. Le code applique ensuite les règles d’affectation de votre outil de tickets.

L’urgence doit être décrite avec vos critères métier. Un message très agacé ne signifie pas nécessairement un incident prioritaire, et une panne critique peut être décrite calmement. Les engagements contractuels et les délais restent calculés en code.

Le gain face à un LLM : réduire le délai et le coût du tri initial lorsque cette étape fait déjà l’objet d’un appel dédié. Plusieurs décisions de routage peuvent être obtenues ensemble avant de solliciter un modèle génératif pour la réponse. Le bénéfice métier apparaît surtout si ce tri est sur le chemin critique de la prise en charge.

À mesurer : latence du routage, coût par ticket, taux de réaffectation et erreurs sur les tickets prioritaires. Le guide de routage d’intention fournit le schéma technique ; notre article sur les agents IA pour le service client détaille le processus métier autour du modèle.

2. Classer les fiches fournisseurs dans votre catalogue

Une enseigne reçoit des descriptions de produits hétérogènes. Les catégories des fournisseurs ne correspondent pas à celles de son PIM, le système qui centralise les informations produit.

Jev peut proposer une catégorie à partir du titre, de la description et d’attributs fiables : « maison », puis « entretien », puis une sous-catégorie plus précise. Une taxonomie profonde se traite par étapes, avec une possibilité de relecture lorsque plusieurs branches restent plausibles. TypeSafe documente cette approche dans son exemple de classification hiérarchique.

Le modèle travaille sur du texte. Si l’information décisive figure uniquement sur une photo, une étape de perception est nécessaire en amont. Les références, dimensions et correspondances exactes doivent aussi être contrôlées par vos règles.

Le gain face à un LLM : réduire le coût du classement d’un catalogue volumineux et rendre plus abordable son retraitement lorsque la taxonomie change. La rédaction des fiches peut rester dans un LLM. Une taxonomie très profonde exige toutefois plusieurs étapes : il faut comptabiliser tous les appels, ainsi que les corrections liées aux confusions entre catégories proches.

À mesurer : coût pour 1 000 références, durée d’un import et taux de correction par les gestionnaires du catalogue. C’est un prolongement concret des usages de l’IA dans le retail et l’e-commerce.

3. Contrôler des informations extraites avant leur entrée dans l’ERP

Votre chaîne documentaire extrait déjà des champs depuis des factures ou des bons de commande. Certaines anomalies relèvent du sens : le libellé ressemble-t-il à un acompte ? Le document correspond-il au type attendu ? Une mention rend-elle nécessaire une vérification complémentaire ?

Jev peut évaluer ces critères à partir du texte extrait et des champs candidats, puis orienter les dossiers douteux vers une file de contrôle. L’exemple de cascade d’extraction structurée de TypeSafe illustre l’articulation avec d’autres modèles.

Les additions, rapprochements exacts, contrôles de TVA et validations de dates restent dans le code. Un résultat sémantique favorable ne valide pas l’ensemble du document.

Le gain face à un LLM : lorsque vous utilisez un second appel génératif pour contrôler une extraction, Jev peut prendre en charge des vérifications ciblées à un coût potentiellement inférieur. Cela peut permettre de contrôler davantage de documents. Le coût de l’OCR et de l’extraction initiale subsiste ; des contrôles moins chers n’apportent de valeur que s’ils détectent les anomalies recherchées.

À mesurer : coût du contrôle par document, anomalies détectées, documents corrects inutilement bloqués et erreurs qui atteignent l’ERP. Ces mesures évitent de présenter comme performant un filtre qui bloque simplement presque tout.

4. Filtrer les passages documentaires d’un assistant RAG

Un assistant interne retrouve plusieurs passages après une question sur les conditions de retour. Certains concernent une autre gamme ; d’autres décrivent une procédure devenue obsolète.

Jev peut attribuer un Score de pertinence à chaque couple question-passage, ou vérifier si une affirmation est soutenue par le texte fourni. Votre application choisit alors les passages à transmettre au modèle génératif et ceux à faire examiner.

La sélection des versions documentaires et les droits d’accès doivent déjà être gérés par le système. Une citation bien reliée à un document ne prouve pas que ce document est exact ou à jour. Les exemples officiels de classification de passages RAG et de vérification des citations donnent deux points de départ.

Le gain face à un LLM : remplacer certains appels de jugement de pertinence par une évaluation spécialisée, et éventuellement transmettre moins de passages inutiles au modèle qui rédige. Si vous utilisez déjà un reranker spécialisé, comparez Jev à ce composant. Ajouter un filtre à une chaîne qui n’en avait pas entraîne des appels supplémentaires ; la réduction du contexte et le gain de qualité doivent en justifier le coût et le délai.

À mesurer : coût total par réponse, tokens transmis au générateur, conservation des passages utiles, qualité finale et latence. Cette étape peut compléter un assistant IA d’entreprise, à condition de l’évaluer dans la chaîne complète.

5. Qualifier des demandes commerciales à partir de critères explicites

Une équipe reçoit des formulaires contenant des descriptions libres de projets. Avant de demander à un commercial de tout lire, elle veut distinguer une demande de démonstration, une recherche de prestataire, une prise d’information ou une sollicitation hors périmètre.

Un Choice propose l’intention. Des Noul vérifient si le message mentionne explicitement un budget, un calendrier ou un besoin compatible avec l’offre. Un Score peut évaluer l’adéquation à une grille définie par l’équipe commerciale. Le schéma de scoring composite montre comment combiner plusieurs critères.

L’absence de budget dans un formulaire signifie « budget non mentionné ». Elle ne démontre pas que le prospect n’a pas de budget. De même, un score d’adéquation n’est pas une probabilité de signer.

Le gain face à un LLM : proposer rapidement les critères de qualification dans le CRM et limiter les appels génératifs consacrés uniquement à ce classement. Cela peut être utile pour réévaluer un historique de demandes lorsque l’offre change. La recherche d’informations manquantes et la rédaction d’un message commercial restent des étapes distinctes. Sur un faible volume de formulaires, le coût d’API sera rarement l’enjeu principal.

À mesurer : coût et délai de qualification, accord avec les décisions humaines et demandes pertinentes manquées. Le résultat peut enrichir le CRM avant une qualification commerciale plus complète.

6. Transformer des textes en variables pour un modèle prédictif

Vos data scientists disposent de données structurées, mais aussi de comptes rendus difficiles à exploiter : interventions techniques, échanges support, descriptions de projets.

Jev peut transformer ces textes en variables définies par des questions : « Une panne récurrente est-elle mentionnée ? », « Le client décrit-il un blocage d’usage ? », « Une contrainte d’intégration est-elle explicite ? ». Les probabilités deviennent des colonnes utilisées par un modèle supervisé.

Cette approche est décrite dans le cookbook de découverte de variables. Pour votre projet, comparez-la aux variables existantes, aux embeddings et à une approche plus simple. Vérifiez surtout que le texte était disponible à la date de la prédiction : utiliser un compte rendu écrit après l’événement créerait une fuite de la cible.

Le gain face à un LLM : rendre moins coûteuse l’évaluation répétée de nombreux critères sur un corpus, afin de tester davantage de variables candidates. Jev fournit des valeurs numériques directement utilisables dans cette exploration. Le gain décisif reste l’amélioration du modèle prédictif : une méthode moins chère qui dégrade ses résultats peut être un mauvais échange.

À mesurer : coût d’un cycle d’expérimentation, amélioration sur un jeu de test séparé et stabilité dans le temps. Une variable facile à produire doit encore démontrer son utilité.

Combien coûte Jev et comment évaluer ses résultats ?

Un prix d’inférence bas, à rapporter au traitement complet

Au 19 septembre 2026, TypeSafe affiche pour jev-1.13.0 un tarif de 0,042 dollar par million de tokens d’entrée, avec des tokens de sortie gratuits. Vérifiez la page des modèles et tarifs au moment de votre essai.

Exemple de calcul : si un avis et l’ensemble de ses questions représentent en moyenne 1 000 tokens d’entrée, traiter 100 000 avis représente 100 millions de tokens, soit 4,20 dollars d’inférence à ce tarif. C’est une hypothèse de dimensionnement, pas une mesure du script présenté plus bas.

Les questions et leurs critères font partie de l’entrée facturée. Le coût du projet inclut aussi la collecte, l’intégration, les éventuelles reprises, le contrôle qualité et la relecture humaine. Suivez le coût par avis correctement traité, en plus du coût de l’appel API.

Ce que montrent les premiers benchmarks

Le benchmark indépendant cité plus haut, publié le 18 septembre, compare Jev à gpt-5.6-luna, avec deux réglages de raisonnement, sur 49 tâches et 8 225 éléments. Jev égale ou dépasse la meilleure configuration de référence sur 42 tâches. Mais seules sept différences sont considérées comme nettes selon le critère statistique du rapport, et Jev est moins bon sur une classification à 77 catégories. Ses gains de coût et de temps ne prédisent donc pas sa précision sur vos avis français. Protocole, résultats et limites.

Un autre test, consacré à 2 000 e-mails de phishing synthétiques contenant de vraies URL, obtient 62,6 % de bonnes réponses pour le verdict direct de Jev, contre 81,3 % pour Haiku. Des contrôles ajoutés au même projet montrent ensuite de meilleurs résultats avec des règles ou un classifieur alimenté par plusieurs signaux, ce qui change fortement la conclusion pratique : la décomposition de la tâche compte autant que le nom du modèle. Benchmark et contrôles.

Pour une entreprise française, tester le français et clarifier les données

TypeSafe indique que l’anglais est la langue principale d’entraînement et celle où la précision est actuellement la meilleure. Un test sur vos textes français doit inclure le vocabulaire métier, les fautes, les formulations indirectes et les avis mixtes. Langues prises en charge.

La documentation signale aussi des limites sur les calculs, les comparaisons de dates, certaines négations et les longs contenus remplis d’informations peu utiles. Transmettez le contexte nécessaire à la décision et gardez les contrôles exacts dans le code. Limites documentées de Jev 1.13.

Sur les données, TypeSafe annonce ne pas entraîner ses modèles sur les requêtes et réponses des clients. Une option de rétention nulle, ou ZDR, est proposée aux clients entreprise. Les conditions de rétention, de traitement et de localisation doivent être clarifiées pour votre contrat ; l’annonce de non-entraînement ne répond pas à toutes ces questions. Consultez le DPA et les documents contractuels avec vos interlocuteurs habituels avant d’envoyer des données personnelles ou confidentielles.

La confiance du modèle ne remplace pas votre évaluation

Pour Choice et Score, confidence résume la concentration de la distribution des réponses. Ce n’est ni la probabilité de l’option choisie, ni une garantie de justesse. Noul fournit directement une probabilité de « oui », sans champ confidence séparé. Explication de la confiance.

Pour préparer un pilote de classification d’avis :

1. Définissez les catégories avec le métier. Ajoutez des exemples et les frontières entre catégories proches.
2. Constituez un corpus annoté. Quelques centaines d’avis peuvent servir de point de départ, avec suffisamment d’exemples pour chaque catégorie et davantage pour les cas rares ou coûteux.
3. Séparez réglage et test final. Ajustez questions et seuils sur une partie du corpus ; évaluez ensuite sur des avis restés à l’écart.
4. Mesurez par catégorie. Suivez précision, rappel, désaccords sur le sentiment et taux de relecture. Comparez aussi aux règles ou au classifieur que vous pourriez déjà utiliser.
5. Testez d’abord en observation. Conservez des contrôles sur les résultats jugés faciles. Un modèle peut se tromper avec une forte probabilité déclarée.

Pour le tableau de bord, distinguez les avis reçus, classés et en attente de relecture. Sinon, les cas difficiles disparaissent du dénominateur et donnent une image artificiellement propre des résultats.

Tutoriel Jev : classifier des avis clients en Python dès aujourd’hui

Nous allons classer trois avis fictifs selon cinq thèmes et un sentiment global. Chaque avis fera l’objet d’un seul appel contenant six questions. Le script conservera les probabilités et signalera les cas incertains.

Le résultat sera un fichier JSONL, avec un objet JSON par ligne, facile à reprendre dans un traitement de données. Les classifications resteront des propositions à évaluer.

Étape 1. Essayer les questions dans le Playground

Ouvrez le Playground TypeSafe et connectez-vous. Collez cet avis dans le champ state :

Produit très solide, mais livré avec quatre jours de retard.

Ajoutez une question Noul : « L’avis aborde-t-il le transport, le colis ou le délai de livraison ? Une mention positive ou négative compte. » Puis une seconde question sur la qualité ou l’usage du produit.

Les deux thèmes peuvent être présents. Pour le sentiment, ajoutez un Choice avec les options positif, négatif, mixte, neutre et indéterminé, en décrivant chaque catégorie. Le guide de démarrage officiel explique les champs de l’interface.

Étape 2. Créer une clé API et installer le SDK

Créez une clé dans la console TypeSafe, avec un compte disposant de l’accès au service. Le SDK Python nécessite Python 3.10 ou plus récent.

Dans un terminal macOS ou Linux :

mkdir essai-jev
cd essai-jev
python3 -m venv .venv
source .venv/bin/activate
python -m pip install "typesafe-sdk==0.7.0"

Pour saisir la clé sans l’inscrire dans le script ni dans l’historique des commandes, exécutez :

export TYPESAFE_API_KEY="$(python -c 'import getpass; print(getpass.getpass("Clé TypeSafe : "))')"

La version du SDK est fixée pour cet exemple. Le modèle utilisé sera jev-1.13.0, afin de conserver une version identifiable pendant l’évaluation. Un alias tel que jev-latest peut évoluer. Versions des modèles.

Étape 3. Définir les catégories et lancer la classification

Téléchargez le script Python complet, ou copiez le code ci-dessous dans un fichier nommé classer_avis.py.

Pour les thèmes, une probabilité à partir de 0,80 sera retenue comme présence proposée ; jusqu’à 0,20, comme absence proposée ; entre les deux, comme résultat incertain. Ces seuils sont illustratifs et doivent être évalués sur vos données. Le script demande aussi une relecture si aucun thème n’est retenu ou si le sentiment reste insuffisamment tranché.

import json
import os

from typesafe_sdk import Choice, Noul, TypeSafeClient, TypeSafeError

MODEL = "jev-1.13.0"
VERSION_QUESTIONS = "avis-v1"
SEUIL_PRESENT = 0.80
SEUIL_ABSENT = 0.20

THEMES = {
    "produit": "qualité, usage ou conformité du produit à sa description",
    "livraison": "transport, colis, délai ou déroulement de la livraison",
    "service_client": "échanges avec le support ou le service après-vente",
    "paiement": "débit, facturation, paiement ou remboursement",
    "prix": "niveau du prix ou rapport qualité-prix",
}

QUESTIONS = {
    "sentiment": Choice(
        instructions="Quel sentiment global cet avis client exprime-t-il ?",
        criteria={
            "positif": "Appréciation favorable, sans critique explicite.",
            "negatif": "Critique, sans appréciation favorable explicite.",
            "mixte": "Présence d'appréciations favorables ET de critiques.",
            "neutre": "Texte compréhensible, purement factuel, sans opinion.",
            "indetermine": "Texte trop ambigu ou incompréhensible pour conclure.",
        },
    ),
    **{
        theme: Noul(
            instructions=(
                f"L'avis aborde-t-il ce thème : {definition} ? "
                "Une mention positive ou négative compte. "
                "Évalue uniquement ce qui est exprimé dans l'avis."
            )
        )
        for theme, definition in THEMES.items()
    },
}

AVIS = [
    ("avis-001", "Produit très solide, mais livré avec quatre jours de retard."),
    ("avis-002", "Débité deux fois. Le support ne répond pas depuis une semaine."),
    ("avis-003", "Conforme à la description, je suis ravi de mon achat."),
]


def classer(client, identifiant, texte):
    base = {"id": identifiant, "version_questions": VERSION_QUESTIONS}
    if not texte.strip():
        return {**base, "statut": "texte_vide", "a_relire": True}

    try:
        reponse = client.system_one(state={"avis": texte}, questions=QUESTIONS)
    except TypeSafeError as erreur:
        return {
            **base, "statut": "erreur_api", "a_relire": True,
            "erreur": type(erreur).__name__,
        }

    sentiment = reponse.choices["sentiment"]
    probabilites = {t: reponse.nouls[t].noul for t in THEMES}
    presents = [t for t, p in probabilites.items() if p >= SEUIL_PRESENT]
    incertains = [
        t for t, p in probabilites.items() if SEUIL_ABSENT < p < SEUIL_PRESENT
    ]
    a_relire = (
        bool(incertains)
        or not presents
        or sentiment.choice == "indetermine"
        or sentiment.probabilities[sentiment.choice] < SEUIL_PRESENT
    )

    return {
        **base,
        "modele": reponse.model,
        "statut": "a_relire" if a_relire else "proposition",
        "a_relire": a_relire,
        "sentiment": sentiment.choice,
        "sentiment_probabilites": sentiment.probabilities,
        "themes": presents,
        "themes_incertains": incertains,
        "themes_probabilites": probabilites,
        "tokens_entree": reponse.usage.input_tokens,
    }


def main():
    if not os.environ.get("TYPESAFE_API_KEY", "").strip():
        raise SystemExit("Définissez la variable TYPESAFE_API_KEY avant de lancer le script.")
    with TypeSafeClient(model=MODEL, timeout=30.0) as client:
        for identifiant, texte in AVIS:
            print(json.dumps(classer(client, identifiant, texte), ensure_ascii=False))


if __name__ == "__main__":
    main()

Les identifiants des questions, comme produit ou prix, servent à retrouver les résultats. La consigne doit donc décrire explicitement le thème dans instructions. Écrire seulement un bon nom de variable ne suffit pas à formuler la question.

Lancez le programme :

python classer_avis.py > resultats.jsonl

Le fichier contient, pour chaque avis, les thèmes proposés, les thèmes incertains, le sentiment, les probabilités, le modèle et le nombre de tokens d’entrée. Le texte brut n’est pas recopié dans le résultat ; l’identifiant permet de le retrouver dans la source.

Les trois avis intégrés sont fictifs. Les annotations attendues figurent dans le tableau du cas d’usage plus haut ; les valeurs numériques dépendront de la réponse réelle de l’API.

Étape 4. Lire les résultats sans transformer un doute en catégorie

Le champ statut distingue quatre situations :

Statut	Interprétation
proposition	Les résultats passent les seuils de démonstration ; ils restent à valider pendant le pilote
a_relire	Au moins un critère appelle une vérification humaine
texte_vide	Aucun texte exploitable n’a été transmis au modèle
erreur_api	La requête a échoué ; aucune classification n’est disponible

Une erreur API ne devient donc pas un avis neutre ou une absence de problème. En cas d’échec, vérifiez la clé, l’accès au modèle et les limites du compte. Le SDK gère des reprises sur certaines erreurs transitoires ; un traitement métier doit aussi conserver les éléments qui restent en échec.

Ce premier script détecte les thèmes et le sentiment global. Pour distinguer « produit apprécié » de « produit critiqué », ajoutez une question dédiée à l’insatisfaction sur le produit. Évaluez-la séparément avant de l’utiliser dans un indicateur qualité.

Étape 5. Passer des trois exemples à un pilote métier

Remplacez la liste AVIS par des couples identifiant-texte issus d’un export autorisé, puis lancez le traitement sur le corpus annoté. Conservez la même définition des catégories pendant la comparaison.

Dans votre chaîne de données, le traitement pourra ensuite prendre cette forme :

Export ou nouvel avis
  → préparation du texte
  → appel Jev
  → stockage des propositions et probabilités
  → relecture des cas signalés + contrôle d’un échantillon des autres
  → alimentation du tableau de bord

Pour un traitement récurrent, ajoutez le suivi des erreurs, la gestion des quotas et une clé associant l’identifiant de l’avis, la version des questions et celle du modèle. Cela permet de reprendre un lot sans compter deux fois les mêmes résultats. Mesurez aussi le temps de bout en bout depuis votre infrastructure : le temps serveur d’un benchmark ne comprend pas nécessairement tout votre parcours réseau et applicatif.

Le premier livrable utile est modeste : un tableau d’avis classés, un taux de relecture et une comparaison avec les annotations du métier. Avec ces trois éléments, votre département data et IA peut décider si Jev mérite une place dans le processus, quelles catégories améliorer et quelles décisions automatiser progressivement.

Vous souhaitez cadrer ce pilote ou le brancher à vos outils ? Notre accompagnement data et IA permet de partir du processus métier, de définir les critères de réussite et de construire l’intégration autour des résultats mesurés.