À retenir

• Le provisioning attribue des droits dans les systèmes cibles ; le compte est le support technique nécessaire pour les porter, pas l’objet du processus. Le déprovisioning retire ces droits, et agit sur le compte selon le contexte. Les deux sont l’exécution technique des décisions du cycle de vie (JML).
• Trois modes coexistent : automatique (déclenché par un changement de l’identité numérique), sur demande (avec ou sans workflow d’approbation selon la sensibilité), et à la volée via la fédération d’identité.
• SCIM (RFC 7643 et RFC 7644) est le standard IETF du provisioning entre systèmes. En production, il s’est imposé pour la synchronisation fournisseur d’identité → applications SaaS, mais reste peu utilisé pour les applications métier internes, qui passent par des connecteurs propriétaires.
• Le déprovisioning est plus complexe qu’on ne le présente : retirer un droit ne se limite pas à désactiver un compte. L’ordre des opérations, la révocation des sessions actives et la conservation légale exigent une discipline propre.

Introduction

Le besoin ne part jamais d’un compte : il part d’un droit. Une personne doit pouvoir faire quelque chose de précis — lire une donnée, modifier un dossier, approuver une transaction. Le compte n’est que le véhicule technique nécessaire pour porter ce droit dans l’application qui héberge l’action. Inverser cette logique — penser « créer un compte » comme la tâche initiale — conduit aux dérives les plus courantes en gestion des accès : comptes créés sans usage clair, droits attribués par recopie d’un collègue, comptes survivant à leur utilité parce que personne ne sait quels droits ils portaient vraiment.

Provisionner, c’est donc d’abord attribuer un droit légitime ; créer le compte (s’il n’existe pas déjà) et propager les permissions associées ne sont que la suite mécanique. Symétriquement, déprovisionner, c’est d’abord retirer un droit qui n’a plus lieu d’être ; agir ensuite sur le compte selon le contexte. Cet article traite le provisioning et le déprovisioning sous cet angle : les modes possibles, le standard SCIM et sa zone d’usage réelle, et les pièges du déprovisioning.

Définitions

Le provisioning désigne l’attribution effective de droits dans les applications, annuaires et systèmes cibles — ainsi que les opérations techniques qu’elle implique : créer ou activer le compte qui porte ces droits quand il n’existe pas, mettre à jour ses attributs, propager les permissions. Le compte n’est pas l’objet du provisioning, il en est le support.

Le déprovisioning est l’opération inverse : retirer des droits qui n’ont plus lieu d’être, et agir sur le compte selon le contexte (le laisser actif sans droits, le désactiver, le supprimer à terme).

Une précision importante, déjà évoquée dans l’article sur le cycle de vie des identités (JML) : provisioning et déprovisioning sont l’exécution technique de décisions prises ailleurs — un changement de l’identité numérique (événement venant du SIRH ou d’un référentiel d’externes, évolution du modèle d’habilitations, demande validée). JML décrit quand et pourquoi il faut agir ; provisioning et déprovisioning décrivent comment. Confondre les deux conduit à des projets qui automatisent des actions sans gouverner les déclencheurs.

L’ISO/IEC 27001:2022 encadre ces opérations à travers ses contrôles 5.16 (gestion des identités) et 5.18 (droits d’accès), qui attendent une gestion structurée de l’attribution et du retrait des accès.

Pourquoi automatiser

L’automatisation du provisioning n’est pas un luxe à mesure que les volumes augmentent : un nouvel arrivant opérationnel dès le premier jour suppose que ses comptes existent et soient correctement provisionnés avant son arrivée. À l’inverse, un départ traité manuellement laisse presque toujours des comptes actifs plusieurs jours, voire plusieurs semaines.

Les bénéfices attendus sont classiques : rapidité, cohérence (les mêmes règles s’appliquent uniformément), traçabilité (chaque action laisse une trace exploitable en audit), réduction des erreurs humaines.

Une réserve honnête à poser, en revanche : automatiser un processus mal défini revient à industrialiser le désordre. Si le modèle de rôles est instable ou si les données d’autorité (SIRH, référentiel des prestataires) sont fausses, l’automatisation propage les erreurs à grande vitesse. La condition d’un provisioning automatique efficace est un cycle de vie maîtrisé et un modèle de rôles assaini — sujets traités dans les articles sur le role mining et sur le JML.

Les modes de provisioning

Trois modes coexistent en pratique, et la plupart des organisations en combinent au moins deux.

Provisioning automatique

