Comment j'ai mis en production mon copilote de support IA multi-agents dans Teams et Azure

TL;DR

• Création d'une démo .NET A2A pour valider le modèle de triage avant de déployer le système Python. Si la forme ne fonctionne que dans une seule pile, ce n'est pas un modèle portable.
• Teams est le canal d’ingestion pour ce déploiement, ce n’est pas une exigence stricte. Le bot publie sur un canal indépendant/entréepoint final ; toute autre ingestion peut faire de même.
• Les budgets de délai d’attente des équipes ont forcé une architecture de réponse entièrement asynchrone.
• Les limites adaptatives de la taille de la carte ont forcé la divulgation progressive : un badge compact à l'avant, tout le reste derrière les bascules.
• Les autorisations RSC ne s'activent que lors de l'installation du manifeste, et non du consentement Entra uniquement. Un mauvais ordre vous coûte un 403 et un bug que vous ne pouvez pas reproduire.
• La conteneurisation était un enjeu de table. Le vrai travail consistait à authentification, télémétrie, stockage et à rendre explicite chaque autorisation de plate-forme.

La deuxième partie couvrait les échecs d'exécution et le travail de durcissement qui a suivi. Cet article concerne la prochaine étape : la production.

Une fois que le système a été capable de produire des résultats de tri crédibles à plusieurs reprises, la question a encore changé. Il ne s'agissait plus de « Cette architecture peut-elle fonctionner ? » C'était « cela peut-il se comporter comme un produit déployé ? »

Cette question s'est avérée être plus large que « le mettre dans Docker » :

• les chaînes avaient des budgets de temporisation
• Les cartes Teams avaient des limites de présentation
• les pièces jointes sont arrivées dans des formes spécifiques à la plate-forme
• stockage et audit nécessaires maisons durables
• le déploiement nécessite les images, les identités, les secrets, les sondes et le flux de mise à jour
• l'approbation de l'administrateur et l'installation du manifeste faisaient partie de l'histoire d'exécution, pas seulement des anecdotes de configuration

En d’autres termes : le plus difficile n’était pas seulement de faire raisonner le système. Il s’agissait de faire fonctionner le système dans l’environnement réel qu’il était censé servir. Pour ce déploiement, cet environnement est Microsoft Teams comme canal d'ingestion et Azure comme environnement d'exécution.

Valider la forme avant de s'appuyer dessus

Avant d’approfondir les leçons de productionisation, je voudrais souligner quelque chose de concret.

Lorsque les agents s'exécutent au sein d'une session LLM, il est difficile de dire si un échec est un problème de routage ou un problème de modèle. Avant le déploiement, je voulais la preuve que le modèle de tri tenait le coup dans un système distribué plus traditionnel : un système dans lequel les "agents" sont de simples services HTTP, pas des sous-sessions LLM, et les échecs ne sont que des échecs HTTP.

Le système principal utilise Claude Code comme environnement d'exécution multi-agent, de sorte que l'orchestration est étroitement liée au comportement du modèle. Une implémentation autonome dans une pile différente pourrait isoler le protocole du raisonnement et donner un signal plus clair : la forme de triage fonctionne-t-elle, ou fonctionne-t-elle uniquement parce que le LLM comble les lacunes ?

C'est pourquoi j'ai construit a2a-docker-demo : une implémentation autonome FastEndpoints/.NET du même modèle de tri, en utilisant la spécification du protocole A2A. Le système principal est Python, donc utiliser une pile différente pour la démo était délibéré. Si la forme ne fonctionne que dans un seul langage ou dans un seul framework, ce n'est pas vraiment un mod...
[Courte citation de 8% de l'article original]