Emailing : le vrai coût de l'autonomie

Le 14 juillet 2026 a marqué la fin de la période transitoire fixée par la CNIL pour les pixels de suivi dans les emails. Une échéance passée relativement inaperçue en dehors des équipes marketing et conformité, mais qui touche directement tous ceux qui envoient des emails avec un minimum de suivi — associations comprises.

C’est un bon point d’entrée pour une question plus large que je reçois régulièrement : quand un client me demande de reprendre la main sur son emailing plutôt que de dépendre d’un service tiers, la première question qu’il pose est presque toujours la mauvaise — “c’est faisable techniquement ?” Ça l’a toujours été. La vraie question, c’est : qu’est-ce que ça déplace comme responsabilité ?

Le pixel de suivi, ou comment la conformité rattrape vite la technique

Le pixel de suivi — cette image invisible d’un pixel par un pixel, glissée dans le corps d’un email pour détecter son ouverture — existe depuis longtemps. Ce qui a changé, c’est son statut juridique : la CNIL a adopté le 12 mars 2026 une recommandation qui le rattache explicitement à l’article 82 de la loi Informatique et Libertés, au même titre qu’un cookie. Publiée le 14 avril, elle laissait trois mois aux organisations pour se mettre en conformité — délai qui a expiré le 14 juillet.

Le pixel n’est pas interdit — la CNIL n’a jamais eu cette ambition. Ce qui compte, c’est la finalité poursuivie, et la recommandation trace une frontière nette entre deux usages :

• un usage délivrabilité, exempté de consentement, mais sous des conditions de sobriété strictes : seule la date du jour de la dernière ouverture peut être conservée, sans horodatage précis, écrasée à chaque nouvelle consultation — pas d’adresse IP, pas d’information sur l’appareil, pas d’historique. C’est ce qui permet d’identifier une adresse devenue inactive et de nettoyer une base, rien de plus ;
• un usage marketing (mesurer les volumes d’ouverture, personnaliser une relance, ajuster une cadence d’envoi, ou tout ce qui va au-delà de cette simple date), qui bascule sous le régime du consentement préalable, spécifique et distinct de l’acceptation de recevoir les emails eux-mêmes.

C’est ce dernier point qui surprend le plus mes clients B2B : le consentement au pixel marketing est indépendant de la base légale qui autorise l’envoi du message. Une entreprise peut légitimement prospecter un professionnel sur la base de son intérêt légitime, sans que ça lui donne le droit de mesurer individuellement l’ouverture de ses messages à des fins de personnalisation. Ce sont deux autorisations distinctes, à recueillir séparément.

Pour les adresses déjà en base avant le 14 avril 2026, la CNIL n’a pas exigé de re-consentement rétroactif — une information claire assortie d’une possibilité de s’opposer facilement (opt-out) suffisait, à transmettre avant le 14 juillet. Passé cette date, la CNIL a annoncé qu’elle contrôlerait le respect de cette obligation d’information.

Reste une question de fond, indépendante du cadre juridique : le pixel a-t-il encore l’utilité qu’on lui prête ? Depuis 2021, Apple Mail Privacy Protection précharge systématiquement les images des emails ouverts sur ses clients, ce qui déclenche le pixel indépendamment d’une ouverture réelle et fausse mécaniquement les taux mesurés. Gmail et une partie des autres clients bloquent par défaut le chargement des images distantes, ce qui produit l’effet inverse — des ouvertures réelles non comptabilisées. Un pixel parfaitement conforme au 14 juillet peut donc rester une mesure peu fiable sur une part croissante de la base. Pour cibler des prospects sur un critère d’engagement, le suivi des clics sur les liens de l’email — un identifiant unique par lien, résolu côté serveur avant redirection — donne une mesure plus robuste, moins sujette aux préchargements des clients mail, et reste circonscrit à une action volontaire du destinataire plutôt qu’à un chargement automatique d’image invisible.

