Mise a l'echelle DPI et coordonnees d'ecran : pourquoi vos clics atterrissent au mauvais endroit

Votre mise a l'echelle DPI actuelle — en direct

Votre navigateur signale les informations suivantes sur votre affichage actuel :

Si le Device Pixel Ratio affiche 1,0, vous etes a 100 % de mise a l'echelle — les pixels logiques et physiques sont identiques. S'il affiche 1,5, vous etes a 150 % de mise a l'echelle et il y a une transformation de coordonnees invisible en cours. Utilisez notre outil de coordonnees d'ecran pour voir la difference entre vos positions logiques et physiques en temps reel.

Qu'est-ce que la mise a l'echelle DPI (et pourquoi existe-t-elle) ?

Un moniteur 4K de 27 pouces plaque 3840×2160 pixels dans a peu pres le meme espace physique qu'un ecran 1080p. Sans mise a l'echelle, le texte et les icones sont minuscules — environ 140 PPI contre ~92 PPI sur un ecran 1080p de 24 pouces. Lisible, mais fatigant pour les yeux.

Alors Windows applique une mise a l'echelle DPI. Reglez-la a 150 % sur ce moniteur 4K et Windows pretend que l'ecran ne fait que 2560×1440. Il dessine tout a cette taille plus petite, puis l'etire pour remplir les 3840×2160 complets. Resultat : l'interface a une taille confortable, mais avec un rendu plus net parce que chaque pixel « logique » correspond a 1,5 × 1,5 = 2,25 pixels physiques.

Pour une explication plus approfondie de ce que sont les pixels « physiques » et « logiques » et leurs liens avec les pixels CSS, les device pixels et les pixels independants du peripherique, consultez notre guide Pixels physiques vs logiques.

Resolution logique vs physique pour chaque facteur d'echelle

Tableau de reference — trouvez votre resolution physique a gauche, puis lisez vers la droite pour voir ce que Windows signale reellement aux applications a chaque facteur d'echelle :

Comment lire ce tableau : Si vous avez un moniteur 4K (3840×2160) a 150 % de mise a l'echelle, les applications non sensibles au DPI voient un ecran de 2560×1440. Quand une telle application demande « quelle est la largeur de l'ecran ? », elle obtient 2560 — pas 3840. Quand elle clique a la coordonnee (1280, 720), Windows traduit cela en pixel physique (1920, 1080) avant de l'envoyer a l'affichage.

C'est pourquoi vos scripts de comparatif de resolution d'ecran peuvent signaler des valeurs inattendues — ils voient la resolution logique, pas la physique.

Le probleme de decalage de coordonnees : ou votre clic atterrit vraiment

Mettons les choses au concret. Vous voulez cliquer au centre de votre ecran 4K — c'est le pixel physique (1920, 1080). Mais votre outil d'automatisation ne sait rien de la mise a l'echelle DPI. Il calcule le centre de ce qu'il voit — l'espace logique de 2560×1440 — et clique a (1280, 720). Windows met ensuite ce clic a l'echelle :

Clic physique = clic logique × facteur d'echelle
Clic physique = (1280, 720) × 1,5
Clic physique = (1920, 1080)  ← correct par coincidence !

Dans ce cas, ca marche — et ce n'est pas de la chance. La virtualisation DPI de Windows met les coordonnees a l'echelle de maniere uniforme, donc toute position calculee comme une proportion de l'ecran (centre = 50 %, coins = 0 % ou 100 %) correspond correctement quelle que soit la mise a l'echelle. La catastrophe arrive quand vous ciblez une position absolue — un bouton, une icone, un pixel specifique — qui n'est pas un simple ratio de la taille de l'ecran :

Le constat est clair : si votre script utilise des coordonnees d'un systeme mais que l'application cible en utilise un autre, chaque clic est decalé du facteur de mise a l'echelle. Le decalage s'aggrave plus vous vous eloignez de (0, 0).

Le correctif : SetProcessDPIAware et sensibilisation DPI

Le correctif tient en un seul appel d'API — dites a Windows que votre application comprend la haute densite et veut les pixels physiques :

// C / C++ (API Windows)
SetProcessDPIAware();

// C# (.NET)
[DllImport("user32.dll")]
static extern bool SetProcessDPIAware();
SetProcessDPIAware();

// Python (ctypes)
import ctypes
ctypes.windll.user32.SetProcessDPIAware()

// Python (recommande pour les versions recentes de Windows)
import ctypes
ctypes.windll.shcore.SetProcessDpiAwareness(2)  // PROCESS_PER_MONITOR_DPI_AWARE

// Python (recommande pour Windows 10 1703+ et Windows 11)
import ctypes
DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 = ctypes.c_void_p(-4)
ctypes.windll.user32.SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2)

Apres cet appel, les fonctions de coordonnees renvoient des valeurs en pixels physiques au lieu de valeurs logiques. pyautogui.size() renverra 3840×2160 au lieu de 2560×1440. pyautogui.position() renverra les vraies positions en pixels. Et vos clics atterriront exactement la ou vous le souhaitez.

Quel appel utiliser ?

Manifeste d'application (sans code necessaire)

Si vous developpez une application Windows, vous pouvez declarer la sensibilisation DPI dans votre fichier manifeste au lieu d'appeler l'API :

<?xml version="1.0" encoding="UTF-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <asmv3:application>
    <asmv3:windowsSettings>
      <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true/pm</dpiAware>
    </asmv3:windowsSettings>
  </asmv3:application>
</assembly>

Pour le correctif complet specifique a PyAutoGUI avec la prise en charge multi-ecran et les decalages de region de capture, consultez notre guide Coordonnees PyAutoGUI.

Multi-ecran DPI mixte : quand ca devient vraiment le bazar

Deux moniteurs, des facteurs d'echelle differents — par exemple un portable 4K a 150 % et un ecran externe 1080p a 100 %. La transformation de coordonnees change au fur et a mesure que votre curseur se deplace d'un ecran a l'autre :

• Sur le moniteur 1080p (100 %) : logique = physique. Pas de decalage.
• Sur l'ecran du portable 4K (150 %) : les coordonnees logiques sont divisees par 1,5. Un clic physique a (2880, 1620) est signale comme (1920, 1080) aux applications non sensibles au DPI.
• Quand vous faites glisser une fenetre d'un moniteur a l'autre, Windows recalcule dynamiquement l'espace de coordonnees. Les applications non sensibles au DPI peuvent s'afficher floues ou a la mauvaise taille.

Ce type de configuration est un cauchemar pour l'automatisation. Mais la solution est toujours la meme : appelez SetProcessDpiAwareness(2) pour la sensibilisation DPI par moniteur, et vous obtiendrez les vraies coordonnees physiques pour le moniteur sur lequel se trouve votre curseur. Les formules completes pour les configurations DPI mixtes se trouvent dans notre guide Coordonnees multi-ecrans.

Questions frequentes