Dual Boot cassé ? Restaurer le chargeur de démarrage Windows en toute sécurité

Réparer le chargeur sans superstition : le modèle mental

Quand Windows « ne démarre pas » après un changement de dual-boot, vous avez généralement une des quatre couches qui a cassé :

Couche 1 : Points d’entrée du firmware (NVRAM UEFI ou BIOS)

Les machines UEFI stockent les entrées de démarrage dans la NVRAM : de petits pointeurs comme « Boot0003 → \EFI\Microsoft\Boot\bootmgfw.efi sur disque X partition Y ». Si ce pointeur est supprimé, renommé ou pointe vers le mauvais disque, Windows peut être parfaitement intact et pourtant inaccessible.

Les machines BIOS Legacy n’ont pas d’entrées NVRAM. Elles chargent le code de premier stade depuis le MBR du disque, qui trouve ensuite le secteur de démarrage de la partition active, qui trouve ensuite un chargeur. Autre époque, modes de panne différents, même panique.

Couche 2 : Disposition des disques (GPT vs MBR, et où se trouve l’EFI System Partition)

Sur les systèmes UEFI, l’EFI System Partition (ESP) est une petite partition FAT32 qui contient les chargeurs pour Windows, Linux, et tout autre système. L’ESP n’est pas optionnelle. Si elle manque, est corrompue, ou est montée et modifiée incorrectement, la machine devient un presse-papier très coûteux avec des LED.

Couche 3 : Les fichiers du chargeur (Windows Boot Manager)

Pour Windows sous UEFI, le fichier principal est typiquement \EFI\Microsoft\Boot\bootmgfw.efi. Sous BIOS/MBR, les « fichiers du chargeur » concernent davantage le code de démarrage du volume et \Boot\BCD sur la partition System Reserved (ou parfois C: si quelqu’un a « optimisé » les choses).

Couche 4 : Le magasin BCD (configuration de démarrage Windows)

BCD (Boot Configuration Data) est le menu de démarrage et les paramètres de Windows. Si BCD est cassé, vous pouvez atteindre le Windows Boot Manager mais échouer à la dernière étape vers l’OS.

Votre tâche est d’identifier quelle couche a cassé, la réparer, et vous arrêter. Ne réécrivez pas tout juste parce que vous avez des outils et des émotions.

Une citation utile : « L’espoir n’est pas une stratégie. » — idée paraphrasée, souvent utilisée en exploitation et fiabilité.

Une petite blague pour détendre : Les chargeurs de démarrage sont comme la signalisation d’aéroport — quand c’est faux, vous avez toujours un avion, mais vous n’allez nulle part.

Mode d’emploi pour diagnostic rapide (vérifier d’abord, ensuite, enfin)

Si vous voulez réparer ça rapidement, ne commencez pas par des incantations bootrec. Commencez par un triage en trois étapes qui réduit le problème en quelques minutes.

Premier : confirmer le mode du firmware et le disque sur lequel vous démarrez réellement

• Vérifiez si Windows a été installé en mode UEFI ou Legacy. Les installations en modes mixtes sont la raison n°1 pour laquelle les réparations « fonctionnent » mais ne démarrent jamais.
• Vérifiez l’ordre de démarrage du firmware. Une installation Linux peut ajouter une nouvelle entrée et repousser Windows dans la liste.
• Vérifiez quel disque physique contient l’ESP ou la partition System Reserved. Les configurations multi-disques en dual-boot sont l’endroit où les hypothèses innocentes vont mourir.

Second : vérifier que l’ESP / partition système existe et est lisible

• UEFI : trouvez l’ESP FAT32, montez-la et confirmez que \EFI\Microsoft\Boot existe.
• BIOS : trouvez la partition « System Reserved » NTFS active (ou équivalent) et confirmez qu’elle contient \Boot\BCD.

Troisième : ensuite seulement, réparez la plus petite couche cassée

• Entrée NVRAM manquante ? Recréez l’entrée (ou exécutez bcdboot qui le fait souvent).
• Fichiers de démarrage manquants ? Reconstruisez-les sur l’ESP via bcdboot.
• BCD cassé ? Reconstruisez le BCD (avec précaution) après avoir identifié l’installation Windows.
• Code MBR cassé ? Utilisez la voie MBR (bootrec, bootsect).

Ne passez pas directement à la chirurgie des partitions. La plupart des « Windows disparus » sont juste un problème de pointeur de démarrage.

Faits intéressants et contexte à répéter en réunion

