Hotspot Windows ne fonctionne pas : le service souvent inactif

Playbook de diagnostic rapide

Si vous êtes pressé, ne parcourez pas les bascules des Paramètres comme si c’était une maison hantée. Répondez dans cet ordre à trois questions : La pile Wi‑Fi peut‑elle héberger ? ICS/NAT est‑il actif ? Le trafic est‑il réellement acheminé ?

1) D’abord : confirmer que le mécanisme de hotspot est disponible

• Vérifiez si des adaptateurs virtuels Wi‑Fi Direct existent et sont activés.
• Vérifiez si la machine possède un adaptateur Wi‑Fi fonctionnel (ça semble évident ; souvent ce n’est pas le cas).

2) Ensuite : vérifiez le service qui le tue le plus souvent

• Le service Internet Connection Sharing (ICS) fonctionne‑t‑il ? (SharedAccess)
• Le Pare‑feu Windows (MpsSvc) est‑il en cours d’exécution ? (ICS s’appuie dessus.)
• WLAN AutoConfig (Wlansvc) est‑il en cours d’exécution ?

3) Enfin : prouvez que le routage/NAT et le DNS fonctionnent bout‑à‑bout

• L’adaptateur hotspot a‑t‑il une adresse IPv4 privée (généralement 192.168.137.1) ?
• Les clients reçoivent‑ils DHCP, passerelle par défaut et DNS ?
• Sur l’hôte, voyez‑vous la NAT configurée et les compteurs de trafic bouger ?

Faites cela dans cet ordre. Sinon vous « réparerez » le DNS alors que l’adaptateur n’a jamais été créé, ou vous réinitialiserez la pile réseau alors qu’un seul service est Disabled par politique.

Ce qu’est réellement le hotspot Windows (et ce que ce n’est pas)

Le Hotspot mobile Windows est une petite pile d’imitation de routeur :

• Couche Wi‑Fi Direct / SoftAP crée une interface point d’accès virtuelle.
• ICS (SharedAccess) relie cet adaptateur virtuel à la connexion montante, se charge d’un comportement type DHCP et configure le partage.
• NAT traduit le trafic de votre sous‑réseau privé du hotspot vers l’interface montante.
• Règles de pare‑feu permettent les bons flux. Si les services de pare‑feu sont cassés, ICS a tendance à échouer de façons intéressantes.
• Gestion du DNS est souvent « suffisante » jusqu’à l’arrivée des VPN et des agents endpoint d’entreprise qui ont leurs propres idées.

Ce que ce n’est pas : un routeur complet. Il a des dépendances fragiles, son comportement change selon les versions de Windows, et il suppose souvent que votre pile réseau n’est pas « gérée » par un logiciel tiers.

Vérité opérationnelle : si vous traitez le hotspot Windows comme un pont d’urgence de dernier kilomètre et non comme un composant réseau stratégique, vous serez beaucoup plus serein. Quand vous devez vous y fier, il faut un triage rapide et des corrections reproductibles — d’où ce guide.

Une idée paraphrasée à épingler : attribuée à John Allspaw : La fiabilité vient de la façon dont vous répondez à l’échec, pas du fait de prétendre que l’échec n’arrivera pas.

Faits intéressants et contexte historique (parce que Windows n’a pas inventé la NAT hier)

1. ICS précède l’interface « Hotspot mobile » de plusieurs années. Internet Connection Sharing existe depuis l’ère Windows XP, bien avant que l’application Paramètres moderne ne rende cela simple.
2. Hosted Network vs Wi‑Fi Direct : les anciennes versions de Windows s’appuyaient sur « Hosted Network » ; les versions récentes ont largement basculé vers Wi‑Fi Direct/SoftAP selon le support des pilotes.
3. 192.168.137.0/24 est le sous‑réseau classique d’ICS. Quand vous voyez 192.168.137.1 sur un adaptateur virtuel, vous regardez généralement ICS appliquer sa configuration par défaut.
4. ICS et le pare‑feu sont couplés. Brisez le service Pare‑feu Windows, et ICS échoue souvent à démarrer ou ne forwarde pas correctement le trafic.
5. Les VPN d’entreprise ont changé la donne. Les politiques de split‑tunnel, le DNS forcé et les pilotes filtre NDIS ont la fâcheuse habitude de « bien aider » votre hotspot à devenir non‑fonctionnel.
6. Hyper‑V et la virtualisation compliquent les liaisons d’adaptateurs. Les switches virtuels et pilotes de pont peuvent réordonner ou renommer les interfaces, perturbant la configuration de partage.
7. La gestion d’alimentation est un tueur silencieux. Les adaptateurs Wi‑Fi des portables sont souvent configurés pour « économiser de l’énergie », ce qui est charmant jusqu’à ce que vous tentiez de faire un point d’accès.
8. Les mises à jour Windows peuvent réinitialiser les types de démarrage des services. Ce n’est pas courant, mais suffisamment fréquent pour figurer dans tout playbook d’incident.

