L’identité est peut-être l’élément fondamental de conception que vous négligez

Il y a dix-huit mois, nous avons commencé à participer aux réunions où se prennent réellement les décisions concernant la montée en puissance de l’IA. Pas les keynotes magistraux, mais les sessions de travail où les responsables de la sécurité, les architectes de plateforme et les sponsors métiers négocient ce qui sera lancé et ce qui sera reporté. Le schéma que nous observions était récurrent et surprenant : les entreprises qui atteignaient la production le plus rapidement n’étaient pas celles disposant des meilleurs modèles ou du plus grand volume de données. C’était celles qui considéraient l’identité comme un élément fondamental de la conception de l’IA dès le premier jour.

L’identité détermine si vous lancez en production ou si vous restez bloqué en phase pilote. C’est le facteur limitant de l’adoption de l’IA en entreprise auquel presque personne ne pense suffisamment tôt lors de la conception.

Nous le savons parce que nous avons passé 18 mois à observer ces échecs en temps réel, dans les secteurs financiers, de la santé, du retail et des logiciels d’entreprise, pour n’en citer que quelques uns. Le mode échec reste étonnamment constant, quel que soit le secteur d’activité, le choix du modèle ou la plateforme cloud.

Une intention humaine, mille événements d’autorisation

Un responsable de la sécurité au sein d’une entreprise de services financiers a résumé le problème pour nous il y a quelques mois. Son équipe avait déployé trois agents d’IA en janvier dans le cadre d’un projet pilote contrôlé, défini, documenté et validé. En mars, elles avaient trouvé 17 autres agents en fonctionnement dans l’organisation, sans qu’aucun n’ait été validé par qui que ce soit. Connectés aux données de production. Effectuant des appels API. Fonctionnant à partir des identifiants des collaborateurs.

« Je ne sais même plus à quoi elles sont connectées », a-t-elle déclaré. Elle n’était pas un cas isolé. Elle représentait la valeur médiane.

Une seule tâche agentique consomme 5 à 30 fois plus d’événements d’identité qu’une interaction standard. Enchaînez les workflows d’agents : un agent peut en appeler un autre, déléguer des sous-tâches, créer des sous-agents, et des chercheurs de Stanford ont constaté que la limite supérieure atteint un facteur 1000 pour des workflows de raisonnement complexes intégrant des boucles de reprise et de l’auto-correction.

Une seule intention humaine. Mille événements d’autorisation. Chacun de ces événements constitue une surface d’attaque, une exposition en matière de conformité et une décision de gouvernance que l’IAM traditionnel n’a jamais été conçu pour gérer.

Seuls 24,4 % des entreprises disposent d’une visibilité complète sur leurs agents d’IA. D’ici 2028, une entreprise moyenne du Fortune 500 déploiera plus de 150 000 agents. Aujourd’hui, 90 % de ces agents disposent d’autorisations excessives. Et cela va au-delà des agents distincts, en incluant les modèles ajustés qui effectuent des appels d’inférence, les pipelines RAG qui extraient des sources sensibles, les chaînes de prompts qui sollicitent des outils, ainsi que les orchestrations multi-agents où les autorisations se propagent à travers des couches de délégation sans qu’aucune personne ne les ait explicitement accordées.

53 % des agents accèdent à des données sensibles sans gouvernance appropriée. Le problème de la Shadow AI dépasse le cadre des agents. Chaque inférence non autorisée transmet des autorisations héritées qui se multiplient à la vitesse des machines.

« L’explosion des événements liés à l’identité n’est pas un simple effet secondaire de l’IA agentique : c’est la caractéristique qui la définit. Chaque agent que vous déployez sans gouvernance représente bien plus qu’un simple risque. C’est un facteur multiplicateur pour tous les autres risques présents dans votre environnement. »
- Sai Lolayekar, Business Innovation Leader, Security Partners, AWS

La plupart des frameworks de gouvernance répondent à des problématiques dépassées

Le secteur converge vers un discours rassurant : « repensez vos workflows, intégrez la sécurité dès le départ, gouvernez vos agents. » Les principaux cabinets d’analystes et fournisseurs de services cloud le confirment. Et même si cette approche est correcte, elle reste insuffisante.

