Une question à laquelle la plupart des directions ne savent pas répondre
Demandez à un directeur technique ou à un RSSI combien de salariés compte son organisation, la réponse arrive instantanément. Posez la même question à propos des identités non humaines présentes dans son environnement, et dans la plupart des organisations, c'est le silence. Comptes de service. Clés d'API. Jetons OAuth. Scripts d'automatisation. Identifiants de pipelines CI/CD. Et, de plus en plus, des agents IA autonomes qui se connectent, agissent et engendrent d'autres agents de leur propre initiative.
Les études sectorielles de 2026 convergent vers un constat inconfortable. Selon les analyses, les identités non humaines dépassent aujourd'hui les identités humaines dans un rapport allant de 80 pour 1 dans une entreprise type à plus de 140 pour 1 dans les environnements cloud-natifs, un ratio qui a approximativement doublé en moins de deux ans. Certaines analyses situent le parc cloud moyen d'une entreprise à plus d'un quart de million d'identités non humaines, la grande majorité disposant de plus de privilèges que ce que leur tâche exige réellement. Les agents IA constituent la part la plus dynamique de cette population, avec une croissance projetée dépassant largement celle des identités machines en général comme celle des effectifs humains.
Il ne s'agit pas d'un détail d'infrastructure marginal. C'est la couche d'identité sous-jacente à toute transformation numérique, tout programme d'adoption de l'IA et toute migration cloud en cours, et pour la plupart des organisations, personne n'en assume la responsabilité de bout en bout.
La vérité qui dérange : la catégorie d'« utilisateur » qui croît le plus vite dans votre organisation en ce moment n'est pas une personne. Elle ne participe à aucun processus d'intégration, n'est jamais désactivée à la fin d'un projet, et n'apparaît sur aucun organigramme. Elle s'accumule, tout simplement.
Comment on en est arrivé là : trois vagues d'automatisation
Les identités non humaines ne sont pas nouvelles. Ce qui a changé, c'est le rythme, l'autonomie et le niveau de privilège en jeu.
Vague 1 : comptes de service et scripts
La première vague était simple : une tâche planifiée nécessite un identifiant de base de données, un outil de supervision a besoin d'un accès en lecture aux journaux, un script de sauvegarde requiert un accès en écriture au stockage. Ces comptes étaient créés délibérément, généralement un par un, et bien qu'ils aient souvent été surprivilégiés et rarement renouvelés, au moins un humain avait pris la décision consciente de créer chacun d'eux.
Vague 2 : la prolifération cloud-native et CI/CD
La deuxième vague est arrivée avec les microservices, les conteneurs et le déploiement continu. Chaque service doit désormais s'authentifier auprès de tous les autres. Chaque étape de pipeline nécessite ses propres identifiants. Les modèles d'infrastructure-as-code créent de nouveaux rôles et principaux de service en simple effet de bord d'un déploiement, souvent sans que personne n'examine les permissions attachées. C'est cette vague qui a fait passer le nombre d'identités non humaines de « supérieur aux effectifs » à « supérieur de plusieurs ordres de grandeur aux effectifs ».
Vague 3 : l'IA agentique
La troisième vague se produit actuellement, et elle diffère qualitativement des deux précédentes. Un agent IA n'est pas un identifiant statique dormant tranquillement dans un fichier de configuration. C'est un acteur autonome qui demande des permissions de manière dynamique en temps réel, appelle des API externes de sa propre initiative, écrit et exécute du code, et, dans des architectures de plus en plus courantes, engendre des sous-agents pour accomplir certaines parties de sa tâche. Un seul assistant de codage IA, agent de déploiement ou robot conversationnel de support client approuvé peut générer une cascade d'identités en aval que personne n'a explicitement provisionnées et que personne ne suit explicitement.
C'est à ce niveau que la gouvernance a le plus pris de retard sur la réalité. Des enquêtes sectorielles récentes constatent qu'une part significative des organisations ne suit absolument pas la création d'identités liées à l'IA, et qu'une large majorité de responsables sécurité admettent manquer de confiance dans leur capacité à empêcher une attaque exploitant l'une d'entre elles.
Pourquoi il s'agit d'un enjeu d'entreprise, et non d'une simple note de bas de page sécurité
Il est tentant de classer la prolifération des identités non humaines dans la catégorie « à traiter par l'équipe sécurité ». Ce cadrage sous-estime l'ampleur de l'exposition. Le sujet se situe précisément à l'intersection de l'architecture technologique, de la résilience opérationnelle et de la maîtrise des coûts, ce qui explique pourquoi il mérite sa place dans le même ordre du jour que votre stratégie cloud et votre feuille de route IA, et non dans un classeur de conformité séparé.
Un problème d'architecture
La manière dont vous concevez vos agents IA, vos microservices et votre infrastructure cloud détermine le nombre d'identités non humaines que vous créez et le niveau de privilège de chacune. Les équipes qui adoptent l'IA agentique sans architecture d'identité en place prennent en réalité des centaines de décisions ad hoc de contrôle d'accès chaque semaine, sans processus de revue. C'est autant un échec de conception technologique qu'un échec de sécurité, et c'est un constat que nous faisons de manière répétée en examinant les environnements cloud et les pipelines CI/CD de nos clients.
Un problème de résilience opérationnelle
2026 a déjà livré un rappel : l'infrastructure cloud dont tout le monde dépend n'est pas infaillible. Une faille de permissions dans la console de facturation d'un grand fournisseur cloud a exposé des données de coûts et d'usage inter-comptes à des clients qui n'auraient jamais dû les voir. Les régulateurs européens ont réagi en désignant formellement les plus grands fournisseurs cloud comme des tiers critiques soumis à une supervision directe de la résilience opérationnelle, précisément parce qu'une part considérable de l'économie, y compris de larges pans du secteur financier, dépend désormais d'une poignée de fournisseurs. Chaque identité non humaine que votre organisation crée dans cette infrastructure partagée est un fil qui relie votre résilience opérationnelle à la leur. Plus ces fils existent sans responsable désigné, plus il devient difficile de répondre à une question réglementaire simple : que se passe-t-il pour nos opérations si cet identifiant, ce fournisseur ou ce prestataire venait à faillir ?
Un problème de coûts
Chaque identité non humaine non gérée, chaque compte de service orphelin, chaque agent IA appelant discrètement une API payante dans une boucle de nouvelle tentative, constitue également un angle mort en matière de maîtrise des coûts. Les directions financières signalent de plus en plus des dépenses cloud liées à l'IA ayant crû plus vite que tout modèle prévisionnel, en bonne partie parce que personne ne dispose d'un inventaire précis de ce qui appelle réellement quoi.
Un problème de chaîne d'approvisionnement logicielle
La même période a vu apparaître une chaîne de vulnérabilités critiques, largement exploitée, affectant des centaines de millions de sites web construits sur des plateformes courantes, ainsi qu'un cycle mensuel de correctifs éditeur traitant plus de 500 vulnérabilités distinctes. Chacun de ces systèmes s'authentifie auprès d'un autre au moyen d'une identité non humaine. La gestion des correctifs, les pratiques de développement sécurisé et la gouvernance des identités ne sont pas trois disciplines distinctes ; ce sont trois angles de vue sur une seule et même exposition sous-jacente.
À quoi ressemble concrètement une défaillance
Les défaillances d'identités non humaines ressemblent rarement à un piratage de film hollywoodien. Elles paraissent banales, jusqu'au moment où elles ne le sont plus.
Scénario 1 : l'assistant de codage surprivilégié
Une équipe de développement adopte un assistant de codage IA avec accès aux dépôts source de l'organisation pour accélérer la livraison, une décision par ailleurs tout à fait saine. L'assistant se voit accorder un jeton d'accès large « pour éviter les frictions », plutôt qu'un jeton restreint et spécifique à la tâche. Quelques mois plus tard, une intégration mal configurée ou un ordinateur portable de développeur compromis expose ce jeton. Comme il n'a jamais été restreint, le rayon d'impact n'est pas un dépôt, mais tous les dépôts que l'assistant pouvait atteindre, ainsi que tous les secrets codés en dur à l'intérieur. Les seuls scans de dépôts publics en 2025 ont révélé des dizaines de millions de secrets exposés, et les outils de codage assistés par IA ont mesurablement accéléré cette fuite, précisément parce que les agents sont rapides pour trouver et réutiliser des identifiants devant lesquels un développeur humain se serait peut-être arrêté.
Scénario 2 : le sous-agent silencieux
Une organisation déploie un agent autonome pour trier et orienter les tickets de support client. Pour traiter un sous-ensemble de demandes, l'agent est conçu pour engendrer un sous-agent spécialisé disposant d'un accès aux systèmes de facturation. Personne n'enregistre ce sous-agent comme une identité distincte, si bien qu'il hérite des permissions larges de son parent plutôt que d'un ensemble restreint qui lui serait propre. Dix-huit mois plus tard, un audit interne découvre que le sous-agent est actif depuis le début, que ses permissions n'ont jamais été revues, et que personne dans l'organisation ne peut dire avec certitude qui est responsable de ce à quoi il a eu accès.
Scénario 3 : l'intégration tierce oubliée
Un service financier connecte un outil d'automatisation de feuilles de calcul à une plateforme comptable cloud via une clé d'API, générée une seule fois, lors d'un test de concept deux ans auparavant. Le porteur du projet a depuis quitté l'entreprise. La clé fonctionne toujours. Elle n'a jamais été renouvelée, jamais restreinte à un accès en lecture seule, et jamais rattachée à un responsable qui aurait remarqué un usage détourné. C'est exactement le type d'identifiant orphelin que des incidents récents survenus chez de grands cabinets de services professionnels et sur des plateformes de support ont montré des attaquants activement rechercher : non pas la porte d'entrée, mais la porte de service que personne ne se souvenait avoir laissée déverrouillée.
Pourquoi la gestion des identités traditionnelle ne résout pas ce problème
La plupart des programmes de gestion des identités et des accès ont été conçus autour de l'humain : une personne rejoint l'entreprise, un manager approuve l'accès, les RH déclenchent le départ, et des revues d'accès périodiques détectent les dérives. Appliquez ce modèle aux identités non humaines, et il s'effondre sur presque toutes ses hypothèses.
- Il n'y a pas de déclencheur RH. Un compte de service ou un agent IA n'est « embauché » ni « licencié » par un processus que quiconque surveille. Il est créé par un script de déploiement et survit souvent au projet, à l'équipe, voire à la relation fournisseur qui le justifiait.
- L'authentification multifacteur ne s'applique pas. On ne peut pas demander un second facteur à une machine à 2 heures du matin. Les identités non humaines reposent généralement sur des secrets statiques, ce qui explique pourquoi la gestion des secrets, et non la politique de mots de passe, est ici le contrôle qui compte.
- La responsabilité est rarement assignée à la création. Un compte humain a un propriétaire nommé dès le premier jour. Un principal de service créé en effet de bord d'un modèle d'infrastructure n'en a souvent aucun, et le jour où quelqu'un demande « à qui appartient-il », la réponse honnête est souvent « personne ne le sait ».
- Les privilèges sont demandés dynamiquement, et non provisionnés une fois pour toutes. Un agent autonome peut acquérir de nouvelles permissions en temps réel à mesure qu'il enchaîne des tâches, ce qui signifie qu'une revue d'accès effectuée aujourd'hui peut être significativement obsolète en quelques jours.
Un cadre concret de gouvernance des identités non humaines
Nous travaillons avec nos clients, au sein des fonctions technologie comme sécurité, pour combler cet écart à l'aide d'un cadre structuré en cinq dimensions concrètes, délibérément conçu pour qu'une équipe technologie et une équipe sécurité puissent l'exécuter conjointement plutôt qu'en chantiers séparés.
Dimension 1 : découverte et inventaire
On ne peut gouverner ce qu'on ne voit pas. Le point de départ est toujours un inventaire complet : chaque compte de service, clé d'API, autorisation OAuth, principal de service et agent IA, à travers tous les comptes cloud, plateformes SaaS et systèmes CI/CD utilisés. La plupart des organisations qui mènent cet exercice pour la première fois sont surprises, et rarement agréablement, par le chiffre obtenu.
Dimension 2 : responsabilité et cycle de vie
Chaque identité non humaine devrait avoir un propriétaire humain ou une équipe nommée, un objectif documenté et un cycle de vie défini : une date de création, une date de revue prévue et un déclencheur de suppression rattaché au projet ou système qu'elle soutient. Une identité sans propriétaire est une identité dont personne ne remarquera l'usage détourné.
Dimension 3 : moindre privilège et accès juste-à-temps
Adoptez par défaut le périmètre le plus restreint qu'exige une tâche, et privilégiez des identifiants éphémères et provisionnés juste-à-temps plutôt que des identifiants statiques de longue durée, partout où l'architecture le permet. Pour les agents IA spécifiquement, cela signifie des limites de permissions explicites par agent et par sous-agent, avec les actions à fort impact conditionnées à une approbation humaine plutôt qu'accordées par défaut.
Dimension 4 : gestion et renouvellement des secrets
Les identifiants codés en dur dans le code source, les fichiers de configuration ou les pipelines CI/CD doivent être traités comme un incident en attente, car les données montrent systématiquement que c'est exactement ce qu'ils sont. Un coffre-fort de secrets géré, avec renouvellement automatisé, comble la faille unique la plus importante que nous observons dans les environnements clients.
Dimension 5 : surveillance et lignes de base comportementales
La surveillance des identités humaines recherche des connexions anormales. La surveillance des identités non humaines doit rechercher des comportements anormaux : un compte de service accédant soudainement à des données hors de son schéma habituel, un agent IA appelant des API qu'il n'a jamais utilisées auparavant, un identifiant s'authentifiant depuis un lieu inattendu ou avec un volume inhabituel. C'est là que la surveillance cyber et la gouvernance de l'IA convergent véritablement en une seule et même capacité.
Par où commencer, concrètement
- Menez une découverte des identités non humaines sur l'ensemble de votre parc cloud et SaaS. Considérez le premier résultat comme une base de référence, pas comme un objectif : l'important est de connaître le chiffre réel avant de chercher à le réduire.
- Identifiez et corrigez en priorité les identifiants orphelins. Les comptes sans propriétaire clair représentent la correction au risque le plus élevé et à l'effort le plus faible : désactivez, renouvelez ou supprimez.
- Rendez l'attribution de la responsabilité obligatoire à l'avenir. Aucun nouveau compte de service, intégration ou agent IA ne devrait être provisionné sans propriétaire nommé et objectif documenté, imposé par votre processus de déploiement, et non par un document de politique que personne ne lit.
- Intégrez le déploiement des agents IA au même processus de gouvernance que tout autre système de production. Si un nouveau microservice nécessiterait une revue d'architecture, un nouvel agent IA disposant d'un accès système devrait en nécessiter une également.
- Déployez un gestionnaire de secrets si ce n'est pas déjà fait. C'est l'une des mesures au rendement le plus élevé et à la perturbation la plus faible disponibles, et elle ne devrait pas attendre la conception d'un programme plus large.
- Étendez la surveillance au comportement non humain, pas seulement aux connexions humaines. Si votre dispositif de surveillance actuel ne peut pas répondre à la question « qu'est-ce que ce compte de service a fait différemment cette semaine », c'est une faille qu'il vaut mieux combler avant qu'un incident ne la mette à l'épreuve.
Le contexte luxembourgeois et européen
Pour les organisations opérant dans les secteurs des services financiers, de l'administration de fonds et des services professionnels au Luxembourg, la gouvernance des identités non humaines n'est pas une bonne pratique abstraite : elle recoupe de plus en plus directement les attentes des superviseurs. Les exigences de gestion du risque informatique de DORA s'appliquent aux systèmes et identifiants dont dépendent vos agents IA et pipelines automatisés, pas uniquement aux applications auxquelles vos employés se connectent manuellement. Alors que les régulateurs européens formalisent la supervision des grands fournisseurs de cloud qui hébergent la majeure partie de cette infrastructure, et que la volonté plus large de l'UE en matière de souveraineté technologique redessine l'endroit où les charges de travail sensibles peuvent s'exécuter, les organisations disposant déjà d'un inventaire propre et responsabilisé de leurs identités non humaines sont tout simplement mieux positionnées pour répondre aux questions qu'un régulateur, un auditeur ou un assureur finira par poser.
Il en va de même pour le nombre croissant d'entreprises luxembourgeoises qui accélèrent l'adoption de l'IA, notamment via le programme de subvention SME Package AI. Un déploiement d'IA bien gouverné et un parc d'identités non humaines bien gouverné sont, en pratique, le même projet vu sous deux angles.
Technologie et sécurité, pas technologie ou sécurité
La gouvernance des identités non humaines se situe précisément là où se situe notre propre pratique : à l'intersection de la construction de la technologie (architecture cloud, pipelines DevSecOps, déploiement d'agents IA) et de sa sécurisation (gouvernance des identités, évaluation des risques, surveillance). Traiter ces sujets comme des projets séparés menés par des équipes séparées est exactement ce qui conduit les organisations à se retrouver avec 250 000 identités non gérées et aucune réponse claire à la question « qui en est responsable ».
Si votre organisation adopte des agents IA, fait croître son infrastructure cloud, ou est simplement incapable aujourd'hui de dire combien d'identités non humaines existent dans son environnement, c'est une conversation qu'il vaut mieux avoir avant qu'un audit, un incident ou un régulateur ne vous y contraigne. Nous serions heureux de vous aider à cartographier l'exposition et à construire un programme de gouvernance adapté à la façon dont vos équipes technologiques travaillent réellement.
