Outil gratuit
CSP Management Advisor
Combien de policies, et comment les découper ?
Migrer des GPO vers des CSP n'est pas qu'un exercice de correspondance paramètre par paramètre. La question qui coûte cher arrive après : comment découper les paramètres en policies pour que le locataire reste gérable, sans conflits silencieux. Cet outil compare les trois structures possibles avec vos propres chiffres, écrit le fichier de suivi qui va avec, et cherche dans vos policies existantes les paramètres portés deux fois.
Aucune inscription, aucun cookie : ce que vous saisissez reste dans votre navigateur et s'efface quand vous fermez l'onglet — rien n'en sort. Seule la visite est comptée, par une mesure d'audience sans cookie qui ne vous identifie pas, décrite dans les mentions légales. Les noms de paramètres que vous collez ci-dessous ne sortent pas de la page.
Votre parc de politiques
Quatre nombres et cinq réponses. Les nombres n'ont pas besoin d'être exacts : ce sont les ordres de grandeur qui font basculer une structure, pas l'unité près.
Le volume à migrer
Ce qui diffère
La gouvernance en place
La structure recommandée
L'outil raisonne sur des volumes, pas sur vos paramètres. Il ne dit pas quel CSP remplace quelle GPO : cette correspondance se fait paramètre par paramètre, et Group Policy Analytics est l'endroit où commencer. Ce qu'il dit, c'est comment ranger le résultat pour que le locataire reste gérable dans deux ans.
Le détecteur de conflits compare des NOMS de paramètres, pas des valeurs, et seulement ceux que vous avez collés. Deux policies qui portent le même paramètre avec la même valeur ne sont pas un conflit ; deux qui le portent avec des valeurs différentes en sont un, et aucun des deux ne s'applique. Le rapport d'état de la policy, dans la console, reste la seule source qui le confirme.
Détecteur de conflits
Déclarez vos policies cibles : un nom, la population visée, et la liste de leurs paramètres — un par ligne, telle qu'un export du catalogue de paramètres ou un rapport Group Policy Analytics vous la donne. Tout paramètre porté par deux policies qui visent la même population est signalé. Laissez la population vide, ou écrivez « tous », pour une policy affectée à tout le monde.
La stratégie
Trois structures, et le vrai sujet : les conflits
La question n'est pas « comment éviter tout conflit » — c'est impossible à garantir. C'est « quelle structure rend les conflits rares, visibles et faciles à corriger ».
Le point décisif : Intune n'arbitre pas les conflits
Deux profils qui fixent la même valeur sur le même paramètre, pour le même appareil ou le même utilisateur, entrent en conflit. En cas de conflit direct, AUCUN des deux paramètres n'est appliqué — ni l'un, ni l'autre — et AUCUNE alerte n'est visible pour l'utilisateur final. Seul le rapport d'état de la policy le montre, si quelqu'un va le consulter.
C'est pour cela que la question n'est pas « comment éviter tout conflit », qui est impossible à garantir, mais « quelle structure rend les conflits rares, visibles et faciles à corriger ». Trois structures y répondent différemment.
Cinq étapes, dans l'ordre
- Inventorier — extraire l'ensemble des GPO et la liste exhaustive des paramètres — une ligne par paramètre, pas par GPO.
- Qualifier chaque paramètre — viable tel quel, viable avec écart, non applicable, ou à abandonner.
- Regrouper par fonction — BitLocker, Delivery Optimization, pare-feu — une ou plusieurs policies cibles par fonction.
- Construire les policies cibles — c'est ici que se joue la question structurelle : socle unique, ou socle et déclinaisons ?
- Suivre le cycle POC → PILOT → Production — chaque policy cible, commune ou différentielle, suit le même cycle de promotion.
A — Duplication complète par population
Une policy entière par population, chacune portant TOUS les paramètres — y compris les identiques.
Avantages
- Isolation totale : modifier une population ne peut pas en affecter une autre.
- Facile à comprendre : une policy, une population.
- Cohérent avec un cycle de promotion POC/PILOT/Production.
Inconvénients
- Le nombre d'objets explose avec le nombre de populations.
- Une mise à jour commune doit être répétée dans chaque copie — un oubli est indétectable sans audit.
- Le risque ne disparaît pas, il se déplace : la dérive entre copies devient le nouveau conflit potentiel.
B — Socle commun + policies différentielles
Une policy « Commun » porte tout ce qui est identique. Un paramètre qui doit différer est RETIRÉ du socle et vit seul dans une policy différentielle ciblée.
Exemple : un socle Delivery Optimization garde les 119 paramètres identiques partout ; celui qui doit changer pour un site sort du socle et vit seul dans une policy « Site X », affectée uniquement à ce site.
Avantages
- Pas de duplication massive : une seule source pour le commun.
- Le nombre de policies différentielles suit les exceptions réelles, pas le nombre de populations.
- Rend visible, par construction, ce qui est réellement spécifique.
Inconvénients
- Discipline stricte requise : réintroduire un paramètre différentiel dans le socle recrée un conflit.
- La correspondance « quel paramètre vit où » doit être documentée en continu.
- Exige une exclusion propre du socle pour chaque population concernée.
C — Policy globale + exclusion + policy de site
La policy globale reste inchangée pour tout le monde ; la population concernée en est exclue ; une policy complète la couvre à la place.
Avantages
- Défendable pour une exception unique, sur un périmètre restreint et stable.
- Peu de risque de dérive avec un seul objet à surveiller.
Inconvénients
- Dès une deuxième exception, elle cumule les inconvénients de A — la duplication — sans le bénéfice de B — la source unique.
- C'est un état transitoire vers A ou vers B, pas un choix durable.
Ce avec quoi on inventorie et on convertit
| Outil / approche | Ce qu'il apporte | Coût | Quand l'utiliser |
|---|---|---|---|
| Group Policy Analytics | Importe un rapport GPO et signale l'équivalent CSP connu, paramètre par paramètre. | Inclus dans la licence Intune | Toujours en premier |
| Fichier de suivi | Trace les décisions humaines : viabilité, propriétaire, statut, phase. | Temps interne | En continu — c'est le pivot organisationnel |
| Outils tiers de migration GPO | Accélèrent la conversion en masse sur de gros volumes hétérogènes. | Sur devis — pas de tarif public fiable | Si le volume dépasse ce qu'un inventaire manuel absorbe |
| Pilote sur périmètre réduit | Valide le mapping et la structure avant généralisation. | Temps interne | Avant toute bascule en production |
Le fichier de suivi : une ligne par paramètre
Ni par GPO, ni par policy. C'est la granularité qui répond aux deux dimensions du sujet, la technique et l'organisationnelle — et la seule qui réponde à « où vit ce paramètre » le jour d'un conflit. Le bouton « Fichier de suivi (CSV) » plus haut en exporte le squelette.
| Colonne | Contenu |
|---|---|
| GPO source | Nom de la GPO et chemin du paramètre |
| Paramètre | Libellé exact du paramètre |
| CSP cible | OMA-URI ou paramètre du catalogue Intune équivalent, si connu |
| Statut de viabilité | Viable / Viable avec écart / Non applicable / À abandonner |
| Policy porteuse | Commun, ou nom de la population pour une différentielle |
| Phase | POC / PILOT / Production |
| Propriétaire métier | Qui valide ce paramètre |
| Dernier test / Commentaire | Traçabilité et écarts constatés |
Trois règles de gouvernance qui évitent la plupart des incidents
Tester un paramètre du socle en l'EXCLUANT du socle pour le groupe de test — jamais en le dupliquant sans exclusion : une duplication sans exclusion est la définition même d'un conflit direct.
Le repli reste le retrait d'affectation ; l'export du contenu des policies est la seule source de reconstruction fiable. Et toute nouvelle policy différentielle est référencée dans le fichier de suivi dès sa création, pas après.
Ce qui reste à décider chez vous
- Le seuil de bascule de A vers B — nombre de populations et nombre de paramètres qui varient — l'outil ci-dessus propose une lecture, votre gouvernance tranche.
- Qui valide qu'un paramètre est « non applicable » — c'est une décision métier, pas technique, et elle doit être tracée.
- Le périmètre que le fichier de suivi couvre en premier — tout ouvrir d'un coup est le meilleur moyen de ne rien tenir à jour.
- Si le volume justifie un outil tiers — sur devis réel, jamais sur un tarif catalogue.