GPO Wi‑Fi et Ethernet : forcer le bon réseau sur les portables

Désactiver automatiquement le Wi‑Fi quand un câble Ethernet est branché évite un problème très concret en PME : deux interfaces actives, deux chemins réseau possibles, des résolutions DNS incohérentes et des tickets difficiles à diagnostiquer. La bonne solution n’est pas de demander aux utilisateurs de couper le Wi‑Fi à la main, mais de pousser une règle machine stable par GPO.

Sur un parc Windows relié à Active Directory, le réglage à viser se trouve côté ordinateur, dans les paramètres du Gestionnaire de connexions Windows. Il faut activer la stratégie qui minimise les connexions simultanées, puis choisir le comportement qui empêche la connexion Wi‑Fi lorsqu’une connexion Ethernet au domaine ou à Internet est disponible.

Le sujet paraît mineur. Il ne l’est pas quand le support doit expliquer pourquoi un poste docké répond parfois depuis la mauvaise interface.

Pourquoi couper le Wi‑Fi quand Ethernet est branché ?

Quand un portable reste connecté au Wi‑Fi tout en utilisant son dock Ethernet, Windows peut conserver deux interfaces valides. Selon la métrique, la configuration DNS, le profil réseau et les routes, l’utilisateur peut ne rien voir, mais le support récupère des symptômes intermittents : nom de machine résolu sur la mauvaise adresse, flux applicatif instable, lenteur inexpliquée ou poste vu deux fois dans certains outils.

Le problème est encore plus visible avec les stations d’accueil USB‑C. L’utilisateur arrive au bureau, pose son portable, branche le dock et pense naturellement être passé sur le réseau filaire. Si le Wi‑Fi reste actif, le poste peut garder une partie de son historique réseau sans que le collaborateur ait conscience de ce double état, puis ouvrir une application métier, un VPN ou un partage de fichiers dans un contexte réseau différent de celui attendu par le support.

La règle doit donc être automatique, prévisible et réversible par l’équipe IT, pas dépendante d’une discipline utilisateur.

Où configurer la règle dans une GPO Windows ?

La configuration se fait dans une GPO liée aux ordinateurs, pas aux utilisateurs. C’est logique : le comportement attendu dépend de l’interface réseau de la machine, pas du profil de la personne connectée. Travaillez donc dans une OU contenant les portables ou les postes dockés, puis éditez la GPO depuis la console de gestion des stratégies de groupe.

Le chemin opérationnel est le suivant : Configuration ordinateur, puis Modèles d’administration, Réseau, Gestionnaire de connexions Windows. Le paramètre à activer concerne la minimisation des connexions simultanées. Selon les modèles ADMX disponibles et la version Windows ciblée, le libellé exact peut varier légèrement ; l’idée reste de limiter les connexions réseau parallèles au domaine ou à Internet.

Ne modifiez pas directement tout le domaine. Une OU pilote suffit.

• Créer une GPO dédiée, avec un nom explicite comme C_Windows_Network_Disable_WiFi_When_Ethernet.
• Lier la GPO à une OU de test contenant quelques portables représentatifs.
• Activer le paramètre WCM qui minimise les connexions simultanées.
• Choisir le niveau qui empêche le Wi‑Fi quand une connexion Ethernet au domaine ou à Internet est disponible.
• Documenter l’exception pour les profils nomades, salles de test ou matériels particuliers.

Les prérequis à vérifier avant de toucher la GPO

Avant de créer la règle, vérifiez d’abord le contexte technique. Les postes doivent être joints au domaine, recevoir correctement les stratégies ordinateur et utiliser des modèles d’administration à jour. Si vos portables sont gérés uniquement par MDM, si une partie du parc est hors domaine ou si plusieurs versions de Windows cohabitent, le périmètre de déploiement doit être clarifié avant tout changement.

Contrôlez aussi le comportement matériel. Certains docks USB‑C, adaptateurs Ethernet ou pilotes réseau ne réagissent pas exactement de la même manière. Un poste peut considérer l’interface filaire comme disponible seulement après quelques secondes, ou conserver un profil Wi‑Fi le temps que le dock se réveille. Ce délai n’est pas forcément une erreur de GPO ; il peut venir du matériel, du pilote, du firmware du dock ou d’un profil d’alimentation trop agressif.

C’est pourquoi un pilote doit mélanger plusieurs cas : portable récent, modèle plus ancien, dock standard, câble direct, utilisateur nomade et poste de bureau hybride. Vous testez une politique réseau, mais aussi la réalité du parc.

Tester sans casser le quotidien des utilisateurs

Le test doit reproduire le geste réel : un portable connecté au Wi‑Fi, puis branché sur un dock ou un câble Ethernet. Après application de la GPO, l’interface Wi‑Fi doit se désactiver ou se déconnecter automatiquement quand l’interface filaire devient disponible. Si le poste conserve deux connexions actives, la stratégie n’est pas appliquée, la version ADMX ne correspond pas, ou le ciblage ne touche pas la bonne machine.

Commencez par gpupdate /force, puis vérifiez l’application avec gpresult. Observez ensuite les interfaces depuis les paramètres réseau ou PowerShell. Le contrôle doit être simple : câble branché, Ethernet actif, Wi‑Fi non utilisé. Si vous devez interpréter dix signaux contradictoires, le test pilote n’est pas encore assez propre.

Un bon test inclut aussi le retour arrière. Avant le déploiement large, notez comment désactiver la GPO, retirer le lien à l’OU ou appliquer un filtrage de sécurité plus restrictif.

