L'audio en temps réel dans le navigateur : ce que 2026 rend réellement possible

La formule « on ne peut pas faire de vrai audio dans le navigateur » était vraie pendant la majeure partie de l’ère WebAudio. Elle a cessé de l’être vers 2020, lorsque AudioWorklet est arrivé. Elle est devenue inconfortablement fausse quand WebGPU est arrivé en 2023 et a permis de déplacer une inférence ML sérieuse hors du CPU. En 2026, l’audio dans le navigateur accomplit des choses qui auraient exigé une application native il y a cinq ans, et quelques-unes qui nécessitent réellement encore le natif.

Voici la carte de travail du plancher et du plafond. Ce que tu peux livrer dans le navigateur aujourd’hui en toute confiance, ce qui se situe pile à la limite, et ce qui exige encore une base de code distincte.

La forme de la plateforme en 2026

Cinq API font le travail :

• AudioContext + graphe d’AudioNode. Les primitives WebAudio classiques. Nodes intégrés : gain, biquad, delay, compressor, convolver, analyser, panner. Parfait pour « j’ai besoin de jouer un son » et pour tout ce qui touche à l’analyse (FFT via AnalyserNode). Limité pour tout ce qui est sur mesure, car le graphe est figé au moment de l’instanciation.
• AudioWorklet. L’échappatoire. Du JavaScript ou du WebAssembly s’exécutant sur un thread audio dédié, traitant des buffers de 128 échantillons à la fois. C’est là que vivent le DSP en temps réel, la synthèse et l’analyse. AudioContext pour le routage, AudioWorklet pour le travail.
• MediaDevices.getUserMedia. Accès au microphone et aux autres entrées. API Constraints pour la fréquence d’échantillonnage, le nombre de canaux, l’annulation d’écho, la suppression de bruit. En 2026, standardisée et cohérente d’un navigateur à l’autre d’une manière qui n’existait pas en 2020.
• MediaStreamTrack avec AudioWorklet via MediaStreamTrackProcessor. Traite une piste en direct comme un flux de trames audio que tu peux traiter. Le pont propre entre la capture et le DSP.
• WebGPU. Du calcul GPU à usage général. La raison pour laquelle le ML audio dans le navigateur est désormais réellement compétitif : voir la section dédiée ci-dessous.

Autour de cela, des outils complémentaires : WebCodecs (encodage/décodage), Web Audio Stream Sink (chemins de rendu à faible latence dans les navigateurs modernes), et l’API AudioSession pour l’intégration aux plateformes mobiles.

Latence : le chiffre phare

L’audio en temps réel se juge à la latence aller-retour : le temps qui s’écoule entre l’entrée du son dans le micro et la sortie du son traité par les haut-parleurs. Les planchers de 2026 :

Plateforme	Latence aller-retour	Usage pratique
Desktop Chrome / Edge	18–35 ms	Monitoring avec effets, tracking avec DSP léger
Desktop Safari	25–45 ms	Comme Chrome mais légèrement moins bon sur macOS
Desktop Firefox	25–40 ms	Même plage que Safari
Android Chrome	35–80 ms	Production amateur ; pas de tracking professionnel
iOS Safari	30–60 ms	Plus serré qu’Android avec une marge
Avec une taille de buffer de 128 + interface audio dédiée	8–15 ms	Réellement utilisable pour le monitoring

Cette dernière ligne compte. Avec des valeurs honnêtes pour audioContext.baseLatency et audioContext.outputLatency de WebAudio, une interface audio configurée pour un buffer de 128 échantillons à 48 kHz peut offrir des latences aller-retour qui se situent dans l’ordre de grandeur de JUCE-sur-natif. La taxe du navigateur est désormais faible. C’est la taxe du mixeur de l’OS qui constitue l’essentiel de ce qui reste.

À titre de comparaison, le plancher équivalent d’une application native en 2026 avec la même interface est de 4–8 ms. Le navigateur affiche 2–3× la latence, pas 10×. Pour la plupart des cas d’usage, cet écart n’a pas d’importance. Pour le monitoring en direct pendant le tracking de voix, il en a encore.

Threading et jitter

AudioWorklet s’exécute en priorité de thread audio. Le buffer de 128 échantillons à 48 kHz signifie que le traitement doit se terminer en 2,67 ms, sinon tu obtiens un underrun (un glitch audible). Le thread audio ne fait pas de GC, n’alloue pas, et ne bloque pas sur des I/O. Le code d’un AudioWorkletProcessor est tenu aux mêmes exigences que le code d’un callback audio natif.