Blague #1 (courte, pertinente) : Le hotspot Windows, c’est comme un projecteur de salle de réunion : ça marche parfaitement jusqu’à ce qu’on en ait besoin.

Le service souvent inactif : ICS (SharedAccess)

Si votre hotspot démarre puis s’arrête, ne démarre jamais, ou affiche « Pas d’internet » pour les clients alors que votre portable va bien, supposez que SharedAccess est arrêté, Disabled ou incapable de se lier au bon adaptateur.

ICS n’est pas qu’un simple interrupteur de service. C’est un moteur de configuration qui :

• décide quelle interface est « publique » (montante) et quelle est « privée » (hotspot),
• attribue un sous‑réseau privé et assigne une IP à l’adaptateur hotspot,
• active le comportement NAT,
• ouvre des trous dans le pare‑feu pour permettre le forwarding et le comportement de type DHCP,
• peut être perturbé par la coexistence de plusieurs montantes (Wi‑Fi + Ethernet + VPN + cellulaire).

Ce qui le tue le plus souvent :

• Type de démarrage du service réglé sur Disabled (par politique, « debloat » ou durcissement de sécurité sans prise en compte des dépendances).
• Service Pare‑feu non démarré (ou produit pare‑feu tiers partiellement désinstallé).
• Client VPN installant des pilotes filtre NDIS qui changent le routage et le DNS de façon que ICS ne peut pas réconcilier.
• Pilote Wi‑Fi ne supportant pas les fonctions SoftAP/Wi‑Fi Direct requises, ou adaptateur virtuel masqué/désactivé.
• Corruption de la pile réseau après mises à jour, changement de pilote ou logiciels « d’optimisation réseau » agressifs.

Tâches pratiques : commandes, sorties, décisions (12+)

Voici les tâches que j’exécute réellement quand je dois faire fonctionner un hotspot en environnement proche de la production (labos, ponts d’incident, appareils sur le terrain). Chaque tâche inclut : une commande, ce que signifie la sortie, et la décision suivante.

Task 1: Check ICS service state (SharedAccess)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service -Name SharedAccess | Format-List Status,StartType,Name,DisplayName"
Status      : Stopped
StartType   : Disabled
Name        : SharedAccess
DisplayName : Internet Connection Sharing (ICS)

Signification : ICS est arrêté et Disabled. Le hotspot échouera typiquement à démarrer, ou démarrera puis s’arrêtera.

Décision : Passez le type de démarrage sur Manual/Automatic et démarrez‑le. Cherchez aussi ce qui l’a désactivé (politique, sécurité baseline, « debloat »).

Task 2: Enable and start ICS

cr0x@server:~$ powershell -NoProfile -Command "Set-Service -Name SharedAccess -StartupType Manual; Start-Service -Name SharedAccess; Get-Service SharedAccess"
Status   Name               DisplayName
------   ----               -----------
Running  SharedAccess       Internet Connection Sharing (ICS)

Signification : ICS est maintenant en cours d’exécution.

Décision : Essayez d’activer le Hotspot mobile à nouveau. Si ça échoue encore, vérifiez le service Pare‑feu et WLAN AutoConfig ensuite.

Task 3: Verify Windows Firewall service (MpsSvc)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service -Name MpsSvc | Format-List Status,StartType"
Status    : Stopped
StartType : Disabled

Signification : Le service Pare‑feu est Disabled/arrêté. ICS dépend souvent de lui et peut échouer même si SharedAccess est « Running ».

Décision : Réactivez MpsSvc, puis redémarrez SharedAccess.

Task 4: Re-enable Firewall service and restart ICS

cr0x@server:~$ powershell -NoProfile -Command "Set-Service -Name MpsSvc -StartupType Automatic; Start-Service MpsSvc; Restart-Service SharedAccess; Get-Service MpsSvc,SharedAccess | Format-Table Name,Status,StartType"
Name        Status  StartType
----        ------  ---------
MpsSvc      Running Automatic
SharedAccess Running Manual

