La formule gratuite de SendGrid a disparu : guide de migration en 30 minutes

La fin de l’offre gratuite à vie

Si vous utilisiez l’offre gratuite de SendGrid pour un projet perso à faible volume ou un nouveau produit, vous avez sans doute remarqué le changement : l’offre gratuite est désormais un essai de 60 jours. À l’expiration de cet essai, vous devez passer à une formule payante, la formule Essentials démarrant à 19.95 USD par mois (tarifs SendGrid). Pour migrer, vous devez exporter vos suppressions, mettre à jour vos enregistrements DNS et remplacer votre intégration API. Comptez environ 30 minutes si vos modèles sont simples.

Évaluer les alternatives

Pour choisir un remplaçant, distinguez l’acceptation par le fournisseur (l’API accepte votre requête), la livraison (le serveur de réception accepte l’e-mail) et le placement en boîte de réception (l’e-mail évite le dossier spam). Aucun fournisseur ne peut garantir ce dernier point, qui dépend de votre réputation d’expéditeur et de votre contenu.

Le paysage des coûts (septembre 2026)

Pour les e-mails transactionnels à faible volume, l’écart de prix est important. Envoyer 50 000 e-mails coûte environ 5 USD avec Amazon SES à la carte, contre environ 66 USD avec les paliers de Postmark.

• Amazon SES : 0.10 USD pour 1 000 e-mails à la carte (tarifs AWS SES). Les nouvelles formules par paliers introduites le 21 juillet 2026 comprennent Essentials (0.16 USD pour 1 000), Pro (0.22 USD pour 1 000, plus 105 USD par mois et par région) et Enterprise (0.23 USD pour 1 000, plus 500 USD par mois).
• Resend : propose une offre gratuite de 3 000 e-mails par mois, plafonnée à 100 par jour. La formule Pro coûte 20 USD par mois pour 50 000 e-mails, avec des dépassements à 0.90 USD pour 1 000 (tarifs Resend).
• Mailgun : à partir de 15 USD par mois pour 10 000 e-mails, avec des dépassements de 1.80 à 1.10 USD pour 1 000 (tarifs Mailgun).
• Postmark : à partir de 15 USD par mois pour 10 000 e-mails, avec des dépassements de 1.80 à 1.20 USD pour 1 000 (tarifs Postmark).
• SendHQ : une alternative moderne pour les équipes produit et les agents IA, axée sur une télémétrie minimisée respectueuse de la vie privée, hébergée exclusivement dans l’UE, et sur des clés API limitées à l’espace de travail.

Étape 1 : export des données et listes de suppression

Ne migrez pas votre liste sans exporter vos suppressions. Si vous envoyez à une adresse qui a déjà généré un bounce ou s’est désinscrite, vous risquez d’abîmer votre réputation auprès du nouveau fournisseur.

SendGrid vous permet d’exporter votre liste de suppression via l’interface ou l’API. Vous obtiendrez un CSV des adresses à ne pas contacter. Lors de leur import chez un nouveau fournisseur, veillez à faire correspondre correctement le « motif » (bounce ou désinscription) pour rester conforme à des lois comme le RGPD ou CAN-SPAM.

Étape 2 : DNS et authentification

C’est là qu’échouent la plupart des migrations. Vous ne pouvez pas vous contenter de changer la clé API : vous devez prouver au nouveau fournisseur que le domaine vous appartient.

DKIM, SPF et DMARC

Vous devrez ajouter de nouveaux enregistrements CNAME ou TXT chez votre fournisseur DNS. Si vous passez à SendHQ, vous pouvez utiliser le Vérificateur DNS e-mail pour contrôler votre configuration actuelle avant tout changement.

1. SPF : mettez à jour votre enregistrement SPF pour inclure le nouveau fournisseur. Si vous utilisez plusieurs fournisseurs, rappelez-vous que vous ne pouvez pas avoir plusieurs enregistrements TXT SPF. Vous devez les combiner en un seul (par exemple v=spf1 include:sendgrid.net include:_spf.sendhq.cc ~all). Pour approfondir, consultez l’entrée SPF du glossaire.
2. DKIM : générez de nouvelles clés DKIM dans le tableau de bord de votre nouveau fournisseur et ajoutez les enregistrements CNAME obtenus à votre DNS. Le serveur de réception peut ainsi vérifier que l’e-mail n’a pas été altéré en transit.
3. DMARC : votre politique DMARC reste la même quel que soit le fournisseur, car c’est une politique au niveau du domaine. Assurez-vous toutefois que votre nouveau fournisseur est aligné avec votre politique DMARC pour éviter que vos e-mails soient rejetés. Consultez le guide DKIM, SPF et DMARC pour les détails de mise en œuvre.

Étape 3 : migration du code

La plupart des fournisseurs utilisent une API REST. Si vous utilisiez les modèles dynamiques de SendGrid, vous devrez migrer ces mises en page HTML/CSS vers le moteur de modèles du nouveau fournisseur.

Exemple : de SendGrid à une API REST générique

SendGrid utilise une structure JSON spécifique pour personalizations. La plupart des API modernes, dont SendHQ, privilégient une structure plus plate et plus lisible.

Payload SendGrid :

