Amazon Web Services a annoncé de nouveaux forfaits pour Amazon Simple Email Service le 21 juillet 2026. Pour un créateur, une association ou une petite entreprise, l’information dépasse la seule grille tarifaire : elle rappelle qu’envoyer un message et exploiter un programme email complet sont deux périmètres à chiffrer séparément.

Le bon comparatif commence donc par votre besoin. Souhaitez-vous intégrer un transport email dans une application, ou disposer d’un environnement pour créer, organiser et envoyer une newsletter ? La réponse change les tâches que vous devrez prendre en charge.

Ce qu’AWS a annoncé le 21 juillet

Les forfaits s’appellent Essentials, Pro et Enterprise. L’annonce prévoit un démarrage sur Essentials pour les nouveaux comptes et certains comptes inactifs, tandis que les clients actifs concernés restent à la carte s’ils ne choisissent pas un forfait. Elle précise aussi l’évolution de l’offre gratuite spécifique SES pour les nouveaux clients. Les conditions exactes figurent dans le billet officiel AWS.

Ce changement n’implique pas que tous les clients doivent migrer ni qu’un forfait sera systématiquement moins cher. Avant de comparer, vérifiez la situation de votre compte, les fonctions réellement nécessaires et les conditions qui vous sont applicables.

Distinguer transport et programme éditorial

Le transport correspond au passage des emails par l’infrastructure d’envoi. Votre travail peut aussi comprendre la préparation des modèles, les formulaires, l’organisation des contacts, la gestion des désinscriptions et le traitement des incidents.

Présentez ces tâches dans votre budget, même lorsqu’une personne de l’équipe les réalise sans facturation séparée. Un coût non visible sur la facture du fournisseur reste une ressource mobilisée. Inversement, une fonction incluse n’a pas automatiquement de valeur pour vous si elle ne répond à aucun usage.

Cette grille de lecture est une proposition d’analyse. Elle ne permet pas de conclure qu’une catégorie de solution serait toujours préférable à une autre. Une équipe technique avec une application existante ne compare pas les mêmes choses qu’une association qui souhaite préparer sa lettre mensuelle.

Construire un budget que l’on peut expliquer

Nous conseillons de séparer quatre postes :

  • Le volume facturable : messages, destinataires ou autre unité définie au contrat.
  • Les frais fixes et options nécessaires au scénario retenu.
  • La mise en place : domaine, intégration, modèles et procédures.
  • L’exploitation : préparation des campagnes, surveillance et corrections.

La tarification officielle SES expose plusieurs composantes et niveaux de volume. Relevez leurs unités et leur périmètre avant d’utiliser votre calcul. N’appliquez pas une grille actuelle à une ancienne période sans disposer de la version correspondante.

Ajoutez ensuite une colonne « responsable ». Elle évite qu’une option soit considérée comme équivalente à un service accompagné alors que l’installation ou la maintenance reste à votre charge.

Exemple fictif : une lettre mensuelle et des confirmations

Imaginons une petite école de musique. Elle souhaite envoyer une lettre mensuelle aux familles et des confirmations d’inscription depuis son site. Le premier besoin implique rédaction et sélection des destinataires ; le second dépend du fonctionnement du formulaire.

Dans son comparatif, l’école crée deux lignes d’usage. Pour la lettre, elle évalue le temps nécessaire à préparer un message et à gérer les demandes. Pour les confirmations, elle chiffre l’intégration avec le site et la capacité du prestataire à rechercher un envoi en erreur.

Elle ne retient pas un fournisseur uniquement parce qu’une multiplication « volume × prix » produit le plus petit nombre. Elle cherche une organisation qu’elle peut maintenir. Cet exemple est fictif et ne constitue ni un devis ni un calcul d’économies.

Examiner ce que les forfaits rendent plus visible

L’intérêt éditorial de l’annonce AWS est aussi de replacer plusieurs fonctions de délivrabilité dans la discussion budgétaire. Notre lecture : elles doivent être évaluées en fonction du problème qu’elles permettent d’examiner, pas simplement comptées dans une colonne de fonctionnalités.

Posez des questions concrètes : qui lit les alertes ? Que devient une adresse rejetée ? Comment retrouver l’origine d’un envoi ? Comment exporter ses données et ses modèles ? Une fonction que personne ne sait utiliser peut laisser le besoin opérationnel intact.

Pour la même raison, demandez une démonstration du parcours qui vous concerne. Un écran présentant de nombreux indicateurs ne répond pas nécessairement à la question « pourquoi cette confirmation a-t-elle échoué ? ».

Comparer sur un scénario stable

Rédigez un scénario commun à toutes les solutions consultées : type de messages, rythme prévu, nombre d’utilisateurs, besoin d’intégration et niveau d’assistance. Faites apparaître les hypothèses encore incertaines.

Évaluez ensuite un usage habituel et un usage plus chargé, sans inventer de croissance garantie. Demandez ce qui déclenche un changement de tranche ou une option supplémentaire. Notez enfin les conditions de sortie afin de ne pas découvrir le travail de migration à la fin.

Vous obtenez ainsi un budget qui sert à décider : ce que l’outil apporte, ce que votre équipe doit encore faire et ce qu’il faudra vérifier lorsque l’activité évoluera.