Reconnecter un compte Gmail dans Thunderbird quand OAuth2 échoue
La fenêtre Google s’ouvre, l’autorisation est accordée, et Thunderbird affiche un pavé rouge du type « Login to server imap.gmail.com with username … failed. ». Le compte reste listé dans le volet des dossiers, les messages déjà téléchargés restent lisibles, l’envoi part en erreur. Un jeton OAuth2 n’a pas été enregistré, ou celui conservé dans le gestionnaire de mots de passe n’est plus accepté par accounts.google.com.
Sommaire
- Étape 1 : effacer le jeton OAuth2 de accounts.google.com
- Étape 2 : ramener la page Google dans une fenêtre du client
- Étape 3 : supprimer le compte Gmail et le recréer
- Étape 4 : confronter les serveurs Gmail à la base d’autoconfiguration
- Étape 5 : déclencher l’autorisation et envoyer un message de test
- Les cinq réglages qui décident du sort de la reconnexion
- Sources
Ressaisir le mot de passe Gmail ne répare rien. Depuis le 30 septembre 2024, Google refuse l’accès IMAP, POP, CalDAV et CardDAV aux applications qui n’envoient qu’un mot de passe, comme l’annonce le billet du 29 septembre 2023 du blog Google Workspace Updates, complété le 29 avril 2025 par une extinction des Less Secure Apps au 1er mai 2025. La rubrique Logiciels couvre les autres clients de messagerie et leurs méthodes d’authentification.
Étape 1 : effacer le jeton OAuth2 de accounts.google.com
Le jeton ne dort pas dans un fichier texte du profil. La documentation du projet est explicite : après l’authentification, Thunderbird enregistre le refresh token dans le logins store, le magasin de mots de passe du client. Un jeton refusé côté Google survit donc à la suppression du compte, et la reconnexion réutilise le même jeton mort. La note de version 155.0 du 1er septembre 2026 liste la correction sous la forme « Removing an account did not remove its OAuth token from the password manager ».
Le nom à effacer vient du fichier d’autoconfiguration gmail.com du projet, qui déclare l’émetteur OAuth sous la valeur accounts.google.com. Le même magasin porte le jeton du calendrier et des contacts, la portée déclarée couvrant mail, contacts, calendar et carddav. Un compte Gmail installé deux fois sur la même machine laisse deux jetons distincts.
Ouvrir Paramètres, puis Vie privée et sécurité, puis Mots de passe enregistrés.
Saisir accounts.google.com dans le champ de recherche et supprimer chaque ligne qui correspond.
Quitter complètement Thunderbird, pas seulement la fenêtre.
Ce qu’on voit : la liste ne contient plus aucune entrée pour accounts.google.com, et le champ de recherche ne renvoie plus rien. Les autres comptes du magasin restent intacts.
Avec un mot de passe principal, Thunderbird le redemande au redémarrage suivant. Cette étape est aussi celle qui remet à plat l’authentification à deux facteurs et les mots de passe d’application, puisque les deux passent par le même magasin.
Étape 2 : ramener la page Google dans une fenêtre du client
Thunderbird 153.0esr, publié le 22 juillet 2026 par le projet Thunderbird, ouvre la page d’authentification Gmail dans le navigateur par défaut du système et non plus dans une fenêtre du client. La préférence mailnews.oauth.useExternalBrowser porte ce choix, et le fichier mailnews.js du dépôt officiel thunderbird/thunderbird-desktop lui donne la valeur true. La documentation du projet, sur source-docs.thunderbird.net, situe cette bascule à la version 151. L’article d’aide Mozilla consacré à OAuth2 parle de la 153.
Deux documents Mozilla ne datent donc pas la même version, et le repère fiable reste le comportement observé : un onglet de navigateur s’ouvre hors de Thunderbird. La version 152.0, publiée le 16 juin 2026, avait remplacé le flux Gmail par une variante PKCE. La 156.0, publiée le 15 septembre 2026, corrige un échec du flux externe quand une préconnexion du navigateur se fermait en premier.
Un second levier existe, mailnews.oauth.usePrivateBrowser, à false par défaut. Le commentaire du fichier mailnews.js explique ce choix : une session privée gêne les fournisseurs qui attendent un identifiant d’appareil.
Ouvrir Paramètres, puis Général, et descendre jusqu’au bouton Éditeur de configuration.
Accepter l’avertissement, rechercher mailnews.oauth.useExternalBrowser, puis basculer la valeur sur false par un double clic.
Ce qu’on voit : la valeur affichée passe de true à false, en texte brut, et la ligne perd sa marque de valeur par défaut. À la demande suivante, la page Google s’ouvre dans une fenêtre Thunderbird, sans onglet de navigateur.
Étape 3 : supprimer le compte Gmail et le recréer
Reinstaller le compte est la seule opération qui réécrit ensemble le serveur entrant, le serveur sortant, la méthode d’authentification et l’identifiant. Google le recommande pour Thunderbird dans son billet du blog Workspace Updates du 29 septembre 2023. La version 155.0 a corrigé un défaut qui rendait la manœuvre impossible : une installation de compte échouée laissait un serveur entrant bloquant la recréation, ce que la note de version décrit par « Failed account setup left an incoming server that blocked account recreation ».
L’ordre compte, l’effacement du jeton venant avant la suppression du compte. Sans cette précaution, la recréation hérite du jeton révoqué et la panne se reproduit à l’identique. Les fichiers de messages locaux survivent à la suppression, ce qui évite de retélécharger des années d’archives au passage.
Paramètres, puis le compte Gmail, puis Actions de compte et Supprimer le compte.
Confirmer la suppression, puis reprendre par Ajouter un compte avec l’adresse Gmail complète.
Ce qu’on voit : le volet des dossiers ne contient plus l’ancien compte, puis la configuration automatique remplit imap.gmail.com sur le port 993 avec le type de socket SSL, et une entrée accounts.google.com réapparaît dans le magasin de mots de passe.
Étape 4 : confronter les serveurs Gmail à la base d’autoconfiguration
Thunderbird ne devine pas les serveurs Gmail, il lit le fichier gmail.com de sa base d’autoconfiguration publique. Ce fichier fixe cinq valeurs par protocole, et une seule ligne fausse suffit à faire échouer la reconnexion sans que le message d’erreur ne désigne la ligne coupable. La base déclare password-cleartext en second choix d’authentification, ce qui explique qu’un mot de passe d’application continue de fonctionner sur une installation ancienne. Elle déclare enfin une portée OAuth2 couvrant quatre services, mail, contacts, calendar et carddav.
| Protocole | Nom d’hôte | Port | Sécurité | Authentification annoncée |
|---|---|---|---|---|
| IMAP, réception | imap.gmail.com | 993 | SSL | OAuth2 |
| POP3, réception | pop.gmail.com | 995 | SSL | OAuth2 |
| SMTP, envoi | smtp.gmail.com | 465 | SSL | OAuth2 |
Un même accord Google ouvre donc la messagerie, le carnet d’adresses et l’agenda. Modifier une seule valeur à la main, en croyant contourner un blocage, casse l’ensemble. Sur le port d’envoi, les deux sources ne disent pas la même chose, et c’est le seul point de la table où un choix se pose réellement.
Étape 5 : déclencher l’autorisation et envoyer un message de test
Un compte peut recevoir et refuser d’envoyer, parce que le serveur sortant a sa propre méthode d’authentification et son propre jeton. Tester une seule direction laisse donc passer la moitié de la panne. La page Gmail Help consacrée à l’ajout de Gmail dans un autre client liste trois symptômes côté Google, « Username and password not accepted », « Invalid credentials », et la demande d’identifiants qui revient en boucle. Ces trois-là désignent une méthode refusée, pas un mot de passe mal tapé.
Le test d’envoi est le seul qui valide le second jeton, celui de smtp.gmail.com, dans la même session Google que la réception. L’alerte qui suit sort du fichier de localisation messenger.properties du dépôt officiel, et sa formulation envoie la plupart des recherches sur une fausse piste.
Composer un message, l’envoyer à sa propre adresse Gmail, puis forcer une relève avec le bouton Relever les messages.
Si l’alerte revient, relever la méthode d’authentification du serveur sortant avant de toucher au reste.
Ce qu’on voit : le message apparaît dans le dossier Envoyés et une copie revient dans la boîte de réception. En cas de refus, l’alerte reprend ces chaînes :
Login to account "adresse@gmail.com" failed Login to server imap.gmail.com with username adresse@gmail.com failed. Retry / Enter New Password
L’alerte nomme le serveur refusé et l’identifiant présenté. Elle ne dit rien du jeton, ce qui explique le nombre de diagnostics partis dans la mauvaise direction. Le remède tient en deux gestes : vérifier que la méthode d’authentification vaut OAuth2 sur le serveur entrant comme sur le sortant, puis reprendre à l’étape 1 si la valeur est déjà bonne. Quand le blocage vient du réseau et non du compte, diagnostiquer une connexion qui tombe évite de défaire un réglage correct. Sur les versions ESR, le fichier mailnews.js ne positionne pas mailnews.oauth.useSchemeRedirect, son commentaire réservant l’URL net.thunderbird aux versions non ESR.
Les cinq réglages qui décident du sort de la reconnexion
Cinq réglages décident de la suite, une fois le jeton revenu. Le port d’envoi, le plafond de clients simultanés imposé par Google, le mot de passe d’application, la portée du jeton sur le calendrier et l’emplacement de la préférence couvrent la quasi-totalité des cas restants. Chacun se vérifie en moins de deux minutes, contre une heure pour une réinstallation complète du client. Le message d’erreur ne les distingue pas : il nomme le serveur refusé et l’identifiant présenté, jamais la cause.
Où modifier mailnews.oauth.useExternalBrowser ?
Dans Paramètres, section Général, en bas de page, bouton Éditeur de configuration. Après acceptation de l’avertissement, le champ de recherche accepte le nom complet. Un double clic sur la ligne bascule la valeur entre true et false. La préférence mail.server.default.oauth2.useExternalBrowser applique la même règle aux serveurs créés ensuite, et la modifier ne rattrape pas un compte déjà installé.
Faut-il préférer le port 465 ou le port 587 pour smtp.gmail.com ?
La base d’autoconfiguration du projet Thunderbird installe le 465 en SSL, et la page Gmail Help consacrée au protocole POP documente le 587 en STARTTLS. Garder le 465 tant qu’il passe, sans rien changer. Sur un réseau d’entreprise qui filtre les ports hauts, basculer le serveur sortant sur le 587 avec STARTTLS rétablit l’envoi sans toucher à la réception. Un seul des deux réglages peut être actif à la fois.
Pourquoi Gmail cesse-t-il de répondre avec plusieurs appareils ?
Google autorise 15 clients de messagerie simultanés par compte, et le dépassement produit l’erreur « Too many simultaneous connections ». Le compteur porte sur les clients connectés en même temps, pas sur les installations passées. Fermer ou déconnecter un client inutilisé libère une place immédiatement. Un jeton OAuth2 abandonné dans le magasin de mots de passe compte comme un client tant qu’il n’est pas supprimé.
Quand un mot de passe d’application Gmail reste-t-il utilisable ?
Un mot de passe d’application est un code de 16 chiffres, que Google ne délivre qu’avec la validation en deux étapes activée sur le compte. Ce code sert aux clients qui ne proposent aucune connexion Google, ce qui n’est pas le cas de Thunderbird. Chaque changement du mot de passe du compte Google révoque tous les mots de passe d’application, ce qui coupe la messagerie sans prévenir. Trois situations les interdisent sans recours : une validation en deux étapes limitée aux clés de sécurité, un compte professionnel ou scolaire, et la protection renforcée activée.
Le calendrier et les contacts Gmail tombent-ils en même temps ?
Oui, ils partagent l’accord OAuth2. Le fichier d’autoconfiguration gmail.com déclare une portée couvrant mail, contacts, calendar et carddav, et un seul refresh token porte les quatre services. Effacer le jeton pour réparer la messagerie déconnecte donc aussi l’agenda et le carnet d’adresses, qui redemandent une autorisation. Recréer le compte rétablit les trois d’un coup, à condition de ne pas supprimer les calendriers distants au passage.