Qualifier les demandes entrantes avec l’IA : router, demander une précision ou s’abstenir

La boîte de réception est triée, mais les demandes continuent de circuler entre services. Un message envoyé à la facturation demande seulement le suivi d’un colis ; une panne de téléchargement est traitée comme une demande de copie. Le libellé paraît plausible et le ticket a bien une destination. Le coût de cette friction apparaît dans les transferts, les questions répétées et le délai avant qu’une personne reprenne la tâche réellement demandée.

En pratique, une catégorie proposée ne suffit pas à autoriser le routage. Il faut préciser quelle décision le destinataire prendra, quelles informations manquent, si le message contient plusieurs tâches et quelle conséquence aurait une mauvaise orientation. L’IA peut suggérer un classement ; la politique métier conserve les demandes qui exigent une clarification ou une revue, même lorsque la catégorie semble certaine.

Un jeu fictif de douze messages permet d’examiner ce contrat. Les catégories de référence et les propositions volontairement imparfaites sont écrites à la main. Les calculs portent uniquement sur ces lignes ; aucun modèle, connecteur ou processus client n’a été testé. La matrice sert à préparer une recette, avec une politique de routage attendue qu’il faudra ensuite implémenter et évaluer sur des données autorisées.

Avant de raccorder cette IA sur mesure aux files de vos équipes, faites qualifier une demande simple, une demande mêlant deux tâches et une demande sans référence exploitable. Pour ce processus de qualification assistée par l’IA, le destinataire doit expliquer ce qu’il peut traiter et les informations qu’il lui manque. Ces réponses fixent les catégories et les reprises avant qu’un classificateur commence à déplacer les tickets.

Pour qui automatiser la qualification des demandes

Partir des transferts qui coûtent du travail

Le sujet concerne services support, opérations, équipes administratives et responsables produit qui reçoivent des formulations libres. Le diagnostic commence par les demandes transférées, les catégories corrigées et les messages qui restent sans propriétaire. Un tri déjà correct mais trop lent ne demande pas la même amélioration qu’un classement rapide qui oublie une seconde tâche.

Le périmètre retenu reçoit des messages déjà lisibles, associés à un compte identifié. Il classe la tâche attendue et propose une file interne. Il ne récupère pas des montants dans des scans, ne corrige pas une facture et ne répond pas au client en autonomie. Un formulaire structuré ou une règle existante reste une option à comparer avant d’ajouter une classification sémantique.

Définir la décision portée par chaque destination

Une file doit avoir une compétence, des droits et une conduite pour les messages reçus par erreur. « Divers » ne constitue pas une reprise si personne ne consulte cette catégorie. Le responsable du triage précise aussi les motifs qui exigent une validation préalable. Dans notre politique fictive R-1, une contestation de facturation passe en revue humaine avant son orientation définitive.

Anthropic décrit le routage comme un workflow qui classe une entrée puis la dirige vers une tâche spécialisée. Cette publication de 2024 fournit un principe d’organisation ; elle ne prouve ni la justesse des catégories d’une entreprise ni la pertinence d’un seuil. Ces deux éléments restent à établir dans votre recette et votre processus.

Définir les catégories et les demandes mixtes

Classer l’action demandée plutôt que le mot rencontré

R-1 distingue Suivi, Facture et Technique. Suivi traite une demande sur un événement de commande ou de transport. Facture traite une copie ou une correction métier de facturation. Technique traite le diagnostic d’un écran, d’un chargement ou d’une erreur applicative. Un PDF de facture qui ne se télécharge pas peut donc relever de Technique, tandis qu’une adresse erronée sur la facture relève de Facture.

Le référentiel d’annotation donne des exemples et contre-exemples aux correcteurs. Il décrit les frontières, les faits nécessaires et les cas qui ne doivent pas être forcés dans une classe. La référence n’est pas le service qui a reçu le message historiquement : une ancienne mauvaise orientation ne devient pas la vérité terrain du projet. Les désaccords sont arbitrés par le métier et conservés avec la version du référentiel.

Préserver plusieurs tâches dans un même message

La classe Mixte signifie que plusieurs décisions doivent être conservées. Elle ne signifie ni message incompréhensible ni classe inconnue. Dans R-1, une demande de suivi et une contestation de montant restent visibles ensemble. L’équipe décide ensuite si elle garde un dossier commun ou répartit des tâches liées, avec un responsable qui contrôle leur achèvement.

Le choix d’une classe Mixte simplifie notre exemple de matrice à une étiquette par message. Une implémentation peut préférer un classement multi-étiquette ou des tâches séparées. Sa recette doit alors mesurer les tâches omises et les liens entre elles, avec les métriques adaptées. Passer en multi-étiquette ne garantit pas que la seconde demande sera détectée ; cela évite seulement de l’interdire dans le contrat de sortie.