Déclenché par un changement de l’identité numérique dans la plateforme de gouvernance, sans intervention humaine sur les droits du socle. Plusieurs types de changements peuvent jouer ce rôle, selon la population et la maturité de l’organisation : un événement venant du SIRH (embauche, mobilité, départ) pour les salariés ; un événement venant d’un référentiel dédié aux prestataires et externes (qui ne sont pas dans le SIRH) ; un changement d’attributs de l’identité ; une nouvelle règle d’habilitation dans le modèle de rôles, qui ré-évalue l’attribution pour les identités déjà existantes. C’est le mode le plus efficace, à condition que les sources d’autorité couvrent bien toutes les populations et que les règles d’attribution soient clairement définies — sinon, l’automatisme propage les angles morts du modèle.

Provisioning sur demande (request-based)

Pour les droits qui ne relèvent pas du socle, l’utilisateur (ou son manager) en fait la demande via un portail dédié. L’attribution peut être directe ou soumise à approbation, selon la sensibilité du droit et la politique en vigueur. Pour un accès anodin — typiquement l’ajout à une application standard, à un groupe de distribution, à un outil collaboratif — un mécanisme en self-service, sans validation, est souvent suffisant et accélère l’opérationnel. Pour un droit sensible (accès financier, données à caractère personnel, droits à privilèges), un ou plusieurs niveaux de validation sont mis en place, par le manager, le propriétaire de l’application, voire un comité dédié. La règle utile : graduer le niveau d’approbation à la sensibilité, plutôt que d’imposer un workflow uniforme qui finit par être contourné.

Birthright et request-based

Ces deux termes ne désignent pas des modes techniques mais une classification fonctionnelle des droits :

• Les droits birthright sont attribués automatiquement à la création de l’identité, en fonction du rôle, de l’entité et de la localisation (messagerie, accès aux applications de base, droits métier du poste).
• Les droits request-based sont attribués sur demande explicite, souvent avec approbation.

Cette distinction structure la conception : trop de droits classés birthright conduit au sur-provisionnement ; trop de droits classés request-based alourdit l’expérience et ralentit l’opérationnalisation.

Provisioning à la volée (JIT)

Dans les architectures de fédération d’identité, le compte cible peut être créé au premier accès : l’utilisateur s’authentifie auprès du fournisseur d’identité (IdP), une assertion est envoyée à l’application, qui crée son compte localement à partir des attributs reçus. Ce mode évite les comptes dormants (s’il n’accède pas, aucun compte n’est créé) mais complique la gouvernance : le compte existe sans avoir été tracé en amont.

SCIM : le standard, et son cas d’usage réel

Le standard SCIM (System for Cross-domain Identity Management) mérite d’être expliqué clairement, parce qu’il est peu présent dans le contenu francophone et souvent mal situé : on le présente comme le standard universel du provisioning, alors que sa zone d’usage réelle est plus restreinte — et c’est utile à savoir avant de bâtir une stratégie.

SCIM est défini par deux RFC de l’IETF, publiées en septembre 2015 et toujours actives :

• RFC 7643 spécifie le schema : la structure des objets manipulés — utilisateurs, groupes, attributs.
• RFC 7644 spécifie le protocole : une API REST avec des opérations standardisées pour créer, lire, mettre à jour et supprimer ces objets.

Les deux ont le statut Proposed Standard — le statut courant des protocoles IETF en usage industriel (OAuth 2.0 et HTTP/2, par exemple, sont au même niveau). Le standard continue d’évoluer par incréments : la RFC 9865 (2025) a ajouté la pagination par curseur, la RFC 9967 (2026) un profil pour les Security Event Tokens. Côté norme, SCIM est stable et vivant.

Là où SCIM s’est imposé

Le cas d’usage dominant en production est la synchronisation fournisseur d’identité (IdP) → applications SaaS. L’annuaire central — Microsoft Entra ID, Okta, Google Workspace, Ping — pousse les identités et leurs groupes vers les SaaS modernes : Salesforce, Slack, Zoom, GitHub, AWS, Box, ServiceNow et bien d’autres. SCIM est devenu, sur ce périmètre, la norme attendue : un SaaS B2B sérieux qui veut être enterprise-ready implémente un connecteur SCIM. C’est efficace et largement déployé.

Là où SCIM reste marginal

Le tableau change pour le provisioning vers les applications métier internes (ERP, applications historiques, outils sectoriels propriétaires). Là, SCIM est peu implémenté, et le provisioning passe par des connecteurs propriétaires maintenus par les éditeurs IGA : LDAP vers les annuaires, API REST spécifique à chaque application, JDBC pour certaines bases, fichier plat pour les plus anciennes. C’est précisément la valeur ajoutée des bibliothèques de connecteurs d’un Sailpoint, d’un Saviynt ou d’un éditeur IGA français.

