Provisionnement SCIM : pourquoi le déprovisionnement est l'étape que tout le monde rate

Qu'est-ce que SCIM concrètement ?

SCIM signifie System for Cross-domain Identity Management. Il s'agit d'une norme ouverte — schéma dans la RFC 7643, protocole dans la RFC 7644 — qui définit une API REST pour transférer des données d'identité entre systèmes. La version 2.0 est celle implémentée par tous les principaux fournisseurs d'identité.

Le concept est plus simple que l'acronyme. Votre IdP est le client, l'application en aval est le serveur. L'IdP détient une liste de personnes et de groupes, et lorsqu'elle est modifiée, il envoie une requête HTTP pour le signaler.

SCIM définit deux collections de ressources, sur lesquelles repose l'intégralité du protocole :

L'avant-dernière ligne est la plus importante. SCIM dispose d'une méthode standard de premier ordre pour dire : cette personne ne doit plus avoir accès — et ce signal provient de l'endroit où le départ de quelqu'un est déjà enregistré, c'est-à-dire l'identité gérée par les RH, et non une feuille de calcul détenue par le service informatique.

SCIM n'est pas le SSO, et la différence est cruciale

Le SSO répond à une question au moment de la connexion : cette personne est-elle bien celle qu'elle prétend être, à cet instant précis ? Une assertion SAML ou un jeton OIDC arrive, l'application le valide et la session démarre.

SCIM répond à une question en continu : cette personne doit-elle toujours exister ici ? Il s'exécute selon son propre calendrier, indépendamment de toute tentative de connexion.

L'écart entre les deux constitue tout le problème. Si vous utilisez le SSO avec une création de compte juste-à-temps (JIT) sans rien d'autre, votre IdP garde la porte d'entrée tandis que les comptes s'accumulent indéfiniment derrière. Désactiver quelqu'un dans l'IdP bloque certes les nouvelles connexions, mais l'objet compte reste présent, toujours associé aux rôles, aux appartenances et — ce qui est particulièrement critique sur une plateforme d'IA — aux clés API et jetons de service qu'il a pu collecter.

Pourquoi le déprovisionnement est l'étape que tout le monde néglige

L'onboarding est un échec bruyant. L'offboarding est un échec silencieux. Cette asymétrie explique la quasi-totalité des conclusions d'audits d'accès que nous avons pu observer.

Personne ne se plaint d'avoir des accès qu'il ne devrait pas avoir. Lorsque le provisioning échoue, un nouvel ingénieur le signale dans un canal de discussion en moins de vingt minutes. Lorsque le déprovisionnement échoue, le bénéficiaire a déjà quitté l'entreprise. Il n'y a aucune boucle de rétroaction, le défaut persiste donc jusqu'à ce qu'un auditeur s'en aperçoive.

Les listes de contrôle de départ manuel deviennent obsolètes. La liste de contrôle est rédigée lorsque l'entreprise utilise huit outils SaaS. Deux ans plus tard, elle en compte soixante, et la liste en contient toujours huit.

Le temps de latence est long. Comme rien ne met le problème en évidence, les comptes orphelins se comptent généralement en mois, et ils ne sont découverts que lors d'un audit ou d'un incident — les deux pires moments pour les trouver.

Sur les plateformes d'IA, un compte orphelin est bien plus qu'une simple connexion. Un enregistrement utilisateur obsolète peut être lié à des identifiants de fournisseur de modèles, à un accès serveur MCP, à des charges de travail déployées et à des clés API à longue durée de vie. Les sessions de navigateur expirent d'elles-mêmes. Les identifiants programmatiques, non. C'est pourquoi l'authentification API et le contrôle d'accès basé sur les rôles (RBAC) dans une passerelle d'IA doivent être basés sur l'identité plutôt que sur la clé — une clé sans propriétaire est une clé que personne ne révoquera jamais.

SCIM supprime l'intervention humaine. Le départ est enregistré une seule fois, dans l'IdP, puis se propage vers l'extérieur.