Signification : Les dépendances principales sont opérationnelles.

Décision : Si le hotspot ne démarre toujours pas, passez aux vérifications des adaptateurs et pilotes.

Task 5: Check WLAN AutoConfig (Wlansvc)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service Wlansvc | Format-List Status,StartType"
Status    : Running
StartType : Automatic

Signification : Le service de configuration Wi‑Fi est sain.

Décision : Si le hotspot est encore cassé, inspectez les adaptateurs et les interfaces virtuelles Wi‑Fi Direct.

Task 6: List network adapters and find the hotspot virtual adapter

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Sort-Object Status,Name | Format-Table Name,InterfaceDescription,Status,LinkSpeed"
Name                         InterfaceDescription                                  Status     LinkSpeed
----                         --------------------                                  ------     ---------
Ethernet                     Intel(R) Ethernet Connection                          Up         1 Gbps
Wi-Fi                        Intel(R) Wi-Fi 6 AX201 160MHz                         Up         866.7 Mbps
Local Area Connection* 10    Microsoft Wi-Fi Direct Virtual Adapter                 Disconnected 0 bps
Local Area Connection* 11    Microsoft Wi-Fi Direct Virtual Adapter #2              Disconnected 0 bps

Signification : Des adaptateurs virtuels Wi‑Fi Direct existent. C’est un bon signe : Windows a quelque chose qu’il peut utiliser pour héberger.

Décision : Si ces adaptateurs manquent complètement, vous êtes probablement face à un problème de pilote, d’appareils masqués désactivés ou de restrictions par GPO.

Task 7: Check whether the hotspot adapter got the expected ICS IP

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration | Where-Object {$_.InterfaceAlias -like 'Local Area Connection*'} | Format-List InterfaceAlias,IPv4Address,IPv4DefaultGateway,DnsServer"
InterfaceAlias    : Local Area Connection* 10
IPv4Address       : 192.168.137.1
IPv4DefaultGateway:
DnsServer         :

Signification : Le côté privé est configuré (192.168.137.1). Gateway/DNS vide est normal pour l’interface privée.

Décision : S’il n’y a pas 192.168.137.1 (ou pas d’IPv4), ICS n’a pas configuré l’interface — retournez à SharedAccess, MpsSvc et aux journaux d’événements.

Task 8: Check NAT configuration (on modern Windows builds)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetNat | Format-Table Name,InternalIPInterfaceAddressPrefix,ExternalIPInterfaceAddressPrefix,Active"
Name                             InternalIPInterfaceAddressPrefix ExternalIPInterfaceAddressPrefix Active
----                             ------------------------------- -------------------------------- ------
SharedAccess_NAT                 192.168.137.0/24                0.0.0.0/0                        True

Signification : Une NAT existe et est active pour le sous‑réseau ICS.

Décision : Si aucun objet NAT n’existe, ICS n’applique peut‑être pas correctement sa configuration. Redémarrez SharedAccess ; si l’objet est toujours absent, réinitialisez le réseau et revérifiez les dépendances.

Task 9: Confirm routing table isn’t pointing clients into a black hole

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -AddressFamily IPv4 | Sort-Object -Property RouteMetric | Select-Object -First 8 | Format-Table DestinationPrefix,NextHop,InterfaceAlias,RouteMetric"
DestinationPrefix  NextHop        InterfaceAlias RouteMetric
-----------------  ------        -------------- -----------
0.0.0.0/0          192.0.2.1      Wi-Fi          25
192.168.137.0/24   0.0.0.0        Local Area Connection* 10 256
192.168.1.0/24     0.0.0.0        Wi-Fi          281

Signification : La route par défaut passe par le Wi‑Fi. Le sous‑réseau du hotspot est connecté directement.

Décision : Si la route par défaut pointe vers une interface VPN alors que vous attendiez Wi‑Fi/Ethernet, vous avez peut‑être un VPN en tunnel forcé. Les clients du hotspot peuvent perdre l’internet sauf si la politique autorise le split tunneling.

Task 10: Look at IP addressing on the upstream interface

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration -InterfaceAlias 'Wi-Fi' | Format-List InterfaceAlias,IPv4Address,IPv4DefaultGateway,DnsServer"
InterfaceAlias     : Wi-Fi
IPv4Address        : 192.168.1.50
IPv4DefaultGateway : 192.168.1.1
DnsServer          : {192.168.1.1}

