Intégrer des pilotes dans une ISO Windows : faire en sorte que l’installation « fonctionne simplement »

février 23, 2026 • février 23, 2026 • Lecture : 29 min • Views: 0

Cet article vous a aidé ?

Vous démarrez l’installateur Windows. Vous cliquez sur « Install now ». Et puis la chute arrive : aucun disque trouvé, pas de réseau,
parfois même pas de clavier sur les plateformes récentes. C’est le moment où les équipes montrent soit un professionnalisme tranquille,
soit commencent à fouiller des ZIP de pilotes comme à une brocante.

L’intégration de pilotes — les injecter dans l’image d’installation — transforme ce chaos en un résultat ennuyeux et reproductible.
Setup voit le stockage. WinPE voit la carte réseau. Les outils d’imagerie se comportent. Votre fenêtre de maintenance nocturne reste
ennuyeuse, ce qui est la plus haute forme de réussite en exploitation.

Ce que signifie réellement l’intégration de pilotes (et ce que ce n’est pas)

L’intégration de pilotes est un service hors ligne : vous montez des fichiers d’image Windows (WIM), injectez des pilotes (généralement via des packages .inf),
validez les modifications et reconstruisez l’ISO pour que Windows Setup charge ces pilotes sans que vous cliquiez sur « Load driver ».
Vous n’« installez pas des pilotes » dans le système en cours d’exécution. Vous les incorporez dans l’environnement d’installation (WinPE)
et/ou dans l’image du système installé.

Il y a deux images principales qui comptent :

boot.wim : l’environnement Windows Preinstallation (WinPE) utilisé par Setup. Si Setup ne voit pas
les disques ou le réseau, c’est généralement ici qu’on injecte.
install.wim (ou install.esd) : les images des éditions Windows qui sont appliquées sur le disque.
Si Windows s’installe mais plante au premier démarrage ou n’a pas de NIC après l’installation, vous injectez aussi ici.

L’intégration de pilotes n’est pas magique. Si vous injectez la mauvaise architecture (x86 vs x64), le mauvais modèle de pilote (un EXE d’installation
legacy au lieu d’un package basé sur INF), ou un pilote nécessitant un co-installateur non supporté dans WinPE, vous perdrez quand même.
Vous perdez simplement plus tôt et de façon plus déterministe — ce qui est honnêtement une amélioration.

Une vérité opérationnelle : traitez le média d’installation comme du code. Versionnez-le. Étiquetez-le. Testez-le. Si quelqu’un dit « J’ai fait une nouvelle ISO,
ça devrait aller », ce n’est pas un processus ; c’est une superstition avec un fichier zip joint.

Faits et contexte à utiliser en réunion

Quelques faits concrets et points de contexte historique qui rendent le sujet moins mystique et plus prévisible :

Le terme « slipstreaming » est devenu populaire à l’époque de Windows XP lorsque les admins fusionnaient les service packs dans
les médias d’installation pour éviter les patchs immédiatement après l’installation.
Les images WIM sont basées sur des fichiers, pas sur des secteurs. C’est pourquoi DISM peut les monter, manipuler leur contenu
et dédupliquer des fichiers entre éditions.
WinPE est minimal par conception. Il n’embarque pas tous les pilotes de stockage et de NIC connus de l’humanité,
car l’objectif est une empreinte réduite et une compatibilité large mais limitée.
L’adoption de l’UEFI a changé la donne. Les plateformes modernes s’appuient sur UEFI, GPT, Secure Boot et des abstractions
de stockage récentes (NVMe, VMD, RAID-on-CPU) qui exigent des pilotes fournisseurs plus tôt dans la chaîne de démarrage/installation.
Le support NVMe dans Windows a évolué significativement ; les versions plus anciennes exigeaient des hotfixes ou des pilotes fournisseurs,
tandis que les versions récentes incluent un support NVMe large — mais pas tous les modes de contrôleur plateforme.
Intel RST/VMD et des piles de stockage « accélératrices » similaires cachent souvent les NVMe physiques derrière une abstraction de contrôleur,
de sorte que le pilote NVMe générique de Windows ne voit pas les disques tant que le pilote fournisseur n’est pas chargé.
install.esd vs install.wim : ESD est un format plus compressé. Il est excellent pour la distribution, agaçant pour le service.
Beaucoup de workflows convertissent ESD en WIM pour injecter des pilotes de façon fiable.
Windows Setup utilise deux indices dans boot.wim sur un média typique : un pour WinPE et un pour l’environnement Setup.
Si vous injectez dans le mauvais index, rien ne change et vous jurerez que DISM ment.

Décider quoi injecter : stockage, réseau et les deux WIM