1. UEFI a remplacé le BIOS progressivement durant les années 2010, et de nombreuses machines offrent encore une compatibilité « Legacy » qui provoque des installations en mode mixte par accident.
2. Les disques GPT n’utilisent pas le drapeau de partition « active » de la même manière que les disques MBR ; ce concept est un artefact de l’ère BIOS.
3. L’EFI System Partition est généralement FAT32 parce que le firmware peut la lire de façon fiable entre fabricants, bien avant le chargement de tout noyau OS.
4. Windows Boot Manager sous UEFI n’est qu’un fichier .efi ; ce n’est pas mystique — supprimez-le ou renommez-le et Windows devient « disparu ».
5. GRUB peut chaîner le démarrage de Windows, mais les mises à jour Windows réécrivent parfois l’ordre de démarrage pour préférer Windows Boot Manager, ce qui surprend les utilisateurs Linux.
6. BCD a remplacé boot.ini (utilisé dans les anciennes versions de Windows) pour supporter des scénarios de démarrage plus flexibles et les interactions avec le firmware moderne.
7. Beaucoup de systèmes OEM livrent plusieurs partitions de récupération ; supprimer des « petites partitions inconnues » pour « nettoyer » peut supprimer la seule copie des fichiers de démarrage critiques.
8. BitLocker modifie le profil de risque des réparations de démarrage : même des réparations correctes peuvent déclencher des demandes de clé de récupération si le chemin de démarrage change.
9. Sur les systèmes multi-disques, les installateurs choisissent souvent le premier ESP qu’ils voient (selon l’énumération du firmware), pas nécessairement le disque que vous aviez en tête pour chaque OS.

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

Ci-dessous des tâches réelles que vous pouvez exécuter depuis l’invite de commande de l’environnement de récupération Windows (WinRE) ou depuis un live USB Linux. Chaque tâche inclut : la commande, ce qu’une sortie typique signifie, et la décision suivante.

Tâche 1 : Dans WinRE, identifier les disques et partitions (indices UEFI vs BIOS)

cr0x@server:~$ diskpart
Microsoft DiskPart version 10.0.19041.1

DISKPART> list disk

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

DISKPART> list vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     D   WinRE        NTFS   Partition    980 MB  Healthy    Hidden
  Volume 1     S   SYSTEM       FAT32  Partition    100 MB  Healthy    System
  Volume 2     C   Windows      NTFS   Partition    475 GB  Healthy    Boot

Ce que cela signifie : Disk 0 est GPT (l’étoile dans la colonne « Gpt »). Le volume S : est FAT32 et marqué « System » — c’est votre ESP. Vous êtes en environnement UEFI.

Décision : Suivez la voie de réparation UEFI et concentrez-vous sur l’ESP + BCD/fichiers de démarrage. Ne lancez pas de commandes orientées MBR comme bootrec /fixmbr sauf si vous aimez la confusion.

Tâche 2 : Confirmer le chemin d’installation Windows et les lettres de lecteur dans WinRE

cr0x@server:~$ dir C:\Windows\System32
 Volume in drive C has no label.
 Volume Serial Number is 3A1B-19C2

 Directory of C:\Windows\System32

01/15/2026  10:21 AM    <DIR>          .
01/15/2026  10:21 AM    <DIR>          ..
...

Ce que cela signifie : Votre partition Windows est montée comme C: dans WinRE (ce qui n’est pas toujours vrai). Si dir échoue, votre partition Windows peut être D: ou E: dans WinRE.

Décision : Utilisez la lettre correcte dans les commandes suivantes. Les mauvaises lettres de lecteur sont la façon dont les gens « réparent » le mauvais OS puis blâment les rayons cosmiques.

Tâche 3 : Monter et inspecter l’ESP dans WinRE (vérification de base)

cr0x@server:~$ diskpart
DISKPART> sel vol S
Volume 1 is the selected volume.

DISKPART> assign letter=Z
DiskPart successfully assigned the drive letter or mount point.

DISKPART> exit

cr0x@server:~$ dir Z:\EFI
 Volume in drive Z is SYSTEM
 Volume Serial Number is 8C2A-4E1D

 Directory of Z:\EFI

01/15/2026  10:18 AM    <DIR>          .
01/15/2026  10:18 AM    <DIR>          ..
01/15/2026  10:19 AM    <DIR>          Microsoft
01/15/2026  10:19 AM    <DIR>          ubuntu

Ce que cela signifie : L’ESP existe, est lisible, et contient à la fois les répertoires Microsoft et ubuntu. C’est bon. Si \EFI\Microsoft est manquant, vous le recréerez probablement.

Décision : Si l’ESP se monte et liste des fichiers, préférez la réparation par reconstruction des fichiers de démarrage (bcdboot) plutôt que de reformater l’ESP. Le formatage est un dernier recours.

Tâche 4 : Reconstruire les fichiers de démarrage Windows sur l’ESP avec bcdboot (UEFI)

cr0x@server:~$ bcdboot C:\Windows /s Z: /f UEFI
Boot files successfully created.

Ce que cela signifie : Les fichiers de démarrage Windows ont été copiés sur l’ESP et une entrée de démarrage a peut-être été enregistrée. Cela corrige étonnamment souvent le message « Windows Boot Manager manquant ».

Décision : Redémarrez et sélectionnez « Windows Boot Manager » dans le firmware. Si cela démarre toujours sur GRUB uniquement, vérifiez l’ordre de démarrage et les entrées NVRAM.

