Erreur 0xc0090016 Microsoft 365 après changement de carte mère (TPM) : corriger AAD Broker et rétablir l’authentification

Après un remplacement de carte mère, Microsoft 365 (Teams, OneDrive, Outlook…) peut refuser toute connexion sous Windows 10/11 avec le code 0xc0090016. Voici une méthode sûre et rapide pour restaurer l’authentification, plus des vérifications avancées.

Sommaire

Vue d’ensemble de la question

Un PC Windows 10/11, parfaitement fonctionnel avant l’intervention matérielle, ne parvient plus à authentifier les applications Microsoft 365 après changement de carte mère. L’erreur affichée est 0xc0090016. La connexion via un navigateur web et depuis un téléphone reste possible, ce qui oriente vers un problème local sur l’ordinateur (jetons et cache d’authentification).

Symptôme	Contexte	Impact
Teams/OneDrive/Outlook bouclent sur la connexion ou échouent	Après remplacement de la carte mère (TPM différente)	Impossible d’accéder aux fichiers, réunions, boîtes aux lettres
Code d’erreur affiché	`0xc0090016`	Erreur d’authentification locale (cache/jetons invalides)
Connexion via navigateur/mobile	OK	Le compte n’est pas bloqué côté cloud : le souci est sur Windows

Pourquoi l’erreur survient après un changement de carte mère ?

Le remplacement de la carte mère modifie la puce TPM (Trusted Platform Module) de l’ordinateur. Or, Windows utilise la TPM pour protéger des secrets d’authentification (par exemple, le Primary Refresh Token ou PRT) via le composant Azure AD Broker Plugin et la pile WAM (Web Account Manager). Après le changement de TPM, les jetons chiffrés localement ne correspondent plus au nouveau matériel : ils deviennent invalides et les applications Microsoft 365 ne peuvent plus obtenir de jetons actualisés, d’où le code 0xc0090016.

Composant	Rôle	Ce qui change après remplacement
TPM	Stocke/assiste le chiffrement de secrets et clés	Nouvelle TPM = clés matérielles différentes
Azure AD Broker Plugin (`Microsoft.AAD.BrokerPlugin`)	Gère les jetons d’accès/actualisation et l’SSO pour Microsoft 365	Cache de jetons chiffré lié à l’ancienne TPM devient inutilisable
WAM (Web Account Manager)	Fournit l’authentification moderne aux applications Windows	Échec lors de l’accès aux secrets liés au précédent matériel

Solution recommandée : forcer la recréation du cache AAD (non destructif)

La méthode la plus efficace consiste à renommer le dossier d’authentification Azure AD afin que Windows régénère un cache sain au prochain lancement des applications.

Avant de commencer

Assurez-vous d’avoir un compte administrateur local ou d’entreprise.
Si BitLocker est activé, notez votre clé de récupération. Cette procédure ne modifie pas BitLocker, mais d’autres actions de la section « Si l’erreur persiste » peuvent l’exiger.
Cette opération est non destructive : seules les informations d’authentification locales sont régénérées, vos données restent intactes.

Étape 1 : activer (temporairement) le compte Administrateur intégré

Ouvrez une invite de commande en tant qu’administrateur et exécutez :

net user administrator /active:yes

Sur certains Windows en français, le compte peut s’appeler Administrateur. Pour vérifier la liste des comptes :

net user

Si nécessaire :

net user administrateur /active:yes

Déconnectez la session courante, puis ouvrez une session avec ce compte Administrateur.

Étape 2 : renommer le dossier Azure AD Broker dans le profil de l’utilisateur affecté

Deux options équivalentes :

Option A (Explorateur)

Dans l’Explorateur de fichiers, accédez au profil de l’utilisateur impacté :
C:\Users\<NomUtilisateur>\AppData\Local\Packages\
Repérez le dossier :
Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
Renommez-le, par exemple en :
Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy.old

Astuce : si vous ne voyez pas AppData, activez l’affichage des éléments cachés.

Option B (Invite de commandes)

Adaptez <NomUtilisateur> puis exécutez :

ren "C:\Users\&lt;NomUtilisateur&gt;\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy" "Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy.old"

Option C (PowerShell — automatisation)

Pour renommer le dossier dans un profil précis :

$user = "&lt;NomUtilisateur&gt;"
$base = "C:\Users\$user\AppData\Local\Packages"
$src  = Join-Path $base "Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy"
$dst  = Join-Path $base "Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy.old"
If (Test-Path $src) { Rename-Item -Path $src -NewName (Split-Path $dst -Leaf) -Force }

