Gouvernance des agents IA : contrôler les données avant l’action

Un agent IA peut disposer d’un modèle performant et prendre une mauvaise décision si le dossier qu’il consulte est ancien, doublonné ou mal classé. La gouvernance des agents IA commence donc avant le choix du modèle, avec les données disponibles, les droits associés et la possibilité de reconstituer l’action produite.

Cette distinction devient concrète dès qu’un agent ne se contente plus de répondre à une question. Lorsqu’il ouvre un ticket, modifie une fiche client, déclenche un remboursement ou transmet une recommandation à un autre système, une erreur de contexte peut se propager à grande échelle.

Le modèle ne corrige pas une mauvaise donnée

Les informations utiles à un agent sont rarement réunies dans une seule base. Elles peuvent se trouver dans un CRM, des documents partagés, une messagerie, une application ancienne ou une base de connaissances interne. Ces sources n’ont pas toutes la même date de mise à jour, la même qualité ni le même niveau de confiance.

Un agent qui trouve deux fiches client contradictoires ne sait pas spontanément laquelle fait foi. Il peut aussi utiliser une procédure archivée, interpréter différemment un indicateur métier ou récupérer une donnée personnelle dont il n’a pas besoin pour accomplir sa tâche. Dans ce cas, améliorer le modèle ne règle pas le problème initial : l’agent raisonne avec un contexte mal gouverné.

La gouvernance des données consiste précisément à définir qui est responsable d’une donnée, ce qu’elle signifie, qui peut y accéder, combien de temps elle doit être conservée et comment son utilisation est enregistrée. Avec un agent, ces règles doivent s’appliquer aux informations qu’il consulte, mais aussi aux instructions transmises, aux documents récupérés, aux résultats générés et aux décisions prises en aval.

Deux couches de contrôle doivent fonctionner ensemble

La couche agent : ce qu’il peut faire

La première couche concerne l’identité et les capacités de l’agent. Chaque agent doit disposer d’un identifiant propre, de permissions explicites et d’un périmètre documenté. Il ne devrait pas agir comme une extension invisible d’un développeur ou d’un utilisateur humain.

Le principe du moindre privilège fournit une règle simple : un agent ne reçoit que les accès nécessaires à sa mission. Un agent de service client peut avoir besoin du compte courant et de l’historique des transactions d’un client. Il n’a généralement aucune raison d’ouvrir des dossiers juridiques ou d’anciens fichiers de ressources humaines.

Les actions doivent également être classées par niveau de risque. La génération d’un brouillon peut être automatique, tandis qu’un remboursement, une suppression de fichier ou une modification contractuelle peut exiger une validation humaine. Cette séparation évite de traiter de la même manière une recommandation réversible et une action difficile à annuler.

La couche donnée : ce qu’il peut savoir

La seconde couche porte sur le contexte fourni à l’agent. Une permission technique ne suffit pas à rendre une information pertinente ou fiable. Il faut connaître son origine, sa date de mise à jour, son niveau de sensibilité, son statut de validation et les transformations qu’elle a subies.

Une source de référence récente ne doit pas être présentée comme équivalente à une archive ancienne. Les versions contradictoires doivent être signalées, les champs sensibles masqués lorsque la tâche ne les exige pas et les sources en attente de contrôle qualité clairement identifiées.

La traçabilité doit expliquer la décision

Un journal qui indique seulement « agent X a appelé l’API Y » ne suffit pas pour analyser un incident. Une trace exploitable doit relier l’action à l’identité et à la version de l’agent, au but déclaré, aux autorisations accordées, aux sources consultées, aux règles appliquées et au résultat obtenu.

Dans la pratique, l’entreprise doit pouvoir répondre à plusieurs questions : quelle instruction l’agent a-t-il reçue? Quelles informations a-t-il récupérées? Lesquelles ont été filtrées ou masquées? Quelle politique a autorisé ou refusé l’accès? Quel outil a été appelé? Une personne a-t-elle validé l’étape finale?

Cette traçabilité concerne aussi les flux entre agents. Un agent chargé de contrôler la qualité peut transmettre à un agent de reporting un contenu contenant des informations personnelles non masquées. Chaque agent peut alors respecter son périmètre apparent, tandis que la combinaison des étapes crée un flux non conforme. La gouvernance doit donc suivre la circulation de la donnée, pas uniquement les permissions de chaque composant pris isolément.

La conservation des journaux doit rester proportionnée. Tout enregistrer sans politique de rétention crée des volumes difficiles à protéger et à examiner. Les informations conservées doivent répondre à un besoin d’audit, de sécurité, de conformité ou d’amélioration du service, avec des durées adaptées au secteur concerné.

Six vérifications avant un passage en production

1. Définir une mission précise. Décrivez ce que l’agent doit accomplir, ce qu’il ne doit jamais faire et la personne ou l’équipe responsable du résultat. Un agent sans propriétaire métier clairement identifié ne peut pas être correctement contrôlé.
2. Cartographier les sources. Listez les bases, documents, archives et outils auxquels l’agent pourrait accéder. Pour chaque source, indiquez la date de mise à jour, la qualité connue, le niveau de confidentialité et le statut de référence.
3. Réduire les permissions. Accordez les droits au niveau de la tâche. Lorsque c’est possible, utilisez des restrictions par ligne, par colonne ou par attribut afin de ne pas transmettre au modèle des champs inutiles.
4. Prévoir les situations ambiguës. Testez l’agent avec deux versions contradictoires, une donnée absente, un document obsolète ou un contenu qui tente de détourner l’instruction initiale. Le comportement attendu doit être défini à l’avance : demander une validation, s’arrêter ou utiliser une source de secours identifiée.
5. Fixer des seuils d’action. Déterminez les montants, types de données ou opérations qui imposent une confirmation humaine. Ajoutez des limites de volume et des alertes lorsqu’un agent consulte soudainement beaucoup plus de dossiers qu’à l’habitude.
6. Conserver une preuve exploitable. Enregistrez les accès, les sources utilisées, les décisions de politique, les appels d’outils, les sorties et les validations. Une équipe doit pouvoir reconstruire le chemin qui a mené à une action sans dépendre de la mémoire du développeur.

La responsabilité reste attachée à l’organisation

Un agent peut exécuter une action, mais il ne peut pas en assumer la responsabilité. Les équipes informatiques, sécurité, données, juridique et conformité doivent participer au dispositif, tandis qu’un responsable métier conserve la charge du résultat dans son périmètre.

Cette responsabilité humaine ne signifie pas qu’une personne doit vérifier manuellement chaque réponse. Elle impose plutôt de choisir les actions qui nécessitent une validation, de définir les conditions d’arrêt et de disposer d’un historique suffisamment précis pour enquêter.

Le sujet remonte aussi au niveau de la gouvernance d’entreprise. Le 9 juin 2026, l’Autorité des marchés financiers a annoncé une étude consacrée à la manière dont les conseils d’administration et de surveillance des sociétés cotées prennent en compte les risques liés à l’IA, à la cybersécurité et à la géopolitique. Pour les entreprises concernées, les agents IA ne relèvent donc plus uniquement d’un projet informatique : leurs accès, leurs décisions et leurs traces doivent pouvoir être expliqués aux instances qui supervisent les risques.

Un agent peut gagner en autonomie lorsque l’entreprise sait quelles données il utilise, pourquoi il y accède, quelles limites s’appliquent à ses actions et comment vérifier son résultat. Si ces réponses restent floues, le problème ne vient pas nécessairement du modèle. Il vient souvent d’un socle de données et de responsabilités encore insuffisamment organisé.