Avant de revoir le design des e-mails de votre SaaS, identifiez clairement les messages existants et les personnes habilitées à les modifier. Un e-mail de bienvenue peut être géré dans une plateforme de lifecycle marketing, tandis qu'une introduction similaire part directement du code de l'application. Et dans le dossier de marque, il existe parfois une troisième version que personne n'envoie.
Partez d'une référence créative validée dans Migma, puis reliez chaque e-mail à son responsable d'envoi effectif et à son objectif produit actuel. Vous pourrez ainsi faire évoluer vos designs sans confondre un dossier de jolis templates avec un véritable inventaire opérationnel.
Ce guide est publié par Migma. La grille d'inventaire ci-dessous constitue une méthode de travail éditoriale, et non une certification de conformité ou un comparatif d'outils. La documentation produit de référence a été vérifiée le 16 octobre 2026.
Inventorier les messages plutôt que les abonnements logiciels
La liste de vos outils SaaS indique ce que vous payez, pas ce que reçoit un utilisateur lorsqu'il invite un collègue, change de forfait ou bloque pendant son onboarding. L'unité d'analyse doit être le message lui-même.
Attribuez à chaque message actif un intitulé explicite selon sa fonction : confirmer une invitation, guider l'étape de configuration suivante, annoncer une fonctionnalité ou relancer un paiement échoué. Conservez les identifiants techniques des templates dans votre tableau de suivi pour les retrouver facilement, mais évitez de les utiliser comme libellés visibles par les destinataires.
L'audit de programme d'e-mails SaaS de Loops aborde l'ensemble des enjeux de données, de couverture lifecycle, de sécurité et de mesure. Fiez-vous à ce guide complet pour évaluer votre dispositif global. Le présent article se concentre sur une étape préparatoire plus ciblée : aligner les créations de référence avec les points d'envoi réels et leurs responsables.
Définir une ligne par mission de message
Un tableur, un document partagé ou un tableau de projet existant suffit. L'essentiel est que ce support reste lisible à la fois pour un designer et pour un développeur.
| Champ | Exemple de saisie |
|---|---|
| Mission du message | Confirmer l'invitation d'un collaborateur |
| État du destinataire | Utilisateur invité n'ayant pas encore accepté |
| Création actuelle | Lien vers la référence Migma validée |
| Point d'envoi | Template ou workflow réellement actif aujourd'hui |
| Responsable produit | Personne qui vérifie l'état de l'invitation |
| Responsable créatif | Personne qui valide les textes et le design |
| Responsable d'envoi | Personne habilitée à modifier l'implémentation en production |
| Preuve | Exemple récent anonymisé ou test contrôlé |
| Prochaine décision | Conserver, analyser, reconcevoir ou retirer via une procédure validée |
Ces exemples sont indicatifs. Adaptez-les à votre organisation plutôt que d'attribuer un même responsable générique à chaque ligne. Une même personne peut cumuler plusieurs rôles, mais chaque décision doit avoir un référent clairement identifié.
Notez les zones de flou sans détour. La mention « probablement envoyé par l'application » est une piste à investiguer, pas un point d'envoi avéré. Séparez bien l'état des lieux actuel des messages envisagés pour l'avenir, afin de ne pas confondre projets en cours et production.
Rapprocher les trois versions de la réalité
Rassemblez trois éléments concrets avec votre équipe : la référence de design, la configuration d'envoi et un exemple réel reçu en boîte de réception. Chacun répond à une question différente.
La référence Migma illustre la création visée. La configuration d'envoi montre le template et les conditions configurés dans l'outil. L'e-mail réellement reçu montre ce que le système génère avec des données précises. Aucun de ces éléments ne remplace les deux autres.
Pour reprendre l'exemple de l'invitation, comparez systématiquement le nom de l'organisation, celui de l'expéditeur, l'URL du bouton, les précisions sur l'expiration du lien et le contact du support. Si l'application y ajoute un gabarit englobant ou des valeurs de repli différentes, l'e-mail final peut s'éloigner de la référence validée, même si le texte central semble exact.
Travaillez sur des exemples anonymisés lors des revues d'équipe. Écartez tout mot de passe, lien de connexion direct ou donnée personnelle inutile. Demandez au responsable technique de fournir des jeux de données de test représentatifs dès que le message d'origine contient des informations sensibles.
Prioriser les refontes selon le problème de l'utilisateur
Ne commencez pas par le template le plus daté simplement parce qu'il saute aux yeux. Ciblez d'abord un dysfonctionnement concret : une invitation qui mentionne le mauvais espace de travail, un e-mail de configuration sans prochaine étape claire, ou l'annonce d'une fonctionnalité pointant vers un écran inaccessible.
Faites valider par les responsables produit et technique si l'anomalie relève du contenu, des données ou de la délivrabilité. Une retouche graphique ne résoudra pas un événement produit manquant, tout comme un ajustement de serveur d'envoi ne clarifiera pas un appel à l'action ambigu. Documentez les causes non résolues comme des points à investiguer avant de commander un nouveau template.
Lorsqu'il s'agit bien d'un problème créatif, fournissez à Migma les éléments validés : la référence actuelle, l'action attendue de l'utilisateur et les contraintes techniques. La configuration de marque de Migma permet d'enregistrer votre identité visuelle, vos consignes et vos références. Vérifiez ces paramètres avant de les décliner sur l'ensemble de votre programme.
Clôturer la ligne après un passage de relais testé
Dès que la nouvelle création est validée, lancez Email Preflight, corrigez les remarques relatives à la mise en page, aux liens ou aux textes, puis examinez un envoi de test. Utilisez ensuite les options d'envoi ou d'export de Migma vers la destination retenue. Attention : un fichier téléchargé ou un template exporté ne prouve en rien que le message a été mis à jour en production.
Demandez au responsable d'envoi de tester l'intégration finale avec des données représentatives et dans l'état produit adéquat. Pour un workflow Loops, cela implique de contrôler directement le message et les paramètres du workflow au sein de Loops ; cela ne signifie pas que Migma importe ou gère automatiquement ce workflow.
Ne mettez à jour votre inventaire qu'une fois la modification confirmée. Conservez ensemble la référence validée, l'emplacement final en production, la date du test et le nom du responsable. Si un message doit être supprimé, appliquez la procédure de gestion des changements de votre équipe au lieu de l'effacer à la volée lors d'un simple nettoyage de templates.
Lors du déploiement de la prochaine version de votre produit, réexaminez les lignes concernées. Une fonctionnalité renommée ou un parcours de configuration modifié peuvent rendre une création obsolète sans que personne n'ait touché au fichier de design. Appuyez-vous sur cet inventaire pour intégrer ces ajustements ciblés dans votre prochain brief sur Migma, avec le bon interlocuteur déjà identifié.
Foire aux questions
Que doit contenir l'inventaire des e-mails d'un SaaS ?
Notez la mission de chaque message, l'état de l'utilisateur, la création validée, le point d'envoi réel, les responsables désignés et une preuve d'envoi. Une simple liste d'outils ne permet pas de savoir quelle version parvient réellement au destinataire.
Faut-il refondre un e-mail dont le responsable d'envoi n'est pas identifié ?
Identifiez d'abord le responsable et le canal d'envoi réel. Vous pouvez préparer une proposition graphique, mais ne la considérez pas comme un remplacement actif tant que le circuit d'envoi et les données de test n'ont pas été validés.
L'aperçu dans Migma prouve-t-il qu'un workflow est actif en production ?
Non. L'aperçu valide uniquement l'intention créative. Vérifiez séparément la configuration d'envoi et effectuez un test contrôlé sur la plateforme finale avant d'indiquer dans l'inventaire que le message est déployé.
Comment gérer les templates obsolètes ?
Indiquez l'analyse en cours et le projet de retrait dans l'inventaire. Laissez le responsable appliquer la procédure formelle de gestion des changements après avoir vérifié les déclencheurs et les workflows actifs. Ne supprimez jamais de templates au détour d'un simple tri graphique.