Dual boot Windows + Linux : la configuration qui ne casse pas les mises à jour

Les principes : ce qui casse réellement et pourquoi

Les pannes de dual-boot ne sont généralement pas des « problèmes Linux » ou des « problèmes Windows ». Ce sont des problèmes de chaîne d’amorçage.
Deux systèmes d’exploitation partagent les mêmes quelques éléments d’état du firmware et métadonnées disque. Si vous ne contrôlez pas ces éléments délibérément,
des installateurs et mises à jour « aidants » s’en chargeront.

La chaîne de démarrage, en clair

Sur les PC modernes vous devez être en UEFI + GPT. Le firmware charge une entrée de démarrage (un enregistrement NVRAM pointant vers un exécutable EFI).
Cet exécutable est typiquement Windows Boot Manager ou un gestionnaire de démarrage Linux (GRUB ou systemd-boot).
De là, vous choisissez un OS, chargez un noyau, et seulement ensuite vous êtes dans le confort de votre système d’initialisation habituel.

Ce qui casse durant les mises à jour est généralement l’un de ces éléments :

• Modifications de l’ordre de démarrage NVRAM UEFI (les mises à jour Windows aiment promouvoir leur propre entrée).
• Modifications du contenu de la partition système EFI (ESP) (fichiers ajoutés/supprimés, parfois écrasés).
• Mésentente sur la politique Secure Boot (clés, shims, signatures).
• Changements d’identité du disque (clonage, déplacement de disques, mises à jour de firmware qui réordonnent les lecteurs).
• Contention d’accès au système de fichiers (Windows Fast Startup et l’hibernation laissant NTFS « sale »).

La conception robuste n’est pas « installer Linux à côté de Windows et prier ». C’est :
responsabilités séparées, minimiser l’état partagé et être capable de reconstruire le démarrage de manière déterministe.

Si vous ne retenez qu’une chose : votre ESP n’est pas un tiroir à bazar. Traitez-la comme une config de production.
Sauvegardez-la. Gardez-la petite et ennuyeuse. Sachez ce qu’elle contient.

Blague #1 : Un machine en dual-boot, c’est comme avoir deux managers — tout va bien tant qu’ils ne « possèdent » pas tous les deux l’agenda.

Faits intéressants et un peu d’histoire

Quelques points de contexte qui rendent les recommandations d’aujourd’hui moins arbitraires :

1. UEFI a remplacé le BIOS legacy pour moderniser le démarrage, permettre Secure Boot, et supprimer d’anciennes limites comme les contraintes de la table de partition MBR.
2. MBR limitait historiquement les disques à ~2 To et quatre partitions primaires. GPT a largement corrigé cela, d’où des layouts de dual-boot plus sensés avec le temps.
3. L’ESP est standardisée : c’est typiquement FAT32 et conçu pour contenir des exécutables EFI pour plusieurs OS — la coexistence est le design, pas un bricolage.
4. Windows Boot Manager est devenu le centre de gravité dans de nombreuses configurations OEM ; les vendeurs codent souvent des préférences de démarrage en sa faveur.
5. Secure Boot a commencé comme fonctionnalité de sécurité mais est devenu une variable opérationnelle : excellent quand c’est cohérent, pénible quand c’est mixte entre distributions et noyaux personnalisés.
6. GRUB s’est popularisé en partie parce qu’il est flexible sur de nombreux systèmes de fichiers et pour la détection multi-OS ; systemd-boot a gagné du terrain en étant natif UEFI et plus simple.
7. BitLocker a changé la donne : ce n’est pas que du chiffrement ; c’est aussi un « système de détection de modifications » qui réagit aux changements du chemin de démarrage.
8. Fast Startup est essentiellement une hibernation allégée : il laisse NTFS dans un état que Linux ne devrait pas monter en écriture, d’où des partitions partagées corrompues mystérieusement.

Une citation à garder en tête pendant tout travail sur le bootloader : Idée paraphrasée : « L’espoir n’est pas une stratégie. » — Général H. Norman Schwarzkopf, souvent cité en ops.

Choisir l’architecture : un disque, deux disques, une ESP, deux ESP

L’option la plus solide : disques physiques séparés

Si vous le pouvez, installez Windows sur un SSD et Linux sur un autre SSD. Cela vous donne un contrôle de rayon d’impact :
les mises à jour Windows ne peuvent abîmer que ce qu’elles voient et ce que votre firmware amorce en priorité.

Dans cette configuration, je préfère deux ESP (une par disque) quand le firmware se comporte et que vous voulez un isolement maximal.
Si votre firmware est capricieux, vous pouvez utiliser une seule ESP sur le disque Windows et garder la racine Linux entièrement séparée.

Pourquoi cela survit aux mises à jour : chaque OS peut garder ses propres fichiers de démarrage. Les entrées NVRAM peuvent toujours être réordonnées, mais les fichiers sous-jacents restent intacts.

L’option la plus courante : un seul disque, ESP partagée

