Mailjet devient critique quand une équipe utilise la même plateforme pour des messages transactionnels, des campagnes, des listes de contacts, des automatisations et des preuves de délivrabilité. Le problème concret apparaît quand une désinscription, un bounce ou un statut blocked modifie une promesse client sans être compris par le produit.
La documentation Mailjet expose des objets précis: Send API v3.1, tableau `Messages`, expéditeur validé, destinataires, `TemplateID`, `Variables`, `TemplateLanguage`, webhooks, contacts, contact lists, exclusion list, statuts delivered, open, click, bounce, spam, blocked, queued et retrying.
Vous allez comprendre quoi cadrer, quoi surveiller, quoi refuser et quoi corriger quand Mailjet porte à la fois l'envoi, la personnalisation, les consentements, les retours de délivrabilité et les workflows. Les symptômes à traiter sont connus: reprise manuelle, friction support, perte de preuve, dette de segmentation et arbitrage oral. Le vrai enjeu consiste à séparer ce qui relève du marketing, du transactionnel, du consentement et de la preuve support, tout en gardant une chronologie unique. Sans cette séparation, Mailjet fonctionne techniquement mais le métier perd la capacité de décider vite.
Pour poser ce cadre sans bricolage, notre accompagnement en intégration API aide à écrire les contrats, mappings, webhooks, workflows, files, retries, dashboards, secrets et runbooks nécessaires quand Mailjet porte des emails critiques.
Cette ressource rejoint la landing API emailing et marketing automation et la page intégrateur Mailjet, parce que la valeur vient de la preuve de statut et de consentement, pas seulement de l'envoi.
Pour qui Mailjet devient critique
Mailjet devient prioritaire pour les PME, e-commerces, SaaS et équipes marketing qui partagent le même outil entre transactionnel, newsletters, listes, segments et automatisations. À ce niveau, un statut mal interprété peut bloquer une facture, une activation ou une relance.
Contrairement à ce que l'on croit souvent, le coût complet ne vient pas du premier appel à `/v3.1/send`. Il vient des templates mal activés, des variables absentes, des contacts mal classés, des exclusions non propagées et des webhooks que personne ne rapproche au bon objet.
Le signal faible se voit avant l'incident: un email transactionnel est traité comme une campagne, une plainte spam bloque une adresse sans explication, un contact est désinscrit d'une liste mais reste visible ailleurs, ou le support ne sait pas si un message est delivered ou seulement queued.
Le déclencheur de priorité est clair: si un statut Mailjet peut modifier une promesse client, une préférence, une relance, un accès, une facture ou un workflow, alors le flux doit porter des owners, des seuils et un rollback exploitable.
1. Send API v3.1 et messages
Structurer le tableau Messages
Le Send API v3.1 de Mailjet attend un payload JSON dont la racine contient `Messages`. Chaque message doit préciser un expéditeur, des destinataires et une charge utile directe ou un template. Cette structure doit devenir un contrat applicatif, pas seulement un exemple copié depuis la documentation.
L'expéditeur doit être une adresse validée et active, sauf configuration prévue côté template. Les destinataires `To`, `Cc` et `Bcc` doivent être modélisés avec prudence, car plusieurs destinataires dans un même message peuvent se voir selon la construction du payload.
Le connecteur doit donc choisir entre un message commun et plusieurs entrées dans `Messages`. Une invitation individuelle, un reset de mot de passe ou une facture ne doit pas exposer d'autres destinataires par confort technique.
Séparer parties directes et TemplateID
Mailjet permet d'envoyer avec `TextPart` et `HtmlPart`, ou avec un `TemplateID` stocké dans Mailjet. Le choix doit être relié à la gouvernance produit: qui modifie la copie, qui valide les variables, qui teste le rendu et qui relit le statut en cas d'échec.
Un message transactionnel sensible ne doit pas dépendre d'un template modifié sans recette. Le connecteur doit conserver l'identifiant du template, la version attendue, la locale, les variables envoyées, le statut Mailjet et la clé interne qui explique le cas client.
Le seuil de qualité est simple: aucun flux critique sans expéditeur validé, aucun template prioritaire sans scénario de test, aucun destinataire multiple sans justification. Si une ligne échoue, l'ouverture est à différer.
Protéger destinataires, copies et confidentialité
La construction des destinataires doit être relue comme une question de confidentialité. Un même objet `Messages` peut contenir plusieurs destinataires, mais cette facilité ne convient pas aux emails individuels où chaque personne doit rester invisible pour les autres.
Le connecteur doit décider quand utiliser plusieurs entrées `Messages`, quand accepter `Cc` ou `Bcc`, et quand refuser un payload qui mélange des clients, partenaires ou collaborateurs sans justification métier. Cette règle doit être testée avant la production.
Si un audit détecte plus de 1 envoi critique avec destinataires exposés ou copies injustifiées sur 30 jours, alors la règle d'assemblage est à corriger immédiatement. Le risque porte sur la confiance, la confidentialité et la charge support.
2. Templates, Variables et TemplateLanguage
Activer TemplateLanguage au bon endroit
Dans Send API v3.1, l'objet de personnalisation s'appelle `Variables`, et le langage de template doit être activé avec `TemplateLanguage`. Si cette propriété reste à false, le système peut interpréter les éléments de template comme du texte ordinaire au lieu de les rendre.
Cette précision change la recette. Un email peut partir sans erreur visible tout en affichant une variable non remplacée, ou être bloqué si une variable attendue n'a pas de valeur ni de fallback. Le test doit donc vérifier le rendu final, pas seulement la réponse API.
Le signal faible devient visible quand le support reçoit des captures avec une balise de variable non rendue ou une valeur par défaut incohérente. Dans ce cas, le problème n'est pas la délivrabilité; il vient d'un contrat de template mal gouverné.
Gouverner valeurs par défaut et données contact
Mailjet distingue les variables poussées via l'appel et les données associées au contact. Les valeurs par défaut peuvent sécuriser un rendu, mais elles peuvent aussi masquer une donnée manquante si le produit ne sait pas quelle information devait réellement être affichée.
Le connecteur doit stocker les variables envoyées, la source des données contact, la version du template, la présence ou non d'une valeur par défaut et le statut de rendu attendu. Sans cette trace, une anomalie visuelle devient difficile à reproduire.
Le seuil opérationnel peut être concret: si plus de 3 emails critiques utilisent une valeur fallback imprévue sur 7 jours, alors le flux est à corriger avant extension. La personnalisation ne doit pas devenir une approximation permanente.
Tester les valeurs manquantes comme des incidents
Les variables absentes doivent être testées comme des incidents métier. Une valeur de prénom manquante est souvent peu grave, mais un montant, une date limite, un lien de paiement ou un identifiant de commande incorrect peut rendre le message dangereux.
La recette doit contenir des cas avec valeur présente, valeur vide, valeur fallback, contact sans propriété et template sans `TemplateLanguage`. Chaque résultat doit être relu dans le rendu final, dans les logs et dans la fiche support qui expliquera le cas.
Si un template critique affiche une valeur par défaut qui modifie la promesse client, alors le message est à bloquer avant envoi. La délivrabilité ne sert à rien si le rendu final provoque ensuite une correction commerciale.
3. Webhooks, statuts et preuve email
Transformer les webhooks en chronologie
Les webhooks Mailjet peuvent signaler open, click, bounce, spam, blocked, unsub et sent. Ces événements doivent être rapprochés avec le message, le contact, le template, le workflow et le statut interne avant de modifier une donnée métier.
Le connecteur doit vérifier MessageID, Message_GUID, email, CustomID, Payload, event, horodatage, tentative de retry et décision déjà prise. Sans idempotence, un webhook rejoué peut produire un doublon ou écraser une action support plus récente.
Le seuil terrain est lisible: si plus de 5 webhooks critiques restent sans rapprochement pendant 7 jours, alors les nouveaux flux Mailjet sont à bloquer. Le support travaille déjà sur une preuve incomplète.
Lire delivered, queued, bounced et blocked
Mailjet rappelle qu'un statut delivered signifie une acceptation par le serveur destinataire, pas une preuve d'arrivée en boîte de réception. Cette nuance doit être visible dans le back-office pour éviter les promesses support trop fortes.
Les statuts queued, retrying, bounced, blocked, spam et unsubscribed doivent produire des décisions différentes. Attendre, ralentir, corriger une adresse, protéger une réputation, désinscrire ou escalader n'ont pas le même impact métier.
Le support doit lire une phrase claire: message envoyé, en file, livré au serveur destinataire, ouvert, cliqué, bounce, bloqué, signalé spam ou désinscrit. Cette traduction évite les réponses floues quand le client demande une preuve.
Utiliser CustomID et Payload avec discipline
Les champs de corrélation comme `CustomID` et `Payload` peuvent aider à rattacher un événement Mailjet à un objet interne. Ils ne doivent pas devenir une zone libre où chaque équipe encode une structure différente selon son besoin du moment.
Le connecteur doit définir un format stable: type de flux, identifiant interne, version de mapping, environnement, owner et référence support. Les informations sensibles doivent rester dans le SI, pas dans un payload envoyé sans règle de gouvernance.
Le seuil de maturité est atteint quand 9 webhooks sur 10 peuvent être rapprochés automatiquement sans recherche textuelle. Si le support dépend encore d'un copier-coller dans les logs, la corrélation Mailjet reste trop fragile.
4. Contacts, listes et exclusions
Séparer liste, contact et exclusion
Mailjet gère des contacts, des propriétés, des listes, des désinscriptions et des exclusions. Une désinscription d'une liste ne porte pas toujours la même portée qu'une exclusion globale pour les campagnes. Le connecteur doit rendre cette différence visible.
Le modèle doit distinguer email, contact id, liste, propriété, statut d'abonnement, exclusion, motif, source et horodatage. Sans cette séparation, une préférence marketing peut bloquer une communication transactionnelle utile ou l'inverse.
Le seuil de qualité doit être écrit: si une désinscription ou une plainte spam n'est pas propagée en moins de 7 jours vers les systèmes qui relancent, alors les campagnes secondaires sont à suspendre. La réputation est déjà exposée.
Traiter les emails invalides et bounces
Mailjet indique qu'une adresse email d'une liste ne se modifie pas comme une simple propriété: une adresse erronée doit être retirée puis remplacée proprement. Cette règle doit être reflétée dans les workflows de correction du CRM et du support.
Les hard bounces, blocked et spam doivent être lus comme des signaux de réputation. Continuer à pousser les mêmes contacts dans des listes ou campagnes sans corriger la source crée une dette de délivrabilité difficile à rattraper.
Si plus de 2 % des contacts d'un segment critique demandent une correction manuelle sur 30 jours, alors la priorité est de corriger l'acquisition ou le mapping, pas d'ajouter de nouveaux scénarios email.
Propager les exclusions vers les systèmes aval
Une exclusion Mailjet ne doit pas rester confinée à l'outil emailing. Elle doit être rapprochée avec CRM, préférences utilisateur, back-office, support et outils de campagne. Sinon, un autre système peut continuer à pousser le même contact dans un flux risqué.
La propagation doit distinguer désinscription marketing, plainte spam, hard bounce, blocked et demande explicite du client. Ces motifs ne portent pas la même décision, et ils ne doivent pas tous bloquer les mêmes messages transactionnels.
Si une exclusion critique apparaît dans Mailjet mais reste absente du CRM pendant 7 jours, alors les campagnes de la liste concernée sont à suspendre. Cette suspension protège la réputation et force la correction de la source de vérité.
Auditer une désinscription de bout en bout
Une désinscription doit être relue comme un parcours complet: email envoyé, lien cliqué, statut unsub reçu, liste concernée, contact mis à jour, exclusion éventuelle et relance empêchée. Si une étape manque, le client peut continuer à recevoir des messages malgré une demande claire.
Le connecteur doit aussi distinguer la portée de la demande. Un unsubscribe sur une newsletter n'a pas toujours le même effet qu'une demande globale ou qu'une plainte spam. Cette différence doit être visible dans le CRM et dans la fiche support, pas seulement dans Mailjet.
Le seuil de contrôle peut être simple: 10 désinscriptions rejouées en recette, 10 propagations vérifiées et 10 relances bloquées comme attendu. Si un seul cas critique reste ambigu, alors la campagne suivante est à différer.
5. Workflows, événements externes et segmentation
Distinguer webhooks Mailjet et événements externes
Les webhooks d'événements Mailjet poussent des statuts email vers votre système. Les événements externes de workflow font l'inverse: votre système envoie un événement à Mailjet pour faire avancer un contact dans une automation. Les deux flux ne doivent pas être mélangés.
Pour les workflows, le qualifier doit correspondre au Tag choisi dans le builder, et le contact doit exister avec le bon identifiant, souvent l'email. Si l'un de ces éléments diverge, le workflow peut rester bloqué ou ne jamais démarrer.
Le seuil de recette peut être simple: aucun workflow critique sans fallback timer, aucun qualifier non versionné, aucun contact envoyé à Mailjet sans preuve d'existence. Si une ligne manque, l'automation est à différer.
Relier segmentation et consentement
La segmentation Mailjet repose sur propriétés, comportements et listes. Le connecteur doit préserver la source et la date des propriétés utilisées, car un segment peut déclencher une campagne ou exclure un contact d'un parcours sensible.
Un segment marketing ne doit pas devenir une règle transactionnelle cachée. Le produit doit savoir si une absence de contact vient d'un filtre, d'une exclusion, d'une propriété manquante ou d'un statut bloqué par la délivrabilité.
Le signal faible apparaît quand une équipe contourne les segments avec des exports CSV. Ce geste indique que le modèle de contact n'est plus assez fiable pour piloter les campagnes ou les workflows sans intervention manuelle.
Journaliser l'appel qui déclenche un workflow
Quand votre système envoie un événement externe à Mailjet, il doit garder le qualifier, le contactMail, la clé API utilisée, le statut de réponse, le payload et l'objet métier d'origine. Sans cette trace, un workflow bloqué devient une enquête entre deux systèmes.
Le fallback timer doit aussi être visible dans le run. Si un contact n'avance pas dans le délai prévu, l'équipe doit savoir si l'événement externe manque, si le contact n'existe pas, si le qualifier diverge ou si un filtre de segment l'a exclu.
Le seuil de recette peut être exigeant: 8 événements externes rejoués, 8 contacts vérifiés et 8 décisions support lisibles. Si un scénario reste oral, le workflow Mailjet n'est pas prêt pour une charge commerciale.
6. Dashboards, support et délivrabilité
Donner au support une preuve lisible
Un dashboard Mailjet utile ne doit pas seulement montrer des taux. Il doit relier chaque message à son contact, sa liste, son template, ses variables, ses webhooks, son statut final et l'action autorisée par le support.
Les métriques doivent produire une consigne. Si blocked augmente, l'équipe vérifie réputation, liste et source de contact. Si spam augmente, les campagnes sont à suspendre. Si queued dure trop longtemps, les flux critiques doivent être priorisés.
Le seuil de maturité est atteint quand 9 tickets sur 10 peuvent être résolus depuis le back-office, sans ouvrir Mailjet et sans demander un export développeur. Sinon, les métriques existent mais la preuve reste dispersée.
Préserver marketing et transactionnel
Une des difficultés de Mailjet tient à la cohabitation entre marketing et transactionnel. Les campagnes veulent optimiser audience, segmentation et engagement; les emails transactionnels veulent prouver une action utile et préserver une promesse client.
Le connecteur doit donc séparer files, templates, owners, seuils, consentements, exclusions et indicateurs. Un problème sur une campagne ne doit pas empêcher un reset de mot de passe si la politique métier l'autorise explicitement.
Si une même règle bloque indifféremment marketing et transactionnel sans justification écrite, alors l'architecture est à corriger avant extension. La prudence doit protéger la réputation sans casser les parcours indispensables.
Faire descendre le dashboard au niveau ticket
Un taux global de bounce ou de blocked aide la direction, mais le support a besoin d'une lecture par message. La fiche doit montrer demande applicative, contact, liste, template, variables, statuts reçus, dernier webhook et action autorisée.
Cette lecture doit rester stable quand le volume monte. Si une personne support doit ouvrir Mailjet, le CRM et un fichier CSV pour expliquer un cas simple, l'observabilité n'est pas encore au bon endroit.
Le seuil de maturité est atteint quand un ticket Mailjet critique peut être qualifié en moins de 15 minutes avec une preuve exploitable. Au-delà, le problème devient une charge support et une dette de confiance.
7. Exemple Mailjet en production
Synchroniser un parcours e-commerce
Prenons un e-commerce qui utilise Mailjet pour confirmations de compte, factures, relances panier, newsletters et workflow après achat. Le flux reçoit une demande applicative, choisit un template, injecte `Variables`, envoie via `Messages`, puis attend webhooks et statuts.
Le scénario nominal paraît direct, mais les variantes coûtent cher: `TemplateLanguage` oublié, contact absent du workflow, désinscription de liste, spam, blocked, bounce, statut queued prolongé, segment incomplet ou variable fallback qui masque une donnée manquante.
Le bon résultat n'est pas seulement une réponse API. Le back-office doit montrer message id, contact, liste, template, variables, dernier event Mailjet, statut support, tentative de retry et prochaine action autorisée.
Décider ce qui bloque le go-live
Cas concret: une confirmation de commande part avec un `TemplateID`, mais une variable de prix utilise une valeur par défaut inattendue. L'email peut être delivered, mais la preuve client est fausse. Le flux doit être bloqué jusqu'à correction du mapping.
Le seuil de lancement doit être lisible: zéro template critique sans `TemplateLanguage`, aucun workflow sans fallback, aucune complaint sans action support, aucune exclusion non propagée et aucun statut blocked sans owner. Si une ligne échoue, l'ouverture est à différer.
Cette discipline protège la promesse client. Le produit sait ce qui est arrivé, le support sait quoi répondre et l'équipe plateforme sait quelle partie du connecteur Mailjet corriger avant d'augmenter les volumes.
Afficher la preuve dans le back-office
Le back-office ne doit pas seulement conserver un MessageID Mailjet. Il doit afficher une chronologie compréhensible: demande créée, contact identifié, liste ou segment concerné, template choisi, variables injectées, appel accepté, webhook reçu, statut final et action support.
Les statuts doivent rester peu nombreux pour éviter la confusion. En attente, sent, delivered, queued, retrying, bounce, blocked, spam, unsub, open, click et action requise suffisent souvent. Les détails techniques restent dans la trace d'audit.
Cette preuve doit survivre aux changements d'équipe. Six mois après le lancement, une nouvelle personne du support doit comprendre pourquoi un contact est exclu, quel template a été envoyé, quel workflow attend encore et quelle action reste autorisée.
La fiche doit aussi garder les refus. Savoir pourquoi un renvoi est interdit après spam, pourquoi une campagne reste suspendue ou pourquoi un workflow attend son fallback évite les contournements et protège la réputation.
8. Plan d'action Mailjet
Cartographier messages, contacts et consentements
Commencez par lister les flux Mailjet réellement utilisés: transactionnel, campagnes, listes, segments, templates, workflows, webhooks, exclusions, bounces et stats. Chaque flux doit avoir un owner, une priorité et une règle de preuve.
La cartographie doit relier application, contact, liste, exclusion, template, Variables, TemplateLanguage, event, statut, workflow, queue, retry et support. Si une ligne ne dit pas quoi faire avec spam ou blocked, le flux n'est pas prêt.
Le livrable attendu tient dans une matrice: flux, endpoint, contact, liste, consentement, template, variable, event, statut, retry, owner, rollback et preuve support. Cette matrice permet de repérer les trous avant la production.
- À valider d'abord: expéditeurs actifs, templates, TemplateLanguage, Variables, contacts, listes, exclusions et webhooks critiques.
- À bloquer avant ouverture: tout email prioritaire sans sent, bounce, spam, blocked et unsub routés vers un système exploitable.
- À corriger avant extension: tout segment, tag, workflow ou variable impossible à rapprocher avec un objet métier interne.
- À différer volontairement: les campagnes secondaires qui consomment réputation ou temps support sans preuve utile immédiate.
Écrire les contrats de statuts
Le deuxième jalon consiste à écrire les contrats de statuts: sent, delivered, open, click, bounce, spam, blocked, unsub, queued et retrying. Chaque statut doit avoir une traduction métier, une action support et une règle de conservation.
Les événements sensibles doivent être séparés des signaux analytiques. Un open ou un click peut nourrir le reporting, mais un bounce, spam, blocked ou unsub doit protéger la réputation et modifier les relances.
Le contrat doit contenir un exemple concret par famille: envoi direct, template, workflow, exclusion, désinscription, blocked, bounce et variable manquante. Ces exemples deviennent la base de la recette et du runbook.
Construire monitoring et reprises
Le troisième jalon porte sur l'exploitation: état des files, statuts queued, bounced, blocked, spam, unsub, webhooks muets, workflow bloqué, contact absent, owner, alertes, dashboard support et procédure de rollback.
Les alertes doivent dire quoi faire. Si un template échoue, alors l'envoi attend. Si spam augmente, alors les campagnes sont à suspendre. Si un contact manque dans un workflow, alors le mapping CRM est à corriger.
La mise en œuvre doit prévoir un rollback réaliste: suspendre une campagne, ralentir une queue, revenir à un template précédent, isoler un segment, désactiver un workflow ou placer certains contacts en revue humaine.
Limiter la première ouverture
La première mise en production doit prouver un périmètre court: deux templates critiques, un workflow, une liste, un segment, un webhook bounce, un webhook blocked, une exclusion propagée et une fiche support.
Le go-live doit être conditionné par des critères vérifiables: expéditeur validé, template testé, Variables présentes, TemplateLanguage actif, bounces routés, spam routé, support capable de relire un cas simple et rollback documenté.
Le risque est de croire qu'une campagne réussie prouve la maturité. Une intégration Mailjet mature sait aussi refuser un envoi quand le consentement, les variables ou les preuves de run ne sont pas assez solides.
9. Recette, seuils et rollback
Tester les familles coûteuses
La recette doit couvrir les familles qui coûtent en production: expéditeur invalide, `TemplateLanguage` absent, variable manquante, fallback inattendu, contact inexistant, liste incorrecte, workflow sans qualifier, bounce, spam, blocked et désinscription non propagée.
Chaque test doit produire une preuve complète: application, contact, liste, template, variables, message id, event reçu, statut métier, owner, décision de reprise et action support. Sans cette preuve, le test valide surtout le transport.
Le seuil d'acceptation peut être simple: si une même famille d'erreur revient sur 7 jours sans cause documentée, alors le flux est à corriger avant toute extension. Cette règle protège réputation, support et promesse client.
Séparer recette produit et recette plateforme
La recette produit vérifie templates, variables, contact, liste, workflow, statut client et consignes support. La recette plateforme vérifie secrets, endpoints, webhooks, logs, exclusions, stats, files, alertes et rollback.
Un envoi peut être correct côté application mais inutilisable si les webhooks ne remontent pas. Inversement, un webhook peut fonctionner mais ne rien dire au support si les statuts Mailjet ne sont pas traduits.
Cette revue doit produire une décision écrite. Le ticket de recette doit dire quelle action est autorisée, quelle action reste interdite et quel indicateur prouvera que Mailjet, l'application et le support racontent la même histoire.
Définir rollback et amélioration continue
Le rollback Mailjet peut prendre plusieurs formes: suspendre un template, ralentir un workflow, réduire une campagne, isoler une liste, désactiver un segment ou revenir à un provider de secours pour un flux critique.
L'amélioration continue doit rester mesurable. Une alerte plus claire sur blocked, une fiche support sur exclusions ou une règle de variable mieux documentée vaut souvent mieux qu'un nouveau workflow qui augmente la surface de risque.
Après les 30 premiers jours, l'équipe doit relire les bounces récurrents, les blocked, les questions support, les webhooks manquants, les workflows bloqués et les templates corrigés. Si le run n'a pas réduit ces frictions, il faut améliorer le mapping avant d'élargir.
Simuler le support avant le volume
La meilleure recette Mailjet consiste à donner de vrais cas au support avant le go-live: un delivered contesté, un blocked, une complaint, un unsubscribe de liste, un workflow qui attend un événement externe et un template dont une variable manque.
Chaque cas doit être résolu avec les écrans et preuves disponibles, sans intervention du développeur qui a construit le connecteur. Si l'équipe support ne trouve pas contact, liste, template, statut, cause et action autorisée, le run n'est pas assez lisible.
Le seuil de sortie peut être concret: 6 scénarios résolus en moins de 15 minutes, 6 décisions support cohérentes et zéro correction hors procédure. Si une réponse dépend d'un souvenir projet, alors la documentation est à corriger avant volume.
Cette simulation doit être rejouée après les premiers changements de template, de liste ou de workflow. Une recette qui réussissait au lancement peut devenir insuffisante dès que les équipes marketing ajoutent des variantes ou de nouveaux segments. Le runbook doit donc préciser qui relance la simulation, quels tickets sont relus et quel seuil impose une pause avant la prochaine campagne. Cette rigueur évite que Mailjet devienne une boîte noire entre marketing, produit et support, surtout quand les volumes montent et que les exceptions deviennent plus nombreuses pendant les pics commerciaux ou les périodes de forte relance avec forte pression support documentée.
10. Erreurs fréquentes Mailjet
Les pièges qui brouillent consentement et preuve
- Confondre delivered et arrivée en inbox, puis promettre au client une preuve que Mailjet ne peut pas fournir seul.
- Oublier TemplateLanguage sur un template critique, puis découvrir des variables non rendues après le go-live.
- Partager les mêmes règles entre campagnes et transactionnel sans arbitrage explicite sur consentement et réputation.
- Ignorer unsub, spam et blocked dans le CRM ou le back-office qui pilote les relances.
- Envoyer des événements externes vers un workflow sans vérifier qualifier, contact existant et fallback timer.
- Élargir les volumes avant d'avoir prouvé webhooks, listes, exclusions, retries et rollback sur un périmètre court.
Ces erreurs passent parfois les premiers tests parce que l'endpoint répond correctement. Elles deviennent visibles quand un client ne reçoit pas un email critique, quand la réputation se dégrade ou quand le support ne peut pas expliquer ce qui s'est passé.
Le bon réflexe consiste à ralentir avant d'élargir. Une intégration Mailjet limitée mais parfaitement observable protège mieux la délivrabilité qu'une architecture large qui laisse consentements et statuts dans une zone grise.
Le signe le plus révélateur reste la multiplication des corrections manuelles. Une désinscription corrigée hors procédure, un blocked ignoré ou un template corrigé sans version paraît parfois acceptable, mais ces gestes deviennent vite une dette.
Les signaux qui imposent une pause
Une pause s'impose quand les webhooks deviennent muets, quand les blocked ne sont pas propagés, quand les spam ne suspendent rien, quand les workflows restent bloqués ou quand les clients ouvrent des tickets répétitifs sur les mêmes emails.
Le seuil terrain est utile: si un même contournement revient plus de 10 fois en 7 jours, alors il faut corriger la règle, documenter le cas ou bloquer l'extension. Le coût support et le risque réputation sont déjà visibles.
La reprise doit être conditionnée par une preuve simple: les mêmes cas doivent pouvoir être résolus avec le runbook, sans recherche manuelle dans Mailjet et sans arbitrage oral. Quand cette condition est atteinte, l'équipe peut rouvrir le périmètre.
Un dernier signal faible mérite attention: les équipes commencent à exporter des contacts pour contourner listes, segments ou workflows. Ce bricolage montre que l'outillage officiel ne suffit plus ou que le modèle de consentement n'est pas clair.
Questions fréquentes sur Mailjet
Que faut-il cadrer avant une intégration API Mailjet ? Il faut cadrer Send API v3.1, Messages, From, To, TemplateID, Variables, TemplateLanguage, contacts, listes, exclusions, webhooks, workflows, bounces, spam, blocked, retries et preuve support.
Pourquoi TemplateLanguage est-il important ? Sans TemplateLanguage actif, les éléments de template peuvent être traités comme du texte ordinaire. Le rendu final doit donc être testé avec les variables réelles, les valeurs par défaut et les cas manquants.
Une réponse Send API Mailjet suffit-elle à prouver la livraison ? Non. Elle prouve le traitement de la demande. Il faut ensuite rapprocher webhooks et statuts pour expliquer delivered, bounce, spam, blocked, open, click, unsub ou queued.
Dawap peut-il accompagner une intégration Mailjet ? Oui. Dawap peut cadrer les contrats, construire le connecteur, sécuriser les accès, modéliser webhooks, listes, exclusions, workflows, retries et donner au support des preuves exploitables.
Guides complémentaires Mailjet
La ressource API Mailgun complète Mailjet avec un autre modèle d'email transactionnel, orienté messages, variables, webhooks et suppressions. La comparaison aide à distinguer transport et run de délivrabilité.
La ressource API SendGrid apporte un angle utile sur templates, événements, suppressions et réputation. Elle aide à cadrer les invariants entre providers email transactionnels et marketing.
La ressource API Postmark éclaire les sujets de messages transactionnels, streams et preuves support. Elle complète Mailjet quand l'équipe compare simplicité opérationnelle et contrôle fin des statuts.
La landing API emailing et marketing automation relie ces comparaisons à l'offre métier, tandis que la page intégrateur Mailjet précise l'accompagnement possible sur Send API, webhooks, contacts, listes, exclusions et workflows.
Conclusion: intégrer Mailjet sans dette
Une intégration Mailjet réussie ne se reconnaît pas au premier message accepté par l'API. Elle se reconnaît quand chaque message, template, variable, contact, liste, exclusion, webhook, workflow et statut peut être expliqué par les équipes qui exploitent le flux.
Le bon ordre reste clair: vérifier les expéditeurs, versionner les templates, activer TemplateLanguage, gouverner les Variables, router les webhooks, gérer les exclusions, surveiller les statuts, encadrer les workflows et documenter les reprises.
La valeur vient aussi du refus des raccourcis. Il faut laisser en attente les envois, campagnes ou workflows qui risquent de brouiller consentement, réputation ou preuve support, même si Mailjet permet techniquement de les brancher.
Si vous devez relier Mailjet à une application, un e-commerce, un SaaS ou un back-office avec un run sérieux, notre accompagnement Integration API peut cadrer le contrat, le connecteur, l'observabilité et les reprises sans déplacer la dette vers les développeurs ou le support.
