Deux agences d'intérim d'un même groupe, sur deux territoires. Deux boîtes mail partagées qui reçoivent chaque jour le même mélange : candidatures spontanées, réponses à annonces, commandes de personnel, relevés d'heures, justificatifs, relances. Et une particularité qui change tout : les mêmes candidats et les mêmes clients écrivent parfois aux deux adresses. Trier tout cela à la main mobilise des permanents plusieurs heures par jour ; le trier automatiquement, sans méthode, produit des doublons, des réponses absurdes et des mails perdus.
Trier des emails automatiquement est un enfer — en programmatique pure comme en IA naïve. Cette étude de cas décrit l'architecture que nous mettons en place pour ce groupe : un pipeline déterministe d'abord, l'IA seulement pour ce qui reste ambigu, et surtout une déduplication à trois niveaux, qui est le vrai nerf de la guerre. Comme toujours, nous ne communiquons aucun chiffre de résultat client : nous décrivons des choix d'architecture et des principes généralisables.
À retenir
- ▸L'erreur classique est d'envoyer chaque mail directement dans un LLM. Le bon ordre : ingestion → normalisation → déduplication → règles déterministes → IA pour l'ambigu seulement.
- ▸La fondation absolue est l'idempotence par Message-ID (RFC 5322) : sans elle, chaque retry et chaque redémarrage crée des doublons de traitement.
- ▸Il existe trois niveaux de duplication distincts — technique, inter-boîtes, sémantique — et chacun se traite différemment.
- ▸La classification IA n'est fiable qu'avec des catégories métier fermées, des sorties structurées et un seuil de confiance en dessous duquel un humain reprend la main.
- ▸Avant toute action automatique : mode dry-run mesuré, et filtrage RGPD en amont — un mail d'arrêt maladie ne doit pas partir tel quel vers un LLM tiers.
Dans cet article
- 1. Contexte : deux agences, deux boîtes mail, les mêmes expéditeurs
- 2. Pourquoi le tri d'emails est un enfer — règles pures comme IA naïve
- 3. L'architecture : un pipeline déterministe d'abord, l'IA ensuite
- 4. La déduplication, le nerf de la guerre : trois niveaux distincts
- 5. Le threading : rattacher chaque mail à sa conversation
- 6. La classification IA : catégories fermées, sorties structurées, seuil de confiance
- 7. Le multi-boîtes en pratique
- 8. Les garde-fous : dry-run et RGPD
- 9. Enseignements généralisables
- 10. FAQ
1. Contexte : deux agences, deux boîtes mail, les mêmes expéditeurs
Le client est un groupe d'agences d'intérim que nos lecteurs connaissent déjà : c'est pour lui que nous construisons la plateforme métier sur mesure décrite dans notre précédente étude de cas. Le chantier suivant porte sur un point d'entrée que toutes les agences partagent : la boîte mail. Deux agences, deux adresses génériques, et un flux quotidien hétérogène où l'urgent (une commande de personnel pour le lendemain) côtoie l'administratif (un relevé d'heures) et le volumineux (les candidatures).
Dans l'intérim, la boîte mail n'est pas un canal parmi d'autres : c'est le déversoir de tous les processus. Une candidature y arrive en pièce jointe, une commande client y arrive en trois lignes tapées depuis un chantier, un justificatif d'absence y arrive en photo. Tant que des permanents trient à la main, chaque mail est lu deux fois : une fois pour le router, une fois pour le traiter. Et la première agence qui propose un profil qualifié remportant souvent la mission, chaque heure passée entre la réception d'une commande et sa prise en charge est une heure de réactivité commerciale perdue.
La particularité du groupe — deux agences sur deux territoires voisins — ajoute la difficulté qui structure toute l'architecture : les mêmes expéditeurs écrivent aux deux boîtes. Un candidat motivé envoie son CV aux deux adresses. Un client régional met les deux agences en copie. Une automatisation conçue boîte par boîte créerait deux fois le même candidat, déclencherait deux réponses différentes au même client, et générerait précisément le chaos qu'elle prétend résoudre.
Le point de départ : automatiser le tri de deux boîtes mail qui se recouvrent partiellement, sans jamais traiter deux fois le même mail, ni perdre un mail urgent, ni répondre de travers à un client. La difficulté n'est pas la classification : c'est tout ce qui doit se passer avant elle.
2. Pourquoi le tri d'emails est un enfer — règles pures comme IA naïve
Le tri d'emails a la réputation d'un problème simple. Il ne l'est pas, et les deux approches « évidentes » échouent chacune à leur manière.
L'approche programmatique pure : des règles qui s'effritent
Filtres sur l'objet, sur l'expéditeur, sur des mots-clés : tout le monde a commencé par là, et tout le monde a vu le résultat. Les règles se multiplient, se contredisent, et capturent mal la réalité d'un mail écrit par un humain pressé. Une commande de personnel peut arriver avec pour seul objet « urgent », un CV avec « bonjour ». Chaque cas raté devient une règle de plus, jusqu'à ce que plus personne n'ose toucher au système. Les règles déterministes sont excellentes pour ce qui est structurellement identifiable — un accusé de réception, une notification automatique, une désinscription — et mauvaises pour tout le reste.
L'IA naïve : tout envoyer au LLM
L'approche inverse — brancher la boîte mail sur un modèle de langage et lui demander de tout classer — séduit par sa simplicité, et échoue pour trois raisons. Le coût et la latence : chaque notification automatique, chaque spam, chaque accusé DocuSign consomme un appel d'API qui n'apprend rien. L'imprévisibilité : sans contrainte forte, le modèle invente des catégories, change d'avis entre deux mails identiques, et son comportement dérive au fil des versions. Et surtout, l'absence de mémoire : un LLM appelé mail par mail ne sait pas qu'il a déjà vu ce CV hier, ni que ce message est le quatrième échange d'une conversation en cours. Or c'est exactement là que se jouent les vrais incidents.
| Approche | Forces | Où elle casse |
|---|---|---|
| Règles déterministes seules | Prévisibles, gratuites, instantanées | Le langage naturel : un humain n'écrit jamais deux fois pareil |
| LLM sur chaque mail | Comprend le langage, démarre vite | Coût, latence, dérive, aucune notion de doublon ni de conversation |
| Pipeline hybride | Le déterministe absorbe le volume, l'IA absorbe l'ambiguïté | Demande une vraie conception en amont — l'objet de cet article |
3. L'architecture : un pipeline déterministe d'abord, l'IA ensuite
Le pattern que nous appliquons tient en une phrase : tout ce qui peut être décidé sans IA doit l'être avant l'IA. Concrètement, chaque mail traverse cinq étapes, dans cet ordre, et peut sortir du pipeline à chacune d'elles :
Ingestion
Réception par webhook push depuis la messagerie (Microsoft Graph ou Gmail API), plutôt que par interrogation périodique. Chaque mail entre avec ses en-têtes complets.
Normalisation
Extraction du texte utile (sans signatures ni historiques cités), des pièces jointes et des métadonnées : expéditeur, destinataires, boîte de réception concernée, horodatage.
Déduplication
Le cœur du système, détaillé à la section suivante : un mail déjà vu — par n'importe quel chemin — ne redéclenche jamais un traitement.
Règles déterministes
Notifications automatiques, accusés de réception, désinscriptions, expéditeurs connus à routage fixe : classés sans appel d'IA, en quelques millisecondes.
Classification IA
Seuls les mails restants — ceux qui demandent une vraie compréhension du langage — sont soumis au modèle, avec le contexte de leur conversation et un schéma de sortie fermé.
Cet ordre n'est pas une optimisation de confort : il rend le système prévisible. Les étapes 1 à 4 produisent toujours le même résultat pour la même entrée ; seule l'étape 5 comporte une part de jugement, et c'est précisément celle qu'on encadre par un seuil de confiance et une revue humaine. C'est la même philosophie que pour notre agent IA WhatsApp : l'IA n'est pas le système, elle est un composant du système.
4. La déduplication, le nerf de la guerre : trois niveaux distincts
Quand on parle de « doublons » dans une boîte mail, on parle en réalité de trois phénomènes différents, qui n'ont ni la même cause ni le même traitement. Les confondre est l'erreur la plus coûteuse de ce type de projet.
Niveau 1 — La duplication technique : le même mail ingéré deux fois
Un webhook qui rejoue après un timeout, deux mécanismes de réception qui se chevauchent, un worker qui redémarre en plein traitement : par conception, un système distribué livre parfois deux fois le même événement. La parade est l'idempotence. Chaque mail porte dans ses en-têtes un Message-ID, identifiant unique au niveau mondial défini par la RFC 5322. Ce Message-ID est stocké en base avec une contrainte d'unicité, et tout traitement commence par une insertion conditionnelle : si elle échoue, le mail a déjà été vu, on s'arrête là. C'est la fondation absolue du système — sans elle, tout le reste s'écroule, car les mécanismes de retry (indispensables par ailleurs) fabriquent des doublons par design.
Niveau 2 — La duplication inter-boîtes : un envoi, deux agences
Le candidat qui écrit aux deux adresses dans le même envoi, le client qui met les deux agences en copie : le Message-ID est alors identique dans les deux boîtes, puisque c'est le même message. La clé d'idempotence doit donc être globale au système, et non par boîte — sinon chaque agence « découvre » le mail de son côté. Mais attention à la subtilité métier : dédupliquer l'ingestion ne signifie pas écraser l'information de routage. Un CV envoyé aux deux agences doit créer un seul candidat dans le vivier, mais conserver la trace que les deux agences sont destinataires — car la décision (quelle agence le rappelle ?) appartient aux permanents, pas au pipeline.
Niveau 3 — La duplication sémantique : le même contenu, des envois différents
Le candidat qui renvoie le même CV trois jours plus tard avec un objet différent, la relance polie, le transfert interne : cette fois les Message-ID diffèrent, et seul le contenu se ressemble. Deux outils se combinent : un hash de contenu (corps normalisé et pièces jointes condensés en empreinte SHA-256 — deux PDF identiques produisent la même empreinte) pour les vrais doublons, et le threading (section suivante) pour rattacher les relances à leur conversation d'origine. Pour les CV spécifiquement, on y ajoute un rapprochement sur l'adresse de l'expéditeur et le téléphone extrait du document.
| Niveau | Cause | Signature | Traitement |
|---|---|---|---|
| Technique | Retries, webhooks rejoués, redémarrages | Même Message-ID, même boîte | Idempotence : contrainte d'unicité en base, insertion conditionnelle |
| Inter-boîtes | Envoi aux deux agences, mise en copie | Même Message-ID, boîtes différentes | Clé d'idempotence globale + trace de toutes les boîtes destinataires |
| Sémantique | Renvois, relances, transferts | Message-ID différents, contenu proche | Hash de contenu (SHA-256) + threading + rapprochement candidat |
La règle d'or : chaque niveau se traite à un étage différent du pipeline. L'idempotence à l'ingestion, l'inter-boîtes à la consolidation, le sémantique à l'enrichissement. Un système qui essaie de tout dédupliquer au même endroit finit par confondre « déjà traité » et « déjà vu quelque part », et perd des mails légitimes.
5. Le threading : rattacher chaque mail à sa conversation
Les en-têtes In-Reply-To et References, définis eux aussi par la RFC 5322, permettent de reconstruire les fils de discussion : chaque réponse référence le Message-ID du mail auquel elle répond. Cette reconstruction n'est pas un raffinement, c'est une condition de bon sens pour tout traitement automatique : sans elle, le système répond « merci pour votre candidature » à un intérimaire qui en est au quatrième échange sur une mission en cours.
Concrètement, nous maintenons un état par conversation : à chaque fil sont associés un statut (nouveau contact, candidature en cours d'examen, mission active, litige…), le dernier traitement effectué et un résumé du contexte. Quand un mail atteint l'étape de classification IA, c'est ce contexte qui accompagne le texte du message — le modèle ne juge jamais un mail isolément, il juge un mail dans une conversation. La différence de qualité est immédiate : la même phrase (« pouvez-vous me rappeler ? ») ne signifie pas la même chose venant d'un candidat inconnu ou d'un client dont la commande est en souffrance.
6. La classification IA : catégories fermées, sorties structurées, seuil de confiance
Arrivé à ce stade, le mail qui reste à classer est exactement celui pour lequel l'IA est faite : un texte libre, écrit par un humain, dont le sens ne se déduit pas de sa structure. Trois pratiques rendent cette classification exploitable en production.
Des catégories métier fermées, pas des étiquettes génériques
« Important / pas important » ne sert à rien en agence. Les catégories doivent décalquer les processus réels — pour l'intérim : candidature spontanée, réponse à annonce, disponibilité d'un intérimaire, commande de personnel, relevé d'heures, administratif et paie, urgence du jour (absence, remplacement immédiat). La liste est fermée : le modèle choisit dans cette liste, ou déclare ne pas savoir. Chaque catégorie correspond à une action concrète dans la plateforme métier : créer un candidat, ouvrir une commande, alimenter la paie.
Des sorties structurées et validées
Le modèle ne répond pas en prose : il répond dans un format structuré à schéma fermé — catégorie parmi la liste, score de confiance, entités extraites (poste, qualification, date, lieu pour une commande ; nom, téléphone, métier pour une candidature). Toute réponse qui ne respecte pas le schéma est rejetée et rejouée. Ce contrat de sortie est ce qui transforme un modèle de langage en composant logiciel fiable.
Un seuil de confiance, et une file de revue humaine
En dessous d'un seuil de confiance, le mail ne déclenche aucune action automatique : il part dans une file de revue humaine, avec la proposition du modèle pré-remplie. Ce mécanisme change la nature du risque : le système n'est plus jamais « faux en silence », il est soit sûr, soit explicitement incertain. Et chaque arbitrage humain sur un cas incertain devient un exemple qui affine les règles ou les instructions du modèle — le système s'améliore là où il s'est trompé, comme nous le pratiquons sur l'automatisation du support client.
7. Le multi-boîtes en pratique
La tentation, avec deux agences, est de déployer deux systèmes jumeaux. C'est la mauvaise réponse : on hérite de deux configurations qui divergent, de deux historiques disjoints, et la déduplication inter-boîtes devient impossible. Le bon modèle est un seul pipeline, plusieurs boîtes :
- Un identifiant de boîte accompagne chaque mail de bout en bout : le traitement est commun, la traçabilité reste par agence.
- Le routage par agence vit en configuration, pas dans le code : quelle catégorie alerte qui, dans quelle agence, sur quel canal. Ajouter une troisième boîte demain est une ligne de configuration, pas un chantier.
- La réception se fait en push (webhooks des API de messagerie), avec un mécanisme de reprise à backoff progressif en cas d'incident — c'est exactement là que l'idempotence du niveau 1 paie : les rejeux ne créent jamais de double traitement.
- Un tableau de bord unifié donne aux permanents la vue d'ensemble : volumes par catégorie, mails en file de revue, urgences du jour des deux agences.
Ce choix d'architecture rejoint un principe que nous défendons pour l'ensemble de l'automatisation d'une agence d'intérim : la donnée consolidée au niveau du groupe, la décision au niveau de l'agence.
8. Les garde-fous : dry-run et RGPD
Le mode dry-run : classer sans agir, mesurer avant d'activer
Les premières semaines, le système fonctionne en mode observation : il classe, propose, et n'agit pas. Les permanents valident ou corrigent, et l'on mesure la précision réelle, catégorie par catégorie, sur le vrai flux — pas sur un jeu de test. Les actions automatiques ne s'activent que catégorie par catégorie, quand la précision mesurée le justifie. Une commande de personnel mal routée coûte plus cher qu'une semaine de validation manuelle supplémentaire.
Le RGPD en amont, pas en aval
Une boîte mail d'agence d'intérim est saturée de données personnelles : les CV en regorgent, et certains mails contiennent des données sensibles au sens de l'article 9 du RGPD — un intérimaire qui justifie une absence par un arrêt maladie transmet une donnée de santé. La CNIL encadre précisément le traitement des données de candidats : finalité, minimisation, durée de conservation. Concrètement, dans notre pipeline : les durées de rétention sont définies par catégorie dès la conception, et les mails susceptibles de contenir des données sensibles sont filtrés en amont de l'appel au modèle — ils sont routés vers un humain sans que leur contenu transite par un LLM tiers, sauf garanties contractuelles adaptées (hébergement européen, absence de conservation des données par le fournisseur).
Un mot enfin sur l'AI Act : le tri de flux entrant n'est pas, en soi, un système à haut risque — mais la frontière est vite franchie. Dès que le système ne se contente plus de router une candidature et commence à l'évaluer, on entre dans le périmètre haut risque de l'Annexe III (recrutement). Notre règle de conception : le pipeline de tri classe et route, il ne note jamais un candidat. L'évaluation reste un acte humain, comme nous l'expliquons dans notre analyse de l'AI Act appliqué aux agences d'intérim.
9. Enseignements généralisables
1. L'IA est la dernière étape du pipeline, pas la première
Tout ce qu'une règle peut décider doit être décidé par une règle. Le modèle de langage ne reçoit que les cas qui justifient son coût et son intelligence — et il les reçoit avec leur contexte conversationnel.
2. L'idempotence n'est pas une option
Webhooks, retries et redémarrages produisent des doublons par conception. Le Message-ID en clé d'unicité globale est la première ligne de code utile du projet — avant toute IA.
3. « Doublon » recouvre trois problèmes différents
Technique, inter-boîtes, sémantique : trois causes, trois signatures, trois traitements, à trois étages du pipeline. Les confondre fait perdre des mails légitimes ou traiter deux fois les autres.
4. Un système incertain vaut mieux qu'un système faux en silence
Seuil de confiance, file de revue humaine, dry-run mesuré : le but n'est pas d'éliminer l'humain, mais de concentrer son jugement sur les cas qui le méritent.
Ces principes dépassent largement l'intérim : toute organisation dont une boîte générique concentre des flux hétérogènes — service client, comptabilité fournisseurs, secrétariat médical, gestion locative — rencontre les mêmes trois niveaux de duplication et le même besoin d'un pipeline où l'IA arrive en dernier. Le fil conducteur reste celui de notre étude de cas sur la plateforme intérim : retirer la friction administrative, garder le jugement humain.
10. FAQ
Parce que la majorité du flux n'en a pas besoin : notifications automatiques, accusés de réception, expéditeurs connus à routage fixe se classent par des règles déterministes, gratuites et instantanées. Envoyer tout le flux au modèle multiplie les coûts et la latence, et surtout produit un système imprévisible : sans déduplication ni contexte conversationnel en amont, le modèle juge chaque mail isolément — y compris les doublons et les relances. L'IA n'intervient efficacement qu'en dernière étape, sur les mails réellement ambigus, avec le contexte de leur conversation.
Par l'idempotence : chaque email porte un Message-ID unique au niveau mondial (en-tête défini par la RFC 5322). Ce Message-ID est stocké en base avec une contrainte d'unicité, et tout traitement commence par une insertion conditionnelle — si le Message-ID existe déjà, le traitement s'arrête immédiatement. Ce mécanisme rend inoffensifs les webhooks rejoués, les chevauchements de réception et les redémarrages de workers, qui produisent tous des doublons par conception. C'est la fondation du système, à poser avant toute logique de classification.
S'il s'agit du même envoi (les deux adresses en destinataires), le Message-ID est identique dans les deux boîtes : une clé d'idempotence globale au système — et non par boîte — garantit une seule ingestion. Le pipeline crée alors un seul candidat dans le vivier, mais conserve la trace des deux boîtes destinataires : la décision de routage (quelle agence rappelle) reste un choix métier visible des permanents. S'il s'agit de deux envois séparés, c'est la déduplication sémantique qui prend le relais : hash des pièces jointes et rapprochement sur l'email et le téléphone du candidat.
La bonne question n'est pas « quel taux d'erreur ? » mais « que fait le système quand il doute ? ». Avec des catégories métier fermées, des sorties structurées validées par schéma et un seuil de confiance, le système est soit sûr, soit explicitement incertain — et dans ce cas le mail part en file de revue humaine avec la proposition pré-remplie, au lieu de déclencher une action erronée. La précision réelle se mesure en mode dry-run sur le vrai flux, catégorie par catégorie, avant d'activer la moindre action automatique.
Le routage pur — reconnaître qu'un mail est une candidature et le diriger vers le bon processus — n'évalue pas la personne. Mais l'Annexe III de l'AI Act classe à haut risque les systèmes utilisés pour le recrutement et la sélection, notamment le tri et l'évaluation de candidatures : dès que le système note, filtre ou priorise des candidats, les obligations du haut risque s'appliquent (documentation, transparence, supervision humaine). Notre règle de conception est nette : le pipeline classe et route, l'évaluation reste humaine. Notre analyse complète : l'AI Act pour les agences d'intérim.
Les données sensibles de l'article 9 du RGPD en premier lieu — dans une agence d'intérim, le cas typique est la donnée de santé : un arrêt maladie, un justificatif médical, une mention de restriction d'aptitude. Ces mails sont détectés en amont par des règles (expéditeur, type de pièce jointe, vocabulaire) et routés directement vers un humain, sans appel au modèle, sauf si le fournisseur d'IA offre des garanties contractuelles adaptées : hébergement européen, absence de conservation et de réutilisation des données. Le reste du flux suit les principes CNIL classiques : minimisation, finalité, durées de rétention définies par catégorie.
Pour aller plus loin
Trier des emails automatiquement n'est ni un problème de filtre, ni un problème d'IA : c'est un problème d'architecture. Le pipeline déterministe absorbe le volume, la déduplication à trois niveaux garantit qu'un mail — quel que soit le chemin par lequel il arrive — n'est traité qu'une fois, le threading donne au modèle le contexte sans lequel il répond à côté, et les garde-fous (seuil de confiance, dry-run, filtrage RGPD) font le reste. Pour deux boîtes comme pour dix.
Si vos boîtes génériques débordent — en agence d'intérim ou ailleurs — un échange de cadrage permet d'identifier votre flux réel, ses doublons et la première brique à automatiser.
Vos boîtes mail débordent ?
30 minutes pour cartographier votre flux entrant, repérer les doublons qui vous coûtent du temps et chiffrer un pipeline de tri adapté à votre organisation.
Victor Glesskrumhorn
Fondateur & Consultant IA — JAIKIN
Expert en implémentation IA et automatisation pour PME et ETI. Accompagne des entreprises en France, en Allemagne et en Suisse, de la cartographie des processus à la mise en production.
À lire aussi
Étude de cas : plateforme intérim IA sur mesure
Étude de cas : une plateforme intérim IA sur mesure pour un groupe d'agences — agent WhatsApp, reprise des offres, plateforme métier conforme AI Act.
LireAgences d'intérim et AI Act : votre logiciel de matching est-il conforme ?
AI Act et intérim : matching et scoring de fiabilité sont « haut risque » (échéance reportée au 2 décembre 2027), et la check-list pour vérifier votre logiciel.
Lire