Comment les équipes marketing peuvent déployer des applications créées par l’IA sans exposer les données des abonnés

« Une personne d’une équipe marketing veut créer un site web. Elle n’est pas ingénieure et n’a probablement que peu ou pas de connaissances en sécurité », a expliqué le chercheur en sécurité Joel Margolis à Wired. Le même reportage indique que l’entreprise de sécurité RedAccess a trouvé plus de 5 000 applications créées par vibe coding pratiquement dépourvues de sécurité ou d’authentification, dont environ 40 % exposaient des données sensibles. Wired n’a pas pu confirmer que les données personnelles ou professionnelles examinées étaient authentiques.

Les applications créées par l’IA pour les équipes marketing présentent une variante particulière de ce problème. Les outils utiles à construire (créateur de segments, tableau de bord de campagnes, analyseur A/B, synchronisation d’audiences) sont ceux qui sont connectés à la liste d’abonnés, et souvent aussi au compte publicitaire.

En bref

• Accordez à chaque clé API de plateforme email et jeton de compte publicitaire les seuls droits nécessaires à l’outil, et conservez-les dans le code serveur. La Marketing API de Mailchimp ne propose pas de type de clé plus restreint : une tâche Mailchimp en lecture seule reçoit donc un export limité aux données nécessaires plutôt qu’une clé.
• La plateforme email reste la source de référence pour le statut d’abonnement. L’outil ne réabonne jamais les personnes désinscrites, transmet les demandes de désabonnement à la plateforme et inclut un lien de désabonnement fonctionnel dans chaque email marketing qu’il envoie lui-même.
• Un import d’audience personnalisée haché contient toujours des données personnelles : décidez des informations transmises aux plateformes publicitaires et aux services d’IA avant tout envoi, et répercutez chaque désabonnement dans l’audience publicitaire.
• Le RGPD encadre la conservation et l’utilisation de la liste (notification des violations, droit absolu d’opposition au marketing) ; ePrivacy/PECR, CAN-SPAM ou CASL encadrent l’envoi des emails, même depuis un outil interne.

Les erreurs de déploiement qui exposent les données des abonnés ou compromettent le consentement

Un outil marketing créé par l’IA qui gère mal la liste pose généralement l’un de ces deux problèmes : la liste est divulguée (par une clé, un lien public ou un transfert), ou elle sert à contacter des personnes qui ont refusé. Un jeton publicitaire doté de droits de gestion ajoute un risque distinct : des dépenses sur le compte publicitaire de l’entreprise.

L’outil de programmation par IA qui a créé l’application peut réaliser la plupart de ces corrections sur demande. Adaptez chaque prompt ci-dessous à votre situation et conservez ceux que vous utilisez dans un fichier de règles que l’outil d’IA lit à chaque session. Le fait que l’IA annonce une modification ne la prouve pas ; c’est le rôle de l’étape Vérifier : sous chaque prompt. Demandez-lui de signaler ses incertitudes et ne collez jamais une clé active ou un export d’abonnés dans la conversation.

Remplacer la clé email à accès complet par la plus restreinte possible

Un outil de segmentation qui affiche uniquement des effectifs n’a pas besoin d’une clé capable d’exporter la liste ou d’envoyer une campagne. Pourtant, la clé la plus large de chacune des plateformes ci-dessous permet les deux. Son emplacement compte aussi : le code du navigateur doit disposer de la valeur de la clé pour effectuer son appel, donc toute personne ouvrant la page peut la lire (Mailchimp ne prend pas en charge l’utilisation de son API côté client).

Chaque ligne repose sur la documentation de la plateforme : page d’aide de Mailchimp sur les clés API, permissions des clés API SendGrid, guide d’authentification Klaviyo et documentation des clés API Mailgun. Les permissions de Listmonk sont décrites dans sa section plus bas.

L’outil reçoit la clé la plus restreinte compatible avec sa tâche, ou aucune clé. Sur Mailchimp, les outils de reporting intégrés ou un export limité aux champs nécessaires, réalisé par le titulaire du compte, conviennent mieux à une tâche en lecture seule (rapport, effectif d’un segment). Cela demande du temps humain et les données ne sont pas plus récentes que l’export ; les modifications et envois restent dans Mailchimp ou sont confiés à l’informatique. Sur d’autres plateformes, comme ActiveCampaign ou Brevo, cherchez d’abord une option de clé restreinte.

