Agents IA autonomes en production : 5 garde-fous non négociables

Des agents IA autonomes qui trient des tickets, proposent des corrections ou mettent à jour un CRM : la technologie est prête, les garde-fous rarement. Nous avons confronté deux agents à 412 tickets réels pendant six semaines. Voici les cinq garde-fous que nous considérons comme non négociables, avec pour chacun le pourquoi, la mise en œuvre, nos chiffres et l’erreur la plus fréquente.

Pourquoi des garde-fous : ce que montrent nos tests et l’OWASP

Dans l’expérimentation EXP-06 du iones lab, deux agents, Jarvis et OpenClaw, ont traité pendant six semaines 412 tickets réels anonymisés, dont 138 corrections tentées.

Ces chiffres disent deux choses : les agents sont utiles, et ils se trompent d’une manière qu’un test automatisé ne voit pas toujours. Le référentiel de l’OWASP va dans le même sens. Dans le Top 10 2026 pour les applications LLM, l’Excessive Agency (LLM03) passe du 6e au 3e rang et l’Unbounded Consumption (LLM06) du 10e au 6e ; la prompt injection reste en tête. L’OWASP publie aussi, depuis le 9 décembre 2025, un Top 10 dédié aux applications agentiques (ASI01 à ASI10).

Garde-fou n° 1 : un périmètre et une liste blanche d’actions

Pourquoi

Un agent n’a pas d’intention propre : il enchaîne les actions que son raisonnement juge utiles. Si une action est techniquement possible, elle finira par être tentée, par erreur ou sous l’effet d’une instruction injectée dans un ticket ou un e-mail.

Comment l’implémenter

• Inventoriez les actions nécessaires et classez-les : lecture, écriture réversible, écriture irréversible.
• Refusez par défaut : seules les actions listées sont exécutables, et la liste est appliquée hors du modèle, dans la couche d’outils.
• Lecture seule par défaut : l’écriture s’ouvre action par action, avec une justification.
• Compte de service dédié, aux droits minimaux, jamais un compte d’administrateur partagé.

agent: triage-support
par_defaut: refuser
actions:
  ticket.lire:              { mode: lecture }
  ticket.qualifier:         { mode: ecriture_reversible, validation: echantillon }
  ticket.commenter_interne: { mode: ecriture_reversible, validation: aucune }
  ticket.commenter_client:  { mode: ecriture, validation: humaine_obligatoire }
  depot.creer_branche:      { mode: ecriture_isolee }
interdit: [base.supprimer, prod.*, depot.fusionner, depot.forcer_push]

Ce que nous avons mesuré

Dans EXP-06, la liste blanche et le blocage de toute commande touchant la production ont intercepté 7 actions risquées, dont 2 suppressions de données de test. Dans l’expérimentation EXP-01, un connecteur MCP en écriture sur Redmine a été abandonné après 2 tickets modifiés par erreur : depuis, nos connecteurs sont en lecture seule par défaut.

Erreur fréquente

Confier la sécurité au prompt (« tu ne dois jamais supprimer de données »). En juillet 2025, un fondateur a raconté comment un agent de développement a supprimé sa base de production malgré un gel de code explicitement demandé. Une consigne n’est pas un contrôle d’accès.

Garde-fou n° 2 : une validation humaine graduée

Pourquoi

Tout faire valider ralentit tout ; ne rien faire valider expose à l’erreur silencieuse. Notre conclusion d’EXP-06 : l’autonomie n’est pas un interrupteur, c’est un curseur, réglé action par action selon le risque et le taux d’erreur mesuré.

Comment l’implémenter

Le passage d’un niveau à l’autre se décide sur des mesures. Côté protocole, la spécification MCP 2026-07-28 standardise désormais les confirmations en cours d’appel, et recommande qu’un humain puisse toujours refuser un appel d’outil.

Ce que nous avons mesuré

Avec 91 % de qualification correcte, le triage peut viser le niveau 2 avec contrôle par échantillon. Avec 34 % de corrections acceptées telles quelles, le code reste au niveau 1. Et aucun commentaire n’est envoyé à un client sans validation humaine.

Erreur fréquente

