Outlook 365 : corriger « localhost refusé » avec Gmail IMAP

Depuis décembre 2024, un grand nombre d’utilisateurs d’Outlook 365 voient l’authentification Gmail échouer avec « localhost refused to connect » (erreur 8011 / ERR_CONNECTION_ABORTED). Voici un guide concret, reproductible et sûr pour rétablir la connexion IMAP sans modifier ports, TLS ni mots de passe.

Sommaire

Vue d’ensemble du problème

Lors de la connexion ou de la reconnexion d’un compte Gmail dans Outlook 365 (version « classique » ou nouvelle application), le parcours OAuth2 s’ouvre dans le navigateur, l’accès « Microsoft apps & services » est bien accepté, mais la redirection finale vers localhost échoue. Résultats typiques :

Bannière jaune persistante « Sign in via browser » dans Outlook.
Tests de compte via Fichier > Paramètres du serveur > Tester… qui réussissent, alors que l’envoi/réception IMAP réels échouent.
Gmail fonctionne dans le navigateur, sur mobile ou sur un autre PC, ce qui inocente le mot de passe et la configuration des ports.

La cause la plus fréquente est une interférence locale empêchant le « mini-serveur » d’écoute temporaire qu’Outlook lance en 127.0.0.1:<port_éphémère> de recevoir le code de validation. Très souvent, elle provient de lignes parasites dans les fichiers hosts/hosts.ics ou d’anciennes informations d’identification OAuth2 corrompues.

Solution consolidée

Appliquez la séquence ci‑dessous dans l’ordre. Elle corrige la grande majorité des cas en quelques minutes.

Étape	Action	Détails clés
1	Neutraliser les entrées parasites dans les fichiers hosts	Chemin : `C:\Windows\System32\drivers\etc`. Ouvrir hosts et (si présent) hosts.ics avec le Bloc‑notes en mode administrateur. Rechercher toute ligne contenant `mshome.net` ou une redirection `127.0.0.1` inconnue ; ajouter `#` devant pour commenter ou supprimer la ligne. Enregistrer.
2	Nettoyer les identifiants OAuth2	Panneau de configuration > Gestionnaire d’identifiants > Identifiants Windows. Supprimer chaque entrée `MicrosoftOffice16_Data:OAUTH2` liée à `tp_google_imap_Oauth2` (une par compte Gmail).
3	Révoquer puis ré‑accorder l’accès côté Google	Compte Google > Sécurité > Vos connexions à des applications tierces : retirer « Microsoft apps & services ». Relancer Outlook : la bannière « Sign in via browser » réapparaît ; refaire l’authentification en cochant la case d’autorisation.
4	Redémarrer le PC	Garantit le rechargement des fichiers hosts et des jetons après nettoyage.

✅ Dans la majorité des cas, commenter ou supprimer les trois entrées mshome.net (créées par des virtualiseurs : Hyper‑V, WSL, VMware/Workstation, etc.) rétablit immédiatement la redirection OAuth2 et la synchronisation IMAP.

À qui s’adresse ce guide

Utilisateurs d’Outlook 365 « classique » et de la nouvelle application Outlook pour Windows.
Windows 10/11, PC personnels ou gérés (AD/AAD/Intune).
Comptes Gmail personnels et Google Workspace utilisant IMAP avec OAuth2.

Étapes détaillées

Neutraliser les entrées parasites dans les fichiers hosts

Pourquoi c’est crucial. Lors de l’authentification, Outlook démarre un écouteur local en 127.0.0.1 avec un port temporaire pour recevoir le « code » final depuis le navigateur. Des ajouts dans hosts ou hosts.ics peuvent détourner ou court‑circuiter la résolution locale, ou introduire une règle de bouclage agressive qui fait avorter la connexion (ERR_CONNECTION_ABORTED).

Ouverture sécurisée du fichier.

Cliquez sur Démarrer, tapez Bloc‑notes, faites un clic droit > Exécuter en tant qu’administrateur.
Dans le Bloc‑notes, Fichier > Ouvrir, pointez sur C:\Windows\System32\drivers\etc, sélectionnez « Tous les fichiers » puis ouvrez hosts (et hosts.ics s’il existe).
Avant toute modification, créez une sauvegarde : Fichier > Enregistrer sous… > hosts.bak.

Que faut‑il supprimer ou commenter ? Recherchez des lignes contenant mshome.net, localhost redéfini, ou des redirections peu claires vers 127.0.0.1. Exemple de contenu problématique :

# Exemples courants à neutraliser (commenter ou supprimer)
127.0.0.1    WIN-12345.mshome.net
127.0.0.1    wsl.mshome.net
127.0.0.1    vmnet.mshome.net
# ⚠ Évitez de dupliquer ou modifier la ligne "127.0.0.1 localhost"

Bonnes pratiques.

