Désactiver BitLocker avant la réinstallation ? L’étape que l’on néglige

février 8, 2026 • février 8, 2026 • Lecture : 29 min • Views: 1

Cet article vous a aidé ?

La plupart des réinstallations de Windows ne ratent pas parce que l’installeur est défaillant. Elles échouent parce que quelqu’un a modifié la chaîne de démarrage pendant que BitLocker observait. Vous redémarrez et vous tombez sur une invite de clé de récupération que vous ne pouvez pas satisfaire, ou vous « nettoyez et réinstallez » et découvrez que l’ordinateur portable est devenu une brique chiffrée que personne ne peut déverrouiller.

Si vous gérez des flottes, c’est pire : une étape oubliée devient une tempête au support, un incident de conformité et une semaine d’archéologie « qui a la clé de récupération ». BitLocker est un bon système de sécurité. Il est aussi extrêmement littéral.

L’étape que l’on néglige (et pourquoi c’est problématique)

L’étape oubliée n’est pas « faire une sauvegarde ». Ce n’est même pas « exporter les pilotes ». C’est vérifier l’état de BitLocker et soit suspendre, soit désactiver BitLocker avant de modifier quoi que ce soit qui affecte le processus de démarrage : réinstaller, reimage, mise à jour du BIOS, réinitialisation du TPM, changement de Secure Boot, clonage de disque, modification de partitions ou remplacement de la carte mère.

Les gens l’oublient parce que BitLocker reste généralement silencieux. Lorsqu’il fonctionne, il est invisible. Cette invisibilité apprend aux administrateurs et aux utilisateurs avancés à le traiter comme une case à cocher plutôt que comme une politique cryptographique appliquée par des mesures matérielles.

Voici la vérité opérationnelle : BitLocker n’est pas un « chiffrement de disque » abstrait. C’est un ensemble de clés protégées par des protecteurs (TPM, PIN, mot de passe de récupération, clé de démarrage) et libérées selon des conditions. Réinstaller Windows modifie souvent ces conditions. BitLocker fait donc ce pour quoi il a été conçu : retenir la clé.

Si vous avez de la chance, vous obtenez une invite de récupération et la clé de récupération existe quelque part. Sinon, vous avez des indisponibilités, une perte de données, ou les deux.

Une citation à garder sur votre mur : « L’espoir n’est pas une stratégie. » — idée paraphrasée attribuée à Gene Kranz. La gestion des clés de récupération BitLocker est l’endroit où l’espoir meurt.

Ce que « désactiver » signifie réellement

En environnement réel, dire « désactiver BitLocker » peut signifier trois actions différentes :

Suspendre la protection : le chiffrement reste en place, mais les protecteurs sont temporairement désactivés pour que les changements de démarrage/reboot ne déclenchent pas la récupération.
Désactiver BitLocker (déchiffrer) : le volume est déchiffré. C’est plus lent mais cela supprime complètement le chiffrement.
Effacer le disque : si vous détruisez les données de manière sécurisée, il n’est pas nécessaire de déchiffrer ; il faut juste s’assurer de ne pas se retrouver avec un volume chiffré non amorçable après le flux d’effacement.

Choisissez la bonne action selon le besoin. Se tromper est la façon dont une « simple réinstallation » devient une file de tickets et des réunions.

Blague n°1

BitLocker, c’est comme un videur qui ne vous oublie jamais. Vous changez de coupe de cheveux (a.k.a. paramètres Secure Boot), et soudain vous n’êtes plus « sur la liste ».

Comportement de BitLocker en termes opérationnels

BitLocker protège la Volume Master Key (VMK), qui déverrouille la Full Volume Encryption Key (FVEK). La VMK est ce qui est gardé par vos protecteurs. La plupart des portables d’entreprise modernes reposent sur un protecteur basé sur le TPM, souvent combiné avec des mesures Secure Boot et parfois un PIN.

Au démarrage de Windows, le système tente de déverrouiller la VMK depuis le TPM. Le TPM ne déverrouillera que si les mesures correspondent à ce qu’il attend (valeurs PCR, état Secure Boot, intégrité du chargeur de démarrage, etc.). Une réinstallation modifie souvent les fichiers du chargeur, les entrées BCD, les GUID de partition et parfois la politique Secure Boot. Pour le TPM, cela revient à « une machine différente ».

Quelques conséquences pratiques :

Réinstaller Windows peut déclencher la récupération même si le disque n’a jamais bougé. Les composants de démarrage ont changé.
Cloner un disque chiffré BitLocker vers un autre appareil n’est pas une astuce propre. Le TPM du nouvel appareil ne pourra pas déverrouiller la clé.
Les mises à jour du BIOS/UEFI peuvent déclencher une récupération si la protection n’a pas été suspendue au préalable.
« Réinitialiser le TPM » est une opération qui entraîne une perte de données sauf si vous avez confirmé l’existence des clés de récupération et des protecteurs.

