Le navigateur, prochain eldorado de l’IA : l’architecture de ce blog en exemple

Depuis trois ans, on te raconte que la bataille de l’IA se joue sur les GPU, les datacenters et la bande passante. C’est vrai, et c’est aussi devenu un peu ennuyeux. Pendant ce temps, quelque chose de bien plus intéressant se prépare à l’autre bout de la chaîne : sur la machine que tu as sous les doigts, dans l’onglet que tu as ouvert.

Le web n’est pas seulement un réseau de transport. C’est surtout un terminal de lecture, et ce terminal a un nom : le navigateur. C’est lui qui décide de ce que tu vois, comment tu l’interroges, et bientôt de ce qu’un agent peut faire en ton nom. Deux dates racontent bien ce basculement.

2023 : le navigateur devient un moteur d’inférence

Quand Transformers.js apparaît en 2023, l’idée paraît presque farfelue : exécuter des modèles de machine learning directement dans l’onglet, sans serveur d’inférence. La bibliothèque reprend l’API pipeline de la bibliothèque Python de Hugging Face et s’appuie sur ONNX Runtime, ce qui permet de convertir des modèles PyTorch, TensorFlow ou JAX vers un format exécutable côté client.

À l’époque, ça tourne surtout sur WebAssembly, donc sur CPU, avec des modèles quantifiés et une patience certaine. Puis la trajectoire s’accélère. La version 3, annoncée en août 2024, apporte le support WebGPU. La version 4 va plus loin avec un runtime WebGPU réécrit en C++ en collaboration avec l’équipe ONNX Runtime, couvrant environ deux cents architectures de modèles et fonctionnant aussi bien dans le navigateur que dans Node, Bun ou Deno.

Ce qui ressemblait à une démonstration technique est devenu une compétence de plateforme. Un navigateur moderne sait charger des poids quantifiés, choisir un backend selon le matériel disponible, et produire du texte en streaming sans jamais appeler une API externe.

Ce que dit la littérature sur l’inférence en navigateur

L’exécution locale est mesurée par la recherche depuis plusieurs années. Le travail de référence est WebLLM, un moteur d’inférence LLM entièrement en navigateur construit sur les compilateurs MLC LLM et Apache TVM. Ses auteurs rapportent qu’il conserve jusqu’à 80 % de la performance native sur le même appareil, avec une marge de progression annoncée. Le chiffre vaut pour les modèles et les machines de leur protocole de mesure, il ne se transpose pas tel quel à ton modèle sur la machine de ton lecteur.

Ce qui m’intéresse encore plus que le chiffre, c’est le triptyque décrit par le papier, parce qu’il correspond exactement à ce que tu vas mettre en place : WebGPU pour les charges GPU, WebAssembly pour les traitements CPU non triviaux comme la gestion du cache clé-valeur, et des Web Workers pour séparer l’exécution du fil d’interface. Ce n’est pas une recette artisanale, c’est le motif que la recherche a convergé à adopter.

Deux travaux complètent utilement le tableau. Llamas on the Web, backend WebGPU pour llama.cpp publié en mai 2026, s’attaque frontalement aux deux vraies contraintes du navigateur : la mémoire disponible et l’hétérogénéité du matériel. Ses auteurs décrivent une planification mémoire statique, une bibliothèque de kernels ajustable selon l’appareil et des kernels templatés couvrant de nombreux formats de quantification. C’est la justification de fond de l’arbitrage que tu verras plus bas entre poids q4 sur WebGPU et poids q8 sur WASM.

2026 : le navigateur devient adressable

L’inférence locale ne suffit pas. Un modèle qui tourne dans ta page ne sait rien de cette page, et un agent externe doit deviner ce qu’il peut y faire. Jusqu’ici, la seule méthode consistait à photographier l’écran, à envoyer l’image à un modèle de vision et à espérer que le clic tombe au bon endroit. Ou plus simplement laisser le modèle fetcher le contenu complet du site. Coûteux, fragile, et franchement peu élégant.

WebMCP répond exactement à ça. Annoncée le 10 février 2026 par l’équipe Chrome, co-écrite par des ingénieurs de Google et de Microsoft au sein du W3C Web Machine Learning Community Group, l’API permet à une page d’enregistrer ses fonctionnalités sous forme d’outils : un nom, une description en langage naturel, un schéma d’entrée structuré et une fonction d’exécution. Deux styles d’API coexistent, l’une déclarative via des annotations sur les formulaires HTML, l’autre impérative en JavaScript. Le site cesse de se faire deviner. Il se déclare.

Un détail qui t’évitera de recopier du code obsolète : la spécification définit l’API sur Document, donc document.modelContext. Plusieurs présentations de début 2026 parlent encore de navigator.modelContext. Vérifie toujours sur la spécification, c’est le seul document qui fasse foi.

Un mot d’honnêteté sur le statut, parce que le vocabulaire circule vite. WebMCP n’est pas encore une recommandation W3C : la spécification reste un Draft Community Group Report, dont la version courante date de septembre 2026, et elle indique elle-même qu’elle ne se trouve pas sur le W3C Standards Track. Ce qui est officiel, en revanche, c’est l’adoption par les implémenteurs. Chrome a démarré un essai d’origine dans la version 149, et le navigateur intégré de l’application de bureau ChatGPT prend en charge la norme depuis le 25 août 2026, sous le nom de site tools, avec un concours de dix jours monté avec Chrome, Cloudflare, Shopify, Vercel, Render et Netlify.

Le message global est clair : le navigateur sait maintenant exécuter un modèle et se présenter à un agent. Ces deux capacités arrivent à maturité en même temps, et c’est précisément leur croisement qui ouvre le terrain.