Windows 11 : évitez les coupures de Wi-Fi et de VPN en PME

Votre PME utilise un Wi-Fi d’entreprise ou un VPN avec connexion automatique ? Faites vérifier son authentification avant de généraliser les mises à jour Windows d’octobre. La mise à jour du 13 octobre 2026 durcit certains mécanismes de connexion : Microsoft indique que des accès Wi-Fi, Ethernet et VPN peuvent être affectés lorsque ceux-ci reposent sur des identifiants dérivés de NTLMv1. Le périmètre est précis, il ne concerne pas tous les réseaux ni tous les ordinateurs, comme l’explique le message officiel publié le 14 octobre.

Pour un dirigeant, la bonne décision n’est pas de suspendre durablement les correctifs de sécurité. Elle consiste à identifier les postes concernés, préserver les accès indispensables et organiser la suppression de la dépendance technique. Voici comment mener cette vérification avec votre prestataire informatique, puis décider si vos applications métiers nécessitent également une intervention.

Ce qui a changé le 13 octobre dans Windows 11

Dans les notes de la mise à jour KB5127648, complétées le 15 octobre, Microsoft décrit un changement de comportement : sur certains appareils, Windows bloque désormais par défaut la génération d’identifiants dérivés de NTLMv1 pour l’authentification unique, ou SSO. Cette évolution vise les appareils où Credential Guard est désactivé et où le paramètre BlockNtlmv1SSO n’est pas explicitement configuré.

Microsoft présente cette mesure comme un durcissement de sécurité planifié, et non comme un dysfonctionnement à attendre de voir disparaître dans un prochain correctif. Son annonce du 14 octobre 2026 cite Windows 11 24H2, 25H2 et 26H2 ainsi que Windows Server 2025, et recommande d’éliminer les dépendances concernées au profit d’une authentification par certificats.

Une organisation a déjà confirmé un impact concret. Dans son avis informatique du 16 octobre, l’université York indique que cette mise à jour perturbe les connexions à son réseau sans fil utilisant MS-CHAPv2. L’établissement précise que ses ordinateurs gérés par Intune avec authentification moderne par certificats ne sont pas affectés par ce problème particulier.

La leçon pour une PME n’est donc pas « Windows casse le Wi-Fi ». Elle est plus opérationnelle : une connexion qui fonctionnait hier peut dépendre d’un mécanisme que la politique de sécurité n’autorise plus aujourd’hui. Votre audit doit porter sur cette dépendance, pas seulement sur l’état du routeur ou de la borne Wi-Fi.

Votre entreprise est-elle concernée par ce blocage ?

Votre entreprise doit vérifier ses configurations si des postes Windows utilisent une authentification automatique pour rejoindre un réseau professionnel ou un VPN. La présence de Windows 11 ne suffit pas à conclure à une exposition : demandez une vérification technique de la méthode d’authentification et de la configuration des appareils.

Le guide Microsoft KB5066470 identifie notamment les connexions fondées sur MS-CHAPv2, dont PEAP-MSCHAPv2 et EAP-MSCHAPv2. Le changement porte sur certains parcours SSO, pas sur une interdiction générale du Wi-Fi ou des VPN.

Pour obtenir une réponse exploitable, transmettez ces questions à votre responsable informatique :

• Quels profils Wi-Fi, Ethernet et VPN utilisent les identifiants de la session Windows pour connecter automatiquement l’utilisateur ?
• Quelle méthode d’authentification chaque profil emploie-t-il réellement ?
• Quels postes ont reçu la mise à jour d’octobre et lesquels doivent encore la recevoir ?
• Credential Guard est-il activé sur les appareils examinés ?
• Existe-t-il une configuration explicite de BlockNtlmv1SSO ou des exceptions déjà déployées ?
• Quels utilisateurs peuvent perdre l’accès à une activité indispensable si la connexion échoue ?

Demandez un résultat écrit : une liste des configurations concernées, des postes représentatifs testés et des actions restantes. Une réponse comme « nous n’utilisons plus NTLMv1 » ne remplace pas la vérification des parcours réseau visés par Microsoft.

Évitez aussi de considérer tous les sites comme identiques. Pour le diagnostic, traitez séparément le siège, les agences, l’atelier et les postes en télétravail. Faites confirmer leur configuration plutôt que de déduire leur comportement du seul test réalisé dans les bureaux principaux.

Quel impact pour votre ERP, votre application terrain ou votre SaaS ?