Pour traiter tous les profils utilisateurs locaux (hors systèmes) :

$profiles = Get-ChildItem 'C:\Users' -Directory | Where-Object { $_.Name -notmatch '^Public$|^Default' }
foreach ($p in $profiles) {
  $src = Join-Path $p.FullName 'AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy'
  if (Test-Path $src) {
    $dst = Join-Path (Split-Path $src -Parent) 'Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy.old'
    try { Rename-Item -Path $src -NewName (Split-Path $dst -Leaf) -Force } catch {}
  }
}

Étape 3 : se reconnecter avec l’utilisateur concerné

Déconnectez la session Administrateur.
Ouvrez la session de l’utilisateur affecté, puis lancez Outlook, Teams ou OneDrive.
Au premier démarrage, les applications demandent l’authentification : saisissez le mot de passe et, le cas échéant, acceptez « Autoriser mon organisation à gérer cet appareil ».

Étape 4 : désactiver le compte Administrateur intégré

Quand tout fonctionne, refermez la porte :

net user administrator /active:no

Ou selon le nom localisé :

net user administrateur /active:no

Pourquoi cette méthode fonctionne

Le dossier Microsoft.AAD.BrokerPlugin contient des jetons et artefacts d’authentification chiffrés et liés à la TPM précédente. En le renommant, on oblige Windows à recréer un cache d’authentification vierge au prochain lancement des applications. Les nouveaux jetons sont alors correctement scellés à la nouvelle TPM, rétablissant l’SSO et l’accès aux ressources Microsoft 365.

Vérifier que la réparation a réussi

Teams s’ouvre sans boucle de connexion et accède aux conversations/équipes.
OneDrive passe au statut « Synchronisé », sans erreur de compte.
Outlook charge le profil en authentification moderne et envoie/reçoit.
Dans une invite PowerShell : dsregcmd /status affiche des indicateurs cohérents (par ex. AzureAdPrt : YES).

Si l’erreur persiste : diagnostic et correctifs complémentaires

La majorité des cas se corrigent en une seule passe. Si des symptômes subsistent, suivez l’ordre ci‑dessous.

Vérifier l’horloge et le fuseau horaire

Un décalage de temps casse l’authentification.

Paramètres → Heure et langue → Activer la mise à l’heure automatique et le fuseau correct.
En invite administrateur :

w32tm /resync /force

Réinitialiser l’inscription « Accès professionnel ou scolaire »

Paramètres → Comptes → Accès professionnel ou scolaire.
Sélectionnez le compte d’entreprise, cliquez sur Déconnecter.
Redémarrez puis reconnectez le même compte (suivez les invites).

Cette action reconstruit l’association WAM/PRT côté Windows.

Purger les identifiants liés à Office/Microsoft 365

Ouvrez Gestionnaire d’identification (Panneau de configuration).
Dans Identifiants Windows, supprimez les entrées obsolètes liées à Office/Microsoft (indices « Office », « ADAL », « Enterprise », « TokenBroker »).
Relancez les applications Microsoft 365 et signez à nouveau.

Vider les caches applicatifs si besoin

Teams (classique) : fermez Teams, puis supprimez le contenu de :
%AppData%\Microsoft\Teams (les données seront reconstruites).
Office : fermez toutes les applis puis redémarrez Word/Outlook pour re-négocier l’authentification.

Contrôler l’état d’appartenance Azure AD

En PowerShell :

dsregcmd /status

Vérifiez au minimum AzureAdJoined / WorkplaceJoined / SSO State. En cas d’état incohérent, vous pouvez :

Quitter l’inscription : Paramètres → Comptes → Accès professionnel ou scolaire → Déconnecter.
Redémarrer et réinscrire le poste avec le même compte.

Cas rare : effacer la TPM (après sauvegarde et suspension de BitLocker)

À n’utiliser qu’en dernier recours sur un matériel sain, et uniquement si la TPM contient des états contradictoires.

Suspendre BitLocker pour éviter toute demande de clé au redémarrage :

manage-bde -protectors -disable C:

Entrer dans l’UEFI/BIOS et Clear TPM (varie selon le constructeur), confirmer.
Démarrer Windows, puis réactiver BitLocker :

manage-bde -protectors -enable C:

Reconnectez‑vous dans les applications Microsoft 365. Le cache AAD sera proprement reconstruit.

Poste membre d’un domaine (AD) ou en hybrid join

