- Une macro qui marche le lundi peut échouer le mardi. Rien n'a changé dans ton travail, seulement la position d'une fenêtre.
- Le problème ne vient pas de l'enregistreur. Il vient de ce qu'il enregistre : des positions, des délais, des touches. Pas la tâche elle-même.
- Cet article explique pourquoi une macro casse, comment le vérifier en dix minutes, et comment viser la fenêtre plutôt que l'endroit où elle se trouve.
Tu enregistres la routine qui ouvre ton tableau de suivi, exporte le rapport et le range dans le bon dossier. Ça marche du premier coup. Le lendemain, tu as agrandi le navigateur de quelques pixels, ou la fenêtre s’ouvre sur ton second écran. La macro clique dans le vide, tape le nom du fichier au mauvais endroit, et tu ne le remarques qu’à la fin, quand le rapport n’est nulle part.
La scène est banale. La cause, elle, est précise.
Un enregistreur retient des gestes, pas des intentions
Quand tu lances un enregistreur, il note trois choses : où se trouve le pointeur, quelles touches tu frappes, combien de temps tu attends entre deux actions. Il ne sait pas que le bouton « Exporter » est en bas à droite de la fenêtre. Il sait seulement qu’un clic a eu lieu à 1 240 pixels du bord gauche de l’écran.
Tant que la fenêtre reste à cet endroit, le geste produit l’effet voulu. Dès qu’elle bouge, le même geste tombe ailleurs.
La confusion vient de là. On croit automatiser une tâche (« exporter le rapport »), alors qu’on automatise un mouvement de souris (« cliquer à cet endroit »). Les deux restent confondus tant que l’écran ne change pas. Ils se séparent au premier imprévu.
Le vrai coût, ce n’est pas la réparation
On peut réenregistrer la macro, ajouter des pauses, rallonger les délais. Ça tient jusqu’à la prochaine variation. Le coût réel est ailleurs : la vérification.
Une macro qui échoue de temps en temps oblige à la surveiller à chaque usage. Tu regardes l’écran pendant qu’elle tourne, tu relis le résultat, tu doutes. Elle ne libère plus rien. Dans leur travail sur les automatismes, Raja Parasuraman et Victor Riley appellent cela le « disuse » : on garde l’outil, mais on refait le travail à la main, par défiance.
Un test de dix minutes avant de réparer
Avant de toucher à la macro, fais ce test. Enregistre une routine de trois ou quatre actions dans une fenêtre. Ferme-la, rouvre-la, et place-la ailleurs sur l’écran. Rejoue la macro.
Si elle réussit, le problème venait d’un délai ou d’une position ponctuelle. Tu peux la garder pour un usage occasionnel, avec une vérification à la fin. Si elle échoue, ne corrige pas une coordonnée : le principe ne tient pas, et chaque correction ajoute une nouvelle fragilité.
Viser la fenêtre, pas l’endroit
La règle de remplacement tient en une phrase : une commande doit s’appuyer sur ce qui identifie la cible et ne change pas quand on déplace la fenêtre. Le nom du processus qui l’a ouverte fait ça très bien. Une position à l’écran n’identifie rien.
AutoHotkey le permet en quelques lignes. La fonction WinExist cherche une fenêtre à partir de ses propriétés et renvoie un résultat si elle existe. WinActivate la ramène au premier plan, où qu’elle se trouve. Si elle n’existe pas, le script la lance.
#Requires AutoHotkey v2.0
; Ctrl + Alt + B : ramène le Bloc-notes au premier plan, ou l'ouvre
^!b:: {
if WinExist("ahk_exe notepad.exe")
WinActivate
else
Run "notepad.exe"
}Remplace notepad.exe par le processus de ton outil, et ^!b par le raccourci de ton choix. Le principe est le même pour un logiciel de rapport, un éditeur ou un outil comptable.
Ce que tu fais aujourd’hui
Installe AutoHotkey v2 si ce n’est pas fait : la leçon Automatisation explique l’installation et le fichier .ahk. Crée un fichier ramener.ahk, colle le script, puis double-clique pour le lancer.
Ouvre le Bloc-notes, glisse-le dans un coin de l’écran, puis appuie sur Ctrl + Alt + B : c’est la même fenêtre qui revient, à sa nouvelle place. Ferme-la, appuie encore : elle se rouvre. Si rien ne se passe, ouvre le Gestionnaire des tâches, onglet Détails, et vérifie le nom exact du processus.
Ce script ne couvre pas tout. Dans un navigateur, le titre d’une page change avec l’onglet, donc une règle qui vise le titre devient fragile. Pour le web, regarde plutôt du côté d’Automa, qui travaille sur les pages et non sur les pixels.
Ce qu’il faut retenir
Une macro enregistrée est un bon point de départ, pas une base de travail. Si elle casse au premier déplacement de fenêtre, réparer une coordonnée ne règle rien : il faut viser ce qui identifie la cible. Une règle écrite une fois coûte moins cher qu’une macro qu’il faut surveiller.
Ce que ça change pour toi : prends une macro que tu utilises et fais le test de dix minutes. Si elle échoue, remplace un seul de ses gestes par une commande qui vise la fenêtre. Pour aller plus loin, la leçon Automatisation relie ce geste aux snippets et aux lanceurs, et le guide gratuit des 10 réglages Windows pose la base avant d’automatiser.
Sources
Dernière vérification : 1er novembre 2026.
Voir les 3 sources de cet article
- AutoHotkey, documentation v2 : WinExist
- AutoHotkey, documentation v2 : WinActivate
- Raja Parasuraman et Victor Riley (1997), Humans and Automation: Use, Misuse, Disuse, Abuse, Human Factors