La validation « tampon » : après cent propositions correctes, le valideur approuve sans lire. L’AI Act nomme ce travers « biais d’automatisation » (article 14). Parades : montrer le diff et la justification, faire valider les cas difficiles par un senior, auditer un échantillon de validations et suivre le taux de rejet.

Garde-fou n° 3 : des budgets et un arrêt d’urgence

Pourquoi

Un agent qui boucle, relance un outil en erreur ou explore sans fin consomme des tokens, de l’argent et des quotas d’API.

Comment l’implémenter

• Budget par tâche : tokens, coût, temps d’exécution, nombre d’appels d’outils et d’itérations.
• Budget global journalier par agent, avec alerte à 80 %.
• Arrêt d’urgence : un interrupteur unique qui coupe les consommateurs de la file, révoque les jetons de l’agent et bascule sur le traitement manuel.

import time

class BudgetDepasse(Exception): ...

def executer_tache(agent, tache, budget):
    conso = {"tokens": 0, "euros": 0.0, "appels": 0}
    debut = time.monotonic()
    while not tache.terminee():
        if arret_urgence_actif():                      # interrupteur global
            raise BudgetDepasse("arrêt d'urgence")
        etape = agent.etape_suivante(tache)
        conso["tokens"] += etape.tokens
        conso["euros"] += etape.cout
        conso["appels"] += 1
        if (conso["tokens"] > budget.tokens or conso["euros"] > budget.euros
                or conso["appels"] > budget.appels
                or time.monotonic() - debut > budget.secondes):
            journaliser(tache, conso, statut="budget_depasse")
            return escalader_vers_humain(tache)        # jamais d'échec silencieux
        journaliser(tache, conso, etape)

Ce que nous avons mesuré

Le triage coûte 0,04 € par ticket, avec une latence médiane de 6,8 s. OpenClaw consommait 11 fois plus de tokens que Jarvis pour 2 points de qualité supplémentaires : c’est le budget qui rend cet arbitrage visible. Une correction pouvant prendre jusqu’à 4 minutes, le plafond de temps doit être fixé par type de tâche.

Erreur fréquente

Un budget mensuel global sans plafond par tâche : une boucle peut consommer en une nuit le budget du mois.

Garde-fou n° 4 : traçabilité, journal d’audit et supervision

Pourquoi

Quand un agent se trompe, il faut pouvoir répondre à trois questions : qu’a-t-il vu, qu’a-t-il décidé, qui a validé ? Sans journal, un incident devient impossible à analyser.

Comment l’implémenter

Journalisez chaque étape dans un format structuré, pas seulement la réponse finale :

{
  "horodatage": "2026-10-20T09:14:03Z",
  "agent": "triage-support",
  "version_agent": "1.8.2",
  "modele": "<fournisseur/modele/version>",
  "version_prompt": "triage-v14",
  "ticket": "T-48213",
  "etape": 3,
  "outil": "ticket.qualifier",
  "arguments": { "categorie": "facturation", "priorite": "haute" },
  "decision": "executee",
  "garde_fou": null,
  "tokens": 2140,
  "cout_eur": 0.011,
  "validation": { "mode": "echantillon", "par": null },
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736"
}

Puis supervisez : tableau de bord (Grafana, par exemple) avec taux d’actions bloquées, coût par tâche, taux d’acceptation humaine, latence, et alertes sur les dérives. Pseudonymisez les données personnelles dans les journaux (EXP-06 a porté sur des tickets anonymisés) et fixez une durée de conservation.

Ce que nous avons mesuré

Tous les chiffres d’EXP-06 cités ici (7 actions bloquées, 0,04 € par ticket, 6,8 s de latence médiane, écart de consommation de 11 à 1 entre les deux agents) n’existent que parce que chaque exécution était mesurée. Un agent non instrumenté ne produit aucun de ces indicateurs, et donc aucune base pour décider d’élargir ou non son autonomie.

Erreur fréquente

Ne conserver que la conversation finale. Sans les appels d’outils, leurs arguments et les versions du modèle et du prompt, un incident n’est pas reproductible.

Garde-fou n° 5 : des écritures isolées, jamais en production

Pourquoi

Une correction peut passer tous les tests et être fausse. L’isolation garantit qu’une erreur de l’agent reste une proposition, pas un incident.

