Écran BitLocker après une mise à jour Windows :
le bug d’avril 2026 a été corrigé en mai.
Qui était concerné, comment débloquer un poste, et où retrouver sa clé de récupération.
Le plus déroutant dans cet incident est que rien n’était cassé. Le chiffrement a fonctionné exactement comme prévu : il a détecté une modification du chemin de démarrage et a demandé une vérification. Le problème venait de ce que la modification était légitime.
Ce qui s’est passé, et ce qui a suivi
Le 14 avril 2026, Microsoft a diffusé ses mises à jour de sécurité mensuelles. Quelques heures plus tard, des signalements remontaient : certaines machines affichaient l’écran de récupération du chiffrement au lieu de la session habituelle, et réclamaient une clé de quarante-huit chiffres.
Les références concernées étaient KB5083769 pour Windows 11 dans ses versions 24H2 et 25H2, KB5082052 pour certaines éditions professionnelles, ainsi que les correctifs équivalents pour Windows 10 et les versions serveur.
Microsoft a confirmé le problème dans sa documentation officielle et en a rapidement circonscrit le périmètre. La demande de clé n’intervenait qu’une seule fois, au premier redémarrage suivant l’installation.
Le 15 mai 2026, l’éditeur a confirmé la publication d’un correctif définitif. Un poste à jour n’est donc plus exposé à ce comportement. C’est l’information essentielle pour quiconque lit ces lignes aujourd’hui.
Un point mérite d’être distingué. Au-delà du problème de chiffrement confirmé par l’éditeur, des utilisateurs ont signalé d’autres dysfonctionnements après cette même mise à jour : boucles de démarrage, affichages dégradés, écrans d’erreur bloquants. Ces signalements n’ont pas fait l’objet de la même reconnaissance officielle et relèvent d’un dossier distinct.
Une précision s’impose sur le calendrier, car elle explique l’émoi suscité. Ces correctifs mensuels ne sont pas des versions de test réservées à quelques volontaires : ils constituent la mise à jour de sécurité principale, installée automatiquement sur la grande majorité des postes. Un dysfonctionnement à ce niveau atteint donc directement le chemin de déploiement standard, sans période d’observation préalable pour l’utilisateur ordinaire. C’est ce qui distingue un incident de ce type d’un problème détecté sur une version anticipée.
Pourquoi le chiffrement réagit ainsi
Comprendre le mécanisme évite de céder à la panique, et surtout de prendre une mauvaise décision.
Le chiffrement de disque intégré à Windows ne protège pas seulement contre la lecture d’un disque volé. Il vérifie aussi que le processus de démarrage n’a pas été altéré. La puce de sécurité de la carte mère enregistre des mesures de chaque étape du démarrage, et ne libère la clé de déchiffrement que si ces mesures correspondent à ce qui était attendu.
La mise à jour d’avril modifiait des éléments liés au démarrage sécurisé, dans le cadre d’une transition vers de nouveaux certificats. Sur certaines configurations, cette modification changeait les mesures enregistrées. Le système constatait alors un écart et exigeait une vérification humaine.
Techniquement, le comportement était conforme à la conception. Ce n’était pas une défaillance du chiffrement mais un décalage entre une chaîne de confiance mise à jour et une politique de validation restée figée.
Un point de vocabulaire aide à comprendre. Les registres appelés PCR sont des emplacements de la puce de sécurité où sont consignées les empreintes des étapes successives du démarrage. Celui qui porte le numéro sept concerne spécifiquement l’état du démarrage sécurisé et les certificats associés. Inclure ce registre dans une politique de validation revient à exiger que rien ne bouge de ce côté, ce qui est un choix de sécurité défendable tant que les certificats ne changent pas. La transition vers de nouveaux certificats, engagée par l’éditeur pour des raisons de sécurité, entrait donc mécaniquement en collision avec ce réglage.
Les cinq conditions cumulatives
Le déclenchement supposait la réunion simultanée de cinq critères. L’absence d’un seul suffisait à écarter le risque.
- Le chiffrement activé sur le disque système.
- Une stratégie de groupe spécifique configurant le profil de validation de la plateforme pour les micrologiciels modernes, avec le registre PCR7 explicitement inclus dans ce profil.
- Un état de liaison PCR7 signalé comme impossible par l’outil d’informations système.
- La présence du certificat de 2023 dans la base de signatures du démarrage sécurisé.
- Un gestionnaire de démarrage antérieur, la machine n’étant pas encore passée à la version signée en 2023.
Cette combinaison décrit un environnement administré de façon centralisée, avec des stratégies de sécurité poussées, engagé dans une transition de certificats mais pas encore achevée.
La conséquence pratique est nette : un ordinateur personnel configuré avec les réglages par défaut n’était pratiquement jamais concerné. Les stratégies de groupe évoquées ne s’appliquent pas sur une machine familiale.
Le paradoxe est cruel pour les organisations. Ce sont précisément les parcs les mieux tenus, ceux qui appliquent des politiques de validation strictes, qui étaient exposés. Le soin apporté à la configuration devenait le facteur déclenchant.
L’impact opérationnel dépassait donc largement le nombre de machines touchées : quelques dizaines de postes bloqués un lundi matin dans une même organisation suffisent à saturer un service d’assistance.
Vérifier son poste en trente secondes
La vérification reste utile même après correction, car elle renseigne sur l’état de configuration d’une machine.
Ouvrez l’outil d’informations système, accessible en tapant son nom dans la recherche Windows ou en saisissant msinfo32 dans la boîte d’exécution. Il faut le lancer en tant qu’administrateur pour afficher l’ensemble des lignes.
Cherchez la ligne relative à l’état de liaison PCR7 du démarrage sécurisé. Trois réponses sont possibles, et chacune se lit différemment.
- Liaison possible ou liée : aucune exposition à ce problème.
- Impossible : la machine remplissait l’une des conditions, à croiser avec les quatre autres.
- Chiffrement désactivé : la question ne se pose pas, mais elle en soulève une autre sur la protection des données.
Débloquer un poste verrouillé
La marche à suivre
Saisir la clé de récupération à quarante-huit chiffres sur l’écran affiché. Windows démarre alors normalement, et les redémarrages suivants ne réclament plus rien, à condition que la stratégie de groupe reste inchangée.
Un identifiant de clé apparaît à l’écran. Il permet de retrouver la bonne clé lorsque plusieurs sont enregistrées, ce qui arrive fréquemment sur les machines réinstallées.
Ce qu’il ne faut pas faire
Ne réinitialisez pas la machine, ne reformatez pas le disque, ne modifiez pas les réglages du micrologiciel. Aucune de ces actions ne débloque l’accès, et toutes peuvent rendre la récupération définitivement impossible.
Ne désactivez pas non plus le chiffrement par réaction. Un disque non protégé s’ouvre sans aucune manipulation particulière sur une autre machine, ce qui remplace un désagrément passager par une exposition permanente.
Une précision utile pour les postes professionnels : dans une organisation, la clé est presque toujours déposée automatiquement auprès du service informatique lors de l’activation du chiffrement. Un appel au support règle la situation plus vite qu’une recherche individuelle, et évite les fausses manipulations.
Retrouver sa clé de récupération
Pour un poste personnel
La clé est le plus souvent associée au compte Microsoft utilisé lors de la configuration de la machine. Elle se consulte depuis un autre appareil, dans la section du compte consacrée aux appareils et aux clés de récupération.
Deux autres emplacements existent selon les choix faits à l’activation : une clé enregistrée sur un support amovible, ou une version imprimée. Ces options sont proposées au moment de l’activation du chiffrement.
Pour un poste professionnel
La clé est généralement stockée dans l’annuaire d’entreprise, consultable par les administrateurs depuis leur console de gestion. Le service informatique reste l’interlocuteur à contacter en premier.
Certaines organisations utilisent également des solutions de gestion de parc qui centralisent ces clés. Le principe reste identique : elles ne sont pas perdues, simplement stockées ailleurs que sur la machine bloquée.
Le cas problématique existe, et il vaut mieux le connaître avant qu’il ne survienne : une machine dont le chiffrement a été activé sans compte associé, sans sauvegarde et sans impression. Dans cette configuration, aucune récupération n’est possible et les données sont définitivement inaccessibles. C’est la raison pour laquelle la vérification préalable de l’existence d’une clé accessible mérite d’être faite une fois pour toutes.
Ce que doivent faire les administrateurs
Le correctif règle ce cas précis, mais la méthode appliquée pendant l’incident garde toute sa valeur pour les prochains.
Auditer les stratégies avant déploiement. Vérifier l’état de liaison PCR7 sur un échantillon représentatif du parc, et repérer les politiques de validation qui incluent explicitement ce registre.
Déployer par vagues. Un premier groupe restreint et représentatif, puis une montée en charge progressive. Cette pratique élémentaire aurait limité l’essentiel des difficultés rencontrées en avril.
Vérifier la centralisation des clés. S’assurer que chaque poste chiffré a bien déposé sa clé dans l’annuaire, ce qui n’est pas toujours le cas sur les machines les plus anciennes ou intégrées hors procédure.
L’éditeur avait par ailleurs proposé un mécanisme de retour en arrière ciblé, accessible via le support entreprise, pour les organisations dans l’impossibilité de modifier leurs stratégies avant déploiement.
Cette gestion rejoint les préoccupations plus larges autour du chiffrement en entreprise, notamment les questions d’accès que nous avons traitées dans notre article sur les capacités d’accès distant à un poste chiffré.
Ce que cet incident révèle
Trois enseignements dépassent le cas particulier, et ils valent pour toute organisation qui gère un parc informatique.
La maintenance ne se limite plus à corriger des vulnérabilités. Elle consiste désormais à gérer l’interaction entre des chaînes de confiance micrologicielles, l’état du démarrage sécurisé, les mesures de la puce de sécurité et les politiques de gestion des appareils. Chacune évolue à son propre rythme.
La flexibilité de Windows a un coût. Un système conçu pour s’adapter à d’innombrables configurations matérielles, images anciennes, outils de gestion tiers et réglages personnalisés multiplie les combinaisons possibles. C’est son avantage concurrentiel et sa fragilité récurrente.
Les réglages explicites vieillissent mal. Une politique définie il y a plusieurs années pour renforcer la sécurité peut entrer en conflit avec des hypothèses plus récentes. Réexaminer périodiquement les configurations héritées fait partie du travail.
Ce type d’incident n’est pas propre à un éditeur, comme le rappelle notre article sur un dysfonctionnement comparable observé sur un autre système, et il arrive que les corrections rétablissent la situation, comme dans le cas du premier problème notable de 2026. Une vigilance particulière s’impose toutefois : les écrans d’erreur inattendus sont exploités par des attaquants, comme le montre notre analyse des faux écrans système invitant à exécuter des commandes. Un écran de récupération authentique ne demande jamais autre chose qu’une clé. Pour le reste, nos conseils sur l’optimisation des performances d’un poste et sur les réglages de sécurité des appareils mobiles restent disponibles, de même que nos retours clients et notre page contact.
Écran BitLocker après mise à jour : les réponses essentielles.
Le problème est-il résolu ?
Oui. Après la confirmation du dysfonctionnement en avril 2026, Microsoft a publié un correctif définitif, confirmé le 15 mai 2026. Un poste à jour n’est plus exposé à ce comportement.
Étais-je concerné ?
Très probablement pas, s’il s’agit d’un ordinateur personnel. Cinq conditions devaient être réunies simultanément, dont une stratégie de groupe spécifique qui ne s’applique pas sur une machine familiale configurée avec les réglages par défaut.
Pourquoi le chiffrement demandait-il cette clé ?
La mise à jour modifiait des éléments du démarrage sécurisé. Sur certaines configurations, ce changement altérait les mesures enregistrées par la puce de sécurité, et le système exigeait une vérification. Le comportement était conforme à la conception, pas défaillant.
La clé était-elle demandée à chaque démarrage ?
Non, une seule fois, au premier redémarrage suivant l’installation. Les démarrages ultérieurs se déroulaient normalement, à condition que la stratégie de groupe reste inchangée.
Comment vérifier la configuration d’un poste ?
En ouvrant l’outil d’informations système, accessible en saisissant msinfo32, de préférence en tant qu’administrateur, puis en consultant la ligne relative à l’état de liaison PCR7 du démarrage sécurisé.
Où retrouver ma clé de récupération ?
Sur un poste personnel, dans la section du compte Microsoft consacrée aux appareils, consultable depuis un autre appareil. Sur un poste professionnel, auprès du service informatique, qui la conserve généralement dans l’annuaire d’entreprise.
Que faire sans clé de récupération ?
Si le chiffrement a été activé sans compte associé, sans sauvegarde et sans impression, aucune récupération n’est possible et les données restent inaccessibles. C’est la raison pour laquelle il vaut mieux vérifier l’existence d’une clé accessible avant tout incident.
Faut-il retarder les mises à jour ?
Non. Repousser indéfiniment les correctifs revient à conserver des vulnérabilités connues, ce qui expose davantage qu’un blocage temporaire. La bonne pratique en entreprise est le déploiement par vagues, sur un groupe restreint d’abord.
- Microsoft — Tableau de bord de l’état des versions et problèmes connus
- Microsoft Learn — Récupération BitLocker et emplacements de sauvegarde des clés
- Suivi de l’incident et confirmation de la correction en mai 2026
- Détail des conditions de déclenchement et recommandations aux administrateurs
- Périmètre des configurations affectées et nature du comportement observé
WY-Créations suit l’actualité du numérique et de la sécurité informatique. Les manipulations décrites concernent des environnements administrés ; en cas de doute sur un poste professionnel, le service informatique reste l’interlocuteur à solliciter avant toute intervention. Pour aller plus loin : toutes les actualités web.
Une sauvegarde qu’on n’a jamais vérifiée n’est pas une sauvegarde.
WY-Créations accompagne les entreprises sur leurs sites, leurs outils et leurs usages numériques depuis 2018.