Douze messages fictifs et leurs décisions attendues

Figer la référence et des propositions contestables

Les douze exemples supposent compte et périmètre déjà identifiés. « Proposition » désigne un libellé illustratif écrit pour provoquer des erreurs, pas la sortie observée d’un modèle. « Traitement R-1 » désigne l’éligibilité attendue après contrôles, pas un routage exécuté. Les corrections et contestations restent en revue ; toutes les demandes mixtes sont examinées avant répartition.

Évaluer les contrôles sans leur donner la référence

La catégorie de référence sert au correcteur de recette ; le moteur ne doit jamais la recevoir en entrée de production. Les contrôles doivent reconnaître les motifs de revue à partir du message, du contexte autorisé et des signaux effectivement disponibles. Pour Q-02 et Q-10, la recette vérifie précisément que la tâche de suivi ou la seconde demande n’est pas oubliée.

Si la classification et ses contrôles produisent ensemble une interprétation fausse, la politique peut encore laisser passer l’erreur. Le tableau fixe ce que l’équipe souhaite obtenir ; il ne prouve pas que son moteur sait déjà le faire. Des variantes qui retirent un signal de revue ou proposent une seule tâche malgré un message mixte servent à contester ce contrat lors de l’implémentation.

Lire la matrice de confusion sans perdre les erreurs rares

Compter les propositions avant les décisions de routage

Les lignes représentent les catégories de référence et les colonnes les propositions. Cette convention correspond à la matrice de confusion décrite par scikit-learn. La diagonale compte les accords ; une cellule hors diagonale montre une confusion précise. Nos douze lignes donnent les effectifs ci-dessous, vérifiés arithmétiquement sur les exemples manuscrits.

La diagonale vaut 2 + 2 + 3 + 1, soit 8 accords sur 12 propositions : environ 66,7 %. Ce taux décrit notre construction fictive. Il ne mesure ni la rapidité du triage, ni l’effet des erreurs, ni la fiabilité d’un fournisseur. Les quatre désaccords sont Q-02, Q-05, Q-10 et Q-11 ; leurs conséquences doivent être examinées individuellement.

Distinguer précision d’une classe et rappel de ses demandes

La proposition Mixte est correcte dans son unique occurrence : précision 1/1 sur ce jeu. Pourtant, seule une des trois demandes réellement mixtes est reconnue comme telle : rappel 1/3. Paradoxalement, une catégorie peut donc afficher une précision parfaite tout en laissant disparaître la majorité des demandes qui devraient y entrer. Un tableau réduit aux erreurs des seuls dossiers étiquetés Mixte manquerait Q-10 et Q-11.

La matrice expose aussi la fausse orientation vers Facture : quatre propositions portent ce libellé, dont deux correspondent à la référence Facture. La lecture par classe aide à choisir une correction de définition, de contexte ou de contrôle. Les effectifs restent minuscules ; aucune estimation de performance réelle ne peut être déduite de ces fractions sans un jeu de test représentatif et indépendant.

Séparer catégorie proposée et permission de routage

Appliquer les conséquences et les droits côté application

R-1 envisage le routage automatique pour une tâche simple de suivi, une copie de facture ou un diagnostic applicatif dans le périmètre autorisé. Corrections, contestations, demandes mixtes et contradictions passent en revue. Cette règle est propre à l’exemple ; elle ne signifie pas que toutes les entreprises doivent traiter une contestation de la même façon. Le propriétaire du processus choisit les conséquences acceptables et les compétences de chaque file.

La décision de routage vérifie aussi identité du compte, portée des documents et destination autorisée. Un classement correct ne donne pas le droit de partager le message avec n’importe quel service. Une destination absente du référentiel ou un rôle retiré suspend la transmission. Le serveur applique la politique ; un champ « routage permis » proposé par le modèle ne crée aucune autorisation.

Donner une conséquence distincte à chaque incertitude

Une abstention de classement signifie que la classe n’est pas suffisamment établie. Une clarification demande un fait utile à la décision, par exemple le numéro de dossier ou l’action attendue. Une revue de politique peut garder une catégorie claire tout en suspendant le routage, comme Q-06. Ces états doivent produire des tâches différentes ; tout envoyer dans une file « incertain » sans motif déplacerait simplement le problème.

