Un bloc HTML personnalisé doit résoudre un problème précis que les composants standard ne permettent pas de traiter. Il doit aussi rester utilisable si le nom d’un produit s’allonge, qu’une image manque ou que l’email est ouvert sur un téléphone. Définissez le composant minimal nécessaire, testez-le en dehors de l’éditeur, puis réutilisez la version qui résiste à ces situations.
Définissez le plus petit changement nécessaire
Notez ce que le bloc doit communiquer et pourquoi la mise en page existante ne le fait pas correctement. Limitez le code à cet objectif. Évitez d’importer une page web entière avec des scripts, des dépendances interactives ou des styles que les applications email risquent de ne pas prendre en charge.
Sendvio prend en charge les blocs HTML pour les emails. Gardez le code personnalisé compréhensible pour la personne qui entretiendra le gabarit le mois prochain. Privilégiez une structure claire, du texte pertinent et des descriptions d’images appropriées plutôt que de cacher le message dans des éléments décoratifs.
Définissez le contrat d’un petit composant
Précisez l’objectif du bloc, le contenu obligatoire et facultatif, la longueur réaliste maximale du texte, les liens, le comportement des images et l’ordre d’affichage sur mobile. Par exemple, un bloc comparant deux options peut nécessiter le nom de chaque produit, une caractéristique distinctive, le contexte du prix et une action. Le contrat doit préciser ce qui doit rester regroupé lorsque la mise en page s’empile.
Demandez-vous si les blocs standard peuvent répondre au besoin avec une présentation plus simple. Le HTML personnalisé se justifie lorsqu’il résout un problème de communication clair, pas seulement parce qu’il permet une composition plus élaborée. Chaque règle structurelle supplémentaire doit ensuite être comprise et testée par la prochaine personne qui modifiera le message.
Gardez le bloc personnalisé autonome. Évitez les styles généraux qui modifieraient par surprise les composants voisins, et ne faites pas dépendre le message principal de scripts ou d’interactions prévues pour un site web. Si l’expérience demande une sélection ou un calcul complexe, expliquez la tâche dans l’email et renvoyez vers une page adaptée.
Vérifiez le comportement en dehors de l’éditeur
Le rendu des emails diffère de celui d’un site web classique. Testez le message réellement envoyé dans les applications pertinentes, sur un petit écran et avec les images désactivées. Vérifiez les liens, l’ordre de lecture, le redimensionnement du texte et la cohabitation du bloc avec les composants standard du gabarit.
Évitez les hauteurs fixes autour de contenus variables et les chaînes de caractères longues impossibles à couper. Un nom de client ou un titre traduit peut révéler un défaut que le court texte d’exemple masque. Prévoyez une version plus simple si le bloc personnalisé ne peut pas fonctionner de manière fiable.
Testez les changements de contenu, pas seulement l’exemple initial
Remplacez le nom de produit le plus court par le plus long que vous puissiez rencontrer. Supprimez une image facultative, ajoutez un titre traduit et allongez le prix ou le libellé d’un bouton. Vérifiez si la structure grandit naturellement ou si elle coupe le contenu et laisse des espaces fixes vides. Ces essais montrent si le bloc est réutilisable ou s’il ne fonctionne que pour un seul exemple.
Examinez le message réellement envoyé dans les environnements email pertinents. Vérifiez que l’ordre de lecture reste logique, que les descriptions d’images conviennent au contexte et que chaque destination fonctionne. Si la mise en page utilise des tableaux, veillez à ce qu’ils ne présentent pas une structure sémantique trompeuse aux technologies d’assistance.
Ne réutilisez que la version testée
Enregistrez le bloc approuvé avec une courte note indiquant son objectif et ses limites. Lors d’une modification, distinguez une simple retouche du texte d’un changement structurel qui nécessite un nouvel examen du rendu.
N’ajoutez pas de scripts de suivi ou de code exécutable pour donner à un email le comportement d’un site web. Si l’interaction va au-delà de ce qu’un email peut assurer de façon fiable, dirigez le lecteur vers une page adaptée. Un petit bloc robuste aide davantage qu’un composant sophistiqué qui ne fonctionne que dans l’aperçu de son créateur.
Conservez le bloc approuvé dans les notes de version du gabarit, avec son objectif, la personne responsable, ses usages pris en charge et ses limites connues. Une retouche de texte peut être sans risque, tandis qu’un changement de colonnes ou l’ajout de contenu conditionnel mérite un nouvel examen du rendu. Rendez cette distinction claire afin que l’équipe évite à la fois les tests inutiles et les refontes traitées comme de simples corrections de texte.
Prévoyez une solution plus simple si le composant ne peut pas se comporter de manière fiable. Une comparaison sur une seule colonne que le client peut lire vaut mieux qu’une mise en page complexe qui échoue dans un environnement courant. Les critères d’acceptation sont concrets : contenu exact, regroupements préservés, texte lisible, actions accessibles et structure que la prochaine personne chargée d’une campagne peut réutiliser sans risque.