C'est une vraie boîte ou un mock ?

Une vraie boîte sur un vrai domaine. Ton application envoie en SMTP classique, comme à un client, donc tu testes tout le chemin : code, service d'envoi, DNS et réception.

Les e-mails HTML s'affichent-ils ?

Oui. Les e-mails HTML s'affichent comme tes utilisateurs les verront.

Combien de temps les e-mails de test sont-ils conservés ?

Chaque e-mail est supprimé automatiquement 7 jours après son arrivée, et la boîte expire 7 jours après sa création. Tu peux aussi tout supprimer toi-même quand tu veux.

Puis-je tester avec plusieurs utilisateurs en même temps ?

Oui. Ouvre la page dans un nouvel onglet ou une fenêtre privée et tu obtiens une autre boîte. Un onglet par utilisateur de test fonctionne très bien pour les invitations, les rôles et les validations.

Pourquoi mon e-mail de test n'est-il pas arrivé ?

Vérifie d'abord l'adresse. Certains services bloquent les domaines jetables connus, et certains fournisseurs retardent d'une ou deux minutes le premier e-mail d'un nouvel expéditeur. Si c'est ton application qui envoie, regarde ses logs et le tableau de bord de ton service d'envoi.

Puis-je l'utiliser pour des comptes de production ?

Non. N'importe qui ayant le lien peut lire la boîte, et elle expire au bout de 7 jours. Utilise-la pour tester, jamais pour des comptes que tu devras récupérer.

Adresse e-mail de test pour ton application

Pourquoi les testeurs utilisent une boîte jetable

Presque toutes les applications envoient des e-mails : confirmations de commande, codes à usage unique, factures, réservations, alertes et notifications. Ces e-mails font partie du produit, et ils cassent plus souvent qu'on ne le croit. Le lien pointe vers la recette. Le code arrive alors qu'il a déjà expiré. L'expéditeur s'affiche comme un nom de serveur brut du genre ip-10-0-3-17.internal. Personne ne le remarque avant qu'un vrai client se plaigne.

Tester avec ton propre Gmail ou Outlook ne tient pas la route. Tu tombes à court d'alias avec « + », ta boîte se remplit de mails de test et tu ne peux pas facilement passer l'adresse à un collègue. Une boîte jetable règle ça : ouvre la page, copie l'adresse, utilise-la dans ton application et regarde l'e-mail arriver en temps réel. Une fois fini, tu n'as plus rien à faire. Tout s'efface tout seul au bout de 7 jours.

Comme c'est une vraie boîte sur un vrai domaine, ton application envoie l'e-mail en SMTP classique, exactement comme à un client. Tu testes tout le chemin, de ton code à ton service d'envoi, au DNS et à la réception, et pas un mock.

Tester les e-mails de ton application en moins d'une minute

Copie l'adresse en haut de cette page.
Utilise-la dans ton application (en local, en recette ou en production), partout où un e-mail part : inscription, commande, réservation, paiement, alerte.
Surveille la boîte. L'e-mail apparaît sans recharger la page, en général en quelques secondes.
Vérifie l'e-mail : l'expéditeur, l'objet, le contenu, chaque lien et chaque code.
Clique sur les liens ou saisis le code pour aller jusqu'au bout du parcours et vérifier que chaque étape fonctionne.

Exemple : tester la souscription d'un forfait mobile avec eSIM avant la mise en production

Imagine que tu fais de la QA chez un opérateur mobile, et que la mise en production de la semaine prochaine change la façon dont les clients souscrivent un forfait en ligne. Le client choisit son forfait, saisit son e-mail, paie, et à partir de là presque tout se passe par e-mail. Chacun de ces e-mails doit être juste dès le premier jour, car un mauvais lien, c'est un client qui ne peut pas activer son eSIM.

Avec une boîte jetable, tu parcours tout le chemin comme un nouveau client, en recette, avant la mise en ligne :

