L'IAM (Identity and Access Management) gère les identités internes : collaborateurs, prestataires, comptes techniques. Le CIAM (Customer Identity and Access Management) gère les identités externes : clients, usagers, partenaires. Les deux vérifient des identités et attribuent des droits, mais ils répondent à deux problèmes différents — et confondre les deux conduit à des architectures inadaptées dans un sens comme dans l'autre.
La différence fondatrice : qui contrôle l'identité
Dans l'IAM, l'organisation crée l'identité, la contrôle et la supprime. Elle décide du format d'identifiant, impose une politique, gère le terminal, et peut convoquer la personne. L'utilisateur n'a pas le choix du dispositif d'authentification.
Dans le CIAM, l'organisation accueille une identité qu'elle ne contrôle pas. La personne s'inscrit seule, choisit ses moyens d'accès, utilise un terminal inconnu, peut disparaître pendant des mois et revenir. Elle peut aussi partir chez un concurrent si le parcours de connexion l'agace — contrainte que l'IAM ne connaît pas.
Toutes les autres différences découlent de celle-ci.
| Dimension | IAM | CIAM |
|---|---|---|
| Population | connue, bornée, contractuellement liée | ouverte, volatile, potentiellement massive |
| Création du compte | provisionnée par l'organisation | auto-inscription |
| Terminal | souvent géré et supervisé | jamais maîtrisé |
| Politique d'authentification | imposable | négociée avec l'expérience utilisateur |
| Cycle de vie | arrivée, mobilité, départ | inscription, inactivité, retour, suppression sur demande |
| Enjeu de disponibilité | interne, mesurable | commercial et immédiat |
| Menace dominante | phishing ciblé, élévation de privilèges, menace interne | credential stuffing, création de faux comptes, fraude |
| Charge | prévisible | pics saisonniers, campagnes, attaques automatisées |
| Consentement et vie privée | encadré par le contrat de travail | central : consentement, préférences, portabilité |
| Support en cas de blocage | interne, identifiable | à distance, sans moyen simple de vérifier l'identité |
Les risques ne sont pas les mêmes
Côté IAM, le risque majeur est la prise de contrôle d'un compte à fort privilège : un compte d'administration compromis donne accès à l'infrastructure et permet de désactiver les contrôles. L'attaque type est ciblée : reconnaissance, phishing personnalisé ou appel au support, puis élévation. C'est le terrain du PAM et de la segmentation des accès.
Côté CIAM, le risque majeur est volumétrique. Le credential stuffing rejoue massivement des couples identifiant/mot de passe issus de fuites tierces, en pariant sur la réutilisation. S'y ajoutent la création automatisée de faux comptes, l'abus de programmes de fidélité et la fraude sur les parcours de paiement. La réponse ne peut pas être la même : on ne convoque pas cent mille clients pour un ré-enrôlement.
Le point commun que l'on oublie : la récupération de compte
C'est le maillon faible des deux mondes, pour des raisons opposées.
En IAM, la réinitialisation passe par le support, qui doit vérifier l'identité de l'appelant. Cette vérification est exactement ce que cible l'ingénierie sociale : un appel bien préparé, un prétexte crédible, et le facteur d'authentification est réinitialisé au profit de l'attaquant.
En CIAM, la récupération repose presque toujours sur un courriel ou un SMS. La sécurité du compte se ramène alors à celle de la boîte mail ou de la ligne téléphonique, quelle que soit la robustesse de la connexion nominale. Un dispositif solide dont la porte de service est un lien envoyé par e-mail vaut la sécurité de ce lien.
Traiter la récupération avec la même exigence que la connexion est, dans les deux cas, le meilleur investissement disponible.
Faut-il un annuaire unique ?
La tentation existe de faire porter les deux usages par la même plateforme. Trois raisons plaident généralement contre.
Les profils de charge diffèrent. Une plateforme dimensionnée pour quelques milliers de collaborateurs ne se comporte pas comme une plateforme absorbant des pics d'inscriptions ou une campagne de credential stuffing.
Les modèles de données diffèrent. Une identité interne porte des attributs organisationnels — service, fonction, habilitations. Une identité client porte des préférences, des consentements, un historique commercial, soumis à des droits d'accès et d'effacement.
Le rayon d'impact diffère. Une indisponibilité côté client est un incident commercial ; une indisponibilité côté collaborateurs est un arrêt d'activité. Les mutualiser revient à coupler deux risques distincts.
En revanche, deux éléments gagnent à être communs : la méthode d'authentification forte — un utilisateur peut être client et collaborateur, et le même niveau d'exigence s'applique aux actions sensibles — et la politique de journalisation, pour disposer d'une vue cohérente lors d'une investigation.
C'est un argument en faveur d'un facteur déployable des deux côtés. Le facteur cognitif s'y prête, en overlay d'un IdP interne comme sur un parcours client, avec un niveau d'exigence ajusté à la criticité de l'action plutôt qu'au type de population.
FAQ
Un CIAM peut-il servir d'IAM interne ?
Techniquement parfois, fonctionnellement rarement. Il manque en général la gestion fine des habilitations, les revues d'accès, le provisionnement depuis le SIRH et l'intégration aux annuaires techniques.
Le RGPD s'applique-t-il différemment ?
Le règlement s'applique dans les deux cas, mais les obligations les plus visibles se concentrent côté CIAM : consentement, information, droit d'accès, portabilité, effacement — le tout en libre-service et à grande échelle.
La MFA est-elle acceptable côté client ?
Oui, à condition qu'elle soit proportionnée. L'imposer à chaque connexion dégrade la conversion ; la réserver aux actions sensibles est mieux accepté et souvent plus efficace, puisque c'est là que se situe le risque financier.
Par quoi commencer si les deux sont à traiter ?
Par le périmètre où une compromission cause le dommage le plus lourd — généralement les accès d'administration côté IAM — puis par les parcours clients à impact financier direct.
Aller plus loin : un facteur commun aux parcours internes et clients · identification, authentification, autorisation · PAM et accès à privilèges · credential stuffing : mécanique