Migration de données CRM : CSV, ETL ou API — quelle méthode choisir ?

La question n'est pas 'quelle méthode est la meilleure ?' mais 'quelle méthode correspond à votre contexte ?'. Un import CSV est parfaitement adapté à une migration simple de 20 000 contacts depuis un fichier Excel. Un ETL devient indispensable dès que plusieurs systèmes sources alimentent le CRM cible avec des transformations complexes. Une migration par API s'impose lorsque la tolérance à la coupure est quasi nulle et que les règles métier sont trop spécifiques pour être gérées par un outil de mapping standard.

Vue d'ensemble : tableau de décision

• CSV / import natif — Idéal pour : migration simple et ponctuelle, peu de systèmes sources, transformations limitées. Limites : relations complexes difficiles à reconstituer, pas d'automatisation possible, 50 000 enregistrements par lot maximum sur Salesforce Data Import Wizard.
• ETL / iPaaS (MuleSoft, Informatica, Talend…) — Idéal pour : plusieurs systèmes sources (ERP + CRM + fichiers), gros volumes, transformations et règles de qualité complexes. Limites : mise en place plus lourde, coût de licence, expertise requise.
• API / script custom — Idéal pour : règles métier très spécifiques, migration incrémentale (delta load), automatisation complète. Limites : développement et maintenance, gestion des erreurs à implémenter soi-même.

Modèle 1 — CSV et import natif

Architecture : Ancien CRM → export CSV → nettoyage + mapping → import CRM cible.

C'est la méthode la plus directe. Elle convient à une migration ponctuelle sur un périmètre bien délimité : comptes et contacts sans historique complexe, peu de relations entre objets, équipe sans ressources techniques dédiées. Sur Salesforce, le Data Import Wizard prend en charge cette approche pour les objets standards (Contacts, Leads, Comptes, Opportunités, membres de Campagne) jusqu'à 50 000 enregistrements par import.

Les pièges à éviter : les encodages (toujours exporter en UTF-8), les formats de date (vérifier le format attendu par le CRM cible), les valeurs de picklist qui n'existent pas encore dans le nouveau CRM (elles seront rejetées), et les relations qui requièrent que l'objet parent soit déjà importé.

Modèle 2 — ETL et iPaaS

Architecture : CRM + ERP + fichiers divers → ETL → couche de transformation et validation → CRM cible.

L'ETL (Extract, Transform, Load) devient le point central d'orchestration quand les données viennent de plusieurs sources hétérogènes. Exemple concret : SAP (données financières et adresses), ancien CRM (contacts et opportunités), fichiers Excel de l'équipe terrain, plateforme e-commerce (historique d'achat) → Salesforce. L'ETL extrait chaque source, applique les règles de transformation centralisées, valide la qualité des données (déduplication, normalisation des téléphones, vérification des emails) et pousse le résultat vers Salesforce via l'API Bulk.

MuleSoft, qui est l'iPaaS de référence dans l'écosystème Salesforce, propose un connecteur natif capable de créer des jobs Bulk API v2 pour des opérations insert, update, delete et upsert. Cela permet de gérer des volumes de plusieurs centaines de milliers d'enregistrements avec un suivi des erreurs ligne par ligne.

Modèle 3 — API et script custom

Architecture : Système source → script d'extraction → moteur de transformation → API CRM cible.

La migration par API est la plus flexible et la seule qui permette d'implémenter une migration incrémentale (delta load) pour réduire au maximum la fenêtre de coupure.

Migration incrémentale et delta load

Le principe du delta load est simple : au lieu de tout migrer le jour J, on découpe la migration en phases :

• J-7 : migration complète de l'historique (toutes les données jusqu'à J-7).
• J-1 : migration des modifications intervenues entre J-7 et J-1 (premier delta).
• Jour J, 6h : migration du delta final (dernières modifications).
• Jour J, 8h : bascule — le nouveau CRM est en production, l'ancien est en lecture seule pendant 48h.

Cette approche réduit la coupure à quelques heures au lieu d'un week-end entier. Elle nécessite que le système source dispose d'un champ de date de modification fiable (LastModifiedDate dans Salesforce, updated_at dans la plupart des bases SQL) pour filtrer uniquement les enregistrements modifiés depuis le dernier delta.

Les concepts techniques à maîtriser pour une migration API robuste : batch processing (traiter les enregistrements par lots de 200 à 2000 pour respecter les limites API), retry avec backoff exponentiel (réessayer automatiquement en cas d'erreur 429 ou 503), logs structurés (garder la trace de chaque enregistrement migré et de chaque erreur), idempotence (s'assurer qu'une ligne migrée deux fois ne crée pas de doublon — c'est le rôle de l'External ID et de l'opération upsert).

Comment choisir ?

• Moins de 50 000 enregistrements, une seule source, transformations simples → CSV + import natif.
• Plusieurs sources, règles de transformation complexes, équipe avec budget intégration → ETL / iPaaS.
• Tolérance à la coupure < 4h, règles métier très spécifiques, équipe technique disponible → script API avec delta load.
• Projet Salesforce complexe avec données + métadonnées → combiner ETL pour les données et Metadata API / Salesforce CLI pour les configurations.

Pour les projets Salesforce spécifiquement, consultez notre comparaison détaillée des outils natifs : Migration Salesforce — Data Import Wizard, Data Loader, Bulk API ou ETL ?