Un seul disque suffit si vous êtes discipliné. Vous aurez une ESP (FAT32) puis des partitions séparées pour Windows et Linux.
Le mode de défaillance ici n’est pas « Linux a écrasé Windows ». C’est « la mise à jour Windows s’est mise en haut et vous avez oublié comment choisir l’autre entrée ».

L’ESP partagée n’est pas intrinsèquement fragile ; elle l’est quand elle n’est pas gérée. Sauvegardez-la et évitez les expérimentations aléatoires sur les bootloaders.

GRUB vs systemd-boot : choisissez selon votre budget de complexité

• GRUB : meilleur quand vous voulez un seul menu pour tout gouverner, supporter de nombreux noyaux, chaîner Windows et gérer des systèmes de fichiers étranges. Plus de pièces en mouvement.
• systemd-boot : plus simple, natif UEFI. Il lit les entrées depuis l’ESP et démarre des stubs EFI. Moins de « scripts magiques », moins de surprises.

Mon avis tranché : si vous utilisez une distribution mainstream sur un portable moderne avec UEFI, systemd-boot est la vie plus calme.
Si vous avez besoin d’une détection multiboot sophistiquée et de chaînes personnalisées, GRUB reste le couteau suisse.

Vérifications préalables avant de toucher aux partitions

Avant de repartitionner quoi que ce soit, vous devez savoir ce que vous avez réellement. Pas ce que vous pensez avoir.
La moitié des « mystères » du dual-boot viennent de quelqu’un qui a installé en mode legacy sur une machine UEFI, ou qui mélange MBR et GPT comme si on était en 2009.

Décidez de ces points d’emblée

• Boot UEFI uniquement (pas de CSM/legacy)
• Partitionnement GPT
• BitLocker : activé ou non, et si oui, comment vous gérerez les clés de récupération
• Secure Boot : activé (préféré) si votre distro le prend en charge proprement ; désactivé si vous utilisez des noyaux personnalisés et ne voulez pas gérer les clés
• Données partagées : oui ou non (et si oui, utilisez une partition de données dédiée avec des règles claires)

Les configurations dual-boot les plus fiables évitent l’ingéniosité. « Ingénieux » est ce que vous faites juste avant d’apprendre pourquoi l’ennui existe.

Plans de partition qui survivent aux mises à jour

Disposition de base UEFI/GPT (disque unique)

Un agencement ennuyeux et résistant aux mises à jour :

• ESP : 512 MiB à 1 GiB, FAT32, montée en /boot/efi sous Linux
• MSR : Microsoft Reserved (Windows la crée)
• Windows : NTFS pour C:
• Racine Linux : ext4 ou btrfs
• Swap Linux : optionnel si vous utilisez un swapfile ; nécessaire si vous voulez l’hibernation fiable
• Données partagées (optionnel) : exFAT ou NTFS, mais voir les règles ci-dessous

Règles pour la partition de données partagée (pour ne pas la corrompre)

Si vous partagez une partition NTFS entre Windows et Linux :

• Désactivez Windows Fast Startup, sinon Linux verra le volume comme en hibernation/dirty et un montage en écriture devient un piège.
• Ne montez jamais en RW les volumes système Windows en hibernation depuis Linux. Utilisez une partition de données séparée si vous avez besoin d’un accès RW.
• Préférez exFAT pour le « stockage basique » (photos, installateurs) si vous n’avez pas besoin des ACL NTFS. C’est plus simple entre OS.

Agencement deux disques (recommandé si possible)

Si vous avez deux SSD :

• Disque 0 (Windows) : ESP + MSR + Windows
• Disque 1 (Linux) : ESP optionnelle (si vous voulez isolation) + racine Linux + swap optionnel + /home optionnel

La partie « ne casse pas les mises à jour » vient ici de l’isolation et de la possibilité de régler la priorité de démarrage du firmware sur le disque de votre choix.
Dans le pire des cas, vous choisissez l’autre disque via le menu de démarrage ponctuel et continuez à travailler.

Ordre d’installation et stratégie de bootloader (ce que je recommande)

Installer Windows d’abord, puis Linux

Les installateurs Windows partent du principe qu’ils sont le seul OS au monde. Les installateurs Linux sont généralement mieux élevés concernant la coexistence.
Installez donc Windows en premier, appliquez tous les correctifs, puis réduisez la partition Windows et installez Linux.

Choisissez intentionnellement le gestionnaire de démarrage « principal »

Vous avez deux modèles sensés :

• Le gestionnaire Linux est principal : GRUB/systemd-boot propose un menu et chaîne Windows.
• Le Windows Boot Manager est principal : Windows démarre normalement, et vous sélectionnez Linux via le menu du firmware ou une entrée Windows ajoutée.

Pour la plupart des personnes qui utilisent Linux au quotidien, le premier modèle est meilleur. Pour les appareils gérés en entreprise avec des politiques Windows strictes, le second modèle évite les conflits de conformité.

Secure Boot et BitLocker : décidez, ne naviguez pas au hasard

