Un e-mail déclenché par un événement n'est prêt pour la production que lorsqu'un utilisateur ciblé entre dans le bon parcours et reçoit le bon message avec des données exploitables. Validez d'abord la création dans Migma, puis testez l'événement et la version finale dans Customer.io avant d'activer l'automatisation.
Un aperçu peut sembler impeccable alors qu'un champ manque dans le payload de l'événement ou qu'une réitération emprunte la mauvaise branche. À l'inverse, l'événement peut très bien déclencher le scénario alors que l'e-mail contient un lien ou un CTA inopérant. Il s'agit de dysfonctionnements distincts qui exigent des vérifications séparées.
Ce guide est conçu par Migma pour les équipes produit et marketing relationnel (lifecycle) qui partagent la responsabilité des e-mails événementiels. La documentation officielle de Customer.io sur les tests et les recommandations d'export de Migma ont été vérifiées le 14 octobre 2026. Les cas de recette présentés ci-dessous sont des exemples originaux et ne proviennent pas de tests clients en production.
Définir le résultat attendu en amont du test
Isolez un événement précis et l'objectif du destinataire (reader job). Par exemple, un événement de configuration de compte indique souvent que l'utilisateur a besoin d'instructions pour finaliser une étape précise. Déterminez quelle tâche reste à accomplir, quel état du compte justifie l'envoi de l'e-mail, et quelle action concrète doit clore ce besoin.
L'article de Customer.io sur la messagerie événementielle détaille comment un même événement peut orienter l'utilisateur vers des parcours différents selon son historique et son contexte. Posez-vous la question : dans votre application, un premier événement et un événement répété doivent-ils déclencher la même réaction ?
Ne transformez pas chaque action enregistrée en notification. Un critère de recette pertinent peut tout à fait stipuler qu'un événement met à jour un contexte sans envoyer d'e-mail. « Aucun e-mail attendu » devient alors un comportement intentionnel et testable.
Formulez clairement le scénario : « Lorsque ce compte de test déclenche l'événement dans tel état, il doit recevoir ce message une seule fois, vers cette destination. » Évitez les exigences floues du type « le workflow doit fonctionner ».
Définir le contrat de données du message
Listez précisément les champs dont l'e-mail a besoin. Indiquez pour chacun s'il est obligatoire, facultatif ou calculé à la destination. Ajoutez un exemple réaliste et le comportement attendu lorsqu'une variable facultative est absente.
Un e-mail d'onboarding a besoin d'un nom de produit et d'un lien cible, pas de l'historique complet des achats. Maintenez ce contrat de données suffisamment concis pour faciliter la relecture. Le développeur ou le responsable des données doit valider quel système fournit chaque champ.
Si une variable porte le même nom dans plusieurs systèmes, assurez-vous qu'elle désigne exactement la même réalité. Un volume total d'événements n'a rien à voir avec un décompte d'actions réussies : ces notions ne doivent pas être confondues dans le contenu.
Travaillez avec des données de test synthétiques ou validées. Pour concevoir le message, il faut des valeurs représentatives et des cas limites, jamais des identifiants de production ni des données sensibles.
Valider les créations dans Migma
Renseignez dans Migma l'objectif du destinataire, le contrat de données, les informations validées et le lien cible. Vérifiez le contexte de marque, puis générez un e-mail ciblé qui guide l'utilisateur vers l'action suivante.
Veillez à la cohérence du texte lorsque des données facultatives manquent. Une accroche telle que « Votre équipe est prête » ne doit pas reposer sur l'hypothèse non vérifiée que des collaborateurs ont déjà rejoint le compte. Le rendu de test doit couvrir à la fois un profil complet et un profil dépourvu de nom ou de prénom.
Lancez Email Preflight pour contrôler l'action principale, la mise en page en boîte de réception et le texte. Preflight vérifie la conception graphique et les risques d'envoi habituels, mais ne peut pas garantir qu'un événement Customer.io a bien atteint le bon scénario.
Utilisez le téléchargement HTML de Migma pour la transmission technique si nécessaire. Ce guide ne suppose aucun connecteur d'export natif vers Customer.io : l'intégration et l'adaptation aux variables et à la syntaxe de Customer.io incombent à la personne chargée de l'implémentation.
Tester le message cible avec des données de test éligibles
Le guide officiel de test d'e-mails de Customer.io recommande de sélectionner un profil dans l'onglet Sample Data avant d'envoyer un test. Pour les flux déclenchés par un événement, ce profil doit impérativement avoir déjà réalisé l'événement en question, faute de quoi les données d'événement seront absentes de la prévisualisation.
Un message d'erreur indiquant un événement manquant ne relève donc pas forcément d'un problème d'intégration du template. Vérifiez l'historique d'événements du profil de test avant de modifier le gabarit, puis validez que les données injectées génèrent bien le contenu attendu.
La documentation rappelle également la distinction entre le profil dont les données alimentent le message et les adresses qui reçoivent physiquement l'e-mail de test. Vérifiez ces deux paramètres : un test exécuté avec le mauvais profil peut donner un résultat faussement rassurant.
Établir une matrice de recette pour le parcours
Appuyez-vous sur un ensemble restreint de scénarios maîtrisés, directement calqués sur votre implémentation réelle.
| Scénario | Résultat attendu |
|---|---|
| Premier événement éligible | Parcours adéquat et message validé |
| Événement répété | Comportement de réitération prévu, sans doublon involontaire |
| Champ facultatif manquant | Texte de repli (fallback) lisible et action opérationnelle |
| Tâche effectuée pendant un délai d'attente | Message toujours pertinent ou envoi interrompu comme prévu |
| Événement issu d'un compte non éligible | Aucun e-mail envoyé par erreur |
La configuration précise des filtres et de la récurrence relève du responsable de vos scénarios. Ce tableau liste ce qu'il convient de contrôler ; il ne garantit pas que n'importe quel paramétrage bloquera automatiquement les doublons.
Consignez systématiquement l'événement, le compte de test, l'état concerné, la version du template, le destinataire du test et le résultat observé. Un événement bien reçu ou un e-mail accepté par un serveur d'envoi constituent des jalons utiles, mais aucun des deux ne prouve que le destinataire a reçu le bon message.
Attribuer chaque anomalie au bon responsable
Si l'événement n'apparaît pas, vérifiez le tracking ou l'historique du profil de test. Si le scénario sélectionne la mauvaise personne, revoyez les règles d'éligibilité et de routage. Si la personnalisation échoue, confrontez le contrat de données au template Customer.io. Enfin, si le message est mal agencé ou illisible, corrigez la création dans Migma.
Ce cloisonnement évite qu'une équipe design ne réécrive un e-mail pour compenser un problème de routage ou de données. Il fournit également aux développeurs des critères de recette clairs plutôt qu'un retour vague indiquant que l'e-mail semble anormal.
N'activez l'automatisation qu'une fois le parcours et son contenu formellement validés par leurs responsables respectifs. Conservez l'historique des tests aux côtés de la création approuvée : lors des prochaines évolutions, vous pourrez ainsi rejouer directement les cas critiques sans repartir de zéro.
Foire aux questions
Pourquoi la prévisualisation Customer.io indique-t-elle que les données d'événement sont manquantes ?
Selon la documentation officielle, le profil de test sélectionné doit avoir déjà déclenché l'événement pour les tests de campagnes événementielles. Vérifiez l'historique du profil avant d'attribuer l'erreur au template.
Le fait qu'un événement atteigne le scénario garantit-il le bon fonctionnement de l'e-mail ?
Non. Le routage, l'éligibilité, la personnalisation, le rendu final et le fonctionnement des liens constituent des vérifications de recette distinctes.
Migma propose-t-il un export natif vers Customer.io dans ce guide ?
Non, aucun connecteur natif n'est présenté. Utilisez l'export HTML documenté selon vos besoins, et adaptez le message aux champs et à la syntaxe Customer.io lors de l'intégration.
Quels cas doivent figurer dans la matrice de recette ?
Testez les cas critiques propres à votre architecture : premier envoi et répétition de l'événement, champs facultatifs manquants, actions accomplies pendant un délai d'attente et comptes inéligibles. Notez systématiquement les résultats attendus et observés.