Windows réinstalle des pilotes défectueux : arrêtez-le définitivement

février 6, 2026 • février 6, 2026 • Lecture : 28 min • Views: 0

Cet article vous a aidé ?

Rien ne dit « journée productive » comme Windows qui remplace poliment votre pilote stable par exactement celui qui vient de planter votre pile graphique, couper votre Wi‑Fi ou casser votre contrôleur de stockage. Vous restaurez la version précédente, vous redémarrez, vous respirez. Puis il revient. Comme un boomerang avec des droits d’administrateur.

Ce n’est pas mystérieux. Ce sont des politiques, un classement, des paquets de pilotes dans le Driver Store, et Windows Update qui fait ce qu’il pense être le mieux — selon des règles que vous pouvez contourner si vous êtes prêt à être précis et un peu obstiné.

Comment Windows décide de « vous aider » (et pourquoi il réinstalle sans cesse)

Windows n’« installe » pas simplement un pilote. Il sélectionne un paquet de pilotes correspondant aux ID matériel, le met en scène dans le Driver Store, puis le lie au périphérique. La sélection repose sur un classement. Le classement prend en compte la spécificité de la correspondance des hardware ID, la confiance de la signature, la date, la version, et parfois des métadonnées fournies par le fournisseur. Le système cherche à converger vers un « meilleur » pilote, pas à ménager vos sentiments.

Quand Windows réinstalle sans cesse un pilote défectueux, ce n’est presque jamais une seule cause. C’est généralement l’un de ces schémas :

Windows Update fournit un pilote et il a un meilleur classement que celui que vous préférez.
Le paquet de pilote défectueux reste dans le Driver Store donc Plug and Play peut le relier à nouveau lors des rescans ou de la ré‑énumération des périphériques.
Les utilitaires OEM (Lenovo Vantage, Dell Command Update, HP Support Assistant, suites GPU des constructeurs) « aident » selon leur propre calendrier.
MDM/Intune/WSUS approuve ou cible des pilotes de façon centrale.
Mises à jour de fonctionnalité ou opérations de réparation remettent en scène des pilotes « inbox » ou mieux classés.

La solution n’est pas « restaurer encore ». La solution : identifier le chemin de livraison, supprimer ou déclasser le paquet que vous détestez, et faire respecter une frontière politique pour qu’il ne puisse pas revenir.

Une citation d’exploitation qui mérite un post‑it près de votre écran (idée paraphrasée) : « L’espoir n’est pas une stratégie. » — souvent attribué aux cercles de direction d’ingénierie ; paraphrasé

Guide de diagnostic rapide

Quand vous êtes d’astreinte (pour vous-même ou pour une flotte) vous ne commencez pas par la philosophie. Vous commencez par « qu’est‑ce qui a changé, qu’est‑ce qui s’est installé, quelle source, quel paquet ». Voici le chemin rapide qui trouve le goulot d’étranglement rapidement.

Première étape : confirmer quel pilote est actif maintenant

Gestionnaire de périphériques → périphérique → Propriétés → Onglet Pilote (version, fournisseur, date).
Puis vérifiez en CLI (parce que les interfaces graphiques omettent des choses) : utilisez pnputil et dism (voir les tâches ci‑dessous).

Deuxième étape : identifier le canal de distribution

Le pilote a‑t‑il été installé par Windows Update ? Consultez l’historique de Windows Update et les journaux de l’Observateur d’événements (SetupAPI, WindowsUpdateClient).
A‑t‑il été installé par un agent OEM ? Vérifiez les programmes/services/tâches planifiées installés.
En entreprise ? Vérifiez la stratégie de groupe / politique MDM et si les pilotes proviennent de WSUS/Microsoft Update.

Troisième étape : choisissez votre niveau de confinement

Poste de travail / appareil unique : masquer la mise à jour spécifique + supprimer le paquet du Driver Store + arrêter les mises à jour automatiques des pilotes.
Petit bureau : GPO pour bloquer les mises à jour des pilotes, ou restrictions d’installation de périphériques par hardware ID.
Entreprise : arrêter l’approbation des pilotes dans WSUS, verrouiller la politique dans Intune, et utiliser un anneau de pilotes contrôlé avec des paquets connus‑bons.

Quatrième étape : valider que la correction tient après ré‑énumération

Redémarrer.
Désactiver/réactiver le périphérique.
Scanner les modifications matérielles.
Vérifier à nouveau le Driver Store. Si le paquet défectueux est encore présent et bien classé, il reviendra.

Faits intéressants et contexte historique

