Les développeurs Microsoft Teams sont avertis : qualifier chaque extension de « bot » peut désormais provoquer des défaillances en production. En 2026, les limites de la plateforme elle-même — 10 à 15 secondes pour répondre à un message — transformeront les bots mal architecturés en tempêtes de timeouts, forçant les équipes à repenser leurs pipelines.

Pourquoi cette distinction est importante

Teams propose trois types d'extensions, chacune conçue pour un modèle d'interaction différent. Les mélanger impose le mauvais runtime, le mauvais SDK et le mauvais modèle de mise à l'échelle.

Applications Teams, bots et agents – ce qu'ils sont

  • Applications Teams – Onglets de surface, pages statiques ou composants d'interface utilisateur simples à l'intérieur du client Teams. Il s'agit essentiellement d'applications web : sans état (stateless), rendues à la demande et hébergées comme n'importe quel autre service HTTP. Aucun flux conversationnel n'est attendu.
  • Bots – Conçus avec le Bot Framework SDK, les bots suivent des dialogues scriptés. Leur logique est un arbre if/else déterministe qui décide de la réponse suivante en se basant uniquement sur l'activité entrante. Comme le chemin de décision est connu à l'avance, la réponse respecte la courte fenêtre de timeout de la plateforme.
  • Agents – Entités orientées objectifs qui reçoivent un objectif de haut niveau, un ensemble d'outils et un LLM (large language model). En utilisant l'Agents SDK ou Semantic Kernel, le LLM choisit quel outil appeler, dans quel ordre, et quand demander des clarifications à l'utilisateur. Le flux est dynamique, nécessitant souvent de multiples appels externes et un raisonnement complexe.

La séparation est nette : un bot est déterministe ; un agent est probabiliste et orchestre les appels d'outils au moment de l'exécution (runtime).

Le piège du timeout

Lorsque les développeurs intègrent un raisonnement complexe — prompts LLM, recherches en base de données ou appels d'API externes — directement dans le gestionnaire de messages d'un bot, Teams constate que la requête dépasse sa fenêtre de 10 à 15 secondes. La plateforme interrompt la réponse et réessaie, ce qui peut entraîner une cascade de travaux en double et de bridage (throttling). Le symptôme ressemble à une erreur intermittente de type « le bot ne répond pas », mais la cause profonde est architecturale.

Construire un pipeline asynchrone prêt pour la production

  1. Point d'entrée Webhook – Le point de terminaison HTTP du bot accepte l'activité Teams et accuse immédiatement réception.
  2. Mise en file d'attente de l'événement – Le gestionnaire pousse la charge utile (payload) vers une file d'attente durable telle qu'Azure Service Bus.
  3. Worker d'arrière-plan – Une Azure Durable Function, un déclencheur Service Bus ou n'importe quel worker de longue durée récupère le message, exécute le raisonnement LLM ou l'orchestration d'outils, et renvoie la réponse finale à Teams via l'API de messagerie proactive du Bot Framework.

Comme le webhook initial répond instantanément, Teams n'atteint jamais son timeout, et le travail lourd se poursuit à son propre rythme. La file d'attente tamponne les pics de charge, et les workers s'adaptent automatiquement (auto-scale) en fonction de la longueur de la file d'attente.

Guide de décision rapide (le test du tableau blanc)

  • Pouvez-vous dessiner l'intégralité de l'arbre de décision avant d'écrire le moindre code ? Oui → Construisez un bot. Un flux déterministe correspond au modèle du Bot Framework et respecte la fenêtre de réponse.
  • Le problème est-il défini par un objectif de haut niveau et une liste d'outils possibles ? Oui → Construisez un agent. Laissez le LLM planifier et invoquer les outils ; déléguez la planification à un worker d'arrière-plan.

À suivre

Ce guide est le premier volet d'une série destinée aux développeurs .NET 9 construisant des solutions Teams intelligentes sur Azure.

Si vous voyez déjà des erreurs « Bot timed out » dans les journaux Teams, la solution est simple : découplez le webhook de la charge de travail lourde, adoptez un worker piloté par une file d'attente et choisissez le bon type d'extension dès le départ. La plateforme a une limite de timeout, mais votre architecture peut l'éviter.

À retenir : Mal étiqueter une extension Teams comme un bot impose une conception synchrone que Teams ne peut pas soutenir. Séparez la requête du raisonnement, choisissez le bon SDK, et votre solution Teams restera réactive, même si le cerveau qui l'anime est un agent alimenté par un LLM.