Les pires échecs proviennent du mélange de workflows : utiliser les outils de récupération OEM, basculer ensuite sur une clé USB d’installation Windows, puis tenter une réinitialisation Intune Autopilot. Chaque étape modifie subtilement la chaîne de démarrage. BitLocker observe tout cela.

Faits et historique qui expliquent les modes de défaillance actuels

BitLocker est apparu avec Windows Vista (2007), et les premières déploiements reposaient fortement sur le TPM — la sécurité dépendait d’une « racine matérielle de confiance » bien avant que ce soit tendance.
Les déploiements de l’ère Vista utilisaient souvent TPM + clés USB de démarrage parce que le TPM-seul était jugé risqué dans certaines organisations. Cet héritage explique pourquoi vous voyez encore des options « clé de démarrage » dans les outils actuels.
Microsoft a introduit Device Encryption sur certains appareils grand public, qui ressemble à BitLocker mais se comporte différemment dans l’interface et les paramètres par défaut. C’est pourquoi les utilisateurs domestiques sont souvent surpris de découvrir que le chiffrement s’est activé « tout seul ».
Les clés de récupération sont passées de « imprimer et classer » à « séquestre en annuaire » (AD DS puis Azure AD/Entra ID). Ce changement a résolu un problème et en a créé un autre : les échecs d’escrow sont maintenant une dette opérationnelle silencieuse.
L’adoption de Secure Boot (UEFI) a changé les mesures. L’intégrité de démarrage s’est améliorée, mais désormais de petits changements de réglages firmware ont de réelles conséquences sur le déverrouillage des clés.
Les appareils Modern Standby ont poussé les fabricants vers le chiffrement systématique car les états de veille et la reprise rapide augmentent le risque de vol et réduisent la friction pour activer le chiffrement.
« Réinitialiser ce PC » sous Windows 10/11 a évolué à plusieurs reprises. Certaines versions gèrent BitLocker correctement ; certaines combinaisons de partitions OEM, WinRE et paramètres de politique posent problème.
Les performances NVMe et SSD ont rendu le chiffrement disque « peu coûteux ». C’est pourquoi le chiffrement est désormais attendu par défaut — davantage de systèmes sont expédiés chiffrés, donc davantage de réinstallations entrent en collision avec lui.
L’adoption du TPM 2.0 s’est accélérée avec les exigences de Windows 11. Davantage d’appareils s’appuient désormais sur des protecteurs TPM ; davantage d’appareils entreront en récupération si vous touchez à la chaîne de démarrage sans suspendre.

Suspendre vs désactiver vs effacer : l’arbre de décision

Voici l’ensemble de règles subjectives que j’utilise en production :

1) Si vous voulez conserver les données et que vous réinstallez sur la même machine

Suspendre BitLocker avant de faire quoi que ce soit. Confirmez quand même que vous avez la clé de récupération. Puis réinstallez. Ensuite réactivez la protection. La suspension est plus rapide et conserve le chiffrement.

2) Si vous transférez la propriété, remettez à un nouvel employé, ou mettez l’appareil au rebut

Ne perdez pas de temps à déchiffrer juste pour effacer. Vérifiez que vous pouvez effacer en toute sécurité puis suivez un processus d’effacement conforme. Le chiffrement BitLocker peut faire partie de votre démarche de mise au rebut, mais seulement si vous êtes sûr que les clés ne seront pas récupérables et que votre processus respecte la politique.

3) Si vous changez la carte mère/TPM ou suspectez un problème TPM

Sauvegardez la clé de récupération, puis désactivez BitLocker (déchiffrez) si vous avez besoin d’un accès continu après le changement matériel. Si vous ne déchiffrez pas, vous misez tout sur la disponibilité des clés de récupération et la configuration de démarrage correcte après le changement.

4) Si vous dépannez des boucles de démarrage/récupération étranges

Arrêtez de deviner. Inspectez les protecteurs et le statut. Confirmez si vous voyez une invite de récupération normale ou si vous êtes dans un environnement mixte (entrées OS multiples, profil PCR modifié, Secure Boot basculé, WinRE incompatible).

Mode opératoire de diagnostic rapide

Ceci est l’ordre d’opérations « arrêter l’hémorragie » quand on vous contacte avec : « L’ordinateur demande la clé BitLocker après une réinstallation » ou « La ré-imagerie est bloquée en récupération ».

Première étape : Identifiez exactement de quoi il s’agit

