Pourquoi les mêmes 50 000 e-mails coûtent $5 ou $66

L’écart de prix expliqué

L’écart de prix tient au modèle économique : infrastructure contre plateforme. Amazon SES vend de la puissance de calcul et de la bande passante brutes (infrastructure), tandis que des fournisseurs comme Postmark ou Mailgun vendent une expérience gérée (plateforme), avec une meilleure interface, un support spécialisé et des pools d’IP soigneusement gérés. Pour 50 000 e-mails, SES à la carte coûte environ $5, alors que les paliers de Postmark peuvent atteindre $66. Vous payez pour réduire votre charge opérationnelle et pour la qualité des outils qui entourent l’API.

Le calcul brut : 50 000 e-mails

Quand je regarde la file d’incidents ou la facture cloud mensuelle, l’écart de prix de l’e-mail est l’une des lignes les plus déconcertantes. Pour comprendre pourquoi, il faut examiner les tarifs du marché en vigueur en septembre 2026.

L’approche infrastructure : Amazon SES

Amazon SES est la référence en matière de coût. D’après sa page de tarifs, l’envoi à la carte coûte $0.10 pour 1 000 e-mails.

• Calcul : (50 000 / 1 000) * $0.10 = $5.00.

Cependant, AWS a introduit de nouvelles formules par paliers le 21 juillet 2026. Avec la formule Essentials, le coût passe à $0.16 pour 1 000. La formule Pro coûte $0.22 pour 1 000, plus des frais mensuels de $105 par région. La formule Enterprise coûte $0.23 pour 1 000, plus $500 par mois. Pour une petite équipe produit, le modèle à la carte est le moins cher, mais il fait peser toute la charge de configuration sur l’ingénieur.

L’approche plateforme : Postmark et Mailgun

Des fournisseurs comme Postmark et Mailgun misent sur l’expérience développeur. D’après les tarifs de Postmark, la formule de base coûte $15 par mois pour 10 000 e-mails. Les dépassements coûtent de $1.80 à $1.20 pour 1 000 e-mails.

• Calcul (Postmark) : $15 (10 000 premiers) + (40 000 / 1 000 * $1.20) = $15 + $48 = $63. (Selon le palier exact, ce montant peut atteindre $66.)

De même, les tarifs de Mailgun démarrent à $15 par mois pour 10 000 e-mails, avec des dépassements entre $1.80 et $1.10 pour 1 000. Ces fournisseurs proposent des modèles hébergés et des analyses plus intuitives, ce qui justifie leur surcoût pour les équipes qui ne veulent pas construire leurs propres tableaux de bord de surveillance.

Le juste milieu moderne : Resend

Resend cible la stack produit moderne. Sa page de tarifs affiche une offre gratuite de 3 000 e-mails par mois (plafonnée à 100 par jour). Sa formule Pro coûte $20 par mois pour 50 000 e-mails, avec des dépassements à $0.90 pour 1 000.

• Calcul (Resend) : $20 forfaitaires pour les 50 000 premiers.

Acceptation, livraison et placement : une distinction essentielle

Une erreur fréquente que je vois dans la documentation technique consiste à employer ces trois termes indifféremment. Ils ne signifient pas la même chose, et aucune API ne peut garantir la dernière étape.

1. Acceptation : c’est la réponse de l’API. Lorsque vous envoyez un payload en POST à un endpoint, le fournisseur renvoie 202 Accepted ou 200 OK. Cela signifie seulement que le fournisseur a reçu la requête et qu’elle a passé une validation de base. Cela ne veut pas dire que l’e-mail est parti.
2. Livraison : c’est l’échange SMTP. Le fournisseur tente de remettre le message au serveur de réception du destinataire. Un événement « delivered » signifie que le serveur de réception a répondu « Je le prends. »
3. Placement en boîte de réception : c’est la destination finale. Le serveur de réception (Gmail, Outlook, etc.) décide si l’e-mail va dans la boîte de réception, dans l’onglet Promotions ou dans le dossier spam. Cette décision dépend des filtres internes du destinataire, de votre réputation d’expéditeur et de vos enregistrements d’authentification.

Pour augmenter vos chances de livraison, vous devez configurer correctement votre DNS. Je recommande d’utiliser un vérificateur DNS pour vous assurer que vos enregistrements se propagent. Suivez un guide rigoureux sur DKIM, SPF et DMARC pour prouver que vous êtes bien qui vous prétendez être.

Concevoir pour la fiabilité

Envoyer un e-mail est un effet de bord externe. Dans un système distribué, les effets de bord sont dangereux, car ils peuvent être dupliqués ou échouer silencieusement.

Le problème de l’idempotence

Si votre serveur applicatif atteint un timeout en attendant la réponse de l’API e-mail, vous ne savez pas si l’e-mail a été envoyé. Si vous réessayez simplement, l’utilisateur reçoit deux e-mails. C’est pourquoi une clé d’idempotence est indispensable.

Une clé d’idempotence est un identifiant unique (généralement un UUID) envoyé dans un en-tête. Si l’API voit deux fois la même clé, elle renvoie la réponse mise en cache de la première requête réussie au lieu d’envoyer un second e-mail.

{ "idempotency_key": "req_8823_abc_123", "from": "notifications@example.com", "to": "user@gmail.com", "subject": "Your Order has Shipped", "body": "Your package is on the way!" }

Encadrer les envois déclenchés par des agents

Avec l’essor des agents IA et des serveurs MCP, on voit se multiplier les communications « d’agent à agent » (A2A). Les agents ne devraient jamais disposer d’un accès illimité à une API d’envoi. Si un LLM part en boucle, il peut épuiser votre quota de 50 000 e-mails en quelques minutes et ruiner votre réputation d’expéditeur.

Mettez en place un workflow d’approbation pour les agents :

1. Étape de brouillon : l’agent génère l’e-mail et l’enregistre dans une table pending_emails.
2. Humain dans la boucle : un utilisateur ou un agent superviseur relit le contenu.
3. Exécution : le système n’appelle l’API qu’une fois l’indicateur status = 'approved' défini.

La checklist technique de migration

Si vous passez d’un fournisseur coûteux à un fournisseur moins cher (ou l’inverse), ne vous contentez pas de remplacer la clé API. Suivez cette checklist :

• Audit DNS : vérifiez vos enregistrements SPF. Assurez-vous de ne pas dépasser la limite de 10 requêtes.
• Correspondance des webhooks : chaque fournisseur utilise des noms d’événements différents. Faites correspondre delivered du fournisseur A à sent chez le fournisseur B.
• Synchronisation des suppressions : exportez vos listes de bounces et de plaintes. Si vous importez 50 000 utilisateurs chez un nouveau fournisseur et envoyez à des adresses connues pour générer des bounces, votre compte sera immédiatement suspendu.
• Gestion des limites de débit : implémentez un backoff exponentiel pour les erreurs 429 Too Many Requests.

Exemple de logique de gestion des erreurs

async function sendWithRetry(payload, attempt = 1) { try { const response = await emailApi.send(payload); return response; } catch (error) { if (error.status === 429 && attempt <= 3) { const delay = Math.pow(2, attempt) * 1000; await new Promise(res => setTimeout(res, delay)); return sendWithRetry(payload, attempt + 1); } throw error; } }

Choisir le bon outil

Si vous êtes un développeur solo qui construit un prototype, les offres gratuites de Resend ou la tarification à la carte de SES suffisent. Si vous êtes une équipe produit qui gère un flux transactionnel complexe à fort enjeu (réinitialisations de mot de passe ou alertes de facturation, par exemple), la sécurité opérationnelle d’un fournisseur de type plateforme vaut souvent la différence de $60.

Pour ceux qui construisent des applications nativement IA, un simple tuyau ne suffit pas. Il vous faut une infrastructure prête pour les agents, comme un serveur MCP et un fichier llms.txt structuré qui aide vos agents à comprendre comment interagir avec votre couche de communication. C’est là qu’une API spécialisée devient un multiplicateur de force plutôt qu’un simple centre de coûts.

En fin de compte, le coût de l’API est la plus petite partie de l’équation. Le vrai coût, c’est le temps d’ingénierie passé à déboguer un enregistrement DNS mal configuré ou à gérer une crise de réputation causée par l’absence de gestion des suppressions. Que vous choisissiez la voie à $5 ou celle à $66, privilégiez la télémétrie et les outils qui permettent à vos e-mails de continuer à circuler.

Découvrez une infrastructure e-mail pensée pour les développeurs sur https://sendhq.cc.