Le test doit durer assez longtemps pour couvrir les gestes ordinaires : arrivée le matin, sortie de veille, changement de salle, réunion en Wi‑Fi puis retour au dock, redémarrage et mise à jour Windows. Une GPO qui fonctionne uniquement après un gpupdate manuel ne suffit pas. Le comportement doit rester stable quand l’utilisateur travaille normalement, sans solliciter le support de proximité à chaque reconnexion, sinon vous aurez remplacé une instabilité réseau par une instabilité d’usage.

Gardez les premiers résultats dans une note courte : machine, modèle de dock, version Windows, OU, heure d’application et comportement observé. Cette documentation accélère les corrections si un site distant ou une série de portables réagit différemment.

Les erreurs qui rendent la GPO inefficace

La première erreur consiste à lier la stratégie au mauvais endroit. Si l’OU contient des utilisateurs mais pas les ordinateurs, le réglage machine ne touchera pas les postes attendus. La deuxième est de tester seulement sur un poste déjà conforme, sans vérifier un cas réel de dock, de Wi‑Fi enregistré et de câble Ethernet actif.

La troisième erreur est plus discrète : oublier les exceptions. Certains techniciens, formateurs ou utilisateurs terrain peuvent avoir besoin d’un comportement différent. Dans ce cas, il vaut mieux créer un groupe d’exclusion propre que laisser la règle être contournée localement. Une exception documentée reste maîtrisable ; un contournement manuel devient vite invisible.

Le dernier piège est de présenter cette GPO comme une mesure de cybersécurité complète. Elle réduit une surface de confusion réseau, mais elle ne remplace ni segmentation, ni NAC, ni politiques Wi‑Fi, ni durcissement du poste.

Faut-il utiliser le filtrage de sécurité ?

Le filtrage de sécurité devient utile quand l’OU contient des machines hétérogènes. Vous pouvez lier la GPO à l’OU des portables, puis limiter son application à un groupe de machines contenant uniquement les postes dockés. Cette méthode évite de multiplier les OU techniques tout en conservant un ciblage lisible.

Elle demande en revanche une discipline d’inventaire. Si le groupe de sécurité n’est jamais mis à jour, la GPO ne suivra pas les nouveaux postes. Si tout le monde peut y ajouter une machine sans revue, l’exception devient incontrôlable. Le bon compromis consiste à rattacher cette mise à jour au processus d’entrée en parc : nouveau portable, affectation du profil, ajout au groupe, test de branchement, puis vérification après la première journée réelle de travail.

Pour les exceptions, évitez les exclusions dispersées. Créez un groupe identifié, avec une raison : laboratoire réseau, équipe terrain, besoin de double connectivité temporaire. Une exception sans date ni propriétaire finit toujours par devenir une dette d’administration.

Comment maintenir la règle dans le temps ?

Une fois la règle déployée, la maintenance doit rester légère. Ajoutez le contrôle dans votre recette de poste, dans la validation d’un nouveau modèle de portable et dans les tests de station d’accueil. Cela évite de découvrir le problème après une migration Windows, un changement d’ADMX ou l’arrivée d’un nouveau dock.

Sur un parc plus large, vous pouvez compléter par un inventaire ponctuel des interfaces actives. L’objectif n’est pas de surveiller en permanence chaque poste, mais de repérer les machines qui conservent deux chemins réseau malgré la politique. Quelques contrôles ciblés valent mieux qu’un tableau de bord permanent jamais lu.

Gardez enfin une note courte dans la base de connaissances du support : symptômes, chemin GPO, commande de vérification, cas d’exception et rollback. C’est ce document que l’équipe consultera le jour où un utilisateur dira que “le Wi‑Fi ne marche plus au bureau”.

Un contrôle PowerShell ponctuel peut aider, à condition de rester simple. Vous pouvez lister les adaptateurs actifs, repérer les machines où Wi‑Fi et Ethernet sont simultanément connectés, puis comparer ce résultat avec l’OU et le groupe de ciblage. L’intérêt n’est pas de produire un audit spectaculaire, mais de confirmer que la règle de parc correspond au comportement réel, en particulier après un renouvellement de postes ou une vague de docks différente.

Quand ne pas appliquer cette règle ?

Cette GPO n’est pas adaptée à tous les contextes. Un technicien qui doit diagnostiquer un réseau Wi‑Fi tout en gardant un accès filaire, un formateur qui bascule entre plusieurs salles ou un poste de supervision particulier peut avoir besoin d’une double connectivité temporaire. Dans ces cas, l’exception est légitime si elle est documentée.

Elle peut aussi poser problème dans certains environnements très mobiles, où les utilisateurs branchent rarement Ethernet mais passent par des adaptateurs intermittents. Si la règle coupe trop agressivement le Wi‑Fi à chaque détection courte du dock, l’expérience devient mauvaise. Le pilote sert précisément à repérer ces cas avant que la GPO ne devienne une gêne opérationnelle. Une politique réseau utile doit supprimer du bruit, pas créer une nouvelle habitude de contournement.

La recommandation pragmatique est donc claire : appliquer par défaut aux postes dockés et sédentaires, tester avec soin les profils mixtes, puis documenter les exceptions plutôt que chercher une règle universelle.

Une règle simple, mais à piloter proprement

La désactivation automatique du Wi‑Fi quand Ethernet est branché n’est pas une optimisation cosmétique. C’est une règle d’exploitation qui clarifie le comportement des portables, réduit les tickets réseau ambigus et rend le support plus prévisible. Elle mérite une GPO dédiée, un pilote court, des exceptions propres et une vérification documentée.

Votre prochaine action : choisissez cinq portables représentatifs, appliquez la GPO sur une OU de test, forcez la mise à jour, branchez chaque machine sur son dock réel et notez le résultat. Si le comportement est stable pendant une semaine, vous pourrez élargir sans transformer une bonne idée en incident de parc.