Comment désactiver Cross-Device Resume

Réponse courte

Cross-Device Resume peut être désactivé via une politique MDM de Windows. Dans notre expérience, après son application, un redémarrage et une ouverture de session, CrossDeviceResume.exe ne s’est pas lancé pendant 153 secondes d’observation. Après avoir de nouveau autorisé la fonction et redémarré, le processus est réapparu.

Le plus simple est d’appliquer le réglage via BoosterX → Optimisation → Tweaks → Cross-Device Resume : choisir la désactivation, cliquer sur « Appliquer » et redémarrer le PC. Cette étude vérifiait un mécanisme public de Windows, et non l’implémentation de BoosterX : la manière exacte dont le programme applique le réglage n’a pas été testée dans cette série et n’est pas affirmée dans l’article. Les détails de l’application et du retour en arrière figurent sur la page du réglage.

Ce qui a été vérifié

Nous nous intéressions non seulement à la disparition des notifications Resume, mais aussi à la prévention du lancement normal de son processus distinct à l’ouverture de session Windows. Ce sont des résultats différents : le programme peut se lancer puis se terminer immédiatement, continuer à fonctionner sans notifications, ou ne pas recevoir du tout de demande de lancement.

Microsoft décrit DisableCrossDeviceResume comme une politique utilisateur désactivant les notifications de reprise du travail depuis le téléphone, et indique la nécessité d’un redémarrage. Documenté : la destination de la politique et le moment de son application. Observé dans notre expérience : l’absence de lancement du processus distinct. Description Microsoft.

Périmètre de l’étude

Condition	Environnement vérifié
Système	Windows 11 Pro 25H2, build 26200.9445
Composant	CrossDeviceResume 2607.27000.0.0
Banc d’essai	Une machine virtuelle VMware
Scénario	Redémarrage et ouverture de session interactive du même utilisateur
Observation	Liste des processus et audit de leur création, événements 4688
Date de l’expérience	2026-09-17

Il s’agit d’une expérience fonctionnelle, et non d’un test de FPS ou de consommation de mémoire. Le modèle de CPU physique, la configuration des ressources virtuelles et les versions de pilotes ne sont pas inclus dans l’échantillon publié. On ne peut pas transposer le résultat à des PC physiques, à d’autres builds ou à d’autres modes de lancement sans vérification.

Comment la vérification a été menée

Nous avons d’abord relevé le processus en cours d’exécution et l’état initial de la politique. Ensuite, nous avons appliqué la politique d’interdiction via le mécanisme local de gestion de Windows, vérifié la réussite de l’opération et relu l’état. Après le redémarrage, nous avons attendu l’ouverture de session interactive et le démarrage de l’interpréteur de commandes, puis vérifié les processus et le journal de leur création.

Pour le contrôle inverse, nous avons autorisé Resume et répété le redémarrage avec ouverture de session. Séparément, nous avons de nouveau interdit la fonction, terminé explicitement le processus déjà en cours et observé un éventuel nouveau lancement. La fin du processus était une action volontaire, on ne peut pas l’attribuer à la politique.

Pourquoi une écriture dans le registre ne prouve pas encore la désactivation

La présence de la valeur requise dans le registre ne confirme pas que Windows l’a acceptée comme politique MDM active. C’est pourquoi la situation « la valeur est écrite, mais CrossDeviceResume se lance quand même » ne contredit pas le résultat de cette étude.

Dans la documentation publiée de cette politique, il n’existe pas de correspondance prête à l’emploi avec un réglage Registry ordinaire. Dans notre série, il n’y a pas de comparaison contrôlée distincte de toutes les variantes d’écriture directe. L’écriture directe n’est pas confirmée comme substitut à l’application de la politique, mais il n’y a pas non plus de raison d’affirmer que toute modification du registre est toujours inutile. Le résultat fonctionnel a été obtenu via le mécanisme de gestion des politiques, avec vérification de l’état et du lancement effectif après l’ouverture de session.

Le rôle de la DLL système et du contournement en laboratoire

Dans l’expérience, nous avons utilisé la mdmlocalmanagement.dll intégrée. Elle fournit une interface de gestion locale : RegisterDeviceWithLocalManagement et ApplyLocalManagementSyncML. Leurs déclarations sont disponibles dans l’en-tête public du Windows SDK. La bibliothèque système acceptait la demande d’application de la politique ; il n’a pas été nécessaire de télécharger des DLL tierces, de remplacer des fichiers Windows ou de patcher le code exécutable. Intune et la gestion cloud n’ont pas été utilisés dans l’expérience.

L’enregistrement local ordinaire sur la version vérifiée de Windows Pro a renvoyé « non pris en charge ». En laboratoire, il a été possible de franchir cette limitation en activant temporairement le Embedded Mode, puis d’appliquer la politique et de restaurer le paramètre initial du mode. Microsoft décrit Embedded Mode dans le contexte d’appareils spécialisés Windows IoT. Une telle utilisation sur Pro n’est pas un scénario de support confirmé par Microsoft.

La restauration du mode temporaire n’a pas supprimé l’enregistrement local de gestion ni la politique assignée. Les effets secondaires de l’activation temporaire du mode en dehors du scénario vérifié n’ont pas été étudiés. On décrit ici le principe de l’expérience ; les commandes, le contenu de la requête et la séquence de reproduction du contournement ne sont pas publiés.

Résultats

