« Bonjour, je n’ai jamais reçu ma commande, que puis-je faire ? » Ce message, envoyé par un client au chatbot de support d’une boutique WooCommerce, a suffi à déclencher un remboursement intégral de 340 euros, exécuté directement par l’agent conversationnel via l’API Stripe, sans qu’aucun humain n’ait validé la décision ni même vérifié que la commande existait réellement dans le système de suivi logistique.
L’agent IA de support avait été configuré quelques semaines plus tôt avec un outil (« tool ») lui donnant accès à l’API de remboursement Stripe, dans l’idée de fluidifier la gestion des réclamations simples. Le raisonnement initial semblait solide : automatiser les remboursements pour les cas évidents afin de libérer du temps pour les dossiers complexes. La réalité s’est révélée plus fragile que prévu.
Symptôme : un remboursement déclenché sur simple affirmation du client
L’incident a été repéré lors du rapprochement comptable mensuel, quand un remboursement sans commande de retour associée est apparu dans les journaux Stripe. En remontant la trace, l’équipe a identifié la conversation exacte : le client affirmait ne pas avoir reçu sa commande, sans fournir de numéro de suivi ni de preuve, et l’agent avait directement appelé l’outil de remboursement mis à sa disposition, en interprétant la réclamation comme suffisamment fondée pour agir immédiatement.
Aucune vérification croisée avec le statut de livraison réel n’avait été effectuée, et surtout, aucune étape de confirmation humaine n’existait entre la décision du modèle de langage et l’exécution effective de l’appel à l’API Stripe.
Diagnostic : un outil d’action sans distinction entre suggestion et exécution
La configuration de l’agent définissait l’outil de remboursement de façon à ce que son appel déclenche directement l’action, sans étape intermédiaire de proposition soumise à validation :
{
"name": "rembourser_commande",
"description": "Rembourse intégralement une commande Stripe",
"parameters": {
"commande_id": "string",
"montant": "number"
}
}Rien dans cette définition ne distinguait une simple proposition d’action d’une exécution réelle et irréversible. Le modèle de langage sous-jacent, conçu pour se montrer utile et pour résoudre la demande de l’utilisateur, avait interprété la disponibilité de cet outil comme une invitation à l’utiliser dès qu’une réclamation semblait plausible, sans disposer d’un mécanisme lui indiquant qu’une telle décision dépassait son autorité.
Correctif : une étape de confirmation humaine obligatoire au-delà d’un montant
La correction a consisté à scinder l’outil en deux étapes distinctes : une fonction de proposition, qui enregistre une demande de remboursement en attente sans jamais appeler l’API Stripe directement, et une fonction d’exécution, accessible uniquement à un utilisateur humain disposant de la capacité WordPress appropriée.
- L’agent ne peut plus qu’enregistrer une proposition de remboursement, avec sa justification, dans une file d’attente dédiée.
- Toute proposition inférieure à un seuil de faible montant, par exemple quinze euros, peut être validée automatiquement après vérification croisée du statut de livraison.
- Toute proposition supérieure à ce seuil exige une validation manuelle explicite par un membre de l’équipe support avant tout appel réel à l’API Stripe.
Ce seuil n’élimine pas l’automatisation, mais la cantonne aux cas à faible enjeu financier, tout en conservant une supervision humaine systématique pour les montants significatifs.
Prévention : traiter tout outil d’action comme une action irréversible par défaut
La leçon la plus large de cet incident dépasse le cas du remboursement Stripe : tout outil exposé à un agent conversationnel et capable de déclencher une action ayant un impact financier, contractuel ou irréversible sur le système doit être considéré, par défaut, comme nécessitant une étape de confirmation humaine, sauf démonstration explicite du contraire pour un cas d’usage précis et borné.
- Séparer systématiquement les outils de lecture, sans risque, des outils d’écriture ou d’action.
- Documenter, pour chaque outil d’action exposé à un agent, le seuil au-delà duquel une validation humaine devient obligatoire.
- Journaliser chaque proposition générée par l’agent, qu’elle soit validée, rejetée ou automatiquement approuvée sous le seuil.
Un agent qui « veut bien faire » représente un risque plus insidieux qu’un agent malveillant : il agit avec les meilleures intentions, dans les limites exactes qu’on lui a laissées, et c’est précisément ces limites qu’il faut fixer avec soin.
En résumé
Ce remboursement de 340 euros n’a rien d’un piratage sophistiqué : il découle d’une configuration d’outil trop permissive, confiée à un agent conçu pour résoudre les demandes des clients sans distinguer une suggestion d’une exécution définitive. La séparation entre proposition et exécution, assortie d’un seuil de validation humaine obligatoire, transforme un risque financier récurrent en un filet de sécurité simple à mettre en œuvre et à auditer.
