Réservations T3 2026 · 2 créneaux retainer ouverts · Direct ou via intégrateur Paris ·Séoul
Sébastien Tang ARCHITECTE SOLUTIONS SALESFORCE
Sciences du vivant

Étude de cas

8M+ d'enregistrements, 7 systèmes historiques, zéro perte de données

Migration d'une plateforme pharma d'envergure avec zéro perte de données sur 8M+ d'enregistrements

EngagementOrg Health & Recovery ArchitectureDurée6 moisLieuParisAnnées2021–22

Sébastien Tang · Solution Architect senior Salesforce, indépendant. Architecture Salesforce pour l'ère IA : Agentforce, Data 360, systèmes multi-cloud qui tiennent en production.

  • Administrator · Certifié Salesforce
  • App Builder · Certifié Salesforce
  • AI Associate · Certifié Salesforce
  • Marketing Cloud AE · Certifié Salesforce

Le problème

L'activité commerciale de Sanofi tournait sur sept CRM et systèmes de données historiques en Europe et en Asie-Pacifique. 8M+ d'enregistrements avec doublons d'identité, incohérence structurelle et lacunes historiques. Trois des sept systèmes n'avaient pas d'API. Une migration en masse standard aurait produit des milliers d'échecs de validation et une exposition réglementaire inacceptable pour un acteur pharmaceutique.

Ce que j’ai fait

Un modèle de données canonique a été conçu et validé par la conformité, le juridique et l'IT avant toute extraction. Des connecteurs sur mesure ont récupéré les données des systèmes sans API. Une passe de déduplication, d'enrichissement et de mappage des valeurs a résolu 340 000 doublons et 89 000 incohérences avant chargement. La migration a été exécutée par vagues chargement-validation-rapprochement avec un seuil de tolérance zéro.

En un coup d'œil

Client
Sanofi
Secteur
Sciences du vivant
Mission
6 mois
Mon rôle
Lead Solution Architect, Migration et Intégrité des données
Clouds Salesforce
Sales Cloud · Service Cloud
Résultat
0 incidents de perte de données

Avant / Après

Avant
  • Sept CRM et systèmes de données séparés en Europe et en Asie-Pacifique.
  • 8M+ d'enregistrements avec doublons d'identité, aucun schéma canonique.
  • 340 000 doublons potentiels, 89 000 incohérences, 12 000 enregistrements aux champs obligatoires manquants.
  • Trois systèmes sources sans accès API.
  • Aucun cadre de rapprochement, aucune piste d'audit pour la revue réglementaire.
6 mois
Après
  • Une plateforme Salesforce consolidée, sept systèmes historiques décommissionnés.
  • 8M+ d'enregistrements sous modèle canonique, propriétaires nommés par entité.
  • 847 enregistrements revus par des humains, le reste résolu automatiquement avec critères tracés.
  • Connecteurs sur mesure et suite de validation packagés comme actifs réutilisables.
  • Rapprochement source-cible à 100 % sur l'ensemble des 8M+ d'enregistrements.

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 jamais pleinement finalisées. Les données clients et celles des professionnels de santé (HCP) existaient de manière fragmentée. Certaines vivaient dans des systèmes on-premises vieillissants, d’autres dans des sandboxes Salesforce régionaux, d’autres encore dans des processus sur 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 dossiers 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 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 partagé sur ce que devait contenir un dossier de professionnel de santé. Trois des sept systèmes ne disposaient d’aucun accès API, exigeant des outils d’extraction sur mesure.

Défi

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 acceptable en contexte commercial, mais inacceptable sous conformité pharmaceutique.

