Vous ouvrez un nouvel environnement Salesforce. Vous recevez l’email de bienvenue. Vous vous dites que vous créerez le mot de passe après le déjeuner. Puis le déjeuner devient une réunion, la réunion devient une semaine, et le lien d’activation finit par expirer.
Quelques jours plus tard, vous revenez plein de bonne volonté. Salesforce vous demande alors de réinitialiser votre mot de passe, puis pose cette question : « In what city were you born? »
Petit problème : vous n’avez jamais choisi cette question de sécurité. Vous n’avez jamais indiqué votre ville de naissance. Salesforce vous demande donc de vous souvenir d’une réponse que vous n’avez pas donnée. C’est un excellent exercice de philosophie, mais un moins bon parcours d’onboarding.
La réponse qui débloque souvent la situation est étonnamment simple : San Francisco.
La réponse courte : essayez « San Francisco »
L’astuce a été documentée en 2022 par Scott S. Nelson, The IT Solutionist, après avoir rencontré le problème sur un compte Salesforce Developer nouvellement créé. Son lien initial n’était plus exploitable et le parcours de réinitialisation lui demandait une ville de naissance jamais renseignée. Il a supposé que la réponse par défaut pouvait être la ville du siège de Salesforce. Il a essayé San Francisco, et cela a fonctionné.
Son article original est disponible ici : SOLVED! Salesforce “In what city were you born?” not set.
Ce n’est pas une règle officiellement documentée par Salesforce. Il faut donc la considérer comme une solution de terrain pour un cas précis, pas comme une nouvelle politique de sécurité universelle. Nous avons également vu Paris être accepté dans certains contextes, mais ce comportement n’est pas documenté et peut dépendre de l’environnement ou du parcours utilisé. Si vous êtes face à cette question sans avoir défini de réponse, commencez par San Francisco.
Oui, c’est un peu absurde. Non, votre lieu de naissance n’a probablement pas été deviné par le CRM.
Comment arrive-t-on dans cette situation ?
Lorsqu’un administrateur crée un utilisateur ou lorsqu’une personne ouvre un environnement de démonstration ou de développement, Salesforce envoie généralement un lien permettant de vérifier le compte et de définir un mot de passe.
Ce lien n’est pas éternel. Salesforce indique que la durée de validité d’un lien de vérification de nouvel utilisateur dépend des paramètres de session de l’organisation : elle peut être fixée à un jour, sept jours par défaut ou 180 jours. Un lien classique de réinitialisation de mot de passe expire, lui, après 24 heures.
Une fois le lien expiré, l’utilisateur revient vers le parcours standard de connexion et de réinitialisation. Selon la configuration de l’organisation et la méthode d’authentification, Salesforce peut alors demander une méthode MFA ou une réponse à une question de sécurité.
C’est là que le paradoxe apparaît : le compte existe, l’adresse email est correcte, mais l’utilisateur n’a jamais terminé l’étape pendant laquelle il aurait défini son mot de passe et sa réponse personnelle. Il se retrouve donc devant une question dont il ignore légitimement la réponse.
Dans l’histoire racontée par Scott Nelson, la réponse par défaut était la ville du siège historique de Salesforce : San Francisco. Une énigme digne d’un jeu d’aventure, cachée au milieu d’un processus d’accès professionnel.
La procédure pratique pour récupérer l’accès
Voici l’ordre le plus sûr pour traiter le problème sans multiplier les essais au hasard.
1. Vérifiez l’adresse de connexion
Une organisation Salesforce peut utiliser login.salesforce.com, test.salesforce.com pour une sandbox, ou une adresse My Domain propre à l’entreprise. Une mauvaise URL peut vous envoyer vers un parcours qui ne correspond pas au compte recherché.
Avant de réinitialiser quoi que ce soit, vérifiez donc :
- le nom d’utilisateur exact, qui peut être différent de l’adresse email ;
- la nature de l’environnement, production ou sandbox ;
- l’URL My Domain éventuelle ;
- l’existence d’un SSO qui impose un autre point d’entrée.
2. Demandez un nouveau lien
Utilisez « Mot de passe oublié » depuis la bonne page de connexion. Ne réutilisez pas un ancien email en espérant que le lien retrouve une seconde jeunesse. Salesforce précise que les liens de réinitialisation expirent au bout de 24 heures.
Un autre piège existe : certains outils de sécurité email ouvrent automatiquement les liens pour les analyser. Selon la configuration, cette analyse peut consommer un lien à usage unique avant même que l’utilisateur ne clique dessus. Salesforce documente des paramètres permettant de limiter ce problème.
3. Si la question apparaît sans avoir été configurée, essayez San Francisco
Saisissez San Francisco, avec l’espace. C’est la réponse de terrain documentée dans le cas du compte Developer décrit plus haut.
Évitez d’enchaîner une collection de villes au hasard. Plusieurs tentatives incorrectes peuvent verrouiller le compte selon les politiques de sécurité de l’organisation. Paris peut fonctionner dans certains cas observés, mais San Francisco reste la première réponse à tester pour ce scénario particulier.
4. Si cela échoue, contactez l’administrateur
Salesforce est clair sur ce point : si vous ne connaissez pas la réponse à la question de sécurité, contactez l’administrateur Salesforce. L’administrateur peut réinitialiser le mot de passe ou relancer le processus d’activation. Si la personne bloquée est l’unique administrateur de l’organisation, il faut passer par le support Salesforce.
Cette étape est plus fiable que dix nouvelles tentatives inspirées par un atlas.
5. Une fois connecté, sécurisez le compte proprement
Le but n’est pas seulement d’entrer une fois. Il faut éviter de retomber dans le même piège. Après récupération de l’accès :
- vérifiez l’adresse email et le nom d’utilisateur ;
- configurez votre méthode MFA ;
- mettez à jour la question de sécurité si elle est encore utilisée ;
- enregistrez l’URL correcte de l’organisation ;
- ajoutez le compte au gestionnaire de mots de passe de l’entreprise ;
- documentez le propriétaire de l’accès et la procédure de secours.
Pourquoi une petite question peut faire perdre beaucoup de temps
À première vue, ce problème ne mérite pas un projet. Il suffit d’un mot et tout repart. Mais encore faut-il connaître ce mot.
Sans expérience du cas, une personne peut :
- demander plusieurs réinitialisations inutiles ;
- essayer le mauvais environnement ;
- confondre le nom d’utilisateur et l’adresse email ;
- faire verrouiller le compte ;
- solliciter l’équipe informatique, puis Salesforce, puis l’ancien prestataire ;
- recréer un environnement ou un utilisateur alors que le premier était récupérable.
Le temps perdu ne vient pas de la complexité technique. Il vient de l’incertitude. Personne ne sait si le problème est normal, si le compte a été mal créé, si le lien a expiré, si le SSO intervient ou si l’environnement est simplement le mauvais.
C’est exactement le type de situation dans laquelle l’expérience accumulée compte. Un intégrateur ne passe pas uniquement ses journées à construire des Flows et des interfaces. Il connaît aussi les petits pièges d’exploitation qui bloquent une équipe pour une raison apparemment incompréhensible.
Ce qu’un intégrateur Salesforce doit prévoir dès la création des accès
Le meilleur dépannage reste celui qu’on évite. Dans un projet bien cadré, la création des utilisateurs fait partie d’un processus d’onboarding, pas d’une succession d’emails laissés à chacun.
Chez Cloud Girafe, nous recommandons une liste de contrôle simple :
- définir qui demande, valide et crée les utilisateurs ;
- confirmer le bon profil et les permission sets ;
- envoyer les accès à une date où les utilisateurs peuvent réellement les activer ;
- contrôler les comptes non activés avant l’expiration des liens ;
- documenter production, sandbox, My Domain et SSO ;
- enregistrer les méthodes MFA et la procédure de récupération ;
- vérifier que les anciens accès sont désactivés au départ d’un collaborateur ou d’un prestataire.
Ce travail paraît administratif. Il touche pourtant directement la sécurité, l’adoption et la capacité à délivrer. Un consultant qui attend son accès ne produit rien. Un utilisateur qui ne sait pas à quel environnement il se connecte peut tester au mauvais endroit. Un ancien compte encore actif devient un risque inutile.
Pour aller plus loin, vous pouvez lire notre article sur les extensions Chrome utiles pour travailler plus efficacement dans plusieurs environnements Salesforce et notre guide sur la maintenance et le support Salesforce dans la durée.
L’intérêt d’un accompagnement continu plutôt qu’un dépannage isolé
La réponse « San Francisco » fait sourire parce qu’elle résout un blocage disproportionné en quelques secondes. Mais elle illustre aussi une réalité : Salesforce est une plateforme riche, et son exploitation quotidienne accumule des dizaines de détails de ce type.
Certains concernent les utilisateurs. D’autres touchent les droits, les emails, les intégrations, les certificats, les limites API, les doublons, les automatisations ou les mises à jour trimestrielles. Pris séparément, chacun semble mineur. Ensemble, ils créent le brouhaha qui fait dire aux équipes : « Salesforce est compliqué » ou « personne ne sait vraiment comment ça marche ».
Un bon accompagnement ne consiste donc pas seulement à recevoir des tickets. Il doit apporter :
- un interlocuteur responsable de l’environnement ;
- un backlog clair et priorisé ;
- des délais de traitement convenus ;
- un suivi de l’adoption et de la qualité des données ;
- une documentation opératoire ;
- des points réguliers pour décider, et pas seulement réparer.
C’est la différence entre une TMA vécue comme une boîte aux lettres et un Salesforce réellement sous contrôle.
Si votre environnement accumule les petits blocages, si les accès dépendent d’une seule personne ou si personne n’est certain de la bonne procédure, notre second avis Salesforce permet de faire un état des lieux et de prioriser les actions utiles.
Questions fréquentes
« San Francisco » fonctionne-t-il dans tous les environnements Salesforce ?
Non. L’astuce est documentée pour un scénario où la question n’avait pas été définie lors de l’activation d’un compte Developer. Salesforce ne publie pas cette réponse comme règle générale. Si elle ne fonctionne pas, contactez l’administrateur plutôt que d’insister.
Pourquoi Salesforce pose-t-il encore une question de sécurité ?
Le parcours dépend des paramètres et de la méthode d’authentification de l’organisation. Salesforce privilégie aujourd’hui la MFA, mais une question de sécurité peut encore apparaître dans certains parcours de récupération.
Est-ce une faille de sécurité ?
Cet article ne permet pas de conclure à une faille. Il décrit surtout un cas limite d’activation et de récupération de compte. Le bon traitement reste de récupérer l’accès, puis de configurer correctement la MFA, les politiques de mot de passe et la procédure d’administration.
Que faire si je suis le seul administrateur et que je reste bloqué ?
Salesforce recommande de contacter son support. Préparez les informations permettant de prouver que vous êtes autorisé à administrer l’organisation.
À retenir
Si Salesforce vous demande dans quelle ville vous êtes né alors que vous n’avez jamais renseigné cette information, essayez San Francisco. Si cela ne fonctionne pas, ne transformez pas la récupération du compte en tour du monde : demandez à l’administrateur de réinitialiser l’accès.
Et surtout, profitez de l’incident pour sécuriser l’onboarding des prochains utilisateurs. Les meilleurs projets Salesforce ne se reconnaissent pas seulement à leurs fonctionnalités. Ils se reconnaissent aussi au fait que les gens peuvent se connecter le lundi matin sans résoudre une énigme californienne.
Sources
- Scott S. Nelson, SOLVED! Salesforce “In what city were you born?” not set, 23 novembre 2022.
- Salesforce Help, Troubleshoot Login Issues.
- Salesforce Help, How Long New User Verification Links Remain Valid Before Expiring.
- Salesforce Help, Expiration Period of Password Resets and Email Verification Links.
