Se connecter à Exchange Online PowerShell : guide pas à pas

Par Mirko Peters · 2026-11-12

Se connecter à Exchange Online PowerShell avec Connect-ExchangeOnline : prérequis, connexion interactive, MFA, options pour les partenaires et les scripts sans assistance, et solutions aux erreurs.

Traduit automatiquement par IA à partir de l'article original. Lire l'original en anglais

Pour vous connecter à Exchange Online PowerShell, chargez le module ExchangeOnlineManagement et exécutez Connect-ExchangeOnline -UserPrincipalName admin@yourdomain.com. Une fenêtre de connexion s'ouvre : saisissez votre mot de passe et validez la demande MFA, puis le shell est connecté. Cet article s'adresse aux administrateurs Exchange et Microsoft 365 qui ont besoin des étapes exactes, des options d'accès pour les partenaires et les scripts sans assistance, ainsi que d'une liste concise de solutions lorsque la connexion échoue. Il suit la documentation Microsoft actuelle : les commandes présentées supposent donc l'authentification moderne et l'absence de session PowerShell à distance.

Points clés

• Pour vous connecter à Exchange Online PowerShell, chargez le module et exécutez Connect-ExchangeOnline avec votre compte administrateur au format UPN.
• La connexion interactive fonctionne avec et sans authentification multifactorielle : inutile donc de chercher un contournement distinct pour la MFA.
• L'authentification de base et l'ancienne méthode New-PSSession ne sont plus prises en charge : les scripts qui les utilisent doivent être réécrits.
• Utilisez Get-AcceptedDomain comme test rapide après la connexion, et terminez toujours la session avec Disconnect-ExchangeOnline.
• Les scripts sans assistance doivent utiliser une authentification application uniquement ou une identité managée, plutôt qu'un mot de passe stocké.

Ce dont vous avez besoin avant de vous connecter

La commande de connexion provient du module : il faut donc l'installer au préalable. Si ce n'est pas encore fait, installez-le depuis la PowerShell Gallery avec Install-Module -Name ExchangeOnlineManagement. Dans la documentation Microsoft, ce module est appelé module V3. Microsoft couvre à la fois Windows PowerShell 5.1 et PowerShell 7. Pour PowerShell 7, la version 2.0.4 du module ou une version ultérieure est requise.

Quatre autres éléments déterminent si la connexion fonctionne :

• Autorisations. Le contrôle d'accès basé sur les rôles détermine les applets de commande que vous pouvez exécuter une fois connecté. Se connecter n'est pas le plus difficile : c'est d'exécuter la bonne applet de commande. Microsoft propose une page pour trouver les autorisations requises par une applet de commande, et il vaut la peine de la mettre en favori.
• Accès à PowerShell pour le compte. Le compte doit être autorisé à utiliser Exchange Online PowerShell. Si un administrateur a désactivé cet accès pour votre utilisateur, la connexion réussit, mais la session PowerShell ne s'établit pas.
• Réseau. Le port TCP 80 doit être ouvert entre votre ordinateur et Microsoft 365.
• Un chemin de profil sans caractères spéciaux. Microsoft indique que les commandes de connexion peuvent échouer si le chemin de votre profil utilisateur contient des caractères spéciaux PowerShell, comme $. Utilisez un autre compte si le vôtre en comporte.

Vous n'avez pas non plus à modifier quoi que ce soit dans WinRM. Les connexions actuelles utilisent REST en arrière-plan : l'ancienne recommandation consistant à activer l'authentification de base dans WinRM ne s'applique donc plus.

Comment se connecter à Exchange Online PowerShell, étape par étape

Il s'agit de la méthode interactive standard. Elle fonctionne de la même manière dans Windows PowerShell 5.1 et PowerShell 7, avec ou sans authentification multifactorielle.

1. Ouvrez une nouvelle fenêtre PowerShell. Une fenêtre vierge évite les conflits d’assemblages avec d’autres modules que vous auriez pu charger plus tôt dans la session.
2. Chargez le module avec Import-Module ExchangeOnlineManagement. Si le module est déjà installé, Microsoft indique qu’on peut généralement passer cette étape et aller directement à la commande de connexion, car PowerShell charge le module automatiquement.
3. Exécutez Connect-ExchangeOnline -UserPrincipalName admin@contoso.com, mais avec votre propre compte au format UPN. Dans certaines organisations, vous pouvez omettre -UserPrincipalName et être invité à le saisir. Si cela échoue, ajoutez le paramètre.
4. Saisissez votre mot de passe dans la fenêtre de connexion et sélectionnez Se connecter.
5. Si votre compte utilise l’authentification multifacteur (MFA), saisissez le code de vérification et sélectionnez Vérifier. Le code est envoyé par la méthode que vous avez configurée, par exemple un SMS ou Microsoft Authenticator. Dans PowerShell 7, la connexion utilise votre navigateur par défaut.
6. Attendez la bannière. L’absence d’erreur signifie que vous êtes connecté.

C’est tout. La même applet de commande vous connecte aux sessions PowerShell pour Microsoft 365 GCC sans paramètre supplémentaire. Seuls les autres clouds nécessitent un paramètre, que nous verrons ensuite.