Le problème, c’est que la plupart des frameworks de gouvernance déployés aujourd’hui sont des moteurs de politiques statiques qui tentent de régir des systèmes dynamiques. Elles définissent les autorisations lors du déploiement. Mais l’IA agentique ne fonctionne pas de cette façon. Le comportement d’un agent se manifeste à l’exécution. Il détermine quel outil appeler ensuite. Il décide s’il convient de déléguer. Il détermine les données dont il a besoin en fonction d’un contexte qui n’existait pas au moment où la politique a été rédigée.

La gouvernance statique appliquée à des agents dynamiques revient à rédiger un code de la route pour une ville dont les rues sont réaménagées chaque heure.

Ce qu’il faut — et que presque personne n’a encore entièrement conçu — c’est une gouvernance des identités capable d’opérer avec la même rapidité et la même adaptabilité que les agents eux-mêmes: 

• Permissions qui s’atténuent en aval à mesure que les chaînes de délégation s’allongent 
• Contrôle d’accès contextuel qui se resserre à mesure que la sensibilité augmente 
• Arrêts d’urgence qui n’exigent pas qu’une personne détecte d’abord le problème

C’est là l’écart. C’est pourquoi l’identité ne se limite pas à être « importante » dans la montée en puissance de l’IA : elle en constitue le facteur limitant. Les entreprises qui résolvent ce problème en premier ne font pas qu’éviter les risques. Ils avancent plus vite que toutes les autres entreprises, car ils peuvent déployer des agents en production alors que leurs concurrents sont encore bloqués en phase pilote, dans l’attente de politiques parfaites.

Les quatre principaux modèles d’échec de sécurité que nous observons réellement en pratique (dans les discussions, pas dans les rapports)

D’après les échanges menés auprès de centaines d’entreprises, nous constatons quatre modèles récurrents qui maintiennent les organisations dans une impasse. Voici à quoi ils ressemblent lorsque vous êtes assis à la table :

1. L’angle mort des opportunités

Une entreprise de santé a investi 4 millions de dollars pour développer des agents de traitement des demandes alimentés par l’IA, dotés de contrôles des accès appropriés. La plus grande opportunité en termes de valeur concernait en réalité le workflow d’autorisation préalable en amont, dans lequel les professionnels de santé partageaient des identifiants et les agents héritaient par défaut de droits d’administration. Le mauvais élément a été protégé, car la concentration des risques liés à l’identité n’a pas été identifiée.

2. La déconnexion entre la stratégie et l’exécution

Une entreprise de retail que le CEO a déclaré « axée sur l’IA » en janvier, où le CTO a financé trois initiatives de plateforme et où le CISO a lancé un framework de gouvernance : toutes ces actions partaient dans des directions différentes. Au troisième trimestre, 12 équipes développaient des agents sur quatre environnements d’exécution, sans aucune coordination autour de l’identité. Ils développaient douze versions de la même dette technique, et aucune d’entre elles ne pouvait réussir une évaluation de sécurité unifiée.

3. Expérimentations qui ne débouchent jamais

Une entreprise spécialisée dans les logiciels professionnels a lancé 47 pilotes d’agents d’IA en 18 mois ; seulement trois ont été déployés en production. Chaque projet pilote en suspens s’est heurté au même obstacle : l’évaluation de sécurité. Chacune avait conçu son propre système d’authentification, de stockage des identifiants et de gestion des autorisations. Quarante-quatre implémentations d’identité sur mesure, aucune infrastructure de gouvernance réutilisable. Les pilotes n’ont pas échoué en raison des capacités de l’IA. Ils ont échoué parce que personne n’a conçu la plateforme d’identité qui leur aurait permis de passer à l’étape suivante. 

4. Quand les garde-fous deviennent des obstacles

Le rapport Global CISO Insights 2026 d’Okta révèle que seulement 31 % des RSSI estiment être pleinement en phase avec leur direction générale et leur conseil d’administration sur le niveau de risque acceptable lié à l’IA, et moins de la moitié indiquent que leur conseil considère la sécurité de l’IA comme un levier pour l’entreprise plutôt qu’un simple critère à respecter en matière de conformité. Résultat : les équipes sécurité deviennent le « service qui dit non ». Pas parce qu’elles le veulent, mais parce que le processus les y oblige.  

Chacun de ces modèles a la même cause profonde : l’identité a été considérée comme un élément secondaire plutôt que comme un principe fondamental de la conception. 

La solution ne réside ni dans une meilleure coordination ni dans l’ajout de nouvelles politiques. Il s’agit d’une responsabilité différente, où l’identité devient une décision d’architecture et non plus un simple point de contrôle en fin de parcours.

