Résultat
contacts en doublon fusionnés
Résultat
entreprises en doublon fusionnées
Résultat
contacts migrés de Sarbacane vers HubSpot, puis Brevo
● Contexte
Le client : TGV Lyria, la grande vitesse entre la France et la Suisse
TGV Lyria opère des trains à grande vitesse entre la France et la Suisse. Derrière chaque liaison Paris-Genève ou Paris-Zurich, une petite équipe communication mène des campagnes à fort volume sur trois marchés et trois langues, la France, la Suisse romande et la Suisse alémanique, sous les contraintes de process strictes de deux grands groupes ferroviaires : SNCF et CFF.
Au moment de changer de plateforme d'emailing, le « suffisant » n'était pas une option. Une campagne commerciale stratégique était déjà programmée au calendrier.
Le problème : une migration CRM qui ne pouvait pas se permettre le moindre faux pas
Au lancement du projet, la situation était un cas d'école du « rapide et fiable, il faut choisir les deux » :
- Une migration avec une deadline. Passer de Sarbacane à Brevo sans perdre en qualité de données, en délivrabilité ou en exploitabilité, avec un temps fort commercial déjà programmé.
- Trois outils, aucun ne communiquant proprement. Sarbacane pour l'envoi historique, HubSpot comme socle CRM, Brevo prévu comme nouvelle plateforme transactionnelle et marketing. Aucune vue contact cohérente entre les trois.
- Des années de données en désordre. Les données source vivaient dans des fichiers CSV/Excel plats, répartis par langue. Des opt-ins stockés en
"Oui","Ja","1"et une douzaine d'autres variantes. Plaintes, NPAI (retours postaux), désabonnements et rebonds, tous remélangés dans les mêmes listes que les contacts actifs. - Deux couches de conformité grand groupe. La SNCF et les CFF apportaient leurs propres workflows de cybersécurité, de RGPD et de validation interne par-dessus des opérations marketing B2C standard.
Les risques étaient tout aussi clairs : perdre la capacité d'envoyer des communications de masse, dégrader la réputation du domaine avec des données de mauvaise qualité, ou se retrouver avec un workflow plus lourd que celui qu'on remplaçait.
La demande : reconstruire la stack data et email sur HubSpot + Brevo, nettoyer des années de bruit historique, et livrer avant la prochaine fenêtre de campagne, sans interrompre un seul envoi.
● La solution Cashmyrr
Pourquoi HubSpot + Brevo (et pas Sarbacane v2)
Sarbacane gérait l'envoi correctement, mais ne réglait pas le problème de fond : le CRM de TGV Lyria était une collection d'imports, pas une base de données. Il nous fallait deux choses à la fois :
- Un socle CRM qui tient un modèle de contact propre et structuré, avec segmentation native, étapes du cycle de vie, relations entreprises parent/enfant et traçabilité RGPD complète. HubSpot.
- Une plateforme d'envoi en masse dotée d'outils de délivrabilité solides, d'une authentification native (DKIM/SPF/DMARC), du warming d'IP et d'une synchronisation bidirectionnelle avec le CRM. Brevo.
Concrètement, cette combinaison nous a permis de livrer trois choses que Sarbacane seul n'aurait jamais pu :
- Une source de vérité unique pour les trois marchés, avec opt-ins, étapes du cycle de vie et champs de langue alignés.
- Un sous-domaine d'envoi dédié (
newsletter.lyria.com) qui protège la réputation du domaine principal quel que soit le volume de campagnes. - Une synchronisation bidirectionnelle entre Brevo (envois, rebonds, désabonnements) et HubSpot (la source de vérité) toutes les ~6 heures, avec suppression pilotée par workflow pour maintenir une délivrabilité élevée.
● Étapes
L'architecture en production
La nouvelle stack compte quatre couches :
- Une base de staging (SQL + MongoDB) où les fichiers CSV/Excel bruts sont normalisés avant de toucher HubSpot.
- Un workflow d'ingestion n8n qui fait des upserts intelligents dans HubSpot, en vérifiant ce qui existe déjà, en ne mettant à jour que les champs manquants, sans jamais écraser une bonne donnée par une moins bonne.
- HubSpot comme source de vérité structurée, avec des comptes B2B parent/enfant, des étapes du cycle de vie et une auto-segmentation par source.
- Brevo sur un sous-domaine dédié pour l'envoi en masse, avec synchronisation bidirectionnelle native vers HubSpot.
Les seules couches sur mesure sont le pipeline de staging et le contrôleur d'ingestion n8n. Tout ce qui est en aval est du HubSpot et du Brevo natifs.
La migration, étape par étape
Étape 1 - Des fichiers plats à une zone de staging contrôlée
Importer les CSV historiques directement dans HubSpot aurait incrusté des années de bruit dans le nouveau système. À la place, nous avons fait transiter tout par une couche de staging SQL + MongoDB.
Des pipelines d'agrégation MongoDB ($project, $unionWith, $lookup) ont fait le gros du travail :
- Normalisation : opt-ins ramenés à un seul booléen, dates standardisées, champs alignés entre les sources FR/DE/EN.
- Exclusion dynamique : les e-mails signalés dans les collections
complaintsetnpaiétaient filtrés avant d'atteindre HubSpot. - Nettoyage des formats : les entrées numéro-de-téléphone-en-guise-d'e-mail (
0606060606@icloud.com) et autres adresses tueuses de délivrabilité étaient supprimées à ce stade.
Seules les données qui passaient le staging poursuivaient vers l'aval.
Étape 2 - Upserts intelligents dans HubSpot
Nous ne faisions pas confiance à un bouton « Tout importer » avec un CRM aussi chargé. Nous avons construit un workflow n8n comme contrôleur d'ingestion :
- Le workflow interroge HubSpot par lots via l'API.
- Pour chaque e-mail, il vérifie si le contact existe déjà.
- Il ne met alors à jour que les champs manquants ou crée un nouveau contact — sans jamais écraser une meilleure donnée par une moins bonne.
Résultat : TGV Lyria s'est retrouvé avec un CRM enrichi, pas écrasé.
Étape 3 - Un sous-domaine dédié + authentification complète
Les campagnes de masse ont été ré-ancrées sur une infrastructure qui protège le domaine principal :
- Sous-domaine dédié :
newsletter.lyria.com, séparé du courrier transactionnel et corporate. - Stack d'authentification complète : DKIM, SPF, DMARC configurés pour un placement en boîte de réception maximal.
- Synchronisation bidirectionnelle : synchro native Brevo ↔ HubSpot toutes les ~6 heures, pour que les hard bounces et les désabonnements de Brevo reviennent automatiquement dans HubSpot.
- Des workflows de suppression dans Brevo qui retirent les hard et soft bounces avant chaque premier envoi.
Étape 4 - Nettoyer la base historique avec clustering + IA
Des années d'imports avaient créé un problème de doublons flous qu'une simple déduplication par e-mail ne pouvait pas résoudre :
jean.dupont@company.comvsj.dupont@company.fr- Fautes de frappe et orthographes alternatives sur les prénoms/noms
- Profils B2B/B2C mélangés
Nous avons superposé trois étapes :
1. Clustering déterministe - regroupement des doublons potentiels selon trois clés : e-mail exact, domaine + nom, téléphone + nom. Cela a produit des clusters ciblés sans encore rien fusionner.
2. Scoring assisté par IA sur la zone grise - pour les paires dont la similarité initiale se situait entre 0,60 et 0,84, nous avons utilisé GPT pour évaluer la similarité sémantique : surnom vs nom complet, fautes typiques, prénom/nom inversés, noms abrégés. GPT renvoyait un score de confiance, et seules les paires à ≥ 0,85 étaient fusionnées automatiquement. Tout ce qui était en dessous restait dans une file de revue manuelle.
3. Règles de fusion intelligentes - champ par champ, jamais destructives :
- Conserver l'e-mail le plus valide.
- Conserver l'étape du cycle de vie la plus avancée (Customer > Opportunity > Lead).
- Préserver le propriétaire existant là où c'était pertinent.
Étape 5 - Un modèle de comptes B2B parent/enfant
Pour les données B2B, nous avons restructuré autour d'un modèle d'entreprise parent/enfant :
- Les entreprises partageant le même
root_domain(ex.hermes.com) étaient identifiées. - Un script désignait ensuite une entreprise parent (typiquement le siège) et reliait les entités locales en tant qu'entreprises enfants.
Les commerciaux ont obtenu une vue globale des comptes clés sans perdre le contexte des contacts locaux.
Étape 6 - Corriger les données à la source
Nettoyer les données historiques est une chose. Stopper la nouvelle pollution est ce qui rend l'effort durable.
Plusieurs entrées « maison » injectaient des contacts de faible qualité directement dans HubSpot - formulaires en pur HTML, barres de recherche et autres fonctionnalités du site qui déclenchaient une création automatique de contact. Résultat : des milliers de « Organic Leads » sans info exploitable et sans consentement. Des cookies marketing étaient aussi déposés avant l'opt-in de l'utilisateur, posant des problèmes de RGPD.
Le point de douleur le plus sévère était structurel : HubSpot traitait chaque champ de saisie comme une source de leads. Requêtes de recherche, connexions au portail, soumissions de formulaire de contact, tout créait de nouveaux contacts et entreprises dans le CRM.
Nous avons corrigé cela en deux mouvements :
1. Verrouillage de l'API. Désactivation de la capture « Non-HubSpot Forms » de HubSpot. Seuls des points de contact intentionnels et contrôlés peuvent désormais créer des contacts.
2. Tracking conditionnel via CookieFirst. Réécriture de l'intégration GTM pour que le script de tracking HubSpot et le cookie hubspotutk ne se déclenchent qu'après consentement explicite via la CMP CookieFirst.
En plus de cela, chaque nouveau contact est auto-segmenté par source et intention via des workflows HubSpot : un contact issu du formulaire newsletter est taggé comme cible B2C ; un contact venant de Salesforce ou doté d'un Owner spécifique est taggé B2B. Le reporting et la pertinence des campagnes démarrent propres dès la création du contact.
Les garde-fous : la documentation comme livrable
Un projet réparti entre des workflows n8n, des scripts Python/SQL, des pipelines MongoDB et de la configuration HubSpot a un mode de défaillance critique : la connaissance qui ne vit que dans la tête des gens.
Nous avons traité la documentation comme un livrable à part entière dès le premier jour :
- Documentation technique en Markdown décrivant le quoi (architecture, workflows, scripts) et le comment, avec des extraits JSON pour les workflows n8n clés, les requêtes MongoDB et leur logique sous-jacente. Tout développeur qui rejoint plus tard peut comprendre le système sans le rétro-concevoir.
- Des runbooks de maintenance, procédures pas à pas pour la vérification des logs de synchro Brevo, la gestion des nouveaux doublons et autres opérations récurrentes. Pas des notes théoriques, de vrais playbooks du quotidien.
- La traçabilité des décisions, règles de fusion et seuils d'IA documentés en langage clair. Si une fusion de contacts est un jour contestée, la logique sous-jacente est auditable.
● Résultat
Ce qui a été livré, le résultat en production
Zéro interruption de campagne. La migration complète a été livrée sans sauter un seul envoi, malgré le temps fort commercial stratégique déjà au calendrier.
Une fondation structurée sur trois marchés et trois langues, prête pour des campagnes à fort volume sur Brevo, avec opt-ins, étapes du cycle de vie et champs de langue alignés entre FR / FR-CH / DE-CH.
Une infrastructure email protégée, sous-domaine dédié, DKIM/SPF/DMARC complets, synchro bidirectionnelle native avec HubSpot. Réputation du domaine isolée du volume de campagnes.
Un risque de pollution des données nettement réduit, grâce au staging, à la déduplication déterministe + IA, et au verrouillage à la source des entrées web non contrôlées.
Un modèle de comptes B2B qui fait remonter les relations entreprises parent/enfant et permet des vues par compte clé.
Une documentation et des runbooks clairs qui rendent les équipes internes opérationnellement autonomes et résilientes aux changements de personnel.
Cashmyrr a su proposer un plan d'action efficace, réaliste et aligné avec nos contraintes de timing, notamment une campagne commerciale stratégique déjà au calendrier.
Nous avons bénéficié d'une double expertise : marketing et pilotage de projet avec Antoine, et un accompagnement technique pointu avec Telmo.
Disponibilité, expertise et agilité dans les projets. Il y a un vrai sentiment de construire aux côtés du client.
— TGV Lyria
Ce que nous avons appris en migrant du B2C à fort volume sur HubSpot + Brevo
Ce qui a marché
- Le staging avant HubSpot, à chaque fois. Traiter HubSpot comme la destination, pas le moteur de traitement, a été la décision unique qui a rendu le reste du projet gérable. Nettoyer les champs, normaliser les opt-ins et appliquer les listes de suppression dans MongoDB est rapide, peu coûteux et auditable. Nettoyer les mêmes données dans HubSpot aurait signifié des workflows par-dessus des workflows, des performances moindres et un coût plus élevé.
- L'IA sur la zone grise, pas sur tout. Le clustering déterministe a traité la majorité des doublons. GPT n'était invoqué que pour la bande intermédiaire ambiguë (similarité 0,60-0,84). Coût prévisible, comportement prévisible, et une seule bande de décisions à auditer.
- n8n comme contrôleur d'ingestion. Des upserts intelligents via l'API battent n'importe quel import en masse. Nous avons choisi quoi mettre à jour, quoi laisser tel quel, et comment journaliser chaque opération, ce qu'un import HubSpot par défaut ne donne pas.
- La documentation comme livrable, pas comme après-coup. Une doc technique en Markdown et des runbooks opérationnels ont rendu la passation ennuyeuse, ce qui est exactement ce qu'on veut sur un projet aussi distribué.
Les limites que nous avons rencontrées
- Les comportements par défaut de HubSpot nécessitent un verrouillage actif. Tel quel, HubSpot crée des contacts à partir de sources que vous ne destiniez pas à être des sources de leads. La capture Non-HubSpot Forms, le script de tracking, le cookie déposé avant le consentement, tout cela a demandé une configuration explicite. Si vous ne traitez pas ce point dès le premier jour, votre CRM « propre » se resalit en quelques semaines.
- La synchro native Brevo ↔ HubSpot tourne toutes les ~6 heures. Suffisant pour la cadence des campagnes marketing, un peu juste pour des boucles de feedback rapides sur les problèmes d'envoi. Nous avons compensé avec des workflows de suppression côté Brevo en amont de chaque premier envoi.
- Les sources multilingues ne se normalisent pas toutes seules. Les données FR/DE/EN arrivaient avec leurs propres vocabulaires d'opt-in et formats de date. Les règles de normalisation devaient être explicites, langue par langue, dans la couche de staging, jamais supposées.
● Questions fréquentes
N'importez pas les CSV historiques directement. Faites transiter chaque fichier source par une base de staging d'abord (nous utilisons SQL + MongoDB) pour normaliser les opt-ins, exclure les plaintes et les NPAI, et nettoyer les mauvais formats. Seules les données qui passent le staging atteignent le nouveau CRM. En parallèle, configurez Brevo avec un sous-domaine d'envoi dédié et une authentification DKIM / SPF / DMARC complète avant le premier envoi, pour que la délivrabilité ne s'effondre pas sur le bruit historique.
Oui, si le basculement est échelonné. Nous avons migré la stack de TGV Lyria sur trois marchés et trois langues sans sauter un seul envoi, y compris pendant une campagne commerciale stratégique déjà au calendrier. Le principe : nettoyer et valider les données dans une couche de staging, mettre en place la nouvelle infrastructure d'envoi en parallèle, et ne basculer les campagnes qu'une fois Brevo entièrement authentifié et synchronisé avec HubSpot.
Parce que les deux métiers sont différents. HubSpot est un socle CRM : modèle de contact structuré, étapes du cycle de vie, relations entreprises parent/enfant, segmentation, traçabilité RGPD. Brevo est une plateforme d'envoi en masse : outils de délivrabilité, warming d'IP, authentification native. Les outils tout-en-un tendent à être forts d'un côté et faibles de l'autre. La combinaison, avec une synchro bidirectionnelle native, vous donne les deux sans compromis.
● Voir d'autres case studies
