Après le changement du nom d’utilisateur Google Account en 2026, comment tester la connexion et la récupération ?

Le compte de test se connecte encore, mais votre application affiche une nouvelle adresse et ouvre peut-être un profil vide.

Pour tester le changement du nom d’utilisateur Google Account, utilisez sub comme identifiant stable, traitez l’adresse comme une donnée modifiable et vérifiez séparément la connexion existante, la nouvelle autorisation et la réception du courriel de récupération.

Cet article s’adresse aux développeurs qui maintiennent l’association entre Sign in with Google et les comptes de leur produit.
Il aide les équipes QA à préparer une recette d’identité continue et de récupération.
Il concerne aussi les responsables produit et sécurité qui contrôlent les changements d’adresse et les risques d’accès croisé.

Dernière mise à jour : 25 octobre 2026. Vérification des informations auprès du billet de Google Developers sur le changement de nom d’utilisateur, de la documentation OpenID Connect de Google et des pages d’aide Google sur les adresses associées au compte et la disponibilité de la fonctionnalité. Vérifiez ces sources avant chaque publication : la disponibilité et les valeurs reçues peuvent dépendre du compte et de l’état de l’autorisation.

Identité Google : sub ou adresse de courriel

Le choix important n’est pas l’adresse affichée dans le profil Google. C’est la valeur que votre système utilise pour retrouver le compte applicatif.

Google recommande d’identifier l’utilisateur avec le champ sub de l’ID token. La documentation OpenID Connect le définit comme un identifiant propre à l’utilisateur et stable pour l’émetteur. Elle précise aussi que sa longueur maximale est de 255 caractères ASCII. En revanche, email est une revendication distincte : ne la transformez pas en identifiant permanent simplement parce qu’elle est pratique à afficher ou à utiliser pour envoyer un message. Consultez la définition officielle des champs de l’ID token.

Cette distinction a des conséquences directes sur votre modèle de données. Une adresse peut être modifiée, remplacée ou corrigée. Si elle est votre clé principale, la nouvelle valeur risque de créer un second compte, tandis que l’ancien compte reste attaché à l’adresse précédente. Selon les règles de rapprochement, vous pourriez également associer les données d’une personne au mauvais profil.

Faites l’inventaire des usages de l’adresse dans votre application : clé de connexion, contrainte d’unicité, adresse de contact, destinataire de récupération ou champ d’affichage. Ces rôles peuvent être portés par des champs distincts. Pour un outil de création, par exemple, le compte conserve les projets de design, les fichiers audio ou les rendus vidéo ; il ne doit pas perdre ces ressources lorsque l’adresse change.

La valeur maximale de sub est un paramètre documenté, pas une raison pour tronquer ce champ. Stockez-le sans transformation et conservez également l’émetteur lorsque votre architecture doit distinguer des fournisseurs d’identité. Une comparaison insensible à la casse, une normalisation hasardeuse ou une troncature peut casser l’association. Le détail des revendications et de leur rôle figure dans la référence OpenID Connect de Google.

Continuité de connexion : autorisation active ou nouvelle autorisation

Selon Google, lorsqu’un utilisateur change le nom d’utilisateur de son compte, une autorisation déjà active peut continuer à fournir l’ancienne adresse. Après révocation de l’autorisation puis nouvelle connexion, l’application peut recevoir la nouvelle adresse. Google indique également que l’ancienne adresse reste associée à la même boîte de réception. Ces comportements ne signifient pas que l’adresse reste identique dans tous les jetons ni que votre compte applicatif doit être recréé. Les détails et limites sont décrits dans le billet de Google sur l’impact pour les applications.

Le changement annoncé pour les utilisateurs aux États-Unis est disponible à partir du 31 mars 2026, d’après les informations fournies par Google. La disponibilité peut dépendre de l’éligibilité du compte et de la région. Vérifiez la page d’aide au moment de planifier votre recette ; ne supposez pas que tous vos comptes de test peuvent effectuer cette modification.

Pour chaque connexion, journalisez les données utiles à l’analyse, sans exposer inutilement les jetons : environnement, état de l’autorisation, sub, adresse retournée et identifiant interne du compte finalement ouvert. Masquez les informations personnelles dans les journaux partagés et limitez l’accès aux journaux bruts. La page Google consacrée à la validation côté serveur des identifiants rappelle que le serveur doit vérifier l’ID token plutôt que de se fier à une valeur envoyée librement par le navigateur ou l’application.

En recette, le critère n’est donc pas « l’adresse affichée a changé ». Il faut confirmer que la session mène au bon compte, que les données historiques sont présentes et que l’adresse présentée par votre produit correspond au scénario exécuté. Un écran de connexion réussi peut masquer une association défectueuse si vous ne vérifiez pas l’identifiant interne et les données du profil.