Tâche 5 : Lister les entrées de démarrage du firmware depuis un média live Linux (vérification UEFI)

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0001,0000
Boot0000* Windows Boot Manager  HD(1,GPT,7c1b...,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
Boot0001* ubuntu                HD(1,GPT,7c1b...,0x800,0x32000)/File(\EFI\ubuntu\shimx64.efi)
Boot0002* UEFI: USB Flash Disk  PciRoot(0x0)/Pci(0x14,0x0)/USB(0x1,0x0)/HD(1,MBR,0x...,0x800,0x1d000)

Ce que cela signifie : Le firmware voit à la fois Windows Boot Manager et l’entrée ubuntu, et les deux pointent vers des fichiers sur la même partition ESP. Bien. Si l’entrée Windows est manquante ou pointe vers le mauvais disque/partition, vous avez trouvé le problème.

Décision : Si l’entrée Windows existe mais n’est pas première, ajustez l’ordre de démarrage. Si elle n’existe pas, relancez bcdboot ou créez une entrée (avancé).

Tâche 6 : Confirmer la partition ESP et le système de fichiers depuis Linux (ne pas deviner)

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,PARTLABEL,PARTUUID,MOUNTPOINTS
NAME        SIZE TYPE FSTYPE PARTLABEL            PARTUUID                             MOUNTPOINTS
nvme0n1   476.9G disk
├─nvme0n1p1 100M part vfat   EFI System Partition  7C1B-...-...                        /mnt/esp
├─nvme0n1p2  16M part        Microsoft reserved   1a2b-...-...
└─nvme0n1p3 476G part ntfs   Basic data partition 3c4d-...-...                        /mnt/win

Ce que cela signifie : L’ESP est vfat et petite (100M), Windows est NTFS. Si votre ESP est montée ailleurs ou se trouve sur un disque différent de celui attendu, arrêtez et cartographiez-la.

Décision : Utilisez l’ESP dont vous démarrez réellement, pas celle dont vous rêvez.

Tâche 7 : Monter l’ESP et vérifier le chemin Microsoft depuis Linux

cr0x@server:~$ sudo mkdir -p /mnt/esp
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/esp
cr0x@server:~$ ls -R /mnt/esp/EFI/Microsoft/Boot | head
/mnt/esp/EFI/Microsoft/Boot:
BCD
BCD.LOG
bootmgfw.efi
bootmgr.efi
memtest.efi

Ce que cela signifie : Les fichiers existent. Si bootmgfw.efi est absent, Windows ne peut pas se charger. Si seuls des répertoires Linux existent, les fichiers de démarrage Windows ont été supprimés ou n’ont jamais été créés sur cette ESP.

Décision : Si manquant, préférez bcdboot depuis WinRE. Copier des .efi aléatoires depuis Internet est la façon dont on finit avec « violation Secure Boot » et une mauvaise journée.

Tâche 8 : Dans WinRE, vérifier l’état de BitLocker avant de « réparer » quoi que ce soit

cr0x@server:~$ manage-bde -status C:
BitLocker Drive Encryption: Configuration Tool version 10.0.19041
Volume C: [Windows]
    Size:                 475.00 GB
    BitLocker Version:    2.0
    Conversion Status:    Fully Encrypted
    Percentage Encrypted: 100.0%
    Protection Status:    Protection On
    Lock Status:          Unlocked
    Identification Field: Unknown
    Key Protectors:
        TPM
        Numerical Password

Ce que cela signifie : BitLocker est activé. Les changements du chemin de démarrage peuvent déclencher des demandes de clé de récupération. Ce n’est pas une catastrophe, mais c’est un problème de coordination si vous n’avez pas la clé.

Décision : Si vous n’avez pas la clé de récupération, marquez une pause et obtenez-la depuis votre compte/IT. Poursuivre quand même, c’est jouer à la roulette avec l’accès.

Tâche 9 : Utiliser bootrec pour scanner les installations Windows (utile surtout sur BIOS/MBR, parfois sur UEFI)

cr0x@server:~$ bootrec /scanos
Scanning all disks for Windows installations.

Please wait, since this may take a while...

Successfully scanned Windows installations.
Total identified Windows installations: 1
[1]  C:\Windows

Ce que cela signifie : WinRE peut voir une installation Windows. S’il en trouve zéro, vous pouvez avoir un problème de pilote de stockage/RAID, un volume BitLocker verrouillé, ou une corruption du système de fichiers.

Décision : Si zéro installation trouvée, ne reconstruisez pas encore le BCD. Rendez d’abord le volume Windows visible et lisible.

Tâche 10 : Reconstruire le BCD proprement (UEFI et BIOS)

cr0x@server:~$ bcdedit /enum
The boot configuration data store could not be opened.
The system cannot find the file specified.

Ce que cela signifie : Le magasin BCD est manquant ou pas là où WinRE s’attend à le trouver. C’est courant après des changements d’ESP.

Décision : Utilisez bcdboot pour régénérer un BCD propre sur la partition système/ESP correcte plutôt que d’essayer de ressusciter un magasin à moitié cassé.

Tâche 11 : Vérifier la santé du système de fichiers sur la partition Windows depuis WinRE

cr0x@server:~$ chkdsk C: /f
The type of the file system is NTFS.
Volume label is Windows.

Stage 1: Examining basic file system structure ...
File verification completed.
Stage 2: Examining file name linkage ...
Index verification completed.
Stage 3: Examining security descriptors ...
Security descriptor verification completed.
Windows has made corrections to the file system.
No further action is required.

Ce que cela signifie : Le système de fichiers avait des problèmes mineurs et a été corrigé. Si vous voyez beaucoup de secteurs défectueux ou « impossible à récupérer », vous avez un problème de disque qui se déguise en problème de démarrage.

Décision : Si l’état du disque est douteux, arrêtez de poursuivre les chargeurs et commencez à planifier la préservation des données et le remplacement du disque.

Tâche 12 : Vérifier que les fichiers de démarrage Windows existent sur l’ESP après réparation

cr0x@server:~$ dir Z:\EFI\Microsoft\Boot
 Volume in drive Z is SYSTEM
 Volume Serial Number is 8C2A-4E1D

 Directory of Z:\EFI\Microsoft\Boot

01/15/2026  10:32 AM    <DIR>          .
01/15/2026  10:32 AM    <DIR>          ..
01/15/2026  10:32 AM           1,048,576 bootmgfw.efi
01/15/2026  10:32 AM              12,288 BCD

Ce que cela signifie : Les fichiers clés sont présents. S’ils ne le sont pas, l’ESP n’était pas celle que vous pensez, ou la copie a échoué à cause de permissions/problèmes système de fichiers.

Décision : Si les fichiers existent et que vous ne pouvez toujours pas démarrer Windows, le problème est probablement l’entrée NVRAM, le comportement Secure Boot/shim, ou les exigences de récupération BitLocker — pas des fichiers manquants.

Tâche 13 : Depuis Linux, vérifier si vous avez accidentellement installé Windows en mode BIOS (détection mode mixte)

cr0x@server:~$ sudo parted -l | sed -n '1,120p'
Model: NVMe Device (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  106MB   105MB   fat32              boot, esp
 2      106MB   123MB   16.8MB                     msftres
 3      123MB   512GB   512GB   ntfs               msftdata

Ce que cela signifie : Ce disque est GPT avec une ESP. C’est cohérent avec Windows en UEFI. Si vous voyez une table MBR (« msdos ») avec une partition NTFS « active » et pas d’ESP, c’est du Windows legacy.

Décision : Adaptez votre stratégie de réparation à ce qui est réellement sur le disque. N’essayez pas de « UEFI-iser » une installation BIOS en pleine incident à moins d’être prêt pour une panne plus longue.

Tâche 14 : Depuis WinRE, définir la partition correcte comme active (BIOS/MBR uniquement)

cr0x@server:~$ diskpart
DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          476 GB  1024 KB

DISKPART> sel disk 0
Disk 0 is now the selected disk.

DISKPART> list part

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    Primary            500 MB  1024 KB
  Partition 2    Primary            475 GB   501 MB

DISKPART> sel part 1
Partition 1 is now the selected partition.

DISKPART> active
DiskPart marked the current partition as active.

DISKPART> exit

Ce que cela signifie : Vous avez marqué une partition comme active pour que le code de démarrage BIOS sache où chercher ensuite. Sur GPT/UEFI, c’est sans objet et parfois trompeur.

Décision : Ne faites cela que si vous avez confirmé le mode MBR/Legacy. Si le disque est GPT, éloignez-vous de active.

Voie de réparation A : UEFI + GPT (systèmes modernes)

Si votre système est UEFI (et la plupart des machines post-2012 le sont), traitez l’ESP comme une infrastructure partagée. Vous voulez que Windows Boot Manager soit restauré sur l’ESP et qu’une entrée NVRAM y pointe.

Étape 1 : Accéder à l’invite de commandes WinRE

Utilisez une clé USB d’installation Windows ou un média de récupération. Choisissez « Réparer votre ordinateur » → « Dépannage » → « Invite de commandes ». Si la disposition du clavier est incorrecte, corrigez-la tôt ; taper les clés de récupération avec une mauvaise disposition, c’est une comédie que vous n’allez pas apprécier.

Étape 2 : Identifier l’ESP et la partition Windows

Utilisez diskpart, list vol. L’ESP sera FAT32, petite (100–550Mo typiquement), et marquée « System ». La partition Windows est généralement NTFS et volumineuse.

Étape 3 : Assigner des lettres et exécuter bcdboot

C’est la réparation UEFI la plus propre dans le monde Windows : elle copie les fichiers de démarrage dans l’ESP et construit un magasin BCD pour l’installation que vous spécifiez.

cr0x@server:~$ diskpart
DISKPART> list vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 1         SYSTEM       FAT32  Partition    100 MB  Healthy    System
  Volume 2     C   Windows      NTFS   Partition    475 GB  Healthy    Boot

DISKPART> sel vol 1
Volume 1 is the selected volume.

DISKPART> assign letter=Z
DiskPart successfully assigned the drive letter or mount point.

DISKPART> exit

cr0x@server:~$ bcdboot C:\Windows /s Z: /f UEFI
Boot files successfully created.

Ce que vous venez de faire : Vous avez dit à Windows : « Utilise l’installation Windows à C:\Windows, mets son chargeur sur Z: (l’ESP), et rends-le compatible UEFI. »

Étape 4 : Confirmer les fichiers sur l’ESP

Si les fichiers n’ont pas été placés là où attendu, ne redémarrez pas en espérant. Vérifiez.

Étape 5 : Corriger l’ordre de démarrage du firmware si nécessaire

Si la machine démarre toujours sur GRUB par défaut, elle peut simplement choisir l’entrée ubuntu en premier. Vous pouvez réordonner dans les paramètres du firmware, ou depuis Linux avec efibootmgr.

cr0x@server:~$ sudo efibootmgr
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0000
Boot0000* Windows Boot Manager
Boot0001* ubuntu

Décision : Si vous voulez Windows en premier, réordonnez. Si vous voulez GRUB en premier, laissez tel quel. Mais choisissez, ne dérivez pas.

Secure Boot et réalités du shim

Secure Boot complique le dual-boot parce que le firmware ne chargera que des binaires EFI signés. Beaucoup de distributions Linux utilisent un shim signé (shimx64.efi) qui charge ensuite GRUB. Windows utilise le gestionnaire de démarrage signé par Microsoft. Si vous remplacez des fichiers de démarrage par des binaires non signés ou tentez de chaîner avec des composants incompatibles, Secure Boot vous bloquera.

Règle : si Secure Boot est activé et que vous n’avez pas une raison valable de le désactiver, laissez-le activé et utilisez des chemins de démarrage signés. La « raison valable » est généralement « je fais du développement noyau », pas « mon démarrage est cassé et je suis impatient ».

Voie de réparation B : BIOS Legacy + MBR

Cela s’applique aux systèmes plus anciens, ou configurés intentionnellement en mode legacy. Ici vos cibles sont : le code de démarrage MBR, le secteur de démarrage de la partition active, et le magasin BCD.

Étape 1 : Confirmer que vous êtes réellement en mode BIOS/MBR

Dans diskpart, la colonne « Gpt » sera vide pour le disque système. Vous verrez aussi habituellement le concept de partition « active » qui importe.

Étape 2 : Identifier la partition System Reserved (ou la partition de démarrage)

Disposition courante : une partition NTFS de 100–500Mo nommée « System Reserved » qui contient \Boot\BCD. Si elle manque, les fichiers de démarrage Windows peuvent se trouver sur C: (pas idéal, mais ça arrive).

Étape 3 : Marquer la bonne partition active

Une seule partition devrait être active sur un disque MBR. Si les outils Linux l’ont changée, le BIOS démarrera la mauvaise chose sans broncher.

Étape 4 : Réparer le MBR et le secteur de démarrage (soyez précis)

cr0x@server:~$ bootrec /fixmbr
The operation completed successfully.

cr0x@server:~$ bootrec /fixboot
The operation completed successfully.

Ce que cela signifie : Le code de démarrage MBR et le secteur de démarrage de la partition ont été écrits. Si /fixboot retourne « Access is denied », vous devrez peut-être assigner une lettre à la partition système et exécuter bootsect ou utiliser bcdboot selon la version et la disposition Windows.

Étape 5 : Reconstruire le BCD

cr0x@server:~$ bootrec /rebuildbcd
Scanning all disks for Windows installations.

Please wait, since this may take a while...

Successfully scanned Windows installations.
Total identified Windows installations: 1
[1]  C:\Windows
Add installation to boot list? Yes(Y)/No(N)/All(A): y
The operation completed successfully.

Décision : Si /rebuildbcd trouve zéro installation, arrêtez et découvrez pourquoi Windows n’est pas détectable (pilotes, BitLocker, NTFS endommagé).

Étape 6 : Préférez bcdboot quand BCD est en vrac

Dans de nombreux cas, surtout avec des historiques de partitionnement étranges, bcdboot est plus déterministe que bootrec /rebuildbcd. Vous pointez vers Windows ; il génère ce dont il a besoin sur la partition système.

cr0x@server:~$ bcdboot C:\Windows /s S: /f BIOS
Boot files successfully created.

Note : Ici S: serait la partition System Reserved à laquelle vous avez assigné une lettre. Ne devinez pas — confirmez avec dir S:\Boot.

Seconde petite blague (et on a fini) : MBR signifie « Mostly Bad Regrets » quand vous exécutez fixmbr sur le mauvais disque.

Après-soin : maintenir le dual-boot stable

Rendre l’ESP ennuyeuse à nouveau

L’ESP est un état partagé. L’état partagé mérite du respect : sauvegardez-la (au moins le répertoire EFI), gardez-la petite et propre, et ne la montez pas en écriture sous Linux sauf si vous faites quelque chose d’intentionnel.

Décidez qui « possède » le démarrage par défaut

Choisissez une des options :

• Windows Boot Manager par défaut, et utilisez le menu de démarrage du firmware pour sélectionner Linux quand nécessaire.
• GRUB par défaut, et chaînez Windows. C’est pratique pour les flux de travail orientés Linux mais peut être perturbé par des mises à jour firmware ou Windows.

Ce qu’il faut éviter : une situation où les mises à jour Windows réinitialisent l’ordre de démarrage chaque trimestre et vous le réparez à chaque fois. Ce n’est pas du dual-boot ; c’est un trouble affectif saisonnier.

BitLocker : suspendre avant des changements majeurs du démarrage

Si vous utilisez BitLocker, pensez à suspendre la protection avant des modifications majeures du chargeur (mises à jour du firmware, reconstruction de l’ESP, modifications significatives des partitions), puis réactivez après un démarrage propre. Cela réduit les demandes de récupération surprises.

Systèmes multi-disques : soyez explicite sur l’emplacement de l’ESP

Si vous avez deux disques (par ex. NVMe pour Windows, SSD SATA pour Linux), vous avez deux options valables :

• ESP partagé unique sur un disque (simple, mais couple les disques).
• ESP séparé par disque (plus résilient, mais nécessite des entrées firmware et une discipline d’installateur précises).

Ce qui ne fonctionne pas : croire que l’installateur « fera la chose évidente ». Les installateurs font la première chose qu’ils trouvent.

Erreurs courantes : symptôme → cause → correctif

1) Symptom : « Aucun périphérique bootable » après l’installation de Linux

Cause : L’ordre de démarrage du firmware a changé, ou l’entrée NVRAM de Windows Boot Manager a été supprimée/écrasée.

Correctif : Utilisez le setup du firmware pour sélectionner Windows Boot Manager ; s’il manque, exécutez bcdboot C:\Windows /s Z: /f UEFI après avoir monté l’ESP.

2) Symptom : Démarre directement sur GRUB, Windows absent du menu