Ne supprimez pas la ligne canonique 127.0.0.1 localhost ni ::1 localhost (IPv6).
Si hosts.ics n’existe pas, c’est normal sur de nombreuses machines : concentrez‑vous sur hosts.
Après modification, Enregistrer, puis fermez le Bloc‑notes.

Nettoyer les identifiants OAuth2 côté Windows

L’échec de redirection laisse parfois des jetons WAM (Web Account Manager)/OAuth2 incohérents qui empêchent toute reconnexion propre.

Ouvrez le Panneau de configuration, puis Comptes d’utilisateurs > Gestionnaire d’identifiants.
Allez dans Identifiants Windows.
Localisez chaque entrée MicrosoftOffice16_Data:OAUTH2 associée à tp_google_imap_Oauth2 (il y en a une par profil Gmail).
Cliquez sur Supprimer pour chacune.

Astuce : si vous avez plusieurs profils Outlook ou plusieurs boîtes Gmail, répétez l’opération pour chaque occurrence.

Révoquer puis ré‑accorder « Microsoft apps & services » côté Google

La révocation manuelle dans le compte Google purgera l’autorisation côté Google afin qu’Outlook redemande un nouveau consentement propre.

Dans votre compte Google, onglet Sécurité, ouvrez la section Vos connexions à des applications tierces.
Retirez l’application Microsoft apps & services (contrôle OAuth pour IMAP/SMTP).
Relancez Outlook : la bannière « Sign in via browser » réapparaît.
Suivez l’authentification dans le navigateur et cochez la case d’autorisation quand elle est proposée, puis validez.

Redémarrer le PC

Ce redémarrage force la prise en compte des modifications hosts/hosts.ics, vide les sockets en attente, et réinitialise les caches d’identifiants chargés en mémoire. Vous évitez ainsi de tester une configuration « à moitié » rafraîchie.

Vérifications après correction

La bannière « Sign in via browser » disparaît après authentification.
L’envoi/réception (IMAP/SMTP) fonctionne ; Ctrl + M (toutes versions) force une synchronisation.
Dans Outlook classique, la fenêtre État de la connexion montre l’état Auth « Bearer » pour IMAP/SMTP.
Aucun message d’erreur 8011, pas d’ERR_CONNECTION_ABORTED à l’étape de redirection.

Tableau de correspondance symptômes → actions

Symptôme	Lecture rapide	Action prioritaire
Bannière « Sign in via browser » qui réapparaît en boucle	Jetons OAuth2 incohérents	Étape 2 puis 3 (nettoyage identifiants + révocation Google)
Navigateur affiche « localhost refused to connect » ou code 8011	Redirection OAuth2 vers 127.0.0.1 bloquée	Étape 1 (fichiers hosts), puis redémarrage
Test de compte OK mais mails bloqués	Connexion IMAP réelle non autorisée	Étape 2 & 3, puis relancer Outlook
Nouvelle app Outlook s’ouvre dans Edge avec `…/oobe`	Moteur d’authentification identique	Appliquer les étapes 2 et 3, puis 1 au besoin

Points d’attention et bonnes pratiques complémentaires

Pas de fichier hosts.ics ? C’est normal sur de nombreuses machines. Travaillez uniquement sur hosts le cas échéant.
Extensions réseau : assurez‑vous qu’aucun proxy/VPN/bloqueur de pubs ne réécrit hosts ni n’impose des règles de loopback agressives dans le pare‑feu.
Nouvelle application Outlook : si Edge ouvre systématiquement une page /oobe, le traitement est identique. Les jetons et l’écoute locale sont gérés par les mêmes composants.
Sauvegarde : conservez hosts.bak pour revenir en arrière si besoin.
Comptes multiples : supprimez toutes les entrées tp_google_imap_Oauth2 correspondantes, puis réauthentifiez compte par compte.

Pourquoi cette solution fonctionne

Le flux OAuth2 d’Outlook pour Gmail s’appuie sur une redirection locale : une fois que vous avez validé l’accès à « Microsoft apps & services » dans le navigateur, ce dernier renvoie un code vers un callback de type https://localhost:<port>/. Outlook écoute brièvement ce port en local pour échanger ce code contre un jeton d’accès/actualisation.

Si la pile réseau locale est altérée (entrées hosts injectées par WSL/Hyper‑V, ICS et consorts, règles de sécurité intrusives, interception par un proxy), la connexion vers 127.0.0.1 peut être abordée ou mal redirigée, d’où les messages « localhost refused » et code 8011. Retirer ces altérations restaure le parcours naturel : navigateur → 127.0.0.1:<port_éphémère> → Outlook.

Cas particuliers

