Pourquoi vous ne devriez pas créer votre propre système d’authentification : leçons tirées de dizaines d’entretiens clients

L’authentification semble être quelque chose que tu peux faire toi-même. Email, mot de passe, hasher, comparer à la connexion. À quel point cela peut-il être difficile de construire ton propre système d’authentification ?

Tu peux le faire. C’est le piège.

Nous avons discuté avec des dizaines d’équipes à propos de l’auth qu’elles avaient construite elles-mêmes. La plupart sont venues vers nous pour la même raison : cela freinait l’entreprise.

Différentes industries, stacks, tailles, mais une même finalité. L’auth qu’ils avaient créée était devenue une dette technique que l’équipe traînait avec elle.

La partie étrange, c’est que cela n’apparaît jamais comme une panne. Le système connecte les gens et fonctionne bien, jusqu’au jour où un changement business bloque tout : une revue de sécurité, le premier client entreprise, une acquisition, une fonctionnalité couvrant deux produits.

La semaine dernière, tout allait « bien ». Ensuite, la prochaine étape de la roadmap est bloquée derrière ça.

La plus grosse erreur avec une auth maison est de la considérer comme une fonctionnalité. Tu peux l’écrire le premier jour. Mais une fois que du vrai trafic passe par là, ça devient inextricable avec tes utilisateurs, organisations et autorisations.

L’authentification n’est pas une fonctionnalité. C’est une infrastructure d’identité.

Derrière la page de connexion se cache tout un modèle d’identité#

Chaque système d’auth maison commence de la même façon. Prends un email et un mot de passe, hash, stocke, compare à la connexion. Quarante lignes de code, propre et terminé.

Les ennuis commencent après le lancement. Des bots bombardent ton endpoint d’inscription, alors tu ajoutes du rate limiting, un CAPTCHA, de la prise d’empreinte de l’appareil. Les codes SMS ne partent plus un matin, alors tu greffes des tentatives/reprises et un plafond quotidien. Ensuite viennent les parties difficiles : la réinitialisation sécurisée du mot de passe, la MFA et sa procédure de récupération, les sessions et tokens de rafraîchissement, et un modèle d’autorisations bien plus complexe qu’un simple booléen is_admin.

Rien de tout cela n’est difficile en soi. Chacun tient dans un sprint. Mais à chaque livraison, tu réponds à une question de plus sur le produit.

Empile ces réponses, et tu obtiens le modèle d’identité que ton produit suppose désormais comme acquis : qui compte comme utilisateur, si une personne peut appartenir à plusieurs organisations, comment le système d’identité d’un client entreprise s’intègre, et comment on retire l’accès quand quelqu’un part.

Chaque fonctionnalité que tu écris après tient pour acquises ces réponses, et plus ça dure, plus il est difficile de les changer.

Nous avons vu cela dans une entreprise : un SaaS vertical B2B, vingt ans d’existence, pour des commerçants traditionnels. Ils ont construit leur auth il y a plus de dix ans, avec une connexion distincte par client et des contrôles de permissions écrits directement dans les modules métiers. À l’époque, c’était le choix raisonnable.

Vingt ans plus tard, ils voulaient une chose qui semble mineure : une page de connexion unifiée, avec l’email comme identifiant. Ce n’était pas une simple modification de page. Les contrôles étaient éparpillés dans des centaines de modules, et unifier la connexion impliquait de toucher au modèle utilisateur, à celui de l’organisation, à la migration des identifiants et à toutes les frontières d’autorisations. Personne ne voulait valider ça, alors ça a traîné pendant des années.

Quand ils ont écrit cette première page de connexion, cela leur semblait être une fonctionnalité. Ce que ça a laissé derrière, c’est tout un modèle d’identité.

Quand ton entreprise va plus loin, l’auth maison devient souvent insuffisante#

Pour être honnête, l’auth maison fonctionne généralement pendant longtemps. Elle connecte les gens, actualise les sessions et supporte l’activité quotidienne pendant des années. Sa complexité s’accumule lentement, jamais d’un coup, et tu la traites petit à petit en pensant la contrôler.

