Sécurité des identités non humaines (NHI) : machines, comptes de service et agents IA

Sommaire

• Qu'est-ce qu'une identité non humaine ?
• NHI, identité machine et identité de charge de travail
• Pourquoi les NHI sont l'angle mort des DSI d'ETI
• Les quatre risques qui touchent réellement une entreprise de 50 à 500 salariés
• Ce que NIS2, le RGPD et l'ISO 27001 exigent sur les identités non humaines
• Une méthode de gouvernance en cinq étapes
• Comment intégrer les NHI à votre prochaine revue des accès
• Comment Corma gouverne les identités non humaines
• Questions fréquentes

La plupart des programmes de sécurité des identités sont construits autour des personnes : onboarding, SSO, MFA, offboarding, une revue des accès annuelle. Pendant ce temps, une seconde population s'est installée dans chaque stack SaaS, et personne ne l'a inscrite à l'organigramme. Comptes de service, clés API, autorisations OAuth entre deux outils SaaS, automatisations Zapier ou Make, et désormais agents IA dotés de leurs propres connecteurs.

Les estimations publiées sur l'écart entre ces identités et le nombre de salariés vont de 25 fois à plus de 100 fois, selon qui compte et ce qui est compté. La tendance, elle, ne fait pas débat. Mais pour une équipe IT de deux ou trois personnes dans une entreprise de 200 salariés, le problème est ailleurs : ces identités n'ont jamais été provisionnées via votre annuaire, elles n'apparaissent pas dans votre checklist de départ, et la plupart n'ont aucun propriétaire.

Cet article couvre la définition d'une identité non humaine, la distinction réelle entre les termes du marché, les quatre risques qui se matérialisent effectivement en ETI, ce qu'attendent NIS2, le RGPD et l'ISO 27001:2022, et une méthode de gouvernance en cinq étapes applicable avec les outils que vous avez déjà. Sans coffre-fort à secrets.

Qu'est-ce qu'une identité non humaine ?

Une identité non humaine (NHI, parfois traduit INH) est une identité numérique utilisée par un logiciel et non par une personne pour s'authentifier et accéder à des systèmes, ce qui couvre les comptes de service, les clés API, les jetons OAuth, les certificats, les charges de travail cloud et les agents IA.

Contrairement à une identité humaine, protégée par un mot de passe et un second facteur puis rattachée à un salarié nommé, une NHI s'authentifie avec un secret : un jeton, une clé ou un certificat. Cette différence produit trois conséquences qui expliquent tout le reste de l'article.

• Pas de MFA. Une machine ne valide pas une notification push, donc l'unique identifiant constitue toute la frontière de sécurité.
• Pas d'horaires de travail. Une NHI n'a pas de comportement normal dont elle pourrait s'écarter, ce qui rend la détection d'anomalie plus difficile.
• Pas de date de sortie. Les humains sont offboardés. Les secrets, eux, restent valides jusqu'à révocation explicite.

Les cinq familles d'identité non humaine

Dans un environnement SaaS d'ETI, les inventaires de NHI se répartissent en cinq catégories. La distinction compte parce que chaque famille est créée différemment, donc découverte différemment.

L'observation importante pour une entreprise de 50 à 500 salariés : le volume ne se trouve pas dans les charges de travail Kubernetes ni dans les certificats TLS mutuels. Il se trouve dans les autorisations OAuth et les comptes de service côté SaaS, créés par des collaborateurs qui connectent un outil à un autre.

NHI, identité machine et identité de charge de travail

Les trois termes sont employés indifféremment par les éditeurs, ce qui crée une vraie confusion en audit. Ce ne sont pas des synonymes, et la distinction est opérationnelle plutôt qu'académique.

• Identité non humaine est le terme générique. Il couvre toute identité qui n'est pas une personne.
• Identité machine est plus étroit et historiquement centré sur la PKI : il désigne généralement les identifiants cryptographiques (certificats X.509, TLS, clés SSH) qui permettent aux équipements et aux services de se faire confiance. C'est le vocabulaire des éditeurs de gestion du cycle de vie des certificats.
• Identité de charge de travail est encore plus restreint : une identité attribuée à une unité de calcul en cours d'exécution (conteneur, pod, fonction serverless), généralement éphémère et émise dynamiquement par la plateforme cloud.

Quel terme retenir dans votre politique de sécurité ?