Secure Boot peut coexister avec Linux si votre distro utilise shim + bootloaders signés. BitLocker peut aussi coexister, mais il est sensible aux modifications du chemin de démarrage.
La règle opérationnelle : terminez la configuration du bootloader, puis activez BitLocker (ou suspendez-le pendant les changements).

Tâches pratiques : commandes, sorties et décisions

Voici des tâches réelles que vous ferez pendant la configuration et la récupération. Chaque tâche inclut : commande, sortie typique, ce que ça signifie et la décision à prendre.
Les commandes sont affichées comme si elles étaient lancées depuis Linux (live USB ou système installé) sauf indication contraire.

Task 1: Confirm you booted the installer in UEFI mode

cr0x@server:~$ ls /sys/firmware/efi
config_table  efivars  esrt  fw_platform_size  fw_vendor  runtime  runtime-map  systab  vars

Ce que ça signifie : Si /sys/firmware/efi existe, vous êtes démarré en mode UEFI. Sinon, vous êtes en mode legacy/CSM.
Décision : Si ce n’est pas UEFI, arrêtez et redémarrez l’USB en mode UEFI. Mélanger les modes est la recette du « ça marche jusqu’au reboot ».

Task 2: Confirm the disk is GPT (not MBR)

cr0x@server:~$ sudo parted -l
Model: Samsung SSD 980 (nvme)
Disk /dev/nvme0n1: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name                          Flags
 1      1049kB  538MB   537MB   fat32        EFI system partition          boot, esp
 2      538MB   672MB   134MB                Microsoft reserved partition  msftres
 3      672MB   300GB   299GB   ntfs         Basic data partition          msftdata
 4      300GB   1000GB  700GB

Ce que ça signifie : « Partition Table: gpt » est ce que vous voulez.
Décision : Si c’est msdos/MBR et que vous voulez un dual-boot UEFI moderne, prévoyez une conversion (ou une réinstallation). N’ajoutez pas un nouveau Linux en mode legacy si vous pouvez l’éviter.

Task 3: Identify the EFI System Partition (ESP)

cr0x@server:~$ lsblk -o NAME,SIZE,FSTYPE,PARTTYPE,PARTFLAGS,MOUNTPOINTS
NAME        SIZE FSTYPE PARTTYPE                             PARTFLAGS MOUNTPOINTS
nvme0n1   931.5G
├─nvme0n1p1 512M vfat   c12a7328-f81f-11d2-ba4b-00a0c93ec93b boot,esp  /boot/efi
├─nvme0n1p2 128M        e3c9e316-0b5c-4db8-817d-f92df00215ae
├─nvme0n1p3 299G ntfs   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
└─nvme0n1p4 632G ext4   0fc63daf-8483-4772-8e79-3d69d8477de4 /

Ce que ça signifie : L’ESP apparaît comme vfat avec le type de partition EFI GUID.
Décision : Si vous n’avez pas d’ESP, vous ne pouvez pas faire un boot UEFI propre. Créez-en une (et préparez-vous à réparer les entrées de démarrage).

Task 4: Inspect what’s in the ESP (who installed what)

cr0x@server:~$ sudo find /boot/efi/EFI -maxdepth 2 -type f -name '*.efi'
/boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
/boot/efi/EFI/Microsoft/Boot/memtest.efi
/boot/efi/EFI/ubuntu/shimx64.efi
/boot/efi/EFI/ubuntu/grubx64.efi

Ce que ça signifie : Vous voyez les artefacts de démarrage Windows et Linux coexister.
Décision : Si les fichiers Linux manquent après une mise à jour, vous pouvez les restaurer depuis une sauvegarde ou réinstaller le bootloader. Si les fichiers Microsoft manquent, la récupération Windows les restaurera.

