Situation
Les opérations commerciales de Sanofi en Europe et en Asie-Pacifique avaient accumulé sept systèmes CRM et bases de données historiques au cours d’une décennie d’acquisitions, de déploiements régionaux et de migrations de plateformes jamais pleinement finalisées. Les données clients et celles des professionnels de santé (HCP) existaient de manière fragmentée — certaines dans des systèmes on-premises vieillissants, d’autres dans des sandboxes Salesforce régionaux, d’autres encore dans des processus basés sur des tableurs qui n’avaient jamais été formalisés.
Le mandat était clair : consolider l’ensemble des données commerciales dans une plateforme Salesforce unique, décommissionner les sept systèmes historiques, et ce avec une tolérance zéro pour la perte de données. Dans l’industrie pharmaceutique, l’intégrité des données n’est pas un indicateur de performance — c’est une exigence réglementaire. Les enregistrements d’interactions avec les professionnels de santé, les données de prescription, la documentation de conformité promotionnelle et l’historique des événements indésirables doivent être complets et auditables. Toute migration qui perd, corrompt ou ne peut justifier un enregistrement crée une exposition réglementaire.
L’envergure du projet portait sur plus de 8 millions d’enregistrements répartis dans les sept systèmes sources, avec des modèles de données qui se chevauchaient, des correspondances de champs incohérentes, des entités en double et aucun schéma canonique établi sur ce que devait contenir un « enregistrement de contact professionnel de santé ». Trois des sept systèmes ne disposaient d’aucun accès API, nécessitant le développement d’outils d’extraction sur mesure.
Diagnostic
Le risque principal n’était pas la complexité technique — c’était la combinaison entre l’intransigeance réglementaire et la divergence des modèles de données. Les approches de migration standard (export en masse, transformation, chargement) comportent un risque de perte de données acceptable dans un contexte commercial, mais sont inacceptables dans le cadre de la conformité pharmaceutique.
Les systèmes sources présentaient trois problèmes distincts de qualité de données. Premièrement, les doublons : le même professionnel de santé existait dans plusieurs systèmes sous des noms, adresses et codes de spécialité légèrement différents. Deuxièmement, l’incohérence structurelle : ce qu’un système appelait « type de compte », un autre l’appelait « segment client », avec des jeux de valeurs différents et aucune table de correspondance. Troisièmement, les lacunes historiques : plusieurs systèmes avaient été utilisés de manière inconsistante, créant des enregistrements avec des champs obligatoires manquants qui échoueraient à la validation contre le schéma Salesforce cible.
Une migration qui aurait chargé ces enregistrements en l’état aurait généré des milliers d’échecs de validation dès le premier jour, nécessitant une remédiation manuelle après le démarrage — précisément le scénario que ni les régulateurs ni les parties prenantes métier ne pouvaient accepter. La solution exigeait de résoudre les problèmes de qualité des données avant la migration, et non après.
Les trois systèmes sans accès API ajoutaient un risque d’extraction. Des connecteurs sur mesure devaient être développés et testés, chaque extraction étant validée par rapport aux décomptes d’enregistrements et aux sommes de contrôle du système source.
Action
Phase 1 : Architecture des données et conception du schéma
Avant d’écrire une seule ligne de code de migration, un modèle de données canonique a été conçu pour l’environnement Salesforce cible. Il établissait la définition de référence de chaque entité : professionnel de santé, compte (établissement), produit, interaction, enregistrement de consentement et documentation de conformité. Chaque champ de chaque système source a été mis en correspondance avec un champ cible, avec des décisions explicites sur la résolution des conflits entre systèmes.
Le modèle canonique a été documenté, examiné par les parties prenantes conformité, juridiques et IT, et validé avant le début des travaux de migration. Cela a créé un référentiel unique de ce à quoi les données migrées devaient ressembler — et non de ce que contenaient les systèmes sources.
Phase 2 : Extraction et profilage
Des connecteurs d’extraction sur mesure ont été développés pour les trois systèmes historiques sans API, utilisant des requêtes directes en base de données lorsque c’était possible et de l’automatisation par capture d’écran lorsque l’accès à la base de données n’était pas disponible. Chaque extraction a été validée : correspondance des décomptes d’enregistrements, validation par somme de contrôle de la complétude, et audit par échantillonnage comparant les enregistrements extraits aux captures d’écran de l’interface du système source.
Un profilage des données a été exécuté sur l’ensemble des données extraites pour quantifier les trois problèmes de qualité : 340 000 doublons potentiels identifiés, 12 000 enregistrements avec des champs obligatoires manquants, et 89 000 enregistrements présentant des incohérences structurelles nécessitant une normalisation des valeurs.
Phase 3 : Transformation et résolution des problèmes de qualité
Un processus de déduplication déterministe a résolu les 340 000 doublons potentiels. Les règles de rapprochement combinaient l’identifiant national (lorsque disponible), un score de proximité nom + adresse, et la correspondance des codes de spécialité. Chaque décision de déduplication a été consignée avec les critères de rapprochement utilisés, créant une piste d’audit exploitable lors des revues réglementaires.
Les champs obligatoires manquants ont été corrigés par une combinaison d’enrichissement automatisé (à partir des registres publics de professionnels de santé lorsque disponibles) et d’un processus de revue structuré pour les enregistrements qui ne pouvaient être complétés automatiquement. Les 12 000 enregistrements avec des champs manquants ont été réduits à 847 nécessitant une revue humaine avant la migration.
Les incohérences structurelles ont été résolues via des tables de correspondance de valeurs : chaque valeur de chaque système source a été mise en correspondance avec la valeur canonique cible, les valeurs impossibles à transposer étant signalées pour décision du responsable métier. Aucun enregistrement n’a été migré avec une correspondance non résolue.
Phase 4 : Chargement, validation et mise en production
La migration a été exécutée par vagues parallèles : d’abord les environnements hors production, avec une validation complète avant le chargement en production. Chaque vague suivait un cycle chargement-validation-rapprochement : charger un lot, exécuter des requêtes de validation automatisées comparant les décomptes d’enregistrements et les valeurs de champs entre source et cible, résoudre tout écart avant de poursuivre.
Un seuil de rapprochement à tolérance zéro a été défini : tout lot dont le rapprochement source-cible échouait, ne serait-ce que pour un seul enregistrement, entraînait l’arrêt de la migration et déclenchait une investigation. Au cours de la migration, trois lots ont provoqué des arrêts — les trois ont été attribués à des problèmes d’extraction dans les systèmes historiques (et non à des erreurs de transformation), corrigés puis rechargés.
Après la migration, une période d’exploitation en parallèle de 30 jours a fait fonctionner simultanément les systèmes historiques et Salesforce, avec des requêtes de comparaison automatisées confirmant la cohérence des données entre les systèmes. La validation du décommissionnement exigeait un rapprochement à 100 % sur l’ensemble des 8M+ d’enregistrements.
Résultat
Huit millions d’enregistrements migrés à travers sept systèmes historiques sans aucun incident de perte de données. La période d’exploitation en parallèle a confirmé le rapprochement complet — chaque enregistrement de chaque système historique a été retrouvé dans la cible Salesforce, avec une piste d’audit intégrale depuis l’extraction source, en passant par les décisions de transformation, jusqu’au chargement final.
Sept systèmes historiques ont été décommissionnés dans les délais, éliminant les coûts de maintenance et le risque de conformité associés à une infrastructure vieillissante. La plateforme Salesforce consolidée a réduit les coûts informatiques annuels de maintenance de systèmes CRM multiples de 1,2 M€.
Le cadre méthodologique de migration développé pour Sanofi s’est avéré réutilisable : les connecteurs d’extraction, la logique de transformation et la suite de validation ont été packagés comme des actifs réutilisables pour de futurs programmes de migration. La méthodologie de résolution de la qualité des données — profiler, résoudre de manière déterministe, signaler les cas résiduels pour revue humaine, documenter chaque décision — a depuis été appliquée à deux programmes de migration ultérieurs chez d’autres clients.
La migration a également établi une fondation de données propre et bien gouvernée qui positionne les opérations commerciales de Sanofi pour les futures initiatives IA et Data Cloud. Des données propres avec des pistes d’audit complètes sont le prérequis de l’automatisation intelligente ; l’organisation commerciale de Sanofi est désormais en mesure de déployer des agents Agentforce sur une fondation capable de les supporter.
Technologies utilisées : Salesforce Sales Cloud, Service Cloud, Data Loader, connecteurs d’extraction sur mesure, frameworks de validation Apex, transformations DataWeave, outils de profilage de données externes
Études de cas associées
Gouvernance unifiée sur 3 000+ points de vente
Vue client unifiée sur 3 000+ points de vente grâce à une architecture multi-cloud
Centre d'Excellence : 15 entités métier, une seule architecture
Architecture de gouvernance centralisée pour passer d'implémentations cloisonnées à une stratégie unifiée