Utilisez identité non humaine dans les documents de gouvernance et les preuves d'audit, car c'est le seul terme suffisamment large pour couvrir l'autorisation OAuth créée par votre équipe marketing le trimestre dernier. Réservez identité machine aux procédures de rotation de clés et de certificats, et identité de charge de travail à tout ce qui est cloud natif. Mélanger les trois dans une même politique, c'est ainsi que les comptes de service se retrouvent hors périmètre.

Si vos équipes clarifient encore le vocabulaire associé, le glossaire Corma de la gestion des identités et des accès couvre les termes adjacents, et gouvernance des identités contre gestion des identités précise où se situent les responsabilités.

Pourquoi les NHI sont l'angle mort des DSI d'ETI

Les identités non humaines constituent un angle mort parce qu'elles sont créées en dehors de l'annuaire, par des personnes qui ne sont pas à la DSI, pour des raisons parfaitement légitimes.

Combien de NHI, concrètement ?

Les ratios publiés varient fortement et méritent d'être lus avec leur source et leur date, car ils ne mesurent pas la même population. Les éditeurs de certificats comptent des certificats. Les éditeurs de sécurité SaaS comptent des intégrations. Les fournisseurs cloud comptent des charges de travail.

Traitez ces chiffres comme un ordre de grandeur, pas comme un benchmark. L'exercice utile consiste à compter les vôtres, ce qui est précisément l'étape 1 de la méthode ci-dessous.

Comment les NHI se créent sans que personne ne décide

Personne n'ouvre un ticket pour créer une identité non humaine. Les chemins habituels :

• Un responsable marketing connecte le CRM à la plateforme d'emailing et clique sur Autoriser dans un écran de consentement demandant un accès en lecture et écriture aux contacts.
• Un développeur génère un jeton API personnel pour bâtir un tableau de bord interne, puis quitte l'entreprise.
• Un analyste financier automatise un export avec Zapier, en utilisant ses propres identifiants comme connexion.
• Quelqu'un active un assistant IA dans un outil SaaS, et cet assistant hérite d'un connecteur aux permissions larges.

Chacune de ces actions crée un chemin d'accès durable et sans MFA. Aucune n'apparaît dans votre annuaire. C'est exactement le même problème de découverte que le shadow IT, et il appelle la même réponse : une découverte continue du parc SaaS plutôt qu'un registre d'actifs statique.

Pourquoi le SSO, le MFA et votre processus JML les manquent

Vos trois contrôles d'identité principaux sont structurellement aveugles aux NHI.

• Le SSO couvre les applications, pas les liaisons machine à machine entre elles. Une autorisation OAuth entre deux applications ne traverse pas votre annuaire à chaque appel.
• Le MFA ne peut pas s'appliquer à un jeton. C'est l'asymétrie la plus lourde : un attaquant détenant une clé API valide ne rencontre aucun second facteur.
• Le processus Joiner-Mover-Leaver désactive le compte humain. Les jetons créés par cette personne, et les automatisations qui tournent sous son nom, survivent généralement à l'offboarding. Notre guide sur la gestion du cycle de vie et de l'offboarding pour les applications sans SCIM, SAML ni SSO traite le versant manuel de cette faille.

Les quatre risques qui touchent réellement une entreprise de 50 à 500 salariés

Les contenus NHI destinés aux grands comptes se concentrent sur la compromission des pipelines CI/CD et le mouvement latéral dans Kubernetes. Ces risques sont réels, mais ce n'est pas ce qui casse dans une entreprise de 200 personnes. Ces quatre-là, oui.

1. Les identités orphelines qui survivent à leur créateur

Quand un collaborateur part, son compte utilisateur est désactivé. Le compte de service qu'il avait mis en place, le jeton API à son nom et la connexion Zapier qu'il avait construite continuent de fonctionner. Une NHI orpheline est une identité non humaine dont le propriétaire a quitté l'organisation, ou dont la finalité n'existe plus, mais dont les identifiants restent valides. C'est l'exemple le plus net d'un chemin d'accès qu'aucune revue ne détecte, parce qu'aucune revue ne le regarde.

2. Les autorisations OAuth sur-privilégiées

Les écrans de consentement OAuth sont optimisés pour l'éditeur de l'application, pas pour l'équipe sécurité. Un outil qui n'a besoin que de lire les disponibilités d'agenda demande fréquemment un accès complet à la boîte mail, parce que le périmètre grossier est plus simple à livrer. Obsidian Security rapportait en 2026 que les organisations comptent en moyenne 40 à 60 intégrations tierces par application SaaS critique, et que 15 à 25 % d'entre elles étaient inactives depuis plus de 90 jours tout en conservant l'intégralité de leurs permissions.