Si vous êtes ici parce que « aucun disque trouvé », commencez par les pilotes de stockage dans boot.wim.
Si c’est parce que l’installateur ne peut pas atteindre votre partage de déploiement, commencez par les pilotes NIC dans boot.wim.
Si Windows s’installe puis ne peut pas démarrer ou ne voit pas le réseau au premier démarrage, injectez aussi dans install.wim.

Stockage : les suspects habituels

Intel RST / VMD sur les ordinateurs portables modernes et certains serveurs.
Broadcom/LSI MegaRAID sur les serveurs d’entreprise.
HPE Smart Array, Dell PERC dans leurs différentes générations.
Excentricités Marvell/JMicron sur des cartes et appliances « whitebox ».

Réseau : ce n’est jamais « juste DHCP »

Sans pilotes NIC dans WinPE, vous ne pouvez pas récupérer un fichier de réponse, des pilotes, des packages ni une image depuis le réseau.
Vous ne pouvez pas rejoindre un système de déploiement. Vous ne pouvez pas non plus dépanner facilement car la moitié de vos outils
se trouvent de l’autre côté du réseau.

Décider où le pilote doit atterrir

Utilisez cette règle de décision :

Setup ne voit pas disques/NIC → injecter dans boot.wim (environnement Setup).
Setup fonctionne mais premier démarrage échoue → injecter dans install.wim (image OS installée).
Les deux → injecter dans les deux. Ne négociez pas avec la physique.

Hygiène des pilotes : choisir le bon INF et éviter la soupe de pilotes

Les fournisseurs adorent fournir un seul téléchargement nommé « Storage Driver Package » contenant :
un MSI, un EXE d’installation, trois dossiers INF différents et un PDF qui suppose que vous déployez avec un outil que vous n’avez pas.
Votre travail est de localiser les fichiers .inf pour le matériel exact et l’architecture de l’OS.

Opérationnellement, vous voulez :

Pilotes signés (surtout avec Secure Boot). Les pilotes non signés dans WinPE sont une bombe à retardement.
Jeu minimal : seulement les pilotes de stockage/NIC dont vous avez besoin pour la famille de plateformes.
Traçabilité : noter la version fournisseur, la date de publication et le(s) modèle(s) matériel(s) ciblé(s).

N’injectez pas « tous les pilotes qu’on a déjà utilisés » dans votre ISO. Ça semble sûr. Ça ne l’est pas.
Cela augmente la taille de boot.wim, le temps de chargement, les risques de conflits de pilotes et rend le dépannage ambigu.

Blague #1 : injecter tous les pilotes que vous trouvez, c’est comme amener tout votre garage pour changer un pneu. Vous perdrez quand même la douille de 10 mm.

Un agencement pratique de laboratoire (dossiers, outils, attentes)

Vous pouvez faire cela sur une station d’administration Windows, une VM de build ou un runner CI. Vous pouvez aussi faire des parties depuis Linux
(montage d’ISO, extraction de fichiers), mais le service DISM est plus simple et mieux supporté sur Windows.

Une structure simple :

C:\ISO\src — contenu de l’ISO Windows extrait
C:\ISO\mount\boot — point de montage pour boot.wim
C:\ISO\mount\install — point de montage pour install.wim
C:\ISO\drivers\storage — pilotes de stockage, basés sur INF
C:\ISO\drivers\nic — pilotes NIC, basés sur INF
C:\ISO\out — sortie de la reconstruction ISO

Outils que vous utiliserez typiquement :

DISM (intégré à Windows) pour mount/add-driver/commit/export
oscdimg (Windows ADK) pour reconstruire correctement une ISO bootable
Get-FileHash / signtool (optionnel) pour vérifications d’intégrité et de signature

Tâches pratiques avec commandes : le travail réel

Les tâches ci-dessous sont écrites comme si vous exécutiez une build de production : vous vérifiez l’état, confirmez les hypothèses
et prenez une décision basée sur la sortie. J’utilise une invite de type bash par exigence ; les commandes sont natives Windows et
exécutables dans PowerShell ou CMD.

Tâche 1 : Confirmer que vous servez la bonne build ISO (vérification de version)

cr0x@server:~$ dism /Get-WimInfo /WimFile:C:\ISO\src\sources\install.wim
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Details for image : C:\ISO\src\sources\install.wim

Index : 1
Name : Windows 11 Pro
Description : Windows 11 Pro
Size : 16,123,456,789 bytes

Index : 2
Name : Windows 11 Pro N
Description : Windows 11 Pro N
Size : 15,987,654,321 bytes

The operation completed successfully.

Ce que cela signifie : Vous avez un WIM avec plusieurs indices (éditions). Injecter dans un seul index signifie que seule
cette édition recevra le pilote.

Décision : Identifiez l’index que vous déployez. Si vous utilisez plusieurs éditions, prévoyez d’injecter dans chaque index
susceptible d’être installé.

Tâche 2 : Inspecter les indices de boot.wim (le piège du « mauvais index »)

cr0x@server:~$ dism /Get-WimInfo /WimFile:C:\ISO\src\sources\boot.wim
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Details for image : C:\ISO\src\sources\boot.wim

Index : 1
Name : Microsoft Windows PE (x64)
Description : Microsoft Windows PE (x64)

Index : 2
Name : Microsoft Windows Setup (x64)
Description : Microsoft Windows Setup (x64)

The operation completed successfully.

Ce que cela signifie : L’index 2 est généralement l’environnement Setup qui énumère réellement le stockage pendant l’UI.

Décision : Injectez les pilotes de stockage/NIC dans l’index 2 au minimum. Par sécurité, beaucoup d’équipes injectent dans les deux.

Tâche 3 : Monter boot.wim index 2 (Setup) en lecture-écriture

cr0x@server:~$ dism /Mount-Wim /WimFile:C:\ISO\src\sources\boot.wim /Index:2 /MountDir:C:\ISO\mount\boot
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Mounting image
[==========================100.0%==========================]
The operation completed successfully.

Ce que cela signifie : Vous avez maintenant une image Windows hors ligne dans C:\ISO\mount\boot.

Décision : Si le montage échoue avec « Access is denied » ou « The directory is not empty », arrêtez et nettoyez avant de poursuivre.
Ne cumulez pas un état incorrect.

Tâche 4 : Lister les pilotes tiers existants dans WinPE avant d’en ajouter

cr0x@server:~$ dism /Image:C:\ISO\mount\boot /Get-Drivers /Format:Table
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Published Name      Original File Name  Inbox  Class Name
oem1.inf            e1d68x64.inf         No     Net
oem2.inf            iaStorVD.inf         No     SCSIAdapter

The operation completed successfully.

Ce que cela signifie : « Inbox: No » indique des pilotes ajoutés. Vous voyez ce qui est déjà présent dans l’image.

Décision : Si le pilote dont vous avez besoin est déjà présent, votre problème n’est probablement pas « pilote manquant » mais
« mode contrôleur incorrect », « Secure Boot bloquant un non signé » ou « mauvais index ».

Tâche 5 : Ajouter des pilotes de stockage récursivement (basés INF)

cr0x@server:~$ dism /Image:C:\ISO\mount\boot /Add-Driver /Driver:C:\ISO\drivers\storage /Recurse
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Searching for driver packages to install...
Found 3 driver package(s) to install.
Installing 1 of 3 - C:\ISO\drivers\storage\iaStorVD.inf: The driver package was successfully installed.
Installing 2 of 3 - C:\ISO\drivers\storage\iaStorAC.inf: The driver package was successfully installed.
Installing 3 of 3 - C:\ISO\drivers\storage\iaVMD.inf: The driver package was successfully installed.
The operation completed successfully.

Ce que cela signifie : DISM a trouvé des packages INF et les a injectés dans le magasin de pilotes de l’image hors ligne.

Décision : Si DISM indique « No driver packages were found », vous pointez probablement vers le mauvais dossier (souvent un bundle EXE/MSI)
ou l’INF n’est pas pour cette architecture.

Tâche 6 : Ajouter les pilotes NIC (pour que WinPE atteigne vos systèmes de déploiement)

cr0x@server:~$ dism /Image:C:\ISO\mount\boot /Add-Driver /Driver:C:\ISO\drivers\nic /Recurse
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Searching for driver packages to install...
Found 1 driver package(s) to install.
Installing 1 of 1 - C:\ISO\drivers\nic\rt68x64.inf: The driver package was successfully installed.
The operation completed successfully.

Ce que cela signifie : WinPE tentera désormais de charger ces pilotes au démarrage, activant le réseau plus tôt.

Décision : Si votre déploiement dépend des partages SMB, du PXE ou de la récupération de fichiers de réponse, les pilotes NIC
dans boot.wim sont obligatoires. Ne dites pas « on branchera une clé USB plus tard » pour vous sortir d’un déploiement en production.

Tâche 7 : Vérifier la présence des pilotes après injection (faire confiance, mais vérifier)

cr0x@server:~$ dism /Image:C:\ISO\mount\boot /Get-Drivers /Format:Table
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Published Name      Original File Name  Inbox  Class Name
oem1.inf            e1d68x64.inf         No     Net
oem2.inf            iaStorVD.inf         No     SCSIAdapter
oem3.inf            iaStorAC.inf         No     SCSIAdapter
oem4.inf            iaVMD.inf            No     SCSIAdapter
oem5.inf            rt68x64.inf          No     Net

The operation completed successfully.

Ce que cela signifie : Vous avez la confirmation que l’image contient les packages de pilotes ajoutés.

