L’ombre de l’IA était le problème facile : le véritable risque réside dans les agents cachés dans les logiciels approuvés

Il y a deux ans, l’ombre de l’IA signifiait que les employés collaient des données client dans ChatGPT. La solution, dans l’ensemble, était gérable : découvrir les outils, sanctionner les bons, bloquer les mauvais, former les personnes. La plupart des organisations sont quelque part au milieu de l’exécution de ce plan, où 61% ont déjà rencontré l’ombre de l’IA dans leurs environnements et le plan fonctionne pour la plupart.

Cependant, cette description ne décrit plus le problème. L’ombre de l’IA a évolué au-delà d’un problème de comportement pour devenir un problème d’architecture. La gouvernance traditionnelle ne peut pas suivre le paysage moderne, y compris les agents d’IA intégrés par les fournisseurs et les agents câblés par les employés à l’intérieur des systèmes approuvés avec des informations d’identification héritées, ce qui fait de l’identité le seul point de contrôle réel.

Les deux ombres que vous ne surveillez pas

La question intéressante en 2026 n’est pas de savoir quel outil d’IA un employé a ouvert. C’est de savoir quel agent d’IA votre fournisseur sanctionné a livré discrètement à l’intérieur de la mise à jour de produit du dernier trimestre et quels sont les autorisations qu’il a héritées de la personne qui l’a installé.

L’ombre de l’IA était autrefois une question de comportement. Vous pouviez la voir, la nommer et mettre une politique contre elle. La version qui se propage maintenant est structurelle. Elle arrive par le biais de logiciels que vous avez déjà approuvés, agissant sous des informations d’identification que vous avez déjà émises, dans des flux de travail que vous avez déjà audité. L’ombre n’est plus comportementale, elle est architecturale. Les employés sont toujours dans le tableau, mais ils sont passés de l’utilisation de l’IA à son déploiement : en câblant des agents dans les systèmes auxquels ils ont déjà accès, et en le faisant à travers des interfaces conçues pour rendre cela simple. Les politiques rédigées pour le premier comportement ne s’appliquent pas au second.

C’est pourquoi « l’interdire » n’a jamais été le véritable débat. Les CISO qui ont pris les devants sur l’ombre de l’IA en sanctionnant les outils d’entreprise et en poussant les employés vers des alternatives régies ont gagné ce round et ont découvert que le suivant était déjà en cours et qu’il avait deux vecteurs, et non un. Le premier est ce que les fournisseurs sanctionnés livrent dans les produits déjà en production : des modèles intégrés, des modes d’agent, de nouvelles intégrations qui sont arrivées dans une note de version que personne n’a lue. Le second est ce que les employés câblent eux-mêmes : un LLM connecté au CRM par le biais d’une automatisation sans code, un GPT personnalisé doté d’une clé API pour l’entrepôt de données, une connexion MCP à partir d’un assistant de bureau dans un système de production. Les deux produisent le même résultat, qui comprend des agents agissant sous des informations d’identification approuvées, contre des systèmes approuvés, dans des flux de travail qui n’ont jamais subi de révision conçue pour les détecter. La passation des marchés peut voir le premier vecteur et manquer complètement le second.

Il est utile d’être honnête sur la façon dont la première manche a été gagnée de manière inégale. Neuf organisations sur dix prévoient d’augmenter leur budget IT lié à l’IA, avec de nombreuses organisations prévoyant une expansion plus large dans les opérations IT au cours des 6 à 24 prochains mois. Le budget est alloué aux capacités intelligentes. Les contrôles rattrapent leur retard par pouces. Ce déséquilibre est le problème, et non un effet secondaire.

La périphérie était toujours humaine

Le modèle mental qui a fonctionné pour la première vague ne fonctionne pas pour celle-ci. L’ombre de l’IA en tant que comportement des employés supposait un humain dans la boucle faisant un choix que l’équipe de sécurité pouvait influencer. L’ombre de l’IA en tant qu’architecture de fournisseur supprime le choix. Le modèle qui a rédigé l’e-mail, l’agent qui a planifié la réunion, l’assistant qui a résumé le document et l’a acheminé vers l’avant. Aucun de ceux-ci n’a nécessité qu’un employé fasse autre chose que continuer à utiliser le logiciel dont il lui avait été dit d’user.

