# MCP ou API REST pour l’emailing : quel workflow choisir ?

URL canonique : https://brew.new/fr/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use
Rédigé par Thomas Park
Publication : 2026-09-23
Mise à jour : 2026-09-29

Un développeur de votre équipe connecte la plateforme d’emailing à Claude et rédige la campagne de la semaine prochaine dans une fenêtre de chat. Le lendemain matin, quelqu’un demande si l’e-mail de bienvenue envoyé à l’inscription pourrait fonctionner de la même façon, via l’assistant. La documentation de la plateforme présente un serveur MCP et une API REST côte à côte.

La plupart des plateformes d’emailing compatibles avec les agents proposent désormais ces deux portes d’entrée. Un serveur MCP permet à un assistant IA d’appeler les outils de la plateforme au fil de la conversation. Une API REST expose des opérations que votre code peut appeler directement. Les deux aboutissent souvent aux mêmes endpoints : le choix dépend donc de qui fait le travail, et à quel moment.

Utilisez MCP quand une personne travaille via un assistant, et l’API REST quand votre produit doit envoyer des e-mails sans que personne ne surveille. La plupart des équipes finissent par utiliser les deux.

## À retenir

- MCP sert au travail interactif, qui demande du jugement : rédiger une campagne, constituer une audience, comprendre pourquoi un envoi a déçu.
- L’API REST sert aux chemins de production : actionner un déclencheur quand un utilisateur s’inscrit, synchroniser des contacts, envoyer des reçus.
- Une CLI se situe entre les deux : scriptable comme l’API, et lisible par les agents de code.
- Le serveur MCP de Brew exige une confirmation avant les envois réels sur les connexions OAuth et d’organisation. Les clients connectés avec une clé API de marque doivent avoir leur propre politique d’approbation. Votre code qui appelle l’API doit prévoir lui-même la relecture, l’idempotence et les nouvelles tentatives.

## Ce que recouvre chacun

MCP, le Model Context Protocol, est un standard ouvert qui permet d’exposer des outils à des clients d’IA comme Claude, ChatGPT et Cursor. Le client lit une liste d’outils, avec leurs descriptions et leurs schémas, puis choisit lesquels appeler selon votre demande. Le serveur de Brew se trouve à l’adresse `https://brew.new/api/mcp` et prend en charge OAuth : vous vous connectez et choisissez une marque, sans manipuler de clés.

