SCIM vs SAML : différences clés et lequel choisir ?

• Réponse rapide
• Qu'est-ce que SCIM ?
• Qu'est-ce que SAML ?
• SCIM vs SAML : tableau comparatif
• Cas d'usage : quand utiliser SCIM, SAML ou les deux
• Lequel implémenter en priorité ?
• Comment Corma vous aide à déployer SCIM et SAML
• FAQ

Si vous avez déjà eu à onboarder 20 nouveaux collaborateurs, à révoquer des accès après un départ, ou à imposer une connexion unique sur 40 outils SaaS, vous avez forcément croisé les acronymes SCIM et SAML. Tous deux sont au cœur de la gestion moderne des identités et des accès (IAM). Pourtant, ils ne font pas la même chose, et les confondre conduit à de vraies failles en matière de sécurité, de conformité et d'efficacité opérationnelle.

Ce guide explique précisément ce que fait chaque standard, en quoi ils diffèrent, et comment décider lequel adopter pour votre organisation, ou s'il faut en réalité les déployer ensemble.

Si vous voulez une vue d'ensemble en deux minutes avant d'aller plus loin, consultez notre article complémentaire : SCIM et SAML expliqués en moins de 5 minutes.

Réponse rapide : SCIM vs SAML en une phrase chacun

SCIM (System for Cross-domain Identity Management) automatise la création, la mise à jour et la suppression des comptes utilisateurs sur l'ensemble de vos applications SaaS. SAML (Security Assertion Markup Language) gère la façon dont les utilisateurs s'authentifient : c'est le protocole qui rend possible le Single Sign-On (SSO).

En résumé : SCIM gère qui existe dans un système. SAML gère qui peut s'y connecter. Ils traitent des problèmes adjacents et sont souvent déployés ensemble, mais chacun couvre une couche distincte de votre architecture d'identité.

Qu'est-ce que SCIM ?

SCIM (System for Cross-domain Identity Management) est un protocole standard ouvert, publié sous les RFC 7642, 7643 et 7644, qui définit une manière standardisée d'échanger des données d'identité entre systèmes. Sa mission centrale est le provisioning : faire en sorte que lorsqu'un utilisateur arrive, change de poste ou quitte l'organisation, ses comptes sur toutes les applications connectées soient mis à jour automatiquement et instantanément.

Comment fonctionne SCIM

SCIM repose sur un modèle client-serveur en HTTPS et API REST. Votre fournisseur d'identité (IdP), typiquement Okta, Microsoft Entra ID (Azure AD) ou Google Workspace, fait office de source de vérité pour l'identité utilisateur. Quand un changement intervient dans l'IdP (ajout d'un nouveau collaborateur, mise à jour d'un rôle, départ d'un employé), SCIM propage ce changement à chaque service provider connecté en temps réel.

Un workflow SCIM standard pour un onboarding ressemble à ceci :

1. Le service RH crée la fiche du nouveau collaborateur dans le SIRH (par exemple BambooHR, HiBob).
2. L'IdP reçoit les données du nouvel utilisateur et déclenche un événement de provisioning SCIM.
3. SCIM envoie une requête POST à chaque application SaaS connectée (Slack, Notion, Salesforce, etc.).
4. Chaque application crée le compte avec le bon rôle et les bonnes permissions, sans aucune action manuelle.

La même logique s'applique en sens inverse pour le deprovisioning : lorsqu'un collaborateur part, SCIM envoie une requête DELETE ou de désactivation à toutes les applications connectées en quelques secondes. C'est essentiel pour la sécurité : selon les données du secteur, les comptes orphelins d'anciens employés restent l'un des principaux vecteurs d'accès non autorisés aux SaaS.

Pour aller plus loin sur le sujet, consultez notre guide sur le provisioning utilisateur automatisé et notre analyse détaillée des bonnes pratiques de provisioning en IAM.

Ce que SCIM ne fait PAS

SCIM ne gère pas l'authentification. Il n'a aucun mécanisme pour vérifier qu'un utilisateur est bien celui qu'il prétend être au moment de la connexion. Il ne fait que gérer l'existence et les attributs des comptes. C'est précisément là que SAML entre en jeu.

Qu'est-ce que SAML ?

SAML (Security Assertion Markup Language) est un standard ouvert basé sur XML, conçu pour échanger des données d'authentification et d'autorisation entre deux parties : un fournisseur d'identité (IdP) et un fournisseur de service (SP). SAML 2.0 (la version actuelle, publiée en 2005) est la colonne vertébrale du Single Sign-On en entreprise. C'est ce qui permet à vos collaborateurs de cliquer sur "Se connecter avec Okta" (ou Google, ou Azure AD) sur n'importe quel outil SaaS compatible SAML, et d'y accéder sans avoir à saisir un nouveau mot de passe.

