Installer Windows hors ligne et récupérer des pilotes ensuite (proprement)

février 11, 2026 • février 11, 2026 • Lecture : 30 min • Views: 0

Cet article vous a aidé ?

Parfois, on veut une installation de Windows sans aucun réseau. Pas le mode « avion ». Pas un « mot de passe Wi‑Fi inconnu ». Je veux dire : pas de pilote NIC, pas de DHCP, pas d’exceptions de proxy, pas de portail captif, pas d’agent d’intégration d’entreprise « aidant ». Juste vous, une clé USB et une machine qui doit démarrer aujourd’hui.

Puis la réalité frappe : pas de pilote réseau, pilote de contrôleur de stockage manquant, le pavé tactile est mort, et le pilote GPU que Windows a choisi est aussi stable qu’une chaise pliante dans un ouragan. Vous pouvez absolument installer Windows hors ligne et ajouter des pilotes ensuite—sans transformer votre système en dépotoir de pilotes. Voici comment.

Les principes de base (ce que « propre » signifie réellement)

« Propre » ne veut pas dire « ça démarre ». Propre signifie : prévisible, pris en charge, reproductible et réversible. Si vous ne pouvez pas expliquer exactement quels pilotes sont sur le système, d’où ils viennent et comment les remplacer, vous n’avez pas une image fiable—vous avez une rumeur.

Principe 1 : Séparer « critique pour le démarrage » et « agréable à avoir »

Les pilotes critiques pour le démarrage sont ceux qui vous amènent au-delà de l’installation et sur un bureau stable : contrôleur de stockage, chipset, affichage de base et réseau (ultérieurement). Tout le reste peut attendre. Cela compte parce que Windows ne peut pas récupérer ce qu’il ne peut pas atteindre, et vous ne pouvez pas réparer le réseau sans un moyen de transférer des fichiers sur la machine.

Principe 2 : Utiliser le Driver Store, pas des exécutables aléatoires

Windows dispose d’un mécanisme formel pour les pilotes : les packages INF importés dans le Driver Store. Quand vous installez via INF, Windows sait comment préparer, revenir en arrière et choisir le pilote le mieux adapté pour le périphérique. Quand vous installez via « setup.exe », vous installez souvent un pilote plus une surprise : services, tâches planifiées, télémétrie, agents de mise à jour et icônes de zone de notification qui existent uniquement pour vous vendre de l’anxiété.

Principe 3 : Préférer les pilotes signés WHQL ou fournis par le fabricant uniquement si nécessaire

Windows Update (et le catalogue de Microsoft) contient souvent des pilotes signés WHQL fiables. Les fabricants proposent parfois des versions plus récentes. Plus récent n’est pas automatiquement mieux ; c’est juste plus récent. Vous voulez la version la plus récente qui corrige votre problème. Si le système est stable et performant, ne partez pas à la pêche aux mises à jour de pilotes comme un hobby.

Principe 4 : Rendre les changements de pilotes observables et atomiques

Avant de changer un pilote, capturez l’état actuel. Après le changement, vérifiez que le périphérique utilise bien le pilote prévu et que le système est sain. Si vous ne pouvez pas revenir en arrière ou au moins réappliquer un ensemble connu bon, vous jouez avec la production.

Principe 5 : Traitez « hors ligne » comme une fonctionnalité, pas comme un handicap

L’installation hors ligne est souvent plus sûre : pas de junk OEM téléchargé automatiquement, pas d’auto-enrôlement, pas de mises à jour de pilotes « utiles » en plein milieu de l’installation. Vous contrôlez le moment où vous introduisez le réseau et les mises à jour. C’est du pouvoir. Servez‑vous en.

Une citation pour rester honnête : L’espoir n’est pas une stratégie. — Gene Kranz

Faits et contexte qui changent votre façon de penser les pilotes Windows

La signature des pilotes est devenue une contrainte stricte sur Windows 64 bits depuis des années. C’est pourquoi « ce vieux pilote » d’un forum a tendance à échouer sur les builds modernes sans contournements douloureux.
Le Driver Store de Windows (DriverStore\FileRepository) est une zone de préparation, pas un tiroir à bazar. Windows l’utilise pour installer/annuler en toute sécurité les packages de pilotes et pour associer automatiquement les périphériques.
La certification WHQL existe parce que « ça marchait chez moi » n’est pas un plan de test. Les pilotes signés WHQL sont testés selon les exigences de compatibilité Windows.
Windows Update distribue des pilotes tiers depuis longtemps. C’est pratique, mais cela signifie aussi que des changements de pilote peuvent arriver quand vous ne regardez pas, à moins de gérer les mises à jour volontairement.
L’association via ID Plug and Play est déterministe. Si vous connaissez l’ID matériel, vous pouvez généralement trouver le bon package INF sans deviner.
Les ordinateurs portables modernes utilisent souvent des modules Wi‑Fi provenant d’une courte liste de fournisseurs. Un « bundle pilote réseau » peut couvrir une grande flotte si vous le soignez.
Beaucoup de packages « chipset » sont principalement des métadonnées INF. Ils étiquettent les périphériques pour que Windows sache ce qu’ils sont ; les gains de performance sont souvent minimes, mais la correction (états d’alimentation, nommage) compte.
Les pilotes de contrôleur de stockage sont la mine terrestre classique des installations hors ligne. Si Setup ne voit pas le disque, rien d’autre n’a d’importance. C’est pourquoi « Charger le pilote » existe encore dans Windows Setup.
Windows peut installer des pilotes depuis un média amovible automatiquement si vous le pointez vers un dossier. Vous n’avez pas besoin d’un installateur — juste des packages INF appropriés et la discipline pour les préparer proprement.