Un peu de contexte aide parce que le comportement des pilotes est le résultat de décennies de « livrer du matériel à grande échelle sans enflammer le support ». Quelques points concrets :

Le Driver Store de Windows est devenu central à l’époque de Vista, permettant la mise en scène des pilotes et des retours en arrière plus simples, mais rendant aussi la suppression d’un pilote un problème en deux étapes (périphérique vs paquet).
Le classement Plug and Play n’est pas aléatoire : une correspondance hardware ID plus spécifique peut battre une version de pilote plus récente, selon le ciblage de l’INF et les calculs de rang.
La signature WHQL (et plus tard la signature d’attestation) a considérablement augmenté la confiance des pilotes à grande échelle, mais elle a aussi donné à Windows Update la confiance pour pousser des pilotes largement.
Windows Update a commencé à distribuer davantage de pilotes de façon agressive à l’ère de Windows 10, visant à réduire les états « périphérique inconnu » et améliorer l’expérience out‑of‑box.
Les mises à jour de fonctionnalité se comportent comme des mises à niveau sur place et peuvent réévaluer les pilotes, parfois en privilégiant des pilotes « inbox » pour éviter les échecs de mise à niveau.
Les OEM peuvent publier des pilotes sur Windows Update via le pipeline écosystémique de Microsoft, ce qui explique pourquoi « Microsoft » apparaît parfois comme fournisseur pour du silicium constructeur.
Le retour arrière de pilote restaure typiquement le pilote précédent pour cette instance de périphérique, mais n’évince pas nécessairement le paquet plus récent du Driver Store.
Windows a des politiques séparées pour les « mises à jour de qualité » vs « mises à jour de pilotes », et les entreprises bloquent souvent l’une tout en autorisant accidentellement l’autre.
Les restrictions d’installation de périphériques par hardware ID existent depuis des années et restent l’un des moyens les plus déterministes pour bloquer le changement de pilote d’un périphérique spécifique.

Blague #1 : Les pilotes sont comme des stagiaires avec un accès root : généralement corrects jusqu’au moment où ils découvrent « l’optimisation ».

Les vraies causes profondes (pas des impressions)

1) Le pilote défectueux est encore dans le Driver Store

Si le paquet est toujours mis en scène, Windows peut le relier à nouveau lors de :

ré‑énumération des périphériques (stations d’accueil, NIC USB, resets GPU)
« scanner les modifications matérielles »
cycles de détection de Windows Update
migration lors des mises à jour de fonctionnalité

Supprimer le périphérique dans le Gestionnaire de périphériques ne suffit pas si vous avez coché « Supprimer le pilote pour ce périphérique » et que ça n’a pas supprimé le paquet (fréquent quand il est en cours d’utilisation ou quand plusieurs périphériques partagent le même paquet).

2) Windows Update propose un pilote qui a un meilleur classement que le vôtre

Windows choisit selon la meilleure correspondance. Si Microsoft Update propose un pilote avec une correspondance hardware ID plus serrée ou un meilleur rang, il peut gagner même si vous avez installé quelque chose manuellement — surtout si votre pilote préféré est un paquet générique du fournisseur et que l’offre est ciblée sur votre subsystem ID.

3) Vous luttez contre la mauvaise source de mise à jour

Les entreprises partent souvent du principe que Windows Update est la seule source. Ce n’est pas le cas. Les outils OEM planifient des envois de pilotes. Les politiques MDM peuvent imposer des pilotes. Les suites de gestion des endpoints peuvent « patcher » des pilotes comme s’il s’agissait de Chrome. Si vous bloquez Windows Update mais que Dell Command Update continue de pousser, vous continuerez à perdre.

4) Conflit de politiques : « ne pas inclure les pilotes » n’est pas appliqué où vous pensez

Il existe plusieurs leviers : stratégie de groupe locale, GPO de domaine, politiques CSP MDM, approbations WSUS, et anneaux Windows Update for Business. Si vous définissez une option localement mais que la politique de domaine l’écrase, votre modification locale n’est que décorative.

5) Mise à jour de fonctionnalité / mise à niveau sur place réinitialise l’état

Pendant une mise à niveau, Windows priorise la capacité de démarrage et la compatibilité. Les pilotes de stockage, chipset et affichage peuvent être remplacés par des bases connues‑bonnes. Si votre « connu‑bon » est plus récent mais pas considéré comme sûr pour la mise à niveau, il peut être remplacé. Ensuite, Windows Update peut « l’améliorer » à nouveau — avec la même mauvaise version que vous évitiez.

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

