Google perd le papa de WebRTC : le début de la fin pour Stadia ou au contraire, la fin du début ?

Encore un départ chez Stadia qui ne passe pas inaperçu. Justin Uberti, le papa de WebRTC – une API de communication temps réel très répandue sur le web – vient de quitter Google après 13 ans de bons et loyaux services, pour travailler dorénavant pour Clubhouse, l’application montante de média social audio. Justin Uberti travaillait dernièrement sur la plateforme de cloud gaming de Google. Avec un tel départ, on peut donc se demander quel avenir peut avoir Stadia, si le papa du protocole de communication sur lequel elle se base en partie, s’en va. Et bien honnêtement… c’est peut-être, en réalité, annonciateur de très bonnes nouvelles pour Stadia. Explications.

Stadia utilise une API appelée WebRTC, développée au sein du World Wide Web Consortium (W3C) qui permet de faire de la communication temps réel. Cette technologie, qui est apparue il y a une dizaine d’années, a été créée, entre autres, par Justin Uberti, pour venir remplacer des plugins tels Adobe Flash ou Microsoft ActiveX. Or, nous venons d’apprendre que cet ingénieur de Google, qui travaillait dernièrement pour Stadia, vient de quitter l’entreprise pour rejoindre Clubhouse. Qu’est-ce que cela veut dire pour Stadia et pour tous les produits Google basés sur cette technologie ? Google jetterait-il l’éponge ?

À en croire un billet de blog publié au mois d’août dernier par Tsahi Levent-Levi, un expert reconnu de WebRTC au W3C (donc pas vraiment n’importe qui en ce qui concerne cette technologie), ce n’est pas Stadia, ni même les technologies Google basées sur WebRTC qui sont menacées, mais le protocole WebRTC lui-même.

Tsahi Levent-Levi
Tsahi Levent-Levi

D’après cet expert, bien que la plupart des fournisseurs de solutions de communications temps réels aient choisi d’implémenter WebRTC, Google chercherait en réalité aujourd’hui à s’en détacher pour apporter encore plus de valeurs. En effet, l’un des points noirs du protocole WebRTC est son côté monolithique. Ainsi, on se retrouve avec une segmentation du standard du W3C au niveau du code avec d’un côté une partie standardisée et de l’autre, un code optimisé pour tel ou tel cas d’usage.

Ce qui rajoute de la complexité. L’idée est donc de dégrouper les fonctionnalités de WebRTC en API plus petites, permettant une meilleure granularité dans l’utilisation des APIs selon ces cas d’usage. Il est en effet possible de découper WebRTC en trois blocs principaux : le transport, les codecs et l’assemblage.

Dégrouper WebRTC
Dégrouper WebRTC

Ce qui donne naissance à trois nouveaux composants, pris en charge par le W3C :

  • WebTransport : Une API qui permet d’envoyer un trafic bidirectionnel à faible latence de type UDP entre un client et un « serveur web ». Le groupe de travail autour de WebTransport au sein du W3C est assuré conjointement par des ingénieurs de chez Google et de chez Microsoft.
  • WebCodecs : Une API qui donne aux navigateurs la capacité d’encoder et de décoder l’audio et la vidéo indépendamment du protocole WebRTC. En effet, de plus en plus les codecs sont intégrés directement aux navigateurs avec une possibilité de décodage matériel, ce qui permet d’améliorer considérablement la qualité audio et vidéo, sans avoir besoin de modifier WebRTC lui-même. Le groupe de travail autour de WebCodecs au sein du W3C est assuré conjointement par des ingénieurs de chez Google, de chez Microsoft et de chez Mozilla.
  • WebAssembly : Un accélérateur pour les navigateurs qui permet l’exécution de code et un outil d’apprentissage automatique.

Tsahi Levent-Levi explique : « Bien que tous ces éléments puissent être utilisés pour des cas d’utilisation nouveaux et passionnants (pensez à Google Stadia, avec une mise en œuvre plus simple), ils peuvent également être utilisés pour mettre en œuvre quelque chose de similaire à ce que fait le WebRTC (sans la capacité peer-to-peer). WebTransport remplace SRTP. WebCodecs effectue le codage/décodage. WebAssembly s’occupe de toute la différenciation et de certaines tâches difficiles (comme l’estimation de la bande passante). »

Pour lui, ce n’est pas seulement de la prospective, mais en effort réel de Google de dégrouper WebRTC pour toutes ces applications. Actuellement, la plateforme de cloud gaming de Google utilise WebRTC, « parce que c’était la solution la plus proche et la seule dont disposait Google pour une diffusion en direct à faible latence vers un navigateur Web », nous explique Tsahi Levent-Levi.

Mais en dégroupant WebRTC, Google pourrait alors optimiser Stadia en utilisant ces nouvelles APIs qu’au moment où il y en a besoin :

  • WebTransport afin de renvoyer des actions de l’utilisateur. D’ailleurs cette pile s’appuie déjà sur QUIC (un protocole réseau UDP créé par Google). Or WebTransport s’appuie lui aussi sur ce protocole réseau
  • WebCodecs pour le décodage audio/vidéo en temps réel, avec de l’accélération matériel natif. Pensez par exemple à la future prise en charge du codec AV1.
  • WebAssembly pour toute la partie adaptation du flux, dépendant des conditions de jeu des utilisateurs.

Selon Tsahi Levent-Levi, le dégroupage de WebRTC aboutira forcément à son abandon pour Stadia au profit de nouvelles API mieux adaptées au besoin. Quand aux autres produits Google, ils pourraient également bénéficier de l’utilisation de ces nouvelles APIs. En effet, l’évolution de Google Meet ne peut se faire qu’avec une différenciation qui permet d’y inclure de la sécurité dans les échanges, sans devoir gérer l’aspect peer-to-peer non utilisé par Google dans son application.

Sur le terrain des applications de communications audio/vidéo temps réel, l’application Zoom est devenue très populaire. Si Google veut continuer d’être compétitif, il devra abandonner dans les années qui viennent WebRTC pour ne plus avoir à négocier avec les organismes de normalisation sur la manière d’introduire de nouvelles fonctionnalités. Cela prendra du temps mais Google finira par abandonner complètement WebRTC pour continuer à innover sur ses applications. Dans ce contexte, il est normal que Justin Uberti ait souhaité continuer à travailler sur WebRTC chez Clubhouse et qu’il se trouve de nouveaux défis, d’autant plus que la perspective est grande dans le cadre de sa nouvelle mission.

Mais cela ne veut pas dire que Stadia est menacé, bien au contraire. Google continue d’innover autour de Stadia et de ses autres produits, quitte à se débarrasser de ses anciennes technologies phares. Cela démontre un réel investissement de la firme de Mountain View dans sa plateforme de cloud gaming pour rester compétitive. Le départ de Justin Uberti témoigne donc de l’incroyable vitalité de Stadia.

Vous en pensez quoi de ce départ ? Avons-nous réussi à mieux vous expliquer les tenants et aboutissants d’un tel départ dans le monde de la tech ? N’hésitez pas à réagir et poser vos questions en commentaires ou sur nos réseaux.

Ce contenu est cool ? Partage-le !