Comptes orphelins : sécuriser l'offboarding IT et les accès

Si vous pilotez l'IT d'une entreprise de 50 à 500 personnes et qu'une revue des accès ou un audit ISO 27001 vient de faire remonter des comptes actifs au nom de personnes parties, cette page est pour vous. Si vous cherchez simplement la définition du déprovisionnement, la première section la donne en trente secondes.

Le déprovisionnement est le retrait des droits d'accès, des comptes et des habilitations d'un utilisateur lorsqu'il quitte l'entreprise, change de poste ou termine une mission. Un compte orphelin est ce qui reste quand ce retrait est incomplet : un compte actif sans propriétaire légitime. Corriger votre processus d'offboarding empêche l'apparition de nouveaux comptes orphelins. Cela n'en ferme aucun parmi ceux déjà ouverts, et ceux-là se trouvent surtout dans les applications que votre fournisseur d'identité n'a jamais couvertes.

Qu'est-ce que le déprovisionnement et que retire-t-il exactement ?

Le déprovisionnement est la moitié opérationnelle de la gestion du cycle de vie des identités, prise à l'envers. Là où le provisionnement crée une identité, attribue des habilitations et ouvre des accès, le déprovisionnement les retire : il désactive l'authentification, révoque les habilitations applicatives, met fin aux sessions ouvertes, réattribue les données détenues et retire les identifiants techniques comme les clés d'API et les jetons.

Il est déclenché par trois événements, pas un seul. Un départ met fin au contrat. Une mobilité interne change le poste et devrait faire perdre les habilitations attachées au précédent. Une mission ou un contrat de prestation se termine. Les deuxième et troisième déclencheurs sont ceux qui échouent silencieusement dans la plupart des entreprises, parce que seul le premier est en général branché sur le SIRH.

Un compte déprovisionné est-il désactivé ou supprimé ?

Les sources qui se positionnent sur cette question ne sont pas d'accord entre elles, et la différence a des conséquences juridiques. Beyond Identity décrit un accès retiré simultanément sur tous les systèmes. Delinea décrit un actif désactivé ou supprimé. Saviynt y ajoute le retrait des identifiants et des données personnelles. La politique informatique de l'université Fordham parle d'un accès suspendu ou désactivé.

L'arbitrage n'est pas affaire de préférence. Sous ISO/IEC 27001:2022, mesure 5.18 de l'annexe A, toute modification des droits d'accès d'un utilisateur doit être journalisée, et la mesure 6.5 couvre les responsabilités qui survivent à la fin du contrat. Vous ne produirez pas ce journal pour un compte que vous avez effacé. Côté RGPD, l'article 5(1)(e) limite la durée de conservation des données sous une forme identifiante, ce qui pousse dans l'autre sens.

La réponse praticable pour une DSI de PME : désactiver d'abord, supprimer selon un calendrier documenté. Désactivez immédiatement pour que le compte ne puisse plus s'authentifier, conservez l'enregistrement et son historique d'accès pendant la durée définie par votre politique de sécurité et votre registre de traitements, puis supprimez. La CNIL raisonne exactement en ces termes : une durée de conservation justifiée et documentée, pas une suppression réflexe. Qui vous conseille de supprimer dès le premier jour optimise le rangement au détriment de votre prochain audit.

Qu'est-ce qu'un compte orphelin ?

Un compte orphelin est un compte actif sans propriétaire identifiable, généralement laissé derrière lorsque le déprovisionnement a été incomplet. Il se distingue du compte dormant, qui a un propriétaire mais aucune activité récente, et du compte inactif, simplement inutilisé. Orphelin est la catégorie dangereuse, parce que personne n'est là pour remarquer la connexion. Le propriétaire peut être un ancien salarié, un ancien prestataire, ou personne du tout dans le cas d'un compte de service dont le créateur est parti. La définition complète du déprovisionnement figure au glossaire IT de Corma.

Votre offboarding est propre. Votre inventaire de comptes ne l'est pas.

L'essentiel de ce qui se publie sur le sujet traite le déprovisionnement comme un problème de processus : brancher correctement le déclencheur SIRH, connecter le fournisseur d'identité, dérouler la checklist. Ce conseil est juste et il règle le flux. Il ne fait rien sur le stock.

