Imaginez la scène. Un vendredi soir, votre directeur commercial vous appelle. Une partie de vos opportunités a disparu. Personne ne sait exactement ce qui s’est passé. La facturation est bloquée. Le pilotage des BU est à l’arrêt. Vous lancez une procédure de restauration. Trois jours plus tard, vous y êtes encore.
Ce scénario n’est ni rare, ni théorique. Il arrive chaque semaine à des entreprises qui croyaient sincèrement être protégées. La plupart pensaient que Salesforce s’occupait des sauvegardes. La plupart faisaient confiance au “weekly export”. Et la plupart découvrent, dans la panique, que ces filets de sécurité n’en sont pas.
Cet article explique pourquoi la majorité des entreprises sous-estiment massivement leur exposition au risque de perte de données Salesforce, et ce que font concrètement les organisations matures pour éviter le désastre.
Le mythe du CRM “sécurisé par défaut”
Salesforce est l’une des plateformes SaaS les plus sécurisées au monde. C’est vrai. Mais cette phrase rassurante cache une nuance critique que peu de DSI ont vraiment intégrée : le modèle de responsabilité partagée.
Salesforce s’occupe de la sécurité de la plateforme. L’infrastructure, le chiffrement en transit, la disponibilité, la résilience des datacenters. Tout cela est invisible et fonctionne très bien. C’est ce qui fait de Salesforce un leader incontesté.
En revanche, ce qui se passe à l’intérieur de votre instance relève de votre responsabilité. La configuration des droits, l’authentification multi-facteurs, la classification des données, la sauvegarde, le monitoring des comportements utilisateurs, l’anonymisation dans les sandbox. Salesforce met les outils à votre disposition. C’est à vous de les activer, de les configurer et de les opérer.
Le problème, c’est que la plupart des clients Salesforce ne sont pas éduqués sur cette frontière. Ils pensent que “tout est dans le cloud, donc tout est sauvegardé”. C’est faux. Et cette confusion coûte très cher quand l’incident arrive.
Pourquoi le weekly export ne protège pas votre entreprise
Le Data Export Service de Salesforce, communément appelé “weekly export”, est l’outil natif que beaucoup d’admins utilisent comme stratégie de sauvegarde principale. Il est gratuit, accessible depuis Setup, et donne l’impression d’avoir coché la case “backup”. C’est précisément ce qui le rend dangereux.
Une fenêtre de perte d’une semaine entière
Le weekly export tourne, comme son nom l’indique, une fois par semaine sur les éditions Enterprise, Performance et Unlimited. Sur les éditions inférieures, c’est une fois tous les 29 jours. Si une perte de données survient un jeudi, vous remontez à votre dernier export du dimanche précédent. Vous perdez 4 jours de création de données commerciales, de notes clients, d’avancées d’opportunités. Pour un commerce qui crée des centaines d’enregistrements par jour, c’est inacceptable.
Des CSV bruts sans relations ni métadonnées
L’export produit une archive ZIP contenant des fichiers CSV. Ces fichiers contiennent les données brutes, mais pas la structure. Pas les relations parent-enfant. Pas les métadonnées (workflows, validation rules, custom fields, layouts). Pas les configurations qui font fonctionner votre org.
En clair, vous avez les briques, mais pas le plan d’architecte. Reconstruire une instance à partir de ces CSV demande un travail manuel colossal de remappage des IDs, de reconstitution des relations, de réimport progressif. Là où une vraie solution de backup restaure en quelques heures, le weekly export demande des jours, voire des semaines.
Une fenêtre de téléchargement de 48 heures
Une fois l’export généré, vous avez 48 heures pour télécharger les fichiers avant qu’ils soient supprimés. Et depuis la release Winter ’26, Salesforce a ajouté une limite de débit : un seul fichier à la fois, avec une attente d’environ 60 secondes entre chaque téléchargement. Pour les grosses orgs dont l’export est découpé en plusieurs fichiers de 512 Mo, cela se traduit par des heures de monitoring manuel chaque semaine.
Aucune protection contre la corruption
C’est le point le plus mal compris. Le weekly export prend une photo de vos données à l’instant T. Si, dans la semaine, quelqu’un modifie en masse 50 000 enregistrements avec des valeurs incorrectes, l’export suivant photographiera la version corrompue. Vous n’avez plus aucun moyen de revenir en arrière sur les modifications individuelles.
Les vrais scénarios de perte de données
Quand on pose la question “qu’est-ce qui pourrait causer une perte de données dans votre Salesforce”, la plupart des DSI pensent à la suppression accidentelle. C’est le scénario le plus visible, mais c’est loin d’être le plus dangereux. Voici les quatre cas réels rencontrés sur le terrain.
La suppression malveillante interne
Un DSI qui apprend son licenciement et qui, avant de partir, supprime une partie significative des données Salesforce. Un commercial qui efface ses comptes pour empêcher son successeur de prendre le relai. Ce sont des cas concrets, observés régulièrement chez des clients Salesforce. La menace interne est probablement la plus sous-estimée du paysage cybersécurité.
La corruption massive de données
Le plus dangereux des scénarios, et de loin. Un développeur lance un script de mise à jour qui contient une erreur. Un flow mal testé écrase des milliers de champs. Une intégration buggée injecte des valeurs aberrantes dans toute la base. Les données ne sont pas supprimées, elles sont corrompues. Et c’est mille fois plus difficile à restaurer qu’une suppression simple.
Pourquoi ? Parce qu’une suppression laisse une trace claire (la donnée est dans la corbeille pendant 15 jours, puis disparaît). Une corruption masque l’historique sous des couches de modifications successives. Sans Field History Tracking étendu et sans une solution de backup capable de restaurer un état antérieur granulaire, vous êtes face à une situation quasiment impossible à débrouiller manuellement.
La fuite de données commerciales
Un commercial sait qu’il va partir à la concurrence. Il lance des exports massifs via Data Loader, ou prend des centaines de captures d’écran, ou exécute des rapports volumineux qu’il télécharge. Sans monitoring spécifique, son administrateur Salesforce ne saura jamais que ces actions ont eu lieu. Pendant ce temps, votre base de prospects, vos pipelines, vos prix, votre stratégie commerciale s’envolent chez votre concurrent direct.
L’attaque externe : la campagne UNC6040 / ShinyHunters
C’est la nouveauté préoccupante des deux dernières années. Le groupe que Google Threat Intelligence suit sous le nom UNC6040 (relié par la presse à ShinyHunters) s’est spécialisé dans l’attaque des instances Salesforce. Leur méthode n’exploite aucune faille de la plateforme. Ils utilisent du phishing vocal (vishing), de plus en plus souvent assisté par IA pour cloner des voix de dirigeants à partir de vidéos publiques.
Le scénario typique : un attaquant appelle un admin Salesforce en se faisant passer pour le support IT. Il l’amène progressivement, étape par étape, à installer une fausse application Data Loader connectée via OAuth. Une fois le token obtenu, l’attaquant extrait des volumes massifs de données et lance une demande de rançon.
Le bilan public est lourd, et largement documenté par la presse spécialisée. Google a confirmé en août 2025 (TechCrunch) qu’une de ses instances Salesforce avait été compromise. BleepingComputer rapporte que des marques du groupe LVMH (Louis Vuitton, Dior, Tiffany), Allianz Life et Qantas figurent parmi les victimes confirmées. Adidas, Pandora et Cisco ont également communiqué publiquement sur des incidents liés à cette campagne. La cible n’est plus la plateforme Salesforce elle-même, mais les défauts de configuration et le manque d’éducation des équipes sur l’ingénierie sociale.
Pourquoi restaurer Salesforce est beaucoup plus compliqué que prévu
Si Salesforce a racheté Own (anciennement OwnBackup) pour 1,9 milliard de dollars en 2024 (TechCrunch), ce n’est pas par hasard. C’est parce que la restauration d’une instance CRM complexe est un problème technique majeur. Si c’était simple, Salesforce aurait construit la solution en interne.
Quand on parle de restauration Salesforce, plusieurs difficultés s’accumulent.
Les relations entre objets. Un compte sans ses contacts ne sert à rien. Un contrat sans son opportunité non plus. Si vous restaurez les comptes mais pas les opportunités, ou si vous les restaurez dans le désordre, vous cassez la cohérence métier.
Les IDs Salesforce sont régénérés à chaque réimport. Cela signifie que toutes les références entre objets doivent être recalculées. Sur un volume de plusieurs millions d’enregistrements, cette opération devient un projet en soi.
Les métadonnées ne sont pas dans l’export. Si quelqu’un a supprimé un custom field, un workflow ou une page layout, le weekly export ne vous aidera pas. Vous devrez reconstruire à la main.
Le temps de restauration. Sur des cas réels documentés, restaurer 500 enregistrements à partir d’un weekly export demande facilement 8 heures de travail. Une org complète, des semaines. Pendant tout ce temps, votre activité commerciale est paralysée.
C’est pour cette raison qu’aucune solution développée en interne, aucune procédure manuelle, ne peut atteindre les niveaux de RPO (Recovery Point Objective) et RTO (Recovery Time Objective) qu’exige une activité critique.
Ce que font les entreprises matures
Les organisations qui ont compris l’enjeu adoptent une approche structurée en trois axes.
Définir formellement RPO et RTO
Combien de temps de création de données acceptez-vous de perdre ? Une journée ? Une heure ? Combien de temps acceptez-vous d’être sans CRM en cas d’incident ? Quatre heures ? Une journée ? Tant que ces chiffres ne sont pas validés par la direction métier, aucun choix d’outil ne peut être pertinent. Ce sont eux qui dictent le niveau d’investissement nécessaire.
Déployer une vraie solution de backup
Salesforce Backup & Recover (issu du rachat d’Own), Gearset, Odaseva, Spinbackup. Le marché propose plusieurs solutions matures, qui font toutes la même chose : sauvegarder données, métadonnées et relations, à fréquence quotidienne ou plus, avec une capacité de restauration granulaire et testable. Les tarifs ont fortement baissé ces dernières années. Sur des sujets aussi critiques, l’argument du coût ne tient plus. Pour comparer les options, la rubrique Security de Salesforce Ben publie régulièrement des analyses comparatives.
Un point souvent oublié : il faut tester la restauration. Régulièrement. Une sauvegarde qui n’a jamais été restaurée n’est qu’une promesse. Les entreprises matures organisent des exercices de récupération une à deux fois par an, sur un périmètre défini, pour mesurer leur RTO réel.
Activer Event Monitoring et Transaction Security Policies
Sans Event Monitoring, vous êtes aveugle sur ce qui se passe dans votre instance. Avec Event Monitoring, vous savez en temps réel qui consulte quoi, qui exporte quoi, qui se connecte d’où. C’est une caméra de surveillance numérique pour votre CRM.
Couplé aux Transaction Security Policies, vous pouvez automatiser des règles de protection. Un volume d’API sortant anormalement élevé ? Bloqué automatiquement. Une connexion depuis Paris suivie deux minutes plus tard d’une connexion depuis Moscou ? Bloquée. Un export de rapport au-delà d’un seuil ? Alerte immédiate à l’administrateur.
C’est exactement le type de garde-fou qui aurait permis de détecter les attaques UNC6040. Sans ces outils, votre équipe ne saura tout simplement rien avant de recevoir la demande de rançon.
Anonymiser les sandbox
Le RGPD interdit l’usage de données personnelles réelles dans des environnements de test. Les sandbox Salesforce sont par défaut des copies de production, donc remplies de données personnelles. Une solution comme Salesforce Shield et son module Data Mask automatise l’anonymisation à grande échelle. C’est un sujet de conformité que beaucoup d’entreprises remettent à plus tard, jusqu’au jour où la CNIL pose des questions.
Bonne nouvelle : si le budget Data Mask n’est pas votre priorité immédiate, il existe une alternative pragmatique. Chez Cloud Girafe, nous développons des scripts Apex sur mesure qui anonymisent les champs sensibles de vos sandbox (noms, emails, téléphones, adresses, données financières) en quelques minutes après chaque refresh. C’est moins industriel qu’une solution dédiée, mais c’est suffisant pour mettre votre conformité RGPD à niveau sans surcoût de licence. Si ce sujet vous concerne, parlons-en.
Conclusion : auditer avant de subir
Le risque de perte de données Salesforce n’est plus théorique. Les attaques externes explosent. Les menaces internes sont structurelles. Les erreurs humaines arrivent toutes les semaines. Et la plupart des entreprises sont équipées d’outils qui ne tiendront pas l’épreuve de la première vraie crise.
Le bon réflexe n’est pas d’attendre l’incident. C’est de poser un diagnostic objectif sur sa posture actuelle.
Chez Cloud Girafe, nous accompagnons les directions techniques et CRM à travers un audit Salesforce complet. Nous évaluons votre stratégie de sauvegarde, votre posture sécurité, votre gestion des droits, votre exposition aux menaces internes et externes. À l’issue de l’audit, vous repartez avec une vision claire de vos risques réels et un plan d’action priorisé.
Si vous lisez cet article en pensant “je crois qu’on est protégés, mais je ne suis pas sûr”, c’est probablement le bon moment pour en parler. Contactez-nous sur cloudgirafe.fr pour planifier un audit.
