# Votre assistant IA peut désormais travailler dans Brew

URL canonique : https://brew.new/fr/blog/brew-mcp
Rédigé par Thomas Park
Publication : 2026-06-26
Mise à jour : 2026-10-15

Une bonne partie du travail sur les e-mails commence déjà dans un assistant : un brouillon, une révision, une question sur une campagne. Nous avons rendu Brew accessible via MCP pour que cette conversation puisse aussi agir dans votre espace de travail e-mail.

La connexion utilise la même marque et les mêmes données que l’application. Un assistant compatible peut appeler les outils de Brew au lieu de vous donner des instructions à refaire à la main.

## Ce que la connexion vous apporte

Les outils MCP de Brew couvrent la création et la modification d’e-mails, les contacts, les campagnes, les automatisations et le reporting. Les opérations disponibles et leurs paramètres exacts se découvrent via `get_brew_capabilities` et les descriptions des outils.

Une fois connecté, commencez par cet appel de découverte. Ne devinez pas le nom d’un outil à partir d’un exemple de blog quand le serveur en production peut décrire lui-même l’opération prise en charge.

![Un assistant qui se connecte à Brew via MCP pour utiliser les outils e-mail.](/blog/brew-mcp-architecture.png)

*L’assistant est un client de Brew comme un autre. Il utilise les mêmes données produit et les mêmes règles d’envoi.*

## Se connecter avec OAuth ou une clé API

L’URL du serveur distant est :

```text
https://brew.new/api/mcp
```

Si votre client prend en charge la connexion OAuth au serveur MCP de Brew, connectez-vous, sélectionnez la marque et vérifiez les accès que vous accordez. Si votre client se configure avec une clé API, créez dans Brew une clé adaptée, limitée à la marque, et suivez le format de configuration que documente le client.

Pour les clients qui utilisent une configuration JSON `mcpServers`, la connexion peut ressembler à ceci :

```json
{
  "mcpServers": {
    "brew": {
      "type": "http",
      "url": "https://brew.new/api/mcp",
      "headers": { "Authorization": "Bearer brew_YOUR_API_KEY" }
    }
  }
}
```

Il s’agit d’une clé fictive, pas d’un identifiant réel. Conservez vos vraies clés à l’emplacement que le client prévoit pour les secrets. La version web de ChatGPT utilise des plugins ; l’application de bureau de ChatGPT et Codex partagent la configuration MCP. D’autres clients peuvent exiger des noms de champs ou de transport différents, comme streamableHttp chez Cline. Suivez le [guide de configuration des clients](https://docs.brew.new/api-reference/mcp/connect-your-client).

## Confiez-lui une première tâche bien délimitée

Demandez par exemple à l’assistant de créer un brouillon pour une audience précise, à partir de faits validés. Demandez-lui d’afficher l’aperçu et de vous indiquer l’identifiant de l’e-mail. Relisez et retouchez le résultat avant de passer à un envoi réel.

Pour une programmation, précisez l’audience, l’expéditeur, la date, l’heure et le fuseau horaire. Vérifiez ensuite les détails de la campagne obtenue. Pour les automatisations, distinguez la création d’un brouillon de sa publication.

Brew exige une confirmation avant tout envoi réel sur les connexions OAuth et d’organisation. Un client connecté avec une clé API de marque doit avoir sa propre politique d’approbation. MCP n’impose pas de comportement de confirmation universel côté client : vérifiez donc les réglages du client autant que les exigences du serveur avant d’accorder un accès à l’envoi.

## Connecter des outils ne dispense pas d’un plan

Un assistant qui a accès à Brew et à un CRM distinct peut coordonner le travail entre les deux, mais cela ne crée pas d’intégration automatique entre tous les enregistrements. Définissez quel système fait foi pour chaque donnée, comment arrivent les mises à jour et comment les échecs sont gérés.

Pour les rappels de cycle de vie différés, les conditions d’événement sur `contact.<name>` peuvent lire les champs actuels du contact Brew après une attente. Gardez ces champs synchronisés ; les champs du payload reflètent toujours l’événement d’origine. Pour une éligibilité qui dépend d’un état externe, faites la vérification côté application. Le [guide de la séquence d’essai](/fr/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events) explique les deux approches.

## Commencez par un brouillon que vous pouvez relire

À votre place, je connecterais le serveur, j’appellerais `get_brew_capabilities` et je créerais un e-mail dont votre équipe a déjà besoin. Vous aurez ainsi un moyen concret de juger le workflow.

Rédigez un [brief clair](/fr/blog/how-to-brief-an-email-agent), examinez le résultat et testez-le dans une vraie boîte de réception. Les [règles d’envoi](/fr/blog/agent-email-deliverability) sont les mêmes, que l’opération soit lancée par une personne ou par un assistant.

Thomas