Décision : Si les pilotes apparaissent mais que le matériel n’est toujours pas détecté dans Setup, il vous manque probablement
une dépendance liée, vous avez injecté la mauvaise pile de stockage, ou vous êtes confronté aux paramètres du BIOS.

Tâche 8 : Commit et démontage de boot.wim

cr0x@server:~$ dism /Unmount-Wim /MountDir:C:\ISO\mount\boot /Commit
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Saving image
[==========================100.0%==========================]
Unmounting image
[==========================100.0%==========================]
The operation completed successfully.

Ce que cela signifie : Vos modifications sont écrites dans boot.wim.

Décision : Si DISM avertit de opérations en attente ou d’erreurs au démontage, ne procédez pas à la reconstruction de l’ISO.
Corrigez d’abord l’état de l’image, sinon vous livrerez un installateur corrompu et deviendrez une histoire à raconter.

Tâche 9 : Monter install.wim pour l’édition que vous déployez et injecter les mêmes pilotes

cr0x@server:~$ dism /Mount-Wim /WimFile:C:\ISO\src\sources\install.wim /Index:1 /MountDir:C:\ISO\mount\install
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Mounting image
[==========================100.0%==========================]
The operation completed successfully.

Ce que cela signifie : Vous éditez l’image OS réelle qui sera installée.

Décision : Si vous déployez plusieurs indices, répétez pour chacun. Oui, c’est fastidieux. Non, vous ne pouvez pas l’ignorer
en espérant que votre séquence de tâches choisira toujours la même édition pour toujours.

Tâche 10 : Ajouter des pilotes à install.wim (stockage + NIC)

cr0x@server:~$ dism /Image:C:\ISO\mount\install /Add-Driver /Driver:C:\ISO\drivers\storage /Recurse
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Searching for driver packages to install...
Found 3 driver package(s) to install.
Installing 1 of 3 - C:\ISO\drivers\storage\iaStorVD.inf: The driver package was successfully installed.
Installing 2 of 3 - C:\ISO\drivers\storage\iaStorAC.inf: The driver package was successfully installed.
Installing 3 of 3 - C:\ISO\drivers\storage\iaVMD.inf: The driver package was successfully installed.
The operation completed successfully.

cr0x@server:~$ dism /Image:C:\ISO\mount\install /Add-Driver /Driver:C:\ISO\drivers\nic /Recurse
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Searching for driver packages to install...
Found 1 driver package(s) to install.
Installing 1 of 1 - C:\ISO\drivers\nic\rt68x64.inf: The driver package was successfully installed.
The operation completed successfully.

Ce que cela signifie : Le système installé disposera de ces pilotes disponibles au premier démarrage.

Décision : Si votre premier démarrage plantait auparavant avec INACCESSIBLE_BOOT_DEVICE, c’est la mitigation
primaire : assurez-vous que le pilote du contrôleur de stockage est présent dans l’image OS avant qu’elle n’essaie de démarrer.

Tâche 11 : Valider l’état de signature des pilotes (ne pas livrer de surprises non signées)

cr0x@server:~$ pnputil /enum-drivers
Published Name: oem10.inf
Original Name: iaVMD.inf
Provider Name: Intel
Class Name: SCSIAdapter
Driver Version: 07/18/2024 20.0.0.1038
Signer Name: Microsoft Windows Hardware Compatibility Publisher

Ce que cela signifie : Un nom de signataire réputé indique généralement un package correctement signé. Les packages non signés
sont un pari avec Secure Boot et les politiques Windows modernes.

Décision : Si le signataire est vide ou « Unknown », arrêtez-vous et trouvez une version signée. Si vous devez utiliser un non signé
pour un laboratoire, traitez-le comme un artefact réservé au labo.

Tâche 12 : Commit et démontage d’install.wim

cr0x@server:~$ dism /Unmount-Wim /MountDir:C:\ISO\mount\install /Commit
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Saving image
[==========================100.0%==========================]
Unmounting image
[==========================100.0%==========================]
The operation completed successfully.

Ce que cela signifie : L’image OS installée est maintenant mise à jour.

Décision : Si le fichier WIM a gonflé et que vous tenez à la taille de distribution, prévoyez une étape d’export/recompression
(tâche suivante). Mais ne faites pas de fantaisies tant que vous n’avez pas un installateur fonctionnel.

Tâche 13 : Ré-exporter install.wim pour nettoyer et éventuellement compresser

cr0x@server:~$ dism /Export-Image /SourceImageFile:C:\ISO\src\sources\install.wim /SourceIndex:1 /DestinationImageFile:C:\ISO\src\sources\install.new.wim /Compress:max /CheckIntegrity
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Exporting image
[==========================100.0%==========================]
The operation completed successfully.

Ce que cela signifie : L’export réécrit l’image proprement et peut réduire la fragmentation et la taille.

