Salut !
Je suis en train de créer une automation de billetterie de bout en bout pour un festival local : elle lit une base de données Google Sheets, exécute un peu d’analyse/logique, et envoie par email à chaque acheteur un code QR, le logo de la marque et du texte via une adresse SMTP d’entreprise connectée.
Ma préoccupation : l’email contient deux images, le logo de la marque (en haut, dans l’en-tête) et le code QR (sous le texte). Le QR est référencé par une expression donc il se résout correctement. Mais si un fournisseur décide d’afficher la version texte au lieu du HTML, le client perd le logo et le code QR.
Pour le contexte, le code QR est également inclus en tant que pièce jointe, pas seulement en ligne, donc même si le rendu échoue, l’acheteur a quand même le code QR. Mais j’aimerais bien comprendre le comportement HTML/texte correctement.
Questions :
-
Avec Email Format : Both, comment n8n décide-t-il réellement ce qui est envoyé : envoie-t-il les deux parties dans un seul message, ou en choisit-il une ?
-
Est-ce que tous les fournisseurs modernes (Gmail, Yandex, Mail.ru, iCloud) rendent la partie HTML, ou y a-t-il un vrai risque que certains affichent la version texte aux clients ? - le plus important
-
Y a-t-il des bonnes pratiques pour garantir que le HTML/QR se rend bien pour les clients qui paient ?
Merci !
Bonjour @Nick_Vieru
Quand vous sélectionnez le format « Both » (les deux) dans n8n, le système n’envoie pas une seule version ; à la place, il regroupe les versions texte brut et HTML dans un seul email (techniquement appelé message multipart/alternative). Une fois l’email reçu, c’est l’application email du destinataire—pas n8n—qui décide quelle version afficher. Dans la quasi-totalité des cas, l’application essaiera d’afficher la version HTML car elle est plus visuellement attrayante.
Pour les fournisseurs modernes comme Gmail, iCloud, Yandex et Mail.ru, le risque qu’un client ne voie que la version texte est très faible. Le rendu HTML est la norme mondiale pour les emails. L’utilisateur ne verrait la version texte seul que s’il a manuellement changé ses paramètres en « Texte brut uniquement » pour des raisons de sécurité extrême ou d’accessibilité, ou si l’email est marqué comme spam à haut risque par le fournisseur.
Concernant vos images, n8n gère les images en ligne en utilisant des « Content-IDs » (CIDs), qui indiquent au client email de récupérer une pièce jointe spécifique et de la placer dans le corps HTML. Bien que cela fonctionne habituellement, certains clients d’entreprise (comme certaines versions de Microsoft Outlook) peuvent être difficiles et peuvent occasionnellement supprimer le rendu en ligne et simplement afficher les images comme des pièces jointes traditionnelles en bas du message.
Puisque vous incluez déjà le code QR en tant que pièce jointe séparée, vous avez déjà mis en place le meilleur filet de sécurité possible. Pour garantir davantage une apparence professionnelle, vous pouvez ajouter du « texte alternatif » à vos balises HTML d’image (par exemple, alt="Votre code QR de billet") afin que même si l’image ne se charge pas, l’utilisateur sache ce qui manque. Votre configuration actuelle est robuste et suit les meilleures pratiques de l’industrie pour les emails transactionnels critiques.
Merci ! Ça m’éclaire et c’est beaucoup moins préoccupant pour moi.
Je vais ajouter la balise HTML alt au code QR et au logo de marque. Bonne journée !
Heureux de pouvoir aider !!!