Calipia : le blog

À partir du 15 septembre 2025, les administrateurs de Microsoft Teams vont devoir mettre les mains dans le cambouis. Microsoft vient d’annoncer un changement d’authentification pour le module PowerShell Teams, et la firme de Redmond ne mâche pas ses mots : ceux qui ne s’adapteront pas verront tout simplement leurs scripts s’arrêter.

En clair, les organisations qui utilisent des applications Microsoft Entra pour automatiser ou gérer Teams en arrière-plan devront mettre à jour leurs autorisations. L’objectif officiel ? Renforcer la sécurité dans Microsoft 365. Mais dans les faits, cela ajoute une couche de complexité supplémentaire à une architecture déjà souvent labyrinthique.

Un nouveau verrouillage dans la stratégie sécurité de Microsoft

Ce n’est pas une surprise. Après avoir annoncé en juin 2025 la désactivation des anciens protocoles d’authentification, Microsoft continue son opération “zéro tolérance pour la vétusté”. Ce tour de vis survient aussi dans un contexte tendu : les récentes intrusions dans les messageries d’entreprises (notamment le piratage de la rédaction du Washington Post) ont montré que la moindre faille est exploitée.

Avec ce changement, Microsoft impose que les applications Entra appelant le module PowerShell Teams disposent de permissions bien précises :

• RoleManagement.Read.Directory : obligatoire pour toutes les applications afin de valider l’appartenance à une unité administrative.
• GroupMember.Read.All : uniquement si l’application utilise les cmdlets de type -CsGroupPolicyAssignment ou -CsGroupPolicyPackageAssignment.

Sans ces permissions, impossible de gérer Teams par script.

Impact technique pour les DSI

Pour les administrateurs, cela signifie :

1. Audit des applications Entra existantes : passer au crible tous les comptes de service et applications enregistrées, vérifier les rôles (Global Administrator, Teams Administrator, Skype for Business Administrator).
2. Mise à jour des API permissions : ajuster les droits dans App registrations afin d’intégrer les nouvelles autorisations.
3. Tests de non-régression : vérifier que les scripts critiques – souvent imbriqués dans des chaînes d’automatisation – continuent de tourner après la mise à jour.

Au-delà de la technique, il y a une question organisationnelle : qui détient la responsabilité de ces applications “headless” qui opèrent en tâche de fond ? Dans bien des entreprises, elles sont mises en place par un administrateur aujourd’hui parti, et documentées… quelque part (peut-être).

Le risque de “service disruption”

Microsoft le dit sans ambages : si rien n’est fait, le 15 septembre 2025 pourrait rimer avec panne sèche. Les workflows de création d’équipes automatiques, l’application des politiques de sécurité ou encore les scripts de gouvernance tomberont à plat. Autrement dit, la promesse d’“automatisation sereine” que vend le module PowerShell se transformera en réveil brutal pour les équipes IT.

Conclusion

Ce renforcement de sécurité est techniquement justifiable. Mais le timing – imposer un changement structurel à moins d’un an – met une fois encore les DSI devant le fait accompli. Derrière le discours “sécurité d’abord”, Microsoft impose surtout une uniformisation des pratiques qui l’arrange : recentrer les autorisations via Entra, mieux tracer les accès, verrouiller l’écosystème.

C’est cohérent avec la tendance de Microsoft à déplacer le centre de gravité vers Entra ID, tout en complexifiant la gestion au quotidien. Pour les DSI, la vraie difficulté ne sera pas tant d’ajouter deux permissions dans Entra que de s’assurer que tous les environnements, y compris les scripts obscurs hérités, soient adaptés à temps.