Pipeline de données CRM pour un réseau retail allemand

Notre client exploite un réseau retail en Allemagne, avec une activité de gros B2B à destination des clients professionnels. Les données clients et commandes étaient dispersées dans plusieurs systèmes : un ERP on-premise, une plateforme e-commerce, des exports de caisse et une org Salesforce utilisée par la force de vente terrain.

Salesforce devait offrir la vue unique de chaque client professionnel. En pratique, il était alimenté par des imports CSV manuels, et l’équipe commerciale avait appris à s’en méfier.

Les fiches de comptes étaient dupliquées d’une région à l’autre, les coordonnées devenaient obsolètes en quelques mois et les indicateurs de consentement étaient tenus à la main — une exposition RGPD autant qu’un problème commercial. Le reporting du pipeline commercial contredisait l’ERP, si bien que les réunions de prévision commençaient par un débat sur la fiabilité des chiffres. Le client n’avait pas besoin d’un nouveau CRM ; il avait besoin d’une discipline d’ingénierie appliquée aux données qui alimentaient celui qu’il possédait déjà.

Nous avons abordé la mission comme un projet de data engineering. Après avoir cartographié chaque système source et chaque champ, nous avons construit une couche d’ingestion et de transformation : des services Python orchestrés avec Apache Airflow, exécutés sur Azure Kubernetes Service dans une région de l’UE, avec une base de staging PostgreSQL comme entrepôt intermédiaire. L’ERP est lu via des extractions OData planifiées ; la plateforme e-commerce et les exports de caisse arrivent par ingestion événementielle et par fichiers.

La déduplication applique d’abord un rapprochement déterministe sur les identifiants de registre, puis un rapprochement approximatif sur le nom et l’adresse, avec des règles de survivance explicites déterminant quelle source l’emporte pour chaque champ — des règles que l’équipe sales operations du client a relues et validées. L’enrichissement vérifie les numéros de TVA et les données d’entités juridiques auprès des registres publics. Les indicateurs de consentement et d’autorisation marketing sont modélisés comme des champs de premier rang, avec historique complet : un retrait de consentement se propage à tous les systèmes connectés au lieu de subsister dans une copie oubliée.

Les fiches nettoyées et fusionnées sont synchronisées vers Salesforce via la Bulk API 2.0, et des événements Change Data Capture ramènent les mises à jour champ par champ de Salesforce vers le pipeline, pour une cohérence bidirectionnelle. Des contrôles de qualité des données s’exécutent à chaque chargement avec Great Expectations ; un contrôle en échec bloque la propagation et alerte notre équipe d’astreinte au lieu d’écrire silencieusement de mauvaises fiches dans le CRM.