Trier les mails d'un dirigeant : un humain sans réponse suffit

Un dirigeant de PME ne manque pas d'outils pour lire ses mails, il manque d'un endroit où voir ce qui l'attend, lui, et rien d'autre. La boîte de réception mélange le client qui signale une anomalie, le cabinet comptable qui réclame une pièce avant une échéance, la newsletter d'un salon et la énième relance d'une place de marché de liens. Tout arrive au même niveau sonore. Le temps passé à trier coûte peu, un client laissé sans réponse pendant plusieurs jours, parce que son message était coincé entre deux invitations de masse, coûte beaucoup plus.

Nous avons ce problème chez nous, comme tout le monde. Cette quinzaine, nous avons livré en production la version de notre cockpit interne qui transforme les mails du dirigeant en tâches à traiter. Le chantier nous a obligés à jeter notre première idée, et la règle qui l'a remplacée tient en une phrase. C'est ce compte rendu que vous lisez.

Ce que le cockpit doit montrer, et ce qu'il doit taire

Un écran de pilotage n'est lu que s'il ne montre que ce qui attend une décision. Notre cockpit est une application interne en quelques vues, parmi lesquelles les arbitrages que nos agents soumettent à un humain, les tâches ouvertes et l'état de la flotte de tâches planifiées. Les agents y poussent des tâches de deux origines : les fils de mails restés sans réponse, et les actions que le dirigeant a prises en réunion, rattachées au compte rendu d'origine, avec une échéance et un dédoublonnage.

Le constat de départ était simple. La liste des tâches issues des mails était polluée par des places de marché de liens et par des invitations de masse. Une liste où le bruit domine cesse d'être consultée, et le jour où elle contient une vraie urgence, personne ne la voit. Le même défaut existait côté flotte : les quelques tâches planifiées lancées hors de notre orchestrateur remontaient en fausse erreur, faute de statut à lire. Un tableau de bord qui crie au loup tous les matins apprend à son lecteur à ne plus regarder.

L'accueil ne montre donc plus que trois choses : les arbitrages en attente, les tâches prioritaires, et les tâches planifiées réellement en erreur. La flotte complète vit sur sa propre page. Les tâches lancées hors orchestrateur portent désormais un statut « sans retour » et la date de leur dernière trace dans les journaux, ce qui a ramené le compteur de fausses erreurs à zéro, sans masquer une panne réelle.

Première version : chercher l'action, et rater l'urgence

Notre première règle de tri exigeait qu'un mail contienne un marqueur d'action pour devenir une tâche, et elle a raté précisément les messages qui comptaient. L'intuition paraissait raisonnable : une tâche, c'est un message qui demande quelque chose, donc on cherche les tournures de demande. En rejouant la règle sur le courrier réel, trois fils sont passés à travers : un message urgent d'un client signalant une anomalie, un message du cabinet comptable sur une déclaration fiscale, et un échange avec un tiers.

Aucun de ces trois messages ne contenait le vocabulaire attendu. Un client pressé n'écrit pas « merci de bien vouloir », il décrit son problème. C'est le défaut de fond de toute sélection par mots-clés : elle lit le texte, et passe à côté de la relation qui donne son importance au message. Ce client-là aurait pu écrire n'importe quoi, son message méritait une réponse parce que c'est un client.

Nous aurions pu confier la décision à un modèle de langage, en lui demandant de juger si chaque mail « nécessite une action ». Nous ne l'avons pas fait, pour la même raison que nous ne laissons pas un modèle faire les calculs d'une analyse financière : une décision qui se répète chaque jour, sur tout le courrier, doit donner deux fois le même résultat et pouvoir s'expliquer en une ligne.

La règle qui tient : un humain sans réponse suffit

Tout fil écrit par un humain et resté sans réponse du dirigeant devient une tâche, et c'est tout le critère. Nous avons inversé la logique : au lieu de chercher ce qui ressemble à une action, le tri écarte ce qui n'est pas un humain, puis regarde si une réponse est partie. Les mots-clés n'ont pas disparu, ils ne servent plus qu'à fixer la priorité, et la priorité haute est réservée à deux sujets : l'urgence et l'argent.

Trois mécanismes rendent cette règle praticable.

Le premier écarte les envois de masse sans liste d'expéditeurs à maintenir. Un envoi de masse se trahit par ses en-têtes techniques de désinscription ou de campagne, que les outils d'emailing posent systématiquement. Ces en-têtes sont lisibles sur la totalité du courrier entrant. Une courte liste noire couvre en plus les places de marché de liens.

Le deuxième raisonne par fil de discussion, pas par message. Un fil produit une seule tâche, même s'il compte de nombreux messages. La tâche se ferme seule quand le dirigeant répond, et se rouvre si l'interlocuteur relance. Une tâche fermée à la main, en revanche, ne se rouvre pas : le geste humain l'emporte sur la règle.

Le troisième distingue les correspondants établis des inconnus. Un expéditeur à qui le dirigeant n'a jamais écrit doit, lui, porter un marqueur d'action pour entrer dans la liste. C'est ce filtre qui a écarté les fils de prospection commerciale, sans un seul faux positif constaté à la livraison.

Après nettoyage de la base, sauvegarde préalable à l'appui, la liste des tâches issues des mails est passée de 100 à 33 en base 100, et toutes les lignes restantes étaient de vrais sujets. L'auto-clôture s'est vérifiée d'elle-même : l'échange avec le tiers cité plus haut n'apparaissait pas dans la liste finale, parce que le dirigeant y avait déjà répondu.

Les pièges d'une IA déterministe : un en-tête trompeur, une liste trop courte

