Fini les scripts PowerShell : automatisez votre migration M365

Si vous etes consultant IT et que vous gerez des migrations Microsoft 365 tenant-to-tenant, il y a de fortes chances que vous ayez un dossier rempli de scripts PowerShell. Des scripts pour lister les utilisateurs, changer les UPN, attribuer les licences, configurer les alias, verifier le flux mail... Chaque migration, vous les ressortez, les adaptez, priez pour qu'ils fonctionnent, et passez des heures a debugger quand ce n'est pas le cas. Il est temps de passer a autre chose.

Le problème avec les scripts PowerShell

Ils sont fragiles

Les modules PowerShell pour Microsoft 365 changent regulierement. Ce qui fonctionnait avec le module AzureAD ne fonctionne plus avec Microsoft.Graph. Les cmdlets sont dépréciées, renommées ou supprimées. Chaque mise a jour de module peut casser vos scripts.

Microsoft a annonce la depreciation du module AzureAD PowerShell en mars 2024 au profit du SDK Microsoft Graph PowerShell. Si vos scripts utilisent encoreConnect-AzureAD,Get-AzureADUser ouSet-AzureADUser, ils sont en sursis.

Pas de rollback

Quand un script PowerShell change l'UPN de 200 utilisateurs et que quelque chose tourne mal au 150e, comment faites-vous pour revenir en arrière ? Il faut écrire un autre script de rollback, en espérant ne pas introduire de nouveaux bugs. Et il faut savoir exactement où le script s'est arrêté, quels utilisateurs ont été modifiés et lesquels ne l'ont pas été.

Pas de visibilite en temps reel

Quand un script tourne dans une fenetre PowerShell sur votre poste, personne d'autre ne peut voir ce qui se passe. Le chef de projet ne sait pas ou en est la migration. Le client ne peut pas suivre en temps réel. Et si votre poste plante ou perd la connexion reseau, vous perdez tout le contexte.

Difficiles a maintenir et a partager

Chaque consultant a ses propres scripts, adaptes a sa maniere. Quand un collegue reprend un projet, il doit comprendre et adapter les scripts existants (ou repartir de zero). Il n'y a pas de standardisation, pas de documentation, et souvent des mots de passe en dur dans les fichiers.

Pas d'audit trail

Qui a execute quoi, quand, sur quel tenant ? Avec des scripts, vous n'avez aucune trace structuree. Pas de logs centralises, pas d'historique des actions, pas de rapport automatique pour le client. Tout est dans la memoire du consultant (et dans son terminal ferme depuis longtemps).

L'alternative : Microsoft Graph API

Microsoft Graph API est l'API unifiee de Microsoft pour interagir avec tous les services Microsoft 365 : Entra ID, Exchange Online, SharePoint, OneDrive, Teams, et plus encore. C'est l'API qui remplace progressivement tous les modules PowerShell spécifiques.

Les avantages de Graph API par rapport a PowerShell :

• API stable et versionee : les endpoints sont versiones (v1.0, beta), avec une depreciation propre et documentee.
• Authentification OAuth moderne : plus besoin de stocker des credentials. Token OAuth avec des scopes precis.
• Aucun agent a installer : tout passe par des appels HTTPS. Pas de module a installer sur le poste du consultant.
• Multi-plateforme : fonctionne depuis n'importe quel OS, navigateur ou serveur.
• Batch et pagination : gestion native des gros volumes avec le batching JSON et la pagination automatique.

Comparaison concrete : 5 operations courantes

1. Lister les utilisateurs du tenant

Connect-AzureAD
Get-AzureADUser -All $true | Select UPN, DisplayName, Licenses

GET /users?$select=userPrincipalName,displayName,assignedLicenses

Avec Graph API, un seul appel HTTP suffit. Pas de module a importer, pas de session a etablir. Le token OAuth est obtenu via MSAL (PKCE pour les apps web, client credentials pour les services).

