Fin du support de Windows : comment anticiper la migration sereinement

Le 14 octobre 2025, Windows 10 a cessé de recevoir des mises à jour de sécurité. Nous sommes en 2026, et une partie du parc informatique continue de tourner dessus. Je le vois régulièrement chez des clients : des postes qui fonctionnent très bien, des logiciels métier qui n'ont jamais bougé, et une direction qui découvre le problème au moment où un audit de conformité tombe sur la table. Le vrai sujet n'est pas la date. Le vrai sujet, c'est que la fin du support de Windows ne se prépare pas en trois semaines.

Pourquoi la fin du support de Windows n'est pas un simple clic sur « Mettre à niveau »

On me pose souvent la question comme si c'était une formalité. « Il suffit de lancer la mise à niveau, non ? » Sur un PC personnel, oui, la plupart du temps. Sur un parc professionnel, c'est une autre histoire.

Le problème n'est pas technique au sens strict. Le problème, c'est tout ce qui s'est accumulé sur ces machines pendant des années : un logiciel de comptabilité édité par une société qui n'existe plus, une imprimante réseau dont le pilote date de Windows 7, des scripts internes que personne n'a documentés. J'ai vu un poste de direction bloquer une migration complète parce qu'un utilitaire de signature électronique n'avait jamais été mis à jour et refusait de s'installer sur un système plus récent.

Ce qui change concrètement avec la fin du support :

• Plus de correctifs pour les failles découvertes après octobre 2025. Une faille non corrigée reste une porte ouverte, indéfiniment.
• Les éditeurs de logiciels suivent le mouvement. Certains arrêtent de tester leurs produits sur Windows 10, puis arrêtent de les supporter.
• Les assureurs et les auditeurs posent la question. « Combien de postes hors support ? » devient une ligne dans un rapport.

Le point que beaucoup sous-estiment : ce n'est pas la sécurité qui déclenche la migration dans la majorité des cas que j'ai traités. C'est la compatibilité. Un logiciel qui cesse de fonctionner arrête l'activité immédiatement. Une faille potentielle, non.

Combien de temps prend réellement une migration ?

Cela dépend du nombre de postes et de la complexité logicielle, pas de la taille de l'entreprise. Sur un parc d'une cinquantaine de machines avec deux applications métier critiques, je compte généralement trois à cinq mois entre la décision et le dernier poste migré. Sur un parc de dix postes sans logiciel exotique, trois semaines suffisent.

Le facteur qui allonge tout, systématiquement, c'est l'application dont personne ne connaît l'éditeur. Pas le nombre de machines.

L'inventaire du parc : l'étape que tout le monde saute

Avant de toucher à quoi que ce soit, il faut savoir ce qu'on a. Pas ce qu'on croit avoir. Ce qu'on a réellement.

J'ai fait l'erreur, sur l'un de mes premiers projets, de partir de la liste fournie par le service informatique. Elle était fausse d'environ 15 % : des postes éteints depuis des mois, des machines prêtées et jamais rendues, des portables utilisés par des prestataires externes. Résultat, une migration « terminée » qui a laissé cinq personnes sans poste fonctionnel le lundi matin.

Ce qu'il faut relever pour chaque poste

• Le modèle exact et l'âge du matériel.
• La version de Windows installée et si le processeur remplit les conditions du système cible.
• La liste des logiciels installés, avec l'éditeur et la version.
• Les périphériques connectés : imprimantes, scanners, lecteurs de badges.
• L'usage réel de la machine, pas l'usage théorique.

Le dernier point est celui qu'on oublie. Une machine déclarée « poste comptabilité » peut en réalité servir de serveur de fichiers informel pour tout un service. Cela se découvre au moment où on la débranche.

Comment vérifier la compatibilité du matériel ?

Microsoft propose un utilitaire d'analyse intégré à Windows qui indique si une machine remplit les conditions requises pour le système visé, notamment au niveau du processeur, de la mémoire, du stockage et de la puce de sécurité. Sur les parcs un peu anciens, le verdict est souvent le même : le processeur ou l'absence de ce module bloque la mise à niveau.

Dans ce cas, deux chemins. Soit on remplace la machine, soit on contourne les prérequis — solution que je déconseille franchement en entreprise, pour des raisons évidentes de support futur. Contourner un contrôle officiel, c'est s'exposer à des mises à jour qui cassent le contournement à n'importe quel moment.

Migrer, payer, changer : les trois voies possibles

Tout le monde présente la migration comme une évidence. Ce n'est pas toujours le bon choix, et je trouve qu'on manque de honnêteté là-dessus.