Une règle écrite en code a des angles morts, et ils se trouvent en la rejouant sur du courrier réel avant de la livrer. Ceux que nous avons rencontrés valent pour tout projet de ce type.

L'en-tête trompeur d'abord. Une passerelle de sécurité de messagerie ajoute aux mails qu'elle relaie un en-tête qui ressemble à celui d'une campagne. Le courrier d'un cabinet d'avocats passait ainsi pour de l'envoi de masse. Le défaut a été repéré et corrigé avant la livraison.

La liste des correspondants établis ensuite. Dans sa première version, elle ne comptait qu'une poignée de domaines. Nous l'avons reconstruite à partir de douze mois de mails envoyés : elle est aujourd'hui quatorze fois plus longue. Pour les messageries grand public, c'est l'adresse complète qui fait foi, pas le domaine, sans quoi n'importe quelle adresse personnelle deviendrait un correspondant de confiance. Rejouée sur trois semaines de courrier, la liste élargie aurait retenu plusieurs fils légitimes que la liste courte laissait passer.

Reste le rattachement des mails aux clients, qui se fait par domaine. Le domaine d'un tiers n'est pas celui du client auquel on serait tenté de le rattacher, et un client peut posséder un nom de domaine qui n'a jamais servi à sa messagerie. Nous avons documenté les absences volontaires de la table, pour éviter qu'un agent ou un collègue ne les rajoute un jour par symétrie.

Un dernier garde-fou encadre l'ensemble : au-delà d'un plafond de fils ouverts, l'agent qui produit les tâches s'arrête et propose un critère de tri supplémentaire, au lieu de déverser une liste que personne ne lira. Et côté technique, la messagerie impose une limite officielle de quatre requêtes concurrentes par boîte, ce qui borne la lecture en parallèle. La lecture des en-têtes en liste était ambiguë dans la documentation, nous l'avons validée par un test plutôt que par une lecture optimiste.

L'humain garde la main, y compris sur le filtre

Chaque geste du dirigeant dans le cockpit corrige le système au lieu de le contourner. Un bouton « Bruit » ferme la tâche et apprend l'expéditeur au producteur, qui écartera ensuite ses fils. Cet apprentissage a deux limites volontaires : il ne bloque jamais un client ni un domaine établi en entier, et il se débloque, sans rouvrir la tâche fermée. Nous avons recetté ce circuit de bout en bout contre la base réelle. À ce jour la liste apprise est vide, ce qui est plutôt bon signe pour les règles en amont.

Le reste du lot sert la même idée : un outil qu'on ouvre plusieurs fois par jour doit répondre tout de suite. Les reports se font en un geste (demain, lundi, dans une semaine), l'élément quitte l'écran avant la réponse de la base et revient avec le motif si l'écriture échoue, les compteurs s'affichent dans la navigation et dans le titre de l'onglet, et l'application s'installe sur un téléphone. Nous avons aussi rapproché les fonctions serveur de la base de données, dans la même région. Mesuré sur l'environnement de préproduction, le temps de réponse de l'accueil est passé de 100 à 20 en base 100. Nous ne l'avons pas encore mesuré sur la production ni sur un démarrage à froid, donc nous ne le présentons pas comme acquis.

Le même cockpit sert de point de validation pour nos agents. Pendant la quinzaine, une de nos boucles automatisées a proposé une modification sur un compte qu'elle pilote : elle n'a été appliquée qu'après une validation humaine donnée dans le cockpit. C'est notre doctrine sur les agents autonomes : l'agent exécute de bout en bout, l'humain tranche ce qui engage. Si vous voulez appliquer cette logique à un de vos processus, notre méthode commence par un diagnostic gratuit de trente minutes, sur un cas précis.

Questions fréquentes

Pourquoi ne pas demander à un modèle de langage de trier les mails ?

Parce que le tri est une décision répétée chaque jour sur tout le courrier. Elle doit être reproductible et s'expliquer en une ligne. Une règle en code (un humain, pas de réponse partie) donne deux fois le même résultat et se corrige quand elle se trompe. Le modèle garde sa place ailleurs, là où il faut lire et résumer.

Comment reconnaître un envoi de masse sans liste noire à maintenir ?

Par ses en-têtes techniques. Les outils d'emailing posent des en-têtes de désinscription ou de campagne sur chaque envoi. Les lire suffit à écarter newsletters et invitations, quel que soit l'expéditeur. Attention aux passerelles de sécurité de messagerie, qui posent des en-têtes ressemblants sur du courrier parfaitement humain.

Que se passe-t-il si la règle écarte un message important ?

Deux filets existent. Les correspondants établis, reconstruits depuis douze mois de mails envoyés, passent sans condition de vocabulaire. Et le filtre appris par le bouton « Bruit » ne peut jamais bloquer un client ni un domaine établi en entier, et il reste réversible.

Pourquoi une tâche par fil et pas une tâche par message ?

Parce que l'unité de travail du dirigeant est la conversation, pas le message. Un fil de devis avec de nombreux messages appelle une seule réponse. La tâche se ferme seule quand la réponse part, et se rouvre si l'interlocuteur relance.

Cette approche s'applique-t-elle à d'autres flux que les mails ?

Oui. Le principe (écarter ce qui n'est pas humain, puis chercher ce qui attend une réponse) vaut pour des tickets, des demandes internes ou des validations d'agents. Ce qui change d'un flux à l'autre, ce sont les signaux techniques disponibles et la liste des correspondants établis.

Combien de temps faut-il pour mettre en place un tri de ce type ?

Le code de la règle est court. Le temps se passe à la rejouer sur du courrier réel, à trouver les angles morts et à construire les listes de référence. Chez nous, la règle a été inversée une fois avant de tenir, et c'est cette itération qu'il faut prévoir.