Après Windows 10 : organiser durablement le cycle de vie Windows 11

Résumé

Windows 10 22H2 a atteint sa fin de support général le 14 octobre 2025. ESU peut réduire temporairement le risque de sécurité pour des appareils admissibles, mais ne remplace pas une cible Windows 11 ou un remplacement matériel.

Windows 11 suit un cycle annuel avec des dates différentes selon l’édition. Je gère donc une cible de version explicite, un inventaire d’éligibilité et des anneaux qui valident applications, pilotes et expérience utilisateur.

Ma recommandation est un flux continu : découverte, qualification, correction, pilote, déploiement, surveillance puis traitement des exceptions. Les exceptions possèdent une date de fin et un propriétaire.

Windows 10 22H2 a atteint sa fin de support général le 14 octobre 2025. ESU peut réduire temporairement le risque de sécurité pour des appareils admissibles, mais ne remplace pas une cible Windows 11 ou un remplacement matériel.

Contexte, objectif et périmètre

Un parc peut être techniquement à Windows 11 tout en restant exposé si une version approche sa fin de servicing. Le tableau de bord doit suivre édition, version, build et échéance, pas seulement Windows 11 = oui.

Les appareils Windows 10 restants se répartissent entre compatibles non migrés, bloqués par application/pilote, non conformes matériellement et exceptions réglementées. Chacune exige une décision différente.

Je traite « Cycle de vie Windows 11 après Windows 10 » comme une chaîne de preuves et non comme une succession de boutons à cliquer. Une action n’est considérée comme réussie que lorsque le résultat est visible au niveau attendu : configuration du service, état reçu par le poste, traitement local, puis remontée cohérente dans les outils d’administration. Cette séparation évite de confondre une affectation valide avec une exécution terminée.

Je conserve systématiquement les heures en UTC et en heure locale, l’identité de l’appareil, le contexte utilisateur ou système, la version de Windows et la version des composants concernés. Sans ces repères, deux événements semblables peuvent appartenir à des cycles différents. Les exemples de journaux sont anonymisés et les identifiants techniques doivent l’être avant tout partage.

La configuration recommandée n’est pas une valeur universelle. Elle constitue un point de départ argumenté, à rapprocher des licences, des contraintes réseau, des responsabilités de support et de la maturité opérationnelle. Lorsque plusieurs méthodes existent, je privilégie celle qui réduit les autorités concurrentes et rend le résultat le plus facilement vérifiable.

Le passage en production suit une progression explicite : validation technique isolée, pilote métier, extension contrôlée puis généralisation. Chaque vague dispose de critères GO et NO-GO, d’une durée d’observation et d’un propriétaire capable d’arrêter ou de revenir en arrière sans attendre une décision improvisée.

• Objectif : définir une cible de servicing pérenne
• Objectif : migrer par preuves et vagues
• Objectif : gérer ESU et exceptions sans dette invisible
• Périmètre : Windows 10 22H2 résiduel
• Périmètre : Windows 11 Pro, Enterprise et Education
• Périmètre : Intune/WUfB et co-management

Architecture et fonctionnement général

L’inventaire alimente une matrice de décision par appareil. PC Health Check, télémétrie Intune, compatibilité applicative et exigences métier ne sont pas remplacés par un seul indicateur matériel.

Une policy Feature Update maintient une version cible pendant que les anneaux règlent expérience, qualité et redémarrage. Je sépare l’offre de version de la cadence des correctifs mensuels.

Le lifecycle devient un service récurrent. Les dates Microsoft sont revalidées périodiquement ; une nouvelle version passe par le même processus pilote avant d’être la cible générale.

Prérequis techniques et préparation

Avant toute mise en œuvre, je fige le périmètre de test et je capture l’état initial. Cette photographie comprend les versions, les affectations, les autorités de gestion, les dépendances et les exceptions connues. Elle sert autant à interpréter le résultat qu’à construire le retour arrière.

Je vérifie les prérequis sur un appareil réellement représentatif. Une console qui autorise la création d’un profil ne prouve ni l’éligibilité du poste, ni la disponibilité effective de la fonctionnalité dans le tenant. Les prérequis réseau, licence, identité et système doivent tous être confirmés.

• inventaire version/édition fiable
• éligibilité TPM 2.0, UEFI, Secure Boot, CPU et stockage
• catalogue applicatif avec propriétaires
• source de mise à jour connue
• télémétrie WUfB/Autopatch
• processus ESU si utilisé
• sauvegarde et rollback validés

Procédure de mise en œuvre

La procédure suivante est volontairement découpée en points de contrôle. Je ne poursuis pas lorsqu’un résultat attendu manque : continuer masquerait la première divergence et produirait des symptômes secondaires plus difficiles à interpréter.

Les noms de groupes, profils, applications et fichiers sont des exemples. Je les remplace par les conventions de l’organisation, je documente la population ciblée et je conserve une preuve avant/après pour chaque changement.

Éligibilité matérielle et compatibilité réelle

TPM, Secure Boot et CPU sont nécessaires, mais la réussite dépend aussi du firmware, des pilotes, du stockage et du chiffrement. Je mets à jour BIOS et pilotes sur un pilote avant la feature update lorsque le constructeur le recommande.

La compatibilité applicative se mesure sur les processus métier et périphériques, pas sur une liste d’exécutables. Je documente propriétaire, scénario de test, résultat et solution de repli.

Un safeguard hold est un signal à respecter. Le contourner demande une analyse explicite du problème connu et une approbation ; l’objectif de date ne suffit pas à rendre le risque acceptable.