3. Les secrets statiques jamais renouvelés

Les mots de passe humains ont une politique d'expiration. Les clés API, rarement. Une clé générée en 2022 pour une migration ponctuelle, collée dans un tableur et jamais révoquée, est fonctionnellement un passe-partout permanent. Aucune alerte ne se déclenche à son usage, puisqu'aucune référence de comportement n'existe.

4. Les connecteurs d'agents IA sans propriétaire identifié

C'est la catégorie qui croît le plus vite et la moins gouvernée. Un agent IA s'authentifie comme n'importe quelle NHI, mais il agit avec beaucoup plus d'autonomie : il décide quels systèmes appeler et quelles données lire. Si votre inventaire d'agents ne répond pas à la question « qui a validé ceci, et jusqu'où cela peut-il aller », vous avez une faille de gouvernance qui sera examinée à votre prochain audit. Nous avons traité le versant opérationnel dans la gouvernance des agents IA et les défis pratiques dans les enjeux de gestion des agents IA pour les équipes IT. La variante non validée est couverte par l'essor du shadow AI.

Ce que NIS2, le RGPD et l'ISO 27001 exigent sur les identités non humaines

Aucun de ces textes ne contient l'expression « identité non humaine ». Tous s'y appliquent malgré tout, parce qu'ils sont rédigés en termes d'identités, de comptes et de droits d'accès, et non en termes de personnes. C'est là que les ETI européennes ont une obligation concrète et datée plutôt qu'une bonne pratique.

NIS2

L'article 21(2) de la directive NIS2 liste les mesures minimales de gestion des risques que doivent mettre en œuvre les entités concernées. Trois d'entre elles portent directement sur les identités non humaines :

• Les politiques de contrôle d'accès doivent couvrir tous les accès aux systèmes, et une clé API est un accès.
• La gestion des actifs suppose de savoir ce qui existe, ce qui inclut les identifiants.
• La sécurité des ressources humaines rejoint le processus de départ, précisément là où naissent les NHI orphelines.

L'article 21 exige également l'authentification multifacteur ou des solutions d'authentification continue lorsque cela est approprié. Puisque le MFA ne peut pas s'appliquer à un jeton, le contrôle compensatoire attendu est la gouvernance du cycle de vie : périmètres restreints, rotation et révocation. En France, l'ANSSI est l'autorité compétente sur NIS2. Pour le cadre général, voir notre guide sur ce que la directive NIS2 signifie pour votre entreprise.

RGPD et doctrine CNIL

Le sujet devient un sujet données personnelles dès qu'une NHI accède à des données de clients ou de salariés, ce qui est le cas de la plupart des intégrations CRM et RH.

• L'article 32 du RGPD impose des mesures techniques appropriées de sécurité du traitement, ce qui inclut le contrôle des accès, humains comme automatisés.
• L'article 30 impose la tenue d'un registre des traitements. Un agent IA qui lit une base de contacts participe à un traitement, et la CNIL attend que la chaîne d'accès soit documentée.
• La CNIL rappelle régulièrement que la limitation des accès aux seules personnes et systèmes qui en ont besoin est une mesure de base attendue. Un jeton API à permissions complètes détenu par un outil qui n'en a plus l'usage est une non-conformité documentable.

ISO/IEC 27001:2022

L'annexe A est plus explicite. Quatre mesures s'appliquent aux NHI sans ambiguïté :

• A.5.16 Gestion des identités : le cycle de vie complet des identités doit être géré, et la norme précise que des identités peuvent être attribuées à des entités non humaines.
• A.5.17 Informations d'authentification : attribution et gestion des secrets, donc la manipulation de vos clés API et jetons.
• A.5.18 Droits d'accès : attribution, revue et retrait des droits d'accès.
• A.8.2 Droits d'accès privilégiés : restriction et contrôle des accès élevés, que détiennent la plupart des comptes de service.

En pratique, un auditeur qui interroge la mesure A.5.16 acceptera une liste d'utilisateurs issue de votre annuaire. Un auditeur qui a lu la révision 2022 demandera aussi l'inventaire des comptes de service, avec un propriétaire par ligne. Notre guide d'implémentation ISO 27001 et IAM cartographie l'ensemble des mesures, et Corma est elle-même certifiée ISO/IEC 27001:2022.

Une méthode de gouvernance en cinq étapes