Pourquoi ce sujet en ouverture d’un article sur l’infrastructure email ? Parce qu’il illustre exactement la dynamique du reste de cet article : sur un outil marketing tout-en-un, ce genre de point est généralement géré en amont par le prestataire, parfois sans même que le client s’en rende compte. Dès qu’on reprend la main soi-même — même partiellement — c’est un point de conformité à anticiper dès la conception, pas à ajouter après coup une fois qu’une CNIL ou un client final le fait remonter.

Le socle technique : un éventail de solutions, pas un choix binaire

Reprendre la main sur son emailing ne veut pas dire, systématiquement, monter un serveur SMTP complet. C’est une option parmi d’autres, et elle a un coût de mise en place et de maintenance qu’il faut mettre en face du besoin réel.

Le full self-hosted — serveur SMTP, IP dédiée, réputation à construire depuis zéro — a un sens quand le volume le justifie et quand l’indépendance vis-à-vis de tout tiers est une contrainte forte, pas juste une préférence. Ça implique un socle technique précis :

• SPF correctement configuré et limité aux IP et domaines réellement autorisés à envoyer, pas une règle trop permissive copiée depuis un tutoriel ;
• DKIM avec rotation de clé prévue dès le départ, pas ajoutée après coup quand une clé finit par être suspectée compromise ;
• DMARC en mode observation avant passage en rejet strict, pour ne pas bloquer son propre trafic légitime pendant la phase de réglage ;
• une réputation d’IP à construire progressivement — un serveur neuf qui envoie 5000 emails le premier jour se fait immédiatement classer comme suspect par la plupart des fournisseurs.

L’envoi via API ou provider transactionnel (Resend ou équivalent) est une option intermédiaire trop souvent ignorée. On délègue la délivrabilité et la réputation IP à un tiers spécialisé, tout en gardant la main sur les données, le contenu, l’implémentation du pixel et sa conformité. Pour un client qui veut simplement sortir d’un outil marketing tout-en-un sans porter la charge d’un vrai serveur mail dans la durée, c’est souvent le compromis le plus raisonnable.

Un point de conception vaut pour les deux options : le transactionnel (confirmation de commande, réinitialisation de mot de passe) et le marketing (newsletter, prospection) ne doivent jamais partager la même IP ni le même sous-domaine d’envoi. Le premier a une réputation qu’on ne peut pas se permettre de dégrader — un email de réinitialisation qui atterrit en spam bloque un client en plein parcours. Le second est structurellement plus volatile, exposé aux signalements et aux plaintes. Faire transiter les deux flux par la même IP, c’est risquer qu’une campagne mal reçue plombe la délivrabilité d’un email transactionnel critique.

Aucune de ces deux briques n’est complexe individuellement. C’est l’accumulation, et surtout la maintenance dans la durée, qui distingue une infrastructure qui tient d’une installation qu’on abandonne après six mois quand les taux de délivrabilité commencent à se dégrader silencieusement.

Qui devient responsable de quoi

Sur un service SaaS d’emailing, le prestataire porte une bonne partie de la conformité RGPD par construction : hébergement, sous-traitance déclarée, mesures de sécurité standardisées, registre de traitement déjà en partie mâché.

Dès qu’on reprend la main — full self-hosted ou via API — cette responsabilité ne disparaît pas, elle revient intégralement au responsable de traitement, c’est-à-dire au client, avec moi comme sous-traitant technique. Ça change concrètement :

• le registre des traitements doit documenter où sont stockées les données de contact, pour combien de temps, avec quelle base légale ;
• la sécurisation de l’infrastructure (accès, chiffrement au repos, logs) devient un point d’audit CNIL potentiel, alors qu’avant c’était géré par le SaaS ;
• la gestion du consentement et du désabonnement — pixel de suivi compris, désormais — doit être implémentée soi-même, avec la même rigueur qu’un service commercial établi. Un lien de désinscription qui ne fonctionne pas n’est pas une excuse acceptable, quelle que soit l’infrastructure choisie.

