Chaque agent Copilot Studio créé avant mai 2026 repose sur une inscription d’application Azure que votre locataire héberge sans jamais l’étiqueter comme agent. Microsoft les convertit en identités Microsoft Entra Agent ID, et aucune date de fin n’est annoncée pour la migration automatique. Voici comment inventorier ces agents, constituer des lots et répéter la bascule dans un tenant de test avant qu’elle ne vous rattrape en production.

Ce qui s’est passé depuis mars 2026, et ce qui reste flou
Les pages de documentation Microsoft ne racontent pas tout à fait la même chronologie. Voici ce que l’on peut établir à la date du 24 octobre 2026.
18 mars 2026
Déploiement automatique de l’Agent ID pour les nouveaux agents
Selon la documentation Microsoft Entra, c’est la date à laquelle les nouveaux agents Copilot Studio ont commencé à recevoir une identité Agent ID automatiquement.
Mai 2026
Fin de l’option de refus
Selon la documentation Copilot Studio, chaque nouvel agent reçoit directement une identité Entra Agent ID, et l’option de désactivation au niveau de l’environnement n’existe plus.
24 août 2026
Migration libre-service dans Power Platform Advisor
Le message center MC1478488 indique que le déploiement graduel a commencé à cette date.
Septembre 2026
Migrations automatiques par Microsoft
Le même avis précise que les migrations automatiques des agents existants ont débuté ce mois-là. Aucune date de fin n’est donnée.

La migration manuelle, elle, reste en préversion : la documentation Copilot Studio la présente comme un moyen de valider le comportement des agents avec Agent ID et l’accès conditionnel avant la bascule. D’où l’intérêt d’un tenant de test : vous ne choisissez pas la date de la migration automatique, mais vous pouvez choisir d’avoir déjà observé ses effets.
Deux pages Microsoft se contredisent sur la méthode
Une page de la documentation Entra décrit une voie « recréer puis déclasser », indique qu’il n’existe pas de conversion sur place et déconseille de recréer les agents fortement utilisés en production. La page de migration Copilot Studio décrit au contraire une conversion qui conserve l’identifiant d’application et supporte le rollback. La seconde étant plus récente que la première, c’est elle qui sert de référence ici. Dans tous les cas, ne recréez pas vos agents à forte utilisation.
Ce que l’identité d’agent apporte, et ce qu’elle laisse intact
L’Agent ID de Copilot Studio est un principal de service de sous-type « Agent ». Il utilise les mêmes flux OAuth que les inscriptions d’application : l’authentification de vos agents ne change donc pas. Le gain porte sur la gouvernance, pas sur le protocole.