Une autre limite à connaître : SCIM 2.0 est centré sur les utilisateurs et les groupes. Pour les droits applicatifs fins — rôles SAP avec leurs permissions transactionnelles, autorisations métier propriétaires, profils ERP — le schema standard ne suffit pas. Des extensions sont possibles mais ne sont pas universelles, et beaucoup d’implémentations SCIM se contentent en pratique de synchroniser l’identité et l’appartenance à des groupes, laissant les droits fins à la mécanique interne de chaque application.

La traduction pratique

Une stratégie de provisioning réaliste ne mise donc pas tout sur SCIM. Elle privilégie SCIM partout où il est disponible (typiquement les SaaS), et accepte d’utiliser des connecteurs propriétaires pour le reste — en évaluant honnêtement leur granularité et leur capacité à propager les droits métier, et pas seulement l’identité.

Le déprovisioning, plus difficile qu’il n’y paraît

La SERP française traite généralement le déprovisioning comme « le contraire du provisioning ». C’est insuffisant. Quatre aspects, rarement décrits, lui donnent sa réelle complexité.

Les opérations qui composent le déprovisioning. « Déprovisionner » recouvre plusieurs opérations distinctes, qui ne s’enchaînent pas mécaniquement : retirer les droits (permissions, appartenance à des groupes, rôles), désactiver le compte (empêcher la connexion, sans toucher au reste), supprimer le compte (effacement définitif). Le périmètre choisi dépend du contexte. Une mobilité temporaire — détachement, mission externe, congé long — peut conduire à retirer les droits opérationnels tout en gardant le compte actif. Un départ définitif conduit en général à désactiver le compte (souvent immédiatement) puis à le supprimer après la période de conservation requise. Une obligation de conservation peut conduire à maintenir durablement un compte sans aucun droit opérationnel, accessible seulement à des fins légitimes (consultation des données personnelles par l’intéressé, archive métier, traçabilité). Confondre les trois opérations en une seule routine appliquée systématiquement appauvrit la gestion du cycle de vie.

L’ordre des opérations quand on veut bloquer l’accès rapidement. Quand l’objectif est précisément de couper l’accès vite — départ sensible, incident, suspicion d’usage abusif — l’ordre compte. Désactiver le compte n’invalide pas automatiquement les sessions actives, ni les jetons (OAuth, refresh tokens en particulier) émis avant la désactivation. Avec des jetons de longue durée, l’accès peut rester possible plusieurs heures ou plusieurs jours après la désactivation. L’ordre correct, dans ce cas, est : révoquer les sessions actives, révoquer les jetons, puis désactiver le compte. Sauter une étape laisse une fenêtre d’accès non maîtrisée.

La conservation légale. Toutes les données rattachées à un compte ne disparaissent pas avec lui : obligations de conservation (sociales, fiscales, archives métier), continuité d’accès à des dossiers en cours par un successeur, transfert de propriété de ressources (fichiers partagés, boîtes mail). Un déprovisioning bien conçu prévoit explicitement ces cas, généralement avec une désactivation de l’accès actif distincte de la suppression définitive du compte.

Les comptes orphelins et dormants. Un compte orphelin est un compte sans propriétaire identifié — souvent hérité d’un projet ou d’une période où la gouvernance n’existait pas. Un compte dormant est un compte qui n’a pas été utilisé depuis longtemps ou jamais. Les deux représentent une surface d’attaque silencieuse, qui n’apparaîtra dans aucune campagne JML — il faut les chercher activement par des analyses d’usage et de propriété.

La limite des connecteurs

L’IGA ne voit que ce que ses connecteurs lui rapportent. Une permission ajoutée directement dans une application — par un administrateur local, par une exception accordée en ligne de commande, par un import oublié — peut être totalement invisible côté IGA.

C’est l’une des raisons pour lesquelles la réconciliation est indissociable du provisioning : confronter périodiquement l’état attendu côté IGA à l’état effectif dans les applications, et traiter les écarts explicitement. Sans elle, le provisioning se fait sur une représentation possiblement fausse de la réalité. Ce point est traité plus largement dans l’article sur la recertification des accès.

Mettre en place provisioning et déprovisioning

Une démarche viable suit en général ces étapes :

