Comment déployer un bot dans Microsoft Teams en 7 étapes
Pour déployer un bot dans Microsoft Teams, vous devez développer et héberger le bot lui-même, inscrire une ressource Azure Bot avec le bon type d’identité, pointer son point de terminaison de messagerie vers votre bot hébergé, empaqueter un manifeste d’application Teams qui le déclare, puis charger ce package via la surface Teams adaptée à votre situation — chargement local sur votre propre compte, diffusion via le catalogue d’applications de votre organisation, ou soumission au Teams Store. Les outils qui sous-tendent ce processus ont beaucoup changé en 2025 : les étapes ci-dessous partent donc du principe que vous démarrez de zéro plutôt que vous ne suivez un ancien tutoriel.
Solution rapide : si vous démarrez un nouveau bot aujourd’hui, ignorez le Bot Framework SDK — il est archivé sur GitHub et n’est plus maintenu. Partez plutôt sur le Microsoft 365 Agents SDK ou le Teams SDK, et construisez-le en mono-tenant ou avec une identité managée affectée par l’utilisateur — la création de bots multi-tenant n’est plus prise en charge depuis le 31 juillet 2025.
Ce qui a changé depuis la première publication de cet article
La chaîne d’outils que ce guide décrivait à l’origine n’existe plus sous une forme prise en charge. Microsoft l’a archivée :
« Le Bot Framework SDK et le Bot Framework Emulator ont été archivés sur GitHub. Le projet n’est plus mis à jour ni maintenu. Les tickets de support pour le Bot Framework SDK ne seront plus traités à compter du 31 décembre 2025. » — Microsoft: What’s new in Azure Bot Service
Les remplacements recommandés par Microsoft, selon ce que vous construisez :
- Microsoft 365 Agents SDK — pour un agent qui doit fonctionner sur plusieurs canaux, en C#, JavaScript ou Python (GitHub).
- Teams SDK (Teams AI Library) — pour un agent conçu spécifiquement pour s’exécuter dans Microsoft Teams, avec des API propres à Teams, la prise en charge des Adaptive Cards et une orchestration IA intégrée (docs).
- Microsoft Copilot Studio — pour une plateforme d’agents low-code/no-code.
Si vous migrez un bot Bot Framework existant plutôt que de repartir de zéro, Microsoft propose un guide de migration.
Quelques noms ont aussi changé. Teams Toolkit s’appelle désormais Microsoft 365 Agents Toolkit, renommé lors de Microsoft Build en mai 2025 ; son dépôt est passé d’OfficeDev/TeamsFx à OfficeDev/microsoft-365-agents-toolkit. L’ancien TeamsFx SDK est déprécié, avec un support communautaire uniquement sur GitHub jusqu’en septembre 2026. Ce qui n’a pas changé : le type de ressource Azure s’appelle toujours Azure Bot, les packages Microsoft.Bot.* et botbuilder-* conservent leur nom en tant que packages historiques dont vous migrez, et token.botframework.com reste le domaine sur lequel votre bot s’authentifie.
Quel type de bot déployez-vous réellement ?
« Bot », « agent » et « app » sont souvent utilisés de façon interchangeable, mais le chemin de déploiement diffère selon ce que vous livrez réellement. Avant de toucher à Azure, déterminez lequel de ces trois cas correspond à votre situation :
| Type | Où il s’exécute | Effort | Idéal pour |
|---|---|---|---|
| Agent déclaratif | L’orchestrateur et le modèle propres à Copilot, au sein des applications Microsoft 365 | Low-code | Des agents rapides et pilotés par modèle, sans besoin d’orchestration personnalisée |
| Agent à moteur personnalisé | Votre propre code — Microsoft 365 Agents SDK, Teams SDK, Copilot Studio pro-code, ou Azure AI Foundry | Contrôle total | Orchestration personnalisée, choix du modèle ou intégration de données poussée |
| Bot classique (Bot Framework) | Une ressource Azure Bot existante sur le SDK historique | Maintenance uniquement | Les bots que vous avez déjà déployés et devez continuer à faire fonctionner |
Source : Vue d’ensemble des agents à moteur personnalisé, Vue d’ensemble des agents
Soyez honnête sur la colonne qui correspond à votre cas avant de commencer, car la voie low-code concentre désormais l’essentiel du volume. Lors de la conférence de résultats du T2 de l’exercice 2026 de Microsoft, le PDG Satya Nadella a déclaré à propos de Copilot Studio et Agent Builder :
« Plus de 80 % des entreprises du Fortune 500 ont des agents actifs construits à l’aide de ces outils low-code/no-code. » — Satya Nadella, conférence de résultats Microsoft FY26 Q2
C’est une affirmation qui concerne spécifiquement les agents low-code, pas les bots code-first. Elle mérite tout de même d’être prise en compte : si un agent déclaratif suffit à votre besoin, vous pouvez ignorer presque tout ce qui suit. Les étapes ci-dessous s’adressent aux cas où ce n’est pas suffisant.
Le reste de ce guide couvre la création et le déploiement d’un agent à moteur personnalisé — ce que la plupart des administrateurs IT et développeurs entendent par « un bot Teams » — ainsi que les parties du processus (ressource Azure Bot, manifeste, validation du store) qui s’appliquent toujours si vous maintenez un bot Bot Framework classique.
1. Sur quel SDK devez-vous construire votre bot ?
Pour un nouveau bot, partez sur le Microsoft 365 Agents SDK s’il doit fonctionner sur des canaux autres que Teams, ou sur le Teams SDK s’il est réservé à Teams et que vous voulez une orchestration IA et une prise en charge des Adaptive Cards intégrées d’emblée. Les deux remplacent le Bot Framework SDK archivé. Le développement au quotidien passe par le Microsoft 365 Agents Toolkit, l’extension VS Code qui sert à générer, exécuter et empaqueter votre projet — le même outil qui s’appelait auparavant Teams Toolkit.
2. Comment créer la ressource Azure Bot et choisir un type d’identité ?
Dans le portail Azure, sélectionnez Créer une ressource, recherchez « bot », puis choisissez la carte Azure Bot (source).
Le type d’identité que vous choisissez ici est la décision la plus importante de tout ce processus, car Microsoft a mis fin à la création de bots multi-tenant :
« La création de bots multi-tenant sera dépréciée après le 31 juillet 2025. Les bots multi-tenant existants continueront de fonctionner, mais la création de nouveaux bots multi-tenant ne sera plus prise en charge après cette date. Pour garantir un support continu, utilisez désormais une identité mono-tenant ou une identité managée affectée par l’utilisateur. »
Il existe trois options d’identité, définies via la valeur MicrosoftAppType :
| Type d’identité | MicrosoftAppType | Prise en charge par langage de SDK | Remarque de configuration |
|---|---|---|---|
| Identité managée affectée par l’utilisateur | UserAssignedMSI | C#, JavaScript, Python | Laissez MicrosoftAppPassword vide |
| Mono-tenant | SingleTenant | C#, JavaScript, Python | Inscription d’application standard |
| Multi-tenant | MultiTenant | Tous les SDK, y compris Java | Laissez MicrosoftAppTenantId vide ; la nouvelle création n’est plus prise en charge |
L’identité managée affectée par l’utilisateur et l’identité mono-tenant ne sont pas seulement non prises en charge dans les autres langages de SDK — Microsoft précise clairement qu’elles « ne sont pas prises en charge dans les autres langages de SDK, Bot Framework Composer, Bot Framework Emulator, ou Dev Tunnels ». Si vous êtes sur Java, le mode multi-tenant est votre seule option, puisque le SDK Java ne prend en charge aucun des deux autres.
L’emplacement de ces paramètres d’identité dépend de votre langage :
| Langage | Fichier de configuration |
|---|---|
| C# | appsettings.json |
| JavaScript | .env |
| Java | application.properties |
| Python | config.py |
Deux autres points à connaître avant de cliquer sur Créer. D’abord, les types de ressources Web App Bot et Bot Channels Registration ne peuvent plus être créés — seule la ressource plus récente Azure Bot le peut désormais — même si les ressources existantes que vous avez déjà continuent de fonctionner. Ensuite, si la résidence des données compte pour vous, la résidence locale des données est actuellement disponible dans les régions Europe Ouest et Inde centrale ; choisissez-la sous Détails du projet lors de la création de la ressource.
3. Comment configurer le point de terminaison de messagerie et tester en local ?
Pointez le point de terminaison de messagerie de votre bot vers l’endroit où il s’exécute réellement : https://<your-host>/api/messages. Pendant le développement, cet hôte doit être accessible depuis Internet, même si le bot s’exécute sur votre machine.
Le Microsoft 365 Agents Toolkit s’en charge pour vous — il inclut un tunneling de débogage pour les agents et les bots reposant sur Dev Tunnels, ce qui vous permet d’exécuter et de déboguer directement depuis VS Code (source). ngrok fonctionne toujours et apparaît encore dans de nombreux exemples, mais c’est désormais la voie manuelle et secondaire plutôt que l’option par défaut.
Attention : Dev Tunnels ne prend pas en charge les types d’application à identité managée affectée par l’utilisateur ou mono-tenant. Si vous avez suivi la recommandation de l’étape 2 et créé un bot mono-tenant ou à identité managée affectée par l’utilisateur, vous ne pouvez pas le déboguer via les Dev Tunnels intégrés à l’Agents Toolkit — il vous faudra ngrok ou un autre tunnel manuel pour les tests en local.
Quel que soit le tunnel utilisé, ajoutez token.botframework.com à la liste d’autorisation dans vos paramètres de domaine afin que votre bot puisse mener à bien l’authentification.
4. Comment créer le manifeste d’application Teams ?
Empaquetez votre bot en tant qu’application Teams avec un manifeste qui le déclare. La version de schéma GA actuelle est la 1.30 :
{
"$schema": "https://developer.microsoft.com/json-schemas/teams/v1.30/MicrosoftTeams.schema.json",
"manifestVersion": "1.30",
"id": "<your-app-id>",
"version": "1.0.0",
"developer": {
"name": "Contoso",
"websiteUrl": "https://contoso.com",
"privacyUrl": "https://contoso.com/privacy",
"termsOfUseUrl": "https://contoso.com/terms"
},
"name": { "short": "Contoso Bot", "full": "Contoso Support Bot" },
"description": { "short": "Answers support questions.", "full": "Answers support questions in Microsoft Teams." },
"icons": { "color": "color.png", "outline": "outline.png" },
"accentColor": "#0078D4",
"bots": [
{
"botId": "<your-bot-id>",
"scopes": ["team", "personal"],
"supportsFiles": true
}
],
"validDomains": ["contoso.com"]
}Deux pièges classiques ici. manifestVersion est verrouillé sur le schéma que vous référencez — le schéma 1.30 n’accepte que "1.30", donc faites évoluer les deux ensemble ou ni l’un ni l’autre. Et validDomains n’est pas une liste d’autorisation d’authentification : elle liste les domaines depuis lesquels le contenu de votre onglet est autorisé à se charger, donc placez-y votre propre domaine d’application, pas token.botframework.com. N’ajoutez un domaine de tunnel local que pendant les tests, et retirez-le du package que vous livrez réellement.
Le schéma exige aussi manifestVersion, version, id, developer, name, description, icons et accentColor au niveau racine — un manifeste uniquement dédié au bot qui les omettrait échouerait à la validation avant même que quiconque ne voie votre bot.
5. Comment charger l’application dans Teams ?
Il existe trois façons distinctes de faire entrer votre application empaquetée dans Teams, chacune nécessitant des autorisations différentes :
- Charger sur votre propre compte ou une seule équipe. Dans le client Teams, accédez à Applications → Gérer vos applications → Upload an app (charger une application). C’est du chargement local en mode développeur — aucun rôle d’administrateur n’est requis de votre part, à condition que la politique de votre tenant l’autorise (voir l’étape suivante) (source).
- Catalogue d’applications de l’organisation. Dans le centre d’administration Teams, accédez à Applications Teams → Gérer les applications et chargez-la depuis là. Les utilisateurs peuvent aussi soumettre une application pour approbation, qu’un administrateur fait ensuite passer de Soumise à Publiée. Cette surface nécessite un accès administrateur Teams (source).
- Teams Store / Marketplace commercial Microsoft. Cela passe par Partner Center, et une application publiée sur le Teams Store est aussi référencée sur le marketplace commercial. C’est le chemin qui déclenche la validation du store, couverte à l’étape 7 (source).
6. Comment faire passer votre bot au-delà de la politique d’administration ?
Le fait que le chargement local fonctionne ou non dépend de la politique, pas des autorisations que vous détenez personnellement. Trois paramètres en décident : le paramètre d’applications personnalisées à l’échelle de l’organisation, la politique de configuration d’application qui contrôle « Upload custom apps » (charger des applications personnalisées), et le paramètre au niveau de l’équipe. Si l’un d’eux bloque les applications personnalisées, votre chargement échoue même avec un manifeste correctement construit — vérifiez auprès de la personne responsable de la politique d’administration Teams dans votre tenant avant de supposer qu’il s’agit d’un bug de votre côté (source).
7. Comment passer la validation du Teams Store ?
Si vous publiez sur le Teams Store, deux règles de validation vous prendront au dépourvu si vous n’y êtes pas préparé.
La version du schéma compte pour la soumission au store, pas seulement pour que le manifeste soit correctement interprété :
« À partir de juillet 2026, les nouvelles soumissions au Teams Store pour les applications compatibles avec les canaux doivent utiliser la version de schéma de manifeste d’application 1.25 ou ultérieure. Pour utiliser la version de schéma de manifeste d’application 1.25 ou ultérieure, mettez à jour votre manifeste d’application et ajoutez
"supportsChannelFeatures": "tier1"pour déclarer la prise en charge des fonctionnalités de canal. »
Et la réactivité de votre bot est une exigence du store, pas seulement une bonne pratique UX :
« Les bots doivent répondre aux commandes des utilisateurs dans un délai de deux secondes ou afficher un indicateur de saisie. »
Intégrez l’indicateur de saisie avant de soumettre votre application — un bot qui reste silencieux pendant qu’il réfléchit échoue à la revue (source).
Combien cela coûte-t-il ?
L’envoi de messages via Teams lui-même n’entraîne aucun frais par message au niveau d’Azure Bot Service : Microsoft Teams est un canal standard, et les messages des canaux standard sont facturés 0,00 $ pour 1 000. Si vous exposez aussi le même bot via un canal Premium — Direct Line ou le chat web, par exemple — ceux-ci sont facturés séparément, à 0,50 $ pour 1 000 messages sur le niveau S1, avec un quota gratuit inclus sans frais (tarification).
Cela ne couvre que la couche de messagerie. Vous payez toujours le calcul qui fait réellement tourner votre bot — App Service, Azure Functions, ou tout autre hébergement que vous utilisez — quel que soit le nombre de messages qu’il envoie via Teams.
Surveillance et mise à jour de votre bot
Une fois en production, connectez Azure Application Insights et surveillez trois éléments : les temps de réponse, les schémas d’utilisation (heures de pointe, commandes les plus utilisées) et les taux d’erreur. Configurez des tableaux de bord et des alertes afin de détecter les problèmes avant que les utilisateurs ne les signalent.
Pour les mises à jour, traitez le bot comme n’importe quel autre service en production : testez-le d’abord dans un environnement de staging, déployez en dehors des heures de pointe, et gardez un plan de retour arrière prêt en cas de problème. Documentez ce qui a changé, et si la mise à jour est visible pour les utilisateurs, annoncez-la via une annonce Teams.
Où nBold s’intègre
nBold ne construit ni ne déploie de bots — cette partie relève entièrement de votre travail Azure et Teams, décrit ci-dessus. Le lien se situe dans ce qui se passe ensuite : une fois qu’un bot ou un agent commence à être déployé auprès de nombreuses équipes, chacune de ces équipes a toujours besoin d’un espace de collaboration où atterrir. Si ces espaces sont configurés de façon ad hoc, votre bot soigneusement construit finit par se brancher sur une structure de canaux, une convention de nommage ou un modèle d’autorisations différents à chaque fois.
nBold crée des espaces de collaboration Teams à partir de modèles avec gouvernance intégrée, afin qu’une nouvelle application ou un nouvel agent dispose d’une structure cohérente et prévisible à laquelle se rattacher dans chaque équipe où il est ajouté, peu importe qui a créé cette équipe ou quand.
FAQ
Le Bot Framework SDK est-il encore pris en charge pour créer de nouveaux bots Teams ?
Non. Microsoft a archivé le Bot Framework SDK et le Bot Framework Emulator sur GitHub, et les tickets de support ne seront plus traités après le 31 décembre 2025. Pour un nouveau bot, partez plutôt sur le Microsoft 365 Agents SDK, le Teams SDK ou Copilot Studio.
Quel type d’identité choisir lors de la création d’une ressource Azure Bot ?
Optez pour une identité mono-tenant ou une identité managée affectée par l’utilisateur. Microsoft a mis fin à la création de bots multi-tenant après le 31 juillet 2025, même si les bots multi-tenant existants continuent de fonctionner. L’identité mono-tenant et l’identité managée affectée par l’utilisateur ne sont prises en charge que dans les SDK C#, JavaScript et Python.
Puis-je déboguer un bot Teams mono-tenant via Dev Tunnels ?
Non. Dev Tunnels ne prend en charge ni les applications à identité managée affectée par l’utilisateur, ni celles en mono-tenant, donc un bot créé avec l’une ou l’autre identité ne peut pas être tunnelisé via Dev Tunnels pour les tests en local. Définissez votre approche de test en local avant de choisir un type d’identité, pas après.
L’envoi de messages via Microsoft Teams a-t-il un coût dans Azure Bot Service ?
Non. Microsoft Teams est un canal standard, et les messages des canaux standard sont facturés 0,00 $ pour 1 000. Les canaux Premium comme Direct Line sont facturés séparément, à 0,50 $ pour 1 000 messages sur le niveau S1. Vous payez toujours les ressources de calcul qui hébergent votre bot.
Quelle version de schéma de manifeste d’application utiliser pour publier un bot Teams ?
Utilisez la version de schéma 1.30, la version GA actuelle. Les soumissions au store pour les applications compatibles avec les canaux doivent utiliser la version de schéma 1.25 ou ultérieure à partir de juillet 2026, avec supportsChannelFeatures défini sur tier1 déclaré dans le manifeste.