Présentation de Prelude Auth : Qu'est-ce que l'authentification et comment nous la repensons

Qu'est-ce que l'authentification, au juste ?

L'authentification répond à une seule question, encore et encore : s'agit-il de la même personne que précédemment ?

Il est facile de confondre l'authentification et la vérification, car elles se produisent généralement à quelques minutes d'intervalle et donnent l'impression d'un flux continu pour l'utilisateur. Pourtant, elles résolvent des problèmes différents, selon des calendriers différents : 

• La vérification a lieu une seule fois, généralement lors de l'inscription. Elle confirme qu'une information, telle qu'un numéro de téléphone, une adresse e-mail ou un document, est réelle et appartient à la personne qui la fournit.

• L'authentification a lieu à chaque fois par la suite. Elle confirme que la personne actuellement connectée à la session est bien la même que celle qui s'est vérifiée initialement.

La vérification est un point de passage unique. L'authentification est une question permanente, posée à chaque connexion, à chaque action sensible, à chaque retour sur le site. Une application bancaire ne vérifie pas votre numéro de téléphone à chaque fois que vous consultez votre solde, mais elle vous authentifie à chaque fois que vous ouvrez l'application.

La plupart des méthodes d'authentification se classent en trois catégories : ce que vous connaissez (un mot de passe), ce que vous possédez (un téléphone, une clé de sécurité) et ce que vous êtes (une empreinte digitale, un visage). Les architectures d'authentification modernes combinent généralement au moins deux facteurs — l'authentification multifacteur — car un facteur unique est à la merci d'une fuite de base de données pour devenir inutile.

Cette partie du problème est bien comprise. Ce qui l'est moins, et qui pose réellement problème en production, c'est ce qui se passe entre la vérification et l'authentification, et ce qui se passe après la première connexion.

Là où la plupart des architectures d'authentification ont des angles morts

Si vous avez déjà développé ou acheté un système d'authentification, cela vous semblera familier. Une architecture classique ressemble à ceci : un fournisseur de vérification gère le code à usage unique (OTP), un outil de lutte contre la fraude évalue le risque de son côté, un fournisseur d'identité gère les sessions de connexion, et un SDK d'empreinte numérique d'appareil vient s'ajouter par-dessus, le plus souvent déconnecté des trois autres. 

Chaque brique fait son travail. Aucune ne communique avec les autres. Cela crée trois angles morts bien précis :

Les sessions vivent de manière isolée. Un utilisateur vérifie son numéro de téléphone, confirme un appareil et passe un contrôle de fraude lors de son inscription. Puis, il se connecte, et la session créée n'en sait absolument rien. Tous ces signaux, recueillis quelques secondes plus tôt, s'évaporent dès que l'authentification commence.

La détection de la fraude intervient trop tard. L'évaluation des risques est généralement une couche distincte, aveugle à ce qui s'est passé lors de l'onboarding et de la vérification du téléphone. Un utilisateur jugé suspect lors de l'inscription peut se connecter librement par la suite, car rien n'a transmis ce score de risque.

L'IA n'a pas de réponse dans l'authentification historique. La plupart des systèmes d'authentification ont été conçus autour d'une hypothèse simple : chaque session appartient à un être humain. Cette hypothèse est désormais obsolète. 

Les données de Cloudflare Radar, partagées par le PDG Matthew Prince en juin 2026, ont montré que les requêtes automatisées représentaient 57,5 % du trafic HTTP vers les contenus HTML, contre 42,5 % pour les humains. C'est la première fois dans l'histoire de l'internet que les bots sont plus nombreux que les humains en ligne, avec environ dix-huit mois d'avance sur les propres prévisions de Cloudflare. Les systèmes d'authentification historiques n'ont aucun mécanisme pour distinguer un agent légitime d'un agent malveillant, car ils n'ont jamais été conçus pour poser cette question à l'origine.

Ce n'est pas un problème hypothétique. Le détournement de session (session hijacking), en particulier, est devenu la méthode préférée pour contourner les défenses de connexion traditionnelles : le rapport SpyCloud's 2026 Identity Exposure Report a enregistré 8,6 milliards de cookies de session et d'identifiants volés récupérés dans les milieux cybercriminels en une seule année, et en juillet 2026, l'entreprise avait dépassé le cap des mille milliards de données d'identité récupérées, les données de session volées étant explicitement désignées comme ayant détrôné les mots de passe en tant que cible prioritaire des attaquants. Un cookie de session volé permet de contourner complètement le formulaire de connexion. Aucun des angles morts mentionnés ci-dessus n'est équipé pour détecter cela.

Pourquoi nous avons créé Prelude Auth

Le produit Prelude n'a pas commencé par l'authentification. Prelude a débuté sous la forme d'une API de vérification de téléphone, acheminant, délivrant et évaluant les OTP pour des entreprises comme BeReal, Sunday, Suno et Voodoo. 

Le manque est alors devenu évident : la plupart des entreprises n'ont pas un seul outil avec un angle mort, elles en ont trois. C'était généralement une combinaison d'un outil de vérification, d'un outil de lutte contre la fraude et d'un outil d'authentification, et aucun ne communique avec l'autre. L'authentification était la couche manquante : celle qui décide si une session récurrente est digne de confiance, en utilisant les mêmes signaux déjà collectés lors de l'inscription.

C'est le problème que résout Prelude Auth. 