2. Changer l'UPN d'un utilisateur

Set-AzureADUser -ObjectId $userId \
  -UserPrincipalName "jean@fabrikam.com"

PATCH /users/{id}
{ "userPrincipalName": "jean@fabrikam.com" }

3. Attribuer une licence

$license = New-Object Microsoft.Open.AzureAD\
  .Model.AssignedLicense
$license.SkuId = $skuId
$licenses = New-Object Microsoft.Open.AzureAD\
  .Model.AssignedLicenses
$licenses.AddLicenses = $license
Set-AzureADUserLicense -ObjectId $userId \
  -AssignedLicenses $licenses

POST /users/{id}/assignLicense
{ "addLicenses": [{ "skuId": "..." }],
  "removeLicenses": [] }

Le contraste est frappant. 7 lignes de PowerShell avec des types .NET obscurs contre 3 lignes de JSON lisible. Et la version Graph API est auto-documentee par le schema.

4. Bloquer la connexion d'un utilisateur

PATCH /users/{id}
{ "accountEnabled": false }

Une seule ligne. Reversible instantanement en passant true.

5. Operations en batch

Graph API supporte nativement le batching JSON ($batch endpoint) : vous pouvez envoyer jusqu'a 20 operations en un seul appel HTTP. Pour changer l'UPN de 200 utilisateurs, ce sont 10 appels batch au lieu de 200 appels PowerShell sequentiels.

Le vrai game-changer : l'interface web

L'automatisation via Graph API est un premier pas, mais le vrai changement de paradigme vient de l'interface web qui orchestre ces appels API. C'est la difference entre "appeler Graph API depuis un script Python" et "utiliser une plateforme SaaS qui le fait pour vous avec une UI".

Une plateforme comme MigrateKit offre :

• Runbook interactif : chaque étape de la migration est une action cliquable, avec validation automatique, logs en temps réel et rollback en un clic.
• Visibilité partagée : le chef de projet et le client voient l'avancement en temps réel depuis n'importe quel navigateur.
• Audit trail complet : chaque action est loguee avec horodatage, utilisateur concerne et resultat.
• Aucune installation : tout tourne dans le navigateur. Pas de module PowerShell, pas de SDK, pas d'agent tenant.
• Reversibilite totale : chaque action executee a un bouton "Rollback" qui annule l'operation.

Mais est-ce que Graph API couvre tout ?

C'est la question legitime. La reponse est : pour les migrations tenant-to-tenant, oui. Les operations courantes sont toutes couvertes par Graph API v1.0 :

• CRUD utilisateurs (creation, modification UPN, suppression)
• Gestion des licences (attribution, suppression, verification)
• Gestion des groupes et des membres
• Configuration des alias SMTP (proxyAddresses)
• Activation/desactivation des comptes
• Lecture des applications d'entreprise et des service principals
• Invitation d'utilisateurs guests (B2B)
• Lecture des sites SharePoint et des drives OneDrive

Les seules operations qui restent hors de portee de Graph API sont les modifications DNS (qui se font chez le registrar) et certaines configurations Exchange avancees (qui nécessitent encore Exchange Online PowerShell). Mais ces cas sont marginaux dans une migration standard.

Conclusion : le script est mort, vive l'API

Les scripts PowerShell ont rendu de grands services pendant des annees. Mais en 2026, avec la depreciation des anciens modules, la maturite de Graph API et l'emergence de plateformes SaaS dediees, il n'y a plus de raison de passer des heures a maintenir des scripts fragiles et non partageables.

L'approche moderne pour un consultant IT, c'est :

1. Se connecter au tenant via OAuth (MSAL PKCE).
2. Inventorier automatiquement via Graph API.
3. Configurer les modes de migration dans une interface web.
4. Exécuter le runbook étape par étape avec rollback.
5. Générer automatiquement toute la documentation.

C'est exactement ce que fait MigrateKit. Zero script, zero installation, zero stress.