Une mise à jour du pilote a tué mon FPS : comment diagnostiquer correctement

octobre 14, 2025 • février 3, 2026 • Lecture : 27 min • Views: 0

Cet article vous a aidé ?

Vous avez mis à jour votre pilote GPU parce que vous êtes un adulte responsable qui applique des correctifs. Puis votre jeu s’est transformé en flipbook. Le FPS a chuté, les temps de trame ressemblent à un sismographe, et il ne manque plus qu’un seul accro pour que vous juriez de ne plus jamais mettre à jour.

Ne devinez pas. Diagnostiquez. Vous ne chassez pas une impression ; vous chassez des goulets d’étranglement, des régressions et des fonctionnalités « utiles » qui ont changé silencieusement. Traitez cela comme un incident : confirmez la régression, capturez des preuves, isolez les variables, et revenez en arrière ou avancez en toute confiance.

Playbook de diagnostic rapide (15 minutes)

Ceci est la séquence « arrêtez de scroller et obtenez du signal ». L’objectif n’est pas d’optimiser votre système. L’objectif est de répondre à une question : quoi limite les performances en ce moment, et la mise à jour du pilote a-t-elle pu raisonnablement provoquer cette limitation ?

Étape 1 (3 minutes) : Prouvez que c’est une régression, pas une charge différente

Utilisez la même version du jeu, la même scène, la même résolution, les mêmes réglages, la même sauvegarde, la même carte, le même angle de caméra si possible.
Redémarrez une fois après l’installation du pilote. Les pilotes aiment l’état « tout en attente ».
Désactivez les choses « ponctuelles » : vidéo dans le navigateur, copies de fichiers, téléchargements de patchs du jeu.

Décision : Si vous ne pouvez pas reproduire la baisse dans une scène contrôlée, ce n’est pas encore un incident—juste du bruit.

Étape 2 (4 minutes) : Identifiez la classe de goulet d’étranglement

Limité par le GPU : utilisation GPU proche du maximum, le FPS évolue avec la résolution, baisser les réglages graphiques aide.
Limité par le CPU : un ou deux cœurs saturés, l’utilisation GPU chute, baisser la résolution n’aide pas beaucoup.
Stutter / limité par l’I/O : FPS moyen correct, pics de frametime, lectures disque, compilation de shaders, streaming d’actifs.
Limité par l’ordonnancement / latence : la saisie est collante, l’audio craque, pics de latence DPC, implication d’outils de capture/overlay.

Décision : Choisissez l’outil de diagnostic suivant selon la classe de goulet d’étranglement. N’« essayez » pas des corrections au hasard.

Étape 3 (4 minutes) : Éliminez les suspects habituels que les pilotes activent indirectement

Overlays/capture (Steam, Discord, GeForce Experience, Xbox Game Bar).
Politique d’alimentation / performance (plan d’alimentation Windows, outils OEM pour portable).
VRR / limites de trame / comportement V-Sync modifiés.
Reconstruction du cache de shaders après mise à jour du pilote.
Bascule ReBAR / MPO / HAGS (selon la branche du pilote et l’OS).

Décision : Si désactiver une catégorie restaure les performances, vous avez trouvé une interaction—pas « votre GPU est devenu plus lent ».

Étape 4 (4 minutes) : Restaurez ou réinstallez proprement selon les preuves

Si la régression est évidente et reproductible : revenez à la version connue bonne.
Si la mise à jour du pilote a été sale (restes, plantages, redétection du périphérique) : faites une installation propre.

Décision : Privilégiez le rollback quand vous avez besoin de stabilité ; privilégiez l’installation propre quand les preuves hurlent « hygiène d’installation ».

Une idée paraphrasée (attribuée) : Werner Vogels insiste souvent sur le fait qu’il faut « construire pour l’échec » et apprendre vite—traitez les régressions comme des données, pas comme du drame. (idée paraphrasée)

Ce qu’une mise à jour du pilote change vraiment (et pourquoi le FPS s’effondre)

Un pilote GPU n’est pas seulement « de nouvelles optimisations ». C’est un moteur de politiques. Il décide comment les shaders sont compilés et mis en cache, comment l’OS planifie le travail, comment les états d’alimentation évoluent, comment le pacing des images est géré, et comment le pilote interagit avec des fonctionnalités du compositeur comme le VRR et le multi-plane overlay. Il peut aussi changer des valeurs par défaut. Les valeurs par défaut sont l’endroit où les bonnes intentions deviennent votre pire benchmark.