La clé n’est ensuite utilisée que par le code serveur (le back-end propre à l’outil, jamais téléchargé par le navigateur) et stockée dans une variable d’environnement : une valeur fournie à l’application au démarrage par le serveur, hors du code et du dépôt.

Repère chaque clé API, jeton d’accès, mot de passe ou secret de ce projet pour notre plateforme email (Mailchimp, Klaviyo, SendGrid, Mailgun, Listmonk ou autre) et toute plateforme publicitaire (Meta, Google Ads, LinkedIn ou autre). Utilise un scanner de secrets local ou une méthode approuvée par l’informatique pour vérifier le code, les fichiers d’environnement et l’historique du dépôt. Ne transmets jamais de secrets bruts, de contenu de fichiers d’environnement ou d’historique contenant des identifiants à un service d’IA externe. Ne donne à l’IA que des résultats expurgés, avec les emplacements et types d’identifiants. Pour chacun, indique :

- le fichier et la ligne

- si la valeur est inscrite dans le code ou lue dans une variable d’environnement

- si le code qui l’utilise s’exécute sur le serveur ou dans le navigateur

N’affiche que les quatre premiers caractères de chaque valeur. N’affiche jamais une clé ou un jeton complet.

Traite en priorité absolue tout identifiant permettant d’envoyer des emails, de modifier les abonnés ou de gérer un compte publicitaire.

Déplace ensuite chaque appel exigeant une clé API privée ou un jeton d’accès vers le code serveur, qui doit lire ses identifiants dans une variable d’environnement réservée au serveur. Ne garde dans le navigateur que les appels publics côté client documentés ; retire les clés privées exposées du code et exclus du dépôt les fichiers contenant de vrais secrets. Décris précisément les changements et signale tes incertitudes sans deviner.

Remarque : Supprimer une clé collée dans la conversation ou le code ne la rend pas confidentielle à nouveau. Révoquez-la (désactivez-la dans les paramètres de la plateforme pour qu’elle cesse de fonctionner) et créez-en une autre.

Vérifier : ouvrez l’outil, appuyez sur F12, sélectionnez l’onglet Réseau et utilisez l’outil comme le fera l’équipe en lisant le domaine de chaque requête. Un appel direct du navigateur à l’API privée d’une plateforme email est un signal d’alerte, mais sa destination ne prouve pas à elle seule l’exposition d’un secret. Vérifiez les en-têtes et le code sans copier d’identifiants privés dans une conversation avec l’IA. Les requêtes de SDK publics côté client peuvent légitimement utiliser des identifiants publics. Sur Klaviyo, les appels à a.klaviyo.com/client/ utilisent une clé publique et ont leur place dans le navigateur ; ceux vers a.klaviyo.com/api/ doivent être examinés, car ils exigent normalement une authentification par clé privée. Confirmez si un identifiant privé a réellement été transmis.

Une personne doit gérer la suite : créer la clé restreinte depuis un compte qui ne dépend pas d’une seule personne (Mailchimp supprime les clés d’un utilisateur dont l’accès est révoqué), la nommer d’après l’outil (Mailchimp recommande une clé par intégration) et demander à l’informatique de la stocker correctement. Pour une rotation planifiée, basculez l’outil sur la nouvelle clé avant de révoquer l’ancienne, car une clé Mailchimp révoquée ne peut pas être réactivée. Une clé compromise doit être révoquée immédiatement, puis remplacée. Prévoyez aussi l’expiration : les clés API Mailchimp générées à partir du 22 juin 2026 expirent un an après leur création.

N’accorder au jeton publicitaire que les permissions utiles à l’outil

Je considère le jeton publicitaire comme l’identifiant aux conséquences les plus importantes pour un outil marketing, car il est lié aux dépenses. Un jeton Meta avec des droits de gestion peut créer, modifier ou suspendre des campagnes facturées au compte de l’entreprise et consulter leurs dépenses et performances.