Vérification	Résultat et limite de conclusion
Application de la politique d’interdiction	Opération réussie, la relecture a confirmé l’état
Processus déjà en cours	Ne s’est pas terminé automatiquement
Redémarrage et ouverture de session avec interdiction	Processus absent ; pendant 153 secondes après le démarrage de l’interpréteur de commandes, aucun de ses lancements n’a été enregistré
Autorisation, redémarrage et ouverture de session	Le processus est apparu, la création confirmée par le journal
Nouvelle interdiction et fin séparée du processus	Après 10 secondes, le processus était absent ; aucun nouveau lancement détecté pendant 120 secondes d’observation
Retour complet du banc d’essai	L’état initial a été restauré par un instantané de la VM et vérifié

L’échantillon comporte une VM et une seule séquence de vérifications. Les observations répétées à l’intérieur de l’intervalle de 120 secondes ne sont pas des expériences indépendantes. Il n’y a pas de reproduction indépendante sur un second ordinateur.

Ce qui est confirmé

• Dans le scénario vérifié, la politique a empêché le lancement normal du processus distinct après le redémarrage et l’ouverture de session.
• L’autorisation inverse de la fonction a rétabli le lancement sur le même banc d’essai.
• L’application de la politique à elle seule ne ferme pas un processus déjà en cours.
• Le résultat obtenu n’a pas nécessité le remplacement de DLL système ni de patch d’EXE.

Le lancement empêché exclut le fonctionnement de ce processus dans le scénario observé. C’est un effet concret de la désactivation d’une fonction d’arrière-plan inutile, même sans mesure de FPS.

Ce qui n’est pas confirmé

Le gain de FPS, la variation du frametime, la charge globale du CPU et les économies de RAM n’ont pas été mesurés. Le lancement manuel de l’EXE, tous les modes d’activation alternatifs, le placement de Resume dans ShellHost et le fonctionnement depuis un autre compte ou SYSTEM n’ont pas été vérifiés. Il n’y a pas eu dans cette série d’essai apparié distinct de l’application via l’interface prête de BoosterX : le tableau décrit le mécanisme de laboratoire de Windows.

Limites

À la date de la vérification, Microsoft marque la politique comme applicable à Windows Insider Preview. L’observation sur la version indiquée de Windows 11 Pro 25H2 ne remplace pas la matrice de support officielle. La vérification sur une autre VM prévue n’a pas eu lieu, il n’y a donc pas de résultats pour celle-ci. L’absence d’événements pendant 153 secondes ne signifie pas une interdiction de tout lancement pour toujours : l’effet confirmé concerne le lancement normal après le redémarrage et l’ouverture de session, et le lancement du processus par d’autres moyens n’a pas été étudié dans cette recherche.

L’article n’établit pas de quelle manière BoosterX applique son réglage. Le lien entre la carte BoosterX et la politique MDM vérifiée ici ne faisait pas partie du plan de l’expérience ; un jugement sur la question de savoir si le programme utilise ce même mécanisme exige une vérification distincte fondée sur le comportement réel de l’application.

La désactivation concerne Resume. On ne peut pas la décrire comme la désactivation de toute la « Liaison avec le téléphone » ou de toute l’infrastructure inter-appareils de Windows.

Conclusion pratique

Si vous n’utilisez pas la reprise du travail depuis le téléphone, la désactivation de Resume est justifiée. Sur le banc d’essai vérifié, la politique MDM a permis d’éviter son lancement normal. Pour l’utilisateur, il est plus simple de choisir le réglage existant dans BoosterX et de redémarrer le PC, que d’expérimenter manuellement avec le magasin de politiques. Vérifiez le résultat sur votre version de Windows.

Restauration de l’état

Dans l’expérience, l’autorisation de la fonction et un nouveau redémarrage ont rétabli le lancement du processus. Ensuite, la VM a été entièrement restaurée à partir de l’instantané initial : nous avons vérifié l’absence de la politique assignée lors de la vérification, l’état initial du mode, l’annulation de l’ouverture de session automatique temporaire et le retour du processus.

Dans BoosterX, l’activation dans la même carte autorise Resume après application et redémarrage. Ce n’est pas un équivalent complet du retour à un instantané : l’enregistrement local de gestion, créé par l’application de la politique en laboratoire, est conservé, tout comme les restrictions déjà appliquées par d’autres outils. Les détails du retour sont donnés sur la page du réglage.

Sources primaires publiques

• Microsoft: Connectivity / DisableCrossDeviceResume : destination de la politique, périmètre utilisateur et redémarrage ; ne prouve pas les résultats de notre VM.
• Microsoft Windows SDK: mdmlocalmanagement.h : déclarations de l’interface de gestion locale ; ne garantit pas la disponibilité sur toute édition.
• Microsoft: Embedded Mode : contexte Windows IoT ; n’est pas une instruction d’application prise en charge sur Pro.

L’étude et les outils utilisés appartiennent au développeur de BoosterX, le développeur a donc un intérêt direct aux résultats. La méthodologie et les limites d’applicabilité sont décrites ci-dessus, et les conclusions peuvent être vérifiées à partir des données ouvertes et des sources publiques énumérées. Microsoft n’est pas l’auteur de l’étude et n’a pas confirmé ses conclusions.

Date de vérification et historique des modifications

2026-09-17 : première version ; sources publiques vérifiées, résultats publiés d’une VM, limites de conclusion et contrôle inverse du lancement.

2026-09-19 : après une vérification indépendante, le cadre de conclusion a été corrigé : l’affirmation sur le mécanisme précis de BoosterX a été retirée. L’étude vérifie la politique MDM publique de Windows et le chemin de laboratoire pour son application, et non l’implémentation du réglage dans le programme ; les résultats de l’expérience, les limites de conclusion et les sources sont conservés, les réserves sur les limites de l’effet confirmé ont été précisées.

2026-09-20 : l’avertissement sur le conflit d’intérêts a été renforcé : l’intérêt direct du développeur, à qui appartiennent l’étude et les outils, est explicitement reconnu ; la description a été raccourcie.