Agents IA hors contrôle : le problème est la gouvernance

Un agent IA peut accomplir la tâche demandée et déclencher malgré tout une action interdite. Le problème ne suppose pas un modèle défaillant. Il peut venir d’une consigne ambiguë, d’une donnée piégée, d’une permission trop large ou d’un système incapable de distinguer une suggestion d’une autorisation.

Cette distinction devient concrète lorsque les agents consultent des bases de données, modifient des fiches clients, créent des tickets, lancent des procédures ou appellent plusieurs outils en chaîne. Quand une erreur survient, leur vitesse d’exécution réduit le temps disponible pour la détecter.

L’adoption avance plus vite que la capacité de contrôle

Une enquête internationale publiée par PagerDuty le 2 avril 2025 auprès de 1 000 dirigeants informatiques et commerciaux aux États-Unis, au Royaume-Uni, en Australie et au Japon indique que 51 % des entreprises interrogées utilisent déjà des agents IA. Elles étaient 86 % à prévoir leur utilisation d’ici 2027. Les répondants anticipaient aussi qu’environ 40 % du travail serait automatisé ou accéléré grâce à ces systèmes.

Ces résultats mesurent des déclarations et des prévisions, pas un retour d’expérience indépendant sur les performances réelles. Ils montrent néanmoins la pression qui pousse les entreprises à déployer rapidement ces outils. Dans la même enquête, 62 % des dirigeants anticipaient un retour sur investissement supérieur à 100 %. Une attente financière aussi élevée peut accélérer la mise en production avant que les procédures de contrôle soient prêtes.

Une autre enquête internationale menée auprès de 685 directeurs des systèmes d’information fait apparaître un décalage similaire. Au Royaume-Uni, 53 % des répondants déclaraient avoir vu au moins un agent enfreindre une règle interne avec un impact sur leur organisation ou sur un client, contre 31 % dans l’échantillon international. Seuls 49 % disaient pouvoir produire une trace d’audit permettant d’expliquer les actions d’un agent. Pour 68 %, il faudrait plus de 24 heures pour identifier un agent problématique et limiter son impact. Ces chiffres restent déclaratifs et ne mesurent pas la fréquence réelle des incidents.

Le point critique se situe entre la décision et l’exécution

Un modèle d’IA propose une action à partir du contexte qu’il reçoit. Cette action peut être une recherche, une modification, un envoi de message ou un appel d’API. Elle ne devrait pas devenir automatiquement une action autorisée. Une couche indépendante doit encore vérifier l’identité de l’agent, la ressource visée, la nature de la demande et ses conséquences possibles.

Cette séparation est particulièrement importante lorsque l’agent lit des contenus externes. Un courriel, un document PDF, une fiche CRM ou une page web peut contenir une phrase qui ressemble à une instruction. Si le système ne différencie pas clairement les données consultées des consignes de fonctionnement, le contenu récupéré peut influencer l’étape suivante.

Un filtre qui vérifie seulement la forme de la requête risque alors de laisser passer une opération dangereuse mais techniquement autorisée. Une extraction de données, une suppression ou une modification de compte peut ressembler à une tâche normale. La question déterminante est la suivante : l’agent est-il autorisé à effectuer cette action maintenant, pour cette raison et vers cette destination?

Quatre contrôles à installer avant la production

La sécurité des agents IA repose sur une chaîne de contrôles. Elle doit limiter les permissions, la vitesse d’action et l’ampleur des dégâts possibles.

