Checklist pour la connexion sans mot de passe par liens magiques : expiration, usage unique, règles de réutilisation, gestion des sessions/appareils et notions de base sur la délivrabilité des emails.
Un lien magique est un lien de connexion à usage unique envoyé par email. Plutôt que de taper un mot de passe, vous ouvrez l'email, touchez le lien et vous êtes connecté.
C'est souvent adapté quand les gens détestent les mots de passe, les oublient fréquemment ou se connectent rarement. Cela peut aussi réduire la réutilisation de mots de passe entre sites, puisqu'il n'y a plus de mot de passe à réutiliser. Mais cela n'élimine pas le besoin de sécurité : la «clé» principale se déplace simplement vers la boîte de réception.
C'est le compromis à bien comprendre : la connexion sans mot de passe avec liens magiques n'est aussi sûre que le compte email de l'utilisateur et sa capacité à en garder l'accès privé. Si quelqu'un peut lire votre email, il peut souvent se connecter en votre nom.
Voici les façons les plus courantes dont les liens magiques posent problème en pratique :
Un petit exemple : quelqu'un demande un lien sur un ordinateur de travail puis consulte ses emails sur son téléphone personnel. Il touche le lien, le téléphone le connecte, et l'ordinateur affiche toujours l'écran de connexion. Si votre parcours n'explique pas ce qui s'est passé, les tickets de support s'accumulent.
Si vous implémentez cela dans un produit fait avec AppMaster, traitez l'étape email comme une action sensible, pas uniquement comme une commodité. Des messages clairs, des liens courts et un contrôle simple des sessions rendent l'expérience rassurante.
La connexion sans mot de passe par liens magiques fonctionne mieux quand l'objectif est un accès rapide avec peu de friction, pas une protection maximale. C'est une bonne option pour des produits où les gens se connectent rarement et détestent les réinitialisations, et où la boîte email est déjà la «base» de l'utilisateur.
Une façon simple de décider : si quelqu'un accède au mauvais compte, quel est le pire dommage réaliste ? Si la réponse est «gênant, mais réparable», les liens magiques peuvent être un bon choix par défaut.
Les bons cas d'usage incluent souvent :
Soyez prudent ou évitez les liens magiques comme seule méthode d'authentification quand :
Si votre produit a des moments sensibles plutôt que des comptes sensibles, utilisez la connexion par email pour l'accès initial, puis ajoutez un second facteur ou un contrôle step-up pour les actions risquées. Par exemple, exigez une confirmation supplémentaire pour modifier les détails de paiement, exporter des données ou ajouter un nouvel admin.
Décidez aussi de ce que l'email est autorisé à faire. Les liens «connexion uniquement» sont plus sûrs et plus simples à raisonner. «Connexion + récupération de compte» est pratique, mais signifie que quiconque a l'email peut prendre le compte. Si vous permettez de changer l'adresse email, traitez cela comme une action à haut risque.
Même dans une plateforme no-code comme AppMaster, cette décision compte : l'UI peut rester simple, mais votre politique sur les actions sensibles et la récupération doit être explicite dès le départ.
Les liens magiques paraissent simples pour les utilisateurs, mais beaucoup de petits choix sont cachés. Un flux bien conçu évite les frictions et réduit les tickets de support.
La plupart des produits suivent le même chemin : l'utilisateur saisit un email, reçoit un message, touche le lien et arrive connecté.
Une amélioration courante est une étape de confirmation finale après l'ouverture du lien. Plutôt que de connecter instantanément, affichez un écran court comme «Confirmer la connexion à Acme» avec un seul bouton. Cela aide quand quelqu'un touche le lien sur le mauvais appareil ou quand l'email est ouvert par un outil d'aperçu.
Sur mobile, définissez ce que signifie «toucher le lien». Si vous avez une app native, la meilleure expérience est généralement : toucher le lien -> ouvrir l'app -> terminer la connexion. Si l'app n'est pas installée, redirigez vers le web mobile et proposez plus tard une option «Ouvrir l'app».
Avant d'implémenter la connexion sans mot de passe par liens magiques, verrouillez ces règles pour que l'expérience soit prévisible :
Le cas «déjà connecté» est facile à oublier. Si un utilisateur déjà connecté touche un nouveau lien magique, vous pouvez (a) le laisser dans le même compte et afficher «Vous êtes déjà connecté», ou (b) le traiter comme un changement de compte et demander confirmation. Pour des apps construites avec AppMaster (portails clients ou outils internes), l'option (a) est généralement plus sûre sauf si le multi-compte est une vraie fonctionnalité.
Un lien magique est «sans mot de passe» seulement s'il reste simple. L'expiration est la partie qui peut rompre cette promesse silencieusement. Trop courte, et les gens trouvent des liens expirés dans leur boîte et abandonnent. Trop longue, et un email transféré ou exposé devient un risque plus important.
Un point de départ pratique pour la connexion sans mot de passe par liens magiques est une fenêtre d'expiration entre 10 et 30 minutes. Des fenêtres plus courtes (3 à 10 minutes) conviennent aux actions à risque élevé comme l'accès à une zone admin ou l'approbation d'un paiement. Des fenêtres plus longues (30 à 60 minutes) peuvent fonctionner pour des apps à faible risque, mais seulement si vous avez de bons contrôles de session et une gestion des appareils solide.
Indiquez clairement l'expiration dans l'email et sur l'écran «Vérifiez votre email». Ne la cachez pas en petits caractères. Utilisez un libellé simple comme «Ce lien expire dans 15 minutes.» Si possible, affichez un compte à rebours sur l'écran d'attente, mais ne dépendez pas de l'horloge de l'appareil de l'utilisateur pour l'exactitude.
Les retards d'email et les différences d'horloge sont courants. Certains fournisseurs retardent les messages de quelques minutes, et certains utilisateurs ouvrent l'email sur un appareil différent de celui qui a fait la demande. Quelques règles aident à éviter la confusion :
Quand un lien est expiré, la meilleure expérience est un renvoi en un clic depuis la page d'atterrissage. Restez prudent : n'autorisez le renvoi qu'après un court délai et évitez de révéler si une adresse existe dans votre système. La page peut dire «Si cet email est enregistré, nous enverrons un nouveau lien.»
Un petit détail qui réduit les tickets : inclure l'adresse email exacte (partiellement masquée) sur l'écran d'attente, plus une option «Changer d'email». Dans un outil no-code comme AppMaster, c'est souvent juste quelques états UI, mais cela évite beaucoup de confusions «Je n'ai jamais reçu l'email».
Pour la plupart des produits, privilégiez les liens magiques à usage unique. Cela protège des accidents courants comme le transfert d'email, les boîtes partagées ou l'ouverture d'un vieux message des semaines plus tard. Cela simplifie aussi le support : si un lien a été utilisé, c'est terminé.
La clé est de définir ce que «utilisé» signifie en pratique. Les gens cliquent deux fois, ouvrent sur le mauvais appareil ou touchent le lien dans un aperçu d'email. Vos règles doivent être sûres, mais aussi justes.
Une bonne base : la première connexion valide le jeton, et toute ouverture ultérieure affiche un message clair comme «Ce lien a déjà été utilisé. Demandez-en un nouveau.» Évitez les erreurs vagues. Si vous voulez réduire la frustration, vous pouvez offrir une petite fenêtre de sécurité avant la consommation, par exemple : ne le marquer comme utilisé qu'après la création de la session.
Voici des patterns conviviaux qui restent sûrs :
Décidez-en à l'avance et soyez cohérent. Le défaut le plus sûr est : chaque nouvelle demande invalide tous les liens précédents en attente. Cela limite les dégâts si quelqu'un accède plus tard à la boîte email.
Si vous gardez plusieurs liens valides en même temps, vous aurez besoin de protections plus strictes (expiration courte, usage unique strict, contrôles clairs de sessions/appareils). Sinon, la «connexion sans mot de passe par liens magiques» peut devenir des clés d'accès longue durée dans les emails.
Évitez les liens réutilisables qui fonctionnent indéfiniment. Même si c'est pratique, cela habitue les utilisateurs à considérer l'email comme une clé permanente et rend la prise de contrôle du compte plus difficile à contenir.
Si vous construisez votre flux d'auth dans un outil no-code comme AppMaster, formalisez ces états en langage simple (valide, utilisé, expiré, remplacé) pour que vos messages UI correspondent exactement à ce que le backend applique.
La plupart des tickets autour des liens magiques ne sont pas des failles de sécurité. Ce sont des «Je n'ai pas reçu l'email», «J'ai cliqué et rien ne s'est passé» ou «C'est du phishing ?». Une bonne UX évite ces trois cas.
Après que l'utilisateur a soumis son email, affichez un écran dédié «Vérifiez votre email» plutôt qu'un petit toast. Restez calme et précis : dites à quelle adresse vous avez envoyé, quoi faire ensuite et quoi tenter si ça n'arrive pas.
Un écran «vérifiez votre email» solide inclut souvent :
La confiance se gagne dans l'email lui-même. Utilisez un nom d'expéditeur et un objet cohérents, et gardez le contenu prévisible. Ajoutez un ou deux détails qui rassurent, comme «Demandé depuis Chrome sur Windows» ou «Demandé à 15:42». Évitez un ton alarmiste. Simple est mieux : «Ce lien vous connecte. Si vous n'en êtes pas l'auteur, ignorez cet email.»
Préparez-vous aussi à la défaillance la plus fréquente : email retardé ou filtré. Votre UI ne doit pas être une impasse. Si le lien peut prendre du temps, dites aux utilisateurs quoi faire en attendant et proposez une solution de repli.
Une solution pratique est d'inclure un court code à usage unique dans le même email que le lien. L'écran «vérifiez votre email» peut alors proposer «Saisir un code» pour les cas où le lien s'ouvre sur le mauvais appareil ou est bloqué par un scanner de sécurité email.
Un détail important : si un utilisateur clique sur un lien ancien ou déjà utilisé, affichez un message utile et une action claire comme «Envoyez-moi un nouveau lien», pas une erreur générique.
Un lien magique n'est sûr que tant que le jeton qui le protège l'est. Traitez ce jeton comme une clé temporaire du compte : il doit être difficile à deviner, de courte durée et utilisable uniquement pour l'action prévue.
Commencez par l'imprévisibilité. Générez des jetons longs et aléatoires (pas basés sur l'email, l'heure ou des IDs incrémentaux). Stockez le moins possible. Un schéma courant : stocker une version hachée du jeton (ainsi, si la base fuit, le lien brut ne peut pas être réutilisé) plus les métadonnées nécessaires pour le valider.
Lier le jeton au contexte peut empêcher le transfert facile. Vous ne voulez pas toujours un lien strictement lié (les gens changent d'appareil), mais vous pouvez ajouter des vérifications légères pour détecter les abus évidents. Exemples : attacher le jeton à l'email demandé, et éventuellement à une empreinte grossière comme la famille d'user agent ou le premier bloc d'IP vu. Si le contexte ne matche pas, demandez un lien frais plutôt que de bloquer fermement.
La limitation de fréquence compte plus que les mathématiques sophistiquées. Sans limites, les attaquants peuvent spammer votre formulaire de connexion, agacer les utilisateurs et sonder l'existence d'emails.
Enfin, journalisez ce dont vous aurez besoin quand un utilisateur dit «Ce n'est pas moi». Enregistrez événements comme demande de lien, email envoyé, lien ouvert, jeton accepté/échoué (et pourquoi), et session créée. Incluez horodatage, IP et user agent. Dans un outil construit avec AppMaster, ces événements peuvent être enregistrés dans le processus métier afin que le support et la sécurité aient une traçabilité claire sans fouiller les entrailles du serveur.
Les liens magiques suppriment les mots de passe, mais les utilisateurs pensent encore en appareils : «Je me suis connecté sur mon téléphone» ou «J'ai utilisé un PC partagé». Si vous ne leur donnez pas un moyen simple de voir et terminer les sessions, les tickets de support augmentent vite.
Commencez par une décision : combien de sessions actives un compte peut-il avoir en même temps. Pour la plupart des produits grand public, plusieurs sessions sont acceptables (téléphone + ordinateur). Pour des outils sensibles (admin, finance, opérations internes), vous pouvez limiter ou demander un lien neuf quand un nouvel appareil apparaît.
Une petite page «Appareils» ou «Sessions actives» rend cela compréhensible. Restez simple et un peu imparfait plutôt que trop précis. Une bonne ligne inclut :
Ensuite, proposez deux actions claires. «Se déconnecter» doit terminer uniquement cette session. «Se déconnecter de tous les appareils» doit tout fermer, y compris l'appareil courant, et forcer de nouveaux liens partout.
Entre ces actions, définissez ce qui arrive quand un appareil est perdu ou partagé. Le comportement le plus sûr par défaut : la déconnexion invalide toutes les sessions existantes et les liens magiques non utilisés déjà envoyés. Les utilisateurs n'ont pas besoin des détails, ils veulent la garantie que l'ancien accès est parti.
Voici un ensemble de comportements simples et peu surprenants :
Si vous construisez cela dans AppMaster, vous pouvez modéliser les sessions dans le Data Designer, les afficher dans une UI web/mobile basique et ajouter des actions en un clic dans un Business Process. Les utilisateurs obtiennent une vue «sessions actives» familière sans transformer l'interface en manuel de sécurité.
Les liens magiques paraissent simples, mais l'email est chaotique. Les gens transfèrent des messages, partagent des boîtes et se trompent en tapant. Si vous ne concevez que pour le cas parfait, vous aurez des blocages et des supports difficiles à gérer.
Le transfert est la plus grande surprise. Une connexion sans mot de passe avec liens magiques doit supposer que le lien peut être ouvert par quelqu'un d'autre, sur un autre appareil, minutes ou heures plus tard. Le point de base le plus sûr : usage unique plus un message clair «ce lien a déjà été utilisé», avec un bouton pour en demander un nouveau. Si vous souhaitez une protection supplémentaire, affichez une étape légère de confirmation après le clic sur un appareil nouveau (par ex. «C'était vous ?» avec une option rapide d'annulation qui révoque la session).
Les boîtes partagées nécessitent une décision produit, pas un rustine technique. Si plusieurs personnes lisent légitimement le même email (comme support@ ou sales@), les liens magiques deviennent par défaut un accès partagé. Envisagez d'exiger une étape supplémentaire pour les comptes «équipe» (par ex. invitation vers un email personnel) ou clarifiez dans l'UI que l'accès à l'email équivaut à l'accès au compte.
Les fautes de frappe créent des «comptes fantômes» et des problèmes de confidentialité. Évitez de créer silencieusement de nouveaux comptes lors de la première connexion, sauf si votre produit en a vraiment besoin. Une approche plus sûre : confirmer l'intention dans l'app avant l'onboarding, et garder la réponse email neutre (même message que le compte existe ou non).
Les alias comptent aussi. Décidez comment traiter le plus-addressing (nom+tag@) et les alias du fournisseur :
Le support est l'endroit où tout peut dégénérer rapidement. Ne demandez pas aux utilisateurs de transférer des emails, coller des jetons ou partager des captures d'écran de liens. Proposez plutôt des actions in-app simples comme «envoyer un nouveau lien», «déconnecter les autres appareils» et «signaler que ce n'était pas moi», pour que le support puisse aider sans manipuler de données sensibles.
Avant de lancer la connexion sans mot de passe par liens magiques, décidez de ce que vous voulez qu'il se passe dans le monde réel chaotique : livraisons d'email lentes, gens qui cliquent deux fois, utilisateurs qui basculent téléphone/ordinateur.
Commencez par les règles qui contrôlent le risque et la charge de support. Si vous vous trompez sur ces points, l'UI ne vous sauvera pas.
Ensuite, vérifiez les parties visibles par les utilisateurs. La plupart des plaintes viennent d'emails peu clairs et d'un comportement mobile déroutant.
Si vous construisez cela dans AppMaster, mappez chaque item de la checklist à un écran concret et à une règle métier dans votre logique pour garantir un comportement cohérent sur web et mobile.
Maya travaille au support. Lundi matin, elle ouvre le portail client sur un nouvel ordinateur portable. Elle saisit son email professionnel et clique «Envoyez-moi un lien». L'email arrive avec un lien magique qui expire en 10 minutes.
Elle clique, le navigateur s'ouvre et elle arrive dans le portail. En coulisses, le lien est accepté une fois, puis marqué comme utilisé. Le portail crée une session «Maya - Laptop Chrome» et la garde connectée 14 jours sauf si elle se déconnecte.
Plus tard dans la journée, Maya tente de se connecter depuis son téléphone. Elle réutilise l'ancien email du matin et touche le même lien. L'app affiche un message clair : «Ce lien a déjà été utilisé. Demandez-en un nouveau.» Elle en demande un autre, mais se déconcentre. Quinze minutes plus tard elle le touche et voit : «Ce lien a expiré. Envoyez-en un nouveau.» Elle redemande et touche immédiatement : la session phone est créée sous «Maya - iPhone Safari».
Vendredi, Maya aide un collègue sur un ordinateur partagé. Elle se connecte, termine la tâche, puis va dans «Appareils» et clique «Se déconnecter de cet appareil». Avant de partir, elle supprime aussi la session du PC partagé pour éviter toute réutilisation.
Voici les règles simples que l'app a suivies :
Pour construire ce flux dans AppMaster, commencez par le module d'authentification et activez la connexion par email. Stockez les sessions dans votre base (utilisateur, nom d'appareil, heure de création, dernière utilisation). Utilisez le module de messagerie pour envoyer l'email de connexion, et un petit Business Process pour valider l'état du jeton (non utilisé, non expiré), puis créer ou révoquer les sessions. Si vous voulez une connexion sans mot de passe avec liens magiques sans beaucoup de code, vous pouvez créer les écrans et la logique dans les éditeurs visuels et l'essayer dès maintenant.
21 janv. 2026
8 min
20 janv. 20268 min
20 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