Nul besoin d'une plateforme de gestion des secrets pour démarrer. Il faut un inventaire, un propriétaire par ligne et une revue récurrente. Voici la séquence.

Étape 1 : découvrir

Constituez une liste unique de toutes les identités non humaines du parc. Puisez dans quatre sources : la liste des comptes de service de votre annuaire, l'inventaire des applications OAuth dans Google Workspace ou Microsoft Entra ID, l'écran des applications connectées de chacun de vos 20 principaux outils SaaS, et vos plateformes d'automatisation. Une plateforme de gestion SaaS le fait en continu plutôt que trimestriellement, ce qui compte puisque la population change chaque semaine.

Étape 2 : attribuer un propriétaire humain à chaque ligne

C'est l'étape au meilleur rendement, et elle ne coûte que de la persévérance. Chaque NHI reçoit une personne nommée, responsable de décider si elle doit encore exister. Une identité sans propriétaire est une décision en attente, et la décision par défaut doit être la révocation. Si le propriétaire a quitté l'entreprise, la ligne est par définition orpheline.

Étape 3 : appliquer le moindre privilège

Pour chaque identité, demandez ce dont elle a réellement besoin, pas ce qui lui a été accordé. Rétrogradez l'écriture en lecture quand l'usage le permet. Remplacez les comptes de service admin partagés par des comptes au périmètre restreint. Un cadrage cohérent est plus simple quand le modèle d'accès sous-jacent est propre, ce à quoi servent les modèles de contrôle d'accès RBAC et ABAC.

Étape 4 : revoir selon un calendrier

Les identités non humaines appartiennent au même cycle récurrent que les comptes humains. Trimestriel pour tout ce qui a un périmètre en écriture ou admin, annuel pour la lecture seule. La question de revue est étroite : cette identité a-t-elle encore une finalité, et son propriétaire est-il encore là ? Les revues d'accès automatisées transforment cet exercice de tableur en un workflow auditable.

Étape 5 : révoquer par défaut

Intégrez la révocation au processus de départ, pas à un projet séparé. Quand quelqu'un est offboardé, la checklist doit inclure les jetons qu'il a créés et les automatisations qui tournent sous son nom. Le provisionnement et déprovisionnement automatisés ferme la boucle côté humain, le versant NHI demande une ligne explicite dans le même runbook.

Comment intégrer les NHI à votre prochaine revue des accès

Le chemin le plus rapide vers la couverture n'est pas un nouveau programme. Ce sont trois colonnes supplémentaires dans la revue que vous menez déjà.

• Colonne 1 : type d'identité. Humain, compte de service, autorisation OAuth, clé API, ou agent IA. Cela seul révèle quelle part de votre surface d'accès était jusqu'ici hors périmètre.
• Colonne 2 : propriétaire responsable. Une personne, jamais un alias d'équipe. Les alias d'équipe sont la façon dont la responsabilité s'évapore.
• Colonne 3 : dernière utilisation. Toute identité inactive depuis plus de 90 jours avec un périmètre en écriture est un candidat à la révocation, pas un élément de revue.

Faites-la tourner une fois avec ces colonnes et le résultat sert immédiatement de preuve pour la mesure A.5.18 de l'ISO 27001. C'est aussi généralement le moment où une équipe découvre qu'un tiers de ses intégrations n'appartient à personne. Les clients Corma abordent le sujet par la gouvernance : Satelia, entreprise du secteur santé soumise à de fortes contraintes de protection des données, utilise Corma pour la gouvernance des identités en environnement réglementé, et Brevo pilote la gestion SaaS à l'échelle sur un parc applicatif étendu.

Comment Corma gouverne les identités non humaines

La plupart des outils NHI ont été conçus pour des équipes sécurité de grands comptes et supposent un coffre-fort à secrets, un programme PKI et des effectifs dédiés. Corma prend le problème par l'autre bout, parce que les NHI qui comptent dans une ETI vivent dans les applications SaaS, pas dans l'infrastructure.

Corma est une plateforme européenne de gestion SaaS et de gouvernance des identités qui découvre, attribue et revoit les accès humains et non humains de tout votre parc SaaS depuis un inventaire unique. Concrètement :