Pensez à votre jeu comme à un pipeline : entrée → simulation → draw calls → exécution GPU → présentation. Une mise à jour du pilote peut déplacer le point d’étranglement vers une autre étape. Le FPS moyen peut chuter. Ou il peut rester identique tandis que les frametimes deviennent laid. Ce dernier cas est plus courant qu’on ne le dit, parce que « ça paraît pire » est généralement un problème de latence/pacing, pas de débit brut.

Les pilotes livrent aussi des correctifs qui ressemblent à des régressions parce qu’ils cessent de dépendre d’un comportement indéfini. Certains jeux (et mods) dépendent de bizarreries. Quand le pilote cesse de faire cette chose accidentellement utile, votre FPS « change mystérieusement ». Le mystère, c’est que cela passait jusque-là.

Et oui : parfois c’est juste une mauvaise release. Ça arrive. Le travail consiste à le prouver, l’isoler, et décider de revenir en arrière, d’appliquer un correctif, ou d’ajuster l’environnement.

Blague #1 : Une mise à jour de pilote, c’est comme un « petit refactor » le vendredi—techniquement correct, émotionnellement dangereux.

Faits intéressants et contexte historique

Les « profils jeu » des pilotes sont anciens : les vendeurs GPU ont fourni des optimisations par jeu pendant des décennies ; un nouveau pilote peut changer le comportement pour un titre sans toucher aux autres.
Le frame pacing est devenu un sujet grand public au début des années 2010 : le FPS moyen allait bien, mais des frametimes inégaux rendaient le gameplay pire que le chiffre ne le laissait penser.
Le stutter de compilation des shaders n’est pas nouveau : les API et moteurs plus anciens compilaient davantage hors ligne ; les pipelines modernes compilent ou spécialisent souvent les shaders à l’exécution, et les caches dépendent du pilote.
WDDM a changé les règles : le modèle de pilote Windows a évolué entre les versions, affectant l’ordonnancement, la gestion mémoire et les chemins de présentation—les mises à jour de pilote peuvent « activer » différents chemins sur la même build d’OS.
Les overlays hookent historiquement les chemins de rendu : compteurs FPS et outils de capture s’injectent souvent dans les API graphiques ; une mise à jour du pilote peut modifier les points d’accroche et l’overhead.
Le multi-plane overlay (MPO) est un suspect fréquent : c’est une fonction du compositeur qui peut améliorer l’efficacité, mais certaines combinaisons de pilotes, moniteurs et applis ont produit stutter ou scintillement au fil des années.
Le support VRR a mûri de manière inégale : le comportement G-SYNC/FreeSync dépend du firmware du moniteur, de la politique du pilote et des règles du compositeur OS ; les mises à jour peuvent déplacer la gestion des cas limites.
La gestion d’alimentation est devenue plus agressive : GPUs et CPUs modernes changent rapidement d’états de fréquence ; un petit changement de politique peut affecter le boost et la constance des frametimes.
Resizable BAR (ReBAR) est une variante moderne d’une vieille idée : mapper de plus larges fenêtres mémoire GPU peut aider certaines charges et en pénaliser d’autres selon les schémas d’accès du jeu et les heuristiques du pilote.

Mesurer d’abord : le FPS est un symptôme, le frametime est la maladie

Quand quelqu’un dit « mon FPS a baissé », je demande : FPS moyen ou 1% lows ? Parce que les régressions de pilote touchent souvent la queue de distribution. Le jeu affiche encore « 120 FPS », mais vous ressentez des accrocs périodiques de 40–80 ms.

Le frametime est le temps pour produire une image. Un 16,6 ms stable est fluide (60 FPS). Un 8,3 ms stable est fluide (120 FPS). Un mélange de 5 ms, 6 ms, 40 ms, 7 ms est affreux, même si la moyenne semble correcte. Votre cerveau n’en fait pas la moyenne ; il se plaint.

Donc : capturez des métriques qui séparent le débit de la latence.

FPS moyen : débit.
1% / 0,1% lows : latence de queue des images.
Graphe de frametime : pacing et pics.
Utilisation GPU/CPU : où vous êtes limité.
Mode de present / chemin du compositeur : si vous luttez contre le bureau.

Aussi : si vous avez mis à jour le pilote et relancé un benchmark immédiatement, vous avez peut‑être mesuré le réchauffement du cache de shaders, pas la performance. La première exécution peut être mauvaise. La seconde montre la réalité. La troisième donne des statistiques.

Blague #2 : Votre FPS n’a pas « mouru ». Il attend juste une étape de compilation qui traverse une crise existentielle.

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

Ces tâches sont pour les systèmes Windows parce que c’est là que se trouvent la plupart des incidents « le pilote a tué mon FPS ». J’inclus les outils des vendeurs quand applicable. Utilisez ce qui correspond à votre GPU.

