Opérations SCIM

Cette page couvre le volet opérationnel du SCIM — que faire lorsque vous approchez des plafonds de capacité, comment fonctionne la limitation de débit, comment détecter et réconcilier la dérive, ainsi que les runbooks dont votre équipe plateforme a besoin.

Pour la configuration et le comportement du provisionnement, consultez Identité & Provisionnement et les guides par IdP (Entra, Okta, OneLogin).

Plafonds de capacité (rappel)

Ces limites sont des garde-fous sur l'infrastructure partagée, non des plafonds architecturaux. Si votre organisation a besoin de limites plus élevées, contactez le support — nous provisionnerons un profil de limitation dédié.

Comportement de la limitation de débit

Lorsque votre IdP dépasse 20 requêtes/s, la plateforme renvoie 429 Too Many Requests avec un en-tête Retry-After. Tous les IdP prennent en charge Retry-After nativement, vous n'avez généralement rien à faire — la synchronisation ralentit et se rattrape automatiquement.

Points de vigilance :

• Rafales de provisionnement en masse — assigner un groupe IdP de 5 000 utilisateurs à l'application Scrydon pour la première fois va solliciter fortement le limiteur de débit. Prévoyez que la synchronisation initiale prendra environ 5 000 / 20 = ~4 minutes, plus les traitements annexes. Les synchronisations delta suivantes sont rapides.
• Rotation fréquente des membres de groupe — chaque changement d'appartenance déclenche une écriture de synchronisation. Si votre IdP dispose d'un groupe très actif, demandez-vous s'il doit vraiment être assigné à Scrydon.
• Plusieurs intégrations IdP — le plafond de 20 req/s est par organisation, pas par IdP. Si vous utilisez deux IdP vers la même organisation Scrydon (rare mais pris en charge), ils partagent le même budget.

Runbook de provisionnement en masse

Lors de l'intégration d'une nouvelle organisation ou du transfert de milliers d'utilisateurs vers Scrydon pour la première fois, suivez cette séquence :

1. Réservez une fenêtre de synchronisation. Un transfert de 5 000 utilisateurs prend quelques minutes ; planifiez-le en tenant compte des attentes de fraîcheur de votre IdP.
2. Préparez les groupes IdP. Créez les groupes dans votre IdP avec les membres souhaités avant de les assigner à l'application Scrydon. SCIM ne voit que ce qui est assigné, la préparation rend donc la synchronisation déterministe.
3. Assignez l'application Scrydon. Cela déclenche la synchronisation initiale.
4. Surveillez le journal d'audit. Filtrez sur les actions scim.* ; vous devriez voir un flux régulier d'événements scim.user.provisioned, scim.group.created, scim.group.member.added.
5. Vérifiez un échantillon. Une fois la synchronisation stabilisée, choisissez 10 utilisateurs au hasard et confirmez qu'ils peuvent se connecter.

Si la synchronisation se bloque, vérifiez le journal d'audit pour des événements scim.error.* — ceux-ci contiennent le corps de la réponse de l'IdP et l'utilisateur / groupe spécifique qui a échoué.

Détection de dérive

On parle de « dérive » lorsque l'appartenance réelle au workspace a divergé de ce que l'IdP indique. Cela peut se produire quand :

• Un administrateur modifie manuellement l'appartenance au workspace dans Scrydon (en contournant ce que SCIM indique).
• L'IdP échoue à un appel SCIM et ne le réessaie pas (rare avec les IdPs modernes, mais cela arrive).
• Un utilisateur est renommé côté IdP mais le nouvel e-mail entre en collision avec un autre utilisateur dans Scrydon.

Pour vérifier la dérive à la demande :

1. Allez dans Paramètres → Plateforme → Identité & Provisionnement → Rapport de dérive.
2. Cliquez sur Lancer l'analyse. L'analyse compare l'appartenance de chaque équipe liée SCIM dans Scrydon à la vue de l'IdP.
3. Examinez le rapport. Chaque entrée indique l'utilisateur, le workspace et la nature de l'écart.

Deux façons de corriger la dérive :