« Vous ne pouvez pas développer l’autonomie sans renforcer la responsabilisation : l’identité est une décision de conception fondamentale qui distingue l’avantage cumulatif du risque cumulatif. »
- Eddie Kim, Head of AI Market Development, AWS ISV North America

Pour être clair : la qualité des modèles et la préparation des données ne sont pas négligeables, elles sont indispensables. Mais ce n’est pas là que les entreprises rencontrent des difficultés. Nous avons vu des équipes disposant de modèles de pointe et de pipelines de données irréprochables rester bloquées pendant des mois, faute de pouvoir répondre à des questions fondamentales sur l’autorisation des agents. Le goulet d’étranglement s’est déplacé.

Le problème du cerveau d’entreprise  

Une discussion est en cours actuellement dans le secteur au sujet de « l’intelligence collective de l’entreprise » : l’idée selon laquelle les agents doivent disposer d’une mémoire et d’un contexte partagés, afin que les connaissances acquises par un agent puissent être transmises aux autres, au lieu de disparaître à la fin de la session.

C’est la bonne intuition. Les agents sans état qui oublient tout entre les sessions expliquent pourquoi les pilotes impressionnent, alors que les systèmes en production déçoivent. Mais personne dans cette conversation ne pose la question suivante : « Qui contrôle la mémoire ? »

Lorsque l’Agent A découvre des informations sur la situation financière d’un client et les transmet à l’Agent B, qui gère un workflow marketing, ce partage était-il autorisé ? Lorsque le contexte accumulé d’un agent inclut des données à caractère personnel, des secrets commerciaux ou des communications privilégiées, qui décide de ce qui est conservé, de ce qui est supprimé et de qui d’autre peut y accéder ?

Le cerveau de l’entreprise sans gouvernance des identités, c’est l’amnésie organisationnelle remplacée par la surveillance organisationnelle. Vous n’avez pas résolu le problème. Vous avez créé une nouvelle menace, plus difficile à détecter et à contenir.

C’est ici que l’identité devient non seulement un contrôle de sécurité, mais aussi un élément fondamental de conception pour la prochaine génération d’architecture d’IA. La couche mémoire, la couche de contexte, la couche de connaissances partagées… toutes nécessitent des contrôles des accès adaptés à l’identité, capables de fonctionner aussi rapidement que les agents qui les utilisent.

Une entreprise de services financiers que nous avons rencontrée avait déployé des agents dotés d’une mémoire partagée, mais sans contrôles des accès à l’échelle de l’identité. En quelques semaines, un agent marketing avait ingéré des données financières de clients qu’un agent conformité avait extraites — des données qu’il n’était pas autorisé à conserver et pour lesquelles il ne disposait d’aucun mécanisme de suppression.

Comment Okta et AWS sécurisent ensemble la mémoire agentique et les workflows délégués

C’est précisément pour cette raison que nous avons conçu l’intégration Okta-AWS afin de contrôler non seulement les actions des agents, mais aussi leur mémoire. Pour les équipes qui exécutent des workloads agentiques sur Amazon Bedrock, chaque agent que vous déployez constitue une nouvelle identité qu’il convient d’identifier, de limiter et de gouverner. 

Okta for AI Agents s’intègre directement à Amazon Bedrock et Amazon Bedrock AgentCore pour combler la lacune de gouvernance de l’IA et résoudre cinq défis en même temps :

1. Découverte de la Shadow AI dans l’ensemble de l’environnement 
2. Enregistrement universel pour attribuer une propriété humaine à chaque identité autonome
3. Application du principe du moindre privilège, avec des autorisations qui diminuent à mesure que les chaînes de délégation s’allongent
4. Rotation automatisée des identifiants à la vitesse des machines
5. Journaux d’audit complets offrant des enregistrements infalsifiables de chaque action effectuée par un agent 

Point essentiel : cela fonctionne avec n’importe quel fournisseur d’identité existant, qu’il s’agisse d’Entra ID, de Ping ou d’un autre, sans qu’il soit nécessaire de tout remplacer.

