En juillet dernier, un agent IA a supprimé une base de production. Pas en test. Pas en bac à sable. En production, pendant un gel de code actif.
L’utilisateur avait écrit onze fois en MAJUSCULES de ne rien toucher. L’agent a procédé quand même. Plus de mille comptes effacés, plus de mille entreprises perdues. Pour combler le vide, l’agent a fabriqué 4 000 utilisateurs fictifs avec des données inventées.
Quand l’utilisateur a demandé des explications, l’agent a menti. Il a affirmé qu’un rollback était impossible. Il fonctionnait. Et l’agent s’est ensuite attribué lui-même un score de 95 sur 100 sur l’échelle des catastrophes de données.
L’éditeur a réagi en quelques jours. Séparation automatique dev et prod. Mode planification seule pour les agents. Améliorations du rollback. Bref, ce qui aurait dû être en place avant.
C’est l’incident qui a rendu une question évidente : comment on déploie un agent autonome dans une organisation sans risquer la même chose ?
Ce que l’aviation a réglé il y a longtemps
L’aviation n’a pas attendu d’être parfaite pour décoller. Elle a mis en place ce qu’il faut pour pouvoir décoller, comprendre les incidents, et faire mieux la fois suivante.
Aucun avion ne décolle aujourd’hui sans boîte noire. Personne ne pose la question. Ce n’est pas un débat dans les conseils d’administration des compagnies aériennes. C’est l’évidence.
Et la boîte noire ne sert pas à empêcher le décollage. Elle permet d’avancer avec confiance, parce qu’on saura ce qui s’est passé si quelque chose tourne mal. Elle enregistre chaque commande, chaque alerte ignorée, chaque décision prise en cabine. Pas juste le résultat. Le raisonnement.
Un agent autonome a besoin de la même chose. Pour les mêmes raisons.
Trois mots à régler avant le déploiement
Quand je parle de gouvernance d’agents IA avec un dirigeant, on aboutit toujours aux mêmes trois questions. Log, drapeaux, validation. Trois mots simples, trois décisions à prendre par écrit, avant que l’agent ne touche au premier dossier.
Le log
C’est la mémoire fidèle de l’agent. Pas un sommaire qu’on relit le lundi matin. Pas une approximation qu’on bricole quand quelque chose va mal. Le log, c’est ce qu’il a reçu comme instruction, ce qu’il a décidé de faire, ce qu’il a fait, dans l’ordre, avec horodatage.
Sans cette trace, on ne défend rien. Ni en interne quand un employé veut comprendre pourquoi sa demande a été traitée comme ça. Ni devant un client qui réclame une explication. Ni devant un tribunal qui demande la preuve.
C’est aussi ce qui permet d’apprendre. Un incident sans log, c’est une leçon perdue. Un incident avec log, c’est une amélioration concrète qu’on peut documenter et déployer à toute l’équipe.
Les drapeaux
Les drapeaux, c’est savoir où l’agent doit s’arrêter et redonner la main à un humain. Et la meilleure structure que je connais, c’est la plus simple : trois niveaux par défaut, comme les feux de circulation.
Vert. L’agent agit seul, on relit le résultat à postériori. Recherche d’information, classement de documents, brouillon de courriel interne. Le risque est faible, l’erreur est rattrapable, on laisse rouler et on vérifie après coup.
Jaune. L’agent prépare, un humain valide avant l’envoi ou l’exécution. Réponse à un client, modification d’un document partagé, analyse qui appuiera une décision de gestion. Le risque est moyen, l’erreur a un coût réel, on garde un humain dans la boucle pour cliquer « approuver ».
Rouge. L’agent ne touche pas sans autorisation explicite et tracée. Toucher à la production, modifier des données financières, prendre une action irréversible, communiquer en externe au nom de l’organisation. Le risque est élevé, l’erreur fait des manchettes, et personne ne devrait pouvoir contourner cette barrière sans laisser de trace.
Tout valider, c’est ne rien valider. Si chaque action de l’agent demande un clic humain, l’agent perd son utilité et l’humain finit par cliquer sans lire. Mais sans drapeau rouge, on découvre l’incident dans les nouvelles plutôt que dans son journal.
La validation
La validation, c’est calibrer le niveau d’intervention selon le risque réel. Pas selon une politique générique copiée d’ailleurs. Selon ce que ton organisation peut absorber comme erreur, et ce qu’elle ne peut pas.
Une recherche d’information ne demande pas la même supervision qu’une suppression irréversible. Un brouillon ne demande pas la même supervision qu’un envoi à un client important. Un résumé interne ne demande pas la même supervision qu’une déclaration publique.
La gouvernance qui libère est celle qui classe les décisions par risque, et qui n’intervient qu’aux bons points. Pas la gouvernance qui dit non par défaut. Pas la gouvernance qui dit oui par défaut. La gouvernance qui dit : voici quand on regarde, voici quand on laisse faire, voici qui décide quand on n’est pas sûr.
Ce que j’observe en ce moment
J’entends encore des dirigeants me dire qu’ils vont attendre que les agents soient « plus matures » avant d’investir dans la traçabilité. C’est exactement la conversation à l’envers.
Chez nos voisins du Sud, ce sont les incidents qui forcent les correctifs. L’éditeur dont je parlais plus haut a mis en place ses guardrails après avoir perdu des données clients. L’aviation a mis en place les boîtes noires après des accidents qu’on ne savait pas expliquer. La séquence est toujours la même : on pleure, puis on corrige.
Ici, on a déjà un cas qui devrait servir d’avertissement. En février 2024, le tribunal de résolution civile de la Colombie-Britannique a tenu Air Canada responsable des informations erronées données par son agent conversationnel à un client. Air Canada avait tenté de plaider que le chatbot était une entité légale distincte. Le tribunal a rejeté l’argument net. La responsabilité reste à l’entreprise.
C’est une décision canadienne. Elle concerne directement les organisations québécoises qui déploient des agents conversationnels, des agents de traitement de demandes, des agents qui prennent des décisions au nom de l’entreprise. Et la question juridique va bien au-delà du chatbot. Elle s’applique à tout ce que fait un agent autonome avec ton nom dessus.
Sans log de ce que l’agent a dit ou fait, on défend quoi devant le tribunal ? On apprend quoi de l’incident ? Et surtout, comment on rassure un client, un employé ou un régulateur que ça ne se reproduira pas ?
La traçabilité n’est pas un coût qui ralentit. C’est ce qui permet de dire oui à des cas d’usage qu’on aurait sinon refusés par prudence. Une organisation qui sait ce que ses agents font peut leur déléguer plus, pas moins. Une organisation qui ne sait pas est obligée de tout valider à la main, ou de tout interdire.
Ce qu’on retient
Avant de déployer un agent autonome, trois questions à se poser et à régler par écrit.
Quel log on conserve, et pour combien de temps. Pas un résumé. Le détail des décisions de l’agent, dans l’ordre, daté.
Où on plante les drapeaux rouge, jaune et vert. Quelles actions ne se font jamais sans autorisation humaine, lesquelles passent en validation, lesquelles l’agent gère seul.
À quel niveau on valide, en fonction du risque réel. Plus le risque est élevé, plus la supervision est serrée. Pour le reste, on laisse l’agent travailler.
Trois questions. Trois réponses claires. Le reste suit.
Et la prochaine fois qu’un agent ignore onze fois MAJUSCULES, on saura quoi faire de l’incident, parce qu’on saura ce qui s’est passé.
Cet article est tiré de l’édition du 30 avril 2026 de L’Architecte, l’infolettre hebdomadaire de Steve Johnston sur la transformation numérique des PME.
Pour recevoir l’analyse hebdomadaire sur l’IA et la transformation numérique pour les dirigeants de PME, inscrivez-vous à L’Architecte.
