Le navigateur, moteur d’inférence locale
Le navigateur n’est plus seulement un rendu HTML/CSS : il devient une plateforme d’exécution pour des modèles de machine learning. Grâce à des API standardisées, des backends performants et des runtimes optimisés, on observe un virage vers des expériences « local‑first » où l’inférence locale se fait directement côté client.
Ce basculement est porté par plusieurs piliers techniques , WebNN pour l’API standard, WebGPU pour l’accélération, ONNX Runtime Web et des runtimes comme Transformers.js ou wasm/llama.cpp , ainsi que par de nouveaux formats de modèles (GGUF) et des techniques de quantization. Ensemble, ils rendent possible l’exécution de modèles sophistiqués dans le navigateur, avec des bénéfices en latence et confidentialité.
WebNN : l’API standard pour l’inférence locale
WebNN (Web Neural Network API) est une API normalisée visant à exécuter des réseaux de neurones « localement dans le navigateur », avec un routage transparent entre CPU, GPU et NPU et un objectif d’exécution proche du natif. Le projet est suivi au W3C avec des documents de groupe et un calendrier public ; la charte du Web Machine Learning WG et des CRs ont été publiés comme livrables.
WebNN définit un modèle d’abstraction matériel, permettant aux implémenteurs de navigateurs et aux runtimes d’exposer des capacités d’accélération sans lier l’application à un backend spécifique. Les documents officiels et exemples (webnn.io) servent de point d’entrée pour les développeurs qui veulent cibler l’inférence locale de manière portable.
Cependant, WebNN reste expérimental dans le paysage réel : son taux d’activation rapporté est très faible (pic de 0.000029% en février 2025 selon Chrome Platform Status / Web Almanac), ce qui montre un écart entre standardisation et adoption pratique à grande échelle pour l’instant.
Backends et runtimes : WebGPU, ONNX Runtime Web et Transformers.js
L’arrivée de WebGPU dans les navigateurs a été un catalyseur majeur. WebGPU (déployé largement depuis Chrome/Edge v113 et avec support croissant sur Firefox et Safari fin 2025) ouvre l’accès aux compute shaders et à l’accélération ML dans tous les grands navigateurs, rendant possible des gains substantiels par rapport aux approches purement WASM.
Microsoft a intégré un backend WebGPU dans ONNX Runtime Web pour accélérer des modèles génératifs (ex. Stable Diffusion Turbo) directement dans le navigateur. Le billet résume bien cette avancée : « ONNX Runtime Web unleashes generative AI in the browser using WebGPU. » Les démonstrations montrent des accélérations importantes , par exemple ~19× pour l’encodage Segment Anything sur WebGPU vs WASM.
Dans la même veine, Hugging Face présente Transformers.js v4 (preview Feb 2026), réécrivant le runtime WebGPU en C++/ONNX Runtime pour exécuter des modèles SOTA côté client. Leur revendication clé : « Local‑first AI: Run SOTA models completely offline in browsers » , une promesse de gains de performance et de support étendu d’architectures.
WASM, llama.cpp et solutions open‑source
Les solutions basées sur WASM restent très pertinentes, surtout lorsque le GPU ou NPU n’est pas disponible. Des projets comme llama-cpp-wasm et des packages npm (wllama) proposent des bindings WASM pour exécuter des modèles via llama.cpp dans le navigateur, avec multi‑threading et OPFS pour mettre en cache localement les poids.
Ces approches présentent cependant des contraintes pratiques : limites de mémoire (par exemple limite ArrayBuffer ≈2 GB pour certains builds) et performance inférieure à WebGPU pour des charges massives. Elles sont néanmoins essentielles pour supporter un large éventail d’appareils et assurer des fallbacks robustes.
De nouveaux moteurs (ex. MDST Engine, février 2026) implémentent l’exécution de modèles au format GGUF en WASM+WebGPU, visant une inférence « 100% locale » dans Chrome/Safari/Edge. L’écosystème open‑source fait ainsi converger compatibilité et performance.
Performances, démos et preuves de concept
Les gains observés ces dernières années sont significatifs : ONNX Runtime Web + WebGPU a montré des accélérations importantes (ex. ~19× pour Segment Anything versus WASM dans la démonstration Microsoft). Ces chiffres illustrent l’intérêt concret de l’accélération GPU côté client.
Des démonstrations 100% navigateur , modèles multimodaux et LLMs , confirment la faisabilité. Par exemple, Janus Pro 1B a été montré en demo via Transformers.js/WebGPU, preuve que l’inférence locale complète est possible pour des modèles de taille moyenne.
La croissance des bibliothèques in‑browser est palpable : WebLLM (MLC) et Transformers.js figurent parmi les solutions les plus utilisées pour LLMs en navigateur ; les téléchargements npm de WebLLM ont cru d’environ 340% entre janvier et novembre 2025 (d’après Web Almanac), signe d’une adoption croissante par les développeurs.
Contraintes matérielles, quantization et strategies
Malgré les progrès, l’exécution complète de modèles 7B+ en navigateur reste exigeante. Des rapports communautaires indiquent que certains modèles 7B/14B non quantifiés peuvent nécessiter des dizaines de GB de RAM. La quantization (int8, int4), le support FP16 via WebGPU et d’autres optimisations réduisent ces barrières, sans les éliminer totalement.
Les roadmaps des outils prennent en compte ces défis : ONNX Runtime publie une roadmap publique avec améliorations WebGPU, optimisations mémoire et support pour quantizations basses (releases trimestrielles ; 1.24 listé comme Jan 2026 avec améliorations WebGPU mentionnées). Ces efforts visent à rendre l’inférence locale plus accessible pour des modèles plus volumineux.
En pratique, les navigateurs et runtimes prévoient des stratégies de fallback : quand un backend matériel manque (GPU/NPU), l’exécution bascule sur WASM/XNNPACK CPU. WebNN et la documentation Chromium détaillent cet ordre de délégation et ces mécanismes de secours pour garantir une exécution fiable partout.
Confidentialité, latence et nouveaux cas d’usage
L’un des principaux avantages de l’inférence locale est la réduction de la latence et des allers‑retours réseau : les applications peuvent répondre instantanément sans dépendre d’un serveur distant, améliorant l’expérience utilisateur pour des tâches interactives.
La confidentialité est un autre atout majeur : exécuter des modèles localement limite l’exfiltration de données sensibles et permet des usages offline après le cache initial des modèles. Les positions officielles de projets comme WebNN et ONNX mettent en avant ces bénéfices pour des cas d’usage sensibles (santé, documents privés, etc.).
Cette approche « local‑first » ouvre aussi la porte à des applications inédites , assistants personnels robustes, éditeurs multimodaux embarqués, et outils de création offline , tant que les contraintes matérielles restent maîtrisées.
Sécurité, éthique et gouvernance
L’exécution locale réduit certaines surfaces d’attaque côté cloud mais crée de nouveaux vecteurs : jailbreaks locaux, fuite via extensions ou plugins, et distribution de modèles compromis sont des risques réels. Les groupes W3C et WebML documentent des principes éthiques et des bonnes pratiques pour encadrer cette évolution.
Les éditeurs de navigateurs prennent aussi position : Mozilla a intégré et accéléré un « Firefox AI Runtime » (un backend natif C++ remplaçant/accélérant onnxruntime-web pour certaines fonctionnalités locales), montrant que les grands acteurs inscrivent l’inférence locale dans leurs stacks tout en contrôlant la sécurité et la performance.
Il faudra un effort coordonné , normes, audits de modèles, contrôle des extensions et guidelines de déploiement , pour que l’inférence locale se développe de façon responsable et fiable.
Écosystème et perspectives
La tendance de 2024 à 2026 est claire : convergence entre (1) API standardisées (WebNN), (2) backends performants (ONNX Runtime Web + WebGPU/WASM), (3) runtimes JS/C++ (Transformers.js v4, llama‑wasm), et (4) formats modèles optimisés (GGUF, quantizations). Le résultat est un passage rapide du proof‑of‑concept à des expériences « local‑first » sur navigateur.
Les roadmaps publiques (ONNX Runtime), les previews (Transformers.js v4 en Feb 2026) et les moteurs comme MDST Engine (février 2026) indiquent une maturation de l’écosystème. Les développeurs disposent aujourd’hui de ressources officielles pour démarrer : WebNN (webnn.io), ONNX Runtime (onnxruntime.ai), TensorFlow.js (tensorflow.org/js), Transformers.js (Hugging Face blog / repo), llama‑cpp‑wasm (repo/site).
À mesure que WebGPU se généralise et que les optimisations mémoire/quantization progressent, l’inférence locale dans le navigateur passera d’une expérimentation prometteuse à une capacité standard des applications web modernes.
En somme, le navigateur est en passe de devenir un véritable moteur d’inférence locale : l’écosystème technique et les preuves de concept existent, les gains sont réels, et les efforts de standardisation (WebNN/W3C) posent les bases d’une adoption pérenne.
Reste à surveiller les limitations matérielles, les enjeux de sécurité/éthique et l’alignement entre spécifications et implémentations dans les navigateurs. Pour les développeurs et architectes produit, c’est le moment d’expérimenter , en gardant à l’esprit les bonnes pratiques et les ressources officielles pour démarrer.
