Microsoft modifie l’adresse du client web de Teams. En septembre 2026, les utilisateurs qui ouvriront teams.microsoft.com pourront être redirigés vers teams.cloud.microsoft. Microsoft présente cette évolution comme un changement de domaine, et non comme une migration fonctionnelle : les liens et favoris existants devraient continuer à fonctionner, et les utilisateurs finaux n’auront pas à installer un nouveau client.

Illustration éditoriale d’une redirection du navigateur à travers les contrôles d’entreprise du pare-feu, du DNS, du proxy et des applications intégrées.

Cela paraît banal jusqu’à ce que la requête traverse un proxy d’entreprise, une passerelle web sécurisée, une politique DNS, une liste blanche de navigateur, une politique de sécurité du contenu, un manifeste d’application ou un contrôle d’accès distant. Dans ces environnements, une redirection n’est pas automatiquement inoffensive. Le navigateur doit pouvoir résoudre et joindre la destination, les outils de sécurité doivent l’autoriser et les applications Teams intégrées doivent reconnaître la nouvelle origine.

Le conseil immédiat est simple : considérez teams.cloud.microsoft comme un point de terminaison de production, vérifiez les données de points de terminaison Microsoft 365 utilisées par votre organisation et testez l’expérience web complète avant que les utilisateurs ne découvrent le changement à l’occasion d’un échec de connexion ou d’un onglet vide. La leçon dépasse Teams. Les changements d’URL des services SaaS doivent relever de la gestion des points de terminaison et du contrôle des changements, même lorsque l’éditeur affirme qu’aucune fonctionnalité ne change.

Ce que Microsoft change

L’avis Message Center MC1465764 indique que les utilisateurs web de Teams seront redirigés de teams.microsoft.com vers teams.cloud.microsoft d’ici septembre 2026. L’avis classe cette évolution comme un changement majeur ayant un impact pour les administrateurs. La destination utilise la famille de domaines plus large cloud.microsoft, introduite par Microsoft pour les expériences Microsoft 365 authentifiées et destinées aux utilisateurs.

La migration n’est pas présentée comme un nouveau client Teams ni comme un nouveau système de comptes. Une personne utilisant le navigateur devrait toujours accéder au même service, avec les mêmes conversations, réunions, fichiers et contexte organisationnel. La différence visible sera l’adresse affichée dans le navigateur, ainsi que les comportements réseau et applicatifs qui découlent de cette adresse.

Microsoft indique que l’ancienne URL effectuera une redirection et que les liens existants continueront de fonctionner. Cela réduit les perturbations pour les utilisateurs ordinaires, mais ne supprime pas la nécessité de tests administratifs. Un favori peut suivre une redirection HTTP ; un proxy strictement administré peut évaluer séparément les deux noms d’hôte. Un navigateur peut charger la page tandis qu’un onglet intégré échoue parce que sa politique frame-ancestors n’a pas été mise à jour. Un pare-feu peut autoriser teams.microsoft.com tout en rejetant *.cloud.microsoft.

L’avis du Message Center précise également qu’un contrôle d’administration temporaire peut désactiver la redirection, mais que ce contrôle prendra fin le 31 décembre 2026. Il s’agit donc d’une aide à la migration, pas d’un modèle d’exploitation durable. Les organisations qui l’utilisent doivent consigner l’exception, lui attribuer un responsable et planifier sa suppression.

La documentation publique de Microsoft sur les points de terminaison répertorie déjà *.teams.microsoft.com et *.teams.cloud.microsoft pour Teams, ainsi que teams.microsoft.com et teams.cloud.microsoft. Cette même documentation répertorie *.cloud.microsoft comme point de terminaison unifié requis pour les expériences Microsoft 365 authentifiées. La conséquence pratique est importante : l’organisation doit mettre à jour son processus de référence pour les points de terminaison, et pas seulement ajouter un nom d’hôte à une règle de pare-feu.

Pourquoi une redirection peut devenir une panne

