ActiveCampaign

Extension payante. Chaque soumission crée ou met à jour un contact. L’inscription à une liste et l’application d’étiquettes ne partent qu’avec un consentement donné par la personne.

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 « Envoyer les réponses vers ActiveCampaign ».

Une étiquette n’est pas une étiquette

C’est la différence qui commande tout le module, et elle mérite d’être dite avant le reste.

Chez HubSpot, une étiquette est une valeur sur une fiche de CRM : elle n’envoie rien à personne. Le module HubSpot laisse donc les étiquettes partir avec le contact, et ne demande un consentement que pour la liste.

Chez ActiveCampaign, appliquer une étiquette déclenche couramment une automatisation — c’est le mécanisme que la plateforme met en avant pour démarrer une séquence de courriels. Une étiquette y est donc un acte marketing au même titre qu’une inscription.

Le consentement commande ici les deux. Ce n’est pas une inconséquence entre les deux modules : c’est la même règle appliquée à deux services qui ne font pas la même chose du même mot.

Le contact, lui, part dans tous les cas : quelqu’un a écrit au site, et c’est l’endroit où cela se note.

Le consentement est un champ du formulaire, et il est figé

Pas une case cochée en administration : une case cochée par l’exploitant dirait « ces soumissions consentent », ce qui n’est pas un consentement mais une affirmation à leur place.

Le réglage désigne quel champ porte la case, et seul le champ Consentement du cœur est acceptable : lui seul enregistre avec la soumission le texte exact accepté et l’horodatage. Une case à cocher ordinaire n’enregistre qu’un « oui » — et un « oui » sans la mention qu’il approuvait ne démontre rien.

La décision est écrite une fois, dans la ligne de suivi, à l’arrivée de la soumission. Rien ne la relit ensuite. Le relire à l’envoi la ferait dépendre de ce qu’un administrateur aura coché entre-temps dans l’écran de la soumission : autrement dit, un consentement pourrait être fabriqué après coup, par quelqu’un d’autre, sans que rien ne le distingue du vrai.

Conséquence directe, tenue par un test : cocher la case après la soumission n’inscrit personne, et un renvoi rejoue la soumission avec le consentement qu’elle portait.

Sans champ désigné, il n’y a aucun état où le module suppose un accord.

sync est un vrai upsert, et c’est rare dans cette série

POST /contact/sync crée le contact ou met à jour celui qui porte la même adresse.

Google Sheets n’a pas d’équivalent, Pipedrive non plus — pour eux, l’idempotence devait être construite localement. Ici le service la fournit, et elle couvre le cas qu’aucun garde local ne voit : la requête aboutit chez ActiveCampaign, la réponse se perd en route, la tâche est rejouée.

La clé unique et la prise de ligne restent, pour le cas courant — deux tâches planifiées pour la même soumission. Elles servent moins à éviter un doublon de contact qu’à éviter une seconde inscription et un second étiquetage : chez ActiveCampaign, les deux relancent les automatisations qui s’y branchent.

Seules les propriétés envoyées sont écrites

sync n’efface pas ce qu’on ne lui donne pas — c’est l’inverse de HubSpot et de Pipedrive, où une propriété envoyée vide efface celle de la fiche.

Les valeurs vides sont retirées quand même : envoyer une chaîne vide écraserait un champ renseigné par un autre canal.

Les champs fichier, signature, paiement et mot de passe ne partent jamais, même associés de force. Une plateforme d’automatisation recopie ces valeurs dans des courriels, et une adresse de téléversement y deviendrait un accès permanent envoyé par courrier.

Les identifiants sont des nombres, et cela se vérifie

Listes, étiquettes et champs personnalisés sont désignés par des nombres. Une valeur d’une autre forme deviendrait 0 au transtypage — qu’ActiveCampaign lirait comme un identifiant, pas comme une absence. Elle est donc écartée à l’enregistrement du réglage.

Les champs sont proposés à l’écran plutôt que saisis : un identifiant faux n’échoue pas bruyamment, ActiveCampaign ignore la valeur et enregistre le reste.

Une subtilité de PHP mérite d’être notée ici, parce qu’elle a produit une différence réelle : une clé de tableau numérique redevient un entier dès l’écriture du réglage, si bien que '12' et 12 désignent la même entrée. La conversion est donc refaite explicitement à l’envoi, pour que ce qui part ait toujours la même forme.

L’adresse de l’API est saisie, donc contrôlée