En pratique :

• Code audio en pur JavaScript. Fonctionne bien pour du DSP de complexité modérée : quelques filtres, un suiveur d’enveloppe, de l’extraction de caractéristiques basique. Les JIT V8/JavaScriptCore sont excellents sur ce genre de boucle numérique serrée. Les allocations sont l’ennemi ; la discipline est la même qu’en natif.
• Code audio en WebAssembly. Le choix par défaut pour tout ce qui est sérieux : émulations complètes de plugins, analyse gourmande en FFT, bibliothèques DSP matures portées depuis le C++. Les chaînes de build (Emscripten, Rust + wasm-bindgen) sont matures ; les performances se situent dans une fourchette de 1,2–1,5× du code natif équivalent.
• SharedArrayBuffer + Atomics. Le moyen de transport pour faire passer des données entre l’UI du thread principal et le DSP du thread audio sans copie. Indispensable pour toute application non triviale. Les exigences d’en-têtes COOP/COEP sont une contrainte opérationnelle mais pas un facteur bloquant.

L’histoire du jitter est honnête : la variance du temps d’exécution du thread audio est bien maîtrisée sur desktop, moins sur mobile. Les applications qui ont besoin d’un comportement à toute épreuve, exempt de glitches, ajoutent un petit buffer de jitter (5–10 ms) côté sortie, la même astuce que les applications natives utilisent sur les systèmes sollicités.

Ce qui est réellement possible

Une liste non exhaustive de choses qui fonctionnent dans les navigateurs de production en 2026 :

Solide

• Chaînes de traitement multibandes. EQ, compression, gating, limiting. La chaîne de mastering standard tourne confortablement dans un seul AudioWorklet avec un budget de quelques centaines de microsecondes par buffer.
• Analyse en temps réel. Spectre, mesure LUFS (l’AudioLab MixLab Analyzer le fait en production), détection de tonalité, beat-tracking, détection d’onset. Tout cela est peu gourmand en CPU.
• Traitement de la voix. Suppression de bruit, voice activity detection, traitement du micro : largement dans le budget. La NS/AEC intégrée au navigateur (echoCancellation: true) est le « assez bon » de la facilité ; du DSP sur mesure pour les produits qui en ont besoin.
• Synthèse. Wavetable, FM, additive, soustractive : toutes les techniques de synthèse classiques. Une polyphonie de plusieurs dizaines de voix est confortable.
• Réverbération à convolution. Le ConvolverNode intégré gère des réponses impulsionnelles arbitraires. Les longues IR (5+ secondes) fonctionnent via la convolution partitionnée, que les implémentations des navigateurs réalisent désormais correctement.
• Bouclage, découpage, time-stretching, pitch-shifting. Les implémentations à vocodeur de phase et granulaires en WebAssembly sont compétitives face aux équivalents natifs.
• Entrée et sortie MIDI. Web MIDI est mature sur les navigateurs Chromium ; Safari l’a obtenu en 2024.

À la limite de l’enveloppe

• Timing à l’échantillon près d’arrangements longs. Possible, mais exige un scheduling soigné par rapport à audioContext.currentTime. Les primitives de timing de la plateforme web sont assez bonnes ; les pièges se situent surtout dans le throttling des onglets de navigateur inactifs.
• Audio réseau à faible latence. WebRTC pour le pair-à-pair est mature ; le problème plus difficile reste le jitter et le concealment sur les réseaux dégradés. Les transports sur mesure via WebTransport sont une voie émergente.
• Hébergement de plugins. L’hébergement AU/VST n’arrivera pas dans le navigateur. WAM (Web Audio Modules) est un standard de plugin émergent, intéressant mais doté d’un petit écosystème en 2026.
• Rendu surround multicanal / Dolby Atmos. WebAudio prend en charge jusqu’à 32 canaux en théorie ; en pratique, le routage au niveau de l’OS pour tout ce qui dépasse la stéréo dépend de la plateforme et du système d’exploitation.

Toujours réellement natif uniquement

