Migration SCCM vers Intune : le guide pas-à-pas pour 2026

Pourquoi migrer SCCM vers Intune en 2026

System Center Configuration Manager (SCCM, devenu MEMCM puis Configuration Manager) reste le pilier de la gestion des postes Windows dans la plupart des grandes organisations québécoises. Il fonctionne, il est mature, il connaît tout. Pourquoi migrer ?

Trois raisons solides en 2026 : la majorité du travail se fait désormais hors du réseau d'entreprise (télétravail, mobilité), or SCCM est conçu pour des postes connectés au LAN ; les nouveaux mécanismes de sécurité Microsoft (Defender for Endpoint, Conditional Access, Zero Trust) sont nativement orchestrés via Intune ; et le déploiement de Windows 11 + Autopilot est radicalement plus simple via Intune.

Mais migrer ne veut pas dire « tout casser pour tout reconstruire ». Microsoft a conçu deux mécanismes - Cloud Attach et Co-management - précisément pour permettre une transition graduelle, charge de travail par charge de travail.

Les 3 approches possibles

Selon votre maturité et vos contraintes, trois trajectoires sont possibles :

• Cloud Attach (rapide, faible risque) : SCCM reste maître de tout, on rattache simplement le tenant Azure AD pour bénéficier de capacités cloud (Endpoint Analytics, Conditional Access basé sur la conformité SCCM). Aucun changement opérationnel.
• Co-management (la voie royale) : SCCM et Intune gèrent conjointement les postes, on bascule les charges de travail (workloads) une par une de SCCM vers Intune. Pendant la transition, c'est Intune qui prend autorité sur le workload basculé.
• Intune Full Cloud (cible finale) : tous les workloads sont gérés par Intune, SCCM est décommissionné. Les nouveaux postes sont provisionnés via Windows Autopilot sans jamais voir SCCM.
• Notre recommandation par défaut : Cloud Attach → Co-management progressif → Intune Full Cloud, sur 9 à 18 mois selon la taille et la complexité.

Phase 1 - Cloud Attach (2 à 4 semaines)

Cloud Attach est l'étape la plus simple : on rattache le site SCCM au tenant Azure AD via la Cloud Management Gateway, et on active la cohabitation. Aucun changement côté postes - ils continuent à recevoir leurs politiques de SCCM.

Bénéfices immédiats : Endpoint Analytics (visibilité sur la santé du parc), Tenant Attach (vous voyez vos postes dans la console Intune sans qu'ils soient managés), et la possibilité de déclencher des actions Intune sur des postes SCCM.

Prérequis techniques : Configuration Manager Current Branch en version 2002 minimum pour Tenant Attach, version 2111+ pour Cloud Attach complet (recommandé 2309 ou plus récent pour bénéficier des dernières capacités). Azure AD Hybrid Join opérationnelle et résolution DNS Cloud Management Gateway obligatoires.

Phase 2 - Co-management workload par workload

Une fois Cloud Attach en place, on commence à basculer les charges de travail. Microsoft en définit sept principales (parfois listées comme huit selon que les Office Click-to-Run apps sont comptabilisées avec les Client apps ou séparément), qu'on peut migrer indépendamment :

• Compliance policies (généralement migré en premier - faible risque, gain Conditional Access immédiat).
• Device configuration (politiques BitLocker, configuration Edge, Defender, etc.).
• Endpoint protection (Defender for Endpoint, antivirus).
• Resource access policies (Wi-Fi, VPN, certificats).
• Windows Update policies (Windows Update for Business → fin des WSUS internes).
• Office Click-to-Run apps (déploiement Microsoft 365 Apps via Intune).
• Client apps (le plus complexe - repackaging Win32 apps).
• Office macros et add-ins.
• Approche recommandée : un workload toutes les 2 à 4 semaines, avec pilote sur 50 à 100 postes, puis bascule globale. Les workloads complexes (client apps) en dernier.

Phase 3 - Repackaging applicatif

C'est ici que la migration ralentit le plus. SCCM utilise les packages .msi et applications custom depuis 15 ans. Intune utilise un format différent : Win32 app (.intunewin), créé via l'outil Microsoft Win32 Content Prep.

Notre méthode : extraction de l'inventaire applicatif SCCM (souvent 200 à 800 applications dans une grande organisation), tri par criticité d'usage (combien de postes installés), repackaging des 80 applications top usage (couvrant 95 % des utilisateurs), retraite des applications obsolètes, traitement long-tail pour le reste.

Pour les applications complexes (Adobe Creative Cloud, AutoCAD, applications métier maison), on utilise PSAppDeployToolkit (PSADT) qui reste l'outil de référence - il fonctionne aussi bien sous Intune que sous SCCM.

Gouvernance Intune : pièges classiques

Intune n'est pas SCCM. Les habitudes opérationnelles doivent évoluer :

• Pas de boundaries : Intune fonctionne sur Internet, pas sur le réseau LAN. Repenser les distributions massives (un patch de 4 Go × 5 000 postes en simultané ≠ même comportement réseau).
• Pas de collections dynamiques par SQL query : on utilise des groupes Azure AD dynamiques avec syntaxe différente. Prévoir une session de formation pour les opérateurs SCCM.
• Approche déclarative : Intune ne pousse pas, il déclare l'état désiré. Le poste va chercher sa politique au prochain check-in (toutes les 8 heures par défaut). Pas de « refresh policy » immédiat.
• Reporting moins riche par défaut : Endpoint Analytics + Power BI Intune Data Warehouse comblent partiellement le gap, mais demandent à être configurés.
• Co-management toggle : un workload basculé est en pratique difficile à rebasculer vers SCCM. Toujours valider en pilote large avant la bascule globale.

Retour terrain : 1 200 postes en 9 mois

Un mandat illustratif : une grande entreprise québécoise de 1 200 utilisateurs (services professionnels, infrastructure SCCM en place depuis 2014).

Calendrier : 1 mois Cloud Attach + Endpoint Analytics. 2 mois pilote co-management sur 80 postes IT et power-users. 4 mois bascule progressive des 8 workloads, 2 par 2. 2 mois finalisation : décommissionnement WSUS, repackaging des 60 dernières applications, formation du support N1.

Résultat à 12 mois : Intune Full Cloud sur tous les postes, SCCM décommissionné, Autopilot opérationnel pour tous les nouveaux postes (zéro-touch deployment). Réduction du temps de provisioning d'un nouveau poste : de 4 heures à 35 minutes. Réduction du nombre de serveurs SCCM/WSUS/MDT à maintenir : de 6 à 0.