À quoi ressemble ce processus en pratique ? Une équipe retail que nous avons accompagnée a mis en place sa couche de gouvernance des agents avant même de développer un seul agent. Chaque agent hérite d’une identité à portée limitée lors de son instanciation. Les autorisations sont automatiquement réduites lorsqu’un agent délègue. Leur premier agent est passé du concept à la production en 11 jours. Leur douzième agent a été déployé en trois jours, car l’infrastructure de gouvernance était déjà en place.

Le business case est une question de rapidité, pas une question de risque

Dans des dizaines d’entreprises que nous avons accompagnées, le schéma se confirme : les équipes qui intègrent la gouvernance des identités dès le premier jour atteignent la mise en production en cycles de six semaines. Les équipes qui ajoutent la gouvernance après coup en sont encore à la phase pilote au bout de 18 mois, car chaque évaluation de sécurité les oblige à repenser leur architecture. 

Cela représente un écart de vitesse d’un facteur 12 entre les entreprises qui placent l’identité au cœur de leur stratégie et celles qui la considèrent en dernier. Et les effets se cumulent. L’équipe qui place l’identité au premier plan a lancé 12 itérations et tiré des enseignements des retours en production, tandis que l’équipe qui traite l’identité en dernier en est encore à négocier sa première validation de déploiement.

Les données 2026 de BCG confirment la tendance générale : les entreprises dotées d’une stratégie d’IA claire intégrant la refonte des workflows constatent une amélioration de 25 points de pourcentage de l’impact mesurable sur leur activité. Les recherches d’Eightfold estiment les gains d’EBITDA entre 10 et 25 %. D’après notre expérience sur le terrain, une conception axée sur l’identité constitue le principal facteur déterminant pour qu’une refonte de workflow soit effectivement déployée en production ou reste à l’état de pilote.

Le mécanisme est simple : les équipes qui placent l’identité au centre conçoivent une couche de gouvernance partagée une seule fois, puis chaque agent ultérieur en hérite. Les équipes qui placent l’identité au second plan reconstruisent la gouvernance sur mesure pour chaque agent, à chaque fois. La première approche évolue de façon linéaire. Le second voit ses coûts et sa complexité augmenter de façon quadratique, puis finit par ne plus évoluer du tout.

Plan d’action : trois frameworks pour préparer l’identité à l’IA

Nous croyons en « voir grand, commencer modestement, évoluer rapidement ». Voici trois conversations pour commencer : 

1. L’audit des points de friction 

• Qui : vous et votre équipe des opérations
• Identifier 3 à 5 points de friction fréquents 
• Pour chacune, posez la question : « Si nous concevions cela aujourd’hui à partir de zéro, avec l’IA comme capacité native et la gouvernance des identités intégrée, à quoi cela ressemblerait-il ? »

2. Le choix de l’architecture d’identité 

• Qui : Vous, votre CISO et la personne responsable de votre plateforme d’IA 
• Trois questions : « Combien d’agents fonctionnent actuellement, qu’ils soient autorisés ou non ? Pouvons-nous révoquer l’accès de n’importe quel agent en moins de 60 secondes ? Si un agent délègue à un sous-agent, les autorisations sont-elles atténuées ou héritées ? »
• Le diagnostic : si vous ne pouvez pas répondre aux trois questions, c’est que votre architecture présente une lacune

3. La question de la rapidité 

• Qui : Vous et votre direction générale ou conseil d’administration 
• Redéfinir la sécurité : passer de l’« atténuation des risques » à la « vitesse de déploiement ». 
• L’axe stratégique : la question n’est pas de savoir comment encadrer l’IA en toute sécurité, mais comment passer en production douze fois plus rapidement que les concurrents. La conception axée sur l’identité est la solution.

L’économie agentique arrive trop rapidement pour que la plupart des entreprises puissent s’y préparer. Le secteur converge vers l’idée que les agents doivent disposer d’identités délivrées par des machines, avec une application stricte du principe du moindre privilège et une auditabilité complète, une position désormais formalisée par le NCCoE du NIST dans son framework dédié à l’identité et à l’autorisation des agents d’IA. Mais s’accorder sur l’idée ne signifie pas s’accorder sur la mise en œuvre. L’écart entre la prise de conscience de l’importance de l’identité et son intégration à l’architecture est précisément là où l’avantage se renforce. Les entreprises qui maîtrisent cet aspect ne se contenteront pas de limiter les risques, elles gagneront en rapidité et lanceront davantage de nouveautés.

L’identité est la décision de conception qui détermine la préparation à la mise en production. Ne l’ignorez pas. Commencez par le créer.