Exporter les pilotes installés vers un dossier (pour des réinstallations sans douleur)

février 20, 2026 • février 20, 2026 • Lecture : 28 min • Views: 1

Cet article vous a aidé ?

Le fantasme de la réinstallation propre ressemble à ceci : effacer, installer, mettre à jour, terminé. La réalité est plutôt :
votre Wi‑Fi a disparu, votre pavé tactile est « une souris » et le Gestionnaire de périphériques ressemble à une exposition de triangles jaunes.
Quelque part au milieu, vous vous rappelez que votre portable ne fonctionne correctement que lorsqu’on lui donne les bons pilotes.

La solution n’est pas un outil magique de mise à jour de pilotes. C’est une exportation disciplinée des pilotes que vous savez déjà fonctionnels,
stockés dans un dossier que vous contrôlez, validés et prêts pour une installation hors ligne. C’est une hygiène opérationnelle de base.
Ça vous fait aussi paraître professionnel quand vous reconstruisez des machines à grande échelle.

Ce que vous exportez réellement (et ce que vous n’exportez pas)

Sur les versions récentes de Windows, les « pilotes » ne sont pas une pile lâche de DLL éparpillées dans C:\Windows.
La source canonique est le Driver Store sous C:\Windows\System32\DriverStore\FileRepository.
Lorsqu’un périphérique est installé, Windows met en scène un package de pilote dans le Driver Store (INF + catalogue + binaires),
puis crée l’association spécifique au périphérique. Cette mise en scène est le concept clé : si le package est mis en scène,
vous pouvez généralement l’exporter.

Quand les gens disent « exporter les pilotes installés », ils veulent généralement dire « exporter les packages de pilotes mis en scène
depuis le Driver Store ». C’est une bonne nouvelle : c’est la chose la plus proche d’un cache de gestionnaire de paquets sous Windows.
C’est aussi pourquoi une réinstallation peut être sans douleur : vous réapportez des packages connus pour être bons.

Ce que vous n’êtes pas en train d’exporter :

Firmware (BIOS/UEFI, firmware de SSD, NVM Thunderbolt, firmware de dock). C’est une chaîne de déploiement différente.
Panneaux de contrôle et applications fournisseurs (suites GPU, consoles audio, tableaux de bord « optimiseurs »).
Ce sont des applications. Certaines sont utiles ; beaucoup sont du confettis.
Le comportement futur de Windows Update. L’exportation n’empêche pas Windows de « vous aider » plus tard.
Tokens de licence pour certains outils propriétaires liés aux pilotes. L’exportation des packages INF ne réglera pas cela.

Si votre objectif est « la machine démarre avec le réseau, l’affichage, le stockage et les entrées fonctionnels », l’exportation des pilotes est
exactement la bonne opération. Si votre objectif est « chaque widget OEM retrouve la même apparence », vous êtes plutôt dans le domaine de l’imagerie et du packaging applicatif. Sport différent.

Faits intéressants et contexte historique (pour comprendre les bizarreries)

Windows XP a popularisé l’ère du « CD de pilotes » parce que les pilotes inclus étaient maigres et le matériel changeait vite.
Cela a entraîné une génération à thésauriser les installateurs comme des rations.
Vista a introduit le modèle moderne du Driver Store pour réduire la « roulette des DLL » et rendre les installations de pilotes plus transactionnelles.
Il a aussi rendu le service des pilotes moins hanté.
La signature WHQL et les catalogues (.cat) sont devenus le levier d’application pour la sécurité en mode noyau. C’est pourquoi les pilotes noyau non signés sont aujourd’hui source de problèmes.
DISM a évolué d’un outil de déploiement à un couteau suisse pour le service hors ligne, incluant les pilotes dans les images Windows hors ligne.
Les « DCH drivers » (Declarative, Componentized, Hardware Support Apps) ont changé la façon dont certains fournisseurs livrent les piles graphiques/audio : plus de pilote, moins d’installateurs hérités.
La livraison de pilotes via Windows Update est devenue courante à l’ère de Windows 10, ce qui a réduit les installations manuelles et augmenté les « rétrogradations surprises ».
Le classement des pilotes est un vrai algorithme (correspondance, signature, date, version). Windows ne choisit pas « le plus récent », il choisit « la meilleure correspondance » selon des règles.
Les INF restent la vérité. Même avec des installateurs sophistiqués, si vous ne pouvez pas raisonner à propos de l’INF et de ses hardware IDs, vous devinez.

Playbook de diagnostic rapide : pourquoi votre export/restore est lent ou échoue

Lors de l’exportation de pilotes ou de leur restauration après une réinstallation, vous pouvez perdre des heures au mauvais endroit.
Voici l’ordre de triage qui rapporte.

Première étape : confirmez que vous exportez depuis la bonne source (Driver Store) et que vous avez les permissions suffisantes

