Mailchimp
Extension payante. Chaque soumission consentie inscrit ou met à jour un membre d’une audience Mailchimp.
Ce document décrit ce que le module garantit et ce qu’il refuse. Le guide utilisateur en donne la version courte, dans la section « Inscrire à une audience Mailchimp ».
Sans consentement, rien ne part — pas même le contact
C’est la différence avec HubSpot et ActiveCampaign, et elle n’est pas un durcissement arbitraire.
Ces deux-là sont des CRM : la fiche y est un acte de gestion, distinct de la liste de diffusion. Le contact y part donc toujours — quelqu’un a écrit au site — et seule l’inscription attend un accord.
Mailchimp est la liste de diffusion. Y inscrire quelqu’un, c’est l’inscrire : il n’y a pas de fiche de gestion à poser d’abord. Un module qui enverrait « seulement le membre » sans consentement serait un export silencieux de contacts vers une plateforme d’envoi.
Trois choses sont donc requises de même rang : une audience, un champ d’adresse, et un champ de consentement. Tant que les trois ne sont pas réglés, aucune soumission ne part, et le panneau le dit.
Sans case cochée par la personne, rien n’est même programmé : il n’y a pas de ligne d’attente, pas de tâche, pas de trace. Il n’y a rien à envoyer.
Le consentement se lit de deux façons, et c’est là qu’on s’est trompé
Le champ Consentement du cœur enregistre {accepted, text, at} : la mention
exacte acceptée, et la date. Seul ce champ convient — une case à cocher ordinaire
n’enregistre qu’un « oui », et un « oui » sans la mention qu’il approuvait ne
démontre rien. Pour une inscription à une liste de diffusion, c’est précisément ce
qu’on vous demandera de produire.
Cette valeur a deux formes. En mémoire, juste après la soumission, c’est un tableau. Relue depuis la base, c’est une chaîne JSON : le dépôt sérialise les valeurs composites.
Trois modules lisaient accepted après avoir vérifié que la valeur était un
tableau, et retombaient sinon sur « une valeur non vide vaut oui ». Sur la forme
relue, {"accepted":false,…} est une chaîne non vide — un refus se lisait comme
un accord. Deux de ces modules ne lisaient le consentement qu’à la soumission et
n’étaient pas atteints ; celui-ci le relit à l’envoi, et l’a été.
La lecture est désormais partagée par les trois, en un seul endroit qui connaît les deux formes. Sur cette question, l’inconnu vaut non.
pending par défaut : le double opt-in
pending fait écrire Mailchimp à la personne, qui confirme en cliquant. C’est la
valeur par défaut et celle que l’écran recommande.
subscribed saute cette confirmation. Ce n’est pas interdit — le module enregistre
justement la preuve qui le permettrait —, mais c’est au responsable du traitement
d’en répondre, et l’écran l’écrit avant de laisser choisir : sans confirmation,
personne ne vérifie l’adresse, une faute de frappe inscrit un inconnu, et le
consentement qu’on détient nomme quelqu’un d’autre.
L’écran de connexion montre le nombre de membres en attente de confirmation. C’est le chiffre qu’on vient chercher quand on doute du double opt-in : un nombre qui ne descend jamais dit que les courriels de confirmation n’arrivent pas — une panne qu’on ne remarque pas autrement, parce que tout a l’air de fonctionner de ce côté-ci.
status_if_new, et non status
C’est le détail qui empêche le module de faire du mal.
status imposerait le statut à chaque envoi : une personne qui s’est désabonnée se
retrouverait réinscrite à la soumission suivante d’un formulaire qu’elle a rempli
autrefois — ou par un simple clic sur « Renvoyer » dans l’administration.
status_if_new ne vaut qu’à la création. Un membre existant garde le statut qu’il a
choisi, et le module se contente de mettre à jour ses champs.
Mailchimp refuse de réinscrire qui s’est désabonné
Une personne désabonnée, en rebond ou ayant signalé un abus se voit répondre 400
avec un message qui le dit. Seule elle peut revenir, depuis un formulaire de
Mailchimp.
Ce refus est définitif : le rejouer trois fois ne le contournerait pas, mais insisterait. L’écran de la soumission le distingue d’une erreur de réglage et l’explique — et il n’y propose pas de bouton de renvoi, parce qu’il n’y a rien à renvoyer.
L’empreinte de l’adresse n’est jamais conservée
Mailchimp désigne un membre par le MD5 de son adresse en minuscules. Ce n’est pas un choix du module, c’est l’API — et ce n’est pas un identifiant anodin : étant donné une adresse, l’empreinte se vérifie en une seconde. C’est une adresse déguisée.
Elle est donc calculée au moment de l’appel et jamais écrite : ni dans la table
de suivi, ni dans le journal des envois, où l’adresse appelée est réduite à
lists/members — sans l’empreinte, et sans l’identifiant de l’audience.
Effacer une soumission emporte sa ligne de suivi et son journal. Mais une empreinte conservée aurait survécu dans les sauvegardes et les exports, et elle s’y serait lue comme une donnée technique anodine alors qu’elle désigne une personne.
Ce qui est gardé à la place est le web_id, l’identifiant numérique que Mailchimp
rend avec le membre : il ouvre sa fiche et ne dit rien de personne.
Les champs de fusion appartiennent à l’audience
Pas au compte. FNAME existe presque partout, MMERGE7 nulle part ailleurs.
Les proposer depuis le compte entier ferait associer une balise absente de l’audience visée — et une balise inconnue fait refuser l’inscription entière, pas seulement le champ. L’écran les lit donc pour l’audience choisie, et le réglage borne les balises au format de Mailchimp : majuscules, dix caractères au plus.
EMAIL ne s’associe pas : l’adresse a son propre réglage, et l’associer une seconde
fois en enverrait deux dont une qui ne sert pas à désigner le membre.
Une valeur vide n’est pas envoyée : un champ de fusion envoyé vide écrase celui du membre, et une seconde soumission sans prénom effacerait celui que la première avait posé.
Le jeton n’expire pas, et il n’y a rien à rafraîchir
Mailchimp rend expires_in: 0 et aucun jeton de rafraîchissement. C’est contraire à
l’habitude des autres intégrations : il n’y a pas de cycle à tenir, et en échange un
secret qui vaut aussi longtemps que personne ne le révoque.
Il est donc chiffré au repos, avec une clé propre à cette intégration. Et la déconnexion le révoque explicitement chez Mailchimp — l’effacer ici ne suffirait pas. Si cette révocation échoue, l’écran demande d’aller retirer l’application côté Mailchimp, parce que sinon l’accès reste vivant chez un tiers, sans date de fin.
L’adresse de l’API arrive par le réseau
login.mailchimp.com porte l’autorisation ; l’API vit sur le centre de données
du compte — us19.api.mailchimp.com —, obtenu par un second appel après l’échange,
sur un point d’entrée prévu pour cela.
Cette adresse vient donc d’une réponse réseau, et c’est elle qu’on appellera avec un
jeton. Elle est confrontée au suffixe .api.mailchimp.com et au schéma https — le
point initial étant ce qui sépare un centre de données de Mailchimp d’un
attaquant-api.mailchimp.com.
Un échange qui rendrait un jeton sans racine admissible est traité comme un échec : mieux vaut refuser la connexion que l’enregistrer vers nulle part.
Ce qui n’est pas tenté, et ce qui est rejoué
Rien n’est programmé sans consentement, sans audience, sans champ d’adresse, sans connexion, ou si la condition du formulaire n’est pas remplie. Une soumission marquée indésirable ne part pas. Une adresse malformée est un refus définitif écrit avant tout appel.
Les refus définitifs ne sont pas rejoués : audience disparue, balise inconnue, refus
de réinscription. Les 429 et les 5xx le sont, à 1, 5 puis 30 minutes.
Un étiquetage en échec ne reprend pas une inscription acquise. La personne est inscrite, et le motif est écrit à côté.
Une panne Mailchimp ne bloque jamais la soumission. Elle est enregistrée, confirmée au visiteur et notifiée par courriel avant que ce module ne soit sollicité.
Renvoyer ne réinscrit personne
Le bouton de renvoi rejoue le PUT avec status_if_new : un membre existant garde
le statut qu’il a choisi. Un renvoi met donc ses champs à jour, et ne peut ni le
réinscrire après un désabonnement, ni le faire sortir d’une attente de confirmation.
Il n’apparaît pas sur une soumission sans consentement, puisqu’il n’y a pas de ligne.
Schéma
slf_mailchimp_members : une ligne par soumission inscrite — et aucune pour les
autres — avec l’audience, le web_id, le statut rendu par Mailchimp, l’étiquetage,
l’état, le motif du dernier problème et le nombre de tentatives.
Il n’y a pas de colonne de consentement : elle n’aurait eu qu’une valeur possible, et la porter aurait laissé croire qu’il existe un état où elle vaut zéro.
La connexion vit dans une option : l’identifiant client et la racine d’API en clair — ce ne sont pas des secrets, et la racine est la première chose à vérifier quand rien ne part — le jeton et le secret chiffrés.
Ce que la V1 ne fait pas
Pas de campagne, pas de segment, pas de commerce, pas de lecture d’audience, pas de suppression de membre, pas de synchronisation en sens inverse.
Et pas de gestion des désabonnements : le désabonnement appartient à Mailchimp et à la personne. Un formulaire ne doit pas pouvoir le défaire — ni, d’ailleurs, le provoquer à sa place.