Ce jeton ne restitue pas la liste d’abonnés importée dans une audience personnalisée. Le guide des audiences personnalisées de Meta utilise des valeurs hachées en SHA-256 (transformation à sens unique de chaque adresse, comparée aux données de la plateforme) pour ajouter et retirer des personnes ; aucun point de terminaison documenté ne renvoie une liste lisible depuis une audience existante.

La référence des permissions de Meta décrit chaque permission et invite les développeurs à ne choisir que celles nécessaires. Chaque outil reçoit son propre jeton d’un utilisateur système, terme de Meta pour un compte logiciel dans Business Manager, affecté uniquement au compte publicitaire de cet outil. N’utilisez pas le jeton de connexion personnel du créateur ; conservez le jeton système sur le serveur, comme la clé email. Le même inventaire s’applique aux accès Google Ads et LinkedIn.

Répertorie tous les appels de cet outil à la Marketing API de Meta, à Google Ads ou à toute autre plateforme publicitaire, y compris via des bibliothèques ou SDK. Pour chaque appel, indique :

- le fichier et la ligne

- le point de terminaison ou la méthode du SDK

- une catégorie : REPORT (lit indicateurs ou dépenses), MANAGE (crée ou modifie campagnes, publicités, budgets ou audiences) ou LEADS (lit les réponses des formulaires de prospects)

- la permission requise pour cette catégorie sur la plateforme

Signale les jetons partagés entre plusieurs outils et tout code qui transmet un jeton au navigateur. N’affiche aucune valeur de jeton. Si tu ne peux pas déterminer la catégorie d’un appel, indique-le.

Vérifier : examinez le jeton du tableau de bord dans l’outil de débogage Meta, qui indique ses permissions, puis comparez-les aux catégories du prompt. Un tableau de reporting doit avoir ads_read et aucun droit de gestion du compte ; une catégorie MANAGE ou LEADS est une anomalie pour cet outil. Confirmez ensuite dans les paramètres professionnels qu’il utilise son jeton d’utilisateur système, pas le jeton personnel du créateur.

Fermer l’accès public et réserver les fiches d’abonnés aux administrateurs de liste

Toute personne trouvant son adresse peut ouvrir une application hébergée par l’outil d’IA. Certaines applications examinées par RedAccess ne présentaient que des obstacles dérisoires, comme l’obligation de se connecter avec n’importe quelle adresse email, rapporte Wired. Cet hébergement convient à une démonstration avec des adresses fictives, ce à quoi servent l’hébergement gratuit et les tunnels.

L’autre question est ce que chaque personne voit après connexion. Un tableau de campagnes affiche des chiffres par campagne : taux d’ouverture et de clic, résultats A/B et tailles de segments. Les fiches sous-jacentes, avec adresse email, preuves de consentement et historique d’engagement, sont des données personnelles.

Des agrégats correctement anonymisés ne sont généralement pas des données personnelles, mais de petits segments ou des ventilations détaillées peuvent encore identifier des personnes. Même anonymes, les chiffres peuvent révéler des informations concurrentielles. Un analyseur A/B stockant les ouvertures et clics individuels détient aussi des données personnelles. L’équipe voit les agrégats ; seuls les gestionnaires de liste voient les fiches, et le serveur impose cette règle à chaque requête.

Répertorie chaque champ contenant des données personnelles d’abonnés dans la base, les écrans, exports et réponses API de cette application : email, nom, téléphone, adresse postale, adresse IP, localisation, statut d’abonnement, source, date et heure du consentement, date d’inscription, désabonnement, ouvertures et clics individuels. Indique les écrans et exports qui affichent chaque champ. Signale les incertitudes sans deviner.

Ajoute ensuite deux rôles, tirés du compte connecté et contrôlés sur le serveur pour chaque page, export et route API :

- administrateur de liste : peut consulter les fiches d’abonnés et lancer des exports

- marketeur : voit uniquement les chiffres par campagne, effectifs de segments et résultats A/B, sans fiches individuelles ni exports

Refuse tout autre accès avec une réponse « accès refusé » (403). Indique le contrôle qui protège chaque page et route.

Le chiffrement sur disque des données stockées relève de l’informatique ; l’outil d’IA ne peut pas le confirmer en lisant le code.