Si vous ne souhaitez pas afficher la bannière d’accueil dans un journal de script, ajoutez -ShowBanner:$false. Si vous voulez que Get-Help affiche l’aide des applets de commande Exchange Online, ajoutez -LoadCmdletHelp. Depuis la version 3.7.0 du module, cette aide n’est plus chargée par défaut, ce qui surprend ceux qui mettent le module à jour et constatent que Get-Help ne renvoie presque rien.

Autres méthodes de connexion : PowerShell 7, partenaires et clouds

La documentation présente plusieurs variantes. Choisissez celle qui correspond à votre situation.

PowerShell 7 sans navigateur. Exécutez Connect-ExchangeOnline -Device. La commande affiche un message vous invitant à ouvrir https://microsoft.com/devicelogin et à saisir un code. Vous effectuez cette étape sur un autre appareil, vous vous connectez, confirmez, et la session initiale finalise sa connexion. Cela fonctionne avec ou sans MFA et s’avère utile sur des serveurs ou des machines Linux sans bureau.

PowerShell 7 avec identifiants en ligne. Connect-ExchangeOnline -UserPrincipalName admin@contoso.com -InlineCredential fonctionne pour les comptes sans MFA. La plupart des organisations exigent la MFA pour les administrateurs, vous utiliserez donc rarement cette méthode.

Windows PowerShell 5.1 avec un objet d’identification. Pour les comptes sans MFA, vous pouvez exécuter d’abord $Credential = Get-Credential, puis Connect-ExchangeOnline -Credential $Credential. Microsoft précise que si cela échoue, vous devez utiliser -UserPrincipalName à la place.

Locataires clients en tant que partenaire. Les partenaires du programme Cloud Solution Provider (CSP) et les administrateurs invités ajoutent -DelegatedOrganization, par exemple Connect-ExchangeOnline -UserPrincipalName admin@contoso.onmicrosoft.com -DelegatedOrganization adatum.onmicrosoft.com. La page de Microsoft renvoie au programme Cloud Solution Provider et aux privilèges d’administration déléguée granulaires (GDAP) pour la partie autorisations.

Clouds gouvernementaux et régionaux. -ExchangeEnvironmentName permet de sélectionner l’environnement. La valeur par défaut est O365Default, qui couvre Microsoft 365 et GCC. Les valeurs documentées pour les autres environnements sont O365USGovGCCHigh, O365USGovDoD, O365GermanyCloud et O365China.

Scripts sans surveillance. N’enregistrez jamais un mot de passe administrateur dans un script. Microsoft documente deux solutions plus sûres. Une identité managée, par exemple Connect-ExchangeOnline -ManagedIdentity -Organization "contoso.onmicrosoft.com", convient aux scripts qui s’exécutent dans Azure. L’authentification app-only avec un certificat convient à tous les autres cas. Le paramètre d’empreinte du certificat n’est pris en charge que sous Windows. La configuration implique un enregistrement d’application dans Microsoft Entra ID, l’autorisation d’application Exchange.ManageAsApp avec consentement administrateur, un certificat et un rôle pris en charge, comme Administrateur Exchange, attribué à l’application. Microsoft recommande le principe du privilège minimum : n’attribuez donc pas le rôle Administrateur général à l’application, sauf s’il n’existe aucune autre solution. Suivez l’article distinct de Microsoft sur l’authentification app-only plutôt qu’une version abrégée de celui-ci.

Dans un service Windows, ajoutez -SkipLoadingFormatData pour éviter les erreurs. Si vous voyez des erreurs mentionnant Web Account Manager, la version 3.7.2 ou ultérieure du module propose le commutateur -DisableWAM pour les résoudre.

Gardez les scripts légers : limitez les cmdlets importées

Une connexion importe normalement les cmdlets Exchange Online que vous êtes autorisé à utiliser. Cela convient pour un rapide coup d’œil sur une boîte aux lettres, mais un script qui n’a besoin que de trois commandes n’a pas besoin de toutes les autres. La page du module de Microsoft donne un conseil précis à ce sujet. Des appels fréquents à Connect-ExchangeOnline et Disconnect-ExchangeOnline dans la même session peuvent provoquer une fuite de mémoire. La solution consiste à se connecter une seule fois par script et à utiliser le paramètre -CommandName pour n’importer que les cmdlets nécessaires.

Un script qui ne fait que lire les statistiques des boîtes aux lettres, par exemple, n’a besoin que de cette seule commande. Nommez les quelques commandes utilisées, connectez-vous une fois en haut, effectuez le travail, puis déconnectez-vous une fois en bas. Les scripts écrits de cette façon sont plus faciles à relire, car la ligne de connexion indique au lecteur les commandes utilisées.

Deux autres bonnes pratiques facilitent la vie dans les environnements d’équipe. D’abord, centralisez la ligne de connexion, par exemple dans une petite fonction, afin qu’un changement de méthode d’authentification ne se fasse qu’une fois et non dans vingt scripts. Ensuite, consignez le compte ou le nom de l’application qui a exécuté le script, jamais son secret. Lorsqu’un changement inattendu survient dans une boîte aux lettres, cette ligne de journal peut vous faire gagner des heures.

