Si vos employés ouvrent Copilot dans un navigateur, l’adresse qu’ils connaissent (m365.cloud.microsoft) est en train de changer. Microsoft redirige maintenant le tout vers copilot.cloud.microsoft. Pour la plupart des organisations, la redirection passera inaperçue. Pour celles dont le proxy, le pare-feu ou la passerelle web filtre encore le domaine cloud.microsoft, Copilot risque de cesser de répondre, dans le navigateur comme dans l’application de bureau et dans Edge.

Ce que Microsoft a annoncé

Deux avis du Centre de messages décrivent le changement :

  • MC1454108 (publié le 13 août 2026, mis à jour le 2 septembre) : l’application Microsoft 365 Copilot devient une application unifiée pour les comptes personnels et professionnels. Elle adopte un nom plus simple (« Microsoft Copilot »), une nouvelle icône et la nouvelle adresse web. Microsoft précise que la sécurité, la conformité et les contrôles d’entreprise ne changent pas. L’identifiant d’application (Application ID) reste le même : les politiques existantes continuent de s’appliquer.
  • MC1462915 (publié le 27 août, mis à jour le 21 septembre) : l’avis qui s’adresse directement aux équipes réseau. Les services en arrière-plan et Copilot dans Edge exigent une connexion à *.cloud.microsoft.

Pour les utilisateurs, Microsoft ajoute des repères visuels : une couleur de fond différente et l’étiquette « Work » dans le volet de navigation quand ils sont connectés avec un compte professionnel ou scolaire.

Une contradiction dans les dates

Les deux avis ne racontent pas tout à fait la même histoire sur le calendrier de la redirection :

  • l’avis MC1454108 (mis à jour le 2 septembre) parle d’une redirection standard dès le début de septembre, puis d’un déploiement différé à la fin de septembre pour l’application web ;
  • l’avis MC1462915 (mis à jour le 21 septembre) indique que les utilisateurs non redirigés en septembre le seront au début d’octobre. Les organisations qui bloquaient peut-être l’adresse y sont explicitement visées.

L’avis le plus récent fait foi, mais Microsoft ne donne pas de date précise. Considérez donc que la redirection peut se produire n’importe quel jour de cette semaine ou des prochaines. Dans le même avis, Microsoft demandait de la contacter avant le 10 septembre si votre organisation ne pouvait pas ouvrir le domaine : cette date est passée, mais votre représentant reste le bon point de contact.

Chronologie du déménagement de Copilot vers copilot.cloud.microsoft, de la mi-août au début d'octobre 2026
Les étapes annoncées dans MC1454108 et MC1462915, avec la divergence sur la redirection différée

Ce qu’il faut ouvrir (et pourquoi pas seulement une adresse)

La page Learn sur les exigences de Copilot (mise à jour le 5 octobre 2026) est claire : ajoutez *.cloud.microsoft aux listes d’autorisation, sur les appareils comme dans l’infrastructure réseau. Microsoft ne prend pas en charge l’ouverture partielle de quelques adresses du domaine : il faut autoriser le domaine complet.

Ce n’est pas surprenant. Le domaine cloud.microsoft sert à regrouper les applications Microsoft 365 sur une seule adresse. Il appartient au domaine de premier niveau .microsoft, dont Microsoft est la seule titulaire. La documentation précise qu’on n’y héberge ni sites tiers ni stockage de type IaaS ou PaaS. Les adresses *.cloud.microsoft font d’ailleurs partie des consignes réseau de Microsoft 365 depuis 2023. Si vous alimentez vos règles avec l’API de service web des points de terminaison, c’est déjà fait. Si vous les tenez à la main, c’est le moment de vérifier.

Deux autres points à surveiller dans la même page :

  • Les connexions WebSocket sécurisées (WSS) doivent passer vers *.office.com, *.cloud.microsoft et copilot.cloud.microsoft. Une inspection TLS qui s’interpose ou un proxy aux délais trop courts peut casser les intégrations de Copilot.
  • Les restrictions de locataire : si vous bloquiez copilot.cloud.microsoft pour empêcher les connexions avec des comptes Microsoft personnels, Microsoft recommande plutôt les restrictions de locataire (v2), qui ciblent précisément ce risque sans couper l’accès à l’application de travail.
Les quatre endroits où une connexion à Copilot peut être bloquée : poste, contrôles réseau, contrôles d'identité et domaine cloud.microsoft
Où chercher si Copilot ne répond plus après la redirection (selon MC1462915 et Microsoft Learn)

