Gartner vient de dire tout haut ce que nous pensions sur la gouvernance de l’IA

Je lis les rapports Gartner depuis plus longtemps que je ne voudrais l’admettre. La plupart confirment ce que les professionnels soupçonnent déjà. Certains remettent en question des idées reçues. Et parfois, un rapport vous fait vraiment réfléchir : enfin, quelqu’un ose le dire.

Le rapport de décembre 2025 d’Avivah Litan, Max Goss et Lauren Kornutick, « Enterprises Should Augment Microsoft Purview and Agent 365 With Independent AI TRiSM Controls », fait partie de cette catégorie.

Le titre à lui seul est remarquable. Gartner ne dit pas que les nouvelles fonctions de gouvernance des données IA de Microsoft sont mauvaises. Il affirme qu’elles sont insuffisantes. Et l’explication est très directe.

Le problème du verrouillage dont personne ne veut parler

Voici le point clé concernant l’approche de Microsoft en matière de gouvernance IA : elle fonctionne très bien si vous restez entièrement dans l’écosystème Microsoft. Entra Agent ID, les nouveaux agents IA Purview, le tableau de bord de sécurité, ce sont de vraies avancées. Je le pense sincèrement.

Mais Gartner souligne un point qui devrait sembler évident, mais qui ne l’est apparemment pas : les fonctions d’audit et de protection les plus poussées exigent que les agents soient enregistrés dans Entra ID. S’ils ne le sont pas ? Au mieux, vous bénéficiez d’une visibilité basique. Et l’enregistrement est basé sur le volontariat. Sans contrôles d’accès adaptés, vous avancez à l’aveugle.

Réfléchissez-y une seconde. Votre stratégie de protection des données IA dépend du fait que les agents IA s’enregistrent d’eux-mêmes, de façon volontaire.

Le rapport indique aussi qu’au moins 50 % des organisations conservent des licences E3 pour de nombreux employés, alors que les fonctions avancées de Purview ont historiquement nécessité une licence E5. Même dans l’écosystème Microsoft, il existe donc un écart de gouvernance selon le niveau de licence. C’est… problématique.

En fait, je vais nuancer. Ce n’est pas juste problématique, cela crée deux niveaux de sécurité au sein d’une même organisation. Certains utilisateurs bénéficient d’une IA gouvernée ; d’autres non. Respecter les exigences de conformité réglementaire devient quasiment impossible dans ces conditions. Ce n’est pas un modèle viable.

« Les garanties des fournisseurs s’arrêtent à leurs propres frontières »

C’est probablement la phrase la plus importante du rapport. Gartner affirme clairement qu’aucun fournisseur cloud ne peut appliquer un contrôle d’exécution sur les agents IA dès qu’ils fonctionnent dans l’environnement d’un autre fournisseur. Microsoft ne peut pas gouverner ce qui se passe sur AWS. AWS ne peut pas gouverner ce qui se passe sur Azure. Personne ne gouverne ce qui se passe sur site, sauf si vous y déployez une solution dédiée.

Je répète ce constat depuis des années à propos de la gouvernance et de la souveraineté des données, donc c’est rassurant de voir Gartner appliquer la même logique aux agents IA. Mais il est aussi inquiétant de constater que peu d’organisations semblent faire le lien.

Quand vos données sensibles quittent l’environnement Microsoft — et cela arrivera, car c’est ainsi que fonctionne le business — les contrôles Purview ne suivent pas. Vos labels de sensibilité MIP ? Ce sont des métadonnées. Des instructions. Mais sans un mécanisme pour les appliquer à destination, sans contrôle DRM adapté, ce ne sont que… des étiquettes.

Le concept d’agent gardien

Gartner présente l’idée d’« agents gardiens indépendants » capables de superviser les agents IA sur toutes les plateformes et clouds. Ils illustrent même ce concept par un schéma montrant ces agents gardiens au-dessus des frameworks d’agents propres à chaque plateforme, assurant une supervision à l’échelle de l’entreprise.

Ce qui me frappe dans cette approche, c’est à quel point elle ressemble à ce que nous construisons avec le concept de Réseau de données privé. Pas parce que nous pensions spécifiquement aux agents IA — ce n’était pas le cas au départ — mais parce que le problème de fond est le même : comment gouverner des données sensibles lorsqu’elles circulent dans des systèmes que vous ne contrôlez pas ?

Notre réponse : créer une couche d’application indépendante. Ne comptez pas sur la plateforme source pour gouverner les données. Ne comptez pas sur la plateforme de destination. Placez la gouvernance au centre, là où vous pouvez appliquer des règles cohérentes, quelle que soit la provenance ou la destination. Cette approche de sécurité zéro trust garantit que la protection accompagne les données.

En y réfléchissant, c’est exactement ce que Gartner décrit pour la gouvernance IA. Ils emploient simplement un autre vocabulaire.

Ce qui compte vraiment pour la gouvernance des agents IA

Je vais préciser ce dont les organisations ont besoin, selon ce rapport et d’après nos échanges avec des RSSI cette année. La visibilité offerte par notre tableau de bord RSSI reflète ces mêmes priorités.

D’abord, il faut une authentification et une gestion d’identité inter-plateformes. Nous avons conçu notre serveur MCP avec OAuth 2.0 précisément parce que les agents IA qui accèdent aux données de l’entreprise ont besoin d’une vérification IAM adaptée et de l’authentification multifactorielle. À chaque accès. Sans exception. Et ces identifiants ne doivent jamais — j’insiste — jamais être exposés au contexte LLM. Les attaques par injection de prompt sont bien réelles, et elles vont se complexifier.