S’agit‑il d’une récupération BitLocker (écran bleu demandant une clé à 48 chiffres), d’un mot de passe Windows ou d’un mot de passe BIOS ?
L’appareil est‑il joint au domaine, joint à Entra ou aucun des deux ? Cela détermine où la clé de récupération peut être séquestrée.
Ont‑ils modifié les paramètres du firmware (Secure Boot, UEFI/Legacy, réinitialisation TPM) ? Ce sont des déclencheurs classiques.

Deuxième étape : Vérifiez l’escrow des clés avant de toucher quoi que ce soit

Confirmez que la clé de récupération existe dans le système attendu (AD DS, portail Entra/MDM, notes du ticket ou coffre sécurisé).
Si aucune clé n’existe, décidez rapidement : avons‑nous besoin de récupérer des données, ou pouvons‑nous effacer et réinstaller ?

Troisième étape : Déterminez le chemin le plus rapide pour restaurer le service

Si vous avez la clé : utilisez‑la, démarrez, puis suspendre et reprendre BitLocker pour ré-sceller correctement les clés.
Si vous n’avez pas la clé et que les données ne sont pas critiques : effacez le disque et réinstallez proprement.
Si vous n’avez pas la clé et que les données comptent : stoppez. Montez une procédure de récupération des données (souvent « irrécupérable » si les clés ont disparu).

Tâches pratiques avec commandes, sorties et décisions (12+)

Ci‑dessous se trouvent des tâches que j’exécute réellement (ou que je fais exécuter par mon équipe) pour éviter les désastres de réinstallation liés à BitLocker. Les commandes sont natives Windows. Les sorties sont représentatives. Vos chiffres exacts varieront ; le sens restera le même.

Tâche 1 : Vérifier l’état de BitLocker sur tous les volumes

cr0x@server:~$ manage-bde -status
BitLocker Drive Encryption: Configuration Tool version 10.0.22621
Copyright (C) Microsoft Corporation. All rights reserved.

Volume C: [OS]
[OS Volume]
    Size:                 475.50 GB
    BitLocker Version:    2.0
    Conversion Status:    Fully Encrypted
    Percentage Encrypted: 100.0%
    Encryption Method:    XTS-AES 256
    Protection Status:    Protection On
    Lock Status:          Unlocked
    Identification Field: None
    Key Protectors:
        TPM

Ce que signifie la sortie : C: est chiffré et la protection est activement appliquée.

Décision : Si vous prévoyez une réinstallation, suspendez d’abord (Tâche 4) ou déchiffrez (Tâche 6) selon le scénario.

Tâche 2 : Confirmer que vous êtes en TPM‑seul (ou quelque chose de plus strict)

cr0x@server:~$ manage-bde -protectors -get C:
BitLocker Drive Encryption: Configuration Tool version 10.0.22621

Volume C: [OS]
All Key Protectors

    TPM:
      ID: {6F9C3D5A-18E7-4DB5-AF8E-8A7F7B0D0A01}

    Numerical Password:
      ID: {C0A0D96D-1AC8-4F2E-9B2E-5B4A10B9DD22}
      Password:
        123456-123456-123456-123456-123456-123456-123456-123456

Ce que signifie la sortie : Un protecteur TPM existe, et il y a aussi un protecteur de mot de passe de récupération (bon signe).

Décision : Si le protecteur de mot de passe de récupération manque, arrêtez et ajoutez‑en un (Tâche 3) avant de réinstaller.

Tâche 3 : Ajouter un protecteur de mot de passe de récupération (si manquant)

cr0x@server:~$ manage-bde -protectors -add C: -recoverypassword
BitLocker Drive Encryption: Configuration Tool version 10.0.22621

Volume C: [OS]
A numerical password protector was added to volume C:.
Numerical Password:
  654321-654321-654321-654321-654321-654321-654321-654321

Ce que signifie la sortie : Vous avez maintenant une clé de récupération qui peut déverrouiller C: si le scellement TPM échoue.

Décision : Stockez/escrowez cette clé selon la politique avant toute réinstallation. Si vous ne pouvez pas la stocker, vous n’êtes pas prêt.

Tâche 4 : Suspendre la protection BitLocker pour une réinstallation (rapide, réversible)

cr0x@server:~$ manage-bde -protectors -disable C:
BitLocker Drive Encryption: Configuration Tool version 10.0.22621

Volume C: [OS]
Key protectors are disabled for volume C:.

Ce que signifie la sortie : Le chiffrement reste, mais BitLocker n’appliquera pas les protecteurs au démarrage jusqu’à sa réactivation.

Décision : Poursuivez la réinstallation/la modification du firmware. Après un démarrage réussi, réactivez (Tâche 5).

Tâche 5 : Réactiver la protection BitLocker après réinstallation