Cause : La configuration de GRUB ne détecte pas Windows, ou les fichiers Windows Boot Manager sont absents de l’ESP.

Correctif : Confirmez que les fichiers de démarrage Windows existent sur l’ESP ; sinon, reconstruisez-les avec bcdboot. S’ils existent, régénérez la config GRUB depuis Linux (distro-specific), ou utilisez le menu firmware pour Windows.

3) Symptom : Invite GRUB (grub>) ou « minimal BASH-like line editing »

Cause : GRUB ne trouve pas sa configuration ou la partition root, souvent après déplacement de partitions ou changement d’UUID.

Correctif : Ne combattez pas GRUB en premier si votre objectif est Windows. Démarrez WinRE et restaurez le chargeur Windows par défaut ; réparez GRUB depuis Linux plus tard quand vous aurez le temps.

4) Symptom : Windows Boot Manager apparaît, puis écran bleu tôt dans le démarrage

Cause : Pas forcément lié au chargeur. Peut être des changements de pilote de stockage, corruption du système de fichiers, ou une mise à jour Windows foirée.

Correctif : Exécutez chkdsk depuis WinRE ; envisagez des réparations sfc/dism (hors scope des seules réparations de chargeur). La réparation du chargeur ne réparera pas un noyau/OS cassé.

