Utiliser Jev pour router les e-mails et tickets : de la démonstration de classification au workflow métier complet

Répartir rapidement 500 e-mails entre quelques catégories est une démonstration de Jev facile à comprendre.

L’auteur d’un exemple communautaire a indiqué que Jev pouvait classer 500 e-mails par lot en quelques secondes, pour un coût d’environ 0.035 dollar. Cependant, la démonstration ne publiait ni la composition des e-mails, ni la définition des catégories, ni les annotations humaines, ni la précision, ni la matrice de confusion. Elle illustre donc mieux un mode d’appel possible qu’elle ne prouve que cette approche peut déjà remplacer le routage du support client en production.

Dans un véritable système de messagerie et de tickets, la difficulté ne consiste pas seulement à décider « à quel service faut-il envoyer ce message ? ».

Un même ticket peut contenir un double prélèvement, une demande de remboursement, une menace de chargeback et plusieurs réclamations restées sans solution. Le placer dans la file billing peut être une classification correcte, tout en laissant échapper les signaux de risque qui devraient recevoir la priorité la plus élevée.

Jev convient mieux non pas pour « résoudre tout le workflow de support avec une seule classification », mais pour jouer le rôle de couche de décision : décomposer un e-mail en plusieurs questions aux limites claires, puis transmettre les résultats structurés au code métier afin de les combiner, de router le ticket et d’exécuter les actions.

E-mail ou ticket de support
   ↓
Prétraitement : extraire l’objet, le corps et le contexte historique nécessaire
   ↓
Jev : sélection de la file, détection du remboursement, détection du risque, évaluation de l’urgence
   ↓
Règles métier : combiner probabilités, seuils, données client et politiques de l’entreprise
   ↓
Routage automatique / revue humaine / escalade à haut risque / génération d’un brouillon de réponse

La répartition des responsabilités la plus importante est la suivante : Jev porte les jugements sémantiques, le code contrôle le flux, et l’équipe de support ou un modèle génératif produit la réponse finale.

Pourquoi Jev convient à cette couche de décision

Jev n’est pas un modèle conversationnel conçu pour générer de longs textes. Il reçoit un state et répond à des typed questions définies à l’avance par le développeur. Ces questions prennent principalement trois formes :

Type	Question adaptée	Résultat renvoyé
Choice	Quelle file est la plus adaptée à ce ticket ?	Une option, les probabilités de chaque option et confidence
Noul	L’utilisateur demande-t-il explicitement un remboursement ?	Une probabilité de « oui » comprise entre 0 et 1
Score	Dans quelle tranche d’urgence se situe ce ticket ?	Un score, les probabilités de chaque tranche et confidence

Plusieurs questions peuvent être évaluées en parallèle dans une même requête. Plutôt que de demander au modèle de lire le ticket, de rédiger une analyse, puis de forcer le programme à interpréter ce texte, il est souvent plus clair de poser plusieurs questions atomiques dont les résultats sont déjà exploitables par le code suivant.

Mais une réponse typée garantit uniquement que le résultat respecte une interface prédéfinie. Elle ne garantit pas que le jugement métier est correct. Le système a toujours besoin de seuils, de chemins de repli, d’une revue humaine et d’une évaluation hors ligne.

Un ticket ne doit pas être réduit à une seule question

Supposons qu’un utilisateur envoie cet e-mail :

Après mon passage à l’offre Pro, j’ai été débité deux fois. Je vous ai contactés il y a trois jours, mais personne n’a encore résolu le problème. Remboursez-moi aujourd’hui, sinon je demanderai un chargeback à ma banque.

Si la seule question posée est « à quel service appartient cet e-mail ? », la réponse sera probablement billing. Pourtant, un système de production doit connaître au moins quatre autres éléments :

Décision	Type de question	Options ou critères recommandés	Finalité
Quelle file principale doit le recevoir ?	Choice	billing / shipping / technical / account / sales / legal / none	Routage initial
Existe-t-il une demande de remboursement ?	Noul	Considérer comme « oui » une demande explicite de remboursement, d’annulation ou de restitution d’un débit	Déclencher le workflow de remboursement
Existe-t-il un risque de chargeback, réglementaire ou juridique ?	Noul	Mention de chargeback, de plainte auprès d’une banque, d’un régulateur ou d’une action en justice	Escalade à haut risque
Urgence	Score	Demande générale sans échéance / service déjà affecté ou contacts répétés / perte financière, chargeback ou délai explicite	Priorité dans la file
Une intervention humaine est-elle nécessaire ?	Noul	Argent, questions juridiques, plaintes répétées non résolues ou jugement incertain du modèle	Décider si le traitement automatique est autorisé