• Router une proposition admissible après vérification du contexte, de la politique et de la destination.
• Demander une précision lorsque la réponse attendue dépend d’un fait que le demandeur peut fournir.
• Faire revoir une conséquence sensible, une contradiction ou une demande à plusieurs tâches.
• Conserver hors périmètre une demande qui ne possède pas encore de traitement approuvé, sans inventer une classe de secours.

La gravité concerne l’effet d’une mauvaise orientation autant que la catégorie. Une erreur vers une file non habilitée peut exposer des informations ; une erreur vers une file lente peut retarder une décision. Le seuil de poursuite tient compte de ces conséquences et de leur réparabilité. Il reste lié à un cas de recette et à une capacité réelle de reprise humaine.

Évaluer la confiance avant de choisir un seuil

Ne pas transformer un nombre annoncé en probabilité de réussite

Une confiance déclarée dans une réponse générative n’est pas automatiquement calibrée. La documentation sur la calibration probabiliste décrit la relation entre probabilités annoncées et fréquences observées de classes correctes. Cette relation demande des données de validation ; un libellé certain ou un pourcentage produit dans une réponse ne la démontre pas.

Le contrat précise ce que le fournisseur expose réellement : probabilité d’un classifieur, score technique, distance ou simple autoévaluation. L’équipe peut choisir de ne pas utiliser ce nombre. Une règle de conséquence, un contexte absent ou un signal de demande mixte peut imposer la revue indépendamment d’un score élevé. Les douze messages ne contiennent aucune probabilité fictive qui prétendrait justifier leur éligibilité.

Choisir un seuil sur des données séparées du test final

Le réglage compare taux d’erreur accepté, couverture et charge de revue sur un ensemble réservé à cette décision. Le test final reste séparé pour éviter d’adapter la règle aux cas qui serviront à l’évaluer. Les dossiers liés à une même conversation ou à un même modèle de message doivent être répartis de façon à limiter les fuites entre ensembles.

La recette ajoute les classes rares, formulations nouvelles, langues utiles et périodes qui changent le flux. Les seuils peuvent varier par conséquence si les observations le justifient. Un petit effectif ou une classe nouvelle demande davantage de prudence et de revue ; il ne justifie pas un seuil numérique universel. Toute modification de taxonomie, prompt ou modèle repasse les contrôles qu’elle affecte.

Donner une reprise aux demandes incertaines

Présenter le motif et la tâche qui reste à décider

La revue affiche le message original, les faits de contexte autorisés, la catégorie proposée et le motif de suspension. Pour Q-02, l’opérateur voit la demande de suivi et la proposition Facture. Pour Q-06, il voit une contestation qui exige sa validation selon R-1. Il peut corriger la catégorie, demander un complément ou confirmer l’orientation autorisée, avec des effets distincts dans le dossier.

Une clarification doit demander le fait utile à la reprise. « Précisez votre demande » oblige le client à deviner ce qui manque. « Souhaitez-vous une copie de la facture ou signaler une erreur au téléchargement ? » présente deux tâches compréhensibles lorsque cette distinction est réellement incertaine. La réponse reçue crée une nouvelle version de contexte ; elle ne valide pas automatiquement la proposition précédente.

Garder un responsable pour les demandes mixtes

Q-10 conserve suivi et contestation, même si la première proposition mentionne seulement Suivi. Le responsable de revue confirme les tâches avant leur répartition. Si l’application ouvre plusieurs traitements, le dossier parent permet de savoir quelle tâche reste attendue. Un message n’est pas considéré comme entièrement pris en charge parce qu’une de ses tâches possède une destination.

La file de revue conserve propriétaire, motif, date d’entrée, contexte attendu et prochaine étape. Son âge et sa capacité font partie de l’exploitation. Le mode dégradé doit permettre de qualifier les demandes sans la proposition IA. Une panne du classifieur ne doit ni effacer les messages ni les marquer comme routés ; elle ouvre le repli prévu par le processus.

Relier la proposition à un contrat de traitement

Séparer la sortie de classification et la décision serveur

Le contrat reçoit en entrée l’identifiant et la version de demande, le message autorisé et le contexte nécessaire. La sortie de classification porte une catégorie admissible et les éléments qui la soutiennent, avec une abstention possible. Le serveur vérifie les valeurs, applique sa politique et choisit une destination permise. La journalisation conserve les versions utilisées et le motif de décision, dans une trace accessible aux rôles de contrôle.

Cette trace JSON fictive réunit la proposition et la décision sur Q-02. Elle n’est pas un protocole fournisseur et ne décrit aucune API exécutée. L’action structurée Suivi entre en conflit avec la proposition Facture ; R-1 demande une revue et aucune remise à une file cible n’est confirmée. L’extrait cité reste lié au message d’origine.

