Ce que vous saurez faire
- Choisir une stratégie de migration (lift & shift, hybride progressif, cloud-only) selon le contexte.
- Planifier la migration des identités et des groupes (sync puis bascule, ou création cloud).
- Organiser le remplacement des GPO par Intune et la migration des partages vers SharePoint / OneDrive.
- Énoncer les conditions et étapes de décommissionnement d'un contrôleur de domaine.
- Dérouler un plan de bascule type sur 6 mois.
Compétences transférées depuis l'AD classique
| L'admin AD réutilise | L'admin AD doit désapprendre |
|---|---|
| Connaissance exhaustive du SI (AD, GPO, partages) | « L'AD est éternel » — c'est un point de départ à faire décroître |
| Gestion de projet d'infrastructure | Migration « big bang » — préférer l'incrémental, réversible |
| Cartographie des dépendances | Sous-estimer les apps legacy (LDAP / Kerberos) comme frein n°1 |
Assembler la trajectoire
1. Trois stratégies
| Stratégie | Principe | Pour qui | Risque |
|---|---|---|---|
| Lift & shift | Serveurs AD / apps sur VM Azure (IaaS), l'AD DS reste tel quel | Contraintes fortes, apps legacy non modifiables à court terme | Faible transformation, coûts IaaS, dette reportée |
| Hybride progressif | Synchronisation (module 03), bascule service par service, réduction progressive de l'AD | La majorité des PME (dont votre cas) | Maîtrisé, réversible |
| Cloud-only | Comptes créés dans Entra, postes joints Entra + Intune, aucun AD DS | Nouveaux SI, ou après élimination des dépendances AD | Nécessite que rien ne dépende plus de l'AD DS |
2. Migration des identités & groupes
Identités — deux voies :
- Synchroniser l'AD vers Entra (Connect / Cloud Sync) puis, à terme, basculer la source en cloud (via une bascule de la gestion).
- Créer directement en cloud pour les nouveaux comptes.
Groupes — les groupes de sécurité AD peuvent être synchronisés. Profiter de la migration pour rationaliser : transformer les groupes « par service » en groupes dynamiques (module 02), supprimer les groupes morts.
Groupes gérés sur le DC, appartenance manuelle. Aucune notion native de groupe dynamique par attribut.
3. GPO → Intune
Reprendre le tableau de correspondance GPO ↔ Intune (module 06). Démarche :
- Inventorier toutes les GPO (Group Policy Analytics mesure la couverture Intune).
- Trier : garder l'utile, supprimer l'obsolète / redondant.
- Prioriser : sécurité et conformité d'abord (BitLocker, mots de passe, pare-feu).
- Rejouer en profils Intune (Settings Catalog, ADMX ingérés), par vagues.
- Valider sur un pilote avant généralisation.
4. Partages de fichiers → SharePoint / OneDrive
- Données personnelles (lecteur
H:) → OneDrive. - Partages d'équipe (lecteur
S:) → SharePoint / Teams. - Outils : SharePoint Migration Tool (SPMT), Migration Manager.
- Repenser les permissions : ACL NTFS + groupes AD → permissions SharePoint + groupes M365 / sécurité.
Partages SMB, ACL NTFS, GPP drive maps.
SharePoint / OneDrive, permissions cloud, plus de mappage de lecteur.
Répliquer l'arborescence de partage 1:1 dans SharePoint. Repenser l'organisation (sites, bibliothèques), pas copier la structure de dossiers legacy.
5. Décommissionnement des DC
Un contrôleur de domaine ne s'éteint pas « quand on veut ». Conditions préalables :
- Plus aucun poste / serveur ne dépend de l'AD DS pour l'authentification.
- Plus aucune application n'utilise LDAP / Kerberos contre l'AD.
- Partages migrés, GPO rejouées en Intune, impressions / services migrés.
- Postes joints Entra + Intune (plus de jointure au domaine AD).
- La synchronisation n'est plus nécessaire (ou on bascule en cloud-only maîtrisé).
Étapes (après conditions remplies) :
- Arrêter la synchronisation (ou basculer la gestion des objets en cloud).
- Réduire progressivement les rôles du DC (période d'observation, DC « débranché » testable).
- Rétrograder proprement (
dcpromo/ suppression du rôle ADDS), transférer / retirer les rôles FSMO. - Décommissionner DNS / DHCP internes si remplacés.
Vous êtes tenté d'éteindre le DC dès que 90 % des postes sont joints Entra. Quel réflexe garder ?
Les 10 % restants — souvent l'app LDAP oubliée, une imprimante réseau qui s'authentifie contre l'AD, un vieux serveur de sauvegarde — cassent la prod le jour de l'extinction. Débrancher physiquement (ou bloquer le réseau) le DC en test pendant 1-2 semaines, observer les incidents, puis rétrograder. Garder les sauvegardes et les rôles FSMO documentés : la réversibilité est le seul filet.
6. Plan de bascule type sur 6 mois
Planning indicatif pour une PME (~30 postes). Chaque mois = un incrément réversible.
| Mois | Objectifs | Livrables |
|---|---|---|
| M1 · Cadrage & socle | Inventaire complet (AD, GPO, apps, partages, comptes). Créer / valider le tenant. Vérifier les domaines. Définir break-glass. | Cartographie des dépendances AD DS ; tenant prêt ; 2 comptes break-glass. |
| M2 · Sync & identités | Déployer la synchronisation (Cloud Sync), PHS + Seamless SSO. Rationaliser les groupes (dynamiques). | Identités synchronisées ; groupes nettoyés ; SSO en place. |
| M3 · Sécurité identité | Déployer MFA, Conditional Access (report-only → On), PIM sur les rôles admin, Identity Protection (report-only). | Baseline CA active ; admins en PIM ; MFA généralisée. |
| M4 · Postes (Intune) | Enrôler un pilote Intune, rejouer les GPO prioritaires (Settings Catalog), conformité + CA « compliant device ». Autopilot sur nouveaux postes. | Pilote conforme ; GPO sécurité rejouées ; Autopilot opérationnel. |
| M5 · Données & apps | Migrer partages → SharePoint / OneDrive (SPMT). Traiter les apps legacy (auth moderne ou plan de sortie). Généraliser Intune. | Partages migrés ; plan apps LDAP ; parc majoritairement Intune. |
| M6 · Convergence & décommission | Vérifier les conditions de décommission. Débrancher le DC en test, observer, rétrograder. Supervision (logs, alertes). Bilan. | Dépendances AD DS levées ; DC décommissionné (ou planifié) ; supervision active. |
Sources Microsoft Learn
- Cloud-first / migration
- Étapes vers le cloud (road to the cloud)
- Group Policy Analytics
- SharePoint Migration Tool
- Cloud Sync
Rappel : en cas d'écart entre ce support et le portail, le portail fait foi.
Atelier de planification
Partie A — Cartographier vos dépendances AD DS (60 min)
Sur un tableur (ou papier), listez pour votre organisation :
- Postes joints AD — combien, quel OS, quelle vétusté.
- Applications qui s'authentifient contre l'AD — LDAP, Kerberos, NTLM.
- Services AD — DNS, DHCP, PKI, RADIUS interne.
- Partages réseau — SMB, drive maps, sensibilité (RH, compta, projets).
- GPO en vigueur — combien, dernière revue, doublons connus.
- Comptes dormants — comptes n'ayant pas servi > 90 jours.
Pour chaque ligne, noter : quand cette dépendance peut-elle être levée ? C'est cette carte qui détermine si le cloud-only est atteignable en 6 mois ou 18 mois.
Partie B — Bâtir votre plan 6 mois (60 min)
À partir de la carte de dépendances de la partie A, remplissez votre propre plan M1-M6 en repartant du template de la section 6. Pour chaque mois :
- Adapter les objectifs à votre contexte (parc, apps, contraintes).
- Nommer un livrable vérifiable.
- Identifier le point de non-retour et la stratégie de rollback.
- Marquer les dépendances entre étapes (M4 « CA compliant device » suppose M3 CA + M4 Intune opérationnels).
5 pièges de projet migration
Testez vos acquis
Une évaluation interactive qui vous donne le badge Acquis (≥60%) ou Maîtrisé (≥80%).
Cas pratique — Cloud-only dans 6 mois ?
Contexte : votre PME veut être cloud-only dans 6 mois. Contraintes : 1 application interne authentifiée en LDAP contre l'AD, 3 partages réseau (dont un sensible), ~40 GPO, 30 postes joints au domaine.
Questions :
- Est-ce réaliste en 6 mois ? Qu'est-ce qui conditionne la réponse ?
- Donnez la séquence des grandes étapes (dépendances entre elles).
- Que faites-vous de l'application LDAP ?
- Quelles conditions vérifiez-vous avant d'éteindre le DC ?
Démarche attendue
- Réaliste seulement si l'app LDAP peut être traitée dans la fenêtre. Le cloud-only exige zéro dépendance AD DS. Si l'app LDAP ne peut être ni réécrite (auth moderne) ni remplacée en 6 mois, la cible réaliste est hybride à 6 mois, cloud-only ensuite. La migration des partages, GPO et postes est faisable en 6 mois ; l'app est le facteur limitant.
- Séquence : socle & inventaire (M1) → sync + identités + SSO (M2) → sécurité CA / PIM / MFA (M3) → postes Intune + rejeu GPO (M4) → migration partages + traitement app (M5) → convergence, vérification des conditions, décommission DC (M6). Les postes Intune (M4) précèdent le CA « compliant device » effectif ; le décommission (M6) suppose M2-M5 aboutis.
- App LDAP : privilégier une réécriture vers une auth moderne (OIDC / SAML via Entra) ou un remplacement. Si impossible à court terme : la maintenir en hybride (l'AD reste pour elle), ou l'isoler sur une VM Azure (lift & shift ciblé) le temps de la sortie. Elle empêche le décommission tant qu'elle en dépend.
- Conditions avant extinction du DC : plus aucune app / poste ne s'authentifie contre l'AD ; partages migrés ; GPO rejouées en Intune ; postes joints Entra ; sync non nécessaire ou bascule cloud maîtrisée ; sauvegardes et période d'observation (DC débranché testable) pour garder la réversibilité.