8000 Hz. Sur le papier, c’est le genre de spec qui fait briller les yeux : votre souris envoie sa position au PC huit mille fois par seconde, contre cent fois pour une souris standard à 1000 Hz. Le marketing autour de ce chiffre est parfaitement rodé, et pendant un moment, j’y ai cru dur comme fer. Puis mon CPU a décroché en plein milieu d’un match compétitif, les ventilateurs à fond, le framerate en chute libre. C’est là que j’ai commencé à comprendre que j’avais confondu « plus de chiffres » avec « mieux jouer ».
À retenir
- Chaque requête souris génère une interruption CPU : à 8000 Hz, le système peut saturer sans qu’on le voit venir
- La différence perceptible entre 1 ms et 0,125 ms représente moins de 0,6% du temps de réaction humain
- Un polling rate stable à 1000 Hz produit des trajectoires d’aim plus lisses qu’un 8000 Hz instable sur un CPU surchargé
Ce que persiste à coûter un taux de polling élevé
Le polling rate d’une souris, c’est la fréquence à laquelle le périphérique communique sa position au système d’exploitation. À 1000 Hz, ce signal arrive toutes les millisecondes. À 8000 Hz, toutes les 0,125 ms. La différence théorique existe, personne ne la nie. Mais cette communication ne se fait pas gratuitement : chaque rapport envoyé génère une interruption processeur, et à 8000 Hz, ces interruptions s’accumulent à un rythme que les architectures actuelles absorbent avec une charge CPU mesurable.
Des tests publiés par des communautés hardware comme Blur Busters ont mis en évidence qu’un polling rate à 8000 Hz peut pousser l’utilisation d’un seul cœur CPU à des niveaux inhabituels, parfois entre 5 et 15% selon la configuration, même quand la machine est idle hors du jeu. Sur un PC où chaque thread compte pour maintenir 240 images par seconde stables, c’est une taxe réelle. Mon erreur était de penser que le CPU « allait gérer » sans regarder les compteurs réels.
Le pic que j’ai vécu correspond exactement à ce scénario : CPU déjà chargé par le jeu, Discord en overlay, streaming actif en arrière-plan, et la souris qui bombardait le système de requêtes au-delà du raisonnable. Ce n’était pas un bug, c’était de la physique.
La latence perçue vs la latence mesurée : le gouffre du ressenti
Le problème central avec le 8000 Hz, c’est qu’il promet une réduction de latence qui se situe dans des plages temporelles que le système nerveux humain ne peut pas discriminer dans des conditions normales de jeu. La différence entre 1 ms et 0,125 ms de délai d’entrée souris représente 0,875 ms. Pour contextualiser : le temps de réaction moyen d’un joueur entraîné à un stimulus visuel tourne autour de 150 à 250 ms. On parle d’un gain théorique qui représente moins de 0,6% du temps de réaction total.
Les pros le savent. Une grande partie des joueurs qui ont atteint les sommets des leaderboards compétitifs ont construit leur aim sur du 500 Hz ou du 1000 Hz pendant des années, avec des configurations matérielles bien moins sophistiquées que ce qui existe aujourd’hui. L’amélioration vient de la constance des entrées, pas de la résolution temporelle microscopique. Un signal stable à 1000 Hz est objectivement préférable à un signal à 8000 Hz qui crée de la jitter (irrégularité des intervalles d’envoi) parce que le CPU est en retard sur les interruptions.
C’est précisément ce qui s’est passé dans mon cas. La courbe d’aim que je traçais avec mes replays était plus propre à 1000 Hz qu’à 8000 Hz, même si je ne voulais pas l’admettre. Les micro-saccades visibles dans les replays n’étaient pas un bug de la souris mais la signature d’un CPU qui peinait à traiter les interruptions de façon uniforme.
À qui le 8000 Hz profite réellement
Ce serait réducteur de dire que le 8000 Hz ne sert à rien. Sur une machine bien dimensionnée, avec un CPU récent aux cœurs puissants, sans charge parallèle agressive, les bénéfices existent pour une frange très précise de joueurs. Les FPS compétitifs à très haut niveau, avec des setups à 360 Hz ou plus, peuvent potentiellement tirer parti d’une précision d’entrée accrue, notamment pour la correction de trajectoire en temps réel pendant un flick.
Razer et Logitech, les deux marques qui ont popularisé le 8000 Hz avec leurs technologies respectives (HyperPolling pour Razer, LIGHTSPEED amélioré chez Logitech), sont les premières à préciser dans leur documentation que ces modes sont conçus pour des systèmes hautes performances. Ce n’est pas un disclaimer de façade : c’est une contrainte d’usage réelle. Le hardware suit, ou il ne suit pas.
Pour la majorité des joueurs avec un setup en dessous de 240 Hz de taux de rafraîchissement moniteur, rester à 1000 Hz est le choix le plus rationnel. La cohérence prime sur la résolution brute. Un polling rate élevé sans moniteur adapté revient à conduire une Formule 1 sur une route avec des dos d’âne tous les 50 mètres : la voiture peut en théorie aller plus vite, mais le contexte ne le permet pas.
Ce que j’ai changé, et pourquoi ça a fonctionné
Après l’incident, j’ai rétrogradé à 1000 Hz et ouvert le gestionnaire des tâches en parallèle du jeu pour la première fois depuis longtemps. La différence de charge CPU sur les cœurs concernés était immédiate et visible. Plus de pic inexpliqué, frametime plus régulier, courbe d’aim dans les replays objectivement plus lisse.
J’ai aussi revu la façon dont j’empilais les processus en arrière-plan pendant les sessions compétitives. Discord avec overlay GPU, logiciel de la souris en mode haute précision, stream OBS activé : chacun de ces éléments grignote une part du budget CPU qui pourrait aller au rendu du jeu et au traitement des entrées. La performance perçue n’est jamais la somme d’une seule variable.
Un détail que peu de guides mentionnent : certains pilotes de souris permettent de configurer des modes « polling adaptatif » qui ajustent dynamiquement le taux selon l’activité détectée, réduisant la charge quand la souris est immobile. C’est une approche bien plus intelligente que de pousser à 8000 Hz en permanence, et elle commence à apparaître dans les firmwares récents comme une alternative au tout-ou-rien du polling rate fixe.