• Découverte sur l'ensemble du parc SaaS, y compris les autorisations OAuth et les applications connectées qui n'ont jamais touché votre annuaire, via des connecteurs natifs vers Google Workspace, Microsoft Entra ID, Okta et JumpCloud.
• Attribution de propriété, pour que chaque compte de service et chaque intégration ait un responsable humain plutôt qu'un champ vide.
• Revues d'accès incluant les identités non humaines dans le même cycle auditable que les salariés, produisant la piste de preuve qu'un auditeur ISO 27001 ou NIS2 réclame.
• Un offboarding qui atteint les jetons, pas seulement le compte utilisateur, via le provisionnement et déprovisionnement automatisés des utilisateurs.
• Hébergement européen et architecture nativement conforme au RGPD, avec la certification ISO/IEC 27001:2022, ce qui compte quand l'inventaire d'identités contient lui-même des données personnelles.
• Une reconnaissance au Gartner Magic Quadrant 2025 des SaaS Management Platforms, avec une approche convergée de la gouvernance des identités que la plupart des éditeurs répartissent sur deux produits distincts.

Les équipes IT qui pilotent les deux volets trouveront la vue métier sur la page solution IAM Corma pour les équipes IT, et les équipes sécurité sous contrainte d'audit sur la page solution IAM Corma pour les équipes de sécurité.

Envie de voir votre propre inventaire d'identités non humaines ? Demandez une démo et nous passerons en revue les autorisations OAuth et les comptes de service de votre parc.

Questions fréquentes

Qu'est-ce qu'une identité non humaine ?

Une identité non humaine est une identité numérique utilisée par un logiciel et non par une personne pour s'authentifier et accéder à des systèmes. Elle couvre les comptes de service, les clés API, les jetons OAuth, les certificats, les charges de travail cloud et les agents IA. Sa caractéristique déterminante est qu'elle s'authentifie avec un secret au lieu d'un mot de passe accompagné d'un second facteur.

Quels sont des exemples d'identités non humaines ?

L'exemple le plus courant en environnement SaaS est l'autorisation OAuth : quand un collaborateur connecte son CRM à un outil d'emailing et valide la demande de permissions, une identité non humaine durable est créée entre les deux applications. Autres exemples quotidiens : un compte de service reliant un outil de reporting à une base de données, une clé API alimentant un tableau de bord interne, et une automatisation Zapier tournant sous les identifiants d'un salarié.

Les agents IA sont-ils des identités non humaines ?

Oui. Un agent IA s'authentifie avec un identifiant et agit sans intervention humaine directe à chaque action, ce qui en fait une identité non humaine par définition. Il diffère d'un compte de service classique par son autonomie : un agent décide quels systèmes appeler et quelles données lire, donc la restriction de périmètre et l'attribution d'un propriétaire comptent davantage, pas moins.

Quelle est la différence entre une identité non humaine et une identité machine ?

Identité non humaine est le terme générique désignant toute identité qui n'est pas une personne. Identité machine est un sous-ensemble plus étroit et historiquement centré sur la PKI, qui désigne les identifiants cryptographiques comme les certificats X.509, TLS et les clés SSH permettant aux équipements et aux services de se faire confiance. Toute identité machine est une identité non humaine, mais une autorisation OAuth entre deux applications SaaS est une identité non humaine que la plupart des outils d'identité machine ne couvrent pas.

Qui est responsable de la sécurité des identités non humaines ?

La responsabilité incombe à qui porte la gouvernance des identités, généralement le DSI ou le RSSI, mais le modèle ne fonctionne que si chaque identité prise individuellement a un propriétaire humain nommé. Les identités sans propriétaire sont la cause première de la plupart des incidents NHI, car personne n'est en position de décider si l'identité doit encore exister.

Les identités non humaines créent-elles un risque de non-conformité RGPD ?

Oui, dès qu'elles accèdent à des données personnelles. L'article 32 du RGPD impose des mesures de sécurité appropriées incluant le contrôle des accès, sans distinguer accès humain et accès automatisé, et l'article 30 impose de documenter les traitements. Une clé API à permissions complètes détenue par un outil qui n'en a plus l'usage, et accédant à une base clients, est une non-conformité documentable. Les mesures A.5.16, A.5.17, A.5.18 et A.8.2 de l'ISO 27001:2022 vont dans le même sens.

Peut-on appliquer le MFA à une identité non humaine ?

Non. Une machine ne peut pas répondre à un défi de second facteur, ce qui explique que l'unique identifiant constitue toute la frontière de sécurité. Les contrôles compensatoires admis sont les permissions restreintes, les identifiants à durée de vie courte quand la plateforme le permet, la rotation des secrets, et une revue récurrente avec révocation de tout ce qui est inutilisé.