Que faire cette semaine ?

  1. Lancez le test officiel : l’outil Microsoft 365 Connectivity Test pour Copilot (connectivity.m365.cloud.microsoft/copilot) valide l’accès à *.cloud.microsoft depuis un poste de votre réseau. Faites-le depuis un poste de bureau et depuis le réseau privé virtuel (RPV).
  2. Passez en revue les règles qui peuvent bloquer : filtrage par catégories d’URL, politiques de proxy, pare-feu, restrictions de locataire, accès conditionnel et contrôle des applications.
  3. Ajoutez *.cloud.microsoft aux listes d’autorisation, en entier. Vérifiez ensuite le WSS.
  4. Prévenez le soutien technique et mettez à jour la documentation et la formation qui parlent de l’ancien nom ou de m365.cloud.microsoft.
  5. Vérifiez les politiques Recall : si vous filtriez l’ancienne application Copilot dans les instantanés de Recall, cette politique ne se reporte pas automatiquement sur la nouvelle application. Microsoft renvoie à ses instructions pour la recréer.

Un petit script pour un premier diagnostic

Ce script PowerShell est en lecture seule. Pour chaque adresse testée, il vérifie la résolution DNS et la connexion sur le port 443, puis lit l’émetteur du certificat présenté. Un émetteur qui n’est pas Microsoft signale souvent une inspection TLS en cours. Il ne remplace pas l’outil officiel et ne teste pas le WSS : c’est un coup d’œil rapide qu’un technicien peut lancer sur un poste.

<#
.SYNOPSIS
    Teste, depuis un poste, l'accès aux adresses de Copilot sur le domaine cloud.microsoft.
.DESCRIPTION
    Lecture seule : résolution DNS, connexion TCP sur le port 443 et lecture de l'émetteur
    du certificat présenté. Aucune donnée n'est envoyée et rien n'est modifié.
    Un émetteur qui n'est pas Microsoft indique souvent une inspection TLS par un proxy.
    Ce test ne remplace pas l'outil officiel Microsoft 365 Connectivity Test.
#>
[CmdletBinding()]
param(
    [string[]]$HostName = @('copilot.cloud.microsoft', 'm365.cloud.microsoft'),
    [int]$TimeoutMs = 5000
)

function Test-TlsEndpoint {
    param([string]$Name, [int]$TimeoutMs)

    $result = [ordered]@{ Hote = $Name; DNS = ''; Port443 = $false; Emetteur = ''; Verdict = '' }
    try {
        $addresses = [System.Net.Dns]::GetHostAddresses($Name)
        $result.DNS = ($addresses | Select-Object -First 2 | ForEach-Object { $_.IPAddressToString }) -join ', '
    }
    catch {
        $result.Verdict = 'DNS bloqué ou introuvable'
        return [pscustomobject]$result
    }

    $client = New-Object System.Net.Sockets.TcpClient
    try {
        $pending = $client.BeginConnect($Name, 443, $null, $null)
        if (-not $pending.AsyncWaitHandle.WaitOne($TimeoutMs)) {
            $result.Verdict = 'Délai dépassé sur le port 443'
            return [pscustomobject]$result
        }
        $client.EndConnect($pending)
        $result.Port443 = $true

        # Le certificat est seulement lu pour en connaître l'émetteur.
        $ssl = New-Object System.Net.Security.SslStream($client.GetStream(), $false, { $true })
        $ssl.AuthenticateAsClient($Name)
        $certificate = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($ssl.RemoteCertificate)
        $result.Emetteur = $certificate.Issuer
        if ($certificate.Issuer -match 'Microsoft') {
            $result.Verdict = 'Accessible, certificat Microsoft'
        }
        else {
            $result.Verdict = 'Accessible, mais émetteur non Microsoft : inspection TLS probable'
        }
    }
    catch {
        $result.Verdict = "Échec de la connexion : $($_.Exception.Message)"
    }
    finally {
        $client.Close()
    }
    return [pscustomobject]$result
}

$HostName | ForEach-Object { Test-TlsEndpoint -Name $_ -TimeoutMs $TimeoutMs } |
    Format-Table Hote, DNS, Port443, Verdict -AutoSize -Wrap

Lancez-le simplement avec .\Test-CopilotCloudMicrosoft.ps1. Le paramètre -HostName permet d’ajouter d’autres adresses. Aucun module n’est requis : le script fonctionne avec Windows PowerShell 5.1 comme avec PowerShell 7.

Ce déménagement d’adresse semble anodin : il l’est pour la majorité des organisations. Mais il rappelle que Copilot dépend autant du réseau que des licences et de la gouvernance des données. Une organisation qui a passé des mois à préparer ses étiquettes de confidentialité et ses politiques de rétention peut voir son déploiement paraître « brisé » à cause d’une règle de pare-feu vieille de cinq ans. Le premier réflexe, quand un utilisateur dit que Copilot ne fonctionne plus, devrait donc être de regarder le chemin réseau avant de blâmer la licence.

Références