La faille de gouvernance de l’IA

L’hypothèse qui a cédé

L’infrastructure d’identité moderne force le respect. SAML, OIDC, SCIM, MFA, provisionnement à la volée. L’IT d’entreprise a passé vingt ans à bâtir un système qui sait qui est chaque collaborateur, ce à quoi il doit accéder, et quand lui couper les vivres.

Ce système repose sur une hypothèse centrale : les demandes d’accès viennent de personnes.

Un collaborateur s’authentifie en SSO. Votre IdP émet un jeton cadré sur ses groupes et ses rôles. À son départ, SCIM le déprovisionne automatiquement. À son changement de poste, ses appartenances de groupe se mettent à jour. Tout le système est fondé sur l’identité. Et c’est parce qu’il l’est qu’il fonctionne.

Cette hypothèse a cédé sans bruit ces deux dernières années. La plupart des organisations n’ont pas encore rattrapé le retard.

Comment les agents obtiennent un accès aujourd’hui

Les agents IA comme Claude, ChatGPT, Copilot ou Gemini font désormais du vrai travail dans de vraies organisations. Pas seulement répondre à des questions : lire des pipelines commerciaux, écrire des e-mails, interroger des bases de données, et poser des actes qui ont des conséquences.

Pour cela, ils ont besoin d’accéder à vos outils SaaS. Et la façon dont ils l’obtiennent aujourd’hui est simple : quelqu’un génère une clé d’API, la colle dans la configuration de l’agent, et l’agent se met à appeler des API.

C’est tout. Pas de SSO. Pas d’appartenance à un groupe. Pas de jeton de session rattaché à une identité. Un identifiant brut qui donne accès à tout ce que la portée de la clé permet, c’est-à-dire en général tout ce que le développeur qui l’a générée avait le droit de faire.

50+ outils SaaS par entreprise

41% des partants conservent un accès

0 contrôle sur les agents IA

Trois failles que l’outillage actuel ne comble pas

Faille 1 : pas d’identité

Quand Claude lit 500 opportunités du CRM, qui a fait cela ? Pas le développeur qui a généré la clé : il n’a peut-être rien fait ce jour-là. L’action apparaît dans les journaux de votre SaaS comme un appel d’API brut depuis un jeton. Ce jeton n’a ni nom, ni rôle, ni propriétaire dans votre IdP. Quand le développeur part, vous désactivez peut-être son compte SSO, mais la clé d’API qu’il a générée reste active et continue d’appeler des API.

Faille 2 : aucune application de la portée

Une clé d’API HubSpot générée par un directeur commercial donne en général les mêmes accès que ce directeur. Pas seulement read_deals, mais aussi write_deals, delete_contacts, export_all. Aucun « moindre privilège » ne s’applique aux agents par défaut. En pratique, les agents tournent surdotés en droits, non par conception mais parce que des portées serrées créent de la friction et que la valeur métier passe d’abord.

Faille 3 : aucune piste d’audit

Qu’a fait votre agent IA mardi dernier ? À moins que quelqu’un n’ait construit une couche d’instrumentation à part, vous n’en savez rien de précis. Vous avez des journaux d’accès dans vos outils SaaS, mais ils vous disent qu’un jeton a été utilisé : ni quel prompt a déclenché l’appel, ni ce que l’agent cherchait à accomplir, ni si l’appel était autorisé par une quelconque politique.

Comparez avec la façon dont un analyste humain fait le même travail :

Analyste humain

✓ Authentifié en SSO, identité vérifiée

✓ Basé sur le rôle : « sales-analyst » lit, n’écrit pas

✓ La session expire, l’accès suit le contrat de travail

✓ Déprovisionné en quelques secondes à son départ

✓ Chaque accès journalisé avec tout son contexte

Agent IA aujourd’hui

✗ Une clé d’API. Pas de SSO, absent de votre IdP.

✗ Hérite de tout ce que la clé permet

✗ La clé n’expire jamais, sauf rotation manuelle

✗ Survit au départ, sauf si la clé est retrouvée

✗ Jeton utilisé. Aucun prompt, aucun motif, aucune politique.

Le volet réglementaire est plus proche qu’il n’y paraît

Le règlement européen sur l’IA est pleinement entré en application en 2025. Ses exigences pour les systèmes d’IA à haut risque incluent des mesures de supervision humaine (article 14) et la journalisation automatique des événements (article 12). Le périmètre de ce qui compte comme « haut risque » est plus large que ne l’anticipent la plupart des directions juridiques, et l’application monte en puissance.