cr0x@server:~$ manage-bde -protectors -enable C:
BitLocker Drive Encryption: Configuration Tool version 10.0.22621

Volume C: [OS]
Key protectors are enabled for volume C:.

Ce que signifie la sortie : Les protecteurs sont à nouveau actifs ; le scellement TPM se basera sur le nouvel état de démarrage.

Décision : Si cela échoue ou déclenche la récupération au prochain démarrage, quelque chose dans la chaîne de démarrage est instable (voir Erreurs courantes).

Tâche 6 : Désactiver BitLocker (déchiffrer) quand il faut retirer le chiffrement

cr0x@server:~$ manage-bde -off C:
BitLocker Drive Encryption: Configuration Tool version 10.0.22621

Decryption is now in progress.

Ce que signifie la sortie : Le déchiffrement a commencé ; cela prendra du temps et nécessite que la machine reste allumée.

Décision : Utilisez ceci avant un remplacement de carte mère/TPM si vous voulez un accès sans complication après le changement matériel.

Tâche 7 : Surveiller la progression du chiffrement/déchiffrement

cr0x@server:~$ manage-bde -status C:
Volume C: [OS]
    Conversion Status:    Decryption in Progress
    Percentage Encrypted: 72.4%
    Protection Status:    Protection Off

Ce que signifie la sortie : Le déchiffrement est en cours ; n’interrompez pas avec une réinstallation pour l’instant.

Décision : Attendez que Conversion Status soit « Fully Decrypted » avant de faire des changements perturbateurs qui supposent un volume en clair.

Tâche 8 : Valider l’état de Secure Boot (déclencheur courant de réinstallation)

cr0x@server:~$ powershell -NoProfile -Command "Confirm-SecureBootUEFI"
True

Ce que signifie la sortie : Secure Boot est activé.

Décision : Ne basculez pas Secure Boot au milieu d’un processus à moins d’avoir suspendu BitLocker. Si c’est False et que votre baseline attend True, attendez‑vous à des invites de récupération.

Tâche 9 : Vérifier la présence et l’état du TPM

cr0x@server:~$ powershell -NoProfile -Command "Get-Tpm | Format-List TpmPresent,TpmReady,ManagedAuthLevel"
TpmPresent : True
TpmReady   : True
ManagedAuthLevel : Full

Ce que signifie la sortie : Le TPM existe et est prêt à sceller/désceller des clés.

Décision : Si TpmPresent est False ou TpmReady est False, ne partez pas sur des hypothèses TPM‑seul ; prévoyez l’entrée de clé de récupération et/ou le déchiffrement avant travaux matériels/firmware.

Tâche 10 : Identifier le mode de démarrage (UEFI vs Legacy) important pour les mesures BitLocker

cr0x@server:~$ powershell -NoProfile -Command "(Get-ComputerInfo).BiosFirmwareType"
Uefi

Ce que signifie la sortie : Le système démarre en mode UEFI.

Décision : Si quelqu’un bascule en Legacy/CSM, cela peut déclencher la récupération. Gardez le mode de démarrage cohérent pendant la réinstallation.

Tâche 11 : Vérifier l’état de l’environnement de récupération Windows (WinRE) (souvent négligé)

cr0x@server:~$ reagentc /info
Windows Recovery Environment (Windows RE) and system reset configuration
Information:

    Windows RE status:         Enabled
    Windows RE location:       \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
    Boot Configuration Data (BCD) identifier: 12345678-90ab-cdef-1234-567890abcdef
    Recovery image location:
    Recovery image index:      0
    Custom image location:
    Custom image index:        0

Ce que signifie la sortie : WinRE est activé et pointe vers une partition de récupération.

Décision : Si WinRE est désactivé ou pointe vers une partition manquante, certains workflows de réinitialisation se comporteront mal. Corrigez avant de compter sur « Réinitialiser ce PC ».

Tâche 12 : Utiliser DiskPart pour confirmer le disque que vous êtes sur le point d’effacer (prévenir les interruptions auto‑infligées)

cr0x@server:~$ diskpart

Microsoft DiskPart version 10.0.22621.1

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          476 GB      0 B        *
  Disk 1    Online         1863 GB  1863 GB        *

DISKPART> select disk 0

Disk 0 is now the selected disk.

DISKPART> list vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     C   OS           NTFS   Partition    475 GB  Healthy    Boot
  Volume 1         SYSTEM       FAT32  Partition    260 MB  Healthy    System
  Volume 2         Recovery     NTFS   Partition    980 MB  Healthy    Hidden

Ce que signifie la sortie : Le disque 0 est le disque OS, GPT, avec des partitions EFI et Récupération.