Mais rester « suffisant » signifie souvent simplement que l’entreprise n’a pas encore atteint sa limite. Quand ça arrive, le problème n’est généralement pas l’auth elle-même. C’est l’activité autour qui a changé, et « suffisant » devient « un obstacle » du jour au lendemain.

Les situations ci-dessous apparaissent pour la plupart des produits à mesure qu’ils grandissent. Elles semblent différentes, mais c’est la même chose en profondeur : l’activité progresse, et l’ancien modèle d’identité ne suit plus.

Les clients entreprise demandent du SSO#

Le scénario : un client veut se connecter avec son propre IdP, et ton système d’auth n’a aucune notion de « fournisseur d’identité externe ».

Le premier vrai contrat entreprise tombe, et la cellule achats envoie une liste d’exigences. D’abord, c’est le SSO via Microsoft Entra ou Google Workspace. Ensuite, il faut SAML et OIDC, parce que le client suivant utilise autre chose. Puis c’est SCIM, pour approvisionner ou retirer automatiquement les employés.

Chaque client a son installation différente : protocoles, champs, rotation des certificats, et façon dont leur structure d’organisation se mappe à la tienne.

Presque rien de ce travail n’est réutilisable. Le client suivant arrive avec un IdP différent et une nouvelle configuration, et tout recommence. Le SSO n’est pas une fonctionnalité à développer une fois. À chaque gros client, tu recommences, et le coût augmente avec le nombre de clients.

L’auth n’est plus « permettre aux utilisateurs de se connecter à ton produit ». C’est « permettre à ton produit de s’intégrer au système d’identité du client ». Deux métiers totalement différents.

Nous avons vu une entreprise où toute la configuration SSO était manuelle, et un seul ingénieur la connaissait en entier. Quand il était là, les clients étaient mis en ligne. Quand il partait en congé, les ventes et l’onboarding s’accumulaient. Quand il est parti, le savoir est parti avec lui.

Rien de tout cela n’était envisagé le jour où ils ont décidé de faire leur propre auth.

Le produit a besoin d’unifier des identités éclatées#

Le scénario : tes données d’identité sont fragmentées, séparées par organisation et par produit, et à mesure que l’entreprise grandit tu as besoin d’une identité unifiée.

La société de vingt ans évoquée plus haut a rencontré ce mur en voulant unifier la connexion, et ce schéma se retrouve ailleurs. Nous avons travaillé avec une plateforme comptant neuf produits, tous venant d’acquisitions, chacun gardant sa propre auth et base utilisateur.

Une acquisition ne fusionne pas ça pour toi. Chaque produit acheté t’ajoute une pile auth en plus, et maintenir neuf systèmes parallèles prend un vrai effectif rien que pour l’entretien.

Les questions s’accumulent. La même personne est-elle un utilisateur unique sur les produits A et B, ou deux ? Comment aligner le même client/organisation sur les deux ? Comment autoriser une fonctionnalité transproduit ? Quand un salarié part, comment retirer son accès partout ? Et où suivre tout ça ?

Aucun des neuf systèmes n’est cassé. Ensemble, c’est un mur.

« Unifier l’identité » semble être une fonctionnalité. En code, cela implique de redéfinir la chose la plus fondamentale qui soit : ce qu’est un utilisateur et une organisation. Presque chaque fonctionnalité repose sur l’ancienne définition, donc la changer fait bouger toute la couche au-dessus.

À l’ère de l’IA, des agents et CLIs agissent pour l’utilisateur#

Le scénario : ce ne sont plus seulement des personnes qui se connectent via un navigateur. Désormais, des agents, lignes de commande et scripts revendiquent aussi agir au nom de tel ou tel utilisateur, alors que ton auth ne connaît qu’une seule chose : une personne se connectant sur une page.

Un agent doit appeler tes outils internes pour un utilisateur. Un serveur MCP veut exposer des ressources protégées en toute sûreté. Un CLI doit accéder à des données de compte sans navigateur.

Les trois se heurtent aux mêmes questions : pour quel utilisateur agit cette requête, quelles ressources peut-elle toucher, à qui appartient le token, quelle est sa portée, comment le révoquer, et journalise-t-on l’utilisateur ou l’agent ?