Vérifier : créez un compte de test avec le rôle marketeur. Connecté avec ce compte, ouvrez le tableau de campagnes (il se charge), puis la liste d’abonnés et l’export (tous deux refusent l’accès). Ouvrez ensuite l’adresse de l’outil depuis un téléphone en données mobiles, sans connexion : rien ne se charge ou la page de connexion de l’entreprise s’affiche.

Confier les désabonnements et preuves de consentement à la plateforme email

Un outil qui conserve sa propre copie de la liste et la réinjecte par synchronisation bidirectionnelle ou réimport de l’export du mois dernier peut réabonner une personne désinscrite et perdre l’origine, la date et les modalités d’inscription. Il ne montre généralement aucun signe avant la campagne suivante, lorsque les règles d’envoi s’appliquent. Quatre règles l’évitent :

1. La plateforme email est la source de référence pour le statut d’abonnement. L’outil lit ce statut et ne réabonne ni n’écrase jamais un abonné existant. Il peut transmettre une demande explicite de désabonnement via la procédure prévue par la plateforme.
2. Aucun import groupé ou synchronisation ne remplace les fiches existantes ni leurs informations d’abonnement et de consentement. Un outil contrôlé peut modifier des champs expressément approuvés, comme les étiquettes, sans changer le statut. Les nouvelles inscriptions passent par le formulaire ou la procédure d’import de la plateforme et ses règles d’opt-in. Après validation, le formulaire propre à l’outil peut ajouter de nouveaux abonnés avec source, date, heure et formulaire, mais jamais réabonner un contact existant ou écraser ses informations d’abonnement ou de consentement.
3. Chaque envoi ou export lit le statut actuel dans la plateforme, pas dans une copie locale. Les exports excluent les contacts désinscrits ou supprimés des envois, ou les signalent dans une liste de non-envoi jamais utilisée pour envoyer.
4. Les champs de consentement (source, date et heure, formulaire ou méthode) accompagnent intégralement chaque fiche copiée ; sinon l’outil ne les copie pas et ne prétend pas les détenir.

Répertorie chaque écriture de cet outil dans la plateforme email ou une copie de la liste : appels API créant ou modifiant des abonnés, imports, synchronisations et exports de fichiers. Pour chacun, indique s’il peut :

- changer le statut d’abonnement d’un abonné existant

- écraser des fiches d’abonnés existantes

- inclure des contacts désinscrits ou exclus des envois

Pour chaque parcours envoyant des emails ou exportant une liste destinée à l’envoi, indique la source du statut d’abonnement : la plateforme à cet instant, ou la copie propre à l’outil.

Modifie ensuite l’outil pour qu’il ne réabonne jamais un contact existant et n’écrase jamais son statut, sauf pour transmettre une demande explicite de désabonnement par la procédure prévue. Il ne doit jamais remplacer intégralement les fiches existantes ; il doit lire le statut dans la plateforme immédiatement avant chaque envoi ou export et conserver source, date, heure et formulaire du consentement avec chaque fiche copiée. Décris les modifications et signale tes incertitudes.

Remarque : Un ancien export réimporté sur la liste conserve ses anciens statuts. Selon le traitement de l’import par la plateforme et l’outil, une personne désinscrite depuis cet export peut donc être réabonnée.

Vérifier : ajoutez un abonné de test dans la plateforme email, puis désinscrivez-le. Lancez la synchronisation, la segmentation et l’export de l’outil. Le contact doit rester désinscrit dans la plateforme, être absent de l’export ou signalé comme ne devant pas être contacté, et n’apparaître dans aucune liste d’envoi créée par l’outil.

Envoyer via la plateforme email ou créer d’abord le parcours de désabonnement

Un outil de réengagement qui écrit directement à la liste via SMTP ou une API d’emails transactionnels ne bénéficie pas automatiquement du lien de désabonnement, de l’adresse postale et du contrôle des exclusions ajoutés par la plateforme marketing. Son code doit les ajouter. La solution est de laisser la plateforme (ou Listmonk) envoyer, l’outil préparant le segment ou déclenchant la campagne. Un outil qui doit envoyer lui-même devient un outil d’envoi et doit être confié à l’informatique avant lancement, comme expliqué plus loin.