Décision : Si vous vouliez effacer un disque externe et que vous regardez le disque interne OS, arrêtez. Confirmez par taille/modèle (Tâche 13) avant de lancer « clean ».

Tâche 13 : Confirmer le modèle physique du disque (pour ne pas effacer le mauvais)

cr0x@server:~$ powershell -NoProfile -Command "Get-Disk | Select Number,FriendlyName,SerialNumber,Size | Format-Table -Auto"
Number FriendlyName              SerialNumber   Size
------ ------------              ------------   ----
0      NVMe SAMSUNG MZVLW512     S4X9NX0K12345  476.94 GB
1      USB  SanDisk Extreme      3232333435     1.81 TB

Ce que signifie la sortie : Vous pouvez clairement distinguer le NVMe interne du USB externe.

Décision : Ne procédez que quand vous pouvez nommer le disque que vous êtes sur le point de détruire. « Le disque 0, probablement » est la façon dont les carrières deviennent intéressantes.

Tâche 14 : Effacer le disque pour une réinstallation propre (destructif)

cr0x@server:~$ diskpart

DISKPART> select disk 0

Disk 0 is now the selected disk.

DISKPART> clean

DiskPart succeeded in cleaning the disk.

Ce que signifie la sortie : La table de partitions est effacée ; le disque est maintenant non alloué.

Décision : Utilisez ceci lorsque vous effectuez intentionnellement une installation propre et que la conservation des données n’est pas requise. Pour les SSD, c’est généralement suffisant pour une réinstallation ; pour une mise au rebut sécurisée, suivez la méthode d’assainissement approuvée par votre organisation.

Tâche 15 : Confirmer que le disque est maintenant vide (vérification finale)

cr0x@server:~$ diskpart

DISKPART> list vol

There are no volumes.

Ce que signifie la sortie : Il n’y a plus de volumes ; l’installateur Windows devrait voir de l’espace non alloué.

Décision : Procédez maintenant à l’installation de Windows. Si des volumes apparaissent encore, vous avez effacé le mauvais disque ou vous êtes dans le mauvais environnement.

Tâche 16 : Après réinstallation, vérifier que BitLocker protège à nouveau

cr0x@server:~$ manage-bde -status C:
Volume C: [OS]
    Conversion Status:    Fully Encrypted
    Percentage Encrypted: 100.0%
    Protection Status:    Protection On

Ce que signifie la sortie : Le chiffrement est terminé et la protection est active.

Décision : Si Protection Status est Off après le déploiement, vous êtes hors conformité. Corrigez la politique/le flux d’applicatif avant d’expédier l’appareil.

Trois micro-récits d’entreprise tirés du terrain

Micro-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a déployé une nouvelle image Windows sur quelques centaines d’ordinateurs portables. L’équipe a supposé « BitLocker est géré par la politique, donc ça s’arrangera tout seul. » Leur séquence de tâches incluait une mise à jour BIOS pour corriger un problème de station d’accueil, puis un redémarrage, puis une mise à niveau sur place.

Les premières machines sont passées. Puis le support a commencé à recevoir des appels : des portables ont démarré sur la récupération BitLocker. Les utilisateurs n’avaient pas les clés. Les techniciens d’imagerie n’avaient pas les clés. L’hypothèse « les clés sont dans l’annuaire » s’est avérée partiellement vraie : les anciens appareils avaient les clés dans l’AD on‑prem ; les plus récents devaient séquestrer dans le cloud.

Le problème était le timing. Certains appareils ne s’étaient jamais correctement enregistrés après l’enrôlement. La politique rapportait « chiffrement activé », mais l’escrow n’avait jamais été finalisé. La séquence de réinstallation a modifié les mesures de démarrage et le TPM a refusé de déverrouiller. Invite de récupération. Aucune clé. Impasse.

L’incident n’était pas la mise à jour du firmware en soi. C’était l’hypothèse que l’escrow est un booléen. Ce n’est pas le cas. L’escrow est un processus : identité de l’appareil, connectivité réseau, santé de l’enrôlement et permissions. Vous le vérifiez comme vous vérifiez des sauvegardes : en testant, pas en croyant.

Ils ont fini par stabiliser en changeant la séquence : étape de vérification d’escrow d’abord, suspension de BitLocker avant le firmware, et arrêt strict si les clés n’étaient pas confirmées. Le déploiement a ralenti. Les incidents ont cessé. Tout le monde a prétendu que c’était toujours le plan.

Micro-récit 2 : L’optimisation qui a échoué

Une organisation globale voulait accélérer les retours de reconditionnement. Quelqu’un a proposé : « Ne déchiffrez pas. Effacez juste les partitions et réinstallez. Le chiffrement protège les anciennes données de toute façon. » Sur le papier, ce n’est pas absurde. En pratique, cela a créé un goulet de support.

