Désactiver le Wi‑Fi par GPO quand l'Ethernet est branché

Désactiver le Wi‑Fi dès qu’un câble réseau est branché paraît être une règle simple. En environnement Windows, le sujet mérite pourtant plus qu’un script copié à la hâte : il touche à la priorité réseau, à la stabilité des postes nomades, à la sécurité des VLAN et à l’expérience utilisateur quand un portable passe du bureau à une salle de réunion.

La bonne approche consiste à utiliser d’abord les mécanismes prévus par Windows, notamment les paramètres de Windows Connection Manager exposés par stratégie. Une GPO peut cadrer le comportement, mais elle doit être testée par modèle de poste, version Windows, dock USB‑C, carte Wi‑Fi et profil utilisateur. Sinon, on remplace un irritant par un incident réseau intermittent, difficile à reproduire parce qu’il dépendra du lieu, du câble, du pilote et parfois de la sortie de veille.

Ce que la GPO doit vraiment résoudre

Dans beaucoup d’entreprises, le problème n’est pas seulement esthétique. Un poste branché en Ethernet mais encore connecté au Wi‑Fi peut prendre un chemin réseau inattendu, conserver une adresse sur le mauvais segment, maintenir une session VPN inutile ou exposer une surface radio qui n’a plus de raison d’être au bureau. La question devient alors : comment forcer le chemin réseau attendu sans bloquer les usages mobiles ?

La réponse dépend du comportement recherché. Si l’objectif est de privilégier l’Ethernet et d’éviter plusieurs connexions simultanées, les stratégies Windows Connection Manager sont le premier endroit à regarder. Si l’objectif est de couper physiquement l’interface sans condition, on entre dans une logique plus intrusive, souvent moins robuste.

Cette nuance évite beaucoup de mauvaises configurations, notamment les règles trop dures qui coupent la mobilité sans améliorer réellement la sécurité.

Une GPO ne devrait pas être pensée comme un interrupteur global. Elle doit traduire une règle opérationnelle : au bureau, le poste utilise le réseau filaire maîtrisé; en mobilité, il retrouve automatiquement le Wi‑Fi autorisé; en cas d’incident, le support peut diagnostiquer rapidement l’état de chaque interface. Cette formulation force l’équipe à décrire le comportement attendu avant de toucher aux paramètres.

Sans cette phrase de cadrage, la GPO devient vite une collection de réglages difficiles à défendre lors du premier incident. Elle doit rester lisible hors console.

Le réglage Windows à connaître avant d’écrire un script

Windows dispose d’un gestionnaire de connexions qui arbitre les connexions disponibles. Les paramètres liés à la minimisation des connexions simultanées permettent de limiter les cas où un poste reste connecté à plusieurs réseaux au même moment. Sur un domaine Active Directory, ces paramètres peuvent être poussés par stratégie de groupe selon les modèles d’administration présents, avec un avantage évident : la règle reste dans le cadre supporté par l’éditeur.

Dans une console GPO, le chemin le plus souvent concerné se trouve côté configuration ordinateur, dans les modèles d’administration réseau liés à Windows Connection Manager. Le libellé exact peut varier selon la version des fichiers ADMX et la langue de la console, mais l’idée reste la même : contrôler les connexions réseau simultanées et favoriser une connexion plus appropriée.

Ce n’est pas une garantie magique sur tous les matériels. Certains pilotes Wi‑Fi, docks, cartes réseau virtuelles, clients VPN et outils de sécurité peuvent modifier la perception du réseau actif. C’est précisément pour cette raison qu’un déploiement sans groupe pilote est une mauvaise pratique.

Le bon réflexe consiste donc à commencer par la stratégie native, puis à vérifier les cas limites. Un script PowerShell ou une tâche planifiée ne devrait intervenir que si le comportement natif ne couvre pas une contrainte réelle, documentée et reproductible.

En pratique, la règle la plus maintenable est souvent celle que le support peut expliquer sans relire un script. C’est ce niveau de simplicité qui évite les exceptions permanentes.

Le tableau montre un point clé : désactiver, prioriser et interdire ne sont pas la même décision technique. Les mélanger dans une seule règle rend le support moins efficace et le rollback plus risqué pour les utilisateurs nomades.

Construire une GPO propre et réversible

Commencez par créer une GPO dédiée, nommée clairement, par exemple “Postes portables – gestion Wi‑Fi Ethernet”. Évitez de glisser ce réglage dans une stratégie générale déjà chargée. Quand un incident apparaît, une GPO monolithique rend le diagnostic beaucoup plus lent, surtout si plusieurs paramètres réseau ont été modifiés en même temps.

Lie ensuite la GPO à une unité d’organisation pilote ou appliquez un filtrage de sécurité à un groupe restreint de machines. Dix postes représentatifs valent mieux qu’un seul ordinateur de test parfait. Il faut inclure au moins un portable récent, un portable plus ancien, un poste avec dock, un utilisateur VPN et un profil qui change souvent de réseau.