Le premier point à distinguer est l’accès au réseau et l’accès à l’application. Avant d’ouvrir un chantier de développement, demandez à votre équipe de localiser l’étape qui échoue : connexion au Wi-Fi, établissement du VPN, ouverture de l’application ou authentification dans cette application.

Cette distinction évite de commander une modification logicielle pour résoudre un problème de configuration réseau. Elle permet aussi d’identifier les situations où l’incident révèle une fragilité plus profonde de l’organisation.

Exemple : une PME industrielle qui dépend d’un ERP interne

Imaginons une PME industrielle dont les équipes administratives accèdent à l’ERP depuis les bureaux et les responsables de production depuis l’atelier. Pour préparer le déploiement Windows, faites tester un cycle complet sur chaque parcours : connexion au poste, accès réseau, consultation d’un ordre de fabrication, saisie d’une opération puis enregistrement.

Le critère de réussite ne doit pas être « la page de connexion s’affiche ». Vérifiez que le salarié peut terminer son travail et retrouver les données enregistrées. Associez un référent métier au test : un administrateur technique ne saura pas nécessairement reconnaître une anomalie dans un écran de production.

Exemple : une équipe terrain qui travaille à distance

Pour une entreprise de maintenance ou du BTP, choisissez un scénario représentatif du déplacement : démarrage de l’ordinateur hors du bureau, connexion au réseau disponible, ouverture du VPN si nécessaire, consultation d’une intervention et transmission du compte rendu.

Si ce test montre que l’ensemble du travail dépend d’une connexion permanente, inscrivez séparément une réflexion sur la continuité de votre logiciel métier. Ne lancez pas une refonte dans l’urgence : commencez par définir quelles opérations doivent rester possibles lors d’une perte d’accès et quelles données peuvent être conservées localement.

Exemple : un éditeur SaaS et ses clients entreprises

Pour un éditeur SaaS, préparez le support à distinguer un incident du service d’un problème d’accès chez le client. Proposez une procédure de diagnostic approuvée : vérifier l’état du service, identifier l’étape de connexion en échec et transmettre les informations utiles à l’administrateur du client.

N’invitez pas les utilisateurs à contourner leur VPN ou les règles de leur entreprise pour « essayer ». Le support doit aider à localiser le problème, pas créer une exception de sécurité sans validation.

Que faire maintenant sans bloquer les mises à jour ?

Nous recommandons une démarche en trois étapes : qualifier le périmètre, tester les usages critiques, puis déployer avec une procédure de secours. Le calendrier ci-dessous constitue une proposition d’organisation, pas une échéance imposée par Microsoft.

Constituez un pilote représentatif

Choisissez des appareils selon leurs usages, pas uniquement selon leur disponibilité. Incluez un poste de bureau, un ordinateur portable utilisé hors site et, si votre activité le demande, un équipement partagé ou rattaché à une agence.

Testez également avec un compte utilisateur ordinaire. Faites vérifier les connexions après un redémarrage, une fermeture de session et une reprise après mise en veille. L’objectif est de couvrir les gestes habituels des salariés, pas de réussir une démonstration dans des conditions exceptionnelles.

Préparez le support avant la généralisation

Fournissez au support une fiche indiquant les symptômes recherchés, les informations à collecter et le responsable habilité à décider d’une mesure temporaire. Demandez de relever l’heure de l’échec, le profil réseau utilisé et l’état du poste, sans collecter les mots de passe des utilisateurs.

Pour les équipes métiers, préparez une consigne simple : qui appeler, quelle opération interrompre et où noter les tâches non transmises. Si des commandes ou comptes rendus doivent être ressaisis après rétablissement, désignez une personne chargée d’éviter les doublons.

Pour les CTO : diagnostiquer avant de modifier le registre

La documentation KB5066470 décrit deux événements dans le journal Microsoft-Windows-NTLM/Operational : 4024 pour l’audit d’une tentative et 4025 pour un blocage. Utilisez ces traces pour vérifier l’hypothèse avant d’appliquer un changement de configuration.

Organisez le diagnostic autour d’une chronologie : état fonctionnel connu, installation de la mise à jour, premier échec, événements correspondants et résultat du test après intervention. Conservez également la configuration initiale du poste et les politiques qui lui sont appliquées.

Microsoft documente une exception temporaire : définir la valeur BlockNtlmv1SSO de type REG_DWORD à 0 dans HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0. Le mode Audit autorise alors les demandes concernées. La valeur 1 correspond au mode Enforce. L’éditeur précise que le mode Audit réduit la protection et doit rester une exception limitée, selon la procédure officielle.