Ces questions sont liées, mais elles ne doivent pas être fusionnées dans une seule demande du type « déterminez globalement comment traiter ce ticket ».

Les recommandations officielles de conception de Jev préconisent de décomposer les tâches complexes en jugements atomiques. Une fois les questions séparées, le code métier peut décider indépendamment de la file, de l’augmentation éventuelle de la priorité, de l’arrêt d’une réponse automatique et de la notification de la personne d’astreinte.

Une question Choice doit également conserver une option comme none, other ou unclear. Si la bonne réponse ne figure pas parmi les options, le modèle ne peut pas inventer une nouvelle file ; il ne peut que forcer le ticket vers l’option disponible la plus proche.

Une couche de règles reste nécessaire entre la sortie du modèle et l’action métier

Le pseudocode de contrôle de flux ci-dessous illustre la répartition des responsabilités entre Jev et le système environnant. Il ne s’agit pas d’une requête littérale issue du SDK officiel :

const decision = await evaluateTicket(ticket, ticketQuestions)

if (decision.transportFailed) {
  return moveToQueue("manual_triage", {
    reason: "decision_service_unavailable"
  })
}

if (
  decision.chargebackRisk >= T_CHARGEBACK ||
  decision.legalRisk >= T_LEGAL
) {
  return moveToQueue("risk_escalation", {
    priority: "highest",
    requireHuman: true
  })
}

if (
  decision.teamTopProbability < T_ROUTE ||
  decision.teamProbabilityMargin < T_MARGIN
) {
  return moveToQueue("manual_triage", {
    reason: "uncertain_route"
  })
}

moveToQueue(decision.team)

if (decision.refundIntent >= T_REFUND) {
  attachWorkflow("refund_review")
}

if (decision.urgency >= T_URGENCY_HIGH) {
  raisePriority()
}

Des constantes comme T_ROUTE et T_REFUND ne sont pas des valeurs universelles intégrées à Jev. Ce sont des politiques métier. Elles doivent être calibrées sur les propres données de tickets de l’organisation et peuvent varier selon le niveau de risque, la langue, la version du modèle et la définition des files.

Pour les demandes ordinaires à faible risque, le système peut accepter des seuils plus souples pour le routage automatique. Pour les remboursements, chargebacks, suspensions de compte ou plaintes juridiques, il convient d’utiliser des seuils plus stricts et de maintenir une revue humaine.

Les appels par lot conviennent au routage, mais les portes à haut risque exigent davantage de prudence

Au niveau de l’interface officielle, Jev permet de répondre à plusieurs questions en parallèle dans une même requête. Cependant, il ne faut pas supposer que regrouper plusieurs tickets dans un appel produit des résultats alignés avec des appels séparés : il convient plutôt d’évaluer et comparer le comportement par lot face au traitement unitaire sur ses propres données.

Le traitement par lot convient donc particulièrement à la classification de gros volumes d’e-mails, notamment pour sélectionner une file, attribuer un thème et décider d’une priorité ordinaire. Par rapport au schéma « une requête par e-mail, puis une autre par question », regrouper les décisions nécessaires dans le moins d’appels possible réduit généralement les allers-retours réseau et facilite le contrôle du débit.

Il ne faut toutefois pas supposer l’équivalence des probabilités Noul entre les appels par lot et les appels unitaires : cette équivalence doit être validée sur ses données, et les tickets à haut risque ou incertains doivent être traités séparément. Une étiquette de file stable ne garantit pas que toutes les probabilités de risque le soient autant.

Une conception plus prudente en deux étapes serait donc :

1. Lors de la première étape, évaluer par lot les décisions à faible risque, telles que la file principale, le thème et le caractère manifestement indésirable du message.
2. Pour les tickets liés aux remboursements, aux chargebacks, au risque juridique ou dont les probabilités se situent dans une zone d’incertitude, effectuer une revue unitaire ou les envoyer directement dans une file humaine.

L’objectif n’est pas de faire voter le modèle à répétition, mais de fournir aux actions à haut risque un contexte plus clair et un chemin de traitement plus strict.

Ne pas interpréter confidence comme une « précision »

Choice et Score renvoient confidence, mais ce champ décrit la concentration de la distribution des probabilités. Il ne peut pas être interprété directement comme une probabilité validée d’exactitude pour les processus métier de l’organisation.

Ce niveau de confiance nécessite donc d’être calibré sur ses propres données avant d’être utilisé pour des décisions critiques. Une règle comme la suivante n’est donc pas sûre :

confidence élevé → exécuter automatiquement

Un système réel doit examiner plusieurs signaux en même temps :

• la probability de l’option arrivée en tête ;
• l’écart de probability entre la première et la deuxième option ;
• un Noul indépendant correspondant au risque métier concerné ;
• le fait que le ticket provienne ou non d’une distribution non couverte par les données d’entraînement ou de validation ;
• un éventuel changement de version du modèle ou de formulation de la question.

« Dans quelle file l’envoyer ? » et « peut-il être traité automatiquement ? » ne devraient pas non plus être résolus avec un seul Choice. Utilisez Choice pour sélectionner la file et un Noul distinct pour vérifier si les conditions du traitement automatique sont réunies.

La formulation des questions doit être gérée comme du code

Dans un workflow Jev, la formulation des questions n’est pas un simple texte de prompt. Elle fait partie de la logique métier.

En cas de contradiction entre les instructions et les critères, le modèle risque de renvoyer un résultat structurellement valide mais sémantiquement erroné, sans qu’aucune exception ne soit levée.

Un projet de routage des e-mails doit donc gérer les définitions de questions au moins avec les pratiques suivantes :

Élément de gestion	Pratique concrète
Versionnage	Créer une nouvelle version à chaque modification de la formulation, des options ou des critères
Revue de code	Conserver les définitions de questions et les règles de routage dans le dépôt pour review, au lieu de les disperser dans des champs de texte d’administration
Exemples de test	Conserver des tickets positifs, négatifs, limites et à intentions multiples pour chaque question
Vérification des contradictions	Vérifier que instruction et true/false criteria vont dans la même direction sémantique
Verrouillage de la version du modèle	Une fois les seuils calibrés, verrouiller une version précise plutôt que de dépendre directement d’un latest alias susceptible d’évoluer

Chaque niveau de Score doit décrire une situation métier observable, plutôt que de se limiter à « faible, moyen, élevé ». Par exemple, « l’utilisateur demande seulement le prix » et « l’utilisateur a déjà contacté plusieurs fois le support et le service est indisponible » seront jugés plus régulièrement que « urgence moyenne ».

Le système doit savoir quoi faire lorsque le réseau échoue

L’échec d’une réponse du modèle de classification ne doit pas être interprété comme « aucun risque » ou « autoriser par défaut ».

En production, des erreurs de transport et des hausses de latence peuvent toujours survenir, notamment sous forte charge ou lors d’aléas réseau. Cela suffit à montrer qu’un système de production ne peut pas mettre en œuvre uniquement le chemin idéal.

Au moins quatre couches de protection sont nécessaires :

1. Reprises et temporisation progressive : privilégier un SDK prenant en charge les reprises et retry-after, afin qu’une erreur réseau transitoire ne fasse pas disparaître le ticket.
2. Sémantique explicite du repli : décider à l’avance si l’indisponibilité du service envoie le ticket vers un tri humain, retarde le traitement ou exécute uniquement des règles déterministes.
3. Idempotence et déduplication : une nouvelle livraison de l’e-mail, une reprise de file ou une reprise après timeout ne doivent pas créer de tickets en double.
4. Journalisation complète : enregistrer la version du modèle, la version des questions, probabilities, la latence de l’appel, l’usage et le résultat humain final.

Pour les tickets financiers, liés au compte ou juridiques, le repli par défaut le plus sûr n’est généralement pas « approuver automatiquement », mais « suspendre l’action automatique et transmettre à une personne ».

Les files multilingues ne peuvent pas partager un seul jeu de seuils Score

Dans un système multilingue, il ne faut pas supposer que les seuils de Score ou de confidence sont directement transférables d’une langue à l’autre : ils doivent être validés et calibrés séparément pour chaque langue.

Même si le choix de file ou de catégorie semble stable, l’étalonnage des scores d’urgence ou des niveaux d’escalade ne doit pas être présumé équivalent sans validation dédiée par langue.

Un système de support multilingue doit donc au minimum :

• constituer un jeu de validation distinct pour chaque langue ;
• calibrer séparément les seuils d’urgence et d’escalade humaine ;
• ne pas recopier directement en chinois ou dans une autre langue les plages de score calibrées sur des données anglaises ;
• appliquer une politique cohérente concernant la traduction, le texte original et l’historique de la conversation.