Ce ciblage protège le parc principal pendant que l’équipe mesure les effets réels sur des postes représentatifs. On mesure avant d’étendre.

La règle doit aussi être documentée dans la description de la GPO. Notez l’objectif, la date de création, l’auteur, le groupe pilote, le comportement attendu et le critère de rollback. Cette description courte devient précieuse trois mois plus tard, quand quelqu’un demande pourquoi le Wi‑Fi disparaît au bureau. Elle protège aussi contre les modifications silencieuses, car chaque changement de périmètre peut être rattaché à une décision d’exploitation.

Après application, vérifiez le résultat côté client avec les outils classiques : résultat de stratégie, état des interfaces, journal d’événements si nécessaire et tests de bascule. Le poste doit utiliser Ethernet quand le câble est branché, puis retrouver le Wi‑Fi autorisé quand il revient en mobilité.

Ce contrôle doit être fait sur un poste standard, pas uniquement sur la machine d’un administrateur local déjà permissive. Sinon le résultat est biaisé.

Le poste témoin doit ressembler au parc réel, avec ses pilotes, ses contraintes et ses habitudes de connexion.

• Créer une GPO séparée, avec un nom lisible et une description exploitable.
• Cibler d’abord un groupe pilote de machines, pas tous les ordinateurs du domaine.
• Tester branchement, débranchement, sortie de veille, changement de dock et VPN.
• Documenter le comportement attendu côté utilisateur et côté support.
• Prévoir un groupe d’exclusion temporaire pour les postes incompatibles.

Pourquoi le script PowerShell doit rester une exception

Un script PowerShell peut surveiller l’état d’une interface Ethernet et désactiver l’adaptateur Wi‑Fi lorsqu’un câble est détecté. Techniquement, c’est faisable. Opérationnellement, c’est plus fragile qu’il n’y paraît. Il faut gérer les noms d’interfaces, les cartes virtuelles, les droits d’exécution, les délais de détection, les sorties de veille et les scénarios où l’utilisateur débranche son câble pendant une réunion.

Le piège le plus fréquent consiste à tester le script sur un seul ordinateur, puis à l’étendre à tout un parc. Sur dix modèles différents, les interfaces peuvent s’appeler autrement, remonter plus lentement ou être masquées par un outil constructeur. Le script coupe alors la mauvaise carte réseau, ou ne réactive pas le Wi‑Fi au moment utile.

Il existe pourtant des cas légitimes, mais ils doivent rester minoritaires et documentés comme des exceptions de sécurité ou d’exploitation.

Un environnement réglementé peut vouloir couper strictement la radio dans certaines zones. Un site industriel peut interdire le Wi‑Fi sur des postes de supervision. Une flotte de terminaux partagés peut avoir besoin d’une règle plus dure que la simple priorité de métrique. Dans ces contextes, le script doit être traité comme un composant de production, avec version, journalisation, propriétaire technique, tests de non-régression et rollback. Sans cette discipline, la dette d’automatisation finit par coûter plus cher que le problème initial.

Si vous choisissez cette voie, évitez le script opaque lancé au démarrage sans trace. Préférez une tâche planifiée claire, une détection robuste de l’état Ethernet, des logs consultables par le support et un mécanisme de réactivation. Le minimum est de savoir pourquoi une interface a été coupée, quand, par quel script et avec quelle condition.

Un script réseau sans logs devient presque impossible à défendre en production quand les tickets arrivent plusieurs semaines plus tard. Les logs sont l’assurance minimale.

Le protocole de test côté poste client

Une GPO réseau n’est validée que sur un poste réel. Commencez câble débranché : le Wi‑Fi doit se connecter au réseau autorisé, obtenir une adresse, accéder aux ressources attendues et conserver le comportement VPN prévu. Branchez ensuite l’Ethernet. Le poste doit basculer vers le réseau filaire sans coupure excessive, sans double chemin problématique et sans conserver une route prioritaire sur le Wi‑Fi.

Le test doit ensuite faire le chemin inverse, car c’est souvent la mobilité retrouvée qui révèle les erreurs de conception.

Débranchez le câble, sortez le poste de veille, changez de salle, reconnectez un dock, puis vérifiez que le Wi‑Fi revient sans intervention administrateur. C’est souvent là que les politiques trop agressives échouent. Elles fonctionnent dans le sens bureau, mais cassent le retour en mobilité, exactement au moment où l’utilisateur n’a pas de câble disponible pour contourner la panne.

Contrôlez également les cas où l’utilisateur n’a pas les droits administrateur. Un réglage qui exige une élévation pour récupérer le Wi‑Fi sera vécu comme une panne. Sur un parc géré, la politique doit fonctionner avec le niveau de droits standard des utilisateurs finaux, sans appel systématique au support et sans contournement local. C’est une condition de déploiement, pas un détail de confort.

