Préparation à la fin de vie de Windows 10 : que faire avant de paniquer

Ce que signifie réellement la fin de vie de Windows 10 (et ce que ça ne change pas)

La fin de vie (EOL) de Windows 10 signifie que Microsoft cesse de fournir les mises à jour de sécurité, les corrections de bugs et le support général pour cette version du système. Vos machines continuent de démarrer. Vos applications se lancent toujours. Votre imprimante continue d’imprimer… jusqu’à ce que ce ne soit plus le cas. Mais d’un point de vue opérationnel et risque, l’EOL fait basculer votre posture de sécurité de « risque géré » à « dette qui s’accumule ».

Ce qui change dès le premier jour

• La cadence des correctifs de sécurité s’arrête. Les vulnérabilités découvertes après l’EOL resteront non corrigées sur Windows 10.
• La conformité évolue. De nombreux cadres et audits considèrent un système d’exploitation non supporté comme une violation de politique.
• Le support des éditeurs devient glissant. Les fournisseurs de logiciels tiers commencent à répondre « reproduisez sur un OS supporté ».
• La réponse aux incidents se complique. Vous passerez plus de temps à compenser (contrôles, isolation) et moins à réparer (patchs).

Ce qui ne change pas magiquement

• Vos postes ne cessent pas de fonctionner. L’OS ne se suicide pas.
• Votre réseau ne devient pas instantanément dangereux. Mais votre marge d’erreur s’effondre.
• Vous n’êtes pas obligé de passer immédiatement à Windows 11 partout. Certaines machines seront remplacées, d’autres ré‑imaginées, certaines déplacées vers VDI, d’autres mises hors service.

Traitez cela comme une migration en production, pas comme un rafraîchissement de postes. Le travail technique est simple. Les modes de défaillance sont humains : hypothèses, inventaires incomplets et « on testera après le déploiement ».

Une idée paraphrasée de Gene Kim (auteur sur la fiabilité/DevOps) : Des changements petits et contrôlés réduisent le risque ; des déploiements massifs créent du drame.

Faits rapides et contexte historique (pour ne pas répéter l’histoire)

Un peu d’histoire aide, car les migrations de postes sont le lieu où les organisations redécouvrent les mêmes coins tranchants chaque décennie.

1. Windows 10 a été lancé en 2015 avec le message « Windows as a service », normalisant des mises à jour fréquentes plutôt que des intervalles de plusieurs années.
2. La fin de vie de Windows 7 (2020) a déclenché une longue traîne de mises à jour de sécurité payantes (ESU) dans de nombreuses entreprises—parce que les inventaires étaient erronés et que les propriétaires d’apps étaient optimistes.
3. La longue après‑vie de Windows XP a enseigné une leçon simple aux attaquants : un OS non supporté est une cible de choix car les écarts de patch sont permanents.
4. UEFI et Secure Boot sont devenus courants durant l’ère Windows 8/10 ; le matériel ancien et les modes de démarrage legacy compliquent encore les mises à niveau sur place.
5. L’adoption de TPM 2.0 s’est accélérée alors que le chiffrement de disque et la protection des identifiants sont devenus des attentes par défaut, pas un « bonus ».
6. BitLocker est passé de niche à normal dans les entreprises, ce qui est excellent jusqu’à ce que vous découvriez que la moitié des clés de récupération ne sont pas sauvegardées.
7. Les modèles de pilotes ont évolué (graphismes, stockage, Wi‑Fi). Une pile de pilotes « qui marche sur 10 » peut se comporter différemment avec les valeurs par défaut de sécurité de 11.
8. Les calendriers de support des navigateurs et d’Office poussent souvent les mises à niveau d’OS indirectement ; vous pouvez être « bon » sur Windows 10 jusqu’à ce qu’une application centrale abandonne le support.

Blague #1 : Les migrations de postes ressemblent au régime—vous pouvez y aller progressivement, ou commencer lundi pour trois mois.

Les décisions à prendre tôt (ou votre projet les prendra pour vous)

1) Mettre à niveau, remplacer ou isoler ?

Chaque appareil Windows 10 finit dans une des trois catégories :

• Mise à niveau vers Windows 11 (si le matériel et les applications le permettent).
• Remplacement du matériel (fréquent pour les appareils sans TPM 2.0, avec de mauvaises performances ou proches de la fin de garantie).
• Isolation et confinement (pour équipements spécialisés, systèmes de labo, kiosques ou « la machine qui gère l’usine » où le remplacement n’est pas immédiat).

