Récupérer une Clé BitLocker (Guide 2026)

Un matin de mars 2026. Vos utilisateurs allument leur poste et tombent sur l'écran bleu redouté qui leur réclame une clé de récupération BitLocker à 48 chiffres. Le ticketing s'enflamme. La cause ? Probablement un changement firmware UEFI, une mise à jour Windows qui a basculé sur le nouveau Windows Boot Manager signé en 2023, ou tout simplement un effacement TPM un peu trop enthousiaste. Bref, pour le technicien helpdesk, savoir où retrouver cette clé en moins de deux minutes — que le poste soit joint à un domaine Active Directory, à Microsoft Entra ID ou inscrit dans Intune — n'est plus un luxe, c'est devenu une compétence fondamentale.

Honnêtement, j'ai vu trop de techniciens paniquer face à cet écran (la première fois, on est tous passés par là). Ce guide couvre donc la totalité du parcours en 2026 : comprendre pourquoi BitLocker se déclenche, identifier la bonne clé via son Recovery Key ID, l'extraire depuis AD avec PowerShell, l'obtenir depuis Entra ID via Microsoft Graph, et — surtout — configurer un stockage centralisé pour ne plus jamais revivre la même galère.

Pourquoi BitLocker demande une clé de récupération ?

BitLocker repose sur le TPM (Trusted Platform Module), qui mesure l'état du démarrage : firmware UEFI, ordre de boot, Secure Boot, bootloader Windows, tout y passe. Si la mesure ne correspond plus à la valeur scellée lors du chiffrement, le TPM refuse tout simplement de libérer la clé principale (la VMK). Windows considère alors qu'il y a potentiellement altération, et bascule en mode récupération. C'est paranoïaque, mais c'est précisément le but.

Les déclencheurs les plus fréquents en 2026 :

