La gouvernance des identités devient cruciale alors que les dépenses d’IA d’entreprise explosent

Google News a mis en avant un avertissement : les dépenses d’IA d’entreprise augmentent plus vite que de nombreuses entreprises ne peuvent gouverner les identités qui opèrent derrière elles. Le sujet ne se limite plus aux chatbots expérimentaux. Les agents d’IA demandent désormais des données, sollicitent des applications métier, génèrent des identifiants et exécutent des tâches dans les systèmes de l’entreprise.

Cette expansion modifie la question de sécurité. Les entreprises se concentraient autrefois sur la décision de savoir quels employés pouvaient accéder à une ressource. Elles doivent désormais gouverner les utilisateurs humains, les comptes de service, les identités applicatives, les outils d’automatisation et les agents d’IA au sein du même environnement.

La pression s’exerce sur les directeurs des systèmes d’information, les responsables de la sécurité et les équipes chargées des identités. On leur demande de soutenir un déploiement plus rapide de l’IA tout en préservant une responsabilité clairement définie, des autorisations limitées et des pistes d’audit fiables. Ces objectifs entrent souvent en conflit lorsqu’un agent peut planifier du travail, déléguer des tâches et franchir les limites entre applications.

La question centrale n’est donc pas de savoir si les entreprises dépenseront davantage pour l’IA. Elle est de savoir si la gouvernance des identités peut empêcher ces dépenses de créer une couche croissante d’autorité non suivie.

Ce qui a changé avec l’accélération des dépenses d’IA d’entreprise

L’IA d’entreprise passe de logiciels qui recommandent des actions à des systèmes capables d’agir.

Lorsqu’un employé utilise un chatbot, cela crée un problème de gouvernance familier. L’organisation doit déterminer à quelles informations cet employé et cette application peuvent accéder. Un agent d’IA pose un défi plus complexe, car il peut se connecter à plusieurs systèmes, conserver des identifiants, invoquer des outils et effectuer des tâches sans qu’une personne n’approuve chaque étape.

Cette différence devient importante lorsque les agents intègrent les workflows de production. Un agent de service client peut lire des dossiers de compte, résumer des interactions passées, émettre une demande de remboursement et mettre à jour un ticket. Un agent de programmation peut examiner des dépôts, ouvrir des outils de développement, créer des modifications d’infrastructure et soumettre du code à révision.

Chaque action requiert une identité. Elle exige aussi une autorisation, qui définit ce que cette identité peut faire après authentification. Une simple connexion ne répond pas à la question de savoir si l’agent doit lire toute une base de données clients ou uniquement les dossiers nécessaires à une tâche qui lui a été attribuée.

Les systèmes traditionnels de gestion des identités et des accès étaient principalement conçus autour des employés, des prestataires, des applications et de comptes de service relativement prévisibles. Ils supposent généralement que les administrateurs peuvent définir un rôle stable et lui attribuer un ensemble stable d’autorisations.

Les agents d’IA mettent ce modèle sous pression. Leurs tâches peuvent évoluer pendant l’exécution, et un agent peut demander à un autre agent ou à un service de réaliser une partie d’un workflow. La chaîne de délégation qui en résulte rend plus difficile l’identification de l’origine de l’autorité initiale.

Les dépenses d’entreprise ajoutent un caractère d’urgence, car davantage de projets financés entraînent davantage de connexions. Chaque déploiement en production peut introduire des clés API, des comptes de service, des connecteurs de données, des points de terminaison de modèles, des plug-ins et des politiques d’accès. Un projet qui semble n’être qu’une seule application d’IA peut créer plusieurs identités en coulisses.

Gartner a indiqué que 84 % des répondants à son enquête 2026 auprès des DSI s’attendaient à ce que leur organisation augmente le financement de l’IA générative au cours de l’année. Sa réflexion sur la gouvernance zéro confiance portait sur la vérification des données et la mise à jour des politiques de gouvernance existantes à mesure que les informations générées par l’IA se diffusent.