Cet outil doit inclure dans chaque message marketing un lien de désabonnement restant fonctionnel après l’envoi, ainsi que l’identité et l’adresse postale de l’expéditeur en pied de message, selon les délais du tableau juridique ci-dessous. Il lui faut aussi une liste d’exclusion durable, vérifiée avant chaque envoi, avec sauvegardes et procédures de restauration empêchant une ancienne base d’abonnés d’annuler des désabonnements plus récents. CAN-SPAM traite différemment les messages transactionnels.

Pour les gros expéditeurs, un lien en pied d’email peut être insuffisant. Gmail impose aux expéditeurs envoyant au moins 5 000 messages par jour à des comptes Gmail personnels le désabonnement en un clic RFC 8058 pour les messages marketing et d’abonnement. Il faut ajouter les en-têtes List-Unsubscribe et List-Unsubscribe-Post, en plus du lien visible. Le point de terminaison doit traiter une requête POST ; l’ouverture de l’URL par GET ne doit pas désabonner quelqu’un. Faites vérifier ces exigences par l’informatique avant d’envoyer à ce volume.

Ajoute un lien de désabonnement dans chaque message marketing envoyé par cet outil et un point de terminaison pour le traiter.
Si l’outil relève des exigences Gmail pour les expéditeurs en nombre, implémente aussi les en-têtes de désabonnement en un clic RFC 8058, couverts par une signature DKIM valide, avec un point de terminaison POST. Ne désabonne jamais quelqu’un au simple chargement d’une URL. Signale toute incertitude à l’informatique.
Quand le point de terminaison reçoit une demande valide (clic sur un lien, soumission de formulaire ou appel API) :

- ajoute immédiatement l’adresse à une liste d’exclusion stockée séparément des tables d’abonnés

- enregistre l’heure et le canal de la demande

- si notre plateforme email détient la liste, demande-lui aussi de désinscrire l’adresse

Vérifie la liste d’exclusion avant chaque envoi et ignore toute correspondance. Ne retire jamais automatiquement une adresse de cette liste lors d’un import, d’une synchronisation ou d’une restauration. Ne conserve que les informations minimales nécessaires au respect du désabonnement, selon la politique de conservation approuvée ; aucun import ou sync ne doit réintroduire une adresse exclue. Les sauvegardes doivent inclure la liste d’exclusion et la restauration des tables d’abonnés doit la laisser intacte. Ajoute le nom et l’adresse postale de notre expéditeur en pied de chaque message marketing, avec des espaces réservés que je remplirai. Décris les changements et les envois concernés.

Vérifier : ajoutez une adresse de contrôle vous appartenant à une liste de test, envoyez une campagne par l’outil et cliquez sur le lien de désabonnement reçu. L’adresse doit apparaître dans la liste d’exclusion (et être désinscrite de la plateforme si elle détient la liste). Renvoyez à la même liste : cette adresse ne doit rien recevoir.

La personne responsable de la conformité des emails fournit le nom et l’adresse postale de l’expéditeur pour ces espaces réservés.

Décider des données transmises aux plateformes publicitaires et outils d’IA avant tout transfert

Deux parcours de code transmettent par défaut les données des abonnés : la synchronisation d’un segment avec une audience personnalisée Meta ou Google, et les appels transmettant des champs d’abonnés à une API d’IA (pour rédiger des objets ou noter des prospects), à des scripts d’analyse ou à des webhooks.

Meta et Google peuvent rapprocher des audiences clients avec des identifiants hachés en SHA-256. La Data Manager API de Google exige la normalisation et le hachage des emails et téléphones avant transmission ; certains imports depuis l’interface Google Ads peuvent les hacher pendant l’import. Le hachage permet le rapprochement avec un profil, mais ne rend pas la personne anonyme (voir la FAQ).

Pour une nouvelle intégration Google Customer Match, vérifiez l’API d’import prise en charge avant de construire la synchronisation. Depuis le 1er avril 2026, Google restreint les anciennes méthodes d’import Customer Match pour les nouveaux utilisateurs et les oriente vers sa Data Manager API.