Vérifiez proprement la connexion et la déconnexion

Une connexion sans erreur est un bon signe, mais testez-la avec une commande de lecture inoffensive. Get-AcceptedDomain liste les domaines de votre organisation et s’exécute en une seconde. Si des domaines apparaissent, votre session fonctionne et votre compte dispose au minimum d’un accès en lecture.

Pour afficher des détails sur vos connexions, utilisez Get-ConnectionInformation. La page du module de Microsoft précise que Get-PSSession ne renvoie rien d’utile pour ces connexions basées sur REST. Les anciens scripts qui vérifient Get-PSSession doivent donc être modifiés.

Une fois le travail terminé, exécutez Disconnect-ExchangeOnline. Ajoutez -Confirm:$false dans les scripts pour éviter l’invite de confirmation. L’article de Microsoft sur la connexion met en garde : fermer la fenêtre sans vous déconnecter peut épuiser vos sessions disponibles, et vous devrez alors attendre leur expiration.

Corrigez les erreurs de connexion les plus courantes

La plupart des échecs proviennent d’une courte liste de causes. Parcourez-les de haut en bas.

• Nom d’utilisateur ou mot de passe incorrect. Recommencez les étapes et vérifiez les deux. Cela semble banal, mais commencez par contrôler le format du UPN.
• L’accès à PowerShell est désactivé pour le compte. Un administrateur peut l’activer. Microsoft propose un article distinct sur l’activation ou la désactivation de l’accès à Exchange Online PowerShell.
• Le port 80 est bloqué. Demandez à votre équipe réseau d’autoriser le port TCP 80 vers Microsoft 365.
• Compte fédéré avec un fournisseur d’identité inaccessible. Si votre IDP ou STS n’est pas accessible publiquement, Microsoft suggère d’utiliser pour la connexion un compte non fédéré dans Microsoft 365.
• « The term 'Update-ModuleManifest' is not recognized ». La connexion nécessite PowerShellGet et sa dépendance PackageManagement. Mettez à jour les deux, puis redémarrez PowerShell.
• « Could not load file or assembly 'System.IdentityModel.Tokens.Jwt' ». Le module entre en conflit avec un autre module de la même session. Connectez-vous dans une nouvelle fenêtre Windows PowerShell avant d’importer quoi que ce soit d’autre.
• Erreurs dans une fenêtre ouverte par un service ou une tâche planifiée. Essayez -SkipLoadingFormatData.

Si aucun de ces cas ne s’applique, la version du module est la piste suivante. Exécutez Update-Module -Name ExchangeOnlineManagement dans la même portée que celle utilisée pour l’installation, puis réessayez dans une nouvelle fenêtre.

Erreurs courantes

• Utiliser l’authentification de base ou New-PSSession. Microsoft ne mentionne ces méthodes qu’à titre de référence historique et indique qu’elles ne sont plus prises en charge. Un script qui crée encore une session de cette manière doit être migré vers Connect-ExchangeOnline.
• Fermer la fenêtre au lieu de se déconnecter. Cela peut épuiser vos sessions. Faites de Disconnect-ExchangeOnline la dernière ligne de chaque script.
• Stocker un mot de passe en clair dans un script. Utilisez plutôt une identité managée ou un certificat.
• Importer d’autres modules au préalable. Un conflit avec un autre module peut faire échouer la connexion. Connectez-vous d’abord à Exchange Online, ou utilisez une nouvelle fenêtre.
• Supposer que la connexion vaut autorisation. Si une applet de commande est « non reconnue » après la connexion, votre rôle ne l’inclut pas. Il s’agit d’une question de RBAC, et non d’un problème de connexion.

Sujets connexes à explorer

• Installer et mettre à jour le module : la connexion dépend du bon module et de la bonne version de PowerShell. Consultez donc la configuration requise du module Exchange Online PowerShell avant de le déployer auprès d’une équipe.
• Trouver les autorisations d’une applet de commande : Microsoft explique comment identifier le rôle requis par une applet de commande Exchange donnée.
• Se connecter à Security & Compliance PowerShell : le même module propose Connect-IPPSSession, qui n’est pas disponible dans PowerShell 7 sous Linux ou macOS.
• Automatisation sans surveillance : l’authentification d’application seule et les identités managées sont la méthode à privilégier pour exécuter en toute sécurité les scripts Exchange planifiés.
• Traitements en masse volumineux : les applets de commande basées sur REST ont un délai d’expiration de 15 minutes. Découpez donc les mises à jour importantes de membres en lots.

Prochaine étape

Pour vous connecter de façon fiable à Exchange Online PowerShell, commencez par une nouvelle fenêtre, exécutez Connect-ExchangeOnline -UserPrincipalName avec votre compte administrateur, testez avec Get-AcceptedDomain, puis déconnectez-vous une fois terminé. Ensuite, concevez vos scripts sans surveillance autour d’une identité managée ou d’un certificat, afin que personne n’ait à saisir ni stocker un mot de passe.