Toute équipe qui construit des fonctionnalités e-mail finit par se retrouver au même croisement : pointer le développement vers un vrai fournisseur SMTP, ou simuler la couche mail et espérer que la production se comporte bien. La première option fuit des identifiants, consomme le quota du fournisseur et envoie parfois un e-mail à un vrai client depuis un ordinateur portable. La deuxième ne teste rien au-delà du point où votre code remet le message à un serveur. Il existe une meilleure voie médiane — plusieurs, en fait. Voici comment se comparent les options standard de test local, et dans quel cas chacune gagne.
Pourquoi le vrai SMTP en développement est une mauvaise idée
La tentation se comprend : vrai fournisseur, vrai comportement, zéro configuration. Les coûts apparaissent plus tard :
- Fuite d’identifiants. Les clés API qui vivent dans des fichiers .env sur les machines des développeurs finissent dans des logs, des captures d’écran et finalement un fil de discussion.
- Envois réels accidentels. Une exécution de test contre une copie de la base de production envoie des e-mails à de vrais utilisateurs depuis votre portable. Cela arrive constamment, et c’est toujours mémorable.
- Suites de tests instables. Quand des tests unitaires dépendent de la disponibilité, des limites de débit et des caprices de sandbox d’un fournisseur tiers, la CI devient de la météorologie.
- Coût et quota. Même les paliers gratuits les plus généreux se vident vite quand une suite de tests envoie des centaines de messages par exécution.
La solution consiste à exclure l’envoi réel de la boucle interne — le raisonnement de développeurs et QA testant avec l’e-mail temporaire s’applique aussi au développement local.
Option 1 : serveurs SMTP locaux catch-all (MailHog, Mailpit)
Un serveur catch-all écoute sur un port local, accepte tout sans authentification ni TLS, stocke les messages en mémoire et les affiche dans une interface web. Votre application pointe dessus comme sur n’importe quel hôte SMTP :
SMTP_HOST=127.0.0.1 SMTP_PORT=1025
docker run -p 1025:1025 -p 8025:8025 axllent/mailpit
Mailpit est le standard maintenu actuel : aperçu HTML, parsing MIME, API REST pour les assertions et un mode chaos qui simule pannes et retards. MailHog, son prédécesseur, n’est plus maintenu depuis 2020 mais fonctionne toujours et apparaît encore dans d’innombrables tutoriels ; choisissez Mailpit pour tout nouveau projet.
Ses points forts : tests unitaires et d’intégration, travail frontend où les designers doivent voir les e-mails, et ordinateurs portables dans des trains sans aucun réseau.
Option 2 : buckets SMTP conteneurisés dans la stack de dev
Le cran au-dessus intègre le bucket mail dans votre stack docker-compose de développement comme un service nommé avec un volume persistant. Deux choses s’améliorent :
- État partagé. Le courrier de chaque développeur arrive au même endroit prévisible, et redémarrer votre application n’efface pas la boîte.
- Assertions de test via API. Mailpit expose une API REST, donc les tests d’intégration peuvent récupérer le dernier message envoyé à une adresse et vérifier objet, en-têtes et corps sans parser de logs.
La contrepartie ne change pas : le mail ne quitte jamais la machine. Authentification, DNS et délivrabilité réelle restent non testées, donc une suite verte peut quand même livrer un enregistrement d’expéditeur cassé. Avant de brancher le staging sur de vrais domaines, vérifiez aussi le côté réception — le vérificateur MX affiche les serveurs de messagerie de n’importe quel domaine que vous vous apprêtez à solliciter.
Option 3 : boîtes jetables pour du réalisme de staging
Les buckets locaux ne peuvent pas répondre à la question : le message est-il réellement arrivé via le vrai internet ? Cette question exige une livraison réelle, et c’est là que les boîtes jetables justifient leur place. Pointez le staging vers votre vraie infrastructure d’envoi et utilisez des adresses temporaires comme destinataires : les messages traversent le vrai DNS, le vrai TLS et le vrai filtrage des fournisseurs, et vous pouvez vérifier l’heure d’arrivée, le contenu et le classement en spam — pas seulement votre propre journal d’envoi.
Cette approche brille pour :
- Les flux d’inscription de bout en bout. Liens de vérification et codes à usage unique, vérifiés côté boîte de réception, avec le schéma d’automatisation de l’API d’e-mail temporaire pour automatiser les tests.
- Les pipelines de webhooks. Les webhooks de bounce et de messages entrants ont besoin de vrais événements mail pour être testés ; notre guide recevoir des webhooks e-mail depuis une boîte temporaire détaille le câblage.
- Les répétitions générales de préproduction. La configuration staging complète est couverte dans le test en environnement de staging.
Quelle option quand
- Tests unitaires locaux et aperçu : Mailpit sur localhost. Rapide, hors ligne, zéro effet de bord.
- Environnement de dev d’équipe : Mailpit comme service compose avec un volume. Partagé, inspectable, vérifiable par API.
- Staging et vérification de release : envoi réel plus boîtes destinataires jetables. La seule option qui exerce le chemin réel qu’emprunte le mail de vos utilisateurs.
- Monitoring de production : ce n’est plus du tout un sujet local — les contrôles de placement et les tests seed prennent le relais.
Considérez-les comme des couches, pas comme des concurrentes : la plupart des configurations matures font tourner les trois, chacune à l’altitude où elle excelle.
FAQ
MailHog reste-t-il un bon choix en 2026 ? Il fonctionne toujours, mais il n’est plus maintenu depuis des années et accuse un retard sur le traitement MIME moderne. Mailpit est son successeur activement développé, avec un ensemble de fonctionnalités compatible — choisissez-le pour tout nouveau projet.
Peut-on tester DKIM et SPF avec un serveur SMTP local ? Non. L’authentification mobilise des requêtes DNS et de clés publiques qu’un serveur localhost n’exerce jamais. Utilisez une livraison réelle vers des adresses jetables, puis vérifiez les signatures sur le message reçu.
Comment empêcher mon environnement de dev d’envoyer des e-mails à de vraies personnes ? Pointez-le vers le SMTP local, ou utilisez un drapeau de staging qui réécrit tous les destinataires vers des boîtes jetables. Ne gardez jamais d’identifiants de production sur un chemin accessible depuis le dev.
Quel est le moyen le moins cher de vérifier qu’un e-mail est arrivé en CI ? Créez une boîte temporaire via API, déclenchez l’envoi, sondez l’arrivée du message et faites échouer le build au timeout. Quelques lignes de script suffisent, et cela attrape les pannes que les buckets locaux ne voient pas.