Réautorisation : même utilisateur ou profil dupliqué

Le scénario de réautorisation permet de vérifier une erreur fréquente : utiliser l’adresse comme clé de recherche, puis créer un nouvel utilisateur lorsque cette adresse diffère. Pour le tester, partez d’un compte de test maîtrisé et autorisé. Notez son sub et l’identifiant de compte interne. Après révocation, relancez Sign in with Google et vérifiez si votre système retrouve le compte existant.

Le résultat attendu repose sur l’identité reçue, et non sur une supposition fondée sur l’adresse. Si le sub correspond à l’identité déjà associée dans votre base, votre application doit appliquer ses règles de compte existantes. Si le sub ne correspond pas, ne fusionnez pas les comptes uniquement parce que les adresses sont identiques ou proches. Une fusion automatique peut donner accès à des données qui ne devraient pas être réunies.

Distinguez bien trois opérations qui sont parfois amalgamées pendant les tests :

• modifier une valeur de courriel dans une fixture ;
• recevoir une nouvelle valeur après une authentification Google réelle ;
• changer l’adresse de contact enregistrée dans votre propre produit.

La première teste votre logique applicative, pas le comportement de Google. La deuxième vérifie une réponse réelle du fournisseur dans un état d’autorisation donné. La troisième relève de votre procédure de modification et doit avoir ses propres contrôles de propriété.

Quand vous devez rapprocher des données historiques, définissez une règle explicite : quel utilisateur peut demander le changement, quelle preuve est requise, quelles sessions doivent être invalidées et comment les opérations sont auditées. Le traitement d’une ancienne adresse doit éviter qu’un autre utilisateur puisse revendiquer le compte simplement en la saisissant. Pour les principes de minimisation des données de test, vous pouvez consulter la politique de confidentialité de MSGTMP.

Récupération : adresse de connexion ou adresse de contact

Le compte Google qui authentifie une personne et l’adresse de récupération de votre produit sont deux éléments différents. Votre produit peut enregistrer une adresse de contact distincte de email. Il doit alors expliquer à l’utilisateur quelle adresse recevra les messages et appliquer une vérification avant de considérer une nouvelle adresse comme validée.

Testez le parcours de bout en bout, en séparant ses étapes. Déclenchez une récupération pour un compte de test, contrôlez l’adresse effectivement ciblée, recevez le message, puis vérifiez que le lien conduit au bon environnement et au bon compte. Après l’action, contrôlez l’état du compte : une récupération réussie sur un profil vide ou un compte homonyme reste un échec.

Ne déduisez pas qu’un ancien message sera livré parce que Google associe l’ancienne adresse à la même boîte de réception. Cette information concerne la boîte Google décrite par Google ; elle ne démontre pas que votre application possède une adresse de contact à jour, que votre serveur a envoyé le bon message ou que le destinataire l’a reçu. Le seul contrôle pertinent pour votre parcours est une réception réelle dans l’environnement de test, avec le compte et la destination consignés.

Le contenu du message compte aussi. Vérifiez que l’objet et le texte permettent de reconnaître votre produit, que le lien correspond au domaine de l’environnement et que son action ne divulgue pas d’informations sensibles. Les messages envoyés depuis une préproduction ne doivent pas inciter un destinataire à agir sur un compte de production. Pour structurer les vérifications avant publication, appuyez-vous sur la liste de contrôle de MSGTMP et adaptez-la aux règles de votre application.

Preuve de test : fixture, authentification réelle et réception

Les fixtures sont utiles pour couvrir les branches de votre code : même sub avec une adresse différente, absence d’adresse vérifiée ou compte interne déjà existant. Elles rendent les tests reproductibles. Elles ne prouvent cependant ni la signature d’un jeton Google réel, ni l’état de l’autorisation, ni la réception d’un message dans une boîte.

Dans votre environnement de production, ne contournez jamais la validation de signature pour rendre un test plus simple. Le serveur doit vérifier les propriétés requises de l’ID token, notamment l’émetteur, le destinataire attendu et l’expiration, comme l’indique la documentation Google sur la validation côté serveur. Un jeton fabriqué avec une adresse modifiée peut servir à tester une fonction isolée si le cadre est maîtrisé ; il ne doit pas être accepté comme preuve d’identité réelle.

Une recette solide sépare les preuves dans son compte rendu :

• Test de fixture : vérifie la logique de recherche, de mise à jour d’adresse et de prévention des doublons.
• Connexion Google réelle : vérifie les revendications effectivement reçues avec un compte et une autorisation déterminés.
• Réception du courriel : vérifie le message envoyé par votre application, son destinataire et son lien.
• Récupération terminée : vérifie que l’action conduit au compte attendu et que son état est cohérent.

