Gouvernance des agents IA : les intégrer à la cartographie du SI
Un agent prépare des relances de factures, consulte les données clients dans l’ERP et envoie des emails depuis la messagerie de l’entreprise. Le service comptable connaît son fonctionnement. Mais qui sait quels accès il utilise, quelles informations il transmet à son modèle et si un autre outil couvre déjà le même besoin ?
La gouvernance des agents IA commence par cette visibilité : identifier chaque agent et le relier aux applications, aux données et aux activités sur lesquelles il agit. La cartographie du système d’information fournit un cadre pour réunir ces informations et les examiner avec les responsables concernés.
Le besoin est déjà tangible. Dans une enquête menée par la Cloud Security Alliance auprès de 418 professionnels de l’IT et de la sécurité, 82 % des répondants déclarent avoir découvert des agents IA auparavant inconnus dans leur organisation au cours de l’année écoulée. [1]
Où chercher les agents IA déjà présents dans votre SI ?
Un agent peut être activé dans un logiciel, construit par une équipe métier ou développé en interne. Son arrivée ne passe donc pas toujours par un projet identifié par la direction des systèmes d’information.
Dans cet article, nous nous intéressons aux agents et assistants fondés sur des modèles de langage, connectés aux outils de l’entreprise pour consulter des informations ou réaliser des actions. Un assistant utilisé sans connexion à ces outils peut aussi soulever des questions de confidentialité ; il se situe simplement hors du périmètre décrit ici.
Pour constituer un premier inventaire, plusieurs traces peuvent être rapprochées :
| Point de repérage | Ce qu’il faut rechercher |
|---|---|
| Fonctionnalités d’IA des logiciels | Les agents ou assistants effectivement activés, leurs utilisateurs et leurs accès. |
| Abonnements des équipes | Les usages de services comme ChatGPT, Claude ou Le Chat, et les applications qui leur sont connectées. |
| Comptes cloud et accès API | Les applications ou automatisations qui utilisent les modèles, leurs responsables et leur facturation. |
| Plateformes d’automatisation | Les workflows intégrant un modèle de langage dans n8n, Make ou Power Automate, et les actions qu’ils exécutent. |
| Serveurs MCP | Les outils et données exposés, ainsi que les assistants autorisés à les utiliser. |
| Développements internes | Les agents déployés, leur environnement d’exécution et l’équipe qui les maintient. |
Une clé d’API, un modèle ou un serveur MCP ne constitue pas à lui seul un agent. Ce sont des points d’entrée pour retrouver les usages. MCP, pour Model Context Protocol, permet notamment à une application d’IA d’accéder à des outils et à des ressources. [2]
L’inventaire consiste ensuite à remonter de ces traces vers un usage identifiable : quel agent, pour quelle tâche, sous la responsabilité de qui ?
Comment décrire un agent dans la cartographie ?
Un agent reprend plusieurs caractéristiques déjà suivies pour une application : un responsable, un cycle de vie, des dépendances et un coût. La cartographie doit aussi préciser son autonomie et les actions qu’il est autorisé à réaliser.
Le métamodèle définit les types d’objets, leurs propriétés et leurs relations dans le référentiel. Sept rubriques offrent une base pour y intégrer les agents :
| Rubrique | Informations à documenter |
|---|---|
| Agent | Finalité, environnement, statut (test, pilote, production, retiré) et niveau d’autonomie. |
| Modèle | Modèle ou modèles utilisés, fournisseur, version lorsqu’elle est connue et lieu de traitement. |
| Applications et accès | Applications appelées, connexion directe ou via MCP, compte utilisé, permissions et actions autorisées. |
| Données | Objets métier concernés, sensibilité et informations effectivement transmises aux services externes. |
| Activité métier | Processus ou capacité que l’agent assiste ou automatise. |
| Responsables | Référent métier, responsable technique et personne chargée de superviser l’usage. Une même personne peut remplir plusieurs rôles. |
| Contrat et coût | Service facturé, contrat ou abonnement, consommation attribuable et centre de coût. |
Illustration d’après l’interface Boldo · données fictives
Chaque fiche doit également porter une date de dernière vérification. Une information encore inconnue reste signalée comme telle, avec une personne chargée de la compléter.
La nature des relations rend la carte exploitable. « Consulte les factures », « prépare un email » et « envoie une relance sans validation » décrivent des possibilités différentes. Un simple lien « utilise la messagerie » ne permet pas de les distinguer.
Il faut aussi séparer les permissions accordées des actions effectivement réalisées. La cartographie décrit les accès et les dépendances documentés ; les journaux d’exécution permettent de vérifier l’activité réelle.
Exemple : un agent de relance des factures
La situation suivante est fictive.
Lors d’une revue des dépenses, une direction informatique repère une consommation de modèle de langage qu’aucun projet connu ne déclare. Elle remonte jusqu’au service comptable : l’équipe a créé un agent chargé de relancer les factures impayées.
1. Identifier son fonctionnement. L’agent consulte les factures et les coordonnées clients dans l’ERP, rédige les messages, puis les envoie par email sans validation humaine. La comptabilité pilote l’usage, mais aucun responsable technique n’a été désigné.
2. Documenter ses relations. L’équipe renseigne les applications appelées, le compte utilisé et ses permissions. L’examen du workflow confirme que les noms des clients, les montants et les dates d’échéance sont transmis à un service de modèle hébergé hors de l’Union européenne. Ces flux sont ajoutés à la carte.
3. Repérer un chevauchement. Une fois rattaché au processus de recouvrement, l’agent apparaît à côté d’un module du CRM utilisé par l’équipe commerciale. Ce voisinage appelle une vérification : les deux outils interviennent-ils sur les mêmes factures ? En comparant leurs règles, les équipes confirment que certains clients peuvent recevoir deux relances.
4. Décider des suites. Les responsables peuvent adapter l’agent, limiter les données transmises, ajouter une validation humaine ou coordonner son périmètre avec celui du CRM. Ils peuvent aussi privilégier le module existant et retirer l’agent. Le choix dépend du besoin métier, de la qualité du service et des contraintes de traitement des données.
5. Traduire la décision dans les outils. Si l’agent est conservé, ses accès et son fonctionnement sont ajustés, un responsable technique est désigné et la fiche est actualisée. S’il est retiré, son exécution est arrêtée et ses accès propres sont révoqués, en vérifiant les éventuelles dépendances partagées. Son historique reste disponible dans le référentiel.
Illustration d’après l’interface Boldo · situation et données fictives
La cartographie ne tranche pas. Elle réunit les informations nécessaires et indique à qui poser la question.
Quelles décisions la cartographie permet-elle de préparer ?
Examiner les accès et les dépendances
À partir d’une application, l’équipe peut retrouver les agents autorisés à y agir et vérifier si leurs permissions correspondent encore au besoin. À partir d’un service de modèle, elle peut identifier les usages et les processus concernés par un changement de fournisseur ou une interruption.
Ces analyses dépendent de la qualité des relations renseignées. Une connexion technique connue ne suffit pas à décrire toutes les données qui la traversent. Pour les usages sensibles, la carte doit être complétée par l’examen des configurations et des flux.
Préparer l’analyse de conformité
L’inventaire aide à identifier les systèmes à examiner au titre du règlement européen sur l’IA, en fonction de leur usage et du rôle de l’organisation. Un agent destiné à analyser ou filtrer des candidatures appelle notamment l’examen des dispositions relatives aux systèmes à haut risque dans l’emploi.
Le règlement (UE) 2026/1744 reporte au 2 décembre 2027 l’application des principales obligations relatives aux systèmes à haut risque de l’annexe III. D’autres dispositions du règlement sur l’IA s’appliquent déjà. [3]
Pour les entités financières soumises à DORA, les contrats de services informatiques concernés doivent être suivis dans le registre d’information prévu par le règlement. [4] Relier les agents à leurs services et contrats facilite ce travail de qualification. La cartographie fournit des éléments utiles ; la conformité nécessite aussi des contrôles et des procédures.
Comprendre les dépenses et les doublons
Relier un agent à son contrat, à sa consommation et à son activité métier permet d’examiner les dépenses avec l’équipe qui en bénéficie. Lorsqu’un abonnement ou un accès API est partagé, une règle d’attribution est nécessaire pour éviter de compter plusieurs fois le même coût.
La carte aide également à repérer des usages proches. Comme dans l’exemple des factures, leur rapprochement ouvre une discussion sur les périmètres et les résultats attendus. Deux outils associés au même processus ne sont pas automatiquement interchangeables.
Par où commencer ?
Choisissez un processus connu et quelques agents dont les usages peuvent être vérifiés avec les équipes. Donnez la priorité à ceux qui réalisent des actions sans validation ou manipulent des données sensibles.
Pour chacun, renseignez d’abord sa finalité, son responsable, les applications accessibles, les permissions, les données transmises et le modèle utilisé. Ce premier périmètre permet déjà de repérer les informations manquantes et de poser des questions concrètes.
Installez ensuite deux règles de cycle de vie :
- À la mise en production : la fiche est renseignée, les accès sont examinés et les responsabilités sont attribuées.
- Au retrait : l’exécution est arrêtée, les accès sont révoqués ou ajustés, et la fiche passe au statut « retiré » en conservant son historique.
Cette seconde règle mérite une attention particulière : seuls 21 % des répondants à l’enquête de la Cloud Security Alliance déclarent disposer d’un processus formel de mise hors service des agents. [1]
Intégrez la vérification de l’inventaire aux revues d’architecture existantes. Actualisez aussi les fiches lorsqu’un agent change de modèle, d’outils, de permissions ou de niveau d’autonomie : ces évolutions peuvent modifier son périmètre d’action entre deux revues.
Cartographier vos agents IA dans Boldo
Dans Boldo, le point de départ est le même que pour le reste du SI : décrire les actifs et leurs relations dans un référentiel commun. Pour les agents IA, le périmètre à construire rassemble leur finalité, leurs responsables, les applications utilisées, les données concernées et les processus soutenus.
Partez d’un cas concret, comme votre processus de recouvrement. La carte doit vous aider à retrouver les usages qui y contribuent, leurs dépendances et les informations à vérifier avant une décision.
Présentez-nous votre cas lors d’une démonstration pour définir comment intégrer vos agents à votre cartographie.
Sources
- Cloud Security Alliance, Autonomous but Not Controlled: AI Agent Incidents Now Common in Enterprises, 2026. Enquête réalisée en janvier 2026 auprès de 418 professionnels de l’IT et de la sécurité, commandée et financée par Token Security. Communiqué du 21 avril 2026.
- Model Context Protocol, Architecture overview.
- Union européenne, règlement (UE) 2026/1744 du 8 juillet 2026, notamment la modification de l’article 113 du règlement sur l’IA.
- Union européenne, règlement (UE) 2022/2554 (DORA), article 28, paragraphe 3.