Toutes les tâches ci‑dessous sont conçues pour être exécutables sur Windows. Je les formate en bloc de style bash comme demandé, mais les commandes sont PowerShell/CMD que vous pouvez exécuter dans une invite élevée sauf indication contraire.

Task 1: Identify the currently bound driver for a device (PnP view)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -PresentOnly | ? {$_.FriendlyName -like '*Wi-Fi*'} | ft -AutoSize Status,Class,FriendlyName,InstanceId"
Status Class    FriendlyName                     InstanceId
------ -----    ------------                     ----------
OK     Net      Intel(R) Wi-Fi 6 AX201 160MHz    PCI\VEN_8086&DEV_06F0&SUBSYS_00748086&REV_00\3&11583659&0&A3

Ce que cela signifie : Vous avez l’ID d’instance du périphérique. Cet ID est votre ancre pour tout le reste.

Décision : Si le périphérique n’est pas présent/OK, vous ne dépannez pas une « réinstallation », vous dépannez une détection ou une panne matérielle.

Task 2: Get the driver version/provider bound to that device

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_PnPSignedDriver | ? {$_.DeviceID -like 'PCI\\VEN_8086&DEV_06F0*'} | select DeviceName,DriverVersion,DriverDate,DriverProviderName,InfName | fl"
DeviceName         : Intel(R) Wi-Fi 6 AX201 160MHz
DriverVersion      : 22.250.1.2
DriverDate         : 2024-03-18T00:00:00.0000000
DriverProviderName : Intel
InfName            : oem42.inf

Ce que cela signifie : La liaison se fait via oem42.inf. Vous avez maintenant le nom de l’INF à cibler.

Décision : Si le fournisseur est « Microsoft » alors que vous attendiez Intel/NVIDIA/AMD, il peut s’agir d’un pilote reconditionné par Windows Update.

Task 3: List Driver Store packages and find the culprit INF

cr0x@server:~$ pnputil /enum-drivers | findstr /i "oem42.inf Provider Class Version"
Published Name : oem42.inf
Driver Package Provider : Intel
Class : Net
Driver Version And Date : 22.250.1.2 03/18/2024

Ce que cela signifie : Le paquet de pilote existe dans le Driver Store sous oem42.inf.

Décision : Si plusieurs INFs OEM montrent des versions similaires, vous devrez peut‑être supprimer plusieurs paquets concurrents pour arrêter la reconnexion.

Task 4: See if Windows Update recently installed a driver (Update history)

cr0x@server:~$ powershell -NoProfile -Command "Get-WindowsUpdateLog -LogPath $env:TEMP\WindowsUpdate.log; Select-String -Path $env:TEMP\WindowsUpdate.log -Pattern 'Driver' -SimpleMatch | Select-Object -First 5"
2026/02/03 21:14:09.1234567  1234  5678  Agent  * Title = Intel - Net - 22.250.1.2
2026/02/03 21:14:09.1237890  1234  5678  Agent  * UpdateId = {GUID}
2026/02/03 21:14:09.1240000  1234  5678  Agent  * Revision = 201

Ce que cela signifie : Windows Update a proposé et probablement installé un pilote correspondant à ce que vous voyez lié.

Décision : Si l’historique de mises à jour l’affiche, bloquez/masquez cette mise à jour et arrêtez les mises à jour de pilotes via une politique. Si ce n’est pas le cas, examinez les outils OEM et le MDM.

Task 5: Check SetupAPI device install logs for who did what

cr0x@server:~$ powershell -NoProfile -Command "Select-String -Path $env:windir\inf\setupapi.dev.log -Pattern 'oem42.inf' | Select-Object -Last 8"
>>>  [Driver Install (UpdateDriverForPlugAndPlayDevices) - PCI\VEN_8086&DEV_06F0...]
>>>  Section start 2026/02/03 21:15:02.100
     inf:       Opened INF: 'C:\Windows\INF\oem42.inf' ([strings])
     dvi:       {DIF_SELECTBESTCOMPATDRV} 21:15:02.180
     dvi:       Selected driver installs from section [Install.NT]
     dvi:       {DIF_INSTALLDEVICE} 21:15:02.650
<<<  Section end 2026/02/03 21:15:06.900

Ce que cela signifie : Le pilote a été installé via un chemin de mise à jour PnP. Les journaux SetupAPI sont la chose la plus proche d’une piste d’audit pour la liaison des pilotes.

Décision : Si les horodatages correspondent à l’activité de Windows Update, concentrez‑vous sur les contrôles de WU. Si cela correspond aux horaires des tâches OEM, coupez le programme de mise à jour OEM.