Ces dépenses ne produisent pas automatiquement des systèmes non sécurisés. Elles augmentent toutefois le nombre de projets que les équipes chargées des identités doivent découvrir, classifier et surveiller. Elles réduisent également le temps disponible pour concevoir des contrôles avant que les unités métier n’attendent des résultats.

Le titre de Google News reflète ce changement, mais l’événement réel est plus vaste qu’un seul rapport. La gouvernance des identités devient une composante de l’infrastructure d’IA, car les agents ne peuvent pas opérer en sécurité sans une responsabilité définie et une autorité révocable.

Les organisations ne peuvent plus traiter l’examen des identités comme une ultime vérification de conformité. Elles ont besoin de décisions relatives aux identités lors de la conception, du déploiement, de l’exécution et de la mise hors service. Sans cela, un agent abandonné peut conserver des identifiants ou des autorisations actifs après la fin de son projet d’origine.

Pourquoi Google News pointe un déficit de contrôle de l’IA

La hausse des dépenses révèle un écart de contrôle entre ceux qui sont responsables de l’IA et ceux qui peuvent réellement contraindre son comportement.

IBM a décrit cet écart dans une étude de juin 2026 consacrée aux directeurs des systèmes d’information et de la technologie. Selon l’étude d’IBM sur le contrôle de l’IA, deux tiers des dirigeants interrogés ont déclaré être responsables de systèmes d’IA qu’ils ne contrôlaient pas entièrement.

Cette conclusion est importante, car la responsabilité sans contrôle crée une ambiguïté organisationnelle. Un DSI peut être responsable du programme d’IA d’entreprise, tandis que des départements individuels sélectionnent des modèles, connectent des sources de données et créent des automatisations de manière indépendante. L’équipe de sécurité peut ne voir l’identité qui en résulte qu’après une revue ou un incident.

L’acquisition de solutions d’IA peut également fragmenter l’autorité. Un département peut acheter une application contenant des agents intégrés sans la présenter comme un projet d’agents. Une autre équipe peut créer un workflow interne à l’aide d’une API de modèle et de plusieurs outils d’automatisation existants.

Ces deux déploiements peuvent créer des identités non humaines. Ces identités peuvent être réparties entre plateformes cloud, services logiciels, bases de données internes et environnements de développement. Aucun inventaire unique ne recense nécessairement l’ensemble du parcours.

Le problème ne réside pas simplement dans le nombre de comptes. La gouvernance des identités doit relier cinq éléments d’information : ce qu’est l’agent, qui en est responsable, pourquoi il existe, quelles ressources il peut atteindre et à quel moment son autorité doit expirer.

Les employés humains fournissent des repères naturels pour plusieurs de ces questions. Leur responsable approuve les accès, un rôle professionnel limite les autorisations et leur départ déclenche un processus de désactivation. Les agents d’IA n’ont pas de statut organisationnel équivalent, à moins que l’entreprise n’en crée un.

Un agent peut également utiliser une autorité empruntée à un utilisateur humain. Cette conception peut simplifier le déploiement, mais elle affaiblit l’attribution si les journaux ne permettent pas de distinguer les actions de la personne de celles de l’agent. Les identifiants partagés créent un écart encore plus important, car les enquêteurs peuvent ne pas savoir quel workflow les a utilisés.

Les équipes de sécurité subissent donc une pression des deux côtés. Les responsables métier souhaitent des cycles de déploiement plus courts, tandis que les régulateurs et les clients attendent un accès contrôlé aux informations sensibles. Les équipes chargées des identités doivent soutenir ces deux exigences sans transformer chaque demande d’agent en une longue revue manuelle.

L’écart de contrôle touche aussi les systèmes de connaissance. Un assistant d’IA connecté à une base de connaissances d’entreprise peut récupérer des informations qui paraissent inoffensives prises isolément. Il peut néanmoins déduire des faits sensibles en combinant plusieurs documents que le workflow demandeur n’était jamais censé analyser ensemble.

C’est pourquoi le contrôle d’accès doit aller au-delà d’une autorisation de dossier. Les organisations doivent comprendre les relations entre utilisateurs, agents, sources de données et résultats générés. Une base de connaissances d’IA bien structurée peut améliorer la récupération d’informations, mais sa valeur dépend du maintien de limites appropriées.