• Latence aller-retour sous les 10 ms sur des machines grand public. L’overhead de la pile audio de l’OS ne disparaît pas. Les interfaces audio pro aident ; elles ne comblent pas entièrement l’écart.
• Intégration au niveau pilote avec les interfaces audio. Routage de mixeur sur mesure, surfaces de contrôle matérielles, synchronisation à l’échantillon près avec des appareils externes. Les navigateurs n’exposent pas cela et ne le feront pas.
• Traitement audio en arrière-plan sur des appareils mobiles verrouillés. L’onglet du navigateur se met en veille. Pas les applications natives.
• Capture audio au niveau de l’OS depuis d’autres applications. Le routage audio au niveau du système est délibérément isolé du navigateur.

WebGPU et ML audio

Le plus grand bouleversement de 2024–2026. WebGPU a apporté le calcul GPU dans le navigateur sans la contrainte graphique unique de WebGL. Pour l’audio :

• Inférence en temps réel de modèles de petite à moyenne taille. Séparation de sources, denoising, déréverbération, super-résolution : tous disponibles dans le navigateur via ONNX Runtime Web ou Transformers.js tournant sur WebGPU. Les performances sont compétitives face à l’inférence CPU de classe desktop.
• Les modèles plus grands (Whisper-large, MusicGen, Demucs dans les tailles supérieures) tournent toujours, mais avec un batching trame par trame qui introduit une réelle latence. L’inférence en streaming est le goulot d’étranglement, pas le débit brut.
• Les tailles de modèles qui tiennent confortablement se situent dans la plage de 50–500 Mo. Au-delà de cette plage, tu te bats contre l’éviction du cache.

Deux schémas pratiques émergent en 2026 :

1. Inférence sur le edge uniquement. Le modèle vit sur la machine de l’utilisateur, tourne entièrement dans le navigateur, n’envoie jamais d’audio nulle part. Les démos AudioLab penchent dans ce sens pour des raisons de confidentialité.
2. Hybride. Prétraitement peu coûteux dans WebGPU ; inférence lourde sur un endpoint cloud via WebTransport avec un aller-retour sous les 100 ms. C’est à cela que ressemblent la plupart des produits vocaux de production aujourd’hui, et la part du cloud rétrécit chaque année.

La réalité côté build

Livrer une application audio sérieuse pour le navigateur en 2026 ressemble à ceci :

• Code audio en Rust ou C++, compilé vers WebAssembly via Emscripten ou wasm-bindgen. La chaîne de build correspond à ce qu’aurait une application native.
• Shim AudioWorklet en TypeScript, important le module WASM et assurant la tuyauterie du thread audio.
• UI sur le thread principal en React/Vue/Svelte, dialoguant avec le thread audio via SharedArrayBuffer.
• Isolation COOP/COEP pour SharedArrayBuffer et WebGPU. Conséquence opérationnelle : les iframes tierces ont besoin d’en-têtes coopératifs. Pénible mais soluble.
• PWA + Service Worker pour des installations utilisables hors ligne. En 2026, les vrais produits audio se livrent installables.
• Pool de workers pour les gros travaux hors du thread audio : décodage de fichiers, analyse, inférence ML.

La chaîne de build a suffisamment mûri pour qu’une petite équipe puisse livrer un vrai produit audio sans posséder une chaîne de build native par plateforme. C’est le véritable bouleversement de 2026, pas une API en particulier.

Ce que cela signifie pour les décisions produit

Une règle pratique :

Choisis le browser-first sauf si tu as spécifiquement besoin de (a) une latence aller-retour sous les 10 ms, (b) l’hébergement de plugins, (c) de l’audio en arrière-plan lorsque l’onglet est fermé, ou (d) un routage audio profond au niveau de l’OS.

Il y a cinq ans, le « browser-first » était un choix contraint : on acceptait des compromis significatifs au profit de la commodité de distribution. En 2026, le browser-first est un choix compétitif pour un large éventail de produits audio. La distribution est plus simple, la plateforme est assez bonne, et l’entonnoir d’installation ne concurrence pas les places de marché des applications natives.

Pour AudioLab, les sept labs sont livrés en browser-first par conception. Les compromis que nous acceptons (une latence plancher légèrement plus élevée, pas d’hébergement de plugins) ne sont pas pertinents au regard de ce à quoi servent les labs. Pour ton produit, fais le bilan honnête de ce dont tu as réellement besoin avant de t’engager dans l’une ou l’autre voie.

Essaie les démos AudioLab → · WebAudio vs natif, analyse approfondie → · Méthodologie →