Décision : Si vous avez plusieurs indices, exportez chacun et reconstruisez un WIM consolidé ; sinon vous livrerez un média où
une seule édition est corrigée.

Tâche 14 : Remplacer l’ancien install.wim en toute sécurité

cr0x@server:~$ move C:\ISO\src\sources\install.wim C:\ISO\src\sources\install.bak.wim
        1 file(s) moved.

cr0x@server:~$ move C:\ISO\src\sources\install.new.wim C:\ISO\src\sources\install.wim
        1 file(s) moved.

Ce que cela signifie : Vous conservez une copie de restauration. Toujours.

Décision : Si vous faites cela dans le cadre d’un processus de release, stockez le .bak en dehors de l’arborescence de build.
Les rollbacks locaux n’aident pas quand quelqu’un « nettoie » le dossier.

Tâche 15 : Vérifier l’intégrité et la santé des WIM avant de reconstruire l’ISO

cr0x@server:~$ dism /Cleanup-Wim
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

No mounted WIM images found.
The operation completed successfully.

Ce que cela signifie : Aucun montage résiduel. C’est bon. Les montages résiduels sont la manière dont vous livrez des images à moitié écrites.

Décision : Si cela signale des images montées que vous n’attendiez pas, enquêtez et nettoyez. Ne reconstruisez pas l’ISO alors que DISM pense
qu’un montage est actif.

Tâche 16 : Construire l’ISO bootable avec oscdimg (ADK)

cr0x@server:~$ oscdimg -m -o -u2 -udfver102 -bootdata:2#p0,e,bC:\ISO\src\boot\etfsboot.com#pEF,e,bC:\ISO\src\efi\microsoft\boot\efisys.bin C:\ISO\src C:\ISO\out\Win-Setup-Drivers.iso
OSCDIMG 2.56 CD-ROM and DVD-ROM Premastering Utility
Scanning source tree (100 files in 20 directories)
Computing directory information complete
Writing 100 files in 20 directories to disc
100% complete
Final image file is 5,123,456,000 bytes
Done.

Ce que cela signifie : Vous avez créé une ISO dual-boot (BIOS + UEFI) avec des secteurs d’amorçage corrects.

Décision : Si vous ne démarrez qu’en UEFI, vous pouvez simplifier, mais ne le faites que si vous êtes certain à propos du firmware de votre flotte.
« Certain » signifie données d’actif, pas impressions.

Tâche 17 : Validation rapide — lister les pilotes dans boot.wim sans monter (vérification ponctuelle)

cr0x@server:~$ dism /Get-Drivers /Image:C:\ISO\mount\boot
Error: 2

The system cannot find the file specified.

Ce que cela signifie : Cela échoue parce que l’image n’est pas montée. C’est attendu et c’est un rappel : les requêtes DISM nécessitent un chemin d’image monté
ou un workflow /WimFile + /Index.

Décision : Si vous voulez une vérification ponctuelle, montez en lecture seule ou remontez et vérifiez. Ne supposez pas que la dernière étape de build
a fait ce que vous pensez qu’elle a fait.

Manuel de diagnostic rapide

Quand Windows Setup ne « fonctionne pas simplement », vous avez besoin d’un ordre de triage déterministe. Pas parce que vous êtes impatient (vous l’êtes),
mais parce que les modes d’échec se recoupent et une mauvaise supposition coûte le plus de temps.

Première étape : décider s’il s’agit d’un échec d’énumération de stockage ou d’un mauvais mode de contrôleur

Vérifiez le mode de stockage du BIOS/UEFI : AHCI vs RAID vs VMD. Si VMD est activé et que vous n’avez pas le pilote VMD dans WinPE,
Setup ne verra pas les disques. Si vous changez de mode après l’installation, Windows peut ne plus démarrer.
Vérifiez le matériel présent : un NVMe derrière VMD ressemble différemment qu’un NVMe brut.

Deuxième étape : confirmez que vous avez injecté dans le bon WIM et le bon index

Disque manquant dans l’UI Setup ? C’est boot.wim index 2 neuf fois sur dix.
Disque visible pendant Setup mais premier démarrage échoue ? C’est install.wim.

Troisième étape : validez le packaging et la signature du pilote

Avez-vous des pilotes basés INF, pas un exécutable d’installation ?
Sont-ils x64 pour les builds Windows modernes ?
Sont-ils signés de façon à survivre aux politiques Secure Boot ?

Quatrième étape : attention aux leurres « media driver missing »

Le redouté « A media driver your computer needs is missing » n’a souvent rien à voir avec les pilotes USB. Ça peut être le stockage,
un install.wim corrompu, une ISO mal écrite sur USB, ou Setup qui n’arrive pas à lire la source. Traitez cela comme « Setup ne peut pas lire quelque chose dont il a besoin »,
puis réduisez le champ.