Le troisième seau est la zone dangereuse. Si vous devez garder un OS non supporté, compensez par la segmentation réseau, l’autorisation d’applications, interdiction d’e‑mail/navigateur, droits administrateurs restreints et surveillance agressive. Vous ne « le laissez pas sur le LAN d’entreprise en espérant ».

2) Mise à niveau sur place ou réimage complet ?

Les mises à niveau sur place sont plus rapides et moins perturbantes—jusqu’à ce qu’elles ne le soient pas. Le wipe‑and‑load (réimage) est plus prévisible et plus facile à soutenir sur le long terme, surtout si vous avez déjà une gestion moderne (Intune, Configuration Manager, flux type autopilot).

Mon biais : si l’appareil accumule des installations « créatives » depuis des années, faites un wipe‑and‑load. S’il s’agit d’un endpoint propre et géré avec des applications standardisées, la mise à niveau sur place convient.

3) Propriété : qui signe la compatibilité des applications ?

Imposer une règle inconfortable : chaque application critique pour l’activité a un responsable qui signe un résultat de test. Si personne ne la possède, elle n’est pas critique ; c’est du folklore avec une clé de licence.

4) Quelle est votre histoire de rollback ?

« Rollback » signifie l’un des éléments suivants :

• restauration depuis une image disque complète (rare mais parfois nécessaire),
• réimage vers l’ancien OS (généralement sans intérêt proche de l’EOL),
• échange d’appareil (meilleur),
• VDI ou application distante comme solution pont.

Si votre rollback est « on dépannera en direct sur l’ordinateur du CEO », vous n’avez pas de rollback. Vous avez du spectacle.

Mode d’emploi diagnostic rapide : trouver le goulot en 30 minutes

Quand la préparation à l’EOL de Windows 10 déraille, c’est généralement parce qu’une contrainte domine et que tout le reste devient du bruit. Voici comment la trouver rapidement.

Premier point : éligibilité matérielle et récupération du chiffrement

• L’appareil peut‑il exécuter Windows 11 ? TPM 2.0, Secure Boot, CPU supporté, RAM/stockage suffisants.
• Avez‑vous les clés de récupération BitLocker ? Sans elles, les mises à niveau et changements de firmware deviennent une roulette russe.

Deuxième point : compatibilité des applications et des pilotes

• Quelles applications sont non négociables ? Listez‑les. Testez‑les. Ne discutez pas.
• Des pilotes noyau ? Clients VPN, agents de sécurité, chiffrement de stockage, redirection USB—ce sont souvent là que les mises à niveau échouent.

Troisième point : plomberie de gestion et de mises à jour

• Les appareils peuvent‑ils recevoir politiques et mises à jour ? Si votre plomberie MDM/WSUS/SCCM est instable, les migrations l’amplifieront.
• Avez‑vous assez de bande passante et de cache ? Les mises à jour de fonctionnalité sont volumineuses. Votre WAN n’est pas sans limite.

Quatrième point : identité et contrôles d’accès

• Grosse répartition des admins locaux ? Cela vous mordra lors des réinstallations d’apps et des dépannages.
• Accès conditionnel basé sur la conformité des appareils ? Si vous appliquez la conformité, votre bascule peut verrouiller les utilisateurs si les politiques ne sont pas progressives.

L’astuce est l’ordonnancement : on ne commence pas par « poussons Windows 11 ». On commence par « sait‑on ce qu’on a, peut‑on le mettre à niveau et peut‑on le récupérer s’il plante ? »

Tâches pratiques avec commandes : preuves, sorties et décisions

Voici des vérifications pratiques que vous pouvez exécuter depuis une machine d’administration Linux ayant accès réseau à votre parc Windows (WinRM activé si nécessaire), à vos serveurs de gestion et à vos services d’annuaire. Les commandes sont volontairement ennuyeuses. L’ennui, c’est bien. L’ennui, c’est ce qui vous fait dormir.

Tâche 1 : Compter les endpoints Windows 10 que vous pouvez réellement voir (requête AD)

cr0x@server:~$ ldapsearch -x -LLL -H ldap://ad01.corp.local -b "DC=corp,DC=local" "(operatingSystem=Windows 10*)" dn operatingSystem | grep -c "^dn:"
342

Ce que cela signifie : Vous avez 342 objets ordinateur déclarant Windows 10 dans les attributs AD.

Décision : Traitez ceci comme un plancher. Comparez avec les comptes de gestion d’endpoints ; les écarts signifient des objets AD obsolètes, des appareils non gérés, ou les deux.

Tâche 2 : Trouver les objets ordinateur Windows obsolètes (ils « existent » mais ne sont pas réels)