Comment fonctionne SAML

Lorsqu'un utilisateur cherche à accéder à un service provider (par exemple votre outil de gestion de projet), le SP le redirige vers l'IdP. L'IdP authentifie l'utilisateur, en vérifiant son identité via ses identifiants, le MFA ou une session active, puis renvoie un document XML signé numériquement appelé assertion SAML. Cette assertion indique au SP : "cet utilisateur est bien celui qu'il prétend être, voici ses attributs." Le SP fait confiance à cette assertion et accorde l'accès en conséquence.

Le flux complet :

1. L'utilisateur tente d'accéder à l'application X (le service provider).
2. L'application X redirige l'utilisateur vers le fournisseur d'identité avec une SAML AuthnRequest.
3. L'IdP authentifie l'utilisateur (mot de passe + MFA si configuré).
4. L'IdP génère une assertion SAML signée et la renvoie à l'application X.
5. L'application X valide l'assertion et connecte l'utilisateur, sans aucune saisie de mot de passe.

Ce que SAML ne fait PAS

SAML ne provisionne pas les comptes. Un utilisateur ne peut s'authentifier via SSO SAML que si son compte existe déjà dans l'application cible. Sinon, il sera bloqué, même avec une assertion SAML valide. C'est exactement la lacune que SCIM vient combler : il faut SCIM pour s'assurer que le compte existe avant que SAML puisse l'authentifier.

Pour une vision plus large de la façon dont SSO, SCIM et SAML s'articulent, lisez notre article sur SSO, SCIM et SAML, technologies clés du provisioning automatisé.

SCIM vs SAML : tableau comparatif

Cas d'usage : quand utiliser SCIM, SAML ou les deux

Quand SCIM seul a du sens

Utilisez SCIM lorsque votre principal problème est la gestion du cycle de vie des comptes. Si votre équipe IT passe des heures à créer manuellement des comptes pour les nouveaux arrivants, ou si vous échouez à des audits parce que d'anciens employés ont toujours des accès actifs, SCIM est ce qu'il vous faut en priorité.

Scénarios typiques où SCIM offre un ROI immédiat :

• PME en forte croissance où l'onboarding RH crée des goulots de provisioning quotidiens.
• Entreprises utilisant plusieurs IdP ou des applications non compatibles SSO mais qui supportent SCIM.
• Organisations qui visent une certification ISO 27001 ou SOC 2, où le deprovisioning automatisé et les preuves d'access reviews sont exigés. (Voir : comment SCIM et SAML aident à la conformité SOC 2 et ISO 27001)

Quand SAML seul a du sens

Utilisez SAML lorsque votre besoin principal est de simplifier et sécuriser l'expérience de connexion. Si vos collaborateurs jonglent avec plus de 20 mots de passe pour leurs outils SaaS, si le phishing par réutilisation de mots de passe est un risque réel, ou si vous voulez imposer le MFA en un point central, le SSO SAML est votre priorité.

Scénarios typiques :

• Entreprises qui ont déjà mis en place un annuaire utilisateurs propre dans Okta ou Azure AD et veulent l'étendre à leurs applications SaaS.
• Organisations qui cherchent à réduire la charge du helpdesk liée aux demandes de réinitialisation de mot de passe.
• Équipes à effectif réduit et stable, où le provisioning n'est pas un goulot mais où la friction de connexion l'est.

Quand vous avez besoin des deux

En pratique, la plupart des organisations au-dessus de 50 collaborateurs ont besoin des deux. SAML et SCIM sont complémentaires par conception : SCIM garantit que le compte existe avec les bons attributs, et SAML gère l'expérience quotidienne de connexion en toute sécurité. Ensemble, ils livrent un cycle de vie d'identité complet, du provisioning au jour 1 jusqu'au deprovisioning au dernier jour, avec une authentification centralisée et sans mot de passe entre les deux.

Cette combinaison comble également une faille de sécurité critique : SAML seul ne révoque pas les accès à toutes les applications quand un collaborateur part. Un utilisateur peut perdre sa session IdP tout en conservant des accès directs actifs sur des applications qui n'imposent pas la connexion SAML uniquement. SCIM garantit que le compte lui-même est supprimé ou désactivé, pas seulement la session.

Pour les entreprises confrontées à des applications qui ne supportent ni SCIM ni SAML, découvrez notre solution de provisioning utilisateur automatisé.

Lequel implémenter en priorité ? Un guide par taille d'entreprise