Les conditions des audiences de listes clients de Meta exigent que l’annonceur garantisse détenir les droits, autorisations et base juridique nécessaires au partage. La politique Customer Match de Google exige de déclarer ce partage dans la politique de confidentialité et d’obtenir le consentement lorsque la loi l’impose.

Par simplicité, cet outil traite chaque désabonnement comme une demande d’arrêt du rapprochement publicitaire. Il s’agit d’une politique d’entreprise prudente, pas d’une affirmation selon laquelle chaque désabonnement email propre à un canal impose légalement le retrait de toutes les audiences publicitaires.

Le parcours d’import ne doit donc prendre que le segment approuvé par l’entreprise pour le rapprochement publicitaire. L’entreprise doit établir une base juridique adaptée avec son responsable de la protection des données ou son délégué à la protection des données (DPO), s’il en existe un. Les contacts désinscrits ou exclus restent hors de chaque import et le désabonnement déclenche leur retrait par valeur hachée de chaque audience (la section RGPD explique pourquoi).

Tout service d’IA ou d’analyse recevant des données d’abonnés doit être approuvé par l’entreprise. Avant de partager des données personnelles, déterminez si le prestataire agit comme sous-traitant ou responsable de traitement indépendant et mettez en place les garanties contractuelles adaptées, dont un accord de traitement des données si nécessaire.

Audite chaque appel sortant de cet outil : plateformes email et publicitaires (y compris imports d’audience), API d’IA (OpenAI, Anthropic ou autres), outils d’analyse et webhooks. Pour chaque appel, répertorie précisément les champs d’abonnés présents dans le corps de la requête ou l’URL. Indique lesquels pourraient fonctionner avec moins de champs ou sans données d’abonnés. Termine par la liste nominative de tous les services externes afin de les comparer aux prestataires approuvés.

Vérifier : chaque champ d’abonné transmis à un service d’IA ou d’analyse doit être nécessaire à la tâche, et chaque service nommé doit être approuvé par l’entreprise ; sinon, soumettez-le au responsable des contrats fournisseurs.

Pour chaque parcours de cet outil qui importe des contacts dans Meta, Google Ads ou une autre plateforme publicitaire :

- hache les emails et téléphones en SHA-256 sur le serveur avant import, selon les règles de normalisation de chaque plateforme

- importe uniquement les contacts de [segment approuvé par votre entreprise pour le rapprochement publicitaire]

- exclus les contacts désinscrits ou écartés des envois au moment de l’import

- lorsqu’un contact se désinscrit, demande son retrait par valeur hachée de chaque audience dans laquelle il a été importé

- journalise chaque import et retrait avec l’heure, l’audience, le nombre de contacts et l’utilisateur ou la tâche à l’origine de l’opération

Décris les modifications et signale toute incertitude.

Vérifier : désinscrivez un contact de test appartenant à un segment importé. Après la prochaine synchronisation, contrôlez qu’une demande de retrait a été envoyée à chaque audience concernée. Vérifiez que chaque plateforme l’a bien traitée, pas simplement que l’outil l’a journalisée ou soumise. Signalez les retraits échoués ou partiels pour nouvelle tentative et examen informatique.

Ce que l’outil fait de la liste détermine son hébergement

Un outil affichant uniquement des chiffres de campagnes fonctionne sur un serveur contrôlé par l’équipe et accessible seulement via un réseau privé. Un outil affichant des fiches d’abonnés ajoute la connexion d’entreprise, nécessaire aux rôles. Un outil envoyant des emails marketing ou synchronisant des audiences reste dans les fonctions des plateformes ou passe par l’informatique avant utilisation.

Les validations suivent le tableau : les deux lignes de lecture seule exigent que l’administrateur de la plateforme fournisse la clé ; les modifications nécessitent une deuxième lecture ; l’envoi nécessite l’informatique et les imports d’audience une revue de confidentialité.

Un réseau privé empêche l’outil de répondre depuis l’extérieur. Une page de connexion écrite par l’IA reste accessible à tous et dépend de la solidité de son code, ce qui explique les applications trouvées par RedAccess acceptant n’importe quelle adresse email.