Plan propre pour passer de hors ligne à en ligne (arbre de décision)

Étape 0 : Décidez quel type de « hors ligne » vous entendez

Il y a deux scénarios :

Hors ligne pendant l’installation, en ligne ensuite : Vous installerez Windows sans réseau, puis introduirez le réseau de façon contrôlée pour récupérer les pilotes restants.
Hors ligne pour toujours (air-gapped) : Vous devez apporter tous les pilotes et mises à jour sur média amovible et maintenir un dépôt interne de pilotes.

Étape 1 : Préparer un kit de pilotes (même si vous pensez ne pas en avoir besoin)

Si vous ne pouvez pas prévoir le matériel de la machine, construisez un petit kit « universel » :

Au moins un ensemble de pilotes Ethernet filaire pour chipsets courants (Intel, Realtek).
Au moins un ensemble de pilotes Wi‑Fi pour chipsets courants (Intel, Realtek, Qualcomm/Atheros, MediaTek).
Pilotes de contrôleur de stockage pertinents pour votre environnement (Intel RST/VMD, AMD RAID, certains contrôleurs NVMe sur serveurs).
Paquets USB/Chipset si vous installez sur des plateformes inhabituelles.

Conservez-le sous forme de packages basés sur INF dans des dossiers. Pas d’outils « driver booster ». Pas d’exe mystérieux. Vous construisez un kit, pas un artefact maudit.

Blague #1 : Si votre plan de pilotes est « Je Google‑iserai ça plus tard », félicitations—vous venez d’inventer le downtime-as-a-service.

Étape 2 : Installer Windows hors ligne de façon prévisible

Utilisez un média d’installation officiel. Si Setup ne voit pas le disque, chargez les pilotes de stockage pendant Setup. Si Setup voit le disque, terminez l’installation et passez à la suite. N’installez pas les utilitaires du fabricant dans la première heure.

Étape 3 : Premier démarrage : inventaire avant de « réparer »

Au premier démarrage, obtenez une base : quels périphériques sont inconnus, quels pilotes ont été installés, quelle version/build de Windows. Cette base est votre ancre de restauration et votre preuve quand quelque chose casse plus tard.

Étape 4 : Obtenir le réseau de la manière la moins invasive

Préférez :

Ethernet filaire (généralement le plus simple, moins de pièces mobiles).
Un dongle Ethernet USB avec support de pilotes inbox (un sauveur sur les ultrabooks modernes).
Installation hors ligne du pilote NIC/Wi‑Fi intégré.

Étape 5 : Ajouter uniquement les pilotes manquants, puis valider

Installez les pilotes en les important dans le Driver Store (pnputil) ou en mettant à jour via le Gestionnaire de périphériques en pointant vers un dossier. Puis confirmez que le périphérique utilise le pilote attendu et que les journaux système sont propres.

Étape 6 : Ensuite et seulement ensuite : outils optionnels du fabricant

Si vous devez utiliser des outils de mise à jour du fabricant (Dell Command Update, Lenovo Vantage, etc.), utilisez‑les après avoir stabilisé les pilotes de base et de préférence après avoir pris un point de restauration ou un instantané (VM) ou au moins exporté l’ensemble des pilotes. Vous ajoutez de la commodité, pas vous ne bâtissez pas votre fondation dessus.

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

Ces tâches sont écrites comme si vous étiez sur une machine avec des pilotes douteux et que vous voulez la vérité, pas des impressions. Toutes les commandes sont réalistes. Les sorties sont représentatives.

Tâche 1 : Identifier l’édition/build de Windows pour la compatibilité des pilotes

cr0x@server:~$ systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
OS Name:                   Microsoft Windows 11 Pro
OS Version:                10.0.22631 N/A Build 22631

Ce que cela signifie : Vous êtes sur Windows 11, build 22631 (famille 23H2). Les packages de pilotes doivent prendre en charge le modèle WDM de Windows 11/10 ; les pilotes de l’ère Windows 7 sont probablement incompatibles.

Décision : En cas de choix entre plusieurs packages, choisissez celui explicitement compatible Windows 11 ou au moins Windows 10 21H2+.