Task 6: Disable automatic driver downloads (the user-friendly switch)

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 : 0x1 est « Oui, faire cela automatiquement » dans beaucoup de builds ; 0x0 est « Non ».

Décision : Sur des machines gérées, cela peut être ignoré. Traitez‑le comme un réglage pratique, pas une garantie.

Task 7: Enforce “Do not include drivers with Windows Updates” (policy-backed)

cr0x@server:~$ reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v ExcludeWUDriversInQualityUpdate
ERROR: The system was unable to find the specified registry value or key.

Ce que cela signifie : La politique n’est pas définie (ou est définie ailleurs via MDM). Vous pouvez la définir via GPO ou le registre (préférez GPO/MDM sur les flottes).

Décision : Si vous êtes dans un domaine, vérifiez l’ensemble résultant de la stratégie avant d’éditer le registre local.

Task 8: Set the policy registry value (local test, then do it properly)

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 : Cela indique à Windows Update de ne pas inclure les pilotes dans les mises à jour de qualité.

Décision : Si un pilote spécifique est critique et que vous dépendez de WU pour le maintenir, n’utilisez pas cela globalement — préférez un blocage par pilote.

Task 9: Remove the bad driver package from Driver Store (the real eviction)

cr0x@server:~$ pnputil /delete-driver oem42.inf /uninstall /force
Microsoft PnP Utility

Driver package deleted successfully.
Deleted driver package: oem42.inf

Ce que cela signifie : Le paquet est parti, et Windows ne peut plus le relier sauf s’il est réintroduit.

Décision : Si la suppression échoue parce qu’il est « en cours d’utilisation », déconnectez le matériel dépendant, démarrez en mode sans échec, ou retirez les périphériques concurrents utilisant cette INF.

Task 10: Confirm it’s actually gone

cr0x@server:~$ pnputil /enum-drivers | findstr /i "oem42.inf"

Ce que cela signifie : Aucune sortie signifie que l’INF n’est pas présente dans le Driver Store.

Décision : Si elle apparaît encore, vous ne l’avez pas supprimée. Arrêtez et corrigez cela avant de chasser les politiques.

Task 11: Install a known-good driver and validate binding

cr0x@server:~$ pnputil /add-driver "C:\Drivers\WiFi\Netwtw06.inf" /install
Microsoft PnP Utility

Driver package added successfully.
Published name: oem77.inf
Driver package installed on matching devices.

Ce que cela signifie : Vous avez mis en scène et installé le pilote connu‑bon ; il est maintenant oem77.inf.

Décision : Notez oem77.inf et la version/date. C’est ce que vous allez défendre.

Task 12: Block driver updates for a specific device by hardware ID (deterministic)

cr0x@server:~$ powershell -NoProfile -Command "$id='PCI\VEN_8086&DEV_06F0&SUBSYS_00748086'; $id"
PCI\VEN_8086&DEV_06F0&SUBSYS_00748086

Ce que cela signifie : Vous avez capturé l’ID matériel pour l’utiliser dans les restrictions d’installation de périphériques (GPO) afin que Windows ne puisse pas installer des pilotes correspondants sauf ceux déjà présents/autorisés.

Décision : Si le périphérique est critique pour le stockage ou le démarrage, soyez prudent : bloquer des installations peut compliquer la récupération si vous avez besoin d’un pilote de remplacement plus tard.

Task 13: Check which GPOs are actually applied (because “I set it” is not evidence)

cr0x@server:~$ gpresult /r
COMPUTER SETTINGS
------------------
    Applied Group Policy Objects
    -----------------------------
        Workstation Baseline
        Windows Update Control

Ce que cela signifie : Vous pouvez voir si un objet de stratégie qui devrait contrôler les pilotes est appliqué.

Décision : Si votre GPO attendu n’est pas listé, votre solution se trouve dans Active Directory, pas dans le registre.

Task 14: Inspect Windows Update policy values that often conflict

cr0x@server:~$ reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /s
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
    ExcludeWUDriversInQualityUpdate    REG_DWORD    0x1
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
    UseWUServer    REG_DWORD    0x1

Ce que cela signifie : Les pilotes sont exclus, et la machine est pointée vers WSUS (UseWUServer=1).

Décision : Si vous utilisez WSUS, corrigez les approbations là‑bas ; masquer les mises à jour localement ne servira à rien si WSUS continue de les forcer.

Task 15: List installed third-party drivers via DISM (useful in incident reviews)

