Classification mailbot : routage d’intents + active learning (N1→N2)

La classification : le GPS de votre support (et pas un “petit modèle de tri”)

Si vous ne deviez investir que dans une seule brique d’un mailbot, je mettrais une pièce sur celle-ci.

Pas parce qu’elle fait rêver.

Mais parce qu’elle évite l’enfer opérationnel : les e-mails qui partent au mauvais endroit, les SLA explosés, les équipes qui se renvoient la balle et, au bout du compte, le client qui écrit “bonjour ???” pour la 4e fois.

La classification n’est pas seulement “mettre une étiquette”.

En production, elle répond à quatre questions très concrètes :

1. De quoi parle cet e-mail ? (intention, ou ensemble d’intentions)
2. À quel point c’est urgent ? (priorité/SLA)
3. À quel point c’est risqué ? (juridique, fraude, PII, action irréversible)
4. Qui doit s’en occuper ? (route : N1 auto, N2 contextualisé, ou HITL)

N1/N2/HITL : la classification pilote la réalité (pas la démo)

Je reprends un modèle simple (et robuste) :

• N1 : compréhension + réponses standard + collecte d’infos manquantes
• N2 : identification + personnalisation + actions backoffice (avec garde-fous)
• HITL : escalade quand la confiance est insuffisante, ou quand le risque monte

La classification est la télécommande qui décide :

• “on répond automatiquement”,
• “on répond mais on personnalise”,
• “on prépare un brouillon pour validation”,
• “on escalade, maintenant”.

Autrement dit, la question n’est pas “le modèle est-il bon ?” mais :

“Avec quel niveau de confiance je peux automatiser cette catégorie, dans ce contexte ?”

Et ça, ce n’est pas une question de magie. C’est une question de design.

Taxonomie : le piège de la liste infinie (et comment en sortir vivant)

La plupart des taxonomies meurent d’une mort bête : elles grandissent comme une to-do list.

“Ah, on a eu un mail sur X, ajoutons une catégorie X.”

Six mois plus tard :

• 83 catégories,
• des labels qui se chevauchent,
• des équipes qui ne sont jamais d’accord,
• et un mailbot qui hésite comme un GPS dans un tunnel.

1) Le bon réflexe : hiérarchiser

Commencez large, puis affinez.

Exemple (très générique) :

• Support
  • bug / incident
  • facturation
  • accès / compte
• Commercial
  • demande de démo
  • réponse à prospection
  • partenariat
• Juridique & conformité
  • mise en demeure
  • RGPD (accès/suppression)
  • fraude / usurpation

Pourquoi ça marche ?

Parce que vous pouvez déjà router au niveau “Support/Commercial/Juridique” avec très peu de risque.
Et seulement ensuite, utiliser un modèle plus fin pour distinguer “facturation” vs “accès”.

2) Multi-label (oui, un e-mail peut être deux choses à la fois)

Un mail peut contenir :

• une question facturation,
• et une menace de résiliation,
• et une pièce jointe sensible.

Si vous forcez un seul label, vous perdez une partie de la vérité.

Pattern efficace :

• intent principal (route),
• intents secondaires (signals),
• risk flags (garde-fous),
• missing info (questions de clarification).

3) La catégorie la plus importante : “unknown”

Elle ne fait pas joli en démo. Elle sauve votre prod.

“Unknown intent” signifie :

• le mail ne ressemble à rien de connu,
• ou il est trop ambigu,
• ou le modèle n’est pas sûr,
• ou les infos manquent.

Plutôt que d’inventer, le mailbot doit :

• demander une précision,
• créer un ticket,
• ou escalader.

Comment router sans se tromper : confiance, seuils, et “coût d’erreur”

En machine learning, on adore l’accuracy.

En support, l’accuracy est un indicateur… mais la vérité, c’est le coût d’erreur.

Se tromper entre “question sur une facture” et “question sur un délai” : pas grave.
Se tromper entre “résiliation” et “bug mineur” : vous perdez un client.
Se tromper entre “fraude” et “demande standard” : vous perdez beaucoup plus qu’un client.

La stratégie robuste :

• calculer un score de confiance,
• appliquer des seuils par intent (pas un seuil unique),
• pondérer par risque et irréversibilité.

Le routage comme une table de décision

Le plus simple à opérer est souvent le plus simple à expliquer :

