Comment tester le code de vérification de connexion Salesforce en 2026 ? Étapes de recette QA

Depuis le déploiement progressif commencé en août 2026 dans les environnements bac à sable, votre script peut afficher une étape de connexion différente de celle attendue ; le déploiement en production a commencé en octobre 2026, sans bascule simultanée de toutes les organisations (calendrier officiel des changements de connexion).
Pour accepter une connexion Salesforce par e-mail, vérifiez séparément l’adresse saisie, la réception du code, le choix du compte ou de l’organisation et l’état final de la session. Si une adresse est associée à plusieurs comptes, testez explicitement l’étape de code et la sélection ; si votre automatisation doit rester sur le nom d’utilisateur, utilisez l’entrée prévue par la documentation officielle plutôt que de déduire la réussite de la seule réception d’un message.

Cet article s’adresse aux ingénieurs QA qui testent l’interface de connexion de leur bac à sable ou organisation de test, aux développeurs qui maintiennent leurs tests automatisés et aux administrateurs qui vérifient le parcours de comptes associés à la même adresse. Il concerne uniquement des organisations auxquelles vous êtes autorisé à accéder.

Dernière mise à jour : 2 novembre 2026. Les dates de déploiement et les parcours décrits ont été vérifiés dans les documents d’aide Salesforce indiqués ci-dessous. Une page effectivement affichée dans votre organisation constitue une preuve de son comportement observé, pas une annonce du calendrier applicable à toutes les organisations.

Avant l’essai : fixer le périmètre de la recette

Commencez par noter l’organisation visée et le point d’entrée réellement utilisé par le test. « Salesforce » ne désigne pas une seule page de connexion : une page générale, le domaine My Domain, un portail Experience Cloud, l’application mobile et une connexion par fournisseur SSO ne sont pas interchangeables. La documentation sur les URL de connexion et leur choix permet de vérifier l’adresse prévue pour l’organisation concernée.

Ce tableau sert à cadrer l’essai ; il ne garantit pas qu’une méthode précise soit disponible pour chaque entrée. Vérifiez le périmètre dans l’aide Salesforce adaptée, puis consignez le résultat réel de votre organisation. La page dédiée à la connexion avec une adresse e-mail décrit le parcours par e-mail ; ne transposez pas automatiquement ses étapes à My Domain, à Experience Cloud ou au SSO.

La portée du déploiement doit aussi rester précise. Salesforce indique un début de déploiement dans les environnements bac à sable en août 2026, puis en production en octobre 2026. Il s’agit d’un lancement progressif, et non d’une preuve que chaque organisation a déjà changé d’interface. Ne transformez donc pas l’observation « mon bac à sable affiche cette page » en règle générale sur toutes les organisations ou tous les utilisateurs.

Avant de lancer le scénario, préparez un compte de test autorisé, l’accès à la boîte de réception correspondante et une note permettant d’identifier l’organisation attendue. Pour une vérification de conformité des données de test, séparez aussi les adresses et identifiants de recette des données personnelles réelles ; les principes de délimitation des données de test peuvent vous aider à formaliser cette séparation.

Pendant la connexion : observer sans présumer du parcours

Lancez une session neuve depuis le point d’entrée consigné. Saisissez l’adresse associée au compte de test et notez l’écran affiché, les choix d’authentification proposés ainsi que toute redirection. N’écrivez pas dans le scénario « tous les utilisateurs passent par le code » à partir d’une seule observation : les étapes dépendent du compte, de l’organisation et de l’entrée utilisées.

Pour une recette reproductible, relevez les faits dans cet ordre : adresse saisie, page après validation de l’adresse, méthode d’authentification proposée, éventuelle demande de code, puis adresse de destination indiquée par le message. Cela vous permet de localiser un écart sans confondre un changement d’interface avec une erreur de réception. Vous pouvez également conserver une capture d’écran expurgée des données sensibles et l’heure de l’essai selon les règles internes de votre équipe.

Attention : l’écran observé pendant un essai confirme uniquement le parcours de ce compte, depuis cette entrée et dans cette organisation. Pour toute conclusion sur le déploiement, confrontez l’observation au document officiel et à la configuration réellement testée.

Comment valider le code lors d’une connexion à une organisation de test Salesforce ?

Effectuez l’essai avec une boîte que vous êtes autorisé à consulter. Après la demande de connexion, vérifiez si le parcours déclenche un message de vérification et si celui-ci arrive à l’adresse attendue. Comparez le contexte du message avec la tentative en cours : compte de test, destinataire et moment de la demande. Ne copiez pas un code d’une exécution précédente et ne réutilisez pas un message sans avoir confirmé qu’il correspond à l’essai actif.

Consignez séparément les états « message reçu » et « code accepté par la page ». Ce sont deux résultats différents : la réception montre que le message est arrivé dans la boîte consultée ; elle ne démontre ni que le code saisi est valide, ni que l’authentification est terminée. La documentation Salesforce sur l’accès à plusieurs comptes avec une même adresse décrit la possibilité d’une vérification par e-mail avant le choix du compte. C’est dans ce cas d’usage documenté que votre scénario doit aussi examiner l’étape suivante.

Pour éviter une conclusion trop large, conservez une trace minimale : destinataire attendu, présence ou absence du message, saisie acceptée ou refusée, puis écran suivant. N’enregistrez pas le code lui-même dans les journaux automatisés. Un code d’authentification est une donnée sensible ; une capture ou une sortie de journal qui le conserve peut exposer un accès de test au-delà de la durée nécessaire à la recette.

Après la vérification : choisir et confirmer le bon compte

Que vérifier si une adresse dessert plusieurs comptes Salesforce ?