Ne transformez pas ce réglage en commande à diffuser sans contrôle. Avant toute intervention, exigez :

• une dépendance identifiée et un besoin métier justifiant l’exception ;
• une sauvegarde de la configuration concernée et une méthode de restauration ;
• un périmètre limité de postes, avec un responsable nommé ;
• une date de réexamen et une tâche de suppression de l’exception ;
• un test final prouvant que le parcours fonctionne dans la configuration cible.

Vérifiez aussi qu’une politique centralisée ne réapplique pas une ancienne configuration après votre correction. Faites apparaître les exceptions dans votre outil de suivi : une mesure temporaire invisible devient difficile à supprimer.

La correction durable : traiter l’authentification et la continuité séparément

Pour les connexions concernées, Microsoft recommande de migrer vers une authentification par certificats. Demandez à votre prestataire réseau un plan qui couvre non seulement le déploiement initial, mais aussi le renouvellement, la révocation, l’arrivée d’un salarié et le remplacement d’un ordinateur.

Pour cadrer cette migration, posez des questions concrètes : qui délivre les certificats, comment les appareils sont-ils enrôlés, comment retire-t-on un accès et que fait le support si un renouvellement échoue ? Faites inclure un test sur un appareil nouvellement préparé, et pas seulement sur un poste historique déjà configuré.

Le chantier applicatif répond à une autre question : comment continuer à travailler lorsqu’un accès devient indisponible ? Pour une application web métier, demandez d’abord une analyse des parcours sensibles : saisies non enregistrées, opérations interrompues et information présentée à l’utilisateur lors d’une déconnexion.

Ces améliorations doivent être proportionnées. Une application utilisée occasionnellement ne justifie pas nécessairement un mode hors connexion complet. À l’inverse, pour une équipe dont chaque intervention produit un compte rendu indispensable, la gestion des interruptions mérite un arbitrage explicite.

Séparez les deux budgets : la migration de l’accès réseau d’un côté, les éventuelles évolutions du logiciel de l’autre. Cette séparation permet de rétablir un accès sûr sans faire dépendre l’urgence d’un projet de refonte.

Comment chiffrer l’intervention sans accepter un devis flou ?

Demandez un chiffrage par livrables plutôt qu’un forfait intitulé « correction Windows ». Le prix doit correspondre à un périmètre vérifiable : configurations examinées, sites couverts, profils testés et documentation remise.

• Diagnostic : inventaire des accès, examen des configurations et reproduction sur un échantillon.
• Continuité : accompagnement du support et éventuelles exceptions approuvées.
• Migration : configuration cible, déploiement pilote et généralisation.
• Validation : tests métiers, suppression des exceptions et transfert des procédures.
• Évolutions applicatives : uniquement si le diagnostic établit un besoin distinct.

Pour hiérarchiser les efforts, utilisez vos propres données. À titre d’exemple de calcul, et non de statistique, 20 salariés bloqués pendant 2 heures représentent 40 heures de travail indisponibles. Ajoutez ensuite le coût du support et de la reprise, sans supposer que toutes ces heures correspondent automatiquement à une perte de chiffre d’affaires.

Le devis doit préciser qui réalise la validation métier. Vous pouvez reprendre la méthode de notre guide sur la recette d’une application web pour formaliser les scénarios et les critères d’acceptation.

Trois décisions à éviter

• Geler les mises à jour sans stratégie de sortie. Demandez plutôt un déploiement progressif, un pilote et une liste explicite des points bloquants.
• Appliquer une exception à tout le parc par précaution. Exigez une justification par configuration concernée et une procédure de retrait.
• Réécrire l’application avant d’avoir localisé l’échec. Faites démontrer si le problème se situe dans l’accès réseau ou dans le logiciel.

Ajoutez un critère de clôture au ticket : le travail n’est pas terminé lorsque « les utilisateurs se reconnectent », mais lorsque la configuration cible est validée, les exceptions supprimées et les procédures de support mises à jour.

Sécurisez les accès Windows 11 sans lancer une refonte inutile

Le durcissement Windows 11 d’octobre appelle une décision ciblée : vérifier les authentifications réseau, tester les parcours essentiels et financer la correction réellement nécessaire. N’utilisez une solution temporaire qu’avec un responsable et une sortie définie.

Vous ne savez pas si votre difficulté relève du VPN, de l’authentification ou de votre logiciel métier ? La séance de consulting IT offerte par Novane permet de cadrer les dépendances de votre application et les questions à transmettre à votre équipe informatique, avant de décider d’une évolution ou d’un chantier plus important.