Les systèmes sources présentaient trois problèmes distincts de qualité de données. 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. 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. Les lacunes historiques : plusieurs systèmes avaient été utilisés de manière inconsistante, créant des enregistrements aux champs obligatoires manquants qui échoueraient à la validation contre le schéma 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. C’est précisément le scénario que ni les régulateurs ni les parties prenantes métier ne pouvaient accepter. Le travail devait résoudre la qualité des données avant la migration, et non après. Les trois systèmes sans accès API ajoutaient un risque d’extraction par-dessus : des connecteurs sur mesure à construire et tester, chaque extraction validée contre les décomptes et les sommes de contrôle du système source.

Ce que j'ai dit au comité de pilotage avant le début des extractions

Le chargement, c’est la partie facile. La mission, c’est la qualité des données. Si on tient le modèle et le nettoyage, la migration elle-même ne fera aucun bruit.

Action

Le choix architectural a été de concevoir le modèle de données canonique avant la moindre ligne de code de migration. Le schéma cible établissait la définition de référence de chaque entité (professionnel de santé, compte, produit, interaction, consentement, documentation de conformité). Chaque champ source était mis en correspondance avec un champ cible, avec des règles explicites de résolution des conflits. La conformité, le juridique et l’IT ont validé avant le démarrage des extractions.

LAYER 01

Extraction et profilage

Connecteurs sur mesure construits pour les trois systèmes sans API via requêtes directes en base et automatisation par capture d'écran. Chaque extraction validée contre les décomptes et les sommes de contrôle. Le profilage a quantifié la portée du nettoyage : 340 000 doublons potentiels, 12 000 enregistrements aux champs obligatoires manquants, 89 000 incohérences structurelles.

LAYER 02

Transformation et résolution qualité

Déduplication déterministe combinant identifiant national, proximité nom plus adresse et code de spécialité. L'enrichissement automatisé depuis les registres publics de professionnels de santé a réduit le jeu des champs manquants de 12 000 à 847 pour revue humaine. Les tables de mappage de valeurs ont résolu les incohérences structurelles ; aucun dossier migré avec une correspondance non résolue.

LAYER 03

Chargement, validation, rapprochement

Vagues parallèles : environnements hors production d'abord, validation complète avant le chargement en production. Chaque lot suivait un cycle chargement-validation-rapprochement. Un seuil de tolérance zéro arrêtait tout lot manquant un seul dossier. Trois arrêts pendant le programme, tous trois liés à des problèmes d'extraction, corrigés puis rechargés.