| Aspect | Avant la migration | Après la migration |
|---|---|---|
| Type d’objet | Inscription d’application Azure | Identité d’agent (principal de service, sous-type Agent) |
| Identifiant d’application (client) | Identifiant existant | Conservé : canaux et connecteurs pointent toujours vers lui |
| Authentification | Flux OAuth | Mêmes flux OAuth |
| Gouvernance | Objet traité comme une application | Objet gouverné dans Entra : audit, cycle de vie, sponsor |
| Permissions des connecteurs | Lisibles dans le Centre d’administration Power Platform | Visibles aussi comme permissions d’API sur l’identité de l’agent |
Trois détails de fonctionnement conditionnent votre plan de test :
- Le premier agent créé ajoute au locataire un « Microsoft Copilot Studio agent identity blueprint », parent de toutes les identités d’agent de Copilot Studio.
- Chaque identité est un objet d’annuaire qui compte dans le quota du locataire : s’il est atteint, la création d’un agent échoue.
- Un agent qui utilise le harnais GitHub Copilot reçoit son identité à sa première publication, pas à sa création (voir notre article sur le harnais GitHub Copilot en disponibilité générale).
Chaque identité d’agent doit aussi avoir un sponsor humain, obligatoire à la création ; le propriétaire est recommandé. Si le sponsor quitte l’organisation, le parrainage passe à son manager. C’est la parade la plus nette contre les agents orphelins.
Prérequis avant de toucher au tenant de test
À réunir avant le premier script
- Un rôle Administrateur Power Platform, Administrateur Dynamics 365 ou Administrateur général pour utiliser la recommandation d’Advisor.
- L’inventaire Power Platform activé dans le locataire : sans lui, Advisor ne repère aucun agent admissible.
- La permission déléguée Microsoft Graph AgentIdentity.Read.All pour les scripts ; sans rôle de propriétaire, le rôle Entra Agent ID Administrator est nécessaire.
- Le module PowerShell Microsoft.Graph.Authentication.
- Dans le tenant de test, quelques agents qui couvrent vos canaux, vos modes d’authentification et vos connecteurs réels.
- Les concepteurs d’agents prévenus et une fenêtre de validation convenue.
Mise en œuvre
Les trois scripts ci-dessous forment une boucle : un instantané des identités d’agents, un plan de lots, puis une comparaison après la migration du lot pilote. Aucun n’écrit dans le locataire. Les scripts 2 et 3 ne se connectent à rien et travaillent sur des fichiers CSV locaux.
Pour installer le module requis :
1Install-Module Microsoft.Graph.Authentication -Scope CurrentUserScript 1 : instantané des identités d’agents
Le script interroge le point de terminaison Microsoft Graph v1.0 /servicePrincipals/microsoft.graph.agentIdentity, suit la pagination et produit un CSV horodaté. Permission minimale : AgentIdentity.Read.All en délégué. En sortie, vous obtenez un message indiquant le nombre d’identités exportées.
1<#2.SYNOPSIS3 Instantané en lecture seule des identités d'agents (Entra Agent ID).4.DESCRIPTION5 Lit GET /servicePrincipals/microsoft.graph.agentIdentity (Microsoft Graph v1.0).6 Permission déléguée requise : AgentIdentity.Read.All. Aucune écriture.7#>8[CmdletBinding()]9param(10 [string]$Path = ('./snapshot-{0}.csv' -f (Get-Date -Format 'yyyyMMdd-HHmm'))11)12 13# Connexion déléguée avec le seul scope de lecture nécessaire14Connect-MgGraph -Scopes 'AgentIdentity.Read.All' -NoWelcome15 16# Les $ sont conservés tels quels : la chaîne est entre apostrophes17$uri = 'https://graph.microsoft.com/v1.0/servicePrincipals/microsoft.graph.agentIdentity?$select=id,displayName,accountEnabled,createdDateTime,agentIdentityBlueprintId&$top=100'18$agents = [System.Collections.Generic.List[object]]::new()19 20# Parcours des pages tant qu'un lien @odata.nextLink est renvoyé21while ($uri) {22 $page = Invoke-MgGraphRequest -Method GET -Uri $uri23 foreach ($item in $page.value) {24 $agents.Add([pscustomobject]@{25 Nom = $item.displayName26 Id = $item.id27 Actif = $item.accountEnabled28 Cree = $item.createdDateTime29 Blueprint = $item.agentIdentityBlueprintId30 })31 }32 $uri = $page.'@odata.nextLink'33}34 35$agents | Sort-Object Cree | Export-Csv -Path $Path -NoTypeInformation -Encoding UTF836Write-Output ('{0} identités d agent exportées vers {1}' -f $agents.Count, $Path)Lancez-le une première fois avant toute migration, par exemple avec -Path ./avant.csv.
Script 2 : découper les agents en lots
Advisor propose un ordre de migration suggéré et des notes par agent. Ce script ajoute votre propre grille de risque. Vous lui fournissez un CSV que vous remplissez à partir du tableau d’Advisor et de vos échanges avec les concepteurs, avec les colonnes Nom, Canal, Authentification, Criticite (Faible, Moyenne ou Haute) et, si vous le souhaitez, Connecteurs. Le lot pilote reprend des agents de criticité faible, un par combinaison canal et authentification, puis les autres agents sont répartis par lots de taille fixe, du moins au plus critique.
1<#2.SYNOPSIS3 Construit un plan de migration par lots à partir d'un CSV d'agents.4.DESCRIPTION5 Colonnes obligatoires : Nom, Canal, Authentification, Criticite (Faible, Moyenne, Haute).6 Travaille uniquement sur des fichiers locaux.7#>8[CmdletBinding()]9param(10 [Parameter(Mandatory)][string]$InputPath,11 [string]$OutputPath = './plan-lots.csv',12 [int]$TaillePilote = 5,13 [int]$TailleLot = 1014)15 16$agents = @(Import-Csv -Path $InputPath -Encoding UTF8)17if ($agents.Count -eq 0) { throw 'Le fichier ne contient aucun agent.' }18 19# Contrôle des colonnes attendues20$colonnes = $agents[0].PSObject.Properties.Name21$manquantes = @('Nom', 'Canal', 'Authentification', 'Criticite') | Where-Object { $_ -notin $colonnes }22if ($manquantes) { throw ('Colonnes manquantes : {0}' -f ($manquantes -join ', ')) }23 24# Ordre de risque : on migre d'abord ce qui est le moins critique25$ordre = @{ 'Faible' = 1; 'Moyenne' = 2; 'Haute' = 3 }26foreach ($a in $agents) {27 if (-not $ordre.ContainsKey($a.Criticite)) {28 throw ('Criticité inconnue pour {0} : {1}' -f $a.Nom, $a.Criticite)29 }30}31$tries = $agents | Sort-Object -Property @{ Expression = { $ordre[$_.Criticite] } }, 'Nom'32 33# Lot pilote : un agent peu critique par combinaison canal et authentification34$pilote = @($tries |35 Where-Object { $_.Criticite -eq 'Faible' } |36 Group-Object -Property Canal, Authentification |37 ForEach-Object { $_.Group | Select-Object -First 1 } |38 Select-Object -First $TaillePilote)39 40$plan = [System.Collections.Generic.List[object]]::new()41foreach ($a in $pilote) {42 $plan.Add([pscustomobject]@{ Lot = 'Pilote'; Nom = $a.Nom; Canal = $a.Canal; Authentification = $a.Authentification; Criticite = $a.Criticite })43}44 45# Les agents restants sont répartis en lots de taille fixe46$restants = @($tries | Where-Object { $_.Nom -notin $pilote.Nom })47$i = 048foreach ($a in $restants) {49 $numero = [math]::Floor($i / $TailleLot) + 150 $plan.Add([pscustomobject]@{ Lot = ('Lot {0}' -f $numero); Nom = $a.Nom; Canal = $a.Canal; Authentification = $a.Authentification; Criticite = $a.Criticite })51 $i++52}53 54$plan | Export-Csv -Path $OutputPath -NoTypeInformation -Encoding UTF855$plan | Group-Object -Property Lot | Select-Object -Property Name, Count | Format-Table -AutoSize56Write-Output ('Plan écrit dans {0}' -f $OutputPath)En sortie, un tableau récapitule le nombre d’agents par lot, et le fichier plan-lots.csv sert de support à la fenêtre de validation.
Script 3 : comparer avant et après le lot pilote
Une fois le lot pilote migré, relancez le script 1 avec -Path ./apres.csv, puis comparez les deux instantanés. Le script affiche les identités apparues ou disparues, les identités désactivées et le nombre d’identités par blueprint. Si l’écart est vide alors que la migration est terminée dans Advisor, refaites un instantané plus tard : la documentation consultée ne donne pas de délai de propagation.
1<#2.SYNOPSIS3 Compare deux instantanés d'identités d'agents (script 1).4#>5[CmdletBinding()]6param(7 [Parameter(Mandatory)][string]$Avant,8 [Parameter(Mandatory)][string]$Apres9)10 11$avantCsv = @(Import-Csv -Path $Avant -Encoding UTF8)12$apresCsv = @(Import-Csv -Path $Apres -Encoding UTF8)13 14# Identités présentes d'un seul côté, repérées par leur Id d'objet15$ecarts = Compare-Object -ReferenceObject $avantCsv -DifferenceObject $apresCsv -Property Id -PassThru16 17Write-Output '--- Écarts entre les deux instantanés ---'18if ($ecarts) {19 $ecarts | Select-Object -Property @{ Name = 'Changement'; Expression = { if ($_.SideIndicator -eq '=>') { 'Nouvelle identité' } else { 'Identité disparue' } } }, Nom, Id, Blueprint | Format-Table -AutoSize20}21else {22 Write-Output 'Aucun écart.'23}24 25# Identités désactivées après migration26Write-Output '--- Identités désactivées dans le second instantané ---'27$apresCsv | Where-Object { $_.Actif -eq 'False' } | Select-Object -Property Nom, Id | Format-Table -AutoSize28 29# Répartition par blueprint : on doit retrouver celui de Copilot Studio30Write-Output '--- Identités par blueprint ---'31$apresCsv | Group-Object -Property Blueprint | Select-Object -Property Count, Name | Format-Table -AutoSizePourquoi aucun script d’écriture ici
La documentation Microsoft décrit des opérations migrate et rollback dans l’API Power Platform, en POST. Comme la fonction est en préversion, la recommandation d’Advisor reste la voie à privilégier ; consultez la page de migration pour la syntaxe exacte des API.
Migrer le lot pilote dans Advisor
Ouvrir la recommandation
Dans le Centre d’administration Power Platform, allez dans Actions, Recommandations, onglet Actif, puis ouvrez la recommandation « Migrate Copilot Studio agents to Microsoft Entra Agent ID for enhanced agent governance ».
Sélectionner le lot pilote
Le tableau fournit un ordre de migration suggéré et des notes pour chaque agent. Sélectionnez les agents du Pilote de votre plan-lots.csv : des agents non critiques qui couvrent vos canaux, modes d’authentification et connecteurs. Microsoft déconseille de tout migrer d’un coup.
Migrer, puis photographier
Lancez la migration du lot depuis ce tableau, puis exécutez le script 1 avec -Path ./apres.csv et le script 3.
Valider ou revenir en arrière
Si un agent échoue à la validation, arrêtez le déploiement et revenez à l’identité d’origine pour cet agent : le rollback est prévu, et l’identifiant d’application n’a pas changé.