Task 5: Check UEFI boot entries and boot order

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0000,0003,0001
Boot0000* Windows Boot Manager  HD(1,GPT,2c2d...,0x800,0x100000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
Boot0001* UEFI: USB Disk  1.00
Boot0003* ubuntu  HD(1,GPT,2c2d...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

Ce que ça signifie : BootOrder décide de ce qui se passe sans intervention. Les mises à jour Windows déplacent souvent Boot0000 en tête.
Décision : Si Linux n’est pas en premier et que vous voulez qu’il le soit, changez BootOrder. Si Windows doit rester premier (en entreprise), acceptez-le et comptez sur une touche de boot ponctuelle.

Task 6: Set Linux boot entry first (when you want GRUB/systemd-boot primary)

cr0x@server:~$ sudo efibootmgr -o 0003,0000,0001
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0000,0001

Ce que ça signifie : Vous avez changé le chemin de démarrage par défaut.
Décision : Si BitLocker est activé, envisagez de le suspendre avant de faire cela (voir tâches ultérieures) ou soyez prêt avec les clés de récupération.

Task 7: Detect whether Windows is hibernated / Fast Startup “dirty” on NTFS

cr0x@server:~$ sudo ntfsfix -n /dev/nvme0n1p3
Mounting volume... FAILED
Attempting to correct errors... FAILED
NTFS signature is missing.
FAILED

Ce que ça signifie : Sur la mauvaise partition vous verrez « NTFS signature missing. » C’est un échec utile : vous avez ciblé le mauvais périphérique.
Décision : Revérifiez la cartographie des partitions ; ne « réparez » pas des partitions au hasard.

cr0x@server:~$ sudo ntfsfix -n /dev/nvme0n1p3
Mounting volume... OK
Processing of $MFT and $MFTMirr completed successfully.
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/nvme0n1p3 was processed successfully.

Ce que ça signifie : Les méta-données de base ont l’air saines. Cela ne prouve pas que Windows a été arrêté proprement, mais réduit le soupçon.
Décision : Si Linux refuse toujours le montage RW à cause d’une hibernation, démarrez Windows et faites un arrêt complet et désactivez Fast Startup.

Task 8: Confirm Windows partitions and flags before resizing

cr0x@server:~$ sudo fdisk -l /dev/nvme0n1
Disk /dev/nvme0n1: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disklabel type: gpt

Device           Start        End    Sectors   Size Type
/dev/nvme0n1p1     2048    1050623    1048576   512M EFI System
/dev/nvme0n1p2  1050624    1312767     262144   128M Microsoft reserved
/dev/nvme0n1p3  1312768  626000000  624687233 298.0G Microsoft basic data
/dev/nvme0n1p4 626000001 1953523711 1327523711 633.5G Linux filesystem

Ce que ça signifie : Vous voyez les bornes exactes. C’est ce que vous référenerez quand vous écrirez des commandes de récupération plus tard.
Décision : Si Windows est p3 et Linux p4, gardez-les ainsi. Évitez d’imbriquer les partitions de façon à compliquer les redimensionnements futurs.

Task 9: Verify Secure Boot state from Linux

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

Ce que ça signifie : Secure Boot est activé. Votre chaîne de démarrage Linux doit être signée correctement.
Décision : Si vous prévoyez d’exécuter des noyaux/modules non signés, soit inscrivez vos propres clés (avancé), soit désactivez Secure Boot. Ne faites pas de demi-mesures.

Task 10: Back up the ESP (this is your “don’t panic” button)

cr0x@server:~$ sudo mkdir -p /root/esp-backup
cr0x@server:~$ sudo tar -C /boot/efi -czf /root/esp-backup/esp-efi.tgz EFI
cr0x@server:~$ sudo ls -lh /root/esp-backup/esp-efi.tgz
-rw-r--r-- 1 root root 38M Feb  5 10:12 /root/esp-backup/esp-efi.tgz

Ce que ça signifie : Vous avez un snapshot point-in-time du contenu de l’ESP.
Décision : Copiez cette archive hors de la machine (USB, autre hôte). Si votre disque meurt, les sauvegardes locales sont de beaux posters motivationnels.

Task 11: If GRUB is missing, reinstall it (UEFI mode)

cr0x@server:~$ sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu
Installing for x86_64-efi platform.
Installation finished. No error reported.

Ce que ça signifie : Les binaires GRUB EFI ont été écrits sur l’ESP et une entrée de démarrage a probablement été créée/mise à jour.
Décision : Suivez par une régénération de config. Si votre distro préfère shim, assurez-vous que shim est aussi installé.

Task 12: Regenerate GRUB menu entries (detect Windows)

cr0x@server:~$ sudo update-grub
Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-41-generic
Found initrd image: /boot/initrd.img-6.8.0-41-generic
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
done

Ce que ça signifie : GRUB a détecté Windows Boot Manager et l’a ajouté.
Décision : Si Windows n’est pas trouvé, c’est généralement parce que l’ESP n’est pas montée ou que os-prober est désactivé. Corrigez ça plutôt que d’éditer au hasard des scripts GRUB.

Task 13: For systemd-boot users, list and install boot entries

cr0x@server:~$ bootctl status
System:
     Firmware: UEFI 2.70
  Secure Boot: enabled
   Setup Mode: no
 Boot into FW: supported

Current Boot Loader:
      Product: systemd-boot 255.4
     Features: ✓ Boot counting
               ✓ Menu timeout control
               ✓ One-shot menu timeout control
               ✓ Default entry control

Available Boot Loaders on ESP:
          ESP: /boot/efi (vfat)
         File: └─/EFI/systemd/systemd-bootx64.efi

Boot Loaders Listed in EFI Variables:
        Title: Linux Boot Manager
           ID: 0x0005
       Status: active, boot-order

Ce que ça signifie : systemd-boot est présent et enregistré.
Décision : Si ce n’est pas listé dans les variables EFI, vous devrez peut-être exécuter bootctl install ou créer une entrée avec efibootmgr selon la distribution.

Task 14: Mount the ESP correctly from a live USB during rescue

cr0x@server:~$ sudo mount /dev/nvme0n1p4 /mnt
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi
cr0x@server:~$ mount | grep -E '/mnt|efi'
/dev/nvme0n1p4 on /mnt type ext4 (rw,relatime)
/dev/nvme0n1p1 on /mnt/boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)

Ce que ça signifie : Vous avez monté la racine Linux et l’ESP dans l’environnement de secours. Les commandes de réinstallation du bootloader cibleront maintenant le bon endroit.
Décision : Si vous montez la mauvaise ESP (fréquent avec plusieurs disques), vous ne « réparerez » rien tout en vous sentant productif. Vérifiez les identifiants de périphérique.

Task 15: Check which disk the firmware is actually booting from

cr0x@server:~$ sudo efibootmgr | sed -n '1,6p'
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0003
Boot0000* Windows Boot Manager
Boot0003* ubuntu

Ce que ça signifie : Vous avez actuellement démarré via Windows Boot Manager (BootCurrent 0000).
Décision : Si vous attendiez le gestionnaire Linux, changez BootOrder ou utilisez le menu de démarrage ponctuel pour le sélectionner, puis revérifiez.

Task 16: Snapshot what the ESP looks like after Windows updates

cr0x@server:~$ sudo sh -c 'cd /boot/efi && find EFI -maxdepth 3 -type f -printf "%p %s\n" | sort | tail -n 8'
EFI/Microsoft/Boot/bootmgfw.efi 1705984
EFI/Microsoft/Boot/bootmgr.efi 1050632
EFI/Microsoft/Boot/memtest.efi 1105920
EFI/ubuntu/grubx64.efi 2867200
EFI/ubuntu/shimx64.efi 1204224
EFI/ubuntu/mmx64.efi 845824
EFI/Boot/bootx64.efi 1204224
EFI/Boot/fbx64.efi 2252800

Ce que ça signifie : Vous avez une vue rapide du « qu’est-ce qui a changé ». Des ajouts inattendus comme EFI/Boot/bootx64.efi peuvent être normaux (chargeurs de secours), mais des suppressions soudaines ne le sont pas.
Décision : Si les fichiers Linux ont disparu, restaurez depuis votre sauvegarde de l’ESP ou réinstallez le bootloader. Si l’ESP se remplit, agrandissez-la maintenant — pas pendant une panne.

Task 17: Diagnose disk UUID mismatches in Linux fstab

cr0x@server:~$ sudo blkid /dev/nvme0n1p1 /dev/nvme0n1p4
/dev/nvme0n1p1: UUID="3A1B-2C3D" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="2c2d..."
/dev/nvme0n1p4: UUID="2b5c0b2b-0b5a-4d7f-9f41-6f2c9a2a1c77" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="9a12..."

Ce que ça signifie : Vous disposez d’identifiants de référence.
Décision : Si votre /etc/fstab référence un UUID qui n’existe plus (fréquent après un clonage), corrigez-le avant de redémarrer pour éviter d’être laissé dans initramfs.

Task 18: Validate Windows Boot Manager exists on the ESP

cr0x@server:~$ sudo test -f /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi && echo OK || echo MISSING
OK

Ce que ça signifie : Le fichier de démarrage Windows existe.
Décision : S’il manque, le support de réparation Windows est votre ami. N’allez pas « emprunter » des binaires EFI aléatoires depuis Internet ; c’est comme attraper un malware avec une excellente disponibilité.

Blague #2 : L’ESP est en FAT32, ce qui est approprié, car c’est là que vos problèmes de démarrage prennent du poids.

Guide de diagnostic rapide

Quand un système dual-boot ne démarre pas, ne commencez pas à réinstaller des OS comme si l’on vous payait au téléchargement.
Vous voulez retrouver rapidement le goulot : sélection du firmware, entrée de démarrage, contenu de l’ESP, noyau/initramfs ou système de fichiers.

Premier : firmware et mode de démarrage

• Vérifiez le mode de démarrage : Êtes-vous en UEFI ? Si vous avez démarré par inadvertance une entrée legacy, tout le reste est du bruit.
• Utilisez le menu de démarrage ponctuel : Sélectionnez explicitement « Windows Boot Manager » vs « ubuntu » vs « Linux Boot Manager » et observez le comportement.
• Si Secure Boot est activé : Notez si l’échec est une erreur de signature/vérification (message du firmware) versus un échec GRUB/noyau.

Second : intégrité et contenu de l’ESP

• Depuis un live USB Linux, montez l’ESP et listez /EFI/Microsoft et votre répertoire Linux (/EFI/ubuntu, /EFI/fedora, etc.).
• Si l’ESP est manquante ou corrompue, vous verrez des échecs de montage ou des répertoires vides. Ce n’est pas un problème de configuration GRUB. C’est du stockage.
• Vérifiez l’espace libre sur l’ESP : si elle est quasi pleine, les mises à jour peuvent échouer de manière étrange.

Troisième : entrées NVRAM UEFI

• efibootmgr -v vous dit ce que le firmware pense exister.
• Si l’entrée Linux pointe vers un fichier disparu, recréez-la en réinstallant le bootloader ou en utilisant efibootmgr.
• Si l’entrée existe mais n’est jamais utilisée, corrigez BootOrder ou les paramètres du firmware.

Quatrième : noyau Linux et système racine

• Si GRUB apparaît mais que Linux ne démarre pas, vérifiez si l’UUID de racine a changé ou si initramfs ne trouve pas le périphérique racine.
• Si vous êtes lâché dans un shell initramfs, c’est généralement le nommage du stockage/UUID ou des pilotes manquants (rare sur les portables ; fréquent sur RAID/HBA).

Cinquième : échec spécifique à Windows

• Si Windows échoue mais que Linux démarre, ne « réparez » pas Windows depuis Linux au-delà de la vérification de l’existence du fichier EFI Windows.
• Si BitLocker demande la récupération après des changements de démarrage, c’est un comportement attendu ; récupérez la clé et stabilisez ensuite la chaîne de démarrage.

Erreurs courantes : symptôme → cause racine → correction

1) « Après une mise à jour Windows, ça démarre directement sur Windows »

