Edge 131 Linux : réparer le partage d’écran Teams & WebRTC après la mise à jour

Depuis début décembre 2024, de nombreux administrateurs Linux ont constaté la disparition brutale du partage d’écran dans Microsoft Teams et les autres services WebRTC lorsque le parc poste à poste a basculé vers Edge 131 Stable. Cet article détaille la cause de la régression, expose toutes les méthodes éprouvées pour rétablir le service dans l’urgence et explique comment appliquer en toute sécurité le correctif publié par Microsoft le 6 décembre 2024.

Sommaire

Problème : impossibilité de partager l’écran après la mise à jour d’Edge 131 sous Linux

Vue d’ensemble

Mise à jour en cause : Microsoft Edge ≥ 131.0.2903.48 (canal Stable, Beta et Dev) compilée pour Linux (DEB, RPM et Flatpak).
Distributions touchées : Ubuntu 22.04/24.04 LTS, Debian 12, Fedora 41, Arch Linux, openSUSE Leap 15.5, RHEL 9.x, etc.
Symptômes :
- Dans Teams (PWA), Google Meet, Zoom Web et tout service WebRTC : seul l’onglet Edge peut être diffusé ; Écran entier et Fenêtre échouent systématiquement.
- Au moment de lancer le partage, la caméra se coupe souvent avec l’avertissement : « Your video isn’t working. We couldn’t access your camera. »
- L’anomalie se produit aussi bien sous X11 que sous Wayland, avec ou sans pipewire, et quelle que soit la carte graphique.
- Les tests indépendants (« gum_test » de Mozilla, WebRTC‑Experiment) montrent un échec immédiat de la capture d’écran.

Impact détaillé

Dans un environnement d’entreprise, la perte du partage d’écran peut bloquer jusqu’à plusieurs milliers d’utilisateurs : démos commerciales impossibles, sessions d’assistance à distance interrompues, réunions de coordination ralenties. Les centres de support se retrouvent saturés d’incidents, et la productivité chute brutalement. Le problème est d’autant plus critique que :

Teams sous Edge est souvent déployé comme solution officielle « zéro client lourd » pour les postes Linux.
La majorité des collaborateurs ne disposent pas de droits administrateur pour installer un navigateur alternatif.
Le calendrier des patchs de sécurité impose parfois de diffuser la dernière version du navigateur sans période de validation intermédiaire.

Dans la pratique, les administrateurs ont rapporté un taux d’échec avoisinant 100 % sur la fonction share screen, y compris après vidage du cache, création d’un nouveau profil et réinitialisation des autorisations matériels.

Solutions et contournements

Le tableau ci‑dessous résume les stratégies permettant de restaurer immédiatement la fonctionnalité, en attendant l’application du correctif officiel. Les commandes sont données à titre d’exemple pour Debian/Ubuntu ; adaptez‑les à votre gestionnaire de paquets.

Objectif	Solution	Commandes Linux (ex. DEB)	Remarques
Retrouver le partage dès maintenant	Rétrograder vers Edge 130.0.2849.80‑1 (ou 130.0.2849.68/46)	`sudo apt install microsoft-edge-stable=130.0.2849.80-1 sudo apt-mark hold microsoft-edge-stable`	Disponible dans le dépôt apt tant que Microsoft conserve les n‑1 versions.
Éviter toute réinstallation	Bloquer la version fonctionnelle	`sudo apt-mark hold microsoft-edge-stable # Debian/Ubuntu sudo dnf versionlock add microsoft-edge-stable # Fedora/RHEL flatpak mask com.microsoft.Edge 130.x # Flatpak`	La levée du blocage sera nécessaire avant l’application du correctif officiel.
Continuer à travailler sans Edge	Basculer temporairement sur Chrome, Chromium, Firefox ou Brave	—	Ces navigateurs restent pleinement compatibles WebRTC ; aucune modification côté Teams n’est requise.
Remonter le bug	Ouvrir un ticket via Teams Admin Center → Need help ou la fonction Feedback	—	Plus votre tenant est associé à la régression, plus Microsoft priorise la réponse ; joignez un extrait de `chrome://webrtc-internals`.
Valider la présence du bug	Tester sur des pages WebRTC tierces (ex. « gum_test » de Mozilla)	—	Permet de confirmer qu’il s’agit bien d’une régression Edge ↔ WebRTC et non d’une politique Teams.

Script d’automatisation : vérification du numéro de build

#!/usr/bin/env bash
build=$(msedge --version | awk '{print $3}')
if [[ "$build" =~ 131.0.2903.[4-7][0-9] ]]; then
  echo "Version à risque détectée : $build"
  exit 1
fi
echo "Version acceptable : $build"

Intégrez ce script dans vos pipelines CI : la job échouera si une build problématique se glisse dans l’image Docker ou dans un golden image VDI.

Correctif officiel publié

Chronologie