Une redirection traverse plusieurs points de contrôle. Chacun peut produire un symptôme différent, et l’utilisateur peut avoir l’impression que « Teams est en panne » alors que le service Microsoft fonctionne normalement.

Pare-feu et passerelles web sécurisées

Les listes blanches traditionnelles contiennent souvent des noms d’hôte précis. Si la règle autorise teams.microsoft.com mais pas teams.cloud.microsoft, la première requête peut aboutir et la requête redirigée être bloquée. Selon la passerelle, les utilisateurs verront une page d’accès refusé, un délai d’attente, une boucle d’authentification ou une interface applicative incomplète.

Certaines organisations utilisent un filtrage par catégorie, une inspection TLS ou un routage proxy explicite. Ces contrôles peuvent s’appuyer sur les noms présents dans les certificats, les catégories d’URL ou des règles écrites autour de l’ancien domaine. Le nouvel hôte doit être évalué selon la même politique attendue. Ajouter un caractère générique très large sans examiner son traitement par la passerelle peut créer une exposition inutile ; refuser le caractère générique sans comprendre les recommandations de Microsoft peut rendre l’exploitation fragile. La bonne décision dépend du modèle de contrôle de l’organisation, mais elle doit être délibérée et documentée.

DNS et comportements des réseaux séparés

Un nouveau nom d’hôte entre aussi dans les processus DNS. Les résolveurs internes, les services de filtrage, les produits DNS sécurisés et les clients d’accès distant peuvent appliquer des règles différentes à un domaine nouvellement observé. Testez les réseaux du bureau, les appareils connectés au VPN, les situations de télétravail et les environnements de bureau virtuel administrés. Un test réussi depuis l’ordinateur portable d’un administrateur ne prouve pas que toutes les voies de sortie fonctionneront de la même manière.

Ne codez pas une adresse IP en dur pour ce changement. Les recommandations de Microsoft sont exprimées en termes de domaines de service et de données d’adresses publiées, et les services cloud peuvent modifier leur infrastructure sous-jacente. Une solution de contournement fondée sur une IP peut échouer lors d’une évolution normale du service et détourner les contrôles de leur objectif, qui repose sur les noms d’hôte.

Confiance du navigateur et politiques de cookies

L’accès web à Teams dépend du comportement du navigateur autant que de l’accessibilité réseau. Les recommandations de dépannage de Microsoft pour Teams citent *.cloud.microsoft parmi les domaines qui peuvent devoir être considérés comme fiables lorsque les contrôles du navigateur restreignent les cookies ou les sites de confiance. Les organisations qui bloquent les cookies tiers, imposent des listes de sites ou déploient des stratégies de groupe doivent tester la connexion, le lancement d’une réunion et la navigation après la redirection.

Une exception de domaine doit être limitée aux services Microsoft nécessaires et soumise au même processus de revue que les autres exceptions liées à l’authentification. Évitez de désactiver globalement une protection de confidentialité du navigateur pour faire passer un seul test. Commencez par déterminer si le problème vient de la portée des cookies, d’une politique de sites de confiance, de l’inspection TLS, d’une règle proxy ou d’un point de terminaison bloqué.

Applications et onglets Teams intégrés

Teams sert également d’hôte pour des applications. Un onglet personnalisé, un outil métier ou une application partenaire peut être chargé à l’intérieur du client web Teams plutôt que comme page de premier niveau. Dans ce cas, le nouvel hôte modifie l’origine du navigateur et peut révéler des hypothèses qui étaient invisibles avec l’ancienne adresse.

Les recommandations de développement Teams de Microsoft indiquent que les propriétaires d’applications doivent mettre à jour la bibliothèque JavaScript Teams vers la version 2.19.0 ou une version ultérieure et initialiser l’application pour le nouvel hôte. Elles précisent aussi que les applications utilisant des en-têtes de politique de sécurité du contenu doivent inclure *.cloud.microsoft dans la directive frame-ancestors, tout en conservant les valeurs existantes pour assurer la compatibilité descendante pendant la migration.