Préversion : jamais de production en premier lot
La migration manuelle n’est pas destinée à la production, alors qu’elle touche des agents bien réels. Réservez-la au tenant de test et attendez la fin de la validation avant d’étendre à d’autres lots.
Valider chaque lot : canaux, journaux et accès conditionnel
Un agent qui répond dans la fenêtre de test peut rester muet dans Teams si une politique d’accès conditionnel bloque l’authentification requise. Contrôlez donc chaque canal réel, pas seulement le test intégré, puis consultez les journaux de connexion dans Microsoft Entra.
Contrôles après chaque lot
- L’agent répond dans tous ses canaux, y compris Teams.
- Ses actions et ses flux s’exécutent.
- L’authentification fonctionne ; les journaux de connexion Entra ne montrent aucun blocage inattendu.
- Le script 3 montre l’identité attendue et le bon blueprint.
- Chaque identité a un sponsor, et un propriétaire si possible.

Quand vous passerez aux politiques, gardez en tête les limites décrites par la documentation Microsoft Learn sur l’accès conditionnel pour les agents :
- Licence : ces politiques demandent Microsoft Agent 365, soit via Microsoft 365 E7 (qui inclut Agent 365 et Entra Suite), soit Agent 365 associé à au moins Entra P1 ou Microsoft 365 E3. Pour le contexte licences, voir notre article sur Agent ID Dataverse et les licences CSP E3.
- Flux OBO (on behalf of, au nom d’un utilisateur) : l’utilisateur est le sujet du jeton, donc une politique qui cible l’identité de l’agent ne couvre pas ces requêtes. Ciblez les utilisateurs.
- Politiques distinctes : il en faut pour l’identité de l’agent et pour son compte utilisateur.
- Clés d’API : un agent qui accède à une ressource avec une clé d’API contourne la délivrance de jetons Entra, et les politiques ne s’appliquent pas.
Pour le cadre global de gouvernance, notre guide sur Agent 365 et Entra Agent ID détaille l’articulation entre ces briques.
Dépannage : cinq symptômes fréquents
| Symptôme | Cause probable | Résolution |
|---|---|---|
| Advisor ne liste aucun agent admissible | Inventaire Power Platform désactivé dans le locataire | Activer l’inventaire Power Platform, puis rouvrir la recommandation |
| Le script 1 renvoie un accès refusé | Scope AgentIdentity.Read.All non consenti, ou rôle manquant | Reconnecter avec le scope, et attribuer Agent ID Administrator si vous n’êtes pas propriétaire |
| L’agent répond en test mais pas dans Teams | Politique d’accès conditionnel qui bloque l’authentification requise | Lire les journaux de connexion Entra, ajuster la politique, sinon rollback de cet agent |
| La création d’un nouvel agent échoue | Quota d’objets d’annuaire du locataire atteint | Faire le ménage dans les identités inutilisées |
| Une politique ne s’applique pas à un agent | Flux OBO, ou accès par clé d’API | Cibler les utilisateurs pour l’OBO ; privilégier Entra à la clé d’API |
Questions fréquentes
Puis-je refuser la migration automatique de mes agents ?
Les pages consultées n’indiquent aucun mécanisme de refus pour la migration automatique, ni de date de fin. Pour les nouveaux agents, l’option de désactivation de la création d’identités au niveau de l’environnement a disparu depuis mai 2026. La seule marge de manœuvre documentée est donc de migrer vous-même, avant Microsoft, dans de bonnes conditions.
L’authentification de mes agents change-t-elle après la migration ?
Non. L’Agent ID de Copilot Studio utilise les mêmes flux OAuth que les inscriptions d’application, et l’identifiant d’application (client) est conservé. Les inscriptions de canaux et les connecteurs qui s’y réfèrent continuent de pointer vers le même identifiant.
Faut-il une licence particulière ?
La migration elle-même n’est pas associée à une licence dans les pages consultées. Les politiques d’accès conditionnel conçues pour les agents demandent en revanche Microsoft Agent 365, via Microsoft 365 E7 ou Agent 365 avec au moins Entra P1 ou Microsoft 365 E3.
Que devient un agent dont le sponsor quitte l’entreprise ?
Selon la documentation Entra, le parrainage passe au manager du sponsor. Vérifiez néanmoins vos sponsors à chaque lot, car un sponsor est obligatoire à la création de l’identité.
Trois actions pour démarrer cette semaine
Prochaines actions
- Exécuter le script 1 dans le tenant de test et conserver
avant.csv. - Remplir le CSV d’agents avec les concepteurs, puis générer le plan avec le script 2.
- Migrer le lot pilote dans Advisor, valider chaque canal, puis comparer avec le script 3.
Si votre organisation compte déjà des agents à forte utilisation en production, planifiez la validation avant de reproduire les mêmes lots chez vous. Si vous ne disposez pas de la licence Agent 365, faites quand même l’inventaire et attribuez les sponsors : la visibilité dans Entra est acquise, les politiques viendront ensuite.
Pour aller plus loin
- Migrer des agents Copilot Studio vers Microsoft Entra Agent ID : la procédure dans Advisor, les prérequis, les API migrate et rollback et le dépannage.
- Agent identities and authentication for Copilot Studio : le moment de création de l’identité et la manière de retrouver l’Agent ID d’un agent.
- Manage Entra Agent IDs (Copilot Studio) : le blueprint, le rattrapage des agents existants et la fin de l’option de refus.
- Conditional Access for Agents in Microsoft Entra : licences, modèles d’accès et limites des politiques.
- List agentIdentities (Microsoft Graph v1.0) : la référence de l’API utilisée dans le script d’inventaire.