Ensuite, il faut une application des règles en temps réel, pas seulement à la configuration. Définir une règle et espérer qu’elle tienne ne suffit pas. Chaque accès doit être évalué selon les conditions du moment : qui est l’utilisateur, où se trouve-t-il, quelle est la sensibilité des données, quelle action tente-t-il ? C’est le principe de l’ABAC (contrôle d’accès basé sur les attributs), et cela doit se faire en temps réel. Le RBAC seul n’offre pas ce niveau de granularité.

Enfin — et c’est un point qui me tient à cœur — il faut des journaux d’audit qui capturent vraiment tout. Une traçabilité complète est indispensable. Le rapport mentionne que Microsoft 365 peut retarder l’enregistrement des logs jusqu’à 72 heures et limiter la journalisation en période de forte activité. Or c’est précisément à ces moments-là qu’il faut une traçabilité totale. Les attaques génèrent des pics d’activité. Si la journalisation est limitée lors de ces pics, vous perdez la visibilité quand elle est la plus cruciale.

La réalité de la menace interne

Gartner accorde une place importante aux menaces internes, soulignant que des utilisateurs sophistiqués peuvent toujours exfiltrer des données via des agents IA malveillants en mettant en pause le client GSA, en utilisant des appareils non gérés ou en exécutant des agents non enregistrés. D’où l’importance d’une capacité de réponse aux incidents solide.

Ce constat fait écho à ce que nous disent nos clients. Les menaces externes attirent toute l’attention, mais le risque interne — qu’il soit malveillant ou accidentel — représente une exposition majeure souvent sous-estimée. Une stratégie DLP efficace doit prendre en compte les deux. Et les agents IA ouvrent de nouveaux vecteurs. Un collaborateur qui hésiterait à s’envoyer un document sensible par e-mail n’hésitera pas forcément à demander à un assistant IA « d’analyser » ce même document et d’exporter les résultats.

Notre approche consiste à partir du principe qu’une faille est possible et à concevoir en conséquence. SafeVIEW permet de visualiser les données sans les posséder : le fichier n’est jamais téléchargé, l’utilisateur voit un flux d’images filigranées. SafeEDIT fonctionne de façon similaire pour l’édition : le document reste sur nos serveurs, l’utilisateur édite via une vidéo en streaming d’un bureau virtuel. Cette édition sans possession garantit que même en cas de compromission, les données ne quittent pas l’environnement contrôlé.

Est-ce une friction ? Oui. Mais c’est une friction adaptée aux données sensibles. Une classification pertinente des données, combinée au moteur de règles Data Policy Engine, permet de décider dynamiquement quand appliquer cette friction selon la donnée, l’utilisateur et le contexte.

Ne pas être Microsoft

Je veux être clair sur un point : je ne suis pas anti-Microsoft. Nous intégrons largement Microsoft. Nos clients utilisent SharePoint, OneDrive et Outlook via notre plugin Microsoft Office 365. Nous propageons les labels de sensibilité MIP et appliquons les règles associées.

Mais Gartner a raison : dépendre uniquement de Microsoft pour la gouvernance crée des difficultés en matière de gestion des risques de sécurité. Non pas parce que Microsoft fait mal les choses, mais parce qu’aucun fournisseur ne peut tout gouverner. Le rapport le dit très bien : « Seule une couche d’agents gardiens neutres et de confiance pourrait imposer un enregistrement universel et une gestion des flux pour combler une faille qu’aucun fournisseur ne peut résoudre seul. »

C’est ce que nous cherchons à être. Pas un remplacement des fonctions de gouvernance Microsoft, mais un complément. Une couche qui étend ces fonctions au-delà du périmètre du tenant, vers la collaboration externe via le partage sécurisé de fichiers Kiteworks, vers les systèmes IA tiers grâce à notre passerelle de données IA, dans la réalité complexe du fonctionnement des organisations.

Ce qui reste incertain

Je n’ai pas toutes les réponses. La gouvernance des risques IA évolue vite, plus vite que ce que nous pouvons suivre. Les fonctions en préversion de Microsoft seront un jour disponibles en GA. D’autres plateformes développeront leurs propres approches. Le Model Context Protocol implémenté par notre serveur MCP vient d’Anthropic, et nous misons sur sa standardisation, mais je peux me tromper.

Ce dont je suis certain, c’est du principe d’architecture : des couches de gouvernance indépendantes qui ne dépendent d’aucun fournisseur unique pour l’application des règles. Une vraie approche zéro trust me semble adaptée, peu importe l’évolution des technologies.

Et je suis convaincu que les organisations qui prennent la gouvernance IA et la conformité des données au sérieux dès maintenant — avant qu’une faille ne les y oblige — seront bien mieux préparées que celles qui attendent que les fournisseurs règlent le problème à leur place.

Le dialogue avec les analystes

À ce propos, si vous lisez ceci et que vous avez accès à ces analystes Gartner, je vous encourage à échanger avec eux sur ce sujet. Avivah Litan, en particulier, réfléchit depuis longtemps aux risques IA et à la TPRM, et le cadre TRiSM est une vraie avancée. Nous prévoyons de présenter notre approche aux trois analystes, et je pense que ces échanges influenceront notre feuille de route d’une façon que je ne peux pas encore anticiper.

C’est ainsi que cela doit fonctionner, selon moi. Les fournisseurs qui ne parlent aux analystes que pour obtenir de la visibilité passent à côté de l’essentiel. La vraie valeur réside dans le dialogue.

Et pour en savoir plus sur la façon dont Kiteworks répond à ces défis, contactez-nous ou réservez votre démo sans attendre !