Cela ne justifie pas de modifier indistinctement tous les en-têtes de sécurité. Il faut plutôt confronter l’en-tête à la liste réelle des hôtes pris en charge, tester l’application dans le client web Teams et vérifier que la validation des origines, les entrées validDomains, les paramètres de cookies et le traitement de postMessage correspondent toujours au parcours applicatif prévu.

Un échec fréquent est partiel : l’interface Teams se charge, mais un onglet affiche un cadre vide ; l’onglet s’ouvre, mais la sélection de fichiers échoue ; ou l’authentification revient vers l’application sans session utilisable. Notez l’hôte visible dans le navigateur et celui qui apparaît dans les traces réseau avant de modifier le code applicatif.

Qui est concerné

Le premier groupe concerné rassemble les organisations qui utilisent Teams dans un navigateur et contrôlent les accès sortants au moyen de pare-feu, proxys, passerelles web sécurisées, filtres DNS ou politiques de navigateur administrées. Le changement sera moins visible pour les personnes qui utilisent uniquement le client de bureau ou mobile, même si les liens, les relais d’authentification et les expériences intégrées peuvent encore faire intervenir des composants web.

Les propriétaires d’applications Teams constituent un deuxième groupe. Il s’agit notamment des développeurs internes, des éditeurs de logiciels, des équipes intranet et des services qui maintiennent des onglets, des extensions de messagerie, des sites web intégrés dans Teams ou des intégrations validant l’origine Teams. Leur risque ne se limite pas à la redirection initiale. Un nouvel hôte peut affecter les politiques de cadres, les contrôles d’origine, les hypothèses sur les URI de redirection, les attributs de cookies, les filtres de télémétrie et la documentation de support.

Les équipes réseau et identité doivent également participer. Elles détiennent souvent des morceaux différents du parcours : l’équipe réseau gère la sortie, l’équipe poste de travail la politique du navigateur, l’équipe identité les contrôles de connexion et l’équipe applicative le contenu intégré. Une évolution qui traverse ces quatre responsabilités peut passer entre les files d’attente si personne ne la traite comme un seul changement de service.

Les petites organisations ne sont pas automatiquement exemptées. Une petite entreprise peut ne pas disposer d’un proxy complexe, mais dépendre d’un pare-feu administré, d’un prestataire informatique ou d’une politique de navigateur héritée d’une organisation mère. Les environnements les plus simples doivent tester rapidement plutôt que supposer que leur simplicité garantit la compatibilité.

Les détails des points de terminaison qui comptent

La documentation Microsoft sur les URL et les plages d’adresses IP de Microsoft 365 indique que les points de terminaison requis doivent être accessibles et identifie *.cloud.microsoft comme une destination unifiée requise sur TCP 443 et UDP 443. Dans la section consacrée à Teams, elle répertorie *.teams.cloud.microsoft, *.teams.microsoft.com, teams.cloud.microsoft et teams.microsoft.com, avec TCP 443 et 80 ainsi qu’UDP 443.

Ces entrées sont plus utiles qu’une liste copiée depuis un message de forum, car Microsoft met à jour les données de points de terminaison lorsque ses services évoluent. La documentation précise que les données sont normalement publiées à l’avance, mais que des mises à jour peuvent aussi intervenir au cours du mois pour des escalades de support, des incidents de sécurité ou d’autres besoins opérationnels immédiats. C’est un argument solide en faveur de l’automatisation du flux de points de terminaison de l’organisation lorsque les outils de sécurité le permettent.

C’est aussi un rappel de l’importance des catégories de points de terminaison. Microsoft distingue les destinations requises, facultatives et par défaut, et explique qu’une fonctionnalité peut dépendre de points de terminaison appartenant à plusieurs groupes de charges de travail. Une équipe qui cherche simplement « Teams » dans une liste statique peut manquer un point de terminaison courant d’authentification ou de contenu, pourtant nécessaire à l’expérience complète.

