Le 8 octobre 2026, le blogue Copilot Studio a publié un billet signé Gary Pretty qui tombe à point pour les équipes qui ajoutent des agents un peu partout. Le point de départ est simple : donner plus de capacités à un agent ne le rend pas automatiquement plus fiable. Faire plus et faire la bonne chose de façon régulière sont deux propriétés différentes. Source : Are bigger agents better? How to design agents that scale (Copilot Studio Blog, 8 octobre 2026). Au moment d'écrire ces lignes le 19 octobre 2026, ces capacités de Copilot Studio continuent d'évoluer : vérifiez l'état exact dans votre locataire.
Ce qui change quand un agent grossit
Le billet prend l'exemple d'un agent d'intégration de fournisseurs. La première version recueille les détails du fournisseur, vérifie que la demande est complète et lance une approbation. Avec le temps, les créateurs ajoutent des outils pour l'ERP, la validation fiscale, le criblage de sanctions, la vérification bancaire, le stockage de contrats, les billets de service, le courriel et les rapports. Ils ajoutent des connaissances régionales et des instructions pour les cas d'exception. Une demande comme « intègre notre nouveau fournisseur » présente alors plusieurs outils de recherche qui se ressemblent et des sources de politiques qui se chevauchent.
Selon le billet, la difficulté d'échelle apparaît à quatre endroits :
- Sélection : des noms et des descriptions d'outils trop proches rendent la bonne action difficile à repérer.
- Contexte : les définitions d'outils, les instructions, les connaissances, l'historique de conversation et les sorties d'outils se disputent une fenêtre de contexte limitée.
- Exécution : plus de chemins possibles veut dire plus d'appels inutiles, de reprises et de résultats inégaux.
- Opérations : une plus grande surface de capacités est plus difficile à évaluer, à sécuriser, à gouverner et à maintenir.
Le billet cite aussi une observation de Microsoft Research : des outils qui fonctionnent bien séparément peuvent réduire la performance de bout en bout quand ils entrent en concurrence dans un ensemble large ou redondant. Souvent le problème n'est pas un mauvais outil : c'est l'ambiguïté entre plusieurs outils raisonnables.
Le coût qui vient avec le contexte
Il y a un coût direct à un jeu d'outils qui gonfle. D'après le billet, un outil consomme des jetons même quand il n'est jamais appelé, parce que son nom, sa description et le schéma de ses paramètres font partie du contexte présenté au modèle. Quand il est appelé, sa sortie s'ajoute au contexte courant. Plus de contexte peut vouloir dire plus de dépense en même temps qu'une sélection moins fiable.
Pour un responsable TI de PME, ce point rejoint directement la facturation. La documentation Microsoft décrit la facturation à l'usage en crédits Copilot pour certaines expériences agentiques et indique que les administrateurs doivent configurer une politique de facturation avant qu'un utilisateur puisse se servir des expériences qui l'exigent. Aucun prix n'est publié sur cette page : voir User subscription license and usage-based billing. Autrement dit, un agent plus gros soulève deux enjeux à la fois : la fiabilité et la dépense à encadrer avant son déploiement.
Choisir le bon composant pour chaque responsabilité
Le billet propose de décider quelle partie du système possède chaque responsabilité plutôt que de tout empiler dans un seul agent :
- Un outil pour une action ou une recherche bornée, avec une entrée et une sortie claires.
- Un workflow quand une séquence, une approbation ou une règle d'affaires doit s'exécuter de façon constante.
- Une compétence (skill) pour des instructions spécialisées utiles seulement à une tâche précise.
- Un agent connecté quand un domaine a son propre contexte, son propre propriétaire ou ses propres exigences.
- L'agent principal pour coordonner le résultat, rassembler l'information, juger et gérer les exceptions.
Ces blocs ne sont pas interchangeables. Chacun introduit des compromis différents côté contexte, souplesse, latence, coût, sécurité et maintenance. L'objectif du billet est d'utiliser le composant le plus simple qui donne à chaque responsabilité un propriétaire clair.
Quatre décisions d'architecture
Rendre les choix distincts
Donnez aux outils, aux sources de connaissances et aux agents connectés des noms et des descriptions qui disent à la fois ce qu'ils font et quand les utiliser. Fusionnez ou retirez les capacités en double. Dans l'exemple du billet, « rechercher des fournisseurs dans l'ERP par raison sociale ou numéro de taxe » se sélectionne plus facilement qu'un outil générique nommé « rechercher ».
Charger la consigne spécialisée seulement au besoin
Certaines instructions ne servent que pour une tâche précise. Les garder dans l'agent principal les fait occuper le contexte à chaque tour, même quand elles ne s'appliquent pas. Une compétence permet d'empaqueter ces instructions à part et de les charger quand la tâche l'exige (par exemple une consigne de diligence régionale).
Séparer sur de vraies frontières
Le billet est clair sur ce point : ne divisez pas un agent simplement parce qu'il est devenu gros. Séparez là où il y a une vraie frontière de contexte, de propriété, de sécurité ou d'exigences. Un agent connecté laisse l'agent principal déléguer une tâche bornée à un autre agent Copilot Studio qui a ses propres instructions, connaissances et outils. Copilot Studio permet aussi de connecter des agents externes compatibles au moyen du protocole Agent2Agent, selon le runtime et le scénario.
Mettre les séquences fixes dans des workflows
Utilisez l'agent quand la prochaine étape demande un jugement. Utilisez un workflow quand la séquence, l'approbation ou le contrôle doit rester constant. L'intégration d'un fournisseur pourrait toujours suivre le même noyau : valider les champs requis, vérifier l'existence du fournisseur, lancer les contrôles de conformité, créer l'enregistrement et router pour approbation. Un workflow possède cette séquence et l'agent décide quand la démarrer.
Ce que la TI peut laisser au harnais et ce qui reste à concevoir
Le billet rappelle que la bonne architecture ne veut pas dire tout régler à la main. Le harnais GitHub Copilot dans Copilot Studio rend de nouveaux modèles disponibles à leur sortie, ce qui laisse les équipes adopter des améliorations sans refaire l'architecture. Il inclut aussi la recherche d'outils (tool search) : quand le jeu d'outils devient grand, les définitions externes sont retenues et seules les pertinentes sont chargées à la demande, au lieu de placer chaque schéma complet dans le contexte du modèle.
La limite est posée dans le billet lui-même. Un modèle plus fort ne compense pas des instructions floues ni des outils qui se chevauchent. La recherche d'outils réduit ce que le modèle voit mais ne crée pas des frontières qui n'ont pas été conçues. Chaque agent connecté ajoute de la consommation de jetons, un point de défaillance de plus et davantage à gouverner. La conception reste votre travail.
Opérations, identités d'agents et Loi 25
Le volet « opérations » est celui qui touche le plus le responsable TI. Chaque agent et chaque composant doit pouvoir être évalué, sécurisé, gouverné et amélioré de façon indépendante. Côté identités, Microsoft Entra Agent ID donne une identité aux agents et le registre des agents est interrogeable par l'API Graph. Attention aux prérequis documentés : l'API de gestion des packages d'agents porte le libellé « preview » et exige une licence Microsoft Agent 365. La page d'orientation pour migrer les identités d'agents Copilot Studio vers Entra Agent ID est elle aussi en préversion (voir govern-migrate-api-entra-agent-identity).
Un agent connecté qui « décide » déclenche une question de conformité au Québec. L'article 12.1 de la Loi sur la protection des renseignements personnels dans le secteur privé vise la décision « fondée exclusivement sur un traitement automatisé » : il faut informer la personne, lui expliquer sur demande les renseignements et les principaux facteurs utilisés et lui permettre de présenter ses observations à un membre du personnel en mesure de réviser la décision (RLRQ c. P-39.1, consulté le 6 octobre 2026). Ce lien avec les agents est une interprétation et non un avis juridique : validez-le avec votre responsable de la protection des renseignements personnels avant d'automatiser une décision qui touche des personnes.
Un script pour inventorier vos identités d'agents
Avant de décider quoi séparer ou quoi fusionner, il faut savoir ce qui existe déjà. Le script suivant est en lecture seule : il interroge Microsoft Graph et affiche les identités d'agents enregistrées dans votre locataire. Chaque ligne du tableau est une identité d'agent. Si vous en voyez plus que prévu, c'est un signal pour revoir la propriété et la gouvernance de chacune.
# Inventaire en lecture seule des identites d'agents (Microsoft Entra Agent ID)
# Role du script : afficher les identites d'agents enregistrees dans le locataire
# Module requis : Microsoft.Graph (Connect-MgGraph, Invoke-MgGraphRequest)
# Permission minimale : AgentIdentity.Read.All (consentement delegue)
# Lecture seule : aucune creation, aucune modification. Endpoint v1.0 selon la doc citee.
Connect-MgGraph -Scopes "AgentIdentity.Read.All"
$uri = "https://graph.microsoft.com/v1.0/servicePrincipals/microsoft.graph.agentIdentity"
$reponse = Invoke-MgGraphRequest -Method GET -Uri $uri
$reponse.value |
Select-Object displayName, id, appId |
Sort-Object displayName |
Format-Table -AutoSizeDeux limites à garder en tête. Le rapport d'utilisation de Copilot (getMicrosoft365CopilotUsageUserDetail) n'existe pour l'instant qu'en version bêta de Graph : traitez-le comme une donnée provisoire. Et l'exportation des interactions d'entreprise n'inclut pas les agents Copilot Studio : ne comptez pas dessus pour auditer le contenu traité par vos agents.
Pour cette semaine, une action simple : lancez l'inventaire ci-dessus, repérez vos deux ou trois agents les plus chargés, puis appliquez-leur les quatre décisions d'architecture (noms distincts, compétences chargées au besoin, séquences fixes en workflow et séparation seulement sur une vraie frontière) en documentant au passage le propriétaire de chaque composant.
Pour passer à l’action, j’ai publié l’outil AgentIdentityInventory sur GitHub. Outil PowerShell en lecture seule qui interroge Microsoft Graph pour inventorier les identités d'agents Microsoft Entra Agent ID d'un locataire et générer un rapport HTML optionnel. Le README précise les prérequis, les permissions nécessaires et des exemples d’utilisation.
