Un agent IA pour les e-mails peut rendre une demande plus lisible, la classer et préparer une proposition de réponse. La frontière importante est ailleurs : l’agent doit-il seulement suggérer, ou peut-il envoyer et modifier des données ? Pour une PME, le premier flux utile est souvent un flux de tri et de proposition, avec escalade explicite dès qu’une règle, une personne ou une donnée manque.
La page CNIL consacrée à l’intelligence artificielle rappelle que les usages agentiques posent des questions de données personnelles et de responsabilités. Un e-mail n’est pas une simple phrase : il peut contenir une identité, une pièce jointe, une information confidentielle et une demande d’action. Le système doit donc traiter le message comme un dossier à qualifier, pas comme un texte à réécrire sans contexte.
Décrire le flux avant de choisir l’outil
Écrivez ce qui se passe aujourd’hui. Qui ouvre la boîte ? Quelles demandes sont répétitives ? Quels messages sont transférés ? Quels cas doivent être lus par une personne habilitée ? Cette observation produit une liste d’états, plus utile qu’une liste de fonctions.
Un flux simple peut contenir : reçu, identifié, classé, source recherchée, proposition rédigée, validation demandée, envoyé, escaladé ou archivé. Chaque état doit avoir une condition d’entrée et une condition de sortie. Si l’agent ne sait pas dans quel état se trouve un message, il peut répéter une action ou laisser croire qu’elle a été faite.
Séparez la lecture de l’écriture. Lire et classer peut être un premier périmètre. Préparer une réponse est un second périmètre. Envoyer, supprimer, transférer à l’extérieur ou modifier un dossier sont des actions qui exigent des contrôles spécifiques.
Définir des catégories qui servent une décision
Une catégorie n’est utile que si elle entraîne une suite. « Client » ou « important » sont trop vagues. Préférez « demande de documentation », « incident à vérifier », « contrat à relire », « demande incomplète » ou « cas hors périmètre », si l’équipe sait ce qu’elle fera ensuite.
Pour chaque catégorie, fournissez des exemples positifs, des contre-exemples et la règle d’escalade. Ajoutez une catégorie « inconnu ». Forcer chaque message dans une case crée une fausse précision et rend les erreurs moins visibles.
Les règles doivent survivre aux variations de vocabulaire. Testez une formulation courte, une formulation longue, une faute de frappe et une demande mélangée. L’agent doit reconnaître l’incertitude lorsqu’un message couvre plusieurs catégories.
Limiter les données accessibles
Un agent de tri n’a pas besoin de toute la boîte historique ni de tous les contacts du CRM. Commencez avec le message, ses pièces jointes nécessaires et une source documentaire ciblée. N’ajoutez un historique que si vous pouvez expliquer la finalité.
La CNIL recommande de définir la finalité, la base légale, les responsabilités et la minimisation des données. Traduisez ces principes en contrôles : masquer une signature inutile, exclure une pièce jointe non pertinente, limiter la recherche à un espace documentaire et empêcher la conservation indéfinie du texte original.
Demandez où sont conservés le message, le résumé, la proposition et les journaux. Une réponse correcte dans l’interface ne dit pas combien de copies ont été créées par les outils secondaires.
Préparer une réponse sans autoriser l’envoi
Un brouillon utile contient la demande comprise, la source consultée, la réponse proposée et le point qui doit être vérifié. Il ne doit pas inventer une disponibilité, une décision, un engagement ou une référence absente.
Utilisez un format de sortie stable :
- intention détectée ;
- informations certaines ;
- informations manquantes ;
- réponse proposée ;
- niveau de confiance expliqué en langage simple ;
- action attendue de la personne qui valide.
La personne qui relit doit pouvoir modifier le brouillon sans devoir recommencer l’analyse. Conservez la demande d’origine et marquez les passages issus d’une source. Si l’agent reformule une règle, renvoyez vers le document de référence plutôt que de présenter la paraphrase comme une décision officielle.
Construire une escalade réellement utilisable
Une escalade ne doit pas être un message générique « contactez un humain ». Elle doit indiquer pourquoi le transfert est nécessaire, quelle équipe est compétente et quelle information manque. Les motifs peuvent être : données contradictoires, demande hors périmètre, enjeu sensible, absence de source, conflit de priorité ou échec d’un outil.
Ajoutez un délai de reprise et un propriétaire. Si un message sensible est transféré à une file que personne ne surveille, l’automatisation ne résout rien. Testez un cas où la première personne est indisponible et documentez la route de secours.
Encadrer les pièces jointes
Une pièce jointe peut contenir des instructions qui ne doivent pas être suivies par l’agent. Traitez-la comme une donnée à analyser, pas comme une autorité de configuration. L’agent doit distinguer la demande de l’expéditeur, le contenu du document et les règles internes.
Testez un document qui demande de divulguer un secret, de contourner une validation ou de modifier un dossier. La grille OWASP Top 10 pour les applications utilisant des modèles de langage aide à formuler des tests d’injection, de divulgation et d’action excessive. Elle ne dispense pas de décider quelles pièces sont admissibles.
Journaliser les transitions utiles
Le journal doit répondre à des questions d’exploitation : quand le message a été reçu, quelle catégorie a été proposée, quelle source a été consultée, quelle action a été tentée, qui a validé, et pourquoi le système s’est abstenu. N’enregistrez pas davantage de contenu sensible que nécessaire pour répondre à ces questions.
Un journal lisible permet de rejouer un incident. Un identifiant de message et une référence de document peuvent suffire si les droits d’accès sont maîtrisés. Évitez de recopier la totalité de la conversation dans chaque service.
Tester avec une matrice d’e-mails
La matrice doit contenir des messages simples, des messages ambigus, des demandes d’action, des pièces jointes, des contradictions et des demandes qui doivent être refusées ou transmises. Pour chaque cas, vérifiez le classement, la source, la proposition, la permission, la trace et la reprise.
Ne mesurez pas seulement le nombre de messages traités. Mesurez aussi les corrections, les transferts inutiles, les erreurs silencieuses et les recherches refaites par l’équipe. Un agent qui produit beaucoup de propositions mais exige une vérification complète peut déplacer la charge au lieu de l’alléger.
Séparer le tri de la décision
Le tri répond à une question de rangement : à quelle file le message appartient-il ? La décision répond à une question de traitement : quelle action l’entreprise doit-elle envisager ? Un agent peut être fiable pour la première et trop incertain pour la seconde. Conservez donc des champs séparés et évitez de transformer une catégorie en autorisation.
Pour chaque catégorie, écrivez un exemple inclus, un exemple proche mais exclu et un cas qui doit être transmis. Cette frontière permet aux utilisateurs de comprendre la proposition et donne au test un résultat attendu. Si une catégorie ne change aucune étape du travail, elle ne mérite peut-être pas d’être automatisée.
Gérer les fils et les messages cités
Un fil peut contenir plusieurs intentions. Le dernier message ne suffit pas toujours : une demande initiale, une pièce jointe et une réponse interne peuvent avoir des statuts différents. Vérifiez quelles parties sont visibles par l’agent et lesquelles restent internes. Un résumé doit distinguer le fait demandé, la réponse déjà donnée et l’action qui reste à faire.
Testez le transfert d’un fil entre deux équipes. Le destinataire doit recevoir le contexte nécessaire sans obtenir des messages qui ne relèvent pas de sa mission. L’agent doit conserver l’identifiant du fil et ne pas créer une nouvelle demande simplement parce que le canal ou le nom de la file change.
Traiter les réponses proposées
Un brouillon doit indiquer ses sources et les éléments variables. Le relecteur vérifie le destinataire, la langue, le ton, les faits, les pièces jointes et la promesse éventuelle. L’agent ne doit pas ajouter une date, une disponibilité ou une exception qui ne figure pas dans une source autorisée.
Prévoyez des gabarits différents pour une demande d’information, une plainte, une demande de suppression et une demande urgente. Le but n’est pas de rendre tous les messages identiques, mais de rendre visibles les conditions qui appellent une décision humaine.
Organiser l’escalade et son retour
Une escalade indique le motif, le propriétaire, le niveau d’urgence interne, les données déjà vérifiées et la question à résoudre. Elle ne doit pas promettre au demandeur un délai que l’équipe n’a pas validé. Après traitement, la décision humaine doit pouvoir être reliée au message initial et à la proposition de l’agent.
Analysez les escalades qui reviennent souvent. Elles peuvent révéler une connaissance manquante, une catégorie trop large ou une règle métier non écrite. Ajoutez un cas de test avant de modifier le comportement et vérifiez que la correction ne rend pas les messages sensibles plus autonomes qu’avant.
Traiter les demandes multiples
Un même courriel peut demander une information, signaler un incident et solliciter une action. Demandez à l’agent de séparer les intentions au lieu de choisir la plus facile. La fiche de reprise doit lister les sous-demandes, les données utiles à chacune et l’ordre de traitement proposé.
Testez une réponse qui traite une partie seulement. L’agent doit signaler ce qui reste ouvert et ne pas présenter le fil comme résolu. Le conseiller doit pouvoir fermer une sous-demande sans faire disparaître les autres. Cette structure évite qu’un message bien rédigé masque un oubli opérationnel.
Encadrer les informations personnelles
Les boîtes de réception contiennent souvent plus d’informations que nécessaire. Définissez les éléments accessibles pour le tri, les éléments nécessaires pour une réponse et les éléments qui doivent rester hors du contexte. Testez une pièce jointe contenant une donnée sans rapport avec la demande.
Le résumé transmis à une autre équipe doit reprendre le minimum utile. Ne recopiez pas toute la conversation dans une nouvelle tâche par facilité. La trace doit permettre de comprendre le classement et la reprise sans multiplier les copies dans les systèmes.
Prévoir les erreurs de transport
Un message peut être reçu deux fois, arriver dans le mauvais dossier ou contenir une pièce jointe illisible. Écrivez le comportement attendu dans chacun de ces cas. Un doublon doit être reconnu ou marqué pour revue ; il ne doit pas déclencher deux fois la même proposition.
Vérifiez ce que voit le conseiller lorsqu’un outil ne répond pas. Le système doit distinguer « action non tentée », « action tentée sans confirmation » et « action confirmée ». Cette différence protège l’équipe contre une réponse qui annoncerait un traitement simplement parce qu’un appel a été lancé.
Revoir les catégories après les retours
Les catégories doivent évoluer à partir de décisions observées. Regroupez les corrections par cause : vocabulaire absent, règle trop large, source manquante, fil difficile à lire ou permission incorrecte. Ne changez pas toutes les catégories après quelques exemples ; ajoutez des cas voisins et vérifiez la stabilité.
Conservez une définition lisible de chaque catégorie et un exemple limite. Le conseiller doit pouvoir contester la proposition avec un motif. Ce retour est plus utile qu’un simple bouton « mauvais classement », car il indique si la règle, le contenu ou le contexte doit être amélioré.
Construire un tableau de contrôle
Le tableau de recette contient l’identifiant du message, la catégorie attendue, la source, la proposition, l’action autorisée, le résultat, la trace et la reprise. Ajoutez les conditions qui rendent le message sensible ou ambigu. Une ligne doit montrer pourquoi l’agent a poursuivi ou s’est arrêté.
Utilisez des messages fictifs qui reprennent les formats habituels : courriel court, fil long, réponse citée, signature, pièce jointe, transfert et langue différente. Variez l’ordre des informations. Ce dispositif révèle les dépendances à une présentation parfaite.
Vérifier les réponses négatives
Testez une demande que l’entreprise ne peut pas satisfaire, une demande adressée au mauvais service et une demande qui exige une information absente. L’agent doit expliquer la limite, proposer une reprise ou demander la donnée manquante. Il ne doit pas inventer une solution pour éviter une réponse négative.
Vérifiez que le refus n’est pas interprété comme une clôture automatique. Le conseiller doit pouvoir choisir une autre suite et conserver le message ouvert. Le statut doit refléter la décision réelle, pas la fin de la génération.
Contrôler les pièces jointes
Définissez les formats acceptés, les pièces qui nécessitent une lecture humaine et les documents qui ne doivent pas être transmis à l’agent. Une pièce jointe peut contenir une instruction qui tente de modifier le comportement ou une information qui n’a aucun rapport avec la demande.
Testez une pièce vide, illisible, contradictoire et trop volumineuse. L’agent doit conserver le nom, le statut de lecture et la raison de l’arrêt sans prétendre avoir analysé le contenu. Le conseiller doit savoir quelle pièce vérifier.
Maintenir le flux pendant une panne
Préparez une procédure lorsque la boîte de réception, le CRM, la base de connaissances ou le connecteur est indisponible. Les messages restent-ils dans la boîte ? Qui les reprend ? Quel statut évite une relance doublée ? La réponse doit être essayée dans un environnement de test.
Après la panne, vérifiez les doublons et les messages restés sans catégorie. Une reprise réussie inclut les événements reçus pendant l’interruption, pas seulement les nouveaux messages.
La checklist de recette du flux courrier
Vérifiez un message normal, une demande multiple, une pièce jointe, un fil long, une demande hors périmètre, une désinscription, un doublon et une panne d’outil. Pour chacun, notez la catégorie, la source, la proposition, la permission, la trace et la reprise. La règle de sortie doit être compréhensible par un conseiller.
Avant l’ouverture, faites rejouer quelques cas par une personne qui n’a pas écrit les consignes. Elle doit pouvoir corriger une proposition, transmettre un message et retrouver l’action dans le journal. Si elle ne sait pas si une réponse a été envoyée, le flux doit rester en proposition.
Révisez la matrice lorsque les catégories, les sources, les boîtes ou les propriétaires changent. Un changement de canal peut modifier les droits et la conservation. La stabilité du tri doit être vérifiée après chaque évolution importante.
Conservez une version de la matrice et la décision associée. Lorsqu’un message est contesté, l’équipe doit pouvoir retrouver la règle et le contexte qui ont produit la proposition. Cette trace rend la correction plus précise et évite de modifier le flux à l’aveugle.
La recette est complète lorsque le conseiller sait accepter, corriger, refuser et transmettre un message, puis retrouver la trace de la décision. Si l’une de ces actions dépend d’un administrateur, maintenez la proposition en revue et documentez le transfert nécessaire.
Le propriétaire du flux doit aussi savoir retirer une catégorie, une source ou une règle sans perdre les messages en attente. Testez ce changement avec des courriels fictifs et vérifiez que les demandes existantes restent visibles pour l’équipe.
Ajoutez un cas de transfert pendant cette modification : le conseiller doit voir le motif, le contexte et la prochaine action, même si la catégorie d’origine n’est plus disponible.
Ce test doit être conservé dans la matrice afin de vérifier les changements futurs de boîte, de source ou de propriétaire.
Exemple de traitement d’un e-mail ambigu
Un message peut demander la copie d’un document, signaler un problème d’accès et demander un rappel. L’agent sépare les demandes, recherche uniquement la source autorisée et prépare une proposition pour chaque sous-sujet. Il ne déclare pas le dossier résolu parce qu’une seule réponse est prête.
Si une pièce jointe est illisible ou si le document demandé dépend d’une autorisation, l’agent indique le point bloquant dans la reprise. Le conseiller reçoit le fil, les sous-demandes, la source consultée et la question qui reste ouverte. Il peut alors traiter le cas sans recommencer l’analyse.
Le test vérifie également le statut final : une proposition n’est pas un envoi, et un transfert n’est pas une clôture. Cette distinction préserve la traçabilité et réduit les messages oubliés dans une file intermédiaire.
Vérification de continuité du courrier
Après une modification de règle, rejouez un message classé, un message ambigu et un message transféré. Vérifiez le statut, la source consultée, la proposition et le chemin de reprise. Le conseiller doit pouvoir constater qu’un message reste ouvert tant qu’une sous-demande n’est pas traitée.
Préparez aussi le retour au traitement manuel. Si la boîte, le connecteur ou la source est indisponible, l’équipe sait où retrouver les messages, comment éviter les doublons et comment remettre le flux en observation. Cette continuité protège l’utilisateur contre une réponse qui donnerait l’impression qu’un traitement est terminé alors qu’il reste à faire.
Journal de recette à partager
Conservez pour chaque cas la demande d’origine, les sous-demandes détectées, les sources utilisées, le statut, la proposition et la décision humaine. La personne qui reprend peut alors expliquer le parcours au demandeur et signaler une correction sans reproduire toute la conversation dans une nouvelle file.
Ce journal est relu après un incident ou un changement de règle. Il confirme que le flux continue de trier, proposer et escalader selon les mêmes limites, sans faire croire qu’une action est exécutée avant sa confirmation.
Recette d’un fil qui exige une reprise humaine
Choisissez un fil de recette contenant une demande initiale, une relance, une pièce jointe annoncée mais absente et une question qui relève d’un autre interlocuteur. Ce cas force le flux à faire plus qu’étiqueter un message. Il doit séparer les éléments vérifiables de ce qu’il ne peut pas confirmer, préparer une réponse courte et proposer la bonne personne de reprise. Conservez le fil dans sa forme complète : un test réalisé sur un résumé déjà nettoyé ne révèle pas les pertes de contexte que rencontrera l’équipe dans une boîte partagée.
Demandez ensuite à deux personnes de relire le résultat sans leur montrer la règle utilisée. Elles doivent pouvoir répondre à quatre questions simples : quelle est la demande active, quelle information manque, quel élément vient du message d’origine et quelle action reste à la main ? Si leurs réponses divergent, ne cherchez pas à rendre le texte plus persuasif. Revenez à la séparation entre faits, hypothèses et proposition. Un message utile peut être bref ; il ne doit pas masquer une incertitude sous une formulation assurée.
Ajoutez enfin un signal de bascule observable. Par exemple, le flux place le dossier dans une file de reprise quand une pièce annoncée est inaccessible, quand deux demandes incompatibles sont détectées ou quand le destinataire proposé n’est pas certain. Ce signal doit être visible dans la boîte de travail et dans le journal, avec la raison exacte. Lors de la revue, vérifiez qu’aucune réponse n’a été envoyée parce qu’un brouillon avait l’apparence d’un message final. Vous obtenez ainsi une recette qui teste le tri, la proposition et l’escalade sur un même cas plutôt qu’une succession de démonstrations isolées.
FAQ
L’agent peut-il envoyer seul une réponse ?
Ce n’est pas le bon point de départ. Gardez l’envoi derrière une validation explicite et ouvrez-le uniquement pour un périmètre stable, réversible et surveillé. Une réponse engage l’entreprise même si le texte a été produit automatiquement.
Comment traiter les messages sans source fiable ?
L’agent doit reconnaître l’absence, poser une question ou escalader. Il ne doit pas transformer une hypothèse en règle métier.
Peut-on utiliser une boîte réelle dès le début ?
Commencez par des données fictives ou un espace isolé. Lorsque la chaîne est comprise, ouvrez un flux réel limité avec une validation humaine et une procédure d’arrêt.
La règle de sortie
Avant d’élargir, vérifiez que chaque état a un propriétaire, qu’une proposition est distinguée d’un envoi, que les pièces jointes sont traitées comme des données, que les permissions sont minimales et que la reprise fournit le contexte. Pour approfondir les permissions, consultez Agent IA et CRM : permissions, journaux et réversibilité. Pour mesurer la qualité des réponses, lisez Mesurer un agent IA de support. Contactez Agents-IA.pro pour cadrer votre premier flux e-mail sans ouvrir toute la boîte.