{ "personalizations": [ { "to": [{"email": "user@example.com"}], "dynamic_template_data": { "first_name": "Alice" } } ], "from": {"email": "noreply@yourdomain.com"}, "template_id": "d-12345" }

Payload d’une API moderne (par exemple SendHQ) :

{ "to": "user@example.com", "from": "noreply@yourdomain.com", "template_id": "welcome-email", "variables": { "first_name": "Alice" } }

Gérer la migration dans le code

Pour éviter toute interruption, implémentez un wrapper ou un pattern Strategy. Vous pourrez ainsi basculer d’un fournisseur à l’autre à l’aide d’une variable d’environnement.

interface EmailProvider { send(payload: EmailPayload): Promise<void>; } class SendGridProvider implements EmailProvider { async send(payload: EmailPayload) { // SendGrid specific implementation } } class SendHQProvider implements EmailProvider { async send(payload: EmailPayload) { // SendHQ specific implementation } } const provider = process.env.EMAIL_PROVIDER === 'sendhq' ? new SendHQProvider() : new SendGridProvider();

Étape 4 : agents IA et idempotence

Si vous utilisez des agents IA pour déclencher des e-mails, vous faites face à un risque spécifique : l’agent peut boucler ou réessayer une requête plusieurs fois à cause d’un timeout, si bien que l’utilisateur reçoit dix e-mails identiques.

Envoyer un e-mail est un effet de bord externe. Vous devez mettre en place l’idempotence. Une clé d’idempotence est un identifiant unique envoyé dans un en-tête, qui indique à l’API : « Si tu as déjà vu cette clé, n’envoie pas l’e-mail une seconde fois ; renvoie simplement la réponse de succès d’origine. »

Mise en œuvre adaptée aux agents :

{ "headers": { "Idempotency-Key": "order_123_welcome_email" }, "body": { "to": "customer@example.com", "template_id": "order-confirmation" } }

En outre, pour les actions d’agent à haut risque (comme l’envoi d’une réinitialisation de mot de passe ou d’une alerte de facturation), mettez en place une étape d’approbation humaine ou une limite de débit stricte par identifiant utilisateur, afin d’éviter que les hallucinations d’un agent ne spamment vos clients.

Étape 5 : tests et validation

Avant de basculer la variable d’environnement vers le nouveau fournisseur, passez en revue cette checklist :

• Propagation DNS : utilisez un outil comme dig ou un vérificateur en ligne pour vous assurer que vos nouveaux enregistrements DKIM et SPF sont en ligne.
• Vérification des webhooks : si vous dépendez des événements de livraison (delivered, opened, clicked), mettez à jour vos endpoints de webhook. Le format d’événement de SendGrid diffère de celui des autres. Assurez-vous que votre endpoint gère le nouveau schéma JSON sans planter.
• Gestion des erreurs : testez la façon dont votre application gère les erreurs propres au fournisseur. Par exemple, une 429 (Too Many Requests) doit déclencher une stratégie de backoff, tandis qu’une 400 (Bad Request) indique généralement une adresse e-mail mal formée, à marquer comme bounce dans votre base de données.

Cas d’erreur courants à tester

1. Format d’e-mail invalide : vérifiez que l’API renvoie une erreur claire et que votre code ne réessaie pas indéfiniment.
2. Limitation de débit : simulez une rafale d’e-mails pour voir si votre file d’attente respecte les limites du fournisseur.
3. Pièces jointes volumineuses : vérifiez la taille maximale de payload du nouveau fournisseur. Certains vous limitent à 10MB, d’autres à 25MB.

Checklist récapitulative de la migration

• Exporter les suppressions : export CSV depuis SendGrid.
• Configurer les enregistrements DNS : alignement SPF, DKIM et DMARC.
• Migrer les modèles : convertissez le HTML/CSS au nouveau format.
• Mettre à jour la logique API : implémentez un wrapper de fournisseur.
• Ajouter l’idempotence : essentielle pour les déclencheurs d’agent IA.
• Tester les webhooks : vérifiez la livraison et l’analyse des événements.
• Basculer le trafic : mettez à jour la variable ENV et surveillez les logs.

Derniers mots sur la délivrabilité

Changer de fournisseur est le moment idéal pour auditer vos pratiques d’envoi. N’oubliez pas que l’acceptation par le fournisseur n’est que le premier obstacle. La livraison dépend de l’acceptation de la connexion par le FAI destinataire (Gmail, Outlook, etc.). Le placement en boîte de réception est le dernier obstacle ; il est déterminé par la réputation à long terme de votre domaine et par les taux d’engagement de vos destinataires.

Ne cédez pas à la tentation d’utiliser ces API pour des envois en masse non sollicités. Non seulement c’est souvent illégal, mais cela entraînera la suspension de votre compte, quel que soit le fournisseur choisi. Tenez-vous-en aux communications transactionnelles et consenties pour conserver un bon score d’expéditeur.

Pour les équipes qui construisent des applications nativement IA, privilégiez les fournisseurs qui proposent des fonctionnalités adaptées aux agents, comme des serveurs MCP et des fichiers llms.txt, pour une intégration fluide. SendHQ est conçu précisément pour ce workflow et fournit l’infrastructure dont les équipes produit modernes ont besoin.

Apprenez-en plus sur la conception de systèmes e-mail fiables sur https://sendhq.cc.