Statut Teams : pourquoi les outils anti-veille échouent

L'inactivité liée à la gestion de l'énergie

Ici, on parle de l'alimentation : quand l'écran s'assombrit, quand l'économiseur d'écran démarre, et quand la machine passe en veille. Certaines applications peuvent demander au système de repousser ces échéances. Sur macOS, cela passe notamment par des assertions de puissance, comme celles utilisées par caffeinate. Sur Windows, une application peut appeler SetThreadExecutionState pour garder l'écran et/ou le système actif.

Ce genre de mécanisme est utile pour des téléchargements longs, des présentations ou des traitements qui ne doivent pas être interrompus. En clair : ce n'est pas fait pour « simuler une présence », mais pour empêcher la mise en veille.

Le compteur d'inactivité des entrées

L'autre mécanisme, c'est le temps depuis la dernière entrée clavier, souris ou pavé tactile. Sur Windows, on peut regarder ce délai via GetLastInputInfo. Sur macOS, on peut aussi obtenir un « temps écoulé depuis le dernier événement d'entrée » via les API Core Graphics.

D'après les mesures rapportées pour le cas étudié, les outils qui maintiennent l'ordinateur éveillé ne remettent pas forcément ce compteur à zéro. Sur Windows 11, SetThreadExecutionState empêchait certaines formes de mise en veille, mais le délai depuis la dernière entrée continuait d'augmenter. Sur macOS, une déclaration d'activité pouvait retarder l'extinction de l'écran sans changer le compteur d'entrée que d'autres logiciels consultent.

Teams finit alors par conclure qu'il n'y a plus d'activité, puis met à jour le statut après un délai (souvent autour de cinq minutes), selon la configuration, la version de Teams et d'autres signaux de présence. Il vaut mieux ne pas transformer ce chiffre en règle universelle : les réglages côté entreprise peuvent changer la donne.

Le point important : garder l'ordinateur éveillé ne veut pas dire enregistrer une nouvelle entrée clavier ou souris. Si vous voulez comprendre pourquoi Teams passe en jaune, regardez d'abord quel mécanisme votre outil modifie réellement, plutôt que de vous fier au nom du produit.

Les utilitaires qui empêchent la veille

Des outils comme caffeinate, Amphetamine ou PowerToys Awake servent à garder l'écran et/ou l'ordinateur actif. Ils répondent à un problème d'énergie. Si Teams s'appuie sur l'absence d'événements clavier ou souris, ces outils ne suffisent pas forcément à maintenir le statut actif.

Ils restent pertinents pour une présentation ou un calcul long, quand votre objectif est simplement d'éviter la veille. En revanche, les utiliser pour « jouer sur la présence » sans tester le résultat, c'est risqué : vous pourriez corriger l'un des symptômes tout en laissant l'autre inchangé.

Les petits mouvements de souris

Déplacer le curseur (même légèrement) peut générer une activité reconnue par le système et donc remettre le compteur à zéro. Sauf que le curseur est un élément visible et partagé : un déplacement minime peut provoquer un survol, afficher une infobulle, ouvrir un menu contextuel ou déplacer le pointeur hors d'un endroit où vous aviez l'intention de travailler.

