Trier et router ses e-mails entrants automatiquement
En bref. Lors de la réunion de suivi de la boîte partagée, le responsable a constaté que près d’un tiers des messages restent sans traitement pendant plus d’une journée. Pour réduire cette perte, il suffit de classer les e-mails selon l’intention exprimée par l’expéditeur plutôt que selon des mots‑clés isolés. Cette approche s’appuie sur des modèles de langage léger (comme Mistral ou GPT‑4o) intégrés à un workflow d’automatisation (n8n ou Make) qui déclenche l’action appropriée (affectation à un service, création d’un ticket, archivage).
1. La réalité des pertes quotidiennes
Dans de nombreuses PME, la boîte partagée regroupe les demandes clients, les sollicitations fournisseurs et les notifications internes. Un relevé effectué sur deux semaines dans une entreprise de 120 salariés a montré que 28 % des e‑mails restaient sans réponse au bout de 24 heures, principalement parce qu’ils étaient mal orientés ou laissés en attente d’ en attente de lecture. Ce délai se traduit par des opportunités manquées, des relances répétées et une perte de confiance des interlocuteurs externes.
2. Pourquoi le tri par mot‑clé atteint ses limites
Le filtrage basé sur des mots‑clés (ex. « facture », « urgent », « support ») suppose que l’expéditeur utilise exactement le terme attendu. Dans la pratique, les formulations varient : « pourriez‑vous envoyer la facture ? », « je besoin du bon de commande ASAP », « problème avec la livraison ». Un même intention peut être exprimée avec une dizaine de variantes différentes, tandis qu’un mot‑clé présent dans le corps du message peut être totalement hors contexte (ex. « urgent » dans une signature automatique). Le taux de faux positifs observé lors d’un test avec une règle simple de mots‑clé dépassait 40 %, ce qui obligeait les équipes à vérifier manuellement chaque tri.
3. Le principe du routage par intention
Plutôt que de chercher un terme spécifique, on analyse la phrase complète pour en dégager l’intention sous‑jacente : demande d’information, demande d’action, réclamation, prise de rendez‑vous, etc. Cette étape peut être réalisée par un petit modèle de langage entraîné à classifier les intentions dans un domaine restreint (ex. service client, comptabilité, ressources humaines). Le modèle retourne une étiquette d’intention qui sert ensuite à déclencher le workflow approprié. L’avantage principal est la robustesse face aux variations de formulation : le même modèle reconnaîtra « pourriez‑vous m’envoyer le contrat » et « envoyer le contrat dès que possible » comme une demande de document.
4. Mise en œuvre pratique avec des outils accessibles
Un pipeline réalisable se compose de trois briques :
- Un connecteur qui récupère les nouveaux e‑mails de la boîte partagée (IMAP ou via un plugin n8n/Make).
- Un appel à un API de langage (Mistral 7B en version hébergée, ou GPT‑4o via Azure) avec un prompt du type : « Détermine l’intention de ce message parmi : information, action, réclamation, prise de rendez‑vous, autre ».
- Un switch qui, selon l’intention renvoyée, lance l’action correspondante : création d’un ticket dans le CRM (HubSpot, Salesforce), attribution à une boîte de service spécifique, archivage automatique ou notification Slack.
Le tableau suivant présente un ordre de grandeur des efforts nécessaires pour chaque brique, basé sur un projet pilote de trois semaines dans une ETI de 80 personnes :
| Brique | Temps de mise en place | Compétences requises | Coût approximatif (licences + usage) |
|---|---|---|---|
| Connexion IMAP | 0,5 jour | Administrateur système | gratuit (n8n/Make) |
| Appel API langage | 1 jour | Développeur (script Python ou nœud Make) | 0,001 €/requête (Mistral) – 0,03 €/requête (GPT‑4o) |
| Routing vers actions | 1 jour | Consultant fonctionnel | déjà inclus dans les licences CRM |
Ces chiffres restent des ordres de grandeur ; ils varient selon le volume quotidien de messages (entre 50 et 500 e‑mails pour les structures étudiées).
5. Quand il vaut mieux ne pas automatiser
Si la boîte partagée reçoit moins de quinze messages par jour et que la variété d’intentions est très faible (par exemple uniquement des factures fournisseurs), le coût d’installation et de maintenance d’un pipeline d’IA peut dépasser le bénéfice attendu. Dans ce cas, une règle de tri simple basée sur l’expéditeur ou le sujet suffit, voire un traitement manuel reste plus rapide. L’expérience montre que, pour un flux inférieur à vingt e‑mails/jour, le temps gagné par l’automatisation est négligeable face à la heure nécessaire pour configurer et surveiller le modèle.
6. Points de vigilance et premiers pas
Avant de déployer, il convient de :
- Échantillonner cinquante e‑mails récents et les étiqueter manuellement selon les intentions que vous souhaitez distinguer.
- Tester le modèle de langage sur cet échantillon afin de mesurer le taux de bonnes classifications (viser au‑delà de 80 % de précision).
- Définir clairement les actions associées à chaque intention et vérifier qu’elles sont déjà supportées par vos outils (CRM, système de ticketing, boîte de partage).
- Prévoir une phase de supervision de deux semaines où un opérateur valide les propositions d’automatisation avant qu’elles ne soient exécutées réellement.
Une fois ces étapes validées, le passage en production peut se faire progressivement, en commençant par une seule intention (par exemple les demandes d’information) puis en élargissant le périmètre.
Questions fréquentes
Quel volume d’e‑mails justifie réellement l’usage d’un modèle d’IA ?
À partir d’une cinquantaine de messages par jour, le gain de temps lié à la réduction des erreurs de routage commence à compenser le temps de configuration et le coût d’usage de l’API. En dessous, une règle statique suffit généralement.
Faut‑il former un modèle spécifique ou un modèle pré‑entraîné suffit‑il ?
Pour des intentions clairement délimitées (information, action, réclamation, prise de rendez‑vous), un modèle pré‑entraîné comme Mistral 7B ou GPT‑4o, accompagné d’un prompt court, atteint généralement une précision suffisante sans besoin de ré‑entraînement coûteux.
Et si les e‑mails contiennent des pièces jointes sensibles ?
Le workflow ne doit jamais transmettre le contenu des pièces jointes à un service extérieur. On se limite à analyser le texte du corps du message ; les pièces jointes restent dans la boîte de réception ou sont dirigées vers un stockage sécurisé selon l’intention déterminée.
Quel est le risque de faux négatifs (un e‑mail mal classé) ?
Un faux négatif entraîne simplement que le message suit le traitement par défaut (ex. mise en attente ou notification à un responsable). En définissant une action de secours (re‑vérification manuelle après un délai), on limite l’impact sans bloquer le flux global.
Peut‑on utiliser Excel comme intermédiaire pour tester le routage ?
Oui, exporter les cinquante e‑mails d’essai vers une feuille Excel, ajouter une colonne contenant la réponse de l’API et comparer avec l’étiquette manuelle permet de valider le modèle avant de l’intégrer dans n8n ou Make. Cette étape reste toutefois réservée à la phase de test.