Le défi devient plus difficile lorsque l’IA évolue plus vite que les revues d’accès. Un processus de certification trimestriel peut approuver un agent pour un objectif donné. Quelques semaines plus tard, les développeurs pourraient ajouter un autre outil ou lui permettre de traiter une nouvelle catégorie de données.

L’approbation statique cesse alors de refléter le système déployé. La gouvernance des identités doit suivre les changements significatifs, notamment les nouvelles intégrations, des périmètres plus larges, des chemins de délégation modifiés et des règles de conservation ajustées.

Google News met en lumière un problème de sécurité que la croissance des budgets rend visible. Les entreprises financent la capacité d’agir par l’IA, mais de nombreux programmes de gouvernance se concentrent encore sur le contrôle de la capacité à se connecter.

Les agents d’IA font des autorisations le principal arbitrage

L’arbitrage fondamental est simple : les agents deviennent plus utiles à mesure que leur autorité s’étend, mais une autorité plus large accroît les conséquences d’une défaillance.

Un agent qui ne peut que rédiger du texte présente un risque opérationnel limité. Un agent capable d’accéder à des dossiers clients, d’appeler des systèmes de paiement, de modifier une infrastructure ou d’envoyer des messages externes peut générer davantage de valeur. Il peut également causer davantage de dommages en cas d’erreur, de manipulation ou de vol d’identifiants.

Le principe du moindre privilège consiste à n’accorder que les accès nécessaires à une tâche définie. Son application aux employés est déjà difficile, car les rôles évoluent et les autorisations s’accumulent. Elle est plus difficile pour les agents, car la tâche requise peut se dérouler de manière dynamique.

Prenons un agent chargé de résoudre un litige de facturation. Il pourrait devoir lire la facture, examiner une commande, comparer un contrat, contacter un approbateur interne et créer un ajustement proposé. Il ne devrait pas obtenir un accès permanent à toutes les factures ni la capacité d’approuver son propre ajustement.

Un compte de service étendu facilite la création de ce workflow. Une identité à périmètre restreint facilite sa gouvernance, mais exige une conception de politique plus précise. Cette tension n’apparaît souvent qu’après qu’un pilote est devenu un service de production.

La délégation ajoute une couche supplémentaire. Un agent orchestrateur peut demander à un agent spécialisé de récupérer des données ou d’exécuter une analyse. L’entreprise doit décider si le second agent hérite de toutes les autorisations, reçoit un sous-ensemble réduit ou obtient un accès temporaire pour une seule opération.

Si l’autorité passe par plusieurs agents, les journaux doivent préserver cette chaîne. Les enquêteurs doivent savoir quel humain ou service a initié la tâche, quel agent a pris chaque décision, quelles ressources ont été utilisées et si l’action résultante est restée dans le cadre de l’objectif approuvé.

McKinsey a estimé que les technologies axées sur les agents pourraient absorber jusqu’à 15 % des budgets de cybersécurité des entreprises au cours des trois prochaines années. Son analyse indiquait que les dépenses se concentreraient sur l’identité et la gouvernance, aux côtés de la protection des données.

Cette prévision reflète une évolution de l’architecture de sécurité. Les organisations ont passé des années à bâtir des contrôles autour des réseaux, des appareils et des comptes humains. Les systèmes agentiques font de l’identité un point d’application central, car un agent peut opérer sur les trois à la fois.

L’autorisation continue offre une réponse possible. Au lieu d’approuver l’accès une seule fois lors de la connexion, un système évalue si une action spécifique reste autorisée au moment où elle est demandée. La décision peut prendre en compte l’agent, la tâche, la ressource, le moment, le niveau de risque et l’utilisateur à l’origine de la demande.

Les identifiants temporaires réduisent également l’exposition. Un agent peut recevoir un identifiant pour une seule tâche et le perdre automatiquement lorsque cette tâche prend fin. Cette approche limite la valeur d’un jeton volé et réduit le risque qu’un accès obsolète perdure indéfiniment.