cr0x@server:~$ ldapsearch -x -LLL -H ldap://ad01.corp.local -b "DC=corp,DC=local" "(&(objectClass=computer)(lastLogonTimestamp<=20240101000000.0Z))" dn lastLogonTimestamp | grep -c "^dn:"
58

Ce que cela signifie : 58 comptes ordinateurs ne se sont pas connectés depuis la date donnée (dépend de votre cutoff).

Décision : Ne perdez pas d’effort de migration sur des fantômes. Validez avec les propriétaires ; puis désactivez ou nettoyez les comptes pour réduire le bruit et le risque.

Tâche 3 : Extraire la liste d’appareils depuis votre source de vérité de gestion (exemple : SCCM/ConfigMgr SQL)

cr0x@server:~$ sqlcmd -S sccm-sql01.corp.local -d CM_PRI -Q "select count(*) as win10 from v_R_System where Operating_System_Name_and0 like '%Workstation 10%';"
win10
-----------
401

Ce que cela signifie : SCCM pense que vous avez 401 postes Windows 10.

Décision : AD dit 342, SCCM dit 401. Vous avez un décalage d’inventaire. Corrigez‑le d’abord : sinon vos métriques de déploiement seront faussées.

Tâche 4 : Vérifier la reachabilité WinRM sur un échantillon (prêt à distance)