La ligne de reconditionnement utilisait Windows Setup pour supprimer les partitions et installer à neuf. Ça fonctionnait la plupart du temps. Mais un sous‑ensemble d’appareils avait des paramètres BIOS spécifiques au fournisseur, certains avaient des firmwares plus anciens, et certains disques étaient précédemment protégés par des protecteurs supplémentaires (PIN, clé de démarrage). Quand ces appareils redémarraient pendant le processus, ils arrivaient en mode récupération et interrompaient les installations non surveillées.

L’équipe a « optimisé » encore en supprimant des étapes interactives du workflow. Personne n’était présent pour taper des clés de récupération si nécessaire. Les appareils sont restés sur des invites de récupération pendant la nuit, accumulant du temps et du travail à refaire.

Le vrai problème n’était pas que l’effacement soit mauvais. C’était que le flux de travail dépendait d’une automatisation ininterrompue alors que l’environnement avait des configurations de protecteurs non uniformes. Une seule invite casse une chaîne de production.

Ils ont corrigé en standardisant : suspendre/désactiver avant tout processus avec beaucoup de redémarrages, appliquer un jeu de protecteurs de base, et ajouter une vérification préliminaire qui refuse de démarrer si elle ne peut pas confirmer les clés. L’« optimisation » n’a été efficace qu’après avoir réalisé les tâches d’hygiène rébarbatives en premier.

Micro-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise régulée (beaucoup d’audits, beaucoup de paperasse, beaucoup de « fournissez la preuve svp ») avait une règle simple : avant toute ré-imagerie, les techniciens doivent capturer une capture d’écran de l’état BitLocker et confirmer l’emplacement d’escrow de la clé de récupération dans le ticket.

Cela paraissait excessif — jusqu’à ce qu’un lot d’ordinateurs portables subisse un changement de politique Secure Boot après une mise à jour firmware. Une poignée de systèmes sont allés en récupération au premier redémarrage, en plein milieu d’une fenêtre de déploiement serrée.

Le support n’a pas paniqué. Ils ont consulté les tickets. Chaque appareil avait la référence de la clé de récupération et la preuve qu’elle avait été séquestrée. Ils ont fourni les clés au personnel sur site, démarré, suspendu, puis repris la protection pour rattacher aux nouvelles mesures. Les temps d’indisponibilité sont restés mesurés en minutes, pas en jours.

La pratique n’a pas empêché le déclencheur. Elle a empêché l’incident de devenir une panne. Voilà à quoi ressemble la bonne opération : on ne peut pas éviter toutes les défaillances, mais on peut les rendre peu coûteuses.

Erreurs courantes : symptôme → cause → correction

Cette section est volontairement spécifique. Si vous voyez ces symptômes, ne « tentez rien ». Appliquez la correction.

1) Symptom : invite de récupération BitLocker immédiatement après la réinstallation

Cause : Les mesures de la chaîne de démarrage ont changé (nouveau chargeur/BCD, état Secure Boot modifié), le TPM ne peut plus désceller.

Correction : Saisissez la clé de récupération, démarrez, puis exécutez manage-bde -protectors -disable C: suivi de manage-bde -protectors -enable C: pour re‑sceller. Vérifiez aussi que Secure Boot et les paramètres du firmware sont stables.

2) Symptom : vous ne trouvez la clé de récupération nulle part

Cause : L’escrow n’a jamais eu lieu, ou il a été effectué sur une identité différente (mauvais tenant/objet appareil), ou une politique a empêché la sauvegarde.

Correction : Si les données sont importantes, stoppez et escaladez. Si les données ne sont pas importantes, effacez et réinstallez. Tourner en rond ne fera pas apparaître les clés par magie.

3) Symptom : « Suspended » mais il demande toujours la clé de récupération

Cause : Vous avez suspendu le mauvais volume, ou vous avez suspendu puis fait un changement qui a quand même forcé la récupération (TPM effacé, Secure Boot basculé, profil PCR modifié), ou plusieurs entrées OS ont embrouillé les mesures.

Correction : Revérifiez avec manage-bde -status et la liste des protecteurs. Confirmez que vous avez bien suspendu C: (volume OS). Évitez d’effacer le TPM sauf si vous avez les clés et l’intention.

4) Symptom : la réinstallation se termine, mais BitLocker est désactivé ensuite

Cause : La politique n’a pas encore été appliquée, l’enrôlement MDM est incomplet, ou la séquence de tâches a désactivé la protection et ne l’a jamais réactivée.

Correction : Vérifiez le statut de protection avec manage-bde -status. Réactivez. Corrigez le flux d’enrôlement/politique pour que le chiffrement soit appliqué avant que l’appareil ne quitte l’IT.

