Gérer le cycle de vie des modèles d’IA pour les agents de Copilot Studio

Copilot Studio propose différents types de modèles. Ces types de modèles sont basés sur leur usage prévu et leur disponibilité. La sélection de modèles IA n’est pas une décision de conception ponctuelle. Les modèles sont introduits, mis à jour, rendus généralement disponibles, définis par défaut, puis finalement retirés. Un agent qui fonctionne bien avec un modèle peut se comporter complètement différemment avec un autre, même un modèle de la même famille de modèles.

Considérez la gestion du cycle de vie du modèle comme une pratique opérationnelle continue pour chaque agent de production du Copilot Studio. Établir un processus reproductible pour découvrir les changements de modèle, évaluer les modèles candidats, préparer les départs à la retraite, migrer les agents concernés et surveiller la qualité après le déploiement.

Changer le modèle utilisé par un agent est rarement un simple changement de sélection de modèle. Un modèle plus récent peut interpréter les instructions plus littéralement, choisir les outils différemment, produire des longueurs et des formats de réponse différents, et modifier la latence. Planifiez chaque changement de modèle comme une migration incluant évaluation, affinement des instructions et des outils, approbation et suivi post-déploiement.

Le principe directeur consiste à concevoir une architecture flexible, à opérer avec prudence et à soumettre chaque mise à niveau à une évaluation. Passer à chaque nouveau modèle risque d’entraîner des régressions silencieuses. Éviter tout changement de modèle garantit une urgence à l’arrivée de la retraite.

Appliquez le cycle de vie suivant aux agents de production :

1. Découvrez les modèles neufs, mis à jour, par défaut et en voie de retraite.
2. Inventez les agents, les environnements, les propriétaires et les processus métier qui dépendent de chaque modèle.
3. Évaluer les modèles de remplacement des candidats selon une base établie.
4. Approuvez la migration en utilisant des critères de qualité et d’exploitation documentés.
5. Déployez le processus de gestion du cycle de vie des applications (ALM) de l’organisation.
6. Surveillez les résultats de production et ajoutez les nouveaux scénarios découverts à la suite de régression.
7. Répétez le processus au fur et à mesure que les modèles et les besoins des agents évoluent.

Cet article traite de la découverte et de l’inventaire. La série se poursuit ainsi :

• Décidez quand mettre à jour un modèle d’IA : Décision de mise à niveau, prérequis et réponse aux départs à la retraite.
• Exécuter et valider une migration de modèle : évaluation, approbation, déploiement et surveillance.

La gestion du cycle de vie du modèle nécessite une coordination entre les propriétaires d’agents, les fabricants, les administrateurs de plateforme, les testeurs, les équipes sécurité et conformité, ainsi que les approbateurs de publication. Attribuez la propriété avant qu’un changement de modèle ne crée une migration urgente.

Comprendre le paysage du modèle

Avant de pouvoir planifier un changement de modèle, vous devez savoir comment Copilot Studio classe les modèles, quels modèles votre organisation peut réellement utiliser, et quels agents dépendent de chacun.

Comprendre les types de versions des modèles

Copilot Studio identifie les modèles par classification de sortie et de disponibilité. Ces classifications aident à déterminer comment gouverner un modèle et où l’utiliser. Les noms des modèles, les stades de sortie, la disponibilité régionale et le statut de retraite changent au fil du temps. Vérifiez toujours la disponibilité des modèles par région pour obtenir des informations actuelles au lieu de vous fier à une liste statique de modèles.

Un agent qui utilise le modèle par défaut passe à un nouveau modèle dès que le modèle par défaut est mis à jour, que vous l’ayez prévu ou non. Pour les agents à haut risque et à grand volume, sélectionnez un modèle spécifique plutôt que de suivre le modèle par défaut, afin que chaque changement de modèle passe par votre processus de migration.

Associer la catégorie d’utilisation du modèle à l’objectif de l’agent

Copilot Studio étiquete chaque modèle avec une catégorie d’utilisation qui décrit ce pour quoi le modèle est optimisé. Choisir la bonne catégorie pour la charge de travail de l’agent influence la qualité, la latence et la consommation de crédits.

