La connexion par lien magique est pratique, mais crée une vraie responsabilité QA : chaque e-mail doit arriver rapidement, contenir le bon lien, expirer sans danger et ne fonctionner qu’une seule fois. Une boîte temporaire permet de tester l’authentification sans mot de passe sans polluer des boîtes personnelles ni réutiliser la même adresse à chaque exécution.
Ce workflow concerne la QA légitime, le staging et les tests produit. N’utilisez pas les boîtes jetables pour contourner les règles de comptes ou créer des inscriptions abusives.
Pourquoi l’e-mail temporaire aide à tester les liens magiques
La connexion sans mot de passe exige souvent des vérifications de bout en bout répétées : chaque exécution devrait utiliser une adresse propre pour voir quel e-mail appartient à quel test.
L’e-mail temporaire est utile pour :
- l’inscription par lien magique d’un nouvel utilisateur
- la connexion sans mot de passe d’un utilisateur revenant
- la gestion des liens expirés
- la gestion des liens réutilisés
- plusieurs demandes de connexion en peu de temps
- les vérifications de lien e-mail entre appareils
- la vérification de comptes de staging et de démo
Si votre application envoie aussi des codes OTP, lisez E-mail temporaire pour les codes de vérification et Le meilleur e-mail temporaire pour les codes de vérification en 2026.
Checklist QA des liens magiques
Créez une boîte neuve sur [TempMailito](/), demandez un lien magique, puis vérifiez le flux complet, de la livraison à la création de session.
Vérifiez ces points :
- l’e-mail arrive dans le délai attendu
- le nom et le domaine de l’expéditeur correspondent à votre produit
- l’objet explique clairement l’action de connexion
- le lien ouvre le bon environnement, pas la production par erreur
- le lien crée la session attendue
- le lien ne peut pas être réutilisé après succès
- le lien expiré affiche une erreur sûre et claire
- la demande d’un second lien invalide le premier si c’est votre politique
- les versions HTML et texte brut contiennent toutes deux un texte de connexion utilisable
Cela recoupe la QA de récupération : si vous testez aussi les réinitialisations, utilisez la checklist de Comment tester les e-mails de réinitialisation de mot de passe avec des boîtes temporaires.
Gardez les comptes de test propres
Utilisez une boîte temporaire par scénario de test. Par exemple :
- `magic-new-user`
- `magic-returning-user`
- `magic-expired-link`
- `magic-reuse-check`
Une convention claire facilite les rapports de bug : l’adresse de la boîte explique à elle seule le scénario. Pour les équipes plus grandes, envisagez un domaine d’e-mail temporaire personnalisé ; consultez E-mail temporaire avec domaine personnalisé pour les équipes.
Automatiser les tests de liens magiques
Les vérifications manuelles conviennent aux tests de fumée avant release. Pour la CI ou les suites de régression, utilisez l’API TempMailito pour créer une boîte, déclencher la connexion, interroger la boîte, extraire le lien et terminer l’authentification dans votre test navigateur.
Un flux d’automatisation stable :
- créer une boîte temporaire via l’API
- soumettre le formulaire de lien magique
- interroger les messages par expéditeur ou par objet
- analyser l’URL de connexion dans le corps du message
- ouvrir l’URL dans le navigateur de test
- vérifier que la session est créée
- réessayer la même URL et confirmer l’échec
Pour une automatisation e-mail orientée API, lisez API d’e-mail temporaire : comment automatiser les tests d’e-mail et Comment recevoir des webhooks d’e-mail depuis une boîte temporaire.
Ce qu’il ne faut pas tester avec des boîtes jetables
N’utilisez pas l’e-mail temporaire pour un accès administrateur réel, la banque, des données clients, la facturation de production ou tout compte exigeant une récupération durable. Les boîtes jetables conviennent aux identités de test contrôlées et aux flux de vérification de courte durée.
Si vous avez un doute sur la sécurité, lisez Sécurité de l’e-mail temporaire : quelles données ne faut-il jamais envoyer ?.
L’essentiel
L’e-mail temporaire est un moyen propre de tester la connexion par lien magique : chaque exécution QA dispose d’une boîte neuve, d’un historique lisible et d’options d’automatisation simples. Gardez les comptes sensibles hors du flux, utilisez une boîte par scénario et vérifiez les chemins de succès comme d’échec.