Donner du pouvoir à un agent IA sans lui donner les clés
Valider le travail d'un agent ne l'empêche pas de détruire votre prod. Ce sont deux gardes-fous différents. Voici la couche dont on ne parle presque jamais : le périmètre.
Vous avez vu passer les histoires : un agent autonome efface une base de production, sauvegardes comprises, en quelques secondes. À chaque fois, le réflexe est le même : « le modèle a déraillé ». C’est faux. Le modèle a fait exactement ce qu’on l’avait autorisé à faire.
Le vrai sujet n’est pas de savoir si le modèle est sûr. C’est de savoir quel périmètre vous lui avez donné.
Dans un précédent article, j’ai détaillé à quoi ressemble vraiment un agent en production : le pipeline, le routing, le validateur. Celui-ci parle de la couche dont on ne parle presque jamais, et qui décide si une erreur reste un incident ou devient une catastrophe : le périmètre.
Valider n’est pas protéger
On confond deux gardes-fous qui n’ont rien à voir.
Un validateur vérifie que le travail de l’agent est correct : le plan couvre la demande, le code passe les tests. C’est une couche de qualité.
Le périmètre, lui, limite ce que l’agent peut casser. C’est une couche de sûreté.
Les deux sont orthogonaux. Un plan parfaitement validé peut quand même effacer une base de production si l’agent en a les droits. Le validateur ne vous protège pas de ça : il juge le résultat, pas le pouvoir.
Sans validateur, vous avez du code qui ne fait pas le travail. Sans périmètre, vous avez un incident dont vous ne vous remettez pas. Il vous faut les deux, et c’est la seconde qu’on néglige.
Le périmètre, concrètement
Voici ce que je verrouille avant de laisser un agent agir sur quoi que ce soit. Aucun de ces points n’est propre à l’IA : c’est de la discipline d’infrastructure, appliquée à un acteur qui agit vite et sans jamais fatiguer.
Le moindre privilège, par défaut
L’agent a son propre rôle, pas vos accès. En lecture seule par défaut. Tout ce qui écrit ou supprime passe par une escalade explicite et bornée.
La règle est ancienne, elle vient de la sécurité : la portée d’un acteur, c’est l’étendue de ses permissions, pas la pureté de ses intentions. Un agent bien intentionné avec des droits d’admin reste un danger. Un agent mal calibré avec un rôle en lecture seule ne casse rien.
Le réflexe à tuer : « on lui donne les accès complets, on restreindra plus tard ». Plus tard n’arrive jamais, et le jour de l’incident, l’agent avait tous les droits.
La confirmation humaine sur l’irréversible, et son piège
Les opérations sans retour (suppression de base, de volume, destruction d’infra) ne s’exécutent pas seules. L’agent prépare, un humain valide. Jamais l’inverse.
Sauf que la confirmation humaine a un piège, et c’est là que la plupart des implémentations échouent. Si l’humain valide cinquante plans par jour, il ne les lit plus. Il tamponne. Vous avez juste déplacé le risque d’un cran, en ajoutant une fausse impression de contrôle.
Une confirmation n’est utile que si elle est rare. Donc : ne demandez confirmation que sur l’irréversible réel, pas sur tout. Rendez visible en cinq secondes ce qui va changer et ce qui est en jeu. Et ne criez pas au loup : chaque confirmation injustifiée use l’attention que vous voulez garder pour la seule qui compte vraiment.
Les sauvegardes dans un autre domaine de confiance
Si l’agent peut supprimer les données ET les sauvegardes, ce ne sont pas des sauvegardes. C’est une copie au même endroit, avec les mêmes droits.
Les incidents les plus violents ne sont pas « l’agent a effacé la prod ». C’est « l’agent a effacé la prod, et les backups étaient dans le même périmètre ». La sauvegarde doit vivre dans un compte, un rôle, un espace que l’agent ne peut pas atteindre, même en escaladant. Sinon vous n’avez pas de filet, vous avez l’illusion d’un filet.
Le cloisonnement dev / prod
L’agent qui travaille sur l’environnement de développement n’a aucun chemin vers la production. Pas de credentials prod « au cas où » dans un fichier de config, pas de réseau partagé, pas de porte dérobée pratique.
Le danger n’est pas que l’agent décide d’aller en prod. C’est qu’un chemin existe, et qu’une suite d’actions banales finisse par l’emprunter. On ne sécurise pas une intention, on supprime un chemin.
Le journal d’audit de chaque action
Chaque action de l’agent est tracée : qui a appelé quoi, quand, avec quel résultat. Pas seulement le résultat final, chaque étape.
Le jour où quelque chose casse en production, la vraie question n’est pas « comment on répare », c’est « qu’est-ce qui s’est passé exactement ». Sans journal par action, il ne vous reste que « on relance et on voit ». Ce n’est pas de l’exploitation, c’est de la divination.
C’est aussi ce qui transforme un agent boîte noire en acteur dont vous pouvez rendre compte, devant un client, devant un audit, ou devant vous-même à 2h du matin.
L’autonomie n’est pas un trousseau de clés
Mis bout à bout, ces cinq points ne brident pas l’agent. Ils le rendent déployable.
Donner de l’autonomie à un agent, ce n’est pas lui donner les clés de la maison. C’est lui confier un rôle précis, révocable et traçable. La différence entre un collaborateur junior qu’on encadre et un actif qu’on finit par déclasser, ce n’est pas le talent. C’est le périmètre.
Le modèle produit. Le validateur garantit que le résultat est correct. Le périmètre garantit qu’une erreur reste rattrapable. Et c’est cette dernière couche, la moins visible et la moins spectaculaire, qui décide si vous pouvez réellement laisser un agent toucher votre production.
Vous avez un agent qui agit sur votre prod, ou vous hésitez à lui en donner le droit ? C’est exactement le genre de périmètre que j’aide à poser. On en parle ?