L’ancien système n’avait jamais prévu les mécanismes nécessaires à ces clients. MCP s’appuie sur OAuth pour l’autorisation. Un CLI passe par une connexion OAuth ou utilise un personal access token se substituant à l’utilisateur et révocable à tout moment. Rien de tout cela n’a été conçu pour une page de login.

Si ton auth a été pensée pour une personne se connectant sur une page, c’est maintenant qu’il faut gérer un client accédant au nom de cette personne.

La maintenance à long terme est le plus gros coût de l’auth maison#

Aucune des situations ci-dessus n’est « l’auth plantée ». Le système tourne encore. Chacune semble être une petite fonctionnalité, mais dès que tu commences, c’est une question de stratégie produit, migration de données, et livraison client.

La MFA est l’exemple le plus clair. À première vue, c’est « peut-on vérifier encore une fois après la connexion ».

Deux étapes plus loin, voici : pour quelles organisations et utilisateurs est-elle obligatoire, un admin peut-il l’imposer à ses membres, les actions sensibles comme changer les infos de paiement ou exporter des données doivent-elles être revérifiées, comment générer et remettre à zéro les codes de secours, le support technique peut-il les réinitialiser, et la MFA d’un utilisateur SSO t’appartient-elle à toi ou à l’IdP du client ? Ajouter la MFA, c’est amener toute une couche de politique de sécurité.

« Il suffit de synchroniser quelques utilisateurs » raconte la même histoire : derrière, une chaîne de décisions autour de l’onboarding, l’offboarding, et les appartenances multi-organisations, chacune supposant que tes modèles utilisateur et organisation étaient bien pensés à la base.

Plus tu ajoutes de fonctionnalités, plus tu entretiens un produit d’identité à l’intérieur de ton produit. La première version coûte peu, quelques ingénieurs, quelques semaines. Mais tu continues à la nourrir année après année.

Le coût caché : la facture simplement change de forme#

La raison la plus courante de faire ton propre système, c’est le coût, et ce n’est pas naïf.

Une organisation associative que nous avons interrogée a fait le calcul il y a cinq ans. Elle avait environ 100 000 membres, mais seulement quelques milliers se connectaient régulièrement. Les fournisseurs facturent au nombre total de membres, le devis a explosé le budget, et faire le système soi-même revenait moins cher. Cette année-là, ce n’était pas un mauvais choix.

Cinq ans plus tard, les calculs s’étaient inversés. Maintenir leur propre login et le garder sécurisé leur avait déjà coûté plus cher qu’acheter une solution.

La première année, la facture évitée est visible et le temps d’ingénierie ne l’est pas. Au bout de cinq ans, le montant évité est similaire, mais le temps d’ingénierie est devenu des délais dans la roadmap, de la dette de sécurité, et de la maintenance dont personne ne veut hériter.

Donc faire ta propre auth n’est pas gratuit. Tu ne reçois juste jamais de facture intitulée « abonnement authentification ». Tu la paies en mois-homme, échéances glissantes, rework, dette de sécurité, et attention d’ingénieur qui aurait dû servir au cœur du produit.

Quelques ingénieurs finissent par tout porter#

Cet ingénieur qui gère à la main le SSO, ce n’est pas un cas isolé. Garde ton auth maison assez longtemps, et le contexte critique repose sur une ou deux personnes : quel client a quoi, quel champ ne jamais toucher, pourquoi telle migration dans le passé a été faite ainsi. Cela finit rarement dans la doc. C’est dans la tête de quelqu’un.

Quand il est là, la livraison avance. Quand il n’est pas là, le pipeline entreprise bloque, et tu te rends compte que ton infra la plus critique n’a pas de propriétaire, juste « la personne qui sait ».

Certaines équipes poussent plus loin et construisent une plateforme de configuration SSO self-service pour leurs clients. Ça semble mature, jusqu’à ce qu’on demande combien de clients elle sert vraiment. Nous en avons vu une avec 1,5 million d’utilisateurs actifs mensuels qui exploitait tout ça pour à peine une douzaine de clients.

Tu pensais créer une fonctionnalité. Tu créais un produit interne, avec le coût réparti sur une poignée de clients. Si l’identité est ton métier, ça vaut le coup. Sinon, c’est la facture cachée dans sa forme la plus pure.