Si pnputil échoue avec des erreurs d’accès, vous n’êtes pas élevé.
Si vous avez exporté depuis des dossiers fournisseurs au hasard, vous avez exporté des ambiances, pas des pilotes.

Deuxième étape : identifiez la classe de pilotes en échec (réseau/stockage/affichage) et priorisez le bootstrap

Pas de réseau après réinstallation ? Vous avez besoin des pilotes NIC/Wi‑Fi d’abord, avant de pouvoir « simplement les télécharger ».
Contrôleur de stockage manquant ? Votre média d’installation peut ne même pas voir le disque. C’est un problème pré-installation.

Troisième étape : vérifiez l’application des signatures et le mismatch d’architecture

Les pilotes hérités non signés ou signés croisés peuvent se mettre en scène mais ne pas s’associer, surtout sur les builds Windows récents.
Le mismatch x86 vs x64 existe toujours. C’est plus rare maintenant, mais quand ça arrive c’est un arrêt net.

Quatrième étape : trouvez le goulot d’étranglement (IO, antivirus, longueur du chemin, ou volume pur)

Les exports peuvent être lents si vous écrivez sur une clé USB défaillante ou si un antivirus scanne chaque fichier de manière agressive.
Les packages du Driver Store peuvent être nombreux. Si vous exportez un système ancien, attendez‑vous à des milliers de fichiers.

Cinquième étape : décidez si vous avez besoin de « tout » ou « seulement des périphériques critiques »

Exporter tout est simple. Restaurer tout peut causer des conflits si vous importez des packages GPU/audio obsolètes.
Pour des flottes, préférez une baseline sélectionnée plus des add-ons spécifiques au modèle.

Règles d’or : quoi faire, quoi éviter

Vous visez deux résultats : (1) un dossier qui contient réellement des packages de pilotes installables, et (2) un processus de restauration déterministe sous pression. Les règles suivantes séparent « j’ai sauvegardé mes pilotes » de « j’ai fait un dossier rempli d’espoir ».

Exportez depuis le Driver Store en utilisant des outils pris en charge. Utilisez pnputil et DISM.
Ne grattez pas System32 et appelez cela un succès.
Conservez l’export en lecture seule une fois créé. Copiez‑le, archivez‑le, checksummez‑le. Ne « nettoyez » pas en supprimant des fichiers que vous ne reconnaissez pas.
Séparez « pilotes » et « logiciels ». Si vous avez besoin des applications fournisseurs, empaquetez‑les séparément.
Les mélanger rend le dépannage pénible.
Enregistrez les hardware IDs pour les périphériques critiques. Surtout NIC et contrôleur de stockage. C’est votre carte quand Windows fait l’idiot.
Privilégiez des importations propres. Après réinstallation, mettez en scène ce dont vous avez besoin, vérifiez, puis laissez Plug and Play associer les périphériques.
Ne traitez pas les mises à jour de pilotes comme des mises à jour de navigateur. Plus récent n’est pas toujours mieux ; « fonctionne avec votre matériel et votre build OS » est mieux.

Une vérité opérationnelle de plus : les exports de pilotes sont des machines à remonter le temps. Les machines à remonter le temps sont utiles, mais elles réintroduisent aussi d’anciens bogues avec confiance.

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

Toutes les commandes ci‑dessous supposent que vous êtes sur Windows, mais les blocs de console sont formatés comme des transcriptions shell pour la lisibilité.
Exécutez‑les dans un PowerShell ou un Invite de commandes élevé sauf indication contraire.

Tâche 1 : Confirmer la build et l’édition de Windows (importante pour la politique de pilotes)

cr0x@server:~$ cmd /c ver
Microsoft Windows [Version 10.0.19045.4046]

Ce que cela signifie : Le numéro de build influence l’application des signatures de pilotes, la disponibilité des pilotes inclus et les attentes des packages fournisseurs.
Décision : Si vous passez entre des versions majeures (par ex., 19045 à 22631), attendez‑vous à ce que certains pilotes hérités refusent de se charger.

Tâche 2 : Vérifier si vous êtes élevé (l’export requiert l’admin)

cr0x@server:~$ powershell -NoProfile -Command "[Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent().IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)"
True

Ce que cela signifie : True signifie que vous pouvez exporter depuis le Driver Store et installer des packages.
Décision : Si False, arrêtez. Relancez votre shell en « Exécuter en tant qu’administrateur ». Ne déboguez pas des problèmes de permissions fantômes.

Tâche 3 : Exporter tous les pilotes mis en scène avec pnputil (le cheval de travail)

cr0x@server:~$ pnputil /export-driver * "D:\DriverExport\WIN10-19045"
Exporting driver package: oem42.inf
Driver package exported successfully.
Exporting driver package: oem43.inf
Driver package exported successfully.
...
Total driver packages: 186
Exported driver packages: 186