Cinquième étape : réduire les variables

Essayez une autre clé USB.
Essayez un autre port USB (les hubs USB-C sont le chaos).
Essayez de démarrer l’ISO dans une VM pour confirmer que le média n’est pas corrompu.

Citation (idée paraphrasée) : Le message fiabilité de John Allspaw est que la résilience vient de l’apprentissage et de l’adaptation, pas de faire comme si l’échec n’existait pas.

Erreurs courantes : symptômes → cause → correction

Voici les échecs qui reviennent parce qu’ils sont faciles à faire et pénibles à repérer.

1) Symptom : « Aucun lecteur n’a été trouvé. Cliquez sur Load driver… »

Cause : Le mode du contrôleur de stockage nécessite un pilote fournisseur (RST/VMD/RAID) absent de boot.wim index 2.
Correction : Injectez le bon INF de stockage dans boot.wim index 2 (et généralement l’index 1 aussi). Vérifiez avec /Get-Drivers.
Confirmez que le mode du BIOS n’a pas changé.

2) Symptom : Setup voit le disque, mais Windows fait un BSOD au premier démarrage (INACCESSIBLE_BOOT_DEVICE)

Cause : Le pilote existe dans WinPE (boot.wim) mais pas dans l’image OS installée (install.wim), ou le mode de stockage BIOS a changé après l’installation.
Correction : Injectez le pilote de stockage dans le bon index de install.wim. Gardez le mode de stockage constant de l’installation au premier démarrage.

3) Symptom : « A media driver your computer needs is missing » tôt dans Setup

Cause : Mauvaise méthode de création USB, ISO corrompue, pilote de stockage manquant, ou Setup ne peut pas lire sa propre source à cause d’un port/hub instable.
Correction : Recréez l’USB avec un outil fiable, essayez un autre port, vérifiez le hash de l’ISO et injectez les pilotes de stockage si la plateforme utilise VMD/RAID.

4) Symptom : DISM dit « No driver packages were found »

Cause : Vous avez pointé DISM vers un dossier sans .inf, ou le pilote est de la mauvaise architecture.
Correction : Extrayez le package jusqu’à obtenir l’ensemble INF + SYS + CAT. Confirmez les pilotes x64 pour WinPE x64.

5) Symptom : Setup fonctionne, mais pas de réseau dans WinPE (impossible d’atteindre le partage de déploiement)

Cause : Pilote NIC manquant dans boot.wim, ou la NIC est plus récente que les pilotes inbox.
Correction : Injectez les pilotes NIC dans l’index 2 de boot.wim. Validez en démarrant et en exécutant ipconfig dans WinPE si vous avez accès à un shell.

6) Symptom : Le pilote s’injecte correctement, mais le matériel n’est toujours pas détecté

Cause : Mauvaise variante de pilote (modèle similaire, PCI IDs différents), ou le BIOS cache le périphérique derrière un autre mode de contrôleur.
Correction : Confirmez les IDs matériels PCI dans un OS en fonctionnement ou avec un outil d’inventaire fournisseur ; faites correspondre avec l’INF. Confirmez les paramètres firmware (VMD activé/désactivé, RAID activé/désactivé).

7) Symptom : Erreurs de montage/démontage, « The image is in use », ou les commits ne persistent pas

Cause : Montages obsolètes, antivirus scannant les chemins de montage, ou opérations DISM interrompues.
Correction : Exécutez dism /Cleanup-Wim, utilisez un répertoire de montage propre, excluez temporairement les chemins de montage de l’AV dans un environnement de build contrôlé.

Trois mini-récits d’entreprise issus du terrain

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

Une entreprise a déployé une série de nouveaux portables pour les ingénieurs. L’équipe de build IT avait une ISO Windows « connue bonne »
qui avait fonctionné pendant des années sur la génération précédente de matériel. Ils ont supposé que NVMe c’était NVMe, Windows c’était Windows,
et que Setup verrait le disque.

Le premier jour, la file d’assistance a été inondée du même écran : aucun disque. Quelqu’un a suggéré que les clés USB étaient défectueuses, donc
ils ont ré-imagé les clés. Même échec. Un autre a accusé Secure Boot et a commencé à basculer les paramètres firmware comme s’il réglait une radio.

La cause était banale : l’OEM avait livré la flotte avec VMD activé par défaut. Cela cachait les NVMe derrière une couche de contrôleur nécessitant
le pilote Intel dans WinPE. L’ISO « connue bonne » n’avait pas ce pilote car l’ancienne flotte n’en avait pas besoin.

La correction a été d’injecter les bons pilotes VMD/RST dans boot.wim index 2 et de reconstruire le média, puis de standardiser
le réglage BIOS sur l’ensemble de la flotte. Le post-mortem a été clair : les suppositions sur le « support NVMe générique » ne survivent pas
à l’abstraction des contrôleurs fournisseurs. Les fournisseurs de matériel sont créatifs.

