Outlook ne peut pas ajouter Gmail/Google Workspace via OAuth : corriger l’erreur « We couldn’t log on to the incoming server »

Depuis octobre 2024, l’ajout d’un compte Gmail/Google Workspace dans Outlook 2016/2019/365 peut échouer avec le message « We couldn’t log on to the incoming (POP/IMAP) server ». Voici la procédure éprouvée pour rétablir l’authentification OAuth et l’IMAP.

Sommaire

Problème et symptômes

De nombreux utilisateurs constatent qu’Outlook refuse subitement d’associer une boîte Gmail/Google Workspace via le flux OAuth standard. Le scénario est quasi identique :

À l’ajout du compte, vous sélectionnez Google comme type de compte, Outlook revient aussitôt avec l’erreur : We couldn't log on to the incoming (POP/IMAP) server sans jamais demander le mot de passe.
L’activation d’IMAP (ou POP) dans Gmail n’y change rien.
La configuration manuelle avec imap.gmail.com / smtp.gmail.com échoue également.
Le problème affecte surtout des Office/Outlook non à jour (builds antérieures à la branche 16.0.17531.x) et des postes où des jetons OAuth obsolètes sont toujours stockés.

Cause la plus probable

Le message d’erreur masque généralement un échec d’authentification OAuth silencieux. Outlook conserve des jetons/cookies d’identité dans le Gestionnaire d’identifiants Windows (CredMan) et dans des caches Office. Après un changement côté Google (révocation, consentement Microsoft apps & services non accordé, durcissement de sécurité du domaine, etc.), ces jetons deviennent invalides. Quand Outlook tente de réutiliser des informations périmées, il n’atteint même plus l’écran Google de saisie du mot de passe et retombe sur l’erreur POP/IMAP trompeuse. La correction consiste à forcer une relance complète du flux OAuth en supprimant l’accès précédent côté Google et en purgeant les identifiants locaux.

Solution express validée

La séquence ci‑dessous a permis de rétablir l’ajout du compte chez les utilisateurs concernés.

Étape	Action	But
Révoquer l’accès d’Outlook	Dans le compte Google → Sécurité → Applications tierces → Microsoft Apps & Services → Retirer l’accès.	Forcer la suppression des anciens jetons OAuth périmés côté Google.
Purger les identifiants sous Windows	Ouvrir Gestionnaire d’identifiants → Informations d’identification Windows → supprimer toutes les entrées `MicrosoftOffice16_Data:OAUTH2...tp_google_imap_oauth2` (repérable via le Registre : `HKCU\Software\Microsoft\Office\16.0\Common\Identity\Identities`).	Éliminer les cookies/jetons corrompus conservés localement.
Relancer Outlook et se connecter via le navigateur	Ajouter à nouveau le compte ; Outlook ouvre un navigateur pour Google. Cocher « Microsoft apps and services » quand Google le demande, puis valider.	Générer de nouveaux jetons OAuth valides et finaliser l’association du compte.
Re‑tester la synchronisation	Lancer Envoyer/Recevoir et vérifier l’état IMAP (dossiers, lecture, envoi).	Confirmer que la liaison Outlook ↔ Gmail est rétablie.

Procédure détaillée pas à pas

Révoquer l’accès d’Outlook dans Google

Connectez‑vous au compte Google concerné.
Ouvrez Sécurité → Votre accès aux apps tierces.
Choisissez Microsoft Apps & Services.
Cliquez sur Retirer l’accès (révocation immédiate).

Pourquoi ? Cette action supprime les droits précédemment accordés à Outlook. Au prochain ajout de compte, Google affichera à nouveau la page de consentement et produira des jetons neufs.

Astuce admin Google Workspace : si votre organisation restreint l’accès aux applications tierces, vérifiez qu’applis Microsoft est autorisé dans les paramètres de contrôle des apps tierces du domaine. Sans cela, l’écran de consentement peut ne jamais s’afficher.

Purger les identifiants Windows et le cache d’identité Office

Le nettoyage le plus fiable passe par l’interface graphique de Windows, avec sauvegarde préalable du Registre en cas de doute.

Via le Gestionnaire d’identifiants