Tâche 1 : Confirmer la version et la date du pilote GPU (NVIDIA)

cr0x@server:~$ nvidia-smi
Tue Jan 21 10:14:02 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 555.42                 Driver Version: 555.42         CUDA Version: 12.5     |
|-----------------------------------------+------------------------+----------------------|
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  GeForce RTX 4070 Ti           Off  |   00000000:01:00.0  On |                  N/A |
|  36%   63C    P2              165W / 285W|   7340MiB / 12282MiB   |     96%      Default |
+-----------------------------------------+------------------------+----------------------+

Ce que ça signifie : Vous avez une version concrète du pilote pour la corréler avec la régression. Notez aussi l’état de performance (P2 vs P0) et l’utilisation GPU.

Décision : Si la version n’est pas celle que vous vouliez (Windows Update « a aidé »), arrêtez et corrigez la provenance du pilote avant d’approfondir.

Tâche 2 : Confirmer la version du pilote GPU (outil Windows intégré)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_VideoController | Select-Object Name, DriverVersion, DriverDate"
Name                           DriverVersion    DriverDate
----                           -------------    ----------
NVIDIA GeForce RTX 4070 Ti     31.0.15.5542     12/18/2025 12:00:00 AM

Ce que ça signifie : Version du pilote telle que Windows la voit, plus une date. Cela détecte les cas où le panneau de contrôle affirme une chose et le pilote installé en est une autre.

Décision : Si la date/version ne correspond pas à votre « dernier connu bon », vous avez une fenêtre de régression. Bien. Vous pouvez maintenant bisecter.

Tâche 3 : Vérifier que vous n’êtes pas accidentellement sur l’iGPU (fréquent sur les portables)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_VideoController | Select-Object Name, AdapterRAM, VideoProcessor"
Name                         AdapterRAM   VideoProcessor
----                         ----------   --------------
Intel(R) Iris(R) Xe Graphics 1073741824   Intel(R) Iris(R) Xe Graphics
NVIDIA GeForce RTX 3060      12884901888  NVIDIA GeForce RTX 3060

Ce que ça signifie : Les deux adaptateurs existent ; le jeu peut avoir changé de préférence après la mise à jour.

Décision : Si le FPS a chuté et que vous voyez l’iGPU actif dans les overlays ou le Gestionnaire des tâches pendant le jeu, forcez le jeu sur le GPU discret dans les Paramètres graphiques de Windows et le panneau de contrôle du vendeur.

Tâche 4 : Vérifier le plan d’alimentation Windows (parce que « Équilibré » peut surprendre)

cr0x@server:~$ powercfg /getactivescheme
Power Scheme GUID: 381b4222-f694-41f0-9685-ff5bb260df2e  (Balanced)

Ce que ça signifie : Vous êtes sur Équilibré. Ce n’est pas automatiquement mauvais, mais c’est un coupable fréquent de frametime sur certains systèmes.

Décision : Si les frametimes se sont détériorés après la mise à jour et que vous êtes sur Équilibré, testez Haute performance (bureau) ou le mode « Performance » OEM (portable). Mesurez ; ne croyez pas aveuglément.

Tâche 5 : Vérifier si le Mode Jeu est activé (et s’il corrèle)

cr0x@server:~$ powershell -NoProfile -Command "reg query HKCU\Software\Microsoft\GameBar /v AllowAutoGameMode"
HKEY_CURRENT_USER\Software\Microsoft\GameBar
    AllowAutoGameMode    REG_DWORD    0x1

Ce que ça signifie : Mode Jeu activé. Généralement c’est OK ; parfois il interagit mal avec capture/overlays ou tâches en arrière-plan.

Décision : Si le problème ressemble à du jitter d’ordonnancement, testez en basculant le Mode Jeu et re-mesurez la même scène.

Tâche 6 : Inspecter HAGS (Hardware-accelerated GPU scheduling)

cr0x@server:~$ powershell -NoProfile -Command "reg query HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers /v HwSchMode"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers
    HwSchMode    REG_DWORD    0x2

Ce que ça signifie : HwSchMode=2 signifie généralement activé. Certains rigs l’adorent. D’autres ont des stutters.

Décision : Si le souci est « on ressent pire » plutôt que « les benchmarks sont plus bas », essayez de basculer HAGS et retestez. Si ça corrige, vous avez trouvé une interaction de politique.

Tâche 7 : Vérifier si votre fréquence de rafraîchissement a été réinitialisée (classique après mise à jour)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -Namespace root\wmi -ClassName WmiMonitorListedSupportedSourceModes | Select-Object -First 1 -ExpandProperty MonitorSourceModes | Select-Object -First 5"
HorizontalActivePixels VerticalActivePixels RefreshRate
---------------------- ------------------- -----------
1920                   1080                60
1920                   1080                120
1920                   1080                144
2560                   1440                60
2560                   1440                144

