Quand votre agent IA rembourse 4 000 € sans vous demander la permission
Un agent de support client équipé d'un outil de remboursement. Un message client ambigu. Un modèle de langage un peu trop enthousiaste. Résultat : quatre mille euros quittent votre compte Stripe avant qu'un humain n'ait lu un seul mot de la conversation.
Ce scénario n'est pas hypothétique — c'est précisément le risque que fait courir toute architecture agentique qui délègue des actions irréversibles à un LLM sans filet de sécurité. Jusqu'au 21 juillet 2025 et la sortie de laravel/ai v0.10.0, il n'existait aucun mécanisme natif dans le Laravel AI SDK pour interrompre la boucle d'un agent avant qu'il n'exécute un outil critique.
Cet article, inspiré d'un post technique publié sur dev.to par Hafiz, explore le pattern Human-in-the-Loop (HITL) et ce qu'il change concrètement pour les équipes qui déploient des agents IA en production.
Le problème fondamental des agents autonomes en contexte métier
Les agents IA sont séduisants parce qu'ils automatisent des workflows complexes : ils enchaînent des appels d'outils, interprètent des réponses, ajustent leur stratégie. Mais cette autonomie est précisément ce qui les rend dangereux sur des opérations sensibles.
Dans un contexte e-commerce ou SaaS, les outils qu'on donne à un agent peuvent inclure :
- l'émission de remboursements
- la révocation d'accès utilisateur
- l'envoi d'emails transactionnels
- la modification de données de facturation
Avant v0.10.0, les seules protections disponibles dans le SDK étaient :
- la validation d'arguments dans
handle() — utile, mais exécutée après la décision du modèle
- des listes blanches de paramètres — fragiles face à des inputs inattendus
- l'exclusion pure et simple de l'outil — efficace, mais on perd toute la valeur de l'automatisation
Aucune de ces approches ne permettait de mettre un humain dans la boucle : laisser l'agent préparer l'action, la soumettre à validation, et n'exécuter que sur approbation explicite.
Ce que change l'API Human-in-the-Loop de Laravel AI SDK
La PR laravel/ai#773, annoncée à Laracon US, introduit un mécanisme de pause avant exécution pour les outils marqués comme "approvables".
Le principe est simple :
- L'agent détermine qu'il veut appeler un outil sensible
- Avant d'exécuter, le SDK sérialise l'appel en attente et le restitue à l'application
- L'application stocke cet état, notifie un opérateur humain
- L'humain approuve ou rejette
- L'agent reprend (ou s'arrête) en fonction de la décision
Concrètement, un outil devient "approvable" via une interface dédiée :
use Laravel\AI\Contracts\Approvable;
class RefundOrderTool implements Tool, Approvable
{
public function handle(string $orderId, float $amount): string
{
// Cette méthode ne s'exécute QUE si un humain a approuvé
return $this->stripeService->refund($orderId, $amount);
}
}
Le SDK intercepte l'intention du modèle, sérialise $orderId et $amount, et retourne le contrôle à votre application avant d'appeler handle().
Les cas limites que le chemin heureux ne couvre pas
La documentation officielle décrit bien le cas nominal. Mais en production, trois situations méritent une attention particulière.
1. La génération échoue à mi-parcours
Si le modèle timeout ou retourne une erreur après avoir préparé un appel d'outil mais avant que vous ne l'ayez persisté, l'état est perdu. La bonne pratique est de persister immédiatement l'appel en attente dans votre base de données dès que le SDK vous le restitue, indépendamment de ce qui suit.
2. Deux outils sensibles dans le même step
Un modèle peut décider d'appeler plusieurs outils en parallèle dans une même itération. Si les deux sont approvables, vous devez traiter chaque approbation indépendamment — et vous assurer que le rejet de l'un n'entraîne pas l'exécution de l'autre par défaut.
3. L'approbateur n'est pas le propriétaire de la conversation
Dans un contexte multi-tenant ou avec des workflows de validation hiérarchique, la personne qui clique "approuver" n'est pas forcément l'utilisateur qui a initié la conversation. Votre système d'approbation doit donc gérer :
- l'identité de l'approbateur (audit trail)
- les permissions : qui peut approuver quoi ?
- le délai d'expiration : une approbation en attente depuis 48h est-elle encore valide ?
Ces questions relèvent de votre architecture applicative, pas du SDK — mais elles sont critiques pour une mise en production responsable.
Un pattern applicable au-delà de Laravel
Bien que l'article source soit centré sur Laravel, le pattern HITL est universel et pleinement applicable dans un contexte Symfony/PHP. Les principes sont identiques :
- Identifier les outils à risque élevé (irréversibilité, impact financier, données personnelles)
- Intercepter avant exécution, pas après
- Persister l'état de l'appel en attente (base de données, queue)
- Notifier l'opérateur humain (email, Slack, interface d'administration)
- Tracer chaque décision d'approbation ou de rejet pour l'audit
En Symfony, ce pattern peut s'implémenter via un event subscriber sur un événement ToolCallPending, un voter pour les permissions d'approbation, et une entité PendingToolCall persistée en base — indépendamment du SDK LLM utilisé.
Conclusion : l'autonomie agentique ne signifie pas l'autonomie absolue
Déléguer des tâches à un agent IA ne revient pas à abandonner le contrôle — cela devrait signifier choisir explicitement quelles actions méritent une validation humaine. Le pattern Human-in-the-Loop est la traduction technique de cette exigence.
La nouveauté de laravel/ai v0.10.0 est de rendre ce pattern accessible sans devoir reconstruire toute la mécanique soi-même. Mais la vraie valeur n'est pas dans le framework : elle est dans la discipline de conception qui consiste à cartographier ses outils par niveau de risque avant de déployer un agent en production.
Un agent qui demande permission avant d'agir n'est pas un agent moins puissant. C'est un agent en qui on peut avoir confiance.