Ouvrez Panneau de configuration → Comptes d’utilisateurs → Gestionnaire d’identifiants.
Allez dans Informations d’identification Windows.
Recherchez et supprimez toutes les entrées commençant par MicrosoftOffice16_Data:OAUTH2 et contenant tp_google_imap_oauth2 (ainsi que d’éventuelles variantes tp_google_smtp_oauth2).

Pour s’orienter via le Registre

Vous pouvez identifier l’UID de l’identité Outlook liée à votre boîte Gmail dans :

HKCU\Software\Microsoft\Office\16.0\Common\Identity\Identities

Dans chaque clé (GUID), vérifiez les attributs (adresse e‑mail, type de fournisseur) pour repérer l’identité Google correspondante. Ne supprimez pas d’entrées au hasard si vous n’êtes pas sûr ; contentez‑vous de la purge via le Gestionnaire d’identifiants.

Raccourcis utiles

Accéder directement au Gestionnaire d’identifiants : control.exe /name Microsoft.CredentialManager
Ancienne boîte de dialogue des identifiants : rundll32.exe keymgr.dll,KRShowKeyMgr

Option avancée et prudente (sauvegarde/clear)

Exportez avant toute modification :

reg export "HKCU\Software\Microsoft\Office\16.0\Common\Identity" "%USERPROFILE%\Desktop\OfficeIdentityBackup.reg"

La suppression globale des identités Office est possible mais déconseillée si vous gérez plusieurs comptes. Ne procédez que si vous maîtrisez l’impact.

Relancer Outlook et réaliser l’authentification OAuth

Redémarrez Outlook.
Ajoutez un nouveau compte, saisissez l’adresse Gmail/Google Workspace.
Quand la fenêtre Google s’ouvre, authentifiez‑vous puis cochez l’option Microsoft apps and services sur l’écran de consentement.
Validez. Outlook crée le profil IMAP et télécharge la structure des dossiers.

Remarques essentielles :

WebView2 : Outlook s’appuie sur le runtime Microsoft Edge WebView2 pour l’authentification moderne. Si la fenêtre web ne s’affiche pas, vérifiez la présence du runtime dans les applications installées et réparez‑le au besoin.
Heure du système : un décalage important de l’horloge Windows casse souvent OAuth. Synchronisez l’heure/UTC et réessayez.

Vérifier la synchronisation IMAP

Lancez un Envoyer/Recevoir et observez la barre d’état d’Outlook.
Contrôlez l’abonnement IMAP (clic droit sur le compte → Dossiers IMAP → Interroger → S’abonner aux dossiers souhaités).
Testez l’envoi via SMTP en vous envoyant un e‑mail.

Vérifications indispensables côté Google

IMAP activé dans Gmail (recommandé plutôt que POP).
Double authentification (2FA) activée pour renforcer la sécurité du compte.
Mot de passe d’application : si OAuth ne peut pas être utilisé (environnement verrouillé), générez un mot de passe d’application et configurez Outlook en IMAP classique (voir plus bas). C’est accepté, mais moins sécurisé qu’OAuth.
Restrictions domaine : dans certains tenants Google Workspace, les admins limitent les applications tierces autorisées. Demandez à inclure Microsoft apps and services dans la liste blanche.
Programme de protection avancée : si le compte est inscrit, des consentements supplémentaires peuvent être requis.

Mise à jour d’Outlook/Office et versions concernées

Le dysfonctionnement touche prioritairement des versions antérieures aux builds 16.0.17531.x. Sur Microsoft 365/Office LTSC/2019, une mise à jour Office peut suffire :

Outlook → Fichier → Compte → Options de mise à jour → Mettre à jour maintenant.
Vérifiez le Canal de mise à jour (Mensuel, Semi‑annuel) et ciblez une build récente.

Bon à savoir : même à jour, un jeton local corrompu peut bloquer l’auth. D’où l’importance de la double action révoquer côté Google + purger CredMan.

Alternative IMAP classique avec mot de passe d’application

En dernier recours (ou dans des environnements très restreints), vous pouvez contourner OAuth via un mot de passe d’application Google. Créez‑le depuis votre compte (2FA requis) puis configurez Outlook en IMAP/SMTP manuels :

