2026 OpenClaw MeshMac en pratique : Microsoft Teams Incoming Webhook pour diffuser l’état de build multi-nœuds

Dans le canal Microsoft Teams cible, ajoutez un connecteur Incoming Webhook (ou le flux équivalent imposé par votre locataire), générez l’URL une fois et considérez la chaîne entière comme un jeton porteur : quiconque peut y POSTer peut saturer le canal. Stockez-la par exemple dans /etc/openclaw/secrets.d/teams/build-status.url avec le mode 0440, propriétaire root et groupe dédié openclaw-notify, sur le modèle de secrets et moindre privilège sur les nœuds MeshMac.

• Ne jamais journaliser l’URL complète. En débogage, affichez l’hôte et les quatre derniers caractères du jeton de chemin.
• Rotation par remplacement. Supprimez le connecteur, recréez le webhook, remplacez le fichier, rechargez la passerelle — alignez la procédure sur canaux d’alerte et rotation des jetons.
• Environnements séparés. Staging et production ont des canaux et des URL distincts pour éviter qu’un workflow mal réglé annonce un faux vert aux décideurs.
• Corps JSON valide. Utilisez un schéma pris en charge (par ex. MessageCard avec @type, résumé, titre, sections). Un corps mal formé renvoie souvent 400 et ressemble à une panne « Teams ».

Les webhooks Teams restent du style « secret dans l’URL » plutôt que HMAC en tête ; malgré tout, appliquez la même rigueur que pour les récepteurs entrants décrits dans webhook OpenClaw : build partagé et notifications. Si votre organisation restreint les connecteurs historiques, un plan B Power Automate ou Logic App avec un point de terminaison HTTPS étroit appelé depuis la passerelle conserve le même modèle : un secret, un émetteur, rotation auditée.

Les builders MeshMac sont souvent derrière un proxy sortant ou un pare-feu d’egress. Seul l’hôte passerelle doit pouvoir effectuer des POST HTTPS vers les points de terminaison webhook de Microsoft. Travaillez avec la sécurité pour autoriser le TLS vers les noms réellement résolus par votre locataire — souvent sous outlook.office.com et *.webhook.office.com — et pour prendre en charge l’inspection TLS du proxy si elle est obligatoire. Refusez l’accès Internet direct depuis les runners self-hôtes sauf via ce saut passerelle.

Liste de contrôle opérationnelle : depuis le shell de la passerelle, exécutez curl -I vers l’hôte du webhook en réutilisant exactement les variables HTTP_PROXY / HTTPS_PROXY du démon ; si le CONNECT échoue, OpenClaw n’atteindra jamais Teams même si les tests unitaires locaux passent. Maintenez la séparation « la CI parle à la passerelle » / « la passerelle parle au SaaS » : une seule politique sortante Microsoft à documenter. Lorsque plusieurs nœuds appelaient auparavant le webhook en direct, consolidez et retirez leurs exceptions : la surface d’attaque diminue et les bascules décrites dans permissions cluster et bascule ne concernent plus qu’une poignée d’adresses IP passerelle.

Chaque fournisseur CI émet un JSON différent. Normalisez sur la passerelle avant de formater le texte ou la carte Teams : une ligne de titre claire, un pied de page qui identifie le Mac du pool, et des liens cliquables vers les journaux évitent les allers-retours SSH.

En option, ajoutez duration_sec et queued_sec lorsque vos métriques de file proviennent du même tissu de tâches OpenClaw que dans file de tâches et étapes de retry : une file lente se voit plus vite qu’une URL de log brute.

Microsoft peut répondre 429 sous limitation ou des 5xx transitoires en périphérie. Utilisez un backoff exponentiel avec jitter, plafonnez le nombre total de tentatives (par exemple cinq sur deux minutes) et tracez le dernier code HTTP dans les journaux passerelle — pas dans la sortie standard bruyante de la CI. Gardez la distinction « retry réseau » / « relancer le build » comme dans le guide file de tâches cité plus haut.

Idempotence : dérivez une clé de provider_run_id + state (ou équivalent) et ignorez un second envoi Teams lorsque la même transition a déjà été acquittée avec succès pendant 72 heures. Stockez les clés dans SQLite, Redis ou un petit fichier si le débit est faible. Sans cela, un retry rapide après une réponse lente duplique les cartes et pousse l’équipe à couper les notifications.

Ne relancez pas aveuglément sur 400 ou 401 : corrigez d’abord le JSON ou l’URL tournée. Un 404 sur le webhook signifie en général « connecteur supprimé » : prévenez le propriétaire gouvernance Teams.

L’étape CI est verte mais le canal reste vide

Vérifiez dans les logs structurés de la passerelle qu’un POST a bien été exécuté avec code de statut. Testez avec curl depuis la passerelle et un corps JSON minimal. Confirmez que le connecteur existe encore — certains locataires désactivent les connecteurs hérités globalement.

Échecs intermittents seulement depuis certains nœuds

Ces machines appellent probablement encore Teams en direct avec un ancien secret ou contournent le proxy. Imposez le chemin passerelle unique et supprimez les règles d’egress par nœud.

HTTP 200 mais carte vide ou erreur d’affichage

Teams a accepté la requête mais a rejeté le rendu. Contrôlez @type, les champs summary/title obligatoires et les limites de taille ; réduisez les pièces jointes si les clients mobiles tronquent.

Tout fonctionnait jusqu’à lundi matin

Inspectez la rotation de certificats sur le proxy le week-end, la dérive DNS vers les points de terminaison Microsoft, et les jobs de rotation de secrets qui auraient touché le mauvais fichier. Croisez avec les runbooks de rotation des jetons et canaux.

D’autres articles OpenClaw sont regroupés sur la page OpenClaw du blog.