Quand les demandes arrivent par courriel et par formulaire, leur tri finit souvent par dépendre de la personne qui ouvre la boîte de réception. Créer un agent IA consiste à lui confier une mission délimitée, des informations utiles et des actions autorisées, tout en gardant une validation humaine aux points sensibles. Le tri des demandes entrantes sert ici de fil conducteur pour choisir la bonne approche, préparer un scénario sans code avec n8n et Claude, puis le tester avant de lui confier davantage d’autonomie.
Pour créer un agent IA de tri, partez d’une décision répétitive et vérifiable, pas du choix d’un modèle. Le scénario doit préciser ce que l’agent lit, ce qu’il propose et ce qu’une personne approuve.
Un agent IA convient lorsque le système doit choisir entre plusieurs actions pour atteindre un objectif précis. Un chatbot répond à une demande formulée par un utilisateur. Une automatisation applique un chemin prévu à l’avance. Un agent peut s’appuyer sur un modèle de langage, ou LLM, pour interpréter un message et décider de la suite dans les limites fixées.
| Situation dans une PME | Option à envisager | Critère décisif |
|---|---|---|
| Répondre à une question sur les horaires ou les modalités de contact | Chatbot | L’utilisateur attend une réponse, sans action dans les outils internes. |
| Envoyer chaque formulaire « devis » vers la même boîte | Automatisation à règles fixes | Le déclencheur et la destination sont connus. |
| Lire une demande ambiguë, proposer une catégorie puis orienter son traitement | Agent IA | La décision dépend du contenu et plusieurs suites sont possibles. |
Un workflow agentique est l’enchaînement des décisions et des actions de l’agent. Son autonomie peut s’arrêter au classement proposé. Si le résultat souhaité se résume à « si le formulaire contient telle réponse, le transmettre à telle équipe », ajouter un LLM complique le scénario sans résoudre un problème supplémentaire.
La mission d’un agent IA doit décrire une tâche répétitive, son déclencheur et son résultat observable. Pour le tri des demandes, le point de départ est concret : une personne ouvre chaque message, cherche son sujet, puis décide à qui le transmettre. Avant de choisir un outil, examinez si les mêmes décisions reviennent régulièrement et si une personne peut juger le classement proposé.
Écrivez le résultat attendu en termes de travail : « À la réception d’une demande, proposer une catégorie et un destinataire, sans envoyer de réponse au demandeur. » Précisez les catégories utiles à votre équipe, comme demande commerciale, assistance ou autre. Si ces catégories changent chaque semaine, stabilisez d’abord votre façon de traiter les messages.
Le périmètre des données doit nommer les informations lues, leur lieu de stockage et leur durée de conservation. Un objet, le corps du message et une adresse de réponse peuvent servir au tri ; une pièce jointe ou l’historique complet d’un contact ne doivent pas être accessibles par défaut. Définissez aussi les cas transmis directement à une personne : demande incompréhensible, sujet sensible ou désaccord entre la catégorie proposée et le contenu.
Si l’agent doit retrouver une information dans des documents internes, la génération augmentée par récupération, ou RAG, permet de lui fournir des extraits pertinents au moment de répondre. Un simple tri de messages n’en a pas nécessairement besoin. Si vous hésitez entre un simple tri et un agent IA qui consulte des documents internes, commencez par clarifier le besoin et le périmètre. Le conseil et le cadrage des agents IA de RIA2D vous aide à choisir la solution et à définir ce périmètre, sans réaliser la construction technique. Pour examiner votre situation et décider de la prochaine étape, prenez rendez-vous pour un diagnostic de 30 minutes. La réalisation technique relève d’Ecluz, Redig ou Onven.
« Je suis Richad Addou, builder IA et fondateur de RIA2D. Dans un diagnostic de 30 minutes, je préfère examiner une demande qui hésite entre deux catégories plutôt qu’une démonstration où tout est évident. L’écueil fréquent est d’ajouter des actions avant d’avoir défini qui tranche ce cas ambigu. »
Richad AddouUn agent de tri reçoit un message, propose son classement et prépare sa suite, sans expédier de réponse sans contrôle. Le parcours commence par un courriel ou un formulaire. Dans n8n, un scénario récupère les informations nécessaires au tri. Un webhook, c’est-à-dire un point de réception déclenché par un autre outil, peut servir d’entrée pour un formulaire si l’outil le permet.
Le scénario transmet ensuite à Claude le sujet, le texte de la demande et les catégories autorisées. Claude est ici le modèle de langage chargé d’interpréter le contenu ; il ne connaît ni vos équipes ni vos règles tant que vous ne les lui avez pas communiquées. Sa réponse attendue indique une catégorie, un destinataire proposé et, si nécessaire, un motif de reprise humaine.
Une demande de devis clairement formulée peut être proposée à l’équipe commerciale. Un message qui mêle réclamation et nouvelle commande reste à examiner. Une pièce jointe inattendue ne doit pas devenir une instruction pour l’agent. Ces exceptions comptent autant que le parcours ordinaire, car une catégorie forcée peut envoyer le message au mauvais endroit.
Le résultat s’affiche dans un espace où une personne peut confirmer ou corriger la proposition. Elle valide avant tout envoi externe ou autre action difficile à annuler. Le scénario garde la trace de la catégorie proposée, de la décision humaine et de l’action finalement effectuée. Cette trace permet de comprendre un mauvais aiguillage et d’ajuster les instructions.
Le no-code convient à un scénario de tri délimité, tandis qu’un développement spécifique se discute lorsque les règles d’accès, les outils ou les actions sortent du cadre proposé par les solutions existantes. « Sans code » ne signifie pas « sans conception » : il faut toujours définir les données, les exceptions, les contrôles et la personne chargée du suivi.
| Approche | Adaptée si… | Point à vérifier avant de choisir |
|---|---|---|
| Plateforme d’agents ou outil no-code | La mission entre dans les possibilités de l’outil et l’équipe peut reprendre le scénario. | Accès aux données, contrôle des actions, export et conditions d’utilisation. |
| Assemblage d’outils, par exemple avec n8n | Le tri doit relier plusieurs outils déjà utilisés dans l’entreprise. | Responsable des connexions, gestion des erreurs et suivi après livraison. |
| Développement spécifique | Les contraintes d’accès ou les actions demandées ne sont pas couvertes de façon satisfaisante. | Maintenance, documentation et possibilité de modifier le système. |
Pour une petite équipe qui veut seulement orienter des formulaires standardisés, une plateforme existante peut suffire. Si les demandes arrivent de plusieurs canaux et doivent rejoindre un outil interne, un assemblage peut être plus approprié. Le développement spécifique ne se justifie pas par principe : il doit répondre à une contrainte identifiée que les autres approches ne traitent pas.
Le choix du prestataire suit la même logique. Un éditeur vend un produit, une agence assemble des solutions et un indépendant peut construire un système puis rester joignable pour l’ajuster. Demandez qui corrige une erreur de tri, qui modifie une connexion et qui reprend le projet si la personne initiale n’est plus disponible. Le suivi couvre les nouveaux cas rencontrés après la mise en service ; ce travail fait partie de la décision, pas d’un détail à régler plus tard.
« Je vois souvent un projet partir d’un choix d’outil alors que personne n’a désigné le responsable des demandes mal classées. Mon réflexe est de faire nommer cette personne avant la construction. Un scénario facile à créer devient difficile à exploiter si personne ne peut le corriger. »
Richad AddouLe premier scénario avec n8n et Claude doit lire une demande, obtenir une proposition de tri et la soumettre à une personne. Commencez par choisir un point d’entrée, courriel ou formulaire, puis faites circuler un message d’essai jusqu’à un espace de vérification. n8n sert à organiser cet enchaînement ; Claude joue le rôle de LLM, un programme qui produit du texte à partir des informations et des instructions reçues.
Rédigez ensuite les instructions de l’agent en langage courant. Indiquez sa mission, les catégories permises et les cas où il doit répondre « à vérifier ». Précisez qu’un message reçu est une donnée à classer, pas une autorité capable de modifier les instructions. Demandez une réponse structurée avec la catégorie proposée et une courte justification, afin qu’une personne puisse la contrôler.
Transmettez au modèle seulement les informations retenues dans le périmètre. Le scénario lit sa proposition et distingue une catégorie autorisée d’une réponse inutilisable. Dans ce dernier cas, il transmet la demande à une personne au lieu de deviner. Pour commencer, l’action contrôlée peut être la préparation d’un classement dans l’outil de suivi, sans message envoyé au demandeur.
Le cadrage du processus précède le choix des connecteurs chez RIA2D : si personne ne sait quoi faire d’une demande mixte, changer de modèle ne résout pas le problème. La configuration précise des connexions relève du studio chargé de construire le système, pas d’une manipulation que le dirigeant doit apprendre pour décider.
Relier un agent à une messagerie, un formulaire ou un outil de suivi exige de limiter les accès à ce que sa mission demande réellement. Pour le tri, la lecture des nouveaux messages peut être nécessaire ; l’accès à toute la boîte, aux anciens échanges ou au carnet d’adresses peut ne pas l’être. Décidez quelles données seront consultées, envoyées au modèle, stockées et conservées.
Le choix des connexions doit tenir compte des droits d’accès. Quand un outil propose oauth 2.0, ce mécanisme permet d’autoriser une connexion sans partager directement le mot de passe. Le contrôle d’accès basé sur les rôles, ou RBAC, aide à distinguer les droits de lecture, de correction et d’envoi. Accordez uniquement les permissions nécessaires : proposer un destinataire ne nécessite pas forcément le droit d’envoyer un courriel.
Les guardrails, ou limites de fonctionnement, précisent les catégories admises et les situations où l’agent s’arrête. Une injection de prompt est une tentative, dans un contenu lu par le modèle, de détourner ses instructions. Un courriel demandant à l’agent d’ignorer ses règles doit rester un courriel à trier, pas devenir une consigne. Décidez quelles propositions et actions doivent pouvoir être examinées pour repérer un écart.
Dans le document « Recommandations de sécurité pour un système d’IA générative », publié le 29 avril 2024, l’ANSSI recommande de sécuriser les systèmes d’IA générative dès leur conception et leur intégration. Pour un tri simple, une connexion supplémentaire ou une recherche documentaire complexe n’apporte rien si le scénario n’en a pas besoin. Le choix entre une solution hébergée et un fonctionnement local dépend notamment des données que l’entreprise accepte de transmettre et de sa capacité à exploiter le système. RIA2D aide à choisir la solution et à définir le périmètre ; la réalisation technique relève d’Ecluz, Redig ou Onven.
« Je traite le droit d’envoyer un courriel comme une décision distincte du droit de le lire. L’erreur fréquente consiste à donner les deux accès dès le départ pour gagner une étape de configuration. Je demande d’abord à voir le tri fonctionner avec une validation humaine. »
Richad AddouUn agent de tri se teste sur des demandes représentatives avant de recevoir des messages en conditions réelles. Rassemblez des cas faciles, ambigus et exceptionnels, puis inscrivez pour chacun la catégorie attendue et l’action acceptable. Faites traiter ces demandes par le scénario et comparez ses propositions aux décisions d’une personne. Une erreur de classement et une action non autorisée ne se corrigent pas de la même façon.
Notez les erreurs observées, modifiez les instructions ou le périmètre, puis rejouez les cas concernés et les cas ordinaires. Définissez explicitement quand l’agent doit passer la main : catégorie absente, contenu contradictoire, réponse du modèle inutilisable ou demande sensible. Une validation humaine se place avant l’action qui ne peut pas être reprise facilement.
La mise en service peut commencer par un mode où l’agent propose sans agir. Vous pouvez ensuite lui confier les seules actions que les tests permettent de contrôler. Conservez un journal des messages traités, des décisions proposées, des corrections et des erreurs. Prévoyez une façon d’arrêter le scénario et de reprendre le tri manuellement si une connexion ou le modèle ne répond plus.
Si le système déclenche des actions répétées, une sandbox d’exécution est un environnement de test séparé du fonctionnement courant. L’idempotence des appels d’outils désigne ici un résultat pratique : relancer une étape ne doit pas créer deux fois la même action. Ces précautions deviennent particulièrement utiles lorsqu’un incident peut provoquer plusieurs envois. Après tout changement de règle, de modèle ou de connexion, reprenez les tests avant d’élargir l’autonomie.
« Lors d’une revue, je regarde d’abord ce qui se passe quand une demande ne rentre dans aucune catégorie. Le piège est de ne tester que les messages bien rédigés. Mon réflexe est de conserver un cas ambigu dans les essais après chaque modification. »
Richad AddouLe budget d’un agent IA comprend davantage que l’accès à une plateforme : comptez aussi l’usage du modèle, les connexions aux outils, la mise au point et le suivi. Pour comparer des solutions, demandez ce qui est inclus dans chaque poste et ce qui dépend du volume de demandes ou des modifications futures. Un abonnement seul ne décrit pas le travail nécessaire pour exploiter le tri.
L’effort augmente si les messages arrivent par plusieurs canaux, si les catégories sont mal définies ou si l’agent doit consulter des documents internes. Il augmente aussi lorsque chaque outil impose des droits d’accès différents. À l’inverse, une demande déjà identifiable par un champ de formulaire relève souvent d’une règle fixe : inutile d’ajouter un modèle de langage pour lire une information déjà structurée.
La réussite se mesure sur votre travail réel. Vérifiez la qualité des catégories proposées, les erreurs qui exigent une correction, les demandes correctement transmises à une personne et le temps que prend encore leur vérification. Décidez à l’avance ce qui rendrait le scénario insuffisant : par exemple, des exceptions difficiles à repérer ou des corrections qui demandent de relire chaque message intégralement. Ne promettez pas un gain avant d’avoir observé ces résultats.
La construction d’agents peut répondre à un besoin où plusieurs actions doivent s’enchaîner, avec des limites explicites et un journal de leur exécution. Elle n’est pas le bon choix si un chatbot répond au besoin, si une automatisation fixe suffit ou si personne ne peut assurer le suivi. Le périmètre se décide avant la mise en service, pas après le premier mauvais aiguillage.
Créer un agent IA peut se justifier si une tâche répétitive oblige à interpréter des demandes différentes, à choisir entre plusieurs suites et à garder une trace des décisions. Pour répondre à des questions sans agir dans vos outils, un chatbot peut suffire ; pour transmettre un formulaire selon un champ connu, une automatisation fixe est plus simple à contrôler. Comparez donc le travail réellement évité à celui qu’il restera pour vérifier les propositions, corriger les erreurs et entretenir les connexions. Un outil existant est préférable s’il couvre la mission, les droits d’accès et le suivi attendus.
Le coût dépend de l’outil choisi, de l’usage du modèle, des connexions à vos logiciels, de la préparation des instructions, des tests et du suivi après mise en service. Demandez un chiffrage qui sépare ces postes et précise qui paie lorsque les demandes augmentent, qu’une connexion change ou qu’un nouveau cas apparaît. Vérifiez aussi les conditions de stockage des données et de sortie de l’outil, car changer de solution peut demander du travail. Sans mission définie ni périmètre des données, un prix global ne permet pas de comparer deux propositions.
Un agent IA n’a pas de prix unique : un tri limité à des propositions dans une boîte de réception ne demande pas le même travail qu’un système connecté à plusieurs outils et autorisé à agir. Pour obtenir un devis comparable, décrivez le déclencheur, les données accessibles, les catégories attendues, les actions permises, les validations humaines et le suivi souhaité. Faites distinguer la création, l’utilisation des outils et du modèle, puis les ajustements après livraison. Si votre besoin se règle par une règle fixe, demandez aussi le coût de cette option avant de retenir un agent.
Vous pouvez préparer un scénario de tri sans programmer si les outils choisis permettent de relier le point d’entrée, le modèle et un espace de validation. La fiabilité dépend toutefois du cadrage : catégories compréhensibles, droits limités, cas ambigus transmis à une personne et tests sur des demandes réelles. Le no-code ne remplace ni la vérification des connexions ni la surveillance après la mise en service. Si le système doit agir dans plusieurs logiciels ou traiter des données sensibles, faites examiner son périmètre et ses permissions par la personne chargée de le construire.
Réduisez d’abord les données lues et les droits accordés à ce que la mission exige, puis imposez une validation humaine avant une action difficile à annuler. Testez des messages ordinaires, ambigus et trompeurs pour voir si l’agent respecte ses catégories et transmet les exceptions à une personne. Conservez un journal des propositions et des actions, ainsi qu’un moyen d’arrêter le scénario. Aucune instruction ne supprime toute erreur : le dispositif doit permettre de la détecter, de la corriger et d’empêcher qu’une mauvaise proposition déclenche automatiquement une action sensible.
La possibilité de changer d’outil doit être examinée avant de connecter la messagerie et les autres logiciels. Demandez quels messages, catégories, décisions et journaux peuvent être récupérés, sous quelle forme, et qui peut retirer les accès une fois la solution arrêtée. Gardez aussi une description des instructions, des règles d’escalade et des connexions : les seules données exportées ne suffisent pas à reconstruire le processus. Si ces points restent flous, limitez le premier scénario à une mission réversible plutôt que de lui confier immédiatement des actions étendues. Le cadre général est sur notre page agents ia.
Racontez-nous ce qui vous prend le plus de temps en ce moment. On vous dit franchement si c’est automatisable, et par quoi commencer.
Demander un diagnostic →Nous mesurons l'audience de ce site pour savoir ce qui vous y amène. Rien n'est déposé sur votre appareil tant que vous n'avez pas accepté, et nous ne revendons aucune donnée.