Enfin, documentez les observations. Version Windows, modèle de carte réseau, dock, pilote, client VPN, profil Wi‑Fi, temps de bascule et anomalies doivent être notés. Cette fiche évite de redécouvrir le problème lorsque le parc recevra une mise à jour pilote ou un nouveau modèle de portable. Pour une équipe support, elle devient la preuve terrain qui justifie l’extension ou le report du déploiement.

La preuve terrain compte plus qu’une option cochée dans la console, surtout avant de toucher tout le domaine. Elle tranche mieux qu’une impression.

Les erreurs qui créent des tickets support

La première erreur consiste à confondre sécurité et brutalité. Couper le Wi‑Fi peut sembler plus sûr, mais une coupure mal gérée pousse les utilisateurs à chercher des contournements : partage de connexion, réseau invité, redémarrage forcé ou demande urgente au support. Une politique réseau doit réduire le risque sans créer des usages parallèles.

Une règle trop dure peut donc produire l’inverse de l’objectif initial : moins de maîtrise, plus d’improvisation côté utilisateurs. Le support le verra vite.

La deuxième erreur est d’oublier les cartes virtuelles. VPN, hyperviseurs, clients de sécurité, tunnels et adaptateurs Bluetooth peuvent apparaître dans la pile réseau. Un script trop naïf qui cherche “Ethernet connecté” ou “Wi‑Fi présent” peut mal interpréter cet environnement. La GPO native limite ce risque, mais elle ne dispense pas d’un test complet.

Les cartes virtuelles sont souvent invisibles pour l’utilisateur, mais pas pour la logique réseau ni pour vos scripts. Elles doivent être nommées dans le test.

La troisième erreur touche au timing. Un dock branché après l’ouverture de session, un câble détecté tardivement ou une sortie de veille peuvent produire un état transitoire. Si la règle réagit trop vite, elle coupe l’interface avant que Windows ait stabilisé le réseau. Si elle réagit trop lentement, l’utilisateur continue à passer par le mauvais chemin.

Un bon déploiement assume ces détails. Il ne cherche pas seulement le “ça marche chez moi”, mais le comportement répétable sur plusieurs modèles et plusieurs journées de travail.

Déployer progressivement sans casser la mobilité

Une fois le groupe pilote validé, élargissez par vagues. Commencez par les postes les plus prévisibles : machines de bureau mobiles mais utilisées majoritairement sur site, docks standardisés, versions Windows homogènes. Gardez les profils itinérants, commerciaux, techniciens terrain et utilisateurs VPN complexes pour une phase ultérieure.

Cette progression évite de mélanger panne de stratégie et diversité matérielle dans le même lot de tickets. Le tri reste possible.

Chaque vague doit avoir une fenêtre de retour. Si les tickets augmentent, si les postes perdent le Wi‑Fi hors site ou si le VPN change de comportement, suspendez la liaison GPO plutôt que modifier cinq paramètres à chaud. La discipline de rollback est le meilleur filet de sécurité d’une stratégie réseau.

Prévenez aussi les utilisateurs concernés. Une phrase suffit : “au bureau, le poste privilégiera le câble réseau; hors bureau, le Wi‑Fi restera disponible”. Cette communication réduit les faux incidents. Elle aide aussi le support à distinguer un comportement attendu d’une vraie panne, surtout les premiers jours où chacun observe différemment l’icône réseau. Un changement silencieux crée souvent plus de tickets qu’un changement correctement annoncé.

Le déploiement final doit rester observable. Gardez une trace de la GPO, des groupes ciblés, des exceptions et des modèles validés. Quand un nouveau matériel arrive, il doit passer par le même contrôle au lieu d’être supposé compatible.

Cette rigueur évite qu’une règle utile devienne un piège après le renouvellement du parc ou des stations d’accueil. Elle donne aussi un point de départ clair au prochain administrateur qui reprendra la GPO après vous.

Ce qu’il faut retenir avant d’activer la règle

Désactiver le Wi‑Fi quand l’Ethernet est branché peut être une bonne règle, mais seulement si elle est formulée proprement. Dans la majorité des parcs Windows, commencez par les paramètres Windows Connection Manager et une GPO ciblée. Le script maison ne doit venir qu’après un écart concret, testé et documenté.

Le vrai critère de réussite n’est pas que le Wi‑Fi disparaisse dans la barre système. C’est que le poste utilise le bon réseau au bon moment, retrouve la mobilité sans intervention et laisse au support assez d’indices pour comprendre ce qui s’est passé.

Si ce critère n’est pas rempli, la règle doit rester en pilote, même si elle semble techniquement appliquée. Le parc n’est pas prêt.

Une stratégie réseau réussie se remarque peu. Elle évite les doubles connexions, stabilise les flux et laisse l’utilisateur travailler sans se demander quel adaptateur Windows a choisi. Pour l’administrateur, le gain est plus concret : moins de routes ambiguës, moins de tickets “ça marche parfois”, et un parc réseau plus lisible.

Pour approfondir ce point, consultez Désactiver Microsoft Defender sans exposer votre PC, qui traite plus précisément de désactiver microsoft defender sans exposer votre pc.