Aucune de ces techniques ne résout l’ensemble du problème de gouvernance. Un moteur de politiques a toujours besoin d’informations fiables sur l’objectif et le responsable de l’agent. Un identifiant temporaire peut être dangereusement étendu même s’il expire rapidement.

Les entreprises ont également besoin d’une séparation des fonctions. Un agent qui propose un paiement ne devrait pas nécessairement l’autoriser ou l’exécuter. Les actions à fort impact peuvent nécessiter une vérification humaine, un second agent opérant sous une autorité différente, ou une règle métier déterministe.

Ce contrôle réduit l’autonomie, ce qui peut décevoir les équipes qui s’attendent à des workflows entièrement automatisés. Pourtant, l’objectif ne devrait pas être une autonomie maximale. Il devrait s’agir du plus haut niveau d’autonomie permettant de préserver des preuves, une responsabilité et des options de reprise acceptables.

C’est là que les dépenses d’IA en entreprise rencontrent le plus directement la gouvernance des identités. L’argent finance les modèles, l’infrastructure et le travail d’intégration. Il doit aussi financer les contrôles qui déterminent les actions que ces systèmes peuvent effectuer.

Le marché de la sécurité des identités a son propre problème de preuves

Les enquêtes des fournisseurs vont dans le même sens, mais leurs chiffres exigent une interprétation prudente.

Les fournisseurs de solutions de sécurité ont publié plusieurs études décrivant une adoption rapide des agents et des contrôles d’identité insuffisants. Ces rapports offrent des signaux utiles, car les fournisseurs observent les environnements clients et les tendances en matière d’incidents. Ils soutiennent également les produits commercialisés par les organisations qui les publient.

Teleport a indiqué que les systèmes d’IA disposant de privilèges excessifs étaient associés à des taux d’incidents 4,5 fois plus élevés dans son étude 2026 sur les entreprises. L’entreprise a également déclaré que 92 % des sociétés interrogées déployaient l’IA alors que les contrôles d’identité restaient à la traîne, selon son rapport sur la sécurité des entreprises.

Ces chiffres ne doivent pas être considérés comme des mesures universelles. Les résultats dépendent de l’échantillon, de la formulation des questions, des définitions et de la manière dont les répondants classent un déploiement d’IA ou un incident de sécurité. Une organisation qui expérimente un assistant de programmation n’est pas équivalente à une autre qui autorise des agents à modifier des systèmes de production.

La tendance générale reste crédible même lorsque les pourcentages exacts varient. Les entreprises ajoutent des identités non humaines, et de nombreux programmes d’identité existants peinent à inventorier les comptes de service et les clés API. Les agents d’IA ajoutent un comportement plus dynamique à ce problème déjà établi.

Une autre limite concerne la terminologie. Les fournisseurs utilisent différemment des termes tels que agent d’IA, identité machine, identité de charge de travail, compte de service et identité non humaine. Une enquête peut sembler mesurer la gouvernance des agents tout en regroupant plusieurs catégories d’automatisation.

Cette ambiguïté affecte les affirmations sur les dépenses. Une entreprise peut classer un système d’accès privilégié modernisé comme un investissement dans la sécurité de l’IA. Une autre peut financer le même contrôle via sa plateforme cloud ou son budget général d’identité.

IDC a indiqué que 16,7 % des investissements mondiaux prévus dans l’IA étaient alloués à la sécurité et à la gouvernance des agents d’IA. Son analyse des priorités des CISO a également identifié la prolifération des outils, la dette technique, les pénuries de compétences et l’enfermement propriétaire comme des obstacles aux décisions d’achat.

Ce chiffre montre une attention significative des acheteurs, mais il ne prouve pas que les dépenses produisent une gouvernance mature. Les organisations peuvent acheter des outils qui se chevauchent sans créer un inventaire d’identités fiable ni un modèle d’approbation cohérent.

