Alertes d’exploitation dans Teams : passer du webhook O365 au workflow

Une alerte qui part dans un canal Teams depuis un script ou un playbook a souvent un webhook de connecteur Office 365 au bout. Ce service est retiré : l’alerte se tait.

Ce qui a changé, et quand

Le billet du blog Microsoft 365 Developer, publié le 3 juillet 2024, a été mis à jour à mesure que l’échéance glissait, de fin 2025 au 30 avril 2026. La mise à jour du 14 avril 2026 fixe le déploiement final du 18 au 22 mai 2026 : après cette date, les connecteurs Office 365 ne fonctionnent plus. Les webhooks des connecteurs doivent être migrés vers des workflows Power Automate.

Constat terrain, en août 2026 : des playbooks Prism Central envoyaient chacun un mail et un message Teams. Les mails arrivaient, Teams restait muet, alors que les playbooks restaient validés et actifs.

Créer le workflow

Dans Teams, menu du canal, Workflows, modèle Send webhook alerts to a channel. Une fois le workflow enregistré, on copie son URL, et on la traite aussitôt comme un secret.

Le déclencheur propose trois modes : quiconque, tout utilisateur du tenant, ou des utilisateurs précis. Avec « Anyone », la doc Power Automate est nette : quiconque a accès à l’URL peut déclencher le workflow. Pour les flux à déclencheur HTTP, Microsoft documente une URL signée par un paramètre sig= et une procédure pour régénérer cette clé SAS, ce qui invalide l’ancienne : c’est le geste à connaître en cas de fuite. Avec les deux autres modes, chaque requête doit porter un jeton.

Autre point : un workflow appartient à un utilisateur, pas au canal. Sans co-propriétaire, il devient orphelin au départ de son auteur.

Le format : une carte

La doc Learn indique que les workflows acceptent les Adaptive Cards et le format Message Card. Pour une Adaptive Card, la doc du connecteur Teams décrit un message avec une pièce jointe application/vnd.microsoft.card.adaptive. La page Learn sur les webhooks montre aussi un exemple {"text": "..."}. Sur le terrain, le modèle « Send webhook alerts to a channel » a refusé cette charge (exécution en échec dans l’historique du workflow) et accepté la carte. Testez sur votre propre workflow avant de migrer.

import os
import sys
import time

import requests

URL = os.environ["TEAMS_WEBHOOK_URL"]  # secret : jamais dans le code ni dans les logs


def carte(titre, texte):
    return {
        "type": "message",
        "attachments": [{
            "contentType": "application/vnd.microsoft.card.adaptive",
            "contentUrl": None,
            "content": {
                "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
                "type": "AdaptiveCard",
                "version": "1.2",
                "body": [
                    {"type": "TextBlock", "text": f"**{titre}**", "wrap": True},
                    {"type": "TextBlock", "text": texte, "wrap": True},
                ],
            },
        }],
    }


def envoyer(payload, essais=3):
    for i in range(essais):
        if i:
            time.sleep(2 ** i)  # attente avant un nouvel essai, jamais après le dernier
        try:
            r = requests.post(URL, json=payload, timeout=10)  # vérification TLS active par défaut
        except requests.ConnectionError as e:
            # le message de l'exception peut contenir l'URL : on n'affiche que son type
            # une coupure après envoi lève aussi cette exception : doublon possible
            print(f"Teams injoignable : {type(e).__name__}", file=sys.stderr)
            continue
        except requests.RequestException as e:
            # timeout de lecture : la requête a pu passer, on ne réessaie pas
            print(f"Envoi incertain : {type(e).__name__}", file=sys.stderr)
            return False
        if r.status_code in (200, 202):
            return True  # accepté, pas forcément publié
        print(f"Teams a répondu HTTP {r.status_code}", file=sys.stderr)
        if r.status_code != 429:
            return False  # seul l'étranglement justifie un nouvel essai
    return False


if not envoyer(carte("Alerte <cluster>", "Seuil dépassé sur <VM>")):
    sys.exit(1)

Pour les connecteurs (webhooks entrants), la page Learn donne 28 Ko par message et un étranglement au-delà de quatre requêtes par seconde. Pour le déclencheur « When a Teams webhook request is received », la page du connecteur Teams donne environ 1 000 appels entrants simultanés et 4 500 ou 45 000 invocations par 5 minutes selon le profil de performance.

Ce que HTTP 202 ne prouve pas

Le POST direct sur le workflow a répondu 202 : la plateforme a accepté la requête. Ça ne dit pas que le workflow a publié le message. La preuve est dans l’historique d’exécution du workflow et dans le canal.

Depuis un playbook Prism Central

L’action native Teams n’émet qu’un {"text"}. On l’a remplacée par une action REST API dont le corps est la carte, variables du playbook comprises. Pièges observés :

• sans use_credential_store (ici "false"), la validation échoue et Prism Central désactive le playbook ;
• webhook_url et password sont lus masqués (********) par l’API : ne renvoyez jamais par PUT une règle qui en contient, le littéral écraserait le secret ;
• l’état de validation lu juste après un PUT est périmé, attendez une quinzaine de secondes ;
• garde-fou : sauvegarde complète des règles avant tout PUT, simulation par défaut, GET frais avant chaque écriture, et is_enabled: true reposé dans le PUT correctif.

Ce qu’il faut retenir

• Les connecteurs Office 365 ne fonctionnent plus depuis le déploiement de mai 2026 : migrez vers un workflow.
• Postez une Adaptive Card, et testez le format sur votre workflow.
• L’URL est un secret : variable d’environnement, jamais dans le code ni dans les logs.
• Un 202 n’est pas une preuve : vérifiez l’historique du workflow.
• Gardez un second canal, le mail a survécu à la panne.

In English

Teams Office 365 connectors no longer work. Create the workflow, post an Adaptive Card from a script, protect the URL, and do not take an HTTP 202 at face value: it proves receipt, not that the message was posted. In Anyone mode, whoever has the workflow URL can trigger it, and webhooks now go through Power Automate workflows.

Sources & vérification

Testé sur : Prism Central de production, août 2026

• Microsoft 365 Developer Blog, Retirement of Office 365 connectors within Microsoft Teams devblogs.microsoft.com
• Microsoft Learn, Create an Incoming Webhook learn.microsoft.com
• Microsoft Learn, connecteur Microsoft Teams, déclencheur webhook learn.microsoft.com
• Microsoft Learn, Add OAuth authentication for HTTP request triggers learn.microsoft.com
• Microsoft Learn, Regenerate the SAS key used in HTTP trigger flows learn.microsoft.com
• Microsoft Learn, Adaptive Cards, Text Features learn.microsoft.com
• Expérience directe de l’auteur, en production (versions ci-dessus)

Comment les billets sont vérifiés et corrigés