Vous pouvez créer votre propre auth en une journée. C'est là le piège.

Des dizaines d’équipes B2B nous ont raconté la même histoire. Tout commence par une simple page de connexion. Puis le vrai trafic arrive et ça devient discrètement une infrastructure d'identité : le socle sur lequel repose tout votre produit.

Commencez gratuitement avec Logto

Discutez avec notre équipe

Ça avait l’air d'une fonctionnalité. Mais ça a laissé derrière tout un modèle d'identité.

Chaque auth maison commence par quelques lignes. Les ennuis commencent après le lancement, quand chaque petite décision devient discrètement le modèle sur lequel votre produit entier va s'appuyer.

Jour un : quarante lignes de code

Email, mot de passe, hash, stockage, comparaison à la connexion. Propre et terminé.

C'est exactement pour cela que chaque équipe commence ici, et pourquoi l'auth semble être quelque chose qu'on peut boucler en une après-midi.

Jour deux cent : un modèle d’identité silencieux

Qui compte comme utilisateur. À quelle organisation il appartient. Quelle session reste fiable. Comment retirer les accès.

Limites de fréquence, MFA et son flux de récupération, sessions, tokens de rafraîchissement, un modèle d’organisation bien plus compliqué qu’un simple booléen is_admin. Chaque choix que vous livrez devient une règle que le produit prendra silencieusement pour acquise.

Cinq ans plus tard : un socle qu'on ne peut plus toucher

Changer la page de connexion sur le papier voulait dire reconstruire tout le socle identitaire dans le code.

Un SaaS de 20 ans a voulu passer à l’email comme identifiant : les vérifications des permissions vivaient dans des centaines de modules. Personne ne voulait donner son accord donc le projet s’est éternisé, jusqu’à l’abandon.

Un auth maison fonctionne très bien — jusqu'à ce que le business évolue

Il connecte les utilisateurs sans incident pendant des années. Puis un changement business transforme du jour au lendemain "ça suffit" en "ça bloque tout". Ces trois points arrivent sur quasiment chaque produit qui devient conséquent.

Les clients entreprise demandent du SSO

Le premier gros contrat arrive et les achats veulent un SSO avec leur propre Entra ou Google Workspace. Puis les deux, SAML et OIDC, car le client d’après utilise autre chose. Chaque client a sa propre configuration d’identité, et quasiment rien ne se réutilise d’un client à l’autre.

Différents protocoles, champs à mapper, et rotation de certificats pour chaque client
Le SSO ne se construit pas une seule fois : vous le reconstruisez pour chaque entreprise signée
Ça devient un travail manuel qu’un seul ingénieur comprend de bout en bout

L'identité était fragmentée, maintenant elle doit être unifiée

Séparée par organisation, par produit, souvent héritée via des acquisitions. « Unifier l’identité » semble être une fonctionnalité ; en code, cela signifie redéfinir ce qu’est un utilisateur ou une organisation.

Un email peut-il appartenir à plusieurs organisations ? Comment migrer les anciens noms d'utilisateur ?
Neuf produits hérités via des rachats veut dire neuf piles authentification qui tournent en parallèle
Révoquez un départ sur tous les systèmes à la fois, et auditez-le au même endroit

Les agents IA et les CLIs agissent pour le compte d'un utilisateur

Il n'y a plus que des personnes sur un navigateur. Agents, serveurs MCP et lignes de commande prétendent agir pour un utilisateur. Et votre système d'auth sait seulement gérer la connexion d'une personne sur une page.

À qui est délivré le token, avec quel scope et public cible ?
Accordez l’accès à un seul outil ou une seule portion de données, puis révoquez-le après
Les accès MCP et CLI passent par OAuth, pas un formulaire de connexion

Le vrai coût n'est pas la construction. C'est de le porter pendant des années.

La première version coûte peu : quelques ingénieurs, quelques semaines, et c’est livré. Puis il faut continuer à l’alimenter chaque année, avec un temps d’ingénierie qui aurait dû servir votre produit cœur.

La facture a juste changé de forme

Vous ne recevrez jamais de facture intitulée « authentification ».