Une API REST est un ensemble d’endpoints HTTP que votre code appelle. Brew publie une spécification OpenAPI, un SDK TypeScript et un [guide pour les agents](https://brew.new/api/v1/llms.txt) consacré à son API, en texte brut. Chaque appel porte une clé API, et c’est votre code qui décide quoi appeler et quand.

Les autres éditeurs suivent le même schéma. Le serveur MCP de Customer.io enveloppe son API dans des [outils distincts de lecture, d’écriture et de suppression](https://docs.customer.io/ai/mcp/get-started/). Brevo génère ses outils MCP à partir de sa [spécification OpenAPI](https://developers.brevo.com/docs/mcp-protocol).

## Comparaison côte à côte

| | MCP | API REST |
| --- | --- | --- |
| Qui pilote | Une personne, via un assistant | Votre code |
| Tâches types | Rédiger et retoucher des e-mails, constituer des audiences, programmer une campagne, lire les statistiques | Actionner des déclencheurs par événement, créer ou mettre à jour des contacts, envoyer des e-mails transactionnels, interroger le statut des envois |
| Authentification | Connexion OAuth, ou clé API pour les clients sans OAuth | Clé API, limitée à une marque ou à une organisation |
| Sécurité | Brew suspend les envois réels jusqu’à confirmation sur les connexions OAuth et d’organisation | Votre code décide ; utilisez des clés d’idempotence et vos propres étapes de relecture |
| Gestion des échecs | L’assistant lit l’erreur, puis réessaie ou vous interroge | Vous traitez chaque cas selon des codes d’erreur stables et réessayez avec un délai croissant (backoff) |
| Taille des réponses | Limitée par la fenêtre de contexte de l’assistant | Limitée uniquement par la pagination |
| Idéal quand | La tâche demande du jugement ou des allers-retours | La tâche doit s’exécuter de la même façon à chaque fois |

## Quand choisir MCP

Utilisez MCP quand le travail prend la forme d’une conversation :

- Production de campagnes. « Rédige l’e-mail de nouveautés produit d’octobre à partir de ce journal des modifications, envoie-moi un test et programme l’envoi pour mardi à 9 h. » L’assistant appelle `create_email`, `edit_email`, `send_email` avec `test: true`, puis `send_email` avec `scheduledAt`, et attend votre approbation.
- Questions sur l’audience. « Combien de clients Pro se sont inscrits avant juillet et ont ouvert au moins un e-mail le mois dernier ? » L’assistant combine `search_contacts`, des recherches sur les champs et `create_audience`.
- Analyse. « Quelle automatisation a le pire taux de clics, et qu’est-ce qui a changé ? » L’assistant lit `get_email_analytics` et les performances des automatisations.
- Configuration ponctuelle. Créer une seule fois un déclencheur et une automatisation, avec une personne qui vérifie chaque étape.

Dans Brew, les e-mails générés via MCP s’appuient sur le même document de marque que ceux générés dans l’application. L’[article sur le serveur MCP de Brew](/fr/blog/brew-mcp) détaille la configuration des clients.

Les réponses MCP doivent tenir dans le contexte de l’assistant. Notre [article sur les séquences](/fr/blog/email-flows) note que demander le HTML complet via MCP ne renvoie que la ou les deux premières étapes d’une longue séquence, alors que la route REST renvoie le corps de chaque e-mail.

## Quand choisir l’API REST

Utilisez l’API quand l’e-mail fait partie de votre produit :

- Déclencheurs par événement. Quand un utilisateur s’inscrit, votre backend appelle `POST /v1/automations/triggers/{triggerEventId}/fire` avec son adresse e-mail et ses champs. L’automatisation publiée s’occupe du reste.
- E-mails transactionnels. Les reçus et les réinitialisations de mot de passe se déclenchent de la même façon, via une automatisation sur un domaine dont l’usage d’envoi est transactionnel. Consultez notre article sur les [e-mails transactionnels](/fr/blog/transactional-emails).
- Synchronisation des contacts. `POST /v1/contacts` crée ou met à jour jusqu’à 1 000 contacts par requête.
- Suivi. `GET /v1/sends/{sendId}` renvoie le statut et les statistiques d’un envoi, pour un tableau de bord ou une alerte.

Sur les endpoints qui le prennent en charge, réutilisez la même `Idempotency-Key` et le même corps de requête pour les nouvelles tentatives, dans la fenêtre documentée de 24 heures (les déclenchements sont dédoublonnés sur la clé pendant 90 jours). Utilisez une clé différente pour chaque opération logique distincte, et lisez le contrat de l’endpoint avant de supposer qu’une écriture est couverte. Les en-têtes de limite de débit vous indiquent quand ralentir. Les réponses d’erreur de l’API comportent un `code`, comme `CONSENT_REQUIRED`, sur lequel votre code peut s’appuyer pour choisir la suite. Traitez les erreurs réseau à part. Le [guide de l’API](https://brew.new/api/v1/llms.txt) de Brew décrit tout cela.

## La place de la CLI

Dans un terminal, les agents de code s’en sortent souvent mieux avec une CLI qu’avec l’une ou l’autre option. La [CLI](https://docs.brew.new/api-reference/cli/agents) de Brew renvoie la réponse de l’API sur une seule ligne JSON quand elle n’est pas attachée à un terminal, et utilise des codes de sortie sur lesquels un agent peut agir. Le code 4 signifie qu’une confirmation est requise, et la CLI affiche la commande exacte à relancer avec `--yes` après approbation. Elle génère aussi des contrats de payload typés avec `brew-cli types`, ce qui maintient les appels de déclencheur de votre backend en phase avec le schéma du déclencheur.

## Un workflow combiné

Voici une façon dont une équipe SaaS peut se répartir le travail :

1. Dans Cursor ou Claude, un développeur utilise MCP pour créer le déclencheur `user_signed_up` et une automatisation de bienvenue, la teste avec `test_automation`, puis la publie.
2. Le backend actionne le déclencheur via l’API REST à chaque inscription, avec une clé d’idempotence construite à partir de l’ID de l’utilisateur.
3. Chaque mois, un marketeur demande à Claude, via MCP, de rédiger et de programmer l’e-mail de nouveautés produit.
4. Une tâche programmée de l’application vérifie l’état actuel d’activation ou de facturation avant de déclencher un événement distinct de rappel aux contacts éligibles. Synchroniser les champs de contact ne suffit pas à mettre à jour le payload d’origine d’une séquence en cours.

Aux étapes 1 et 3, une personne vérifie le travail de l’assistant. Les étapes 2 et 4 s’exécutent à chaque inscription ou chaque nuit, sans que personne ne surveille.

## Questions fréquentes

### MCP est-il plus lent ou moins fiable que l’API ?

Il intercale un assistant entre vous et l’endpoint : une requête demande donc plus d’étapes, et l’assistant peut choisir le mauvais outil. C’est acceptable pour du travail interactif, mais inadapté à un événement d’inscription qui doit se déclencher à chaque fois.

### Quelle option est la plus sûre ?

Brew exige une confirmation avant les envois réels sur les connexions OAuth et d’organisation. Avec des clients connectés par une clé API de marque, configurez votre propre politique d’approbation. Avec l’API, protégez vos clés dans des variables d’environnement, utilisez des clés limitées à une marque quand c’est possible et ajoutez une clé d’idempotence à chaque écriture susceptible d’être retentée.

### Un agent intégré à mon propre produit peut-il utiliser l’API comme outils ?

Oui. Le [guide d’intégration des agents](https://docs.brew.new/integrations/ai-agents/use-brew-with-ai-agents) de Brew explique comment brancher les endpoints de l’API comme outils d’appel de fonctions (function calling), le SDK se chargeant de l’authentification et des nouvelles tentatives.

## Prochaine étape

Pour essayer les deux volets, connectez le [serveur MCP](/fr/mcp) dans votre assistant pour le travail sur les campagnes, et créez une clé API pour le déclencheur que votre backend actionnera.