Un besoin banal, une opération qui ne l'est pas
Réattribuer un portefeuille, corriger un secteur mal renseigné, appliquer une nouvelle nomenclature, marquer une population avant une campagne : la modification en masse est une demande hebdomadaire dans une org vivante.
Elle paraît anodine, et elle est pourtant l'une des opérations les plus risquées de l'administration courante. La raison est simple : elle touche beaucoup d'enregistrements d'un coup, elle déclenche tout ce qui est branché dessus, et elle ne se défait pas d'un clic.
Voici comment choisir la méthode, et surtout comment ne pas transformer une mise à jour de routine en incident.
Les quatre méthodes, et quand les utiliser
La modification depuis une vue en liste
La plus simple : vous filtrez une vue, vous modifiez une valeur, elle s'applique aux enregistrements sélectionnés. Pas d'outil, pas de fichier, aucun risque de mauvais rattachement.
C'est la bonne méthode pour quelques dizaines d'enregistrements et un seul champ à changer. Elle atteint ses limites au delà, et elle ne convient pas quand chaque enregistrement doit recevoir une valeur différente.
L'assistant d'importation
Intégré à Salesforce, il traite un fichier et convient bien aux objets standards. Il propose un rapprochement par identifiant ou par un champ que vous désignez comme clé.
C'est la bonne méthode pour un fichier propre, sur un objet courant, avec un volume raisonnable. Il ne couvre pas tous les objets, et il est moins précis que le Data Loader sur le comportement attendu.
Le Data Loader
L'outil de référence dès que le volume augmente ou que l'objet sort du cadre de l'assistant. Il gère l'insertion, la mise à jour, la mise à jour combinée à l'insertion, la suppression, et il produit systématiquement deux fichiers de résultat : les succès et les échecs.
Ces deux fichiers sont sa vraie valeur. Ils vous disent exactement ce qui est passé, ce qui a échoué et pourquoi. Conservez-les, ils constituent la trace de l'opération.
Le traitement planifié
Quand la même correction revient régulièrement, l'automatiser vaut mieux que la refaire. Un Flow planifié parcourt les enregistrements concernés à heure fixe et applique la règle.
C'est la bonne réponse aux besoins récurrents : requalifier des pistes dormantes, clôturer des opportunités dépassées, recalculer un indicateur. Attention toutefois aux volumes, un traitement mal construit se heurte aux limites de la plateforme.
Les cinq pièges
1. Les automatisations qui se déclenchent
C'est le piège principal, et le plus sous-estimé. Chaque enregistrement modifié déclenche les règles de validation, les Flows et les déclencheurs comme s'il avait été modifié à la main.
Conséquences classiques : trois mille emails partis en quelques minutes, un champ recalculé de travers sur toute la base, ou un traitement qui s'interrompt au milieu parce qu'une règle de validation refuse une ligne. Avant toute modification en masse, listez ce qui est branché sur l'objet concerné.
2. L'absence d'export préalable
Il n'y a pas d'annulation. Si vous écrasez la mauvaise colonne sur cinq mille lignes, la seule issue est de restaurer depuis un export fait avant.
Exportez donc systématiquement les enregistrements concernés, avec leur identifiant et les champs que vous allez toucher. Cet export est votre marche arrière, et il coûte deux minutes.
3. Le mauvais rattachement
Une mise à jour se rattache aux enregistrements par leur identifiant technique. Un fichier bâti sur un nom ou un email produit des rattachements approximatifs, donc des valeurs posées sur les mauvaises fiches.
Partez toujours d'un export Salesforce contenant les identifiants, plutôt que d'un fichier reconstitué depuis un tableur.
4. L'oubli du champ vide
Une cellule vide dans votre fichier ne signifie pas la même chose selon l'outil et le réglage : soit elle laisse la valeur existante, soit elle l'efface. Vérifiez ce comportement avant de lancer, sinon vous effacerez des données que vous vouliez simplement laisser tranquilles.
5. Le mauvais moment
Lancer une opération de masse en pleine journée, pendant que les commerciaux saisissent, produit des blocages et des conflits. Préférez une heure creuse, et prévenez les utilisateurs quand l'opération touche à ce qu'ils voient.
Attention également aux traitements planifiés de votre org. Si une automatisation nocturne parcourt les mêmes enregistrements, la lancer en même temps qu'un import crée des interférences difficiles à diagnostiquer. Vérifiez l'heure de vos traitements programmés avant de choisir votre créneau, c'est une minute de contrôle pour une soirée d'ennuis évitée.
La méthode sûre, en cinq temps
- 1. Exporter les enregistrements concernés, identifiants compris.
- 2. Recenser les automatisations branchées sur l'objet.
- 3. Tester dans une sandbox, ou à défaut sur dix enregistrements réels en production, et vérifier le résultat champ par champ.
- 4. Lancer l'opération complète en heure creuse, puis conserver les fichiers de résultat.
- 5. Contrôler avec un rapport bâti avant l'opération, qui doit afficher le résultat attendu.
L'étape trois est celle qu'on saute quand on est pressé, et c'est exactement celle qui évite la journée perdue. Dix enregistrements suffisent à révéler une automatisation oubliée ou un champ mal aligné.
Le cas particulier de la reprise de données
Importer une base venue d'ailleurs, un ancien outil ou un fichier commercial, obéit aux mêmes règles avec deux exigences supplémentaires.
Le dédoublonnage se fait avant l'import, pas après. Une fois les enregistrements créés, les doublons se fusionnent un par un, avec revue manuelle, ce qui coûte des jours. En amont, un tri dans le fichier prend une heure.
L'import se fait par lots, jamais d'un bloc. Commencez par cinquante lignes représentatives, vérifiez le résultat champ par champ, corrigez le fichier, puis lancez le reste. Un import de dix mille lignes mal cadré produit dix mille enregistrements à supprimer, et la suppression déclenche elle aussi des automatisations.
Pensez également à marquer les enregistrements importés, par un champ dédié ou une valeur de source. Cela paraît accessoire au moment de l'import, et c'est ce qui vous permettra six mois plus tard de mesurer ce que cette base a réellement produit, ou de la retirer proprement si elle s'avère décevante.
Enfin, prévenez que la reprise est en cours. Une modification en masse silencieuse fait apparaître des milliers d'enregistrements du jour au lendemain dans les vues des commerciaux, qui croiront à un bug.
Quand renoncer à la modification en masse
Deux situations doivent vous faire changer d'approche.
Si la même correction revient tous les mois, ce n'est plus un besoin de mise à jour, c'est un problème de saisie. Corrigez à la source, par un contrôle ou une valeur par défaut, plutôt que de repasser derrière indéfiniment.
Si l'opération exige une logique conditionnelle complexe, avec des exceptions et des dépendances entre enregistrements, un fichier n'est pas le bon véhicule. Un traitement construit dans l'org sera plus sûr, testable et rejouable.
Dans les deux cas, la question n'est plus de savoir comment modifier vite, mais pourquoi la donnée est fausse. C'est le même raisonnement que pour la qualité des données : traiter la cause coûte moins cher que traiter le symptôme tous les mois.
Questions fréquentes
Quel outil pour une mise à jour en masse dans Salesforce ?
La modification directe depuis une vue en liste pour quelques dizaines d'enregistrements, l'assistant d'importation pour un fichier simple, le Data Loader dès que le volume est important ou que l'objet n'est pas géré par l'assistant. Au delà, un traitement planifié devient préférable à une manipulation manuelle répétée.
Une modification en masse déclenche-t-elle les automatisations ?
Oui, dans la grande majorité des cas. Chaque enregistrement modifié déclenche les règles de validation, les Flows et les déclencheurs comme s'il avait été modifié à la main. C'est la première cause d'incident lors d'une mise à jour en masse, et la raison pour laquelle on teste toujours sur un échantillon.