Votre agent dans Teams : ce qu'implique de le publier sur Microsoft 365

Votre agent fonctionne dans l'aire de jeu et répond bien. Le porter dans Microsoft Teams ou Microsoft 365 Copilot, c'est publier une ressource avec sa propre identité, avec des permissions à réassigner et une portée à choisir. Partager le lien ne suffit pas. Le module Microsoft Learn « Integrate an agent with Microsoft 365 » parcourt le processus complet. Ce post le suit pareillement : ce que la publication crée, comment se déroule le flux et ce que change avec la nouvelle identité. Aussi quand entre en jeu Agents Toolkit, comment les données Microsoft 365 se connectent avec Work IQ, et quoi faire quand quelque chose échoue.

Ce que la publication crée

Publier un agent crée une ressource d'application d'agent avec trois choses : une URL d'invocation dédiée, une identité Microsoft Entra propre et l'isolation des interactions par utilisateur. Microsoft Entra ID est le système de comptes et d'identités de Microsoft : celui qui décide qui entre dans quelle ressource et avec quelles permissions. Chaque utilisateur interagit isolé : ce qu'une personne demande à l'agent ne se mélange pas à celui d'un autre.

L'application agit comme couche de routage : elle route le trafic vers la version déployée, si bien que publier une nouvelle version ne change pas l'point d'extrémité que les clients utilisent.

Ce dernier détail est ce qui rend la mise à jour tranquille : les clients continuent d'appeler la même URL pendant que le trafic tombe sur le nouveau déploiement.

En pratique, le trajet d'un message ressemble à ceci : une personne écrit à l'agent dans Teams ; Teams envoie le message au Bot Service de votre abonnement ; le Bot Service le remet à l'agent dans Foundry ; la réponse revient par le même chemin et par la même URL. L'utilisateur ne voit aucune de ces pièces : il voit le chat. Votre travail de publication a été de placer ces pièces sur le chemin.

Le flux, pas à pas

La publication sur Microsoft 365 passe par trois mouvements : créer une ressource Azure Bot Service, enregistrer une application dans Microsoft Entra ID et générer un paquet de publication Microsoft 365. L'assistant du portail fait ces étapes. De vous, il ne demande que des métadonnées visibles par les utilisateurs :

Nom et description.
Icônes PNG de 32 et 192 pixels.
Éditeur, politique de confidentialité et conditions.

Et voici l'avertissement explicite : ne mettez pas de secrets dans ces métadonnées. Ils sont visibles dans la store. Pour ne pas mélanger deux choses : l'application d'agent est la ressource dans Azure, avec son URL et son identité ; le paquet de publication est ce que l'on charge dans Teams pour la distribuer. Celle qui route les messages entre Microsoft 365 et l'agent est l'Azure Bot Service que l'assistant provisionne dans votre abonnement ; Functions, Cosmos DB et Logic Apps ne font pas partie du flux de publication. Avant de distribuer, il vaut tester le paquet en le chargeant à la main dans Teams : Applications → Charger une application personnalisée.

Les deux portées

Il y a deux façons de distribuer, et la différence est qui approuve :

Partagé : apparaît immédiatement dans « Vos agents » de la store de Teams. N'a pas besoin d'approbation. C'est la portée pour tester et pour les petites équipes.
Organisation : apparaît sous « Créé par votre organisation » et un administrateur doit l'approuver dans le centre d'administration Microsoft 365. C'est celle indiquée pour la production.

Un doute commun, réglé une fois pour toutes : il n'y a pas de différences de ressources Azure ni de performances entre les deux portées. Ce qui change, c'est le chemin de distribution, pas l'infrastructure. La règle pratique : partagé pendant que vous testez avec votre équipe, organisation quand toute la compagnie va l'utiliser.

Le chemin complet, de bout en bout :

