Agence Wordpress Suisse

MailHog : tester les e-mails WordPress en local

MailHog : tester les e-mails WordPress en local

MailHog : tester les e-mails WordPress en local

Un formulaire de contact qui semble fonctionner, c’est rassurant. Jusqu’au jour où l’on découvre que les messages n’arrivent nulle part. Ou pire : qu’un courriel de test vient d’être envoyé à un vrai client avec pour objet « Essai essai essai ». Pour éviter ce petit moment de solitude, MailHog permet de tester les courriels de WordPress sur son ordinateur, sans les expédier sur Internet.

Pratique pour vérifier un formulaire, un courriel de réinitialisation de mot de passe ou une confirmation de commande, cet outil intercepte les messages produits par votre site et les affiche dans une interface web. Vous pouvez ainsi contrôler leur contenu et leur présentation sans toucher à une véritable boîte de réception. Voyons comment l’installer, le relier à WordPress et l’utiliser efficacement.

Pourquoi tester les courriels WordPress en local ?

WordPress envoie des courriels pour toutes sortes de raisons : création d’un compte, changement de mot de passe, formulaire de contact, notification de commentaire ou achat sur une boutique en ligne. Pourtant, en environnement de développement, ces messages ne sont pas toujours faciles à vérifier. Le serveur local n’est pas nécessairement configuré pour envoyer du courrier, et un message peut échouer sans que l’erreur soit évidente.

On peut bien sûr brancher le site sur un service d’envoi réel. Mais chaque test comporte alors un risque : envoyer un message à la mauvaise personne, polluer une boîte de réception ou lancer une notification qui ressemble trop à une communication officielle. Dans une boutique en ligne, mieux vaut éviter qu’un faux reçu de commande parte chez un vrai client. L’humour a ses limites, surtout en comptabilité.

MailHog règle le problème en jouant le rôle d’un serveur de courrier de test. WordPress lui remet les messages comme s’il s’agissait d’un serveur d’envoi habituel. MailHog les intercepte, puis les rend consultables dans une interface accessible depuis le navigateur. Aucun message ne quitte votre environnement local.

Ce que MailHog permet de vérifier

Une fois l’outil en place, vous pouvez ouvrir les messages générés par votre site et examiner leurs détails. Il ne s’agit pas seulement de vérifier qu’un courriel existe : vous pouvez aussi repérer les petits défauts qui nuisent à l’expérience, comme un lien incorrect ou un texte de remplacement oublié.

MailHog est particulièrement utile pendant la création d’un site ou la mise au point d’une extension. Il permet de tester rapidement une modification sans solliciter un service tiers à chaque essai. Un changement de texte, une nouvelle adresse de réponse ou un lien de réinitialisation cassé ? Le résultat apparaît dans l’interface après le déclenchement du message.

Installer MailHog avec Docker

La méthode la plus directe consiste à utiliser Docker. Si Docker est déjà installé sur votre ordinateur, vous pouvez démarrer MailHog avec une commande dans le terminal :

docker run -d --name mailhog -p 1025:1025 -p 8025:8025 mailhog/mailhog

Cette commande lance MailHog en arrière-plan. Le port 1025 reçoit les courriels envoyés par WordPress, tandis que le port 8025 donne accès à l’interface web. Pour consulter les messages, ouvrez ensuite http://localhost:8025 dans votre navigateur.

Si vous utilisez déjà Docker Compose pour votre projet, il est plus commode d’ajouter MailHog à votre fichier de configuration. Vous gardez ainsi les services de développement au même endroit et pouvez les démarrer ensemble :

mailhog:
image: mailhog/mailhog
ports:
- "1025:1025"
- "8025:8025"

Après avoir enregistré le fichier, relancez les services avec la commande habituelle de votre projet. Le nom du service, ici mailhog, pourra être utilisé par WordPress comme adresse du serveur de courrier si les deux applications partagent le même réseau Docker.

Vous préférez éviter Docker ? MailHog existe aussi sous forme de programme à télécharger pour certains systèmes. La procédure varie selon votre environnement. L’essentiel reste le même : démarrer le service, vérifier les ports utilisés et garder l’interface d’administration accessible uniquement depuis votre ordinateur ou votre réseau de développement.

Relier WordPress au serveur de test

MailHog est prêt, mais WordPress doit encore savoir où lui remettre les messages. Il existe plusieurs façons de le faire. Pour un réglage simple et facile à retirer, une extension de configuration de courrier peut suffire. Elle permet généralement de choisir une méthode SMTP, puis de renseigner le serveur local, le port et, si nécessaire, les paramètres de sécurité.