SCIM vs JIT vs sur invitation uniquement : quel mode de provisionnement choisir

TrueFoundry prend en charge trois modes de provisionnement, et un locataire n'en utilise qu'un seul à la fois. C'est la décision que la plupart des équipes essaient réellement de prendre lorsqu'elles recherchent SCIM.

Trois points ressortent de ce tableau.

JIT n'est pas un SCIM simplifié. C'est la moitié de SCIM — la moitié visible. Il gère efficacement et sans configuration le cas d'une nouvelle personne ayant besoin d'un compte. Il ne fait rien pour le départ d'une personne. Si votre raison de choisir JIT est « nous gérerons le départ manuellement », déterminez honnêtement qui est responsable de cette étape et comment elle est auditée.

L'option « sur invitation uniquement » n'est pas moins bonne, elle est différente. Pour un prestataire externe travaillant dans une entreprise partenaire sans enregistrement dans votre IdP, l'invitation est le mécanisme approprié. Le problème survient lorsque vous l'utilisez pour des employés qui sont dans votre IdP, car vos administrateurs deviennent alors une réplique manuelle d'un système pour lequel vous payez déjà.

La synchronisation des groupes est la ligne que les gens sous-estiment. Créer des utilisateurs automatiquement permet de gagner quelques minutes par embauche. La synchronisation des groupes est ce qui garantit l'exactitude des autorisations au fil du temps — un coût permanent plutôt qu'unique.

Où les équipes font fausse route

Confondre SSO et déprovisionnement. C'est l'erreur la plus courante, et elle est compréhensible, car désactiver un utilisateur dans l'IdP bloque effectivement les nouvelles connexions. Cependant, cela ne supprime ni le compte, ni ses appartenances à des groupes, ni les identifiants qu'il détient. Verrouiller la porte d'entrée ne revient pas à fermer le compte.

Noms de groupes qui échouent silencieusement à se synchroniser. Chaque système de provisionnement impose des contraintes de nommage, et les groupes IdP sont généralement nommés par des personnes qui n'ont jamais lu ces règles. Un groupe nommé ML Platform — Prod (EMEA) contient un espace, un tiret cadratin et des parenthèses ; il ne pourra donc pas devenir une équipe valide en aval. L'échec est silencieux : les utilisateurs se synchronisent, mais pas le groupe, et personne ne s'en aperçoit jusqu'à ce que quelqu'un demande pourquoi l'équipe est vide.

Croire que SCIM couvre tous les accès accordés à une personne. SCIM synchronise les utilisateurs et leur appartenance aux groupes. Il ignore tout des autorisations accordées directement, en dehors de tout groupe, sur une ressource spécifique. Si vous retirez quelqu'un d'une équipe, l'accès direct subsiste. C'est la réponse la plus fréquente à la question : « Pourquoi cette personne a-t-elle encore accès à cela ? »

Mauvaise gestion du jeton SCIM, ou absence totale de stockage. Le jeton Bearer n'est affiché qu'une seule fois. Les équipes le copient dans l'IdP, ferment l'onglet et n'en gardent aucune copie. C'est une situation gérable — il suffit d'en générer un nouveau — mais cela invalide l'ancien, interrompant ainsi le provisionnement jusqu'à ce que l'IdP soit également mis à jour. Enregistrez-le dans votre gestionnaire de secrets avant de fermer l'onglet.

Want to see the lifecycle end to end?

Spin up a TrueFoundry tenant, wire up your IdP, and watch a group become a team.

Get started free

Comment fonctionne le provisionnement SCIM dans TrueFoundry

TrueFoundry prend en charge SCIM pour les configurations SSO OIDC et SAML v2. Avant de configurer le provisionnement, assurez-vous que le SSO est opérationnel : l'URL et le jeton SCIM se trouvent aux côtés de la configuration SSO, et non dans une intégration séparée.

Étape 1 — Configurer le SSO

