Ce que AWS Reimagine révèle sur le fossé de gouvernance de l’IA en entreprise
Une entreprise a atteint un taux d’adoption de 88 % de ses outils d’IA, mais n’a obtenu un réel gain de performance que lors d’une session sur 5 000. Cette statistique, dissimulée dans le nouveau rapport Reimagine 2026 d’Amazon Web Services, en dit bien plus sur l’état de la gouvernance de l’IA en entreprise que n’importe quelle enquête sur l’adoption publiée cette année. L’utilisation est généralisée. La valeur vérifiable et gouvernée, quasi inexistante. Et l’écart entre les deux représente précisément la zone d’exposition à la sécurité et à la conformité pour la plupart des organisations aujourd’hui.
AWS a élaboré le rapport Reimagine 2026 à partir de neuf mois d’entretiens confidentiels, de novembre 2025 à juillet 2026, avec 154 dirigeants, principalement des membres de comités exécutifs responsables de programmes IA dans 23 secteurs et 27 pays, épaulés par des chercheurs seniors d’Amazon qui ont codé et vérifié les résultats. Il ne s’agit pas d’une enquête commerciale gonflée de taux d’adoption. C’est une analyse fine des failles de la gouvernance dès que des agents IA interviennent dans des processus métiers réels, et le constat rejoint une tendance que Kiteworks suit de près dans ses propres recherches. L’adoption va plus vite que les contrôles censés la réguler, et cet écart devient aujourd’hui autant un problème de gouvernance des données que de technologie.
Ce cadrage est essentiel pour le lecteur qui devra en assumer les conséquences en cas de problème. Un RSSI ou un responsable conformité ne vit pas l’IA fantôme comme une histoire de productivité. Il la vit comme une question impossible à éluder, posée par un régulateur ou un avocat adverse : qui a autorisé cet agent IA à accéder à ces données, étaient-elles chiffrées, tracées et contrôlées à ce moment-là ? Relues sous cet angle, les conclusions d’AWS décrivent un vide d’imputabilité que l’échange sécurisé de données Kiteworks vise à combler, car les régulateurs réglementent les données, pas les modèles, et un audit qui ne répond pas à cette question n’est pas une preuve.
Cet article revient sur les constats d’AWS, distingue les statistiques vérifiées des chiffres qui lui sont attribués à tort dans des reprises secondaires, et relie le déficit de gouvernance aux contrôles spécifiques, à l’application des droits à chaque requête, à l’isolation des identifiants et à la journalisation unifiée qui transforment la supervision du risque IA d’un simple document de politique en un dispositif vérifiable par un auditeur.
Résumé des points clés
1. L’adoption ne prouve pas la valeur gouvernée.
AWS a identifié une organisation avec 88 % d’adoption des outils IA, mais qui n’a généré de réels gains que lors d’une session sur 5 000, montrant que les métriques d’usage n’indiquent rien sur la sécurité, la fiabilité ou l’autorisation des résultats produits par l’IA.
2. Une gouvernance documentée de l’IA reste l’exception.
Une enquête complémentaire de Strand Partners auprès d’entreprises européennes, commandée par AWS, révèle que plus de la moitié des PME et grandes entreprises, ainsi que trois quarts des startups, utilisent désormais l’IA, mais seules 24 % disposent d’une approche responsable documentée et seulement 10 % d’une stratégie de gouvernance des données.
3. Des cycles d’approbation trop lents poussent l’usage de l’IA dans l’ombre.
Les personnes interrogées par AWS décrivent des processus de validation IT de six mois appliqués à des expérimentations IA qui évoluent en quelques jours, et constatent que lorsqu’une expérimentation de deux semaines nécessite un mois d’approbation, les équipes cessent de demander l’autorisation et préfèrent demander pardon, transformant la politique en moteur d’IA fantôme plutôt qu’en contrôle.
4. La gouvernance doit exister en dehors du système IA, pas à l’intérieur.
Les recommandations du rapport pour l’IA agentique préconisent des contrôles d’identité, d’accès et de chiffrement indépendants de l’agent, ainsi qu’une autonomie progressive accordée uniquement après fiabilité démontrée, une approche qu’AWS compare à une période d’essai pour une nouvelle recrue.
5. La solution passe par l’application des contrôles au niveau des données, pas par un nouveau document de politique.
Combler le déficit décrit par AWS nécessite des contrôles appliqués automatiquement dès qu’un agent IA demande l’accès à des données, ce que proposent précisément Kiteworks Compliant AI et le Kiteworks Secure MCP Server.
Dans les coulisses de la recherche AWS Reimagine 2026
L’équipe Reimagine, composée d’Executives in Residence d’AWS issus d’anciens dirigeants de haut niveau (notamment du Jet Propulsion Laboratory de la NASA), a mené neuf mois de recherche au lieu de se contenter d’une enquête. Entre novembre 2025 et juillet 2026, ils ont conduit 154 entretiens, dont 128 avec des cadres couvrant 23 secteurs et 27 pays, complétés par des dirigeants et chercheurs AWS ayant appliqué des méthodes d’analyse computationnelle pour coder les retranscriptions. AWS s’appuie aussi sur une étude interne des dynamiques d’adoption de l’IA auprès de plus de 35 000 praticiens dans 27 pays, afin de confronter les entretiens à un jeu de données bien plus large.
Cette méthodologie est importante car elle a permis d’obtenir ce que les enquêtes d’adoption capturent rarement : un récit cohérent, vu de l’intérieur de dizaines d’organisations, sur la façon dont se creuse l’écart entre usage et gouvernance de l’IA. Les chercheurs précisent qu’il ne s’agit ni d’un modèle de maturité ni d’un argumentaire commercial déguisé. Il s’agit d’un diagnostic : la plupart des organisations ont conçu leur gouvernance IA pour un monde où les projets technologiques avançaient au rythme du budget annuel, alors que l’IA ne respecte pas ce tempo.
Une précision s’impose, car une statistique largement relayée à propos de ce rapport est erronée. Certains articles secondaires attribuent à AWS Reimagine 2026 un chiffre de « 83 % d’adoption, 13 % de visibilité ». Ce chiffre n’apparaît ni dans le rapport AWS ni dans sa communication officielle. Il provient d’une enquête d’un autre fournisseur. Les chiffres vérifiés d’AWS et de Strand Partners ci-dessous sont ceux sur lesquels fonder un argumentaire de gouvernance.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
Quand 88 % d’adoption ne génèrent presque aucune valeur gouvernée
La preuve la plus flagrante que l’adoption n’est pas un indicateur de succès vient d’un cas mis en avant par AWS. Une entreprise affichait 88 % d’adoption des outils, soit presque tous les employés ayant utilisé le système IA au moins une fois, mais moins d’une session sur 5 000 produisait un résultat réellement supérieur à l’existant. L’adoption était généralisée. L’amélioration, quasi invisible statistiquement. AWS observe le même schéma dans l’ensemble des données : moins de 5 % des utilisateurs ayant rapidement acquis une certaine aisance avec l’IA atteignent un niveau d’usage avancé générant une valeur mesurable pour l’entreprise.
Ce constat doit amener les équipes sécurité ou conformité à revoir la lecture de leur tableau de bord d’adoption IA. Un taux élevé d’adoption signifie une forte exposition. Il ne dit rien sur la gouvernance de cette exposition, sur la pertinence des données consultées par l’agent, ni sur la capacité à reconstituer a posteriori ce qui s’est passé lors de chaque session. Un indicateur d’adoption sans journal d’accès associé n’est pas un indicateur de gouvernance, mais une surface de risque déguisée sous un nom rassurant.
C’est précisément l’angle mort que les programmes de gouvernance des données IA doivent traiter en priorité, avant d’investir dans de nouvelles capacités IA. La visibilité sur ce qu’un agent IA a consulté, et l’autorité sur ce qu’il est autorisé à consulter, doivent exister au moment même de la requête, pas dans un rapport généré des semaines plus tard à la demande.
Ce que révèle Strand Partners sur l’adoption sans gouvernance
Les entretiens menés par AWS sont confortés par une enquête complémentaire commandée à Strand Partners, « Unlocking Europe’s AI Potential in the Digital Decade 2025 », basée sur les données de milliers d’entreprises européennes. Les tendances observées recoupent presque parfaitement les entretiens. Plus de la moitié des PME et grandes entreprises, ainsi que trois quarts des startups, déclarent utiliser l’IA. Mais seules 24 % disposent d’une approche responsable documentée, et seulement 10 % d’une stratégie de gouvernance des données.
Sasha Rubel, Head of AI and Generative AI Policy pour AWS en EMEA, nuance la lecture de ces chiffres comme un simple échec : « Cela reflète la véritable difficulté de gouverner une technologie qui se réinvente chaque trimestre », explique-t-elle aux chercheurs Reimagine. L’argument est recevable, mais il ne change rien à l’exposition que révèlent ces chiffres. Une organisation qui utilise l’IA sans stratégie de gouvernance des données documentée n’a aucun fondement cohérent pour répondre à la question la plus élémentaire d’un régulateur : quelles données ce système a-t-il consultées, sous quelle autorité, et où sont allés les résultats ? Expliquer la difficulté à combler l’écart entre gouvernance et adoption ne prouve en rien que cet écart est acceptable.
Le versant positif mérite d’être souligné, car il renforce l’argument business en faveur de la gouvernance, au-delà de la conformité. Selon une étude de Bain & Company sur l’adoption responsable de l’IA, citée dans le rapport AWS, les organisations dotées d’une approche responsable efficace voient l’impact médian sur leurs profits grimper de 6 à 10 % grâce à l’IA, contre 3 à 5 % pour celles qui n’en ont pas. Une bonne gouvernance n’est pas une taxe sur la valeur de l’IA, mais un multiplicateur.
Pourquoi des cycles de validation de six mois ne peuvent pas gouverner une IA qui évolue en quelques jours
Le constat le plus précis – et le plus utile pour un responsable conformité – du rapport AWS concerne la conception des processus, plus que la technologie. Beaucoup d’organisations interrogées appliquent encore à l’IA la même rigueur d’approbation que pour les programmes IT classiques de six mois, avec comités de validation, politiques approuvées par le juridique, et validation humaine obligatoire des résultats. Ces processus fonctionnaient pour des projets de six mois. Ils ne fonctionnent plus quand la même idée peut être testée en quelques jours.
Tony Leopold, Chief Technology Officer de United Rentals, résume ce changement dans le rapport : ce qui coûtait des centaines de milliers de dollars et six mois de travail se fait désormais en quelques jours pour quelques centaines de dollars. Un processus de validation calé sur l’ancien rythme devient, selon AWS, « inadapté quand il faut six jours », car la gouvernance reste extérieure au système IA, ajoutée après coup au lieu d’être intégrée, et considère chaque cas d’usage comme risqué par défaut.
La conséquence est logique et AWS la nomme clairement. Si une expérimentation de deux semaines nécessite un mois de validation, les équipes cessent de demander l’autorisation et préfèrent demander pardon après coup. Dans cette situation, la politique ne réduit pas le risque, elle le déplace dans l’ombre, vers des outils non surveillés et des workflows non tracés que l’équipe sécurité ne découvre qu’une fois le problème survenu. Chris Sedore, Vice President of Information Services and Technology et Chief Information Officer de Boston University, estime que 40 à 50 % du personnel utilise l’IA au moins chaque semaine, « parfois via nos modèles et systèmes, parfois en mode furtif ». Un autre interviewé note que les DSI qui ont passé des années à gérer le shadow IT font désormais face à une IA fantôme dix fois plus massive.
L’IA fantôme est un symptôme de conception de la gouvernance, pas un problème d’utilisateur
On pourrait croire que ces constats sur l’IA fantôme relèvent d’un problème de discipline, d’employés qui ignorent les règles, et vouloir répondre par plus de formation et une application plus stricte des processus existants. L’analyse d’AWS va à l’encontre de cette lecture, et mérite d’être prise au sérieux. L’existence de l’IA fantôme ne prouve pas l’échec de la gouvernance en tant que concept, mais qu’elle a été conçue comme une contrainte excessive pour les utilisateurs, d’où la nécessité de repenser le design plutôt que de renforcer la sanction.
Ce diagnostic rejoint d’autres recherches menées indépendamment d’AWS. Le rapport 2026 AI-Ready Governance Survey de OneTrust, réalisé avec Sapio Research auprès de 1 200 décideurs dans huit pays, révèle que 87 % des organisations encouragent activement l’usage d’agents IA, mais seules 47 % disposent d’une gouvernance claire sur leur mode de fonctionnement. Deux études indépendantes, menées par des organismes différents et selon des méthodologies distinctes, convergent donc vers la même faille structurelle : la direction veut la productivité, mais la couche de contrôle n’a pas suivi.
Combler cet écart ne consiste pas à durcir la gouvernance, gestion des risques et conformité existante et à l’appliquer plus lentement à l’IA. Il s’agit de sortir la gouvernance du document validé par un comité pour l’intégrer dans un système qui applique la règle à chaque requête d’accès aux données par un agent IA – un contrôle d’une nature radicalement différente. Une politique qui stipule qu’un agent IA ne doit accéder qu’aux données pertinentes pour sa tâche est inapplicable si rien ne le vérifie au moment de la requête. Un contrôle d’accès basé sur les attributs qui évalue chaque requête selon le rôle de l’agent, la sensibilité du contenu et le contexte de la mission rend cette politique concrète, et non plus théorique.
Quatre principes du rapport pour gouverner l’IA agentique
AWS résume sa recherche en quatre principes pratiques pour la gouvernance de l’IA agentique, chacun correspondant à une faille de contrôle laissée ouverte par la plupart des organisations. Le premier : maîtriser les fondamentaux avant tout. Identité, accès et chiffrement restent les piliers qui empêchent les failles de sécurité de se propager à la vitesse de la machine, et les négliger sous prétexte que l’agent va trop vite est une erreur. Le deuxième : placer les limites de sécurité à l’extérieur de l’agent, car ce dernier peut mal interpréter ou contourner les règles intégrées à ses instructions – les vraies limites doivent donc résider dans une infrastructure hors de sa portée.
Le troisième principe considère l’autonomie comme un privilège à acquérir, non un droit par défaut. AWS est clair : commencez par une validation humaine, élargissez l’autonomie après fiabilité démontrée, et gardez la capacité de la restreindre à tout moment. « Traitez cela comme une période d’essai pour une nouvelle embauche », recommande le rapport, un parallèle qui parlera à tout responsable conformité habitué à gérer l’onboarding, la gestion des accès et les revues périodiques pour les employés humains, mais rarement pour une identité non humaine dotée des mêmes droits. Le quatrième principe préconise des tests continus plutôt qu’une validation unique, car les modèles évoluent, les prompts changent, et chaque modification peut introduire un risque non anticipé lors de la revue initiale.
Ensemble, ces quatre principes dessinent une approche que AWS appelle « gouvernance as code » : la politique traduite en mécanismes d’application opérant à la vitesse de la machine, pour que le jugement humain soit réservé aux exceptions réelles, et non à la validation répétitive de décisions à faible risque. C’est une architecture radicalement différente d’un comité de revue mensuel, et c’est ce que Kiteworks Compliant AI et le Secure MCP Server sont conçus pour offrir.
Combler le déficit de preuves pour les RSSI et responsables conformité
Toutes les conclusions du rapport AWS aboutissent à la même question que doit affronter un RSSI ou un responsable conformité sous pression : l’organisation peut-elle produire une preuve, non une simple assurance ou un document de politique, mais un enregistrement précis, horodaté, attribuable, de ce qui s’est passé lorsqu’un agent IA a accédé à des données sensibles ? Le rapport annuel Kiteworks Data Security and Compliance Risk : 2026 met en lumière une faille similaire côté application : 79 % des organisations n’ont déployé aucun « kill switch » automatisé pour leurs systèmes IA, ce qui signifie que la plupart sont incapables d’arrêter un agent IA en cours de tâche s’il commence à accéder à des données non autorisées. L’adoption qui dépasse la gouvernance et l’application qui dépasse la réponse aux incidents sont deux facettes du même problème.
Un tableau de bord RSSI qui centralise l’activité de chaque agent IA est un point de départ, mais la visibilité seule ne répond pas à la question d’imputabilité soulevée par AWS : qui est le responsable désigné si un agent IA cause un incident ? Un organigramme ne suffit pas. Il faut un système qui génère automatiquement la preuve. Le Control Plane de Kiteworks enregistre chaque interaction IA-contenu dans un journal d’audit unifié, ce qui signifie que la preuve exigée par un régulateur ou un avocat existe déjà, sans avoir à être reconstituée dans l’urgence. La recommandation AWS va dans ce sens : tenir un registre des agents avec un propriétaire humain désigné pour chaque agent en production, à condition que ce registre s’appuie sur des logs suffisamment précis pour prouver ce que l’agent a fait – une exigence au niveau des données, pas un simple exercice de tableur.
Comment Kiteworks Compliant AI et le Secure MCP Server comblent le déficit
Les contrôles précis mis en avant par AWS – des limites extérieures à l’agent, un accès qui évolue selon la fiabilité démontrée, une application continue plutôt qu’un contrôle unique – décrivent exactement ce que Kiteworks Compliant AI propose. Chaque requête d’un agent IA ou d’un grand modèle de langage est évaluée selon une politique basée sur le rôle et les attributs au moment même de la demande, et non a posteriori : c’est la concrétisation du principe « gouvernance en dehors de l’agent » recommandé par AWS.
Le Secure MCP Server applique cette logique à la catégorie de risques IA à la croissance la plus rapide : les agents connectés aux systèmes d’entreprise via le Model Context Protocol. Il stocke les jetons d’authentification OAuth dans le coffre-fort du système d’exploitation, sans les exposer dans les prompts, de sorte qu’un agent compromis ou mal paramétré ne puisse utiliser des identifiants volés pour accéder à des données au-delà de ses droits, et il journalise chaque interaction dans le même audit trail unifié couvrant la messagerie sécurisée, le transfert sécurisé de fichiers et le partage de fichiers Kiteworks. Ce duo – application du contrôle à la requête et traçabilité complète, exportable – transforme la recommandation AWS « gouvernance as code » en réalité vérifiable lors d’un audit.
Les organisations n’ont pas à choisir entre la rapidité promise par l’IA et la gouvernance exigée par les régulateurs. Le rapport AWS Reimagine 2026, fondé sur 154 entretiens de dirigeants et une enquête auprès de milliers d’entreprises européennes, démontre que la vitesse sans gouvernance aboutit à une adoption sans valeur vérifiable et à un problème d’IA fantôme pire que le précédent. Intégrer la gouvernance au niveau des données, plutôt que de la greffer sur le système IA après coup, permet de concilier les deux.
Pour en savoir plus sur la façon de combler l’écart entre adoption des agents IA et accès gouverné et traçable aux données, réservez une démo personnalisée dès maintenant.
Foire aux questions
Pas forcément, et AWS l’affirme clairement. L’usage généralisé de l’IA fantôme montre que les collaborateurs jugent le parcours officiel trop lent ou trop contraignant par rapport à la valeur que l’IA peut leur apporter, et non que la gouvernance est une mauvaise idée. La bonne réponse consiste à considérer le volume d’IA fantôme comme un indicateur honnête des points de friction de votre processus de validation, puis à intégrer les contrôles essentiels, en particulier le contrôle d’accès et la visibilité sur les données, directement dans le système pour que le parcours officiel devienne le plus rapide.
Au minimum, un enregistrement horodaté précisant quel agent ou modèle a fait la demande, quel contenu il a consulté, quelle politique a autorisé cet accès, et où ont été envoyés les résultats. Une déclaration générale du type « le système IA est surveillé » ne suffira pas à un régulateur ou à un auditeur. Un journal d’audit généré automatiquement à chaque requête, et non reconstitué après un incident, fait la différence entre une réponse solide et une gestion de crise.
La plupart des systèmes de gestion des identités et des accès déterminent si un utilisateur ou un compte de service peut s’authentifier sur un système. Kiteworks Compliant AI répond à une question plus précise et plus critique : à quels contenus spécifiques cet agent IA ou ce grand modèle de langage peut-il accéder pour cette requête, une fois authentifié, selon une politique basée sur le rôle et les attributs, évaluée en temps réel. Ce contrôle à la requête correspond à la recommandation AWS de placer les limites de sécurité à l’extérieur de l’agent, plutôt que de faire confiance à ses propres instructions.
La recherche AWS montre que la question reste ouverte dans les organisations étudiées, et considère cette ambiguïté comme un problème à résoudre plutôt que comme une réponse déjà tranchée. La solution recommandée est structurelle, pas organisationnelle : tenir un registre des agents avec un propriétaire humain désigné pour chaque agent en production, afin que la responsabilité ne dépende pas d’une reconstitution a posteriori. Un journal d’audit unifié sur tous les systèmes touchés par un agent rend cette responsabilité effective, et non symbolique.
Oui, c’est même l’argument central de la recommandation AWS « gouvernance as code ». Le ralentissement vient du fait que chaque décision IA passe par un comité humain, quel que soit le niveau de risque, et non de la gouvernance elle-même. En intégrant la politique au niveau des données, les requêtes à faible risque sont évaluées et validées automatiquement, tandis que les demandes réellement sensibles ou inhabituelles sont traitées par un humain. Ce modèle, appliqué par le Secure MCP Server pour les agents connectés via le Model Context Protocol, permet de garder le contrôle tout en éliminant le goulot d’étranglement humain sur la majorité des décisions courantes.
Ressources complémentaires
- Article de blog
Stratégies Zero-Trust pour une protection abordable de la confidentialité de l’IA - Article de blog
Comment 77 % des organisations échouent sur la sécurité des données IA - eBook
AI Governance Gap : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025 - Article de blog
Il n’existe pas de « –dangerously-skip-permissions » pour vos données - Article de blog
Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent des preuves concrètes.