cr0x@server:~$ dism /online /get-drivers /format:table | more
Published Name   Original Name  Inbox  Class Name  Provider Name  Date       Version
-------------   -------------  -----  ----------  -------------  ---------  -------------
oem77.inf       netwtw06.inf   No     Net         Intel          2023-11-10  22.220.0.4
oem13.inf       nv_dispi.inf   No     Display     NVIDIA         2024-01-05  551.23

Ce que cela signifie : Cela vous donne une vue adaptée à la flotte : inbox vs tiers, fournisseur, date, version.

Décision : Si vous observez un saut de fournisseur/date après le Patch Tuesday, vous avez un problème de dérive de pilotes.

Task 16: Force a rescan and observe whether the bad driver returns

cr0x@server:~$ pnputil /scan-devices
Microsoft PnP Utility

Scanning devices completed.

Ce que cela signifie : La machine a réévalué les correspondances périphérique‑pilote. C’est un moyen sûr de tester si votre blocage/éviction tient.

Décision : Si le mauvais pilote revient immédiatement, votre blocage n’est pas en place ou le paquet est encore mis en scène quelque part.

Stratégies de blocage qui tiennent réellement

Vous avez trois niveaux de contrôle. Choisissez selon le rayon d’action et le degré de confiance que vous avez en votre futur vous.

Level 1: Block driver updates broadly (fast, blunt)

Utilisez ExcludeWUDriversInQualityUpdate via GPO/MDM. Cela empêche Windows Update de pousser des pilotes dans le cadre des mises à jour de qualité. Cela n’empêche pas les installations manuelles, les mises à jour OEM, ou le comportement des mises à jour de fonctionnalité. C’est néanmoins utile dans des environnements où la stabilité des pilotes prime sur la nouveauté.

Quand l’utiliser : flottes de bureau, endpoints VDI, kiosques, systèmes avec piles matérielles validées, stations audio, appareils industriels.

Quand ne pas l’utiliser : ordinateurs portables dépendant des correctifs fréquents du fournisseur (régressions Wi‑Fi/BT), ou si vous n’avez pas de processus alternatif de distribution des pilotes.

Level 2: Hide/block a specific driver update (surgical, but source-dependent)

Si un pilote particulier est proposé via Windows Update, vous pouvez le masquer afin que WU ne le réinstalle pas. En environnement grand public, cela se fait souvent via l’outil « afficher ou masquer les mises à jour ». En environnements gérés, gérez cela via les approbations (WSUS) ou le ciblage des pilotes (MDM). Le but : arrêter la livraison à la source.

Piège : Le masquage fonctionne jusqu’à ce que la mise à jour soit republiée sous une nouvelle révision ou sous un paquet légèrement différent. Alors c’est une « nouvelle » mise à jour et vous êtes de nouveau dans la boucle.

Level 3: Device Installation Restrictions by hardware ID (most deterministic)

C’est la solution sérieuse quand vous devez maintenir un périphérique sur une version de pilote spécifique. Vous bloquez l’installation de périphériques correspondant aux hardware IDs sauf si le pilote est déjà installé, ou vous autorisez explicitement seulement certaines classes.

En clair : vous mettez un videur qui contrôle les changements de pilote de ce périphérique.

Piège : Si vous bloquez trop largement (par exemple la classe « Display » dans un environnement riche en GPU), vous saboterez éventuellement les mises à niveau et les remplacements matériels.

Evict the bad package from the Driver Store (non-negotiable)

Si vous voulez « arrêter pour de bon », vous supprimez le paquet que Windows continue de sélectionner. Sinon vous comptez sur le classement et le hasard. Utilisez pnputil /delete-driver avec /uninstall et /force quand c’est approprié. Puis confirmez l’absence du paquet.

Aussi : si plusieurs versions existent, supprimez celles que vous ne voulez pas. Windows peut et choisira un autre « mauvais » si celui‑ci est encore dans le store et bien classé.

Deal with OEM updaters (they mean well; they still break things)

Sur les portables orientés entreprise, les outils OEM sont des coupables fréquents. Ils poussent BIOS, firmware et pilotes. Ils peuvent être utiles — jusqu’à ce qu’ils combattent l’état souhaité. Si vous gérez une flotte, décidez qui possède les pilotes :

Si l’IT possède les pilotes : supprimez/désactivez les outils OEM ou configurez‑les pour seulement notifier.
Si l’OEM possède les pilotes : acceptez la dérive et mettez en place la surveillance plus l’automatisation du rollback.

Blague #2 : Windows Update est le collègue le plus confiant du monde — il « corrige » toujours la chose que vous aviez enfin stabilisée.

Trois mini-récits d’entreprise depuis le terrain

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

