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

Position recommandée

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.

Besoin, cas d’usage et périmètre de la recommandation

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.

Critères de décision et options possibles

Pour Cycle de vie Windows 11 après Windows 10, je commence par trois résultats concrets: définir une cible de servicing pérenne, migrer par preuves et vagues et gérer ESU et exceptions sans dette invisible. Ils doivent être observables avant de comparer les méthodes disponibles.

L’architecture cible suit Inventory → Decision → Rings → Lifecycle. Chaque composant a un propriétaire clair, un état vérifiable et une méthode de retour arrière; cette répartition évite qu’une seconde politique masque le résultat de la première.

Le pilote contrôle notamment 100 % appareils avec trajectoire, version cible supportée et pilote représentatif. La généralisation ne commence qu’après une période stable et après vérification des exceptions propres aux populations visées.

La recommandation devient mesurable lorsqu’elle relie le besoin à une cible vérifiable. Les résultats attendus sont définir une cible de servicing pérenne, migrer par preuves et vagues et gérer ESU et exceptions sans dette invisible. Les responsabilités se répartissent ainsi: Inventory: Matériel, édition, version, applications et propriétaires. Decision: Upgrade, replace, ESU ou exception bornée. Rings: Validation, early adopters, production et critique. Lifecycle: Conformité de version et amélioration continue. Cette répartition permet d’attribuer chaque écart au bon propriétaire et d’éviter qu’un second profil, une ancienne autorité ou une exception silencieuse ne produise un résultat apparemment correct mais impossible à exploiter dans la durée.

Les écarts « Feature update non offerte », « Scan vers WSUS », « Rollback automatique » et « Parc Windows 10 stagne » servent de tests de décision. Pour chacun, la preuve indiquée dans la matrice doit permettre de choisir entre correction, exception temporaire et retour arrière. Le pilote surveille également les points suivants: dates variables par édition, ESU est temporaire, ne pas contourner safeguard sans preuve et test local non représentatif du parc. La valeur cible, le mode de distribution, les contrôles et la sortie de secours sont ainsi évalués ensemble.

Architecture cible et répartition des responsabilités

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, gouvernance et préparation

La préparation de Cycle de vie Windows 11 après Windows 10 couvre 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. Le propriétaire de chaque composant et la population pilote sont définis avant la création de la configuration.

L’état initial est mesuré avec édition/version/build, date de fin de support, éligibilité matérielle, applications bloquantes. Il servira de point de comparaison pendant le pilote et lors d’un éventuel retour arrière.

• 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

É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.

Configuration recommandée et déploiement par étapes

La méthode retenue pour Cycle de vie Windows 11 après Windows 10 se déploie par les étapes « Segmenter le parc », « Choisir la version cible », « Piloter par anneaux », « Fermer les exceptions ». Chaque passage produit un résultat vérifiable avant l’ouverture du suivant.

Paramètres, commandes et automatisation

Les commandes et valeurs de cette section servent à vérifier édition/version/build, date de fin de support, éligibilité matérielle, applications bloquantes. Chaque exemple précise l’état attendu et les éléments à comparer dans le service.

Le contexte d’exécution, les permissions et les effets sur Inventory, Decision, Rings, Lifecycle doivent rester explicites lorsque la configuration est automatisée.

# Collecte de diagnostic
$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, indicateurs et critères GO / NO-GO

La décision repose sur 100 % appareils avec trajectoire, version cible supportée, pilote représentatif et taux de réussite conforme. Ces indicateurs couvrent le résultat technique, l’état du service et l’effet réel sur la population pilote.

• 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

Exploitation, journaux et contrôle continu

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

Exceptions, erreurs connues et traitement

Les exceptions à prévoir pour Cycle de vie Windows 11 après Windows 10 apparaissent notamment sous la forme Feature update non offerte, Scan vers WSUS, Rollback automatique, Parc Windows 10 stagne. La preuve associée indique s’il faut corriger la configuration ou conserver une exception documentée.

Coût de maintien des exceptions

Une exception à Cycle de vie Windows 11 après Windows 10 crée une charge récurrente: elle doit être identifiée, surveillée et réévaluée jusqu’à sa suppression. Sans propriétaire ni date de revue, cette charge finit par devenir une configuration parallèle difficile à tester.

Rollback, gestion du changement et points de vigilance

Le rollback de Cycle de vie Windows 11 après Windows 10 restaure explicitement l’affectation, la valeur ou l’autorité précédente. Les actions et points de vigilance ci-dessous précisent ce qui doit être contrôlé après ce retour.