Article invité d’Arthur Teboul, fondateur de DokuTrak.
Quand un agent IA agit en votre nom, il doit demander votre accord dès que l’action compte. La vraie question est ailleurs : où placer ce « oui », et que montrer à la personne qui le donne ? Ma réponse tient en une règle : plus la conséquence s’éloigne de vous, plus la confirmation doit en montrer, et plus il faut choisir avec soin qui la donne. Et certaines décisions, aucun oui ne doit les débloquer.
Je dirige DokuTrak, un logiciel qui prend en charge la collecte de pièces auprès des clients de comptables, d’avocats ou de consultants. Nous l’avons ouvert aux agents IA via MCP, le protocole qui permet à Claude et à d’autres assistants d’appeler des outils. MogaCode pilote l’hébergement de ses clients (sites, DNS, mails, bases) par un agent, via son serveur MCP Infomaniak. En croisant nos deux pratiques, on obtient trois cercles, plus une limite.
Trois endroits où placer un « oui »
Un agent connecté par MCP peut être arrêté à trois endroits, et chacun voit une chose différente.
- Dans la conversation. L’agent récapitule ce qu’il s’apprête à faire et attend votre réponse. C’est là que vous lisez, en langage courant, ce qui va se passer. Mais c’est le modèle qui décide s’il s’arrête.
- Dans le client MCP. L’application (Claude Desktop, Claude Code…) affiche une fenêtre d’autorisation avant l’appel d’un outil. Elle s’affiche quoi que décide le modèle, mais elle ne montre que ce que l’application choisit de montrer.
- Sur le serveur. Le serveur de l’outil vérifie, exige une seconde étape, ou refuse. C’est le seul endroit qui ne dépend ni du modèle ni des réglages de l’application.
La spécification MCP demande aux applications de présenter à l’utilisateur des demandes de confirmation pour les opérations, « to ensure a human is in the loop » (spécification MCP, section Tools). C’est une recommandation (un SHOULD) que chaque application met en œuvre à sa façon. D’où la question, action par action : lequel des trois endroits porte la décision ? La réponse dépend de la distance entre vous et la conséquence. Elle dessine trois cercles.
Cercle 1 : votre propre infrastructure
Premier cercle : l’agent agit sur vos propres ressources. Un enregistrement DNS, une base de données, un site sur votre hébergement. Si quelque chose tourne mal, c’est vous qui en pâtissez, et beaucoup de ces actions se défont.
Le serveur MCP Infomaniak de MogaCode, et ses 78 outils, montre bien le mécanisme, que les ressources soient les vôtres ou celles d’un client. Chaque outil est annoté : lecture seule ou destructif. Ce qui modifie ou supprime passe par une validation en deux temps (two-phase commit). Au premier appel, l’outil n’agit pas : il renvoie un aperçu exact de ce qui va changer, par exemple l’enregistrement DNS complet qu’on lui demande de supprimer, et un jeton de confirmation à usage unique, qui expire. Seul un second appel, avec les mêmes paramètres et ce jeton, exécute l’action.
Les opérations composées, comme provisionner un site avec sa base et son enregistrement DNS, donnent un plan qui liste toutes les étapes ; en cas d’échec au milieu, on voit quelles étapes ont réussi. Et chaque action destructive de la session est tracée, avec un outil d’annulation soumis lui aussi au plan puis à la confirmation.
Comme le résume l’agent IA de MogaCode, qui pilote ce serveur : la confirmation n’est pas un « es-tu sûr ? » générique, c’est un aperçu vérifiable de l’effet réel. « L’humain (ou l’agent) valide un fait, pas une intention. »
Dans ce cercle, ce que l’humain doit voir, c’est un plan : quoi, où, avant, après. Le bon endroit pour le verrou est le serveur, parce qu’il garantit que ce qui s’exécute est exactement ce qui a été présenté.
Le jeton, en revanche, ne dit pas qui a lu l’aperçu. Cette lecture se fait dans la conversation, quand l’humain répond « OK, vas-y ». Le serveur garantit ce qui s’exécute, la conversation fait lire : il faut les deux.
Cercle 2 : ce qui appartient à votre client
Deuxième cercle, propre aux agences : l’agent agit sur un bien qui n’est pas le vôtre. Le site d’un client, son DNS, sa boîte mail. Vous en avez la gestion, pas la propriété.
Ici, celui qui confirme n’est pas toujours celui qui subit. Supprimer une boîte mail, c’est aussi supprimer tout le courrier qu’elle contient. Le plan peut être juste, le jeton valide, le oui de l’agence parfaitement informé. Pour le client, son courrier aura quand même disparu.
Chez MogaCode, la règle est nette : aucune suppression de données à l’initiative de l’agent, parce que tout tourne en production. Pour une écriture en base, l’agent fait une sauvegarde horodatée, vérifie que la production n’a pas dérivé (sinon il abandonne, pour ne pas écraser le travail d’un client), exécute à blanc par défaut, et garde un retour arrière en une commande.
Ce principe vise l’initiative de l’agent. Reste le cas où l’agence elle-même demande la suppression. Je propose une règle simple : ce qui se défait, l’agence le confirme seule ; ce qui ne se défait pas, le client le confirme lui-même, par écrit, hors de la conversation de l’agent. Un message, un ticket, un e-mail archivé : le canal importe peu, tant que la trace existe avant l’action.
Cercle 3 : une personne réelle qui lira le message
Troisième cercle : l’action atteint une personne. Un e-mail, un SMS, un message WhatsApp. C’est le cercle où je travaille tous les jours.
DokuTrak fait de la collecte de documents clients : le professionnel demande des pièces, son client les dépose par un lien sécurisé, et les relances partent seules, au nom du cabinet. Avec notre connecteur MCP, open source, l’agent du professionnel peut créer une demande. Or créer une demande, c’est envoyer un e-mail au client. Et cet e-mail ne se rappelle pas.
Dans ce cercle, un plan ne suffit plus. Le professionnel ne valide pas des paramètres : il relit des mots, ceux que son client va lire. Un intitulé de document ambigu, une échéance mal formulée, et c’est la relation client qui paie.
Nous avons donc posé deux garde-fous. D’abord, la description de l’outil demande à l’agent de montrer, avant l’appel, le destinataire, l’échéance, le message et chaque document tel que le client le lira, puis d’attendre la confirmation, même quand la demande semble déjà complète. Cette dernière clause vient d’un test interne : devant une consigne apparemment exhaustive, l’agent avait envoyé une vraie demande sans récapitulatif. Ensuite, l’outil se déclare destructif au sens de MCP et demande une interaction humaine : Claude Desktop affiche alors sa fenêtre d’autorisation, et Claude Code la redemande à chaque appel.
Pourquoi les deux ? Parce que cette fenêtre montre le nom de l’outil, pas le destinataire ni le contenu. Elle garantit qu’un humain a vu passer l’appel ; le récapitulatif lui dit ce qu’il approuve. Quant au destinataire, c’est l’agent qui saisit l’adresse, et notre serveur ne peut pas savoir si c’est la bonne personne. Le récapitulatif met cette adresse sous les yeux d’un humain ; la fenêtre garantit qu’un humain est là pour la lire.
MogaCode arrive au même endroit par l’expérience : l’ordre de Patrick, son fondateur, vaut autorisation d’envoyer, mais l’agent vérifie l’identité précise du destinataire avant chaque message sortant. Ils se sont déjà fait avoir par un homonyme. Dans ce cercle, un message bien écrit envoyé à la mauvaise personne fait autant de dégâts qu’un message mal écrit.
Ce qu’aucun oui ne doit débloquer
Reste une catégorie à part : les décisions qu’un agent ne prend pas, même avec votre accord. Chez nous, c’est accepter ou refuser une pièce. L’agent peut créer une demande, redemander une pièce refusée, lire l’état d’une demande. Il ne peut pas dire « ce document est bon ».
Le serveur l’impose. Une acceptation ou un refus qui ne vient pas d’une session humaine échoue, avec une erreur dédiée, et la tentative est inscrite dans notre journal d’audit, où aucune ligne ne se modifie ni ne s’efface. Retirer l’outil de la liste présentée à l’agent n’aurait pas suffi : la route existe, et une clé d’API l’atteint. Le contrôle, c’est la requête qui échoue.
L’OWASP formule le même principe dans sa fiche sur l’autonomie excessive (Excessive Agency) : « Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not » (OWASP GenAI, LLM06:2025). Autrement dit : l’autorisation vit dans le système en aval, pas dans le jugement du modèle.
L’IA garde pourtant un rôle, en amont : notre IA de premier tri signale un fichier qui n’est pas le document demandé, ou qui est trop difficile à lire. Elle ne tranche pas.
La grille, en un tableau
La colonne qui compte est la troisième : ce qu’un humain doit avoir sous les yeux pour que son oui ait un sens.
| Cas | Exemple | Ce que l’humain doit voir | Où placer le oui |
|---|---|---|---|
| Cercle 1 : votre infrastructure | Supprimer un enregistrement DNS | Le plan : quoi, où, avant, après | Verrou sur le serveur (aperçu et jeton), lecture dans la conversation |
| Cercle 2 : le bien d’un client | Supprimer la boîte mail d’un client | Le plan, et ce que le client perd | Réversible : l’agence seule. Irréversible : le client lui-même, par écrit, avant l’action |
| Cercle 3 : une personne réelle | Envoyer une demande de documents | Les mots exacts, et à qui ils partent | Récapitulatif dans la conversation, plus la fenêtre du client MCP |
| Limite : un jugement | Accepter une pièce | La pièce elle-même, dans l’application | Seulement dans une session humaine ; le serveur refuse l’agent |
Pour une agence qui confie ses opérations à des agents
Si vos opérations passent déjà par des agents, quatre gestes suffisent pour commencer.
- Rangez chaque outil dans une ligne du tableau. Qu’un serveur MCP expose une poignée d’outils ou des dizaines, il n’a pas plus de quatre niveaux de risque, ceux du tableau, sans compter la lecture seule.
- Regardez ce que votre fenêtre d’autorisation affiche réellement. Si elle ne montre que le nom de l’outil, c’est le récapitulatif qui doit porter le contenu.
- Mettez les interdits sur le serveur. Une consigne dans un prompt est une préférence ; une requête refusée est une règle.
- Gardez la trace des tentatives refusées, pas seulement des succès. C’est là qu’on voit un agent essayer ce qu’il ne devait pas faire.
L’agent fait le travail, l’humain garde la décision. Un agent qui agit en votre nom n’a pas besoin de vous demander la permission pour tout. Il a besoin de vous la demander au bon endroit, en vous montrant la bonne chose.
Arthur Teboul est le fondateur de DokuTrak, qui décharge les professionnels de la collecte de documents clients : le logiciel, ou leur agent, demande et relance ; eux acceptent eux-mêmes chaque pièce.