Ils exploitaient une flotte hybride : stations de travail en bureau, portables distants sur VPN, et quelques machines de laboratoire partagées pilotant du matériel de mesure onéreux. Quelqu’un a remarqué un pilote instable d’adaptateur USB‑vers‑Ethernet sur un sous‑ensemble de portables — déconnexions aléatoires, surtout après la mise en veille.

L’hypothèse était propre mais fausse : « C’est Windows Update qui pousse un mauvais pilote. » Ils ont donc bloqué les pilotes largement via une politique, se sont félicités, et ont passé à autre chose.

Deux semaines plus tard, les machines du labo commençaient à se déconnecter du réseau pendant des tests longs. Pas les portables. Pas les distants. Seulement le labo. Le fournisseur a blâmé les câbles. L’équipe réseau a blâmé le spanning tree. Le labo a blâmé tout le monde.

La cause racine était un utilitaire OEM s’exécutant en tant que SYSTEM sur l’image du labo. Il avait été configuré des mois auparavant pour « appliquer automatiquement les mises à jour recommandées ». Il n’en avait rien à faire de la politique d’exclusion des pilotes de Windows Update parce qu’il n’utilisait pas Windows Update. Il a téléchargé un pilote plus récent directement depuis le catalogue OEM et l’a installé pendant une fenêtre de maintenance.

Correction : ils ont retiré l’updater OEM de l’image du labo, déplacé BIOS/firmware vers un processus mensuel contrôlé, et utilisé des restrictions d’installation de périphériques pour les hardware IDs spécifiques des NIC USB. L’hypothèse erronée n’était pas malveillante ; elle manquait simplement de modélisation des menaces. La livraison des pilotes a plusieurs bouches.

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

Un groupe d’ingénierie sur postes fixes voulait un provisionnement plus rapide. Ils ont construit une « image gold » avec un Driver Store surchargé : chipset, GPU, audio, NIC — tout pré‑stagé. L’idée était saine : premier démarrage, zéro périphérique manquant, douleur utilisateur minimale.

Ça a bien marché… jusqu’à ce que ça ne marche plus. Un sous‑ensemble de machines a commencé à choisir un pilote GPU plus ancien mais plus spécifique qui avait été stagé des mois plus tôt pour un subsystem ID légèrement différent. Il était bien classé, il correspondait étroitement, et il était là dans le store comme un piège.

Les symptômes étaient bizarres : certaines applications de CAO plantaient, mais seulement sur certaines révisions matérielles. Le rollback aidait pendant un jour. Puis, après un cycle dock/undock ou un scan Windows Update, l’ancien pilote revenait. Leur « optimisation » avait créé un ensemble de candidats plus large, augmentant la probabilité que Windows choisisse quelque chose qu’ils n’avaient pas prévu.

Correction : ils ont modifié le processus d’imagerie pour stagier seulement les pilotes requis pour ce SKU modèle, pas tout l’univers du fournisseur. Ils ont aussi ajouté une étape de validation post‑provisionnement qui énumérait les paquets du Driver Store et supprimait les INFs connus‑mauvais. Le provisionnement est devenu un peu plus lent. Le temps moyen pour retrouver la raison est nettement amélioré.

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

Un service financier exploitait des postes Windows connectés à un système de numérisation de reçus ancien mais critique. Le scanner dépendait d’une version très précise du pilote du contrôleur USB — les versions plus récentes « fonctionnaient » mais produisaient une corruption intermittente difficile à détecter avant les audits. Tout le monde détestait cette configuration, ce qui signifie qu’elle était importante.

Plutôt que de jouer au Whac‑A‑Mole, l’équipe endpoint a fait trois choses peu attrayantes. Premièrement, ils ont documenté exactement les hardware IDs du contrôleur et du scanner. Deuxièmement, ils ont créé un paquet de base de pilotes et l’ont stocké en interne dans la chaîne d’imagerie. Troisièmement, ils ont appliqué des restrictions d’installation de périphériques afin que le contrôleur ne puisse pas changer de pilote sans une fenêtre de changement explicite.

Puis une mise à jour de fonctionnalité Windows a traversé l’organisation. Comme prévu, elle a essayé de moderniser les pilotes. Sur la plupart des appareils, cela a été acceptable. Sur ceux‑ci, elle n’a pas pu remplacer le pilote du périphérique restreint, et les appareils ont continué à fonctionner avec la version approuvée.

Pas d’incident. Pas de panique. Pas d’e‑mail exécutif type « des nouvelles?? ». La pratique ennuyeuse — règles explicites d’autorisation/blocage et paquet connu‑bon — ne les a pas rendus populaires, mais elle les a rendus efficaces. En exploitation, l’efficacité gagne.