La séquence opérationnelle sûre consiste à comparer les données actuelles de Microsoft avec les couches de contrôle réelles de l’organisation, puis à tester le résultat. Ne supposez pas qu’une seule liste blanche sur le pare-feu périmétrique représente toute la politique. Un courtier de sécurité d’accès au cloud, un agent de poste, une configuration de navigateur, une zone DNS privée ou une règle de tunnel partagé VPN peut encore bloquer le nouvel hôte.

Un plan de validation pratique

1. Identifier les vrais utilisateurs et les vrais parcours

Commencez par un inventaire, pas par une modification de règle. Déterminez quels groupes ouvrent Teams dans un navigateur, lesquels utilisent des bureaux virtuels, quels utilisateurs se connectent au VPN et si des prestataires ou fournisseurs de services administrés utilisent des voies de sortie différentes. Incluez les postes partagés, les appareils de type borne et les systèmes de salle de réunion s’ils lancent des liens Teams dans un navigateur.

Consignez les contrôles appliqués à chaque parcours : filtrage DNS, proxy, inspection TLS, pare-feu, passerelle web sécurisée, politique du navigateur, sécurité du poste et politique d’accès conditionnel de l’identité. Cette cartographie permettra ensuite de distinguer plus facilement un problème de service d’un problème de politique locale.

2. Examiner la source des points de terminaison

Utilisez la documentation actuelle de Microsoft sur les points de terminaison Microsoft 365 et, si possible, ses données téléchargeables ou son service web, plutôt qu’un tableur conservé localement. Vérifiez que les entrées requises du domaine unifié et les entrées Teams sont représentées dans les systèmes qui appliquent réellement les accès.

Si l’organisation n’autorise volontairement que certains FQDN, décidez si teams.cloud.microsoft suffit pour la redirection web actuelle de Teams ou si le caractère générique documenté est nécessaire pour l’usage plus large de Microsoft 365. Prenez cette décision avec le responsable de la sécurité. Un caractère générique peut simplifier la maintenance, tandis que des noms d’hôte individuels limitent davantage la portée mais exigent une maintenance plus fréquente.

3. Tester la redirection elle-même

Depuis chaque voie réseau représentative, ouvrez l’ancienne URL Teams et observez toute la chaîne. Confirmez que la requête atteint teams.cloud.microsoft, que le certificat est accepté, que l’authentification aboutit et que l’application termine son chargement. Testez un compte utilisateur normal ainsi qu’un compte administrateur ; les comptes privilégiés peuvent avoir une politique et un état mis en cache différents.

Utilisez les outils de développement du navigateur ou les journaux de la passerelle pour relever les requêtes bloquées, les codes d’état et les décisions de politique. L’objectif n’est pas de collecter une capture réseau énorme. Il faut répondre à quatre questions concrètes : le DNS a-t-il résolu le nom, la connexion est-elle passée, la redirection s’est-elle terminée et l’application a-t-elle chargé toutes les ressources nécessaires ?

Effacez les données de site mises en cache seulement après avoir enregistré le premier résultat. La suppression du cache peut masquer un problème de migration reproductible ou créer un faux échec que les utilisateurs ordinaires ne rencontreront pas. Exécutez au moins un test avec un profil vierge et un autre avec le profil de production administré.

4. Tester les actions utilisateur, pas seulement la page d’arrivée

Un écran de connexion affiché en vert ne suffit pas. Validez les actions importantes pour l’organisation : ouvrir une conversation, rejoindre une réunion, démarrer un appel si la fonction est activée, ouvrir un fichier partagé, changer de locataire si nécessaire, charger un onglet personnalisé et utiliser toute intégration Teams approuvée. Testez à la fois un favori direct du navigateur et un lien reçu par e-mail ou dans une invitation de calendrier.