5) Symptom : « Boot configuration data file is missing » ou erreurs BCD

Cause : Magasin BCD manquant/corrompu, mauvaise partition système, ou ESP non utilisé.

Correctif : Pour UEFI, montez l’ESP et exécutez bcdboot. Pour BIOS, assurez-vous de la partition active correcte et exécutez bcdboot ... /f BIOS ou bootrec /rebuildbcd.

6) Symptom : « Access is denied » sur bootrec /fixboot

Cause : Commun sur certains environnements de récupération Windows 10/11 à cause des permissions de partition ou d’une partition cible incorrecte.

Correctif : Utilisez bcdboot pour recréer les fichiers de démarrage sur la bonne partition. Si BIOS/MBR, assurez-vous que System Reserved a une lettre assignée et est la partition active.

7) Symptom : Windows demande la clé de récupération BitLocker après une réparation

Cause : Les mesures TPM ont changé parce que la chaîne de démarrage a changé (nouveau binaire EFI, nouveau chemin, entrée différente).

Correctif : Entrez la clé de récupération, démarrez avec succès, puis envisagez de suspendre et réactiver BitLocker pour « apprendre » le nouvel état de démarrage au TPM.

8) Symptom : La réparation fonctionne une fois, puis casse après une mise à jour firmware

Cause : La mise à jour firmware a réinitialisé l’ordre de démarrage ou supprimé des entrées NVRAM.

