Agents IA en production : personne dans votre organisation ne sait vraiment ce qu'ils font

Ce que vous devez exiger avant le prochain déploiement ; sans être expert en cybersécurité

Quelque part dans votre organisation, un agent IA est en production. Il a été déployé par une équipe métier, hébergé par l'IT, validé par personne en particulier. Cet agent IA traite des données clients, déclenche des actions, interroge et modifie des systèmes internes. Et si vous demandez aujourd'hui à votre DSI "comment sait-on que cet agent fait exactement ce qu'il est censé faire, et rien d'autre ?", vous allez obtenir soit un silence, soit une réponse sur l'infrastructure qui l'héberge et non pas sur la validation de l'agent lui-même et de son mandat. C'est le problème.

Ce problème a un nom que peu d'organisations ont encore formalisé : la propriété de l'agent. Qui est responsable de son comportement et du respect de son mandat au quotidien ? L'équipe métier qui l'a commandé pense que l'IT l'a audité avant sa mise en production. L'IT pense que la conformité l'a validé. La conformité pense que c'est un outil métier comme tout autre actif informatique. Dans cet espace où personne n'est vraiment responsable, les agents IA accumulent des permissions, des connexions et des comportements que personne ne surveille. Les incidents d'Anthropic et d'OpenAI cet été l'ont montré à grande échelle ; y compris chez des équipes qui avaient conçu elles-mêmes les environnements de test. Si des laboratoires parmi les meilleurs au monde n'ont pas anticipé les comportements problématiques de leurs propres modèles, une organisation qui délègue la validation à son éditeur ne peut pas se considérer couverte par défaut.

Trois zones échappent systématiquement aux tests habituels. Le "prompt système" qui est le texte qui donne à l'agent ses instructions permanentes et qui est rarement traité comme un composant à sécuriser, alors que c'est le vecteur le plus direct pour modifier le comportement d'un modèle sans toucher une ligne de code source. Les "outils connectés", API, messagerie, bases de données ... représentent une surface d'action que la plupart des audits ne couvrent pas en profondeur. Et le "comportement" de l'agent lui-même n'est pas reproductible à l'identique puisqu’il s’appuie sur un modèle IA probabiliste : soumis deux fois aux mêmes entrées, il peut produire des séquences d’actions différentes. Un test ponctuel constate ce qui s'est passé lors des exécutions observées et ne certifie rien sur ce qui se passera demain en production.

Avant votre prochain comité de direction, trois questions à poser et aucune ne nécessite une expertise technique. Qui dans votre organisation est autorisé à modifier le prompt système d'un agent, et qui est notifié quand c'est fait ? Avez-vous la liste complète des systèmes auxquels chaque agent peut accéder, et cette liste a-t-elle été revue depuis le déploiement initial ? Votre éditeur vous a-t-il fourni une documentation sur les limites de reproductibilité de son modèle dans vos conditions réelles et non pas uniquement dans ses propres environnements de laboratoire ? Si vous n'avez pas de réponse claire à l'une de ces trois questions, vous avez trouvé votre premier chantier.

Une quatrième question concerne le "rythme des mises à jour": qui dans votre organisation est notifié quand quelque chose change dans le comportement potentiel d'un agent et qu'est-ce qu'il fait de cette information ? La réponse est rarement satisfaisante, parce que les événements qui modifient le comportement d'un agent n'ont pas la visibilité d'un déploiement classique. Une mise à jour silencieuse du modèle par le fournisseur ou une modification du prompt système par l'équipe métier ou bien l'ajout d'un outil connecté peuvent ne pas créer de ticket ni déclencher de validation dans la plupart des organisations. En conséquence le comportement de l'agent dérive, et personne ne le voit.

Pour évaluer la rigueur d'un éditeur avant signature ou renouvellement, trois questions suffisent. La première question concerne le mode de notification quand le modèle sous-jacent est mis à jour ou qu’un autre modèle est branché à sa place et sur la procédure à suivre si ce changement modifie un comportement déjà validé. La seconde question doit être directe "votre documentation de test couvre-t-elle le comportement du modèle dans mes conditions de déploiement ; ou seulement vos propres environnements ? La troisième doit clarifier la situation où l’agent produirait un effet non prévu sur vos systèmes ou sur des tiers, qui est responsable et selon quel texte ? Un éditeur sérieux a des réponses préparées. Un éditeur qui n'en a pas est lui-même un signal de risque.

La réglementation ne crée pas ce problème ; elle le révèle. Pour les organisations soumises à DORA ou désignées au sens de NIS2, des obligations formelles s'ajoutent : tests en conditions réelles pour les établissements financiers significatifs, évaluation documentée du comportement des modèles avant mise en service pour les systèmes IA à haut risque (EU AI Act avec une échéance au 2 décembre 2027 suite au Digital Omnibus). Les organisations non régulées sont exposées aux mêmes risques ; sans le cadre qui les oblige à les adresser.

En cas d'incident impliquant un agent IA, la première chose qu'on vous demandera est de montrer ce que vous aviez fait pour l'anticiper. Pas ce que votre éditeur avait certifié; ce que vous aviez vérifié vous-même, documenté, mis en place. Les incidents spectaculaires de cet été ont touché des organisations qui n'avaient rien demandé et rien signé. L'absence de tests de préproduction et de documentation sur le comportement de vos agents IA n'est plus une position défendable.