En parallèle, les auditeurs SOC 2 commencent à poser des questions précises sur la gouvernance de l’IA. La réponse habituelle est un document de politique vague assorti de bonnes intentions. Elle ne suffit plus. Un rapport de Type II est censé démontrer l’efficacité opérationnelle dans la durée. On ne démontre pas cela pour des contrôles qui n’existent pas.

Le principe de minimisation des données du RGPD (article 5) entre aussi en jeu. Si votre agent lit 10 000 fiches clients pour répondre à une question portant sur une seule opportunité, vous avez un problème de minimisation. Les architectures d’agents actuelles rendent la sur-extraction accidentelle facile, sans mécanisme pour restreindre l’accès au niveau de chaque appel d’outil.

À quoi ressemble vraiment la gouvernance des agents

La bonne nouvelle : nous savons résoudre cela sur le principe, parce que nous l’avons déjà résolu pour les humains.

Le bon modèle mental est simple. Les agents doivent être des identités de plein droit dans votre système de contrôle d’accès. Pas des comptes de service. Pas des clés d’API. Des identités dotées de :

Un identifiant d’agent enregistré, rattaché à une définition : qu’est-ce que cet agent, qui l’a construit, que doit-il faire
Un rôle issu du même cadre RBAC que celui de vos collaborateurs : « sales-analyst » lit les opportunités sans pouvoir écrire ; « hr-ops » accède aux données RH ; « finance-viewer » est en lecture seule partout
Un jeu de politiques déterminant quels appels d’outils sont autorisés, avec quels paramètres et à quelle cadence
Un journal d’audit inaltérable capturant chaque appel avec tout son contexte : identifiant de l’agent, outil appelé, paramètres, réponse et issue
Un coupe-circuit qui suspend un agent globalement, sur tous les outils qu’il touche, en quelques secondes, sans révoquer les identifiants sous-jacents

À quoi ce journal d’audit ressemble en pratique :

audit · journal inaltérable WORM

2026-06-03 14:02:11 clde_7fRxP2 ALLOW hubspot.read_deals (25 lignes, 41 ms · politique : ai.sales.read)

2026-06-03 14:02:41 clde_7fRxP2 DENY hubspot.export_contacts (violation de la politique données personnelles · export en masse hors du rôle)

2026-06-03 14:03:15 clde_7fRxP2 ALLOW notion.read_page (doc : « Revue du pipeline T2 », 1,2 ko)

2026-06-03 14:05:02 clde_9mWkQ1 DENY salesforce.delete_record (écritures désactivées pour ce rôle d’agent · coupe-circuit actif)

C’est le DENY de la ligne 2 qui compte le plus. La gouvernance ne consiste pas seulement à journaliser ce qui s’est passé. Elle consiste à empêcher les mauvaises choses de se produire.

L’opportunité MCP

Le Model Context Protocol (MCP), publié par Anthropic fin 2024, s’impose comme la façon standard de connecter les agents IA à des outils externes. Plutôt que de développer des intégrations sur mesure entre chaque agent et chaque outil SaaS, les agents appellent les outils via des serveurs MCP, un intermédiaire standardisé qui arbitre la connexion.

Cela crée un point de contrôle naturel. Un serveur MCP placé entre vos agents et vos outils SaaS peut :

Authentifier l’agent appelant et le rattacher à une identité et un rôle enregistrés
Confronter chaque appel d’outil à une politique avant de le transmettre au SaaS cible
Journaliser chaque appel avec tout son contexte : ce qui a été demandé, ce qui a été renvoyé, quelle politique s’est appliquée
Bloquer les appels qui violent la politique, sans que l’agent ait besoin d’en connaître la raison
Offrir un coupe-circuit global qui suspend un agent sur tous les outils simultanément

C’est l’équivalent de ce que fait un reverse proxy pour le trafic web, ou une passerelle d’API pour des services. La couche d’application existe naturellement. La question est de savoir quelles politiques vous y faites respecter.

La fenêtre, c’est maintenant

La plupart des organisations en sont encore, sur les agents IA, au stade « on verra la gouvernance plus tard ». C’est compréhensible. Les cas d’usage sont convaincants, l’outillage est neuf, et les implications de sécurité paraissent abstraites jusqu’à ce qu’elles ne le soient plus.

Les organisations qui bâtissent leur infrastructure de gouvernance maintenant, tant que les déploiements d’agents restent maîtrisables, se retrouveront dans une position très différente de celles qui devront greffer des contrôles sur un système devenu trop vaste pour être audité.

Le contrôle d’accès pour les humains a mis des décennies à devenir juste. La fenêtre pour le réussir du premier coup avec les agents, avant que le désordre ne devienne irréversible, se referme. Les cadres existent déjà. Le point de contrôle existe déjà. Ce qui manque, c’est la volonté de l’appliquer avant que quelque chose ne tourne mal.