Il ne s'agit pas d'un gestionnaire de session d'appoint greffé à côté de notre API de vérification. Il est construit sur le même graphe de signaux. L'identifiant de l'appareil (Device ID), l'empreinte réseau et le score de fraude générés lors de la vérification du téléphone alimentent directement chaque décision d'authentification, chaque déclencheur d'authentification renforcée (step-up) et chaque score de confiance de session qui en découle. La question n'est plus « s'agit-il d'un numéro de téléphone valide ? » lors de l'inscription et « s'agit-il d'un mot de passe valide ? » lors de la connexion, posée par deux systèmes qui ne partagent jamais leurs informations. Elle devient une seule question continue, traitée par une seule et unique plateforme : s'agit-il d'un utilisateur réel et de confiance ?

Ce que fait concrètement Prelude Auth

Prelude Auth est une API d'authentification complète : gestion des utilisateurs, connexion multi-méthodes, suivi des sessions et gestion des profils, le tout via une interface REST unique.

Toutes les méthodes de connexion attendues par vos utilisateurs. Connexion par OTP par SMS ou e-mail, e-mail et mot de passe avec des règles configurables, et connexion sociale via Google, Apple, Microsoft, GitHub et Okta. Le SSO via SAML est opérationnel dès le premier jour, de sorte que la conclusion d'un contrat de niveau entreprise ne nécessite pas de reconstruire une infrastructure d'authentification à partir de zéro.

Des signaux qui persistent au-delà de la connexion. Les OTP par SMS et par e-mail transmettent les signaux de l'API de vérification directement dans la session. Toutes les autres méthodes de connexion alimentent le même graphe de confiance des appareils, de sorte qu'un utilisateur s'étant vérifié une fois par OTP n'a pas besoin de se revérifier pour modifier son mot de passe. Auth suit l'état de vérification par session et le conserve pour les actions suivantes.

Une authentification renforcée (step-up) selon vos règles. Pour les actions sensibles telles que les paiements, les modifications de mot de passe ou les exports de données, Auth appelle un webhook sur votre backend avec tout le contexte nécessaire, et vous décidez de la suite à donner. Combinez librement les types de vérification : verify_sms, verify_email, biometric_check, kyc_review, document_scan, security_question.

Détection des bots et des agents à la périphérie (edge). L'empreinte réseau identifie les clients avant même qu'ils n'atteignent le flux d'authentification, que ce client soit un navigateur, une application mobile ou un agent d'IA. La corrélation des identifiants d'appareils bloque les comptes synthétiques et les attaques automatisées sans ajouter de friction pour les utilisateurs réels. Cela est d'autant plus important avec la transition vers les clés de sécurité (passkeys) à l'échelle de l'industrie : le rapport State of Passkeys 2026 de la FIDO Alliance évalue l'adoption mondiale des passkeys à environ 5 milliards d'utilisations actives, avec une notoriété de 90 % chez les consommateurs et 68 % des entreprises qui déploient ou mettent en œuvre activement des passkeys pour la connexion de leurs collaborateurs. À mesure que les mots de passe disparaissent, le signal d'importance n'est plus ce qu'un utilisateur sait, mais depuis quel appareil et quelle session il opère réellement, ce qui est précisément la raison d'être de la corrélation d'appareils.

La sécurité appliquée au niveau du protocole. Chaque session utilise les jetons de preuve de possession RFC 9449 DPoP, liés à la paire de clés du client, avec une révocation automatique sur toutes les sessions si un jeton est réutilisé. Chaque connexion sociale passe par PKCE, de sorte qu'un jeton volé est inutile sans un vérificateur qui ne quitte jamais le navigateur.

Conçu pour faciliter la migration. Une API REST propre, des jetons JWT standards et des SDK pour iOS, Android et React Native reprenant des modèles familiers. Importez vos utilisateurs existants et vos champs personnalisés via l'API de gestion, sans réauthentification forcée. Un flux d'authentification complet — lancer l'OTP, vérifier l'OTP, obtenir la session — tient en moins de 15 lignes de code.

Sous le capot : certifications SOC 2 Type II et ISO 27001, données chiffrées au repos et en transit, hébergement au sein de l'UE, et jamais vendues ni partagées.

Pourquoi les équipes font la transition

Les équipes qui passent à Prelude Auth ne recherchent généralement pas une fonctionnalité unique. Elles consolident : elles remplacent un fournisseur de vérification, un outil de détection de fraude et un fournisseur d'identité par une plateforme unique qui partage un graphe de signaux, au lieu de trois outils distincts qui ne communiquent pas. 

Les clients ont ainsi économisé plus de 50 % par rapport à leur fournisseur précédent en ne payant que pour les fonctionnalités qu'ils utilisent réellement. Le reste des avantages se fait également sentir rapidement : les appareils de confiance connus évitent totalement la revérification, les numéros jetables et les schémas de fraude connus sont bloqués avant même d'atteindre le produit, et il n'y a plus qu'une seule intégration à maintenir au lieu de trois.

Par où commencer

Si vous utilisez déjà Prelude Verify, Auth est la suite logique, s'appuyant sur les mêmes signaux que vous collectez déjà. Si vous partez de zéro, Auth, Verify et Notify fonctionnent comme une seule et même plateforme, avec une seule facture et un profil de confiance unique par utilisateur.

Consultez la documentation complète pour découvrir le guide d'intégration, ou commencez gratuitement pour tester la solution sur votre propre flux d'inscription.