La gestion des identités non humaines est désormais un enjeu de sécurité qui relève du conseil d’administration, car les machines, les services, les bots, les charges de travail, les clés API et les agents d’IA sont déjà bien plus nombreux que les employés, dans des proportions vertigineuses. En avril 2026, la Cloud Security Alliance a cité des estimations faisant état d’environ 96 identités non humaines pour chaque être humain dans le secteur des services financiers, et d’un rapport pouvant atteindre 144 pour 1 dans les environnements fortement axés sur le cloud. La solution ne réside pas dans une nouvelle politique de mots de passe. Il faut mettre en place un inventaire, définir les responsabilités, appliquer le principe du privilège minimal, procéder à la rotation des mots de passe, assurer la surveillance et permettre une mise hors service rapide.
La gestion des identités non humaines est devenue le nouveau point sensible de l'IAM
L'intention de recherche ici est d'ordre informatif, avec un aspect pratique lié à la sécurité : vous souhaitez savoir ce que signifie la gestion des identités non humaines, pourquoi les chiffres semblent soudainement absurdes, et quelles mesures permettent réellement de réduire les risques. En bref, la situation est préoccupante. La plupart des organisations ont conçu leurs programmes d’identité autour des employés, des prestataires et des administrateurs privilégiés, alors que la véritable prolifération des identités s’est étendue aux comptes de service, aux clés API, aux jetons OAuth, aux certificats, aux identités de charges de travail, aux identifiants CI/CD, aux bots d’automatisation et aux agents d’IA.
Le rapport 2026 de la Cloud Security Alliance consacré aux services financiers a chiffré précisément cette évolution. Une étude de fournisseurs citée par la CSA estimait le rapport entre les identités non humaines et humaines à environ 144 pour 1 tous secteurs confondus, et à 96 pour 1 dans les services financiers. CyberArk a indiqué en avril 2025 que les identités machines dépassaient celles des humains dans un rapport de plus de 80 pour 1 ; la tendance ne fait donc aucun doute, même si ces ratios varient selon les environnements.
Voici les chiffres concrets. Une banque comptant 12 000 employés, avec un ratio de 96 pour 1, peut gérer environ 1,15 million d’identités non humaines. Avec un ratio de 144 pour 1, une entreprise de logiciels natifs du cloud comptant 2 000 collaborateurs pourrait gérer environ 288 000 identités machine. Personne ne vérifie cela manuellement. Personne.
Les équipes de sécurité ont déjà été confrontées à ce problème dans le domaine de la livraison logicielle, où la rapidité engendre une dette opérationnelle cachée. Le même phénomène se retrouve dans le développement logiciel évolue plus rapidement que les équipes de sécurité ne peuvent le contrôler: les identifiants sont créés pour des raisons valables, puis oubliés une fois le déploiement, la migration ou l'expérience terminée.
Qu'est-ce qu'une identité non humaine ?
Une identité non humaine (ou NHI) est une identité numérique utilisée par une entité autre qu'une personne pour s'authentifier, demander un accès, exécuter du code ou appeler un autre système. Le rapport de la CSA de septembre 2024 définit les NHI comme incluant les bots, les clés API, les comptes de service, les jetons OAuth et les secrets. IBM donne également une définition large de cette catégorie : applications, services, charges de travail, conteneurs, API, bots, agents d'IA et appareils.
Cette définition est importante car les équipes se disputent souvent sur les appellations plutôt que sur l'exposition. Un rôle de charge de travail Kubernetes, un GitHub Actions secrètes, a service cloud Un compte et un rôle d'application Microsoft Entra peuvent se trouver dans des consoles différentes, mais pour un attaquant, cela revient au même : c'est un moyen d'agir au sein de votre environnement sans être un utilisateur humain.
La gestion des identités non humaines consiste à identifier ces identités, à les associer à leurs propriétaires et à des objectifs métier, à limiter leurs capacités d'action, à renouveler ou remplacer leurs identifiants, à surveiller leur utilisation et à les supprimer lorsqu'elles ne sont plus nécessaires. Les bons programmes considèrent l'accès aux machines comme un cycle de vie. Les mauvais le traitent comme une simple infrastructure.
Un écueil dont presque personne ne parle : le terme « propriétaire » désigne souvent la personne qui a créé l’identité, et non celle qui en assumera la responsabilité en 2026. Cette différence est considérable après une réorganisation. Si le créateur a quitté l’entreprise en 2024 et que le service dispose toujours d’un accès à la base de données de production, votre inventaire risque d’être techniquement complet mais inutilisable sur le plan opérationnel.
Les chiffres qui illustrent la crise d'identité des machines
Le rapport 2026 de la CSA sur les services financiers a également révélé que le risque lié à l’identité non humaine se classait à la 241e place parmi les préoccupations en matière de sécurité du cloud et de l’IA dans cette enquête, ce qui équivaut à peu près à la sécurité des API et devance le risque lié à l’identité humaine. Dans ce même rapport, l’amélioration de la sécurité des identités et des accès figurait en tête des priorités en matière de sécurité des infrastructures cloud pour les 12 prochains mois, avec un score de 48%, suivie par l’intégration de la sécurité de l’IA, avec un score de 44%.
Ces deux chiffres expliquent pourquoi la gestion des identités non humaines passe d'une activité de niche dans le domaine de la gestion des identités et des accès (IAM) à un programme de sécurité essentiel. La sécurité des API, la sécurité du cloud, la gouvernance de l'IA et la gestion des secrets se résument toutes à la même question : quelle identité effectue cette action, et devrait-elle y être autorisée ?
| Source et année | Chiffre communiqué | Pourquoi c'est important |
|---|---|---|
| CyberArk, 2025 | Le nombre d'identités de machines dépasse celui des humains dans un rapport de plus de 80 pour 1 | Cela montre que l'ampleur du phénomène dépassait déjà les capacités des processus humains d'examen de l'IAM |
| Rapport de la CSA sur les services financiers, 2026 | Environ 96:1 dans le secteur des services financiers | Les secteurs réglementés ne sont pas épargnés par la prolifération des identités de machines |
| Rapport de la CSA sur les services financiers, 2026 | Le fournisseur estime ce rapport à environ 144:1 tous secteurs confondus | Les environnements fortement axés sur le cloud peuvent héberger bien plus de comptes de machines que de comptes de personnel |
| Enquête CSA/Oasis, 2026 | 78% ne dispose pas de politiques documentées concernant la création ou la suppression d'identités d'IA | Des agents d'IA sont mis en place avant même que la gouvernance ne soit officialisée |
| Enquête CSA/Oasis, 2026 | 79% de professionnels de l'informatique se sentent mal préparés à prévenir les attaques par NHI | Le déficit en matière de compétences et d'outils reste important |
Les ratios peuvent sembler abstraits, alors vérifiez-les par rapport à votre propre parc. Comptez vos employés, puis multipliez ce chiffre par 80, 96 et 144. Si votre inventaire connu se situe bien en dessous de ces fourchettes, il se peut que votre environnement soit exceptionnellement « propre ». Il est plus probable que des identités vous échappent dans vos systèmes CI/CD, vos plateformes SaaS, vos locataires cloud, vos environnements de test pour développeurs ou vos automatisations abandonnées.
Pourquoi les agents d'IA font paraître obsolètes les anciens contrôles des comptes-machines
Les comptes de service traditionnels présentent déjà des risques, mais bon nombre d'entre eux ont un comportement prévisible. Ils effectuent une sauvegarde, synchronisent un répertoire, déploient une version ou transfèrent des données d'un système à l'autre. Les agents IA compliquent le modèle, car leurs actions peuvent être dynamiques, déléguées et enchaînées entre différents outils.
Le livre blanc de la CSA de mai 2026 sur la gouvernance de l’IA agentique indique que les agents IA peuvent obtenir des autorisations lors de l’exécution, créer des sous-agents, appeler des API externes, écrire ou exécuter du code et enchaîner des actions entre différents systèmes. La documentation Entra 2026 de Microsoft définit les « identités d’agents » comme des comptes d’identité destinés aux agents IA, et précise que ces derniers n’utilisent ni mot de passe, ni SMS, ni clé d’accès, ni application d’authentification pour s’authentifier.
Ce dernier point met fin à toute réponse à la va-vite. On ne peut pas sécuriser un agent de la même manière qu’un commercial, à l’aide de demandes d’authentification multifactorielle (MFA) et de formations contre le hameçonnage. Microsoft décrit également l’accès à l’identité des agents via les autorisations Microsoft Graph, les rôles RBAC d’Azure, les rôles d’annuaire Microsoft Entra et les rôles d’application Microsoft Entra, ce qui signifie que l’accès des agents peut porter sur les mêmes plans de contrôle à forte valeur ajoutée que ceux des administrateurs humains.
Le secteur des services financiers ajoute une dimension supplémentaire. En juin 2026, la CSA a averti que les paiements par agent obligent les institutions à déterminer si l'identité derrière une transaction autonome est celle du consommateur, de l'agent, du commerçant ou de la plateforme. Qui est responsable lorsqu'un agent autorise un paiement erroné ?
Pour replacer cela dans son contexte, le risque de sécurité ne se limite pas aux référentiels d'identité. Les agents d'IA font déjà l'objet d'études en tant qu'outils opérationnels pouvant être manipulés par des attaquants, comme l'explique l'article consacré à la manière dont les agents d'IA sont utilisés comme armes par les pirates informatiques ; par ailleurs, les protocoles des outils d'agents définissent leurs propres limites d'autorisation, comme le montrent les recommandations relatives à la sécurisation des serveurs MCP.
Comment sécuriser les identités des machines sans submerger l'équipe ?
La solution ne consiste pas à acheter un tableau de bord et à crier victoire. La gestion des identités non humaines nécessite des contrôles, même s’ils peuvent paraître fastidieux, qui résistent réellement à la pression : inventaire, propriété, règles de cycle de vie, principe du moindre privilège, rotation, surveillance et auditabilité. Les recommandations d’IBM pour 2026 et les documents de la CSA pour 2026 s’accordent sur ces mêmes catégories de contrôles.
Commencez par l'inventaire, mais n'en faites pas un projet d'« archéologie des feuilles de calcul ». Critical Start a recommandé en mai 2026 la mise en place d’un inventaire NHI unifié couvrant les comptes de service, les clés API, les jetons OAuth, les certificats, les identités de charge de travail, les identifiants CI/CD, les bots d’automatisation et les agents IA, en les associant au propriétaire, à la fonction métier, à l’étendue des privilèges, à la source de création et à la date de dernière utilisation.
- Identifiez les identités sur l'ensemble des fournisseurs de cloud, des plateformes SaaS, des systèmes de gestion du code source, des outils CI/CD, des gestionnaires de secrets, des annuaires et des plateformes de gestion des terminaux.
- Désignez une personne ou une équipe responsable, ainsi qu'une fonction métier, et ne vous contentez pas d'un champ « créateur ».
- Enregistrer l'étendue des privilèges, la source de création, le type d'identifiant, l'horodatage de la dernière utilisation et les systèmes concernés.
- Supprimez les identités inutilisées, en particulier celles qui n'ont pas fait l'objet d'activité récente ou qui n'ont pas de titulaire.
- Renouvelez les secrets et les identifiants selon un calendrier défini par la politique, avec un renouvellement d'urgence en cas de suspicion d'exposition.
- Appliquez le principe du « privilège minimal » grâce à des rôles délimités, des identifiants à durée de validité limitée et un système d'autorisation pour les autorisations à haut risque.
- Surveillez les comportements afin de détecter les appels d'API inhabituels, les nouvelles zones géographiques, les modifications de privilèges ou les accès ne correspondant pas au modèle de service attendu.
Honnêtement, c’est lors de la première phase de nettoyage que de nombreux programmes échouent. Les équipes identifient des milliers d’identités, paniquent, puis excluent les plus risquées, car personne ne souhaite perturber l’environnement de production. Une meilleure approche consiste à classer ces identités par niveau de risque : identifiants exposés à l’extérieur, rôles privilégiés dans le cloud, secrets obsolètes, propriétaires inconnus et identités capables d’en créer d’autres.
Les plateformes de sécurité dans le cloud peuvent s'avérer utiles, notamment lorsqu'elles offrent une vue d'ensemble des charges de travail, des identités et des comportements d'exécution ; si vous comparez différents outils, cet aperçu de plateformes de sécurité cloud d'entreprise destinées aux équipes DevOps est un allié précieux. L'acquisition d'identités et la consolidation de la gestion des identités et des accès (IAM) revêtent également une grande importance, c'est pourquoi la décision d'Accenture de se développer aux côtés d'IAMConcepts est pertinente pour la demande croissante d'expertise en matière de sécurité des identités.
La fuite d'informations confidentielles est une faille de sécurité qui se cache à la vue de tous.
Le « Top 10 des identités non humaines » de l’OWASP, publié pour 2025, recense des risques tels que la fuite de secrets. Cela n’a rien de surprenant, mais ce risque reste sous-estimé. La fuite de secrets est un vecteur d’attaque discret : pas d’e-mail de hameçonnage, pas d’activation de logiciel malveillant, pas d’attaque par force brute bruyante. Simplement un identifiant valide effectuant des actions qui semblent légitimes.
Le rapport 2024 de la CSA sur l'NHI a défini les clés API, les jetons OAuth, les comptes de service et les secrets comme des objets de sécurité essentiels, ce qui constitue une approche pertinente. A jeton Dans un référentiel, un secret CI/CD à longue durée de vie ou un compte de service doté de privilèges excessifs peut s'avérer plus utile à un attaquant qu'un mot de passe saisi par un utilisateur, car il peut contourner l'authentification multifactorielle (MFA), les contrôles de l'état des appareils et l'analyse du comportement normal des utilisateurs.
Un contre-argument mérite d'être pris en considération : toutes les identités de machine ne constituent pas nécessairement un risque imminent. Beaucoup d'entre elles disposent d'autorisations limitées, de courte durée et faisant l'objet d'un suivi rigoureux. La crise provient plutôt de la catégorie intermédiaire non gérée : des identités dotées de droits étendus, dont la propriété n'est pas clairement définie et qui n'ont pas de date d'expiration, car elles ont été créées dans l'urgence puis normalisées.
La détection doit également tenir compte du contexte. Un compte de service qui consulte une table de clients tous les soirs à 2 h du matin peut ne pas poser de problème. En revanche, si ce même compte exporte des données à midi, crée une nouvelle application OAuth ou appelle une API externe inconnue, cela mérite une attention immédiate.
Un modèle de gouvernance concret pour 2026
La gestion des identités non humaines devrait se situer à la croisée de l’IAM, de la sécurité du cloud, du DevSecOps, de l’ingénierie des plateformes et de la gouvernance de l’IA. Si elle relève d’une seule équipe, elle ne couvrira que la moitié de l’environnement. Les développeurs créent bon nombre de ces identités, les équipes cloud accordent les autorisations, les équipes de sécurité définissent les politiques et les responsables métier en assument le risque.
Placez le cycle de vie au cœur du modèle opérationnel. Chaque nouvelle identité de machine doit avoir une finalité, un responsable, des limites d’autorisation, un comportement attendu, une date de révision et un critère de mise hors service. Pour les agents d’IA, ajoutez une fiche indiquant les pouvoirs délégués, les outils approuvés, les classes de données autorisées, ainsi que la capacité de l’agent à créer des sous-agents ou à exécuter du code.
Les identifiants à durée de vie limitée sont généralement préférables aux secrets à durée de vie prolongée, mais ils ne constituent pas une solution miracle. Si un agent peut générer sans cesse de nouveaux accès sans que ceux-ci ne fassent l’objet de contrôles de politique pertinents, vous n’avez fait que déplacer le risque au lieu de le réduire. À ce stade, il est difficile de justifier l’existence d’un NHI doté de privilèges élevés sans une surveillance continue et des décisions d’accès vérifiables.
Les rapports destinés au conseil d'administration doivent éviter les indicateurs de vanité. Une affirmation telle que « Nous avons identifié 400 000 identités de machines » n'a d'intérêt qu'une seule fois. Parmi les indicateurs récurrents plus pertinents, on peut citer le pourcentage d'identités associées à un propriétaire, le pourcentage d'identités dont les données ont été utilisées récemment, le nombre d'identités privilégiées obsolètes supprimées, l'âge médian des identifiants, les secrets à haut risque ayant fait l'objet d'une rotation, ainsi que les agents IA pour lesquels des politiques de création et de suppression sont documentées.
Le constat de CSA/Oasis de janvier 2026, selon lequel 78% d'organisations ne disposent pas de politiques officiellement adoptées pour la création ou la suppression d'identités générées par l'IA, constitue un signal d'alerte. La création d'identités générées par l'IA devient de plus en plus facile. La suppression de ces identités relève quant à elle toujours de la gouvernance, et les mesures de gouvernance sont rarement mises en place par hasard.
FAQ
Qu'est-ce que la gestion des identités non humaines ?
La gestion des identités non humaines désigne le processus consistant à régir les identités numériques utilisées par les applications, les services, les charges de travail, les API, les bots, les appareils et les agents d'IA. Elle englobe la détection, la propriété, les autorisations, la rotation des identifiants, la surveillance et la suppression.
Pourquoi le nombre d'entités non humaines est-il supérieur à celui des salariés ?
Les environnements modernes de cloud, de SaaS, de CI/CD et d'automatisation génèrent des identités pour pratiquement chaque intégration, charge de travail et connexion entre services. En 2026, la CSA a cité des estimations allant de 96:1 dans le secteur des services financiers à 144:1 dans certains environnements fortement axés sur le cloud.
Les agents d'IA sont-ils des entités non humaines ?
Oui. La documentation Entra 2026 de Microsoft décrit les identités d'agents comme des comptes d'identité destinés aux agents IA, dont les modèles d'authentification diffèrent de ceux des utilisateurs humains. Ils nécessitent leurs propres autorisations, propriétaires, règles de surveillance et de suppression.
Quel est le principal risque lié aux identités des machines ?
Les fuites d'informations confidentielles et les accès avec des privilèges excessifs constituent deux des risques les plus importants. La fuite d'une clé API, d'un jeton OAuth ou des identifiants d'un compte de service peut permettre à un pirate de se faire passer pour un utilisateur de confiance sans avoir à se connecter manuellement.
Par où commencer pour sécuriser les identités non humaines ?
Commencez par établir un inventaire unifié associant chaque identité à son propriétaire, à son objectif métier, à l'étendue de ses privilèges, à sa source de création et à sa date de dernière utilisation. Supprimez ensuite les identités obsolètes, renouvelez les secrets exposés ou anciens, réduisez les privilèges et surveillez en permanence les comportements.
FR 
EN 
ES