Il n'y a pas de réponse universelle à la question SCIM ou SAML en premier : cela dépend de votre effectif, de votre vitesse de croissance, de la maturité de votre IdP et de vos points de douleur actuels. Voici une grille de lecture concrète.

Startups et entreprises en phase d'amorçage (1 à 50 collaborateurs)

À ce stade, votre stack SaaS est probablement réduite et votre équipe IT (si elle existe) gère le provisioning manuellement. Le SSO SAML est généralement la priorité numéro un : il centralise l'authentification, met fin au chaos des mots de passe et pose les fondations de l'IdP avec lequel vous allez scaler. La plupart des IdP modernes (Google Workspace, Okta) incluent un provisioning SCIM de base dans leurs offres standard, vous pouvez donc activer les deux simultanément avec peu de surcoût.

Point de départ recommandé : mettre en place un IdP avec SSO, puis activer SCIM pour vos 5 à 10 applications SaaS les plus utilisées.

PME en croissance (50 à 500 collaborateurs)

C'est ici que SCIM devient critique. À partir de 50 collaborateurs, le provisioning manuel devient un véritable goulot opérationnel et un risque de conformité. Onboarder un nouveau collaborateur prend une journée IT complète si c'est fait manuellement sur plus de 30 applications. Offboarder un partant sans SCIM signifie des comptes orphelins qui restent actifs pendant des semaines. Priorisez la couverture SCIM sur l'ensemble de votre stack SaaS.

À ce stade, vous avez probablement déjà le SSO SAML en place. L'objectif désormais est d'automatiser tout le cycle de vie : pas seulement la connexion, mais la création, la mise à jour des rôles et la suppression, et de construire la piste d'audit nécessaire aux certifications de conformité.

Point de départ recommandé : cartographier toutes les applications SaaS, identifier celles compatibles SCIM, et mettre en place le provisioning automatisé. Utilisez une plateforme comme la solution de provisioning utilisateur Corma pour centraliser tout cela sur votre stack.

Mid-market et grandes entreprises (500+ collaborateurs)

À grande échelle, SCIM et SAML sont une infrastructure de base non négociable. Le défi se déplace de la mise en œuvre vers la gouvernance : assurer la couverture sur des centaines d'applications, gérer les accès basés sur les rôles au niveau des départements, appliquer les politiques de moindre privilège, et générer les rapports d'access reviews pour les auditeurs.

Les grandes entreprises doivent aussi composer avec des applications qui ne supportent nativement ni SCIM ni SAML, ce qui exige des contournements comme les agents de provisioning navigateur ou les intégrations API. Les capacités de provisioning utilisateur et de gestion des accès d'une plateforme IAM dédiée deviennent essentielles à cette échelle.

Point de départ recommandé : auditer vos zones de couverture SCIM/SAML manquantes, prioriser les applications à haut risque sans deprovisioning automatisé, et mettre en place une gouvernance des identités structurée incluant les access reviews.

Comment Corma vous aide à déployer SCIM et SAML à grande échelle

Implémenter SCIM et SAML application par application est chronophage, source d'erreurs et difficile à auditer. Corma est une plateforme de SaaS Management et d'IAM conçue pour les équipes IT et les CIO qui ont besoin d'une visibilité et d'un contrôle complets sur l'accès à leurs applications, sans construire une infrastructure d'identité complexe en partant de zéro.

Voici concrètement ce que Corma prend en charge :

• Provisioning et deprovisioning automatisés via SCIM : Corma se connecte à votre IdP et propage les événements du cycle de vie utilisateur sur l'ensemble de votre stack SaaS automatiquement, y compris pour les applications qui ne supportent pas nativement SCIM, en utilisant des agents navigateur si nécessaire.
• Couverture SSO SAML : Corma s'intègre à votre IdP existant (Okta, Azure AD, Google) pour étendre la couverture SSO et identifier les applications qui utilisent encore des connexions directes, un risque courant de shadow IT et de non-conformité.
• Access reviews et gouvernance des identités : Corma génère des workflows d'access review automatisés qui correspondent directement aux exigences de contrôle ISO 27001 et SOC 2. Voir la solution Corma d'access reviews automatisés.
• Visibilité SaaS complète : Corma détecte toutes les applications utilisées par vos collaborateurs, y compris celles en dehors de votre périmètre SCIM/SAML, donnant à votre équipe IT une image complète du risque d'accès.
• Pensé pour les équipes IT : Corma est conçue pour les équipes IT qui pilotent les accès SaaS, pas pour les ingénieurs identité d'entreprise prêts à passer des mois à configurer des pipelines complexes.