Ce que ça signifie : Modes supportés. Vous devez toujours confirmer ce qui est réellement sélectionné dans les Paramètres d’affichage de Windows, mais ceci aide à détecter les situations où le moniteur a négocié le mauvais mode.

Décision : Si vous vouliez 144 Hz et que vous êtes sur 60 Hz, votre histoire de cap/latence sera étrange. Corrigez la fréquence avant de chasser des fantômes.

Tâche 8 : Vérifier si le jeu est limité par le CPU ou le GPU (échantillonnage rapide en direct)

cr0x@server:~$ typeperf "\Processor(_Total)\% Processor Time" "\GPU Engine(*)\Utilization Percentage" -sc 5
"(PDH-CSV 4.0)","\\HOST\Processor(_Total)\% Processor Time","\\HOST\GPU Engine(pid_1234_luid_0x0000_0x0000_eng_3D)\Utilization Percentage"
"01/21/2026 10:18:01.123","42.318","97.000"
"01/21/2026 10:18:02.123","45.102","98.000"
"01/21/2026 10:18:03.123","41.777","96.000"
"01/21/2026 10:18:04.123","43.550","97.000"
"01/21/2026 10:18:05.123","44.001","98.000"

Ce que ça signifie : Utilisation GPU proche du max tandis que le CPU est modéré suggère un goulot GPU. Si l’utilisation GPU est faible et le CPU élevé (ou un cœur élevé), vous êtes limité par le CPU/ordonnancement.

Décision : Si vous êtes GPU-bound et que le FPS a baissé après la mise à jour du pilote, concentrez-vous sur les réglages du pilote (alimentation, filtrage de texture, cache de shaders, VRR, caps de trame). Si CPU-bound, concentrez-vous sur l’ordonnancement, les processus en arrière-plan et le comportement de puissance/boost CPU.

Tâche 9 : Identifier les principaux consommateurs CPU en arrière-plan pendant le jeu

cr0x@server:~$ powershell -NoProfile -Command "Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 Name,Id,CPU"
Name            Id      CPU
----            --      ---
Game.exe      1234  812.43
MsMpEng       4321  210.10
Discord       9876   55.22
chrome        2468   44.01
OneDrive      1357   21.88

Ce que ça signifie : Defender (MsMpEng) ou des outils de synchronisation peuvent consommer du CPU et provoquer du stutter, surtout pendant la reconstruction du cache de shaders ou quand le jeu écrit fréquemment des logs/configs.

Décision : Si un processus en arrière-plan est constamment élevé durant les stutters, mettez-le en pause, excluez le répertoire du jeu des analyses (prudemment), ou programmez-le hors de la session de jeu. Retestez.

Tâche 10 : Vérifier la santé du disque et si le disque du jeu est sollicité

cr0x@server:~$ powershell -NoProfile -Command "Get-PhysicalDisk | Select-Object FriendlyName, MediaType, HealthStatus, OperationalStatus"
FriendlyName        MediaType HealthStatus OperationalStatus
------------        --------- ------------ -----------------
Samsung SSD 980 Pro SSD       Healthy      OK
WDC WD10EZEX       HDD        Healthy      OK

Ce que ça signifie : Confirme que vous ne streamez pas depuis un HDD mourant en supposant qu’il est « correct ».

Décision : Si le jeu est sur un HDD et que vous observez du stutter après une mise à jour, déplacez-le sur SSD avant de blâmer le pilote. Les pilotes peuvent changer le comportement du cache de shaders et augmenter le churn disque.

Tâche 11 : Vérifier les E/S disque en temps réel en reproduisant un stutter

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\PhysicalDisk(_Total)\Avg. Disk sec/Read','\PhysicalDisk(_Total)\Disk Reads/sec' -SampleInterval 1 -MaxSamples 5"
Timestamp                 CounterSamples
---------                 --------------
01/21/2026 10:22:11       \\HOST\physicaldisk(_total)\avg. disk sec/read : 0.085
                          \\HOST\physicaldisk(_total)\disk reads/sec : 420.000
01/21/2026 10:22:12       \\HOST\physicaldisk(_total)\avg. disk sec/read : 0.120
                          \\HOST\physicaldisk(_total)\disk reads/sec : 610.000
01/21/2026 10:22:13       \\HOST\physicaldisk(_total)\avg. disk sec/read : 0.015
                          \\HOST\physicaldisk(_total)\disk reads/sec : 95.000
01/21/2026 10:22:14       \\HOST\physicaldisk(_total)\avg. disk sec/read : 0.090
                          \\HOST\physicaldisk(_total)\disk reads/sec : 500.000