Vous payez en mois-personnes, retards de livraison, dette de sécurité, et retouches. Une organisation d’adhérents l’a construit maison pour éviter une licence ; cinq ans après, la maintenir leur a coûté plus cher que l’achat n’aurait coûté.

Ça repose discrètement sur une ou deux personnes

Le contexte critique est dans la tête de quelqu'un, pas dans la doc.

Quel client est configuré comment, pourquoi telle migration a été faite ainsi. Quand la personne est absente, la pipeline entreprise s'arrête. Quand elle part, ce savoir quitte l’entreprise avec elle.

Où voulez-vous vos ingénieurs ?

Aucun client ne vous paiera un centime de plus parce que vous avez écrit votre propre serveur OAuth.

L’auth doit être fiable. Mais « fiable » ne signifie pas « développé par vous ». Pour la majorité des produits, c’est une dépendance clé, pas un différenciateur. Ces deux choses n’ont rien à voir.

Si vous ne le faites pas vous-même, comment choisir ?

La plupart des solutions d'auth matures gèrent déjà SSO, MFA, organisations, login unifié, accès agent. Ce qui change vraiment, c’est si vous pouvez partir. Ne quittez pas votre propre pile de quelques milliers de lignes pour vous retrouver enfermé ailleurs.

Des protocoles standards, pas une pile inventée

OIDC, OAuth et JWT signés RS256 que vous comprenez déjà. Lisez directement les claims sur un token standard, sans API spécifique à apprendre.

Une porte vraiment ouverte

Si c'est open source et auto-hébergé, vous partez quand vous voulez. Ne troquez pas votre système custom pour une solution hébergée dont vous ne pouvez plus sortir.

Une facturation qui ne dépend pas de votre base d'utilisateurs

Facturer par utilisateurs inscrits ou actifs mensuels suit une table qui ne cesse de grossir. À grande échelle, c’est une « taxe à la croissance », la raison pour laquelle tant d’équipes internalisent l’auth.

Vos données ne sont jamais enfermées

Exportez les données utilisateurs quand vous voulez. Et confier ces données sensibles à un spécialiste vous protège contre le risque de garder des piles de PII pour lesquelles vous n’êtes pas le bon acteur.

L'auth n'est probablement pas votre cœur de métier. Traitez-le comme tel.

Logto est open source, auto-hébergé, et aussi disponible en Cloud managé. Connexion, MFA, SSO et RBAC fonctionnent en standard OIDC. La facturation suit les tokens — et quand vous souhaitez changer, la porte reste ouverte.

Commencez gratuitement

Nous contacter

Foire aux questions

Ne devrait-on jamais créer son propre système d’authentification ?

Non. Pour une démo précoce, un outil interne, un projet de validation ponctuel, ou des besoins hyper spécifiques d'autorisation fine que les solutions du marché ne couvrent pas, créer la sienne (ou la moitié) peut être pertinent. À éviter : assumer à long terme une brique générique d’infrastructure identité sans s’en rendre compte, et la mettre sous la responsabilité d’une équipe business.

Quelle différence entre authentification et autorisation ?

Pourquoi le SSO entreprise complique-t-il la gestion maison de l’auth ?

Nous avons géré notre auth pendant des années. On peut encore migrer ?

Oui, mais une bascule unique et brutale est rarement la voie à suivre. Le chemin réaliste, c’est de migrer par strates : mettre les nouveaux inscrits, nouvelles connexions et nouveaux SSO sur la nouvelle plateforme d’identité, puis migrer graduellement les utilisateurs existants lors de leur prochaine connexion. Unifiez d’abord annuaire et modèle organisation, puis affinez progressivement les droits, toujours avec rollback et audit.

Pourquoi les agents IA et MCP créent-ils une nouvelle pression sur l’auth ?

Parce qu’ils posent une nouvelle question : un client demande l’accès à des ressources pour le compte d’un utilisateur. Si l’ancien système ne gère que la connexion d’une personne à une page, il ne sait pas qui reçoit le token, ce qu’il couvre, comment le révoquer, ni qui doit apparaître dans les journaux d’audit. Au fond, c’est un changement métier du même type que le SSO entreprise, mais déclenché par une nouvelle évolution.