Option	Coût principal	Durée de validité	Pour qui
Mise à niveau vers le système actuel	Temps de projet, renouvellement matériel partiel	Durable	La majorité des parcs, quand le matériel suit
Mises à jour de sécurité étendues	Abonnement annuel par poste	Temporaire	Matériel incompatible et budget bloqué
Remplacement complet du parc	Investissement matériel	Durable	Parc ancien de plus de cinq ans
Passage à un autre système d'exploitation	Temps de formation, compatibilité logicielle	Variable	Parcs à usage limité : navigation, bureautique simple

Le dispositif de mises à jour étendues mérite qu'on s'y arrête. Il permet de continuer à recevoir des correctifs de sécurité après la fin du support, moyennant un abonnement. Je le vois souvent présenté comme une solution miracle. Ce n'est pas ça.

C'est un sursis. Utile pour étaler un investissement sur deux exercices budgétaires, ou pour laisser le temps de finir un projet bloqué par une application critique. Inutile si l'objectif est d'éviter la migration pour de bon.

Et le passage à un autre système, c'est crédible ?

Pour un poste qui sert à consulter une messagerie, ouvrir des documents et naviguer sur le web : oui, très crédible. J'ai basculé plusieurs postes d'accueil et de consultation vers un système libre, et les utilisateurs n'ont pas vu de différence après une semaine.

Pour un poste avec un logiciel métier lourd, c'est presque toujours non. Les éditeurs de ces logiciels ne portent leurs produits que sur Windows, et personne ne va réécrire une application de gestion pour satisfaire une migration.

Le plan de migration, étape par étape

Voici l'ordre que j'applique, et que je n'ai jamais eu de raison de changer.

1. Sauvegarder les données de chaque poste concerné. Vérifiée, la sauvegarde, pas juste lancée.
2. Inventorier le parc comme décrit plus haut.
3. Tester la compatibilité logicielle : chaque application métier doit s'installer et fonctionner sur le système cible.
4. Choisir une méthode de déploiement. Sur un petit parc, poste à poste. Au-delà d'une vingtaine de machines, un outil de gestion centralisée fait gagner un temps considérable.
5. Migrer un groupe pilote de trois à cinq utilisateurs, choisis pour leur tolérance au changement.
6. Corriger ce qui casse, puis généraliser par vagues de dix à quinze postes.

L'étape pilote n'est pas une perte de temps. C'est celle qui révèle les problèmes. Sur mon dernier projet, elle a mis en évidence qu'une extension de navigateur utilisée par le service commercial bloquait la connexion au logiciel de facturation. Détecté sur cinq postes, corrigé en une journée. Détecté sur quarante postes, ça aurait été un autre lundi.

Prévoir un retour arrière

Chaque migration doit avoir un plan de retour. Concrètement : une image du système d'origine conservée, et une procédure écrite pour revenir dessus en cas de blocage. Je ne l'ai utilisée qu'une seule fois, mais ce jour-là, elle a évité deux jours d'arrêt pour un service entier.

Une migration sans filet de sécurité transforme un incident mineur en arrêt de production. Ce n'est pas un risque théorique.

Les erreurs que je vois le plus souvent

Trois reviennent systématiquement, quel que soit le secteur.

Attendre un déclencheur externe. Un audit, une panne, un logiciel qui cesse de fonctionner. À ce moment-là, la migration se fait dans l'urgence, et l'urgence coûte cher en heures supplémentaires et en mauvaises décisions.

Sous-estimer les périphériques. Les imprimantes, en particulier. Un modèle un peu ancien peut ne pas avoir de pilote pour le système cible, et cela se découvre au dernier moment.

Oublier la formation. Une interface qui change, même légèrement, génère des questions. Deux heures d'accompagnement par service réduisent nettement le volume de tickets dans les semaines qui suivent.

Faut-il un budget dédié ?

Oui, et il vaut mieux le poser tôt. Le poste le plus lourd n'est pas le matériel, c'est le temps interne mobilisé. Sur un parc de vingt postes, comptez l'équivalent de plusieurs semaines de travail d'une personne, réparties sur deux ou trois mois. Ajoutez l'abonnement aux mises à jour étendues si vous choisissez cette voie, et le renouvellement des machines les plus anciennes.

Ce budget se défend bien mieux quand il est présenté comme un projet planifié plutôt que comme une réponse à une panne.

Alors, quand faut-il s'y mettre ?

Maintenant, si ce n'est pas déjà fait. Pas parce que la date est passée, mais parce que chaque mois supplémentaire réduit votre marge de manœuvre. Un projet de migration mené tranquillement n'a rien à voir avec le même projet mené dans l'urgence après une faille exploitée.

Et si vous ne savez pas par où commencer, il y a un exercice simple. Prenez les cinq postes les plus anciens de votre parc et vérifiez s'ils peuvent accueillir le système actuel. Ce test-là, fait en une heure, vous donnera une idée assez juste de l'ampleur du chantier à venir. C'est souvent le moment où la vraie question se pose : combien de temps peut-on encore se permettre d'attendre ?