Signification : L’amont semble sain.

Décision : Si le DNS amont est un résolveur d’entreprise accessible uniquement via VPN, les clients peuvent afficher « connecté, pas d’internet ». Décidez de changer le DNS des clients, déconnecter le VPN ou ajuster le split tunneling.

Task 11: Check event logs for SharedAccess/ICS failures

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName System -MaxEvents 80 | Where-Object {$_.ProviderName -match 'SharedAccess|Service Control Manager'} | Select-Object -First 8 | Format-Table TimeCreated,ProviderName,Id,LevelDisplayName,Message -Wrap"
TimeCreated           ProviderName              Id  LevelDisplayName Message
-----------           ------------              --  ---------------- ------
2/5/2026 9:18:10 AM  Service Control Manager   7000 Error            The Internet Connection Sharing (ICS) service failed to start due to the following error: The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.

Signification : Classique : service désactivé ou dépendance d’adaptateur manquante/désactivée.

Décision : Vérifiez la présence/état activé de l’adaptateur ; vérifiez les types de démarrage des services ; supprimez les politiques « debloat » ; puis redémarrez.

Task 12: Validate Wi‑Fi driver support (Hosted network status hint)

cr0x@server:~$ netsh wlan show drivers
Interface name: Wi-Fi

    Driver                    : Intel(R) Wi-Fi 6 AX201 160MHz
    Vendor                    : Intel Corporation
    Provider                  : Intel
    Date                      : 1/10/2026
    Version                   : 23.20.0.4
    Radio types supported     : 802.11b 802.11g 802.11n 802.11ac 802.11ax
    Hosted network supported  : No
    Wireless Display Supported: Yes (Graphics Driver: Yes, Wi-Fi Driver: Yes)

Signification : « Hosted network supported: No » ne tue pas automatiquement le Hotspot mobile sur les versions récentes (Wi‑Fi Direct peut encore fonctionner), mais c’est un signal d’alerte : les capacités du pilote sont limitées ou ont changé.

Décision : Si le hotspot ne démarre pas et que Hosted Network est No, priorisez la mise à jour des pilotes, les pilotes OEM ou un autre adaptateur (dongle Wi‑Fi USB supportant SoftAP).

Task 13: Reset the network stack (the controlled burn)

cr0x@server:~$ powershell -NoProfile -Command "netsh int ip reset; netsh winsock reset"
Resetting Global, OK!
Resetting Interface, OK!
Restart the computer to complete this action.
Successfully reset the Winsock Catalog.
You must restart the computer in order to complete the reset.

Signification : Vous avez réinitialisé TCP/IP et Winsock. Cela peut nettoyer des LSP/filters corrompus et un mauvais état d’interface.

Décision : Redémarrez. Puis revérifiez l’état des services et la présence des adaptateurs. Si c’est une machine d’entreprise, attendez‑vous à ce que les clients VPN et agents endpoint se réimposent après le redémarrage.

Task 14: Check for “helpful” VPN routes and DNS changes

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table InterfaceAlias,ServerAddresses"
InterfaceAlias                 ServerAddresses
--------------                 --------------
Wi-Fi                          {10.10.10.53, 10.10.10.54}
Local Area Connection* 10      {}
Ethernet                       {}

Signification : Le DNS amont Wi‑Fi est défini sur des résolveurs d’entreprise (probablement via VPN ou profil). Si ces résolveurs ne sont joignables que par l’interface VPN, les clients du hotspot ne résoudront pas les noms.

Décision : Déconnectez le VPN, activez le split tunneling (si autorisé) ou remettez le DNS amont sur celui du FAI/local pendant l’usage du hotspot.

Task 15: Verify firewall profiles (Public/Private) aren’t sabotaging sharing

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Format-Table Name,InterfaceAlias,NetworkCategory,IPv4Connectivity"
Name           InterfaceAlias NetworkCategory IPv4Connectivity
----           -------------- -------------- ---------------
CorpWiFi       Wi-Fi          Public         Internet
Unidentified   Local Area Connection* 10 Private        NoTraffic

Signification : L’amont est Public ; le côté hotspot est Private (ok). Si les deux sont Public avec des règles strictes, le forwarding peut être bloqué selon la politique.

Décision : Si la politique le permet, définissez le côté hotspot en Private. Si la politique l’interdit, utilisez plutôt un routeur de voyage ou le tethering du téléphone plutôt que de lutter contre la politique.