Cette séparation rend vos résultats exploitables lors d’un audit ou d’un incident. Si vous n’avez pas accès à un compte éligible pour modifier son nom d’utilisateur, indiquez précisément cette limite. Vous pouvez valider la logique interne avec des fixtures et compléter la recette par une connexion réelle dans un autre scénario autorisé ; vous ne pouvez pas marquer comme vérifié un changement Google que vous n’avez pas exécuté.

Pour diagnostiquer une différence entre la valeur affichée et celle enregistrée, comparez les événements et les données utiles sans conserver de jetons dans des journaux ordinaires. La page de diagnostic de MSGTMP peut vous aider à organiser le relevé d’un problème de réception ; elle ne remplace pas la validation de l’identité par votre serveur.

Recette avant publication : critères mesurables

Utilisez la liste ci-dessous sur un compte de test que vous êtes autorisé à contrôler. Cochez chaque point seulement après avoir conservé la preuve correspondante dans votre outil de suivi.

• [ ] Le compte applicatif utilise sub comme identifiant de l’utilisateur Google et ne dépend pas de l’adresse seule.
• [ ] La connexion avec autorisation active consigne l’adresse reçue, l’identifiant interne ouvert et les données retrouvées.
• [ ] La réautorisation après révocation permet de comparer les sub avant et après, sans remplacer artificiellement une revendication Google.
• [ ] Une adresse modifiée ne crée pas de compte supplémentaire si l’identité stable correspond au compte existant.
• [ ] Une identité différente ne déclenche pas de fusion automatique fondée uniquement sur une adresse identique.
• [ ] La modification de l’adresse de contact dans votre produit exige une preuve de contrôle prévue par vos règles.
• [ ] Le message de récupération arrive à la destination attendue et renvoie vers le bon environnement.
• [ ] La récupération terminée ouvre le compte correct et conserve les données attendues.
• [ ] Les fixtures, les connexions réelles et les réceptions réelles sont distinguées dans le rapport.
• [ ] Les essais non réalisables faute d’éligibilité ou d’accès à un compte sont signalés comme limites, et non comme résultats positifs.

Pour décider de la publication, examinez séparément la continuité d’identité, le risque de doublon, la mise à jour de l’adresse et la récupération. Une réussite sur un axe ne compense pas un échec sur un autre. Par exemple, une connexion Google correcte ne démontre pas que le courriel de récupération arrive, et une réception correcte ne prouve pas que l’identité du compte a été associée sans erreur.

Consignez l’environnement, les autorisations utilisées, les valeurs comparées et les limites de la campagne. Évitez de conserver plus de données personnelles que nécessaire. Si une recette nécessite un destinataire de test, choisissez-le pour contrôler la réception de vos propres messages ; ne le présentez jamais comme un substitut à un vrai compte Google ni comme une preuve de connexion fédérée.

Questions fréquentes

Quelle adresse Google votre application peut-elle recevoir après le changement ?

Une autorisation déjà active peut continuer à fournir l’ancienne adresse. Après révocation puis nouvelle autorisation, Google indique que la nouvelle adresse peut être fournie. Il s’agit d’un comportement à tester dans le contexte précis de votre compte et de son état d’autorisation, pas d’une règle à simuler en remplaçant une valeur dans une fixture.

Quelle valeur doit servir à associer le compte applicatif ?

Utilisez sub comme identifiant stable de l’utilisateur Google. Gardez l’adresse dans un champ distinct, modifiable selon votre modèle de données. Si votre système repose actuellement sur l’adresse comme clé, examinez les risques de doublon et de rapprochement avant de changer la logique ; ne fusionnez pas deux comptes sur une simple correspondance de courriel.

Comment éviter un doublon après une révocation ?

Enregistrez l’identifiant interne et le sub avant la révocation, puis comparez-les aux valeurs d’une connexion réelle après réautorisation. Vérifiez également le profil et les données retrouvées. Si le code ouvre un compte différent, bloquez la création silencieuse et examinez la règle d’association. Un courriel différent, à lui seul, ne prouve pas qu’il s’agit d’une nouvelle personne.

L’ancienne adresse reçoit-elle les courriels de récupération de votre application ?

Pas nécessairement. Le fait que Google associe l’ancienne adresse à la même boîte de réception ne vérifie ni votre carnet de contacts, ni le destinataire choisi par votre application, ni la livraison d’un message. Testez le parcours de récupération de votre produit jusqu’à la réception et à l’ouverture du lien, puis contrôlez le compte réellement modifié.

Si le contrôle restant porte uniquement sur la réception d’un message de récupération envoyé par votre propre application, une boîte temporaire MSGTMP peut servir de destinataire de test dans un scénario maîtrisé. Vérifiez alors le message et son lien comme vous le feriez avec toute boîte de recette ; cette observation ne démontre ni l’identité Google, ni la validité d’un ID token, ni le fonctionnement de Sign in with Google.

Questions fréquentes