Pendant deux décennies, la gestion des identités s’est concentrée sur l’humain : donner à la bonne personne le bon accès, au bon moment, et le lui retirer à son départ. Cette discipline reste centrale. Mais elle ne couvre plus qu’une fraction des authentifications qui se produisent réellement dans un système d’information moderne. La majorité des connexions ne sont plus le fait d’un utilisateur devant son clavier, mais de machines qui s’authentifient entre elles : un microservice qui appelle une base de données, un script d’intégration continue qui déploie une application, une fonction serverless qui interroge une API tierce.
Ces authentifications reposent sur des identités machine, aussi appelées identités non humaines ou NHI (Non-Human Identities). Comptes de service, clés API, jetons OAuth, certificats client, identités de charges de travail : ces entités sont désormais plus nombreuses que les comptes humains dans la plupart des organisations, et pourtant elles échappent souvent à toute gouvernance structurée. Cet article, à jour de juillet 2026, expose la nature du risque et propose une méthode de reprise en main, dans la continuité de notre analyse sur la maîtrise des identités et accès à privilèges.
Qu’est-ce qu’une identité machine ?
Une identité machine authentifie une charge logicielle, et non une personne physique. Là où un humain prouve son identité par un mot de passe complété d’un facteur multifacteur, une machine prouve la sienne par un secret : une chaîne de caractères, une clé cryptographique, un jeton signé ou un certificat.
Le périmètre des NHI recouvre plusieurs familles distinctes.
Les comptes de service. Des comptes techniques créés dans un annuaire, un système d’exploitation ou une application, destinés à exécuter des tâches automatisées. Ils possèdent souvent des privilèges élevés et une longévité importante, ce qui en fait des cibles de choix.
Les clés API. Des identifiants qui autorisent un programme à consommer une interface applicative, interne ou tierce. Elles voyagent dans des en-têtes HTTP, des variables d’environnement et des fichiers de configuration.
Les jetons OAuth et d’accès. Des artefacts temporaires ou durables délivrés par un fournisseur d’identité pour autoriser un accès délégué. Un jeton de rafraîchissement mal protégé équivaut à un accès permanent.
Les certificats client. Des identités cryptographiques utilisées pour l’authentification mutuelle (mTLS) entre services, notamment dans les architectures de microservices et de maillage de services.
Les identités de charges de travail cloud. Des identités attachées à une ressource (machine virtuelle, conteneur, fonction) par le fournisseur cloud, qui évitent en principe de stocker un secret statique. Elles constituent l’orientation recommandée, mais leur mauvaise configuration ouvre d’autres angles d’attaque.
Le point commun de toutes ces familles : elles s’appuient sur un secret dont la fuite compromet directement l’accès qu’elles protègent. Contrairement à un humain, une machine ne détecte pas une usurpation, ne s’étonne pas d’une connexion à une heure inhabituelle, et ne signale jamais un comportement anormal. Le secret est le seul rempart.
Pourquoi les NHI sont devenues un angle mort
La croissance du nombre d’identités machine est mécanique. Chaque adoption d’une architecture de microservices multiplie les points d’authentification service à service. Chaque pipeline d’intégration et de déploiement continu introduit des identités techniques. Chaque intégration SaaS ajoute des clés API. Chaque conteneur éphémère peut recevoir sa propre identité de charge de travail. Le rapport entre identités machine et identités humaines s’établit couramment à plusieurs dizaines pour une, et cette proportion continue de croître avec l’automatisation.
Ce déséquilibre pose un problème de gouvernance. Les processus IAM historiques ont été conçus pour un rythme humain : un salarié arrive, un salarié part, un accès est demandé puis validé par un responsable. Les identités machine suivent un rythme radicalement différent. Dans un environnement conteneurisé, des identités peuvent être créées et détruites plusieurs fois par heure. Les revues d’accès trimestrielles, adaptées aux humains, sont inopérantes face à ce flux.
À cette inadéquation s’ajoute un problème de propriété. Une identité humaine a un titulaire évident. Une identité machine, elle, se retrouve souvent sans propriétaire clairement désigné. Le développeur qui a créé une clé API a quitté l’équipe, le service qu’elle servait a été décommissionné, mais la clé reste active, avec ses privilèges intacts, dans un fichier de configuration que plus personne ne relit. Ces identités orphelines constituent une dette de sécurité silencieuse.
Enfin, la nature même du secret pose problème. Un secret doit être connu du logiciel qui l’utilise, ce qui crée une tension permanente entre disponibilité et confidentialité. La solution de facilité consiste à coder le secret en clair dans le code source ou dans une variable d’environnement, ce qui le disperse dans les dépôts, les images de conteneurs, les journaux et les sauvegardes. C’est précisément cette dispersion qui alimente le vecteur d’attaque dominant.
Le secret exposé : le vecteur d’attaque dominant
Le scénario le plus fréquent de compromission d’une identité machine n’a rien de sophistiqué. Un secret est écrit en clair quelque part où il ne devrait pas se trouver, un attaquant y accède, et l’accès qu’il protège est compromis.
Les dépôts de code sont le premier lieu d’exposition. Un développeur pressé commite une clé API dans un fichier de configuration. Même si l’erreur est corrigée quelques minutes plus tard, le secret reste inscrit dans l’historique du dépôt, accessible à quiconque en obtient une copie. Les dépôts publics font l’objet d’un balayage automatisé permanent par des acteurs malveillants qui cherchent précisément ce type de fuite. Les dépôts privés ne sont pas à l’abri : une compromission de compte développeur, un accès trop large ou une sauvegarde mal protégée suffisent à exposer l’ensemble de l’historique.
Les fichiers de configuration, les images de conteneurs, les journaux applicatifs et les tickets d’assistance constituent les autres réservoirs de secrets exposés. Un secret finit régulièrement copié dans un message d’incident, une capture d’écran ou un export de configuration partagé sans précaution.
Le référentiel OWASP Non-Human Identities Top 10, publié par la fondation OWASP, place l’exposition et le mauvais stockage des secrets parmi les risques prioritaires associés aux identités machine [1]. Ce classement, conçu comme le pendant des célèbres Top 10 applicatifs de l’OWASP, offre une grille de lecture partagée pour hiérarchiser les efforts de sécurisation. Il souligne également le risque des privilèges excessifs, des identités surprovisionnées et de l’absence de rotation, qui transforment une simple fuite en compromission durable.
Le CERT-FR, dans son suivi de la menace, observe que la compromission d’accès légitimes reste un mode opératoire majeur des attaques contre les organisations françaises [2]. Un secret machine volé constitue un tel accès légitime : il ne déclenche aucune alerte d’authentification anormale puisque, du point de vue du système, la machine se comporte exactement comme elle le devait. C’est ce qui rend ce vecteur à la fois discret et durable.
Les quatre piliers de la gouvernance des NHI
Reprendre le contrôle des identités machine ne relève pas d’un produit unique mais d’une démarche structurée autour de quatre piliers complémentaires.
Pilier 1 : l’inventaire
On ne protège pas ce que l’on ne connaît pas. La première étape consiste à établir un inventaire des identités machine actives : comptes de service, clés API, jetons, certificats, identités de charges de travail. Cet inventaire s’appuie sur le balayage des dépôts de code et des configurations à la recherche de secrets exposés, sur l’énumération des comptes techniques dans les annuaires et les applications, et sur l’interrogation des consoles cloud pour recenser les identités de charges de travail.
L’inventaire initial est presque toujours instructif. Il révèle des identités orphelines dont plus personne ne connaît l’usage, des secrets jamais renouvelés depuis leur création, des clés API dupliquées entre plusieurs services, et des privilèges sans commune mesure avec la fonction réelle de l’identité. Ce diagnostic fournit la base de priorisation des chantiers de remédiation.
Pilier 2 : la propriété
Chaque identité machine doit avoir un propriétaire identifié : une équipe ou une personne responsable de son cycle de vie, de ses privilèges et de sa désactivation en fin d’usage. Sans cette attribution, aucune décision ne peut être prise sur une identité donnée, faute d’interlocuteur capable de confirmer qu’elle est encore nécessaire.
L’attribution de propriété transforme une population anonyme d’identités techniques en un ensemble gouvernable. Elle conditionne la possibilité de mener des revues, de valider des rotations et de décommissionner sans risque les identités devenues inutiles.
Pilier 3 : la rotation automatisée
Un secret qui ne change jamais est un secret qui finira par fuir. La rotation régulière des secrets limite la fenêtre d’exploitation d’un secret compromis : même volé, il devient inutilisable après sa prochaine rotation.
La rotation manuelle ne passe pas à l’échelle des milliers d’identités d’un SI moderne. Elle doit être automatisée, ce qui suppose un gestionnaire de secrets (coffre-fort) capable de distribuer dynamiquement les secrets aux charges de travail qui en ont besoin, sans qu’ils soient jamais écrits en clair dans le code. L’orientation la plus mature consiste à supprimer les secrets statiques au profit de secrets à durée de vie courte, générés à la demande et expirant automatiquement. Les grands fournisseurs cloud documentent cette approche de bonnes pratiques de gestion des identités et des secrets applicatifs [3].
Pilier 4 : le moindre privilège
Le principe du moindre privilège s’applique aux machines comme aux humains : une identité ne doit disposer que des droits strictement nécessaires à sa fonction, et rien de plus. Or les identités machine sont fréquemment surprovisionnées, par facilité ou par méconnaissance du périmètre réel dont le service a besoin.
Réduire les privilèges d’une identité machine demande de comprendre finement ce qu’elle accomplit, ce qui n’est pas trivial. La démarche s’appuie sur l’analyse des accès réellement exercés, sur la restriction progressive des droits et sur la surveillance des refus d’accès pour détecter un privilège retiré à tort. Ce travail de resserrement réduit mécaniquement l’impact d’une compromission : un secret volé n’ouvre que ce à quoi l’identité avait légitimement droit.
Articulation avec le zero trust et l’IAM humain
La gouvernance des NHI ne constitue pas une discipline isolée. Elle s’inscrit dans le cadre plus large de l’architecture zero trust, dont la publication de référence du NIST (SP 800-207) pose les principes : ne faire confiance à aucune identité par défaut, vérifier explicitement chaque accès, et appliquer le moindre privilège de manière systématique [4]. Ces principes s’appliquent aux machines exactement comme aux humains. Une identité machine est un sujet zero trust à part entière : son accès doit être vérifié à chaque requête, contextualisé et limité. Notre article sur l’architecture zero trust en cinq étapes détaille cette logique de vérification permanente.
La gestion des NHI complète l’IAM et le PAM humains sans les remplacer. Les mécanismes diffèrent : une machine n’a pas de facteur multifacteur au sens où l’entend le NIST dans ses recommandations sur l’authentification numérique [5], et son cycle de vie ne suit pas le rythme d’un contrat de travail. Mais les objectifs convergent : savoir qui accède à quoi, avec quels droits, et pouvoir le révoquer instantanément. Une gouvernance des identités mature traite les deux populations, humaine et machine, dans une vision d’ensemble plutôt qu’en silos disjoints.
L’articulation vaut également pour les chaînes d’intégration et de déploiement. Les pipelines concentrent des identités machine à privilèges élevés, capables de déployer du code en production. Leur sécurisation relève à la fois de la gouvernance des NHI et des pratiques DevSecOps, comme nous l’exposons dans notre analyse de la sécurité de la chaîne CI/CD.
Le cas particulier des agents d’intelligence artificielle
L’essor des agents autonomes fondés sur des modèles de langage ajoute une dimension nouvelle au sujet. Un agent d’IA qui agit sur des systèmes réels a besoin d’identités machine pour s’authentifier auprès des services qu’il pilote : lire une base de données, appeler une API, déclencher une action. Ces identités héritent de toutes les problématiques décrites précédemment, avec une difficulté supplémentaire : le comportement de l’agent est moins prévisible qu’un script déterministe, ce qui complique la définition d’un périmètre de privilèges strict.
La sécurisation des identités attribuées aux agents d’IA devient un chantier à part entière, à la croisée de la gouvernance des NHI et de la maîtrise des risques propres à l’IA agentique, que nous traitons dans notre dossier sur l’IA agentique en entreprise. Le principe du moindre privilège y prend une importance décuplée : un agent surprovisionné et détourné de sa fonction peut causer des dégâts d’une ampleur inédite.
Une trajectoire de mise en oeuvre réaliste
Pour une organisation qui découvre l’ampleur du sujet, une trajectoire progressive sur plusieurs mois est réaliste, à condition d’un sponsoring de la direction et d’une coordination entre les équipes sécurité, infrastructure et développement.
Phase de diagnostic. Balayage des dépôts et des configurations à la recherche de secrets exposés, inventaire des comptes de service et des clés API actifs, cartographie des identités de charges de travail cloud. Cette phase produit un état des lieux chiffré et une liste de secrets à révoquer en urgence.
Phase de remédiation prioritaire. Révocation des secrets exposés dans les historiques de code, désactivation des identités orphelines confirmées, rotation des secrets les plus anciens et les plus privilégiés. Cette phase traite le risque immédiat le plus élevé.
Phase d’industrialisation. Déploiement d’un gestionnaire de secrets centralisé, intégration de la distribution dynamique des secrets dans les pipelines et les charges de travail, mise en place de la rotation automatisée, définition d’une politique de nommage et de propriété des identités machine.
Phase de gouvernance continue. Attribution systématique d’un propriétaire à chaque nouvelle identité, revue périodique des privilèges, surveillance des secrets nouvellement exposés, et intégration de la gestion des NHI dans les processus de sécurité existants. La démarche n’a pas de fin : elle devient une composante permanente de l’hygiène de sécurité, au même titre que la gestion des correctifs ou la sauvegarde.
Le point de départ n’est jamais le produit : c’est l’inventaire. Tant que l’organisation ignore combien d’identités machine elle possède, où elles se trouvent et à quoi elles servent, aucun outillage ne produira de résultat durable. La reprise en main des NHI commence par un exercice de connaissance de soi, souvent inconfortable, toujours indispensable.
Foire aux questions
Quelle différence entre une identité machine et un compte de service ?
Le compte de service est une catégorie particulière d’identité machine. L’expression identité non humaine (NHI) est plus large : elle englobe les comptes de service, mais aussi les clés API, les jetons OAuth et d’accès, les certificats client, les identités de charges de travail cloud et les secrets applicatifs. Toutes ces entités authentifient un logiciel ou une machine, et non une personne physique. Un compte de service est donc une NHI, mais toutes les NHI ne sont pas des comptes de service au sens strict de l’annuaire.
Un coffre-fort de secrets suffit-il à sécuriser les identités machine ?
Non. Un gestionnaire de secrets résout le stockage et la distribution des secrets, ce qui est nécessaire mais pas suffisant. La sécurité des NHI exige aussi un inventaire exhaustif, l’attribution d’un propriétaire à chaque identité, la rotation régulière des secrets, l’application du moindre privilège et la détection des secrets en clair déjà disséminés dans le code et les configurations. Le coffre-fort est un composant central de l’architecture, pas la totalité de la démarche.
Faut-il traiter les NHI avec le même outillage que l’IAM humain ?
Partiellement. Les principes sont communs : moindre privilège, revue d’accès, journalisation, révocation. Mais les mécanismes diffèrent. Une identité machine n’a pas de facteur multifacteur au sens humain, elle change rarement de contexte, et elle peut être créée ou détruite plusieurs fois par heure dans un environnement conteneurisé. L’outillage IAM traditionnel n’est pas conçu pour ce rythme. Les plateformes de gestion des NHI et des secrets complètent l’IAM/PAM humain plutôt qu’elles ne le remplacent.
Par où commencer quand on découvre l’ampleur du problème ?
Par l’inventaire. Tant que l’organisation ne connaît pas le nombre, la localisation et la fonction de ses identités machine, aucune décision de priorisation n’est fiable. La première étape consiste à scanner les dépôts de code et les fichiers de configuration à la recherche de secrets exposés, puis à recenser les comptes de service et les clés API actifs. Cet inventaire révèle presque toujours des identités orphelines, des secrets jamais renouvelés et des privilèges disproportionnés qui constituent les premières cibles de remédiation.
Références
[1] OWASP Foundation, Non-Human Identities Top 10, projet de référence sur les risques associés aux identités non humaines. [2] CERT-FR, panorama de la menace, rapports publiés par l’ANSSI sur les modes opératoires d’attaque observés en France. [3] Google Cloud, bonnes pratiques de gestion des identités et de la sécurité des secrets applicatifs. [4] NIST, Special Publication 800-207, Zero Trust Architecture. [5] NIST, Special Publication 800-63B, Digital Identity Guidelines, exigences relatives à l’authentification.
Sources primaires : OWASP NHI Top 10, NIST SP 800-207, NIST SP 800-63B, Cyber.gouv.fr, CERT-FR, Cybermalveillance.gouv.fr, ENISA.