Dans un environnement PowerShell 7 dédié à l’administration Microsoft 365, il est fréquent d’installer les modules Microsoft.Graph et PnP.PowerShell. Pris séparément, ces modules fonctionnent correctement. En revanche, leur utilisation conjointe peut provoquer des erreurs inattendues.

Après l’installation de PnP.PowerShell, des commandes Microsoft Graph parfaitement valides peuvent échouer avec le message suivant :

Could not load type
‘Microsoft.Graph.Authentication.AzureIdentityAccessTokenProvider’
from assembly ‘Microsoft.Graph.Core’

Cette erreur n’est ni liée aux permissions Graph ni à l’authentification. Elle est causée par un conflit de dépendances .NET. PnP.PowerShell embarque ses propres versions des bibliothèques Microsoft Graph (Core, Authentication, Azure.Identity). Lors de l’import du module, ces DLL sont chargées en mémoire.

PowerShell ne fournit pas de mécanisme d’isolation des assemblies par module. La première version chargée d’une DLL est utilisée par toute la session. Ainsi, lorsque Microsoft.Graph PowerShell est exécuté dans la même session, il peut se retrouver à utiliser une version de Microsoft.Graph.Core trop ancienne, ne contenant pas les classes attendues.

Comment corriger le problème

La solution la plus simple consiste à fermer la session PowerShell et à relancer une session dédiée uniquement à Microsoft Graph. Si nécessaire, il est également recommandé de réinstaller le module Graph afin de s’assurer de la cohérence des versions :

Get-InstalledModule Microsoft.Graph* -AllVersions | Uninstall-Module -Force
Install-Module Microsoft.Graph -Force

Comment éviter le problème à l’avenir

La seule approche réellement fiable est de ne jamais utiliser Microsoft.Graph et PnP.PowerShell dans la même session PowerShell. Chaque module doit être exécuté dans une session distincte, avec des scripts séparés selon l’usage (Graph ou PnP).

Ce comportement n’est pas un bug des scripts ni une mauvaise configuration utilisateur. Il s’agit d’une limite structurelle du modèle de chargement des assemblies .NET dans PowerShell. Le connaître permet d’éviter des diagnostics inutiles et de concevoir des automatisations Microsoft 365 plus robustes.