En bref
Servez les agents IA de vos clients en suivant trois règles : répondez à toute question portant sur des informations publiques, n'agissez qu'après la même vérification de compte que pour une personne, et soumettez les opérations financières ou les modifications de compte au titulaire du compte. Ne vous fiez pas à la détection. Les standards applicables aux agents prouvent quel agent écrit, jamais quel client l'a envoyé, et les e-mails ne fournissent aucun signal. Vérifiez donc le titulaire, pas l'expéditeur. Votre propre agent IA de support peut répondre en premier, à condition que les remboursements et les résiliations attendent une approbation : c'est ainsi qu'eesel fonctionne dans Zendesk, Freshdesk et Gorgias.
Qu'est-ce qui change quand votre client est un agent IA ?
Je traite les tickets de support chez eesel tous les jours, et les premiers tickets rédigés par des agents ne ressemblent pas à des messages de robots. Ils ressemblent à ceux du client le plus organisé que vous ayez jamais eu : numéro de commande dès la première ligne, citation exacte de votre politique, demande polie de remboursement. Puis vous répondez « non », et un nouveau message tout aussi poli arrive, avec un autre angle d'approche.
C'est ça, le changement. Les agents grand public comme Muse de Meta, Instinct et ChatGPT patientent désormais au téléphone, changent de canal et continuent de demander. Decagon rapporte que Muse a dépassé les 5 millions de téléchargements quelques semaines après son lancement, et que chez certains de ses clients grandes entreprises, les agents personnels demandent à parler à un humain à presque chaque prise de contact.
Les personnes qui les envoient sont ravies :
"This week, Muse called customer service on my behalf. It navigated the phone tree, waited on hold, spoke with a human rep, and resolved the issue (worked great!).
The crazy thing for me (besides that it works) is that the rep didn't blink. Talking to a bot was completely natural to them."
Les personnes qui les reçoivent sont moins convaincues. Un professionnel du support répondant à une discussion LinkedIn sur ce sujet précis l'a dit clairement :
"This is already happening, In the last 10 days I have seen a lot of tickets coming in from Agents and its actually pretty hard to get them to agree to close out tickets.
The agents seem to love asking for ten non pertinent things along with one pertinent item. Identifying the one is becoming a skill that you need to have."
Trois choses changent concrètement de votre côté de la file de tickets :
- Le volume augmente. Quand se plaindre ne coûte rien au client, les petits problèmes qu'il ignorait auparavant deviennent des tickets. La publication la plus partagée sur le sujet, celle de @TheMindScourge sur X (2 683 mentions J'aime), affirmait que les agents "reduce the cost of complaints/requests to ~ zero".
- La persévérance est gratuite. Une personne abandonne après le deuxième « non ». Un agent peut reformuler la même demande dix fois sans se fatiguer, et finit donc par trouver la moindre faille dans votre politique de remboursement.
- L'expéditeur n'est pas le titulaire. Ce qui vous écrit est un logiciel. La personne à qui appartient le compte n'est peut-être pas en train de suivre l'échange, n'a peut-être pas approuvé cette demande précise, et peut ensuite affirmer qu'elle n'y a jamais consenti.
Si vous utilisez déjà un agent IA pour traiter vos tickets, ou si un agent ChatGPT s'occupe de vos propres démarches, vous faites désormais du support d'agent à agent, que vous l'ayez prévu ou non. La bonne nouvelle : l'essentiel de ce dont vous avez besoin relève de vos règles de fonctionnement, pas d'un nouveau produit.
Peut-on savoir quand un agent IA nous écrit ?
Parfois, et seulement en partie. Voici la lacune qu'aucune page de fournisseur ne met vraiment en avant : les standards qui identifient les agents vous disent quel agent appelle, pas quel client l'a envoyé. Le groupe de travail de l'IETF sur l'authentification des bots indique explicitement que "authenticating the end user of a participating client or agent" est hors périmètre.
Voici ce que chaque voie vous apporte réellement aujourd'hui :
| Comment l'agent vous contacte | Ce que vous pouvez savoir | Où se trouve le signal | Ce qu'il ne vous dit pas |
|---|---|---|---|
| E-mail, chat, téléphone (l'essentiel du trafic aujourd'hui) | Rien de fiable, sauf si l'agent se déclare ou si un modèle de détection le signale | Votre outil de support | Quel agent, quel client |
| Requêtes web signées (Web Bot Auth) | La plateforme de l'agent, par exemple Signature-Agent: "https://chatgpt.com" | Journaux du CDN ou du pare-feu | Quel utilisateur de ChatGPT |
| Paiement via un réseau de cartes (Visa Trusted Agent Protocol, Mastercard Agent Pay) | Un agent enregistré, plus des identifiants de l'acheteur partagés avec son consentement, comme un identifiant de fidélité ou une adresse e-mail | Données de paiement et de commande | Tout ce qui ne concerne pas l'achat |
| Protocole d'agent avec connexion (Poppy) | L'agent, un identifiant utilisateur propre à chaque entreprise et les périmètres d'autorisation accordés par le client | Un point de terminaison du protocole que vous exploitez | Rien de majeur, mais presque personne ne le prend encore en charge |
Quelques précisions à connaître :
- L'agent de ChatGPT a un nouveau nom. Le centre d'aide d'OpenAI indique désormais "ChatGPT agent is no longer available" et renvoie vers le navigateur cloud de ChatGPT Work, qui signe chaque requête avec Web Bot Auth. OpenAI indique aussi qu'il s'interrompt pour laisser l'utilisateur se connecter et demande confirmation "before actions that could be hard to reverse", comme une réservation ou un paiement. C'est utile, mais c'est une promesse d'OpenAI concernant son propre agent, pas une garantie applicable à tous les agents.
- Il existe des modèles de détection pour la voix. Sierra a lancé fleming-1 pour signaler les appelants utilisant une voix synthétique, avec une approche présentée comme "information, not judgement". Le Personal Agent Gateway de Decagon signale les agents probables dans le chat en direct et les échanges vocaux.
- L'e-mail est l'angle mort. Je n'ai trouvé aucun fournisseur qui revendique une détection fiable des agents par e-mail, et c'est là qu'arrivent beaucoup de tickets rédigés par des agents.
La détection est donc utile pour mesurer et orienter les demandes. Ce n'est pas une base sur laquelle fonder votre politique de remboursement. Si vos règles ne s'appliquent qu'une fois un agent repéré, tous les agents qui ne se déclarent pas passent directement entre les mailles du filet.
Faut-il bloquer les agents IA ou les servir ?
Servez-les, avec des règles. Les bloquer semble rassurant, mais cela pénalise surtout le client qui a envoyé l'agent et pousse les agents à mieux se faire passer pour des humains.
Certaines entreprises raccrochent déjà. Un utilisateur de Muse qui faisait construire une maison a tenté d'obtenir les conditions de plusieurs constructeurs :
"I had it make multiple customer service calls. I'm building a house and I was trying to get terms and agreements from multiple builders. They all hung up as soon as muse started talking."
Ce constructeur a perdu une demande de devis d'un véritable acheteur. Et les clients qui envoient des agents ont souvent de bonnes raisons de le faire :
"When I need support, I can't reach a human at most companies I work with now. If I manage to do so, it's only after extensive effort and negotiation with support bots.
So why in the world wouldn't I respond to this by automating away the hassle?"
Il existe aussi une raison juridique de ne pas faire obstacle à certaines demandes. Au Royaume-Uni, les nouvelles règles sur les abonnements entrent en vigueur le 1 janvier 2027, et le projet de lignes directrices indique qu'un client peut résilier un abonnement au moyen d'"a clear statement", sans forme imposée. Ces lignes directrices ne précisent pas si une déclaration envoyée par un agent est valable. Mais un parcours de résiliation qui ne fonctionne que si un humain saisit la demande constitue précisément le type d'obstacle que les régulateurs examinent déjà, et la CMA, la FCA, l'ICO et Ofcom au Royaume-Uni ont publié une déclaration commune sur les agents agissant pour les consommateurs le 30 octobre 2026.
La bonne question n'est pas « humain ou bot ? ». C'est « que cherche à faire cette demande, et qui doit y consentir ? »
Comment le support doit-il traiter une demande provenant d'un agent IA ?
Classez la demande selon ce qu'elle fait, puis appliquez les mêmes vérifications que pour une personne. Cela vous donne trois catégories.
| Catégorie | Exemples de demandes | Vérification avant d'agir | Qui décide |
|---|---|---|---|
| Répondre à tout le monde | Politique de retour, caractéristiques des produits, délais de livraison, horaires du magasin | Aucune, il s'agit d'informations publiques | Votre agent IA, de manière autonome |
| Agir après la vérification habituelle | Statut de commande, correction d'adresse avant expédition, remboursement sous votre plafond, remplacement d'un article endommagé | La même vérification de compte que pour une personne : l'e-mail du ticket correspond à la commande, session connectée, numéro de commande et code postal | Votre agent IA, dans les limites que vous fixez |
| Confirmation du titulaire | Changement de l'e-mail ou du mot de passe du compte, informations de paiement, remboursements au-dessus de votre plafond, fermeture d'un compte | Une étape que le titulaire du compte effectue lui-même | Une personne de votre équipe, ou directement le titulaire |
Les résiliations se situent à la frontière entre la deuxième et la troisième catégorie. Compte tenu des règles britanniques ci-dessus, je traiterais une résiliation une fois le compte vérifié, puis j'en informerais directement le titulaire, plutôt que d'imposer d'abord des étapes supplémentaires à l'agent.
Vérifiez le titulaire, pas l'expéditeur
La règle la plus utile que j'aie vue sur ce sujet consiste à arrêter de demander « est-ce un bot ? » pour commencer à demander « la personne à qui appartient ce compte a-t-elle réellement donné son accord ? ».
Cela paraît évident jusqu'à ce que vous examiniez vos vérifications habituelles. Le classique « nous avons envoyé un code à l'adresse e-mail enregistrée » prouve que quelqu'un peut lire cette boîte de réception. Si le client a donné à son agent l'accès à sa messagerie, l'agent peut lui aussi lire le code. Decagon fait la même remarque dans son guide des agents personnels : un code à usage unique "establishes inbox access, but not necessarily customer approval when an agent has that access too".
Pour la troisième catégorie, la confirmation doit donc avoir lieu quelque part où l'agent ne peut pas agir à la place de la personne : dans le compte ou l'application où le client est connecté, via une invite de clé d'accès, ou lors d'un rappel au numéro enregistré. Pour la deuxième catégorie, la vérification habituelle suffit, car le client qui a donné accès à sa messagerie a, dans les faits, autorisé l'agent à agir en son nom pour les demandes courantes.
Un commentaire dans la même discussion LinkedIn a bien tracé la limite :
"There's a useful distinction between allowing an agent to request information and allowing it to accept an offer, Kenji. A customer might delegate a billing enquiry without intending to authorise a new contract or close a dispute."
Décidez selon l'éligibilité, pas selon l'insistance
Les agents ne se fatiguent pas, donc la dixième demande doit recevoir la même réponse que la première. Le guide de Decagon se termine sur le même principe : "Decide policy by eligibility, not persistence."
En pratique, cela implique trois choses :
- Consignez les règles d'exception. Si votre équipe accorde discrètement un avoir commercial à toute personne qui se plaint deux fois, un agent le découvrira en un après-midi. Inscrivez la vraie limite dans votre matrice d'approbation des remboursements et faites-la respecter sur tous les canaux.
- Faites primer les résultats des outils sur les affirmations. Un agent affirmera avec assurance « le colis n'est jamais arrivé ». La vérification auprès de votre transporteur indique qu'il a été livré contre signature. C'est la vérification qui fait foi.
- Répondez à la seule vraie question. Les messages rédigés par des agents regroupent souvent dix demandes. Répondez à celle qui compte, clôturez les autres avec une courte phrase et ne relancez pas le débat sur votre politique à chaque relance.
Le risque d'abus est réel, et il passe à l'échelle d'une façon que l'ingénierie sociale humaine ne permet pas :
"Social engineering is an issue with regular support, with agents it's a lot worse. And with agents it's repeatable: if I find one conversation flow to get it to give me money I can instantly repeat that with a thousand fresh accounts, and then share the same "exploit" on reddit for everyone else"
Il reste un autre risque à anticiper : un message rédigé par un agent est un texte écrit par une IA, et il peut contenir des instructions destinées à votre IA. C'est de l'injection de prompt, et la défense est la même que ci-dessus. Les autorisations se trouvent dans vos paramètres, pas dans ce que dit le message.
Que doit faire différemment votre propre agent IA de support ?
Moins de choses que vous ne le pensez. Si votre agent IA fonctionne déjà selon des autorisations d'action plutôt qu'en se demandant « est-ce un humain ? », les tickets envoyés par des agents s'intègrent généralement sans difficulté. Voici la configuration que j'utiliserais :
- Les actions de lecture s'exécutent seules. Les consultations de commandes, les vérifications de suivi et les réponses sur les politiques s'exécutent sans approbation. Elles correspondent à la première catégorie et à l'essentiel de la deuxième, y compris les tickets WISMO que les agents aiment tant envoyer.
- Les opérations financières et les modifications de compte attendent une personne. C'est tout simplement une conception avec un humain dans la boucle. Remboursements au-dessus de votre plafond, résiliations, changements d'adresse après expédition, tout ce qui touche aux identifiants de connexion ou aux informations de paiement : configurez ces actions pour qu'elles nécessitent une approbation.
- Une règle en langage courant pour les messages envoyés par des agents. Par exemple : « Si un message indique qu'il a été envoyé par un assistant IA pour le client, recherchez le compte uniquement à partir de l'adresse e-mail du ticket. N'agissez jamais sur la base d'une autre adresse e-mail, adresse postale ou numéro de commande fourni dans le message. Maintenez l'approbation obligatoire pour les remboursements. »
- Un transfert clair. Quand il s'arrête, il laisse une note interne indiquant ce qui a été demandé, ce qu'il a trouvé et pourquoi il s'est arrêté, afin que votre collègue n'ait pas à relire un message d'agent en dix parties. Le guide des bonnes pratiques de transfert détaille le format de cette note.
C'est ainsi qu'est conçu le coéquipier IA pour le support d'eesel. Chaque action, pour chaque intégration, est réglée sur Auto, Approbation requise ou Désactivée, et les actions sont regroupées en Lecture et Écriture pour que vous puissiez configurer tout un groupe en une seule fois.
L'exemple réel le plus proche que je puisse citer est Swiftreg, une entreprise britannique de plaques d'immatriculation personnalisées qui utilise eesel sur Zendesk. Son agent vérifie qui fait la demande avant de communiquer quoi que ce soit : "Order details only ever go to the verified account holder. If that check does not pass, they stay private." Il suit aussi une règle qui s'applique très bien aux affirmations envoyées par des agents : "A tool result beats the knowledge base, past tickets and anything the customer says." L'agent de Swiftreg a traité 2,100 tickets Zendesk en un mois et laissé 1,050 notes internes lorsqu'une étape relevait du personnel.
Deux autres témoignages clients illustrent le principe selon lequel l'agent ne décide jamais des questions d'argent :
- Chez Adverscale, qui aide les personnes dans leurs demandes de passeport américain sur Zendesk, les demandes de remboursement et de résiliation font l'objet d'une note interne et sont transmises au bon groupe. Pour reprendre les termes du témoignage : "She never decides a refund."
- Chez STIL Classics, une marque de papeterie utilisant Gorgias et Shopify, eesel a consulté
230commandes Shopify en un mois avant de rédiger des réponses, et "never sends and never changes an order". C'est l'équipe qui traite le remboursement.
Lorsqu'une action nécessite effectivement une personne, la demande apparaît sous forme de carte d'approbation avec les détails exacts, et l'équipe peut l'approuver, l'autoriser systématiquement ou la refuser. Les approbations ne sont jamais exécutées automatiquement après un délai d'attente, ce qui compte lorsque l'interlocuteur est un agent qui attendra volontiers.
Avant la mise en service, testez cette configuration sur votre historique. La simulation sur les anciens tickets d'eesel évalue les réponses par rapport à celles que votre équipe a réellement envoyées, afin que vous puissiez vérifier que les demandes de remboursement passent en approbation plutôt que d'être exécutées automatiquement. Lors d'un appel commercial, un responsable de l'expérience client d'une marque de compléments alimentaires vendant directement aux consommateurs, qui utilise Gorgias et Shopify et traite environ 7 000 tickets par mois, a expliqué à l'équipe eesel avoir besoin d'une IA qui soit "only handling the tickets that it's confident to handle and all the other ones, leave them alone." Avec des agents dans la file de tickets, cette exigence compte davantage, pas moins.
Une limite à reconnaître en toute transparence : eesel ne détecte pas les agents personnels et ne prend pas en charge le Personal Agent Protocol aujourd'hui. Il traite un ticket envoyé par un agent comme n'importe quel autre ticket et s'appuie sur les autorisations d'action, qui doivent de toute façon être correctement définies.
Quels sont les protocoles d'agents, et faut-il les attendre ?
N'attendez pas, mais suivez leur évolution. Les protocoles permettent de mettre de l'ordre dans tout cela : l'agent indique qui il est, le client se connecte sur votre page, et vous accordez des périmètres d'autorisation restreints. Aujourd'hui, presque tout le trafic des agents arrive encore par les canaux ordinaires : ce sont donc les règles de vos catégories qui font l'essentiel du travail.
| Protocole | Qui est derrière | Statut (novembre 2026) | Ce qu'il apporte à une équipe de support |
|---|---|---|---|
| Personal Agent Protocol (Poppy) | Sierra et Meta, 43 partenaires répertoriés, dont OpenAI, Zendesk, Visa et Mastercard | v0.1 publiée le 9 octobre 2026, projet 0.3 en cours | Connexion OAuth sur votre propre page, périmètres d'autorisation définis par l'entreprise, demande de transfert et indicateur sur chaque message précisant s'il a été écrit par une personne ou une IA |
| PACT | Decagon | Publié en open source sur GitHub, aucun commit sur la branche principale depuis le 6 octobre | Consentement à périmètre défini reposant sur A2A et OAuth, lié à la passerelle de Decagon |
| Visa Trusted Agent Protocol et Mastercard Agent Pay | Réseaux de cartes de paiement | Visa indique "in development and deployment" | Agents enregistrés au moment du paiement, plus identifiants de l'acheteur partagés avec son consentement |
| Web Bot Auth | Projet de l'IETF, utilisé par Cloudflare et OpenAI | Projet du groupe de travail daté du 29 octobre 2026 | Preuve de la plateforme d'agent qui a envoyé une requête web |
Deux détails du projet Poppy méritent d'être repris dès maintenant dans vos propres règles. Les entreprises peuvent marquer chaque périmètre d'autorisation comme réversible ou irréversible, et publier les tâches qu'elles n'effectueront pas du tout via le protocole, avec "Close an account" parmi les exemples de la spécification elle-même. C'est le modèle à trois catégories inscrit dans un protocole, et un bon modèle pour vos propres garde-fous IA.
Du côté des plateformes de support, Lorikeet indique que sa prise en charge de Poppy est opérationnelle et accessible en libre-service, tout en précisant que "Today ChatGPT cannot speak Poppy". Zendesk, Genesys et NiCE figurent sur la liste des partenaires, mais n'ont pas encore annoncé leur propre prise en charge.
La question de la responsabilité évolue aussi. Selon les règles Visa (édition du 24 octobre 2026), le titulaire d'une carte est responsable d'un achat effectué par un agent "as if the Cardholder initiated the Transaction", et les commerçants ne peuvent pas obliger les clients à renoncer à leurs droits de contestation. Conservez une trace de ce qui a été confirmé et à quel moment, car « mon agent a acheté le mauvais article » est la prochaine catégorie de litige de facturation.
Si vous vendez en ligne, la dimension commerciale de ce sujet est abordée dans mes guides sur le commerce agentique et l'Agent Gateway de Walmart.
Comment vous préparer dans les 30 prochains jours ?
Voici un ordre de travail pratique, à raison d'environ une semaine par étape :
- Mesurez le phénomène. Ajoutez un tag comme
ai-agent-senderet demandez à votre équipe (ou à votre agent IA) de l'appliquer lorsqu'un message indique qu'il provient d'un assistant, ou semble avoir été rédigé par un assistant. Un mois de tags vous permettra d'en mesurer l'ampleur chez vous. - Définissez les trois catégories par écrit. Listez vos 20 principaux motifs de contact et classez chacun dans une catégorie. Accordez le plus d'attention à tout ce qui entraîne un mouvement d'argent, modifie les identifiants de connexion ou met fin à un contrat.
- Corrigez l'étape de confirmation. Pour la troisième catégorie, assurez-vous que le titulaire confirme à un endroit où l'agent ne peut pas accéder à sa place. Un code envoyé par e-mail ne suffit pas dans ce cas.
- Alignez les autorisations de votre agent IA. Actions de lecture autonomes, actions d'écriture entraînant un mouvement d'argent soumises à approbation, et règle en langage courant pour les messages envoyés par des agents. Puis simulez le tout sur d'anciens tickets de remboursement et de résiliation.
- Communiquez la règle à votre équipe. « Même réponse à la dixième demande » et « vérifiez le titulaire, pas l'expéditeur » tiennent sur un pense-bête. Les agents dans la file de tickets vont mettre ces deux règles à l'épreuve.
Pour approfondir les catégories à risque, commencez par les guides sur le support à la récupération de compte et les tickets liés à la fraude.
Pour la catégorie financière, les guides sur les demandes de remboursement traitées par l'IA et les workflows d'approbation détaillent la configuration.
Si vous souhaitez que votre agent IA communique directement avec d'autres systèmes plutôt que par la messagerie, les guides sur MCP pour le support client et les agents IA de service à service couvrent cet aspect.
Essayez eesel pour les tickets envoyés par des agents
Si des tickets rédigés par des agents commencent à arriver dans votre file Zendesk, Freshdesk ou Gorgias, eesel est un moyen rapide d'y répondre sans assouplir vos règles. Il rejoint votre outil de support comme un nouveau collègue, répond seul aux questions sur vos politiques, consulte la commande avant de répondre, et met les remboursements, les résiliations et les modifications de compte en attente d'approbation par votre équipe, de la même manière que Swiftreg réserve les détails des commandes aux seuls titulaires de compte vérifiés. Vous pouvez le tester sur vos anciens tickets avant qu'il ne réponde à qui que ce soit, et les offres commencent par une formule gratuite sur la page des tarifs.
Comment mon équipe de support peut-elle savoir si un ticket provient d’un agent IA ?