La plupart des problèmes se ramènent à une poignée de causes. Ils sont classés ici selon la fréquence à laquelle les marchands les rencontrent, et chacun a sa solution.
« J’ai tout connecté mais rien ne se synchronise »
C’est presque toujours l’une de deux causes, et chacune se vérifie rapidement.
1. Le cron ne s’exécute pas. La synchronisation passe par une file d’attente en arrière-plan : sans cron, rien n’est envoyé et aucune erreur ne s’affiche à l’écran. Dans l’admin, ouvrez l’onglet Queue Monitor (Marketing → Intuit Mailchimp → Dashboard) : si Pending ne cesse d’augmenter sans jamais se vider, le cron est en cause. Demandez à votre hébergeur de confirmer que le cron de Magento est bien planifié ; une fois qu’il s’exécute, l’onglet Cron Monitor affiche chaque tâche en vert.
2. Votre base de données est en dessous du minimum requis. L’extension nécessite MySQL 8.0+ ou MariaDB 10.6+ pour la synchronisation en arrière-plan. Si le cron s’exécute et que Pending ne se vide toujours pas, vérifiez la version de votre base de données et mettez-la à niveau si elle est en dessous du minimum.
L’installation ou la mise à niveau échoue (erreurs setup:upgrade ou di:compile)
Lors d’une installation avec Composer, celui-ci applique les prérequis pour vous (Magento 2.4.6+, PHP 8.1 à 8.4, MySQL 8.0+ ou MariaDB 10.6+) : un refus net signifie donc que l’environnement doit atteindre ce socle minimal. Si vous installez plutôt depuis un zip, installez d’abord le paquet PulseCore fourni dans app/code, sinon di:compile s’arrête sur une erreur de classe introuvable. setup:upgrade ajoute des colonnes à quelques tables du cœur de Magento, les boutiques volumineuses devraient donc l’exécuter pendant une fenêtre de maintenance. Si une compilation échoue après une mise à jour, passez au dernier correctif publié puis relancez setup:upgrade, di:compile et cache:flush. Installation contient le pas-à-pas complet.
Ce que signifient les libellés de statut
Chaque commande, client et produit affiche un statut :
| Statut | Signification | Faut-il agir ? |
|---|---|---|
| Synced | Envoyé à Mailchimp | Non |
| Up to date | Rien n’a changé, l’élément a donc été ignoré | Non |
| Pending | En attente de la prochaine exécution du cron | Assurez-vous simplement que le cron s’exécute |
| Error | Un envoi récent a échoué ; peut se résoudre seul | Revenez voir dans quelques minutes |
| Action needed | Échec définitif après plusieurs tentatives | Corrigez les données, puis cliquez sur Retry dans l’Entity Queue |
| Not supported | Un produit de type personnalisé n’a pas de SKU ou de nom ; rien n’a été envoyé | Ajoutez le SKU ou le nom, puis resynchronisez (voir plus bas) |
| Not in Mailchimp | Jamais envoyé ; hors du périmètre de synchronisation | Seulement si vous vous y attendiez (voir plus bas) |
Pourquoi « Not in Mailchimp » ? Ce n’est pas une erreur : l’enregistrement était hors du périmètre de synchronisation. Sa vue de boutique n’est pas connectée, il est plus ancien que votre fenêtre de synchronisation, ou il s’agit d’une commande historique en dehors de votre sélection de revenus confirmés. Par défaut, les revenus confirmés correspondent aux statuts processing, complete et closed : cette sélection détermine quelles commandes historiques sont importées et quelles commandes comptent dans les revenus et la valeur vie client. Les nouvelles commandes se synchronisent au fil de l’eau et restent à jour à chaque changement de statut.
Erreurs « Invalid email », mais impossible de trouver ce client
Une commande passée en tant qu’invité n’a pas de compte client : l’e-mail se trouve donc sur la commande, pas dans la grille des clients. Cherchez dans Sales → Orders.
Mailchimp rejette les adresses qui semblent factices ou mal formées. Les vrais e-mails d’invités se synchronisent sans problème ; seules les adresses invalides sont exclues, et c’est voulu. Pour en corriger une, ouvrez la commande, corrigez l’e-mail de facturation et enregistrez (elle se remet en file d’attente d’elle-même). Sur les boutiques de test, les données d’exemple contiennent souvent des e-mails fictifs que Mailchimp rejettera : c’est attendu, ce n’est pas un défaut.
Problèmes de connexion
- Une bannière indique « Mailchimp is disconnected » : la solution accompagne le message. La bannière embarque son propre bouton Reconnect to Mailchimp, et un clic rétablit la liaison. Si vous avez un jour besoin du chemin plus complet, ouvrez la page Mailchimp accounts (le menu ⋯ de la barre d’onglets d’exploitation), choisissez-y Reconnect, puis vérifiez que votre vue de boutique pointe toujours vers la bonne audience.
- L’en-tête affiche « Not Connected » après l’ajout d’un compte : ajouter un compte et connecter une vue de boutique sont deux étapes distinctes. Basculez la portée sur une vue de boutique, puis choisissez Connect store.
- « Connect store » n’affiche aucune boutique : soit aucun compte n’est encore connecté, soit chaque boutique Mailchimp est déjà liée à une autre vue de boutique. Ajoutez un compte, ou créez une nouvelle boutique dans Mailchimp.
- La fenêtre de connexion n’aboutit jamais : autorisez les popups pour votre domaine d’admin, et assurez-vous que votre serveur peut joindre Mailchimp en HTTPS.
« Ma clé API est signalée comme invalide, alors qu’elle est toute neuve »
Vérifiez d’abord le format : une clé Mailchimp se termine par le suffixe de son centre de données (par exemple -us21), générez donc une clé neuve et collez-la en entier. Si la clé est réellement valide, le journal sous var/log enregistre chaque appel de validation avec la clé masquée : une ligne avec HTTP 401 signifie que Mailchimp a rejeté la clé elle-même, tandis qu’une erreur de transport sans code de statut signifie que votre serveur n’a pas pu joindre Mailchimp ; demandez alors à votre hébergeur d’autoriser le HTTPS sortant vers <dc>.api.mailchimp.com. Une clé qui devient invalide plus tard se repère sur la page Mailchimp accounts : l’indicateur de santé du compte change dans l’heure, et Update key la corrige sur place, sans déconnecter la boutique. Connecter votre compte Mailchimp détaille chaque étape.
Les tags n’apparaissent pas sur les contacts
Les tags de catégorie s’appliquent à chaque commande synchronisée dès l’instant où vous les activez, et une resynchronisation applique aussi les tags à votre historique de commandes : les tags ne sont jamais dupliqués, la resynchronisation est donc toujours sans risque. Ils s’appliquent aux acheteurs disposant d’un compte client ; les achats des invités enrichissent plutôt les champs de données d’achat. Tags, champs de données et segmentation explique comment chaque tag est construit.
Champs d’achat vides sur des contacts plus anciens
Les champs de données d’achat sont créés automatiquement lors de la première synchronisation d’un contact. S’ils apparaissent vides sur des contacts qui étaient déjà dans votre audience, Rebuild merge fields (ou une resynchronisation) les remplit. Tags, champs de données et segmentation explique ce que chaque champ suit.
« Les revenus de campagne dans Mailchimp ne correspondent pas à ma boutique »
Une chute soudaine à 0 $ sur toutes les campagnes signifie que les commandes n’atteignent plus Mailchimp : vérifiez d’abord le Queue Monitor et le Cron Monitor. Le choix des commandes prises en compte est un paramètre : Order Statuses to Sync (Configuration → Ecommerce Sync) décide de ce qui compte dans les revenus, et les annulations sont envoyées avec des totaux remis à zéro, elles ne les gonflent donc jamais. Un crédit attribué à la mauvaise campagne est exclu par conception : l’extension n’assigne jamais de campagne à une commande ; l’attribution relève du suivi des clics de Mailchimp lui-même. Quand les chiffres divergent malgré tout, chaque surface mesure une tranche différente, et Pourquoi vos chiffres diffèrent de ceux de Mailchimp en donne le détail complet.
Les produits semblent incorrects dans Mailchimp : images manquantes, prix étranges, détails obsolètes
Corrigez d’abord les données du catalogue : un produit sans image dans le rôle Base se synchronise sans image, et le prix provient de la portée de vue de boutique que vous modifiez. Puis renvoyez le produit : Push Now, dans l’onglet Mailchimp du produit, le remet en file à priorité temps réel, et l’action de masse Push to Mailchimp ou bin/magento mailchimp:resync envoient toujours, même quand rien n’a changé dans Magento. Le détail de la ligne dans l’Entity Queue montre la charge utile exacte qui est partie, consultez-le donc peu après l’envoi. Les prix se synchronisent comme le prix final du catalogue, sans taxe ajoutée, et Mailchimp affiche un seul prix de vente actif par produit, ce qui est attendu. Les cartes cadeaux Adobe Commerce portent un prix représentatif (le plus petit montant configuré, ou le minimum du montant libre), et un produit de type personnalisé à prix nul retombe à 0,00. Les totaux de commande et les prix de ligne proviennent toujours des montants réellement payés : une carte cadeau à montant libre est donc déclarée au montant exact choisi par l’acheteur. Comment fonctionne la synchronisation explique ce qui est envoyé et quand.
Les champs de données mappés arrivent vides ou cessent de se mettre à jour
Les mappages personnalisés vivent dans la grille Data fields (Configuration → Contact Sync) et se modifient à la portée de la vue de boutique, car chaque vue de boutique correspond à sa propre audience. Créez d’abord le champ d’audience dans Mailchimp : la liste déroulante ne propose que les balises de fusion qui existent dans cette audience, une faute de frappe ne peut donc jamais être enregistrée. Enregistrer un vrai changement remet en file chaque contact concerné, et Rebuild merge fields force le même rafraîchissement, ce qui remplit aussi les champs vides sur les contacts antérieurs au mappage. Si un champ cesse discrètement de se mettre à jour, la cause habituelle est que sa balise a été supprimée dans Mailchimp : recréez-la côté Mailchimp ou videz la ligne. Tags, champs de données et segmentation couvre chaque champ.
Les invités n’apparaissent pas après avoir abandonné leur panier
Mailchimp a besoin d’une adresse e-mail pour envoyer une relance, et l’extension en capture une dès l’instant où un invité la saisit quelque part : au moment du paiement, dans un encart newsletter, ou en arrivant depuis un lien de campagne. Si les paniers d’invités n’apparaissent pas, vérifiez que la vue de boutique est connectée ; un invité qui n’a jamais communiqué d’e-mail nulle part ne peut pas être relancé, et tous les autres paniers circulent d’eux-mêmes. Récupérer les paniers abandonnés montre le parcours complet.
« Mon automatisation de panier abandonné n’envoie jamais d’e-mail »
Les e-mails de récupération sont envoyés par votre automatisation Mailchimp, pas par l’extension : commencez donc par le panneau Abandoned Carts du Dashboard. Si les paniers sont bien comptés mais que rien ne part, suivez le lien Set up automation du panneau pour finaliser l’automatisation dans Mailchimp. Si Total Carts reste à 0, ouvrez le Cron Monitor (les paniers passent par la voie Boost) et le Queue Monitor, et vérifiez que cette vue de boutique est connectée. Une commande finalisée retire aussitôt son panier de Mailchimp, les acheteurs ne reçoivent donc jamais de relance pour un article déjà acheté, et les liens de récupération des clients enregistrés mènent volontairement à la page de connexion. Récupérer les paniers abandonnés parcourt tout le trajet.
L’interrupteur du Pixel refuse de s’activer
L’interrupteur ne bascule qu’une fois l’activation confirmée par Mailchimp : s’il reste éteint, la fenêtre de l’extension vous en donne la raison et nomme la vue de boutique concernée. Le cas courant est celui de deux vues de boutique qui partagent la même adresse web : chaque Pixel vit sur son propre domaine, une seule des deux vues le porte donc. Les événements comportementaux continuent, quoi qu’il arrive, de circuler côté serveur pour chaque vue de boutique, vos segments et vos parcours client continuent donc de fonctionner. Le Pixel Mailchimp et les événements comportementaux donne les détails.
Le Pixel est actif mais rien ne se déclenche sur la boutique en ligne
Ouvrez la boutique en ligne avec les outils de développement de votre navigateur : la page vous indique lequel des trois comportements connus vous observez. Si votre bannière de consentement aux cookies n’a pas encore été acceptée, le Pixel est retenu volontairement : acceptez-la et le script s’injecte en une seconde environ. Si la console affiche une violation de Content-Security-Policy citant chimpstatic.com ou mcjs.prd.a.intuit.com, le blocage vient d’une CSP définie en dehors de Magento : ajoutez-y les deux hôtes à script-src et connect-src. S’il s’agit d’une différence de hachage de script inline sur la page de paiement, mettez l’extension à jour : chaque version embarque le hachage approuvé courant. Les événements côté serveur continuent de circuler quoi qu’il arrive, dans l’onglet Events Tracking. Le Pixel Mailchimp et les événements comportementaux explique les deux moitiés.
La case d’abonnement ne s’affiche pas
Trois vérifications rapides : videz le cache de Magento ; regardez si le Pixel est actif sur cette vue de boutique (la case de la page de paiement s’efface volontairement, pour que la page de confirmation ne porte aucune invite en double) ; et vérifiez que Sync Newsletter Subscribers est activé dans les paramètres Contact Sync, car c’est lui qui rend disponibles les surfaces d’opt-in. Développer votre audience couvre les deux cases.
Les désabonnements effectués dans Mailchimp n’atteignent pas Magento
Les webhooks s’enregistrent d’eux-mêmes lors du Go Live, commencez donc par la surface d’audit : ouvrez Webhooks depuis le menu d’exploitation, cliquez sur Check Webhooks et choisissez la vue de boutique. Une boutique saine affiche « Webhooks are active » ; si elle propose Register à la place, cliquez dessus (ou Re-register si l’URL de votre boutique a changé). Quand l’enregistrement échoue, la fenêtre en explique la raison, et le cas courant est que Mailchimp ne parvient pas à joindre l’URL de votre boutique (pare-feu, mode maintenance, ou site de préproduction protégé par mot de passe) : rendez-la accessible publiquement et enregistrez de nouveau. Les désabonnements s’appliquent dès leur arrivée ; les changements de profil nécessitent aussi que Sync Newsletter Subscribers soit activé. Désabonnements et consentement couvre le flux dans les deux sens.
Les e-mails de confirmation arrivent en double, ou les abonnés restent en attente
Considérez le réglage Double Opt-In de l’extension (Configuration → Contact Sync) comme l’unique bouton de confirmation : lorsqu’il est activé, Mailchimp envoie le seul e-mail de confirmation et pilote l’étape de confirmation. Laissez le réglage « Need to Confirm » de la Newsletter de Magento désactivé, sauf si vous voulez délibérément un second e-mail de confirmation : avec les deux activés, les abonnés reçoivent deux e-mails et restent en attente jusqu’à ce qu’ils cliquent sur le lien de Mailchimp. Si un client se réabonne mais ne réapparaît jamais, l’API Log montre l’entrée verrouillée pour conformité : Mailchimp protège les contacts qui se sont désabonnés via un lien de campagne, et ils se réinscrivent via un formulaire d’inscription hébergé par Mailchimp. Désabonnements et consentement explique le consentement dans les deux directions.
Nous avons changé de domaine et la synchronisation s’est mise en pause
Elle s’est mise en pause à dessein : c’est la protection qui empêche une boutique déplacée ou clonée d’écrire au mauvais endroit. Quand l’adresse de votre boutique change, après un changement de domaine, une migration de serveur ou un environnement copié, l’extension met cette vue de boutique en pause et une bannière d’admin explique ce qui s’est passé. Déconnectez puis reconnectez la vue de boutique et la synchronisation reprend ; Connecter votre compte Mailchimp détaille les étapes de connexion.
Une bannière indique que notre boutique Mailchimp liée a été supprimée dans Mailchimp
Rien n’est perdu : la synchronisation n’écrit jamais vers une boutique absente, et les changements en file attendent en toute sécurité au statut Pending. Soit vous restaurez la boutique côté Mailchimp (une vérification de santé horaire lève la pause d’elle-même), soit vous basculez Configuration sur la vue de boutique concernée, vous déconnectez depuis la fenêtre de connexion et vous reconnectez via le Setup Wizard ; les données se resynchronisent automatiquement. Si une boutique Mailchimp existe déjà sur le même domaine au moment de la reconnexion, l’assistant propose de l’archiver et d’en créer une neuve, sans toucher à votre audience. Tout est-il bien connecté et synchronisé ? rassemble tous les signaux de connexion au même endroit.
L’activité récente se synchronise mais l’historique stagne (ou l’inverse)
Boost et Backfill s’exécutent chacun dans leur propre groupe cron : un hébergeur qui ne lance que le groupe par défaut de Magento ne démarre donc que la moitié du moteur. Demandez à votre hébergeur de confirmer que le cron de Magento exécute tous les groupes ; le Cron Monitor montre l’état de chaque groupe, vous voyez donc exactement lequel attend. Comment s’exécute le moteur de synchronisation explique les deux voies.
« Mon audience est bien plus grande que ma liste d’abonnés » (nombre de contacts et facturation)
Le volume de contacts est borné par conception et prévisualisé avant toute synchronisation : le Setup Wizard affiche une estimation pour la fenêtre d’historique que vous choisissez (3, 12, 24, 36 ou 48 mois, ou tout l’historique), une fenêtre plus courte borne donc le nombre. Sync Customers ne synchronise jamais que les clients ayant passé une commande, jamais toute votre base de clients, et Default Subscription Status for Synced Customers décide s’ils arrivent comme abonnés ou non-abonnés. Si l’audience est déjà plus grande que souhaité, archivez des contacts dans Mailchimp : les contacts archivés ne sont pas facturés et reviennent d’eux-mêmes si l’acheteur commande à nouveau. Comment fonctionne la synchronisation explique exactement qui se synchronise et quand.
Une règle promotionnelle est bloquée sur « Action needed »
Vérifiez d’abord que Sync Promo Rules & Codes et Enable Ecommerce Sync sont tous deux sur Yes (Configuration → Ecommerce Sync). Quand Mailchimp décline une règle (remise nulle, dates manquantes, nom manquant), seule cette règle attend : ouvrez l’onglet Entity Queue, filtrez la colonne Status sur « Action needed » et lisez le Status Message pour connaître la raison exacte. Corrigez la Cart Price Rule dans Magento, puis cliquez sur le lien Retry de la ligne : réenregistrer la règle ne suffit pas à relancer la ligne. Tout le reste continue de se synchroniser pendant ce temps. Garder un œil sur votre synchronisation montre comment lire la file.
Un produit affiche « Not supported » dans l’Entity Queue
Ce statut ambre n’apparaît que pour un produit de type personnalisé (une carte cadeau Adobe Commerce ou un type issu d’une extension tierce) auquel il manque son SKU ou son nom : rien n’a été envoyé, et le Status Message nomme le type de produit. Les produits de type personnalisé dotés d’un SKU et d’un nom se synchronisent automatiquement avec une charge utile au mieux des données disponibles, consignée dans l’API Log sous generic_type_fallback. Ajoutez le SKU ou le nom manquant, puis utilisez le Retry de la ligne dans l’Entity Queue (ou lancez Resync All Data depuis Manage Connection, dans l’onglet Manage) ; réenregistrer le produit ne suffit pas à débloquer la ligne. Une commande contenant ce produit se place en « Action needed » en nommant ses SKU ; une fois le produit corrigé synchronisé, utilisez Retry sur la ligne de la commande. Resynchronisation et outils en ligne de commande donne les détails.
Toujours bloqué ?
Ouvrez le Queue Monitor, trouvez l’enregistrement qui ne se synchronise pas et lisez l’erreur Mailchimp complète ; elle nomme généralement la solution. Si vous restez bloqué, le support ebizmarts est à un e-mail de vous : joignez votre version de Magento, la version de votre base de données, la version de l’extension et une capture d’écran de l’erreur.