Le stock, ce sont les comptes déjà ouverts aujourd'hui, créés avant que votre processus ne soit resserré, dans des applications que ce processus n'a jamais couvertes. Aucun événement de départ ne se déclenchera pour eux, faute d'enregistrement de départ à l'origine. On les trouve par inventaire, pas par workflow.

L'ampleur de cet écart est visible dans les cas clients publiés par Corma. À chaque fois, l'entreprise disposait d'un inventaire qu'elle croyait juste, et la découverte a rendu un autre chiffre.

Satelia est le cas le plus net, parce que la conséquence est documentée. L'entreprise ne pouvait pas avancer vers ses certifications ISO 27001 et SOC 2 sans une vue auditable des SaaS réellement utilisés, et son propre récit attribue le déblocage à l'obtention de cette vue. L'histoire complète est publiée dans le cas client gouvernance des identités de Satelia.

Lisez ce tableau comme un rapport plutôt que comme une série de valeurs absolues. À toutes les tailles, de 30 à 340 salariés, le parc applicatif réel était nettement plus large que le parc suivi. Chaque application de cet écart peut héberger des comptes que votre processus de départ n'a jamais touchés.

Un avertissement sur les chiffres de risque que vous croiserez en documentant le sujet. La page actuellement première sur cette requête en anglais, le guide OneLogin sur le provisionnement et le déprovisionnement, cite encore un coût moyen de violation de données de 148 dollars par enregistrement et 7,91 millions de dollars par violation aux États-Unis, sur une page dont les métadonnées indiquent une modification au 21 août 2026. Ce chiffre est un chiffre IBM de 2018, et IBM a cessé depuis longtemps de raisonner en coût par enregistrement. L'édition 2026 du rapport IBM Cost of a Data Breach, publiée le 29 juillet 2026, situe la moyenne mondiale à 4,99 millions de dollars. Vérifiez le millésime de toute statistique de violation avant de la mettre dans une note au comité de direction.

D'où viennent réellement les comptes orphelins ?

De quatre endroits, et un seul est celui que décrivent la plupart des articles.

Les applications que votre fournisseur d'identité n'a jamais couvertes

Votre fournisseur d'identité fait autorité sur les applications qui lui sont connectées. Il est muet sur tout le reste. Une équipe achète un outil sur une carte bancaire d'entreprise, s'y connecte avec un e-mail et un mot de passe, et l'outil n'apparaît jamais dans le catalogue SSO. Au départ de la personne, désactiver son compte annuaire ferme la porte d'entrée et laisse cet outil intact.

Ce n'est pas une hypothèse. Sur r/sysadmin, un administrateur utilisant Okta pour le SSO décrivait une quarantaine d'applications jamais réellement intégrées à sa pile d'identité, dont des outils internes d'ingénierie. C'est exactement là que survivent les comptes orphelins, et le combler suppose une découverte qui fonctionne à l'intérieur comme à l'extérieur du périmètre SSO, par le navigateur et par le poste de travail plutôt que par le seul annuaire.

Les prestataires jamais entrés dans le SIRH

Freelances, personnel d'agence et experts en régie sont fréquemment intégrés en dehors des RH. Ils reçoivent des comptes, la mission se termine, aucun enregistrement de fin n'est créé, donc aucun déclencheur ne part. Le cadrage réglementaire est explicite : le règlement (UE) 2024/2690 impose de limiter en portée et en durée les droits d'accès des tiers, fournisseurs et prestataires compris, ce qui suppose de savoir qu'ils existent. C'est un point sensible en France, où le recours à la prestation et à la régie est structurel dans les DSI de PME.

Les mobilités internes, ces départs que personne ne déclare

Une mobilité interne est un départ partiel. La personne conserve son identité et devrait perdre un ensemble d'habilitations. En pratique, elles s'accumulent. Après deux ou trois mouvements, un salarié détient un jeu de droits qui reflète une carrière plutôt qu'un poste, et chaque habilitation abandonnée est une permission orpheline attachée à un compte vivant. La revue des accès est le contrôle qui les fait remonter.

Et si l'éditeur facture le SSO en supplément ?

L'objection revient sans arrêt et presque personne n'écrit dessus. Comme le formulait un responsable IT sur r/ITManagers, quand l'éditeur ne prend pas en charge le SSO ou le réserve à une offre supérieure, l'équipe ne peut rien faire au niveau de la couche d'identité. C'est une contrainte budgétaire, pas une décision de sécurité, et elle produit une population permanente de comptes hors périmètre.