Dans un environnement Docker Compose où WordPress et MailHog sont deux services du même réseau, l’adresse du serveur est souvent le nom du service, par exemple mailhog, et le port est 1025. Si WordPress tourne directement sur votre ordinateur et MailHog dans Docker, l’adresse peut plutôt être localhost. Le détail dépend de la façon dont les conteneurs et les ports sont configurés : si la connexion échoue, vérifiez d’abord ce point.

Une autre possibilité consiste à configurer le site dans son fichier wp-config.php ou dans les réglages de l’extension de courrier utilisée par le projet. Évitez toutefois de modifier durablement la configuration de production pour effectuer un test local. Un paramètre qui se retrouve par mégarde sur le serveur public peut détourner tous les courriels vers MailHog — ce qui est excellent pour les essais, moins pour les commandes réelles.

Après avoir enregistré les réglages, déclenchez un courriel depuis WordPress : demande de réinitialisation de mot de passe, formulaire de contact ou fonction de test proposée par votre extension. Ouvrez l’interface de MailHog et vérifiez qu’un nouveau message apparaît. S’il est là, la liaison fonctionne. S’il ne l’est pas, pas de panique : quelques contrôles ciblés permettent souvent de trouver l’origine du problème.

Faire un premier test concret

Le plus simple est de commencer par un scénario que vous connaissez bien. Par exemple, ouvrez la page de connexion de votre site et demandez un lien de réinitialisation du mot de passe pour une adresse de test. Rendez-vous ensuite dans MailHog. Le message devrait apparaître avec un objet indiquant la réinitialisation et un lien vers votre site local.

Cliquez sur le message pour inspecter son contenu. Le lien pointe-t-il vers la bonne adresse ? Le nom de l’utilisateur est-il correctement inséré ? Le texte est-il lisible sur téléphone ? Si votre site est multilingue, la langue attendue est-elle utilisée ? Ce petit parcours permet de vérifier à la fois l’envoi et la qualité du message reçu.

Pour un formulaire de contact, soumettez des données fictives et vérifiez les deux côtés du processus : le courriel destiné à l’équipe et le message de confirmation envoyé à la personne qui a rempli le formulaire. Il arrive que le premier soit bien configuré, mais que le second contienne encore un texte générique ou une adresse de réponse inadaptée. C’est le genre de détail qu’on repère mieux avant la mise en ligne.

Comprendre les problèmes les plus courants

Si aucun message n’apparaît, commencez par vérifier que MailHog est bien démarré et que vous consultez la bonne interface. Avec Docker, la commande docker ps permet de voir les conteneurs actifs. Vérifiez aussi que les ports 1025 et 8025 ne sont pas déjà utilisés par un autre service.

Un autre piège concerne les liens. Un message peut être correctement intercepté tout en contenant une adresse publique ou un mauvais nom de domaine. C’est fréquent quand l’adresse du site a été copiée depuis un autre environnement. Prenez l’habitude de cliquer sur les liens en sachant que vous êtes dans un site de test, et vérifiez leur destination avant de les partager.

Quelques précautions avant la mise en ligne

MailHog est un outil de développement, pas un service d’envoi destiné aux visiteurs de votre site. Il ne remplace ni un serveur de courrier de production ni un prestataire spécialisé. Avant de publier, repassez en revue les réglages d’envoi et assurez-vous que WordPress utilise bien la configuration prévue pour le site en ligne.

Pour éviter les confusions, séparez clairement vos réglages locaux et ceux de production. Vous pouvez, par exemple, conserver des paramètres différents selon l’environnement, ou utiliser une extension dont les réglages sont définis séparément sur chaque site. Vérifiez aussi les variables de configuration et les fichiers ignorés par votre système de gestion de versions : les identifiants d’un service réel ne devraient pas se retrouver dans un dépôt partagé.

Enfin, testez les courriels importants dans leur contexte : demande de compte, commande, remboursement, notification administrative. Un message qui s’affiche correctement dans MailHog n’est pas forcément irréprochable partout. La largeur des colonnes, les images et les boutons peuvent varier selon le logiciel de courrier utilisé. MailHog valide le contenu et le parcours ; pour contrôler le rendu dans différents logiciels, des outils complémentaires peuvent être nécessaires.

Un petit outil, un grand gain de sérénité

MailHog s’installe rapidement et rend les essais de courrier beaucoup plus sûrs. En interceptant les messages de WordPress, il vous permet de vérifier leur contenu, de corriger les liens et de tester vos formulaires sans envoyer de courriel réel. C’est une étape modeste dans un projet web, mais elle évite des erreurs visibles — et parfois embarrassantes — une fois le site en ligne.

La prochaine fois que vous modifierez un formulaire ou un modèle de message, lancez votre environnement local, ouvrez MailHog et faites un essai. Votre boîte de réception restera tranquille, vos utilisateurs ne recevront pas de faux message, et vous pourrez travailler avec la satisfaction rare d’avoir prévenu un problème avant qu’il ne devienne une urgence.

Quitter la version mobile