Et ça peut aussi vous gêner au moment où vous revenez : sur un poste utilisé pour de la précision (support à distance, tests d'interface, outils sensibles), ces micro-interactions peuvent devenir une vraie source d'erreur.

Les frappes de clavier simulées

Simuler une touche (par exemple une touche « muette » comme F15) ou une touche modificatrice peut aussi réinitialiser le compteur. Mais la touche peut être interprétée par l'application au premier plan. Selon le contexte, elle peut déclencher une action, modifier la saisie, ou transformer le prochain clic.

Si une touche comme Maj est perçue comme maintenue, vous risquez d'obtenir un comportement inattendu au clic. Autrement dit : ce n'est pas « sans risque » par défaut. Une solution correcte, c'est une solution testée dans les applications que vous utilisez réellement - pas seulement sur un bureau vide.

Comparer les options avant de choisir

• Maintien de l'alimentation : évite la veille, mais ne réinitialise pas forcément le compteur d'entrée.
• Déplacement de souris : génère une activité, mais bouge le curseur et peut déclencher des interactions.
• Frappe clavier : génère une activité, mais peut produire un effet visible dans l'application active.
• Entrée « neutre » : peut limiter les effets applicatifs, mais dépend des API, des permissions et du comportement du système.

Aucune option n'est universelle. Pour un usage professionnel, testez l'effet réel, vérifiez les permissions, et mesurez si votre entreprise l'accepte. Sur un poste administré, la politique informatique prime sur le confort individuel.

Sur macOS : un événement de changement de modificateurs inchangé

macOS propose des événements flagsChanged, associés aux changements d'état de touches comme Maj, Contrôle, Option, Commande ou Verr. Maj. L'événement décrit l'état courant des modificateurs.

Sur macOS, une expérimentation consiste à publier ce type d'événement en gardant exactement les mêmes indicateurs que ceux déjà actifs : aucune touche n'est réellement enfoncée ni relâchée, et aucun caractère n'est saisi. Dans les mesures rapportées par le développeur de KeepMeOn, cet événement est néanmoins traité comme une entrée et remet le compteur d'inactivité à zéro.

C'est la différence clé avec une assertion de puissance : ici, le signal cible le compteur d'entrée ; l'autre mécanisme cible la veille de l'écran. Les deux existent, mais ils ne jouent pas au même endroit.

Cette technique demande l'autorisation d'accessibilité de macOS pour publier des événements. Selon le comportement du système, il peut aussi falloir relancer l'application après attribution de la permission. Et surtout : il ne faut pas émettre le signal pendant qu'une touche modificatrice est maintenue. Intervenir au milieu d'un glisser-déposer avec Commande ou Maj serait une mauvaise idée.

Enfin, l'événement peut être marqué avec une donnée d'identification. Cela ne le rend pas « invisible » : ça permet surtout à un outil de surveillance compatible de distinguer ce signal des entrées ordinaires. Cette transparence est généralement préférable à une méthode conçue pour dissimuler le fonctionnement.

Sous Windows : une touche virtuelle non attribuée

Pour Windows, l'approche décrite repose sur l'envoi d'un code de touche virtuelle de la plage 0x97 à 0x9F, présenté comme non attribué, en ne transmettant que son événement de relâchement via SendInput. Comme aucune touche correspondante n'est considérée comme « pressée », l'application active n'a pas de caractère ou d'action à traiter. Dans les essais rapportés, le compteur de GetLastInputInfo revient proche de zéro, sans déplacement du curseur.

À garder en tête : c'est une technique empirique, pas une garantie générale que l'API se comportera pareil dans toutes les configurations futures. Un test de non-régression sur votre système Windows reste une bonne idée : il vérifie que le signal remet bien le compteur à zéro et n'entraîne pas de déplacement du pointeur.

Autre limite : Windows peut bloquer l'injection quand une application au premier plan tourne avec des privilèges élevés, tandis que l'outil émetteur fonctionne avec des droits ordinaires. Les protections d'intégrité de l'interface utilisateur expliquent cette différence. Chercher à « contourner » en exécutant toujours l'outil en administrateur n'est pas une réponse satisfaisante : ça augmente des privilèges sans bénéfice prouvé.

Pourquoi un signal « neutre » ne règle pas tout

Un événement discret n'est pas automatiquement approprié partout. Les systèmes évoluent, certaines API sont soumises à des autorisations, et des logiciels de sécurité peuvent analyser des entrées synthétiques.

Trois questions restent à vérifier :

1. Le compteur est-il bien réinitialisé ?
2. L'application active reste-t-elle réellement intacte ?
3. Votre organisation autorise-t-elle ce type d'outil ?

Une vérification sérieuse regarde ces trois points. C'est plus fiable que de conclure au succès uniquement parce que l'indicateur Teams est resté vert pendant une courte période.

Définir une fenêtre d'usage limitée

Dans l'implémentation présentée, l'outil ne démarre qu'après deux minutes sans entrée réelle, puis il vérifie toutes les 60 secondes. Avec ces réglages, le compteur peut monter à environ trois minutes dans les essais décrits, sous le seuil d'environ cinq minutes observé avant le passage à l'état absent. Ces chiffres viennent d'expérimentations précises : ils ne garantissent pas le même résultat sur chaque poste.

Le principe compte plus que la valeur exacte : n'émettre aucun signal pendant que vous travaillez, éviter les signaux trop fréquents et fixer un délai maximal observé. Réduire l'intervalle limite le risque de changement de statut, mais augmente le nombre d'événements artificiels. L'augmenter diminue l'activité de l'outil, mais peut ne pas répondre à votre besoin. Dans tous les cas, l'arbitrage mérite d'être explicité, pas choisi au hasard.

Suspendre le mécanisme dans les situations évidentes

Un outil responsable devrait aussi s'arrêter quand c'est évident qu'il n'y a personne : écran verrouillé, ordinateur ou écran en veille, et idéalement hors des horaires de travail ou pendant une pause définie. Ce sont des garde-fous qui réduisent le risque de signaler une présence alors que la personne est partie pour un moment.

La règle la plus simple, et souvent la plus robuste : si vous quittez votre poste longtemps, verrouillez l'écran. L'outil doit alors s'interrompre, et Teams reflétera l'absence. Un mécanisme prévu pour une courte pause café ne devrait pas servir à « garder vert » après une réunion manquée ou une demi-journée hors du bureau.

Vérifier la politique de votre organisation

Sur un ordinateur professionnel, installer un outil qui publie des événements d'entrée peut être soumis à des règles internes. Vérifiez les consignes de votre service informatique, surtout si le poste est administré.

Le fait qu'un outil soit libre, gratuit, ou sans télémétrie ne veut pas dire qu'il est automatiquement autorisé. L'exemple de KeepMeOn (application annoncée libre pour macOS et Windows) met d'ailleurs en avant une exécution visible, une entrée dans les éléments de démarrage et, côté Mac, une autorisation d'accessibilité. Ce sont des choix qui rendent le fonctionnement plus inspectable. Ça ne remplace ni une validation de sécurité ni un accord clair avec l'employeur.

Une méthode de décision en quatre étapes

1. Identifiez le besoin. Pour éviter la veille pendant une présentation, utilisez un outil de gestion de l'énergie. Pour comprendre un changement de présence, examinez le compteur d'entrée et les réglages Teams.
2. Testez ce qui est mesurable. Observez le délai d'inactivité avant et après le signal, sans vous arrêter à la couleur de l'indicateur.
3. Contrôlez les effets secondaires. Vérifiez que le pointeur ne bouge pas, qu'aucune frappe ne s'insère, et que les applications ouvertes ne réagissent pas.
4. Fixez une limite d'usage. Arrêt sur écran verrouillé, règles claires pour les horaires, et respect de la politique informatique.

Cette approche évite le piège des « ça marche chez moi » sans comprendre ce qui est modifié. Elle aide aussi à séparer le côté technique (compteur d'entrée) du débat plus large sur la façon dont la disponibilité doit être affichée.