Tâche 2 : Voir quels périphériques n’ont pas de pilotes (périphériques problématiques)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -PresentOnly | Where-Object {$_.Status -ne 'OK'} | Format-Table -Auto"
Status     Class          FriendlyName                      InstanceId
------     -----          ------------                      ----------
Error      Net            Ethernet Controller               PCI\VEN_10EC&DEV_8168&SUBSYS...
Error      Other devices  PCI Device                        PCI\VEN_8086&DEV_A0A3&SUBSYS...
Error      Other devices  SM Bus Controller                 PCI\VEN_8086&DEV_A0A4&SUBSYS...

Ce que cela signifie : Les périphériques existent mais les pilotes ne sont pas chargés. Le InstanceId vous donne les IDs fournisseur/périphérique à faire correspondre à un INF.

Décision : Priorisez les erreurs liées au Réseau et au Stockage/Chipset en premier. L’audio peut attendre ; l’accès disque non.

Tâche 3 : Extraire les IDs matériels pour trouver le bon pilote

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -InstanceId 'PCI\VEN_10EC&DEV_8168&SUBSYS_01231028&REV_15\4&2C0F6B2E&0&00E3' | Get-PnpDeviceProperty DEVPKEY_Device_HardwareIds"
KeyName                      Type        Data
-------                      ----        ----
DEVPKEY_Device_HardwareIds   StringList  {PCI\VEN_10EC&DEV_8168&SUBSYS_01231028, PCI\VEN_10EC&DEV_8168, PCI\VEN_10EC&CC_020000}

Ce que cela signifie : Famille NIC Realtek 8168. Cela réduit énormément la recherche du pilote.

Décision : Utilisez un package pilote Realtek PCIe GBE de confiance, de préférence depuis l’OEM pour le modèle ou depuis le catalogue Microsoft/Windows Update plus tard.

Tâche 4 : Lister les pilotes installés et leurs fournisseurs (repérer le bloat OEM)

cr0x@server:~$ pnputil /enum-drivers | findstr /I /C:"Published Name" /C:"Driver Package Provider" /C:"Class" /C:"Driver Version"
Published Name :            oem23.inf
Driver Package Provider :   Microsoft
Class :                     Display adapters
Driver Version :            06/21/2006 10.0.22621.1

Published Name :            oem41.inf
Driver Package Provider :   Intel
Class :                     System
Driver Version :            08/15/2023 10.1.19502.8391

Ce que cela signifie : Le pilote d’affichage de base Microsoft affiche cette fameuse date 2006 (plus de détails plus bas). Le pilote système Intel est moderne.

Décision : Si vous tenez à la performance GPU ou à la stabilité multi‑écran, installez le pilote GPU approprié. Si la machine est sans tête (headless), vous pouvez laisser l’affichage basique.

Tâche 5 : Confirmer quel pilote un périphérique utilise réellement

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Net | Select-Object FriendlyName,Driver,Status | Format-Table -Auto"
FriendlyName                           Driver     Status
------------                           ------     ------
Realtek PCIe GbE Family Controller     oem77.inf   OK

Ce que cela signifie : La NIC est maintenant liée à oem77.inf et fonctionne.

Décision : Vous pouvez maintenant mettre la machine en ligne et laisser Windows Update récupérer les pilotes restants—après avoir défini les attentes politiques.

Tâche 6 : Installer un package pilote depuis un dossier (import INF propre)

cr0x@server:~$ pnputil /add-driver "D:\Drivers\NIC\Realtek\*.inf" /subdirs /install
Processing inf :            netrtx64.inf
Driver package added successfully.
Published Name :            oem77.inf
Driver package installed on matching devices.

Ce que cela signifie : Le pilote est préparé dans le Driver Store et installé sur le matériel correspondant.

Décision : Si le message dit « added successfully » mais pas installé, vous n’avez sans doute pas d’IDs matériels correspondants ; arrêtez et vérifiez les IDs au lieu d’essayer d’installer par la force.

Tâche 7 : Exporter des pilotes depuis une machine connue bonne (construire votre kit)

cr0x@server:~$ dism /online /export-driver /destination:"E:\DriverKit\FromKnownGood"
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Exporting driver packages...
[==========================100.0%==========================]
The operation completed successfully.

Ce que cela signifie : Vous avez maintenant un dossier rempli de packages INF de pilotes réutilisables hors ligne. Ce n’est pas parfait (il inclut beaucoup), mais c’est légitime et reproductible.

Décision : Curatez cet export. Conservez seulement les classes nécessaires pour votre flotte, et versionnez-le comme du code.

Tâche 8 : Injecter des pilotes dans le média Windows hors ligne (WIM) pour que Setup voit disques/NIC

cr0x@server:~$ mkdir C:\Mount
cr0x@server:~$ dism /mount-wim /wimfile:"D:\sources\install.wim" /index:1 /mountdir:"C:\Mount"
Mounting image
[==========================100.0%==========================]
The operation completed successfully.

cr0x@server:~$ dism /image:"C:\Mount" /add-driver /driver:"E:\DriverKit\Storage" /recurse
[==========================100.0%==========================]
The operation completed successfully.

cr0x@server:~$ dism /unmount-wim /mountdir:"C:\Mount" /commit
[==========================100.0%==========================]
The operation completed successfully.