Correctif : Recréez les entrées avec bcdboot (Windows) ou efibootmgr (Linux). Gardez le contenu de l’ESP stable et sauvegardé.

9) Symptom : Tout semble correct, mais l’entrée Windows Boot Manager pointe vers le mauvais disque

Cause : Système multi-disques ; les fichiers de démarrage Windows ont été créés sur le disque A mais l’entrée firmware pointe vers l’ESP du disque B (ou vice versa).

Correctif : Identifiez l’ESP réellement utilisé par le firmware ; recréez les fichiers de démarrage là avec bcdboot. Optionnellement supprimez les entrées obsolètes et standardisez.

Trois mini-histoires d’entreprise depuis les tranchées du démarrage

Incident n°1 : La mauvaise hypothèse (le conte de fées « il n’y a qu’une ESP »)

Une entreprise de taille moyenne gérait des postes développeurs en dual-boot : Windows pour les outils corporate, Linux pour les pipelines de build. Un nouveau lot de matériel est arrivé avec deux disques par machine : un petit NVMe et un SSD SATA plus grand. Le processus d’imagerie a installé Windows sur le NVMe. Linux est allé sur le SATA.

L’équipe a supposé que l’ESP vivait sur le disque Windows. Raisonnable. Aussi faux. L’installateur Linux, lancé en vitesse, a trouvé une ESP existante sur le SATA (reste d’une image fournisseur) et l’a utilisée. La machine avait donc deux ESP, et celle que le firmware préférait dépendait d’une subtile ordre d’énumération.

L’incident est apparu comme « Windows disparaît parfois ». Après des mises à jour ou cycles d’alimentation, la moitié de la flotte démarrerait sur GRUB sans option Windows ; l’autre moitié démarrerait correctement sur Windows. Tout le monde a blâmé les mises à jour Windows parce que c’est ce qu’on fait quand on se sent impuissant.