1. Cartographier les applications cibles et leurs capacités techniques : SCIM ? API REST ? LDAP ? Import de fichier ? Cette photographie conditionne la stratégie.
2. Définir le mode par application en fonction de la criticité, du volume et de la faisabilité technique : automatique pour les applications à fort volume et à droits standardisés, sur demande avec workflow pour les droits sensibles ou exceptionnels.
3. Définir les SLA. Pas le même délai cible pour provisionner un Joiner que pour déprovisionner un Leaver. Ces délais doivent être explicites et mesurés.
4. Brancher progressivement, en commençant par les applications à plus fort volume et à plus forte stabilité de modèle de rôles. Tenter de tout brancher d’un coup multiplie les risques.
5. Prévoir la réconciliation dès le départ, pas en après-coup. C’est elle qui garantit que l’automatisation reste alignée sur la réalité.

Au moment de définir les workflows d’attribution, il est utile d’intégrer dès le départ les contrôles de séparation des tâches : un provisioning qui ignore les conflits SoD à l’attribution les crée mécaniquement, et il sera bien plus coûteux de les rattraper en recertification que de les bloquer à la source.

Erreurs fréquentes

• Tout automatiser sans avoir assaini le modèle de rôles. L’automatisation propage les erreurs aussi vite que les bonnes pratiques.
• Choisir des connecteurs trop limités en granularité, qui n’attribuent qu’un niveau d’accès grossier alors que les besoins sont fins.
• Absence de réconciliation. L’IGA croit que les accès sont alignés alors que la réalité a divergé.
• Déprovisioning incomplet : compte désactivé mais sessions ou jetons actifs ; suppression de compte sans transfert des données ; oubli des comptes orphelins.
• Confondre suspension et suppression. Une suspension temporaire (congé long, mission externe) ne se gère pas comme un départ.

FAQ

Quelle différence entre provisioning et déprovisioning, et JML ? JML décrit les événements de cycle de vie (arrivée, mobilité, départ). Provisioning et déprovisioning sont les actions techniques exécutées en réaction à ces événements. JML déclenche, provisioning exécute.

Qu’est-ce que SCIM, concrètement ? SCIM (System for Cross-domain Identity Management) est un standard de l’IETF (RFC 7643 et RFC 7644) qui définit comment provisionner et déprovisionner des utilisateurs et des groupes entre systèmes via une API REST normalisée. En production, son cas d’usage dominant est la synchronisation d’un fournisseur d’identité (Entra ID, Okta, Google Workspace…) vers des applications SaaS. Pour les applications métier internes, les connecteurs propriétaires restent largement utilisés.

Faut-il toujours automatiser le provisioning ? Non. Pour les droits standardisés à fort volume, l’automatisation est nettement avantageuse. Pour les droits sensibles ou peu fréquents, le provisioning sur demande — avec approbation quand la sensibilité le justifie — reste pertinent : il ajoute le contrôle d’un humain au plus près de la décision. Le bon choix est par application et par type de droit, pas global.

Pourquoi un compte désactivé peut-il encore poser problème ? Parce que la désactivation du compte n’invalide pas automatiquement les sessions actives ou les jetons (OAuth, refresh tokens) émis avant elle. Sans révocation explicite de ces éléments, l’accès peut rester possible pendant la durée de vie des jetons. Un déprovisioning rigoureux invalide les sessions et révoque les jetons avant de désactiver le compte.

Conclusion

Le provisioning et le déprovisioning sont l’exécution opérationnelle de toute la gouvernance des identités — et c’est précisément ce qui rend leurs erreurs visibles : un Joiner sans compte, c’est un onboarding raté ; un Leaver mal traité, c’est un risque de sécurité. Leur réussite tient d’abord à la cartographie honnête des capacités techniques des applications cibles, à la combinaison réfléchie des modes (automatique, sur demande, à la volée), et au bon emploi des standards là où ils sont effectivement supportés — SCIM côté IdP-SaaS, connecteurs propriétaires pour le reste. Pour démarrer concrètement, le plus utile est de partir d’une application à fort volume et à modèle stable, de la connecter en SCIM ou via un connecteur robuste, et d’établir la pratique de réconciliation dès le départ — avant d’élargir.

Sources

• ISO/IEC 27001:2022, Annexe A — contrôles 5.16 (gestion des identités) et 5.18 (droits d’accès).
• IETF — RFC 7643, System for Cross-domain Identity Management: Core Schema (schéma SCIM).
• IETF — RFC 7644, System for Cross-domain Identity Management: Protocol (protocole SCIM, API REST).