Une nouvelle tentative d'envoi ne doit pas modifier subrepticement le contenu d'un reçu transactionnel. Si un job Node expire et que l'essai suivant charge un template fraîchement édité ou des montants de commande recalculés, l'équipe ne sait plus exactement quel message le client a reçu.
Validez le design du reçu dans Migma, puis laissez les responsables Node et Loops figer les données métier de l'événement et rapprocher les statuts d'envoi incertains. Rédigé par Migma, ce guide s'intéresse au contrat créatif qui encadre les retries, sans prétendre installer d'intégration d'envoi ni affirmer que Migma pilote Loops de manière automatisée.
Définir ce qui constitue un même message
Prenons l'exemple d'une commande fictive de deux carnets. Le reçu initial détaille les articles, les totaux validés et la référence de commande. Ces données décrivent un événement métier précis. Un remboursement ultérieur ou un changement d'adresse représente une modification distincte à traiter explicitement, et non une variable à glisser discrètement dans un simple retry sans validation préalable.
Consignez par écrit ce que le premier envoi devait transmettre : référence de l'événement, destinataire prévu, version validée du template, variables obligatoires et responsable de chaque donnée. Laissez les coordonnées bancaires et les données personnelles superflues hors des notes de révision créative.
La question essentielle n'est pas simplement « Le code s'est-il réexécuté ? », mais « La tentative suivante visait-elle à transmettre le même événement validé à la même personne ? » Dès que la réponse diffère, ne traitez plus l'action comme un retry ordinaire et demandez au responsable concerné comment gérer cette correction.
Distinguer validation créative et identité de l'envoi
Le workflow documenté de Migma prépare les textes, le design, les images et un export HTML compatible avec les clients de messagerie pour relecture. C'est l'outil idéal pour s'accorder sur la mise en page et la rédaction du reçu. En revanche, il ne détermine pas quelle requête a été acceptée par le routeur, ni si le client final l'a déjà reçue.
Conservez la version créative validée aux côtés du mapping entre l'événement et le template. Si votre intégration utilise un template partagé dans Loops, formalisez la manière dont l'application verrouille les modifications lorsqu'un job d'envoi est en attente. Une simple capture d'écran stockée en local ne fige en rien le template exécuté par l'application en production.
Vérifiez le contenu factuel comme les actions proposées. Un lien de suivi de commande doit renvoyer à la commande exacte mentionnée sur le reçu. Un bouton générique « Voir votre commande » ne compense pas une URL erronée. Demandez au responsable technique d'examiner des exemples alimentés avec de vraies données, et non de simples noms de variables vides.
Respecter le contrat de retry du routeur
La ressource Node de Loops détaille l'envoi transactionnel et la gestion des nouvelles tentatives. Pour vérifier le comportement exact du service, reportez-vous à la documentation de l'endpoint transactionnel, consultée pour ce guide le 17 octobre 2026.
Cet endpoint documente l'utilisation d'un en-tête optionnel Idempotency-Key pour prévenir les requêtes en doublon, ainsi qu'une réponse HTTP 409 lorsqu'une clé a déjà été consommée dans sa fenêtre de validité. L'équipe responsable de l'envoi doit appliquer rigoureusement ce contrat. Générer une nouvelle clé d'idempotence dans le seul but de contourner un conflit compromet la protection contre les doublons que vous cherchiez à garantir.
Cet article ne fournit aucun code de retry ni de recette universelle de gestion des erreurs. Il appartient à l'ingénieur responsable de définir comment enregistrer et rapprocher les échecs temporaires, les erreurs définitives et les réponses ambiguës. La revue créative doit fournir les données stables dont ce processus a besoin, sans inventer d'état de distribution parallèle.
Évaluer trois scénarios avant le déploiement
Pour un retry à l'identique, vérifiez que l'événement d'origine, le destinataire, les montants et le contenu validé restent strictement inchangés. Assurez-vous que le job d'envoi référence bien cette version approuvée et que le responsable peut analyser ultérieurement le retour du routeur.
Pour un reçu modifié, identifiez précisément ce qui change et pourquoi. Une quantité corrigée, un remboursement ou un nouveau destinataire justifie souvent une communication validée à part. Ne réécrivez pas le sens du premier message pour faire correspondre l'envoi à une capture d'écran plus récente.
Pour une réponse incertaine, maintenez cet état d'incertitude tant que l'émetteur ne l'a pas résolu. Un timeout réseau ne prouve pas que le routeur a rejeté la requête. La volonté d'un marketeur de « s'assurer que le message est bien parti » ne doit pas se traduire par un second envoi non contrôlé via un autre canal.
Vérifier le rendu final du reçu
Utilisez l'export HTML de Migma comme référence créative validée. Le responsable de l'intégration Loops doit confirmer la méthode retenue pour intégrer ce design et renseigner ses variables. Ce guide n'implique aucune passerelle native directe entre Migma et Loops.
Testez l'affichage d'un reçu comportant plusieurs articles, un nom de produit particulièrement long, une variable optionnelle manquante et une commande rectifiée. Les données transactionnelles obligatoires ne doivent jamais être masquées par des suppositions approximatives. Si une information est indisponible, le responsable métier doit décider si l'email reste exact et diffusable.
Lancez Email Preflight pour contrôler la rédaction, les liens, la mise en page et les aperçus dans les boîtes de réception. Ensuite, suivez le protocole de test supervisé par l'équipe d'envoi pour valider le template final et les scénarios de retry. Un contrôle visuel ne préjuge ni de l'acceptation par le routeur, ni de la délivrabilité effective en boîte de réception.
Garder les corrections visibles pour toute l'équipe
Centralisez le contenu validé, le mapping des événements, les cas de test et le responsable du rapprochement. Lorsque le template partagé évolue, évaluez son impact sur les jobs en cours avec l'ingénieur avant de supposer que seuls les futurs messages seront concernés.
Au final, l'équipe dispose d'un reçu parfaitement traçable : son texte exact, l'événement qu'il décrit et les logs d'envoi attestant de son statut. Concevez vos créations dans Migma et liez systématiquement chaque décision de retry aux données réelles de l'application et du routeur.
Foire aux questions
Un timeout prouve-t-il que le reçu n'a pas été envoyé ?
Non. L'état d'une réponse peut être incertain même si le routeur a bien pris en compte la demande. L'équipe d'envoi doit rapprocher le statut réel de la requête avant d'envisager une nouvelle tentative.
Faut-il générer une nouvelle clé après une réponse 409 de Loops ?
N'utilisez pas une nouvelle clé simplement pour contourner un conflit. Consultez le contrat d'API actuel de l'endpoint et faites le point avec le responsable de l'envoi sur l'événement initial, la requête et la réponse du routeur.
Valider une capture d'écran dans Migma fige-t-il le template dans Loops ?
Non. Documentez la façon dont le template de destination et les jobs en attente référencent le contenu validé. Une capture d'écran sert de repère visuel de relecture, mais ne pilote pas le système d'envoi externe.
Un reçu modifié constitue-t-il un simple retry ?
Toute modification du destinataire, des faits métier ou de l'objet du message requiert une validation explicite. Le responsable doit déterminer s'il s'agit d'une correction ou d'une communication distincte, plutôt que d'écraser silencieusement le sens du message initial.