• Deep : Optimisé pour un raisonnement délibéré, en plusieurs étapes et des flux de travail supportés par outils. Idéal pour l’analyse complexe, l’analyse de politiques et la synthèse de documents. Affiche la latence et la consommation de crédit les plus élevées.
• Automatique : Couvre les charges de travail mixtes en routant dynamiquement les requêtes. Idéal pour les agents du helpdesk et des employés avec une complexité de requête imprévisible ou variable. La latence et le coût varient selon les tours.
• Général : Optimisé pour la vitesse et le coût dans les conversations quotidiennes et un ancrage léger. Idéal pour la rédaction, le résumé, les réponses de type FAQ et l’automatisation simple d’actions. Latence et consommation de crédits les plus faibles.

En savoir plus dans les catégories d’utilisation des modèles.

Comprendre les modèles externes et les contrôles administrateurs

Vous pouvez utiliser des modèles provenant de fournisseurs externes tels qu'Anthropic, xAI et Mistral comme modèle principal d'un agent. En savoir plus dans Choisissez un modèle externe comme modèle principal d’IA.

Les paramètres administrateur contrôlent quels fabricants de modèles peuvent sélectionner dans un environnement. Un modèle documenté comme disponible peut toujours être indisponible pour l’agent que vous migrez si le paramètre requis n’est pas activé.

Avant de planifier une migration, vérifiez que le modèle candidat est disponible pour le fabricant dans l’environnement cible. La liste des modèles dans Copilot Studio reflète vos paramètres d’administrateur et constitue la réalité fondamentale sur ce qu’un agent spécifique peut utiliser. En savoir plus sur les contrôles administratifs pour la sélection des modèles d’IA.

Vérifiez régulièrement la disponibilité des modèles

Examinez régulièrement le modèle d’IA principal pour votre agent . C’est la source faisant autorité pour la liste actuelle des modèles. De nouveaux modèles apparaissent à leur introduction, et les modèles existants sont mis à jour au fur et à mesure qu’ils deviennent généralement disponibles, deviennent les valeurs par défaut ou sont retirés.

Utilisez ensemble les sources suivantes :

Déclenchez également une révision lorsque :

• Un modèle pertinent devient disponible en aperçu ou en général.
• Le modèle par défaut change.
• La mise hors service d’un modèle ou une mise à niveau automatique est annoncée.
• Un modèle devient disponible dans la région de l’organisation.
• L’organisation permet le traitement inter-géo, des modèles externes, ou des modèles d’aperçu et expérimentaux.
• La surveillance de la production identifie une préoccupation de qualité, de latence, de fiabilité ou de consommation qu’un autre modèle pourrait répondre.

Tenir un inventaire de mannequins et d’agents

Utilisez les inventaires d’agents fournis dans le centre d’administration Power Platform, la CLI Power Platform ou les API Power Platform pour identifier les agents utilisant un modèle spécifique. Utilisez ces informations pour engager la communication relative au cycle de vie du modèle avec les responsables métier et techniques concernés.

Utilisez l’une des vues suivantes dans le centre d’administration Power Platform :

Interrogez l’API d’inventaire pour trouver les agents par modèle

Les vues du centre d’administration Power Platform sont efficaces pour examiner et exporter manuellement les résultats. Interrogez plutôt l’API d’inventaire lorsque vous souhaitez collecter les mêmes informations de façon programmatique, afin que l’énumération des agents puisse être scriptée, planifiée et répétée sur tout le locataire au lieu de télécharger les rapports à la main. Les organisations disposant d’un important patrimoine d’agents peuvent utiliser cette approche pour actualiser la liste des agents concernés à la demande lors d’une migration à la retraite et la maintenir à jour entre les événements du cycle de vie.

L’API d’inventaire renvoie le nom de l’agent, le nom affiché, l’environnement et le modèle configuré dans une requête à l’échelle du locataire unique, de sorte qu’aucune corrélation avec une autre source de données n’est requise.

Avant de lancer la requête :

• Connectez-vous avec un compte qui a le rôle d’administrateur Power Platform ou d’administrateur Dynamics 365.
• Acquérez un jeton d’accès pour la https://api.powerplatform.com/ ressource.
• Confirmez que l’inventaire de l’agent est activé pour le locataire.

Envoyez une requête POST au point de terminaison de requête de ressources, filtrez selon le microsoft.copilotstudio/agents type de ressource, et projetez les champs dont vous avez besoin, y compris properties.model:

POST https://api.powerplatform.com/resourcequery/resources/query?api-version=2024-10-01
Authorization: Bearer <access-token>
Content-Type: application/json