Blague #2 (courte, pertinente) : Certains clients VPN considèrent le « partage d’internet » comme un incident de sécurité. Ils n’ont pas tort ; ils sont juste inconvenants.

Modes de panne par symptôme (ce que ça vous dit)

Symptôme A : Le bouton Hotspot mobile s’active puis se désactive immédiatement

C’est le pattern classique « une dépendance est morte ». L’interface utilisateur de Windows est optimiste ; la couche service ne l’est pas.

• Très probable : SharedAccess arrêté/Disabled ; MpsSvc Disabled ; adaptateur manquant ; pilote incapable de créer l’interface Wi‑Fi Direct.
• Fréquent aussi : un pare‑feu/VPN tiers a inséré des pilotes filtre et laissé la pile incohérente.

Symptôme B : Le hotspot s’active, les clients se connectent, mais pas d’internet

Généralement ce n’est pas du « Wi‑Fi ». C’est du routage, de la NAT ou du DNS.

• Probable : NAT manquante ou non liée ; route amont passant par VPN ; résolveurs DNS inaccessibles ; client a une adresse APIPA (169.254.x.x) suite à un échec DHCP.
• Moins probable : portail captif amont non complété (Wi‑Fi d’hôtel), donc l’hôte semble avoir internet via une session mise en cache mais les nouveaux clients n’en profitent pas.

Symptôme C : Erreur « Nous ne pouvons pas configurer le hotspot mobile »

Ce message est la façon polie de Windows de refuser de dire quel composant interne a échoué. Utilisez les journaux d’événements et les vérifs de services pour le faire parler.

Symptôme D : Le hotspot fonctionne après redémarrage, puis échoue après connexion au VPN

C’est un conflit de routage/DNS. Le VPN gagne, le hotspot perd, et vous devez arbitrer avec des outils que vous ne devriez probablement pas avoir à utiliser.

Symptôme E : L’option hotspot est absente

Soit l’appareil n’a pas d’adaptateur/pilote Wi‑Fi compatible, soit c’est bloqué par une politique (MDM/GPO), soit vous êtes sur une édition/build de Windows avec restrictions. Pilote et politique sont les deux premiers suspects.

Erreurs fréquentes : symptôme → cause → correctif

Voici les récidivistes que je vois sur de vraies flottes. Les corrections sont spécifiques parce que les conseils vagues vous amènent souvent à réinstaller Windows à 2 h du matin.

1) Le hotspot ne démarre pas du tout

Symptôme : Le bouton s’active puis se désactive ; erreur de configuration.

Cause : Service SharedAccess Disabled ou ne démarre pas ; parfois suite à une politique ou un script de « debloat ».

Fix : Réglez SharedAccess en Manual ; démarrez‑le ; vérifiez que MpsSvc est Running ; puis réessayez.

2) Les clients se connectent mais ont « Pas d’internet »

Symptôme : Le Wi‑Fi indique connecté ; navigation impossible ; timeouts DNS.

Cause : VPN en tunnel forcé utilisé comme route par défaut ; DNS pointant vers des résolveurs accessibles uniquement via VPN ; objet NAT manquant.

Fix : Déconnectez le VPN (ou autorisez le split tunnel) ; restaurez le DNS amont ; confirmez que Get-NetNat montre SharedAccess_NAT actif.

3) Les clients obtiennent des adresses 169.254.x.x

Symptôme : Le client a une adresse APIPA ; impossible de joindre 192.168.137.1.

Cause : Le comportement DHCP d’ICS ne fonctionne pas parce que SharedAccess n’applique pas la config, ou les règles de pare‑feu le bloquent.

Fix : Assurez‑vous que SharedAccess et MpsSvc fonctionnent ; réinitialisez le réseau ; puis vérifiez que l’adaptateur hotspot obtient 192.168.137.1.

4) Le hotspot ne fonctionne qu’en 2,4 GHz (ou uniquement en 5 GHz) et disparaît aléatoirement

Symptôme : Certains clients ne voient pas le SSID ; d’autres se connectent très bien.

Cause : Problèmes de domaine réglementaire/canal ; limitations du pilote ; confusion par band steering ; chipsets clients incapables de certains canaux.

Fix : Forcez une autre bande dans les paramètres du hotspot si disponible ; mettez à jour les pilotes Wi‑Fi ; évitez les canaux DFS en utilisant le 2,4 GHz pour compatibilité.

5) « J’ai désactivé le Pare‑feu Windows pour dépanner » et c’est pire