Ce que cela signifie : Vous avez exporté les packages actuellement mis en scène dans le Driver Store. Chaque oemXX.inf correspond à un package.
Décision : Si le nombre exporté est curieusement bas, vous êtes peut‑être sur une installation fraîche (peu de packages) ou vous n’êtes pas élevé.

Tâche 4 : Exporter les pilotes avec DISM (utile pour le scripting et les contrôles de parité)

cr0x@server:~$ dism /online /export-driver /destination:"D:\DriverExport\WIN10-19045-DISM"
Deployment Image Servicing and Management tool
Version: 10.0.19041.3636

Exporting driver packages...
The operation completed successfully.

Ce que cela signifie : DISM a exporté les pilotes depuis l’OS en cours d’exécution (« image en ligne »).
Décision : Si DISM réussit mais pnputil échoue (ou vice versa), vous avez appris quelque chose sur la politique/les permissions ; conservez l’export réussi.

Tâche 5 : Vérifier que l’export contient des INF et des catalogues (pas seulement des binaires)

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -Recurse D:\DriverExport\WIN10-19045 -Include *.inf,*.cat | Select-Object -First 5 | Format-Table -AutoSize Name,Directory"
Name        Directory
----        ---------
netrtwlane.inf D:\DriverExport\WIN10-19045\netrtwlane.inf_amd64_4f0c1c5a0a0c3b2d
netrtwlane.cat D:\DriverExport\WIN10-19045\netrtwlane.inf_amd64_4f0c1c5a0a0c3b2d
iaStorVD.inf D:\DriverExport\WIN10-19045\iastorvd.inf_amd64_2f7b4acb3e4a1c9b
iaStorVD.cat D:\DriverExport\WIN10-19045\iastorvd.inf_amd64_2f7b4acb3e4a1c9b
oemsetup.inf D:\DriverExport\WIN10-19045\oemsetup.inf_amd64_0d1a2b3c4e5f6a7b

Ce que cela signifie : Les packages de pilotes sont intacts : l’INF décrit l’installation, le CAT fournit la signature, les binaires font le travail.
Décision : Si vous voyez peu/pas de .cat, vous pouvez avoir des exports incomplets ou des packages hérités ; prévoyez des problèmes de signature.

Tâche 6 : Obtenir un inventaire des packages de pilotes (ce que vous avez réellement capturé)

cr0x@server:~$ pnputil /enum-drivers
Published Name : oem42.inf
Original Name  : netrtwlane.inf
Provider Name  : Realtek Semiconductor Corp.
Class Name     : Net
Class GUID     : {4d36e972-e325-11ce-bfc1-08002be10318}
Driver Version : 11/10/2023 10.66.1234.2023
Signer Name    : Microsoft Windows Hardware Compatibility Publisher

Published Name : oem43.inf
Original Name  : iaStorVD.inf
Provider Name  : Intel Corporation
Class Name     : SCSIAdapter
Driver Version : 09/15/2022 19.5.0.1037
Signer Name    : Microsoft Windows Hardware Compatibility Publisher

Ce que cela signifie : C’est la liste faisant autorité des packages de pilotes mis en scène et de leurs métadonnées.
Décision : Capturez cette sortie dans un fichier à côté de votre dossier d’export. C’est votre outil de diff plus tard.

Tâche 7 : Enregistrer la sortie enum dans un fichier horodaté (pour prouver ce qui a changé)

cr0x@server:~$ powershell -NoProfile -Command "pnputil /enum-drivers | Out-File -Encoding utf8 D:\DriverExport\WIN10-19045\driver-inventory.txt"

Ce que cela signifie : Vous avez maintenant un inventaire en texte brut qui peut être comparé entre réinstallations ou machines.
Décision : Si vous faites cela pour plus d’une machine, standardisez les noms de fichiers et incluez le nom d’hôte/modèle.

Tâche 8 : Identifier les périphériques critiques et leurs hardware IDs (la liste de cibles pour la restauration)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -PresentOnly | Where-Object {$_.Class -in 'Net','Display','System','HDC'} | Select-Object -First 10 Status,Class,FriendlyName,InstanceId | Format-Table -AutoSize"
Status Class  FriendlyName                          InstanceId
------ -----  ------------                          ----------
OK     Net    Intel(R) Ethernet Connection          PCI\VEN_8086&DEV_15F3&SUBSYS_...
OK     Net    Intel(R) Wi-Fi 6 AX201 160MHz         PCI\VEN_8086&DEV_06F0&SUBSYS_...
OK     Display NVIDIA GeForce RTX 3060 Laptop GPU   PCI\VEN_10DE&DEV_2520&SUBSYS_...
OK     HDC    Standard SATA AHCI Controller         PCI\VEN_8086&DEV_A352&SUBSYS_...

