Migrer 3000 postes vers Windows 11 : ce que j'ai appris sur Intune en environnement bancaire

Sur le papier, faire passer un parc d'ordinateurs de Windows 10 à Windows 11 est une opération banale : nouveau système d'exploitation (le logiciel de base de l'ordinateur), nouvelle période de support, échéance à tenir. Dans une grande banque française, avec plus de trois mille postes de travail répartis sur plusieurs pays, ce n'était pas si simple.

Le contexte : bien plus qu'une mise à jour

Trois contraintes se sont additionnées dès le cadrage. La régulation bancaire d'abord : chaque changement de configuration devait être tracé, justifié et validé par des comités qui ne sont pas là pour aller vite. Le périmètre international ensuite : les fenêtres de maintenance n'étaient pas les mêmes d'un pays à l'autre, ni la qualité de la connexion, ni les habitudes des équipes de support sur place. L'état du parc de départ enfin : plusieurs générations de matériel, des applications métier aux dépendances anciennes, des réglages locaux accumulés au fil des ans sans jamais avoir été harmonisés.

Ce dernier point mérite qu'on s'y arrête. La difficulté d'une migration de cette taille ne vient presque jamais du système cible. Elle vient de tout ce qui s'est empilé sur l'ancien pendant des années, et qu'il faut comprendre avant d'y toucher.

Pourquoi Intune plutôt qu'un déploiement traditionnel

Le parc reposait sur des outils de déploiement classiques, conçus pour un monde où les ordinateurs restent connectés au réseau de l'entreprise. Passer à Intune répondait à un besoin plus large que la seule migration. Intune est l'outil de Microsoft qui permet de gérer à distance les ordinateurs d'une entreprise (on parle de MDM, pour « mobile device management »). Il offrait à la DSI, la direction des systèmes d'information qui pilote l'informatique de l'entreprise, une gestion cohérente de sa flotte, y compris pour les postes qui ne sont pas tout le temps sur le réseau interne.

Le projet s'est organisé autour de trois chantiers menés en parallèle, mais très liés.

• L'image de marque du poste (fond d'écran, page de démarrage, personnalisation). Cela paraît accessoire, mais cela conditionne l'acceptation du changement par les utilisateurs.
• Intune proprement dit : l'enregistrement des ordinateurs, les profils de configuration, les règles de conformité.
• La remise à niveau des applications, le chantier le plus lourd : identifier celles qui fonctionnent telles quelles sous Windows 11, celles qu'il faut mettre à jour, et celles qu'il faut simplement remplacer.

Le vrai piège d'un projet de ce type n'est pas l'outil. C'est la tentation de vouloir mener les trois chantiers en même temps, au même rythme. Nous avons dû séparer très tôt l'image de marque et la remise à niveau des applications : la première pouvait avancer vite, la seconde imposait un rythme bien plus lent, vague après vague, application après application.

Ce qui s'est mal passé, et pourquoi le dire

Un projet de cette taille ne se termine jamais sans accroc. Plusieurs déploiements en cours de route ont provoqué des dysfonctionnements en production, c'est-à-dire chez les utilisateurs : des applications qui refusaient de démarrer après la migration, des profils de configuration en conflit avec des règles locales déjà en place, un pic d'appels au support quand plusieurs sites ont basculé le même jour.

Nous avons répondu en créant une cellule de crise : une équipe resserrée (une « task force »), un compte rendu quotidien au comité de pilotage (l'instance qui suit l'avancement et prend les décisions), et surtout une règle appliquée sans exception. En cas de doute sur l'impact d'un déploiement, on suspend la vague plutôt qu'attendre que le problème se règle tout seul. Cette règle a coûté du temps à court terme. Elle a évité des incidents bien plus coûteux ensuite.

Ce qu'il faut retenir n'est pas que ces incidents ont eu lieu, sur un périmètre pareil c'est statistiquement inévitable. C'est que le dispositif pour les détecter et y réagir avait été pensé avant le premier déploiement, et non improvisé après le premier problème.

Ce que je retiens pour un projet similaire

Trois recommandations pour une DSI qui prépare sa propre migration à grande échelle.

1. Séparer les chantiers dès le cadrage. Image de marque, enregistrement dans Intune et remise à niveau des applications n'avancent pas au même rythme. Les traiter comme un bloc unique retarde tout le monde.
2. Prévoir la cellule de crise avant le premier déploiement, pas après le premier incident. Une équipe prête à intervenir coûte peu, comparée à une réparation improvisée en production.
3. Accepter de ralentir une vague plutôt que de la forcer. Sur un périmètre international régulé, suspendre un déploiement à temps coûte toujours moins cher que le maintenir contre vents et marées.

Le déploiement a finalement été mené dans les délais fixés par le comité de pilotage, sans incident majeur en production sur la durée du projet. Ce résultat tient moins à la maîtrise d'Intune, un outil parmi d'autres, qu'à la discipline de méthode : cartographier avant d'agir, mesurer le risque avant de déployer, et accepter de suivre le rythme du terrain plutôt que celui du planning de départ.