Ils ont ajouté une checklist de pré-vol : confirmer le mode de stockage, confirmer les PCI IDs et confirmer la couverture pilote WinPE. Ce n’était
pas glamour. Ça a arrêté l’hémorragie.

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

Une autre organisation voulait un déploiement plus rapide. Quelqu’un a eu l’idée de construire une « ISO installeur universelle » contenant
tous les packs de pilotes qu’ils avaient jamais utilisés : chipset, GPU, audio, Wi‑Fi, stockage, NIC, imprimantes — oui, imprimantes.
Ils pensaient : plus de pilotes = moins de surprises = installations plus rapides.

En pratique, l’ISO est devenue lourde. boot.wim a tellement grossi que les temps de démarrage WinPE ont augmenté, surtout sur des clés USB plus anciennes.
Pire, certaines piles de pilotes de stockage se recoupaient. Sur un sous-ensemble de serveurs, Setup chargeait parfois le miniport « mauvais » en premier,
faisant apparaître et disparaître les disques au fil des redémarrages. Les défaillances intermittentes sont l’endroit où votre calendrier meurt.

Ensuite est venue la question conformité : ils n’avaient aucun enregistrement propre des pilotes inclus, de leurs versions et de leur support.
Quand l’équipe sécurité a demandé la traçabilité, la réponse était essentiellement « un dossier de trucs ». Ce n’est pas une réponse.

Le rollback n’a pas été un rollback ; c’était une désintoxication. Ils ont reconstruit des médias par famille matérielle : une ISO pour la gamme de portables,
une pour une génération de serveurs spécifique, une pour une appliance niche. Plus petits, ciblés, vérifiables. La vitesse de déploiement a augmenté
parce que le temps de dépannage a diminué.

Blague #2 : une « ISO pilote universelle » est comme une télécommande universelle — géniale jusqu’à ce qu’elle contrôle la mauvaise TV et que vous coupiez votre propre réunion.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la journée

Une équipe de services financiers avait une habitude qui semblait fastidieuse : chaque trimestre ils reconstruisaient leur média de déploiement Windows
dans une VM propre, n’injectaient que les pilotes de stockage et NIC requis pour chaque classe de plateforme, et faisaient une installation de test
sur une machine représentative par classe. Ils tenaient un petit changelog : version du pilote mise à jour, raison, modèle testé et date.

Lors d’un rafraîchissement de datacenter, ils ont reçu des serveurs avec une révision de contrôleur RAID légèrement différente de ce qu’ils attendaient.
La documentation du fournisseur était ambiguë. Ça semblait identique. Ce n’était pas le cas.

Leur première installation de test l’a détecté immédiatement : pas de disques dans Setup. Au lieu de découvrir cela lors d’une coupure de minuit,
ils l’ont découvert un mardi après-midi avec du café disponible et personne en train d’appeler quelqu’un.

Parce qu’ils avaient un processus de build contrôlé, la correction a été simple : ajouter le pilote mis à jour au serveur ISO, reconstruire, relancer le test.
Le changement était documenté et facile à justifier.

La pratique ennuyeuse — builds répétables, jeux de pilotes minimaux et une installation de test sacrificielle — a sauvé le déploiement. Rien d’héroïque.
Pas de salle de crise. Juste moins de surprises.

Check-lists / plan étape par étape

Checklist A : Avant de toucher à DISM

Identifier les modèles matériels cibles et les modes de contrôleur (AHCI/RAID/VMD).
Télécharger des packages pilotes contenant des fichiers INF pour x64.
Séparer les pilotes dans des dossiers storage et nic.
Extraire les packages jusqu’à pouvoir pointer DISM sur des dossiers contenant des .inf.
Décider quelle édition Windows vous déployez (index de install.wim).

Checklist B : Étapes d’injection à suivre réellement

Extraire le contenu de l’ISO vers C:\ISO\src.
Exécuter dism /Get-WimInfo sur boot.wim et install.wim.
Monter l’index 2 de boot.wim sur C:\ISO\mount\boot.
Ajouter les pilotes de stockage et NIC avec /Add-Driver /Recurse.
Vérifier avec /Get-Drivers.
Commit/démonter.
Monter install.wim pour l’index que vous déployez.
Ajouter les mêmes pilotes (au minimum le pilote contrôleur de stockage ; généralement la NIC aussi).
Commit/démonter.
Optionnel : exporter/recompresser le WIM.
Reconstruire l’ISO avec oscdimg.
Tester le démarrage et la détection des disques sur du matériel représentatif.

Checklist C : Tests d’acceptation (ne les sautez pas)