Ce que cela signifie : Vous collectez les identifiants que Windows utilise pour associer les INFs aux périphériques.
Décision : Enregistrez ces IDs. Si une réinstallation fait perdre le Wi‑Fi, vous saurez exactement quel package de pilote doit correspondre.

Blague 1 : Les pilotes sont comme des stagiaires : si vous n’écrivez pas ce qu’ils ont fait, vous passerez le trimestre suivant à le redécouvrir.

Tâche 9 : Détecter les « périphériques problématiques » avant la réinstallation (pour ne pas exporter des défauts)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice | Where-Object {$_.Status -ne 'OK'} | Format-Table -AutoSize Status,Class,FriendlyName,InstanceId"
Status Class    FriendlyName                 InstanceId
Error  System   PCI Encryption/Decryption... PCI\VEN_1022&DEV_...

Ce que cela signifie : Vous avez déjà un état de périphérique cassé. Exporter le Driver Store actuel ne résoudra pas forcément cela plus tard.
Décision : Enquêtez et réparez avant de « figer » ce système comme votre baseline. Sinon, vous préservez un défaut.

Tâche 10 : Vérifier l’état des signatures sur les fichiers catalogue exportés (sanité, pas perfection)

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -Recurse D:\DriverExport\WIN10-19045 -Filter *.cat | Select-Object -First 3 | ForEach-Object {Get-AuthenticodeSignature $_.FullName | Select-Object Status,SignerCertificate,Path} | Format-Table -AutoSize"
Status  SignerCertificate                                              Path
------  -----------------                                              ----
Valid   [Subject] CN=Microsoft Windows Hardware Compatibility Publisher D:\DriverExport\WIN10-19045\netrtwlane.inf_amd64_...\netrtwlane.cat
Valid   [Subject] CN=Microsoft Windows Hardware Compatibility Publisher D:\DriverExport\WIN10-19045\iaStorVD.inf_amd64_...\iaStorVD.cat
Valid   [Subject] CN=Microsoft Windows Hardware Compatibility Publisher D:\DriverExport\WIN10-19045\oemsetup.inf_amd64_...\oemsetup.cat

Ce que cela signifie : Un statut Valid est ce que vous souhaitez. NotSigned ou UnknownError est un signal d’alerte.
Décision : Si des packages critiques sont non signés, prévoyez des frictions avec Secure Boot / la signature en mode noyau après réinstallation.

Tâche 11 : Créer un manifeste de checksums pour le dossier d’export (l’intégrité compte)

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -Recurse D:\DriverExport\WIN10-19045 -File | Get-FileHash -Algorithm SHA256 | Export-Csv -NoTypeInformation D:\DriverExport\WIN10-19045\hashes-sha256.csv"

Ce que cela signifie : Vous pouvez plus tard valider que le dossier n’a pas été corrompu par une clé USB défaillante ou une synchronisation « aidante ».
Décision : Si les hash ne correspondent pas le jour de la restauration, n’importez pas. Recopiez depuis une source de confiance.

Tâche 12 : Restaurer les pilotes après réinstallation : mettre en scène tout depuis le dossier

cr0x@server:~$ pnputil /add-driver "D:\DriverExport\WIN10-19045\*.inf" /subdirs /install
Processing inf: D:\DriverExport\WIN10-19045\netrtwlane.inf_amd64_...\netrtwlane.inf
Driver package added successfully.
Driver package installed on matching devices.
Processing inf: D:\DriverExport\WIN10-19045\iaStorVD.inf_amd64_...\iaStorVD.inf
Driver package added successfully.
Driver package installed on matching devices.
...

Ce que cela signifie : /add-driver met en scène les packages dans le nouveau Driver Store ; /install déclenche l’installation sur les périphériques correspondants.
Décision : Si vous voulez un contrôle maximal, omettez /install, mettez en scène d’abord, puis installez par classe de périphérique.

Tâche 13 : Si un périphérique manque toujours, forcez un rescannage et vérifiez le statut

cr0x@server:~$ pnputil /scan-devices
Scanning for hardware changes...
Done.

Ce que cela signifie : Plug and Play a réénuméré le matériel. Parfois, cela suffit après la mise en scène des pilotes.
Décision : Si le périphérique reste inconnu, passez aux hardware IDs et à la sélection directe du pilote.

Tâche 14 : Trouver rapidement les périphériques inconnus (triage post-réinstallation)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice | Where-Object {$_.Status -ne 'OK'} | Format-Table -AutoSize Status,Class,FriendlyName,Problem,InstanceId"
Status Class   FriendlyName   Problem InstanceId
------ -----   ------------   ------- ----------
Error  Unknown Unknown device 28      PCI\VEN_8086&DEV_XXXX&SUBSYS_...