L’intégration reste la partie difficile. Les données d’identité peuvent résider dans un fournisseur d’identité, une plateforme cloud, un gestionnaire de secrets, un système de ressources humaines, un catalogue d’applications et une plateforme d’opérations de sécurité. Les métadonnées des agents peuvent se trouver dans un environnement de développement ou d’orchestration distinct.

Un produit de gouvernance ne peut afficher que ce que les systèmes connectés révèlent. L’IA fantôme, qui désigne une utilisation de l’IA non approuvée ou non détectée, peut rester hors de cette vue. Un employé pourrait connecter un outil d’IA grand public à des données professionnelles sans enregistrer d’application officielle.

Les recherches d’Okta publiées en 2026 ont décrit un décalage entre la confiance des dirigeants et le comportement des employés. Elles ont relié cet écart à des politiques floues, à des outils d’IA non approuvés et à des garanties insuffisantes au sein de l’entreprise agentique.

La conclusion prudente n’est pas que chaque entreprise fait face à une crise immédiate des identités. Elle est que les entreprises ne disposent pas d’un système de mesure cohérent pour les identités des agents, leurs autorisations effectives et leur comportement réel.

Les autorisations effectives comptent davantage que les autorisations attribuées. Un agent peut combiner des accès issus de plusieurs systèmes ou déduire des informations à partir de sources autorisées. Chaque autorisation peut paraître raisonnable isolément, alors que la capacité combinée dépasse la limite prévue.

Les tests doivent donc aller au-delà de la revue de configuration. Les équipes de sécurité doivent observer les actions tentées, les demandes refusées, les schémas de délégation, l’utilisation des identifiants et les mouvements de données. Elles doivent également tester le comportement des systèmes lorsqu’un agent reçoit des instructions malveillantes ou rencontre un contenu corrompu.

La réponse aux incidents introduit une autre incertitude. Les organisations peuvent être en mesure de désactiver un compte d’agent, sans pour autant identifier chaque identifiant, workflow ou tâche en aval qui y est associé. Un mécanisme d’arrêt complet exige une cartographie des dépendances avant qu’un incident ne survienne.

Les éléments disponibles justifient une attention accrue, et non une confiance aveugle dans une plateforme ou une statistique donnée. La gouvernance des identités ne devient efficace que lorsqu’une organisation peut démontrer qui est responsable d’un agent, ce qu’il peut faire et comment cette autorité prend fin.

Qui subit la pression liée au changement de gouvernance

Les CIO portent la pression de livraison, les CISO assument une grande partie du risque, et les équipes d’identité héritent de la charge opérationnelle.

Les directeurs des systèmes d’information doivent transformer les investissements en IA en résultats métier mesurables. Ils doivent faire passer les projets au-delà des prototypes tout en contrôlant des dépenses fragmentées et des plateformes incompatibles. Une gouvernance mise en place trop tard peut retarder la production ou imposer des refontes coûteuses.

Les responsables de la sécurité des systèmes d’information sont confrontés à une incitation différente. Ils doivent prévenir les accès excessifs, détecter les abus et expliquer les incidents. Un agent qui agit via des identifiants partagés peut compromettre ces trois responsabilités.

Les équipes de gestion des identités et des accès se situent entre ces priorités. Elles maîtrisent les annuaires, l’authentification, les accès privilégiés, les revues d’accès et les cycles de vie des comptes. Elles ne sont pas nécessairement responsables de l’orchestration des agents, du comportement des modèles, de la gouvernance des données ou de la conception des applications.

Cette répartition crée des lacunes à moins que les entreprises n’attribuent des responsabilités explicites. Chaque agent de production a besoin d’un responsable métier qui accepte sa finalité et ses conséquences. Il a également besoin d’un responsable technique qui maintient l’intégration, les identifiants, les politiques et la surveillance.

Les développeurs subissent une pression car les contrôles d’identité influencent l’architecture. Un prototype peut utiliser une clé API unique à longue durée de vie stockée dans une variable d’environnement. Un déploiement en production devrait utiliser des secrets gérés, des identifiants à portée limitée, une rotation, une expiration et des requêtes traçables.

