Windows 11 26H2 : la disponibilité complète ne remplace pas la validation du parc
Dans son état de situation du 21 octobre 2026, Microsoft indique que le déploiement de Windows 11 26H2 a atteint la disponibilité complète pour les appareils sous 24H2 et 25H2. Les équipes Workplace doivent réexaminer les appareils en attente et les résultats de leurs anneaux de validation, sans confondre disponibilité de l’offre et compatibilité de chaque poste.
- Impact
- appareils Windows 11 24H2/25H2 du canal général candidats à 26H2 ; pas une consigne de migration des éditions LTSC ou de Windows 11 26H1.
- Action
- contrôler les blocages et le niveau de correctif, puis valider les usages sensibles avant d’élargir le déploiement.
- Statut
- À tester
Ce qui change depuis septembre
La disponibilité générale date du 29 septembre. La nouveauté du 21 octobre est l’état « full availability » affiché dans Release Health, en remplacement de l’annonce d’un déploiement progressif.
Ce statut ne constitue ni une télémétrie de votre parc ni une garantie d’absence d’incidents. Les stratégies de déploiement et les éventuels blocages de compatibilité restent à examiner. Microsoft précise que les safeguard holds concernent les appareils utilisant Windows Update ; leur protection ne doit pas être supposée pour une installation par média ou via WSUS.
Au 22 octobre, le tableau officiel des versions donne KB5127648 du 13 octobre, build 26300.9711, comme dernière cumulative publiée pour 26H2. C’est la référence de mise à jour pour cette validation, pas le minimum nécessaire pour toute installation de 26H2. La build de septembre 26300.9550 n’est plus la référence courante.
Les incidents à intégrer au test
Les statuts ci-dessous concernent la documentation Microsoft consultée le 22 octobre, pas l’état des postes du lecteur.
| Périmètre | État amont | Contrôle utile |
|---|---|---|
| AVD/FSLogix : écran noir après connexion ; applications utilisant le décodage AC-3 Windows | Résolus par KB5127648 ou une mise à jour ultérieure | Après mise à jour et redémarrage, rejouer l’ouverture du profil concerné et la lecture audio affectée. |
| Machine Identity Isolation et relation d’approbation AD | Résolu par KB5124010 ou ultérieure ; l’application de MII est désactivée par le correctif | Vérifier les connexions au domaine ; ne pas réactiver MII pour ce test. |
| RDP vers un hôte avec Administrator protection, depuis un compte non administrateur | Mitigated ; erreur possible 0xC000000D | Tester ce scénario précis et suspendre l’élargissement du groupe concerné en cas d’échec. |
| Périphériques USB Audio Class 1.0 | Mitigated ; certains symptômes restent ouverts | Vérifier démarrage et son avec les modèles réellement utilisés ; contacter le support Microsoft si un contournement immédiat reste nécessaire. |
| Réactivation de Smart App Control après désactivation | La KB documente un contournement, pas un correctif définitif | Si ce scénario fait partie du projet, vérifier que l’option peut être réactivée. Les appareils où la protection est déjà active ne sont pas affectés par ce problème. |
Décider de l’élargissement
Pour un appareil non mis à niveau, rapprocher sa cible de version, ses affectations et ses pauses du statut de déploiement. Si les rapports Windows Update for Business sont utilisés, consulter les safeguard holds et rechercher leur identifiant dans Release Health. Une offre absente ne justifie pas de contourner un blocage : Microsoft recommande d’attendre sa résolution.
Dans Autopatch, conserver une mise à jour de fonctionnalités en plusieurs phases. Le parcours documenté passe par Devices > Windows updates > Feature updates > Create Autopatch multi-phase release. Ne pas inclure les appareils LTSC dans cette procédure : Autopatch ne leur fournit pas les mises à jour de fonctionnalités.
Comparer les résultats avant/après sur les applications métier, la connexion au domaine et les scénarios du tableau présents dans le parc. Vérifier la version et la build remontées après redémarrage, pas seulement l’approbation de la mise à jour. Élargir uniquement les populations dont les usages sont validés ; isoler les écarts et rechercher leur correspondance avec les incidents Microsoft avant de généraliser.