Vous lancez l’installeur, choisissez la langue, cliquez sur Install, regardez la roue… et puis : 0%. Pas 1%. Pas « en train d’appliquer des mises à jour ». Juste 0%, comme si Windows faisait de la pleine conscience.
La plupart accusent l’ISO, la clé USB, ou « Windows qui fait Windows ». Parfois ils ont raison. Mais la cause cachée la plus fréquente que je vois sur le terrain est plus laide et plus précise : les E/S de stockage échouent tôt—silencieusement—parce que l’installeur dialogue avec un contrôleur/disque qui fait des timeouts, est mal identifié, sous-alimenté ou fonctionne en mode/mauvais pilote.
Playbook de diagnostic rapide
Si vous voulez le chemin le plus court vers la vérité, traitez ceci comme un incident SRE : confirmez le symptôme, isolez le sous-système, prouvez-le avec des logs, puis changez une variable à la fois.
Première étape : décidez si c’est le media ou le stockage
- Changez le média d’installation (autre clé USB, autre port). Utilisez un port USB 2.0 si disponible (oui, plus lent, mais souvent plus compatible).
- Débranchez tout ce qui n’est pas nécessaire : disques supplémentaires, lecteurs de cartes, disques externes, dongles. Laissez un disque cible et la clé d’installation. Moins de bus, moins de surprises.
- Testez la même clé USB sur une autre machine. Si elle cale aussi, la médias est suspecte. Si elle fonctionne ailleurs, concentrez-vous sur le chemin de stockage de la machine cible.
Deuxième étape : confirmez la visibilité et le mode du stockage
- Vérifiez le mode de stockage dans le BIOS/UEFI : AHCI vs RAID/Intel RST vs RAID constructeur. Si vous n’avez pas besoin de RAID, mettez AHCI pour un chemin de pilote le plus simple.
- Vérifiez que le disque cible est vu dans le firmware et a une santé raisonnable (si possible). Si le firmware le voit de façon intermittente, Windows Setup ne le réparera pas magiquement.
- Déconnectez les adaptateurs NVMe/riser cards et testez une connexion directe quand vous le pouvez. Les problèmes d’intégrité du signal adorent apparaître au pire moment.
Troisième étape : collectez les logs de l’installeur immédiatement
- À l’écran bloqué, appuyez sur Shift+F10 pour ouvrir un invite de commandes.
- Récupérez les logs depuis
X:\Windows\PantheretX:\$WINDOWS.~BT\Sources\Panther(chemins variables). Cherchez des réinitialisations de stockage/timeouts, des échecs de chargement de pilote, et des problèmes d’énumération de disque.
Quatrième étape : changez une variable qui compte
- Injectez le bon pilote de stockage (Intel RST/VMD, RAID HBA, pilote NVMe du constructeur si applicable). Si vous voyez « no drives found » ou des timeouts répétés, les pilotes ne sont pas optionnels.
- Mettez à jour le firmware (UEFI/BIOS + firmware SSD). Si Setup est bloqué à 0% parce que le disque tombe du bus, vous déboguez la physique, pas Windows.
C’est le playbook. Tout le reste est du détail—important, mais du détail.
Ce que signifie réellement « 0% »
« 0% » n’est pas une mesure précise. C’est un jalon UI. Windows Setup est une pipeline multi-étapes : boot dans WinPE, chargement des pilotes, énumération des disques, staging de l’image d’installation, création des partitions, application du WIM, configuration du boot, puis reboot dans le nouvel OS. Selon la version et la phase UI, la barre de progression peut ne pas bouger avant plusieurs étapes lourdes—surtout la découverte des disques, le partitionnement et le premier segment d’application d’image.
Donc quand vous voyez 0% longtemps, vous êtes typiquement dans l’un de ces modes d’échec :
- L’énumération des disques boucle (mismatch pilote/contrôleur, bus instable, bug firmware).
- Les E/S vers le disque cible font des timeouts (réinitialisations NVMe, resets de lien SATA, drame du firmware RAID).
- Le média d’installation est lent ou défaillant (clé USB défectueuse, port défaillant, hub bizarre, écriture ISO ratée).
- L’UEFI/partitionnement est bloqué (entrées de boot conflictuelles, GPT/MBR corrompu, métadonnées RAID résiduelles).
- Instabilité mémoire ou CPU (rare, mais ça arrive : profils XMP instables et RAM marginale peuvent ressembler à « setup bloqué »).
Mais celle qui se cache le mieux—parce qu’elle ne renvoie pas toujours une erreur lisible—est le blocage des E/S de stockage à la frontière du contrôleur.
La cause cachée que personne ne vérifie : réinitialisations précoces du stockage et blocages I/O
Voici la vérité inconfortable : Windows Setup est souvent la première fois qu’un système effectue des E/S soutenues et réalistes sur un disque neuf sous une pile de pilotes générique. Cette combinaison—écritures lourdes, changements de profondeur de file d’attente, transitions de gestion d’énergie, et un pilote qui veut être universel—expose les cas limites. Le résultat est un « bloqué à 0% » qui n’est pas bloqué. Il attend des E/S qui ne se terminent jamais.
Ce à quoi ça ressemble sous le capot
Dans les logs, vous verrez des variantes de :
- Réinitialisations de contrôleur/port (réinitialisations de lien SATA, resets de contrôleur NVMe).
- Ré-énumération répétée du disque (le disque disparaît, revient avec un chemin différent).
- Timeouts lors de l’application de l’image (blocages d’écriture, retries).
- Échecs de chargement de pilote ou fallback vers un pilote générique qui « fonctionne » jusqu’au moment où il ne fonctionne plus.
Sur les plateformes modernes, cela apparaît souvent avec :
- Configurations Intel VMD / RST où le disque se trouve derrière une couche de virtualisation et nécessite le bon pilote pendant le setup.
- Disques NVMe grand public avec firmware ancien qui se comporte mal sous les paramètres de gestion d’énergie par défaut de WinPE.
- Adaptateurs USB-vers-SATA utilisés comme disques cibles (non recommandés), qui se comportent bien sous Windows mais s’effondrent dans WinPE.
- HBA RAID dont le firmware est correct pour les volumes de données mais capricieux pendant l’installation sans pilotes constructeurs.
Et oui, parfois la « cause cachée » est presque insultante de banalité : le disque est en train de mourir. Setup est la première charge qui demande au disque d’écrire des gigaoctets en continu. Une map NAND marginale ou un contrôleur qui est déjà en fin de vie montrera son jeu.
Une petite blague, parce qu’on en a tous besoin : Une barre de progression à 0% c’est la façon qu’a Windows de dire « je fais des choses, mais je ne veux pas en parler. »
Pourquoi les gens le manquent
Parce que l’UI ne dit pas « votre NVMe vient de se réinitialiser trois fois. » Elle dit « 0% ». Si vous ne récupérez pas les logs, vous devinez. Et deviner, c’est ainsi que le downtime devient « mystérieux ».
Faits intéressants et contexte historique
Voici quelques éléments concrets de contexte qui expliquent pourquoi ce problème continue d’apparaître sous de nouvelles formes :
- Windows Setup tourne sur WinPE, un environnement minimal avec un ensemble de pilotes sélectionnés ; ce n’est pas votre installation Windows entièrement patchée.
- Le déploiement basé sur WIM (appliquer l’image, puis spécialiser) est central à l’installation Windows depuis des années ; l’UI « copie des fichiers » masque souvent un large pipeline de décompression/écriture.
- AHCI est devenu la baseline pour SATA, mais les OEM ont continué à livrer avec RAID/RST activés par défaut pour supporter le caching et des fonctionnalités entreprise.
- NVMe a changé les signatures de panne : au lieu de pertes de lien SATA évidentes, vous pouvez obtenir des resets de contrôleur qui ressemblent à des blocages momentanés puis « continuent », jusqu’à ce qu’ils ne continuent plus.
- UEFI a remplacé les hypothèses BIOS : GPT, partitions système EFI et entrées de boot NVRAM ajoutent de nouveaux endroits où un état résiduel peut bloquer le progrès.
- La compatibilité USB 3.x a été un pain récurrent sur plusieurs générations de Windows ; l’installeur peut booter correctement puis rencontrer des problèmes de débit/compatibilité lors de lectures soutenues.
- Les piles stockage fournisseur comptent : Intel RST/VMD, AMD RAID et les pilotes HBA ne sont souvent pas inclus dans de vieux médias d’installation.
- Les exigences Secure Boot et TPM (surtout à l’ère Windows 11) ont poussé plus de systèmes vers des configurations de firmware « modernes » où la correction pilote/firmware est non négociable.
- Le chiffrement disque et les fonctionnalités Opal peuvent compliquer les installations quand les disques sont verrouillés ou ont des métadonnées de sécurité résiduelles.
Trois micro-histoires en entreprise depuis le terrain
Micro-histoire n°1 : L’incident causé par une mauvaise hypothèse
Une entreprise de taille moyenne a déployé un nouveau modèle de laptop pour un service qui vit dans des feuilles de calcul et des visioconférences. Rien d’extraordinaire. L’image était « standard », la clé USB d’installation « connue bonne », et les techniciens avaient fait ça des centaines de fois.
La moitié des appareils restaient bloqués à 0% pendant Windows Setup. Même ISO, même workflow, résultats différents. La première hypothèse était évidente : lot de clés USB défectueuses. Ils ont changé de clés. Toujours bloqué. Puis ils ont pensé que c’était « Windows 11 trop lourd ». Ils ont laissé tourner toute la nuit. Toujours bloqué.
Quelqu’un a finalement ouvert les logs avec Shift+F10 et a remarqué des réinitialisations répétées du contrôleur de stockage et des disques manquants lors de l’énumération. La variable cachée était un réglage firmware : ces laptops sortaient avec Intel VMD activé par défaut. L’installateur pouvait booter, mais il n’avait pas le bon pilote VMD pour cette génération de plateforme.
Une fois le bon pilote de stockage chargé (et, dans certains cas, VMD désactivé pour les appareils qui n’en avaient pas besoin), les installations se sont déroulées normalement. La mauvaise hypothèse n’était pas une incompétence technique ; c’était la croyance que « si ça boot, le stockage doit être OK ». Sur du matériel 2026, booter ne prouve presque rien.
Micro-histoire n°2 : L’optimisation qui a foiré
Une autre organisation avait un processus « clean-room » : toujours utiliser les ports les plus rapides, toujours des clés USB 3.2 récentes, toujours activer « fast boot » dans le firmware pour réduire le temps jusqu’au desktop. L’objectif était la vitesse. La métrique était appareils par heure. L’ambiance était « nous sommes des pros ».
Puis Windows Setup a commencé à rester coincé à 0% sur un sous-ensemble de desktops. Pas tous. Seulement ceux avec un certain design d’en-tête USB frontal. L’installeur bootait de façon fiable, mais une fois en phase « copy/apply image », le débit de lecture s’effondrait puis le processus plantait. Parfois ça revenait, parfois ça bloquait.
L’« optimisation » était l’utilisation des ports USB frontaux 3.x via un hub interne et câblage plus long. Sous une charge de lecture soutenue dans WinPE, le bus négociait vers le bas ou corrigeait les erreurs jusqu’à l’épuisement. Passer à un port arrière de la carte mère—ou forcer USB 2.0—a fait disparaître le problème. Ils ont perdu quelques minutes par machine et économisé des heures de reprise.
Ils ont aussi appris une leçon cruelle : une configuration peut être « rapide » jusqu’au moment précis où elle ne l’est plus. Setup a besoin de stabilité ennuyeuse plus que de débit de pointe.
Micro-histoire n°3 : La pratique ennuyeuse mais correcte qui a sauvé la situation
Une entreprise globale avec une petite équipe SRE (oui, SRE pour postes clients ; ça existe quand on est grand) avait une politique : chaque échec de déploiement ouvre un ticket avec les logs attachés. Pas d’impressions, pas de suppositions. Des logs.
Une semaine, un nouveau lot de SSD a commencé à provoquer des blocages Windows Setup à 0%. Les techniciens n’ont pas discuté de la barre de progression. Ils ont extrait les logs Panther, noté des timeouts I/O disque, et corrélé par lot matériel. Puis ils ont testé le même modèle de SSD avec une révision de firmware différente. Les timeouts ont disparu.
La « pratique ennuyeuse » était le contrôle de version pour le firmware : ils suivaient les versions BIOS et firmware SSD comme ils suivaient le logiciel. Ça leur a permis d’identifier la panne à une révision de firmware précise et d’obtenir du fournisseur un package mis à jour. En attendant, ils ont atténué le problème en échangeant les SSD ou en mettant à jour le firmware avant d’imager.
Ce processus n’avait rien d’héroïque. C’était juste de la discipline. La récompense fut de ne pas avoir une « panne mystérieuse » au milieu d’une vague de déploiement.
Tâches pratiques : commandes, sorties et décisions
Tout ce qui suit est conçu pour être exécuté depuis Windows Setup en appuyant sur Shift+F10 (invite de commandes WinPE). Certaines tâches utilisent PowerShell ; si ce n’est pas disponible dans votre build WinPE, utilisez les alternatives cmd fournies. Chaque tâche inclut : commande, sortie exemple, ce que ça signifie, et la décision que vous prenez.
Task 1: Confirm you’re in WinPE and capture basic context
cr0x@server:~$ ver
Microsoft Windows [Version 10.0.22621.1]
Meaning: This is the WinPE/Setup environment version, not necessarily the final OS version.
Decision: If you’re installing a very new Windows build on very new hardware but your WinPE is old, expect missing drivers. Use newer install media.
Task 2: Check whether disks are detected at all (DiskPart)
cr0x@server:~$ diskpart
Microsoft DiskPart version 10.0.22621.1
DISKPART> list disk
Disk ### Status Size Free Dyn Gpt
-------- ------------- ------- ------- --- ---
Disk 0 Online 953 GB 953 GB *
Disk 1 Online 115 GB 1024 KB *
Meaning: Setup sees two disks. Often Disk 1 is your USB installer and Disk 0 is the internal SSD, but verify by size.
Decision: If list disk shows no disks or the internal disk is missing, stop blaming Windows. You have a controller/driver/firmware path problem.
Task 3: Identify which disk is the USB installer vs target disk
cr0x@server:~$ diskpart
DISKPART> select disk 0
Disk 0 is now the selected disk.
DISKPART> detail disk
Samsung SSD 990 PRO 1TB
Disk ID: {…}
Type : NVMe
Status : Online
Meaning: You’ve confirmed the model and bus type.
Decision: If the disk type or model looks wrong (e.g., “USB” for what you thought was NVMe), you may be installing to the wrong target or behind an adapter you forgot about.
Task 4: Check for leftover RAID metadata or weird partitioning that can stall setup
cr0x@server:~$ diskpart
DISKPART> select disk 0
DISKPART> list partition
Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 Reserved 16 MB 1024 KB
Partition 2 Primary 953 GB 17 MB
Meaning: This disk already has partitions. That’s not inherently bad, but it can complicate “upgrade” vs “clean” flows.
Decision: For stubborn installs, wipe and recreate partitions (after confirming data is not needed). If this is a corporate rebuild, you usually want clean.
Task 5: Do a clean wipe of the target disk (only when you mean it)
cr0x@server:~$ diskpart
DISKPART> select disk 0
DISKPART> clean
DiskPart succeeded in cleaning the disk.
Meaning: Partition table is removed. This often clears stale GPT, old boot entries, and leftover RAID signatures (not always all metadata, but often enough).
Decision: If Setup proceeds after clean, your earlier hang was likely partitioning/boot metadata weirdness, not “slow copying.”
Task 6: Check the storage controller drivers currently loaded
cr0x@server:~$ drvload
Drvload: Enumerating driver packages...
Drvload: No driver packages found.
Meaning: This example shows no additional drivers loaded manually. WinPE still has in-box drivers, but not necessarily the right vendor one.
Decision: If disks are missing or flaky, you probably need to load the vendor driver from a USB folder (RST/VMD/RAID/NVMe).
Task 7: Load a storage driver manually (RST/VMD/RAID)
cr0x@server:~$ drvload D:\Drivers\VMD\f6flpy-x64\iaStorVD.inf
Drvload: Successfully loaded D:\Drivers\VMD\f6flpy-x64\iaStorVD.inf
Meaning: The driver is now loaded into WinPE.
Decision: Re-run DiskPart list disk. If the internal disk appears, your 0% stall was driver/controller mismatch. Continue install with the right driver integrated.
Task 8: Inspect Setup logs for storage resets and “stuck at 0%” clues
cr0x@server:~$ type X:\Windows\Panther\setupact.log | findstr /i "error fail stor nvme iaStor reset timeout"
2026-02-04 10:21:33, Error SP Failed to enumerate disks. Error: 0x0000000e
2026-02-04 10:21:34, Info SP Storage: controller reset detected
2026-02-04 10:21:40, Warning SP NVMe: command timeout, retrying
Meaning: This is the money trail. Enumeration failures and timeouts explain why the UI never advances.
Decision: If you see resets/timeouts, treat it as a storage stability issue: update BIOS/SSD firmware, change controller mode, load correct driver, or swap hardware.
Task 9: Pull additional logs from the $WINDOWS.~BT staging area (when present)
cr0x@server:~$ dir X:\$WINDOWS.~BT\Sources\Panther
Volume in drive X has no label.
Directory of X:\$WINDOWS.~BT\Sources\Panther
02/04/2026 10:19 AM <DIR> .
02/04/2026 10:19 AM <DIR> ..
02/04/2026 10:21 AM 842,113 setuperr.log
02/04/2026 10:21 AM 6,201,004 setupact.log
Meaning: The installer has created a staging directory; logs here can be richer than the base Panther path.
Decision: If these logs don’t exist, you might be hanging before staging—often during driver init or early disk discovery.
Task 10: Check whether the system is thrashing on memory or unstable
cr0x@server:~$ wmic computersystem get TotalPhysicalMemory
TotalPhysicalMemory
17179869184
Meaning: Confirms RAM is detected (here: 16 GiB).
Decision: If RAM is reported incorrectly or you suspect instability (random hangs, inconsistent behavior), disable XMP/overclocks in BIOS and re-test. Setup is a stability test pretending to be a wizard.
Task 11: Validate the install media drive letter and read speed symptoms
cr0x@server:~$ dir D:\
Volume in drive D is ESD-USB
Directory of D:\
02/04/2026 09:58 AM <DIR> boot
02/04/2026 09:58 AM <DIR> efi
02/04/2026 09:58 AM <DIR> sources
Meaning: You’ve found the install media (commonly D: in WinPE, but not always).
Decision: If dir is slow, errors, or hangs, your USB path is suspect. Move to a rear port, avoid hubs, try a different stick, or rebuild the media.
Task 12: Check the target disk for obvious SMART/health signals (limited in WinPE)
cr0x@server:~$ wmic diskdrive get Model,Status,InterfaceType
InterfaceType Model Status
NVMe Samsung SSD 990 PRO 1TB OK
USB Generic Flash Disk OK
Meaning: WMIC gives a coarse “OK” or “Pred Fail” style status; it’s not a full SMART dump.
Decision: If status is not OK or the model is missing/garbled, treat the disk or controller as unreliable. Swap hardware or update firmware before you waste time.
Task 13: Confirm UEFI vs Legacy boot mode from WinPE
cr0x@server:~$ reg query HKLM\System\CurrentControlSet\Control /v PEFirmwareType
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control
PEFirmwareType REG_DWORD 0x2
Meaning: 0x2 typically indicates UEFI; 0x1 indicates BIOS/Legacy.
Decision: If you intended UEFI but you’re in Legacy mode (or vice versa), stop. Boot mode mismatch causes partitioning confusion and bootloader failures that look like “setup stuck.” Fix boot mode first.
Task 14: Check whether BitLocker or encryption metadata might be complicating disk access
cr0x@server:~$ manage-bde -status
BitLocker Drive Encryption: Configuration Tool version 10.0.22621
ERROR: The system drive is not encrypted.
Meaning: In this case, no BitLocker on the current WinPE environment (expected). On real systems, data drives may still have BitLocker metadata.
Decision: If you’re reinstalling over an encrypted volume, consider wiping partitions. Don’t try to “repair install” your way through a locked disk situation.
Task 15: Export logs to USB so you can read them on another machine
cr0x@server:~$ md D:\setup-logs
cr0x@server:~$ xcopy X:\Windows\Panther D:\setup-logs\Panther /e /i /y
X:\Windows\Panther\setupact.log
X:\Windows\Panther\setuperr.log
2 File(s) copied
Meaning: You’ve captured logs for offline analysis.
Decision: If you’re in a corporate environment, attach these logs to the ticket. If you’re solo, read them on a working machine and search within them for storage-related keywords.
Task 16: Verify WinPE can write to the target disk (quick sanity test)
cr0x@server:~$ diskpart
DISKPART> select disk 0
DISKPART> create partition primary size=1024
DiskPart succeeded in creating the specified partition.
DISKPART> format fs=ntfs quick
100 percent completed
DiskPart successfully formatted the volume.
Meaning: Basic create/format operations succeeded. This doesn’t guarantee sustained write stability, but it’s a strong signal.
Decision: If this fails, your target storage path is not healthy enough for OS install. Fix hardware/firmware/driver before trying again.
Deuxième petite blague (et voilà vos deux alloties) : DiskPart a deux modes : obéissant et « Vous êtes sûr d’avoir voulu faire ça ? »
Erreurs courantes (symptômes → cause racine → correction)
Cette section est volontairement spécifique. Si vous voulez des conseils génériques, demandez à un moteur de recherche. Si vous voulez réparer la machine, faites correspondre les symptômes aux causes.
1) Symptom: Setup UI stuck at 0%, disk LED flickers occasionally
- Root cause: Repeated NVMe timeouts/resets under WinPE driver/power defaults; sometimes triggered by older SSD firmware.
- Fix: Update SSD firmware and BIOS/UEFI. Try a newer Windows installer build. If on a laptop, ensure AC power. If behind VMD/RST, load correct driver or disable VMD.
2) Symptom: No disks shown in “Where do you want to install Windows?”
- Root cause: Storage controller requires vendor driver (Intel VMD/RST, AMD RAID, HBA RAID).
- Fix: Load the controller driver via
Load driverUI ordrvload. Alternatively, switch BIOS storage mode to AHCI if RAID features aren’t needed.
3) Symptom: Works on one USB port but not another
- Root cause: Front-panel port/hub instability; USB 3.x controller quirks in WinPE; insufficient power on certain ports.
- Fix: Use rear motherboard ports. Avoid hubs. Try USB 2.0 port. Recreate the installer on a different brand stick.
4) Symptom: Setup restarts or hangs randomly; logs show different disk IDs between boots
- Root cause: Flaky cable/backplane; marginal NVMe adapter; power delivery instability; controller firmware bug.
- Fix: Reseat drive, swap SATA cable/port, remove risers/adapters, update firmware, test with a known-good drive.
5) Symptom: “Copying files” never begins; 0% forever; CPU mostly idle
- Root cause: Setup blocked before image application—often on disk enumeration or partitioning step.
- Fix: Open Shift+F10, run DiskPart
list disk. If disks missing: driver/controller issue. If disks present: wipe partitions and retry, and read Panther logs.
6) Symptom: Disk shows up, but formatting or partition creation fails
- Root cause: Disk is write-protected (rare), failing media, or controller translation layer issue (USB-SATA bridge, RAID mode confusion).
- Fix: Use DiskPart
attributes diskandclean. If still failing, swap disk or bypass the adapter/bridge/RAID layer.
7) Symptom: Setup only hangs when other drives are attached
- Root cause: Setup chooses the wrong disk for boot files, or gets confused by stale boot partitions/ESP on another drive.
- Fix: Disconnect all non-target drives during install. After successful install, reconnect and fix boot order.
8) Symptom: Setup proceeds after disabling “Fast Boot” in BIOS
- Root cause: Fast Boot skips device init; some controllers don’t fully reinitialize for WinPE in a clean state.
- Fix: Disable Fast Boot for installs and troubleshooting. Re-enable after the OS is stable if you must.
Checklists / plan étape par étape
Checklist A: The 15-minute “stop wasting time” plan
- Débranchez tous les périphériques et disques supplémentaires (laissez le disque cible + la clé USB d’installation seulement).
- Déplacez la clé USB d’installation vers un port arrière de la carte mère ; évitez les hubs/panneaux frontaux.
- Booter l’installeur, attendre l’écran bloqué, appuyer sur Shift+F10.
- Exécuter DiskPart
list disk. Si le disque cible est absent : passez aux étapes mode/driver stockage. - Vérifier le mode stockage dans le BIOS : préférer AHCI sauf si vous avez besoin de RAID/VMD.
- Si vous devez utiliser VMD/RST/RAID : chargez le bon pilote (
drvload) et confirmez l’apparition du disque. - Lire
setupact.logpour les chaînes « timeout/reset/enumerate ». - Si le disque est présent mais que l’installation bloque toujours :
cleanle disque et retenter.
Checklist B: The “hardware truth serum” plan (for repeated 0% stalls)
- Mettre à jour le BIOS/UEFI vers une release stable connue (pas nécessairement la dernière beta).
- Mettre à jour le firmware SSD avec les outils du fournisseur (faites-le avant la réinstallation si possible).
- Désactiver overclocks/XMP temporairement. Stabilité d’abord, vanité après.
- Si SATA : changer le câble, changer de port, retirer splitters/backplanes.
- Si NVMe : reseater le disque, tester sans risers/adapters, essayer un autre emplacement M.2.
- Essayer un autre disque cible (known-good). Si le problème disparaît, arrêtez de débattre et remplacez l’unité défectueuse.
Checklist C: The “corporate repeatability” plan
- Standardiser la version de l’installeur (même build Windows, même jeu de pilotes WinPE).
- Maintenir un pack de pilotes par modèle matériel (surtout stockage et chipset).
- Suivre les versions BIOS/firmware SSD comme partie de votre dossier de build.
- Exiger les logs attachés aux échecs (logs Panther au minimum).
- Garder au moins une « machine de référence » par modèle pour reproduire les problèmes.
Une citation d’ingénierie (idée paraphrasée)
Idée paraphrasée, attribuée à W. Edwards Deming : « Sans données, vous n’êtes qu’une autre personne avec une opinion. »
Dans ce contexte, « données » signifie les logs Panther, les résultats d’énumération disque et le mode du contrôleur. Pas l’impression que renvoie la barre à 0%.
FAQ
Pourquoi Windows Setup affiche-t-il 0% si longtemps ?
Parce que l’UI de progression ne commence pas à compter avant certaines étapes. L’énumération des disques, l’initialisation des pilotes et le partitionnement peuvent se produire avant que la barre ne bouge.
Est-il normal que Windows 11 prenne plus de temps à 0% que Windows 10 ?
Parfois, mais « normal » signifie des minutes, pas des heures. Si vous êtes bloqué assez longtemps pour remettre en question vos choix de vie, vous avez probablement des problèmes I/O ou pilote.
Comment ouvrir les logs si l’installeur est bloqué ?
Appuyez sur Shift+F10, puis inspectez X:\Windows\Panther\setupact.log et setuperr.log. Recherchez « timeout », « reset », « enumerate », « nvme », « stor », et le nom de votre pilote de contrôleur.
Mon disque n’apparaît pas. Quelle est la correction la plus probable ?
Chargez le pilote du contrôleur de stockage correct (Intel RST/VMD, AMD RAID ou pilote HBA RAID). Si vous n’avez pas besoin de RAID, passer en AHCI est souvent la voie la plus simple.
Dois-je désactiver Intel VMD pour installer Windows ?
Si vous n’avez pas besoin des fonctionnalités VMD, oui—désactivez et utilisez AHCI pour la simplicité. Si vous en avez besoin (certaines builds corporate, RAID, fonctionnalités de gestion spécifiques), laissez-le activé mais fournissez le bon pilote VMD pendant le setup.
Le « clean » dans DiskPart corrige-t-il les blocages à 0% ?
Il corrige un nombre surprenant de cas, car il supprime les tables de partition et métadonnées de boot conflictuelles. Il ne réparera pas un disque qui se réinitialise ou un pilote manquant.
Une clé USB défectueuse peut-elle vraiment causer un blocage à 0% ?
Absolument. WinPE peut booter depuis une clé marginale puis caler lors de lectures soutenues. Changez de clé, de port, et évitez les hubs.
Si DiskPart montre le disque, mais Setup bloque toujours, que faire ?
Alors la visibilité n’est pas le problème—c’est la stabilité. Vérifiez les logs pour des timeouts/réinitialisations, mettez à jour BIOS/firmware SSD, et envisagez d’échanger le disque cible pour prouver ou infirmer un problème matériel.
L’instabilité RAM est-elle une cause réaliste ?
Oui, surtout sur des desktops avec profils XMP agressifs. Désactivez XMP/overclocks et relancez l’installation. Si ça marche, vous venez de diagnostiquer que les réglages « benchmark » sont la source de la panne.
Pourquoi débrancher les autres disques aide-t-il ?
Windows Setup place parfois des fichiers de boot sur un autre disque que celui où vous installez, surtout si un autre disque a déjà une partition système EFI. Retirer les autres disques empêche Setup d’être « créatif ».
Conclusion : prochaines étapes qui fonctionnent
Si Windows Setup est bloqué à 0%, traitez-le comme un incident avec une dépendance critique unique : des E/S de stockage fiables. La cause cachée n’est pas mystique. C’est généralement un mismatch de mode contrôleur, un pilote manquant, un bug de firmware, ou un disque qui faillit silencieusement sous des écritures soutenues.
Faites ceci ensuite :
- Appliquez le playbook de diagnostic rapide : simplifiez le matériel, confirmez la visibilité du disque, récupérez les logs.
- Si les disques sont absents : corrigez le mode contrôleur ou chargez le bon pilote—ne répétez pas inutilement.
- Si les logs montrent des réinitialisations/timeouts : mettez à jour BIOS et firmware SSD, et prouvez la stabilité avec un disque known-good.
- Une fois corrigé, rendez cela répétable : standardisez les médias et suivez les versions de firmware comme vous suivez le logiciel.
Les barres de progression ne sont pas de la télémétrie. Vos logs le sont. Déboguez avec des preuves, et 0% cesse d’être un mystère pour devenir juste un ticket résolu.