Ce que cela signifie : Ces pilotes seront présents dans l’image OS installée, ce qui est la façon la plus propre d’éviter le drame « Charger le pilote » pendant Setup.

Décision : Injectez uniquement ce dont vous avez besoin (stockage + peut‑être NIC). Plus vous injectez, plus vous vous exposez à devoir gérer un mauvais pilote intégré à chaque machine.

Tâche 9 : Vérifier l’état de BitLocker avant des changements de pilotes sur des appareils d’entreprise

cr0x@server:~$ manage-bde -status C:
Volume C: [OS]
    Size:                 475.10 GB
    BitLocker Version:    2.0
    Conversion Status:    Fully Encrypted
    Percentage Encrypted: 100.0%
    Protection Status:    Protection On
    Lock Status:          Unlocked
    Identification Field: Unknown
    Key Protectors:
        TPM

Ce que cela signifie : BitLocker est actif et lié au TPM. Certains changements de firmware/chaîne de démarrage déclenchés par des échanges de pilotes de stockage peuvent provoquer des invites de récupération.

Décision : Si vous touchez aux modes du contrôleur de stockage (AHCI/RAID/VMD), planifiez d’abord la suspension de BitLocker et l’accès aux clés de récupération.

Tâche 10 : Forcer Windows à rechercher un chemin local pour les pilotes (sans Internet)

cr0x@server:~$ powershell -NoProfile -Command "pnputil /add-driver 'E:\DriverKit\Network\*.inf' /subdirs"
Driver package added successfully.
Published Name :            oem91.inf

Ce que cela signifie : Le package de pilotes est préparé. Si le périphérique est présent et correspond, vous pouvez ajouter /install, ou utiliser le Gestionnaire de périphériques pour mettre à jour le pilote et pointer vers le dossier.

Décision : Utilisez /install quand vous êtes confiant ; sinon préparez d’abord, puis associez délibérément.

Tâche 11 : Vérifier si Windows est bloqué sur le pilote GPU « basique » et pourquoi c’est important

cr0x@server:~$ dxdiag /t "%TEMP%\dxdiag.txt" & type "%TEMP%\dxdiag.txt" | findstr /I /C:"Card name" /C:"Driver Version"
Card name: Microsoft Basic Display Adapter
Driver Version: 10.0.22621.1

Ce que cela signifie : Vous utilisez un pilote générique. Il fonctionne pour « l’écran affiche des pixels » mais pas pour la gestion d’alimentation, les stations d’accueil, les taux de rafraîchissement élevés ou le calcul GPU.

Décision : Installez le pilote GPU OEM si c’est un portable/de bureau. Pour un serveur uniquement utilisé via RDP, vous pouvez le laisser si cela ne cause pas de problèmes d’affichage.

Tâche 12 : Vérifier le Visualiseur d’événements pour des échecs de chargement de pilotes (signal rapide)

cr0x@server:~$ wevtutil qe System /q:"*[System[(Level=2) and (Provider[@Name='Service Control Manager'])]]" /c:5 /f:text
Event[0]:
  Provider Name: Service Control Manager
  Event ID: 7000
  Level: Error
  Description:
  The Intel(R) Management Engine Interface service failed to start due to the following error:
  The system cannot find the file specified.

Ce que cela signifie : Mismatch pilote/service : le service installé attend un binaire qui n’est pas présent, ou l’installation du pilote a été incomplète.

Décision : Réinstallez proprement ce package de pilote (de préférence INF), ou supprimez le package cassé s’il n’est pas essentiel. N’ignorez pas les erreurs répétées du SCM ; elles ajoutent du temps de démarrage et de l’instabilité.

Tâche 13 : Confirmer le pilote du contrôleur de stockage et le mode (éviter les boucles de démarrage)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class SCSIAdapter | Format-Table -Auto"
Status Class       FriendlyName                          InstanceId
------ -----       ------------                          ----------
OK     SCSIAdapter Standard NVM Express Controller        PCI\VEN_144D&DEV_A808&SUBSYS...
OK     SCSIAdapter Intel(R) Volume Management Device...   PCI\VEN_8086&DEV_9A0B&SUBSYS...

Ce que cela signifie : Vous avez Intel VMD en jeu. Le mode de stockage compte ; de mauvais changements de pilote peuvent faire disparaître le disque au redémarrage.

Décision : Si le stockage est stable, ne « optimisez » pas les pilotes de stockage à la légère. Si vous devez changer le mode BIOS (VMD/AHCI), planifiez‑le comme une migration.

Tâche 14 : Supprimer un package pilote spécifique (quand vous savez que c’est le coupable)

cr0x@server:~$ pnputil /delete-driver oem132.inf /uninstall /force
Driver package deleted successfully.

Ce que cela signifie : Le package est supprimé du Driver Store et désinstallé des périphériques qui l’utilisaient (de force).

Décision : Ne faites cela que lorsque vous avez une alternative prête ou que vous effectuez un rollback d’une mise à jour mauvaise. Supprimer des pilotes réseau/stockage sans plan de secours est de l’art performance.