cr0x@server:~$ for h in pc-001 pc-002 pc-003; do echo "== $h =="; timeout 3 bash -c "echo | nc -vz $h 5985"; done
== pc-001 ==
Connection to pc-001 5985 port [tcp/*] succeeded!
== pc-002 ==
nc: connect to pc-002 port 5985 (tcp) timed out: Operation now in progress
== pc-003 ==
Connection to pc-003 5985 port [tcp/*] succeeded!

Ce que cela signifie : pc-002 n’est pas joignable sur WinRM HTTP (5985). Peut être hors ligne, bloqué, ou non configuré.

Décision : Si votre plan dépend des requêtes à distance ou des mises à niveau à distance, vous avez besoin d’une baseline de reachabilité. Pour les machines injoignables, planifiez une intervention physique ou corrigez réseau/politiques.

Tâche 5 : Interroger la version/build de Windows à distance (WinRM + PowerShell)

cr0x@server:~$ evil-winrm -i pc-001.corp.local -u CORP\\svc_audit -p 'REDACTED' -s . -c "powershell -NoProfile -Command \"(Get-ComputerInfo).WindowsVersion; (Get-ComputerInfo).OsBuildNumber\""
10.0.19045
19045

Ce que cela signifie : Windows 10 22H2 build 19045 (typique d’un Windows 10 récent).

Décision : Les appareils non à jour sur la dernière mise à jour de fonctionnalité Windows 10 doivent être considérés à risque plus élevé et plus difficiles à mettre à niveau ; mettez‑les à jour avant les mouvements majeurs.

Tâche 6 : Vérifier la présence et la version du TPM (critère Windows 11)

cr0x@server:~$ evil-winrm -i pc-001.corp.local -u CORP\\svc_audit -p 'REDACTED' -c "powershell -NoProfile -Command \"Get-Tpm | Select TpmPresent,TpmReady,ManagedAuthLevel\""
TpmPresent TpmReady ManagedAuthLevel
---------- -------- ---------------
      True     True            Full

Ce que cela signifie : Le TPM est présent et prêt.

Décision : Cette machine franchit probablement l’un des principaux prérequis de Windows 11. Si vous voyez False, prévoyez remplacement ou traitement d’exception (pas « on verra plus tard »).

Tâche 7 : Vérifier l’état de Secure Boot (autre prérequis Windows 11)

cr0x@server:~$ evil-winrm -i pc-001.corp.local -u CORP\\svc_audit -p 'REDACTED' -c "powershell -NoProfile -Command \"Confirm-SecureBootUEFI\""
True

Ce que cela signifie : Secure Boot est activé.

Décision : Si False (ou si la cmdlet renvoie une erreur due au BIOS legacy), vous devrez prévoir un plan de remédiation firmware/boot. Ce n’est pas un correctif one‑click à grande échelle.

Tâche 8 : Vérifier l’espace libre sur le disque système (les mises à jour échouent quand le stockage est serré)

cr0x@server:~$ evil-winrm -i pc-001.corp.local -u CORP\\svc_audit -p 'REDACTED' -c "powershell -NoProfile -Command \"Get-PSDrive -Name C | Select Used,Free\""
Used         Free
----         ----
178234961920 21464350720

Ce que cela signifie : ~20 Go libres sur C:. C’est limite selon la méthode d’upgrade et le staging.

Décision : Fixez une politique d’espace libre minimum (j’aime 30–40 Go pour la sécurité). En dessous : nettoyage, déplacement de caches ou planification d’un wipe‑and‑load.

Tâche 9 : Vérifier l’état de BitLocker et les types de protecteurs de clé (plan de récupération)

cr0x@server:~$ evil-winrm -i pc-001.corp.local -u CORP\\svc_audit -p 'REDACTED' -c "powershell -NoProfile -Command \"manage-bde -status C:\""
BitLocker Drive Encryption: Configuration Tool version 10.0.19041
Volume C: [OSDisk]
    Size:                 237.87 GB
    BitLocker Version:    2.0
    Conversion Status:    Fully Encrypted
    Percentage Encrypted: 100.0%
    Protection Status:    Protection On
    Lock Status:          Unlocked
    Identification Field: None
    Key Protectors:
        TPM
        Numerical Password

Ce que cela signifie : Le disque est chiffré et protégé. Les protecteurs incluent TPM et un mot de passe de récupération numérique.

Décision : Confirmez que le mot de passe de récupération est bien escroqué dans AD/Azure AD. Sinon, stoppez et corrigez l’escrow avant les changements firmware/OS.

Tâche 10 : Vérifier les indicateurs de redémarrage en attente (ils sabotent les mises à niveau et installations d’agents)

cr0x@server:~$ evil-winrm -i pc-001.corp.local -u CORP\\svc_audit -p 'REDACTED' -c "powershell -NoProfile -Command \"Test-Path 'HKLM:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\WindowsUpdate\\Auto Update\\RebootRequired'\""
False

Ce que cela signifie : Aucun drapeau de redémarrage Windows Update détecté via cette clé (pas exhaustif, mais utile).

Décision : Si True, planifiez un redémarrage avant d’essayer une mise à niveau de fonctionnalité ou un changement majeur d’agent.

Tâche 11 : Identifier les agents de sécurité/EDR installés (les conflits au niveau pilote sont courants)

cr0x@server:~$ evil-winrm -i pc-001.corp.local -u CORP\\svc_audit -p 'REDACTED' -c "powershell -NoProfile -Command \"Get-ItemProperty 'HKLM:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\*' | Select DisplayName,DisplayVersion | Sort DisplayName | Select -First 10\""
DisplayName                         DisplayVersion
-----------                         --------------
7-Zip 22.01 (x64 edition)           22.01
Contoso Endpoint Protection Agent    5.4.1
Microsoft OneDrive                   24.005.0113.0002
Microsoft Teams                      1.7.00.3653
Microsoft Visual C++ 2015-2022 ...   14.38.33135

Ce que cela signifie : On voit un agent de protection endpoint installé, plus des logiciels courants.

Décision : Construisez une matrice de compatibilité pour les agents de sécurité et clients VPN. Si votre fournisseur d’agent exige une version plus récente, mettez l’agent à jour avant le changement d’OS.

Tâche 12 : Vérifier la source des mises à jour Windows (WSUS vs Microsoft Update vs conflit de politique)

cr0x@server:~$ evil-winrm -i pc-001.corp.local -u CORP\\svc_audit -p 'REDACTED' -c "powershell -NoProfile -Command \"reg query HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate /v WUServer\""
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
    WUServer    REG_SZ    http://wsus01.corp.local:8530

Ce que cela signifie : Ce poste est pointé vers WSUS.

Décision : Assurez‑vous que WSUS (ou votre plateforme de mise à jour) peut fournir le contenu de mise à niveau prévu. Sinon, votre déploiement calera sur du « vérification des mises à jour » sans fin.

Tâche 13 : Mesurer le risque de goulot LAN/WAN (les mises à jour de fonctionnalité sont gourmandes)

cr0x@server:~$ iperf3 -c branch-fw01.corp.local -p 5201 -t 5
Connecting to host branch-fw01.corp.local, port 5201
[  5] local 10.10.10.50 port 55762 connected to 10.20.30.1 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-5.00   sec  34.8 MBytes  58.4 Mbits/sec                  sender
[  5]   0.00-5.00   sec  34.1 MBytes  57.2 Mbits/sec                  receiver

Ce que cela signifie : Environ 57 Mbps entre l’hôte test et le firewall de la succursale.

Décision : Si des dizaines d’appareils téléchargent des mises à jour de plusieurs Go via ce lien, vous avez besoin de cache (Delivery Optimization, points de distribution locaux) ou d’un calendrier étagé.

Tâche 14 : Vérifier la capacité de partage de fichiers pour le staging de profils/données

cr0x@server:~$ df -h /srv/migration-staging
Filesystem                 Size  Used Avail Use% Mounted on
/dev/mapper/vg0-staging    3.0T  2.5T  420G  86% /srv/migration-staging

Ce que cela signifie : Votre volume de staging est à 86% d’utilisation, avec ~420 Go libres.

Décision : Si vous vous apprêtez à stager des profils ou des données hors ligne, vous flirtiez avec la corruption due disque plein et des transferts échoués. Agrandissez le stockage ou purge avant le déploiement.

Tâche 15 : Valider que les sauvegardes ne sont pas imaginaires (test de restauration échantillon)

cr0x@server:~$ restic -r /backups/endpoints snapshots --last
repository 2b1c2b55 opened (version 2, compression level auto)
ID        Time                 Host     Tags        Paths
9f1a8e3c  2026-02-03 23:10:12  pc-001   win10        C:\Users

Ce que cela signifie : Vous avez au moins un snapshot récent pour les données utilisateur de pc-001.

Décision : Faites un test de restauration sur un petit sous‑ensemble. Si vous ne pouvez pas restaurer rapidement, votre sauvegarde est une pièce de musée, pas un système de sécurité.

Tâche 16 : Vérifier l’expiration des certificats pour l’auth Wi‑Fi/VPN (les pannes ressemblent à « Windows 11 est cassé »)

cr0x@server:~$ openssl s_client -connect vpn01.corp.local:443 -servername vpn01.corp.local /dev/null | openssl x509 -noout -dates -subject
notBefore=Jan 10 00:00:00 2026 GMT
notAfter=Apr 10 23:59:59 2026 GMT
subject=CN=vpn01.corp.local

Ce que cela signifie : Le certificat VPN expire en avril 2026.

Décision : Si le certificat approche de l’expiration, renouvelez‑le avant que votre vague de migration ne l’atteigne. Sinon vous « déboguerez Windows 11 » alors que le vrai coupable est la négligence PKI.

Voilà plus d’une douzaine de tâches. Utilisez‑les comme sondes. Les résultats vous indiquent où se trouve le vrai travail : remplacement matériel, plomberie de politiques, bande passante ou propriétaires d’applications.

Trois mini‑histoires d’entreprise issues des tranchées de la migration

Mini‑histoire n°1 : L’incident causé par une fausse hypothèse

Une entreprise de taille moyenne a conduit un pilote de mise à niveau vers Windows 11 avec une douzaine d’ordinateurs portables IT. Propre. Lisse. Ils l’ont considéré « validé », parce que les portables avaient tous TPM 2.0, des CPU modernes et la même image de base. Ils ont ensuite planifié une mise à niveau en place pour le service finance, car « ce sont aussi majoritairement des portables ».

Finance avait un mix : portables récents, anciens postes fixes et quelques machines « temporaires » qui étaient temporaires depuis les trois dernières réorganisations. Certains postes fixes tournaient en mode BIOS legacy, avec Secure Boot désactivé, et un modèle avait un TPM physiquement présent mais désactivé dans le firmware. Personne n’avait vérifié car le pilote utilisait des machines brillantes.

L’outil de mise à niveau a refusé certains appareils immédiatement. D’autres ont échoué en cours de mise à niveau et sont revenus en arrière. L’incident réel est survenu plus tard : un sous‑ensemble de machines a démarré en mode récupération BitLocker après des changements firmware tentés pendant la remédiation. Le helpdesk n’avait pas les clés de récupération pour un groupe, car l’escrow des clés n’avait jamais été appliqué de façon cohérente.

La panne n’était pas « Windows 11 ». C’était une défaillance de processus : un pilote qui ne représentait pas le parc, et une hypothèse que la récupération du chiffrement était « gérée quelque part ». Il a fallu deux jours pour toucher physiquement les machines, prouver la propriété et réimager les pires cas. Finance a manqué une date de clôture. La migration a été mise en pause un mois.

La correction a été ennuyeuse : rapport de préparation matérielle par modèle, contrôles forcés d’escrow des clés BitLocker et règle que les pilotes doivent inclure le pire matériel encore en service—pas le meilleur.

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

Une autre organisation voulait « économiser le WAN » lors d’un déploiement sur sites distants. Leur idée : précharger la mise à jour de fonctionnalité Windows 11 sur un partage de fichiers centralisé dans le datacenter, puis laisser les postes la récupérer via SMB la nuit. Une copie sur le serveur, beaucoup de clients—quoi de mal ?

Ça fonctionnait en labo. En production, des centaines de postes dans plusieurs succursales ont commencé à copier des fichiers multi‑Go depuis le même partage. Le trafic SMB a explosé. Les liens WAN se sont saturés. Les applications interactives ont laggé. La VoIP est devenue hachée. Ensuite, comme les utilisateurs se sont énervés et ont redémarré ou fermé leurs portables, beaucoup de transferts ont été interrompus et relancés, amplifiant la consommation de bande passante.

Le stockage a aussi pris des dégâts. Le cache du serveur de fichiers a tourné à plein régime sous une lecture massive. La latence a augmenté. D’autres workloads sur le même datastore VM ont subi une hausse de l’I/O wait. Personne n’aime apprendre que « lecture seule » peut être destructive si elle n’est pas façonnée.

Ils ont fait marche arrière et ont appliqué ce qu’ils auraient dû faire d’abord : distribution de contenu appropriée (points de distribution locaux, Delivery Optimization peer caching ou livraison cloud étagée) et ordonnancement throttle par site. L’« optimisation » n’était que déplacer le goulot vers un endroit plus difficile à voir.

Mini‑histoire n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une grande entreprise avait la réputation d’évoluer lentement. On se moquait d’eux. Leur équipe endpoints a insisté sur une « porte d’entrée de préparation » avant toute migration d’OS : chaque appareil devait signaler (a) éligibilité matérielle, (b) escrow des clés de chiffrement, (c) dernier check‑in et (d) appartenance au lot d’apps critiques. Si un appareil ne passait pas, il n’obtenait pas la politique de mise à niveau.

Cette porte était appliquée automatiquement via leur plateforme de gestion des appareils. Les exceptions étaient possibles, mais nécessitaient un propriétaire d’app et une validation sécurité. Les gens se plaignaient que c’était bureaucratique. Mais la porte produisait quelque chose de rare : des déploiements prévisibles. Leurs métriques semblaient moins excitantes, ce qui en exploitation est souvent un compliment.

Pendant la vague principale, un fournisseur a livré un client VPN mis à jour qui cassait le split tunneling sur la nouvelle build OS. Parce que l’entreprise avait des anneaux étagés—IT d’abord, puis quelques départements, puis le reste—ils ont vu le problème tôt, ont mis la prochaine vague en pause et ont déployé une version corrigée du client. Pas de panne générale, pas de « tout le monde ne peut pas se connecter lundi matin ».

Le meilleur : ils n’ont pas eu à être des héros. Leur processus empêchait de faire la mauvaise chose rapidement. C’est le type de contrôles que vous voulez en production.

Blague #2 : La seule chose plus effrayante qu’un OS non supporté, c’est de découvrir que c’est la machine qui fabrique les étiquettes pour votre OS supporté.

Erreurs courantes : symptômes → cause profonde → correction

1) « La politique de mise à niveau est appliquée, mais rien ne se passe »

Syndromes : Les appareils montrent qu’ils sont ciblés ; les utilisateurs ne voient pas d’invite ; les logs montrent des « checking for updates » répétés.

Cause profonde : Mauvaise configuration de la source de mises à jour (WSUS manque produits/classifications, dual scan bloqué ou conflits de politiques).

Correction : Vérifiez les clés de registre de source de mise à jour et les politiques de gestion ; assurez‑vous que votre plateforme peut fournir les mises à jour de fonctionnalité ; testez sur un appareil avec connectivité connue bonne.

2) « La mise à niveau échoue entre 30–70% puis revient en arrière »

Syndromes : La mise à niveau sur place redémarre, progresse puis revient à Windows 10.

Cause profonde : Incompatibilité pilote ou agent de sécurité ; parfois espace disque ou magasin de composants corrompu.

Correction : Identifiez et mettez à jour/supprimez les pilotes/agents problématiques ; assurez suffisamment d’espace disque ; exécutez des vérifications de santé des composants avant de réessayer. Envisagez le wipe‑and‑load pour les cas chroniques.

3) « Écran de récupération BitLocker après changements BIOS/UEFI »

Syndromes : Les utilisateurs redémarrent et voient l’invite de clé de récupération ; le helpdesk ne trouve pas la clé.

Cause profonde : Clés de récupération non escroquées ; changement firmware modifiant les mesures TPM.

Correction : Appliquez la politique d’escrow, audit de présence de clés, et formez les techniciens : suspendez BitLocker avant les mises à jour firmware et reprenez‑le ensuite.

4) « Le VPN fonctionne sur Windows 10, échoue sur les appareils mis à niveau »

Syndromes : Boucles d’auth, absence de routes, problèmes de split tunnel, ou le client ne démarre pas.

Cause profonde : Incompatibilité du pilote VPN, chaînes de certificats, ou durcissement des valeurs de sécurité.

Correction : Validez le support fournisseur pour les builds Windows 11 ; mettez le client à jour ; vérifiez certificats et politiques de conformité des appareils.

5) « L’impression devient soudainement un sujet politique »

Syndromes : Les imprimantes disparaissent, demandes d’admin, échecs d’installation de pilotes.

Cause profonde : Politiques de pilotes d’impression, restrictions point‑and‑print, pilotes legacy.

Correction : Standardisez les pilotes via des packages approuvés ; utilisez un déploiement d’impression moderne ; testez avec vos modèles exacts.

6) « Performance post‑mise à niveau dégradée »

Syndromes : Ventilateurs à fond, lenteur de connexion, disque à 100%.

Cause profonde : HDD ancien, RAM insuffisante, outils de sécurité lourds, ou télémétrie/indexation excessive après migration.

Correction : Remplacez HDD par SSD, augmentez la RAM, ajustez les paramètres des agents de sécurité, et laissez les appareils se stabiliser après le premier démarrage tout en surveillant CPU/disque.

7) « Les utilisateurs ne peuvent pas se connecter après la bascule »

Syndromes : Échec des identifiants mis en cache, erreurs de confiance de domaine, blocs d’accès conditionnel.

Cause profonde : Changements d’identité d’appareil, comptes machines obsolètes, ou application trop précoce des politiques de conformité.

Correction : Étalez les changements d’accès conditionnel ; validez la synchronisation horaire ; assurez‑vous de la santé des enregistrements et de la confiance des appareils avant l’application des restrictions.

Checklists / plan étape par étape (la partie ennuyeuse qui évite les pannes)

Phase 0 : Arrêtez de deviner

• Construisez un inventaire réel. Réconciliez AD, SCCM/Intune, console EDR et listes d’achats. Choisissez une source de vérité pour le « compte ».
• Classifiez les endpoints. Postes de travail, portables, kiosques, machines de labo, appareils partagés, appareils uniquement distants.
• Étiquetez la criticité. Les appareils liés aux opérations génératrices de revenus, fabrication, cadres et centres d’appels nécessitent un soin accru.

Phase 1 : Portes d’éligibilité et de risque

• Rapport de préparation matérielle. TPM/Secure Boot/CPU/RAM/stockage.
• Préparation chiffrement. Confirmez l’état de BitLocker et que les clés de récupération sont escroquées et récupérables.
• Préparation réseau. Bande passante des succursales et stratégie de caching. Ne faites pas un DDoS de votre propre WAN.
• Préparation de gestion. Les appareils doivent se connecter régulièrement et recevoir les politiques.

Phase 2 : Réalité des applications

• Créez la liste « doit fonctionner ». VPN, EDR, suite Office, navigateur, outils d’identité, impression et 5–20 applications métier essentielles.
• Attribuez des propriétaires d’app. Les propriétaires valident les résultats de test et les déclarations de compatibilité.
• Construisez une matrice de tests. Par modèle d’appareil + build OS + jeu d’apps clé. Concentrez‑vous sur les apps lourdes en pilotes et l’outillage de sécurité.

Phase 3 : Pilote avec douleur représentative

• Ring 0 (les sacrifiés IT). Incluez le matériel le plus ancien que vous utilisez encore.
• Ring 1 (département ami). Choisissez un groupe avec des utilisateurs patients et des flux normaux.
• Ring 2 (déploiement large). Seulement après avoir éliminé les problèmes connus.

Phase 4 : Mécanique de déploiement qui ne crame pas la prod

• Planifiez par site et par horaire. Étalez les mises à jour ; limitez le débit ; utilisez caches/distribution locaux.
• Communiquez en termes opérationnels. Temps d’indisponibilité attendu, ce que les utilisateurs doivent laisser allumé, actions en cas d’échec.
• Ayez une réserve de remplacement. Un petit stock d’appareils pré‑imagés est le rollback le plus rapide.

Phase 5 : Durcissement post‑migration

• Vérifiez les baselines de sécurité. Credential Guard si approprié, protections LSASS, règles firewall et santé EDR.
• Retirez les exceptions. Les « temporaires » Windows 10 doivent avoir des dates butoir et des contrôles d’isolation.
• Mesurez les résultats. Taux de réussite par anneau, tickets helpdesk par 100 appareils, taux d’échec VPN, régressions du temps de démarrage.

Un rythme hebdomadaire pragmatique

• Semaine 1 : réconciliation d’inventaire + rapports de préparation + audit d’escrow des clés.
• Semaine 2 : attribution des propriétaires d’app + matrice de tests + pilote ring 0.
• Semaine 3–4 : ring 1 + boucle de correction (pilotes, agents, politiques).
• Semaine 5+ : déploiement étagé + gestion des exceptions + mise hors service/segmentation des holdouts.

FAQ

1) Faut‑il mettre tout le monde immédiatement à Windows 11 ?

Non. Il faut arrêter d’exploiter des OS non supportés pour les endpoints à usage général. Cela peut signifier Windows 11, nouveau matériel, VDI ou systèmes spécialisés isolés avec contrôles compensatoires.

2) Quel est le blocage le plus courant pour la préparation Windows 11 ?

L’éligibilité matérielle (TPM/Secure Boot/CPU) et la réalité désordonnée des anciens modèles encore en service. La vérification technique est simple ; la réalité des actifs ne l’est pas.

3) Mise à niveau sur place ou réimage—qu’est‑ce qui est plus sûr ?

Le réimage est plus prévisible à long terme. La mise à niveau sur place est plus rapide à court terme. Si vos endpoints sont standardisés et sains, la mise à niveau sur place convient. S’ils sont des « flocons de neige » uniques, le wipe‑and‑load vous fera gagner du temps au final.

4) Peut‑on garder Windows 10 pour quelques machines spéciales ?

Parfois. Mais vous devez les traiter comme des systèmes legacy : isoler l’accès réseau, retirer la navigation/e‑mail, appliquer le principe de moindre privilège et surveiller intensivement. Aussi : prévoyez une date de retrait, pas des vibes.

5) Combien d’espace disque libre faut‑il pour une mise à niveau ?

Cela dépend de la méthode et du staging, mais si vous êtes sous ~30 Go libres sur C:, attendez‑vous à des échecs et des comportements bizarres. Le stockage est bon marché ; l’indisponibilité ne l’est pas.

6) Pourquoi les mises à niveau déclenchent‑elles la récupération BitLocker ?

Les changements firmware/boot peuvent modifier les mesures TPM. Si BitLocker détecte un changement inattendu, il demande la récupération. C’est un comportement normal ; l’anormal est de ne pas avoir la clé de récupération.

7) Comment éviter de saturer les liens WAN pendant le déploiement ?

Utilisez le caching et la distribution de contenu (Delivery Optimization peer caching, points de distribution locaux), limitez le débit par site et évitez « tout le monde télécharge à 2 h du matin » si 2 h est l’heure des backups.

8) Que tester en premier pour la compatibilité applicative ?

Client VPN, agent EDR/outillage sécurité, outils de chiffrement disque et tout ce qui installe des pilotes noyau. Puis vos 10 applications métier principales. Les imprimantes et les middlewares de carte à puce méritent aussi une attention précoce.

9) À quoi ressemble le « succès » opérationnellement ?

Un taux de réussite mesurable par anneau, un volume de tickets en baisse, des performances VPN/auth stables et une liste d’exceptions qui diminue. Bonus : le renouvellement matériel s’aligne sur les cycles de garantie plutôt que sur des achats paniqués.

Conclusion : prochaines étapes à faire cette semaine

La voie propre à travers la fin de vie de Windows 10 n’est pas l’héroïsme. C’est la preuve. Réconciliation d’inventaire, portes de préparation, validation des propriétaires d’apps, anneaux étagés et vrais plans de rollback. Si cela ressemble à du SRE appliqué aux postes : parfait. Les endpoints sont aussi de la production ; ils courent juste dans des sacs à dos.

Faites ceci ensuite, dans l’ordre

1. Réconciliez vos comptes entre AD, plateforme de gestion et EDR jusqu’à ce que le nombre soit fiable.
2. Exécutez les vérifications de préparation (TPM, Secure Boot, espace disque, escrow BitLocker) et créez des listes de remplacement par modèle.
3. Attribuez des propriétaires d’app et construisez la liste « doit fonctionner » avec une matrice de tests.
4. Corrigez votre plomberie de mise à jour (politiques WSUS/Intune/SCCM, reachabilité, caching) avant de pousser quoi que ce soit de volumineux.
5. Démarrez Ring 0 avec du matériel représentatif, pas les plus beaux portables de l’équipe IT.
6. Rédigez la politique d’exception pour les holdouts Windows 10 inévitables : segmentation, usage restreint, surveillance et date de retraite.

La panique est un mauvais chef de projet. Remplacez‑la par une checklist, quelques sorties de commandes et un plan qui suppose que la réalité sera désordonnée. Elle le sera. Vous pouvez quand même gagner.