Salesforce en panne, cela se vérifie en une minute sur status.salesforce.com, en cherchant le nom de votre domaine : si votre instance est en « Service Disruption », aucun réglage chez vous n’y changera rien et il faut basculer sur vos procédures de secours. Si elle est au vert, le blocage vient presque toujours d’ailleurs : le fournisseur d’identité qui gère le SSO, une restriction d’adresses IP, un compte verrouillé ou un navigateur encombré. Dans ce cas, la connexion par l’URL My Domain de votre entreprise, en navigation privée, règle la majorité des situations.
En bref : la solution rapide
- Ouvrez status.salesforce.com depuis votre téléphone en 4G et cherchez votre domaine ou votre instance. Rouge ou orange : c’est Salesforce, attendez et prévenez l’équipe.
- Instance au vert : connectez-vous par votre adresse My Domain (du type
https://votreentreprise.my.salesforce.com) dans une fenêtre de navigation privée. - Si la page de connexion de l’entreprise (SSO) tourne dans le vide, l’administrateur peut tenter l’adresse My Domain suivie de
/?loginpour s’identifier avec son mot de passe Salesforce. - Côté intégrations, mettez les appels en file d’attente et laissez les relances s’espacer. Marteler l’API pendant une panne ne fait qu’allonger le retour à la normale.
- Notez sur un tableur ce qui ne peut pas attendre. Vous le ressaisirez ensuite.
Reconnaître le problème
La page de connexion s’affiche, vous validez, et le navigateur mouline jusqu’à une page blanche ou une erreur 503. Les collègues déjà connectés continuent parfois à travailler quelques minutes, puis sont éjectés à leur tour. Les outils branchés sur le CRM remontent des erreurs en cascade. Et quand vous cherchez à ouvrir un ticket, le portail d’aide réclame la même connexion que celle qui ne répond plus.
Trois familles de causes se cachent derrière ces symptômes, et la marche à suivre diffère pour chacune.
| Message ou comportement | Où il apparaît | Ce qu’il indique le plus souvent |
|---|---|---|
| Page blanche, délai dépassé, erreur HTTP 502 ou 503 | Navigateur, tout le monde en même temps | Instance ou service de connexion Salesforce indisponible ou surchargé |
| « Please check your username and password. If you still can’t log in, contact your Salesforce administrator. » | Page de connexion | Identifiant ou mot de passe erroné, compte verrouillé, ou connexion refusée par une restriction IP ou horaire (le message reste volontairement vague) |
| « We can’t log you in because you’re only allowed to use single sign-on » | Page de connexion Salesforce | Votre compte est limité au SSO : passez par le portail de l’entreprise |
| Erreur affichée sur une page qui n’est pas celle de Salesforce (portail Microsoft, Okta, Google…) | Avant d’arriver sur Salesforce | Problème chez le fournisseur d’identité, pas chez Salesforce |
REQUEST_LIMIT_EXCEEDED (HTTP 403) | Journaux d’une intégration | Quota d’appels API ou limite de requêtes simultanées dépassé |
SERVER_UNAVAILABLE (HTTP 503) | Journaux d’une intégration | Serveur nécessaire à l’appel indisponible ou saturé |
UNABLE_TO_LOCK_ROW | Imports, automatisations, API | Deux traitements modifient les mêmes enregistrements en même temps |
Les libellés de l’interface changent selon la langue et la version. Retenez les codes en majuscules, eux ne bougent pas.
Pourquoi cela se produit
Salesforce n’est pas un bloc unique. Chaque client est hébergé sur une instance, c’est-à-dire un groupe de serveurs partagé avec d’autres entreprises. Les instances historiques portent des noms courts (préfixes NA, EU, AP, CS pour les sandbox) ; celles de Hyperforce, l’infrastructure de Salesforce bâtie sur le cloud public, sont nommées d’après un pays suivi d’un numéro. Une panne touche rarement toute la planète : elle frappe une instance, une région ou un service précis.
Le service d’authentification est le maillon le plus sensible. S’il sature, vos données sont intactes mais personne ne peut plus entrer, ni les humains, ni les intégrations dont le jeton vient d’expirer, ni vous-même sur le portail d’aide.
Deuxième cause, très fréquente en entreprise : le SSO (authentification unique). Vous vous identifiez auprès d’un fournisseur d’identité, qui se porte garant auprès de Salesforce. Si ce fournisseur tombe, ou si son certificat a expiré, Salesforce fonctionne parfaitement et vous restez dehors.
Dernière famille, la plus banale : le local. Cookies corrompus, proxy d’entreprise, adresse IP non autorisée par votre profil, tentative hors des heures de connexion, compte verrouillé après trop d’essais.
Avant de commencer
Récupérez trois informations, idéalement notées ailleurs que dans Salesforce : votre adresse My Domain, le nom de votre instance, et le nom d’un administrateur joignable par téléphone. L’instance se lit dans Configuration (Setup) > Informations sur la société, ou se retrouve en saisissant votre domaine dans la recherche du site Trust.
Ne réinitialisez pas votre mot de passe par réflexe pendant une panne. L’e-mail risque de ne pas arriver, et vous ajouterez un second problème au premier.
Solution 1 : vérifier l’état de votre instance sur Salesforce Trust
À faire en premier, par tout le monde. Aucun risque.
1. Trouver votre instance
Ouvrez status.salesforce.com. Saisissez dans le champ de recherche votre domaine (la partie avant .my.salesforce.com) ou le nom de l’instance, puis cliquez sur le résultat.
2. Lire le statut
Quatre états existent. « Available » : le service fonctionne. « Performance Degradation » : il répond, mais lentement. « Service Disruption » : il est indisponible. « Maintenance » : intervention planifiée.
3. Tenir compte du décalage
Salesforce se fixe pour objectif de publier sur Trust dans les dix minutes qui suivent la détection d’un incident critique, puis de mettre à jour au moins toutes les trente minutes. Dans les premières minutes, la page peut donc rester verte alors que tout est déjà bloqué. Si dix collègues sont éjectés en même temps sur des réseaux différents, considérez que c’est une panne et rechargez Trust un quart d’heure plus tard.
Solution 2 : passer par votre URL My Domain
Pour les utilisateurs, quand Trust est au vert. Aucun risque.
Beaucoup de personnes se connectent encore par login.salesforce.com, par habitude ou via un vieux favori. Or un administrateur peut interdire cette porte d’entrée dans les réglages My Domain (option « Prevent login from https://login.salesforce.com »). Le symptôme est déroutant : le mot de passe est bon, la connexion échoue.
Saisissez directement https://votreentreprise.my.salesforce.com. Si vous ignorez votre domaine, cherchez-le dans un ancien e-mail de notification Salesforce.
Comment vérifier : la page affiche le logo ou le bouton SSO de votre entreprise.
Solution 3 : écarter le navigateur et le réseau
À tenter quand vous êtes seul touché. Risque nul, hormis la perte des sessions enregistrées si vous videz tout.
1. Navigation privée
Ouvrez une fenêtre privée (Ctrl+Maj+N dans Chrome et Edge, Ctrl+Maj+P dans Firefox) et reconnectez-vous. Si cela passe, un cookie ou une extension est en cause.
2. Cookies du site
Supprimez les cookies et le cache des domaines salesforce.com et force.com, puis testez un second navigateur.
3. Autre réseau
Basculez sur le partage de connexion du téléphone. Deux résultats possibles, tous deux instructifs. Si cela fonctionne en 4G et pas au bureau, le proxy ou le pare-feu de l’entreprise bloque. Si cela fonctionne au bureau et pas en 4G, votre profil est sans doute limité à une plage d’adresses IP : c’est voulu, et seul l’administrateur peut l’assouplir.
Solution 4 : l’application mobile et la session déjà ouverte
Quand seule l’authentification est en panne, une session déjà ouverte reste souvent utilisable. Ne vous déconnectez pas, ne fermez pas l’onglet, ne videz rien.
L’application mobile Salesforce garde par ailleurs en cache les enregistrements consultés récemment, à condition que l’administrateur ait laissé la mise en cache hors ligne activée et que vous ayez ouvert l’application avant l’incident. De quoi retrouver un numéro de téléphone ou un montant, pas saisir une journée de travail.
Solution 5 (administrateur) : contourner le SSO
À utiliser quand le fournisseur d’identité est en panne et que Trust est au vert.
1. Se connecter sans le fournisseur d’identité
Ajoutez /?login à la fin de votre adresse My Domain : https://votreentreprise.my.salesforce.com/?login. La page affiche alors le formulaire classique, identifiant et mot de passe Salesforce. La variante ?login=true circule aussi.
2. Comprendre pourquoi cela échoue parfois
Le contournement ne marche que pour les comptes qui n’ont pas l’autorisation « Is Single Sign-On Enabled » (« L’authentification unique est activée ») dans leur profil ou leur ensemble d’autorisations. Les autres voient s’afficher le refus cité dans le tableau. C’est la raison pour laquelle la bonne pratique consiste à ne jamais fédérer les administrateurs système : ils gardent un mot de passe Salesforce robuste, protégé par l’authentification à plusieurs facteurs.
3. Rouvrir l’accès aux utilisateurs
Une fois entré, vous pouvez retirer temporairement l’autorisation SSO d’un groupe d’utilisateurs clés et leur envoyer un lien de réinitialisation de mot de passe. Vous abaissez alors le niveau de sécurité : consignez la manipulation et annulez-la dès le retour du fournisseur d’identité.
Attention : si aucun compte administrateur n’échappe au SSO, il n’existe pas de porte dérobée. Seul le support Salesforce pourra vous aider, après vérification de votre identité.
Solution 6 (administrateur) : restrictions IP, heures de connexion, compte verrouillé
Quand un seul utilisateur ou une seule équipe est bloqué.
1. Lire l’historique des connexions
Dans Configuration, tapez « Historique des connexions » (Login History) dans la recherche rapide. Chaque tentative y figure avec son statut, son adresse IP et son type de connexion. Le message flou de la page de connexion y devient explicite : mot de passe invalide, adresse IP restreinte, verrouillage.
2. Vérifier les plages IP et les horaires
Configuration > Profils > le profil concerné > Plages IP de connexion. Hors de ces plages, la connexion est refusée sans aucun recours par code de vérification. Cas classique : le fournisseur d’accès a changé l’adresse IP publique du bureau. Les plages définies dans Configuration > Accès réseau fonctionnent autrement : hors plage, l’utilisateur doit simplement confirmer son identité par un code. Regardez aussi les Heures de connexion du profil.
3. Déverrouiller l’utilisateur
Configuration > Utilisateurs, ouvrez la fiche : le bouton Déverrouiller n’apparaît que si le compte est verrouillé. La durée de blocage et le nombre d’essais se règlent dans Configuration > Stratégies de mot de passe.
Solution 7 : protéger les intégrations et les API
Pour les administrateurs et les prestataires, pendant et après la panne.
- Relances espacées : Salesforce recommande, face à
SERVER_UNAVAILABLE, une relance à délai exponentiel (1 seconde, 2, 4, 8…). Ajoutez un plafond et un peu d’aléa pour que tous vos traitements ne repartent pas à la même seconde. - File d’attente : stockez les messages sortants (formulaires web, commandes, leads) au lieu de les perdre.
- Idempotence : pour qu’une relance ne crée pas de doublon, utilisez un identifiant externe et l’opération upsert plutôt qu’une création simple.
- Quotas : une vague de relances peut épuiser le quota d’appels API sur 24 heures et provoquer
REQUEST_LIMIT_EXCEEDEDune fois la panne terminée. Surveillez la ressource REST/services/data/vXX.X/limits/et l’en-tête de réponseSforce-Limit-Info. La limite de requêtes longues simultanées (20 secondes et plus) est de 25 en production. - Verrous :
UNABLE_TO_LOCK_ROWsurgit au rattrapage, quand plusieurs lots modifient en parallèle des enregistrements rattachés au même parent. Traitez en série, ou triez les lots par compte parent.
Solution 8 : joindre le support quand le portail est inaccessible
Pendant une panne d’authentification, le portail d’aide devient inutilisable puisqu’il repose sur la même connexion. Restent le téléphone et votre interlocuteur commercial. Salesforce France affiche sur sa page de contact le numéro +33 (0)805 082 131 ; les autres pays ont leur page de contact régionale.
Préparez avant d’appeler : l’identifiant de l’organisation (15 ou 18 caractères commençant par 00D), le nom de l’instance, l’heure de début, le nombre d’utilisateurs touchés et l’impact métier chiffré. Pendant un incident général, n’attendez pas de diagnostic individuel : le support renvoie vers Trust. L’appel sert surtout à tracer votre signalement.
Tableau récapitulatif
| Symptôme | Cause probable | Solution à essayer |
|---|---|---|
| Tout le monde est bloqué, Trust en rouge | Panne de l’instance ou de l’authentification | Solution 1, puis procédures de secours |
| Blocage sur le portail d’identité de l’entreprise | Fournisseur d’identité ou certificat SSO | Solution 5 |
| Mot de passe correct, connexion refusée par login.salesforce.com | Connexion générique interdite | Solution 2 |
| Un seul utilisateur bloqué, partout | Compte verrouillé, mot de passe, MFA | Solution 6 |
| Connexion possible au bureau, pas à l’extérieur | Plages IP du profil | Solution 6 |
Erreurs 503 ou SERVER_UNAVAILABLE dans les flux | Serveurs saturés | Solution 7, relances espacées |
REQUEST_LIMIT_EXCEEDED après la panne | Quota API consommé par les relances | Solution 7, lissage des reprises |
Si rien ne fonctionne
Acceptez la panne et organisez le travail sans le CRM. Un tableur partagé suffit, à condition d’imposer les mêmes colonnes à tous : date et heure, nom du compte, contact, action réalisée, montant, prochaine étape.
Une fois le service revenu, procédez dans l’ordre. Ressaisissez ou importez le tableur de secours. Vérifiez ensuite les automatisations : flux planifiés qui n’ont pas tourné, e-mails en attente, tâches Apex planifiées, synchronisations tierces. Contrôlez les doublons créés par les relances. Puis demandez à Salesforce le compte rendu d’incident.
Sur la compensation, mieux vaut être lucide. Le contrat standard engage Salesforce à déployer des efforts commercialement raisonnables pour une disponibilité 24 heures sur 24, sans taux garanti ni avoir automatique. Un crédit n’est dû que si votre contrat comporte un engagement de niveau de service négocié. Relisez votre bon de commande, puis adressez votre demande par écrit à votre responsable de compte, avec les horaires relevés sur Trust.
Éviter que cela se reproduise
Abonnez-vous aux notifications Trust de votre instance : aucune licence n’est nécessaire, une adresse partagée de l’équipe convient.
Programmez l’export de données : Configuration > Export de données > Planifier l’export. La fréquence est hebdomadaire en éditions Enterprise, Performance et Unlimited, mensuelle en Professional. Le lien de téléchargement expire au bout de 48 heures : confiez à quelqu’un la tâche de récupérer les fichiers. Cet export ne restaure rien tout seul. Pour une vraie reprise, regardez l’option payante de sauvegarde de Salesforce ou un outil tiers.
Gardez deux comptes administrateurs hors SSO et surveillez la date d’expiration du certificat SSO.
Rédigez enfin une fiche de continuité d’une page : qui déclare la panne, par quel canal l’équipe est prévenue, où se trouve le tableur de secours, qui appelle le support, qui pilote le rattrapage. Imprimez-la.
Questions fréquentes
Mes données sont-elles perdues pendant une panne ?
Non, dans l’immense majorité des cas. Une panne d’accès empêche d’entrer, elle n’efface rien. Ce qui se perd, ce sont les saisies en cours non enregistrées et les messages d’intégrations sans file d’attente.
Trust est au vert mais personne n’arrive à se connecter, pourquoi ?
Soit l’incident n’est pas encore publié, soit le problème se situe chez votre fournisseur d’identité ou sur votre réseau. Testez l’adresse My Domain avec /?login depuis un compte administrateur.
Peut-on se connecter par login.salesforce.com si My Domain ne répond pas ?
Seulement si votre administrateur n’a pas interdit cette entrée. Et si l’instance elle-même est en panne, aucune adresse ne fonctionnera.
Faut-il relancer manuellement les intégrations après la panne ?
Vérifiez d’abord ce qui est reparti seul. Relancez ensuite par petits lots, en surveillant les quotas API et les erreurs de verrouillage.
Une situation de Salesforce en panne se gère surtout avant : une adresse My Domain connue de tous, un administrateur hors SSO, un export récent et une fiche de secours. Si vous avez rencontré un message d’erreur absent de ce guide ou trouvé une parade qui a tiré votre équipe d’affaire, décrivez-la en commentaire.
Share this content: