Créer une clé USB bootable avec PowerShell (sans outils GUI)

Règles de base (ce que nous construisons et pourquoi)

Une « clé USB bootable » n’est pas magique. C’est une clé USB avec une table de partitions, un système de fichiers lisible par le firmware,
et des fichiers de démarrage placés là où le firmware les attend. Sur le matériel moderne, cela signifie généralement un firmware UEFI
recherchant \EFI\BOOT\BOOTX64.EFI sur un système de fichiers FAT32.

Quand vous utilisez des outils graphiques, ils prennent silencieusement des décisions pour vous : GPT vs MBR, FAT32 vs NTFS,
créer une ou deux partitions, écrire une image brute ou copier des fichiers.
Ces décisions peuvent être correctes pour une machine et mauvaises pour la suivante.
PowerShell vous permet de décider délibérément, et—tout aussi important—de consigner ce que vous avez fait.

Notre cible par défaut dans cet article : une ISO d’installation Windows (Windows 10/11, Server) écrite sur USB
de manière à démarrer sur des systèmes UEFI. Nous couvrirons aussi le BIOS/CSM et le piège classique :
les ISO Windows contiennent souvent un fichier > 4 Go, que FAT32 ne peut pas stocker.

Position d’opinion : pour une compatibilité large, créez une clé USB bootable UEFI avec FAT32 et gérez proprement le problème du fichier de 4 Go.
Évitez les astuces ingénieuses jusqu’à ce que vous ayez validé la méthode simple.

Faits intéressants et courtes leçons historiques

• El Torito (années 1990) est la norme de démarrage des CD-ROM qui a rendu les médias d’installation bootables courants. Le démarrage USB a ensuite repris le modèle « faire comme un disque ».
• Le chemin média amovible d’UEFI (\EFI\BOOT\BOOTX64.EFI) existe spécifiquement pour qu’une clé USB puisse démarrer sans entrées NVRAM.
• FAT32 n’est pas « obsolète », il est « ami du firmware ». La spécification UEFI exige que le firmware sache lire FAT, d’où la pertinence continue de FAT32 en 2026.
• Le support NTFS dans le firmware n’est pas garanti. Certains fournisseurs l’implémentent, beaucoup ne le font pas, et certains le font mal.
• GPT sur les lecteurs amovibles était autrefois un champ de mines ; de nombreux systèmes de l’ère BIOS ne comprenaient que MBR. UEFI a rendu GPT normal.
• Les médias d’installation Windows ont évolué de install.wim parfois vers install.esd pour réduire la taille ; les images d’entreprise utilisent encore souvent de gros WIM.
• Secure Boot a durci les règles : les chargeurs doivent être signés (ou la plateforme en Setup Mode). Votre USB peut être parfait et pourtant « ne pas démarrer » à cause des politiques.
• Les premiers démarrages USB étaient instables car les fournisseurs BIOS traitaient le stockage de masse USB comme une priorité secondaire. Un peu de cet ADN réapparaît encore dans des menus de démarrage étranges.

Blague n°1 : UEFI, c’est comme l’art moderne—certaines personnes insistent que c’est beau, et tout le monde d’autre veut juste que la porte s’ouvre.

Mode d’action pour diagnostic rapide (trouver le goulot vite)

Première chose : la machine tente-t-elle vraiment de démarrer sur la bonne cible ?

• Vérifiez l’entrée du menu de démarrage : est-ce l’entrée « UEFI : USB » ou la version legacy/CSM ?
• Si Secure Boot est activé, confirmez que l’ISO est une distribution Microsoft officielle ou signée de manière appropriée.
• Si c’est une VM ou un KVM distant, confirmez que la « redirection USB » ne présente pas le périphérique comme un lecteur CD-ROM ou une émulation étrange.

Deuxième chose : l’USB est-il formaté d’une façon lisible par le firmware ?

• Pour UEFI, la partition contenant \EFI doit en général être en FAT32.
• Vérifiez que vous n’avez pas créé par erreur de l’exFAT (Windows l’aime ; le firmware souvent pas).
• Confirmez que la partition est présente et possède une lettre quand elle est attachée à Windows.

Troisième chose : les fichiers de démarrage requis existent-ils au chemin attendu ?

• Sur l’USB, vérifiez que \EFI\BOOT\BOOTX64.EFI existe pour les systèmes UEFI x64.
• Pour le BIOS, vérifiez qu’il y a un secteur de démarrage approprié et les fichiers du chargeur pertinents (varie selon l’ISO).
• Ne devinez pas. Listez les répertoires et validez les chemins.

Quatrième chose : la taille des fichiers casse-t-elle FAT32 ?

• Si l’ISO contient \sources\install.wim > 4 Go, la copie simple vers FAT32 échouera ou omettra silencieusement des fichiers selon votre processus.
• Corrigez en splittant le WIM ou en utilisant une approche à deux partitions (FAT32 + NTFS) si nécessaire.

Cinquième chose : le média lui-même est-il mauvais ?

• Oui, même des clés « neuves » peuvent échouer. Testez lecture/écriture, reformatez, essayez un autre port (surtout les ports USB 3 en façade sur les anciennes cartes).
• Si vous ne pouvez pas reproduire le problème avec une autre clé, arrêtez de discuter avec la physique et remplacez-la.

Prérequis et vérifications de sécurité (ne pas nuke le mauvais disque)

Vous vous apprêtez à exécuter des commandes qui peuvent effacer des disques instantanément. La seule protection fiable est votre propre discipline.
Si vous êtes sur un portable avec un SSD USB externe connecté et que vous « clean » le mauvais disque, vous allez découvrir de nouvelles émotions.

Ce dont vous avez besoin

• Windows 10/11 ou Windows Server avec PowerShell et droits administrateur.
• Une clé USB (8 Go minimum ; 16+ Go est plus confortable).
• Un fichier ISO Windows accessible localement.

Tâche 1 : identifier les disques et confirmer l’USB par taille et type de bus

cr0x@server:~$ powershell -NoProfile -Command "Get-Disk | Sort-Object Number | Format-Table Number,FriendlyName,BusType,Size,PartitionStyle -Auto"
Number FriendlyName              BusType    Size PartitionStyle
------ ------------              -------    ---- --------------
0      NVMe Samsung SSD 980      NVMe   1000204886016 GPT
1      SanDisk Ultra USB 3.0     USB       16008609792 RAW

Ce que cela signifie : Le disque 1 est une clé USB de 16 Go, actuellement RAW (sans table de partitions).

Décision : Le disque 1 est la cible. Si votre USB apparaît différemment (par ex. « SATA »), arrêtez et investiguez—certains docks mentent.

Tâche 2 : vérification de santé des volumes (évitez d’effacer le mauvais)

cr0x@server:~$ powershell -NoProfile -Command "Get-Volume | Sort-Object DriveLetter | Format-Table DriveLetter,FileSystemLabel,FileSystem,SizeRemaining,Size -Auto"
DriveLetter FileSystemLabel FileSystem SizeRemaining        Size
---------- -------------- ---------- -------------        ----
C          Windows        NTFS        215.73 GB       930.89 GB
E          BACKUP         NTFS        120.11 GB       465.76 GB

Ce que cela signifie : Votre USB peut ne pas encore avoir de lettre, ce qui est normal.

Décision : Si l’USB a déjà une lettre et contient quelque chose d’important, copiez-le maintenant. Nous allons l’effacer.

Tâche 3 : confirmer que l’ISO existe et n’est pas un téléchargement incomplet

cr0x@server:~$ powershell -NoProfile -Command "$iso='C:\ISO\Win11_23H2_English_x64.iso'; Get-Item $iso | Format-List Name,Length,LastWriteTime"
Name          : Win11_23H2_English_x64.iso
Length        : 6640211968
LastWriteTime : 01/10/2026 14:21:53

Ce que cela signifie : L’ISO existe et fait ~6,6 Go.

Décision : Si la taille est suspectement petite (quelques Mo), arrêtez—votre ISO n’est pas complète.

Méthode : ISO Windows → clé USB bootable (compatible UEFI)

Il y a deux façons basiques de créer une clé USB bootable :

1. Méthode par copie de fichiers : partitionner + formater l’USB, monter l’ISO, copier les fichiers. C’est ce que nous ferons.
2. Écriture d’image brute : écrire une image disque bit-à-bit. Les ISO Windows ne sont pas typiquement destinées à être écrites en brut sur USB comme c’est souvent le cas pour les ISO Linux.

Pour les médias d’installation Windows, la méthode par copie est prévisible et maintenable. Elle facilite aussi la gestion de la limite des 4 Go.

Tâche 4 : effacer et initialiser l’USB en GPT (priorité UEFI)

cr0x@server:~$ powershell -NoProfile -Command "$disk=1; Clear-Disk -Number $disk -RemoveData -Confirm:\$false; Initialize-Disk -Number $disk -PartitionStyle GPT; Get-Disk -Number $disk | Format-Table Number,PartitionStyle,Size -Auto"
Number PartitionStyle   Size
------ --------------   ----
1      GPT           14.91 GB

Ce que cela signifie : Le disque 1 est maintenant en GPT.

Décision : Si vous avez besoin que cette clé démarre sur des machines BIOS-only anciennes, envisagez MBR à la place. Pour la plupart des flottes modernes, GPT est le bon choix par défaut.

Tâche 5 : créer une partition FAT32 unique et lui assigner une lettre

cr0x@server:~$ powershell -NoProfile -Command "$disk=1; $p=New-Partition -DiskNumber $disk -UseMaximumSize -AssignDriveLetter; Format-Volume -Partition $p -FileSystem FAT32 -NewFileSystemLabel 'WINSTALL' -Confirm:\$false; Get-Volume -FileSystemLabel WINSTALL | Format-Table DriveLetter,FileSystem,Size,SizeRemaining -Auto"
DriveLetter FileSystem   Size SizeRemaining
---------- ----------   ---- -------------
F          FAT32     14.90 GB     14.85 GB

Ce que cela signifie : L’USB est maintenant en F: formaté en FAT32.

Décision : Notez la lettre de lecteur. Nous allons y copier le contenu de l’ISO.

Tâche 6 : monter l’ISO et trouver sa lettre de lecteur

cr0x@server:~$ powershell -NoProfile -Command "$iso='C:\ISO\Win11_23H2_English_x64.iso'; $img=Mount-DiskImage -ImagePath $iso -PassThru; ($img | Get-Volume) | Format-Table DriveLetter,FileSystemLabel,FileSystem -Auto"
DriveLetter FileSystemLabel FileSystem
---------- -------------- ----------
D          CCCOMA_X64FRE   UDF

Ce que cela signifie : L’ISO est montée en D: (système de fichiers UDF, comme attendu pour une image optique).

Décision : Nous copierons de D:\ vers F:\.

Tâche 7 : inspecter l’ISO pour les fichiers de démarrage UEFI avant la copie

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -Path 'D:\EFI\BOOT' | Select-Object Name,Length | Format-Table -Auto"
Name         Length
----         ------
BOOTX64.EFI  1528832

Ce que cela signifie : L’ISO contient le chargeur UEFI pour média amovible.

Décision : Bon signe. Si D:\EFI\BOOT\BOOTX64.EFI est absent, l’ISO pourrait ne pas être bootable en UEFI en l’état.

Tâche 8 : vérifier la bombe à retardement FAT32 (taille de install.wim)

cr0x@server:~$ powershell -NoProfile -Command "Get-Item 'D:\sources\install.wim' -ErrorAction SilentlyContinue | Format-List Name,Length"
Name   : install.wim
Length : 4875429312

Ce que cela signifie : install.wim fait ~4,8 Go. FAT32 ne peut pas stocker un fichier unique supérieur à 4 Go.

Décision : Ne copiez pas l’ISO à l’aveugle. Utilisez la méthode de séparation du WIM ci‑dessous.

Tâche 9 : copier tout sauf install.wim, puis scinder le WIM en parties SWM

L’approche propre : copier tous les fichiers en sautant le gros WIM, puis utiliser DISM pour le scinder en plusieurs fichiers .swm
qui tiennent chacun sous 4 Go. Windows Setup comprend automatiquement install.swm.

cr0x@server:~$ powershell -NoProfile -Command "robocopy D:\ F:\ /E /R:2 /W:1 /XF install.wim /XD 'System Volume Information' /NFL /NDL"
-------------------------------------------------------------------------------
   ROBOCOPY     ::     Robust File Copy for Windows
-------------------------------------------------------------------------------

  Started : Thursday, February 5, 2026 9:12:51 AM
   Source : D:\
     Dest : F:\

    Files : *.*

  Options : *.* /NFL /NDL /S /E /DCOPY:DA /COPY:DAT /R:2 /W:1

------------------------------------------------------------------------------

  Total    Copied   Skipped  Mismatch    FAILED    Extras
   Dirs :       62        62        0        0        0        0
  Files :      987       986        1        0        0        0
  Bytes :  5.92 g   1.36 g   4.56 g        0        0        0
  Times :   0:02:31   0:02:31                       0:00:00   0:00:00

  Ended : Thursday, February 5, 2026 9:15:22 AM

Ce que cela signifie : Un fichier a été sauté : install.wim. C’est intentionnel.

Décision : Maintenant générez les parties install.swm sur l’USB.

cr0x@server:~$ powershell -NoProfile -Command "dism /Split-Image /ImageFile:D:\sources\install.wim /SWMFile:F:\sources\install.swm /FileSize:3800"
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Splitting image: D:\sources\install.wim
[==========================100.0%==========================]
The operation completed successfully.

Ce que cela signifie : DISM a scindé le WIM en parties : install.swm, install2.swm, etc.

Décision : Confirmez que les fichiers existent et qu’ils sont chacun inférieurs à 4 Go.

Tâche 10 : valider les fichiers SWM et supprimer toute copie WIM accidentelle

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem 'F:\sources' -Filter 'install*.s*' | Select-Object Name,Length | Format-Table -Auto"
Name           Length
----           ------
install.swm    3984568320
install2.swm   3961206784

Ce que cela signifie : Les parties SWM existent et rentrent dans la limite de FAT32.

Décision : Assurez-vous que F:\sources\install.wim n’existe pas. Setup doit uniquement voir les parties SWM dans ce cas.

cr0x@server:~$ powershell -NoProfile -Command "Test-Path 'F:\sources\install.wim'"
False

Tâche 11 : démonter l’ISO proprement

cr0x@server:~$ powershell -NoProfile -Command "$iso='C:\ISO\Win11_23H2_English_x64.iso'; Dismount-DiskImage -ImagePath $iso"

Ce que cela signifie : L’ISO n’est plus montée.

Décision : Éjectez la clé en toute sécurité quand vous êtes prêt, mais vérifiez d’abord les fichiers et la structure de démarrage.

Blague n°2 : Une clé USB bootable n’est qu’un petit disque avec de grandes attentes—un peu comme ma première permanence d’astreinte.

Gérer install.wim supérieur à 4 Go (réalité FAT32)

La taille maximale d’un fichier unique sur FAT32 est 4 GiB moins 1 octet. Ce n’est pas négociable. Vous ne pouvez pas « forcer » cela.
Si vous essayez, vous obtiendrez une erreur de copie, ou pire : un outil qui prétend succès mais qui omet silencieusement le fichier.
Dans les deux cas, vous aurez une clé USB qui démarre mais échoue plus tard, au moment où Setup a besoin de l’image.

Option A (recommandée) : scinder le WIM en SWM

C’est ce que nous avons fait ci‑dessus. Cela préserve la compatibilité UEFI et garde l’USB simple : une partition, un système de fichiers, un ensemble d’attentes.
Cela rend aussi votre processus auditable—DISM affiche ce qu’il a fait.

Option B : deux partitions (boot FAT32 + payload NTFS)

Parfois vous distribuez une image personnalisée et vous ne voulez pas scinder. Un schéma courant :
partition FAT32 contenant \EFI et les fichiers de démarrage, plus une partition NTFS contenant le gros WIM.
Cela peut fonctionner, mais augmente la variance matérielle et le risque d’erreur humaine. Certains systèmes n’énumèrent que la première partition sur les médias amovibles.
Certains menus de démarrage se confondent. Des gens copient les mauvaises choses sur la mauvaise partition.

Si vous le faites quand même, gardez la partition FAT32 en premier, petite (1–2 Go), et vérifiez que votre matériel cible voit les deux partitions.
Pour l’installateur Windows en particulier, vous devez vous assurer que Setup peut accéder à la partition NTFS depuis WinPE démarré.
La plupart des builds WinPE modernes peuvent le faire, mais « la plupart » n’est pas une catégorie pour la gestion de changement.

Option C : convertir WIM en ESD (parfois)

Convertir WIM en ESD peut réduire la taille, mais ce n’est pas toujours adapté aux workflows d’imagerie d’entreprise.
Cela peut aussi affecter des scénarios de maintenance. Si vous ne savez pas déjà pourquoi vous voulez ESD, vous n’en avez probablement pas besoin.

Notes BIOS Legacy (quand vous êtes coincé en 2009)

Le démarrage BIOS legacy depuis USB est un autre monde : il attend des secteurs de démarrage et préfère souvent MBR.
Certaines ISO Windows incluent le support de démarrage BIOS ; certaines plates‑formes exigent une disposition de type « USB-HDD ».

Si vous devez supporter du matériel BIOS-only, envisagez d’initialiser l’USB en MBR plutôt qu’en GPT. Ceci dit, de nombreux environnements « supportent BIOS »
en politique alors que le matériel réel est UEFI depuis une décennie. Vérifiez avant de concevoir pour des fantômes.

Tâche 12 : initialiser l’USB en MBR (alternative compatible BIOS)

cr0x@server:~$ powershell -NoProfile -Command "$disk=1; Clear-Disk -Number $disk -RemoveData -Confirm:\$false; Initialize-Disk -Number $disk -PartitionStyle MBR; Get-Disk -Number $disk | Format-Table Number,PartitionStyle -Auto"
Number PartitionStyle
------ --------------
1      MBR

Ce que cela signifie : L’USB utilise désormais MBR.

Décision : Ne faites cela que si vous devez réellement supporter le BIOS. Sinon tenez‑vous-en à GPT pour des flottes UEFI-first.

Pour le démarrage BIOS, les partitions marquées « active » comptent encore dans certains cas. Les cmdlets de stockage PowerShell n’exposent pas proprement tous les drapeaux de l’ère BIOS.
Quand vous êtes profondément dans la compatibilité legacy, diskpart est parfois l’outil le moins pire. Si votre exigence est vraiment « PowerShell uniquement »,
vous pouvez toujours appeler diskpart depuis PowerShell. Ce n’est pas un outil GUI ; c’est juste un couteau tranchant.

Tâches de vérification (prouver qu’elle démarrera)

Instinct SRE : ne faites pas confiance aux messages de succès. Mesurez. Validez. Collectez des preuves que vous pourrez joindre à un ticket quand quelqu’un affirme
« la clé USB que vous avez faite ne marche pas » alors qu’il tente de démarrer par le réseau par erreur.

Tâche 13 : confirmer le système de fichiers et l’espace libre sur l’USB

cr0x@server:~$ powershell -NoProfile -Command "Get-Volume -DriveLetter F | Format-List DriveLetter,FileSystem,HealthStatus,Size,SizeRemaining"
DriveLetter   : F
FileSystem    : FAT32
HealthStatus  : Healthy
Size          : 16000143360
SizeRemaining : 8429182976

Ce que cela signifie : FAT32, sain, espace libre suffisant.

Décision : Si c’est exFAT ou NTFS et que vous attendez la compatibilité UEFI partout, corrigez‑le maintenant plutôt que de discuter plus tard avec le firmware.

Tâche 14 : vérifier que le chemin de démarrage média amovible existe sur l’USB

cr0x@server:~$ powershell -NoProfile -Command "Test-Path 'F:\EFI\BOOT\BOOTX64.EFI'"
True

Ce que cela signifie : Le fichier clé de démarrage UEFI existe.

Décision : Si False, votre copie n’a pas inclus les fichiers EFI (ou vous avez monté la mauvaise ISO). Recopiez et revérifiez.

Tâche 15 : valider que le répertoire \sources contient ce que Setup attend

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem 'F:\sources' | Select-Object -First 10 Name | Format-Table -Auto"
Name
----
acmigration.dll
background.bmp
boot.wim
compatresources.dll
diagerr.xml
diskpart.exe
etwproviders.dll
inf
install.swm
install2.swm

Ce que cela signifie : boot.wim existe et les parties SWM sont présentes.

Décision : Si boot.wim est manquant, l’USB peut démarrer sur rien ou échouer tôt.

Tâche 16 : confirmer que l’USB est lisible de bout en bout (contrôle de hachage rapide)

cr0x@server:~$ powershell -NoProfile -Command "Get-FileHash 'F:\EFI\BOOT\BOOTX64.EFI' -Algorithm SHA256 | Format-List Algorithm,Hash"
Algorithm : SHA256
Hash      : 4C5E9AB2D16B9F5D3B8C0CE4D8B6F26B1D9C3B7D8B7B7C3A9B0D2D4E9A5F0B1C

Ce que cela signifie : Le fichier est lisible et haché ; vous n’avez pas d’erreurs I/O immédiates.

Décision : Si le hachage génère des erreurs, la clé peut être défaillante. Remplacez‑la plutôt que de déboguer des fantômes.

Tâche 17 : confirmer que la disposition de partitions est bien celle attendue

cr0x@server:~$ powershell -NoProfile -Command "Get-Partition -DiskNumber 1 | Format-Table DiskNumber,PartitionNumber,DriveLetter,Size,GptType,MbrType -Auto"
DiskNumber PartitionNumber DriveLetter    Size GptType                               MbrType
---------- --------------- -----------    ---- -------                               ------
1          1               F           14.90 GB EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

Ce que cela signifie : Partition de données unique sur GPT (données basiques).

Décision : Pour le démarrage UEFI amovible, l’essentiel est FAT32 + chemin EFI. Le type de partition importe moins que le contenu,
mais des dispositions étranges peuvent confondre le firmware ancien.

Tâche 18 : vérification rapide de la taille des répertoires (avez‑vous réellement copié la majeure partie de l’ISO ?)

cr0x@server:~$ powershell -NoProfile -Command "(Get-ChildItem F:\ -Recurse -Force | Measure-Object -Property Length -Sum).Sum"
5123456789

Ce que cela signifie : Le total d’octets sur l’USB est une valeur multi‑gigaoctets plausible.

Décision : Si c’est minuscule (quelques centaines de Mo), vous n’avez pas copié correctement ou vous avez trop exclu.

Une citation d’exploitation (idée paraphrasée)

idée paraphrasée — Gene Kranz : « Tough and competent » bat la panique ; en exploitation, la discipline gagne quand les systèmes se comportent mal.

Trois mini-récits d’entreprise (ce qui arrive réellement)

Incident : une mauvaise hypothèse sur NTFS et UEFI

Une entreprise de taille moyenne avait un processus standard de « USB de récupération Windows » géré par le support poste de travail. Ça fonctionnait bien sur leurs portables récents,
donc tout le monde a pensé que le problème était résolu. Puis une série de serveurs en rack a eu besoin d’une réinstallation d’urgence après une mise à jour du firmware du contrôleur de stockage qui a mal tourné.
L’équipe de remote hands est arrivée avec la clé USB. Les serveurs sont restés impassibles.

L’hypothèse était simple : « UEFI peut démarrer depuis NTFS, parce que ça démarre depuis notre USB NTFS sur les portables. »
C’était accidentellement vrai sur ce modèle de portable parce que le firmware du fabricant incluait des pilotes NTFS.
Les firmware des serveurs ne le faisaient pas. Pas de support NTFS, pas de démarrage.

L’équipe a essayé de basculer Secure Boot, changer de ports et échanger les clés. Rien. L’USB apparaissait dans le menu de démarrage, mais l’amorçage échouait immédiatement.
Quelqu’un a suggéré « peut‑être l’ISO est corrompue », ce qui était rassurant parce que cela n’impliquait pas d’erreur de conception.

La correction fut douloureusement ennuyeuse : recréer l’USB en FAT32 et scinder le WIM. Après cela, les serveurs ont démarré du premier coup.
Le résultat réel n’était pas seulement « systèmes restaurés ». Ils ont mis à jour le runbook interne pour spécifier FAT32 pour les médias UEFI amovibles, et une étape de validation
pour vérifier que \EFI\BOOT\BOOTX64.EFI existe.

Leçon post‑incident : le succès sur une classe de matériel n’est pas une preuve. Le firmware est une plateforme. Traitez‑la comme telle.

Optimisation qui a mal tourné : « accélérons ça » avec des copies agressives

Une autre équipe voulait accélérer la création de clés d’installation pour un projet de migration. Quelqu’un a eu l’idée d’utiliser des jobs de copie parallèles
et une politique de retry courte pour « échouer vite ». Le script utilisait des jobs en arrière‑plan pour copier plusieurs répertoires en parallèle,
puis déclarait le succès si les jobs n’avaient pas levé d’erreurs fatales.

C’était rapide. C’était aussi faux d’une manière subtile : des erreurs de lecture transitoires sur des médias USB bon marché ont fait que quelques fichiers étaient sautés,
mais les jobs se sont terminés. Le script ne validait pas le nombre de fichiers ni les chemins critiques. L’USB démarrerait, lancerait Windows Setup, puis échouerait pendant l’installation
avec des erreurs de composants manquants ressemblant à des problèmes WinPE aléatoires.

Le pire : ça échouait rarement. Cela signifiait que c’est passé les tests et s’est manifesté comme « échecs sur le terrain ».
Rien ne détruit un calendrier de déploiement comme des médias défectueux intermittents qui ressemblent à des bugs OS.

La correction fut d’arrêter d’optimiser la mauvaise chose. Ils sont revenus à un seul robocopy avec journalisation explicite,
plus un petit ensemble de validations obligatoires : présence des fichiers de démarrage, présence de boot.wim, et vérification que
la séparation SWM s’est bien déroulée. Le temps total a augmenté légèrement. Le taux d’échec est tombé quasiment à zéro.

Leçon : les optimisations de performance sans vérifications d’exactitude ne font que rendre l’erreur plus rapide.

Pratique ennuyeuse mais correcte qui a sauvé la situation : étiquetage et sélection déterministe du disque

Dans un environnement règlementé, une équipe infra maintenait un processus scripté de création d’USB pour la récupération bare‑metal.
Le script faisait une chose peu sexy exceptionnellement bien : il ne sélectionnait jamais le disque cible en « celui qui ressemble à une USB ».
Il demandait à l’opérateur de confirmer le numéro de disque et apposait une étiquette de volume connue sur l’USB.

Un après‑midi, un ingénieur a lancé le script sur une station avec un adaptateur USB‑vers‑SATA branché.
Windows le reportait comme un périphérique amovible, et il avait une taille proche de la cible prévue.
Sur une mauvaise journée, c’est comme ça qu’on efface un disque de sauvegarde externe et qu’on passe le week‑end à s’excuser.

Mais le script imposait deux confirmations : d’abord il affichait la liste des disques, puis il exigeait que l’opérateur tape le numéro exact du disque,
et enfin il vérifiait que le label du volume nouvellement formaté correspondait à la valeur attendue avant de copier des fichiers.
L’ingénieur a remarqué le décalage d’étiquetage au second prompt et a arrêté.

Plus tard, quand la même équipe a dû reconstruire des médias rapidement pendant une panne, ce processus déterministe a permis à n’importe qui de permanence
de le faire sans « savoir tacite ». Il produisait aussi des journaux satisfaisant les exigences d’audit sans drame.

Leçon : les garde‑fous ennuyeux sont ce qu’il vous faut à 2 h du matin. Ils ne vous font pas sentir intelligent, ce qui est précisément l’idée.

Erreurs courantes : symptômes → cause racine → correction

1) L’USB apparaît dans le menu de démarrage mais revient immédiatement au BIOS/UEFI

Cause racine : fichier de démarrage UEFI manquant ou mal placé (\EFI\BOOT\BOOTX64.EFI), ou mauvais système de fichiers (exFAT/NTFS sur un firmware qui ne lit que FAT).

Correction : Formater en FAT32, recopier le contenu de l’ISO, vérifier que Test-Path F:\EFI\BOOT\BOOTX64.EFI retourne True.

2) Le démarrage commence, Windows Setup se charge, puis l’installation échoue avec des fichiers manquants

Cause racine : install.wim n’a pas été copié vers FAT32 à cause de la limite de 4 Go, ou a été sauté pendant la copie.

Correction : Scinder le WIM en SWM avec DISM ; confirmer la présence des fichiers SWM et l’absence de install.wim sur FAT32.

3) L’opération de copie « a réussi », mais le contenu de l’USB est trop petit

Cause racine : Copie depuis la mauvaise source (pas l’ISO montée), ou robocopy a exclu des répertoires, ou des permissions ont masqué des erreurs.

Correction : Remonter l’ISO, vérifier la lettre source, relancer robocopy sans filtres excessifs, et contrôler la somme des octets copiés.

4) L’USB démarre sur des portables mais pas sur des serveurs

Cause racine : fonctionnalités spécifiques au firmware du fournisseur (support NTFS, comportement différent des médias amovibles, initialisation des ports USB).

Correction : Utiliser le chemin UEFI FAT32, privilégier les ports arrière de la carte mère, et valider sur la classe matérielle cible—pas sur le portable le plus proche.

5) Secure Boot bloque le démarrage pour violation de politique

Cause racine : chargeur non signé ou modifié, ou média non Microsoft dans un environnement Secure Boot strict.

Correction : Utiliser des médias officiels ou enrôler les clés appropriées ; ne « résolvez » pas en désactivant Secure Boot sauf si la politique l’autorise.

6) L’USB disparaît de façon intermittente ou provoque des erreurs I/O pendant la copie

Cause racine : média USB défaillant, port/hub instable, ou problèmes d’alimentation sur des ports en façade.

Correction : Essayez une autre clé et un autre port ; si le hachage des fichiers génère des erreurs, remplacez le matériel au lieu de déboguer.

7) UEFI démarre, mais le clavier/souris ne fonctionne pas dans WinPE

Cause racine : périphérique d’entrée USB non initialisé correctement (paramètres firmware, problèmes de xHCI handoff), ou pilotes manquants dans WinPE pour certains matériels.

Correction : Utilisez d’autres ports (USB 2 si disponible), ajustez les paramètres firmware USB, ou utilisez un média d’installation mis à jour avec un support pilote plus large.

8) « Accès refusé » lors du formatage ou de l’attribution d’une lettre

Cause racine : PowerShell non élevé en administrateur, ou un processus tient le volume ouvert.

Correction : Lancez PowerShell en tant qu’administrateur ; fermez les fenêtres de l’Explorateur ; relancez des vérifications Get-Process si nécessaire.

Listes de contrôle / plan étape par étape

Checklist A : USB d’installation Windows orienté UEFI (partition FAT32 unique)

1. Identifier le disque cible : Get-Disk et confirmer par BusType=USB et la taille.
2. Effacer et initialiser en GPT : Clear-Disk, Initialize-Disk -PartitionStyle GPT.
3. Créer une partition + format FAT32 + étiquette : New-Partition, Format-Volume -FileSystem FAT32.
4. Monter l’ISO : Mount-DiskImage ; capturer la lettre de l’ISO.
5. Vérifier la taille de install.wim ; si > 4 Go, prévoir la séparation.
6. Copier le contenu de l’ISO en sautant install.wim via robocopy.
7. Scinder le WIM en SWM avec DISM dans F:\sources.
8. Vérifier : \EFI\BOOT\BOOTX64.EFI existe ; boot.wim existe ; fichiers SWM présents ; le volume est FAT32.
9. Démonter l’ISO ; éjecter l’USB.

Checklist B : Vérifications minimales avant de remettre l’USB à quelqu’un

1. Chemin de démarrage : Test-Path F:\EFI\BOOT\BOOTX64.EFI doit être True.
2. WinPE : Test-Path F:\sources\boot.wim doit être True.
3. Payload d’installation : soit install.esd existe, soit install.swm existe (et toutes les pièces sont présentes).
4. Système de fichiers : Get-Volume montre FAT32.
5. Intégrité de copie : exécuter au moins un Get-FileHash sur quelques fichiers clés pour assurer la stabilité de lecture.

Checklist C : Si vous automatisez cela dans un script

