Windows 11 : la mise à jour KB5074109
empêche certains PC de redémarrer.
La machine s’éteint pour appliquer la mise à jour, comme des centaines de fois auparavant. Elle ne se rallume pas. À la place, un écran annonçant que le volume de démarrage ne peut pas être monté, et un système qui bascule en mode récupération. Aucun avertissement, aucun signe avant-coureur.
La mise à jour du 13 janvier
Le deuxième mardi de chaque mois, Microsoft publie ses correctifs de sécurité. Celui de janvier 2026 portait la référence KB5074109 et n’avait rien d’anodin : plus de cent dix vulnérabilités corrigées d’un coup.
C’est le paradoxe de ce dossier. La mise à jour incriminée n’était pas une nouveauté fonctionnelle dont on aurait pu se passer, mais un lot de correctifs de sécurité que chaque administrateur avait de bonnes raisons d’appliquer sans tarder. Attendre exposait aux failles ; installer exposait au blocage.
Le rythme mensuel n’est pas neutre dans cette affaire. En concentrant ses correctifs sur une date unique et connue de tous, l’éditeur facilite l’organisation des équipes techniques, mais il crée aussi une synchronisation mondiale : des centaines de millions de machines appliquent le même paquet dans la même fenêtre de quelques jours. Quand un défaut passe au travers des tests, il ne touche pas quelques utilisateurs isolés au fil des semaines, il se manifeste partout en même temps. C’est ce qui donne à ces incidents leur caractère spectaculaire, même lorsque la proportion de machines touchées reste faible.
Les premiers signalements sont remontés dans les jours qui ont suivi, d’abord sur des forums spécialisés, puis suffisamment pour que Microsoft publie une reconnaissance officielle. La formule employée mérite d’être citée telle quelle : l’entreprise dit avoir reçu un nombre limité de signalements indiquant que certains appareils ne parviennent plus à démarrer après installation de la mise à jour de sécurité de janvier 2026 et des mises à jour ultérieures.
Deux mots comptent dans cette phrase. « Limité », qui relativise l’ampleur sans la chiffrer. Et « ultérieures », qui signale que le problème ne disparaissait pas avec les correctifs suivants.
Le symptôme exact
Beaucoup de descriptions approximatives ont circulé. Le tableau documenté par Microsoft et par les retours de terrain est plus précis, et plus grave.
- Un écran noir apparaît, indiquant que l’appareil a rencontré un problème et doit redémarrer.
- Un écran bleu affiche le message UNMOUNTABLE_BOOT_VOLUME, accompagné du code d’arrêt 0xED.
- Le démarrage s’arrête là. La machine ne dépasse pas cette étape et bascule vers l’environnement de récupération.
- Une intervention manuelle devient nécessaire : le système ne se répare pas seul, même après plusieurs redémarrages.
- Un second symptôme a été rapporté par des utilisateurs après la même vague : un écran bleu mentionnant le fichier acpi.sys avec le code 0xc000000f.
Une précision rassurante mérite d’accompagner ce constat. Que le volume ne puisse pas être monté ne signifie pas que son contenu a disparu. Le système échoue à établir l’accès au disque pendant la séquence de démarrage, à un moment très précoce où presque rien n’est encore chargé. Les fichiers, eux, restent en place et se lisent parfaitement depuis un autre système. La panique provoquée par le message pousse pourtant beaucoup d’utilisateurs vers une réinstallation immédiate, qui détruit ce que le défaut avait laissé intact.
Le message d’erreur principal désigne une situation précise : le système ne parvient plus à monter le volume sur lequel il est installé. Ce n’est pas un pilote périphérique qui plante ni une application qui se ferme, c’est l’accès au disque de démarrage lui-même qui échoue. D’où l’impossibilité de contourner le problème par un simple redémarrage ou un mode sans échec classique.
À ne pas confondre avec les faux écrans bleus utilisés dans certaines attaques, qui imitent cet affichage pour pousser la victime à appeler un faux support. Nous décrivions ce procédé dans notre article sur l’exploitation du faux écran bleu de la mort.
Qui est concerné, et qui ne l’est pas
Le périmètre communiqué est étroit sur certains points, muet sur d’autres. Cette asymétrie a nourri beaucoup d’inquiétude inutile, et empêché beaucoup d’anticipation utile.
Ce qui est établi : le problème concerne Windows 11 dans ses versions 24H2 et 25H2, après installation de la mise à jour de janvier. Il ne touche que des machines physiques, les machines virtuelles étant explicitement écartées. Les postes restés sur une branche antérieure ne sont pas visés.
Ce qui ne l’est pas : tout le reste. Aucune indication sur le fabricant, le modèle, le type de disque, la présence de tel ou tel logiciel, la configuration du chiffrement ou l’ancienneté du microprogramme. Impossible, donc, de dresser une liste des machines à risque et de les traiter en priorité.
Cette absence est la véritable difficulté opérationnelle. Un administrateur confronté à un défaut identifié peut isoler les postes concernés et laisser les autres se mettre à jour. Face à un défaut dont le déclencheur reste inconnu, il n’a que deux options, toutes deux mauvaises : suspendre le déploiement sur l’ensemble du parc et laisser cent dix failles ouvertes, ou continuer en acceptant que des postes tombent au hasard.
Ce que Microsoft n’a pas dit
Aucune explication technique n’a été rendue publique sur l’origine du défaut. Les hypothèses qui ont circulé relèvent de la déduction, et méritent d’être présentées comme telles.
Le message d’erreur oriente vers la couche d’accès au stockage : pilote de contrôleur, gestion du chiffrement de volume, initialisation du disque au démarrage. Le second symptôme rapporté, impliquant le composant de gestion de l’alimentation et de la configuration matérielle, pointe dans une direction voisine, celle de l’initialisation très précoce du système.
Ces éléments suggèrent une interaction entre la mise à jour et une couche basse propre à certaines configurations, sans permettre de la nommer. Il faut résister à la tentation de combler ce vide. Attribuer l’incident à un conflit avec des pilotes tiers, ou à tel logiciel de sécurité, revient à inventer une cause qu’aucune publication n’étaye.
Ce silence n’a rien d’exceptionnel. Un éditeur communique rarement sur la cause exacte d’un défaut avant d’en avoir terminé l’analyse, et parfois jamais. La conséquence pour l’utilisateur est que l’absence d’explication ne signifie ni dissimulation ni incompétence, mais qu’elle le prive de tout moyen d’évaluer son propre risque. La dépendance à un fournisseur unique se mesure précisément dans ces moments-là, comme lors de l’épisode du certificat expiré ayant rendu des périphériques inutilisables.
Une correction plus lente qu’annoncée
Le récit d’une résolution en quelques heures a circulé. La chronologie réelle s’étale sur plusieurs semaines.
- 13 janvier 2026 : publication de la mise à jour de sécurité mensuelle.
- Jours suivants : accumulation des signalements sur les forums d’assistance et les réseaux sociaux.
- Mi-janvier : reconnaissance publique du problème par l’éditeur, sans correctif dédié ni explication technique.
- 22 janvier : déploiement d’une mise à jour corrective visant les dysfonctionnements de celle de janvier.
- 26 janvier : des publications spécialisées relèvent qu’aucun correctif dédié à ce problème précis n’a encore été publié, et recommandent toujours la désinstallation ou le recours à l’environnement de récupération.
- 2 février : publication de la mise à jour cumulative suivante, apportant une trentaine de nouveautés et de corrections.
Plus de neuf jours séparent donc la publication de la mise à jour de la première réponse corrective, et le doute a persisté au-delà. Pour un poste bloqué, cette durée n’a rien de théorique : c’est une machine hors service pendant une semaine et demie, ou une réparation manuelle à mener sans garantie.
La recommandation la plus reprise pendant cette période était de suspendre le déploiement sur les machines physiques jusqu’à stabilisation, ce qui revient à repousser un lot de correctifs de sécurité substantiel.
Récupérer une machine bloquée
La marche à suivre est connue, mais elle comporte un préalable que beaucoup découvrent au pire moment.
Le principe consiste à passer par l’environnement de récupération, accessible depuis les options de démarrage avancées ou depuis un support d’installation externe, puis à désinstaller la dernière mise à jour de qualité. La machine redémarre alors dans son état antérieur, privée des correctifs de sécurité mais fonctionnelle.
Encore faut-il y accéder. Sur une machine qui refuse de démarrer, Windows bascule normalement de lui-même vers cet environnement après plusieurs échecs consécutifs. Quand ce n’est pas le cas, il reste le support externe : une clé USB d’installation permet de démarrer dessus et d’atteindre les mêmes options de réparation. Créer cette clé demande un ordinateur en état de marche, ce qui explique pourquoi elle se prépare avant l’incident et non pendant.
Le préalable, c’est le chiffrement du disque. Sur un poste dont le volume est chiffré, l’environnement de récupération réclame la clé avant toute intervention. Sans elle, la procédure s’arrête net et les données restent inaccessibles. Cette clé est normalement sauvegardée dans le compte associé à la machine ou dans l’annuaire de l’entreprise, mais encore faut-il savoir où la chercher et disposer d’un second appareil pour y accéder. Nous détaillions ce mécanisme dans notre article sur le chiffrement BitLocker et la gestion des clés de récupération.
Deux réflexes valent d’être rappelés. Ne pas forcer l’extinction à répétition : au bout de plusieurs échecs consécutifs, Windows déclenche des procédures de réparation automatiques qui peuvent aggraver une situation déjà instable. Et récupérer la clé de chiffrement avant d’engager quoi que ce soit, depuis un autre poste ou un téléphone, plutôt que de découvrir son absence une fois la machine dans l’écran de récupération.
Ce qu’une entreprise doit en tirer
Une TPE ne dispose pas d’un service informatique, mais la plupart des mesures utiles ici ne demandent ni budget ni compétence particulière.
- Décaler les mises à jour de qualité de quelques jours sur les postes critiques, sans jamais les désactiver. Windows permet ce report dans ses paramètres, et une semaine suffit à voir remonter les incidents majeurs.
- Ne pas mettre à jour tous les postes le même jour. Traiter une machine d’abord, observer, puis étendre. C’est l’équivalent artisanal du déploiement progressif.
- Sauvegarder les clés de chiffrement ailleurs que sur la machine chiffrée, et vérifier qu’elles sont accessibles depuis un autre appareil.
- Disposer d’une clé USB d’installation prête, créée avant l’incident. La fabriquer suppose un ordinateur qui fonctionne, ce dont on manque précisément le jour où on en a besoin.
- Sauvegarder les données de travail sur un support distinct du poste. Un système qui ne démarre plus n’efface rien, mais il retarde l’accès de plusieurs jours.
- Conserver un poste de secours, même modeste, capable de faire tourner l’essentiel pendant une immobilisation.
Un dernier point sur l’arbitrage de fond. Repousser indéfiniment les mises à jour de sécurité pour éviter ce genre d’incident revient à laisser ouvertes des failles activement exploitées, ce qui cause statistiquement bien plus de dégâts qu’un correctif défaillant. La bonne réponse n’est pas de ne plus mettre à jour, mais d’organiser le déploiement de manière à pouvoir revenir en arrière. Les mêmes principes valent d’ailleurs pour un site web, où le rythme d’adoption de Windows 11 continue par ailleurs de progresser, comme le montre notre article sur la progression du parc Windows 11 en 2026.
Les faux messages d’assistance technique prospèrent précisément après ce type d’incident médiatisé, en imitant les écrans d’erreur du système, procédé décrit dans notre article sur la technique ClickFix et ses faux écrans Windows.
Ce qu’on nous demande le plus souvent.
Quelle mise à jour est en cause ?
La mise à jour de sécurité KB5074109, publiée le 13 janvier 2026 pour Windows 11, qui corrigeait par ailleurs plus de cent dix vulnérabilités. Le problème a été signalé après son installation et persistait avec les mises à jour suivantes.
Quels sont les symptômes ?
Un écran noir indiquant que l’appareil doit redémarrer, puis un écran bleu affichant UNMOUNTABLE_BOOT_VOLUME avec le code 0xED. La machine bascule en mode récupération et ne démarre plus sans intervention manuelle.
Quelles machines sont concernées ?
Windows 11 dans ses versions 24H2 et 25H2, sur des machines physiques uniquement, les machines virtuelles étant écartées. Aucune précision n’a été publiée sur le fabricant, le modèle ou la configuration en cause.
Comment débloquer un PC touché ?
En passant par l’environnement de récupération pour désinstaller la dernière mise à jour de qualité. Sur un disque chiffré, la clé de récupération est demandée avant toute action : la récupérer depuis un autre appareil est la première étape.
Mes données sont-elles perdues ?
En principe non. Ce défaut empêche le montage du volume au démarrage, il ne détruit pas son contenu. Une réinstallation précipitée reste la principale cause de perte réelle dans ce type de situation.
Faut-il arrêter les mises à jour Windows ?
Non. Les failles laissées ouvertes causent statistiquement bien plus de dégâts qu’un correctif défaillant. Décaler de quelques jours sur les postes critiques et ne pas traiter tout le parc simultanément suffit à réduire l’exposition.
- Reconnaissance publiée par Microsoft en janvier 2026 relative aux appareils ne parvenant plus à démarrer après installation de la mise à jour de sécurité du 13 janvier 2026.
- Notes de publication de la mise à jour KB5074109 pour Windows 11, et périmètre des versions 24H2 et 25H2.
- Relevés de la presse spécialisée francophone entre le 13 et le 29 janvier 2026 sur les symptômes observés et les procédures de contournement.
- Publications relatives à la mise à jour corrective du 22 janvier 2026 et à la mise à jour cumulative suivante du 2 février 2026.
- Documentation Microsoft sur l’environnement de récupération Windows, la désinstallation des mises à jour de qualité et la gestion des clés de chiffrement de volume.
WY-Créations conçoit des sites internet et construit des stratégies de visibilité pour les artisans, les TPE, les PME et les professions libérales depuis 2018. Les éléments publiés par l’éditeur sont distingués des hypothèses formulées par la presse spécialisée. Pour aller plus loin : les avis clients ou nous écrire.
Savez-vous où se trouve la clé de chiffrement de votre poste ?
Le jour où l’écran de récupération la demande, il est trop tard pour la chercher sur la machine qui ne démarre plus. Cinq minutes de vérification aujourd’hui valent une semaine d’immobilisation évitée.