01/21/2026 10:22:15       \\HOST\physicaldisk(_total)\avg. disk sec/read : 0.010
                          \\HOST\physicaldisk(_total)\disk reads/sec : 80.000

Ce que ça signifie : Les pics d’Avg. Disk sec/Read (par ex. 80–120 ms) se corrèlent avec des stalls de streaming d’actifs. Un SSD devrait généralement être bien plus bas sous charge de jeu, même si des pics peuvent survenir.

Décision : Si les stutters coïncident avec des pics de latence disque, investiguez la reconstruction du cache de shaders, l’analyse antivirus, la contention CPU due à la décompression, et l’espace libre / throttling thermique du disque.

Tâche 12 : Vérifier si le GPU est limité par la puissance ou bloqué dans un état de performance inférieur (NVIDIA)

cr0x@server:~$ nvidia-smi -q -d PERFORMANCE | sed -n '1,120p'
==============NVSMI LOG==============
Timestamp                                 : Tue Jan 21 10:24:01 2026
Driver Version                            : 555.42
GPU 00000000:01:00.0
    Performance State                      : P2
    Clocks Throttle Reasons
        Idle                               : Not Active
        Applications Clocks Setting         : Not Active
        SW Power Cap                        : Active
        HW Slowdown                         : Not Active
        Thermal Slowdown                    : Not Active

Ce que ça signifie : Vous êtes en P2 et le cap logiciel de puissance est actif. Cela peut arriver à cause des réglages d’alimentation, d’outils d’OC, ou de changements de valeurs par défaut du vendeur.

Décision : Si SW Power Cap est actif pendant le jeu alors que ce n’était pas le cas avant, inspectez le mode d’alimentation du panneau du vendeur, retirez les outils d’OC tiers, et vérifiez l’alimentation/les connecteurs PSU. Ne « corrigez » pas cela en augmentant aveuglément les limites de puissance sans comprendre pourquoi cela a changé.

Tâche 13 : Vérifier les journaux Windows pour les réinitialisations du pilote d’affichage (TDR)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; Id=4101} -MaxEvents 5 | Format-Table TimeCreated, ProviderName, Message -AutoSize"
TimeCreated           ProviderName      Message
-----------           ------------      -------
01/21/2026 09:55:12   Display           Display driver nvlddmkm stopped responding and has successfully recovered.

Ce que ça signifie : Le pilote s’est réinitialisé. Cela peut provoquer du stutter, une baisse d’horloge, ou une instabilité qui ressemble à une « baisse de FPS ».

Décision : Si vous avez des TDR après la mise à jour, arrêtez l’optimisation de performance et commencez le débogage de stabilité : installation propre, suppression des overclocks/undervolts, vérification des températures, vérification de l’alimentation PCIe, envisagez un rollback.

Tâche 14 : Capturer une trace prête pour GPUView (avancé, mais décisif)

cr0x@server:~$ wpr -cancel
WPR session cancelled.
cr0x@server:~$ wpr -start GPU -start CPU -filemode
Recording...
cr0x@server:~$ timeout /t 15
Waiting for 15 seconds...
cr0x@server:~$ wpr -stop C:\Temp\fps_drop_trace.etl
WPR trace saved to: C:\Temp\fps_drop_trace.etl

Ce que ça signifie : Vous avez capturé une trace que vous pouvez inspecter pour des stalls d’ordonnancement, des problèmes de present, et des problèmes de recouvrement CPU/GPU.

Décision : Si la trace montre de longues pauses dans la soumission du travail GPU, le CPU (ou l’overhead du pilote) est votre goulet. Si la file GPU est pleine et que le present est bloqué, examinez les interactions VRR/V-Sync/compositeur.

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

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

Dans un studio de taille moyenne, un responsable QA a signalé une « régression de pilote » sur la dernière release d’un grand vendeur GPU. Le FPS avait chuté de 25–30 % dans leur scène de benchmark. L’ambiance était familière : incriminer le pilote, alerter le représentant du vendeur, retenir les notes de version en otage.

L’hypothèse erronée était subtile : ils supposaient que la scène de benchmark était stable entre les builds. Elle ne l’était pas. Une mise à jour de contenu était arrivée la même semaine—nouveau système de particules, chemin de caméra légèrement différent, et un nouveau toggle de post-traitement qui s’activait par défaut pour les configs fraîches.

Nous l’avons traitée comme un incident SRE de toute façon. Nous avons verrouillé la charge de travail : même hash exécutable, même fichier de config, même chemin de replay, même état du cache de shaders. Nous avons aussi diffé les répertoires de config du jeu avant et après l’exécution. Surprise : le nouveau pilote avait forcé une réinitialisation graphique « premier lancement » pour ce titre, qui réactivait une fonctionnalité coûteuse qu’ils laissaient normalement désactivée dans les benchmarks.