Quelle techno pour classer ? (règles, ML, LLM, hybride)

On peut classifier un e-mail de plusieurs façons. Le bon choix dépend de :

• volume,
• diversité des intents,
• langue,
• exigences de conformité,
• et budget.

Comparatif sans romantisme

Où les modèles 2026 entrent en jeu

Pour le routage par LLM, vous avez le choix :

• API commerciales : OpenAI, Anthropic, Google, Mistral… (pratique, rapide).²³⁴⁵
• Open weights : Llama 4 et compagnie (souveraineté, coût stable… mais ops GPU).⁶

Et oui, ça compte — surtout si votre classification est appelée sur chaque e-mail.
Mais rappelez-vous : une taxonomy propre + des seuils propres, c’est souvent un meilleur ROI qu’un “upgrade de modèle”.

Active learning : transformer l’escalade en moteur d’amélioration (sans ruiner l’équipe)

Un mailbot apprend de deux façons :

• “à froid” (en entraînant/ajustant sur un dataset),
• “à chaud” (en exploitant le feedback humain).

L’active learning est la discipline qui transforme “les cas difficiles” en “données de training” de manière efficace.¹

Concrètement, l’idée est presque triviale :

• au lieu d’étiqueter au hasard,
• vous étiquetez ce qui vous apprend le plus.

Qu’est-ce qui “apprend le plus” ?

Trois familles classiques :

1. Uncertainty sampling : le modèle hésite → on label.
2. Diversity sampling : le modèle voit toujours la même chose → on cherche des cas différents.
3. Error-driven sampling : les erreurs qui coûtent cher → priorité absolue.

L’escalade HITL comme queue d’annotation

Si vous avez déjà une file HITL (et vous devriez), vous avez déjà :

• des cas incertains,
• des cas risqués,
• des cas hors scope.

Autrement dit : votre dataset se fabrique tout seul.

Le trick, c’est de capturer proprement :

• l’intent finale (label humain),
• la justification (si possible),
• les champs extraits,
• et les raisons d’escalade (confiance, risque, missing info).

Un “label” qui vaut de l’or : la raison de non-automatisation

Quand un humain prend la main, ne capturez pas seulement le résultat.

Capturez aussi le “pourquoi” :

• “trop ambigu”,
• “règle business non couverte”,
• “pièce jointe illisible”,
• “conflit de sources”,
• “risque juridique”.

Ce sont vos futures fonctionnalités :

• meilleure taxonomy,
• meilleur RAG,
• meilleure extraction pièces jointes,
• meilleure détection de risque.

Drift : quand le monde bouge (et que votre mailbot le découvre en dernier)

Même avec une taxonomy propre, vous aurez un autre phénomène : le changement.

Nouveaux produits, nouvelle tarification, nouvelle promo, nouvelle réglementation, nouvelle fraude, nouveau canal (“on a tout centralisé dans support@”), nouvelle équipe… Votre boîte mail est un organisme vivant. Elle mute.

Le drift en support se voit rarement comme une grande annonce. Il se voit comme une accumulation :

• plus d’“unknown” qu’avant,
• des temps de traitement qui remontent,
• un agent qui dit “c’est bizarre, j’ai 10 mails comme ça aujourd’hui”,
• et un routage qui commence à “sentir la poussière”.

Signaux simples à monitorer (sans faire un doctorat)

• Taux d’unknown par semaine (et par source)
• Top confusions (A ↔ B) : “facturation” vs “résiliation”, “partenariat” vs “spam”
• Distribution des intents (si une intent passe de 3% à 20%, il se passe quelque chose)
• Escalades HITL par motif (ambiguïté, risque, pièces jointes, conflit de sources)

Réponse opérationnelle (la version utile)

1. Mettre un owner sur la taxonomy (sinon personne n’ose la toucher).
2. Faire un rituel court : 30 minutes/semaine sur les erreurs + unknown.
3. Promouvoir/déprécier des intents (comme un produit) au lieu d’empiler.
4. Déclencher une mini-campagne de labelling quand un pattern apparaît (active learning ciblé).

Implémentation : un blueprint simple qui tient en prod

L’objectif est d’avoir un routage explicable (par une phrase) et opérable (par une équipe).

1

Définir 10–20 intents “macro”

Commencez par une hiérarchie simple. Mesurez 2 semaines. Ajustez. Évitez la taxonomy “encyclopédie” au départ.