{
  "requestId": "Q-02",
  "requestRevision": 1,
  "proposal": {
    "label": "Facture",
    "tasks": ["Suivi"],
    "evidence": "je cherche le suivi du colis"
  },
  "decision": {
    "status": "review_required",
    "reason": "task_label_disagreement",
    "policyRevision": "R-1"
  },
  "delivery": {
    "status": "not_dispatched"
  }
}

Tester une sortie cohérente mais fausse

Comparer des champs détecte une contradiction interne ; cela ne prouve pas qu’une sortie cohérente comprend le message. La recette doit aussi présenter Q-02 avec label Facture et tâche Facture, ou Q-10 avec une seule tâche Suivi. Si les contrôles ne voient pas l’omission, l’erreur peut franchir la politique. Ces variantes servent à mesurer les limites de l’extraction des intentions et du contrôle, pas à revendiquer leur indépendance.

Le moteur relie la décision à la version courante de demande et à la destination autorisée. Une correction humaine ou un complément invalide une proposition devenue obsolète. La remise au système de tickets possède son propre statut vérifiable ; une catégorie enregistrée ne prouve pas que la file cible a accepté le dossier. Une reprise consulte l’état existant avant de créer une nouvelle orientation.

Mesurer couverture, qualité et travail humain

Conserver les demandes suspendues dans le bilan

R-1 rend six demandes du jeu éligibles au routage automatique : Q-01, Q-03, Q-04, Q-07, Q-08 et Q-09. Les six autres demandent une revue. La couverture attendue de cette politique sur nos exemples vaut donc 6/12, soit 50 %. Les six propositions éligibles correspondent ici à leur référence. Cette sélection manuelle ne démontre aucun taux d’erreur réel d’un moteur.

Le bilan conserve aussi les quatre propositions incorrectes, les catégories correctes suspendues par politique et les demandes mixtes. Présenter uniquement l’accord sur les six dossiers éligibles masquerait la moitié du travail encore nécessaire. Le test réel doit mesurer si la politique détecte les motifs attendus et si les dossiers admis restent conformes, avec les effectifs et les conséquences de chaque erreur.

Comparer le processus complet à sa situation de départ

Le monitoring suit erreurs de catégorie, tâches omises, faux motifs de revue, corrections, transferts après routage et délai de qualification. La mesure du travail humain inclut lecture, complément, réorientation et traitement des demandes sans propriétaire. Une baisse du temps de classification peut être annulée par une augmentation des questions répétées ou de la file de revue.

La comparaison utilise une période et un périmètre explicites, avec une qualification de référence représentative. Elle rapporte les résultats par canal, classe et conséquence. Un changement de portefeuille de demandes peut expliquer un écart sans changement de modèle ; une amélioration apparente peut aussi venir de demandes difficiles désormais exclues. Le comité garde visibles ces changements de couverture avant de décider une extension.

Erreurs fréquentes dans le classement des messages

Apprendre la mauvaise frontière à partir des anciens tickets

Les catégories historiques peuvent refléter une organisation disparue, une équipe qui a repris des demandes faute de place ou une correction jamais enregistrée. Les utiliser comme référence sans revue apprend ces détours au nouveau système. La recette commence par des frontières validées pour les décisions actuelles et distingue catégorie proposée, destination initiale, correction et responsable final.

Les messages presque identiques créent une autre difficulté. Une conversation découpée en plusieurs tickets peut se retrouver dans le réglage et dans le test, avec les mêmes formulations. Le taux d’accord obtenu ne représente alors pas des demandes nouvelles. L’équipe regroupe les éléments liés avant la séparation et documente l’unité d’évaluation retenue : message, demande ou tâche.

Utiliser une file humaine pour dissimuler l’absence de règle

« À revoir » doit conduire à un choix que quelqu’un peut réaliser. Une classe inconnue exige une décision sur la taxonomie ; un compte non confirmé exige un contexte ; une demande mixte exige une revue des tâches. Mélanger ces motifs empêche d’identifier la bonne correction et charge la même équipe de problèmes qu’elle ne peut pas tous résoudre.

À l’inverse, forcer une classe parmi les trois plus fréquentes fait disparaître le hors-périmètre. Le contrat doit pouvoir recevoir une abstention et une demande nouvelle. L’ajout d’une catégorie passe par exemples, destinataire, droits, recette et procédure de reprise. Un nom ajouté dans le prompt ne constitue pas encore un processus de traitement approuvé.

Plan d’action : préparer une recette de qualification

Construire les catégories et les décisions attendues ensemble