{
  "TableName": "PowerPlatformResources",
  "Clauses": [
    {
      "$type": "where",
      "FieldName": "type",
      "Operator": "in~",
      "Values": ["'microsoft.copilotstudio/agents'"]
    },
    {
      "$type": "project",
      "FieldList": [
        "name",
        "properties.displayName",
        "properties.model",
        "environmentId = tostring(properties.environmentId)"
      ]
    }
  ],
  "Options": { "Top": 200 }
}

La réponse renvoie un enregistrement par agent. Les noms de champ dans la réponse remplacent le point par un trait de soulignement, ainsi properties.model est renvoyé sous la forme properties_model :

{
  "totalRecords": 158,
  "count": 200,
  "data": [
    {
      "name": "00000000-0000-0000-0000-000000000000",
      "properties_displayName": "Sample Agent",
      "properties_model": "GPT-5 Auto",
      "environmentId": "00000000-0000-0000-0000-000000000000"
    }
  ]
}

La réponse inclut totalRecords et, lorsque les résultats sont tronqués, une skipToken valeur. Transférez cette valeur Options.SkipToken et répétez la requête jusqu’à ce que tous les enregistrements soient récupérés.

Regroupez les enregistrements collectés par properties_model pour voir où chaque modèle est utilisé au sein du locataire. L’exemple suivant montre le nombre d’agents par modèle pour un locataire, en excluant les agents qui utilisent le modèle par défaut de Copilot Studio ou qui fonctionnent dans l’expérience Microsoft 365 Copilot :

Model                  Count
-----                  -----
Claude Sonnet 4.6         24
GPT-5 Chat                22
GPT-5.5 Chat               5
GPT-5 Auto                 4
Claude Sonnet 4.5          3
Claude Opus 4.6            2
Claude Opus 4.7            1
Claude Opus 5              1
Claude Sonnet 5            1
GPT-4o                     1
GPT-5.6 Reasoning          1

Lorsqu’une retraite est annoncée, filtrez le même ensemble de résultats sur le modèle de départ à la retraite pour produire la liste des agents concernés, leurs environnements et leurs identifiants d’agent. Utilisez cette environmentId valeur pour mapper chaque agent à un environnement nommé, puis acheminez les résultats vers les propriétaires de ces environnements. En savoir plus dans Répondre à un modèle de retraite pour la réponse complète à la retraite.

Pour en savoir plus :

• API d’inventaire Power Platform
• Informations de référence sur le schéma d’inventaire Power Platform

Utilisez l’interface CLI Power Platform pour afficher les détails d’un environnement

Utilisez pac copilot list lorsque vous avez besoin des agents et du contexte de la solution pour un seul environnement, par exemple lorsque vous préparez une migration dans un environnement :

pac copilot list --environment <environment-id-or-url>

La commande renvoie le nom de l’agent, l’ID Copilot, l’état du composant, l’état géré, l’ID de la solution, le code d’état et le code d’état. Cette sortie n’inclut pas le modèle, donc utilisez l’API d’inventaire pour identifier les agents par modèle. Utilisez pac admin list pour récupérer les noms et identifiants des environnements.

Que noter pour chaque agent

Le modèle seul ne suffit pas à planifier une migration. Notez ce qui suit pour chaque agent, afin que, lors de l’annonce d’une retraite, vous sachiez déjà qui contacter et quel travail chaque agent doit faire :

• Nom de l’agent, identifiant de l’agent, environnement et type d’environnement, tels que développement, test ou production.
• Critique commerciale.
• Responsable métier, responsable technique, testeur et approbateur de la mise en production.
• Le modèle configuré et son tag de libération.
• Que l’agent utilise le modèle par défaut ou un modèle spécifique sélectionné.
• Exigences de traitement inter-géo et contraintes régionales.
• Que l’agent soit alimenté par le faisceau standard ou par le faisceau GitHub Copilot, qui détermine les méthodes de test d’évaluation disponibles. En savoir plus sur les harnais Copilot Studio.
• Le test de régression a établi l’emplacement et la date de la dernière exécution de base.
• Si la fenêtre du modèle retiré est utilisée, à quelle date elle expire, et qui l’a approuvée.

Étape suivante

Avec le paysage des modèles bien compris et l’inventaire de vos agents en place, utilisez les critères de décision pour déterminer si une mise à niveau est nécessaire.

Informations associées

• Suivre, gérer et mettre à l’échelle l’adoption de Copilot dans Power Platform