Ces exigences ajoutent un travail d’ingénierie facile à sous-estimer. Le modèle peut générer une réponse en quelques secondes, mais le système qui l’entoure doit récupérer des informations autorisées, valider les appels d’outils, enregistrer les décisions, gérer les défaillances et empêcher les nouvelles tentatives dangereuses.

Les acheteurs en entreprise doivent examiner davantage que la qualité du modèle. Ils doivent se demander si un produit d’IA prend en charge des identités distinctes pour les agents, des périmètres d’autorisation granulaires, l’approbation par un administrateur, des journaux exportables, la rotation des identifiants et une révocation immédiate.

Ils devraient également demander comment le fournisseur gère la délégation. Si un agent invoque un autre service, le client doit savoir quelle identité apparaît dans les journaux en aval et si le contexte de l’utilisateur d’origine est préservé.

Les responsables des données ont un rôle à jouer, car les décisions d’accès ne peuvent pas reposer entièrement sur des équipes de sécurité centralisées. La personne responsable des données financières, médicales, clients ou d’ingénierie devrait définir les finalités acceptables et les actions à risque plus élevé.

Les équipes juridiques et de conformité s’intéresseront aux preuves. Un document de politique indiquant que les agents appliquent le principe du moindre privilège est moins solide que des enregistrements montrant quelles autorisations ont été accordées, qui les a approuvées, quelles actions ont eu lieu et quand l’accès a expiré.

Les employés subissent aussi le changement de gouvernance. Un agent étroitement contrôlé peut demander une approbation plus souvent ou refuser une tâche qu’il ne peut pas accomplir dans les limites de ses autorisations. Cette friction peut encourager les utilisateurs à choisir des outils non autorisés si les systèmes approuvés semblent inutilisables.

La réponse des entreprises doit donc équilibrer contrôle et facilité d’utilisation. Les politiques devraient distinguer la rédaction à faible risque de l’exécution à fort impact. Exiger le même processus d’approbation pour les deux peut créer des retards sans améliorer les protections les plus importantes.

Les achats peuvent soutenir cette distinction en classant les produits selon leur autorité. Un outil qui résume des documents présente un risque différent de celui qui modifie des enregistrements ou communique à l’extérieur.

Les conseils d’administration devraient se concentrer sur l’exposition plutôt que sur le nombre de projets d’IA. Dix agents disposant d’un accès en lecture seule à des informations publiques peuvent présenter moins de risque opérationnel qu’un seul agent détenant un identifiant de production étendu.

Ce recadrage fait de la gouvernance des identités une décision métier. Il relie les dépenses d’IA à la valeur et au risque des actions automatisées, plutôt que de traiter chaque déploiement comme un achat de logiciel équivalent.

Les lecteurs de Google News devraient donc considérer l’histoire de la gouvernance des identités comme une redistribution du travail. Davantage de dépenses en IA n’éliminent pas la responsabilité humaine. Elles déplacent cette responsabilité vers les personnes qui conçoivent, approuvent et surveillent l’autorité des machines.

Ce que les acheteurs en entreprise devraient surveiller ensuite

La prochaine phase sera mesurée par la couverture des identités, la qualité des autorisations et la préparation aux incidents, et non par le nombre d’annonces d’agents.

Le premier signal sera de voir si les principales plateformes d’IA adoptent des normes d’identité interopérables. Les entreprises risquent actuellement de gérer chaque environnement d’agents à travers des objets d’identité, journaux et systèmes de politiques différents.

Des normes communes aideraient les organisations à identifier un agent de manière cohérente à travers une plateforme de modèles, un framework d’orchestration, un service cloud et une application métier. Elles faciliteraient également la conservation des chaînes de délégation.

L’annonce par un fournisseur de la prise en charge de l’identité des agents ne suffit pas. Les acheteurs devraient examiner si l’identité est unique, persistante, attribuable à un responsable et compatible avec les systèmes d’authentification existants. Ils devraient aussi vérifier que les applications en aval peuvent la reconnaître.