Symptôme : Le menu GRUB/systemd-boot a disparu ; Windows se charge immédiatement.
Cause racine : Windows a mis « Windows Boot Manager » en tête de BootOrder ou a réinitialisé les défauts du firmware.
Correction : Depuis Linux (ou un live USB), exécutez efibootmgr -v et remettez BootOrder. Si vous ne pouvez pas démarrer Linux, utilisez le menu de démarrage ponctuel du firmware pour lancer l’entrée Linux, puis corrigez BootOrder de manière persistante.

2) « Linux démarre, mais l’entrée Windows manque dans GRUB »

Symptôme : Le menu GRUB n’affiche que des noyaux Linux, pas d’option Windows.
Cause racine : L’ESP n’était pas montée sur /boot/efi lors de update-grub, ou os-prober est désactivé par défaut dans la distro.
Correction : Montez l’ESP, activez os-prober si nécessaire, relancez update-grub. Validez que /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi existe.

3) « La partition Windows est en lecture seule ou ne se monte pas sous Linux »

Symptôme : Linux refuse un montage RW ; les logs mentionnent « hibernated » ou « unsafe state ».
Cause racine : Windows Fast Startup ou hibernation a laissé NTFS sale.
Correction : Démarrez Windows, désactivez Fast Startup, faites un arrêt complet. Ne forcez pas le montage RW à moins d’aimer perdre des données pour le plaisir.