Lorsque la page propose plusieurs comptes, organisations ou noms d’utilisateur, comparez les choix affichés à la cible déclarée dans le scénario. Sélectionnez le compte de test voulu, puis vérifiez l’organisation effectivement ouverte. Le fait qu’une adresse soit liée à plusieurs comptes ne permet pas de conclure que l’utilisateur arrivera automatiquement dans le bon environnement : le choix doit être observé et validé.

L’état « code accepté » ne prouve donc pas que l’organisation correcte est ouverte. Après le choix, confirmez le contexte depuis l’interface accessible : identité du compte de test, organisation attendue et page que le scénario devait atteindre. Si vous testez une autorisation particulière, vérifiez aussi cette autorisation avec un contrôle prévu à cet effet ; une connexion réussie ne prouve pas, à elle seule, que chaque rôle ou permission attendu fonctionne.

Gardez dans votre rapport les différentes étapes au lieu de les réduire à une seule mention « connexion réussie ». Cette granularité aide à distinguer une boîte qui n’a rien reçu, un code refusé, un mauvais compte choisi et une session authentifiée dans une organisation inattendue.

Comment prouver que la connexion est réellement terminée après réception du code ?

Définissez à l’avance le signal de réussite propre au scénario : par exemple, l’accès à la page prévue et la confirmation de l’organisation attendue. Un message reçu, un code accepté ou une redirection ne suffit pas si le test n’a pas encore établi que la session est arrivée au bon endroit.

Dans l’automatisation, attendez une condition observable correspondant à l’état final, plutôt qu’une durée fixe supposée convenir à toutes les exécutions. La condition doit vérifier le contenu ou le contexte attendu et éviter de se contenter de la disparition d’un formulaire. Si le parcours présente une sélection de compte, l’attente de la page finale doit commencer après le choix effectif, pas dès la validation du code. Cette séparation rend les échecs plus faciles à diagnostiquer et réduit les faux positifs.

Pour la régression : maintenir les parcours distincts

Comment conserver une connexion par nom d’utilisateur dans l’automatisation ?

Ne fusionnez pas la connexion par e-mail et la connexion par nom d’utilisateur en un seul test générique. Maintenez un scénario pour chaque comportement que votre produit ou votre organisation doit encore prendre en charge. La page de connexion peut évoluer ; un sélecteur fondé uniquement sur la position d’un bouton ou sur une formulation précise risque alors de devenir fragile.

La documentation Salesforce sur les URL de connexion doit servir à confirmer l’entrée et les paramètres officiellement documentés pour le parcours par nom d’utilisateur. Utilisez l’adresse et le paramètre qui correspondent à votre organisation, après vérification dans cette documentation ; ne construisez pas une URL par supposition et ne faites pas dépendre durablement la recette d’un bouton situé à un emplacement donné. Votre contrôle doit ensuite confirmer l’identité de l’organisation cible, comme pour la connexion par e-mail.

Les parcours mobiles doivent eux aussi être testés séparément. Salesforce publie une documentation distincte sur l’expérience de connexion de l’application mobile ; ne déduisez pas le comportement d’un navigateur de celui de l’application, ni l’inverse. Pour les autres méthodes, notamment My Domain, Experience Cloud ou SSO, partez de l’entrée effectivement utilisée et vérifiez les documents pertinents plutôt que d’extrapoler à partir de l’interface générale.

À la clôture : rendre le résultat exploitable

Votre compte rendu doit permettre à une autre personne de retrouver le point de rupture sans reproduire toute l’enquête. Notez l’organisation et l’entrée utilisées, le type de compte, les étapes présentées, le résultat de réception, l’acceptation ou le refus du code, le choix de compte et l’état final observé. Indiquez aussi ce qui n’a pas été testé : une recette de la page générale ne valide pas implicitement le mobile, le SSO ou chaque domaine personnalisé.

Appliquez cette décision au périmètre de votre prochaine régression :

• Si le scénario vise une connexion par e-mail, utilisez le parcours affiché pour ce compte et confirmez séparément réception, saisie acceptée, sélection éventuelle et organisation finale.
• Si l’adresse est associée à plusieurs comptes, ajoutez une assertion sur le compte ou l’organisation choisie ; sans cette vérification, le test ne valide pas la bonne destination.
• Si le scénario exige un nom d’utilisateur, gardez un test distinct et utilisez une entrée ou un paramètre confirmé dans la documentation Salesforce.
• Si vous testez Experience Cloud, My Domain, le mobile ou le SSO, créez une recette correspondant à cette entrée ; ne réutilisez pas sans contrôle les résultats de la page générale.
• Si vous ne pouvez pas consulter la boîte attendue, n’interprétez pas l’absence de message comme un refus de connexion : rétablissez d’abord un moyen de réception autorisé, puis relancez l’essai.

À retenir pour le rapport : formulez la conclusion au niveau effectivement testé, par exemple « connexion par e-mail validée pour ce compte et cette organisation ». Évitez « toutes les connexions Salesforce sont validées » si les autres entrées et types de comptes n’ont pas fait l’objet d’essais distincts.

Pour une boîte de recette, une adresse de réception contrôlée peut éviter de mélanger les essais et le courrier personnel. Avant de l’utiliser, vérifiez toutefois que sa réception convient au parcours testé et que vous pourrez consulter le message au moment voulu ; ne présumez ni une compatibilité générale ni une réussite garantie. Si cette option correspond à votre environnement, MsgMask propose une boîte temporaire sans inscription, utilisable immédiatement, afin de ne pas exposer votre adresse principale à un essai ponctuel. Vous pouvez vérifier le service depuis MsgMask et l’évaluer d’abord sur une recette non critique. Pour un compte à conserver, une connexion nécessitant des réponses ou un accès durable — notamment un compte sensible — privilégiez une adresse dont vous maîtrisez la continuité et la récupération.