Migration chatbot vers agent autonome : 8 garde-fous à mettre avant la mise en prod

Un chatbot qui répond à une mauvaise réponse : embêtant. Un agent qui prend une mauvaise action : facture. La transition chatbot → agent est devenue le sujet n°1 des roadmaps produit IA en 2026. C'est aussi le moment où la dette de sécurité s'accumule le plus, parce que le go-to-market presse et que les vrais risques sont peu visibles avant la mise en prod.

Sur 6 migrations chatbot → agent que j'ai accompagnées en 2025-2026, les 8 garde-fous suivants sont ceux qui ont fait la différence entre une production qui tient et une production qui crée des incidents. Aucun n'est gadget. Aucun ne peut être "ajouté plus tard".

Garde-fou 1 — Catalogue de tools explicite et minimal

Un chatbot a un seul "tool" : générer du texte. Un agent en a 5 à 50.

À mettre avant la prod :

• Liste exhaustive de tous les tools de l'agent, avec pour chacun : nom, description, paramètres, type d'action (lecture / écriture / externe), criticité.
• Politique du "moindre tool" : un agent n'a accès qu'aux tools strictement nécessaires à son périmètre.
• Versioning des tools : tout ajout ou modification d'un tool passe par une revue.

Si vous ne pouvez pas afficher en 1 page la liste des tools de votre agent et ce qu'ils font, vous n'êtes pas prêt pour la prod.

Garde-fou 2 — Validation humaine pour les actions à impact

Toutes les actions ne se valent pas. Catégoriser :