4) « Demande de clé de récupération BitLocker après l’installation de Linux »

Symptôme : Windows demande la clé de récupération à chaque démarrage après des changements en dual-boot.
Cause racine : La chaîne de démarrage a changé (entrée EFI, bootloader, état Secure Boot). BitLocker interprète cela comme une altération.
Correction : Démarrez avec la clé de récupération une fois, puis stabilisez : conservez l’état Secure Boot, évitez les changements fréquents de bootloader, et ré-enclenchez BitLocker en le suspendant puis en le réactivant après la configuration finale.

5) « GRUB apparaît, mais Linux tombe en initramfs avec ‘cannot find UUID’ »

Symptôme : Le noyau démarre puis s’arrête, demandant le périphérique racine manuel.
Cause racine : L’UUID de la partition racine a changé (clone, restauration) ou /etc/fstab référence le mauvais UUID ; parfois la ligne de commande GRUB pointe vers le mauvais root.
Correction : Utilisez blkid pour trouver les UUID corrects ; mettez à jour /etc/fstab, régénérez initramfs et vérifiez la config du bootloader.

6) « Secure Boot activé : Linux ne démarre plus après une mise à jour du noyau »

Symptôme : Le firmware ou shim signale des erreurs de vérification/signature.
Cause racine : Noyau/module non signé, MOK mal inscrit, ou mélange de builds personnalisés avec Secure Boot sans gestion de clés.
Correction : Utilisez des noyaux signés par la distro, ou inscrivez votre Machine Owner Key et signez vos noyaux/modules, ou désactivez Secure Boot (mais faites-le intentionnellement).

7) « L’ESP s’est remplie et maintenant les mises à jour échouent »

Symptôme : Les mises à jour du noyau échouent, entrées de démarrage incohérentes, ou erreurs de montage ESP avec utilisation proche de 100%.
Cause racine : ESP trop petite (ancien défaut OEM 100–200 MiB) plus multiples bootloaders/noyaux/shims.
Correction : Augmentez la taille de l’ESP (avec précaution) ou nettoyez les anciens artefacts de démarrage. La bonne solution est généralement de redimensionner à au moins 512 MiB.

Trois mini-histoires du monde corporate

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise moyenne a déployé des portables développeurs avec Windows pour les outils corporate et Linux pour les pipelines de build. Du standard.
Le document de déploiement disait : « Installez Linux. GRUB affichera automatiquement Windows. » Cette ligne a tourné au vinaigre.

Sur une série de portables plus récents, l’installateur Linux a été démarré en mode legacy (parce que la clé USB avait deux options de démarrage et que les gens prenaient la première).
Linux s’est installé correctement. GRUB s’est installé correctement. La machine démarrait même — jusqu’à ce qu’une mise à jour firmware arrive via Windows Update et désactive silencieusement le CSM.

Le lendemain matin : écran noir et « No bootable device. » Windows existait toujours sur le disque. Linux aussi.
Mais les bootloaders avaient été installés pour le boot legacy, alors que le firmware exigeait maintenant UEFI uniquement.