Paramètre	Valeur
Serveur IMAP	`imap.gmail.com` — Port `993` — Sécurité SSL/TLS — Authentification Mot de passe d’application
Serveur SMTP	`smtp.gmail.com` — Port `465` — Sécurité SSL/TLS — Authentification requise
Nom d’utilisateur	Adresse e‑mail complète (ex. : `prenom.nom@domaine.com`)
Mot de passe	Mot de passe d’application à 16 caractères (pas le mot de passe principal du compte)

Limites : pas d’authentification moderne, pas de consentement granulaire. Préférez OAuth dès que possible.

Diagnostic avancé

Réseau, VPN et proxy

La redirection OAuth exige que la machine atteigne sans interception les domaines Google. Les proxies filtrants, VPN d’entreprise, filtres SSL/AV ou portails captifs peuvent bloquer la séquence. Pour trier :

Essayer hors VPN/proxy, ou sur un autre réseau (partage 4G/5G).
Mettre temporairement l’antivirus en mode passif (si la politique le permet) puis réessayer.
Autoriser au minimum : accounts.google.com, oauth2.googleapis.com, www.googleapis.com, apis.google.com, ssl.gstatic.com, imap.gmail.com, smtp.gmail.com.
Écarter tout proxy système dans Paramètres Windows → Réseau & Internet → Proxy (test temporaire).

Runtime web d’authentification (WebView2)

Outlook s’appuie sur Microsoft Edge WebView2 pour rendre la page de connexion Google. Si rien ne s’affiche ou si la fenêtre clignote et disparaît :

Vérifier la présence de Microsoft Edge WebView2 Runtime dans les applications installées.
Réparer ou réinstaller le runtime puis relancer l’ajout du compte.

Nettoyage de l’identité Office et déconnexion globale

Dans une application Office (Word/Excel), ouvrez Fichier → Compte, puis Se déconnecter de tous les comptes.
Dans Paramètres Windows → Comptes → Accéder au travail ou à l’école, déconnectez les comptes personnels qui ne sont plus utilisés (si applicable).

Heure, certificats et TLS

Resynchronisez l’heure Windows avec un serveur NTP fiable.
Vérifiez que l’inspection SSL n’introduit pas de certificat racine non approuvé du côté client.
Assurez‑vous que TLS 1.2/1.3 est autorisé par la stratégie locale.

Indicateurs fréquemment observés

Symptôme	Interprétation	Action
Erreur immédiate POP/IMAP sans saisie du mot de passe	Flux OAuth court‑circuité par un jeton local périmé/corrompu	Révoquer l’accès + Purger les identifiants Windows
Fenêtre de connexion qui n’apparaît pas	Runtime WebView2 absent ou bloqué par un AV/proxy	Réinstaller/réparer WebView2, tester hors proxy
Consentement Google non proposé	Accès tiers restreint par la politique Google Workspace	Demander à l’admin de permettre Microsoft apps and services
Profil Outlook qui fonctionne sur un autre PC	Problème local (CredMan, cache, runtime)	Nettoyage identifiants + réparation Office/WebView2

Bonnes pratiques de sécurité

Préférez l’authentification moderne OAuth avec consentement explicite.
Activez la 2FA sur tous les comptes Google Workspace.
Sur les postes partagés, évitez de conserver des profils Outlook persistants avec des comptes personnels.
Documentez la procédure de révocation d’accès lors des départs d’utilisateurs.

FAQ

Pourquoi Outlook me parle d’un serveur POP/IMAP alors que j’utilise Google ?

Le message est trompeur : il s’affiche quand Outlook n’obtient pas de jeton OAuth et ne peut donc pas tester IMAP/SMTP. La cause est presque toujours l’authentification qui ne s’est pas lancée correctement.

Dois‑je activer POP ?

Non, IMAP suffit et est recommandé. POP peut rester désactivé.

Est‑ce que la mise à jour d’Office seule résout le problème ?

Parfois, oui. Mais si des identifiants corrompus subsistent dans Windows, même une version récente d’Outlook échouera tant que vous n’aurez pas nettoyé CredMan et relancé le flux OAuth.

Le mot de passe d’application est‑il sûr ?

C’est moins robuste qu’OAuth (droits larges, pas de révocation granulaire). À utiliser temporairement ou dans des environnements où OAuth n’est pas disponible.

Comment vérifier que tout est bien synchronisé ?