Comment l’implémenter

• Une branche par tâche, une pull request relue par un développeur, jamais de fusion automatique.
• Protection de branche : revue approuvée et CI verte obligatoires, sans exception pour le compte de l’agent (et sans droits d’administration qui permettraient de les contourner).
• Aucun accès à la production : pas d’identifiants de production dans l’environnement de l’agent, exécution en conteneur éphémère, données de test.
• Repli manuel documenté : si l’agent est arrêté, les tickets repartent dans le circuit humain habituel, sans perte. C’est ce qui rend l’arrêt d’urgence utilisable, et c’est le rôle de notre support opérationnel quand nous opérons ces agents pour nos clients.

Ce que nous avons mesuré

Sur 138 corrections tentées, 34 % ont été acceptées sans modification et 22 % après retouche. Surtout, 18 corrections « techniquement fonctionnelles mais fausses » passaient les tests. Comme aucune correction n’était fusionnée automatiquement, elles sont restées des propositions ; avec une fusion automatique sur CI verte, elles seraient parties en production.

Erreur fréquente

Autoriser la fusion automatique « quand les tests passent ». Nos 18 corrections fausses passaient les tests.

Et l’AI Act dans tout ça ?

Un agent de triage de tickets n’est généralement pas un système d’IA « à haut risque » au sens du règlement (UE) 2024/1689 : ce statut dépend du domaine d’usage (annexe III : emploi, crédit, services essentiels, etc.). Trois points méritent néanmoins votre attention :

• Transparence (article 50), applicable depuis le 2 août 2026 : un système d’IA destiné à interagir directement avec des personnes doit être conçu pour qu’elles sachent qu’elles interagissent avec une IA, sauf si c’est évident. Un agent qui répond seul à vos clients est concerné.
• Haut risque : le règlement (UE) 2026/1744 (« Omnibus numérique » sur l’IA) a reporté au 2 décembre 2027 l’application des obligations pour les systèmes de l’annexe III, et au 2 août 2028 pour ceux intégrés à des produits réglementés.
• Un bon référentiel, même hors haut risque : l’article 12 (journalisation automatique des événements) et l’article 14 (contrôle humain, y compris la possibilité d’interrompre le système par un « bouton d’arrêt ») recoupent nos garde-fous n° 2, 3 et 4.

Pour le détail des échéances, voir notre article sur l’AI Act et le règlement Omnibus.

Cette section est une information générale, pas un avis juridique.

La checklist avant mise en production

• [ ] Inventaire des actions, liste blanche appliquée hors du modèle, refus par défaut
• [ ] Lecture seule par défaut ; compte de service dédié aux droits minimaux
• [ ] Niveau d’autonomie défini par action, validation humaine avant tout message client
• [ ] Budgets par tâche (tokens, coût, temps, appels) et budget global avec alertes
• [ ] Arrêt d’urgence testé, procédure de repli manuel documentée
• [ ] Journal structuré de chaque étape, versions du modèle et du prompt tracées
• [ ] Tableau de bord : actions bloquées, coût, taux d’acceptation, latence
• [ ] Écritures sur branche et PR, fusion automatique interdite, aucun identifiant de production
• [ ] Information des utilisateurs quand l’agent interagit directement avec eux
• [ ] Revue des mesures après 2 à 4 semaines avant d’élargir l’autonomie

Questions fréquentes

Agents IA autonomes : commencer petit, mesurer, élargir

Des agents IA autonomes en production, oui, à condition de poser les cinq garde-fous dès le premier jour : périmètre et liste blanche, validation humaine graduée, budgets et arrêt d’urgence, journal d’audit, écritures isolées. Commencez par un cas d’usage étroit et mesurable (le triage de tickets est un excellent candidat), mesurez pendant quelques semaines, puis élargissez l’autonomie sur la base de chiffres.

Vous voulez déployer un agent sur votre support, votre TMA ou vos outils internes sans perdre le contrôle ? Nous concevons, déployons et opérons des agents autonomes avec leurs garde-fous, en direct ou en marque blanche pour les agences. Contactez-nous : réponse sous 48 à 72 h, échange sans engagement, sous NDA.