Vous pensez que vos données Salesforce sont en sécurité. Que les sauvegardes existent. Que vos équipes sont vigilantes. Que vos contrôles d’accès sont à jour. Et puis un matin, votre directeur commercial vous appelle, paniqué. Une partie du pipeline a disparu. Personne ne sait ce qui s’est passé. La facturation est bloquée. Vos managers ne savent plus à qui appartiennent les comptes.
Ce n’est pas un cas d’école. Ce sont des appels que des DSI passent chaque semaine, en France comme ailleurs.
Voici les cinq scénarios catastrophe que vos données Salesforce peuvent réellement subir. Aucun n’est exotique. Tous sont déjà arrivés à des entreprises sérieuses, équipées, parfois cotées. Et la plupart auraient pu être évités.
Scénario 1 : la suppression — accidentelle ou volontaire
Mardi matin, 8h47. Un développeur lance un déploiement de routine entre la sandbox et la production. Le script contient une étape de nettoyage destinée à la sandbox uniquement. Mais il a copié-collé l’identifiant de la production dans le mauvais champ. Quinze secondes plus tard, 80 000 enregistrements de l’objet Opportunity disparaissent.
La corbeille Salesforce conserve les enregistrements 15 jours. Sur le papier, c’est confortable. Dans la réalité, les données sont liées à des contrats, des emails, des activités, des rapports. Restaurer 80 000 enregistrements en respectant la cohérence métier prend des jours, pas des minutes.
L’autre version du scénario est plus inquiétante : un commercial qui apprend son licenciement et qui, dans un dernier accès admin mal révoqué, supprime ses comptes. Un consultant externe dont le compte de service est resté actif six mois après la fin du projet. Un ancien DSI qui veut “laisser une trace” avant de partir.
Le vrai problème n’est pas de perdre la donnée. C’est de ne pas pouvoir la restaurer. Sans solution de backup capable de remonter une version cohérente datée d’avant l’incident, vous reconstruisez à la main. Pendant que vos commerciaux n’ont plus de pipeline.
Scénario 2 : la corruption massive de données — le pire des scénarios
Si la suppression vous fait peur, la corruption devrait vous terrifier.
Imaginez un Flow mal testé, déployé un vendredi à 18h. Un petit oubli dans une condition. Pendant le weekend, le Flow tourne. Il modifie 50 000 comptes en remplaçant la valeur d’un champ stratégique. Personne ne s’en rend compte avant le lundi matin, quand les commerciaux découvrent que tous leurs comptes “Grands Comptes” sont devenus “Prospects”. Les territoires sont cassés. Les commissions explosent. Les rapports affolent les directeurs.
Pourquoi c’est pire qu’une suppression ? Parce qu’une suppression laisse une trace claire : la donnée est dans la corbeille pendant 15 jours, puis disparaît. Une corruption, elle, masque l’historique sous des couches de modifications successives. Le Flow a peut-être déclenché des workflows. Ces workflows ont peut-être modifié d’autres objets. Les utilisateurs ont déjà commencé à corriger manuellement certaines fiches, créant une troisième couche de modifications.
Sans une vraie solution de backup capable de restaurer un état antérieur granulaire, vous êtes face à un puzzle quasiment impossible à résoudre. Le weekly export ne suffit pas : il photographie l’état corrompu si vous le générez après l’incident.
Sur des cas réels documentés, ce type d’incident peut paralyser une activité commerciale pendant 5 à 15 jours. Pour une entreprise qui fait 100 millions d’euros de chiffre d’affaires annuel, c’est entre 1,5 et 4 millions d’euros de pipeline gelé. Sans compter les conséquences indirectes : décisions stratégiques basées sur des données fausses, défiance des équipes, audits comptables, RGPD.
Scénario 3 : la fuite de données interne — le départ silencieux
Marc est commercial senior depuis huit ans. Il vient de signer chez votre concurrent direct. Il ne vous l’a pas encore dit. Il a un mois de préavis devant lui.
Pendant ce mois, Marc fait son métier comme d’habitude. Il consulte ses comptes. Il génère des rapports. Il télécharge des list views. Sauf que là, il en télécharge dix fois plus que d’habitude. Il exporte aussi des données auxquelles il n’a pas vraiment besoin d’accéder pour son périmètre actuel — par exemple les comptes de l’autre BU.
Sans Event Monitoring activé, son administrateur ne saura jamais que ces actions ont eu lieu. Aucun dashboard ne dira : “Marc a téléchargé 800 fiches cette semaine, contre 30 d’habitude.” Aucune Transaction Security Policy ne bloquera ses exports massifs. Le jour de son départ, votre base de prospects, vos pipelines, vos prix, votre stratégie commerciale partent avec lui.
Vous découvrirez peut-être le problème six mois plus tard, quand vos meilleurs clients commenceront à signer chez le concurrent. Ou jamais.
La menace interne est probablement la plus sous-estimée du paysage cybersécurité. Pas parce qu’elle est rare. Parce qu’elle est invisible quand on n’a rien mis en place pour la voir.
Scénario 4 : l’attaque externe ciblée — UNC6040 et ShinyHunters
Mercredi 14h32. Votre admin Salesforce reçoit un appel. À l’autre bout du fil, une voix calme se présente comme le support IT interne. L’interlocuteur connaît le nom de votre DSI. Il connaît même le nom du dernier ticket ouvert. Il dit qu’il y a un problème d’authentification sur une intégration et qu’il a besoin que l’admin valide une connexion OAuth pour le résoudre. Cinq minutes. Rien d’inhabituel.
L’admin valide. Il ne voit aucune raison de douter. La connexion OAuth porte un nom rassurant, “Salesforce Data Loader”. Il ne sait pas que c’est une fausse application configurée par un attaquant. Le token OAuth émis donne un accès permanent à son instance, sans MFA. Et ce token, l’attaquant l’a maintenant en main.
Pendant les 72 heures suivantes, depuis un serveur en Asie, l’attaquant utilise ce token pour exfiltrer plusieurs millions d’enregistrements. Sans restriction IP, sans Transaction Security Policy plafonnant le volume API, rien ne s’interrompt. Trois mois plus tard, votre DSI reçoit un email avec un échantillon de vos données et une demande de rançon en cryptomonnaie.
Ce scénario n’est pas hypothétique. Google Threat Intelligence le suit sous le nom UNC6040. La presse spécialisée le relie au groupe ShinyHunters. Les victimes confirmées en 2025 incluent Google (TechCrunch), les marques du groupe LVMH (BleepingComputer), Adidas, Pandora, Allianz Life, Qantas et Cisco. Des entreprises avec des budgets cybersécurité considérables, qui n’ont pas vu venir l’attaque parce que celle-ci n’exploite aucune faille technique de Salesforce. Elle exploite la confiance.
Scénario 5 : le phishing vocal IA — quand le CEO est un deepfake
Vendredi 16h. Sandra, votre admin Salesforce, est sur le point de partir en weekend. Son téléphone sonne. C’est votre CEO. Sa voix est reconnaissable, son ton est pressé. Il dit qu’il est en réunion conseil d’administration, qu’il a besoin du rapport “Top 100 Clients” envoyé immédiatement à un email externe pour un investisseur stratégique. Il insiste : “C’est urgent, je n’ai pas le temps d’expliquer.”
Sandra connaît son CEO. Elle reconnaît sa voix. Elle exécute.
Sauf que ce n’était pas votre CEO. Quelques secondes d’audio public — une interview podcast, une vidéo LinkedIn, une keynote — ont suffi pour cloner sa voix. L’attaquant a ensuite passé un appel depuis un numéro maquillé qui ressemble à un poste interne. Le rapport “Top 100 Clients” est maintenant entre les mains d’un groupe qui le revendra ou s’en servira pour vous attaquer commercialement.
Ce scénario n’est pas de la science-fiction. CNN a documenté en février 2024 une attaque où un employé du cabinet d’ingénierie britannique Arup, à Hong Kong, a transféré environ 25 millions de dollars après une visioconférence où plusieurs participants — dont un faux CFO — étaient des deepfakes générés par IA. Aucune faille technique. Une simple confiance humaine, exploitée par une vidéo synthétique convaincante.
L’IA a démocratisé une menace qui était jusqu’ici réservée aux services de renseignement. Aujourd’hui, n’importe quel attaquant motivé peut cloner la voix de votre CEO en cinq minutes avec un outil grand public.
Pourquoi ces scénarios arrivent vraiment
Trois failles structurelles permettent à ces scénarios de se reproduire en boucle.
Le manque de gouvernance des accès. Dans la plupart des instances Salesforce qui ont quelques années, on retrouve des dizaines d’utilisateurs avec des permissions trop larges, des comptes de service oubliés, des connected apps ajoutées sans validation, des prestataires dont l’accès n’a jamais été révoqué. Chaque accès en trop est une porte ouverte.
La mauvaise configuration. MFA non enforcée correctement, pas de restrictions IP, sharing model trop permissif, profils clonés qui héritent de droits inutiles, Field History Tracking désactivé sur des champs critiques. Aucune de ces erreurs n’est exotique. Toutes sont évitables. Pratiquement toutes les attaques 2025 sur Salesforce les exploitent.
L’absence totale de monitoring. Sans Event Monitoring, votre équipe sécurité est aveugle sur ce qui se passe dans votre instance. Pas en partie. Totalement. Personne ne saura qu’un commercial exporte 800 fiches par jour. Personne ne saura qu’une connected app inconnue siphonne votre base via API. Personne ne saura qu’un admin se connecte depuis un pays où vous n’avez aucun salarié.
Et c’est exactement ça que les attaquants cherchent : la zone aveugle.
Comment éviter ces situations
Aucune solution miracle. Mais une combinaison cohérente de quatre piliers réduit drastiquement votre exposition.
1. Une vraie stratégie de sauvegarde
Le weekly export Salesforce ne suffit pas. Il faut une solution capable de sauvegarder données, métadonnées et relations à fréquence quotidienne, avec restauration granulaire et testable. Salesforce Backup & Recover, Gearset, Odaseva ou équivalent. Et surtout : tester la restauration au moins une fois par an. Une sauvegarde non testée n’est qu’une promesse.
2. Event Monitoring + Transaction Security Policies
Event Monitoring vous donne la visibilité temps réel sur les actions sensibles : connexions, exports, accès, requêtes API. Couplé aux Transaction Security Policies, vous passez de la détection à la prévention automatique : bloquer un export massif, exiger une MFA sur une action sensible, couper une connexion géographiquement impossible. C’est exactement le type de garde-fou qui aurait stoppé les attaques UNC6040 décrites plus haut.
3. Une gouvernance formalisée des accès
Qui a le droit de demander quoi. Qui valide. Qui révoque. Sous quels délais. Les nouveaux arrivants reçoivent un profil minimal et obtiennent des permissions additionnelles uniquement sur justification. Les départs déclenchent une désactivation immédiate. Les prestataires ont un accès limité dans le temps. Une revue trimestrielle des permissions élimine progressivement la dérive.
4. Un audit régulier de la posture sécurité
Au minimum une fois par an, idéalement après chaque release majeure. Cet audit balaie profils, permission sets, connected apps, OWD, configurations sécurité (MFA, IP, sessions), sites Experience Cloud, comptes de service. L’outil natif Health Check de Salesforce donne un premier score, mais ne suffit pas. Une expertise humaine est nécessaire pour relier les configurations aux risques métier réels.
Conclusion : ce n’est pas une question de SI, c’est une question de QUAND
Si vous lisez cet article jusqu’ici, vous avez probablement reconnu un ou deux scénarios qui vous concernent directement. Vous savez qu’un commercial est sur le départ. Vous savez qu’un Flow critique a été déployé sans tests rigoureux. Vous savez que votre admin Salesforce reçoit régulièrement des appels suspects.
La question n’est plus de savoir si votre instance Salesforce sera ciblée. C’est de savoir quand. Et si, ce jour-là, vous serez préparé.
Chez Cloud Girafe, nous accompagnons les directions techniques et CRM dans l’audit complet de leur posture sécurité Salesforce. Nous évaluons votre stratégie de sauvegarde, votre monitoring, votre gestion des accès, vos configurations critiques. À 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 ne suis pas sûr que nous soyons préparés”, c’est probablement le bon moment pour en parler. Contactez-nous sur cloudgirafe.fr pour planifier un audit Salesforce.
