Trier les e-mails avec l'IA : classification, attribution et gestion des exceptions

Un système qui lit le courrier entrant et le trie fonctionne bien sur les messages normaux. Le problème est que les e-mails qui font perdre du temps ne sont pas normaux : ce sont ceux qui sont ambigus, ceux transférés trois fois, ceux où l'information se trouve dans la pièce jointe et où le texte dit seulement « comme convenu ». C'est sur ceux-là que se décide si le système enlève du travail ou en ajoute.

La question utile n'est pas de savoir si un modèle peut lire les e-mails, car il le peut. C'en est une autre : que lui laissons-nous décider seul, que doit-il se limiter à proposer, et où finit ce qu'il n'a pas compris.

Les catégories : peu nombreuses, distinctes, avec un destinataire

Les catégories ne sont pas une ontologie de votre entreprise : ce sont la liste des chemins qu'un message peut emprunter. Si deux chemins mènent au même bureau et au même travail, c'est un seul chemin.

• Une catégorie existe si elle change qui prend en charge le message ou ce qui se passe ensuite. Sinon, c'est une étiquette décorative.
• Chaque catégorie a un destinataire opérationnel : une personne ou un groupe qui répond, pas une adresse générique que tout le monde lit et que personne ne surveille.
• Il doit exister une catégorie « à examiner », et l'utiliser ne doit pas être considéré comme un échec du système : c'est le comportement correct face à un message ambigu.
• La priorité est un attribut distinct de la catégorie. Une réclamation urgente et une réclamation ordinaire vont au même endroit, avec un ordre différent.

Ce qu'il peut décider et ce qu'il doit proposer

Le critère pour répartir les responsabilités est unique : combien coûte la correction de l'erreur une fois qu'elle a été commise. Si la correction est immédiate et visible, l'automatisme peut décider. Si l'erreur se propage en silence dans d'autres systèmes, non.

La ligne sur l'extraction des données est celle qu'on saute le plus souvent, car c'est aussi celle qui fait gagner le plus de temps. Le compromis praticable consiste à montrer la donnée extraite à côté du point du message d'où elle a été prise, afin que la confirmation demande une seconde au lieu d'une relecture.

Les messages sur lesquels il faut vraiment tester

Un échantillon de test fait d'e-mails bien rangés ne prouve rien. L'échantillon utile se construit en prenant, dans la vraie boîte, les cas qu'une personne expérimentée résout en ralentissant.

• Le message qui contient deux demandes différentes : une commande et une réclamation dans le même e-mail.
• Le transfert avec tout l'historique en dessous, où la vraie demande tient dans les trois premières lignes et le texte le plus long est l'ancien.
• La réponse d'une personne à une notification automatique, qui arrive avec un objet qui n'a rien à voir.
• La pièce jointe qui contient l'information, avec le corps du message vide ou réduit à « voir pièce jointe ».
• La pièce jointe qui est la photo d'un document, de travers et avec l'ombre de la main.
• Le message à l'objet erroné parce que l'expéditeur a répondu à un ancien e-mail au lieu d'en écrire un nouveau.
• La demande incomplète : il manque le code, il manque l'adresse, il manque la quantité.
• Les messages automatiques : absence du bureau, échec de livraison, communications de service des fournisseurs.

Confirmer avant les actions qui comptent

La confirmation humaine fonctionne si elle est rapide. Si elle exige de rouvrir le message, chercher la donnée et la réécrire, les personnes cessent de confirmer et commencent à approuver sans regarder, ce qui est la pire situation de toutes.

• Montrer à côté de chaque donnée extraite le point du message d'où elle provient.
• Distinguer « non trouvé » de « trouvé mais incertain » : ce sont deux situations qui demandent des actions différentes.
• Permettre la correction d'un champ sans relancer tout le traitement.
• Fixer un seuil en dessous duquel le message part de toute façon en révision, décidé avec ceux qui travaillent et revu après les premières semaines.

La file de révision : où finissent les cas douteux

Tout ce que le système ne résout pas doit finir à un seul endroit, avec un responsable et un délai maximal de séjour décidé par vous. Une file sans responsable transforme le système en un second endroit où les demandes se perdent : c'est la façon la plus courante d'aggraver la situation de départ.

• Chaque correction est enregistrée : ce que le système avait proposé, ce qui était juste, qui a corrigé.
• Les corrections se comptent par type, pas une par une : elles servent à comprendre où le système se trompe systématiquement.
• La file a une taille attendue. Si elle croît, ce n'est pas un problème de patience : c'est un signal que les catégories ou les seuils ne fonctionnent pas.

Corriger les erreurs récurrentes

1. Regrouper les corrections par type, à la fin de chaque semaine dans les premières phases.
2. Distinguer trois causes : catégorie mal définie, information absente du message, défaut du système.
3. Intervenir sur la bonne cause. Une catégorie mal définie se redéfinit avec ceux qui travaillent, elle ne se compense pas avec des instructions toujours plus longues.
4. Retester sur le même échantillon avant de remettre en fonction, pour vérifier qu'on n'a pas cassé les cas qui fonctionnaient.

Quand l'information n'est pas dans le message, aucun modèle ne peut la déduire. Dans ce cas, on intervient en amont : le formulaire du site demande le code, la signature automatique du client indique la référence, le fournisseur reçoit des indications sur comment écrire l'objet.

Quand il ne vaut pas la peine d'automatiser

• Si le volume est faible et qu'une personne vide la boîte en quelques minutes : le temps gagné ne compense pas la supervision.
• Si les catégories sont encore en discussion entre services : le système rendrait automatique un désaccord.
• Si personne ne peut surveiller la file de révision tous les jours.
• Si la boîte reçoit des données particulièrement sensibles et qu'il n'a pas encore été décidé qui peut les voir, où elles résident et combien de temps elles restent.
• Si le processus en aval est déjà désordonné : trier plus vite vers un désordre produit du désordre plus vite.

Dans plusieurs de ces cas, la voie praticable est plus étroite et plus utile : ne pas tout trier, mais seulement une catégorie bien définie et à volume élevé, en laissant le reste tel qu'il est aujourd'hui.

Ce que ce guide ne couvre pas

Ici, on traite l'interprétation du courrier électronique : catégories, tests, limites des décisions automatiques. La façon de recueillir sans les perdre les demandes qui arrivent par des canaux différents — site, e-mail, messagerie, téléphone — est traitée dans le guide dédié. L'extraction de données depuis des documents structurés, avec les vérifications qu'elle exige, fait elle aussi l'objet d'un guide à part.