Erreurs courantes : symptôme → cause → correction

1) Symptom: “I roll back the driver, but it returns after reboot”

Cause racine : Le paquet plus récent/mauvais est toujours dans le Driver Store et a un meilleur classement. Le rollback change la liaison active, pas l’ensemble des candidats.

Correction : Supprimez l’INF défectueuse du Driver Store avec pnputil /delete-driver ... /uninstall. Ensuite installez le paquet connu‑bon et validez avec un rescan.

2) Symptom: “I disabled driver updates, but the driver still changes”

Cause racine : Un updateur OEM ou une politique MDM installe le pilote en dehors de Windows Update, ou une mise à jour de fonctionnalité remplace les pilotes.

Correction : Identifiez la source via les journaux SetupAPI + tâches/services planifiés. Supprimez/désactivez l’updater OEM ou ajustez la politique MDM/WSUS. Utilisez des restrictions d’installation de périphériques pour un contrôle vraiment durable.

3) Symptom: “Device Manager says one version, but behavior matches the broken version”

Cause racine : Plusieurs composants : paquet pilote vs firmware vs logiciel compagnon ; ou le périphérique utilise en réalité une autre instance (ex. NIC du dock vs NIC interne).

Correction : Confirmez InstanceId et hardware IDs. Énumérez Win32_PnPSignedDriver par DeviceID. Vérifiez quel appareil échoue via les journaux d’événements.

4) Symptom: “pnputil delete-driver fails: driver is in use”

Cause racine : Le pilote est lié à un périphérique actif, ou un autre périphérique utilise le même paquet.

Correction : Désinstallez le(s) périphérique(s), déconnectez le matériel amovible, redémarrez, ou utilisez le mode sans échec. Puis supprimez le pilote à nouveau. Confirmez avec pnputil /enum-drivers.

5) Symptom: “After feature update, drivers reverted to older ones”

Cause racine : Le processus de compatibilité de la mise à niveau a choisi des pilotes « sûrs » pour garantir le démarrage et l’affichage.

Correction : Réappliquez votre pilote connu‑bon après la mise à niveau, et imposez une frontière politique si le système continue de dériver. Pour les flottes, intégrez cela aux séquences de tâches post‑mise à niveau.

6) Symptom: “Only some machines are affected”

Cause racine : Différents subsystem IDs, images OEM différentes, ou différents candidats de pilotes déjà stagés dans le Driver Store.

Correction : Comparez les hardware IDs et le contenu du Driver Store. N’assumez pas qu’« même modèle » signifie « mêmes IDs ». Ce n’est souvent pas le cas.

Checklists / step-by-step plan

Single machine: stop the bleeding in 30 minutes

Identifiez l’instance du périphérique (Task 1) et l’INF actuelle (Task 2).
Confirmez que l’INF défectueuse existe dans le Driver Store (Task 3).
Vérifiez si Windows Update l’a fournie (Task 4) et confirmez via SetupAPI (Task 5).
Évincez le paquet défectueux avec pnputil /delete-driver (Task 9), puis confirmez (Task 10).
Installez le pilote connu‑bon (Task 11).
Désactivez la livraison de pilotes via Windows Update en utilisant une politique (Task 8), au moins temporairement.
Forcez un rescan (Task 16) et redémarrez. Vérifiez à nouveau la version/fournisseur du pilote.

Small fleet: stabilize without creating a new problem

Choisissez une version de pilote connue‑bonne et documentez‑la (fournisseur, version, INF, hardware IDs).
Arrêtez les mises à jour de pilotes via la politique Windows Update (préférez GPO). Validez avec gpresult (Task 13).
Supprimez le mauvais pilote du Driver Store via script (pnputil) pendant des fenêtres de maintenance.
Désactivez les updaters OEM ou configurez‑les pour ne notifier que.
Ajoutez de la surveillance : exécutez périodiquement l’inventaire de pilotes DISM (Task 15) et signalez la dérive selon fournisseur/date/version.

Enterprise: make it boring, repeatable, and auditable

Décidez de la propriété : Windows Update vs OEM vs pilotes packagés par l’IT. La propriété mixte cause la dérive.
Mettez en place des anneaux de pilotes : groupe pilote d’abord, puis déploiement large après validation.
Utilisez les contrôles WSUS/MDM pour empêcher les déploiements de pilotes indésirables. Ne comptez pas sur le masquage endpoint.
Utilisez les restrictions d’installation de périphériques pour les périphériques critiques et ceux connus‑problèmes.
Construisez un playbook de rollback qui inclut l’éviction du Driver Store, pas seulement le rollback du périphérique.
Pendant les mises à jour de fonctionnalité, planifiez une étape de remédiation post‑mise à niveau pour réappliquer les pilotes approuvés et supprimer les non autorisés.

