Agent Builder, l'outil de création d'agents intégré à Microsoft 365 Copilot, vient de recevoir une série de mises à jour qui changent concrètement la façon de publier, gouverner et enrichir un agent en entreprise. Entre la fin du bricolage manuel de fichiers ZIP, la refonte des pièces jointes et l'arrivée annoncée des « skills », voici ce qui bouge pour les administrateurs et les créateurs d'agents.
La publication d'agents ne nécessite plus de manipulation de fichiers ZIP
Jusqu'à présent, transformer un agent Agent Builder en application d'entreprise gérée par l'IT — un « enterprise agent » publié dans l'Agent Store — imposait un parcours peu intuitif : télécharger le fichier ZIP de l'agent via le menu ellipsis, l'extraire, modifier manuellement un fichier JSON pour renseigner les métadonnées (description, site web du créateur, déclaration de confidentialité, conditions d'utilisation), tout réempaqueter, puis réuploader le résultat.
Ce flux, peu documenté et souvent ignoré par les créateurs d'agents, disparaît. Un nouveau bouton Agent details, accessible depuis le menu déroulant de l'agent, permet désormais de renseigner directement :
- la description courte de l'agent ;
- le site web du créateur ;
- la déclaration de confidentialité ;
- les conditions d'utilisation.
Ces champs sont sauvegardés avec l'agent et réutilisés automatiquement lors de toute soumission ultérieure vers le catalogue de l'organisation.
Soumettre un agent au catalogue de l'organisation en quelques clics
Une fois les détails renseignés, il suffit de retourner dans le même menu et de cliquer sur Submit to org catalog (ou l'option de publication vers M365, selon l'interface). Ce flux reproduit exactement le processus déjà connu dans Copilot Studio : le créateur soumet l'agent, un administrateur le reçoit dans la file d'attente et l'approuve ou le rejette.
Lors de la soumission, les champs pré-remplis (description, site web, mentions légales) réapparaissent — c'est là que le travail préparatoire fait dans Agent details prend tout son sens. Il faut ensuite ajuster deux champs supplémentaires avant de valider :
- le nom d'affichage de l'agent tel qu'il apparaîtra dans le catalogue ;
- le nom du développeur, généralement le nom de l'organisation ou de l'équipe IT responsable (par exemple « Contoso IT » ou « Corporate Communications »).
Une fois validé, l'agent passe en attente de revue par un administrateur, qui le retrouvera à sa prochaine connexion au registre Agent 365.
Ce nouveau flux de publication est identique, dans sa logique, à celui de Copilot Studio. Les organisations qui gèrent déjà un processus d'approbation d'agents n'ont donc pas de nouvelle procédure à créer — seule l'origine de la demande change.
Validation par les administrateurs dans le centre d'administration Microsoft 365
Côté administration, la revue se fait dans le centre d'administration Microsoft 365, section Agents > Agent 365, onglet Requests. L'agent soumis y apparaît avec le statut Pending review, accompagné d'informations utiles :
- la plateforme de création (Agent Builder) ;
- les informations sur le soumetteur ;
- les capacités déclarées de l'agent.
Le parcours de publication qui suit est commun à tous les types d'agents soumis via Agent 365, quelle que soit leur origine :
- Définir qui peut installer l'agent (par exemple « tous les utilisateurs »).
- Choisir s'il doit être pré-installé pour les utilisateurs concernés.
- Appliquer un modèle de configuration (template) — les valeurs par défaut conviennent dans la majorité des cas.
- Cliquer sur Publish pour finaliser, ou Reject pour refuser la demande.
Activer la pré-installation pousse automatiquement l'agent vers les utilisateurs ciblés sans action de leur part. Vérifiez le périmètre d'installation avant de publier — une erreur de portée déploie l'agent bien plus largement que prévu.
Attachments et Knowledge : deux mécanismes de mise à jour différents
La section auparavant nommée Uploaded files s'appelle désormais Attachments. Ce n'est pas qu'un changement de nom : il clarifie une distinction technique importante qui existait déjà mais restait mal comprise.
Concrètement, si vous attachez un fichier depuis votre OneDrive via Attachments, l'agent conserve la version au moment de l'upload — toute modification ultérieure du fichier source nécessite un ré-upload manuel. À l'inverse, un fichier ajouté via Knowledge reste synchronisé avec sa source M365 : la mise à jour se propage automatiquement à l'agent.
Des outils désormais activés par défaut, mais déplacés
Le Code Interpreter et le générateur d'images ne figurent plus dans une section « Tools » distincte en bas de page. Ils ont été déplacés — sans logique de placement évidente — sous l'icône en forme de roue dentée de la section Knowledge. Autre changement notable : ces deux outils sont désormais activés par défaut sur tout nouvel agent, alors qu'ils devaient auparavant être activés manuellement.
On y trouve également deux options à connaître :
- People data : donne accès aux données de profil M365 (organigramme, expertise déclarée, etc.), utile pour construire un agent de type « recherche d'expert » qui identifie un interlocuteur compétent sur un sujet donné.
- Discourage model knowledge : remplace l'ancienne formulation « Prevent model knowledge ».
Discourage vs Prevent model knowledge : la nuance à connaître
Ce changement de vocabulaire n'est pas anodin. « Discourage » signifie que le modèle déclasse les connaissances issues de son entraînement général au profit des données organisationnelles fournies via Knowledge ou Attachments — mais sans garantie absolue que l'agent n'utilisera jamais ses connaissances internes.
Ne confondez pas « discourage » avec un blocage strict. Si votre cas d'usage exige une réponse exclusivement fondée sur les données internes (conformité, exactitude réglementaire), testez systématiquement des questions pièges pour vérifier que l'agent ne pioche pas dans ses connaissances générales.
Migrer un agent vers Copilot Studio en un clic
La fonction Copy to Copilot Studio permet de recréer un agent Agent Builder directement dans Copilot Studio, pour lui ajouter des capacités qui dépassent le périmètre d'Agent Builder. Quelques points à retenir avant de s'en servir :
- La copie de la connaissance SharePoint semble encore instable au moment de la rédaction ; des comportements incohérents ont été observés.
- L'agent recréé n'utilise pas l'orchestrateur GitHub Copilot : il reste sur le chat harness classique, ce qui signifie qu'aucune licence supplémentaire n'est requise au-delà de la licence M365 Copilot déjà en place.
- Cette migration est pertinente une fois que les limites d'Agent Builder sont atteintes (orchestration complexe, connecteurs avancés, flux multi-étapes).
Skills : la fonctionnalité qui va rapprocher Agent Builder de Copilot Studio
Le changement le plus structurant reste à venir : l'arrivée des skills dans Agent Builder, sous forme de fichiers markdown, sur le même principe que les skills Anthropic déjà présentes dans SharePoint et Copilot Studio. Cette évolution comble un écart de parité important entre les deux plateformes de création d'agents Microsoft.
Point clé pour les organisations soucieuses de leur consommation : les skills n'exigent aucun crédit Copilot, ce qui en fait un levier de valeur supplémentaire dans le cadre d'une licence M365 Copilot existante. Le déploiement est annoncé pour les prochaines semaines.
Dépannage : points de vigilance courants
- Les champs de publication restent vides malgré une soumission antérieure : vérifiez que les informations ont bien été enregistrées via Agent details avant de relancer la soumission — elles ne se propagent pas rétroactivement.
- Un agent reste bloqué en « Pending review » : le registre Agent 365 nécessite un rafraîchissement manuel côté admin dans le centre d'administration Microsoft 365 ; la file d'attente ne se met pas toujours à jour en temps réel.
- Un fichier attaché ne reflète pas les changements récents : c'est un comportement attendu des Attachments, pas un bug — utilisez Knowledge si une synchronisation continue est nécessaire.
- La copie vers Copilot Studio échoue partiellement sur la connaissance SharePoint : contrôlez manuellement les sources de connaissance après migration avant de mettre l'agent en production.
Points clés à retenir
- La publication d'un agent vers l'Agent Store se fait désormais entièrement depuis Agent Builder, sans manipulation de ZIP ni édition de JSON.
- La revue et l'approbation restent centralisées dans le centre d'administration Microsoft 365, section Agent 365.
- Attachments et Knowledge répondent à deux besoins distincts : donnée statique versus donnée synchronisée.
- Code Interpreter et générateur d'images sont désormais actifs par défaut — vérifiez si cela correspond à votre politique de gouvernance.
- « Discourage model knowledge » n'équivaut pas à un blocage garanti des connaissances générales du modèle.
- Les skills à venir promettent des agents plus riches sans consommation de crédits Copilot : à surveiller de près dans les prochaines semaines.
Si votre organisation utilise déjà Agent Builder en production, commencez par auditer vos agents existants pour renseigner les champs Agent details manquants : c'est le prérequis pour tirer parti du nouveau flux de publication vers l'Agent Store dès qu'un besoin de gouvernance IT se présente.
