Sur quel canal placer un agent IA : la décision prise en dernier qui commande depuis le début
Sur quel canal placer un agent IA, c'est la question qui arrive presque toujours à la fin, quand l'agent tourne déjà et qu'il faut le montrer à quelqu'un. Et elle arrive trop tard, parce que ce n'est pas une décision de présentation : c'est elle qui détermine qui va s'en servir pour de vrai, combien de temps il a pour répondre, avec quelles permissions il naît et ce qui reste écrit le jour où il se trompe. Choisir une surface, c'est choisir une architecture, un budget de latence et un modèle de sécurité d'un seul coup.
La thèse de ce guide est simple et se vérifie dans n'importe quelle entreprise : l'agent qui vit là où les gens travaillent déjà est utilisé ; celui qui vit dans un onglet à part meurt tout seul, aussi bon soit-il. Ce n'est pas une affaire d'enthousiasme ni de formation. C'est que chaque nouvelle surface que tu demandes d'ouvrir est un péage d'attention que quelqu'un paie tous les jours, et ce péage a un prix mesuré : la recherche publiée par Harvard Business Review en août 2022, sur 137 employés de trois entreprises du Fortune 500, a compté environ 1 200 sauts quotidiens entre applications et fenêtres, près de quatre heures par semaine — autour de 9 % du temps de travail — consommées rien qu'à se réorienter. Source : How Much Time and Energy Do We Waste Toggling Between Applications?, Harvard Business Review, août 2022.
Le contexte n'aide pas non plus un nouvel outil à se faire une place. Le rapport de Microsoft WorkLab sur la journée infinie, publié en juin 2025 à partir de signaux agrégés et anonymisés de Microsoft 365, situe une interruption toutes les deux minutes pendant la journée — 275 par jour chez les 20 % d'utilisateurs qui reçoivent le plus de notifications — entre réunions, e-mails et chats. Source : Breaking down the infinite workday, Microsoft WorkLab, juin 2025. Contre ce bruit-là, demander à quelqu'un de se souvenir d'un onglet de plus n'est pas une petite demande : c'est se battre pour le créneau le plus cher de ton équipe.
Les cinq surfaces réelles et qui se trouve en face de chacune
Dans la pratique, il n'y a que cinq endroits où un agent d'entreprise s'installe, et chacun arrive avec un utilisateur différent collé dessus. La surface ne se choisit pas au goût : elle se choisit en repérant où se trouve cette personne à l'instant exact où le travail apparaît.
- Dans le CRM ou l'ERP. Utilisateur : l'employé qui vit déjà là huit heures par jour. C'est la surface avec la meilleure adoption et la pire visibilité pour celui qui achète : personne ne fait une démo brillante d'un panneau latéral. En échange, l'agent apparaît à côté de la fiche qu'il va toucher, avec le compte et l'historique sous les yeux, et il n'y a rien à expliquer à personne sur l'endroit où le trouver.
- Slack ou Teams. Utilisateur : l'équipe, en conversation. Ça sert au travail qui naît en parlant — « quelqu'un sait si ce client a un contrat de support ? » — et aux processus où la décision est collective. Avantage réel : la question et la réponse restent visibles par tous, et ça construit la confiance bien plus vite qu'un chat privé.
- WhatsApp. Utilisateur : le client qui t'écrit déjà par là. C'est le canal avec le plus de traction commerciale en Espagne, en Italie et au Portugal, et celui qui traîne le plus de règles de plateforme. On le choisit quand le client y est déjà, jamais pour l'y amener.
- Le chat du site. Utilisateur : un visiteur anonyme en train de décider. C'est la surface la plus exigeante en latence et la plus pauvre en contexte : tu ne sais pas qui c'est. Son travail est de qualifier et de capter, pas de résoudre des cas client.
- L'e-mail. Utilisateur : le processus, plus que la personne. Factures fournisseurs, commandes, demandes qui arrivent déjà dans une boîte. C'est la surface la moins glamour et celle qui cache le plus de travail répétitif, parce que personne ne la regarde comme un canal : on la regarde comme un dossier.
Il en manque une sixième que presque tout le monde choisit par défaut et qui n'est pas dans la liste, exprès : l'onglet maison, l'application interne avec son URL et son login. Ce n'est pas qu'elle ne serve jamais — elle vaut pour le travail profond, avec des sessions longues et un utilisateur expert qui y va exprès —, c'est qu'on la choisit pour le confort de celui qui construit, pas pour l'endroit où est le travail. Si le cas d'usage, c'est « régler un truc qui surgit pendant que tu fais autre chose », l'onglet maison est la pire option disponible.
Latence : combien de silence chaque canal supporte avant de perdre l'utilisateur
Chaque surface a un budget de temps implicite que personne n'écrit et que tout le monde respecte. Ça se voit quand on le dépasse : l'utilisateur considère l'agent comme mort et s'en va. Voici les ordres de grandeur avec lesquels il vaut mieux concevoir.
| Surface | Budget de réponse | Ce que ça t'oblige à monter |
|---|---|---|
| Chat du site | Secondes | Modèle rapide + réponse partielle pendant qu'il travaille ; pas question d'attendre la réponse complète |
| Secondes à quelques minutes | Accusé de réception immédiat ; le client n'a pas l'écran ouvert à attendre | |
| Slack / Teams | Dizaines de secondes | Une réaction ou un « je m'en occupe », puis le vrai message ; l'asynchrone est déjà accepté |
| Dans le CRM / ERP | Secondes si c'est un bouton ; minutes s'il écrit dans la fiche | Décider si c'est une interaction ou un processus de fond — ce sont deux designs différents |
| Heures | Presque rien : ici la latence cesse d'être le problème et c'est la traçabilité qui le devient |
La conséquence la plus dure à accepter, c'est que le canal commande au modèle. Si la surface exige des secondes, tu ne peux pas te permettre trois appels enchaînés au modèle le plus capable, même s'ils répondent très bien ; il faudra répartir — pas cher pour classer et router, capable pour décider — et rendre quelque chose avant d'avoir fini. Cette répartition est développée dans quel modèle utiliser dans un agent IA, et c'est une décision qui se prend après celle de la surface, pas avant.
Permissions : chaque surface arrive avec les siennes déjà activées
Installer un agent sur une surface n'est pas neutre côté sécurité : il hérite du modèle de permissions de cette surface, et par défaut il en demande presque toujours trop. Mieux vaut regarder ça avant de signer, pas après le premier incident.
- CRM / ERP : il hérite, et c'est une bonne nouvelle. L'agent peut tourner avec le rôle de l'utilisateur qui l'invoque : si le commercial ne voit pas ce compte, l'agent ne le voit pas non plus. C'est le seul cas où la surface t'offre le travail déjà fait. Ce qu'il faut surveiller, c'est la tentation de lui donner un compte de service avec des droits d'administrateur « pour que rien ne plante ».
- Slack / Teams : des périmètres à lui, et le dangereux c'est l'historique. Il s'installe comme une application avec ses permissions. Lire l'historique complet d'un canal, c'est bien plus que ce qu'il faut d'habitude : pour la plupart des cas, recevoir les messages où il est mentionné suffit. Demander tout l'historique transforme l'agent en lecteur permanent des conversations internes, et ça mérite d'être une décision consciente.
- Chat du site : des inconnus. Il parle à des visiteurs non authentifiés, donc il ne peut pas avoir un accès en lecture aux données de clients précis. Tout ce qui ressemble à « dis-moi où en est ma commande » exige une étape d'identification avant, sinon tu finis avec une fuite de données élégamment conçue.
- WhatsApp : identité fragile. Un numéro de téléphone n'est pas une identité vérifiée : les numéros se recyclent et les téléphones se prêtent. Pour toute action à conséquences, il faut une vérification supplémentaire.
- E-mail : le périmètre est le piège. Donner accès à une boîte, c'est donner accès à tout son historique. Le périmètre se borne par étiquette, dossier ou alias dédié, jamais par boîte entière.
La règle commune aux cinq : la permission se demande par cas d'usage et se révise avec une date, on n'accepte pas celle que l'installateur apporte. Le développement complet — ce qu'on lui donne, comment on le retire et ce qu'on enregistre — est dans quelles permissions donner à un agent IA.
Ce qui reste tracé et ce qui s'évapore quand on ferme l'onglet
Le jour où l'agent se trompera — et ça arrivera — la question ne sera pas « pourquoi ? », ce sera « je regarde où ? ». La surface décide si cette question a une réponse en deux minutes ou en deux jours.
Slack et Teams sont la meilleure surface sur cet axe et presque personne n'en tient compte au moment de choisir : la conversation reste écrite, avec qui a demandé, ce que l'agent a répondu et qui l'a contredit, dans un endroit que l'entreprise conserve déjà et sait déjà exporter. Dans le CRM, c'est pareil si l'agent écrit dans la fiche au lieu d'un panneau volatil : la note reste collée au client et au dossier. Le chat du site, c'est l'extrême inverse : la session se ferme et, si tu n'as pas monté la persistance exprès, il ne reste rien à auditer sauf ce que ton fournisseur décide de garder, et pour combien de temps.
Ça rejoint ce qui se passe quand l'agent doute ou se retrouve sans réponse : le transfert vers une personne n'est bon marché que si la surface conserve le contexte. Sur Slack ou dans le CRM, la personne entre et lit ce qui est déjà là. Dans un chat de site sans persistance, la personne repart de zéro et le client répète tout. Ce qui doit voyager dans ce transfert est dans que fait un agent IA quand il ne connaît pas la réponse.
Les règles de canal qui ne se négocient pas : WhatsApp et l'e-mail
Deux des cinq surfaces arrivent avec une réglementation de plateforme à elles, et elle n'est pas indicative : si tu l'ignores, le canal cesse de fonctionner. Mieux vaut le savoir avant de promettre une expérience que la plateforme n'autorise pas.
Sur WhatsApp, quand un utilisateur t'écrit, une fenêtre de service client de 24 heures s'ouvre ; dans cette fenêtre tu peux répondre avec des messages libres, et si l'utilisateur réécrit, le compteur repart. En dehors, tu ne peux le contacter qu'avec des modèles approuvés au préalable, classés par catégorie — utilité, authentification, marketing — avec des règles et un coût différents selon le type. Source : documentation officielle de Meta, WhatsApp Business Messaging Policy, consultée le 14 septembre 2026. La traduction opérationnelle pour la conception de l'agent est directe : un agent WhatsApp est réactif par défaut, et tout flux qui demande d'initier la conversation doit être conçu comme un modèle approuvé avant d'écrire une ligne de code. Le détail de ce qui passe et de ce qui ne passe pas est dans ce que Meta autorise pour un agent IA sur WhatsApp, et la version commerciale du cas, dans répondre sur WhatsApp 24 heures sur 24.
L'e-mail n'a pas de plateforme pour te sanctionner, mais il a deux contraintes tout aussi dures : l'identité de l'expéditeur (si l'agent répond depuis une adresse générique, le taux de réponse s'effondre ; s'il répond depuis celle d'une personne, cette personne est responsable de ce qu'il dit) et le fil (répondre en créant un nouveau fil casse le suivi de n'importe quel processus). Aucune des deux n'est technique et les deux décident si le canal sert à quelque chose.
Le tableau de décision : quatre questions, une surface
La décision se boucle en un après-midi avec quatre questions, dans cet ordre. L'ordre compte : la première écarte la moitié des options et les autres affinent.
- Qui est l'utilisateur et qu'a-t-il d'ouvert quand ce travail apparaît ? Un employé dans un système → ce système. Une équipe qui parle → Slack ou Teams. Un client qui t'écrit déjà → son canal. Un visiteur anonyme → le chat du site. Personne, parce que le travail arrive tout seul → l'e-mail.
- Combien de temps peut-il attendre sans se sentir abandonné ? Si la réponse se compte en secondes, l'architecture doit rendre quelque chose avant d'avoir fini. Si c'est en heures, il te reste du budget et tu peux le dépenser à mieux vérifier.
- Quelles permissions cette surface m'oblige-t-elle à demander, et combien me sont vraiment nécessaires ? Si le minimum que la surface permet dépasse déjà ce que le cas justifie, c'est une raison légitime de changer de surface.
- Quand ça plantera, c'est écrit où ? S'il n'y a pas de réponse, soit tu montes la persistance avant de lancer, soit tu choisis une autre surface.
Et une règle d'architecture qui rend tout ce qui précède réversible : l'agent est un service, le canal est une couche fine par-dessus. Si la logique — les étapes, les conditions, les appels à tes systèmes — vit dans le constructeur visuel du fournisseur de chat, changer de surface ce n'est pas déplacer, c'est reconstruire. Si elle vit chez toi, derrière un contrat d'entrée et de sortie, déplacer le même agent du site vers WhatsApp ou d'un onglet maison vers Teams, c'est du travail de quelques jours. C'est cette condition qui fait de la décision de surface quelque chose que tu peux corriger le jour où les données d'usage te contredisent.
Nous, on commence par là, avant le modèle et avant le prompt : où est le travail, qui le fait et qu'est-ce qu'il a d'ouvert à ce moment-là. C'est ce qu'il y a sous Adoption IA pour les équipes — parce qu'avoir de l'IA dans l'entreprise n'est pas la même chose que l'entreprise utilise l'IA — et ce qu'on monte avec l'infrastructure d'IA pour l'entreprise quand l'agent doit vivre dans des systèmes déjà en production. Le reste du montage — permissions, autonomie, mémoire, évals — est dans créer un agent IA qui tient en production.