La parade n'est pas de se battre contre la grille tarifaire. C'est de traiter ces applications comme une liste d'exceptions nommée, avec une étape d'offboarding manuelle ou pilotée par agent attachée, et de garder cette liste courte volontairement. Corma détaille les options techniques dans son guide sur l'offboarding des applications sans SCIM, SAML ni SSO.

Les comptes qui n'ont pas de date de départ

Comptes de service, jetons d'API, intégrations OAuth et agents IA sont des identités. Ils s'authentifient, détiennent des habilitations et déplacent des données. Ils n'ont ni contrat, ni manager, ni dernier jour, ce qui signifie qu'aucun processus piloté par les RH ne les déprovisionnera.

Nikolai Fomm, COO et cofondateur de Corma, posait le problème sans détour dans un article publié le 17 août 2026 : ces identités n'ont jamais été provisionnées par votre fournisseur d'identité, elles n'apparaissent pas dans votre checklist de départ, et la plupart n'ont pas de propriétaire. L'argumentation complète est dans le guide Corma sur la sécurité des identités non humaines.

C'est le volume qui surprend les équipes IT. Obsidian Security indique que ses clients arrivent typiquement avec environ 900 intégrations OAuth connectées à Google, 750 à Microsoft et 150 à Salesforce, et que plus de 70 % de ces intégrations sont inactives depuis 90 jours ou plus tout en conservant les habilitations accordées. Une clé d'API créée en 2022 pour une migration ponctuelle, collée dans un tableur et jamais révoquée, est fonctionnellement un identifiant permanent sans échéance.

Comment trouver les comptes orphelins que vous avez déjà

La découverte est un exercice de rapprochement. Vous cherchez les comptes qui existent dans une application sans personne active correspondante dans votre référentiel. Cinq étapes, dans cet ordre.

1. Fixez un référentiel. Exportez l'effectif actif depuis le SIRH, plus une liste séparée des prestataires et fournisseurs en cours. Sans cette liste, tout le reste est de la conjecture.
2. Exportez tous les comptes de toutes les applications connectées. Commencez par le fournisseur d'identité, puis parcourez application par application votre catalogue SSO. Vous obtenez la moitié facile.
3. Trouvez les applications absentes du catalogue. Recoupez les notes de frais et les relevés de carte, les listes d'autorisations OAuth dans Google Workspace et Microsoft 365, les journaux DNS ou proxy, et la télémétrie navigateur ou poste de travail. C'est cette étape qui fait passer de 30 applications connues à 160, et c'est celle que les audits manuels sautent.
4. Rapprochez et classez. Confrontez chaque compte à l'effectif. Tout compte non rapproché tombe dans l'une de quatre cases : départ, prestataire dont la mission est finie, mobilité avec habilitations résiduelles, ou identité non humaine sans propriétaire. Attribuez un propriétaire à chaque identité non humaine ou marquez-la pour retrait.
5. Consignez le constat avant d'agir. Notez le compte, l'application, la dernière connexion et la date de découverte. Cet enregistrement est votre preuve d'audit et votre base de comparaison pour la revue suivante.

L'étape 3 est celle où l'approche manuelle casse, parce qu'on n'inventorie pas des applications dont on ignore l'existence, et que la liste change tous les mois. Faire tourner cela comme un contrôle récurrent plutôt que comme un projet ponctuel fait la différence entre un audit propre et une non-conformité qui se répète. Les revues d'accès automatisées de Corma font remonter les comptes sans propriétaire selon un calendrier, et produisent les décisions des relecteurs sous forme de preuve, ce qui est exactement l'artefact que réclamera un auditeur.

Comment les fermer sans rien casser

Supprimer un compte qui détient un espace partagé, une relation de facturation ou une intégration de production provoque une panne. Travaillez dans cet ordre.