Tâche 15 : Vérifier les paramètres de livraison des pilotes par Windows Update (contrôler le chaos)

cr0x@server:~$ reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching" /v SearchOrderConfig
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching
    SearchOrderConfig    REG_DWORD    0x1

Ce que cela signifie : La recherche de pilotes est activée (la valeur varie selon la politique/version). En environnement géré, la stratégie de groupe ou MDM peut outrepasser cela.

Décision : En entreprise, définissez une politique : soit vous autorisez largement les pilotes Windows Update, soit vous les retenez. L’indécision cause des tickets « ça a changé pendant la nuit ».

Tâche 16 : Créer un point de restauration avant une vague risquée de pilotes (si la Protection du Système est activée)

cr0x@server:~$ powershell -NoProfile -Command "Checkpoint-Computer -Description 'Pre-driver-install' -RestorePointType 'MODIFY_SETTINGS'"

Ce que cela signifie : Point de restauration créé (aucune sortie n’est normale). Si cela échoue, la Protection du Système peut être désactivée ou bloquée par une politique.

Décision : Utilisez les points de restauration sur les postes quand c’est autorisé. Sur les serveurs, appuyez‑vous plutôt sur des fenêtres de changement testées et des sauvegardes basées image.

D’où doivent venir les pilotes (et d’où ils ne doivent pas venir)

Les bonnes sources (classées)

Windows Update (après que vous ayez la stabilité de base) : Utile pour les périphériques grand public, surtout NICs et chipsets.
Packages pilote OEM pour votre gamme de modèles : Surtout pour les portables/stations d’accueil, où les interactions alimentation/firmware comptent.
Pilotes fournisseurs de puces (Intel/AMD/NVIDIA/Realtek) : Utile quand l’OEM est lent, mais vous devez valider selon votre matériel et cas d’usage.
Pilotes exportés depuis des machines connues bonnes : Excellents pour construire un kit hors ligne. Traitez‑les comme une graine, pas un évangile.

Les mauvaises sources

Utilitaires « mise à jour de pilotes » : Ils optimisent pour l’installation, pas pour la correction. Ils aiment aussi empaqueter des adwares et des « gestionnaires de performance ».
Sites de repackages aléatoires : Si le package pilote n’est pas signé et traçable, vous importez du risque directement en mode noyau. Ce n’est pas audacieux ; c’est imprudent.
Mises à jour automatiques non épinglées des fabricants : Elles peuvent tirer différentes versions jour après jour. Super pour le chaos engineering, mauvais pour les systèmes critiques.

Blague #2 : Installer des pilotes depuis des sites non vérifiés est une excellente façon de rencontrer votre futur vous, qui remplira des rapports d’incident à 2 h du matin.

Trois mini-histoires en entreprise depuis le terrain

Mini‑histoire 1 : L’incident causé par une fausse hypothèse

Une entreprise de taille moyenne a déployé un processus d’« imagerie sécurisée hors ligne » pour des portables utilisés dans un laboratoire restreint. L’idée était sensée : imager hors ligne, puis joindre le domaine plus tard sur un segment réseau contrôlé. L’équipe a supposé que les pilotes inbox de Windows prendraient en charge le réseau « suffisamment » pour le premier cycle de mise à jour.

Ça a plutôt fonctionné—jusqu’à ce qu’une nouvelle révision du portable arrive avec un autre chipset Wi‑Fi. Même nom de modèle, même SKU d’achat chez le revendeur, silicium différent à l’intérieur. L’imagerie hors ligne s’est terminée, mais au premier démarrage il n’y avait ni Wi‑Fi ni Ethernet parce que la station d’accueil nécessitait aussi un pilote. Les portables étaient des briques à moins d’avoir déjà un chemin de pilotes dans le système.

Ils ont essayé l’évidence : brancher une station d’accueil, utiliser une clé USB, utiliser un hotspot phone. Le hotspot nécessitait encore le Wi‑Fi. La NIC de la station d’accueil avait besoin d’un pilote. La clé USB a fonctionné, mais seulement une fois qu’ils ont trouvé le bon package pilote et réalisé que c’était un exécutable qui refusait de s’exécuter sans composants .NET absents.

La solution a été ennuyeuse : construire un petit kit de pilotes hors ligne contenant des pilotes NIC INF pour les principaux fournisseurs, plus un dongle Ethernet USB qui fonctionne avec les pilotes inbox. Ils ont aussi commencé à capturer les IDs matériels pour chaque nouvelle révision d’achat avant l’imagerie. L’incident n’a pas été causé par la complexité. Il a été causé par l’hypothèse que l’identité matérielle reste stable parce que la paperasse d’achat l’est.

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

Une autre organisation voulait des déploiements plus rapides, alors elle a décidé d’injecter « tous les pilotes pour tous les modèles » dans l’image Windows. L’objectif : une WIM unique pour les gouverner tous. Stockage, chipset, audio, caméra, pavé tactile, stations d’accueil—tout. Ils avaient un dossier partagé plein de packages pilotes, ont pointé DISM sur lui avec /recurse et ont considéré le travail fait.