Le responsable du triage et les équipes destinataires sélectionnent des demandes qui se transfèrent ou restent ambiguës. Ils décrivent la tâche attendue et la compétence nécessaire, puis annotent classe, contexte manquant et traitement permis. Un désaccord récurrent est traité avant le réglage du modèle : la référence doit être suffisamment claire pour qu’une correction ait un sens.

1. Définir les tâches, les frontières entre catégories et le traitement des demandes mixtes.
2. Établir une référence métier sur des messages autorisés et conserver les désaccords arbitrés.
3. Fixer les motifs de clarification, de revue et de hors-périmètre avec leurs responsables.
4. Écrire le contrat d’entrée, de proposition et de décision serveur, sans fournir la référence au moteur.
5. Tester classement, omissions de tâches et application de politique, puis rapprocher les résultats.
6. Comparer couverture, transferts et travail de revue avant d’ouvrir un routage supplémentaire.

La recette du scénario Q-10 conserve ses deux tâches même lorsque la proposition n’en décrit qu’une. Elle teste aussi une erreur cohérente dans tous les champs, un contexte absent et une destination retirée. Les résultats attendus portent sur le dossier et sa reprise, pas seulement sur la validité du JSON. Le propriétaire peut ainsi bloquer une extension qui améliorerait le taux moyen mais oublierait la contestation.

Préparer la suspension et la reprise du routage

Le runbook indique comment suspendre la remise automatique sans perdre les demandes reçues. La file humaine garde identifiant, motif et prochain responsable. La journalisation distingue erreur de classification, refus de politique et échec de remise. Le monitoring alerte sur le délai de la plus ancienne revue et sur les dossiers qui n’ont plus de destination approuvée.

Le repli doit être testé avec une proposition indisponible et avec une file humaine saturée. L’équipe fixe ses seuils de capacité à partir de mesures locales, sans supposer une cadence universelle. Une reprise rapproche les décisions existantes avant de traiter le backlog. L’extension n’est ouverte que si les exceptions peuvent être revues et les orientations corrigées dans les conditions du service.

Guides complémentaires pour le dossier et la responsabilité

Relier la qualification à un état de travail

Le dossier métier avec IA, états et exceptions décrit comment conserver un contexte incomplet, une proposition périmée et une reprise. Le contrat de mission d’un agent support précise ce que l’assistant peut consulter et proposer avant de changer le travail d’une équipe.

La classification reste une étape de ce parcours. Elle ne confirme ni la prise en charge finale ni le traitement de toutes les tâches. Le suivi du dossier relie les destinations et les validations utiles, tandis que la recette de qualification conserve la preuve de ce qui a été proposé et de ce qui a réellement été autorisé.

Garder l’extraction et la revue dans leur périmètre

L’extraction, le classement et le routage documentaire traitent les fichiers, champs et pièces sources. Le workflow humain et IA avec responsabilité de décision approfondit l’autorité du validateur et la capacité de reprise. Les messages de notre jeu supposent déjà une entrée lisible.

Ces frontières évitent de traiter une mauvaise pièce extraite comme une simple erreur de catégorie, ou une file sans responsable comme un problème de confiance du modèle. Chaque étape possède sa preuve et son correctif. Le triage commence par la tâche demandée ; l’exploitation confirme que cette tâche a trouvé un traitement autorisé et observable.

Conclusion : décider ce que la classification autorise

Qualifier une demande signifie comprendre la tâche attendue et sa portée. Le routage ajoute une décision sur la destination, les droits, les conséquences et la reprise. Une bonne catégorie peut rester en revue ; une proposition cohérente peut encore oublier une seconde tâche. La politique doit préserver ces distinctions dans le dossier comme dans les mesures.

Les douze messages fictifs rendent visibles des confusions, un rappel faible des demandes mixtes et une couverture attendue de moitié pour R-1. Les calculs sont vérifiables sur ce jeu manuscrit ; ils ne prouvent aucune performance de modèle. La recette réelle doit contester les motifs de revue, les omissions et les dossiers admis, avec des données séparées du réglage.

Le pilote de qualification IA de vos demandes métier doit conserver Q02 et Q10 dans sa revue : le premier révèle une mauvaise destination, le second une tâche omise dans une demande mixte. Des champs cohérents ne suffisent pas à découvrir ces erreurs. Le responsable de chaque file vérifie donc le message original, le travail reçu et le motif de reprise avant d’autoriser davantage de routages.

Dawap vous accompagne pour définir les catégories, relier les files à vos logiciels et bâtir la recette d’une IA métier sur mesure connectée à vos opérations. Le premier routage commence par une tâche que le destinataire sait traiter, une erreur que le processus sait détecter et une demande incertaine qui conserve un responsable jusqu’à sa résolution.