30 novembre 2024 : publication d’Edge 131.0.2903.48 (Stable).
1–5 décembre 2024 : remontée massive d’incidents auprès des services Microsoft 365 et de l’équipe Edge.
6 décembre 2024 : diffusion d’Edge 131.0.2903.86‑1 corrigeant la régression WebRTC.
7 décembre 2024 : passage en ring 100 %; le correctif est disponible sur tous les miroirs DEB/RPM/Flatpak.

Procédure de mise à jour recommandée

# 1) Lever le blocage au besoin
sudo apt-mark unhold microsoft-edge-stable

# 2) Mettre à jour Edge

sudo apt update && sudo apt install microsoft-edge-stable

# 3) Vérifier la version

msedge --version   # doit afficher ≥ 131.0.2903.86

# 4) (Optionnel) Nettoyer le hold/dnf versionlock une fois la version confirmée

sudo apt-mark unhold microsoft-edge-stable
sudo dnf versionlock clear
flatpak mask --remove com.microsoft.Edge

Après redémarrage du navigateur, le partage d’écran redevient disponible immédiatement ; aucune vidange de cache ni réauthentification Teams n’est nécessaire. Pensez néanmoins à demander aux utilisateurs de :

Fermer toutes les instances Edge (icône dans la barre d’état) pour purger l’ancien binaire chargé en mémoire.
Vérifier que les extensions de confidentialité (uBlock, Ghostery, NoScript…) ne bloquent pas les nouvelles autorisations de capture d’écran.
Rafraîchir la PWA Teams pour forcer l’injection du manifest mis à jour.

Questions fréquentes (FAQ)

Pourquoi le partage d’écran échoue-t-il sous Wayland alors que PipeWire est actif ?

Edge 131 modifie la négociation du flux RTC sur les environnements Wayland. La branche fautive transmet un handle de surface invalide lorsque la demande vient d’un non‑tab capture. PipeWire n’est donc pas sollicité, et le navigateur se replie sur une capture « null », renvoyant un flux 0x0 px qui provoque l’erreur côté Teams.
Le bug touche-t-il Windows ou macOS ?

Non. Les builds Windows/macOS utilisent un code de capture basé sur l’API Desktop Capture qui n’a pas subi la même refactorisation. Les numéros de version sont alignés (131.x) mais le correctif n’était nécessaire que sur Linux.
Quelles sont les implications en matière de sécurité ?

Le bug n’expose pas de surface d’attaque supplémentaire ; il s’agit d’une régression fonctionnelle. Néanmoins, rester sur Edge 130.x trop longtemps vous prive des correctifs de sécurité mensuels. Il est donc recommandé de migrer vers 131.0.2903.86 ou toute version ultérieure dès que possible.
Pouvons‑nous déployer le correctif par GPO ou MDM ?

Oui. Le package DEB/RPM étant signé, il suffit de lever les blocages (apt-mark unhold, dnf versionlock clear) puis de relancer la routine standard de votre MDM (Intune, Puppet, Ansible, etc.). Vérifiez simplement que votre proxy inverse autorise le téléchargement de la nouvelle build.

Bonnes pratiques complémentaires

Contrôle de version pré‑prod : exécutez systématiquement msedge --version dans vos scripts de validation d’image pour refuser toute build non approuvée.
Navigateur de secours prêt à l’emploi : installez Chromium ou Firefox par défaut et verrouillez‑le derrière une icône « fallback » sur le bureau.
Surveillance des notes de version : abonnez‑vous au flux RSS Enterprise Release Notes pour détecter en amont les mentions WebRTC, Screen Capture ou Camera Capture.
Tests automatisés WebRTC : montez une page interne minimaliste reprenant la capture getDisplayMedia(). Un test Selenium de 15 s suffit à signaler une régression avant la mise en production.
Communication utilisateur claire : préparez un message Teams expliquant la marche à suivre (fermeture d’Edge, relance, vérification de la version) pour éviter des tickets de helpdesk en rafale.

Annexes : exemples de policies JSON à déployer

{
  "PolicyList": {
    "CommandLineFlagSecurityWarningsEnabled": false,
    "ScreenCaptureAllowed": true,
    "ScreenCaptureSpecificApps": [],
    "ComponentUpdatesEnabled": true
  }
}

La clé ScreenCaptureAllowed doit rester à true ; l’erreur rencontrée n’est pas liée à cette policy, mais il est utile de la rappeler pour prévenir un diagnostic erroné.

Résumé rapide

Cause : régression WebRTC introduite dans Edge 131.x Linux.
Effets : partage d’écran impossible, coupure caméra.
Contournements : downgrade vers 130.x ou usage d’un autre navigateur.
Résolution définitive : mettre à jour vers Edge 131.0.2903.86 ou version supérieure.

Edge 131 Linux : réparer le partage d’écran Teams & WebRTC après la mise à jour

Problème : impossibilité de partager l’écran après la mise à jour d’Edge 131 sous Linux