La plupart des articles de comparaison de fournisseurs d'identité sont écrits par… des fournisseurs d'identité. Étonnant, non ? Ils énumèrent les fonctionnalités de leur produit, omettent celles qu'ils n'ont pas, et appellent ça un « guide objectif ».
Ce guide n'est pas comme ça.
Nous avons passé en revue des dizaines de vraies demandes d’évaluation d’entreprises — les tableurs et les RFP réels que les équipes d’achat envoient aux fournisseurs. Les schémas sont clairs : les équipes d'ingénierie sous-évaluent systématiquement les critères les plus importants et surévaluent ceux qui comptent le moins.
Résultat ? Les équipes choisissent un IdP après une démo, découvrent que la migration est un cauchemar au bout de six mois, et recommencent l’évaluation.
Voici le cadre d'évaluation que nous aurions aimé recevoir avant de démarrer. Il est conçu pour les équipes d’ingénierie de sociétés B2B SaaS — celles qui construisent des produits, pas celles qui achètent un SSO pour les collaborateurs.
Réponse rapide : ce qui fait la différence dans le choix d’un IdP#
Si tu lis en diagonale, voici la version courte :
- La profondeur protocolaire est plus importante que le nombre de fonctionnalités. Dire « OAuth2 pris en charge » ne veut rien dire. Quels types de grant ? Peux-tu personnaliser les claims des tokens ? Peux-tu toi-même devenir fournisseur OIDC ?
- La capacité de migration est le critère sous-estimé n°1. Si tu ne peux pas migrer tes utilisateurs existants sans leur imposer une réinitialisation du mot de passe, l’IdP est inutilisable — peu importe l’apparence du reste.
- La multi-location doit être native, pas bricolée. Si le modèle des organisations et les configurations par tenant demandent des contournements, tu agiras toujours à contre-courant.
- La préparation à l’IA n’est pas de la prospective — c’est un besoin à 12 mois. Échange de tokens, identité d’agent, délégation de scopes. Si l’IdP ne prend pas en charge tout ça, tu reviendras ici l’année prochaine.
La suite du guide détaille chaque dimension d’évaluation, avec les questions à poser et les signaux d’alerte.
À qui ce guide s’adresse (et à qui il ne s’adresse pas)#
Ce guide est pour toi si :
- Tu es CTO, VP Engineering ou architecte plateforme dans une boîte B2B SaaS de 50 à 300 personnes
- Tu as plus de 100K utilisateurs existants, et une migration perturbatrice n’est pas envisageable
- Tu grimpes vers des clients enterprise qui demandent SSO, modèles d’orgas et logs d’audit
- Tu dois rédiger une évaluation technique et veux un cadre indépendant des fournisseurs
Ce guide n’est PAS pour toi si :
- Tu cherches un IAM collaborateurs (SSO pour outils internes) — c’est un choix différent
- Tu es une startup avec 500 utilisateurs et aucun client enterprise — prends la meilleure SDK, avance
- Tu veux de la vérification d’identité (KYC/KYB) — c’est une autre catégorie
Dimension 1 : Capacités protocolaire — Pas juste « OAuth2 pris en charge »#
Chaque IdP du marché dira qu’il prend en charge OAuth2 et OIDC. C’est le minimum. La vraie question, c’est la profondeur.
Types de grant : lesquels et pourquoi c’est important#
À avoir impérativement :
- Authorization Code + PKCE — Seul flow à utiliser pour apps web/mobile. Si on te recommande encore Implicit flow, fuie. PKCE n’est pas facultatif — c’est une exigence de sécurité.
- Client Credentials — Pour la communication inter-services. Tes backends doivent pouvoir s’authentifier sans utilisateur présent.
- Refresh Token — Ça paraît basique, mais l’implémentation varie énormément. Peux-tu configurer la rotation ? L’expiration ? Révoquer un refresh token spécifique sans terminer toute la session ?
De plus en plus critique :
- Token Exchange (RFC 8693) — Ce grant type permet l’authentification des agents IA, l’impersonation (agir à la place d’un autre) et la délégation. S’il manque aujourd’hui, demande la roadmap. Pas de roadmap : mauvais signe.
Capacité fournisseur OIDC#
Peu d’équipes pensent à demander : Peux-tu utiliser cet IdP comme fournisseur OIDC — pas juste comme client OIDC ?
Pourquoi c’est clé : ta plateforme grandissant, tes partenaires/clients voudront se servir de ton identité pour se connecter à LEURS outils. Tu dois pouvoir délivrer des tokens, gérer le consentement, enregistrer des apps tierces. Si tu ne fais que consommer sans pouvoir fédérer vers l’extérieur, tu seras bloqué.
À demander :
- L’IdP expose-t-il un endpoint OpenID Discovery que tu peux en marque blanche ?
- Peux-tu inscrire applications first-party/third-party avec différents niveaux de confiance ?
- Les apps first-party peuvent-elles passer l’écran de consentement, les tierces devant le voir ?
Personnalisation JWT#
Le token est le contrat entre ton IdP et tes services. Si tu ne peux pas le personnaliser, chaque service aval doit refaire des appels API pour savoir ce qu’a le droit de faire un utilisateur.
À demander :
- Peux-tu ajouter des claims personnalisés dans les access et ID tokens ?
- Peux-tu injecter le contexte organisationnel (le tenant courant) dans le token ?
- Peux-tu définir des scopes mappés sur ton modèle de permissions applicatif ?
- Les claims sont-ils calculés à l’émission ou dynamiquement (webhook/script) ?
Un token qui inclut { "org_id": "org_123", "role": "admin", "auth_level": 2 } = middleware d’API qui décide en une ligne. Un token basique { "sub": "user_456" } = chaque service doit rappeler l’IdP ou requêter la base. À l’échelle, c’est la différence entre 2 ms et 200 ms par requête.
Dimension 2 : Flows d’authentification — Les détails qui tuent#
Tous les IdP font email/mot de passe et login social. Bravo, tu… n’as encore éliminé personne.
La différenciation se joue dans les détails tus par les démos.
Le flow d’inscription#
- Auto-login après inscription : Suite à la création de compte, l’utilisateur est-il automatiquement connecté ? Ou retombe-t-il sur un écran de login ? Forcer à se (re)connecter est un tue-conversion fréquent. Énormément d’IdP échouent là-dessus.
- Champs personnalisés d’inscription : Peux-tu collecter rôle, société ou le cas d’usage au signup ? Ou faut-il un onboarding séparé ensuite ?
- Profilage progressif : Peux-tu demander des infos additionnelles au fil de plusieurs sessions, et pas tout d’un coup ?
Le flow de connexion#
- login_hint supporté : Si l’utilisateur clique depuis un mail marketing, peux-tu pré-remplir son email ? Ce détail « trivial » fait souvent passer le taux de conversion de 40 à 60%.
- Politiques d’auth par organisation : Org A exige SAML SSO, Org B l’email/mot de passe ? MFA imposé seulement pour les clients enterprise ? Si chaque onboarding enterprise demande du code, tu vas cramer des cycles d’ingé.
- Personnalisation graphique du login : Peux-tu tout personnaliser par tenant ? Pas juste le logo/couleurs : CSS entier, domaines personnalisés, email en marque blanche. Choix entre UI hébergée et UI maison, jamais imposé.
Ce que la plupart des checklists oublient#
- Authentification silencieuse : À expiration du token, l’app peut-elle rafraîchir sans rediriger user ? Refresh token expiré : existe-t-il un fallback (session glissante via iframe, etc.) ?
- Lien de comptes : Signup Google puis tentative par email : 1 ou 2 comptes ? Merge d’identité ? Si tu rates ça, comptes fantômes garantis.
- Passwordless : Magic links, passkeys, WebAuthn. Aujourd’hui pas critique, mais les clients enterprise le demanderont sous 6 mois.
Dimension 3 : Gestion des sessions et tokens — Là où ça se complique#
C’est là que la différence entre démo et réel se joue. Gestion des sessions/token : ennuyeuse… jusqu’à la panne, où tout le monde se trouve déconnecté.
Sécurité des cookies#
Peu vendeur, totalement critique.
- HttpOnly, Secure, SameSite : Les trois OBLIGATOIRES. Si l’IdP ne met pas HttpOnly : pas prêt pour la prod.
- Support inter-sous-domaines : Si ton app vit sur
app.tonproduit.com et ton API sur api.tonproduit.com, la session traverse-t-elle les sous-domaines ? Comment ?
- Dépréciation des cookies tiers : Chrome les supprime. L’IdP gère comment l’auth cross-origin sans cookies tiers ? « On y travaille » ≠ réponse acceptable.
« Se souvenir de moi » et sessions persistantes#
Tes utilisateurs veulent des sessions de plusieurs semaines, pas minutes. Mais une session de 180 jours ≠ une session de 30 min niveau sécurité.
Questions :
- Peux-tu régler la durée des sessions indépendamment de la durée des tokens ?
- Option « se souvenir de moi » pour allonger la session en gardant des tokens courts ?
- Peux-tu imposer une réauth forte pour une opération sensible sans rompre la session ?
Sécurité des refresh tokens#
- Rotation des tokens : Le refresh token est-il renouvelé à chaque usage ? (obligatoire)
- Stockage chiffré : Les refresh tokens sont-ils chiffrés au repos ?
- Granularité de révocation : Peut-on révoquer la session d’un device sans couper toutes les sessions utilisateur ?
- Expiration configurable : Durée personnalisable par application, ou globalement seulement ?
Dimension 4 : Modèle d’autorisation — Bien au-delà du RBAC#
La gestion par rôles (RBAC) est la base. Si l’IdP n’offre pas le RBAC, inutile d’y penser. Mais en SaaS B2B, c’est insuffisant.
Permissions à périmètre orga#
Tes utilisateurs appartiennent à des organisations. Leurs permissions dans chaque orga différent des permissions platform.
Un utilisateur peut être admin sur Org A et viewer sur Org B. Même utilisateur, deux contextes. Si l’IdP ne sait pas modéliser ça, tu vas reconstruire un système en double.
À demander :
- Peux-tu définir des rôles au niveau orga, pas juste user ?
- Un utilisateur peut-il avoir différents rôles selon l’orga ?
- Le contexte d’orga courant est-il dans le token, pour ton API ?
Auth multi-niveau (auth_level)#
Finance, santé, toute op à risque : toutes les sessions authentifiées ne se valent pas.
Voir un dashboard ? Cookie de session suffisant. Initier un virement ? Nécessite MFA fraîche même logué.
On parle d’authentification « step-up » : la notion d’auth_level doit être native dans le token.
Questions :
- Le token porte-t-il un claim
auth_level exploitable par le backend ?
- Peux-tu déclencher un step-up sans full relogin ?
- L’expiration de l’
auth_level est-elle distincte de celle de la session ?
Pas supporté nativement ? Tu vas tout recoder — ce contre quoi tu voulais justement acheter un IdP.
Décisions d’autorisation token-based#
L’idéal : middleware API qui lit le token → org, rôle, niveau d’auth, autorisation décidée localement.
La réalité… : le token dit juste qui est l’utilisateur, pour savoir ce qu’il peut faire tu dois requêter l’IdP ou une base.
Ce call supplémentaire ajoute de la latence, crée une dépendance et ajoute un mode de défaillance. À 1 000 req/s, tu ne veux pas de dépendance réseau pour chaque vérification d’autorisation.
Dimension 5 : Migration — Le critère décisif#
Stat qu’on tait tous : la plupart des évaluations IdP n’échouent pas sur la qualité du produit, mais sur l’incapacité à migrer les utilisateurs existants.
Avec 100K+ utilisateurs, la migration n’est PAS un extra — c’est tout le projet.
Trois stratégies de migration (et lesquelles ton IdP DOIT couvrir)#
1. Import massif avec hash de mot de passe existant
Tes utilisateurs ont des mots de passe hashés en bcrypt, argon2, etc. L’IdP peut-il importer ces hash et les vérifier en direct ?
Oui : l’utilisateur se connecte comme avant, rien ne change — scénario idéal.
Non : reset du mot de passe général. Tu perdras 30 à 50 % de la base sur cette étape. Ce n’est pas théorique — déjà observé plusieurs fois.
2. Migration progressive (lazy)
Plutôt que tout migrer en bloc, tu le fais à la première connexion. Premier login interroge l’ancien système, vérifie le mot de passe, crée l’utilisateur dans le nouvel IdP. Les suivants passent directement dans le nouvel IdP.
La voie la plus sûre avec une grosse base, mais nécessite que l’IdP accepte :
- Un hook d’auth perso qui va taper dans l’existant
- Création à la volée d’utilisateur pendant le login
- Suivi qui a migré vs. qui non
3. Dual-write (systèmes parallèles)
Pendant la bascule, anciens et nouveaux systèmes cohabitants. Les écritures partent aux deux, les lectures migrent progressivement. Offre un « retour arrière », mais ajoute de la complexité opérationnelle.
Red flags migration#
- « On gère l’import CSV » — = import de profils, PAS de mots de passe : reset obligatoire
- « On a un guide de migration » — Lis-le : s’il impose un réinit mot de passe aux utilisateurs, tu perds 30-50 % de ta base
- Pas de mention des hash — Si le fournisseur n’a pas réfléchi au hashage, il ne joue pas dans ta cour
Points à demander#
- Quels algo de hash mot de passe sont importables ?(bcrypt, argon2, scrypt, PBKDF2, custom ?)
- Peut-on migrer progressivement utilisateur par utilisateur ?
- Peut-on suivre le taux de migration ?
- Quelle stratégie de rollback ?
- La continuité de session est-elle assurée (pas de déconnexion en migration) ?
Si le fournisseur hésite, passe ton chemin.
Dimension 6 : Multitenancy — Natif vs. bricolage#
SaaS B2B rime avec multi-tenancy : tes clients sont des organisations avec plusieurs users, rôles, policies d’accès. L’IdP doit comprendre ça nativement.
Ce que signifie « multi-location native »#
- Organisation entité de premier plan : Pas juste un champ custom dans le profil utilisateur, mais un vrai modèle de données : ID, conf, membres
- Politiques d’auth par orga : Org A = SAML/SSO, Org B = login/email/MFA, Org C = Google Workspace. Tout configuré UI/APIs, pas code.
- Invitations et gestion des membres : Admins invités, assignent rôles, suppriment membres. Invitation, vérification email et assignation des rôles gérés côté IdP.
- Tokens périmètres orga : Token indique l’orga active. L’API sait à qui renvoyer quelles données.
Le bricolage « métadonnées custom »#
Des IdP sans modèle d’orga natif préconiseront : stocker l’org_id dans user.app_metadata.org_id = "123".
Ça s’écroule :
- User multi-org : tableaux et gestions dans les métadonnées
- Pas de flow invitation/membres natifs
- Pas de policies auth séparées
- Pas de tokens scindés orga — faut inférer le contexte autrement
- Audit logs non orientés orga
Si tu entends « tu peux modéliser les org avec nos métadonnées utilisateur » : c’est l’équivalent d’un JSON dans une colonne relationnelle. Ça marche jusqu’à la casse.
Questions à demander#
- L’organisation est-elle native ou basée sur des métadonnées ?
- Les users peuvent-ils appartenir à plusieurs orgas ?
- Peut-on configurer des exigences différentes par organisation ?
- Rôles et permissions orga natifs ?
- Les admins org peuvent-ils gérer les membres en self-service ?
- Le token inclut-il le contexte d’orga ?
Dimension 7 : IA-readiness — Le critère encore ignoré#
Il y a 12 mois, « authentification d’agent IA » n’était sur aucune checklist. Aujourd’hui, si tu greffes des IA sur ton produit (copilotes, agents autonomes…), il te faut un IdP qui gère une nouvelle identité : l’agent.
Pourquoi les agents bousculent le modèle classique#
Classiquement : deux acteurs, l’utilisateur et l’application. OAuth2 a été conçu ainsi.
Les agents IA ajoutent un troisième : entité non-humaine agissant pour un user, permissions limitées, audit trail propre.
- Un agent n’est pas un user — pas de mot de passe/session browser
- Un agent n’est pas un service M2M — il agit au nom d’un user
- Un agent = permissions scope & durée limitée — pas tous les droits du user
Ce que l’IdP doit offrir#
Token Exchange (RFC 8693) : l’agent présente son credential + l’autorisation user, reçoit un token scope. Ce token porte : qui (user), quoi (agent), scope (barrière), quand (expiration).
Agent comme client OAuth dédié : L’agent est un vrai client OAuth2 avec son propre client_id, et pas un bricolage d’API key/user token.
Gestion déléguée du scope : L’utilisateur peut déléguer certains droits à l’agent : lecture, accès restreint à des ressources, etc.
Distinction d’audit : Logs qui font la différence entre « user a fait » et « agent a fait pour le user ». Sinon, tu rates tout audit SOC2 : « qui a modifié ceci ? ».
Compatibilité MCP (Model Context Protocol)#
MCP devient la norme d’auth pour agents IA qui opèrent sur des outils/services. Si ton IdP supporte l’auth OAuth pour serveurs MCP, les agents peuvent s’authentifier via le protocole, pas des API keys.
Questions à demander#
- Prise en charge OAuth2 Token Exchange ?
- Agents modélisés comme clients distincts ?
- Les tokens portent l’info de délégation (qui autorise + scope) ?
- Logs d’audit différencient-ils humain/agent ?
- Intégration MCP ou OAuth pour auth agent→outil ?
Si le fournisseur n’a pas réfléchi à ça : ils développent pour 2020, pas 2026.
Dimension 8 : Exigences non fonctionnelles — Ce qui t’empêche de dormir#
Les features font vendre. L’opérationnel fait renouveler.
- Débit d’authentification : Le système supporte-t-il 100+ req d’auth/sec ? et 1 000+ ?
- Latence de validation token : Tes services valident-ils les JWT localement (à privilégier) ? Si introspection requise, P99 ?
- Plafond de scalabilité : Maximum d’utilisateurs actifs mensuels supportés ? Preuves à la clé ?
- SOC2 Type II : Le Type I est instantané. Le Type II, audité dans la durée. S’ils n’ont que Type I, demander la feuille de route vers Type II.
- Logs d’audit : Tout event d’auth, changement de droit, action admin tracé. Exportable vers SIEM ? Logs immuables ?
- Résidence des données : Peux-tu choisir la région qui héberge les données utilisateurs ? Pour l’UE, c’est obligatoire.
Fiabilité#
- SLA uptime : 99,9 % = 8,7h/an de coupure. 99,99 % = 52 min. En auth = porte d’entrée du produit, la différence est vitale.
- Bascule : En cas de panne fournisseur : quel fallback ? Multi-datacenter ?
- Historique incidents : Regarde le vrai historique de leur status page, pas juste leurs promesses.
Portabilité des données#
- Export utilisateur : Export total des user datas (métadonnées, orgas, rôles) ? Format ?
- Respect des standards : Protocoles standard (OIDC, SCIM) = migration facilitée ensuite.
- Indice de non-verrouillage : API propriétaires, protocoles custom, tokens non standard : clignotants de lock-in. Plus l’intégration est fermée, plus la sortie sera douloureuse.
La matrice d’évaluation : un scoring pragmatique#
Après analyse de toutes les dimensions, il faut comparer. Voici un cadre de priorité :
P1 — Show-stoppers (obligatoire ou éliminatoire)#
| Critère | Pourquoi c’est P1 |
|---|
| Import hash mot de passe ou migration progressive | Non migrable = inutilisable |
| Authorization Code + PKCE support | Base de sécurité |
| Modèle d’organisation natif | Exigence SaaS B2B |
| SOC2 Type II ou roadmap claire | Tes clients enterprise l’exigeront |
| SLA uptime 99,9 %+ | Auth HS = produit HS |
P2 — Fortement préféré (gros coût d’ingé sinon)#
| Critère | Pourquoi c’est P2 |
|---|
| Claims JWT custom | Évite lookup permission à chaque requête |
| Policies d’auth orga | Onboarding client enterprise |
| Rôles/tokens orga natifs | Auth multi-tenant |
| Rotation/révocation refresh token | Bonnes pratiques sécurité |
| UI hébergée + UI custom possible | Flexibilité usages différents |
P3 — Important (à prévoir sous 12 mois)#
| Critère | Pourquoi c’est P3 |
|---|
| Token Exchange (RFC 8693) | Auth agent IA |
| Fonction fournisseur OIDC | Fédération partenaire |
| Auth step-up / auth_level | Op financières/à risque |
| Provisionning SCIM | Sync annuaires clients enterprise |
| Passkey / WebAuthn support | Vers le passwordless |
P4 — Bonus (ne bloque pas la décision)#
| Critère | Pourquoi c’est P4 |
|---|
| Dashboard analytics intégré | Faisable depuis les logs d’audit |
| Templates email white-label | Confort |
| Flow builder visuel | Confort |
| Connexions sociales préconfigurées (hors top 5) | Fournisseurs longue traîne |
À utiliser ainsi : Commence par P1. Un fournisseur échoue à une P1, stop. Ensuite, score P2/P3. Celui au meilleur score combiné gagne.
Erreurs classiques d’évaluation#
On a vu les équipes tomber dans les mêmes pièges encore et encore :
Erreur 1 : Évaluer les features, pas l’architecture#
Le tableau de features indique ce qui existe. Pas comment c’est bâti. Un IdP peut « gérer l’organisation »… en stockant un id dans la métadonnée user. Case cochée ≠ solution scalable.
Correction : Pour chaque feature, demande « comment ? », pas juste « avez-vous ? »
Erreur 2 : Oublier la migration jusqu’après le choix#
Équipe qui sélectionne le « meilleur » IdP, commence à intégrer… et découvre que toute la base doit réinitialiser son mot de passe. Piège ultime.
Correction : La migration doit être ton premier filtre. Pas le dernier.
Erreur 3 : Se fier à la démo#
Toute démo est soignée. Base vide. Aucun edge case. Ta prod : users merge, unicode improbable, sessions « fantômes »…
Correction : Exige un PoC avec tes vrais users. Importe 1 000 users réels, joue tes authentifications réelles.
Erreur 4 : Mauvais casting d’évaluateurs#
Équipe plateforme seule : prendra ce qui est « techniquement propre ». Produit seul : ce qui s’intègre facilement. Sécu seule : la compliance maximum.
Correction : Equipe d’éval = plateforme + produit + sécu. Chacun propriétaire de certains critères P1/P2.
Erreur 5 : Oublier qu’on partira un jour#
Le lock-in existe : SDK propriétaire, API custom, tokens bizarres = migration future complexe.
Correction : Privilégie IdP standard (OIDC, OAuth2, SCIM). Ton futur toi te dira merci.
FAQ#
Combien de temps dure typiquement une évaluation IdP ?#
Pour une éval sérieuse avec PoC, compte 4 à 8 semaines. Bâcler conduit direct aux erreurs (surtout la migration). Budgète 2 semaines pour recueil besoins, 2-3 semaines pour la shortlist et le PoC, 1-2 semaines pour alignement interne.
On construit notre auth maison ?#
Dépend du stade. Si tu as < 10 000 users, pas de clients enterprise, une lib d’auth légère suffit peut-être. Mais si tu as SSO, multi-tenant, MFA, compliance… la dette dépasse vite le coût d’un IdP dédié. Vu jusqu’à 2-3 ingés plein temps pour maintenir l’auth maison (~300-500 K$ / an en coût d’opportunité).
Différence entre CIAM et workforce IAM ?#
Customer Identity and Access Management (CIAM) = ce que vivent tes utilisateurs finaux (signup, login, profil). Workforce IAM = ce que tes salariés utilisent pour accéder aux outils internes (Okta pour Slack ou GSuite). Deux décisions d’achat, deux checklists. Ici, on parle CIAM.
L’open source vs. le propriétaire, c’est important ?#
Les IdP open source assurent transparence (audit du code), portabilité (auto-hébergement), communauté. Les IdP proprio, souvent plus UX et plus managés. Le plus important n’est pas « open vs. fermé », mais « puis-je partir si besoin ? ». L’open facilite la sortie, car le modèle de données/API est public.
Quand faire de l’auth agent IA un P1, pas un P3 ?#
Tu développes déjà des features IA qui accèdent aux données pour tes users (copilote, automation…) : mets-le P1. IA prévue à 6-12 mois : garde P3, mais pèse-le fort. IA hors radar : reste P4… mais revois dans 6 mois.
La plupart des IdP facturent à l’utilisateur actif mensuel (MAU). Mais la définition varie — certains comptent chaque login, d’autres chaque utilisateur unique, certains séparent tokens M2M. Demande un devis sur TON cas : X users, Y org, Z connexions M2M, volume d’auth prévu. Compare le coût total, pas le coût unitaire.
Ce qu’il faut retenir#
Choisir un fournisseur d’identité est une décision d’INFRASTRUCTURE, pas de features. Tu engages un système qui porte chaque première interaction utilisateur, chaque check de permission à l’API, chaque ligne de log compliance.
Le framework d’évaluation ci-dessus te donne les vrais critères — pas ceux du marketing. Utilise-le pour filtrer vite (P1 d’abord), tester en profondeur (P2/P3 en PoC), et choisir pour des années, pas des mois.
Les équipes qui réussissent tout ont un point commun : elles gèrent l’identité comme de l’infra — jamais comme une simple feature à livrer et oublier.