Pour les réunions, testez le parcours depuis un lien de calendrier, car le navigateur peut suivre des étapes supplémentaires de redirection et d’authentification. Pour les fichiers, testez l’ouverture et la modification d’un document représentatif si ce flux est important. Pour les applications personnalisées, testez chaque onglet métier critique et le retour après connexion.

5. Vérifier les politiques des applications intégrées

Les propriétaires d’applications doivent rechercher dans le code et la configuration les références codées en dur à teams.microsoft.com, les comparaisons explicites d’origine, les valeurs CSP frame-ancestors, les listes de domaines de confiance, les URI de redirection, les hypothèses sur le domaine des cookies et les filtres de télémétrie. La recherche doit couvrir la configuration de déploiement et la documentation, pas uniquement le code applicatif.

Suivez les recommandations de Microsoft pour les applications Teams concernant la version de TeamsJS et le comportement d’initialisation. Conservez les anciennes valeurs lorsque la compatibilité descendante est requise et ajoutez le nouvel hôte selon le modèle de sécurité de l’application. Ne remplacez pas aveuglément les anciennes valeurs si des utilisateurs peuvent encore arriver par l’ancienne URL ou si d’autres hôtes Microsoft 365 restent pris en charge.

Après la modification des en-têtes ou des manifestes, testez chaque contexte d’hôte pris en charge. Une CSP qui fonctionne dans un onglet de navigateur de premier niveau peut encore refuser un cadre intégré. À l’inverse, un en-tête de test trop permissif peut dissimuler le fait que la réponse de production est générée par un autre proxy inverse ou un autre CDN.

6. Mettre à jour les documents et l’exploitation

Recherchez l’ancien nom d’hôte Teams dans les articles du support, les guides d’intégration, les formulaires de demande de pare-feu, les politiques proxy, les politiques de navigateur, les contrôles de supervision et les procédures d’incident. Conservez l’ancienne URL dans les notes historiques lorsque cela est utile, mais décrivez-la comme une source de redirection plutôt que comme l’unique adresse du service.

La supervision doit également être mise à jour. Un contrôle synthétique qui exige le nom d’hôte final peut commencer à échouer, alors que le service fonctionne, s’il a été écrit pour l’ancienne adresse. Un contrôle qui suit les redirections et vérifie la page finale est plus représentatif, à condition de signaler aussi toute modification inattendue de la chaîne de redirection.

Ce qu’il ne faut pas faire

Ne demandez pas aux utilisateurs de contourner le proxy, de désactiver les protections du navigateur ou d’utiliser un appareil non administré comme solution standard. Ces actions peuvent masquer le problème de politique et créer un second risque de sécurité.

Ne désactivez pas définitivement la redirection uniquement parce qu’une équipe applicative n’a pas testé son onglet. Le contrôle d’administration temporaire possède une date d’expiration, et repousser le travail transforme un changement maîtrisé en incident lié à une échéance. Utilisez ce contrôle uniquement lorsqu’il est nécessaire de préserver la continuité du service pendant la planification d’une correction précise.

Ne remplacez pas les règles de noms d’hôte par des adresses IP fixes. L’infrastructure cloud de Microsoft est conçue pour évoluer, et une solution fondée sur une IP peut devenir obsolète ou acheminer le trafic de manière incorrecte.

N’autorisez pas tout *.microsoft sans examen. La documentation Microsoft pertinente identifie des familles de domaines et des catégories de points de terminaison précises ; élargir l’accès au-delà du besoin métier réduit la valeur du contrôle.

Ne considérez pas une réponse HTTP 200 de la première page comme la preuve que Teams fonctionne. L’échec peut survenir après l’authentification, lors d’un appel d’API, pendant le chargement d’un onglet ou à l’ouverture d’un fichier.

Gérer l’exception temporaire