Ce que cela signifie : Le code d’erreur 28 est typiquement « pilotes non installés ».
Décision : Utilisez le hardware ID pour localiser l’INF correct dans votre export, ou mettez en scène les packages fournisseurs manquants.

Tâche 15 : Mapper un hardware ID à une INF dans votre dossier d’export

cr0x@server:~$ powershell -NoProfile -Command "$id='PCI\VEN_8086&DEV_06F0'; Select-String -Path 'D:\DriverExport\WIN10-19045\*\*.inf' -Pattern $id -SimpleMatch | Select-Object -First 5"
D:\DriverExport\WIN10-19045\netwtw08.inf_amd64_...\netwtw08.inf:    %NIC.DeviceDesc% = Install, PCI\VEN_8086&DEV_06F0

Ce que cela signifie : Vous avez trouvé le package de pilotes qui revendique la prise en charge de cet ID de périphérique.
Décision : Si aucune correspondance, votre export ne contient pas le bon package. Vous devrez le chercher ailleurs (OEM, fournisseur, ou Windows Update).

Tâche 16 : Installer une INF spécifique (surgically plutôt que carpet-bombing)

cr0x@server:~$ pnputil /add-driver "D:\DriverExport\WIN10-19045\netwtw08.inf_amd64_...\netwtw08.inf" /install
Driver package added successfully.
Driver package installed on matching devices.

Ce que cela signifie : Vous avez installé un package ciblé. C’est le mouvement à faire quand vous suspectez des conflits ou des pilotes GPU/audio obsolètes.
Décision : Utilisez les installations ciblées pour l’affichage/audio ; utilisez les installations en masse pour chipset/réseau sur des systèmes nus.

Tâche 17 : Confirmer que le nouveau système a effectivement lié la version de pilote attendue

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Net | Get-PnpDeviceProperty DEVPKEY_Device_DriverVersion | Select-Object -First 5 InstanceId,Data | Format-Table -AutoSize"
InstanceId                                   Data
----------                                   ----
PCI\VEN_8086&DEV_06F0&SUBSYS_...             22.250.1.2
PCI\VEN_8086&DEV_15F3&SUBSYS_...             12.19.2.45

Ce que cela signifie : Vous pouvez prouver quelle version est en usage, pas seulement quels packages sont mis en scène.
Décision : Si Windows a lié un pilote plus ancien ou générique, décidez si vous l’acceptez (stabilité) ou si vous l’écrasez (fonctionnalités/performance).

Tâche 18 : Empêcher Windows Update de remplacer immédiatement vos pilotes connus bons (en environnement contrôlé)

cr0x@server:~$ reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v ExcludeWUDriversInQualityUpdate /t REG_DWORD /d 1 /f
The operation completed successfully.

Ce que cela signifie : Cette politique décourage la livraison de pilotes via les quality updates. Ce n’est pas un bouclier universel, mais ça réduit les changements.
Décision : Utilisez‑la sur des flottes gérées ou lors de débogages. Sur des machines personnelles, envisagez de laisser la valeur par défaut si vous dépendez de WU pour les pilotes.

Citation (idée paraphrasée) : Le mantra de fiabilité de Gene Kranz était essentiellement « être dur et compétent » — pas d’excuses, vérifiez vos systèmes et restez discipliné.

Trois mini-récits d’entreprise depuis les tranchées des pilotes

Mini-récit 1 : L’incident causé par une mauvaise hypothèse (la panne « c’est juste le Wi‑Fi »)

Une entreprise de taille moyenne a déployé un renouvellement d’ordinateurs portables dans plusieurs départements. L’équipe de déploiement disposait d’une image Windows propre,
d’un ensemble d’applications et d’une croyance joyeuse que « Windows trouvera les pilotes ». Cette hypothèse tenait au bureau. Puis les portables ont été expédiés
au personnel distant.

Le premier jour, une partie des utilisateurs a démarré sur un bureau sans pilote Wi‑Fi lié. Pas de ports Ethernet non plus — portables fins, options limitées.
L’image n’incluait pas le package sans fil spécifique à cette révision de modèle. Au bureau, l’adaptateur Ethernet d’un dock masquait le problème ; Plug and Play
a installé un NIC différent et tout le monde est passé outre.

Le playbook du helpdesk était essentiellement : « Connectez‑vous à Internet et lancez les mises à jour. » Ce qui revient à dire à une personne qui se noie de nager jusqu’au bateau
que vous n’avez pas apporté. L’incident n’était pas dramatique dans les métriques — pas de serveurs hors service — mais opérationnellement c’était une panne au ralenti :
les utilisateurs ne pouvaient pas s’authentifier au VPN, ne pouvaient pas télécharger le pilote et ne pouvaient pas travailler.