Que vous démarriez tout juste votre projet SCIM et SAML ou que vous auditiez une implémentation existante, Corma vous fournit la couche opérationnelle pour le piloter sans tableurs ni tickets manuels.

→ Demandez une démo pour découvrir comment Corma automatise le provisioning SCIM et la couverture SAML sur votre stack SaaS

Questions fréquentes sur SCIM vs SAML

SCIM est-il meilleur que SAML ?

SCIM et SAML ne sont pas des standards concurrents : ils résolvent des problèmes différents et sont conçus pour fonctionner ensemble. SCIM gère le provisioning utilisateur (qui possède un compte et quels accès). SAML gère l'authentification (comment les utilisateurs prouvent leur identité au moment de la connexion). Demander lequel est "meilleur" est un mauvais cadrage : dans une configuration IAM mature, vous avez besoin des deux.

Peut-on utiliser SAML sans SCIM ?

Oui, et beaucoup d'organisations le font, surtout en phase de démarrage. Avec le SSO SAML seul, les utilisateurs peuvent se connecter avec une identité unique, mais les comptes doivent toujours être créés et supprimés manuellement dans chaque application. Cela crée une faille : quand un collaborateur part, sa session SAML est révoquée mais ses comptes peuvent persister sur tous les outils SaaS jusqu'à ce que quelqu'un les supprime manuellement. SCIM comble cette faille en automatisant le deprovisioning des comptes.

Peut-on utiliser SCIM sans SAML ?

Oui. SCIM peut fonctionner indépendamment de SAML. Certaines organisations déploient le provisioning SCIM via leur IdP tout en laissant les utilisateurs se connecter avec des identifiants directs application par application. C'est fréquent quand une entreprise n'a pas encore déployé le SSO. Vous obtenez les bénéfices d'automatisation du cycle de vie de SCIM (zéro compte orphelin, onboarding automatisé) sans la couche SSO. Ajouter SAML plus tard est simple une fois que SCIM est en place.

Quelle est la différence entre SCIM et SAML pour le SSO ?

SAML est le protocole qui rend le SSO possible : c'est ce qui permet à votre IdP d'authentifier les utilisateurs sur plusieurs applications sans demander de mots de passe distincts. SCIM n'est pas un protocole SSO. C'est un protocole de provisioning qui synchronise les comptes utilisateurs entre votre IdP et vos applications. SSO et provisioning automatisé sont des capacités complémentaires, pas des alternatives.

Okta utilise-t-il SCIM ou SAML ?

Okta utilise les deux. En tant que fournisseur d'identité, Okta peut agir comme un IdP SAML pour fournir le SSO sur les applications compatibles SAML, et il peut agir comme un client SCIM pour pousser les événements de provisioning vers les applications SaaS compatibles SCIM. La plupart des déploiements Okta en entreprise combinent les deux protocoles.

SCIM vs SAML est-il pertinent pour la conformité ISO 27001 ?

Oui, les deux sont directement pertinents. Les contrôles de l'Annexe A de la norme ISO 27001:2022 sur la gestion des accès (A.5.15 à A.5.18) exigent que les accès soient accordés, modifiés et révoqués de manière maîtrisée et dans des délais raisonnables. SCIM automatise le volet provisioning/deprovisioning de cette exigence. SAML (via SSO) répond aux exigences de contrôle d'authentification. Implémenter les deux, avec une journalisation d'audit appropriée, est l'un des moyens les plus efficaces de satisfaire la section gestion des accès d'un audit ISO 27001. Voir notre guide détaillé sur ISO 27001 et IAM : guide d'implémentation complet.

Quelles applications supportent SCIM et SAML ?

La plupart des grandes applications SaaS d'entreprise supportent les deux : Salesforce, Slack, Notion, GitHub, Google Workspace, Microsoft 365, Zoom, Atlassian, Workday, ServiceNow, et des centaines d'autres. Le support SCIM est généralement disponible sur les plans Business ou Enterprise. Cela signifie qu'une fonctionnalité essentielle de SCIM se trouve derrière un paywall, ce que l'on appelle aussi le SCIM Scheme. Les applications plus petites ou plus de niche supportent souvent le SSO SAML mais pas SCIM, ce qui exige des approches alternatives pour le provisioning. Découvrez notre solution Corma de gouvernance des identités pour gérer ces cas.

Quelle alternative existe si mes applications ne supportent pas SCIM ?

Un outil d'IAM comme Corma est une alternative qui aide à gérer les demandes d'accès, à provisionner et déprovisionner les utilisateurs, et à appliquer le moindre privilège efficacement, sans dépendre uniquement des API SCIM.