Jev : optimiser le routage des workflows IA

Faut-il vraiment un grand modèle de langage pour décider si un ticket concerne la facturation ou un bug ?

Dans beaucoup de workflows, le même modèle trie la demande, choisit un outil et rédige la réponse. C'est une façon pratique de construire une première automatisation. Mais ces étapes n'ont pas toutes besoin des mêmes capacités.

Identifier le service concerné revient à choisir parmi quelques possibilités. Résoudre un problème technique peut demander de consulter une documentation, de recouper des informations et de formuler une explication.

Avec Jev, TypeSafe AI propose de séparer ces deux besoins. L'enjeu pour les entreprises : orienter les demandes à moindre coût, puis mobiliser le bon traitement pour chaque situation.

Jev, un modèle spécialisé dans la prise de décision

Lancé le 15 septembre 2026, Jev reçoit un contenu et des questions dont les réponses possibles sont définies à l'avance. Il renvoie des résultats structurés, avec des probabilités, plutôt qu'une réponse rédigée.

TypeSafe annonce une architecture spécifique, des sorties calculées en parallèle et un entraînement destiné à améliorer la calibration des décisions, nommé RLCD. Annonce officielle de TypeSafe

Que fait-il concrètement ? Sur un message de support, il peut être interrogé sur le service concerné, le niveau d'urgence ou la nécessité d'une vérification complémentaire. Le workflow utilise ensuite ces résultats pour choisir la suite du traitement.

Une nuance technique mérite d'être précisée : l'absence de génération de texte ne suffit pas à établir qu'un modèle ne partage aucune base avec un LLM. Les informations publiques consultées ne permettent pas de déterminer précisément le modèle de départ de Jev. La distinction utile porte ici sur son fonctionnement : produire des décisions directement exploitables par un logiciel.

Pourquoi séparer le tri du traitement ?

Un agent généraliste peut recevoir une demande avec de nombreuses consignes : reconnaître son sujet, évaluer sa priorité, choisir parmi plusieurs outils et préparer une réponse.

Cette souplesse est utile. Elle peut aussi conduire à solliciter des capacités de raisonnement élaborées pour des décisions simples et répétitives.

Le routage consiste à choisir le traitement vers lequel envoyer une demande. Lorsqu'il fonctionne correctement, il permet de confier chaque cas à une procédure ou à un agent mieux adapté.

Un agent chargé de la facturation peut ainsi disposer des consignes commerciales et des outils nécessaires pour consulter une facture. Un agent de support technique peut accéder à une base de connaissances et à des informations de diagnostic.

Cette spécialisation pourrait améliorer le coût, le délai et la qualité du traitement. Elle ne garantit cependant pas un gain : une mauvaise orientation peut provoquer davantage de travail qu'un traitement généraliste dès le départ.

Exemple : un workflow de support client

Prenons une entreprise qui reçoit trois grandes catégories de demandes : facturation, assistance technique et questions commerciales.

Un client écrit : « Pouvez-vous me renvoyer la facture de ma dernière commande ? »

Le sujet est clair. Si les informations nécessaires sont disponibles et que les contrôles d'accès sont satisfaits, une procédure connue peut prendre le relais. Une analyse approfondie du message n'apporte probablement pas grand-chose.

Un autre client écrit : « Le paiement a échoué deux fois, mais mon compte a quand même été débité. »

Cette demande touche à la fois au paiement et à un possible incident technique. Un classement trop rapide risque de l'envoyer au mauvais endroit. Le workflow doit prévoir les messages ambigus ou qui concernent plusieurs sujets.

Une organisation possible serait la suivante :

1. Vérifier les informations déjà connues. Le formulaire utilisé ou les données du dossier permettent parfois d'orienter la demande sans IA.
2. Évaluer les messages qui nécessitent une interprétation. Le modèle propose une catégorie et des indicateurs de confiance.
3. Appliquer les critères de routage. Les cas suffisamment fiables suivent une branche définie.
4. Prévoir un traitement complémentaire. Les demandes ambiguës passent à un modèle plus capable ou à un collaborateur.

L'agent spécialisé intervient alors avec un périmètre plus précis. Il reçoit le contexte utile à sa mission et les outils nécessaires pour la réaliser.

La confiance doit être mesurée sur vos données

Une probabilité affichée ne prouve pas qu'un modèle évalue correctement son incertitude.