Après la bascule, une période d’exploitation en parallèle de 30 jours a fait tourner les systèmes historiques et Salesforce simultanément. Des requêtes de comparaison automatisées ont confirmé la cohérence des données entre 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 pour de futurs programmes. La méthodologie de qualité des données (profiler, résoudre de manière déterministe, signaler les 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 l’activité commerciale de Sanofi pour les futures initiatives IA et Data Cloud. Des données propres avec pistes d’audit complètes sont le prérequis de l’automatisation intelligente. L’organisation commerciale est aujourd’hui sur une plateforme capable de supporter des agents Agentforce.

Recul

Ce motif fonctionne quand la rigueur réglementaire est la contrainte structurante et que la cible doit tenir un niveau de qualité supérieur à la source. Il fonctionne quand la direction accepte que la mission est la qualité des données, pas l’étape de chargement. Il fonctionne quand la conformité et l’IT peuvent rejoindre la conception du modèle canonique avant le démarrage des extractions.

Cela fonctionne moins bien quand l’org cherche une bascule plus rapide en reportant le travail de qualité après la migration. C’est le scénario que les régulateurs refusent et qui produit des années de remédiation en aval.

À faire plus tôt : le modèle canonique. Nommer les entités, les champs et les propriétaires avant le début de l’extraction supprime la plupart des arbitrages tardifs qui transforment les migrations régulées en risques de livraison.

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

0 Incidents de perte post-migration
1,2 M€ Coûts IT annuels supprimés
100 % Rapprochement source-cible

Glossaire

Modèle de données canonique
Une forme unique partagée pour chaque entité de base (professionnel de santé, compte, produit, interaction, consentement). Chaque système source s'y aligne ; le modèle fait foi, pas les systèmes.
Déduplication déterministe
Rapprochement de dossiers vers une seule entité réelle à partir de critères de règles (identifiant national, proximité nom plus adresse, code de spécialité). Chaque décision de rapprochement est consignée avec les critères utilisés, créant une piste d'audit pour la revue réglementaire.
Charger-valider-rapprocher
Chaque vague de migration charge un lot, exécute des requêtes automatisées comparant décomptes et valeurs entre source et cible, et résout les écarts avant le lot suivant. Un seul dossier non rapproché arrête la vague.
Période d'exploitation en parallèle
Après bascule, les systèmes historiques et la nouvelle plateforme tournent côte à côte sur une fenêtre fixée, avec des requêtes de comparaison automatisées. La validation du décommissionnement exige un rapprochement à 100 % sur cette fenêtre.

Questions fréquentes

  • Les systèmes sources n'étaient pas une définition fiable de ce que devait contenir un dossier. Trois d'entre eux étaient utilisés de manière incohérente. Mapper cible vers source après extraction aurait ancré la nouvelle plateforme dans la qualité héritée. Construire le modèle canonique d'abord, puis le faire valider par la conformité, le juridique et l'IT, donnait à chaque extraction et transformation une référence fixe. Les enregistrements ne tenant pas dans le schéma canonique apparaissaient comme du travail de remédiation, pas comme une dette de données silencieuse.
  • Chaque vague suivait un cycle chargement-validation-rapprochement. Des requêtes automatisées comparaient décomptes et valeurs entre source et cible. Tout lot dont le rapprochement échouait, ne serait-ce que pour un seul enregistrement, arrêtait la migration et déclenchait une investigation. Trois arrêts ont eu lieu pendant le programme. Les trois venaient d'erreurs d'extraction dans les systèmes historiques, pas de transformations ; ils ont été corrigés et rechargés avant la vague suivante.
  • Le profilage a identifié 12 000 enregistrements avec des champs obligatoires manquants. L'enrichissement automatisé depuis les registres publics de professionnels de santé a résolu la majorité. Les 847 résiduels ont suivi un processus de revue humaine structuré, avec des responsables de données nommés, avant migration. Aucun enregistrement n'a été chargé avec une correspondance non résolue. Chaque décision de revue a été documentée et reste disponible pour audit.
  • Oui. La méthodologie (profiler, résoudre de manière déterministe, signaler les résiduels pour revue humaine, documenter chaque décision) a été appliquée depuis à deux programmes de migration ultérieurs chez d'autres clients. Les connecteurs d'extraction, la logique de transformation et la suite de validation ont été packagés comme actifs réutilisables. La rigueur réglementaire apporte une discipline utile à toute migration ; en contexte commercial, elle va simplement plus vite parce que l'exigence d'audit est moindre.
  • Des données propres avec piste d'audit complète sont le prérequis de l'automatisation intelligente. Agentforce ne peut pas raisonner sur des identités fragmentées ou des enregistrements obsolètes. L'activité commerciale de Sanofi opère désormais sur une plateforme consolidée, avec des propriétaires d'entités nommés, des définitions canoniques et un monitoring de qualité en place. La couche de données est prête pour l'ingestion Data Cloud et pour des pilotes Agentforce capables de référencer l'état réel du client.

Réserver l'appel

On saura en 30 minutes
si je peux vous aider.

Pas de slides. Pas de pitch deck. Apportez le diagramme d'architecture ou décrivez le problème avec vos mots. Je vous dirai si je suis le bon profil et combien coûte la prochaine étape — avant que vous ayez fini votre café.

  1. Réponses sous 24 heures, toujours
  2. Si je ne suis pas le bon profil, je vous oriente vers quelqu'un qui l'est
  3. Aucune relance par email sauf si vous le demandez
Réserver un appel