Comment charger des données dans Salesforce : Data Loader ou script ?

Ce que Data Loader fait bien

Data Loader est l'outil officiel de Salesforce pour insérer, mettre à jour, upserter, supprimer ou exporter des enregistrements à partir de fichiers CSV. Il gère le mapping de colonnes, l'authentification et plusieurs modes d'API : SOAP, par lots de 200 enregistrements au plus ; Bulk, par lots jusqu'à 10 000 ; et Bulk 2.0 dans ses versions récentes, où Salesforce découpe lui-même les lots.

• Imports ponctuels de quelques milliers à quelques centaines de milliers de lignes.
• Opérations simples sans transformation : les données arrivent déjà prêtes.
• Équipes qui préfèrent une interface graphique et des fichiers de mapping réutilisables.
• Exécution en ligne de commande possible pour planifier des chargements récurrents.

Ses limites

Data Loader charge ce qu'on lui donne. Il ne transforme rien, ne résout pas les relations entre objets à votre place et ne garde pas de mémoire d'une exécution à l'autre.

• Chaque exécution produit un fichier de succès et un fichier d'erreurs : la reprise consiste à corriger et recharger ces fichiers à la main.
• Les chargements dépendants demandent plusieurs exécutions successives, avec report manuel des identifiants créés.
• La ligne de commande se configure par fichiers XML, peu lisibles et difficiles à versionner proprement.

Quand un script Python devient nécessaire

Un script Python, avec une bibliothèque comme simple-salesforce ou un appel direct aux API REST et Bulk 2.0, prend le relais dès que le chargement n'est plus une simple copie de fichier.

• Transformations à la volée : normalisation des formats, calcul de champs, résolution de références par External ID.
• Chargements dépendants : créer les comptes, récupérer leurs identifiants, puis charger les contacts en une seule exécution.
• Reprise sur erreur : relancer uniquement les lignes en échec, avec un journal détaillé par lot.
• Fichiers et pièces jointes : migrer des documents vers Salesforce Files ou vers un stockage externe comme SharePoint, en gardant le lien avec l'enregistrement.
• Volumes élevés : l'API Bulk 2.0 accepte des fichiers CSV volumineux et traite les lots côté serveur, de façon asynchrone.

Les autres options

• L'assistant d'importation de données, intégré à Salesforce : simple, limité à 50 000 enregistrements par import et à certains objets.
• Les outils ETL et d'intégration du marché : utiles quand les chargements deviennent récurrents et doivent être supervisés au même endroit que les autres flux.
• Les outils en ligne bâtis sur les API Salesforce : pratiques pour des imports planifiés sans infrastructure à maintenir.

Les règles communes à tous les outils

Quel que soit l'outil, les bonnes pratiques sont les mêmes. Utiliser des External ID et des upserts plutôt que des inserts aveugles, pour pouvoir rejouer un chargement sans créer de doublons. Tester d'abord dans un sandbox avec un échantillon représentatif, puis avec le volume complet.

Pendant les chargements de masse, les flows, triggers et règles de validation se déclenchent sur chaque enregistrement. Une permission personnalisée, vérifiée par ces automatisations, permet de les contourner pour l'utilisateur de chargement uniquement, sans toucher au paramétrage.

Enfin, conserver un journal de chaque exécution : date, utilisateur, fichier source, nombre de lignes traitées, identifiants créés, erreurs. C'est ce journal qui rend possible un retour arrière propre.

Comment choisir

• Import ponctuel, données déjà propres, un seul objet : assistant d'importation ou Data Loader.
• Plusieurs objets liés, transformations, reprises à prévoir : script versionné.
• Chargements récurrents à superviser : outil d'intégration, ou script planifié avec alertes.

Dans une migration, les deux cohabitent souvent : Data Loader pour les vérifications et les objets de référence, des scripts pour tout ce qui doit être rejoué. Le cadre complet est décrit dans le guide pour migrer ses données vers Salesforce.