Transformez vos e-mails en revenus avec Brew.
Les contrôles avant chaque campagne et les seuils de l’audit Brew : troncature à 102 Ko, liens morts, texte alternatif, compatibilité, longueur des textes.
Une checklist de contrôle qualité avant envoi, c’est la courte liste de vérifications que vous faites sur chaque e-mail avant qu’il parte. Les campagnes ratées partent généralement avec un bouton qui pointe encore vers #, un visuel principal remplacé à 18 h par un PNG de 4 Mo, ou une mise en page sur deux colonnes que l’Outlook classique ignore. Chacun de ces problèmes se repère en une minute avant l’envoi, et ne se corrige plus après.
Ce mois-ci, nous avons reconstruit l’audit d’e-mail de Brew autour de ces contrôles, chacun avec un seuil précis. Faites-les à la main, avec ou sans Brew.
Les constats regroupés par gravité, avec un seul verdict sur la préparation à l’envoi.
Un lien cassé gâche l’envoi. Vérifiez que :
#, example.com ou un {{url}} non renseignéhttpsbrew.new/pricing qui pointe ailleurs ressemble à du phishingCliquez sur chaque lien dans un e-mail de test reçu, pas dans l’éditeur d’e-mails. Votre ESP réécrit les liens pour le suivi des clics au moment de l’envoi : les chaînes de redirections et les paramètres de suivi cassés n’apparaissent que là.
Ne laissez jamais un outil de vérification automatique appeler les liens de désabonnement ou de préférences. Certains fournisseurs considèrent toute requête vers cette URL comme un désabonnement. Et une barrière anti-robots servie à un outil de vérification ne prouve pas qu’un lien est mort. Cliquez dessus vous-même.
Gmail tronque les messages qui dépassent environ 102 Ko de HTML et cache la suite derrière un lien « Afficher l’intégralité du message ». Le pied de page, le lien de désabonnement et l’adresse postale disparaissent : un e-mail marketing tronqué devient discrètement un problème de conformité.
Nos seuils :
Nous avertissons dès 80 Ko parce que le suivi des clics remplace les liens courts par des URL de redirection plus longues, et que certains ESP ajoutent du balisage. Un e-mail de 98 Ko dans votre éditeur peut arriver à 105 Ko.
Les sources de poids habituelles : des styles inline répétés sur chaque élément, des commentaires oubliés par l’outil de création, des sections mobile et desktop dupliquées et masquées, et des images intégrées en base64.
Chaque image doit :
alt, ou alt="" si elle est purement décorativewidth et height, pour que la mise en page tienne pendant le chargement des images ou quand elles sont bloquéesUne grande image au-dessus d’une ligne de texte est illisible quand les images sont désactivées, opaque pour les lecteurs d’écran et un signal de spam pour certains filtres. Mettez le titre et l’offre en texte HTML.
Flexbox, grid, position, les images d’arrière-plan et le SVG inline posent chacun problème dans au moins un grand client de messagerie. Can I email suit leur prise en charge par fonctionnalité et par client : c’est la meilleure référence unique.
Surveillez Outlook de très près. Gmail et Apple Mail se dégradent généralement sans bruit. L’Outlook classique sous Windows effectue le rendu avec le moteur de mise en page de Word, ignore de nombreuses largeurs CSS, abandonne les images d’arrière-plan et supprime la marge intérieure des boutons construits comme des liens stylés.
Nous ne signalons une fonctionnalité pour une famille de clients, comme Gmail ou Outlook, que si au moins deux de ses clients l’ignorent. Ce n’est un avertissement que si Outlook la casse sans solution de repli. Tout le reste est classé Info. Sinon, chaque e-mail recevrait vingt avertissements de compatibilité, et plus personne ne les lirait.
Les contrôles qui ne coûtent presque rien :
lang sur <html>, pour que les lecteurs d’écran prononcent correctement le texte<title>h1 à h4Les WCAG 2.2 servent de référence. La plupart des problèmes des e-mails correspondent à leurs critères sur les alternatives textuelles, le contraste, la langue de la page et les titres.
Gardez des objets de moins de 60 caractères et 9 mots environ, sinon les téléphones les coupent. Évitez les MAJUSCULES, les « RE : » ou « TR : » sur un e-mail qui n’est pas une réponse, et les rafales de points d’exclamation.
Gardez un texte d’aperçu de moins de 90 caractères environ, sans répéter l’objet. Laissez-le vide, et de nombreux clients afficheront à la place « Voir la version en ligne ».
Une balise de fusion sans valeur par défaut envoie « Bonjour , » à tous ceux dont le prénom manque. Les lecteurs s’en souviennent.
Chaque chiffre doit avoir une source que vous pouvez citer, surtout dans les premiers jets rédigés par l’IA, qui avancent facilement des chiffres avec aplomb. Comment rédiger des e-mails marketing et le guide des objets d’e-mail approfondissent la formulation.
La loi américaine CAN-SPAM impose aux e-mails commerciaux un lien de désabonnement fonctionnel et une adresse postale valide. Les expéditeurs en masse vers Gmail et Yahoo ont aussi besoin d’en-têtes de désabonnement en un clic, présentés dans Ce qui s’applique toujours quand un agent envoie vos e-mails.
Les e-mails transactionnels échappent à certaines règles marketing, pas à cette checklist. Un reçu avec un lien mort finit quand même en ticket de support.
Retirez ce que les clients de messagerie suppriment ou bloquent :
<script>, <form> et <iframe>data:background-color, pour que le texte reste lisible si l’image ne se charge pasCommencez par un doctype. Sans lui, certains clients passent en mode quirks et les espacements se décalent.
L’audit d’e-mail de Brew applique cette liste depuis :
POST /v1/emails/audit ou l’outil audit_emailConsultez la documentation de l’audit et la référence de l’API pour le détail de chaque champ.
Des contrôles instantanés gratuits s’exécutent automatiquement pour chaque règle qui n’a besoin que du HTML : éléments provisoires, poids, texte alternatif et dimensions d’image manquants, ordre des titres, lang et <title>, longueur de l’objet et du texte d’aperçu, balises de fusion sans valeur par défaut et balisage bloqué.
Lancer l’audit ajoute les contrôles qui nécessitent le réseau ou une part de jugement :
Chaque jugement de l’IA est calibré pour qu’un constat signalé soit juste dans au moins 95 % des cas sur nos propres e-mails. Un relecteur IA qui crie au loup est pire que pas de relecteur du tout.
Un audit complet coûte 5 crédits. Si un contrôle requis n’est pas disponible, vous obtenez gratuitement un audit partiel, sans score, puisqu’un score qui aurait sauté des contrôles serait trompeur.
Chaque audit renvoie un score de 0 à 100 et un état : prêt, à vérifier ou pas prêt (affichés dans l’app comme Prêt à l’envoi, À vérifier et Problèmes détectés). Chaque constat a une gravité (Critique, Erreur, Avertissement ou Info) et des éléments de preuve, comme le statut HTTP d’un lien mort.
Le score part de 100. Chaque constat critique coûte 20 points, chaque erreur 10, chaque avertissement 3, et une info rien du tout. Seules les trois premières occurrences par règle comptent.
Exemple : un bouton qui pointe vers #, un lien de pied de page qui renvoie une erreur 404, deux images sans texte alternatif, un objet de 68 caractères et du flexbox que deux clients Yahoo ignorent.
| Constat | Gravité | Points |
|---|---|---|
| Le lien du bouton est provisoire | Critique | −20 |
| Le lien du pied de page renvoie une erreur 404 | Erreur | −10 |
| Image sans texte alternatif (×2) | Avertissement | −6 |
| Objet de plus de 60 caractères | Avertissement | −3 |
| Flexbox ignoré par 2 clients Yahoo | Info | 0 |
| Score | 61 |
Un constat critique ou une erreur, et l’e-mail est « pas prêt » ; des avertissements seuls, et il est « à vérifier ». Corrigez les deux liens et celui-ci obtient 91, à vérifier. C’est honnête : il partirait sans problème, et le reste vaut bien une minute.
Corriger dans la discussion transmet les avertissements et les constats plus graves à l’agent Brew, puis relance les contrôles instantanés gratuits sur la version corrigée.
Il ne bloque pas les envois. En cas de constats critiques, la fenêtre d’envoi demande de cliquer sur Envoyer quand même et journalise ce passage en force. Les envois par l’API, par MCP et par les automatisations signalent les constats et partent quand même. C’est le bon comportement par défaut. Certains e-mails que l’audit n’aime pas doivent tout de même partir, et un outil de contrôle qualité qui prend les envois en otage finit désactivé.
Il ne réécrit pas votre HTML. Les corrections sont une étape distincte, que vous lancez vous-même.
Il ne teste pas le placement en boîte de réception, ne produit pas de captures de rendu et ne vérifie pas le mode sombre. Pour le mode sombre, ouvrez un e-mail de test sur votre téléphone en mode sombre : vous repérerez le logo qui disparaît sur fond noir.
Dans la fenêtre d’envoi, 15 minutes. Au-delà, ou si l’e-mail change, le panneau vous demande de le relancer. Via MCP, vous pouvez relire gratuitement un rapport enregistré pendant 7 jours.
Non. L’audit vérifie l’e-mail lui-même. Le placement dépend aussi de la réputation du domaine, de l’authentification et du taux de plaintes, traités dans le guide de la délivrabilité.
Oui, via l’API ou MCP. Envoyez emailHtml ou emailJsx au lieu d’un identifiant d’e-mail Brew, et obtenez le même rapport avant que l’e-mail parte dans votre ESP. Si vous remixez un modèle de la galerie et l’exportez vers votre ESP, auditez-le dans Brew avant l’export.
Toute personne qui a accès à la marque peut le faire : les admins de l’organisation et les membres qui y ont été ajoutés. Brew n’a pas de rôle en lecture seule.