Ma règle : commencer par le réseau privé, puis ajouter la connexion d’entreprise lorsque les rôles l’exigent. Une plateforme de déploiement gérée avec connexion et stockage des secrets intégrés convient aussi aux équipes déjà clientes et qui évaluent leurs prestataires.

La partie serveur doit être confiée à l’aide informatique, avec un responsable nommé pour le serveur et les clés. L’outil fonctionne sur un VPS (serveur loué entièrement contrôlé par l’équipe) avec un outil de déploiement comme Coolify ou Dokploy, qui lance l’application depuis son code et conserve ses variables d’environnement, y compris les clés des plateformes.

Le réseau privé est fourni par Tailscale, plus rapide à configurer mais dépendant de son service de coordination (Headscale peut le remplacer), ou par WireGuard, entièrement auto-hébergé. La connexion d’entreprise (SSO avec le compte professionnel) repose sur Authentik ou Keycloak, et un proxy inverse (Caddy ou Nginx Proxy Manager) ajoute HTTPS aux accès exposés au web.

Passer le moteur d’envoi à Listmonk

Plutôt que de restreindre les clés de la plateforme actuelle, l’autre approche retire sa clé en transférant la liste et l’envoi vers un gestionnaire auto-hébergé. Listmonk (v4.0.0 et versions ultérieures) permet un utilisateur API propre à chaque outil, avec un rôle limité aux listes concernées.

Un outil en lecture seule reçoit un accès de consultation à ses listes, sans envoi ; campaigns:send et tx:send (messages transactionnels) sont réservés aux outils d’envoi. Trois permissions particulièrement risquées doivent être exclues des rôles restreints : lists:get_all et lists:manage_all, qui priment sur les rôles par liste, et subscribers:sql_query, dont la documentation des rôles et permissions de Listmonk avertit qu’elle permet d’interroger toutes les listes et tous les abonnés directement dans la base en contournant les permissions individuelles. Examinez aussi subscribers:get_all, campaigns:get_all et campaigns:manage_all avant de qualifier un outil de restreint à certaines listes. N’accordez que les droits nécessaires. Listmonk vise les campagnes plutôt que l’automatisation en plusieurs étapes (quand Listmonk n’est pas adapté) ; Mautic fournit cette automatisation sur un serveur similaire.

Le compromis est un travail continu : l’équipe prend en charge l’authentification du domaine d’envoi (SPF, DKIM et DMARC), le relais SMTP, les mises à jour, sauvegardes et la délivrabilité. Si la liste est petite, que personne ne peut gérer un serveur ou que la réputation d’envoi et les automatisations de la plateforme actuelle sont indispensables, mieux vaut conserver la plateforme avec des clés restreintes.

Dans les deux cas, il faut un serveur sous responsabilité définie, avec outil de déploiement et réseau privé et, pour l’auto-hébergement, Listmonk et un relais SMTP. Notre Linux VPS fournit l’accès root ; Listmonk, Mautic, Tailscale, WireGuard et Authentik s’installent en un clic. L’aide informatique peut ainsi se concentrer sur la configuration et la revue plutôt que l’installation ; les mises à jour restent à la charge de l’équipe.

Les implantations comprennent Francfort et Amsterdam dans l’UE, Londres au Royaume-Uni et plusieurs villes américaines. Le choix détermine où résident l’outil et ses copies de la liste (et la liste elle-même avec Listmonk). Ce lieu éclaire la discussion avec le DPO, sans la remplacer ni rendre à lui seul l’outil conforme.

Consentement et règles antispam pour les emails marketing

Le RGPD pour la liste d’abonnés

Le RGPD n’impose pas le consentement comme base du traitement à des fins de marketing direct : le considérant 47 indique qu’il peut relever d’un intérêt légitime. Si le marketing repose sur le consentement, l’article 7 exige de pouvoir démontrer que chaque personne a consenti et de rendre le retrait aussi simple que l’accord. La source, la date et l’heure du consentement dans la plateforme servent à cela.

La règle plus stricte figure à l’article 21 du RGPD. Quelle que soit la base, une personne peut s’opposer à tout moment au marketing direct et au profilage associé ; ses données ne doivent alors plus être traitées à ces fins. Pour le marketing, aucun test de mise en balance ne s’applique, contrairement à d’autres oppositions. Le choix le plus prudent pour cet outil consiste à étendre une opposition générale à tous les usages marketing de ses données : liste d’envoi, segments et audiences. Un désabonnement propre à un canal peut être plus limité : l’entreprise doit définir ses préférences avec son responsable de la confidentialité et respecter chaque demande selon sa portée.