Souscris un forfait en recette avec l'adresse de cette page.
Confirme l'adresse e-mail avec le code reçu par e-mail.
Vérifie la confirmation de commande : le bon forfait, le prix mensuel TTC, l'engagement et le numéro de commande.
Vérifie l'e-mail de l'eSIM : le QR code s'affiche, il a un texte alternatif, et le lien d'activation pointe vers la production, pas vers un serveur de recette.
Vérifie l'e-mail de bienvenue avec le numéro client et le lien vers l'espace client.
Recommence pour chaque type d'offre (prépayé, forfait sans engagement, offre famille) dans un nouvel onglet, pour que chaque client de test ait sa propre boîte.

Le même principe vaut pour tous les secteurs où une action du client déclenche des e-mails : banque, assurance, e-commerce, réservation de voyages ou essai gratuit d'un SaaS. Teste chaque e-mail que le client va recevoir avant la mise en production, pas après la première réclamation.

Les bugs que tu trouves avant tes utilisateurs

Des liens de recette dans les e-mails de production. Une URL de base copiée du mauvais environnement. Très courant, et invisible tant que personne ne clique.
Des codes qui expirent trop vite. L'e-mail met 40 secondes à arriver et le code est valable 30.
Des templates cassés. Une variable comme {{first_name}} non remplacée, ou un objet vide.
Une authentification manquante. Si tes e-mails finissent en spam, vérifie le SPF, le DKIM et le DMARC de ton expéditeur. On l'explique dans SPF, DKIM et DMARC expliqués simplement.
Mauvaise langue ou mauvais format. Un client français reçoit le template anglais, ou la date et le prix sont au mauvais format (23/10/2026, 19,99 €).

Tester avec plusieurs utilisateurs en même temps

Les invitations, les rôles d'équipe et les circuits de validation demandent plus d'une personne. Ouvre cette page dans un nouvel onglet ou une fenêtre privée et tu obtiens une boîte totalement séparée. Un onglet par utilisateur de test, c'est le plus rapide : invite l'utilisateur B depuis le compte de A, accepte depuis la boîte de B, puis regarde ce que A voit ensuite. Plus de détails dans les tests multi-utilisateurs pour la QA.

Quand ne pas utiliser une boîte jetable

Les boîtes jetables servent à tester. N'importe qui ayant le lien peut lire la boîte, et tout est effacé au bout de 7 jours. Ne l'utilise donc pas pour des comptes administrateur en production, pour tout ce qui touche aux paiements, ni pour des comptes que tu devras récupérer plus tard. Pour ça, utilise une vraie boîte gérée par ton équipe.

Et ne mets pas d'adresses de vrais clients dans tes environnements de recette : en plus du risque d'envoyer un e-mail de test à un client, c'est contraire au RGPD. Une adresse de test évite le problème.

Questions fréquentes

C'est une vraie boîte ou un mock ?: Une vraie boîte sur un vrai domaine. Ton application envoie en SMTP classique, comme à un client, donc tu testes tout le chemin : code, service d'envoi, DNS et réception.
Les e-mails HTML s'affichent-ils ?: Oui. Les e-mails HTML s'affichent comme tes utilisateurs les verront.
Combien de temps les e-mails de test sont-ils conservés ?: Chaque e-mail est supprimé automatiquement 7 jours après son arrivée, et la boîte expire 7 jours après sa création. Tu peux aussi tout supprimer toi-même quand tu veux.
Puis-je tester avec plusieurs utilisateurs en même temps ?: Oui. Ouvre la page dans un nouvel onglet ou une fenêtre privée et tu obtiens une autre boîte. Un onglet par utilisateur de test fonctionne très bien pour les invitations, les rôles et les validations.
Pourquoi mon e-mail de test n'est-il pas arrivé ?: Vérifie d'abord l'adresse. Certains services bloquent les domaines jetables connus, et certains fournisseurs retardent d'une ou deux minutes le premier e-mail d'un nouvel expéditeur. Si c'est ton application qui envoie, regarde ses logs et le tableau de bord de ton service d'envoi.
Puis-je l'utiliser pour des comptes de production ?: Non. N'importe qui ayant le lien peut lire la boîte, et elle expire au bout de 7 jours. Utilise-la pour tester, jamais pour des comptes que tu devras récupérer.

E-mail jetable pour tester ton application