Le WordPress d'aujourd'hui, décodé pour les développeurs

Extensions

Mailjet plutôt que wp_mail : un envoi transactionnel fiable pour une association

Remplacer wp_mail par l'API Mailjet pour fiabiliser les accusés d'adhésion d'une association qui perdait des emails sans le savoir.

Par WordPress Développement • 20 mai 2020 • 4 min de lecture • Aucun commentaire
Mailjet plutôt que wp_mail : un envoi transactionnel fiable pour une association

92 % des accusés d’adhésion arrivaient à destination. Les 8 % restants disparaissaient sans erreur visible dans l’admin, simplement absorbés par un serveur mutualisé mal configuré pour l’envoi de mail. C’est le chiffre relevé sur les journaux d’un fournisseur mutualisé pour une fédération d’associations de quartier, avant migration vers une API transactionnelle dédiée.

wp_mail() repose sur la fonction native mail() de PHP ou sur un serveur SMTP configuré via un plugin, sans retour fiable sur ce qui s’est réellement passé après l’envoi. Sur un hébergement mutualisé, le port 25 est souvent limité, la réputation IP partagée avec d’autres sites, et le taux de dépôt en boîte de réception s’en ressent — sans qu’aucune erreur ne remonte côté WordPress.

Le symptôme avant la bascule

Le constat n’était pas un message d’erreur, mais son absence : les bénévoles chargés des adhésions signalaient que certains nouveaux membres n’avaient « jamais reçu » leur confirmation, sans que rien n’indique un problème côté site. wp_mail() retourne true dès que le message est accepté par le MTA local, pas quand il atteint la boîte du destinataire. Cette différence, invisible en développement, devient un vrai problème de confiance une fois l’association en production.

Un test simple a confirmé le doute : envoi de cinquante confirmations vers des adresses Gmail, Outlook et Orange, avec relevé manuel des réceptions. Le taux de perte concernait presque exclusivement les domaines Microsoft, dont les filtres anti-spam sont particulièrement stricts avec les IP mutualisées non authentifiées SPF/DKIM.

Basculer vers l’API Mailjet plutôt que le SMTP

Deux options existent pour utiliser Mailjet : reconfigurer wp_mail pour qu’il passe par le relai SMTP de Mailjet, ou appeler directement son API REST. La seconde option a été retenue ici, car elle renvoie un identifiant de message et un statut d’envoi exploitables, alors que le SMTP reste une boîte noire du point de vue de l’extension.

L'essentiel à retenir : wp_mail dépend de la configuration mail du serveur mutualisé ; L'API Mailjet renvoie un statut d'envoi exploitable ; Le hook wp_mail_failed permet de tracer les échecs restants

Envoyer un email transactionnel via l’API

L’appel se fait avec wp_remote_post(), sans dépendance externe :

function fedasso_envoyer_confirmation( $email, $prenom ) {
    $reponse = wp_remote_post( 'https://api.mailjet.com/v3.1/send', array(
        'headers' => array(
            'Authorization' => 'Basic ' . base64_encode(
                MAILJET_API_KEY . ':' . MAILJET_API_SECRET
            ),
            'Content-Type' => 'application/json',
        ),
        'body' => wp_json_encode( array(
            'Messages' => array( array(
                'From' => array(
                    'Email' => 'contact@fedasso-quartier.fr',
                    'Name'  => 'Fédération des associations',
                ),
                'To' => array( array( 'Email' => $email, 'Name' => $prenom ) ),
                'Subject'  => 'Confirmation de votre adhésion',
                'TextPart' => "Bonjour {$prenom},\n\nVotre adhésion est enregistrée.",
            ) ),
        ) ),
        'timeout' => 15,
    ) );

    if ( is_wp_error( $reponse ) ) {
        error_log( 'Mailjet indisponible : ' . $reponse->get_error_message() );
        return false;
    }

    $code = wp_remote_retrieve_response_code( $reponse );
    return 200 === $code;
}

Le code de retour HTTP à lui seul ne suffit pas à garantir la réception finale, mais il distingue déjà nettement un rejet immédiat (adresse invalide, quota dépassé) d’un envoi accepté par Mailjet pour distribution.

Garder wp_mail comme filet de secours

Plutôt que de remplacer entièrement wp_mail(), l’extension conserve son usage pour les notifications internes non critiques (rappels aux bénévoles, par exemple), et réserve l’appel API Mailjet aux emails qui engagent la confiance de l’adhérent. Le hook wp_mail_failed reste utile pour tracer les rares échecs qui subsistent sur les envois natifs :

add_action( 'wp_mail_failed', function ( $wp_error ) {
    error_log( 'Échec wp_mail : ' . $wp_error->get_error_message() );
} );

Suivre les statuts d’envoi dans l’admin

Un tableau de bord léger dans l’administration WordPress liste les derniers envois, avec leur statut Mailjet, en s’appuyant sur une table personnalisée alimentée à chaque appel réussi ou échoué :

  • Adresse destinataire et date d’envoi.
  • Statut renvoyé par l’API (accepté, rejeté, erreur réseau).
  • Bouton de renvoi manuel pour les bénévoles, sans repasser par le formulaire d’adhésion.

Un envoi transactionnel qui ne peut pas être audité après coup finit toujours par être remis en cause à tort ou à raison — autant se donner les moyens de répondre avec des faits.

En pratique

Le passage à Mailjet n’a rien changé à l’expérience des adhérents : même formulaire, même email reçu. Ce qui a changé, c’est la capacité de l’association à vérifier, en cas de doute, si un envoi a bien eu lieu et où il a échoué. Pour une structure qui vit de la confiance de ses membres, ce niveau de traçabilité vaut largement les quelques dizaines de lignes de code nécessaires pour l’obtenir, bien plus qu’un simple changement de plugin SMTP.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi