Votre extension de messages Teams fonctionne en local mais renvoie “The tenant admin disabled this bot” une fois déployée ? Ce guide pas‑à‑pas explique l’origine probable (dont l’incident TM710191), les vérifications à mener et les correctifs concrets côté Teams et Azure AD.
Contexte et symptômes
Après déploiement de l’application dans l’environnement de développement (tenant cible), l’extension de messages (Message Extension) cesse de répondre et Teams affiche un message d’erreur indiquant que le bot a été désactivé par l’administrateur. Le même package fonctionne pourtant en local (tunnel ou ngrok, Bot Framework Emulator, Developer Portal).
"The tenant admin disabled this bot"
errorCode: 0
standardizedError.errorCode: 209
standardizedError.errorSubCode: 1
Dans Teams, les extensions de messages reposent sur l’infrastructure Bot Framework : si le “bot” associé est bloqué ou si Teams estime qu’il ne doit pas être invoqué, l’extension est à son tour bloquée.
Racine du problème : incident Microsoft + configurations de locataire
L’incident TM710191 a temporairement empêché certains locataires (notamment EDU et tenants fédérés) d’invoquer des bots, ce qui a indirectement interrompu les extensions de messages. Microsoft a effectué un rollback et a communiqué vers les locataires impactés ; le service est revenu à la normale après rétablissement. En parallèle, le même message d’erreur peut aussi être provoqué par un blocage intentionnel côté tenant ou par un consentement manquant.
Ce que signifient les codes d’erreur
| Champ | Valeur | Interprétation |
|---|---|---|
| standardizedError.errorCode | 209 | Blocage d’application/bot au niveau Teams ou politique de l’organisation. |
| standardizedError.errorSubCode | 1 | Concrétise l’état Disabled/Blocked : la demande n’est pas routée vers le bot. |
| Message | “The tenant admin disabled this bot” | Teams considère que l’administrateur du tenant a interdit l’app/bot (qu’il s’agisse d’un blocage temporaire suite à incident ou d’une politique explicite). |
Plan d’action rapide (runbook)
- Vérifier l’état du service dans le Centre d’administration Microsoft 365 > Service Health : confirmez que TM710191 est marqué Résolu.
- Contrôler les politiques Teams : dans Teams apps → Gérer les stratégies, assurez-vous que l’application est autorisée par l’App permission policy active pour vos utilisateurs de test et qu’aucun blocage au niveau global ne s’applique.
- Vérifier Azure AD (Entra ID) : dans l’enregistrement d’application, confirmez les autorisations API et le consentement administrateur ; corrigez d’éventuels consentements manquants.
- Valider le package : alignez l’ID d’application du manifeste, le botId et la composeExtension avec l’environnement cible. Redeployez/republiiez l’app si nécessaire.
- Forcer le rechargement côté client : purgez le cache Teams ou redémarrez le client, puis retestez.
- Confirmer le rétablissement : l’auteur a validé que le problème disparaît après la correction Microsoft.
Diagnostiquer efficacement
1) Checker Service Health
Avant toute modification, écartez l’hypothèse d’un incident plateforme. Si TM710191 (ou un incident proche) figure dans votre tableau de bord et est Résolu, passez aux contrôles locaux. En cas de réapparition d’un incident similaire, attendez le rétablissement ou appliquez les contournements communiqués par Microsoft, puis relancez vos tests.
2) Lire les stratégies qui peuvent bloquer l’app
| Emplacement | Ce qu’il faut vérifier | Résultat attendu |
|---|---|---|
| Teams admin center → Teams apps → Permission policies | Politique appliquée à vos comptes de test ; l’app est‑elle Autorized/Allowed ? Les applications personnalisées (Custom apps) sont‑elles permises ? | L’application est explicitement autorisée ou non bloquée par une liste/stratégie globale. |
| Teams admin center → Teams apps → Setup policies | L’app est‑elle épinglée si votre scénario le requiert ? (Non obligatoire, mais utile pour le test.) | L’app peut être ajoutée par l’utilisateur, voire pré‑épinglée. |
| Teams admin center → Teams apps → Manage apps | État de l’application dans le tenant : Autorisé, Bloqué ou Non disponible. | Autorisé |
| Azure AD → Enregistrement d’application | Autorisations API, consentement admin, configuration SSO/ressources, redirections. | Toutes les autorisations requises présentes et consenties. |
3) Comprendre les écarts entre “local” et “développement”
Le scénario “ça marche en local, pas en dev” trahit souvent une divergence de package, d’ID ou de domaine. Utilisez le tableau ci‑dessous comme grille de contrôle.
| Élément | Local | Développement | Risque si non aligné |
|---|---|---|---|
| appId (manifest) | GUID A | GUID B ? | Le tenant “voit” une autre app/bot et applique une politique différente (potentiellement bloquée). |
| botId (manifest → bots / composeExtensions) | Bot X (dev tunnel) | Bot Y (Azure Bot Service) | Le bot enregistré n’est pas autorisé, d’où le message de blocage. |
| validDomains (manifest) | localhost, *.ngrok | api.dev.contoso.com | App non chargée, ou comportements inattendus lors de l’invocation. |
| webApplicationInfo / resource | ResourceID local | ResourceID prod | Consentements incohérents, jetons invalides, erreurs d’accès Graph. |
| Tenant cible | Dev Tenant | Autre Tenant (EDU/Fédéré) | Politiques et consentements distincts, pouvant bloquer l’app. |
Procédure pas‑à‑pas
Étape A — Vérifier et, si besoin, corriger les politiques Teams
- Dans Teams apps → Manage apps, recherchez votre application ; son état doit être Autorisé. Si elle est Bloquée, débloquez‑la.
- Dans Teams apps → Permission policies, ouvrez la politique appliquée à vos utilisateurs de test :
- Assurez‑vous que les Custom apps sont Autorisées si votre app n’est pas publiée sur le store.
- Si vous utilisez des listes Autoriser/Bloquer, ajoutez votre app dans la liste d’autorisation.
- Dans Teams apps → Setup policies, envisagez d’épingler l’app pour vos testeurs afin de simplifier les essais.
Étape B — Vérifier Azure AD (Entra ID) et le consentement
- Ouvrez l’Enregistrement d’application : confirmez l’Application (client) ID et l’Object ID.
- Dans Autorisations API, vérifiez que toutes les delegated et/ou application nécessaires sont présentes. Cliquez sur Accorder le consentement de l’administrateur si requis.
- Si vous utilisez SSO Teams : contrôlez webApplicationInfo dans le manifeste (resource et application ID URI) et les redirect URIs.
Étape C — Redeployer et republier correctement
- Synchronisez l’ID d’application entre tous vos environnements (local, dev, test, prod) selon votre stratégie : soit un appId par environnement, soit un appId unique avec canaux séparés. Documentez le choix.
- Vérifiez le manifeste : sections
bots,composeExtensions,validDomains,webApplicationInfo, et les itemsscopes. Réemballez (zip) le manifeste et republiez via le Developer Portal ou le Centre d’administration Teams. - Nettoyez le cache Teams après mise à jour (voir plus bas) puis retestez.
Étape D — Tester et collecter des preuves
Activez la journalisation détaillée du client pour capturer les erreurs côté utilisateur et joindre les logs à vos tickets internes.
Raccourci client Teams (Windows / macOS)
Ctrl + Alt + Shift + 1
Cette action génère des archives de logs. Corrélez l’horodatage avec vos essais d’invocation de l’extension.
Nettoyer le cache Teams (forces de rechargement)
Selon l’OS, effacez les dossiers de cache pour forcer le client à recharger le manifeste et l’état des politiques.
Windows
%AppData%\Microsoft\Teams
%LocalAppData%\Microsoft\Teams
macOS
~/Library/Application Support/Microsoft/Teams
Web
Ouvrez Teams dans le navigateur, puis effacez le stockage site (cookies/cache) pour le domaine de l’organisation, reconnectez‑vous et réessayez.
Pourquoi l’incident TM710191 a‑t‑il cassé les extensions ?
Les extensions de messages appellent un point d’entrée Bot Framework (reconnaissance de commandes, recherche, “action” avec task modules). Si un déploiement Teams impacte la résolution ou l’autorisation des bots au niveau plateforme, toutes les fonctionnalités qui reposent sur ce composant héritent du blocage. Le message 209/1 est alors un symptôme générique : Teams pense que votre bot est “désactivé par l’admin”, alors que la cause réelle est temporaire et côté service. D’où l’importance : vérifier d’abord Service Health avant de retoucher vos politiques.
Check‑list “Configuration du locataire”
| Question | Validation | Correctif si échec |
|---|---|---|
| Votre app figure‑t‑elle comme Autorisée ? | Teams → Manage apps | Changer l’état sur Autorisé. |
| La Permission policy active autorise‑t‑elle votre app ? | Teams → Permission policies | Ajouter l’app en liste d’autorisation ou ouvrir les Custom apps. |
| Les API permissions ont‑elles un consentement admin valide ? | Azure AD → Enregistrement d’app | Accorder le consentement au niveau tenant. |
| Le botId et l’appId du manifeste correspondent au tenant cible ? | Manifeste comparé à l’enregistrement Azure | Corriger le manifeste et republier. |
| Les validDomains contiennent vos FQDN publics ? | Manifeste → validDomains | Ajouter les domaines manquants et réemballer. |
| Des politiques de sécurité (CA, ToU, Device) bloquent‑elles l’app ? | Azure AD Sign‑in Logs | Ajuster les règles, ajouter une exclusion pour l’app, ou satisfaire les exigences. |
Exploitation des Sign‑In Logs Azure AD
Les journaux de connexion révèlent des signaux utiles lorsqu’une politique conditionnelle bloque l’émission du jeton requis par votre extension :
- ConsentRequired / InteractionRequired : un consentement admin manque.
- BlockedByConditionalAccess : une règle de CA empêche l’accès (local fonctionnait car vous étiez dans un autre contexte).
- MfaRequired, TermsOfUse, DeviceNotCompliant : exigences non remplies par l’utilisateur de test.
Filtrez par Application (SPN) de votre app ou par Client App pour isoler les tentatives liées à Teams et vérifiez les échecs corrélés à vos tests.
Bonnes pratiques CI/CD pour Teams et Azure AD
- Environnements séparés : au minimum dev / test / prod avec des enregistrements d’app dédiés. Documentez appId, botId, secrets, et validDomains par environnement.
- Contrôles automatiques pré‑déploiement : requête vers l’API Service Health ou procédure manuelle pour bloquer un déploiement si un incident Teams est en cours.
- Tests d’intégration : scénario d’invocation de l’extension (recherche/action) exécuté contre le tenant cible, avec vérification du code renvoyé.
- Observabilité : instrumentation côté bot (télémétrie, App Insights), corrélation avec l’ID d’activité Teams pour suivre les refus d’invocation.
- Feature flags : capacité à désactiver temporairement une fonctionnalité côté serveur en cas d’incident plateforme.
Dépannage rapide côté client
- Logs Teams : Ctrl + Alt + Shift + 1 pour capturer une archive. Reproduisez l’appel d’extension et notez l’horodatage.
- Redémarrage complet du client après purge de cache.
- Test croisé : autre utilisateur, autre poste, Teams Web vs Desktop.
- Vérification du manifeste local dans le Developer Portal : importer le zip de dev, confirmer l’ID et les domaines.
Exemples utiles de manifeste
Section composeExtensions (extrait)
{
"composeExtensions": [
{
"botId": "00000000-0000-0000-0000-000000000000",
"commands": [
{
"id": "search",
"title": "Recherche",
"parameters": [{ "name": "q", "title": "Query" }]
}
]
}
],
"validDomains": [
"api.dev.contoso.com",
"login.microsoftonline.com"
]
}
Section SSO (si utilisée)
{
"webApplicationInfo": {
"id": "11111111-1111-1111-1111-111111111111",
"resource": "api://dev-contoso-app-id"
}
}
Une incohérence d’ID entre cette section et l’enregistrement Azure AD de l’environnement cible est une cause fréquente d’échecs en dev.
FAQ ciblée
Q : Pourquoi le message indique “admin disabled this bot” alors que l’admin n’a rien changé ?
R : Parce que Teams bloque effectivement l’invocation du bot ; la cause peut être une politique ou un incident temporaire côté service (comme TM710191). Le message ne distingue pas ces cas.
Q : Mon extension répond en local via un tunnel. En dev, elle échoue avec 209/1. Que regarder en premier ?
R : Confirmez le statut de Service Health ; puis alignez appId/botId/validDomains et la politique Teams du tenant dev. Enfin, vérifiez le consentement d’application.
Q : Une politique de sécurité Azure AD peut‑elle générer ce message ?
R : Oui. Si une règle Conditional Access empêche l’obtention du jeton attendu, Teams peut refuser l’invocation. Les Sign‑In Logs rendent ce diagnostic explicite.
Q : Faut‑il un appId par environnement ?
R : Deux stratégies existent. Beaucoup d’équipes préfèrent un appId distinct par environnement pour isoler les politiques et consentements. D’autres gardent un appId unique avec une gouvernance stricte. L’important est la cohérence et la documentation.
Étude de cas résumée
Pendant TM710191, plusieurs tenants (principalement EDU et fédérés) ont vu leurs bots refusés. Les extensions de messages associées ont affiché 209/1. Après rollback Microsoft, le service est revenu à la normale. Dans l’environnement analysé, aucune politique locale ne bloquait l’application ; le redéploiement du package et la purge de cache ont suffi à valider le rétablissement. Ce scénario illustre pourquoi la vérification Service Health doit précéder toute modification de configuration.
Modèle de runbook prêt à l’emploi
- Pré‑check : Service Health (rechercher TM710191 ou incident actif lié à Teams/Bot).
- Politiques : Manage apps (Autorisé), Permission policy (app/Custom apps autorisées), Setup policy (optionnel).
- Azure AD : consentements, webApplicationInfo, redirections, secret/certificats à jour.
- Manifeste : appId/botId/validDomains/webApplicationInfo alignés sur le tenant dev.
- Client : purge cache Teams, redémarrage.
- Validation : test d’invocation, collecte logs client, corrélation avec Sign‑In Logs si échec.
- Communication : si incident plateforme, informer les équipes que la correction est côté Microsoft ; sinon, documenter la ou les politiques ajustées.
Conseils d’exploitation continue
- Observabilité : journaliser l’errorCode et l’errorSubCode renvoyés par vos handlers pour accélérer le triage.
- Alertes : déclencher une alerte sur une hausse des 209/1 afin d’identifier rapidement un blocage généralisé.
- Playbooks d’urgence : prévoir un message utilisateur clair (“incident en cours, pas d’action requise côté client”) pour réduire le support.
Ressources et canaux d’assistance interne
- Communauté développeurs Teams : le forum Teams Developer – Microsoft Community Hub est adapté aux questions de ce type (publiez logs et manifeste expurgés).
- Support Microsoft : si un incident similaire réapparaît, ouvrez un ticket en partageant le message 209/1 et vos journaux de connexion.
Conclusion
Le message “The tenant admin disabled this bot” avec standardizedError 209/1 est un symptôme commun à deux classes de problèmes : des incidents plateforme comme TM710191 et des configurations de tenant (politiques Teams, consentements Azure AD, sécurité conditionnelle). Le bon réflexe est de commencer par Service Health, puis d’appliquer la check‑list de politiques et d’alignement de manifeste. Enfin, validez en purgeant le cache client et en examinant les Sign‑In Logs. Dans le cas étudié, la cause était bien un incident temporaire côté Microsoft ; néanmoins, instaurer une discipline CI/CD et des contrôles automatisés vous évitera que ce type d’incident ne compromette vos mises en production.
Annexe — Référentiel de vérification rapide
| Étape | Action | Critère de succès |
|---|---|---|
| Service Health | Confirmer l’état Résolu de TM710191 (ou incident analogue). | Incident clos, pas d’alerte en cours. |
| Teams Manage apps | État de l’app : Autorisé. | L’application n’est plus bloquée. |
| Permission policy | App ou Custom apps autorisées. | Aucune politique n’empêche l’ajout/l’invocation. |
| Azure AD | Consentement administrateur accordé pour les scopes requis. | Pas d’erreur ConsentRequired dans les Sign‑In Logs. |
| Manifeste | appId/botId/validDomains/webApplicationInfo alignés. | L’extension se charge et s’invoque. |
| Client | Purge cache et redémarrage. | Le manifeste est rechargé, plus d’erreurs de cache. |
Annexe — Rappels utiles
- Message Extension ≠ Bot autonome mais s’appuie sur un botId : si le bot est bloqué, l’extension l’est aussi.
- 209/1 n’implique pas nécessairement une action volontaire de l’admin : il peut signaler un incident en amont.
- Local vs Dev : la différence d’appId ou de botId est l’écueil numéro 1.
- Azure AD : en cas de règles CA strictes, isolez un groupe de test autorisé à utiliser l’app en dev.
Récapitulatif des solutions appliquées / recommandées
- Vérifier Service Health : confirmer TM710191 en Résolu.
- Contrôler les stratégies Teams et Azure AD :
- Autoriser l’app dans Teams Apps → Gérer les stratégies.
- Vérifier les autorisations API et le consentement d’admin dans les Enregistrements d’applications Azure AD.
- Redéployer / republier l’application :
- Aligner l’ID d’application et le package manifeste entre local et dev.
- Purger le cache Teams (ou redémarrer le client) pour recharger le manifeste.
- Tester après rétablissement : l’auteur a confirmé le retour à la normale après correction Microsoft.
En synthèse
Votre extension de messages était bloquée non pas par une mauvaise configuration locale, mais par un incident temporaire côté Microsoft (TM710191). Cela n’exonère pas pour autant la gouvernance du tenant : un œil systématique sur Service Health, une politique Teams claire, des consentements Azure AD rigoureux, et un manifeste strictement cohérent entre environnements réduiront drastiquement le risque de retrouver “The tenant admin disabled this bot” lors de vos prochains déploiements.