La correction fut douloureusement simple : exporter les pilotes NIC connus‑bons depuis une machine fonctionnelle, les placer dans le partage de déploiement et les mettre en scène lors de l’imagerie.
La leçon fut plus nette : on ne traite pas les pilotes réseau comme optionnels. Ce sont des dépendances bootstrap.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux (déduplication des exports de pilotes)

Une autre organisation voulait « optimiser » le stockage des pilotes. Ils avaient des dizaines de modèles matériels et exportaient les pilotes depuis chaque machine de référence,
générant un dépôt volumineux. Quelqu’un a proposé la déduplication en supprimant les dossiers qui « semblaient en double » et en ne gardant que la version la plus récente par fournisseur.
Cela semblait raisonnable sur une feuille de calcul.

En pratique, le schéma de nommage du Driver Store (something.inf_amd64_hash) n’est pas un détail cosmétique. Ce hash corrèle au contenu exact du package et à la signature du catalogue.
Deux packages avec le même fournisseur et des chaînes de version proches peuvent quand même différer dans les hardware IDs pris en charge,
les co‑installers ou les INFs d’extension.

L’équipe a « optimisé » le dépôt et a découvert plus tard qu’un modèle de portable avait perdu ses gestes de pavé tactile après réimage.
Le périphérique fonctionnait toujours comme une souris HID basique, donc le problème n’avait pas été détecté dans les tests superficiels. Les utilisateurs l’ont remarqué immédiatement, parce que les doigts sont très sensibles à ce qu’ils attendent.

Ils avaient supprimé un package plus ancien, spécifique au modèle, qui contenait la correspondance exacte du hardware ID. Le package plus récent « unifié » ne couvrait pas ce subsystem ID.
Reconstruire le dépôt depuis zéro a pris du temps et, pire, cela a érodé la confiance dans le pipeline de déploiement.

La vraie optimisation n’était pas de dédupliquer au flair ; c’était de construire un manifeste : modèle → hardware IDs critiques → packages de pilotes validés.
Le stockage coûte moins cher que votre semaine d’astreinte.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (inventaire + hash)

Une équipe gérant un petit VDI et des postes avait une politique : chaque bundle de pilotes exporté doit inclure (1) un fichier d’inventaire des pilotes,
(2) des captures d’écran des hardware IDs pour réseau/stockage/affichage, et (3) un manifeste de checksums. C’était assez ennuyeux pour que personne n’en parle.

Lors d’une reconstruction précipitée après un incident de sécurité, ils devaient réimager un ensemble de machines rapidement tout en maintenant le support des périphériques externes
(lecteurs de cartes à puce, adaptateurs série USB, certains matériels audio de niche). Ils ont tiré le bundle exporté depuis un partage réseau et ont commencé à le mettre en scène.
Plusieurs installations ont échoué avec d’étranges erreurs de lecture de fichiers.

Parce qu’ils avaient des hashes, ils n’ont pas perdu de temps à blâmer DISM, Windows ou les rayons cosmiques. Ils ont validé l’export et trouvé une corruption en transit :
l’une des cibles de stockage avait silencieusement perdu des bits sous charge. Les packages de pilotes étaient incomplets, ce qui explique pourquoi les installations échouaient
de manière incohérente et exaspérante.

Ils ont restauré le bundle depuis une copie propre, relancé la mise en scène et la reconstruction a pu se poursuivre. Pas d’héroïsme, juste des justificatifs.

Blague 2 : Une « sauvegarde de pilotes » sans vérification est comme un parachute que vous avez plié pendant une réunion — techniquement possible, émotionnellement imprudent.

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

Plan A : PC unique, vous voulez juste une réinstallation sans douleur

Préparez le stockage : choisissez une destination avec suffisamment d’espace et une fiabilité décente (SSD externe plutôt qu’une clé USB au hasard).
Créez un nom de dossier incluant la build OS et le modèle de machine.
Exportez les pilotes : exécutez pnputil /export-driver * vers le dossier.
Capturez l’inventaire : sauvegardez la sortie de pnputil /enum-drivers dans driver-inventory.txt.
Capturez les hardware IDs critiques : enregistrez les IDs NIC et contrôleur de stockage avec Get-PnpDevice.
Hachez l’export : créez un manifeste SHA256 CSV.
Rendez l’export en lecture seule : copiez‑le à deux endroits si vous tenez à cœur (externe + NAS). Ne modifiez pas sur place.
Après la réinstallation : mettez en scène les pilotes depuis le dossier avec pnputil /add-driver ... /subdirs.
Vérifiez l’association : confirmez les versions des pilotes NIC et qu’il n’y a pas d’entrées « Périphérique inconnu » dans le Gestionnaire de périphériques.

Plan B : Flotte / imagerie d’entreprise, où le chaos est budgété

