Quand un e-mail envoyé par Magento affiche un mauvais nom de boutique, changer simplement le logo dans la maquette ne résout généralement rien. La notification finale reçue par le client combine en réalité un gabarit de corps de texte avec un en-tête, un pied de page, des variables dynamiques et des paramètres propres à une vue magasin (store view) spécifique.
Commencez dans Migma par définir ce que le client doit identifier : l'identité visuelle de la marque, la langue, le point de contact du support et l'objectif du message. Demandez ensuite au responsable technique d'Adobe Commerce de vérifier la façon dont ces briques s'assemblent dans la notification réelle de la boutique. Cette démarche fait le pont entre la validation créative et les réglages de configuration qui pilotent l'e-mail final.
Ce guide est publié par Migma. Il détaille une méthode de recette éditoriale et non une intégration native pour Magento ou une procédure de déploiement. Les recommandations d'Adobe concernant les modèles ont été vérifiées le 20 octobre 2026.
Identifier précisément la vue magasin et l'e-mail concerné
Partez d'un cas concret. Notez la vue magasin, le type de notification, l'identité attendue, l'anomalie constatée et l'heure d'envoi. Travaillez toujours sur un exemple anonymisé plutôt que de faire circuler inutilement des données clients.
Prenons l'exemple fictif d'un distributeur qui gère une boutique principale d'équipement en anglais et un outlet localisé dans une autre langue. L'e-mail de bienvenue de l'outlet peut très bien afficher le bon texte dans le corps du message, mais renvoyer vers la boutique principale anglophone dès qu'un utilisateur clique sur l'en-tête. Il s'agit d'un dysfonctionnement bien différent d'un logo manquant ou d'une description produit non traduite.
Décrivez le problème du point de vue du destinataire. Indiquer que « le clic sur le header renvoie vers l'autre storefront » donne au responsable de l'implémentation un scénario précis à reproduire. Affirmer simplement que « le branding n'est pas le bon » laisse la porte ouverte à trop d'hypothèses.
Vérifier la structure complète du message
La documentation d'Adobe sur les modèles d'e-mails personnalisés explique que les messages système associent un gabarit principal à des modèles d'en-tête et de pied de page distincts. Elle précise également que la personnalisation s'applique à l'échelle du site web, de la boutique ou de la vue magasin, et qu'il est indispensable d'assigner le bon gabarit personnalisé dans la configuration.
Par conséquent, prévisualiser uniquement le corps de l'e-mail ne garantit en rien la cohérence globale de l'identité du message. Vérifiez avec l'équipe technique quels en-têtes et pieds de page sont sélectionnés, et quelle configuration appelle le gabarit de corps pour la notification concernée. Conservez les identifiants précis de ces modèles dans votre fiche de suivi.
Lors de la revue créative, examinez ces aspects conjointement :
| Élément | Question côté client | Élément de preuve à demander |
|---|---|---|
| Header | Quelle marque s'exprime et vers quelle page pointe son lien ? | L'en-tête généré avec son lien de destination réel |
| Corps du message | Le message et la langue sont-ils adaptés à cette vue magasin ? | Le modèle d'e-mail sélectionné avec des données d'exemple validées |
| Footer | Le destinataire peut-il joindre la bonne équipe de support ? | Des liens fonctionnels vers le support et les informations de la boutique |
| Variables | Les valeurs dynamiques de la boutique sont-elles cohérentes avec le message ? | Un exemple généré avec les données de la vue magasin concernée |
Ces points constituent des critères de recette et non des consignes pour modifier directement les réglages de production. Le responsable technique Commerce doit appliquer la procédure officielle adaptée à votre infrastructure.
Définir l'identité de référence dans Migma
Vérifiez le contexte de marque dans Migma avant d'entamer la rédaction. Contrôlez le logo, la palette de couleurs, la typographie, la tonalité, les références enregistrées et les informations légales validées de l'entreprise. Démarrer une conception à partir du contexte d'une autre marque risque d'introduire une nouvelle anomalie pendant que l'on tente de résoudre la première.
Rédigez un brief précis pour la vue magasin ciblée. Pour notre exemple d'outlet, précisez la langue validée, les coordonnées du support et la page d'accueil correspondante. Détaillez les éléments fournis par l'équipe technique et les tournures de phrase qui doivent rester rigoureusement inchangées. Ne collez jamais de véritables données clients dans un prompt de conception générique.
Créez une maquette complète qui montre explicitement l'agencement attendu entre le header, le corps et le footer. Si l'environnement Commerce final assemble ces blocs séparément, documentez clairement ce passage de relais. Ce processus ne repose pas sur l'idée qu'un simple fichier HTML téléchargé va configurer par magie chaque composant de gabarit dans Magento.
Préserver les variables de la plateforme lors de l'intégration
Adobe met en garde contre l'écrasement du code placé entre doubles accolades lors de l'édition du contenu des modèles. Cette séparation est essentielle pour distinguer le texte validé lors de la revue créative des variables dynamiques générées par la plateforme.
Demandez à l'intégrateur de recenser les variables et directives propres à la notification. La demande d'un graphiste ou d'un rédacteur visant à reformuler une phrase ne doit en aucun cas modifier accidentellement un numéro de commande, l'URL de la boutique ou toute autre expression dynamique. Utilisez des jeux de données d'exemple validés pour contrôler la syntaxe et la grammaire autour des champs injectés.
Si une variable manque à l'appel ou affiche une valeur inattendue, confiez l'analyse au responsable technique. N'inventez pas une syntaxe de remplacement issue d'une autre plateforme. Un espace réservé visuellement crédible sur une maquette ne garantit absolument pas que la notification en production saura l'alimenter correctement.
Comparer le rendu configuré à la maquette de référence
Consultez les options d'export de Migma pour suivre le flux de transmission créative pris en charge, puis inspectez le résultat directement dans l'environnement cible. L'administrateur doit contrôler les gabarits personnalisés sélectionnés et leur niveau de portée (scope) : le simple fait d'enregistrer un modèle ne signifie pas que la vue magasin active l'utilise.
Pour notre outlet fictif, rejouez le scénario de l'e-mail de bienvenue en utilisant des données de test validées. Vérifiez que l'en-tête renvoie bien vers l'outlet, que le corps du message utilise la bonne langue et que le footer dirige vers le service client dédié. Examinez ensuite un autre storefront de référence pour vous assurer qu'aucune modification globale involontaire n'a affecté les autres boutiques.
Cette vérification s'avère particulièrement utile lorsqu'une correction semble fonctionner sur un aperçu isolé alors que l'e-mail réellement reçu reste incorrect. Retracez la configuration active et le message généré avant de modifier à nouveau la création.
Valider l'affichage en boîte de réception et consigner la recette
Lancez l'Email Preflight sur la maquette de référence Migma et traitez les alertes importantes. Testez ensuite le message final produit par la plateforme dans les principales messageries, sans oublier les écrans mobiles et le mode sombre dès que votre équipe dispose des outils pour le faire. Le rendu varie souvent d'un client de messagerie à l'autre ; ne garantissez jamais un affichage strictement identique partout.
Rassemblez dans un même dossier de recette la vue magasin concernée, les références des gabarits, la version validée dans Migma, le scénario de test, les URL de destination finales et le nom du relecteur. Mentionnez également toute contrainte technique non résolue. Ce document doit expliciter clairement à la fois ce que le client final voit et quelle configuration technique en est responsable.
Le guide de Brevo sur l'automatisation des e-mails Magento offre un éclairage plus large sur la gestion des e-mails en environnement multi-boutiques. Notre méthode se concentre sur un objectif précis : faire en sorte que chaque notification envoyée appartienne sans ambiguïté à la bonne boutique en ligne. Commencez par valider une référence dans Migma, puis vérifiez l'e-mail complet une fois assemblé avant de déployer la modification à plus grande échelle.
Foire aux questions
Pourquoi le corps du message peut-il être correct alors que l'identité de la boutique est erronée ?
Adobe structure les messages à partir de gabarits distincts pour le corps, l'en-tête et le pied de page, avec une configuration propre à chaque niveau de portée (scope). Analysez le message assemblé et la configuration active, plutôt que le seul corps de l'e-mail.
L'enregistrement d'un modèle personnalisé suffit-il pour qu'il soit appliqué à la vue magasin ?
Pas nécessairement. La documentation d'Adobe précise qu'il faut également mettre à jour la configuration pour lier ce modèle personnalisé. Demandez au responsable technique Commerce de valider l'assignation effective pour la notification et la portée concernées.
Un export Migma peut-il configurer automatiquement tous les éléments d'un e-mail Magento ?
Non, ce n'est pas l'objet de ce processus. Migma sert à établir la référence créative validée et à exporter le code HTML pris en charge, tandis que l'équipe technique configure dans la plateforme l'en-tête, le corps, le pied de page, les variables et les paramètres correspondants.
Que doit contenir un rapport de recette pour valider l'identité d'un storefront ?
Consignez la vue magasin, le type de notification, les références des gabarits sélectionnés, la version validée dans Migma, le scénario de test avec données fictives, les URL de destination fonctionnelles et le nom du relecteur. Notez les éventuelles limites techniques non résolues et vérifiez un storefront de comparaison si des paramètres partagés sont en jeu.