Au début, ça ressemblait à une victoire. Setup reconnaissait les disques partout, et le Gestionnaire de périphériques avait moins de points d’exclamation jaunes. L’équipe a célébré, puis a continué d’ajouter des pilotes chaque trimestre. L’image a grossi. Setup est devenu plus lent. Plus important : la détection des périphériques au démarrage a commencé à sélectionner des correspondances étranges, surtout pour des périphériques similaires entre fournisseurs.

La première vraie douleur est apparue sous forme d’écrans bleus intermittents sur une ligne de portables spécifique. Seulement certaines unités. Seulement après mise en veille/reprise. Cause racine : un package pilote injecté incluait un filtre destiné à une variante différente de pavé tactile. Ce n’était pas « malveillant », juste suffisamment erroné pour déstabiliser la pile sous certaines transitions d’alimentation.

Ils ont résolu le problème en faisant ce qu’ils ne voulaient pas faire initialement : séparer la stratégie d’image. Une image de base maigre, plus des bundles pilotes spécifiques par modèle appliqués au moment du déploiement. Ils ont gardé les pilotes critiques pour le démarrage (stockage) dans l’image de base, mais tout le reste est devenu ciblé. L’optimisation a échoué parce qu’elle a troqué la vitesse de déploiement pour la correction à long terme—et la correction accumule toujours sa dette.

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

Une société financière gérait des postes Windows avec un contrôle de changement strict. Aucune mise à jour de pilote sans ticket. Les gens se moquaient en disant que c’était lent. Puis une mise à jour du pilote graphique provenant de Windows Update a provoqué des scintillements et des blocages d’application sur un sous‑ensemble de machines avec une certaine station d’accueil + configuration multi‑écrans.

L’équipe qui avait « laissé Windows gérer les pilotes » a été submergée. Pendant ce temps, le groupe strict avait épinglé les mises à jour pilotes via une stratégie et les avait planifiées par vagues. Ils avaient une base claire : listes de pilotes exportées par ligne de modèle, et des hachages de packages connus bons dans leur dépôt interne.

Quand les rapports ont commencé à arriver d’autres départements, ils n’ont pas paniqué. Ils ont exécuté leurs commandes d’audit, confirmé que la version problématique n’était pas présente, et ont continué leur activité. Ils ont aussi rapidement testé le mauvais pilote dans un petit labo, puis ajouté une règle de blocage et un avis interne.

La pratique ennuyeuse n’était pas le système de tickets. C’était la visibilité : savoir quelles versions de pilotes étaient installées, et avoir une méthode reproductible pour appliquer (ou ne pas appliquer) de nouvelles versions. Ça a sauvé la mise parce que le meilleur incident est celui que vous regardez arriver chez quelqu’un d’autre.

Feuille de route de diagnostic rapide

Quand une machine Windows fraîchement installée hors ligne est mécontente, vous traitez généralement une des goulots d’étranglement suivants : visibilité du stockage, capacité réseau, ou un pilote défectueux provoquant de l’instabilité. Ne vous égarez pas. Trier.

Premièrement : Le système voit‑il son disque et démarre‑t‑il de façon fiable ?

Si Setup n’a pas pu voir le disque : vous avez besoin de pilotes de stockage pendant Setup ou injectés dans la WIM.
Si le système démarre mais est lent/bloqué : vérifiez le journal Système pour des échecs de démarrage de pilotes/services et des problèmes de stockage/contrôleur.

Deuxièmement : Pouvez‑vous obtenir un chemin réseau sans installer une pile de logiciels ?

Tentez d’abord l’Ethernet filaire.
Si pas de pilote NIC : utilisez un adaptateur Ethernet USB qui utilise des pilotes inbox, ou installez le pilote NIC via pnputil depuis votre kit.
Une fois en ligne, décidez si les pilotes Windows Update sont autorisés pour cette classe de machine.

Troisièmement : Y a‑t‑il des périphériques inconnus avec des IDs matériels clairs ?

Inventoriez les périphériques problématiques.
Extraites les IDs matériels.
Faites correspondre à un package pilote de confiance.

Quatrièmement : Le système est‑il stable en veille/reprise, dock/undock et sous charge ?

Les pilotes Graphiques + Chipset + gestion d’alimentation tendent à faire apparaître des problèmes ici.
Validez avec les journaux d’événements et une boucle de tests fonctionnels rapide.

Erreurs courantes : symptôme → cause → correctif

1) « Aucun disque trouvé » pendant Windows Setup

Symptôme : L’installateur Windows ne voit pas le SSD/NVMe interne.

Cause : Pilote de contrôleur de stockage manquant (commun avec les configurations Intel VMD/RST) ou mode RAID sans pilotes.

Correctif : Charger le pilote de stockage approprié pendant Setup depuis USB, ou l’injecter dans la WIM d’installation via DISM. Si la politique le permet, basculer le mode de stockage du BIOS en AHCI uniquement seulement si vous comprenez BitLocker et les implications de démarrage.

