Pourquoi mon application n'envoie-t-elle plus d'e-mails ?

Regardez d'abord le journal du fournisseur, pas le vôtre

Ce qui déroute dans cette panne, c'est que rien n'a l'air cassé. Votre code s'est exécuté, la fonction d'envoi a retourné, aucune exception n'a été levée, et vos propres journaux montrent des messages qui partent. C'est que le journal de votre application enregistre ce que votre code a décidé de faire, tandis que celui du fournisseur enregistre ce qui est arrivé au message. Quand les deux se contredisent, c'est le fournisseur qui a raison. Ouvrez sa vue d'activité et filtrez sur la fenêtre où les envois se sont arrêtés : vous verrez normalement soit du silence à partir d'un horodatage, ce qui veut dire que votre code a cessé d'appeler, soit une série de refus assortis d'un motif, ce qui veut dire qu'il a appelé et a été éconduit.

Faites cela avant de changer du code, de renouveler une clé d'API ou de renvoyer quoi que ce soit. Chacune de ces actions complique le diagnostic, et l'une d'elles aggrave le problème : une rafale de renvois sur un compte déjà signalé pour son volume est la manière classique de transformer une suspension temporaire en suspension définitive.

Les quatre choses qui arrêtent vraiment les envois

Dans l'ordre approximatif de la fréquence à laquelle chacune se révèle être la réponse :

• Une limite de forfait que votre croissance a rattrapée Les plafonds d'envoi quotidiens et mensuels sont la cause la plus fréquente et la plus injuste en apparence, parce que rien dans votre système n'a changé : ce sont vos inscriptions qui ont changé. La limite tombe un mardi identique à tous les autres mardis, et ce qui est écarté est ce qui a été mis en file en dernier, généralement les messages de notification et de cycle de vie plutôt que les e-mails de connexion partis le matin.
• Une suspension par le fournisseur Les fournisseurs arrêtent des comptes en cas de variation brutale du volume, de taux de rebond définitif au-dessus d'un seuil et de plaintes pour spam. Ici, un e-mail d'avertissement arrive généralement — à l'adresse enregistrée au moment de la création du compte, qui dans une petite équipe n'est bien souvent plus la boîte de personne.
• Une authentification de domaine cassée Les enregistrements SPF, DKIM et DMARC vivent dans le DNS, ils cassent donc quand le DNS change : une migration de registraire, un enregistrement qui a remplacé au lieu d'ajouter, une vérification expirée, une clé de signature renouvelée. Celle-ci se dégrade avant de s'arrêter : la distribution échoue d'abord chez un fournisseur de boîtes, puis le taux de rebond grimpe, puis la suspension arrive.
• Votre propre code a cessé d'appeler Une variable d'environnement absente dans un seul environnement, un travailleur de file mort en silence, un drapeau de fonctionnalité resté éteint après un déploiement, une mise à jour de SDK qui a changé un champ obligatoire. Si le journal du fournisseur montre du silence plutôt que des refus, c'est cette branche, et la réponse est dans votre historique de déploiements et non dans le tableau de bord du fournisseur.

Lisez le corps, pas le code de statut

C'est ce qui transforme un incident de dix minutes en incident de trois jours, et nous avons commis l'erreur plus d'une fois dans notre propre système. Un appel refusé n'arrive pas de façon fiable comme une erreur. Il arrive en HTTP 200 avec l'échec à l'intérieur du corps de la réponse, et le code qui ne vérifie que le statut enregistre une réussite. Nous avons rencontré exactement cette forme chez plusieurs fournisseurs différents : l'un répond 200 avec un indicateur de réussite à faux dans le corps quand il manque une autorisation à un jeton ; un autre a accepté une publication sur un réseau social, a signalé une erreur de validation dans le corps, et notre système — qui ne lisait que l'enveloppe — a enregistré la publication comme publiée et l'a annoncé au client. Rien n'avait été publié.

La règle qui en est sortie est courte, et vaut pour l'e-mail comme pour le reste : ne considérez un envoi comme réussi que si le corps de la réponse dit que le fournisseur l'a accepté, journalisez le motif du fournisseur mot pour mot quand il ne l'accepte pas, et déclenchez l'alerte sur cette chaîne plutôt que sur votre propre résumé. La ligne de statut décrit la conversation avec l'API. Le corps décrit l'e-mail.

La même discipline couvre la limitation de débit. Un fournisseur qui répond 429 vous dit quelque chose d'utile et de temporaire, et un code sans temporisation progressive convertit cela en perte définitive, puisque le message est abandonné et jamais réessayé. Nous avons tourné sans cette temporisation plus longtemps qu'il n'aurait fallu, et ce qui a fini par révéler le problème n'était pas une alerte. C'était quelqu'un qui est allé regarder.

Faire du bruit la prochaine fois

Le correctif qui compte n'est pas de relever la limite, c'est de s'en apercevoir avant de l'atteindre — et l'alerte doit porter sur la proportion, pas sur le décompte. « Nous avons consommé 80% du quota du jour à 14 heures » se traduit en action ; « nous avons envoyé 100 messages » cesse de vouloir dire quoi que ce soit dès que le forfait change. Notre propre volume a dépassé la centaine de messages par jour à mesure que les inscriptions augmentaient, face à un plafond d'offre gratuite fixé à exactement cent : environ 107 le jour où nous avons enfin regardé, après être restés à 99 sur 100 plus tôt dans la semaine. Aucune partie du système n'a dit un mot. La montée en forfait était la moitié facile. L'alerte que nous nous devions encore était la moitié qui comptait, et si elle manquait, c'est que le plafond n'avait jamais été proche et que personne n'y avait donc pensé comme à un nombre qui bouge.

Deux autres choses méritent d'être faites tant que vous y êtes. Gardez une seconde porte d'entrée vers le compte pour le jour où un e-mail porteur d'une connexion n'arrive pas, exactement pour les raisons exposées dans notre page sur pourquoi les connexions par lien magique échouent. Et séparez le courrier qui porte une connexion ou un reçu de celui qui porte une campagne — par domaine d'envoi au minimum, idéalement par fournisseur — pour qu'un envoi marketing franchissant un seuil de plaintes ne puisse pas emporter vos réinitialisations de mot de passe avec lui. Notre page sur la mise en place des e-mails de cycle de vie détaille ce qui relève de chaque flux. Construire AgentCeres, l'AI Growth Officer sur agentceres.com, nous a appris la priorité par la voie coûteuse : les messages que le client a réellement demandés sont ceux que l'on protège en premier.