Cloudflare vient de faire un move discret qui va changer l’architecture de pas mal de projets Workers. Depuis avril 2026, tu peux envoyer des courriels directement depuis un Worker, sans passer par SendGrid, Resend ou Mailgun. Natif. Dans l’écosystème. Sans clé API tierce à gérer. Si tu construis des agents IA déployés à la périphérie, lis ça attentivement. Ce que tu vas apprendre:
- Ce que le Cloudflare Email Service change concrètement dans l’architecture d’un agent IA Workers
- Comment fonctionne la tarification réelle et à quel volume ça devient avantageux
- Les limites honnêtes d’une bêta publique à ne pas ignorer
- La comparaison côte à côte avec Resend, SendGrid et Mailgun
- Comment activer la bêta et les premiers pas concrets
Ce qui s’est passé
Cloudflare a lancé en bêta publique, en avril 2026, un service natif d’envoi de courriels pour Workers. L’annonce est passée relativement sous le radar, coincée entre les nouvelles sur les modèles IA, mais elle mérite attention. C’est la pièce manquante de l’écosystème Workers pour quiconque bâtit des flux d’automatisation ou des agents autonomes. Concrètement: tu ajoutes une dépendance SDK (disponible en TypeScript, Python et Go), tu configures ton domaine dans le tableau de bord Cloudflare, et ton Worker peut envoyer des courriels dans le même appel que le reste de ta logique métier. Pas de requête HTTP vers un service externe, pas de gestion de webhook de statut depuis un tiers, pas d’un autre compte à maintenir en vie.
Le service s’active via le tableau de bord Workers ou via Wrangler. Une fois activé, tu accèdes à un objet d’envoi exposé par le runtime, avec les champs standards: destinataire, expéditeur, sujet, corps texte ou HTML. La limite actuelle est fixée à 50 destinataires par message. Le plan requis pour accéder à l’envoi de courriels payant est Workers Paid, à 5 $US/mois. Ce plan inclut 3 000 courriels par mois. Au-delà, le prix est de 0,35 $/1 000 courriels envoyés.
Pourquoi c’est important
Regarde ben. Le problème avec les agents IA déployés à la périphérie, c’est la surface de dépendances. Chaque service tiers que tu intègres, c’est une clé API à sécuriser dans des secrets Workers, un taux de disponibilité à monitorer séparément, et une relation de facturation supplémentaire à gérer. Quand ton agent autonome doit envoyer une alerte, un rapport ou une notification, tu faisais un fetch() vers l’API de ton service de courriel. Maintenant, c’est un appel interne.
Pour les équipes déjà dans l’écosystème Cloudflare (Workers pour la logique, R2 pour le stockage objet, D1 pour la base de données), c’est la consolidation naturelle. Une seule relation de facturation, une seule console, un seul journal de logs. C’est pas glamour, mais opérationnellement, c’est significatif.
À retenir: Si tu génères des courriels transactionnels en réponse à des événements IA (résumés, alertes de seuil, rapports périodiques), l’intégration native élimine la couche réseau entre ton Workers et ton service d’envoi. Moins de latence, moins de points de défaillance. Les cas d’usage les plus évidents pour les agents IA en périphérie: notifications d’alerte quand un agent détecte une anomalie dans un flux de données, rapports automatisés envoyés à des intervalles déclenchés par des Cron Triggers Workers, confirmations transactionnelles générées dynamiquement après une action utilisateur traitée par un agent. Dans tous ces cas, le courriel est le canal de sortie terminal d’une chaîne de décision automatisée. L’avoir natif change l’architecture du “happy path”.
Le fait que les SDKs couvrent TypeScript, Python et Go dès le lancement est aussi un signal. C’est pas un prototype jeté pour les notes de release. Cloudflare a outillé les trois langages principaux de leur écosystème dès la bêta publique. Ça indique que la GA (disponibilité générale) n’est probablement pas loin.
Callout : À retenir
À retenir: Le calcul de volume est simple. À 100 000 courriels par mois, tu paies environ 39 $/mois tout inclus: le plan Workers Paid à 5 $US/mois plus les 97 000 courriels supplémentaires aux 3 000 inclus. C’est un chiffre vérifié, pas une estimation.
Comment le milieu réagit
La réaction dans la communauté Workers a été surtout pratique. Les développeurs qui utilisaient Resend comme choix par défaut ont commencé à comparer les tarifs à volume élevé. Et là, les chiffres parlent.
| Service | Free tier | 50 000 emails/mois | 100 000 emails/mois | 1 million emails/mois |
|---|---|---|---|---|
| Cloudflare Email | 3 000/mois (avec Workers Paid à 5 USD/mois) | ~21 USD/mois | ~39 USD/mois | ~355 USD/mois |
| Resend | 3 000/mois (sans plan de base) | 20 USD/mois (plan Pro) | ~45 USD/mois | 650+ USD/mois |
| SendGrid | palier gratuit limité | selon plan | selon plan | selon plan |
| Mailgun | palier gratuit limité | selon plan | selon plan | selon plan |
Le truc c’est que Resend reste attractif pour les petits volumes sans Workers Paid. Si tu n’es pas déjà dans l’écosystème Cloudflare et que tu veux juste envoyer des courriels transactionnels depuis un projet quelconque, Resend avec son palier gratuit à 3 000 courriels par mois sans frais de base reste une option crédible. Tu paies zéro jusqu’à ce que tu dépasses le palier. Sauf que si tu es déjà sur Workers Paid (et à 5 $US/mois, beaucoup de projets en production le sont déjà), la question change. Tu as les 3 000 courriels inclus. Tu n’as pas besoin d’un compte Resend séparé pour ta phase expérimentale. Tu testes dans le même environnement, avec les mêmes logs, le même dashboard.
La délivrabilité est la vraie inconnue. Les services établis comme SendGrid et Mailgun ont des années de réputation de domaines d’envoi, des relations avec les grands FAI, des systèmes de gestion des bounces et des désabonnements éprouvés. Cloudflare arrive avec une infrastructure solide mais une réputation d’expéditeur à construire. C’est le risque bêta que personne ne mesure vraiment encore. Sur les forums et les serveurs Discord dev, le sentiment général est: “utilise-le pour les notifications internes, les alertes ops, les rapports automatisés, et garde un service établi pour les courriels marketing ou transactionnels critiques pour l’expérience utilisateur.” C’est prudent. C’est aussi probablement ce que Cloudflare recommanderait eux-mêmes en bêta.
La suite
Là, écoute. Il y a des limites à nommer honnêtement avant de sauter dedans. La limite à 50 destinataires par message est restrictive pour certains cas d’usage. Si ton agent IA doit envoyer un rapport hebdomadaire à une liste de plusieurs centaines de destinataires, tu vas devoir paginer tes envois ou repenser la logique. C’est faisable, mais c’est pas transparent. La bêta publique signifie que Cloudflare se réserve le droit de modifier les quotas, la tarification et les fonctionnalités. En pratique, les grandes plateformes cloud ont tendance à maintenir la tarification de lancement quand elles passent en GA, mais rien n’est garanti contractuellement pendant la bêta.
À retenir: Les fonctionnalités avancées comme la gestion des bounces, les webhooks de statut de livraison, la suppression automatique des désabonnements et les analytiques de délivrabilité ne sont pas toutes documentées comme disponibles en bêta. Vérifie la documentation officielle avant de migrer des flux critiques. Pour activer la bêta, le chemin est: tableau de bord Cloudflare, section Workers, paramètres du Worker concerné, puis l’onglet Email. Tu confirmes l’activation, tu lies ton domaine (il doit être géré par Cloudflare DNS), et tu récupères les configurations nécessaires pour ton
wrangler.toml. Les SDKs TypeScript, Python et Go sont disponibles via le gestionnaire de paquets standard de chaque écosystème.
Le prérequis sur le DNS est important à ne pas manquer. Si ton domaine n’est pas sur les nameservers Cloudflare, tu ne peux pas utiliser le service d’envoi natif. C’est une contrainte d’architecture que certaines équipes avec des configurations DNS hybrides devront évaluer. Pour les agents IA en production, la recommandation pratique à ce stade: commence à utiliser Cloudflare Email pour les courriels non critiques (logs d’activité, alertes internes, rapports ops) pendant la bêta. Garde ton service établi pour les courriels transactionnels utilisateurs (confirmations d’achat, réinitialisation de mot de passe, onboarding). Quand la GA arrive et que tu auras quelques mois de données sur la délivrabilité dans ton propre domaine d’utilisation, tu réévalues.
La pente de migration est douce. Tu n’as pas à choisir tout de suite. L’écosystème Cloudflare est précisément conçu pour que tu puisses adopter les services graduellement sans tout refaire. C’est leur avantage concurrentiel structurel: l’intégration est native, mais le lock-in est optionnel parce que tu peux toujours appeler un service externe via fetch() si le service natif ne répond pas à tes besoins.
À un million de courriels par mois, Cloudflare coûte environ 355 USD/mois contre 650 USD et plus pour Resend. L’écart devient substantiel à ce volume. Pour les équipes qui scalent des agents IA qui génèrent des volumes importants de notifications ou de rapports automatisés, le calcul devient très favorable à Cloudflare, à condition que la délivrabilité suive.
Verdict et prochaine étape
Cloudflare Email Service est une addition logique à un écosystème qui cherche à être le plan par défaut pour les applications modernes à la périphérie. La tarification est compétitive, particulièrement à volume élevé. L’intégration native dans Workers est un vrai avantage architectural pour les agents IA autonomes. La bêta publique mérite une adoption prudente et ciblée. Pas de migration totale depuis un service établi avant la GA. Mais commencer à l’utiliser pour les cas d’usage à faible enjeu critique aujourd’hui te donnera des données réelles sur la délivrabilité dans ton contexte spécifique. Ton prochain move concret: si tu es sur Workers Paid, active le service dans un Worker de test, envoie-toi une dizaine de courriels depuis différents déclencheurs (Cron Trigger, requête HTTP, réponse d’agent), et vérifie les taux de livraison dans ta boîte, ton dossier spam, et les logs Cloudflare. Trente minutes de test, et tu auras une vraie donnée sur laquelle baser ta décision d’architecture. C’est tout.
Check tes courriels.
Lien à cliquer pour confirmer ton abonnement.
Texte par David Cyr
