Qu'est-ce que l'IAM (gestion des identités et des accès) ?

L’IAM est un framework de politiques et de technologies qui garantit aux bons utilisateurs le bon accès aux bonnes ressources, au bon moment. La gestion des identités et des accès est la discipline derrière chaque formulaire de connexion et chaque vérification de permission — avec une précision d’emblée : les grands fournisseurs cloud vendent aussi des produits baptisés “IAM” pour contrôler l’accès à leur propre infrastructure ; ce sont des implémentations de la discipline, pas sa définition. Cet article traite de la discipline — y compris de la version que tout développeur d’app construit ou dont il hérite, le plus souvent sans l’appeler IAM.

Points clés

Le cycle de vie des identités : arrivée, mobilité, départ

Le quotidien de l’IAM est une boucle que parcourt chaque compte, et elle se traduit en opérations concrètes :

ARRIVÉE  créer l'identité → vérifier l'e-mail → émettre identifiants/session
         (provisionnement — automatisé via SCIM côté collaborateurs)
MOBILITÉ changements de rôle · changements d'équipe · octrois et révocations
         (l'autorisation suit les rôles : une mobilité = une mise à jour de données)
DÉPART   révoquer les sessions IMMÉDIATEMENT → désactiver le compte → supprimer ou anonymiser
         (déprovisionnement — les étapes sautées deviennent des "comptes orphelins",
          le constat d'audit qui revient sans cesse dans les rapports de brèches)

La même boucle sous forme d’appels d’API :

// JavaScript / Node.js — Back4app JS SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
const user = new Parse.User();
await user.signUp({ username: 'ada', password: secret, email: '[email protected]' });

// Move: authorization follows roles, not people
editors.getUsers().add(user);
await editors.save();

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)

// Flutter / Dart — Back4app Flutter SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
final user = ParseUser('ada', secret, '[email protected]');
await user.signUp();

// Move: authorization follows roles, not people
editors.addRelation('users', [user]);
await editors.save();

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)

// iOS / Swift — Back4app Swift SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
var user = User()
user.username = "ada"
user.password = secret
user.email = "[email protected]"
let signedUp = try await user.signup()

// Move: authorization follows roles, not people
try await editors.users.add([signedUp]).save()

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)

// Android / Kotlin — Back4app Android SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
val user = ParseUser()
user.username = "ada"
user.setPassword(secret)
user.email = "[email protected]"
user.signUp()

// Move: authorization follows roles, not people
editors.users.add(user)
editors.save()

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)

Authentification vs. autorisation

La distinction sur laquelle repose toute la discipline :

La version aéroport, une seule fois : le contrôle des passeports face à la carte d’embarquement. Puis la version ingénieur, qui compte davantage : l’authentification produit l’identité que porte une session ; l’autorisation la consomme à chaque requête qui suit — c’est pourquoi les deux échouent différemment et se durcissent séparément.

Les quatre piliers — et les trois sigles du marché

L’anatomie fonctionnelle : l’authentification (prouver l’identité — mots de passe, MFA, SSO, sans mot de passe), l’autorisation (décider des actions — rôles, permissions, règles par objet), le cycle de vie (la boucle arrivée/mobilité/départ) et l’audit (le quatrième pilier, chroniquement sous-estimé : journaux, revues d’accès et capacité à répondre à “qui pouvait lire ceci, et qui l’a lu ?”). Le marché des éditeurs découpe le même territoire en segments que vous croiserez lors des achats : AM (access management — connexion, SSO, MFA), IGA (gouvernance — certifications, séparation des tâches, la couche du “devraient-ils avoir ceci ?” au-dessus du “peuvent-ils ?” opérationnel) et PAM (accès à privilèges — coffres-forts de secrets et élévation just-in-time pour les comptes dont la compromission signe la fin de la partie). Une même discipline, deux cartes.

Le stack des standards

La soupe de sigles, ramenée à des rôles — le tableau que les pages du classement ne fournissent jamais :

Workforce IAM vs. CIAM

La distinction mérite son tableau parce que le contenu du classement porte presque entièrement sur la colonne de gauche, alors que la plupart des développeurs qui lisent un glossaire construisent celle de droite : les parcours d’inscription, la gestion des sessions et la récupération de compte pour les utilisateurs d’une app, c’est du CIAM — la discipline s’applique même quand personne dans la pièce n’emploie le sigle.

Cas d’usage courants

• Gestion des utilisateurs d’une app — inscription, vérification, sessions, rôles, suppression : le CIAM comme travail backend du quotidien.
• SSO d’entreprise — un IdP, de nombreuses apps ; MFA et départs appliqués en un point unique.
• Identité des API et des services — identifiants machine, tokens à portée limitée et rotation pour les appelants non humains.
• Programmes de conformité — revues d’accès, pistes d’audit et preuves de moindre privilège pour le RGPD, HIPAA, SOC 2.
• Architectures zero trust — des vérifications d’identité à chaque requête remplacent l’emplacement réseau comme signal de confiance.

Faut-il construire ou acheter votre IAM ? Matrice de décision

Limites et trade-offs

• L’IAM est un processus habillé en logiciel. Les outils automatisent la politique ; ils ne peuvent pas l’inventer — la conception des rôles, la cadence des revues et la rigueur des départs restent un travail humain.
• Centraliser concentre le risque. Un IdP, c’est un seul endroit à sécuriser et une seule panne qui déconnecte tout le monde ; la planification de la disponibilité et de la reprise vient avec le confort.
• La fédération hérite de la confiance. Chaque app qui fait confiance à un IdP hérite de ses compromissions ; la validation des tokens et des durées de vie courtes assurent le confinement.
• L’automatisation du cycle de vie a besoin de vérité. Le provisionnement ne vaut que la source de référence qui l’alimente ; des données RH périmées deviennent des accès périmés.
• Un audit sans revue relève du théâtre. Des journaux que personne ne lit et des certifications suivies d’aucune action satisfont les checklists, pas les attaquants.

L’IAM sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. La vision de l’IAM côté développeur correspond exactement à ce qu’elle fournit : la classe User est le référentiel d’identités ; l’inscription, la vérification d’e-mail, la réinitialisation du mot de passe et la connexion sociale couvrent l’authentification (avec un adaptateur MFA pour l’authentification renforcée) ; des tokens de session révocables portent l’identité ; les rôles et les ACL par objet forment le pilier de l’autorisation, appliqués à chaque requête REST, GraphQL et Live Query ; et le cycle de vie des onglets de code — arrivée, mobilité, départ — est un travail de données ordinaire, les triggers Cloud Code étant l’endroit où appliquer la politique (bloquer les e-mails jetables, journaliser les événements d’audit, déprovisionner en cascade). C’est du CIAM en tant que couche de plateforme : les piliers arrivent assemblés, et votre travail passe de la construction de la machinerie d’identité à la définition de la politique.