5) Symptom : Réinitialiser ce PC échoue ou boucle en récupération

Cause : WinRE mal configuré/désactivé, partition de récupération endommagée, ou interaction BitLocker/WinRE rompue à cause de modifications de partitions.

Correction : Vérifiez reagentc /info. Réactivez ou réparez WinRE. Si l’environnement est trop chaotique, faites une installation propre après avoir suspendu ou en effaçant.

6) Symptom : disque cloné, le périphérique cible demande la clé de récupération indéfiniment

Cause : Le protecteur TPM est lié au TPM du dispositif original. Le disque cloné ne peut pas désceller sur le nouveau matériel.

Correction : Utilisez la clé de récupération pour démarrer (si disponible), puis supprimez et réajoutez le protecteur TPM sur la cible. Ou déchiffrez avant de cloner. Mieux : ne clonez pas de disques OS chiffrés entre appareils sans plan.

7) Symptom : après mise à jour du BIOS, des invites de récupération soudaines sur certains modèles

Cause : La mise à jour firmware a modifié les mesures PCR ; la protection BitLocker n’a pas été suspendue avant la mise à jour, ou le profil PCR varie selon le modèle/firmware.

Correction : À l’avenir : suspendez avant les mises à jour firmware. Pour l’instant : utilisez les clés de récupération, démarrez, puis désactivez/réactivez les protecteurs pour re‑sceller sur le nouvel état PCR.

8) Symptom : « On a effacé les partitions, mais l’installateur voit encore des volumes verrouillés étranges »

Cause : Vous n’effacez pas le disque que vous pensez, ou vous êtes dans un environnement pré‑boot montrant des métadonnées obsolètes, ou le disque a plusieurs contrôleurs (mode VMD/RAID) masquant le vrai périphérique.

Correction : Identifiez le disque par modèle/numéro de série (Tâche 13). Confirmez le mode de stockage dans le BIOS (AHCI vs RAID/VMD). Puis effacez correctement.

Blague n°2

Supprimer des partitions sans vérifier le numéro de disque est un excellent exercice pour travailler votre voix d’excuse.

Listes de vérification / plan étape par étape

Checklist A : Réinstallation sûre sur la même machine (conserver les données si possible)

Confirmer l’état de BitLocker : exécutez manage-bde -status. Si Protection On, continuez.
Confirmer les protecteurs et l’existence d’un mot de passe de récupération : manage-bde -protectors -get C:. Ajoutez un mot de passe de récupération si absent.
Vérifier le processus d’escrow de la clé de récupération dans le système de votre organisation (preuve dans le ticket). Ne continuez pas tant que ce n’est pas confirmé.
Suspendre la protection : manage-bde -protectors -disable C:.
Noter les réglages firmware (UEFI/Legacy, Secure Boot). Ne les changez pas sauf si nécessaire.
Poursuivre la réinstallation (sur place ou clean‑install selon le besoin).
Après le premier démarrage réussi, réactivez les protecteurs : manage-bde -protectors -enable C:.
Valider la conformité : manage-bde -status doit afficher Protection On, Fully Encrypted (ou chiffrement en cours si nouvellement activé).

Checklist B : Effacement propre + réinstallation (données non nécessaires)

Décidez si l’appareil reste interne ou est mis au rebut. La destruction peut nécessiter une méthode d’assainissement différente que « DiskPart clean ».
Démarrez depuis un média d’installation connu (USB, PXE, etc.).
Identifiez les disques : DiskPart list disk, puis PowerShell Get-Disk pour confirmer modèle/taille.
Effacez intentionnellement : DiskPart select disk X puis clean.
Installez sur l’espace non alloué, laissez Setup créer les partitions EFI/MSR/Récupération.
Après le démarrage OS, assurez‑vous que BitLocker est activé selon la politique et que les clés de récupération sont séquestrées.

Checklist C : Mise à jour firmware/BIOS sur des appareils protégés par BitLocker (le plan « ne m’appelez pas après »)

Confirmez manage-bde -status et les protecteurs.
Suspendre : manage-bde -protectors -disable C:.
Appliquer la mise à jour firmware.
Démarrer correctement dans Windows.
Réactiver : manage-bde -protectors -enable C:.
Confirmer qu’il n’y a pas d’invite de récupération au redémarrage suivant. Si c’est le cas, vous avez un problème de stabilité des mesures à investiguer.

FAQ

1) Dois‑je vraiment désactiver BitLocker avant de réinstaller Windows ?

Si vous modifiez la chaîne de démarrage (et une réinstallation le fait), vous devriez au minimum suspendre la protection. « Devoir » est un jeu de probabilités ; « devoir le faire » est une mesure de prévention d’indisponibilité.

