CRM emailing : qui détient la désinscription ?

Un CRM emailing, c'est un seul endroit qui garde la fiche de chaque contact et qui envoie les emails depuis cette fiche. Pas un CRM d'un côté, un outil d'envoi de l'autre, reliés par un export CSV. Ce qui change tout tient dans un aller-retour : ouverture, clic, réponse et désinscription reviennent dans la fiche, et décident du message suivant.

Deux montages très différents portent la même étiquette

Tu vas croiser deux choses sous ce nom, et elles ne demandent pas le même travail.

Le premier montage : un outil unique, qui fait fiche contact et campagne. Tu crées le contact, tu écris, tu envoies, l'historique s'écrit tout seul au même endroit. C'est simple, et ça tient longtemps quand tu vends une offre à une seule audience.

Le second : ton CRM reste maître de la donnée client, un outil d'emailing envoie, et un connecteur fait circuler l'information dans les deux sens. Plus de câblage au départ, plus de liberté ensuite.

Le troisième montage n'a pas de nom, parce que personne ne le revendique : le CRM d'un côté, l'outil d'envoi de l'autre, et un fichier exporté à la main quand tu prépares une campagne. C'est celui que tu as probablement aujourd'hui.

Le seuil où le couplage devient vraiment utile

Ce n'est pas une histoire de nombre de contacts. Il y a des bases de 8 000 adresses qui n'ont besoin d'aucun CRM, et des bases de 300 qui en réclament un depuis six mois.

Le seuil est ailleurs : c'est le jour où tu écris un segment qui a besoin d'un événement passé. « Ceux qui ont cliqué sur la page tarifs le mois dernier et qui n'ont pas répondu. » Tant que tes segments tiennent dans des champs fixes (métier, ville, date d'inscription, source), une table et une fonction d'envoi suffisent. Dès qu'un segment dépend d'un comportement, il te faut l'aller-retour, sinon tu reconstruis la liste à la main chaque semaine.

Exemple maison : la newsletter de ce site part d'une table Postgres et d'un adaptateur d'envoi. Pas de CRM, pas de connecteur. Aucun de mes segments n'a encore besoin d'un événement, donc un outil de plus ne ferait rien que la table ne fasse déjà. Le jour où je voudrai écrire aux lecteurs qui ouvrent trois numéros sur quatre, la réponse changera.

“

Un système détient la désinscription, tous les autres la lisent.

”

Le conseil : décide qui détient la désinscription

Si tu ne gardes qu'une chose de cette lettre, prends celle-là. Un système détient la désinscription, tous les autres la lisent.

Concrètement, quatre gestes :

1. Choisis le système maître du consentement, celui qui reçoit le clic sur le lien de désinscription. C'est presque toujours l'outil d'envoi, parce que le lien pointe chez lui.
2. Interdis l'écriture de ce champ ailleurs. Ton CRM lit l'état, il ne le décide pas.
3. Vérifie que ton connecteur synchronise ce champ précis. Beaucoup font circuler les contacts et les étiquettes, pas les statuts de désinscription. C'est écrit en petit, ou pas écrit du tout.
4. Teste-le toi-même. Inscris une de tes adresses, envoie-toi une campagne, désinscris-toi depuis l'email, puis ouvre la fiche dans le CRM dix minutes plus tard. Si le champ n'a pas bougé, ton couplage est décoratif.

Ce test prend un quart d'heure et il tranche une question que les pages produit laissent volontairement floue.

Ce qu'il faut arrêter : l'export du vendredi

L'export CSV manuel a l'air inoffensif. Il produit trois dégâts, toujours les mêmes.

Il crée des doublons : la même personne revient avec deux orthographes, et reçoit deux exemplaires du même email.

Il fige l'état : le fichier date de vendredi, la désinscription est arrivée samedi, l'envoi part lundi.

Il fabrique des plaintes : réécrire à quelqu'un qui s'est désinscrit, c'est le geste qui déclenche le clic « signaler comme spam ».

Le troisième est le seul qui coûte vraiment cher. Une plainte pèse sur la réputation de ton domaine d'envoi, et cette réputation met des semaines à se construire. C'est le même terrain que dans mes douze notes de terrain sur le cold-emailing : la délivrabilité se perd bien plus vite qu'elle ne se gagne. Sur un domaine neuf, un service de warm up comme Mailivery fait le travail d'échauffement avant les campagnes, mais aucun échauffement ne rattrape des envois à des désinscrits.

Ce que je regarde avant de choisir l'outil

Les comparatifs alignent des tableaux de fonctions. Quatre questions écartent déjà la moitié des candidats.

Est-ce que l'outil expose des webhooks sur les événements d'envoi ? Sans webhook ni API de lecture, tu récupères un rapport, pas un aller-retour. Le couplage restera manuel, quel que soit le prix payé.

Est-ce que tu peux tout ressortir, événements compris ? Un export des contacts ne suffit pas. Si l'historique d'envoi reste prisonnier de l'outil, changer d'outil te fait repartir de zéro sur la segmentation.

Le prix est-il indexé sur les contacts stockés ou sur les emails envoyés ? Le premier modèle te pousse à supprimer les contacts inactifs pour rester dans la tranche tarifaire. Tu détruis ton historique pour économiser quinze euros par mois. Le second te laisse garder la mémoire.

Qui envoie techniquement ? Le domaine partagé de l'éditeur, ou ton domaine authentifié. La différence ne se voit pas le premier mois, elle se voit au premier pic de volume et le jour où un voisin de domaine se fait signaler.

Si tes envois sont pilotés par du code ou par un agent plutôt que par une interface, la brique cherchée change de nature : tu veux une infrastructure email adressable par API, comme AgentMail, pas un logiciel avec des écrans.

La question que je te laisse : si tu perdais demain matin l'accès à ton outil d'emailing, que saurais-tu encore de tes contacts ? Ta réponse dit qui détient réellement ta base.

FAQ

Un CRM emailing remplace-t-il un outil d'emailing ? Parfois oui, souvent non. Les CRM qui envoient couvrent bien les messages simples et les relances de suivi. Dès que tu fais de la newsletter éditoriale, avec mise en page et tests d'objet, l'outil d'emailing dédié reste plus confortable. La vraie question n'est pas de choisir un camp, c'est de décider quel système garde la mémoire du contact.

Faut-il commencer par le CRM ou par l'emailing ? Par ce que tu fais déjà. Si tu envoies une lettre chaque semaine et que tu n'as aucun suivi commercial, commence par l'emailing et tiens une table propre à côté. Si tu suis des affaires en cours et que tu écris rarement, commence par le CRM et ajoute l'envoi ensuite.

Combien de contacts avant d'avoir besoin d'un couplage ? Le nombre n'est pas le bon critère. Le déclencheur, c'est le premier segment qui dépend d'un comportement passé plutôt que d'un champ fixe. Certains y arrivent à 200 contacts, d'autres n'y arrivent jamais.

Emailing CRM et marketing automation, quelle différence ? Le couple CRM emailing règle une question de données : où vit le contact, qui écrit son état. Le marketing automation ajoute une couche de déclencheurs et de scénarios par-dessus. Sans aller-retour propre en dessous, les scénarios se déclenchent sur des informations périmées.

Un tableur peut-il servir de CRM emailing ? Pour démarrer, oui, à une condition : que la désinscription y arrive automatiquement. Un tableur mis à jour à la main, c'est l'export du vendredi avec un nom plus flatteur.