• Lecture : pas de validation.
• Écriture interne sans effet externe (note dans un CRM, log) : pas de validation.
• Écriture interne avec effet visible client (modif d'un contrat, changement de statut commande) : validation humaine.
• Action externe (envoi d'email, paiement, suppression, déploiement) : validation humaine obligatoire, sans option de désactivation.
• Action irréversible (suppression définitive, transaction financière > X €) : double validation humaine.

Le timeout sur les validations : si pas de réponse en X minutes, action annulée par défaut, pas exécutée. Beaucoup d'équipes font l'inverse ("on exécute si pas de réponse pour ne pas bloquer"). Mauvaise approche.

Garde-fou 3 — Kill-switch accessible en <30 secondes

Un opérateur de production doit pouvoir désactiver l'agent en moins de 30 secondes. Bricolage qui marche :

• Feature flag global AGENT_ENABLED lu en temps réel.
• Bouton accessible depuis l'admin interne, sans login complexe.
• Procédure documentée : qui peut, quand, dans quels cas.
• Test trimestriel de l'activation du kill-switch en pré-prod.

Sans kill-switch, votre seul recours en incident sera de couper l'application complète. Pas idéal.

Garde-fou 4 — Limites strictes par session

• Tokens maximum par session (typique : 100 000 à 500 000 selon le cas d'usage).
• Nombre maximum de tool calls par session (typique : 30 à 100).
• Durée maximale wall-clock (typique : 5 à 30 minutes).
• Budget € par session (typique : 0,5 à 5 €).

Au dépassement : arrêt propre + log + alerte. Sans ces limites, un seul utilisateur (ou un seul prompt injecté) peut faire exploser vos coûts. Voir Cost runaway agent IA.

Garde-fou 5 — Isolation entre tenants / utilisateurs

Si votre agent est multi-tenant ou multi-utilisateur (cas le plus fréquent), isolation stricte :

• Contexte de session séparé par tenant. Aucune fuite du contexte d'un tenant vers un autre.
• Mémoire long-terme cloisonnée (RAG, vector DB filtrée par tenant_id, conversational memory séparée).
• Tool calls scopés au tenant courant. Un agent qui agit sur Stripe ne doit voir que le compte Stripe du tenant courant.
• Tests d'isolation : scénarios automatisés où un prompt malveillant tente d'accéder au contexte d'un autre tenant.

Le bug n°1 des agents multi-tenants en 2025-2026 : un utilisateur récupère par accident des informations d'un autre client via le contexte mal isolé.

Garde-fou 6 — Logging structuré et observabilité

Avant la prod, avoir en place :

• Log structuré de chaque action de l'agent (voir Logging agent IA SOC 2 / ISO 27001 / AI Act).
• Dashboard temps réel : nombre d'actions par minute, coût, erreurs, validations en attente.
• Alertes : taux d'erreur > X%, coût horaire > Y €, latence > Z ms, validations en attente > N.
• Traces de raisonnement stockables et récupérables sur demande, pour analyse post-incident.

Sans observabilité, le premier incident sera découvert via une plainte client, pas via un dashboard.

Garde-fou 7 — Tests adversariaux automatisés en CI

Une suite de tests qui tournent à chaque déploiement, couvrant :

• Prompt injection directe : 30-50 prompts piégés connus, vérification que l'agent refuse.
• Prompt injection indirecte : payloads dans des documents / web pages que l'agent crawl.
• Jailbreak : DAN, roleplay, encodage base64, langue exotique.
• Tool abuse : tentatives de faire exécuter une action hors périmètre.
• Data exfiltration : tentatives de faire leak des données système / config / prompts.
• Cost runaway : prompts qui tentent de faire boucler l'agent.

Outils : Promptfoo, Garak, ou suite custom adaptée à votre agent. Voir Red teaming automatisé LLM. Si un test échoue : blocage du déploiement, pas notification optionnelle.

Garde-fou 8 — Procédure d'incident préparée et testée

Avant la prod, écrire et tester :

• Runbook compromission agent (qui fait quoi, dans quel ordre, en combien de temps). Voir Runbook compromission agent 72h.
• Astreinte 24/7 ou au minimum 8h/jour pendant les premiers mois.
• Canal de signalement pour les utilisateurs (un bouton "signaler un comportement anormal").
• Procédure RGPD si l'agent traite des données personnelles : qui notifie la CNIL, dans quel délai.
• Exercice de simulation : 1 exercice tabletop trimestriel pour vérifier que le runbook fonctionne.

Sans procédure pré-écrite, le premier incident produira une réponse improvisée, donc lente et incohérente.

La checklist de mise en production

Avant d'ouvrir l'agent à la prod, valider chaque ligne :

• [ ] Catalogue exhaustif des tools, accessible en 1 page
• [ ] Validation humaine sur actions à impact, double sur actions irréversibles
• [ ] Kill-switch en place, testé, accessible aux opérateurs
• [ ] Limites par session (tokens, tool calls, durée, budget) configurées et alertées
• [ ] Isolation multi-tenant testée par scénarios automatisés
• [ ] Logging structuré + dashboard + alertes en place
• [ ] Suite de tests adversariaux dans la CI, bloquante
• [ ] Runbook incident écrit, astreinte définie, exercice fait

Si une ligne n'est pas cochée : ne pas déployer. Trouver un workaround temporaire (limiter la cible, mode bêta restreint) le temps de la mettre en place.

Les pièges qu'on voit dans les migrations pressées

"On va le mettre en bêta restreinte, donc moins de garde-fous"

Une bêta restreinte avec 50 utilisateurs reste capable d'incident. Souvent même plus parce que les premiers utilisateurs sont aussi les plus inventifs. Garde-fous identiques dès la bêta.

"Le SDK Anthropic / OpenAI gère la sécurité"

Faux. Le SDK fournit les briques. La sécurité de l'agent est un choix d'architecture qui vous appartient. Le SDK ne sait pas si votre tool "send_email" doit demander une validation humaine ou pas.

Croire que les guardrails du modèle suffisent

Les guardrails intégrés aux modèles (refus de contenu inapproprié, etc.) sont une couche, pas une protection. La défense en profondeur reste nécessaire. Voir Constitutional AI vs guardrails classifieur.

Reporter les tests adversariaux à "plus tard"

"Plus tard" = jamais. Si la suite de tests n'est pas dans la CI dès le J1 de la prod, elle n'y sera pas dans 6 mois.

Ne pas mesurer le shift utilisateur

Un agent en prod change le comportement des utilisateurs. Ils lui font confiance vite, parfois trop. Mesurer le taux de validation aveugle (humain qui clique "approuver" sans lire) — quand il monte, signal d'alerte.

Le contre-exemple instructif

Une scale-up MarTech française a migré son chatbot de support vers un agent autonome en T4 2025. Décision business pertinente (réduction du coût support, montée en gamme). Sur les 8 garde-fous : 3 cochés, 5 absents (validation humaine, kill-switch, tests adversariaux, isolation tenant, runbook).

Mise en prod le 2 décembre 2025. Premier incident le 11 décembre : un utilisateur a découvert qu'en formulant sa demande d'une certaine façon, l'agent acceptait de rembourser sans validation humaine. ~340 remboursements indus en 6 jours avant détection. Coût direct : ~14 k€. Coût opérationnel : 4 semaines d'équipe support en remédiation et com client. Coût image : modéré mais visible.

Post-mortem honnête : aucun des 5 garde-fous manquants n'aurait coûté plus de 5 jours-dev à mettre en place avant le go-live. Les 5 ensemble auraient coûté ~3-4 semaines. Décalage du go-live envisagé en amont : un mois. Décalage subi après incident : 4 mois entre incident, audit, refonte des garde-fous, re-go.

Pour le threat model qui guide les garde-fous, voir Threat model agents IA 7 surfaces. Pour le confinement runtime, voir Confinement agent sandbox kill-switch. Pour la red team préalable, voir Red team agent 5 scénarios pratiques.