2) Quelle est la différence entre « Suspendre la protection » et « Désactiver BitLocker » ?

Suspendre garde les données chiffrées et désactive temporairement les protecteurs de clé. Désactiver déchiffre complètement le volume. La suspension est la valeur par défaut pour les réinstallations sur le même matériel ; désactiver sert pour les changements matériels ou quand la politique exige des données en clair pour une raison donnée.

3) Si j’efface le disque, dois‑je encore me soucier de BitLocker ?

Vous devez vous soucier de deux choses : (1) vous assurer d’effacer le bon disque et de ne pas être bloqué par une invite de récupération pendant un workflow automatisé, et (2) respecter les exigences de mise au rebut/sanitisation. Pour une réinstallation, effacer les partitions contourne généralement BitLocker parce que le volume chiffré n’existe plus.

4) Pourquoi BitLocker demande‑t‑il la clé de récupération après une mise à jour du BIOS ?

Parce que les mesures du TPM ont changé. BitLocker interprète cela comme un événement potentiel de manipulation. Suspendez avant la mise à jour, puis réactivez après un démarrage réussi pour « apprendre » le nouvel état normal au TPM.

5) Puis‑je réinstaller Windows et conserver les mêmes clés BitLocker ?

Vous pouvez conserver le chiffrement, mais attendez‑vous à ce que les protecteurs soient re‑scellés. Pratiquement, traitez la réinstallation comme un événement du cycle de vie des protecteurs : vérifiez la clé de récupération, suspendez, réinstallez, réactivez.

6) Et si l’utilisateur n’a jamais sauvegardé la clé de récupération ?

Si la clé n’est pas séquestrée centralement et que l’utilisateur ne l’a pas sauvegardée, et que le TPM ne peut pas désceller, il est probable que les données soient irrécupérables. Ce n’est pas un bug Windows ; c’est la cryptographie qui fonctionne comme prévue. La décision devient « effacer et continuer » vs « déclencher une réponse incident perte de données ».

7) L’état de Secure Boot (activé/désactivé) a‑t‑il de l’importance ?

Oui. L’état de Secure Boot influence le démarrage mesuré. Le changer peut déclencher la récupération. Gardez‑le cohérent et suspendez BitLocker avant de le modifier.

8) Est‑il sûr de « nettoyer/clear le TPM » pour corriger les invites BitLocker ?

Uniquement si vous êtes certain d’avoir les clés de récupération et que vous comprenez l’impact. Effacer le TPM peut orpheliner des protecteurs scellés par TPM et transformer une gêne récupérable en perte de données irrécupérable.

9) Pourquoi un modèle d’ordinateur se comporte‑t‑il différemment d’un autre ?

Différentes versions de firmware, différentes implémentations TPM, profils PCR différents, modes de stockage différents (AHCI vs RAID/VMD). BitLocker interagit avec la plateforme, pas seulement l’OS.

10) Après réinstallation, BitLocker est activé mais les performances semblent pires. C’est normal ?

Sur les CPU modernes avec accélération matérielle et NVMe, la surcharge est généralement modeste. Si elle est significative, vérifiez que vous n’êtes pas en mode crypto logiciel uniquement, contrôlez les pilotes et confirmez que le mode du contrôleur de stockage n’a pas changé lors de la réinstallation.

Prochaines étapes réalisables dès aujourd’hui

Si vous gérez plus d’une poignée d’endpoints, traitez BitLocker comme une dépendance de production, pas comme une case de sécurité.

Ajoutez une étape de pré‑vol à chaque runbook de réinstallation/reimage : manage-bde -status + manage-bde -protectors -get C:.
Appliquez une vérification d’escrow des clés de récupération comme un point de contrôle. Si vous ne pouvez pas prouver qu’elle est séquestrée, vous jouez de la roulette.
Standardisez les réglages firmware (UEFI, Secure Boot, mode de stockage) et arrêtez de « basculer pour voir si ça aide ».
Rendez la suspension/reprise une routine autour des changements perturbateurs : mises à jour BIOS, travaux sur les partitions, réparations du chargeur de démarrage.
Exercez‑vous à l’échec : prenez un portable de test, déclenchez une récupération volontairement et prouvez que votre organisation peut récupérer les clés rapidement. C’est probablement le gain le plus facile en ingénierie de fiabilité.

L’idée n’est pas d’avoir peur de BitLocker. C’est de respecter qu’il fait exactement ce que vous lui avez demandé : bloquer l’accès quand la plateforme paraît différente. Si vous planifiez la réinstallation comme un opérateur, BitLocker redeviendra un bruit de fond — là où il doit être.