Choix de version et anneaux

Enterprise/Education disposent généralement d’une durée de support plus longue que Home/Pro pour certaines versions. Je n’utilise jamais une date générique sans vérifier édition et version exactes.

L’anneau validation reçoit tôt la cible et couvre les modèles et applications critiques. Le pilote métier ajoute les vrais usages. La production s’étend par vagues avec seuils d’arrêt sur échecs, rollback et incidents.

La cible de version évite qu’un poste passe involontairement à une version non validée. Elle est révisée avant sa propre fin de servicing pour empêcher un nouveau projet d’urgence.

ESU, remplacement et exceptions

ESU fournit des mises à jour de sécurité éligibles pour prolonger temporairement certains Windows 10. Il n’ajoute pas les nouvelles fonctions, ne corrige pas la compatibilité matérielle et ne doit pas devenir un état permanent.

Pour un appareil non compatible, je compare remplacement, virtualisation d’application, Windows 365/Azure Virtual Desktop ou retrait du besoin. Chaque solution possède coût, expérience et contraintes réseau.

Les critères NO-GO incluent sauvegarde non testée, application critique sans propriétaire, source WSUS contradictoire, safeguard inexpliqué et capacité support insuffisante. Le calendrier est ajusté plutôt que de masquer ces risques.

Scripts, commandes et exemples de lecture

Les commandes présentées servent à observer ou illustrer le fonctionnement. Les scripts de diagnostic restent de niveau 1, avec arrêt sur erreur et gestion globale de l’exception. Ils ne modifient pas le poste. Une remédiation serait au minimum de niveau 2, avec mode de simulation, journalisation adaptée au test et comportement de rollback explicitement validé.

Je lis toujours la sortie avec le contexte d’exécution. Une commande lancée dans la session de l’utilisateur ne voit pas nécessairement les mêmes certificats, chemins, variables, applications ou ruches de registre qu’un processus exécuté par l’Intune Management Extension sous SYSTEM.

# Exemple pédagogique non testé — niveau 1
$ErrorActionPreference = 'Stop'
try {
  $os = Get-CimInstance Win32_OperatingSystem
  $bios = Get-CimInstance Win32_BIOS
  $tpm = Get-Tpm
  [pscustomobject]@{ Caption=$os.Caption; Version=$os.Version; Build=$os.BuildNumber; Bios=$bios.SMBIOSBIOSVersion; TpmPresent=$tpm.TpmPresent; TpmReady=$tpm.TpmReady; FreeSystemGB=[math]::Round((Get-PSDrive C).Free/1GB,1) }
}
catch { Write-Error "Inventaire Windows impossible : $($_.Exception.Message)"; exit 1 }

Validation et critères de contrôle

Je valide d’abord le résultat technique sur le poste, puis sa remontée dans le service. Le portail peut conserver un état ancien pendant un certain temps ; inversement, un état vert dans la console ne dispense pas de contrôler l’artefact local réellement attendu.

Le critère GO exige un résultat reproductible, une absence de régression sur les fonctions voisines, une documentation à jour et un retour arrière démontré. Le critère NO-GO s’applique dès qu’une dépendance n’est pas maîtrisée, qu’une partie du parc réagit différemment ou que l’état final ne peut pas être prouvé.

• 100 % appareils avec trajectoire
• version cible supportée
• pilote représentatif
• taux de réussite conforme
• applications critiques validées
• rollback testé
• exceptions datées

Journaux, diagnostic et constitution des preuves

Je surveille offre, téléchargement, installation, rollback, safeguard et redémarrage. WindowsUpdateClient/Operational, SetupDiag et les rapports feature update sont corrélés.

Le registre Update aide à identifier la policy, mais n’établit pas seul l’autorité. En co-management, je vérifie workload, WSUS, scan source et stratégies historiques.

• édition/version/build
• date de fin de support
• éligibilité matérielle
• applications bloquantes
• source de scan
• safeguard hold
• résultat SetupDiag
• capacité de rollback

Dépannage : symptômes, preuves et corrections

Je pars de la colonne Symptôme, mais je ne choisis jamais une correction sur ce seul indice. La colonne Preuve indique l’élément qui doit confirmer la cause. Si cette preuve manque, l’hypothèse reste ouverte et l’action proposée ne doit pas être appliquée comme une recette automatique.

Après correction, je reproduis le scénario initial et je compare les mêmes points de mesure. Un changement de symptôme n’est pas toujours une résolution : il peut simplement indiquer que le traitement progresse jusqu’à une nouvelle phase. La chronologie complète reste donc la référence.

Retour arrière et points de vigilance

Le retour arrière ne consiste pas seulement à retirer une affectation. Je restaure l’autorité précédente, la configuration ou la version attendue, puis je vérifie que le poste a effectivement reçu et appliqué ce nouvel état. Les caches et délais de remontée sont documentés au lieu d’être interprétés comme une absence de rollback.

Je conserve les preuves du pilote, le motif de la décision et les écarts rencontrés. Si le service cloud ou une interface évolue, je réévalue les étapes avant une nouvelle vague. Aucun succès obtenu uniquement sur le poste de développement ne constitue une validation de production.

• Rollback : pause de la vague
• Rollback : restauration de la cible précédente si supportée
• Rollback : désinstallation feature update dans la fenêtre documentée
• Rollback : réimage/sauvegarde pour cas hors fenêtre
• Vigilance : dates variables par édition
• Vigilance : ESU est temporaire
• Vigilance : ne pas contourner safeguard sans preuve
• Vigilance : test local non représentatif du parc