Accédez à Platform → Settings → SSO, activez Enabled, sélectionnez votre fournisseur, puis choisissez OIDC ou SAML v2.

Pour l'OIDC, vous devez fournir un identifiant client (Client ID), un secret client (Client Secret) et une URL d'émetteur (Issuer URL) ; l'URL de rappel côté fournisseur d'identité (IdP) est toujours https://login.truefoundry.com/oauth2/callback. Pour le SAML, vous devez fournir l'URL SSO de l'IdP et un certificat de signature X.509, puis revenir après avoir enregistré pour récupérer le URL de rappel et Émetteur générés par TrueFoundry et les coller dans votre IdP.

Un détail qui permet de gagner du temps : configurez votre IdP pour qu'il émette des revendications nommées email, sub et groups. Ce sont les valeurs par défaut de TrueFoundry, et en créant des alias pour ces attributs côté IdP, vous n'aurez jamais besoin de toucher aux champs avancés.

Étape 2 — Activer SCIM

Allez dans Paramètres → Sécurité et accès → Provisionnement et sélectionnez SCIM. C'est ici que se trouvent les trois modes de provisionnement ; en choisir un permet de définir le modèle de cycle de vie du locataire.

Étape 3 — Copier l'URL de base SCIM

Développez votre configuration SSO enregistrée pour révéler l'URL SCIM ainsi que le reste des métadonnées. C'est la valeur que votre IdP doit appeler.

Étape 4 — Générer le jeton SCIM

Cliquez sur l' icône de clé à côté de la configuration SSO pour générer le jeton d'authentification SCIM.

Considérez-le comme un mot de passe. Il n'est affiché qu'au moment de sa création ; si vous le perdez, vous devrez en générer un nouveau, ce qui rendra le précédent invalide.

Étape 5 — Configurez votre IdP

Dans les paramètres de provisionnement de votre IdP, définissez l' URL de base (certains IdP l'appellent URL du locataire) sur l'URL SCIM, réglez l' Authentification sur Jeton porteur (Bearer Token), et collez le jeton SCIM comme valeur du jeton. Ensuite, assignez les utilisateurs et les groupes dans l'IdP et lancez le provisionnement. En quelques minutes, les utilisateurs et les équipes apparaîtront dans TrueFoundry.

Les groupes IdP deviennent des équipes — c'est là que tout se joue

La plupart des guides sur SCIM s'arrêtent à la synchronisation des utilisateurs. La synchronisation des utilisateurs n'est que la partie facile. La raison d'utiliser SCIM sur une plateforme comme celle-ci est la synchronisation des groupes, car c'est dans les groupes que réside l'autorisation.

Lorsque le locataire est configuré pour SCIM, chaque groupe transmis par votre IdP devient automatiquement une équipe TrueFoundry. Ajoutez une personne au groupe IdP et elle rejoint l'équipe ; retirez-la et elle la quitte.

Les équipes synchronisées sont des équipes ordinaires à tous les autres égards. Vous pouvez leur accorder l'accès à des ressources, leur assigner des rôles au niveau du locataire et ajouter des mappages de revendications de fournisseur d'identité.

Soyez précis quant à la répartition des tâches, car il est facile de surestimer les capacités. SCIM ne décide pas de ce qu'une équipe peut faire — un administrateur lui attribue ses rôles une fois, de manière délibérée. SCIM automatise l'appartenance, et comme les autorisations sont liées à l'équipe, l'appartenance actuelle définit l'ensemble des permissions effectives. Concevez l'autorisation une seule fois et laissez le fournisseur d'identité (IdP) gérer les changements.

Il existe une contrainte de nommage à respecter. Le nom du groupe dans l'IdP devient le nom de l'équipe ; il ne peut donc contenir que des caractères alphanumériques, des traits d'union et des traits de soulignement, et ne doit pas dépasser 36 caractères. Renommez les groupes dans l'IdP avant d'activer le provisionnement, pas après.

Exemple concret : un prestataire dans l'équipe de la plateforme ML