Établissez une machine de référence par modèle matériel (ou par famille si vous avez validé la compatibilité des hardware IDs).
Exportez pilotes et inventaire avec une convention de nommage standard :
MODEL-OSBUILD-DATE (les dates vont dans les noms de dossier ; évitez‑les dans les slugs et documents de politique).
Constituez un « bootstrap pack » : NIC + stockage + chipset + contrôleurs USB. Ce pack doit fonctionner hors ligne.
Gardez un « pack risqué » séparé : GPU, audio, camera, piles Bluetooth. C’est là que se cachent les conflits et régressions.
Épinglez et testez les versions de pilotes avec un petit groupe pilote. Vous ne courez pas après le « plus récent », vous courez après le « stable ennuyeux ».
Checksummez tout et validez à l’import. La bit‑rot et les outils de sync défaillants sont plus courants que vous ne le pensez.
Documentez le rollback : si un nouveau pilote GPU casse les moniteurs externes, vous devez connaître le package précédemment connu‑bon.

Plan C : Avant un wipe, vous réalisez que la machine a du matériel niche

Exportez les pilotes immédiatement (pnputil).
Identifiez et capturez en image (ou exportez) les hardware IDs des périphériques inconnus/critique.
Mettez en scène l’export sur une seconde machine pour confirmer qu’il contient les bonnes correspondances INF (recherchez les IDs dans les INFs).
Faites le wipe seulement ensuite.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom : L’export « réussit » mais la restauration n’installe rien

Cause racine : Vous avez mis en scène les pilotes mais n’avez pas déclenché l’installation, ou les périphériques ne sont pas encore énumérés.
Correction : Utilisez pnputil /add-driver ... /install, puis exécutez pnputil /scan-devices. Vérifiez avec Get-PnpDevice le statut.

2) Symptom : Après restauration, le Wi‑Fi manque toujours et vous ne pouvez pas télécharger les pilotes

Cause racine : L’export n’inclut pas le package correct pour cet ID matériel NIC spécifique (fréquent entre révisions de modèle).
Correction : Récupérez le hardware ID de la machine en panne, recherchez‑le dans vos INFs exportées avec Select-String.
Si non trouvé, sourcez le pilote correct et ajoutez‑le à votre dépôt pour la prochaine fois.

3) Symptom : « The third-party INF does not contain digital signature information »

Cause racine : Package de pilote non signé, ou fichier catalogue manquant/invalide, ou signature bloquée par politique/Secure Boot.
Correction : Préférez les packages signés. Si le matériel héritage l’exige vraiment, vous devrez envisager des changements contrôlés (test signing / politique Secure Boot),
mais traitez cela comme une exception avec approbation des risques.

4) Symptom : L’export prend une éternité, la diode disque reste allumée, les ventilateurs hurlent

Cause racine : Destination lente, antivirus qui scanne chaque fichier extrait, ou Driver Store gonflé sur une machine vieille d’années.
Correction : Exportez d’abord sur un SSD local, puis copiez vers le stockage externe. Ajustez temporairement la politique AV si votre environnement le permet.
Envisagez aussi de nettoyer les packages obsolètes (avec prudence) sur le système source avant d’en faire une référence.

5) Symptom : Après réinstallation, l’affichage fonctionne mais les performances sont médiocres (ou les moniteurs externes échouent)

Cause racine : Windows a lié un pilote d’affichage générique ou le mauvais package fournisseur (fréquent avec les graphiques hybrides).
Correction : Utilisez une installation INF ciblée pour le package GPU. Vérifiez la version liée avec DEVPKEY_Device_DriverVersion.
Gardez les pilotes GPU dans un « pack risqué » séparé pour pouvoir revenir en arrière rapidement.

6) Symptom : Le touchpad/le clavier fonctionne « en quelque sorte » mais les gestes/raccourcis ont disparu

Cause racine : Les pilotes de classe HID sont présents, mais le pilote d’extension ou filtre spécifique au fournisseur n’a pas été mis en scène/installe.
Correction : Identifiez le hardware ID du périphérique et installez le package OEM correspondant. Ne supposez pas que « c’est une souris » est acceptable.

7) Symptom : La restauration fonctionne, puis Windows Update « met à jour » les pilotes et les choses régressent

Cause racine : La livraison de pilotes via Windows Update remplace votre package choisi selon le classement.
Correction : Utilisez une politique pour exclure les pilotes WU pendant la stabilisation, ou épinglez les versions via votre outil de gestion.
Décidez si vous privilégiez la stabilité ou les mises à jour automatiques, puis appliquez‑le.

8) Symptom : Vous avez exporté les pilotes d’une machine « fonctionnelle », mais un autre modèle identique échoue