2) Après l’installation : pas d’Ethernet, pas de Wi‑Fi, et vous ne pouvez rien télécharger

Symptôme : Le Gestionnaire de périphériques affiche « Ethernet Controller » inconnu ; pas d’adaptateurs dans Paramètres.

Cause : Pilote NIC manquant ; parfois l’OEM a utilisé une nouvelle révision non couverte par les pilotes inbox.

Correctif : Utilisez un kit pilote hors ligne avec des packages INF NIC et installez via pnputil /add-driver ... /install. Ou utilisez un dongle Ethernet USB connu qui est pris en charge par les pilotes inbox pour amorcer les mises à jour en ligne.

3) Vous avez installé le « package pilote », mais le périphérique est toujours inconnu

Symptôme : L’installateur a tourné, redémarré, et il y a toujours un point d’exclamation jaune.

Cause : Le package n’incluait pas un INF correspondant à vos IDs matériels, ou il a installé seulement une application de contrôle sans le pilote.

Correctif : Récupérez les IDs matériels et vérifiez la correspondance. Préférez les installations basées INF ; décompressez les EXE du fabricant si nécessaire et installez via INF.

4) Boucle de démarrage ou invite BitLocker après un changement de pilote de stockage

Symptôme : Windows ne démarre pas ou demande la clé de récupération après un changement de réglage BIOS/stockage.

Cause : Un changement du mode contrôleur de stockage (VMD/RAID/AHCI) a modifié la chaîne de démarrage ; BitLocker détecte une configuration différente. Ou le pilote nécessaire n’est pas activé au démarrage.

Correctif : Restaurez le réglage BIOS d’origine, démarrez, suspendez BitLocker, déployez les bons pilotes de stockage, puis effectuez la transition avec un runbook testé.

5) Écrans bleus aléatoires après un « nettoyage de pilotes »

Symptôme : BSODs après suppression de vieux pilotes ou exécution de scripts de nettoyage.

Cause : Vous avez supprimé un package pilote encore nécessaire à un périphérique, ou retiré un filtre incorrectement.

Correctif : Réinstallez des pilotes connus bons ; évitez les purges indiscriminées du Driver Store. Utilisez pnputil pour supprimer des packages spécifiques seulement quand vous pouvez vérifier qu’ils ne sont pas en cours d’utilisation.

6) La performance est pire après l’installation des derniers pilotes GPU ou chipset

Symptôme : Saccades, consommation d’énergie plus élevée, ventilateurs actifs, ou dysfonctionnements avec une station d’accueil.

Cause : Le pilote récent a changé des paramètres par défaut ou introduit une régression avec votre firmware/station d’accueil/chaîne d’écrans.

Correctif : Revenez à la version connue bonne, puis épinglez les versions. Mettez à jour firmware et pilotes comme un ensemble testé, pas comme des expériences unitaires aléatoires.

7) Windows Update réinstalle en permanence un pilote que vous ne voulez pas

Symptôme : Vous faites un rollback d’un pilote ; il revient.

Cause : La politique de mise à jour permet les pilotes ; Windows considère la mise à jour comme de rang supérieur.

Correctif : En entreprise, utilisez les contrôles de politique/MDM pour bloquer des pilotes ou des mises à jour spécifiques. Sur une machine autonome, ajustez les paramètres de distribution des pilotes et utilisez les restrictions d’installation de périphériques si nécessaire.

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

Checklist A : Installation minimale hors ligne qui ne vous hantera pas

Commencez avec un média d’installation Windows propre (non modifié).
Apportez une clé USB contenant :
- Dossiers de pilotes NIC INF (Intel + Realtek au minimum).
- Dossiers de pilotes de stockage INF pertinents pour votre matériel (RST/VMD si applicable).
- Un fichier texte où vous notez modèle machine, version BIOS et toute déviation.
Installez Windows hors ligne.
Premier démarrage : capturez l’état de base des périphériques/pilotes.
Installez seulement ce dont vous avez besoin pour obtenir un réseau stable.
Mettre le réseau en ligne et exécuter des mises à jour contrôlées (d’abord OS, puis pilotes si autorisé).
Installez GPU/chipset seulement si nécessaire pour votre charge de travail (les portables généralement oui).
Redémarrez, validez, exportez l’ensemble des pilotes pour réutilisation future.

Checklist B : Construire un kit de pilotes hors ligne maintenable

Créez une structure de dossiers par classe et fournisseur (Network, Storage, Chipset, GPU).
Préférez les packages qui incluent INF/CAT/SYS (pas juste des installateurs).
Enregistrez :
- Version du pilote
- Versions OS prises en charge
- IDs matériels couverts (au moins les principaux)
- Source (OEM vs Microsoft vs fournisseur de puce)
Testez sur au moins une machine par ligne de modèle.
Gardez le kit léger. Supprimez ce dont vous n’avez pas besoin.
Versionnez le kit (date dans le nom du dossier suffit en interne ; ne l’intégrez pas dans vos hypothèses d’image « golden »).

Checklist C : Si vous devez injecter des pilotes dans une WIM

