« 503 Service Temporarily Unavailable » : ce code de retour, renvoyé par l’API d’un prestataire d’envoi transactionnel largement utilisé, a commencé à apparaître dans les journaux d’erreurs de plusieurs sites clients un mardi en fin d’après-midi. Pendant six heures, ce prestataire a été incapable de traiter les envois entrants, privant potentiellement des dizaines de sites e-commerce de leurs confirmations de commande.
Le choix du prestataire d’envoi lui-même ne relève pas de ce billet : il s’agit ici de ce qu’une configuration serveur correctement pensée en amont peut compenser temporairement lors d’un tel incident, sans jamais résoudre la panne côté fournisseur, hors de portée de l’hébergement.
Ce qui distingue les sites touchés de ceux qui ont tenu
Sur les sites suivis par notre équipe, la différence de comportement pendant l’incident a été nette. Les sites configurés avec un envoi direct et synchrone vers l’API du prestataire, sans file d’attente intermédiaire, ont vu leurs e-mails de confirmation purement et simplement perdus pendant la panne : la requête échouait, et rien ne la relançait automatiquement. Les sites configurés avec une file d’attente locale ont, eux, mis les messages en attente jusqu’au rétablissement du service, sans aucune perte.
- Envoi synchrone direct : message perdu si l’API tierce répond en erreur
- File d’attente locale avec retry borné : message conservé et renvoyé au rétablissement
- File d’attente sans limite de tentative : risque d’envois en masse tardifs et incohérents
Comment fonctionne une file d’attente locale de secours
Le principe repose sur l’interposition d’une table ou d’une file de messages entre l’application WordPress/WooCommerce et l’appel réel vers l’API du prestataire d’e-mailing. Chaque tentative d’envoi crée d’abord une entrée en base locale, puis un worker cron tente l’envoi réel. En cas d’échec, l’entrée reste marquée en attente pour une nouvelle tentative, au lieu d’être perdue.
// Enregistrement en file avant tentative d'envoi
function file_attente_email( $destinataire, $sujet, $contenu ) {
global $wpdb;
$wpdb->insert( $wpdb->prefix . 'file_emails', [
'destinataire' => $destinataire,
'sujet' => $sujet,
'contenu' => $contenu,
'statut' => 'en_attente',
'tentatives' => 0,
'date_creation' => current_time( 'mysql' ),
] );
}
Borner le nombre de tentatives, un point critique
Une file d’attente sans limite de tentative peut devenir problématique à sa manière : si la panne dure plusieurs jours, relancer indéfiniment des envois anciens peut aboutir à des confirmations de commande envoyées bien après le passage réel de la commande, créant une confusion chez le client final. Un plafond de tentatives, associé à un délai maximal de conservation, doit être fixé dès la conception du mécanisme.
// Worker cron avec limite de tentatives et d'ancienneté
$max_tentatives = 8;
$delai_max_heures = 24;
Communiquer avant que le client ne s’en aperçoive
Un incident de ce type, même absorbé techniquement sans perte de données, mérite une communication proactive vers le client final de l’agence : mieux vaut prévenir d’une panne chez un prestataire tiers, avec l’assurance que les messages seront rattrapés, que laisser le client découvrir la situation via un appel inquiet de sa propre clientèle.
Sur les incidents fournisseurs de ce type, la première action de notre équipe n’est jamais technique : c’est d’envoyer un message clair au client expliquant ce qui est en cours, et ce qui est déjà couvert par la configuration existante.
Limites de ce que le serveur peut réellement compenser
Une file d’attente locale absorbe une panne de quelques heures sans difficulté majeure. Au-delà d’une journée complète d’indisponibilité côté prestataire, la pertinence de continuer à mettre en attente des e-mails transactionnels devient discutable, et une bascule vers un service d’envoi de secours, si elle a été anticipée, devient préférable à une attente prolongée.
Bilan de l’incident
Sur les six heures qu’a duré la panne du prestataire ce jour-là, aucun des sites équipés d’une file d’attente locale n’a perdu la moindre confirmation de commande, l’ensemble des messages en attente ayant été renvoyés dans les minutes suivant le rétablissement du service tiers. Ce mécanisme, simple à mettre en place, reste l’une des mesures de résilience les plus rentables face à des incidents que l’hébergement ne peut, par nature, jamais prévenir directement.