1. Désactivez d'abord l'authentification. Suspendez le compte et mettez fin aux sessions ouvertes. Le risque s'arrête immédiatement et l'action reste réversible en cas d'erreur de classement.
2. Vérifiez ce que le compte détient. Documents, agendas, dépôts de code, sièges de facturation, intégrations et automatisations. Réattribuez la propriété avant d'aller plus loin.
3. Révoquez les identifiants séparément. Désactiver un compte utilisateur ne tue pas toujours les jetons d'API, les jetons d'accès personnels et les autorisations OAuth créés par ce compte. Révoquez-les explicitement.
4. Récupérez la licence. Un compte orphelin est en général un siège payé. C'est la partie de l'exercice qui se finance elle-même.
5. Supprimez sur calendrier, pas sur impulsion. Appliquez la durée de conservation définie dans votre politique, puis supprimez et journalisez la suppression.

Le gain de temps est réel mais modeste par événement, et c'est bien pourquoi le stock compte plus que le flux. Une entreprise e-commerce de 30 personnes équipée de Corma déclare gagner entre 20 et 30 % du temps auparavant consacré à chaque onboarding et offboarding. Appliqué à un arriéré de plusieurs centaines de comptes non rapprochés, ce rapport est ce qui rend le nettoyage finissable.

Ce qu'attendent ISO 27001, NIS2 et le RGPD une fois les comptes trouvés

Trouver des comptes orphelins crée une obligation. Les auditeurs ne notent pas la découverte, ils notent ce que vous avez fait ensuite et votre capacité à le démontrer. Les trois cadres ci-dessous traitent différemment deux risques : l'accès non autorisé de quelqu'un qui ne devrait plus l'avoir, et l'incapacité à prouver que l'accès a bien été retiré.

Deux détails du règlement d'exécution NIS2 méritent une lecture attentive, car presque aucun contenu éditeur ne les couvre. D'abord, le point 11.5.1 de l'annexe impose de gérer le cycle de vie complet des identités des réseaux et systèmes d'information et de leurs utilisateurs, ce qui fait entrer les comptes de service et les identités machine dans l'obligation au lieu de les laisser au rang de bonne pratique. Ensuite, le point 12.5 impose, lorsqu'un actif ne peut être restitué ni supprimé à la fin du contrat, de garantir qu'il ne peut plus accéder aux systèmes. C'est une instruction directe sur l'accès résiduel dont traite cet article. Une définition d'ensemble figure dans l'entrée de glossaire sur la directive NIS2.

Une précision de périmètre souvent escamotée : le règlement (UE) 2024/2690 fixe ces exigences techniques pour une liste définie de types d'entités, dont les fournisseurs de services cloud, les centres de données, les fournisseurs de services managés, les places de marché en ligne et les prestataires de services de confiance. L'article 21(2) de la directive s'applique plus largement. En France, la transposition et la supervision relèvent de l'ANSSI, et le texte national fait foi sur le périmètre exact des entités concernées : vérifiez lequel vous vise avant de citer un numéro de paragraphe à votre direction. Sur le volet données personnelles, la CNIL est l'interlocuteur, pas l'ANSSI.

Corma est certifié ISO/IEC 27001:2022, audité chaque année par un tiers indépendant, et héberge les données de ses clients dans l'Union européenne.

La checklist de déprovisionnement qui empêche les nouveaux comptes orphelins

Une fois l'arriéré traité, le travail consiste à ne pas le reconstituer. Cette checklist couvre l'événement de départ lui-même.

• L'enregistrement de fin de contrat dans le SIRH est le déclencheur unique, et il part automatiquement.
• Compte annuaire suspendu et sessions terminées le dernier jour travaillé, pas la semaine suivante.
• Accès révoqués dans toutes les applications connectées, la liste d'exceptions hors SSO étant traitée explicitement plutôt qu'oubliée.
• Propriété des documents, agendas et dépôts transférée à une personne nommée.
• Jetons d'API, jetons d'accès personnels, autorisations OAuth et identifiants partagés créés par le compte révoqués ou renouvelés.
• Licences récupérées et l'économie consignée.
• Fins de mission et de contrat de prestation traitées comme des départs, avec le même workflow.
• Un compte rendu par départ produit automatiquement, pour que la preuve existe avant qu'on la demande.

La mécanique complète de cette mise en place, câblage SIRH vers fournisseur d'identité et fondations SCIM et SAML comprises, est traitée dans le guide Corma sur l'automatisation de l'onboarding et de l'offboarding IT. Ce guide traite le flux. Cette page traite le stock, et les deux sont faits pour être menés ensemble.

Pourquoi Corma

Corma est une plateforme européenne qui réunit le SaaS Management et la gestion des identités et des accès (IAM) dans un seul produit, ce qui rend le problème du stock traitable. La plupart des outils IAM gouvernent ce qui leur est déjà connecté, si bien que leur vue du parc est exactement aussi complète que vos intégrations. Corma commence par trouver ce qui n'est pas connecté, puis le gouverne, ce qui explique que les rapports de conformité reflètent le parc réel plutôt que le parc catalogué.

• Découverte dans et hors SSO, par le navigateur et le poste de travail autant que par les connecteurs API, ce qui fait apparaître les applications qu'un export d'annuaire ne voit pas.
• Revues d'accès automatisées qui signalent les comptes sans propriétaire et non rapprochés selon un calendrier récurrent, et consignent les décisions des relecteurs comme preuve.
• Workflows d'arrivée, de mobilité et de départ sans intervention, appuyés sur des connecteurs natifs à Google Workspace, Microsoft Entra ID, Okta et JumpCloud, de sorte que Corma gouverne au-dessus de votre fournisseur d'identité au lieu de le remplacer. Voir le provisionnement utilisateur automatisé.
• Détection des identités non humaines et de la shadow AI, qui couvre les autorisations OAuth, les comptes de service et les agents qu'aucun processus de départ n'atteint.
• Hébergement européen et certification ISO/IEC 27001:2022, avec un cadrage RGPD et NIS2 intégré au reporting plutôt que rapporté après coup.

Questions fréquentes

Quelle différence entre déprovisionner et supprimer un compte ?

Le déprovisionnement retire l'accès : il désactive l'authentification, révoque les habilitations et met fin aux sessions. La suppression retire l'enregistrement du compte lui-même, et avec lui son historique d'accès. Le déprovisionnement doit être immédiat. La suppression doit venir plus tard, sur une durée de conservation documentée, parce que l'enregistrement est la preuve qu'un évaluateur ISO 27001 ou SOC 2 réclamera.

Que veut dire déprovisionné ?

Un compte déprovisionné est un compte dont les droits d'accès, les permissions et les habilitations applicatives ont été retirés parce que la personne ou le système n'en a plus besoin. Cela suit normalement un départ, un changement de poste ou une fin de mission, et cela doit couvrir toutes les applications touchées par le compte, pas seulement l'annuaire.

Comment trouver des comptes orphelins dans des applications non connectées au SSO ?

Faites le rapprochement en dehors du fournisseur d'identité. Recoupez les notes de frais et les relevés de carte pour repérer les outils achetés, examinez les autorisations OAuth dans Google Workspace et Microsoft 365, consultez les journaux DNS ou proxy, et utilisez une découverte navigateur ou poste de travail. Comparez ensuite la liste d'utilisateurs de chaque application à votre effectif actif. Les comptes sans personne active correspondante sont vos candidats.

Que faire quand l'éditeur facture le SSO en supplément ?

Traitez ces applications comme une liste d'exceptions nommée plutôt que de faire comme si elles étaient couvertes. Attribuez un propriétaire à chacune, ajoutez une étape d'offboarding explicite, manuelle ou automatisée, au workflow de départ, et revoyez la liste chaque trimestre. Garder cette liste courte et visible est plus efficace que de payer chaque montée de gamme SSO.

Combien de temps un compte orphelin peut-il rester ouvert avant de devenir une non-conformité ?

Il n'existe pas de délai de grâce universel, et les auditeurs évaluent au regard de votre propre politique documentée. Pour les entités visées par le règlement (UE) 2024/2690, les identités devenues inutiles doivent être désactivées sans délai. En pratique, les comptes à privilèges sont attendus révoqués le jour même, et une population permanente de comptes non rapprochés est une non-conformité quel que soit l'âge de chacun d'eux.

Les comptes de service et les jetons d'API sont-ils des comptes orphelins ?

Ils le deviennent dès que personne ne les possède, ce qui est fréquent puisqu'ils n'ont pas de date de départ pour déclencher une revue. Le règlement (UE) 2024/2690 couvre explicitement le cycle de vie des identités des réseaux et systèmes d'information autant que celui de leurs utilisateurs : ils relèvent donc de la gouvernance, pas des options.