Setup voit le disque cible sans cliquer sur « Load driver ».
Setup voit le réseau si vous en dépendez (partage de déploiement ou récupération de fichier de réponse).
Windows termine le premier démarrage sans BSOD lié au stockage.
Le Gestionnaire de périphériques dans l’OS installé ne montre aucun contrôleur de stockage inconnu.
L’ISO démarre en UEFI sur votre plateforme la plus récente et en mode legacy lorsque nécessaire.

FAQ

1) Dois‑je vraiment injecter des pilotes dans boot.wim et install.wim ?

Si vous voulez que Setup voie les disques et que l’OS installé démarre de façon fiable, oui — injectez dans les deux. boot.wim vous fait passer l’installation ;
install.wim vous fait passer le premier démarrage et au‑delà.

2) Dans quel index de boot.wim dois‑je injecter ?

Généralement l’index 2 (Windows Setup). Beaucoup d’équipes injectent dans les index 1 et 2 parce que ça coûte peu et évite les surprises dans des chemins d’amorçage alternatifs.

3) Je n’ai qu’un EXE fournisseur. DISM peut l’injecter ?

Non. DISM injecte des packages pilotes via INF. Extrayez l’EXE (souvent c’est juste un wrapper) jusqu’à obtenir .inf, .sys et .cat.

4) Pourquoi Setup dit‑il qu’un « media driver is missing » alors que je démarre clairement depuis l’USB correctement ?

Ce message d’erreur est vague. Il peut signifier pilote de stockage manquant, source média illisible, problèmes de création USB, ou Setup incapable d’accéder à install.wim.
Traitez‑le comme « Setup ne peut pas lire quelque chose dont il a besoin », puis réduisez le champ.

5) Puis‑je simplement passer le BIOS de RAID/VMD à AHCI et éviter les pilotes ?

Parfois, oui. Mais changer de mode peut casser des installations existantes et peut ne pas correspondre au standard de votre organisation. Si c’est une flotte, standardisez le firmware
et créez le média en conséquence. Les basculements aléatoires par machine ne montent pas en charge.

6) Comment gérer install.esd au lieu de install.wim ?

Convertissez‑le ou exportez‑le en WIM pour le service, injectez les pilotes, puis recomprimez éventuellement en ESD si vous avez une raison.
Si vous n’avez pas de raison, restez sur WIM — c’est plus simple opérationnellement.

7) Secure Boot bloquera‑t‑il mes pilotes injectés ?

Il peut. Les pilotes non signés ou mal signés peuvent échouer à se charger selon la politique et la plateforme. Privilégiez les packages signés WHQL et validez les métadonnées de signature avant livraison.

8) Dois‑je injecter le chipset, GPU, audio et tous les pilotes « agréables à avoir » aussi ?

Pas dans le média d’installation sauf si vous avez un besoin spécifique dans WinPE. Pour le succès de l’installation, stockage et NIC sont prioritaires.
Tout le reste peut être géré après l’installation via des outils de gestion, déploiement de pilotes ou packages OEM.

9) Comment garder cela maintenable sur plusieurs modèles matériels ?

Construisez par famille matérielle et gardez les jeux de pilotes minimaux. Versionnez vos artefacts ISO, tenez un changelog et testez sur une machine représentative par famille
avant de promouvoir le média en production.

10) Mon pilote injecté apparaît dans /Get-Drivers, mais les disques n’apparaissent toujours pas. Et maintenant ?

Confirmez que vous avez injecté dans le bon index. Confirmez le mode firmware du contrôleur. Confirmez que l’INF correspond aux IDs matériels. Et confirmez que le pilote est compatible
avec la build Windows. À ce stade, vous déboguez la réalité plateforme, pas DISM.

Étapes suivantes pour rester à l’abri des ennuis

Si vous voulez que Setup « fonctionne simplement », cessez de traiter le média d’installation comme un artefact ponctuel et commencez à le traiter comme une petite release contrôlée.
Injectez les bons pilotes dans boot.wim (Setup) et install.wim (OS installé), reconstruisez avec une chaîne d’outils appropriée et testez sur du matériel réel.

Prochaines étapes pratiques :

Créer une VM de build propre et une structure de dossiers standard pour le service ISO.
Construire un pack pilote minimal par famille matérielle (stockage + NIC d’abord).
Automatiser le workflow DISM mount/inject/commit dans un script et journaliser chaque exécution.
Maintenir un petit changelog : quel pilote a changé, pourquoi et ce qui a été testé.
Réaliser un test d’installation trimestriel sur du matériel représentatif pour détecter les surprises « même modèle, contrôleur différent » des fournisseurs.

L’objectif n’est pas de devenir un artisan des images Windows. L’objectif est d’éviter de découvrir des problèmes de pilotes devant un dirigeant,
un client ou une minuterie de fenêtre de maintenance.