• Réconcilier vers l'IdP — accepter la vue de l'IdP comme source de vérité et la pousser dans Scrydon. À utiliser quand l'IdP fait autorité (ce qui est le modèle SCIM normal).
• Correction manuelle — corriger la cause sous-jacente (renommer un utilisateur, réparer la collision d'e-mails) et relancer la synchronisation de l'IdP.

Scénarios courants

Un utilisateur a été provisionné mais ne peut pas se connecter

L'utilisateur a été provisionné (un enregistrement Scrydon existe) mais ne se connecte pas réellement. Cause la plus fréquente : le SSO n'est pas encore configuré entre votre IdP et Scrydon. SCIM crée l'enregistrement ; le SSO authentifie la session. Les deux sont nécessaires.

Vérifiez que Paramètres → Plateforme → Identité & Provisionnement → SSO est configuré pour le même IdP que celui qui exécute SCIM.

Un utilisateur a été déprovisionné mais je le vois toujours dans Scrydon

Le déprovisionnement est une suppression logicielle — le compte est banni, les sessions sont révoquées, l'appartenance à l'organisation est supprimée, mais l'enregistrement utilisateur sous-jacent est conservé à des fins d'audit. Vous le verrez toujours dans les requêtes du journal d'audit ; vous ne le verrez pas dans la liste des utilisateurs actifs et il ne peut pas se connecter.

Si vous devez vraiment supprimer définitivement un utilisateur déprovisionné (ex. droit à l'effacement RGPD), utilisez Paramètres → Plateforme → Confidentialité → Effacement d'un sujet — voir RGPD.

Un utilisateur a été re-provisionné après un déprovisionnement

Si le même utilisateur est réajouté à l'IdP par la suite, SCIM réactive automatiquement l'enregistrement d'origine — même userId, historique d'audit continu, sans doublon. C'est voulu : votre piste d'audit reste complète tout au long du cycle de vie.

« Conflit d'e-mail » lors du provisionnement

L'utilisateur est en train d'être créé avec un e-mail qui existe déjà dans l'organisation sous un externalId SCIM différent. Cela ne devrait pas se produire sauf si un administrateur a modifié un e-mail manuellement après le provisionnement, ou si l'IdP a changé la façon dont il identifie l'utilisateur. Résolvez d'abord côté IdP ; SCIM est la partie en aval.

Token révoqué ou expiré

Les tokens SCIM sont des identifiants sensibles et ne se rafraîchissent pas automatiquement. Effectuez une rotation annuelle (ou selon votre politique de sécurité), et à chaque suspicion d'exposition.

Pour effectuer une rotation :

1. Paramètres → Plateforme → Identité & Provisionnement → Tokens SCIM → Générer un nouveau token.
2. Copiez le nouveau token dans la configuration SCIM de votre IdP.
3. Confirmez que la prochaine synchronisation IdP réussit avec le nouveau token.
4. Révoquez l'ancien token.

Planifiez la rotation sur une fenêtre de synchronisation calme — votre IdP constatera des échecs d'authentification pendant le bref chevauchement.

Événements d'audit

Chaque action SCIM émet un événement d'audit structuré. Les plus courants :

• scim.token.created / scim.token.revoked
• scim.user.provisioned / scim.user.updated / scim.user.deactivated / scim.user.reactivated
• scim.group.created / scim.group.updated / scim.group.deleted
• scim.group.member.added / scim.group.member.removed
• scim.error.invalid_token / scim.error.scale_cap_hit / scim.error.email_conflict

Filtrez le journal d'audit sur le préfixe scim.* pour voir toute l'activité SCIM. Transférez vers votre SIEM via le redirecteur SIEM.

Détail des plafonds

À connaître précisément :

Tous les plafonds sont configurables par organisation si votre volumétrie le nécessite. Contactez le support.

Liens connexes

• Identité & Provisionnement (SCIM) — modèle de provisionnement et IdPs pris en charge.
• Cloisonnement strict — restreindre les identifiants système à des groupes spécifiques.
• Journal d'audit — où les événements SCIM sont enregistrés.
• Catalogue des événements d'audit — référence complète des événements.
• Redirection vers le SIEM — transférer les événements SCIM vers votre SIEM.