Une fois la config figée, la « régression » est retombée à une erreur d’arrondi. Il restait un petit changement dans la queue de frametime, mais pas la chute annoncée. Le vrai coupable était un changement de valeur par défaut et un benchmark qui dérivait silencieusement.

Enseignement : si vous ne pouvez pas épingler la charge de travail, vous ne faites pas du benchmarking ; vous jouez au benchmark.

Mini-récit n°2 : L’optimisation qui a mal tourné

Une équipe IT d’entreprise a voulu bien faire. Ils ont déployé un nouveau pilote GPU sur une flotte de stations—certaines pour DAO, certaines pour simulation, et oui, certaines pour du jeu après les heures. Le pilote promettait de meilleures performances et des correctifs de sécurité, et la fenêtre de changement était « calme ».

Après le déploiement, un groupe d’utilisateurs a signalé du stutter dans des jeux et certains outils de visualisation. Le FPS moyen était correct, mais l’interaction était collante. Les gens ont commencé à tout désactiver : Mode Jeu, overlays, même leur second écran. Le classique.

L’« optimisation » consistait à activer un ensemble de valeurs par défaut basse-latence et économies d’énergie via un profil de gestion. L’intention était de réduire les thermiques et le bruit des ventilateurs dans un open space. Ça a marché—les thermiques ont baissé. Mais la livraison régulière des images aussi. Les GPUs oscillaient entre états plus agressivement, et les pics de frametime coïncidaient avec les transitions d’état.

La correction était ennuyeuse : définir une politique d’alimentation stable pour les machines qui font du rendu interactif, et ne pas forcer globalement des « modes latence » orientés jeu. Aussi : testez les changements sur un sous-ensemble représentatif, pas sur le GPU le plus bruyant de l’inventaire.

Les « améliorations » de performance qui ne sont pas mesurées contre la qualité d’interaction ne sont que des impressions avec des privilèges administratifs.

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

Une société financière utilisait une petite appli de visualisation interne qui employait un moteur de jeu pour des tableaux de bord temps réel. Pas une blague. C’était un mur d’écrans, et il fallait que ça paraisse fluide parce que les dirigeants remarquent le stutter comme des requins sentent le sang.

L’équipe avait une politique : chaque mise à jour de pilote exigeait une capture « scène connue », un rapport de frametime, et un plan de rollback. Personne n’aimait ça. Ça ressemblait à de la paperasse. Mais ils l’ont maintenue parce qu’une mauvaise mise à jour des années plus tôt avait transformé une démo live en diaporama.

Cette fois, le nouveau pilote introduisait des hitchs sporadiques sur les configurations multi-écrans. L’équipe avait déjà des baselines : même scène, même hardware, même build OS. La régression était évidente dans les 1% lows et dans une trace montrant des retards de present corrélés à l’activité du compositeur.

Ils ont rollé en moins d’une heure, poussé un changement de config pour désactiver un composant d’overlay problématique dans l’app, et retesté. Le problème a disparu. Ils ont ensuite figé les versions de pilote pour les machines de démo jusqu’à ce qu’un correctif fournisseur soit validé.

La pratique ennuyeuse—baselines et rollback—leur a évité de débattre de la réalité du problème. Ils avaient des graphiques. Les dirigeants ont eu des visuels fluides. Les ingénieurs ont pu dormir.

Erreurs courantes : symptôme → cause racine → correction

Voici la partie où vous arrêtez d’allumer des bougies et commencez à utiliser un multimètre.

1) « Le FPS est plus bas partout »

Symptôme : Tous les jeux sont en baisse de 10–30 % après la mise à jour.
Cause racine : La politique d’alimentation a changé (plan Windows, mode performance portable, « optimal power » du vendeur), ou la GPU est en underclock à cause d’un cap.
Correction : Vérifiez le plan d’alimentation actif ; contrôlez l’état de perf GPU et les raisons de throttling ; assurez-vous que le mode du panneau vendeur est adapté au jeu ; retirez les outils de tuning tiers et retestez.

2) « Le FPS moyen va bien, mais ça stutter en permanence »

Symptôme : Pics de frametime toutes les quelques secondes ; la saisie est irrégulière.
Cause racine : Overlays/capture qui hookent, reconstruction du cache de shaders, ou analyses en arrière-plan (Defender) sur les fichiers de cache.
Correction : Désactivez temporairement les overlays ; lancez la scène deux fois pour chauffer les caches ; excluez prudemment les dossiers de cache de shaders ; stoppez les téléchargements en arrière-plan.