L’avis de Microsoft indique que le contrôle d’administration permettant de désactiver la redirection Teams prendra fin le 31 décembre 2026. Si une organisation l’utilise, l’exception doit avoir une raison claire et un responsable nommé. Un enregistrement utile précise le locataire ou le groupe d’utilisateurs concerné, la dépendance bloquée, l’équipe applicative ou réseau responsable, la date cible du test et la date de suppression de l’exception.

L’exception ne doit pas remplacer la maintenance des points de terminaison. Si le problème vient d’une règle proxy, corrigez la règle proxy. S’il vient de la CSP d’un onglet personnalisé, corrigez la réponse de l’application. S’il concerne une intégration tierce, demandez à son propriétaire un parcours de migration pris en charge et documentez sa réponse.

Lorsqu’une application critique ne peut pas être validée à temps, séparez le risque. Maintenez l’exception dans la portée la plus étroite permise par le contrôle disponible, surveillez le flux concerné et communiquez sa date de fin au responsable du service. L’objectif est de préserver la continuité tout en gardant la migration visible.

Pourquoi il s’agit d’un changement d’infrastructure

Un fournisseur SaaS peut modifier un nom d’hôte sans changer la fonctionnalité visible pour l’utilisateur. Pour le client, un nom d’hôte fait pourtant partie du contrat de service appliqué par les réseaux, les navigateurs et les applications. L’adresse détermine quelle politique s’applique, quel certificat est inspecté, quels cookies sont envoyés, quelle origine est approuvée et quels journaux identifient le trafic.

C’est pourquoi les migrations de domaines méritent la même discipline légère que les autres changements de production. Il faut un responsable, une matrice de tests, un plan de retour arrière ou d’atténuation, une mise à jour de la supervision et un circuit de communication. Le travail ne nécessite pas un grand projet. Il nécessite quelqu’un qui vérifie tout le parcours au lieu de supposer qu’une redirection sera transparente partout.

Cette évolution illustre aussi un changement dans l’exploitation du cloud. Les points de terminaison de service ne sont plus une annexe statique maintenue une fois au déploiement. Microsoft indique que ses données de points de terminaison évoluent avec les services et peuvent être mises à jour en dehors du rythme normal lorsque les circonstances opérationnelles l’exigent. Les organisations qui consomment automatiquement ces données peuvent réduire les délais manuels, mais l’automatisation doit toujours être revue : un flux peut mettre à jour un pare-feu alors que la CSP de l’application et la procédure d’exploitation restent inchangées.

Une liste de contrôle concise pour septembre

  • Confirmer si Teams est utilisé dans un navigateur au sein de l’organisation.
  • Relire MC1465764 dans le centre d’administration Microsoft 365 et identifier l’état du déploiement pour le locataire.
  • Confirmer que teams.cloud.microsoft et les points de terminaison *.cloud.microsoft pertinents sont autorisés par la politique réseau documentée.
  • Tester depuis les parcours du bureau, du VPN, du télétravail, du bureau virtuel et du navigateur administré.
  • Suivre la redirection et vérifier la connexion, les réunions, les fichiers et les onglets Teams critiques.
  • Examiner le filtrage DNS, les règles proxy, l’inspection TLS ainsi que les politiques de confiance ou de cookies du navigateur.
  • Demander aux propriétaires d’applications de vérifier TeamsJS, la CSP frame-ancestors, la validation d’origine, les manifestes et les URI de redirection.
  • Mettre à jour la supervision synthétique, la documentation et les consignes du support.
  • Consigner toute exception temporaire à la redirection, avec un responsable et une date de suppression antérieure au 31 décembre 2026.

La migration web de Teams est facile à absorber dans un navigateur non administré et potentiellement lourde de conséquences dans une entreprise contrôlée. La bonne réponse n’est pas une modification d’urgence et généralisée du pare-feu. C’est une validation courte, fondée sur des éléments observables, du nouveau point de terminaison sur les parcours réellement empruntés par les utilisateurs et les applications. Une fois ce travail terminé, la redirection devrait devenir ce que Microsoft prévoit : un changement d’adresse, pas un changement de disponibilité.

Sources