La mission a commencé comme une migration Windows 11. Elle est devenue le passage à l'échelle du modèle de gouvernance d'un parc Endpoint international tout entier.

Échelle : plusieurs dizaines de milliers de postes, + de 40 pays, une architecture Endpoint commune.

Le point de départ était familier pour la plupart des grandes organisations : un parc Windows réparti sur plusieurs entités et régions, historiquement géré localement — outils différents, standards différents, niveaux de maturité différents — avec une échéance qui n'était pas seulement la fin de support de Windows 10 — c'était surtout un enjeu de conformité et d'exposition sécurité, avec un parc vieillissant sortant progressivement de couverture. C'est ça qui rendait le calendrier non négociable. Le modèle de gestion standardisée, cloud-first, pilotée par le Groupe n'était pas nouveau en soi — Intune était déjà la direction prise par l'organisation sous Windows 10. Ce que Windows 11 a imposé, c'est le passage à l'échelle : faire réellement converger des dizaines d'équipes IT locales vers ce modèle, sans casser ce qui fonctionnait déjà localement.

Mon rôle sur ce programme a été de porter cette transformation de gouvernance et de migration de bout en bout : faire respecter l'architecture cible à travers chaque OpCo, poser les règles de délégation entre l'équipe centrale et les équipes locales, arbitrer les cas où la standardisation devait primer sur les exceptions locales, et résoudre personnellement le problème de reporting le jour où il a commencé à produire des décisions auxquelles plus personne ne pouvait se fier.

La gouvernance avant le déploiement

La première vraie décision n'était pas technique — elle était structurelle : quel modèle pouvait porter le poids d'un déploiement multi-entités sans basculer dans le tout-centralisé ou la totale autonomie locale. L'architecture cible avait déjà fait de Microsoft Intune le plan de contrôle unique de l'état cible — configuration des postes, conformité, orchestration des mises à jour. Ma part a été de faire tenir ce modèle en pratique à travers chaque entité, et de le faire vivre à l'échelle : cette montée en charge a confirmé que le modèle cloud-native retenu pouvait réellement être opéré au niveau international, pas seulement sur le papier.

Derrière les choix techniques se cachait en réalité un travail de définition du modèle opérationnel cible : qui décide, qui opère, qui valide et qui supporte chaque composant du service Endpoint. C'est ce travail-là, plus que le choix des outils eux-mêmes, qui déterminait si la gouvernance allait tenir une fois le programme terminé.

Le RBAC et les Scope Tags ont fait le gros du travail : les administrateurs locaux pouvaient opérer dans leur propre périmètre, sans pouvoir toucher aux objets d'une autre entité, tandis qu'un nombre restreint d'administrateurs Groupe conservait le contrôle global. La règle qui comptait le plus en pratique était simple à énoncer et difficile à faire respecter : l'exclusion prime toujours sur l'affectation aux rings, et seule l'équipe centrale peut mettre le déploiement en pause au niveau global. Non formalisée, une exception devient vite une échappatoire informelle — et à partir de là, un modèle de gouvernance cesse d'en être un en pratique, quoi qu'il en soit sur le papier.

Règle appliquée. Les affectations aux anneaux de déploiement sont réalisées exclusivement via des groupes de devices. En cas d'appartenance à plusieurs anneaux, le poste est automatiquement rattaché à l'anneau le plus précoce. Toute appartenance à un groupe d'exclusion prévaut sur les affectations aux anneaux et empêche le déploiement jusqu'à la levée de l'exception.

Décisions structurantes

  • Intune comme plan de contrôle unique
  • RBAC + Scope Tags
  • Groupes devices uniquement
  • Exclusions gouvernées
  • Reporting centralisé

Un déploiement pensé pour être mis en pause, pas seulement lancé

Derrière la migration Windows 11, l'objectif réel était de converger vers une architecture Endpoint cloud-native. Windows 11 n'était qu'un catalyseur. La cible consistait à réduire progressivement la dépendance aux modèles historiques de gestion du poste de travail — GPO, outils de patching locaux, images personnalisées — au profit d'un modèle fondé sur Microsoft Intune, Windows Autopilot, Microsoft Entra ID et Windows Update for Business.

Migrer des dizaines de milliers de postes à travers des dizaines d'équipes IT locales n'échoue pas à cause d'un mauvais plan — ça échoue à cause de ce qui se passe quand le plan rencontre le réel. Le déploiement s'est appuyé sur un modèle en rings, progressant d'une petite population pilote vers des vagues de plus en plus larges. Chaque ring portait son propre reporting ; chaque exclusion devait être justifiée et tracée, pas simplement appliquée en silence.