Si le poste est joint à un domaine Active Directory avec synchronisation Azure AD (hybrid join), confirmez que la stratégie d’entreprise n’empêche pas l’usage du compte Administrateur local. Si c’est le cas, réalisez l’opération de renommage avec un autre compte ayant les droits locaux au poste, ou en Mode sans échec. En environnement géré (Intune/Group Policy), la réinscription MDM/Workplace peut aussi être nécessaire après correction du cache.

Bonnes pratiques et sécurité

Renommer vs supprimer : renommer le dossier est réversible et évite une suppression définitive. Si tout fonctionne, vous pourrez supprimer l’ancien dossier ultérieurement.
Données personnelles : seules les informations d’authentification locales sont réinitialisées. Les fichiers utilisateur et les profils d’applications restent intacts.
Gestion des comptes : désactivez toujours le compte Administrateur intégré après usage.
BitLocker : ne touchez pas à la TPM si vous n’êtes pas certain des implications. Suspendez/réactivez correctement les protecteurs si vous devez intervenir sur la TPM.

Guide pas‑à‑pas récapitulatif

Activer le compte Administrateur intégré : net user administrator /active:yes
Depuis ce compte, renommer le dossier de l’utilisateur impacté :
C:\Users\<NomUtilisateur>\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy → …\.old
Revenir sur l’utilisateur affecté et se reconnecter dans Outlook/Teams/OneDrive.
Accepter, si demandé, « Autoriser mon organisation à gérer cet appareil ».
Désactiver le compte Administrateur intégré : net user administrator /active:no

Commandes utiles pour le diagnostic

Objectif	Commande	Ce à vérifier
État de l’adhésion Azure AD / PRT	`dsregcmd /status`	AzureAdPrt : YES, cohérence des statuts
Synchronisation de l’horloge	`w32tm /resync /force`	Éviter les dérives de temps
État de la TPM	`powershell Get-Tpm`	TpmPresent, TpmReady
BitLocker (suspension)	`manage-bde -protectors -disable C:`	Avant toute opération sur la TPM
BitLocker (réactivation)	`manage-bde -protectors -enable C:`	Après intervention sur la TPM

FAQ

Dois‑je réinstaller Office ?

Non. Le problème vient du cache d’authentification lié à la TPM, pas de l’installation d’Office. La recréation du dossier Microsoft.AAD.BrokerPlugin suffit dans l’immense majorité des cas.

Pourquoi la connexion web/mobile fonctionne‑t‑elle ?

Les connexions depuis un navigateur ou un téléphone utilisent d’autres jetons (non scellés à la TPM de votre PC). Le compte est sain côté cloud ; la panne se situe dans le cache local de Windows.

Que risque‑je en renommant le dossier ?

Rien de critique : vous ne touchez qu’aux jetons locaux. Les fichiers utilisateur, les messages Outlook et les données OneDrive/SharePoint ne sont pas supprimés. Au pire, vous devrez resaisir vos identifiants et effectuer une validation MFA.

Le compte Administrateur est désactivé par la sécurité de mon entreprise. Comment faire ?

Utilisez un autre compte ayant les droits d’administrateur local, ou démarrez en Mode sans échec pour renommer le dossier dans le profil de l’utilisateur impacté. L’objectif est d’éviter les verrous de fichiers tout en ciblant le bon profil.

Après renommage, l’erreur persiste dans une seule application

Purger le cache spécifique de l’application concernée (ex. Teams), puis redémarrer. Si besoin, déconnectez/reconnectez l’entrée Accès professionnel ou scolaire dans les Paramètres.

En bref

Le code 0xc0090016 après un remplacement de carte mère est typique d’un décalage entre la nouvelle TPM et les jetons locaux scellés à l’ancienne. Le renommage du dossier Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy dans le profil de l’utilisateur affecté force Windows à reconstruire un environnement d’authentification propre. La procédure est rapide, non destructive et a prouvé son efficacité. En cas de persistance, les pistes complémentaires (horloge, réinscription Accès professionnel ou scolaire, purge des identifiants, voire effacement contrôlé de la TPM) permettent de revenir à une situation saine.

Procédure condensée : activer l’Administrateur intégré → renommer Microsoft.AAD.BrokerPlugin dans C:\Users\<Utilisateur>\AppData\Local\Packages → reconnecter l’utilisateur dans les applis Microsoft 365 → désactiver l’Administrateur intégré.

Après‑coup : dans les cas observés, la méthode a résolu la panne immédiatement, confirmant qu’il s’agit du correctif le plus simple et le plus sûr lorsque l’authentification moderne casse après un changement de carte mère.