Bounce ou plainte : ce qui nuit vraiment à la délivrabilité

La différence fondamentale

Un bounce est un échec technique : le serveur de réception rejette l’e-mail. Une plainte est une action de l’utilisateur : le destinataire marque votre e-mail comme spam. Si un taux de bounces élevé révèle une mauvaise hygiène de liste, les plaintes révèlent un manque de consentement ou de pertinence. Les plaintes nuisent bien davantage à votre réputation, car elles signalent directement aux FAI que votre contenu est indésirable, ce qui accélère l’inscription en liste noire et fait baisser les taux de livraison sur toute votre plage d’IP.

Comprendre les bounces

Un bounce se produit lorsqu’un e-mail ne peut pas être remis dans la boîte aux lettres du destinataire. D’un point de vue technique, c’est un échec de la tentative de livraison. Les bounces se répartissent en deux types : hard et soft.

Hard bounces

Un hard bounce est un échec définitif. L’adresse e-mail n’existe pas, le domaine est invalide ou le serveur de réception a bloqué définitivement votre IP. Vous devez cesser immédiatement d’envoyer à ces adresses. Continuer à écrire à des adresses en hard bounce indique clairement aux FAI que vous utilisez une liste ancienne ou achetée, ce qui est la marque des envois en masse non sollicités.

Codes d’erreur SMTP courants pour les hard bounces :

• 550 : User unknown (utilisateur inconnu)
• 554 : Transaction failed (échec de la transaction)
• 550 5.1.1 : Bad destination mailbox address (adresse de boîte de destination invalide)

Soft bounces

Un soft bounce est un échec temporaire. La boîte aux lettres est peut-être pleine, le serveur temporairement indisponible, ou la taille du message dépasse la limite. Ce ne sont pas des raisons de supprimer immédiatement un contact, mais des soft bounces répétés doivent finir par être traités comme des hard bounces.

Codes d’erreur SMTP courants pour les soft bounces :

• 421 : Service not available, closing transmission channel (service indisponible, fermeture du canal de transmission)
• 450 : Requested mail action not taken: mailbox unavailable (action non effectuée : boîte aux lettres indisponible)
• 451 : Requested action aborted: local error in processing (action interrompue : erreur locale de traitement)

Comprendre les plaintes

Une plainte survient lorsqu’un utilisateur clique sur « Signaler comme spam » ou « Marquer comme indésirable » dans son client de messagerie. Contrairement à un bounce, l’e-mail a bien été remis dans la boîte aux lettres. L’échec n’est pas technique, mais comportemental.

Les FAI (fournisseurs d’accès à Internet) et fournisseurs de messagerie comme Gmail ou Outlook suivent le ratio entre plaintes et volume total. Si votre taux de plaintes dépasse un seuil très bas (souvent 0,1 % seulement), votre réputation chute. Cela ne touche pas seulement la campagne en cours : cela affecte chaque e-mail envoyé depuis cette IP ou ce domaine.

La hiérarchie de la délivrabilité

Il est essentiel de distinguer trois notions : l’acceptation par le fournisseur, la livraison et le placement en boîte de réception.

1. Acceptation par le fournisseur : le serveur de réception accepte la connexion et le message. En cas d’échec, vous obtenez un bounce.
2. Livraison : le message est bien déposé dans le stockage de messagerie du destinataire.
3. Placement en boîte de réception : le message arrive dans la boîte de réception plutôt que dans le dossier spam. Les plaintes influent directement sur cette étape.

Avec un taux de plaintes élevé, vos e-mails peuvent toujours être « délivrés » (acceptés par le serveur), mais ils seront envoyés directement dans le dossier spam de tous les utilisateurs, que ceux-ci se soient plaints ou non.

Concevoir la réponse technique

En tant qu’ingénieur responsable de la file d’incidents, vous ne pouvez pas compter sur un nettoyage manuel. Il vous faut un pipeline automatisé pour traiter les événements de livraison.

La liste de suppression

Toute configuration d’envoi professionnelle nécessite une liste de suppression : une base d’adresses auxquelles il ne faut plus jamais écrire. Lorsque vous recevez un événement bounce ou complaint par webhook, votre système doit ajouter immédiatement cette adresse à la liste de suppression.

Avec SendHQ, ces suppressions sont gérées au niveau de l’API : même si la logique de votre application tente d’envoyer à une adresse supprimée, le système bloque l’envoi avant qu’il ne parte.

Gérer les webhooks

Votre gestionnaire de webhooks devrait ressembler à ceci (exemple conceptuel en Node.js) :

app.post('/webhooks/email', async (req, res) => { const event = req.body; switch (event.type) { case 'bounce': if (event.detail.category === 'permanent') { await suppressionService.add(event.detail.email, 'hard_bounce'); } break; case 'complaint': await suppressionService.add(event.detail.email, 'spam_complaint'); break; case 'delivered': await trackingService.markAsDelivered(event.detail.messageId); break; } res.sendStatus(200); });

Le problème des agents IA : idempotence et validation

Lorsque des agents IA sont chargés d’envoyer des e-mails, le risque de catastrophe de délivrabilité augmente. Un agent pris dans une boucle pourrait envoyer par erreur 1 000 e-mails identiques à un même utilisateur et déclencher un flot de plaintes.

Clés d’idempotence

Pour éviter les envois en double, utilisez toujours une clé d’idempotence. Ainsi, si un agent réessaie une requête après un timeout, l’e-mail n’est envoyé qu’une seule fois.

Humain dans la boucle (HITL)

Pour les agents qui envoient des communications à fort enjeu, mettez en place une file de validation. L’agent génère le brouillon, mais c’est un humain qui déclenche l’appel API final. Cela évite le scénario du « spam halluciné », où un agent envoie un contenu hors sujet à une longue liste et fait grimper votre taux de plaintes.

Compromis d’infrastructure et de coût

Choisir un fournisseur implique souvent un arbitrage entre simplicité d’utilisation et coût. À grande échelle, les écarts de prix pour les gros volumes sont frappants.

Selon la page de tarification d’Amazon SES, SES coûte 0.10 USD pour 1 000 e-mails à la carte. Pour un volume de 50 000 e-mails, cela revient à environ 5 USD. À l’inverse, selon la grille tarifaire de Postmark, 50 000 e-mails coûteraient environ 66 USD (15 USD de base pour 10 000, plus des dépassements entre 1.20 et 1.80 USD pour 1 000).

Autres options :

• Resend : l’offre gratuite comprend 3 000 e-mails par mois (plafonnés à 100 par jour). Pro coûte 20 USD par mois pour 50 000 e-mails, avec des dépassements à 0.90 USD pour 1 000 (tarifs Resend).
• SendGrid : l’offre gratuite est désormais un essai de 60 jours ; Essentials démarre à 19.95 USD par mois (tarifs SendGrid).
• Mailgun : 15 USD par mois pour 10 000 e-mails, avec des dépassements de 1.10 à 1.80 USD pour 1 000 (tarifs Mailgun).

SES est moins cher, mais la charge opérationnelle liée à la gestion de vos propres listes de suppression et de votre réputation est plus lourde. SendHQ comble cet écart en proposant l’envoi transactionnel depuis des domaines vérifiés et une gestion intégrée des suppressions, sans la complexité d’une configuration AWS brute.

Checklist de délivrabilité pour les ingénieurs

Pour réduire à la fois les bounces et les plaintes, suivez cette checklist technique :

• Validation DNS : vérifiez que vos enregistrements SPF, DKIM et DMARC sont corrects. Utilisez le vérificateur DNS de SendHQ pour les vérifier. Consultez notre guide sur DKIM, SPF et DMARC pour les détails de configuration.
• Double opt-in : n’ajoutez jamais d’e-mails à une liste sans confirmation explicite. C’est le seul moyen de maintenir les taux de plaintes près de zéro.
• Désinscription en un clic : implémentez l’en-tête List-Unsubscribe. Il vaut mieux qu’un utilisateur se désinscrive plutôt qu’il vous signale comme spam.
• Suppression en temps réel : assurez-vous que votre gestionnaire de webhook met à jour votre base de données en moins de 5 minutes.
• Surveillance : configurez des alertes lorsque votre taux de bounces dépasse 2 % ou que votre taux de plaintes dépasse 0,1 %.

Tableau récapitulatif : bounce ou plainte

Caractéristique | Bounce | Plainte

Cause | Échec technique (adresse invalide, boîte pleine) | Action de l’utilisateur (marqué comme spam)

Signal | Mauvaise hygiène de liste / données anciennes | Contenu non pertinent / absence de consentement

Action immédiate | Retirer immédiatement les hard bounces | Retirer immédiatement

Impact sur la réputation | Modéré (sauf s’il est très élevé) | Grave

Indicateur principal | Taux de bounces | Taux de plaintes

Objectif | Garder une liste propre | Préserver la confiance des utilisateurs

Conclusion

Les bounces sont une gêne, mais les plaintes sont une crise. Un taux de bounces élevé indique à un FAI que vous êtes négligent ; un taux de plaintes élevé lui indique que vous êtes un acteur malveillant. En automatisant votre logique de suppression et en mettant en place des parcours d’opt-in stricts, vous protégez votre réputation d’envoi.

Pour les équipes produit qui ont besoin d’un moyen fiable de gérer les e-mails transactionnels et les communications pilotées par des agents, découvrez SendHQ.