Injectez uniquement les pilotes critiques pour le démarrage sauf raison forte.
Montez la WIM, ajoutez les pilotes, validez, puis documentez précisément ce que vous avez injecté.
Conservez la WIM d’origine inchangée pour pouvoir comparer les comportements.
Testez Setup sur du matériel réel qui échouait auparavant.
Re‑testez après chaque actualisation du média Windows.

FAQ

1) Puis‑je installer Windows 11 complètement hors ligne ?

Oui. Vous pouvez devoir contourner les exigences réseau pendant le setup selon l’édition et le build, mais côté pilotes c’est faisable. Le vrai problème est d’avoir les pilotes de stockage/NIC disponibles si les pilotes inbox ne couvrent pas votre matériel.

2) Pourquoi certains pilotes Microsoft affichent‑ils une date « 2006 » ?

C’est une convention de compatibilité utilisée pour les pilotes inbox afin que les pilotes fournisseurs puissent avoir un meilleur classement par date/version. Ne l’interprétez pas comme du « code ancien » ; interprétez‑la comme une « base générique ».

3) Le bouton « Mettre à jour le pilote » du Gestionnaire de périphériques est‑il meilleur que les installateurs du fabricant ?

Souvent, oui. Pointer le Gestionnaire de périphériques vers un dossier de pilotes INF (ou utiliser pnputil) installe seulement le package pilote. Les installateurs fournisseurs ajoutent fréquemment des logiciels supplémentaires qui compliquent le dépannage.

4) Quelle est la différence entre préparer (staging) un pilote et l’installer ?

La préparation ajoute le package pilote au Driver Store. L’installation le lie au matériel correspondant. La préparation est plus sûre quand vous n’êtes pas sûr de la correspondance ; l’installation est appropriée quand vous la connaissez.

5) Dois‑je injecter tous les pilotes dans l’image d’installation pour que tout fonctionne immédiatement ?

Non, sauf si vous aimez déboguer des problèmes de sélection de pilotes cross‑model. Injectez les pilotes critiques pour le démarrage ; appliquez les bundles spécifiques au modèle après l’installation si vous avez besoin de rapidité.

6) Comment gérer les pilotes sur des systèmes air‑gapped ?

Construisez un kit de pilotes interne et traitez‑le comme un logiciel contrôlé. Utilisez des pilotes signés, conservez les versions, testez les changements et installez via INF/Driver Store. Planifiez aussi la manière dont vous gérerez les mises à jour de firmware, qui sont un casse‑tête connexe.

7) Puis‑je copier des pilotes depuis une autre machine et les coller dans System32 ?

Vous pouvez, mais vous ne devriez pas. Les pilotes appartiennent au Driver Store avec des métadonnées INF et des signatures appropriées. La copie manuelle de fichiers crée des systèmes qui « fonctionnent » jusqu’au prochain reboot, mise à jour ou ré‑énumération du périphérique.

8) Quelle est la façon la plus sûre d’obtenir le réseau sur une machine sans pilotes NIC ?

Utilisez un adaptateur Ethernet USB qui fonctionne avec les pilotes inbox, ou installez le pilote NIC depuis un kit hors ligne sélectionné en utilisant pnputil. Évitez les méthodes de tethering qui nécessitent un Wi‑Fi fonctionnel.

9) Comment savoir quel package pilote correspond à un nom INF OEM comme oem77.inf ?

Utilisez pnputil /enum-drivers et cherchez ce nom publié pour voir le fournisseur, la classe et la version. À partir de là, décidez si c’est celui que vous vouliez ou un fallback générique.

10) Quand devrais‑je laisser Windows Update installer des pilotes automatiquement ?

Sur des machines grand public, généralement c’est acceptable. Sur des flottes gérées, décidez intentionnellement : soit vous l’autorisez avec surveillance, soit vous le restreignez et déployez les pilotes par vagues contrôlées. « Parfois oui » est la voie vers des régressions surprises.

Conclusion : quoi faire ensuite

Installer Windows hors ligne et nettoyer les pilotes ensuite n’est pas un bricolage. C’est un flux de travail discipliné : obtenir un OS démarrable, inventorier la réalité, mettre le réseau en ligne délibérément, puis installer seulement les pilotes réellement nécessaires—via le Driver Store—en gardant des options de retour en arrière.

Prochaines étapes pratiques :

Construisez dès aujourd’hui un petit kit pilote hors ligne (NIC + stockage). Mettez‑le sur une clé USB et étiquetez‑la sérieusement.
Sur une machine connue bonne, exportez les pilotes avec DISM et curatez le résultat dans votre kit.
Pratiquez le scénario « pas de pilote réseau » une fois, volontairement, pour ne pas le découvrir lors d’une panne.
Pour les flottes : rédigez votre politique de pilotes—qui met à jour, depuis où, et comment vous faites un rollback.

L’objectif n’est pas d’avoir les pilotes les plus récents. L’objectif est d’avoir les bons pilotes, installés correctement, avec le moins de drame possible. Le drame appartient au théâtre, pas au mode noyau.