La réponse honnête est que la périphérie que la plupart des programmes de sécurité défendent encore était une périphérie d’action humaine. Les employés ouvraient des outils, les employés accordaient l’accès, les employés prenaient des décisions que l’équipe de sécurité pouvait observer et façonner. Cette périphérie disparaît dans deux directions à la fois. D’en haut, les fournisseurs livrent des agents dans des produits approuvés plus rapidement que tout processus d’examen ne peut suivre. D’en bas, les employés sortent du rôle d’utilisateur et entrent dans le rôle d’intégrateur, en câblant des agents dans les systèmes par le biais d’interfaces conçues pour être autoservies et qui n’ont jamais été instrumentées pour la gouvernance. La nouvelle périphérie, construite autour de ce que les identités font, indépendamment du fait que ces identités soient des personnes, et indépendamment de qui les a déployées, nécessite un tissu de contrôle que la plupart des organisations n’ont pas encore.

Le seul endroit où il reste à regarder

L’identité est le bon point de contrôle, mais le cadre doit changer. La formulation conventionnelle dit que « l’identité est la nouvelle périphérie » parce que les utilisateurs sont partout, les appareils sont partout et le SaaS est partout. C’était vrai il y a une décennie, c’est désormais acquis. La version qui compte en 2026 est différente : l’identité est le seul endroit où vous pouvez voir ce que l’IA fait réellement, car une fois qu’elle le fait, la limite de l’outil a déjà été franchie. L’agent agit sous les informations d’identification de quelqu’un. De qui, avec quelle portée, contre quelle donnée, sur quelle autorisation sont les seules questions qui produisent une traçabilité utile. La gouvernance au niveau de l’outil ne peut pas répondre à ces questions car l’outil n’est plus l’unité d’analyse.

Près de 90% des dirigeants IT reconnaissent déjà que l’unification a un impact direct sur leur capacité à mettre en œuvre et à mettre à l’échelle l’IA de manière sécurisée. La question plus difficile est de savoir ce que signifie réellement l’unification au niveau de la couche de contrôle. Elle ne peut pas simplement signifier moins de tableaux de bord. Cela signifie un tissu d’identité unique où chaque acteur, qu’il soit humain, compte de service, agent, modèle intégré, est provisionné, étendu, surveillé et supprimé par le biais du même ensemble de mécanismes. Tout ce qui est inférieur à cela vous donne l’apparence d’une gouvernance consolidée alors qu’en réalité il s’agit d’une application fragmentée.

Votre examen de fournisseur a une date d’expiration

Malheureusement, un examen de fournisseur n’est valable que pendant un certain temps. Cela a des implications inconfortables sur la façon dont les programmes de sécurité sont structurés. La plupart des comités de gouvernance de l’IA sont organisés autour de l’examen des outils, avec des fournisseurs qui viennent et sont évalués, sanctionnés ou rejetés, afin d’être ajoutés au registre. Ce processus suppose que le comportement de l’outil au moment de la sanction est le comportement de l’outil en production. Pour les logiciels intégrant l’IA, cette hypothèse est rompue avant même que l’encre ne soit sèche. Le fournisseur livrera un nouveau modèle, un nouvel agent, une nouvelle intégration, et l’examen de gouvernance qui a été approuvé il y a six mois décrit maintenant un produit qui n’existe plus.

Hors de l’outil, sur l’identité

Les programmes qui tiendront seront ceux qui déplaceront la gouvernance de l’outil vers l’identité. Chaque action contre vos données, par n’importe quel acteur, est traçable à une identité avec un propriétaire connu, un ensemble d’autorisations étendu, et une durée de vie définie. Que ce soit humain ou non humain, employé ou agent, outil sanctionné ou mode intégré, la question est la même : qui est-ce, qu’est-ce qu’il est autorisé à faire, et comment savons-nous quand cela devrait cesser d’être vrai ? Les programmes qui peuvent répondre à ces questions n’ont pas besoin de gagner la course de sanction des outils. Les programmes qui ne le peuvent pas seront en retard par rapport aux fournisseurs et aux employés qui livrent plus rapidement que tout processus d’examen ne peut bouger.

L’ombre de l’IA en tant que catégorie ne disparaît pas. Surtout avec la nouvelle ère de la main-d’œuvre agente, 72% des organisations ont déjà des agents d’IA en production. Au lieu de cela, elle devient une partie plus petite d’un problème plus grand. Les organisations qui consacrent le prochain cycle de budget à la découverte d’outils et à la politique de sanction sont celles qui résolvent le problème de 2024 sur un calendrier de 2026. Celles qui consacrent leur budget à l’instrumentation de la couche d’identité pour les humains, les agents, le continuum complexe entre eux, sont celles qui résolvent le problème qu’elles auront réellement.

La première vague de l’ombre de l’IA a enseigné aux équipes de sécurité qu’elles ne pouvaient pas devancer la curiosité des employés. La deuxième vague va leur enseigner qu’elles ne peuvent pas non plus devancer la vitesse des fournisseurs ou l’ingéniosité des employés. Les deux leçons pointent vers la même conclusion. L’unité de gouvernance n’a jamais été l’outil. C’était toujours l’identité qui agit à travers lui.