La réparation était ennuyeuse : inventorier les disques, identifier l’ESP faisant autorité par machine, reconstruire les fichiers de démarrage Windows sur cette ESP avec bcdboot, puis standardiser l’ordre de démarrage du firmware. Ils ont aussi supprimé l’ESP orpheline après avoir confirmé qu’aucune dépendance n’existait. La vraie cause racine n’était pas un bug Windows ; c’était une hypothèse qui avait pris vie.

Incident n°2 : L’optimisation qui a mal tourné (réduire l’ESP pour « économiser de l’espace »)

Une autre organisation avait l’habitude de « serrer » les partitions pour maximiser l’espace utile. Quelqu’un a remarqué une ESP de 500Mo et l’a trouvée gaspillée. Ils l’ont réduite à 100Mo, parce que « ce ne sont que des fichiers de démarrage ».

Ça a marché. Pendant un temps. Puis une mise à jour Linux a ajouté de nouveaux noyaux et quelques artefacts EFI. Les mises à jour Windows ont aussi rafraîchi les composants de démarrage. L’ESP s’est remplie en silence, parce que la supervision ne surveillait pas « l’espace libre sur l’ESP », pour la même raison que personne ne surveille l’espace libre dans le placard de la salle de pause.

Finalement, les mises à jour ont commencé à échouer. Puis les réparations de démarrage ont commencé à échouer. Puis un sous-ensemble de machines a arrêté de démarrer du tout parce que le système de fichiers de l’ESP est devenu incohérent après des écritures partielles répétées. La récupération n’était pas difficile, mais perturbante : agrandir l’ESP (pas toujours simple), ou créer une nouvelle ESP et migrer les entrées, puis nettoyer avec précaution.

La leçon est simple : traitez l’ESP comme un volume de configuration partagé avec de la marge. Économiser quelques centaines de mégaoctets sur un disque de plusieurs centaines de gigaoctets, c’est une optimisation qui prouve que vous savez mesurer des choses, pas que vous savez les exploiter.

Incident n°3 : La pratique ennuyeuse qui a sauvé la mise (une petite sauvegarde d’ESP)

Une société financière avait du dual-boot sur quelques portables spécialisés pour des tests matériel. Leur équipe SRE n’adorait pas ça, mais l’a accepté avec des garde-fous. Un de ces garde-fous était une procédure trimestrielle de « snapshot de l’ESP » : démarrer sous Linux, monter l’ESP en lecture seule quand possible, et tar l’annuaire EFI vers un stockage interne chiffré.

Un jour, une mise à jour du firmware a réinitialisé les entrées NVRAM et la machine a par défaut choisi un chemin non fonctionnel. L’opérateur ne pouvait plus démarrer Windows, et Linux démarrait de façon inconsistante. Personne n’a paniqué. Ils ont démarré un live USB Linux, monté l’ESP, comparé avec la dernière archive connue bonne, et restauré les répertoires manquants. Puis ils ont recréé les entrées de démarrage.

Ce qui aurait pu devenir une panne totale d’ordinateur est devenu une réparation contrôlée de 40 minutes. Pas de perte de données, pas de drame, pas d’actions héroïques nocturnes. La pratique n’était pas astucieuse ; elle était juste cohérente.

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

Checklist 1 : Avant de toucher quoi que ce soit (filets de sécurité)

1. Confirmez si Windows est UEFI ou BIOS. Utilisez diskpart (étoile Gpt) et la présence d’une ESP.
2. Notez la disposition actuelle des disques/partitions. Capture d’écran ou notes de list disk, list vol.
3. Si BitLocker est activé, assurez-vous d’avoir la clé de récupération. Si vous ne l’avez pas, marquez une pause.
4. Sur les systèmes multi-disques, identifiez quel disque le firmware préfère démarrer en premier. Le « Disk 0 » dans Windows n’est pas toujours le disque préféré par le firmware.

Checklist 2 : Réparation minimale pour systèmes UEFI (par défaut recommandé)

1. Démarrez WinRE Invite de commandes.
2. Exécutez diskpart → list vol, trouvez le volume FAT32 « System » (ESP).
3. Assignez une lettre à l’ESP (par ex. Z:).
4. Confirmez la lettre de la partition Windows (C: ou autre) en vérifiant \Windows.
5. Exécutez bcdboot <WinLetter>:\Windows /s Z: /f UEFI.
6. Redémarrez et sélectionnez Windows Boot Manager dans le menu firmware.
7. Si nécessaire, réordonnez les entrées de démarrage dans le firmware ou via Linux efibootmgr.

Checklist 3 : Réparation minimale pour systèmes BIOS/MBR

1. Démarrez WinRE Invite de commandes.
2. diskpart → confirmez l’absence d’étoile GPT pour le disque système.
3. Trouvez la partition System Reserved ; assignez une lettre (S:).
4. Marquez la partition System Reserved comme active.
5. Exécutez bootrec /fixmbr et bootrec /fixboot.
6. Exécutez bootrec /rebuildbcd ou bcdboot C:\Windows /s S: /f BIOS.
7. Redémarrez et validez.

Checklist 4 : Si vous devez préserver Linux aussi