Un modèle bien calibré devrait, sur un ensemble représentatif de décisions annoncées avec une confiance de 80 %, avoir raison environ huit fois sur dix. Cette propriété se vérifie sur de nombreux exemples. Elle ne garantit pas qu'une réponse particulière est correcte.

Il faut également distinguer la probabilité attribuée à une option et l'indicateur de confiance éventuellement fourni par le service. Leur signification doit être comprise avant de les utiliser dans une règle métier.

Choisir un seuil de 0,8 parce que le chiffre semble rassurant ne suffit donc pas. Le seuil doit dépendre des résultats observés et des conséquences d'une erreur.

Une demande envoyée dans la mauvaise file peut souvent être réorientée. Un remboursement ou une modification de droits d'accès exige des contrôles supplémentaires. Le modèle peut contribuer à l'évaluation, mais les autorisations et les règles de validation doivent rester explicites.

Quels gains de coût et de rapidité attendre ?

À son lancement, TypeSafe annonce un prix de 0,042 dollar par million de tokens en entrée, sans facturation de la sortie, et une latence de 70 à 500 millisecondes. Ces chiffres viennent du fournisseur. TypeSafe précise notamment que ses mesures de vitesse sont généralement réalisées depuis la côte ouest américaine, où son service est situé. Tarifs et précisions sur les mesures

Pour une entreprise, le chiffre pertinent reste le coût du traitement complet.

Ajouter une étape de routage a un coût et prend du temps. Cette étape devient intéressante si elle évite suffisamment d'appels plus coûteux, réduit le travail des agents suivants ou diminue les reprises manuelles.

Si presque toutes les demandes finissent malgré tout chez le même agent généraliste, le routeur peut simplement ajouter une étape au parcours.

Il faut donc comparer le workflow actuel et le workflow envisagé à qualité de service comparable. Une baisse du prix des appels n'est pas un progrès si les erreurs de traitement augmentent.

Comment tester cette approche dans n8n, Make ou un développement sur mesure ?

Le premier travail consiste à repérer les appels qui servent uniquement à choisir entre quelques branches.

Pour chaque décision, les catégories doivent être suffisamment claires. Que recouvre une demande urgente ? Comment traiter un message qui concerne deux services ? Que faire lorsqu'aucune catégorie ne convient ?

Ces questions relèvent d'abord de l'organisation de l'entreprise. Un modèle ne corrigera pas à lui seul une procédure ambiguë.

L'évaluation peut ensuite s'appuyer sur des demandes historiques, préparées avec les précautions nécessaires pour les données clients. Les réponses attendues sont validées par les équipes, et une partie des exemples est conservée à part pour évaluer les réglages sans les tester uniquement sur les cas ayant servi à les définir.

Les mesures utiles sont :

• La proportion de demandes correctement orientées.
• Le nombre d'erreurs commises avec une confiance élevée.
• La part des demandes envoyées en vérification.
• Le délai de traitement complet.
• Le coût total, y compris les corrections manuelles.

Une première phase peut fonctionner en parallèle du processus existant : le modèle propose une orientation, sans déclencher d'action. Les résultats sont comparés aux décisions des équipes avant d'automatiser les cas qui donnent satisfaction.

Il est également utile de comparer Jev à une règle simple ou à un petit modèle généraliste. La solution la plus adaptée dépend du besoin réel, pas seulement des performances annoncées d'un nouveau produit.

Le bon traitement pour le bon besoin

L'intérêt de Jev tient à la place qu'un modèle spécialisé peut prendre dans une automatisation.

Certaines décisions sont déjà couvertes par des règles fiables. D'autres demandent une interprétation limitée. D'autres encore nécessitent du raisonnement, des recherches ou une intervention humaine.

Distinguer ces situations permet de construire des workflows où chaque outil a un rôle précis. Cela suppose aussi de suivre les résultats dans le temps : les demandes des clients, les produits et les procédures évoluent.

Chez UBNI, c'est cette possibilité qui retient notre attention : utiliser une couche de tri pour orienter les demandes vers le bon traitement, puis vérifier que cette organisation améliore réellement le service et son coût.

Besoin d'intégrer l'IA dans votre entreprise ou d'améliorer vos workflows existants ? UBNI vous aide à identifier les bons usages et à les mettre en place dans vos outils et vos processus.