Windows Autopatch a été retenu comme modèle cible à long terme pour la gestion des mises à jour. Les postes en hybrid join et les environnements historiquement gérés, hors exceptions, basculaient sur une gestion administrative classique — pas sur Autopatch — le temps que leur périmètre soit éligible.

Sur la stratégie de version, la discipline qui a tenu le programme a été de résister à la pression de courir après chaque nouvelle version : rester une version en retrait de la dernière comme standard Groupe, et traiter la population encore non alignée sur la baseline en cours comme la priorité — pas la prochaine feature update à l'horizon.

Une part non négligeable du parc ne pouvait pas basculer vers Windows 11 dans le calendrier initial — essentiellement du matériel ne répondant pas au socle de sécurité de la plateforme. Pour ces postes, le programme a traité la décision comme un vrai choix à trancher, pas comme un défaut par omission : soit un refresh matériel ciblé là où le remplacement avait du sens, soit une exception Extended Security Updates strictement bornée dans le temps là où ce n'était pas le cas. Aucun des deux chemins n'avait le droit de devenir le défaut silencieux. L'ESU en particulier a été gouvernée pour ce qu'elle est réellement — un pont temporaire avec une date d'expiration et une liste de postes tracée, pas une stratégie de migration de substitution — pour que la population résiduelle reste visible plutôt que de devenir de la dette technique dissimulée dans un tableur.

Arbitrages d'architecture

  • Autopatch vs orchestration manuelle
  • ESU vs refresh matériel
  • Cloud-native vs héritage local
  • Standardisation vs autonomie locale

Quand le dashboard devient le problème

À mi-parcours du programme, il est devenu clair que le reporting Power BI lui-même devait être corrigé avant de pouvoir servir de base aux décisions. Des assets en doublon, des états en cache obsolètes, des environnements virtualisés ou historiquement gérés remontés comme non conformes alors qu'ils étaient hors périmètre — rien de tout cela n'était un échec de déploiement, mais laissé tel quel, tout cela aurait mené aux mauvaises décisions : refresh matériel inutile, dépense de licences inutile, fausses alertes en comité de pilotage.

Corriger cela impliquait de traiter la qualité de la donnée comme un chantier à part entière, pas un effet secondaire de la migration — j'ai tracé une frontière claire entre les deux plateformes qui portaient l'essentiel : Intune comme couche qui définit et fait respecter l'état cible. Tanium comme couche qui apporte la visibilité temps réel à grande échelle. Une fois cette frontière explicite, les deux outils ont mieux fonctionné, parce qu'aucun des deux n'essayait discrètement de faire le travail de l'autre.

Règle appliquée. Intune orchestre l'état cible. Tanium observe, audite en temps réel. Dès que les deux commencent à se chevaucher sur le même objet, c'est la gouvernance qu'il faut corriger — pas l'outillage.

Lessons learned

  • Un dashboard n'est pas la vérité
  • La qualité de donnée est un projet
  • Un KPI sans périmètre est dangereux
  • La gouvernance précède l'outillage

Ce que le programme a réellement produit

La migration Windows 11 n'a pas seulement permis de moderniser le parc. Elle a permis de valider qu'un modèle Endpoint cloud-native pouvait être gouverné, opéré et mesuré à l'échelle internationale. Ce qui en est ressorti, au-delà des postes migrés, c'est un modèle de gouvernance reproductible : un plan de contrôle clair là où il n'y avait que de la gestion locale fragmentée, un modèle de délégation qui passe à l'échelle sans se disperser, un processus d'exception traité aussi sérieusement que le chemin standard, et une couche de reporting sur laquelle le business pouvait enfin s'appuyer pour décider. Près de cinquante mille postes reposent désormais sur une seule architecture plutôt que sur des dizaines de modèles locaux. La valeur métier était double : réduire le risque lié au maintien de postes Windows 10 non supportés, et obtenir une vraie visibilité endpoint que l'organisation n'avait tout simplement pas avant.

Le résultat est une infrastructure Endpoint standardisée et gouvernée, capable d'accompagner les prochaines évolutions du Digital Workplace — intelligence artificielle, automatisation, sécurité renforcée et nouveaux modèles d'usage — sans reconstruire son socle à chaque transformation.