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

Le contexte : pourquoi cette migration n'était pas « juste » une mise à jour

Sur le papier, migrer un parc de Windows 10 vers Windows 11 ressemble à une opération technique banale : un nouvel OS, un nouveau cycle de support, une échéance à tenir. Sur le terrain d'une grande banque française, avec plus de trois mille postes répartis sur plusieurs pays, la réalité était différente.

Trois contraintes se sont superposées dès le cadrage. D'abord, la régulation bancaire : chaque changement de configuration poste de travail devait être tracé, justifié, et validé par des comités qui n'ont pas vocation à aller vite. Ensuite, le périmètre international : les fenêtres de maintenance n'étaient pas les mêmes selon les pays, ni les contraintes locales de connectivité, ni même les habitudes des équipes support sur place. Enfin, l'état du parc de départ — plusieurs générations de matériel, des applications métier avec des dépendances anciennes, des configurations locales qui s'étaient accumulées au fil des années sans jamais être réellement harmonisées.

Ce dernier point mérite d'être souligné : la difficulté d'une migration à cette échelle ne vient presque jamais de l'OS cible. Elle vient de tout ce qui a été empilé sur l'OS de départ pendant des années, et qu'il faut comprendre avant de pouvoir y toucher.

Le choix d'Intune plutôt qu'un déploiement traditionnel

Le parc reposait historiquement sur des outils de déploiement traditionnels, pensés pour un monde où les postes restent sur le réseau de l'entreprise. Le passage à Intune répondait à un besoin plus large que la seule migration Windows 11 : donner à la DSI une gestion de flotte cohérente, y compris pour les postes qui ne sont pas en permanence connectés au réseau interne.

Ce choix a structuré tout le projet en trois périmètres distincts, gérés en parallèle mais avec des dépendances fortes entre eux :

• Branding — l'image de marque du poste (fond d'écran, page de démarrage, personnalisation), qui semble accessoire mais qui conditionne l'acceptation du changement par les utilisateurs finaux ;
• Intune proprement dit — l'inscription des postes, les profils de configuration, les politiques de conformité ;
• Remédiation applicative — le travail le plus lourd : identifier quelles applications métier fonctionnent telles quelles sous Windows 11, lesquelles nécessitent une mise à jour, et lesquelles doivent être purement et simplement remplacées.

Le vrai piège d'un projet MDM à cette échelle n'est pas l'outil, c'est la tentation de vouloir migrer les trois périmètres en même temps, avec le même calendrier. Nous avons dû découpler branding et remédiation applicative très tôt : le premier pouvait avancer vite, le second imposait un rythme beaucoup plus lent, vague par vague, application par application.

Ce qui s'est mal passé (et pourquoi c'est utile de le dire)

Un projet de cette taille ne se termine jamais sans incident. Plusieurs déploiements en cours de campagne ont provoqué des dysfonctionnements en production — des applications métier qui refusaient de démarrer après migration, des profils de configuration qui entraient en conflit avec des stratégies locales préexistantes, un pic de sollicitations du support utilisateur au moment où plusieurs sites basculaient le même jour.

La réponse a été la mise en place d'une cellule de crise dédiée : task force resserrée, reporting quotidien au comité de pilotage, et surtout une règle simple appliquée sans exception — en cas de doute sur l'impact d'un déploiement, on suspend la vague plutôt que d'attendre que le problème se résolve de lui-même. Cette règle a coûté du temps à court terme. Elle a évité des incidents bien plus coûteux à moyen terme.

Ce qu'il faut retenir de ces épisodes n'est pas qu'ils ont eu lieu — sur un périmètre pareil, c'est statistiquement inévitable — mais que le dispositif de détection et de réaction a été pensé avant le premier déploiement, pas improvisé une fois le premier incident survenu.

Ce qu'il faut retenir pour un projet similaire

Trois recommandations concrètes, pour une DSI qui prépare sa propre migration à l'échelle :

1. Séparer explicitement les chantiers dès le cadrage. Branding, inscription MDM et remédiation applicative n'avancent pas au même rythme — les traiter comme un seul projet monolithique retarde tout le monde.
2. Dimensionner la cellule de crise avant le premier déploiement, pas après le premier incident. Le coût d'une astreinte prête à intervenir est marginal comparé au coût d'une remédiation improvisée en production.
3. Accepter de ralentir une vague plutôt que de la pousser en force. Sur un périmètre international régulé, un déploiement suspendu à temps coûte toujours moins cher qu'un déploiement maintenu envers et contre tout.

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 doit moins à la maîtrise technique d'Intune — qui reste 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 piloter au rythme du terrain plutôt qu'à celui du planning initial.