Mise à jour de sécurité d'avril 2026 — Windows passe au Boot Manager signé en 2023, ce qui modifie le PCR 7 et déclenche le mode récupération sur les postes avec stratégies BitLocker strictes. (C'est la grosse vague de l'année.)
Mise à jour du firmware UEFI ou du BIOS.
Modification de l'ordre de démarrage, ou activation/désactivation du Secure Boot.
Effacement du TPM (« Clear TPM » dans l'UEFI ou via tpm.msc).
Remplacement de la carte mère ou du disque — le TPM change, et c'est game over.
Démarrage sur une clé USB d'installation pour réparer le système.
Échecs d'authentification PIN BitLocker répétés.

Important, et je ne le répéterai jamais assez : la clé de récupération est générée une seule fois, au moment du chiffrement. Si elle n'a pas été sauvegardée correctement (AD DS, Entra ID, Intune, compte Microsoft, fichier ou impression), personne ne peut la régénérer. Pas même Microsoft. Le poste devient alors irrécupérable, et seule la réinitialisation efface définitivement les données.

Anatomie d'une clé de récupération

L'écran de récupération affiche deux éléments distincts qu'il faut absolument savoir différencier :

Recovery Key ID : un GUID au format 4BEABAB4-C3F9-4916-8A2B-D13D9E011936. Les huit premiers caractères suffisent à identifier la bonne clé dans l'annuaire.
Recovery Password : la chaîne de 48 chiffres groupée par 6, par exemple 123456-654321-...-987654. C'est ce que l'utilisateur saisit pour déverrouiller.

Un même volume peut avoir plusieurs key protectors. Dans la pratique helpdesk, vous utiliserez systématiquement le Recovery Key ID affiché à l'écran pour retrouver la bonne ligne dans AD ou Entra ID. Et ne tentez jamais de saisir un mot de passe au hasard : six erreurs consécutives déclenchent un délai croissant, et certaines stratégies imposent même un effacement après un seuil défini. Vous voilà prévenu.

Méthode 1 — Récupération depuis Active Directory (on-premise)

Sur les postes joints à un domaine AD DS, la clé est stockée dans un sous-objet de type msFVE-RecoveryInformation attaché à l'objet ordinateur. À condition, bien sûr, que la GPO « Sélectionner la méthode de récupération des lecteurs du système d'exploitation protégés par BitLocker » ait été configurée avant le chiffrement. Sinon, c'est trop tard.

Vérifier la prise en charge du schéma AD

Sur Windows Server 2012 et versions suivantes, le schéma contient déjà les classes nécessaires. Vérifiez avec PowerShell :

Get-ADObject -SearchBase ((Get-ADRootDSE).SchemaNamingContext) `
    -Filter { Name -like 'ms-FVE-*' } |
    Select-Object Name, ObjectClass

Vous devez voir au minimum ms-FVE-RecoveryInformation, ms-FVE-RecoveryGuid, ms-FVE-RecoveryPassword et ms-FVE-VolumeGuid. Sinon, étendez le schéma avant de déployer la GPO — sinon vos clés iront se perdre dans le néant.

Activer l'onglet « Récupération BitLocker » dans la console

Dans Utilisateurs et ordinateurs Active Directory, l'onglet Récupération BitLocker n'apparaît qu'après installation de la fonctionnalité BitLocker Drive Encryption Administration Utilities :

Add-WindowsFeature RSAT-Feature-Tools-BitLocker-RemoteAdminTool

Récupérer une clé via PowerShell (par nom de poste)

L'approche la plus fiable utilise Get-ADObject avec le DN du poste comme SearchBase :

Import-Module ActiveDirectory

$ComputerName = 'PC-LYON-042'
$Computer = Get-ADComputer -Identity $ComputerName

$Keys = Get-ADObject `
    -Filter { objectClass -eq 'msFVE-RecoveryInformation' } `
    -SearchBase $Computer.DistinguishedName `
    -Properties 'msFVE-RecoveryPassword', 'whenCreated'

$Keys | Sort-Object whenCreated -Descending | ForEach-Object {
    [PSCustomObject]@{
        KeyId       = $_.Name.Substring(11, 8).ToUpper()
        Date        = $_.whenCreated
        Password    = $_.'msFVE-RecoveryPassword'
    }
}

Le nom de l'objet msFVE-RecoveryInformation commence par la date suivie du GUID complet. La sous-chaîne à partir du caractère 11 isole le Recovery Key ID, à comparer ensuite avec celui affiché à l'écran. Simple, efficace.

Récupérer une clé par Recovery Key ID seul

Si l'utilisateur n'identifie pas son poste — situation hyper courante dans les flottes mobiles — utilisez directement le Recovery Key ID :

$KeyId = '4BEABAB4'  # 8 premiers caractères affichés à l'écran

Get-ADObject -LDAPFilter "(&(objectClass=msFVE-RecoveryInformation)(name=*$KeyId*))" `
    -Properties 'msFVE-RecoveryPassword', 'distinguishedName' |
    Select-Object @{N='Computer';E={ ($_.DistinguishedName -split ',CN=')[1] }},
                  @{N='KeyId'; E={ $_.Name.Substring(11, 8) }},
                  @{N='Password'; E={ $_.'msFVE-RecoveryPassword' }}

Sauvegarder manuellement une clé existante dans AD

Lorsqu'un poste a été chiffré avant l'application de la GPO, sa clé n'est pas dans AD. Forcez la sauvegarde rétroactivement, en exécutant ce qui suit localement sur le poste, en tant qu'administrateur :

$Vol = Get-BitLockerVolume -MountPoint 'C:'
$Protector = $Vol.KeyProtector |
    Where-Object KeyProtectorType -eq 'RecoveryPassword'

Backup-BitLockerKeyProtector `
    -MountPoint 'C:' `
    -KeyProtectorId $Protector.KeyProtectorId

Méthode 2 — Récupération depuis Microsoft Entra ID

Pour les postes Entra Joined ou Hybrid Joined, la clé est stockée sur l'objet appareil dans le tenant. Trois rôles intégrés peuvent la lire : Cloud Device Administrator, Helpdesk Administrator et Intune Administrator. Pour respecter le principe de moindre privilège (et c'est franchement la bonne pratique à adopter), créez plutôt un rôle personnalisé avec uniquement la permission microsoft.directory/bitlockerKeys/key/read.

Méthode rapide via le portail

L'URL https://aka.ms/aadrecoverykey redirige vers la liste des appareils du compte connecté. Pour un autre utilisateur, passez par Microsoft Entra admin center → Devices → All devices → [appareil] → BitLocker keys → Show recovery key. À noter : chaque affichage déclenche une entrée dans le journal d'audit KeyManagement. C'est une bonne chose, ça vous protège en cas d'incident.

Récupération via Microsoft Graph PowerShell

Installez et connectez le module Graph avec les portées appropriées :

Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes 'BitlockerKey.Read.All', 'Device.Read.All'

Récupérez ensuite la liste des clés (sans le mot de passe), puis le mot de passe d'une clé précise :

$DeviceName = 'PC-LYON-042'
$Device = Get-MgDevice -Filter "displayName eq '$DeviceName'"

$KeyMeta = Get-MgInformationProtectionBitlockerRecoveryKey `
    -Filter "deviceId eq '$($Device.DeviceId)'"

foreach ($k in $KeyMeta) {
    $Full = Get-MgInformationProtectionBitlockerRecoveryKey `
        -BitlockerRecoveryKeyId $k.Id `
        -Property 'key,createdDateTime,volumeType'
    [PSCustomObject]@{
        Created     = $Full.CreatedDateTime
        VolumeType  = $Full.VolumeType
        Password    = $Full.Key
    }
}

Le paramètre -Property 'key,...' est indispensable — sans lui, la propriété key reste masquée, et vous récupérerez de jolis nuls. Chaque appel de cette forme génère par ailleurs un événement d'audit dans Entra audit logs → KeyManagement.

Audit de couverture du parc

Pour identifier les postes Entra inscrits qui n'ont aucune clé sauvegardée — typiquement les machines chiffrées avant l'inscription, ou celles pour lesquelles l'escrow a échoué :

$AllDevices = Get-MgDevice -All -Filter "operatingSystem eq 'Windows'"
$Missing = foreach ($d in $AllDevices) {
    $Has = Get-MgInformationProtectionBitlockerRecoveryKey `
        -Filter "deviceId eq '$($d.DeviceId)'" -Top 1
    if (-not $Has) { $d.DisplayName }
}
$Missing | Out-File missing-bitlocker-keys.csv

Méthode 3 — Récupération via Intune et Portail d'entreprise

Quand BitLocker est déployé via une stratégie Intune, la clé est automatiquement escrowée dans Entra ID. Deux chemins helpdesk existent :

Intune admin center — Devices → Windows → [appareil] → Recovery keys. Affiche également l'identifiant TPM, ce qui est pratique pour le diagnostic.
Self-service par l'utilisateur, depuis un autre appareil : https://portal.manage.microsoft.com, puis Appareils → [PC] → Obtenir la clé de récupération. La clé reste affichée 5 minutes pour des raisons de sécurité (court, mais largement suffisant).

Sur un poste où la stratégie Intune est appliquée mais où la clé n'apparaît pas dans Entra (cas fréquent en migration, soit dit en passant), forcez la synchronisation depuis le poste :

$BLV = Get-BitLockerVolume -MountPoint 'C:'
$RP  = ($BLV.KeyProtector | ? KeyProtectorType -eq 'RecoveryPassword').KeyProtectorId
BackupToAAD-BitLockerKeyProtector -MountPoint 'C:' -KeyProtectorId $RP

Procédure helpdesk : du ticket à la résolution en 5 étapes

Vérifier l'identité de l'utilisateur via une question de challenge ou un appel vidéo. La clé BitLocker équivaut à un accès complet aux données du poste — on ne plaisante pas avec ça.
Demander le Recovery Key ID affiché à l'écran (les 8 premiers caractères suffisent). Faites prendre une photo si la dictée est fastidieuse — l'écran ne contient aucune information sensible.
Identifier l'environnement : poste joint au domaine, Entra Joined, Hybrid ou Workgroup. Un script unifié Find-BitLockerKey.ps1 qui teste AD puis Entra automatise ce tri (et vous fera gagner un temps fou sur le long terme).
Communiquer la clé par canal sécurisé — ne dictez jamais 48 chiffres au téléphone. Utilisez un outil de partage à expiration (par exemple One-Time Secret auto-hébergé) ou un push via votre outil ITSM.
Investiguer la cause racine après déverrouillage : journal Windows Microsoft-Windows-BitLocker/BitLocker Management, événement 24620 ou 24622. Si la cause est une mise à jour Windows (avril 2026, on en reparle juste après), planifiez une mise à jour de la stratégie BitLocker.

Le piège d'avril 2026 : prévenir la vague de récupérations

La mise à jour cumulative d'avril 2026 a basculé Windows 11 sur le Windows Boot Manager signé en 2023. Sur les machines avec une stratégie BitLocker imposant une validation TPM stricte (PCR 7 fixe), cette transition est interprétée comme une altération et déclenche le mode récupération massivement. Massivement, ça veut dire : 30 % des postes d'un parc en une matinée. Ne demandez pas comment je le sais.

Trois actions préventives à mener avant le déploiement en masse :

Auditer la couverture des clés avec le script de la section précédente — toute machine sans clé escrowée doit être traitée en priorité absolue.
Suspendre BitLocker pendant la fenêtre de déploiement de la KB :
```
Suspend-BitLocker -MountPoint 'C:' -RebootCount 2
```
Le compteur RebootCount 2 couvre le redémarrage post-update et le redémarrage de réactivation.
Assouplir la stratégie TPM en autorisant Windows à choisir un profil PCR compatible plutôt que de forcer une validation stricte. Voir la valeur de registre HKLM\SOFTWARE\Policies\Microsoft\FVE\PlatformValidation_*.

Bonnes pratiques de configuration GPO

Une configuration GPO correcte fait la différence entre une panne de 2 minutes et un poste perdu pour de bon. Les paramètres incontournables, sous Computer Configuration → Policies → Administrative Templates → Windows Components → BitLocker Drive Encryption :

Operating System Drives → Choose how BitLocker-protected operating system drives can be recovered :
- Cocher Save BitLocker recovery information to AD DS for operating system drives.
- Sélectionner Backup recovery passwords and key packages.
- Cocher Do not enable BitLocker until recovery information is stored to AD DS — ça empêche le chiffrement si l'escrow échoue. Indispensable.
Activer Choose drive encryption method and cipher strength et imposer XTS-AES 256 bits sur les disques fixes.
Pour les environnements hybrides, activer Allow standard users to enable encryption during Microsoft Entra Join.

Foire aux questions

Comment savoir si la clé BitLocker est bien sauvegardée dans AD ou Entra ID ?

Sur le poste, exécutez manage-bde -protectors -get C: et notez le Numerical Password ID. Comparez ce GUID avec les sous-objets msFVE-RecoveryInformation dans AD, ou avec Get-MgInformationProtectionBitlockerRecoveryKey -Filter "deviceId eq '...'" pour Entra. Si l'ID n'apparaît dans aucun annuaire, c'est que la clé n'est pas escrowée — utilisez immédiatement Backup-BitLockerKeyProtector ou BackupToAAD-BitLockerKeyProtector.

Que faire si l'utilisateur a perdu la clé et qu'elle n'est ni dans AD ni dans Entra ID ?

Mauvaise nouvelle : il n'existe aucune méthode légitime de contournement. Microsoft ne dispose pas de back-door BitLocker (et tant mieux, d'ailleurs). Vérifiez d'abord les sources de sauvegarde alternatives : compte Microsoft personnel de l'utilisateur (https://account.microsoft.com/devices/recoverykey), clé USB d'export, fichier texte sur partage personnel, impression. Si toutes les pistes sont épuisées, la seule issue reste la réinitialisation du PC depuis l'environnement de récupération Windows — qui efface toutes les données chiffrées.

Pourquoi la clé n'apparaît-elle pas dans Entra ID alors que la stratégie Intune est appliquée ?

Trois causes typiques : (1) la machine était chiffrée avant l'inscription Intune et le déchiffrement/rechiffrement n'a pas été effectué ; (2) le poste n'a pas pu joindre le tenant au moment du chiffrement (réseau, certificat, ce genre de choses) ; (3) la stratégie autorise le chiffrement avant escrow. Forcez la sauvegarde avec BackupToAAD-BitLockerKeyProtector, et corrigez la stratégie en cochant Client-driven recovery password rotation dans Intune.

Combien de temps dois-je conserver les clés BitLocker dans Entra ID ?

Conservez-les aussi longtemps que l'appareil existe dans le tenant. Lorsqu'un appareil est supprimé d'Entra ID, ses clés sont également purgées après le délai de rétention soft-delete (30 jours par défaut). Pour les exigences de conformité au-delà, exportez périodiquement les clés via Graph dans un coffre-fort sécurisé (Azure Key Vault par exemple), idéalement chiffré avec une clé HSM-backed.

La rotation automatique des clés BitLocker est-elle activée par défaut ?

Non, et c'est dommage. Pour les appareils Entra Joined gérés par Intune, activez explicitement Client-driven recovery password rotation dans la stratégie BitLocker. La rotation s'exécute automatiquement après chaque utilisation d'une clé de récupération, ce qui garantit qu'une clé divulguée par téléphone ne reste pas valide indéfiniment. Pour les postes joints uniquement à AD DS, aucune rotation native n'existe — il faut un script planifié appelant Add-BitLockerKeyProtector puis Remove-BitLockerKeyProtector sur l'ancien.