Symptôme : Vous avez coupé le pare‑feu et le hotspot est mort.

Cause : Désactivation du service (MpsSvc) plutôt que d’un profil — cela casse les attentes d’ICS.

Fix : Réactivez le service MpsSvc, mettez‑le en Automatic, démarrez‑le ; laissez les profils gérés par la politique si nécessaire.

6) Le hotspot fonctionnait ; après mise à jour du pilote il a arrêté

Symptôme : Adaptateur virtuel manquant ; option hotspot présente mais échec.

Cause : Le package pilote a changé les capacités Wi‑Fi Direct/SoftAP ou a créé un périphérique masqué/désactivé.

Fix : Restaurez le pilote ; installez le pilote OEM ; vérifiez la présence des adaptateurs Microsoft Wi‑Fi Direct via Get-NetAdapter.

7) La politique d’entreprise bloque ICS

Symptôme : SharedAccess est forcé Disabled après chaque redémarrage ; bouton hotspot manquant ou échec constant.

Cause : MDM/GPO baseline de sécurité bloque ICS pour empêcher le pontage de réseaux.

Fix : Ne luttez pas localement contre la politique. Demandez une exception ou utilisez un routeur de voyage / tethering approuvé.

8) « Réinitialisation réseau » l’a réparé une fois, puis c’est revenu

Symptôme : Ça marche après reset/redémarrage ; ça casse après que le client VPN/agent de sécurité ait mis à jour.

Cause : Un pilote filtre NDIS tiers ou une politique réintroduit la configuration cassante.

Fix : Identifiez le composant fautif (VPN, pare‑feu endpoint) et coordonnez‑vous avec l’IT ; traitez la réinitialisation réseau comme un palliatif temporaire.

Trois mini‑histoires du monde de l’entreprise (anonymisées, plausibles, techniquement exactes)

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Une équipe terrain devait mettre à jour le firmware d’une série de capteurs de labo sur le site d’un client où le Wi‑Fi invité bloquait les appareils entre eux. Le plan était simple : l’ingénieur crée un hotspot, les capteurs se connectent, le firmware est poussé localement, et c’est fini. L’ingénieur l’avait déjà fait des centaines de fois à la maison.

Sur place, le bouton du hotspot s’est activé puis désactivé immédiatement. L’équipe a supposé « la carte Wi‑Fi est morte » et a commandé un dongle Wi‑Fi USB livré en overnight. Pendant ce temps, les capteurs étaient inactifs et le chef de projet commençait à rédiger le genre d’email qui ressemble à une mise à jour de CV.

Le vrai problème était plus stupide : un durcissement endpoint avait mis SharedAccess en Disabled des mois auparavant lors d’un sweep de sécurité. Personne ne l’avait relié au Hotspot mobile parce que l’UI ne dit pas « ICS est désactivé par politique ». Elle s’en fiche et basta.

La correction a été une exception de politique appliquée à un groupe d’appareils spécifique, plus une entrée dans le runbook : avant de voyager, vérifiez SharedAccess/MpsSvc. Le dongle USB est arrivé le lendemain — toujours sous blister, comme un monument aux hypothèses.

Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux

Une équipe IT corporate a décidé d’« accélérer le démarrage » en désactivant des services que « personne n’utilise ». Ils ont utilisé un script trouvé sur Internet — toujours un excellent début — et l’ont déployé sur un sous‑ensemble d’ordinateurs en pilote.

Tout semblait bien jusqu’à ce qu’un ingénieur commercial ait besoin de partager un Ethernet d’hôtel avec un appareil de démo. Le hotspot a échoué. Puis un autre ingénieur a rencontré le même problème en installant rapidement un réseau de labo en salle de conférence. Les escalades ont atterri dans la même file de support en quelques heures.

La liste des coupables était prévisible : SharedAccess Disabled ; MpsSvc en Manual et ne démarrant pas ; quelques services réseau auxiliaires retardés. L’« optimisation » a sauvé une fraction de seconde au démarrage et coûté plusieurs heures‑personnes plus une perte de réputation. Le pilote a été annulé.

L’amélioration durable n’a pas été « ne jamais optimiser ». Elle a été : si vous changez des baselines de services, maintenez une carte des dépendances et testez des workflows réels — hotspot/ICS, VPN, scenarios dock/undock. Les gains de performance qui cassent des workflows essentiels ne sont pas des gains ; ce sont des incidents avec un meilleur branding.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la journée