Cause racine : « Identique » n’est pas identique : fournisseur NIC différent, subsystem ID différent, mode du contrôleur de stockage différent, ou changements de BIOS modifiant les hardware IDs.
Correction : Capturez les hardware IDs par révision de modèle. Ne faites pas confiance aux noms marketing. Faites confiance aux IDs PCI et subsystem IDs.

FAQ

1) Dois‑je utiliser pnputil ou DISM pour exporter les pilotes ?

Utilisez pnputil /export-driver * comme défaut. C’est simple et correspond bien à la restauration avec pnputil /add-driver.
DISM est excellent pour le service des images hors ligne et pour les environnements déjà centrés sur des workflows DISM. Si vous hésitez, exportez avec les deux et comparez les comptes.

2) L’export de pilotes copie‑t‑il des fichiers depuis System32 ?

Pas comme les gens l’imaginent. Les exports corrects copient les packages de pilotes mis en scène (INF/CAT/binaires) depuis le Driver Store.
C’est l’unité installable. Des fichiers aléatoires dans System32 sont souvent des composants partagés et insuffisants pour une réinstallation.

3) Puis‑je restaurer les pilotes sans Internet ?

Oui. C’est tout l’intérêt. Mettez en scène depuis votre dossier d’export avec pnputil /add-driver ... /subdirs.
Pour une installation fraîche, priorisez les packages NIC et stockage pour que le système devienne autonome rapidement.

4) Cela capture‑t‑il complètement les pilotes GPU ?

Cela capture les packages de pilotes qui sont mis en scène. Cela ne capture pas nécessairement l’application de contrôle du fournisseur,
les services de télémétrie ou les composants « aide » fournis séparément. Si vous tenez à ces éléments, empaquetez‑les séparément.

5) Est‑il sûr d’importer tout depuis le dossier d’export ?

D’habitude oui — surtout sur la même famille de machine. Mais pour des systèmes longtemps utilisés, vous pouvez accumuler plusieurs versions de pilotes GPU/audio.
L’import massif peut réintroduire d’anciens packages que vous préféreriez laisser de côté. Pour ces classes, préférez des installations ciblées.

6) Pourquoi Windows choisit‑il parfois un pilote différent de celui que j’ai mis en scène ?

La sélection de pilote se base sur un classement : qualité de la correspondance de hardware ID, signature, date/version et autres facteurs.
La mise en scène rend les packages disponibles ; elle n’impose pas la sélection à moins d’installer un package correspondant spécifique ou d’utiliser des étapes de gestion de périphérique plus poussées.

7) Combien d’espace devrais‑je prévoir pour un export ?

Cela varie énormément. Un portable typique peut occuper quelques gigaoctets ; une machine mise à jour pendant des années peut être bien plus volumineuse.
Si vous exportez sur une clé USB, prévoyez de la marge — manquer d’espace en cours d’export est une tristesse évitable.

8) Puis‑je exporter des pilotes depuis une installation Windows hors ligne (non démarrée) ?

Oui, en utilisant DISM contre un chemin d’image hors ligne, mais c’est plus orienté déploiement et vous devez connaître le répertoire Windows monté.
Pour la plupart des particuliers, exporter avec le système en cours d’exécution est plus simple et moins sujet aux erreurs.

9) Dois‑je désactiver Secure Boot pour restaurer des pilotes ?

Pas pour des pilotes correctement signés. Si votre restauration nécessite des pilotes noyau non signés, vous êtes dans le domaine des exceptions.
La bonne solution est généralement « utiliser des pilotes signés », pas « affaiblir la chaîne de démarrage ».

10) Quelle est la meilleure façon de maintenir cela dans le temps ?

Traitez les exports de pilotes comme des artefacts : versionnez‑les par build OS et modèle matériel, incluez inventaires et hashes, et ne les modifiez pas.
Quand vous mettez à jour un pilote, créez un nouveau bundle. Les anciens bundles sont votre parachute de retour.

Conclusion : prochaines étapes réalisables aujourd’hui

Si vous ne faites rien d’autre, faites ceci : exportez vos pilotes mis en scène avec pnputil, sauvegardez un fichier d’inventaire et stockez le bundle dans un endroit fiable.
Cela suffit à transformer une réinstallation de « théâtre d’impro » en « procédure répétable ».

Prochaines étapes pratiques :

Créez D:\DriverExport\YOURMODEL-OSBUILD et lancez l’export.
Sauvegardez driver-inventory.txt et un manifeste SHA256 dans le même dossier.
Enregistrez les hardware IDs pour les contrôleurs NIC et de stockage.
Après réinstallation, mettez en scène les pilotes depuis ce dossier, puis vérifiez ce qui a effectivement été lié.
Décidez si Windows Update est autorisé à changer les pilotes pendant la stabilisation — et appliquez cette décision.

Les réinstallations sont inévitables. La panique est optionnelle. Exportezz les pilotes tant que tout fonctionne, et le vous du futur pourra dormir.