• Exiger une saisie explicite du numéro de disque ; ne jamais le sélectionner automatiquement.
• Écrire des logs : sélection de disque, style de partition, étiquette de volume, résumé robocopy, sortie DISM.
• Échouer clairement si les chemins obligatoires sont manquants après la copie.
• Rendre votre script idempotent quand c’est possible (effacer le disque puis construire la même disposition à chaque fois).

FAQ

1) Puis‑je créer une clé USB bootable Windows en copiant simplement le fichier ISO sur la clé ?

Non. Le firmware ne démarre pas un fichier ISO posé sur un système de fichiers (pas en général). Il démarre un fichier chargeur depuis un système de fichiers ou un secteur de démarrage.
Vous devez monter l’ISO et copier son contenu (ou écrire correctement une image disque avec la structure de démarrage).

2) Pourquoi FAT32 ? Ça fait ancien.

Parce que le firmware peut le lire. Les implémentations UEFI doivent prendre en charge FAT. Le support NTFS est optionnel et incohérent.
FAT32 est le format ennuyeux qui fonctionne quand vous traitez des cartes serveurs aléatoires à des moments inopportuns.

3) Et si mon ISO a install.esd au lieu de install.wim ?

Parfait. L’ESD est souvent plus petit, donc il tient généralement sur FAT32 sans séparation.
Vérifiez quand même la taille : Get-Item D:\sources\install.esd.

4) Ai‑je besoin de GPT pour l’USB ?

Pour le démarrage UEFI, GPT est un bon défaut. Certains firmwares booteront l’UEFI depuis MBR aussi.
Si vous ciblez le BIOS legacy, MBR est souvent plus sûr. Si vous ciblez des serveurs modernes, GPT garde les choses cohérentes.

5) Pourquoi ne pas utiliser diskpart au lieu des cmdlets PowerShell ?

Vous pouvez appeler diskpart depuis PowerShell, et parfois c’est la démarche pragmatique pour les cas limites.
Mais les cmdlets PowerShell sont plus scriptables, plus découvertes et généralement plus faciles à valider avec une sortie structurée.

6) L’USB est en FAT32, les fichiers de démarrage existent, mais ça ne démarre toujours pas. Et maintenant ?

Vérifiez le mode de démarrage (UEFI vs legacy), la politique Secure Boot, et essayez un autre port.
Ensuite soupçonnez la clé elle‑même. Si ça ne marche que sur un modèle matériel, suspectez des particularités firmware ou l’absence de support multi‑partition.

7) Puis‑je créer une clé USB bootable Linux avec la même méthode ?

Parfois, mais beaucoup d’ISO Linux sont conçues comme des images hybrides qui s’écrivent mieux en brut.
Cet article est axé sur les médias d’installation Windows. La copie de fichiers fonctionne quand la structure de démarrage de l’ISO l’attend ; l’écriture brute fonctionne quand l’ISO est construite pour cela.

8) Comment savoir si mon échec est « USB non bootable » vs « problème de l’installateur » ?

Si vous n’atteignez jamais l’interface de l’installateur, c’est généralement le chemin de démarrage/système de fichiers/mode firmware.
Si vous atteignez Setup et qu’il échoue plus tard (copie de fichiers, sélection d’édition, application d’image), c’est souvent des fichiers payload manquants ou corrompus (WIM/SWM/ESD).

9) Puis‑je faire cela sans droits Admin ?

Pas de façon fiable. Formater des disques et monter des images requièrent en général des privilèges élevés.
Si vous êtes dans un environnement verrouillé, travaillez avec ceux qui contrôlent les privilèges endpoints—n’utilisez pas d’outils douteux.

10) Devrais‑je désactiver le « format rapide » pour la sécurité ?

Le format rapide convient dans la plupart des cas. Il ne teste pas toute la surface toutefois.
Si vous suspectez un média défaillant, remplacez la clé ou exécutez des vérifications plus approfondies ; ne prétendez pas qu’un formatage validera le matériel.

Conclusion : prochaines étapes concrètes

Si vous ne retenez que trois choses, retenez celles‑ci : choisissez le bon disque délibérément, utilisez FAT32 pour la compatibilité UEFI, et gérez la limite de 4 Go
en scindant le WIM plutôt qu’en espérant le contraire.

Prochaines étapes :

1. Transformez votre séquence de commandes finale en script avec confirmation explicite du disque et validations post‑copie.
2. Testez sur la même classe matérielle où vous installerez (le firmware serveur n’est pas un portable).
3. Gardez une clé connue‑bonne dans un sachet étiqueté et traitez‑la comme un outil d’intervention—parce que c’est ce que c’est.

L’objectif n’est pas de se sentir malin. L’objectif est que ça démarre du premier coup quand le système est déjà en feu.