Ouvrez Dossiers IMAP pour vous abonner à tous les dossiers utiles, surveillez la barre d’état d’Outlook, envoyez un e‑mail de test et contrôlez son arrivée côté Gmail.

Que faire si j’ai plusieurs comptes Google ?

Répétez la révocation d’accès et la purge des identifiants pour chaque compte concerné, en vérifiant que vous consentez Microsoft apps and services à la bonne adresse.

Et si l’entreprise impose un proxy avec inspection SSL ?

Demandez à faire exclure les domaines Google OAuth de l’inspection ou à déployer le certificat racine d’inspection sur le poste. Dans l’intervalle, testez sur un réseau sans interception pour confirmer le diagnostic.

Le problème peut‑il revenir ?

Rarement, mais oui si une politique change côté Google/Windows/Office. La même procédure (révoquer → purger → reconnecter) reste la solution la plus efficace.

Checklist de résolution rapide

IMAP activé + 2FA sur le compte Google.
Révocation de Microsoft Apps & Services sur le compte Google.
Purge des entrées MicrosoftOffice16_Data:OAUTH2...google... dans le Gestionnaire d’identifiants Windows.
Outlook à jour (build récente).
Reconnexion via la fenêtre Google et consentement coché pour Microsoft apps and services.
Test Envoyer/Recevoir, abonnement IMAP et envoi SMTP OK.

Résumé et résultat

Dans les cas étudiés, l’enchaînement révoquer l’accès côté Google → purger les identifiants Windows → relancer Outlook et consentir « Microsoft apps and services » a immédiatement rétabli l’ajout du compte et la synchronisation IMAP dans Outlook. Si malgré tout OAuth reste impossible sur votre environnement (proxy/AV stricts, politique d’entreprise), la configuration IMAP via mot de passe d’application demeure une alternative fonctionnelle, à considérer comme un plan B.

Annexes utiles

Chemins et éléments à connaître

Élément	Où le trouver	Remarques
Identités Office	`HKCU\Software\Microsoft\Office\16.0\Common\Identity\Identities`	Explorer pour identifier l’identité liée à Gmail (adresse e‑mail, fournisseur).
Entrées CredMan Outlook/Google	Gestionnaire d’identifiants → Informations d’identification Windows	Rechercher `MicrosoftOffice16_Data:OAUTH2*` incluant `tp_google_imap_oauth2` / `tp_google_smtp_oauth2`.
Mise à jour Office	Outlook → Fichier → Compte	Assurez‑vous d’être sur une build récente de votre canal ; appliquez Mettre à jour maintenant.
Runtime WebView2	Applications installées (Windows)	Réparer/réinstaller si la fenêtre d’authentification n’apparaît jamais.

Bonnes pratiques IMAP dans Outlook

Activez la mise en cache suffisante des dossiers très volumineux pour limiter les re‑synchronisations.
Évitez les règles locales complexes lors des premières heures de synchronisation.
Surveillez la taille du fichier de données IMAP (.ost) et laissez la première indexation se terminer.

Quand se contenter d’une mise à jour Office ?

Si votre Outlook est très en retard et que le problème est dû à un composant d’authentification corrigé dans une build récente, la mise à jour seule pourra suffire. Cependant, si vous avez tenté à plusieurs reprises d’ajouter le compte avant d’actualiser, des jetons invalides auront probablement été déposés ; une purge restera nécessaire.

Points de contrôle après correction

L’écran Google de consentement s’affiche de manière fiable lors de l’ajout d’autres comptes.
Le consentement « Microsoft apps and services » est coché.
La barre d’état ne présente plus d’erreurs IMAP/SMTP.
La recherche Outlook retourne des résultats cohérents dans les dossiers Gmail (la première indexation peut être longue).

Conclusion : si Outlook n’arrive plus à ajouter un compte Gmail/Google Workspace et renvoie l’erreur « We couldn’t log on to the incoming (POP/IMAP) server », pensez d’abord flux OAuth bloqué plutôt que « serveur IMAP en panne ». En révoquant l’accès Microsoft côté Google, en purgant les identifiants Windows et en relançant l’authentification via navigateur avec le bon consentement, vous soldez la majorité des cas en quelques minutes. Conservez l’option du mot de passe d’application uniquement comme filet de sécurité.