Faire dialoguer votre logiciel métier avec Microsoft Teams

Trois portes d'entrée vers Teams : laquelle pour votre besoin ?

Deux questions tranchent : le logiciel doit-il seulement prévenir, ou aussi recevoir une réponse ? Et le message doit-il venir de l'application ou d'une personne ? Une alerte de production se contente d'un webhook ; une demande d'accord sur un devis appelle un bot.

Que reste-t-il des webhooks entrants après les connecteurs Office 365 ?

Les webhooks entrants historiques reposaient sur les connecteurs Office 365, que Microsoft retire. Annoncé le 3 juillet 2024 et plusieurs fois repoussé, ce retrait a reçu un calendrier final le 14 avril 2026 : déploiement du 18 au 22 mai 2026, après quoi ces connecteurs ne fonctionnent plus. Les URL de webhook concernées se remplacent par des webhooks de l'application Workflows (Power Automate), par exemple avec le modèle qui publie dans un canal à réception d'une requête.

Ce que la documentation Teams précise sur ces webhooks :

• le logiciel envoie une requête HTTP POST en JSON à une URL unique, rattachée à un canal ;
• les cartes adaptatives (Adaptive Cards) et le Markdown de base sont pris en charge, le HTML est traité comme du texte brut ;
• un message de plus de 28 Ko est refusé, et au-delà de 4 requêtes par seconde l'expéditeur est limité ;
• le format MessageCard est accepté mais ses boutons ne s'affichent pas, et le message est publié sous l'identité « flow bot » ou au nom d'un utilisateur ;
• un workflow est rattaché à ses propriétaires, et non à l'équipe ou au canal : sans copropriétaire désigné, il devient orphelin quand il n'a plus de propriétaire.

Nous créons donc ces workflows avec plusieurs propriétaires, et l'URL, qui ouvre l'accès au canal, est rangée comme un secret.

Un bot pour notifier et recueillir des réponses

Un bot Teams, que la documentation de Microsoft désigne aussi comme un agent, converse en tête-à-tête, en conversation de groupe ou dans un canal. Microsoft le fait développer avec le Teams SDK, disponible en version générale pour JavaScript et C# et en préversion pour développeurs pour Python, ou avec le Bot Framework SDK, et fournit l'outil Microsoft 365 Agents Toolkit (ancien Teams Toolkit) pour partir de modèles.

Pour qu'un bot écrive de lui-même (message proactif), l'application doit être installée pour l'utilisateur ou dans l'équipe ; l'installation peut passer par Microsoft Graph si l'application figure au catalogue de l'organisation ou dans le Teams Store. Le bot crée la conversation une fois, en conserve l'identifiant, puis l'utilise pour chaque notification. Il ne peut pas ouvrir de nouvelle conversation de groupe ni de nouveau canal, et un utilisateur qui l'a bloqué renvoie une erreur 403 (MessageWritesBlocked), que le logiciel consigne.

Microsoft demande de réessayer les réponses 429, 412, 502 et 504 avec un délai exponentiel assorti d'une part d'aléatoire.

Ce que Microsoft Graph permet sur les canaux et conversations

Microsoft Graph expose les messages Teams sous la ressource chatMessage : lister les messages d'un canal et leurs réponses, lire un message, envoyer dans un canal ou une conversation existante, réagir, supprimer, suivre les changements par requête delta, s'abonner aux nouveaux messages.

• Envoyer : l'envoi dans une conversation existante demande la permission déléguée ChatMessage.Send, donc un utilisateur connecté ; la seule permission d'application documentée, Teamwork.Migrate.All, sert à importer des messages. Microsoft précise aussi qu'utiliser Teams comme fichier journal enfreint ses conditions d'utilisation.
• Être prévenu : un abonnement sur /teams/getAllMessages couvre tous les canaux de l'organisation (permission ChannelMessage.Read.All) ; un abonnement sur un seul canal peut s'appuyer sur un consentement propre à la ressource, ChannelMessage.Read.Group, plus limité, et filtrer par mot-clé. Un abonnement Teams dure 3 jours au plus, l'organisation en compte 10 000 au total, et la latence annoncée reste sous 10 secondes en moyenne. Au-delà d'une heure, une adresse de notifications de cycle de vie est obligatoire.
• Recevoir le contenu : pour que la notification contienne le message lui-même, il faut fournir un certificat de chiffrement ; sinon, le logiciel relit le message par l'API.

Depuis le 25 août 2025, Microsoft ne facture plus l'usage des API Teams de Graph, auparavant comptées à l'appel. Consentement administrateur, limites d'appels et règles de notification sont détaillés sur notre page Microsoft 365 et Microsoft Graph.

Cinq usages de Teams branchés sur un logiciel métier

• Alerte d'atelier. Un automate signale un arrêt de ligne au logiciel de supervision, qui publie par webhook une carte dans le canal « Production » : machine, heure, code défaut. Voir nos automates et supervision reliés à vos logiciels.
• Validation d'un devis. Au-delà d'un montant, le logiciel commercial demande un accord : le bot envoie au directeur une carte « Valider » ou « Refuser », et la réponse revient dans le devis, horodatée.
• Ticket SAV escaladé. Un ticket urgent sans réponse depuis deux heures est publié dans le canal du service avec le lien vers la fiche ; le technicien qui répond « je prends » au bot se voit affecter le ticket. Voir notre page sur le logiciel de maintenance et SAV.
• Point du matin. Chaque jour à 8 h, le logiciel publie dans le canal de direction le chiffre de la veille, les commandes en retard et les factures à relancer.
• Décisions de chantier archivées. Un abonnement Graph sur le canal « Chantiers », filtré par mot-clé, capte les messages qui citent un numéro de dossier et les rattache au dossier dans le logiciel métier.

Les pièges d'une intégration Teams

• L'identité d'envoi : un webhook Workflows publie sous « flow bot » ou au nom d'un utilisateur, un bot sous son nom, Graph au nom d'une personne. Les utilisateurs doivent savoir d'où vient un message pour s'y fier.
• Le bruit : Microsoft recommande que chaque notification dise ce qui s'est passé, qui l'a déclenché, quelles actions sont possibles et comment s'en désabonner. Un canal saturé d'alertes finit en sourdine, et un bot mal accueilli finit bloqué.
• L'installation : publier une application au catalogue et l'installer pour les utilisateurs passe par les stratégies d'applications définies par l'administrateur Teams ; c'est une étape du planning, pas un détail.
• Les données : lire les canaux revient à traiter des échanges internes. Le périmètre se limite aux canaux utiles et la durée de conservation dans le logiciel se fixe d'avance, voir notre guide RGPD et logiciel métier.

Ce que YMHB Web livre pour Teams

Si votre logiciel du marché propose déjà une application Teams, ou si un workflow suffit à publier une alerte, nous le disons et nous nous arrêtons là. Le développement se justifie quand Teams doit dialoguer dans les deux sens avec un logiciel spécifique. Après cadrage et chiffrage, nous livrons :

• l'application Teams (manifeste, bot) et son inscription Entra ID dans votre locataire ;
• les webhooks Workflows créés avec plusieurs propriétaires, leurs URL dans un coffre de secrets ;
• le code du bot et des abonnements Graph, remis avec sa documentation dans votre dépôt ;
• un journal des messages envoyés et des réponses reçues, avec une alerte quand un envoi échoue ou qu'un abonnement expire.

Pour une autre messagerie d'équipe, voir notre page Slack.