Parc d’entreprise : des GPO ou un EDR peuvent imposer des entrées hosts ou bloquer 127.0.0.1. Testez sur un réseau isolé sans proxy, vérifiez les règles du pare‑feu Windows et des suites de sécurité.
Poste avec Hyper‑V/WSL/VirtualBox : la suppression des lignes *.mshome.net suffit souvent. WSL ou ICS peut recréer hosts.ics ; revenez vérifier après un redémarrage ou neutralisez les services correspondants si nécessaire.
Utilisateur non‑administrateur : faites modifier hosts par un administrateur, ou exécutez le Bloc‑notes en élévation (UAC).

Plan B si le problème persiste

Si, après les quatre étapes, la situation est inchangée, procédez comme suit :

Vider les cookies du navigateur utilisés pour l’authentification Google (uniquement les cookies Google si possible) puis réessayer.
Désactiver temporairement les proxys : désactivez « Détecter automatiquement les paramètres », videz le proxy WinHTTP : netsh winhttp reset proxy
Réinitialiser la pile réseau (à n’utiliser qu’en dernier recours, car cela touche tous les adaptateurs) : ipconfig /flushdns netsh winsock reset netsh int ip reset
Vérifier le pare‑feu : autorisez explicitement Outlook, les composants Office et le trafic sortant vers 127.0.0.1.
Désactiver provisoirement l’antivirus/EDR (si politique autorisée) pour tester si une interception TLS locale provoque l’abandon de la connexion.

FAQ

Pourquoi le test de compte réussit‑il mais pas l’envoi/réception ?
Le test de paramètres confirme la joignabilité des serveurs et la validité des ports/TLS. L’accès IMAP/SMTP réel, lui, dépend des jetons OAuth2. Si la redirection locale échoue, les jetons restent invalides : d’où la bannière « Sign in via browser » en boucle.

Dois‑je activer les « applications moins sécurisées » ou créer un mot de passe d’application ?
Non. Outlook 365 moderne utilise OAuth2. Il n’est pas nécessaire de modifier ports, TLS, ni d’employer des méthodes d’authentification obsolètes.

Le problème vient‑il de Google ou de Microsoft ?
Dans la plupart des cas, non. Le blocage se situe sur l’hôte Windows (redirection locale défaillante) et non sur les services distants. Le nettoyage local restaure le flux.

Puis‑je supprimer hosts.ics définitivement ?
Vous pouvez le commenter ou le supprimer, mais certains services (ICS/WSL) peuvent le régénérer. Le point clé est d’éliminer les entrées qui perturbent 127.0.0.1.

Que faire avec plusieurs comptes Gmail ?
Répétez la suppression des identifiants tp_google_imap_Oauth2 pour chaque compte, puis réauthentifiez‑les un par un.

Exemples de fichiers hosts avant/après

Avant (problématique)

# ...
127.0.0.1    localhost
::1          localhost
127.0.0.1    WIN-12345.mshome.net
127.0.0.1    wsl.mshome.net
127.0.0.1    vmnet.mshome.net
# ...

Après (corrigé)

# ...
127.0.0.1    localhost
::1          localhost
#127.0.0.1    WIN-12345.mshome.net
#wsl.mshome.net neutralisé
#127.0.0.1    wsl.mshome.net
#127.0.0.1    vmnet.mshome.net
# ...

Récapitulatif exécutable

Éditer hosts/hosts.ics en administrateur et commenter les lignes *.mshome.net ou redirections 127.0.0.1 douteuses.
Supprimer dans le Gestionnaire d’identifiants chaque MicrosoftOffice16_Data:OAUTH2 lié à tp_google_imap_Oauth2.
Retirer « Microsoft apps & services » des accès de votre compte Google puis relancer l’authentification.
Redémarrer le PC et tester l’envoi/réception.

Résultat

Une fois ces actions effectuées, les comptes Gmail se ré‑authentifient correctement et la synchronisation IMAP/SMTP repart immédiatement. Aucun changement de port, de chiffrement TLS ou de mot de passe n’est requis.

Annexe technique

Que fait Outlook en coulisses ? Il démarre un serveur HTTP local éphémère, écoute sur 127.0.0.1 un port aléatoire, et attend la redirection finale du navigateur. Le navigateur contacte alors https://localhost:<port>/ ; si la résolution/route locale est interceptée ou si le pare‑feu rejette la session loopback, la connexion est « refusée » ou « abandonnée ».

Pourquoi mshome.net ? Des composants de virtualisation et de partage de connexion (Hyper‑V, WSL, ICS, VMware) inscrivent des alias/règles facilitant le fonctionnement de réseaux virtuels. Dans certaines combinaisons, ces alias interagissent mal avec l’écoute locale attendue par Outlook.

Et la nouvelle application Outlook ? Elle s’appuie sur le même moteur d’authentification que la version classique ; la correction reste donc identique (nettoyage des jetons, des entrées hosts et ré‑autorisation Google).

Outlook 365 : corriger « localhost refusé » avec Gmail IMAP