Le deuxième signal concerne la qualité de l’autorisation à l’exécution. De nombreuses plateformes peuvent limiter les accès lors de la configuration, mais moins nombreuses sont celles qui peuvent évaluer chaque action en fonction de la tâche et du contexte actuels.

Les contrôles à l’exécution devraient répondre à des questions pratiques. Cet agent est-il autorisé à accéder à ce dossier client pour cette demande ? Peut-il envoyer les informations obtenues à l’extérieur de l’entreprise ? Une action financière nécessite-t-elle une seconde approbation ?

Surveillez les produits qui prennent en charge des identifiants de courte durée, des périmètres au niveau de la tâche, des contrôles de politiques et des enregistrements clairs de refus. Ces capacités indiquent que la gouvernance des identités entre dans l’exécution au lieu de rester une revue administrative.

Le troisième signal sera constitué des preuves issues des incidents et des audits. Les entreprises découvriront si leurs contrôles fonctionnent lorsqu’un agent se comporte de manière inattendue, reçoit des instructions manipulées ou utilise une autorité en dehors de sa finalité prévue.

Des preuves publiques utiles incluraient des rapports d’incident détaillés, des conclusions réglementaires, des exigences d’assurance et des orientations d’audit. Ces sources peuvent montrer si les organisations peuvent retracer les actions d’un agent et révoquer rapidement chaque identifiant associé.

Une baisse des autorisations excessives renforcerait l’argument selon lequel les programmes d’identité rattrapent leur retard. Une hausse des incidents impliquant des comptes partagés ou une responsabilité floue montrerait que les dépenses continuent de dépasser la gouvernance.

Les entreprises peuvent commencer à mesurer leur propre situation sans attendre une nouvelle norme. Elles devraient recenser les agents en production, identifier leurs responsables, cartographier les identifiants, consigner les autorisations effectives et suivre les dates d’expiration des accès.

La couverture est le premier indicateur utile. Une organisation ne peut pas gouverner un agent qu’elle n’a pas découvert. L’inventaire doit inclure les applications achetées intégrant des agents, les workflows développés en interne et les automatisations créées par les employés.

La qualité des autorisations constitue le deuxième indicateur. Les équipes doivent mesurer combien d’agents disposent d’un accès étendu ou permanent, à quelle fréquence les demandes sont refusées et si les actions sensibles exigent une approbation supplémentaire.

La performance du cycle de vie est le troisième indicateur. Les entreprises doivent savoir combien de temps il faut pour créer, examiner, modifier, suspendre et retirer une identité d’agent. Des processus lents encouragent les contournements, tandis que l’absence de contrôles de retrait laisse subsister des accès inutiles.

La préparation aux incidents fournit le test final. Une équipe doit pouvoir désactiver un agent, révoquer ses identifiants, arrêter les tâches en attente, identifier les ressources affectées et reconstituer la séquence des actions.

Ces étapes n’obligent pas les entreprises à abandonner leurs systèmes d’identité existants. De nombreuses organisations peuvent étendre leurs processus de gouvernance actuels si ces systèmes prennent en charge les identités de machines, les autorisations temporaires et des données d’événements détaillées.

Cependant, le simple fait d’attribuer aux agents des rôles calqués sur ceux des employés ne résoudra pas la délégation dynamique ni l’accès spécifique à chaque tâche. Les entreprises auront besoin de politiques conçues autour des actions et des finalités, et pas uniquement des intitulés de poste.

Google News a mis en avant un titre d’actualité opportun, mais l’histoire durable est opérationnelle. Les dépenses des entreprises en IA créent des systèmes capables d’exercer une autorité à la vitesse des machines. La gouvernance des identités doit déterminer de quelle autorité ils disposent, jusqu’où elle s’étend et à quel moment elle prend fin.

La prochaine question, très concrète, pour chaque acheteur d’IA est la suivante : votre organisation peut-elle nommer chaque agent en production, identifier son responsable, expliquer ses autorisations effectives et les révoquer sans perturber des activités sans rapport ? Si la réponse demeure incertaine, le budget IA a déjà créé une obligation de gouvernance à laquelle le budget de sécurité doit répondre.