2

Ajouter risk flags indépendants

Juridique, fraude, PII, action irréversible… Ce ne sont pas des intents, ce sont des garde-fous.

3

Définir des seuils par intent

“Résiliation” n’a pas le même seuil acceptable que “mot de passe”. Vous automatisez d’abord là où le blast radius est faible.

4

Créer une file HITL et instrumenter

Chaque escalade devient un exemple. Capturez labels + raisons + temps de traitement.

5

Lancer l’active learning (petit) et itérer

Chaque semaine : top erreurs, intents “unknown”, confusion matrix, nouveaux exemples. Ajustez la taxonomy avant de changer de modèle.

Cas d’usage : assureur, marketing, prospection (le routage change tout)

Assurance : “sinistres@” n’est pas une catégorie, c’est une jungle

Un assureur reçoit :

• déclarations de sinistres (avec pièces),
• demandes de suivi,
• contestations,
• fraude,
• RGPD,
• et parfois… des sujets qui n’ont rien à voir (mais qui arrivent quand même).

La classification utile n’est pas “sinistre oui/non”.

C’est :

• type de sinistre (auto, habitation, santé),
• étape (déclaration, pièces manquantes, suivi),
• risque (fraude, juridique),
• urgence (dommages corporels).

Et à chaque fois : un seuil qui pilote l’automatisation.

Marketing / creators : votre inbox est une place de marché

Si vous gérez des faceless channels (TikTok/YouTube), votre boîte mail ressemble souvent à :

• offres de sponsoring,
• demandes de partenariat,
• notifications de plateforme,
• droits d’auteur / DMCA,
• factures et paperasse.

Le routage vous permet de :

• répondre vite aux bons deals,
• filtrer le bruit,
• escalader le juridique,
• et ne pas laisser un “bonjour, on vous propose un CPA très sérieux” dévorer votre journée.

Prospection commerciale : classifier les réponses, sinon vous vendez à des fantômes

L’outbound efficace n’est pas seulement “envoyer”.

C’est traiter les réponses :

• intéressé,
• pas maintenant,
• stop (désinscription),
• transfère à un collègue,
• “qui êtes-vous ?”

Sans classification, vous créez :

• des relances maladroites,
• de la friction,
• et des plaintes (deliverability, réputation).

Conclusion : la classification est une discipline de décision

Un mailbot fiable n’est pas un générateur de texte.

C’est un système de décision :

• taxonomy qui tient,
• unknown intent assumé,
• seuils de confiance,
• escalade HITL,
• et active learning pour apprendre.

Si vous faites ça, vous pouvez changer de modèle 2026 sans tout casser.

Si vous ne faites pas ça, le meilleur modèle du monde vous donnera juste des réponses… au mauvais endroit.

Checklist “routing ready”

• Taxonomie hiérarchique (macro → micro)
• Unknown intent + clarification
• Multi-label + risk flags séparés
• Seuils par intent (blast radius)
• File HITL instrumentée (labels + raisons)
• Active learning hebdo (erreurs + drift)
• Observabilité (confusion, temps de traitement, escalades)

FAQ

Questions frequentes

Faut-il un dataset dès le départ ?+

Pas forcément. Vous pouvez démarrer avec une taxonomy macro + un routeur LLM, puis collecter les escalades HITL comme dataset. Le piège est de ne pas instrumenter : sans labels, vous ne progressez pas.

Pourquoi les seuils doivent être par intent ?+

Parce que le coût d’erreur varie. Automatiser “réinitialisation mot de passe” à 90% peut être ok. Automatiser “résiliation” au même seuil peut être catastrophique.

Comment éviter la taxonomy qui explose ?+

Hiérarchie + multi-label + unknown. Et surtout : résister au réflexe “ajouter une catégorie pour chaque cas”. Le plus souvent, un risk flag ou un champ extrait résout mieux le problème.

Sources et references

1. [1]Settles — Active Learning Literature Survey (University of Wisconsin-Madison, 2009) :
2. [2]OpenAI — Documentation modèles (texte + audio + vision) :
3. [3]Anthropic — Liste des modèles Claude (aliases + snapshots) :
4. [4]Google — Gemini API : modèles disponibles :
5. [5]Mistral AI — Model catalog (texte, audio, OCR) :
6. [6]Meta — Llama 4 model card (open weights) :