Votre agent IA n’a pas besoin d’être désactivé, il a besoin d’un arrêt d’urgence

Un développeur travaillant sur un mandat de fabrication industrielle a donné trop de privilèges à un outil de code agentique. L’outil devait corriger un bug précis. Il a modifié du code bien au-delà de ce qui était demandé, sur des parties du système que personne n’avait autorisées à toucher. Aucune donnée n’a été perdue, mais l’incident a suffi pour révéler un problème beaucoup plus large que ce cas précis : la plupart des équipes qui utilisent l’IA en production n’ont jamais formellement décidé jusqu’où elle avait le droit d’aller seule.

La distinction qui compte, et qui n’est presque jamais nommée

Il y a une différence fondamentale entre un agent qui agit de façon complètement autonome, sans jamais s’arrêter pour demander confirmation, et un agent qui exécute ses actions une à une en demandant une validation avant chaque étape risquée. Cette différence n’est pas un détail technique réservé aux équipes de développement. C’est une décision de gouvernance du risque, au même titre que décider qui a accès aux comptes bancaires de l’entreprise ou qui peut signer un contrat au nom de l’organisation.

Le problème, c’est que cette décision se prend rarement consciemment. Elle se prend par défaut, souvent en fonction de la configuration la plus pratique ou la plus rapide à mettre en place sur le moment, sans qu’un dirigeant ait explicitement évalué ce qui se passerait si l’outil se trompait à grande échelle plutôt qu’à petite échelle.

Pourquoi l’interdiction pure ne règle rien

La réaction la plus commune après un incident comme celui-ci est d’interdire l’usage de l’IA dans le contexte où l’erreur s’est produite. C’est une réaction compréhensible, et c’est aussi la mauvaise réponse. Interdire l’IA après un incident revient à interdire les voitures après un accident plutôt que d’exiger des ceintures de sécurité. Le problème n’était pas l’existence de l’outil. C’était l’absence de garde-fous proportionnés au risque réel de la tâche.

Une agence confrontée à ce type d’incident a choisi une voie différente : plutôt que d’interdire les outils d’IA en environnement client, elle a établi une règle interne précise interdisant l’utilisation non supervisée d’extensions d’IA en production, tout en continuant à encourager leur usage encadré ailleurs. La nuance semble subtile sur papier. Elle change complètement ce qui se passe la prochaine fois qu’un développeur configure un outil pour un mandat client.

À quoi ressemble un arrêt d’urgence, concrètement

Un arrêt d’urgence bien conçu n’est pas un simple bouton qu’on appuie après coup pour arrêter les dégâts. C’est un ensemble de mécanismes construits avant qu’un agent commence à agir : un environnement de test qui reflète fidèlement la production sans jamais y toucher directement, des permissions explicitement limitées à ce que la tâche exige (un agent chargé de corriger un texte n’a aucune raison d’avoir accès aux fichiers de configuration réseau), et un déploiement graduel où l’agent agit d’abord sur une portion limitée du système avant qu’on élargisse son accès une fois sa fiabilité démontrée sur ce périmètre restreint.

Le déploiement graduel est probablement le mécanisme le plus négligé des trois, parce qu’il ralentit la mise en place initiale d’un outil, ce qui semble aller à l’encontre de la promesse de vitesse que l’IA est censée apporter. C’est un mauvais calcul à court terme : les quelques heures gagnées en donnant un accès complet dès le premier jour coûtent infiniment plus cher le jour où cet accès complet permet à une erreur de se propager sans limite.

Ce qui distingue un bon garde-fou d’un mauvais

Un garde-fou efficace n’est pas une case à cocher générique du type « demander confirmation avant chaque action ». C’est une évaluation, tâche par tâche, du coût réel d’une erreur si elle se produisait sans supervision. Modifier un fichier de configuration interne n’a pas le même niveau de risque que modifier le code en production d’un système client qui gère des commandes en temps réel. Traiter les deux cas avec la même règle, qu’elle soit trop permissive ou trop restrictive, garantit soit des incidents évitables, soit une perte de tout l’avantage de vitesse que l’IA était censée apporter.

La bonne approche identifie les points de décision réellement irréversibles ou coûteux à corriger, ceux qui méritent une confirmation humaine explicite, et laisse l’agent agir librement partout où une erreur serait simplement annulable ou sans conséquence sérieuse. Ça exige un travail de cartographie que la plupart des équipes n’ont jamais fait, parce que ça semblait accessoire tant qu’aucun incident n’avait forcé la conversation.

Documenter la politique plutôt que la garder dans la tête d’une seule personne

Un garde-fou qui existe uniquement dans la tête du développeur qui l’a mis en place disparaît le jour où cette personne change de mandat ou quitte l’organisation. La politique doit être écrite, précise sur les niveaux de permission accordés par type de tâche, et accessible à quiconque configure un nouvel usage de l’IA, pas seulement à celui qui a géré l’incident initial. Une organisation qui a vécu un incident a maintenant un document de deux pages qui liste, par catégorie de tâche, le niveau d’autonomie accordé et la justification derrière ce choix. Ce document se révise à chaque nouveau cas d’usage, pas seulement après un nouvel incident.

Qui devrait posséder cette décision

Une question qui reste souvent sans réponse claire dans une organisation qui découvre ce problème est simple : qui, précisément, décide où placer la limite entre ce qu’un agent peut faire seul et ce qui exige une validation humaine ? Laisser cette décision au développeur qui configure l’outil au jour le jour semble pratique, mais ça revient à laisser une décision de gouvernance du risque à la personne la moins bien placée pour en évaluer les conséquences à l’échelle de toute l’organisation. La bonne réponse ressemble davantage à un comité restreint incluant la direction technique et la direction générale, qui révise ces limites à intervalles réguliers plutôt qu’une seule fois au moment de l’implémentation initiale, parce que le périmètre d’un outil évolue presque toujours plus vite que la politique qui était censée l’encadrer.

Ce que ça exige d’un dirigeant, concrètement

Un dirigeant qui approuve l’utilisation d’un outil d’IA agentique dans son organisation devrait pouvoir répondre à une question simple : si cet outil se trompait complètement, sans supervision, quel serait le pire scénario réaliste, et est-ce que ce scénario est acceptable ? Si la réponse n’est pas claire, ou si personne n’a jamais posé la question, c’est le signe que la décision de gouvernance n’a jamais vraiment été prise. Elle a simplement été laissée au hasard de la configuration technique par défaut.

Ce n’est pas une question qui se pose une seule fois. Elle se pose à chaque nouveau contexte d’utilisation, parce que le niveau de risque acceptable change selon ce que l’outil touche : un compte publicitaire de test n’a pas le même poids qu’un système de production chez un client.

Le risque n’est pas que l’IA agisse. C’est qu’elle agisse sans qu’on ait décidé jusqu’où.