FAQ

1) Pourquoi Windows réinstalle‑t‑il sans cesse le même mauvais pilote après que je l’ai restauré?

Parce que le rollback change la liaison active, mais le paquet pilote plus récent reste souvent dans le Driver Store et continue d’être classé comme la « meilleure » correspondance. Évincez le paquet avec pnputil /delete-driver et bloquez sa livraison.

2) « Ne pas inclure les pilotes avec Windows Update » suffit‑il?

Parfois. Cela bloque la livraison via les mises à jour de qualité, mais n’empêche pas les updaters OEM, les pushes MDM, ou les remplacements lors des mises à jour de fonctionnalité. Si vous avez besoin de garanties, ajoutez l’éviction du Driver Store et des restrictions d’installation.

3) Supprimer le périphérique dans le Gestionnaire supprime‑t‑il le pilote?

Pas de manière fiable. Cela peut désinstaller l’instance du périphérique, mais le paquet pilote peut rester mis en scène. Utilisez pnputil /enum-drivers pour confirmer si l’INF existe toujours.

4) Quelle différence entre « fournisseur Microsoft » et « fournisseur Intel/NVIDIA/AMD »?

« Microsoft » indique souvent que le pilote a été distribué via le pipeline Microsoft (ou est un pilote inbox). Il peut toujours s’agir de code fournisseur. Ne déduisez pas la qualité uniquement du champ fournisseur — vérifiez la version, l’INF et la source.

5) Puis‑je bloquer une mise à jour de pilote précise et autoriser les autres?

Oui, mais le mécanisme dépend de votre environnement. En réseaux gérés, bloquez‑la dans WSUS/ciblage MDM. Sur un PC autonome, masquer la mise à jour peut fonctionner, mais des révisions republiées peuvent contourner ce masquage.

6) Est‑ce sûr de forcer la suppression des pilotes avec pnputil?

Ça peut être sûr si vous comprenez les dépendances. Ne supprimez pas de force des pilotes critiques pour le stockage, le chipset ou le démarrage à moins d’avoir un média de récupération et une procédure de rollback testée. Pour GPU et NIC c’est généralement moins risqué, mais planifiez une fenêtre d’indisponibilité.

7) Pourquoi seules certaines machines reçoivent le mauvais pilote?

Les hardware IDs diffèrent plus qu’on ne le pense — subsystem IDs, révisions et personnalisations OEM changent la correspondance et le classement. De plus, les machines accumulent des contenus Driver Store différents au fil du temps.

8) Comment prouver d’où vient le pilote?

Corrélez les horodatages SetupAPI dans C:\Windows\inf\setupapi.dev.log avec les journaux Windows Update et les horaires des updaters OEM. Ce n’est pas une attribution parfaite, mais c’est suffisant pour identifier l’acteur.

9) Bloquer les pilotes nuit‑il à la sécurité?

Parfois. Les pilotes peuvent contenir des correctifs de sécurité. L’approche correcte est des mises à jour de pilotes contrôlées : tester, approuver, déployer — plutôt que « ne jamais mettre à jour les pilotes ». Stabilité et sécurité peuvent coexister si vous avez un processus plutôt qu’un espoir.

10) Qu’en est‑il des mises à jour de firmware qui ressemblent à des pilotes?

Le firmware (surtout pour le stockage, les docks et Thunderbolt) peut être distribué comme une mise à jour et modifier le comportement comme une régression de pilote. Traitez le firmware comme une partie de la pile : inventaire, contrôle, et évitez que trois outils différents le mettent à jour indépendamment.

Conclusion : étapes pratiques suivantes

Si Windows réinstalle sans cesse un mauvais pilote, arrêtez de négocier avec lui. Faites trois choses dans l’ordre :

Identifier l’instance du périphérique, la version actuelle du pilote et le nom de l’INF (Tasks 1–3).
Évincer le paquet de pilote indésirable du Driver Store et installez votre version connue‑bonne (Tasks 9–11).
Faire respecter la frontière : bloquez la livraison de pilotes via une politique et/ou verrouillez le périphérique avec des restrictions d’installation (Tasks 8, 12–14).

Puis testez en pessimiste : rescan de périphériques, redémarrer, dock/undock, et lancer Windows Update. S’il reste stable après ça, il restera probablement stable face aux surprises de la semaine suivante aussi.