Utiliser Microsoft Teams pour la gestion : un tableau Excel partagé par e-mail chaque lundi, mis à jour à la main, avec des numéros de téléphone qui ne sont plus à jour depuis deux mois : c’est encore la réalité de la gestion des astreintes dans une majorité d’équipes IT et de support, malgré les risques évidents d’erreur au pire moment, celui où un incident critique survient un dimanche à trois heures du matin. La fonctionnalité Shifts (Horaires) de Microsoft Teams, couplée à Power Automate et éventuellement à des connecteurs tiers, permet de construire un système de gestion d’astreinte fiable, traçable et directement intégré à l’outil de communication que l’équipe utilise déjà. Voici comment le mettre en place concrètement, des rotations de base jusqu’à l’escalade automatisée en cas de non-réponse.
Poser les rotations d’astreinte dans l’application Shifts
L’application Shifts, accessible directement dans la barre latérale Teams, permet de créer un planning d’équipe avec des groupes de postes dédiés à l’astreinte, distincts des horaires de travail classiques. La bonne pratique consiste à créer un groupe spécifique nommé par exemple « Astreinte N1 » ou « Astreinte Infra », avec un poste type paramétré sur une durée de sept jours (du lundi 9h au lundi suivant 9h, ou toute autre convention retenue dans l’accord d’astreinte de l’entreprise) plutôt que des postes quotidiens qui multiplient les manipulations. Shifts permet d’affecter les postes soit manuellement semaine par semaine, soit via un modèle récurrent qui répète automatiquement la rotation entre les membres de l’équipe éligibles, ce qui réduit drastiquement le temps de gestion administrative du planning. Un point souvent négligé : la fonction « Demander un échange » intégrée à Shifts permet à deux techniciens de s’échanger un poste d’astreinte directement dans l’application, avec validation du manager, ce qui évite les échanges informels par SMS qui ne sont ensuite tracés nulle part et créent des zones de flou en cas d’incident sur une astreinte qui n’était plus « officiellement » tenue par la personne prévue au planning initial.
Relier l’astreinte à la présence et aux notifications prioritaires
Un planning d’astreinte n’a de valeur que s’il déclenche effectivement une notification qui sort la personne d’astreinte de son silence nocturne. Teams propose depuis plusieurs versions les notifications prioritaires : un message marqué « Urgent » sonne et vibre en boucle sur l’appareil du destinataire toutes les deux minutes pendant vingt minutes, jusqu’à ce qu’il soit lu, y compris si le statut de présence est réglé sur « Ne pas déranger ». C’est ce mécanisme, et non un simple message standard, qui doit être utilisé pour toute alerte adressée à la personne d’astreinte, car un message classique peut rester invisible plusieurs heures en dehors des horaires de bureau. Pour automatiser ce déclenchement plutôt que de compter sur un humain qui pense à cocher « Urgent », un flux Power Automate peut interroger l’application Shifts via l’API Microsoft Graph pour identifier qui est d’astreinte au moment précis de l’incident, puis envoyer automatiquement un message urgent à la bonne personne dans un canal ou en message privé, déclenché par exemple par un ticket créé dans l’outil ITSM ou par une alerte de supervision (Azure Monitor, Nagios, Datadog) reliée via webhook.
Construire une chaîne d’escalade automatisée
L’astreinte ne se limite pas à identifier la bonne personne : elle doit prévoir ce qui se passe si cette personne ne répond pas. Un flux Power Automate robuste combine trois éléments : une notification urgente initiale, un délai d’attente de réponse (typiquement quinze minutes, à ajuster selon la criticité), et une bascule automatique vers l’astreinte de niveau 2 ou le manager d’astreinte si aucune accusé de réception n’est enregistré. L’accusé de réception peut prendre la forme d’une carte adaptative avec un bouton « Je prends en charge » envoyé dans le message Teams, dont le clic écrit un horodatage dans une liste Microsoft de suivi des incidents ; l’absence de clic dans le délai imparti déclenche l’étape suivante de la chaîne. Ce mécanisme reproduit dans Teams ce que proposent des outils spécialisés comme PagerDuty ou Opsgenie, avec l’avantage de ne pas multiplier les applications pour une équipe qui n’a pas le volume d’incidents justifiant une licence dédiée. Pour les organisations qui gèrent déjà PagerDuty ou Opsgenie en parallèle, le connecteur Teams officiel de ces plateformes permet d’afficher et de gérer les alertes directement depuis un canal dédié, ce qui reste souvent préférable dès que le volume d’astreintes dépasse une équipe unique.
Adapter le dispositif par métier
Les besoins d’astreinte diffèrent nettement selon le métier concerné, et le dispositif Teams doit s’y adapter plutôt que d’imposer un modèle unique. Pour une astreinte IT infrastructure, la priorité est la rapidité de bascule vers l’escalade, avec des délais de réponse courts (dix à quinze minutes) et une intégration directe aux outils de supervision. Pour une astreinte support client ou hotline métier, le sujet est davantage la visibilité du planning pour les équipes commerciales ou les clients internes eux-mêmes : un onglet Shifts partagé en lecture dans un canal « Contacts urgence » permet à toute personne autorisée de voir immédiatement qui contacter sans devoir interroger un manager. Pour une astreinte de type facilities ou sécurité physique (gestion de bâtiment, sécurité incendie), le dispositif doit prévoir un accès mobile fiable même en cas de connectivité réseau limitée, ce qui pousse à privilégier les notifications SMS en complément des notifications Teams via un connecteur comme Twilio, Teams seul ne pouvant garantir une alerte en zone de faible couverture data. Documentez ces variantes dans une fiche par type d’astreinte plutôt que de vouloir un seul processus universel qui finira par mal servir tout le monde.
Assurer la traçabilité et le suivi de charge
Au-delà de la réactivité en temps réel, un dispositif d’astreinte doit produire des données exploitables pour piloter la charge et respecter les obligations légales de repos compensateur. Chaque intervention déclenchée via le flux Power Automate décrit plus haut doit écrire une ligne dans une liste Microsoft ou une table Dataverse : horodatage de l’alerte, personne notifiée, temps de réponse, durée de l’intervention, nature de l’incident. Ce journal, exploité ensuite dans un tableau de bord Power BI connecté directement à la source, permet de objectiver deux choses essentielles pour un responsable d’équipe : la charge réelle supportée par chaque personne d’astreinte sur un trimestre, indispensable pour ajuster une compensation financière ou en repos, et la fréquence des incidents hors heures ouvrées par catégorie, qui alimente les arbitrages de fiabilisation technique à plus long terme. Sans cette traçabilité automatisée, l’évaluation de la charge d’astreinte repose sur des souvenirs et des déclarations manuelles, une source de tension récurrente entre équipes et management lors des révisions d’accord d’astreinte.