3) « Baisser la résolution n’aide pas »

Symptôme : 1440p et 1080p donnent quasiment les mêmes performances, toujours basses.
Cause racine : Goulot CPU ou overhead du pilote. Parfois un nouveau pilote change le comportement de threading ou augmente le coût CPU par draw call.
Correction : Mesurez l’utilisation par cœur CPU ; fermez les gouffres CPU en arrière-plan ; vérifiez si le jeu est passé en mode fenêtré sans bord (borderless) avec overhead du compositeur ; envisagez un rollback si une repro propre montre une augmentation du temps CPU par frame.

4) « Le plein écran est pire que le borderless (ou inversement) »

Symptôme : Un mode d’affichage a une pire latence ou provoque du stutter.
Cause racine : Différents chemins de present et interactions du compositeur ; mismatch politique VRR/V-Sync.
Correction : Testez les deux modes avec le même cap de trame ; vérifiez les réglages VRR ; assurez-vous que la fréquence de rafraîchissement est correcte ; envisagez de désactiver MPO/HAGS à titre d’expérience si les preuves pointent vers des problèmes de présentation.

5) « Un seul jeu est cassé »

Symptôme : Un titre chute ; les autres sont normaux.
Cause racine : Changement de profil pilote spécifique au jeu, synchronisation de patch du jeu, invalidation du cache de shaders pour ce moteur, ou interaction avec un anti-triche/overlay particulier.
Correction : Épinglez la version du jeu ; videz et reconstruisez son cache de shaders ; désactivez les hooks tiers ; testez le rollback du pilote juste pour valider, pas par superstition.

6) « Après la mise à jour, mon utilisation GPU est faible »

Symptôme : L’utilisation GPU chute à 40–70 % alors que le FPS est bas.
Cause racine : Limite CPU, processus en arrière-plan volant des tranches de temps, problèmes d’ordonnancement du pilote, ou jeu tournant sur l’iGPU.
Correction : Confirmez le GPU actif ; vérifiez le CPU par cœur ; capturez une trace si nécessaire ; assurez-vous qu’il n’y a pas de cap caché de trame actif.

7) « Le FPS est bloqué à 60 maintenant »

Symptôme : Cap dur à 60 quel que soit le réglage.
Cause racine : Fréquence de rafraîchissement réinitialisée à 60 Hz, V-Sync forçant la synchronisation, limite de trame activée dans le pilote, ou jeu passé à un autre mode d’affichage.
Correction : Vérifiez la fréquence du moniteur, désactivez temporairement les caps côté pilote, testez plein écran exclusif vs borderless, et vérifiez le limiteur dans le jeu.

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

Checklist A : Avant de toucher quoi que ce soit (disciple du baseline)

Redémarrez une fois après l’installation du pilote.
Choisissez une scène reproductible (benchmark, replay, champ d’entraînement, angle de caméra fixe).
Enregistrez : résolution, preset graphique, réglages DLSS/FSR, état V-Sync/VRR, cap de trame, mode d’affichage.
Exécutez la scène deux fois ; enregistrez la deuxième exécution (cache chauffé).
Capturez : FPS moyen, 1% low, graphe de frametime si disponible.

Checklist B : Isolation (ne changez qu’une chose à la fois)

Désactivez les overlays un par un (Discord, Steam, Xbox Game Bar, overlay vendeur).
Pausez les tâches en arrière-plan (navigateur, synchronisation cloud, téléchargements).
Basculez HAGS et retestez.
Alternez plein écran et borderless ; retestez.
Basculez VRR (G-SYNC/FreeSync) et stratégie V-Sync ; retestez.
Essayez le dernier pilote connu bon (rollback) pour confirmer la régression.

Checklist C : Quand vous suspectez un problème d’hygiène d’installation

Exportez vos réglages actuels (captures d’écran des paramètres du panneau de contrôle suffisent).
Effectuez une installation propre du pilote (option du programme d’installation du vendeur) et redémarrez.
Retestez avec les paramètres par défaut d’abord.
Réappliquez seulement les réglages que vous pouvez justifier par des mesures.

Checklist D : Quand vous suspectez le stockage ou le cache de shaders

Confirmez que le jeu est sur SSD.
Vérifiez l’espace libre (laissez de la marge ; les SSD détestent être pleins).
Surveillez la latence disque pendant les stutters.
Exécutez la même scène plusieurs fois pour voir si le stutter s’estompe après reconstruction du cache.
Si nécessaire, videz les caches de shaders (jeu et pilote) et reconstruisez une fois—puis mesurez la seconde exécution.

FAQ