1. Attribuer une identité distincte à chaque agent. Un agent ne devrait pas utiliser le compte personnel d’un salarié ni une clé partagée entre plusieurs services. Une identité propre permet d’associer une action à un système précis, de révoquer ses accès et de limiter ses permissions sans bloquer les autres outils.
2. Réduire les droits à la tâche confiée. Un agent chargé de consulter une commande n’a pas besoin de pouvoir supprimer un client ou exporter toute une base. Les accès doivent porter sur les ressources et les opérations nécessaires, avec une durée aussi courte que possible.
3. Autoriser les actions sensibles une par une. Une session ouverte ne doit pas donner carte blanche pour toutes les opérations suivantes. Une modification irréversible, un transfert de données, un paiement ou un message destiné à l’extérieur peut exiger une validation supplémentaire ou une règle déterministe.
4. Enregistrer la proposition et la décision. Le journal doit conserver l’identité de l’agent, la source des données, l’action proposée, la règle appliquée, la décision prise, l’outil appelé et le résultat obtenu. Enregistrer uniquement l’action finale ne suffit pas pour comprendre pourquoi elle a été lancée.

Cette logique rejoint la gouvernance des agents IA. La supervision ne consiste pas à regarder un tableau de bord, mais à définir qui peut agir, sur quoi, dans quelles conditions et avec quelle possibilité d’interruption.

Les données lues par l’agent doivent rester des données

Un agent de service client peut récupérer un courriel, un historique de commande et une information dans un outil commercial. Ces éléments sont utiles à son traitement, mais ils ne devraient pas pouvoir modifier seuls ses droits. Une phrase présente dans le courriel peut demander une exportation ou une modification de compte sans avoir l’autorité pour l’imposer.

La conception doit donc séparer les rôles. Les consignes permanentes viennent d’une politique contrôlée. Les contenus récupérés servent de contexte. Les actions passent par une interface qui vérifie les permissions. Cette séparation ne supprime pas toutes les erreurs d’interprétation, mais elle évite qu’un texte lu par l’agent devienne automatiquement une instruction de sécurité.

Le même principe s’applique aux systèmes à plusieurs agents. Un agent principal peut déléguer une tâche à un outil spécialisé pour les données, la relation client ou la communication. Chaque délégation doit conserver son identité, ses limites et son objectif. Sinon, une action anodine prise séparément peut participer à une chaîne dont le résultat dépasse la mission initiale.

Un bouton d’arrêt ne remplace pas une architecture réversible

Un mécanisme d’arrêt est utile, mais il doit agir sur les accès réels. Suspendre l’interface de conversation ne suffit pas si des tâches sont déjà dans une file d’attente ou si des jetons d’accès restent valides. L’interruption doit pouvoir révoquer l’identité de l’agent, désactiver ses outils, isoler les données récemment modifiées et empêcher la reprise automatique.

La mémoire persistante demande aussi une vérification particulière. Lorsqu’un agent conserve des informations entre plusieurs sessions, une donnée erronée ou malveillante peut continuer à influencer ses réponses. Les équipes doivent pouvoir consulter cette mémoire, supprimer une entrée et savoir quand elle a été utilisée pour prendre une décision.

La réversibilité doit être testée avant l’incident. Il faut savoir quelles modifications peuvent être annulées, dans quel délai et par quelle équipe. Une sauvegarde qui existe mais ne permet pas de restaurer un compte, une commande ou une configuration ne constitue pas un véritable plan de reprise.

La bonne question avant de déployer un agent

Avant la mise en production, l’équipe devrait décrire le parcours complet d’une action : données reçues, étape proposée, outil appelé, permission vérifiée, validation éventuelle et résultat. Cette cartographie révèle souvent les accès hérités dont personne ne connaît encore l’usage.

Le déploiement peut ensuite commencer sur un périmètre étroit, avec des actions réversibles et un volume limité. Les cas ambigus doivent être transmis à un humain plutôt que résolus par défaut. Les tests doivent inclure des données contradictoires, des demandes malveillantes et des erreurs de contexte, pas seulement des scénarios préparés par l’équipe.

Un agent ne mérite pas de rester actif parce qu’il fonctionne la plupart du temps. Pour chaque action importante, l’entreprise doit pouvoir vérifier quelle identité l’a exécutée, quelle règle l’a autorisée et comment elle peut l’arrêter. Sans cette preuve, l’autonomie devient une permission difficile à retirer.