Où veux-tu mettre tes ingénieurs ?#

Revenons à ce SaaS vertical de vingt ans. Ce ne sont pas de mauvais ingénieurs. Maintenir un produit métier pendant vingt ans prouve justement qu’ils connaissent bien leurs clients.

C’est justement le problème. Soyons francs : veux-tu qu’ils gèrent à la main le SSO de chaque client et extraient vingt ans de logique d’autorisations de centaines de modules, ou préfères-tu les voir aller plus loin sur le logiciel métier lui-même ?

Ce n’est pas du perfectionnisme technique. C’est une question de ressources. Que tu fasses du paiement de factures, du vertical SaaS, un portail associatif, ou des outils opérationnels, aucun client ne te paiera un centime de plus parce que tu as codé toi-même ton serveur OAuth.

Une équipe « bill-pay » nous l’a dit simplement : leur IdP maison était correct, mais c’est un choix stratégique. Ne code pas trop d’auth. Garde ton énergie pour que le paiement de factures soit excellent, et utilise l’auth éprouvée du marché pour le reste.

L’auth doit être fiable. Mais « fiable » n’est pas synonyme de « fait maison ». Ta base de données, l’envoi de mails, et le cloud doivent aussi l’être, et une équipe mature ne considère pas qu’une brique doit être interne parce qu’elle est importante.

Pour la plupart des produits, l’auth est une dépendance essentielle, pas un avantage compétitif. Sauf si l’identité est ton métier, entretenir un produit d’identité dans ton produit, ce n’est généralement pas un avantage. C’est une fuite de ressources à long terme.

Quand est-ce encore ok de faire sa propre auth ?#

C’est facile d’aller à l’extrême : ne jamais coder d’auth. Ce serait faux aussi.

À certaines étapes, faire soi-même (ou à moitié) est sensé : démos internes, prototypes précoces, expérimentations. Et si ton business a de l’autorisation ultra pointue que le marché exprime mal, garder cette partie en interne — et laisser une plateforme externe gérer l’authentification, les sessions, le SSO, la MFA et l’annuaire utilisateurs — est parfaitement raisonnable.

Mais attention à la pente POC. On a vu le schéma classique : deux développeurs passent six à huit mois sur un prototype pour intégrer un système externe. La démarche n’est pas mauvaise. Dans leurs mots, « ça marche bien ». Cela n’a juste jamais été conçu pour tenir l’échelle.

Or, un POC est ce qu’il y a de plus facile à verrouiller dans une architecture de long terme. Six mois plus tard, c’est « la solution actuelle », deux ans plus tard « le legacy », cinq ans plus tard « l’infra qu’on n’ose plus toucher ». Le meilleur moment pour quitter l’auth maison n’est généralement pas quand ça casse. C’est avant que ça devienne la fondation.

Donc la vraie question, c’est : ce n’est pas de savoir si tu as déjà écrit du code d’auth. C’est de savoir si tu t’es imposé une couche d’infrastructure d’identité générique que tu vas devoir entretenir sur le long terme.

Construis tes briques différenciantes toi-même. Sois prudent avec la couche d’identité fondamentale. Et ne te retrouve pas, sans t’en rendre compte, à bâtir une plateforme CIAM complète.

Si tu ne la construis pas, comment choisir une solution d’auth ?#

Si tu décides de ne pas tout faire toi-même, la question suivante arrive : qui choisir, et comment ?

La plupart des solutions matures couvrent déjà les fonctionnalités : SSO, MFA, multi-organisations, connexion unifiée, accès agents. Donc la vraie différence n’est généralement pas dans la colonne « features ».

Ce qui est plus difficile à voir, et vaut d’être comparé, ce sont les points ci-dessous. Ce sont des aspects d’une même chose : ne sors pas d’un bricolage maison pour t’enfermer dans un système impossible à quitter.