Une entreprise régulée avait une posture stricte : pas de pont hotspot ad‑hoc depuis des appareils corporates sauf approbation explicite. C’est normal. Ce qui a rendu cela opérationnel, c’est que les exceptions étaient traitées comme de l’ingénierie, pas des faveurs.

Une équipe de labo a demandé l’accès hotspot pour un petit ensemble d’appareils dans une salle de test blindée sans prises LAN. La sécurité a accepté, mais a exigé des garde‑fous : seulement certains portables, seulement pendant les heures de labo, et avec journalisation. L’IT a construit un petit package de configuration qui mettait SharedAccess sur Manual (pas Disabled), assurait MpsSvc en Automatic et validait les versions de pilotes pour le modèle d’adaptateur Wi‑Fi approuvé.

Des mois plus tard, une mise à jour Windows a modifié le comportement réseau sur certaines machines. Les portables de labo n’ont pas fondu parce que le package de configuration s’exécutait à chaque check‑in et réparait la dérive. Le labo avait une checklist, et le SRE de garde connaissait les états connus‑bons à comparer.

C’était ennuyeux. Ça a aussi marché. La plupart des victoires en fiabilité ressemblent à « rien ne s’est passé », ce qui est le plus grand compliment qu’un système de production puisse recevoir.

Listes de vérification / plan pas à pas

Checklist 1: Faire fonctionner le hotspot sur une machine Windows personnelle normale

1. Redémarrez une fois (oui, vraiment). Si ça corrige, procédez quand même — les victoires intermittentes ramènent les problèmes.
2. Vérifiez SharedAccess n’est pas Disabled ; démarrez‑le.
3. Vérifiez MpsSvc est Running et Automatic.
4. Vérifiez Wlansvc est Running et Automatic.
5. Vérifiez l’existence des adaptateurs virtuels Wi‑Fi Direct (Get-NetAdapter ; cherchez Microsoft Wi‑Fi Direct Virtual Adapter).
6. Activez le hotspot dans Paramètres et observez s’il reste activé pendant 30 secondes.
7. Vérifiez l’IP de l’adaptateur hotspot est 192.168.137.1 (ou un autre privé si personnalisé).
8. Connectez un client ; confirmez qu’il obtient une adresse 192.168.137.x et passerelle 192.168.137.1.
9. Depuis le client testez un ping vers 192.168.137.1, puis une résolution DNS, puis HTTP vers un site connu.

Checklist 2: Approche pour appareil d’entreprise (conscient des politiques)

1. Supposez que la politique bloque ICS jusqu’à preuve du contraire. Vérifiez le StartType de SharedAccess ; s’il est forcé Disabled, stoppez et escaladez correctement.
2. Déconnectez le VPN pour le test (à moins que la politique n’exige VPN always‑on ; dans ce cas, acceptez que le hotspot soit peut‑être impossible).
3. Confirmez que le produit pare‑feu endpoint ne désactive pas le service MpsSvc. Si c’est le cas, vous avez besoin d’une configuration fournisseur/IT, pas d’un bricolage local.
4. Vérifiez les journaux d’événements pour des erreurs du Service Control Manager autour de SharedAccess et MpsSvc.
5. Ne « réparez » pas en désinstallant le logiciel de sécurité. C’est une décision limitant la carrière.
6. Si c’est critique pour le business : utilisez un routeur de voyage approuvé ou le tethering téléphone ; traitez le hotspot Windows comme non garanti sous contrôles corporate.

Checklist 3: Triage « hotspot pas d’internet »

1. Confirmez que l’hôte a internet sur l’interface montante.
2. Confirmez que le client a une IP, une passerelle et un DNS.
3. Sur l’hôte, confirmez que la NAT existe (Get-NetNat) et que l’adaptateur hotspot a 192.168.137.1.
4. Si le client peut ping 192.168.137.1 mais ne résout pas les noms, c’est un problème de DNS (souvent lié au VPN).
5. Si le client résout les noms mais ne peut pas atteindre des IPs, c’est NAT/routage/pare‑feu.
6. Si le client n’obtient pas d’IP, c’est ICS/service/règles de pare‑feu.

FAQ

1) Pourquoi le hotspot Windows dépend‑il d’ICS ?

Parce que le partage hotspot est essentiellement « partager cette connexion montante vers cette interface privée », ce pour quoi ICS a été conçu. L’interface s’est modernisée ; la plomberie est restée familière.