La réparation n’a rien eu de magique. Ils ont reconstruit la chaîne de démarrage : créé/validé l’ESP, réinstallé le bootloader Linux en mode UEFI et vérifié que Windows avait une entrée UEFI correcte.
La vraie correction a été culturelle : leur checklist a ajouté « vérifier le mode UEFI » comme étape obligatoire avant l’installation, en utilisant la vérification exacte /sys/firmware/efi.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation a tenté « d’optimiser » l’usage disque sur des SSD mince. Ils ont réduit l’ESP au minimum observé dans les layouts OEM.
Ils ont aussi consolidé les bootloaders en supprimant les fichiers EFI « dupliqués » quand ils en voyaient.

C’était propre. Pendant un temps. Puis une mise à jour du noyau Linux a dû rafraîchir des fichiers liés à shim, et une mise à jour fonction Windows a rafraîchi ses composants de boot.
FAT32 n’est pas subtil. L’ESP s’est remplie, des écritures ont échoué partiellement et le système s’est retrouvé avec des artefacts de boot incohérents.

Le symptôme immédiat était hétérogène : certains appareils démarraient Linux mais pas Windows, d’autres l’inverse, d’autres ne démarraient aucun et retombaient sur le shell firmware.
L’équipe a perdu des heures parce que chaque portable semblait « unique », alors que la cause était uniformément ennuyeuse : l’ESP était trop petite.

Ils ont corrigé en redimensionnant les ESP à une base sensée (512 MiB+) et en instituant une règle :
pas de suppression manuelle dans l’ESP sauf si vous pouvez expliquer exactement pourquoi chaque fichier existe et comment il est référencé.
L’espace disque coûte moins cher que le temps d’incident.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise axée sécurité avait des appareils dual-boot pour les intervenants incidents. Ils avaient BitLocker activé, Secure Boot activé et Linux pour les outils forensics.
Ça ressemble à une recette de drame. Ce ne fut pas le cas, car ils traitaient la config de démarrage comme une infrastructure.

Chaque appareil avait : une sauvegarde de l’ESP prise après provisionnement, un petit runbook imprimé dans l’enveloppe de l’actif (oui, papier), et les clés de récupération correctement placées en escrow.
Le runbook comprenait exactement trois commandes : efibootmgr -v, un montage + listing de l’ESP, et une séquence de réinstallation du bootloader.

Pendant un cycle de mise à jour Windows, certains portables ont changé BootOrder et ont commencé à démarrer Windows par défaut.
Les utilisateurs l’ont remarqué immédiatement car leur flux de travail attendait Linux en premier. Personne n’a paniqué.

Ils ont utilisé le menu de démarrage ponctuel pour accéder à Linux, exécuté efibootmgr pour restaurer BootOrder et ont poursuivi.
Pas de réimagerie. Pas de « réinstallez simplement ». La pratique ennuyeuse — sauvegardes et un petit runbook — a transformé l’événement en erreur d’arrondi.

Checklists / plan étape par étape

Plan A : Meilleure pratique dual-boot sur un disque (UEFI/GPT)

1. Mettre à jour le BIOS/UEFI avant l’installation.
   Les mises à jour du firmware après l’installation peuvent réordonner des entrées de démarrage ou basculer des réglages. Évacuez le chaos tôt.
2. Configurer le firmware : UEFI uniquement (désactiver CSM), décider Secure Boot on/off, régler le mode SATA (AHCI sauf si RAID requis).
3. Installer Windows d’abord. Laissez-le créer ESP/MSR. Complétez la configuration initiale et les mises à jour.
4. Désactiver Fast Startup dans Windows si vous prévoyez d’accéder au NTFS depuis Linux.
5. Réduire la partition Windows depuis la gestion des disques Windows (plus sûr que depuis Linux pour NTFS).
6. Démarrer l’installateur Linux en mode UEFI et le confirmer avec ls /sys/firmware/efi.
7. Installer Linux dans l’espace libéré. Montez l’ESP existante sur /boot/efi ; ne la formatez pas.
8. Choisir le gestionnaire de démarrage : installez GRUB ou systemd-boot comme principal (ma préférence : systemd-boot si pris proprement en charge).
9. Redémarrer et valider : les deux chemins d’amorçage, l’ordre de démarrage du firmware, et que Windows démarre sans drame BitLocker.
10. Sauvegarder l’ESP et stocker l’archive hors appareil.

Plan B : Deux disques (survivabilité maximale)

1. Installez Windows sur le Disque 0 avec sa propre ESP.
2. Installez Linux sur le Disque 1, idéalement avec sa propre ESP aussi.
3. Réglez le disque de démarrage par défaut du firmware sur l’OS que vous voulez par défaut ; gardez l’autre accessible via le menu de démarrage.
4. Sauvegardez les deux ESP ; étiquetez-les par numéro de série du disque.

Garde-fous opérationnels (faites-les et votre futur vous sera moins en colère)