Une liste divulguée ou modifiée à tort peut constituer une violation de données personnelles. L’article 33 exige de notifier l’autorité de contrôle nationale sans retard injustifié et, si possible, dans les 72 heures suivant la prise de connaissance, sauf s’il est peu probable que la violation engendre un risque pour les personnes. Au Royaume-Uni, le texte équivalent est le UK GDPR, appliqué par l’ICO.

Les règles d’envoi : ePrivacy et PECR, CAN-SPAM et CASL

Les règles ePrivacy de l’UE et PECR du Royaume-Uni exigent le consentement préalable pour les emails marketing aux particuliers, avec un « soft opt-in » limité aux clients existants. Le Royaume-Uni prévoit aussi un soft opt-in caritatif distinct, soumis à des conditions spécifiques ; cet article traite du marketing commercial. La CASL canadienne exige un consentement exprès ou tacite. CAN-SPAM aux États-Unis n’exige pas de consentement préalable, mais un désabonnement fonctionnel respecté sous 10 jours ouvrables, des coordonnées d’expéditeur exactes et une adresse postale dans chaque message.

Le soft opt-in de l’article 13 de la directive ePrivacy concerne les coordonnées obtenues lors d’une vente, utilisées pour vos propres produits similaires, avec un refus gratuit à la collecte et dans chaque message. La version britannique est le règlement 22 des PECR, expliqué dans les recommandations de l’ICO sur le marketing par email. L’article 13 interdit aussi les emails qui masquent l’expéditeur ou ne fournissent aucune adresse valide pour les refus ; le règlement 23 des PECR fait de même au Royaume-Uni.

Les chiffres CAN-SPAM proviennent du guide CAN-SPAM de la FTC, qui précise que les adresses désinscrites ne peuvent être vendues ou transférées, sauf à une entreprise chargée d’aider au respect de CAN-SPAM. Les règles CASL figurent à l’article 6 de la CASL et à l’article 11, et les sanctions dans la présentation de la CASL par ISED.

Foire aux questions

Le RGPD s’applique-t-il à un outil de newsletter que j’ai créé ?

Cela dépend du lieu d’activité de l’entreprise et des personnes dont elle détient les données, pas de la façon dont l’outil a été créé. Selon l’article 3, le RGPD s’applique aux entreprises établies dans l’UE, ainsi qu’à celles établies ailleurs qui proposent des biens ou services aux personnes dans l’UE ou y suivent leur comportement. Le DPO doit déterminer si une entreprise donnée entre dans ce champ.

Que se passe-t-il si notre clé API Klaviyo est divulguée ?

Une clé Full Access permet de modifier la liste ; une clé Read-Only permet seulement de la consulter. Créez une clé de remplacement avec les seules portées utiles (Klaviyo ne permet pas d’ajouter une portée à une clé existante, choisissez-les dès maintenant), révoquez immédiatement la clé divulguée, basculez l’outil sur la nouvelle et recherchez les exports ou modifications non autorisés. Si la liste a pu être consultée, traitez cela comme une possible violation de données personnelles relevant du RGPD.

Une liste d’emails hachée reste-t-elle une donnée personnelle ?

Selon le RGPD, oui si elle peut être reliée à une personne. Le considérant 26 considère les données pseudonymisées attribuables à une personne au moyen d’informations supplémentaires comme des informations sur une personne identifiable. Selon mon interprétation, le rapprochement publicitaire fonctionne précisément pour cette raison : la plateforme calcule le même hachage à partir d’une adresse qu’elle connaît déjà.

Les emails marketing B2B suivent-ils les mêmes règles ?

Pas partout. Selon la FTC, CAN-SPAM ne prévoit aucune exception pour les emails interentreprises. La règle email des PECR couvre les particuliers, et l’ICO confirme la possibilité d’envoyer des emails marketing aux entreprises. Pour les pays de l’UE et le Canada, consultez un juriste.