Transformez vos e-mails en revenus avec Brew.
Pourquoi le contexte de marque de Brew est passé d’un objet rigide à un document modifiable qui explique les choix de design autant que les valeurs exactes.
Un code hexadécimal indique à un agent e-mail quel bleu utiliser. Il ne lui dit pas pourquoi une marque place une petite étiquette en monospace au-dessus de chaque titre, ni pourquoi ses séparateurs sont de fins traits plutôt que des encadrés.
C’était tout le problème de notre première modélisation des marques chez Brew. Nous enregistrions énormément de valeurs , et nous perdions pourtant les détails qui rendaient une marque reconnaissable.
À nos débuts, une marque ressemblait à des données structurées. Nous modélisions les couleurs, la typographie, les visuels et une grande collection de propriétés de style. Un crawler remplissait les champs, puis la chaîne de génération les assemblait en contexte pour l’agent e-mail.
Le résultat pouvait avoir la bonne couleur et la bonne police, et paraître malgré tout générique. Chaque nouvelle marque apportait un détail que le schéma n’avait pas prévu. Nous pouvions continuer à ajouter des champs, mais la question la plus utile était de savoir comment un designer expliquerait cette même marque à quelqu’un d’autre.
Un designer rédigerait un guide. Des valeurs exactes là où elles comptent, des exemples là où ils aident, et du texte pour expliquer les décisions entre les deux.
Nous avons donc changé ce que nous demandions à l’agent d’extraction de produire.
Nous l’appelons email-design.md. C’est un document Markdown modifiable qui décrit comment une marque donnée doit apparaître dans ses e-mails.
Voici un exemple fictif et abrégé :
# Acme email design
## Voice
Write for engineers who want the setup instructions first.
Use short explanations and name the product action precisely.
## Signature details
- Put a small monospace label above the main headline.
- Use thin dividers between sections, without drop shadows.
- Reserve the accent color for the primary action.
- Use one product screenshot when it explains the task.
## Assets
Use the approved logo URL from the asset list.
Do not invent product images or customer logos.Le document peut contenir une règle comme « n’utiliser la couleur d’accent que sur un seul élément par e-mail » à côté de la valeur exacte de la couleur. Il donne à l’agent une consigne pour les cas que nous n’avions pas prévus un par un.
Les consignes de marque sont visibles. Une correction devient partie intégrante du brief suivant.
Le Markdown est utile ici parce qu’on peut le lire et le modifier sans formulaire dédié. Les titres structurent le document, et ajouter une nouvelle règle de design ne demande pas de nouveau champ en base de données. C’est un choix de format pragmatique. Nous ne prétendons pas que le Markdown consomme toujours moins de tokens que le JSON, ni que tous les modèles d’IA ont été entraînés principalement sur du Markdown.
Un site web et un e-mail n’ont pas les mêmes contraintes de rendu. La prise en charge des polices, de la mise en page et du mode sombre varie d’un client de messagerie à l’autre. Un design qui s’affiche correctement dans l’aperçu d’un navigateur doit tout de même être testé en boîte de réception.
Le document de marque contient donc des consignes propres à l’e-mail : polices de secours, largeurs de conteneur, recettes de mise en page compatibles avec les tableaux, et choix pour les fonds clairs et sombres. Ces consignes aident l’agent à prendre des décisions adaptées ; elles ne garantissent pas un rendu identique dans tous les clients.
Les images ont d’autres exigences : Brew utilise donc aussi image-style.md pour les consignes visuelles. Garder ces deux sujets séparés et explicites est plus simple que de demander à une seule liste de tokens de design de décrire tous les supports.
Un site en ligne est une source utile, mais il ne fait pas toujours autorité. Il peut contenir une ancienne campagne ou un essai de style que l’équipe de la marque n’utilise plus.
Brew peut utiliser les chartes graphiques, logos, images et autres documents de référence que vous fournissez, en plus du domaine. En cas de désaccord, les consignes de marque importées priment sur ce qui est déduit du site web. Relisez le document obtenu, surtout là où les sources sont incomplètes ou incohérentes.
Un domaine et des fichiers validés apportent au processus d’extraction des sources de nature différente.
Si la forme des boutons ne va pas, modifiez la consigne. Si le ton est trop formel, remplacez l’adjectif vague par une phrase d’exemple. Une telle correction est bien plus facile à discuter qu’un gros objet rempli de champs que personne n’a envie de modifier.
Le document place directement dans le contexte de génération l’emplacement des visuels validés, les noms de produits et les décisions de design. Cela réduit les zones d’ombre que le modèle d’IA devrait sinon combler en devinant. Cela n’élimine pas pour autant les résultats erronés.
Nous avons aussi modifié d’autres parties de l’agent e-mail pendant ce travail. Sans comparaison contrôlée, je n’attribuerais pas une amélioration globale de la qualité au seul format de fichier. Ce que je peux affirmer est plus limité : le brief de marque est plus facile à examiner, à corriger et à réutiliser.
Un e-mail généré doit toujours faire l’objet d’une relecture factuelle et visuelle. Confrontez ses affirmations au brief, testez les liens et examinez le résultat en boîte de réception. Le guide pour briefer un agent e-mail traite de cette passation.
Le serveur MCP de Brew est désormais disponible. Un assistant compatible peut travailler avec Brew via les outils documentés, avec le même contexte de marque que l’application. L’annonce du serveur MCP et la documentation de configuration expliquent comment le connecter.
J’aime que les consignes de marque aient un endroit évident où vivre. Quand un e-mail sonne faux, nous pouvons désigner une phrase, la modifier et réessayer. C’est une conversation plus utile que de demander une fois de plus au modèle d’IA : « rends-le plus à l’image de notre marque ».