• Tiens-toi aux protocoles standards, pas aux inventions d’un éditeur. OIDC, OAuth, JWT signés en RS256 sont des choses que tu maîtrises déjà. Tu lis les claims directement dans un token standard, sans devoir apprendre une API propriétaire.
• Garde une porte de sortie accessible. Si la solution est open source et auto-hébergeable, tu pars quand tu veux. (Maintenir une version auto-hébergée sur la durée a bien sûr ses propres coûts cachés.)
• Ne laisse pas la facturation suivre ta table utilisateurs. Facturer à l’utilisateur enregistré ou à l’actif mensuel suit une table qui ne fait que croître, blindée de gens qui ne se connectent plus, et à l’échelle ça devient une « taxe sur la croissance ». C’est ce pricing qui a poussé l’association évoquée plus haut à construire en interne.
• Tes données ne seront pas prisonnières. Tu peux exporter les utilisateurs quand tu veux. Et laisser ces données sensibles à un hébergeur spécialisé t’évite de garder un gros tas de données non faites pour être entre tes mains.

Transparence : Logto est le produit d’auth que nous avons conçu en réponse à ces quatre points. C’est open source, auto-hébergeable, et proposé aussi en Cloud managé : utilise Cloud pour zéro maintenance, ou auto-héberge la version open source pour garder la main, et si tu veux en sortir un jour, la porte est toujours ouverte.

Connexion, MFA, SSO et RBAC fonctionnent out-of-the-box sur OIDC standard, et la facturation suit les tokens, donc tu paies l’usage réel.

Il y a d’autres options matures sur le marché, et l’auth n’a jamais eu une seule réponse universelle. Si tu compares, j’ai écrit un article sur comment choisir une solution d’identité que tu peux consulter.

Conclusion : ne confonds pas une plateforme d’identité long terme avec une simple fonctionnalité#

Créer son auth maison est généralement raisonnable le premier jour. Le piège, c’est que ça devient de l’infrastructure ensuite.

Chaque avancée du business remet ça sur la table : les entreprises veulent le SSO, la sécurité veut la MFA, le produit demande une connexion unifiée, plusieurs produits doivent se connecter, les agents d’IA veulent accéder aux ressources au nom d’un utilisateur. Derrière chaque « petite fonctionnalité » il y a une chaîne de décisions d’organisation, et l’alimenter sur la durée mange du temps d’ingénieur qui devrait revenir au cœur produit.

Cette « facture » n’arrive pas le premier jour. Elle se manifeste souvent des années après. À ce moment tu vois enfin ce qui s’est joué : la page de connexion que tu avais écrite à l’époque était déjà une brique d’infrastructure destinée à soutenir tout le cycle de vie de ton produit.

L’auth n’est probablement pas le cœur de ton business. Plus vite tu l’intègres, plus vite tu pourras remettre ton temps, ton énergie et tes ressources sur le produit que tu veux vraiment construire.

FAQ#

Ne devrait-on vraiment jamais coder sa propre authentification ?#

Non. Démos internes précoces, outils en interne, expérimentations, ou autorisations très fines impossibles à exprimer avec des solutions du marché sont des cas où c’est valable. Ce qu’il faut éviter, c’est d’accepter, sans s’en rendre compte, de porter structurellement une infrastructure d’identité générique à long terme dans le périmètre de maintenance d’une équipe métier.

Quelle est la différence entre authentification et autorisation ?#

L’authentification répond à « qui es-tu ». L’autorisation à « que peux-tu faire ». Dans un vrai SaaS, les deux sont presque inséparables : utilisateurs, organisations, rôles, permissions, sessions, claims de tokens, logs d’audit, tout s’entremêle. Donc migrer une auth ne concerne pas qu’une page de connexion.

Pourquoi le SSO d’entreprise complique-t-il l’auth maison ?#

Car cela implique de brancher ton produit sur le système d’identité du client. Chaque client a ses IdP, protocoles, champs claims, certificats, mappings de structure. Connecter le premier n’implique pas de pouvoir copier/coller les suivants. Très souvent, cela devient du bricolage que seul un ingénieur comprend.

On tourne sur du maison depuis des années. Peut-on migrer ?#

Oui, mais une bascule brusque n’est généralement pas la bonne méthode. Migre par étapes : mets les nouvelles inscriptions, connexions, SSO d’entreprise sur la nouvelle solution, et migre les utilisateurs existants lors de leur prochaine connexion. Garde une porte arrière et des logs d’audit tout du long, pour que la migration ne soit jamais irréversible.