Voici le cycle de vie complet, avec les étapes manuelles indiquées.

Configuration initiale (manuelle). Un administrateur crée un groupe IdP nommé ml-platform-contractors — minuscules, traits d'union, 23 caractères, conforme. SCIM le synchronise et une équipe du même nom apparaît dans TrueFoundry. L'administrateur accorde à cette équipe les droits nécessaires : le compte du fournisseur de modèles approprié, un accès utilisateur sur deux serveurs MCP, et rien d'autre. La conception de l'autorisation est terminée, une fois pour toutes.

Intégration (automatique). Un prestataire arrive. Le provisionnement RH l'ajoute au groupe ml-platform-contractors. SCIM crée son utilisateur TrueFoundry et l'ajoute à l'équipe. Il se connecte via SSO avec exactement les accès dont dispose l'équipe. Personne n'a eu besoin d'ouvrir un ticket.

Changement de périmètre (automatique). Trois mois plus tard, le prestataire change de projet. Quelqu'un le retire du groupe ml-platform-contractors et l'ajoute à un autre. SCIM ajuste les deux équipes. Son accès au fournisseur de modèles disparaît avec l'appartenance à l'équipe, sans qu'aucun administrateur n'ait eu à intervenir dans TrueFoundry.

Départ (automatique). Le contrat prend fin. L'enregistrement dans l'IdP est désactivé. SCIM marque l'utilisateur TrueFoundry comme inactif, et tout utilisateur désactivé est rejeté lors du processus d'authentification. Le compte ne fonctionne plus, sans que personne n'ait eu à se souvenir que TrueFoundry figurait sur la liste.

Le seul élément restant manuel. Si ce prestataire avait également reçu un accès direct — par exemple, à un groupe de secrets spécifique, en dehors de toute équipe — cet accès subsiste, car il ne provient pas de l'IdP. La désactivation bloque la connexion dans tous les cas, mais l'enregistrement de l'accès demeure jusqu'à ce qu'il soit supprimé manuellement. Intégrez ce point à vos revues d'accès. C'est le même schéma que l'on retrouve dans Contrôle d'accès MCP entreprise: les autorisations héritées et directes se cumulent, et la suppression de l'une n'entraîne pas la suppression de l'autre.

Ready to make your IdP the source of truth?

Configure SSO, switch on SCIM, and let group membership drive access.

Start free on TrueFoundry

Pièges à éviter

Pour Entra ID et Okta, SCIM nécessite SAML. La matrice des capacités présente le SSO comme simplement recommandé pour SCIM en général, mais pour les deux fournisseurs d'identité (IdP) les plus utilisés, les guides de provisionnement dépendent de la configuration SAML. Si vous configurez OIDC avec Entra ou Okta et que vous cherchez ensuite à activer SCIM, vous devrez reconfigurer l'ensemble.

Un seul mode de provisionnement par tenant. Vous ne pouvez pas utiliser SCIM pour les employés et les invitations pour les prestataires au sein du même tenant en activant simplement les deux options. Si vous devez intégrer une personne qui ne figure pas dans votre IdP, le flux Inviter un utilisateur dans Accès > Utilisateurs reste disponible — et lorsque vous l'utilisez pour un utilisateur SSO, laissez la case Envoyer un e-mail pour définir le mot de passe décochée, car il n'y a aucun mot de passe à définir.

La désactivation et la suppression sont deux opérations distinctes. La désactivation bloque la connexion et c'est ce que pilote SCIM. La suppression pure et simple d'un utilisateur est une action d'administration distincte, que TrueFoundry refuse tant que l'utilisateur n'a pas été explicitement retiré de toutes les ressources et équipes. Cette sécurité vous empêche de supprimer une identité alors que des droits d'accès y sont encore rattachés.

La page dédiée au Provisionnement a été introduite dans la version v0.143. Sur les versions antérieures, SCIM est configuré directement dans le formulaire SSO. Les valeurs sont identiques, seuls les écrans diffèrent.

‍