1) Dois‑je toujours revenir en arrière si le FPS baisse après une mise à jour ?

Non. Revenez en arrière quand vous pouvez reproduire la régression dans une scène contrôlée et que vous avez besoin de stabilité immédiatement. Si l’installation est désordonnée ou qu’il y a une dérive des réglages, une installation propre peut résoudre sans sacrifier les correctifs de sécurité et les profils jeu.

2) Pourquoi la première exécution après une mise à jour stutter plus ?

Les caches de shaders s’invalident souvent après une mise à jour du pilote. Le jeu recompile ou respecialise des shaders pendant le jeu, provoquant des pics de frametime. Mesurez la deuxième exécution, pas la panique initiale.

3) Mon FPS moyen est correct, mais c’est « moins agréable ». Que mesurer ?

Graphes de frametime et 1% lows. Vérifiez aussi le mode de present et le comportement du compositeur (plein écran vs borderless), et désactivez les overlays. « Moins agréable » est généralement du pacing ou de la latence, pas la puissance GPU brute.

4) Windows Update peut‑il remplacer mon pilote GPU et casser les performances ?

Oui. Il peut installer une branche de pilote différente ou une variante « safe ». Confirmez la version du pilote installée depuis Windows, pas seulement via le panneau du vendeur.

5) Les overlays coûtent‑ils vraiment autant de performance ?

Parfois non, parfois oui—surtout lorsqu’ils s’additionnent à des chemins de present spécifiques ou des fonctions de capture. Le geste diagnostique est simple : désactivez-les et retestez la même scène.

6) Ça vaut la peine de basculer HAGS, MPO, ou d’autres fonctions graphiques OS ?

Seulement si vous avez des symptômes cohérents avec des problèmes d’ordonnancement/present (stutter, latence étrange, anomalies borderless) et que vous mesurez avant/après. Basculer au hasard sans données, c’est du cargo culting.

7) Pourquoi baisser la résolution n’augmente plus le FPS ?

Vous êtes probablement limité par le CPU, ou vous atteignez un cap de trame (V-Sync, limiteur, comportement VRR). Si le GPU n’est pas proche de son utilisation maximale, n’essayez pas de « optimiser les réglages graphiques ». Vous travaillez du mauvais côté du pipeline.

8) Le stockage peut‑il vraiment affecter le FPS si le jeu « tourne bien » ?

Le stockage affecte les frametimes via le streaming d’actifs et les lectures/écritures du cache de shaders. Une mise à jour de pilote peut changer le comportement du cache et augmenter le churn disque. Si les pics de latence disque coïncident avec les stutters, le stockage fait partie de l’histoire.

9) Quelle est la cause la plus commune des bizarreries post‑mise à jour ?

Dérive des réglages : réinitialisation de la fréquence de rafraîchissement, changements de politique V-Sync/VRR, modifications du mode d’alimentation, overlays réactivés, ou le jeu passant en un autre mode d’affichage. La correction consiste à vérifier l’environnement avant d’incriminer le pilote.

10) Quand devrais‑je escalader vers une trace « réelle » (WPR/GPUView) ?

Quand vous pouvez reproduire le problème de façon fiable et que les vérifications simples n’identifient pas le goulet d’étranglement. Une trace convertit les arguments en timelines : gaps de soumission CPU, present bloqués, overhead du pilote et contention deviennent visibles.

Étapes suivantes que vous pouvez faire aujourd’hui

Faites ceci dans l’ordre. C’est volontairement ennuyeux.

Verrouillez une scène. Même endroit, mêmes réglages, seconde exécution mesurée.
Confirmez la provenance. Enregistrez la version/date du pilote depuis Windows et (si applicable) les outils du vendeur.
Classifiez le goulet d’étranglement. GPU-bound, CPU-bound, I/O-bound, ou pacing/present-bound.
Éliminez l’overhead évident. Désactivez temporairement overlays/capture ; mettez en pause les tâches en arrière-plan.
Vérifiez rafraîchissement et caps. Assurez-vous de ne pas être retombé à 60 Hz ou d’avoir activé un limiteur.
Décidez rollback vs installation propre. Régression reproductible → rollback pour valider. Comportement chaotique/TDRs/paramètres volatils → installation propre et retest en paramètres par défaut.
Si vous êtes toujours bloqué, tracez. Capturez une trace WPR et inspectez l’ordonnancement et le comportement de present. Les preuves gagnent sur l’archéologie des forums.

L’objectif n’est pas de ne jamais mettre à jour les pilotes. L’objectif est de mettre à jour comme vous gérez des systèmes : mesurez, isolez, et gardez un chemin de rollback. Votre GPU aura encore de mauvais jours, mais au moins vous saurez pourquoi.