2) Si SharedAccess fonctionne, pourquoi le hotspot échoue‑t‑il encore ?

Fonctionner n’est pas la même chose que fonctionner correctement. ICS peut être Running mais incapable de se lier aux bons adaptateurs, bloqué par des politiques de pare‑feu, sans configuration NAT, ou perturbé par des pilotes filtre VPN. Vérifiez MpsSvc, la présence des adaptateurs et les journaux d’événements.

3) Pourquoi les clients se connectent mais affichent « Pas d’internet » ?

Généralement DNS ou routage. Le client parle à l’AP, mais la résolution de noms pointe vers des serveurs DNS inaccessibles (courant avec les VPN), ou la NAT ne traduit pas le trafic vers l’interface montante.

4) Que signifie 192.168.137.1 ?

C’est l’IP privée par défaut que Windows assigne à l’interface partagée (hotspot) quand ICS configure le partage. La voir est un bon indicateur qu’ICS a appliqué la configuration.

5) Puis‑je changer le sous‑réseau ICS 192.168.137.0/24 ?

Parfois, mais ce n’est pas un réglage convivial et le comportement varie selon les builds. Si vous avez collision avec un réseau amont en 192.168.137.0/24, la solution pragmatique est d’éviter ce réseau amont ou d’utiliser un routeur dédié qui permet de choisir clairement le sous‑réseau.

6) Pourquoi ça a arrêté de marcher après l’installation d’un VPN ?

Les clients VPN installent souvent des pilotes filtre réseau, imposent des paramètres DNS et réécrivent les routes. Cela peut casser le forwarding NAT ou rendre le DNS injoignable pour les clients du hotspot. Si la politique le permet, testez sans VPN.

7) « Hosted network supported: No » signifie‑t‑il que le hotspot ne peut pas marcher ?

Pas toujours. Certaines implémentations récentes du hotspot reposent sur Wi‑Fi Direct plutôt que sur l’ancien Hosted Network. Mais si vous avez des échecs et voyez Hosted Network unsupported, les limitations du pilote deviennent un suspect prioritaire.

8) Désactiver le Pare‑feu Windows est‑ce une bonne étape de dépannage ?

Désactiver un profil de pare‑feu peut être informatif. Désactiver le service (MpsSvc) est généralement destructeur pour ICS/hotspot. Gardez le service en marche.

9) Pourquoi le hotspot marche après redémarrage mais casse ensuite ?

Quelque chose reconfigure la pile réseau après le démarrage : VPN qui se connecte automatiquement, rafraîchissement de la politique endpoint, gestion d’alimentation des pilotes, ou changement d’état d’un adaptateur après mise en veille. Suivez ce qui change entre « ça marche » et « c’est cassé ».

10) Quel est le contournement le plus fiable quand le hotspot Windows est capricieux ?

Un petit routeur de voyage ou le tethering d’un téléphone. Pas glamour, mais c’est un matériel réseau conçu pour cela plutôt qu’un OS de bureau qui fait semblant.

Prochaines étapes (faites ceci, pas ça)

Quand le hotspot Windows échoue, ne commencez pas par réinstaller des pilotes ou cliquer des dizaines de fois sur les bascules jusqu’à user la souris. Commencez par la vérité ennuyeuse : SharedAccess (ICS) et MpsSvc sont les cadavres habituels. Ramenez‑les, confirmez que l’adaptateur hotspot obtient son IP privée, puis prouvez que NAT et DNS fonctionnent.

Faites ceci :

• Vérifiez les états et types de démarrage de SharedAccess, MpsSvc, Wlansvc.
• Vérifiez l’existence d’adaptateurs virtuels Wi‑Fi Direct.
• Confirmez que 192.168.137.1 (ou votre IP privée configurée) apparaît sur l’adaptateur hotspot.
• Vérifiez NAT et routage ; suspectez le VPN quand les clients ont « Pas d’internet ».
• Utilisez les journaux d’événements pour remplacer les suppositions par des preuves.

Évitez ceci :

• Désactiver le service Pare‑feu pour « voir si ça aide ». Ça fait généralement pire.
• Scripts « d’optimisation » aléatoires qui désactivent des services sans cartographie des dépendances.
• Combattre localement la politique d’entreprise. Si ICS est bloqué par conception, escaladez ou utilisez du matériel approuvé.

Si vous deviez retenir une règle opérationnelle : traitez le hotspot Windows comme un graphe de dépendances, pas comme un bouton. Le bouton est la partie la moins intéressante.