Ce qu’il faut évaluer avant le lancement

Un système de routage des e-mails ne peut pas être jugé uniquement sur sa précision globale. Les différents types d’erreurs ont des coûts très différents. Envoyer une question d’avant-vente vers la file du support peut seulement provoquer un transfert supplémentaire ; manquer une menace de chargeback ou une plainte juridique peut créer un risque financier et de conformité direct.

Il faut au minimum observer séparément les indicateurs suivants :

Indicateur	Question à laquelle il doit répondre
Précision de la file principale	Le ticket a-t-il atteint la bonne première file de traitement ?
Rappel des cas à haut risque	Combien de tickets liés au chargeback, au juridique, à la réglementation ou à la sécurité des comptes ont été manqués ?
Couverture du routage automatique	Quelle part des tickets a évité un premier tri manuel ?
Taux de traitement automatique incorrect	Combien de tickets qui auraient dû nécessiter une personne ont été laissés passer automatiquement ?
Taux de revue humaine	Les seuils sont-ils si prudents que la file humaine perd son intérêt ?
Latence et taux d’échec	Le système reste-t-il stable avec la concurrence, la longueur des e-mails et les conditions réseau réelles ?
Coût complet par ticket	Après les décisions, reprises, modèles en aval et revue humaine, le workflow reste-t-il économique ?

Lors du choix des références de comparaison, il ne faut pas opposer Jev uniquement à des modèles conversationnels de pointe et coûteux. Les systèmes de règles, les modèles Flash avec sortie structurée, les embeddings associés à un classifieur et les petits modèles entraînés sur les propres données annotées de l’organisation peuvent tous constituer des alternatives raisonnables.

Dès lors que des données annotées sont disponibles, il est recommandé de benchmarker un classifieur spécialisé par rapport à Jev, sans présumer qu’il sera plus précis ou plus rapide. Une trajectoire raisonnable consiste à utiliser Jev lors du démarrage à froid et tant que les étiquettes changent souvent, puis à réévaluer le passage d’une file à fort volume vers un classifieur local ou spécialisé lorsque suffisamment de données ont été accumulées.

Jev ne rédige pas la réponse finale du support

Après le routage, le système peut encore devoir résumer le problème, retrouver la commande, vérifier l’éligibilité au remboursement ou générer un brouillon de réponse. Toutes ces tâches ne doivent pas être confiées à Jev.

Une répartition plus claire du travail est la suivante :

Étape	Exécutant le plus adapté
Recherche exacte de commande, calcul de montant et comparaison de dates	Code métier et bases de données
Jugements sur la file, le risque, l’intention et l’urgence	Jev ou un autre modèle de classification
Recherche dans la base de connaissances	Systèmes de recherche et RAG
Brouillon de réponse, explication et communication en langage naturel	Un LLM génératif
Approbation du remboursement, suspension du compte et traitement juridique	Humains et politiques de l’entreprise

Cette architecture ne transforme pas Jev en « agent de support automatisé ». Elle ajoute simplement une couche de décision peu coûteuse, structurée et directement exploitable par le code avant que chaque e-mail n’arrive à un modèle onéreux ou à une file humaine.

Conclusion : la classification n’est pas le produit, le flux de contrôle l’est

Jev montre une direction utile : lorsque le logiciel n’a besoin que d’une file, d’une probabilité ou d’un niveau, il n’est pas nécessaire d’appeler systématiquement un modèle génératif, de lui faire rédiger du texte, puis de demander au code d’en deviner le sens.

Mais passer d’une démonstration de classification des e-mails à un workflow métier complet exige de concevoir le contrôle après la classification : quels tickets peuvent être routés automatiquement, quels signaux doivent être détectés séparément, quand une personne doit intervenir, comment le système se replie lorsque le service échoue et comment vérifier continuellement les seuils sur des données réellement annotées.

Un système de tickets utilisant Jev ne doit donc pas être évalué uniquement en demandant « à quelle vitesse a-t-il classé 500 e-mails ? ». La question la plus utile est :

Réduit-il de manière stable les transferts inutiles, les appels de modèles et le premier tri humain sans manquer les tickets à haut risque ?

Ce n’est que lorsque cette question reçoit une réponse positive sur les propres données métier de l’organisation que le routage des e-mails passe d’une démonstration de modèle à un workflow réellement utilisable.