À ça s’ajoutent des obligations qui ne relèvent pas du RGPD mais s’appliquent tout autant, quelle que soit l’infrastructure retenue, à tout email commercial ou de prospection : la mention de l’adresse physique de l’expéditeur (LCEN), une identification claire du caractère publicitaire du message, et une désinscription gratuite et simple, traitée sous un délai maximal de trois jours ouvrables (Code de la consommation). Sur un SaaS établi, ces points sont généralement pris en charge par construction. En reprenant la main sur l’envoi, ils redeviennent une obligation à prendre en charge explicitement — l’oubli n’est pas une zone grise, c’est une infraction distincte du RGPD.

Je ne présente jamais la reprise en main de l’emailing comme un raccourci de conformité. C’est l’inverse : c’est un choix qui demande plus de rigueur documentaire, en échange d’une indépendance réelle vis-à-vis d’un tiers qui peut changer ses conditions, ses prix, ou fermer son service du jour au lendemain.

Pour qui le sur-mesure a du sens

La vraie question n’est pas “self-hosted ou SaaS”, elle est déjà tranchée à ce stade de l’article. La question qui reste, c’est : pour qui vaut-il la peine de construire une solution pensée pour son cas précis, plutôt que de configurer un outil du marché — SaaS géré ou provider générique — pour s’en approcher ?

Le sur-mesure prend son sens quand plusieurs de ces conditions se recoupent :

• le volume est suffisant pour que l’investissement de mise en place s’amortisse, et pas juste en théorie ;
• le besoin de mesurer individuellement l’ouverture des emails est réel et documenté — pas un réflexe hérité d’un outil marketing qui le faisait par défaut, sachant que ce suivi a désormais un coût de conformité à part entière ;
• une infrastructure existe déjà par ailleurs (VPS notamment), donc pas de coût d’apprentissage d’une brique complètement nouvelle ;
• l’emailing doit s’intégrer à un système existant — CRM, application métier, base de prospection — que les connecteurs standards d’un SaaS ne couvrent qu’approximativement ;
• il y a quelqu’un, en interne ou en prestation, dont c’est explicitement le rôle de maintenir la solution dans la durée, conformité comprise.

Une association qui envoie une newsletter mensuelle à trois cents adhérents n’a pas ce profil. Une entreprise qui fait du transactionnel critique à fort volume, avec un CRM maison à connecter, commence à s’en rapprocher.

Dans les autres cas, je le dis clairement à mes clients : rester sur un service mail géré, avec une vérification correcte de ses clauses RGPD, est souvent le choix le plus raisonnable. L’indépendance technique n’a de valeur que si quelqu’un reste disponible pour la maintenir — et cette disponibilité doit maintenant inclure le suivi des évolutions réglementaires comme celle du 14 juillet, pas seulement la maintenance des serveurs.

Trois profils, trois réponses

Ramené aux critères posés plus haut, ça donne trois cas de figure assez nets.

Rester sur un SaaS géré convient à qui envoie un volume modeste, n’a pas de besoin de suivi individuel documenté, et n’a personne dédié à la maintenance d’une infrastructure email. C’est le choix par défaut, pas un choix par défaite — il reste le plus raisonnable pour une majorité de TPE et d’associations.

Passer par un provider ou une API (Resend ou équivalent) s’adresse à qui veut sortir d’un outil marketing tout-en-un devenu trop rigide ou trop cher, sans porter la charge d’un serveur mail. C’est l’option qui absorbe le mieux un besoin de personnalisation modéré — implémentation propre du pixel, séparation transactionnel/marketing, intégration à un CRM — sans le coût de la délivrabilité en propre.

Monter une infrastructure full self-hosted ne se justifie que pour un volume conséquent, une intégration profonde à un système existant, et une vraie disponibilité pour la maintenance dans la durée — la mienne, en tant que sous-traitant technique, ou celle d’une équipe interne. C’est le cas le moins fréquent chez mes clients, mais celui où l’indépendance a le plus de valeur réelle, à condition de ne pas la confondre avec une économie de rigueur documentaire.

Pour le texte complet de la recommandation CNIL du 12 mars 2026 sur les pixels de suivi : cnil.fr/fr/recommandation-pixel-suivi-courriels.

Et si l’hésitation persiste entre ces trois profils, c’est souvent le signe que le sur-mesure n’est pas encore justifié — et que rester sur un service géré reste, pour l’instant, la bonne réponse.