flowchart LR
    P[Vous publiez depuis le portail Foundry] --> B[L'assistant crée un Bot Service dans Azure]
    B --> E[Enregistre l'application dans Entra ID]
    E --> Z[Génère le paquet Microsoft 365]
    Z --> A{Vous choisissez la portée}
    A -->|Partagé| C[Apparaît instantanément dans Vos agents]
    A -->|Organisation| O[Un administrateur l'approuve dans le centre Microsoft 365]

En clair : vous demandez à l'assistant de publier, il construit les trois pièces d'Azure et le paquet, et votre seule décision est la portée. Tout le reste est automatique.

Le piège de l'identité

C'est le point opérationnel critique. En publiant naît une nouvelle identité d'agent, distincte de l'identité du projet de développement. Les permissions de développement ne se transfèrent pas. En développement, les outils parlaient à Azure avec l'identité du projet ; après publication, ils parlent à une autre. Même agent, autre credential, permissions qui repartent de zéro.

Le symptôme est typique : l'agent testait bien dans l'aire de jeu et, après publication, les outils qui touchaient des ressources Azure échouent avec des erreurs d'autorisation. Seulement dans l'environnement publié. La solution est de réassigner le RBAC à l'identité publiée, par exemple sur l'index d'Azure AI Search, dans le portail d'Azure. RBAC est l'acronyme de role-based access control : la manière dont Azure définit qui a le droit de faire quoi sur chaque ressource. En développement c'était le projet qui commandait ; une fois publié, c'est la nouvelle identité, et cette fiche il faut la remplir à la main.

Quand entre en jeu Agents Toolkit

La publication directe depuis le portail est la voie rapide pour les déploiements standard. Pour les scénarios plus exigeants il y a Microsoft 365 Agents Toolkit, qui intercale une application proxy sur le chemin : Teams ou Copilot parlent au proxy, et le proxy à l'agent Foundry.

Elle se justifie dans trois cas : SSO ou authentification unique (l'utilisateur entre une fois et accède à tout sans se ré-authentifier ; elle s'applique quand la configuration par défaut d'Entra ne suffit pas), logique de middleware (traiter ou journaliser le message entre Teams et l'agent) et déploiement multi-environnements avec CI/CD (intégration et livraison continues : le code avance du développement à la production sans étapes manuelles). Elle sert aussi à déboguer depuis l'éditeur. Le coût va sur la facture : heures ou jours, face aux minutes de la publication directe. L'extension vit dans Visual Studio Code.

Work IQ : les données Microsoft 365

Publier l'agent ne lui donne pas accès à votre courriel ni à vos documents. Pour cela il y a Work IQ : une CLI et un serveur MCP qui connectent les agents aux données Microsoft 365 (courriel, réunions, documents SharePoint et OneDrive, messages Teams et contacts). CLI est le nom des outils utilisés depuis le terminal de commandes, sans interface graphique ; MCP, ou Model Context Protocol, est le standard par lequel un assistant reçoit des outils externes. Il travaille sur Microsoft Graph, la couche avec laquelle on accède aux données Microsoft 365, avec l'identité authentifiée ; il ne stocke pas les données et hérite des permissions et de l'audit de Copilot. Nécessite une licence Copilot et un consentement administratif.

Deux modes d'usage, avec leur exemple :

CLI : workiq ask -q «What were the key decisions in last week's architecture review meeting?».
Serveur MCP : enregistrer @microsoft/workiq dans la configuration MCP de VS Code et demander à Copilot les prérequis d'une réunion. L'assistant appelle les outils de Work IQ et répond avec du contexte Microsoft 365.

La différence qui compte : l'agent cesse de ne savoir que le projet et commence à savoir ce qui se passe dans l'entreprise, avec les mêmes permissions et le même audit que Copilot avait déjà.

Ce que Work IQ n'est pas

Et une note sur les noms : Work IQ n'est pas un modèle d'apprentissage automatique, ni un remplacement de Teams, ni l'extension de Visual Studio. C'est Agents Toolkit.

Avant de commencer : ce qu'il faut avoir à portée de main

Le flux est automatique, mais il ne sort pas de nulle part. Avant de cliquer sur « Publier », il vaut rassembler ce qui suit :

Un abonnement Azure avec les permissions de créer Azure Bot Service et d'enregistrer des applications dans Microsoft Entra ID.
Les métadonnées de la store : nom, description, icônes PNG de 32 et 192 pixels, éditeur, politique de confidentialité et conditions. Pas de secrets dedans : ils sont visibles dans la store.
Si le chemin est celui de l'organisation, un administrateur prêt à approuver dans le centre d'administration Microsoft 365.
Pour Work IQ, une licence Copilot et un consentement administratif. Et si vous regardez les prérequis aujourd'hui, gardez à l'esprit qu'il est en version préliminaire.

Rassemblez cela à l'avance et la publication prend des minutes. Ce qu'il ne faut pas précipiter, c'est la décision de portée : elle vient après le test.

Tester et démêler

L'aire de jeu ne simule ni l'UI ni l'authentification réelles de Teams, donc le test se fait dans Teams, et il vaut tester avec plusieurs utilisateurs et clients : l'isolation par utilisateur et l'approbation de l'administrateur se comportent différemment avec plus d'un compte en jeu. Pour quand quelque chose échoue, un diagnostic par scénario, avec quatre symptômes et quatre causes sans spéculer :

Ne répond pas : vérifier l'Azure Bot Service.
Les outils échouent seulement dans Teams : réassigner le RBAC à l'identité publiée.
On ne le trouve pas : vérifier la portée ou l'approbation en attente.
C'est lent : simplifier les instructions et revoir les outils.

Et si le symptôme n'entre dans aucune des quatre catégories, l'ordre reste le même : regardez d'abord le Bot Service, ensuite les rôles, et seulement ensuite vos instructions.

Publier pour de vrai

Ce qui manque, c'est l'étape qu'on ne peut pas simuler : publier pour de vrai. L'exercice « publish a Foundry agent to Teams » exige un abonnement Azure avec les permissions de créer Azure Bot Service et d'enregistrer des applications dans Microsoft Entra ID, et il est resté non exécuté ici. Le post a parcouru le flux, les portées, le piège de l'identité et les scénarios de troubleshooting ; il reste à publier et à voir l'agent apparaître dans « Vos agents » avec sa nouvelle identité.

Si amener en production est votre truc, la liste ci-dessus est votre point de départ. Et la seule prudence supplémentaire concerne Work IQ : la source le décrit en version préliminaire, donc révalidez ses API et ses prérequis avant d'en dépendre.

Mon avis

La publication, c'est la partie bon marché du processus : l'assistant fait les trois étapes en minutes. Ce qui coûte de se souvenir, c'est la nouvelle identité, parce que l'erreur n'apparaît pas au moment de publier. Elle apparaît ensuite, quand un utilisateur teste un outil qui avait besoin d'un rôle. L'ordre qui marche pour moi : publier, réassigner le RBAC, tester dans Teams avec un deuxième utilisateur, et seulement ensuite choisir la portée et distribuer. S'il ne reste qu'une idée de ce post : réassignez les RBAC avant d'envoyer le lien aux gens.

---

*Source : le module « Integrate an agent with Microsoft 365 » de Microsoft Learn.*