# Ce qui s’applique toujours quand un agent envoie vos e-mails

URL canonique : https://brew.new/fr/blog/agent-email-deliverability
Rédigé par Thomas Park
Publication : 2026-09-27
Mise à jour : 2026-09-28

Un agent peut lancer une campagne via la même infrastructure d’envoi qu’une personne. Gmail voit toujours l’expéditeur, le domaine et le message.

Les fournisseurs de messagerie évaluent **les domaines, les IP et les taux de plainte**. Ils ne cherchent pas à savoir si un humain a cliqué sur « Envoyer ». Si l’agent fait passer un contenu promotionnel par l’IP transactionnelle, vous héritez du problème que vous auriez créé à la main, simplement plus tôt.

Cet article complète le [guide de la délivrabilité](/fr/blog/email-deliverability), sans le remplacer. Ce guide traite de la réputation, de l’authentification et de l’hygiène de liste. Cet article-ci porte sur les erreurs qui surviennent quand c’est un logiciel qui clique sur « Envoyer ».

## La loi ne parle pas des agents

La loi [CAN-SPAM](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) s’applique aux messages commerciaux. Le [critère de la finalité principale](https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-316/section-316.3) porte sur l’objet et le corps du message, pas sur l’identité de la personne qui les a tapés.

Pour un message qui mêle une facture et une offre, évaluez sa finalité principale. L’objet, l’emplacement des informations de compte et la place accordée à la promotion entrent en ligne de compte. Un court pied de page promotionnel ne rend pas automatiquement commercial un relevé de compte. Le guide de la FTC donne des exemples. Les messages commerciaux exigent des en-têtes et des objets véridiques, une adresse postale et un mécanisme de désabonnement qui fonctionne.

L’inverse est vrai aussi. Une réinitialisation de mot de passe que l’agent a déclenchée à la suite d’un véritable événement de sécurité reste transactionnelle, tant que le corps du message s’en tient à cet événement.

## Ce que Gmail et Yahoo exigent vraiment

Les [exigences de Gmail pour les expéditeurs](https://support.google.com/mail/answer/81126) comprennent des règles pour tous les expéditeurs et des règles plus strictes pour les expéditeurs en masse, qui atteignent environ **5 000 messages** par jour vers des comptes Gmail personnels. Ces exigences plus strictes comprennent :

- SPF, DKIM et l’alignement DMARC, avec une politique `p=none` ou plus stricte.
- Le désabonnement en un clic selon la [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html), avec `List-Unsubscribe` et `List-Unsubscribe-Post`.
- Un taux de spam inférieur à **0,1 %**, qui ne doit jamais atteindre **0,3 %**.

Les e-mails transactionnels sont exemptés de la règle du désabonnement en un clic. Ils ne sont exemptés ni de l’authentification, ni des plaintes pour spam si vous chargez le modèle d’une promotion.

[Yahoo](https://senders.yahooinc.com/best-practices/) demande aux expéditeurs à fort volume de placer le marketing et le transactionnel sur des **IP différentes**, et de préférence sur des domaines différents. Vérifiez quelle identité d’envoi l’agent utilisera, plutôt que de vous en remettre à un vague réglage par défaut.

## Ce qu’il faut mettre à la portée de l’agent

Donnez à l’agent une identité d’envoi **promotionnelle** pour les campagnes et les automatisations. Le domaine dont vous assurez le warm-up, l’IP sur laquelle vous vous attendez à des plaintes, les en-têtes de désabonnement que vous avez testés.

Gardez les e-mails **transactionnels** sur une identité distincte. Dans Brew, cette identité est un domaine à usage transactionnel, et l’e-mail lui-même est une automatisation publiée avec un déclencheur. L’agent peut composer le modèle. Mais pour chaque événement, l’envoi doit toujours passer par `POST /v1/automations/triggers/{triggerEventId}/fire` avec un payload JSON, et non par « envoie ce brouillon à la liste ».

Ne laissez pas l’agent choisir l’adresse From parmi une pile de domaines vérifiés « pour voir ce qui passe ». C’est le meilleur moyen de bâtir deux réputations à la fois sans comprendre ni l’une ni l’autre.

## Relisez avant le premier envoi sans supervision

Le risque, ce n’est pas la coquille. C’est un paragraphe fluide qui cite un chiffre que vous n’avez jamais publié, ou un objet qui ressemble à un reçu.

Avant de laisser un agent envoyer sans file de validation :

1. Relisez la première campagne en la confrontant au brief d’origine. Chaque chiffre doit figurer dans un document qui vous appartient.
2. Envoyez-la à une liste témoin qui comprend des adresses Gmail, Yahoo et Outlook.
3. Vérifiez que l’en-tête de désabonnement en un clic figure bien sur les e-mails promotionnels, et qu’il est volontairement absent des e-mails transactionnels.
4. Vérifiez que l’adresse postale figure dans le pied de page promotionnel.

Cory Nelson, chez Harmonya, a expliqué à [Noah Adelstein](https://thegtmengineer.substack.com/p/how-to-turn-email-marketing-into) qu’il avait relu ainsi sa première campagne avant de faire confiance à la boucle. C’est le bon ordre.

## En bref

Authentifiez le domaine, choisissez la bonne identité d’envoi et relisez la première campagne à la lumière du brief validé. Vérifiez aussi les autorisations et les paramètres de confirmation de l’assistant : les clients MCP ne demandent pas tous une approbation de la même manière.

Le brief qui empêche les chiffres inventés est décrit dans [comment briefer un agent e-mail](/fr/blog/how-to-brief-an-email-agent). La relecture de la première campagne chez Harmonya est racontée dans [comment Harmonya a transformé une newsletter en programme de cycle de vie](/fr/blog/harmonya-lifecycle-email).