ActiveCampaign ne publie pas une adresse d’API unique : chaque compte a la sienne — monentreprise.api-us1.com —, qu’on lit dans ses réglages de développeur et qu’on recopie dans l’écran.

Une adresse saisie est une adresse à vérifier. Sans contrôle, une faute de frappe ou un collage malheureux enverrait les soumissions et la clé d’API à un hôte quelconque. Le contrôle porte donc sur le schéma — https seulement — et sur deux suffixes : .api-us1.com et .activehosted.com.

Le point initial des suffixes est volontaire. Sans lui, attaquant-api-us1.com passerait — c’est la faute classique de ce genre de liste, et elle ne se voit pas à la lecture.

Une adresse refusée n’est pas enregistrée : le faire produirait une connexion qui a l’air réglée et n’appelle jamais. Le message dit ce qui est admis, parce que c’est la seule information qui permette de corriger.

Une clé d’API n’expire pas

C’est ce qui la rend plus dangereuse qu’un jeton d’accès : elle ouvre tout le compte — contacts, listes, automatisations, campagnes — aussi longtemps que personne ne la révoque.

Elle est donc chiffrée au repos, avec une clé propre à cette intégration, et jamais réaffichée — ni en entier, ni tronquée. Le plan proposait de suivre Brevo, dont la clé vit en clair dans les réglages généraux ; c’est le dernier module à faire ainsi, et ce n’était pas une raison pour en ajouter un.

Déconnecter ne révoque pas. Effacer la clé ici ne la rend pas inutilisable : elle ne se révoque que depuis le compte qui l’a émise. L’écran le dit plutôt que de laisser croire qu’effacer suffit.

La clé voyage dans un en-tête Api-Token, jamais dans la chaîne de requête : une adresse se retrouve dans les journaux du serveur, dans ceux de l’intermédiaire et dans l’historique.

Ce qui n’est pas tenté, et ce qui est rejoué

Rien n’est programmé si la connexion manque, si le champ d’adresse n’est pas désigné, ou si la condition du formulaire n’est pas remplie. Une soumission marquée indésirable ne part pas, même si la tâche était déjà en file. Une adresse absente ou malformée est un refus définitif écrit avant tout appel.

Les refus définitifs ne sont pas rejoués — y compris le 403. Ailleurs il peut signaler un quota momentané ; ici il signale une clé refusée, et une clé ne redevient pas valable toute seule. La rejouer trois fois repousserait de trente minutes le moment où l’écran le dit.

Les 429 et les 5xx le sont, à 1, 5 puis 30 minutes.

Ce qui suit le contact n’annule jamais le contact. Une inscription ou un étiquetage en échec laisse l’envoi réussi : la fiche est chez le client, et le motif est écrit à côté. Rejouer tout l’envoi pour une étiquette rejouerait aussi l’inscription — et une seconde inscription relance les automatisations.

Une panne ActiveCampaign 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 met à jour, et réapplique

Le bouton de renvoi met le même contact à jour — sync le retrouve par son adresse — et ne crée pas de doublon.

En revanche, si le consentement était donné, la liste et les étiquettes repartent, ce qui relance les automatisations qui s’y branchent. L’écran le dit avant le clic.

Le consentement, lui, n’est pas touché : un renvoi ne peut pas en inventer un.

Ce que le journal ne contient pas

Ni la requête, ni la réponse, ni la clé. Les deux premières portent les valeurs de la soumission : les consigner ferait du journal une seconde copie, qui s’en irait dans les sauvegardes et les exports — où elle se lirait comme une trace technique alors qu’elle décrit une personne. Restent le code HTTP et le motif.

Schéma

slf_activecampaign_contacts : une ligne par soumission, avec l’identifiant du contact, le consentement figé, l’inscription et l’étiquetage effectifs, l’état, le motif du dernier problème et le nombre de tentatives. Elle disparaît avec la soumission ; le contact chez ActiveCampaign, lui, reste.

La connexion vit dans une option : l’adresse en clair — ce n’est pas un secret, et c’est la première chose à vérifier quand rien ne part — et la clé chiffrée.

Ce que la V1 ne fait pas

Pas de campagne, pas d’automatisation créée ou déclenchée directement, pas d’affaire, pas de lecture de contacts, pas de suppression, pas de synchronisation en sens inverse. Le flux va du site vers la plateforme.

Pas de désinscription non plus : retirer quelqu’un d’une liste depuis un formulaire demanderait de vérifier que c’est bien lui qui le demande, et cette vérification n’appartient pas à ce module.