# Checklist de contrôle qualité avant envoi : 8 vérifications

URL canonique : https://brew.new/fr/blog/pre-send-email-qa-checklist
Rédigé par Thomas Park
Publication : 2026-10-11
Mise à jour : 2026-10-11

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.

![Le résultat d’un audit d’e-mail, avec un score, un statut de préparation à l’envoi et des constats regroupés par gravité.](/images/blog/email-audit-findings.png)

*Les constats regroupés par gravité, avec un seul verdict sur la préparation à l’envoi.*

## À retenir

- Contrôlez huit points : liens, poids, images, compatibilité avec les clients de messagerie, accessibilité, textes, conformité et balisage.
- Gmail tronque le HTML au-delà d’environ 102 Ko, ce qui masque le pied de page et le lien de désabonnement. Brew avertit dès 80 Ko, car le suivi des clics alourdit l’e-mail.
- Cliquez sur chaque lien dans un e-mail de test réellement reçu, mais ne laissez jamais un outil de vérification automatique ouvrir les liens de désabonnement ou de préférences.
- L’audit de Brew attribue un score de 0 à 100 : moins 20 points par constat critique, 10 par erreur, 3 par avertissement. Un seul constat critique ou une seule erreur, et l’e-mail n’est pas prêt.
- L’audit ne bloque jamais un envoi, et il ne teste ni le placement en boîte de réception, ni les captures de rendu, ni le mode sombre.

## 1. Liens

Un lien cassé gâche l’envoi. Vérifiez que :

- chaque bouton a une vraie destination, et non `#`, `example.com` ou un `{{url}}` non renseigné
- aucun lien ne renvoie d’erreur 404 ou 410, ne pointe vers un domaine qui ne se résout pas, n’a de certificat invalide, ne refuse la connexion ni ne part dans une boucle de redirections
- chaque lien utilise `https`
- le texte visible du lien correspond à sa destination. Un `brew.new/pricing` qui pointe ailleurs ressemble à du phishing
- vous évitez les raccourcisseurs d’URL publics, qui partagent leur réputation avec tous les spammeurs qui s’en servent

Cliquez 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.

## 2. Poids

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 :

- **80 Ko** de HTML : avertissement
- **102 Ko** de HTML : erreur, car Gmail tronquera l’e-mail
- **3 Mo** de poids total chargé, HTML et images compris : avertissement
- **5 Mo** de poids total chargé : erreur

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.

## 3. Images

Chaque image doit :

- avoir un texte `alt`, ou `alt=""` si elle est purement décorative
- avoir des attributs `width` et `height`, pour que la mise en page tienne pendant le chargement des images ou quand elles sont bloquées
- se charger, et être une image, pas une page d’erreur HTML
- peser moins de **1 Mo**, ou **3 Mo** pour un GIF

Une 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.

## 4. Compatibilité des clients de messagerie

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](https://www.caniemail.com/) 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.

## 5. Accessibilité

Les contrôles qui ne coûtent presque rien :

- un attribut `lang` sur `<html>`, pour que les lecteurs d’écran prononcent correctement le texte
- un `<title>`
- des niveaux de titres dans l’ordre, sans sauter de `h1` à `h4`
- un texte alternatif qui dit ce que l’image communique. « Graphique à barres montrant le doublement des inscriptions en mars » aide. « image1.png », non
- le contraste du corps de texte, des boutons et du texte gris clair du pied de page, où se cachent la plupart des défauts

Les [WCAG 2.2](https://www.w3.org/TR/WCAG22/) 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.

## 6. Textes, objet et texte d’aperçu

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](/fr/blog/how-to-write-marketing-emails) et le [guide des objets d’e-mail](/fr/blog/email-subject-lines) approfondissent la formulation.

## 7. Conformité

La loi américaine [CAN-SPAM](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) 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](/fr/blog/agent-email-deliverability).

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.

## 8. Balisage

Retirez ce que les clients de messagerie suppriment ou bloquent :

- les éléments `<script>`, `<form>` et `<iframe>`
- le SVG intégré et les URI `data:`
- les images d’arrière-plan sans couleur de repli `background-color`, pour que le texte reste lisible si l’image ne se charge pas

Commencez par un doctype. Sans lui, certains clients passent en mode quirks et les espacements se décalent.

## Appliquer la checklist dans Brew

L’audit d’e-mail de Brew applique cette liste depuis :

- l’onglet **Audit** de la fenêtre d’envoi, à côté des onglets Aperçu et Audience
- le bouton **Auditer** des étapes d’e-mail, dans le canevas des automatisations
- l’API et MCP, avec `POST /v1/emails/audit` ou l’outil `audit_email`

Consultez la [documentation de l’audit](https://docs.brew.new/create-emails/audit-email) et la [référence de l’API](https://docs.brew.new/api-reference/public-v1/emails/audit-an-email) 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 :

- une requête réelle vers chaque lien, jusqu’à 100 par e-mail, en ignorant les liens de désabonnement et de préférences. Les liens bloqués par une barrière anti-robots ressortent « non vérifiés », pas morts
- une requête vers chaque image, pour repérer les visuels morts ou trop lourds
- la compatibilité avec 15 clients de messagerie répartis en quatre familles (Gmail, Apple Mail, Outlook et Yahoo), selon la règle de la section 4
- le contraste et les autres règles d’accessibilité, avec les références WCAG 2.2
- une relecture par IA qui vérifie si l’objet est trompeur, si les textes des liens et les textes alternatifs ont un sens, si une adresse postale est présente, quel que soit le format du pays, et si l’e-mail est marketing ou transactionnel

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.

## Comment fonctionne le score

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.

## Ce que l’audit ne fait pas

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.

## Questions fréquentes

### Combien de temps un audit reste-t-il valable ?

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.

### Un score élevé garantit-il que l’e-mail arrivera en boîte de réception ?

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é](/fr/blog/email-deliverability).

### Puis-je auditer un e-mail créé dans un autre outil ?

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](/fr/blog/how-to-remix-a-real-brand-email-template-and-export-it-to-your-esp), auditez-le dans Brew avant l’export.

### Qui peut lancer un audit dans mon équipe ?

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.