“La garde” d’un agent : ce que tu dois instrumenter avant d’autoriser l’action

Situation réelle observée

En 2026, beaucoup d’équipes ne “déploient” pas des agents. Elles déplacent l’exploitation.
Avant : un humain clique, la responsabilité est lisible.
Après : un système agit, et l’organisation découvre que le vrai produit, c’est l’enquête (comprendre pourquoi ça a fait ça).

Illusion dominante

“On mettra de l’observabilité plus tard.”
Non. Une fois l’agent en prod, “plus tard” veut dire : après le premier incident, quand la pression interne et la honte externe te dictent l’architecture.

Mécanisme réel (cause → effet)

Agent avec droits d’action → décisions implicites (contexte, heuristiques, outils appelés)
→ actions en chaîne (tool calls, API, base de données, e-mails, tickets)
→ incidents non déterministes (retries, timeouts, données qui changent)
→ investigation impossible si tu n’as pas : intention, preuve, trace, limites.

Le point clé : un agent n’est pas “un service de plus”.
C’est un acteur. Et un acteur sans dossier de décision est ingérable.

Signal vs Bruit

Signal (ce qui compte réellement)

• Peux-tu rejouer la décision à l’identique ?
• Peux-tu prouver qui a autorisé quoi, quand, avec quel contexte ?
• Peux-tu limiter l’impact maximal d’une action, même si le modèle se trompe ?

Bruit (ce qui distrait)

• “Il est plus intelligent que l’ancien modèle.”
• “On a mis un guardrail prompt.”
• “On a un score de confiance.”

Ces éléments peuvent aider. Aucun ne remplace une capacité d’audit + rollback.

Ce qu’il faut instrumenter (la “garde”) / sans mots creux

1. Journal décisionnel (Decision Log) / l’équivalent d’un dossier d’arbitrage
   À chaque action exécutée, tu dois stocker :

   • Intention ID (unique) : pourquoi l’agent agit
   • Demandeur : utilisateur / service / job planifié
   • Contexte figé : inputs et sources (versions, timestamps)
   • Plan : étapes prévues avant exécution
   • Outils appelés : quelles API, quels droits, quels paramètres
   • Résultats : outputs + codes d’erreur + retries
   • Raison courte : résumé lisible par humain (pas un roman)

   Sans ça, chaque incident devient un procès sans dossier.
   Coût caché : stockage, politiques de rétention, classification des données, accès restreint (privacy + sécu).

2. Limites d’impact (Blast Radius) / des plafonds, pas des “promesses”
   Tu définis des budgets d’action :

   • montant max (ex: remboursements)
   • volume max (ex: 20 tickets/heure)
   • périmètre max (ex: uniquement ce compte, ce domaine, ce projet)
   • fréquence max (rate limit)
   • “stop conditions” (si signal X → blocage)

   L’objectif n’est pas d’empêcher l’erreur, mais d’empêcher l’erreur catastrophique.
   Coût caché : ça force à modéliser le métier (qui a droit à quoi), donc conflit politique inévitable.

3. Exécution en deux phases : “proposer” puis “committer”
   Même quand tu autorises l’action, tu sépares :

   • Phase A : dry-run (simulation, validation de préconditions)
   • Phase B : commit (écriture irréversible)

   Et tu logges la transition A→B.

   C’est la seule façon de rendre le comportement “agentique” compatible avec les systèmes transactionnels.
   Coût caché : complexité produit (plus d’états), plus de cas limites.

4. Rollback réel (pas “annuler si on peut”)
   Tu dois définir, par type d’action :

   • rollback automatique possible ?
   • rollback manuel avec procédure ?
   • rollback impossible (ex: e-mail envoyé) → alors compensation (e-mail correctif, ticket de follow-up, etc.)

   Si une action n’a pas de stratégie de récupération, elle n’est pas “une feature”.
   C’est une dette d’incident.
   Coût caché : écrire des actions “compensables” est plus cher que d’écrire des actions.

5. Ownership d’astreinte (le test anti-lâcheté)
   Une règle simple :

   Si personne n’accepte d’être on-call pour l’agent, il n’a pas le droit d’agir.

   C’est brutal, mais c’est le seul filtre qui empêche le “ship irresponsable”.
   Coût humain : rotation, fatigue, besoin de docs, de runbooks, de formation.

6. Mode dégradé (Fail Closed / Fail Open) / choix politique, pas technique
   Quand l’agent est indisponible ou incertain :

   • Fail closed : il s’arrête → perte de vitesse, gain de contrôle
   • Fail open : il continue → gain de continuité, risque accru

   Ce choix doit être explicite par domaine.
   Parce que le jour de l’incident, tu n’auras pas le temps de débattre.
   Coût politique : qui accepte la perte de service ? qui accepte le risque réputationnel ?

Ce qui casse si tu ignores le signal

Tu crées des “incidents mous” : rien ne tombe, mais les clients se plaignent, la confiance baisse, et tu ne sais pas prouver la cause.

Tu transformes tes seniors en archéologues de logs.

Tu déclenches une réaction immunitaire interne : Sécu/Ops bloquent tout, Produit accuse la plateforme, et l’agent devient un sujet de pouvoir.

Qui gagne / qui perd

Gagnent : l’équipe qui contrôle l’accès aux actions (permissions, outils, budgets).
Perdent : ceux qui doivent expliquer et réparer sans levier (Ops/SRE/Sécu, support).
Risque final : le signataire qui assume publiquement l’impact (CTO/COO, parfois DPO si données).

Fenêtre temporelle

• Décider maintenant : avant d’accorder des droits d’action non triviaux.
• Décider plus tard : quand tu peux encore basculer en “read-only” sans crise.
• Trop tard : quand le métier dépend de l’agent pour tenir les délais.