• Garder l’ESP ≥ 512 MiB. Les vieilles ESP OEM à 100 MiB sont un piège.
• Ne partagez pas la partition système Windows en RW depuis Linux. Si vous partagez, utilisez une partition de données dédiée.
• Faites un changement à la fois. Bootloader + Secure Boot + BitLocker en même temps est la recette pour perdre la causalité.
• Enregistrez vos entrées de démarrage (copiez la sortie de efibootmgr -v dans une note). Quand ça casse, vous voudrez « avant vs après ».
• Gardez une clé USB live Linux capable de monter vos systèmes de fichiers et incluant efibootmgr/mokutil.

FAQ

1) Dois-je faire du dual boot ou utiliser une VM ?

Si vous avez besoin de performance GPU, d’accès matériel complet, ou vous travaillez au niveau noyau, le dual-boot est raisonnable.
Si vous avez principalement besoin des outils userland Linux, une VM est opérationnellement plus calme et bien moins susceptible de casser lors des mises à jour.

2) Les mises à jour Windows peuvent-elles supprimer GRUB ?

Elles changent plus souvent l’ordre de démarrage pour préférer Windows Boot Manager. La suppression effective est plus rare mais peut arriver si l’ESP est corrompue, trop petite ou « nettoyée » par des humains.
Traitez l’ESP comme un état critique partagé et sauvegardez-la.

3) Est-il sûr d’avoir une ESP partagée ?

Oui, si elle est dimensionnée correctement (512 MiB+), montée correctement et pas modifiée manuellement de façon routinière.
L’ESP partagée est le modèle standard pour lequel UEFI a été conçu. La fragilité vient d’une mauvaise hygiène, pas du concept.

4) Dois-je désactiver Secure Boot ?

Si vous utilisez des noyaux standard de distribution, laissez Secure Boot activé. C’est un vrai contrôle de sécurité et ça fonctionne généralement.
Si vous prévoyez d’exécuter des noyaux/modules personnalisés et ne voulez pas gérer la signature des clés, désactivez-le. Choisissez et tenez-vous-y.

5) Comment éviter les invites de récupération BitLocker ?

Ne changez pas la chaîne de démarrage après avoir activé BitLocker sans d’abord la suspendre. Stabilisez le bootloader, les réglages firmware et l’état Secure Boot, puis activez BitLocker.
Gardez les clés de récupération accessibles car « éviter les invites » est un objectif, pas une garantie.

6) GRUB ou systemd-boot : lequel casse le moins ?

systemd-boot a moins de couches et tend à être plus facile à raisonner sur les systèmes UEFI, ce qui se traduit souvent par moins de surprises.
GRUB est plus flexible et plus documenté pour les configurations exotiques. Si vous avez besoin de flexibilité, acceptez la complexité.

7) Puis-je installer Linux sans toucher au bootloader Windows ?

Vous pouvez garder Windows Boot Manager par défaut et démarrer Linux via le menu firmware, ou ajouter Linux comme entrée firmware sans en faire le « primaire ».
C’est souvent le choix le moins conflictuel sur des appareils gérés en entreprise.

8) Quelle taille pour mes partitions Linux ?

Pour une station de travail développeur, ne sous-dimensionnez pas Linux : 50–100 GiB minimum pour la racine si vous construisez des conteneurs, SDKs ou noyaux.
Si vous utilisez btrfs pour des snapshots ou conservez de nombreux noyaux, prévoyez plus.

9) Quel système de fichiers pour Linux : ext4 ou btrfs ?

ext4 est le « moins surprenant ». btrfs offre snapshots et rollback facile, ce qui est réellement utile quand les mises à jour tournent mal.
Si vous choisissez btrfs, apprenez le workflow snapshot/rollback avant d’en avoir besoin à 2h du matin.

10) Si je clone mon disque sur un SSD plus grand, le dual boot fonctionnera-t-il toujours ?

Parfois. Le clonage peut changer les IDs de disque, les UUID de partition ou embrouiller les entrées firmware.
Prévoyez de vérifier efibootmgr -v, blkid et que le contenu de l’ESP correspond aux attentes après le clonage.

Conclusion : prochaines étapes pratiques

La configuration dual-boot qui survit aux mises à jour n’est pas magique. C’est de l’architecture et de l’hygiène :
UEFI/GPT, une ESP correctement dimensionnée, un gestionnaire de démarrage que vous comprenez, et un chemin de récupération exécutable sous stress.

Prochaines étapes que vous pouvez faire aujourd’hui :

• Vérifier que vous êtes en UEFI/GPT et identifier votre ESP.
• Sauvegarder l’ESP hors de l’appareil.
• Décider quel gestionnaire est principal et régler BootOrder en conséquence.
• Désactiver Fast Startup si vous partagez des données avec NTFS.
• Noter la sortie de efibootmgr -v et garder une clé USB live à portée.

Si vous faites ces cinq choses, la plupart des incidents « mise à jour Windows a cassé mon dual boot » deviennent une réparation de cinq minutes au lieu d’un projet de weekend.
Et votre futur vous pourra rester grincheux sur des problèmes plus intéressants.