1. Après que Windows démarre, décidez du propriétaire du démarrage par défaut (Windows Boot Manager vs GRUB).
2. Si GRUB a été écrasé ou perdu, réparez GRUB depuis Linux (distro-specific) pour restaurer le menu dual-boot.
3. Conservez une copie du contenu de l’ESP une fois stabilisé.
4. Documentez l’ESP choisie et l’ordre de démarrage pour éviter que votre futur vous ne réapprenne cette leçon.

FAQ

1) Est-ce sûr d’exécuter bcdboot ? Va-t-il supprimer Linux ?

Sur les systèmes UEFI, bcdboot écrit les fichiers de démarrage Windows sur l’ESP et met à jour la configuration de démarrage Windows. Il ne supprime pas intrinsèquement Linux, mais si votre ESP est minuscule et pleine, ou si vous « nettoyez » ensuite les répertoires, vous pouvez casser Linux. Utilisez-le, mais vérifiez l’espace libre de l’ESP et ne supprimez pas les répertoires d’autres fournisseurs.

2) Dois-je désactiver Secure Boot pour réparer le dual-boot ?

Pas comme première action. Secure Boot peut révéler des chemins de démarrage non signés/incorrects, mais le désactiver masque souvent le vrai problème et crée une nouvelle classe de problèmes plus tard. Réparez la chaîne de démarrage correctement ; laissez Secure Boot activé sauf si vous avez une exigence spécifique.

3) Pourquoi Windows reprend-il sans cesse l’ordre de démarrage ?

Les mises à jour Windows et certaines mises à jour firmware peuvent réinitialiser l’ordre NVRAM pour préférer Windows Boot Manager. Ce n’est pas personnel ; c’est juste la priorité des fournisseurs pour la prise en charge. Si vous voulez Linux en premier, prévoyez de réaffirmer GRUB comme défaut de temps à autre, ou utilisez le menu firmware pour Linux.

4) Mon ESP a disparu. Puis-je en créer une nouvelle ?

Oui, mais ce n’est pas la solution la plus rapide. Créer une nouvelle ESP implique des modifications de partition, formater en FAT32, définir le bon type/flags GPT, puis utiliser bcdboot pour la remplir et efibootmgr/firmware pour l’enregistrer. Ne le faites que si l’ESP d’origine est irrécupérable.

5) Que faire si bootrec /scanos ne trouve aucune installation Windows ?

C’est un problème de visibilité, pas un problème de « chargeur ». Causes courantes : volume BitLocker verrouillé, pilotes de stockage manquants (RAID/VMD), ou NTFS corrompu. Déverrouillez le volume, chargez les pilotes si nécessaire, et assurez-vous que la partition Windows est lisible avant de reconstruire le BCD.

6) Puis-je réparer le chargeur Windows uniquement depuis Linux ?

Vous pouvez parfois restaurer des fichiers EFI manquants si vous avez une copie connue bonne, et recréer des entrées NVRAM avec efibootmgr. Mais la méthode la plus fiable pour générer des fichiers de démarrage Windows/BCD corrects reste bcdboot depuis WinRE.

7) La réparation du chargeur risque-t-elle une perte de données ?

La plupart des réparations touchent des métadonnées et effectuent de petites écritures sur l’ESP ou la partition système. Le vrai risque de perte de données vient des erreurs de partitionnement (formatage de la mauvaise partition, redimensionnement du mauvais disque, « nettoyage » des partitions). Commencez par des commandes minimales et vérifiez chaque cible.

8) Je vois plusieurs entrées « Windows Boot Manager » dans le firmware. Laquelle est la bonne ?

Bienvenue en vie multi-disque. Chaque entrée pointe vers un disque/partition/chemin de fichier spécifique. Utilisez efibootmgr -v sous Linux pour voir laquelle pointe vers l’ESP contenant réellement \EFI\Microsoft\Boot\bootmgfw.efi. Supprimez les entrées obsolètes seulement après avoir confirmé un démarrage stable.

9) Dois-je réinstaller Windows à la place ?

Seulement si le volume OS est corrompu au-delà de toute réparation ou si vous planifiez déjà une réinstallation. Les problèmes de chargeur se réparent généralement en moins d’une heure. La réinstallation est une opération plus risquée et plus longue que les gens choisissent parce qu’elle donne l’impression d’être décisive.

Prochaines étapes (pratiques)

Voici ce que je ferais, dans l’ordre, si vous voulez la plus grande probabilité d’une récupération propre :

1. Déterminez si vous êtes UEFI ou BIOS en utilisant diskpart et la présence d’une ESP.
2. En UEFI : montez l’ESP, exécutez bcdboot, confirmez que les fichiers existent, puis corrigez l’ordre de démarrage.
3. En BIOS/MBR : définissez la partition active correcte, réparez le MBR/secteur de démarrage, reconstruisez le BCD.
4. Redémarrez une fois et validez. Si ça échoue, collectez l’erreur exacte et réévaluez quelle couche est encore cassée.
5. Après un démarrage réussi, stabilisez le dual-boot : choisissez le propriétaire du démarrage par défaut, documentez l’emplacement de l’ESP, et conservez une petite sauvegarde du contenu de l’ESP.

Si vous ne retenez rien d’autre : arrêtez d’essayer des commandes au hasard. Les échecs de démarrage récompensent le calme, les cartes et un changement délibéré à la fois.