WebNN et ONNX Runtime Web : la pile d'inférence accélérée dans le navigateur

Chaque fois que quelqu'un parle d'exécuter l'IA dans le navigateur, la conversation se tourne rapidement vers une question d'ingénierie très concrète : comment un modèle entraîné en Python, sur un serveur doté d'un GPU, se retrouvera-t-il dans un onglet Chrome et s'exécutera-t-il suffisamment vite pour être utile ? La réponse n’est pas un seul produit. Il s'agit d'un empilement de trois pièces qui s'emboîtent, et comprendre comment elles s'emboîtent est ce qui sépare une décision architecturale solide d'une expérience qui meurt en prototype.

Les trois pièces sont une forme, un moteur et une couche d'accélération. Le format est ONNX. Le moteur est ONNX Runtime Web. La couche d'accélération est WebNN. Chacun résout un problème différent, et le plus amusant réside dans la façon dont ils se réunissent.

Le format : ONNX comme dénominateur commun

Les modèles naissent dans différents cadres. Une équipe s'entraîne à PyTorch, une autre à TensorFlow, une autre à ses propres outils. Chaque framework stocke le modèle à sa manière, ce qui devient pénible lorsque vous souhaitez sortir le modèle de l'environnement dans lequel il a été créé.

ONNX, qui signifie Open Neural Network Exchange, est un format ouvert conçu pour être ce dénominateur commun. Vous vous entraînez où vous voulez et exportez vers ONNX. Le modèle est désormais décrit de manière standardisée, indépendante du framework source, que tout outil compatible peut lire.

Pour ceux qui décident de l'architecture, la valeur d'ONNX est le découplage. Votre choix de cadre de formation ne lie plus votre choix d’environnement d’exécution. Entraînez-vous à un endroit, courez à un autre, et le format intermédiaire garantit que le pont existe. C'est une infrastructure ennuyeuse dans le meilleur sens du terme : on n'y pense pas quand elle fonctionne.

Le moteur : ONNX Runtime Web s'exécute dans le navigateur

Avoir le modèle dans ONNX ne suffit pas. Quelqu'un doit charger ce fichier, interpréter la séquence d'opérations qu'il décrit et faire le calcul. C'est le travail d'un runtime d'inférence.

ONNX Runtime Web est la version de ce runtime conçue pour s'exécuter dans le navigateur. Il prend le modèle ONNX et l'exécute sur le client, en utilisant les ressources offertes par la plateforme Web. Historiquement, cela signifiait deux voies : WebAssembly, qui s'exécute sur le processeur avec des performances décentes, et WebGL, qui exploite le GPU via l'API graphique du navigateur.

Ces itinéraires fonctionnent, mais ils ont des limites. WebAssembly sur le processeur est portable et fiable, mais ce n'est pas la solution la plus rapide pour les modèles plus grands. WebGL utilise le GPU, mais indirectement, car il a été conçu pour restituer des graphiques et non pour exécuter des réseaux de neurones. C’est là qu’intervient le troisième élément de la pile, celui qui modifie le plafond de performances.

Accélération : WebNN et accès au bon matériel

WebNN, ou Web Neural Network API, est une API qui donne au navigateur un accès direct au matériel d'accélération de l'IA de l'appareil. Au lieu d'utiliser une API graphique comme intermédiaire, il s'adresse à ce qui est le plus adapté sur l'appareil : le CPU, le GPU ou, lorsqu'il est disponible, le NPU.

Le NPU mérite attention. Il s'agit de l'unité de traitement neuronal, un bloc de silicium dédié aux opérations des réseaux neuronaux qui apparaît fréquemment dans les téléphones portables et ordinateurs portables modernes. Il effectue des inférences tout en consommant moins d’énergie et plus efficacement qu’un CPU ou un GPU générique. Le problème est que, jusqu'à WebNN, le navigateur n'avait tout simplement aucun moyen de lui parler. Le NPU était là, inactif, invisible sur le Web.

ONNX Runtime Web peut utiliser WebNN comme l'un de ses chemins d'exécution. Lorsque cela se produit, le moteur délègue le gros du travail à la couche qui sait comment piloter le meilleur matériel disponible. Le modèle ONNX reste le même. Ce qui change, c'est l'endroit et la manière dont il circule en dessous, avec un bond en termes de performances et d'efficacité énergétique que les anciennes routes n'avaient pas réalisé. Ce gain est ce qui rend, en pratique, l'inférence locale dans le navigateur viable pour des modèles qui n'avaient auparavant de sens que sur le serveur.

La pile entière, d'un bout à l'autre

Cela vaut la peine de rassembler les pièces en un seul flux mental. Un modèle est formé dans n'importe quel framework, sur le serveur, avec toute l'infrastructure de formation. Il est ensuite exporté vers ONNX, obtenant une représentation standardisée et portable. Ce fichier est transmis au navigateur, où ONNX Runtime Web le charge et l'exécute. Et, lorsque l'environnement le permet, le runtime déclenche WebNN pour que les comptes s'exécutent sur le CPU, le GPU ou le NPU de l'appareil de l'utilisateur.

Le résultat de cette chaîne est une inférence qui se produit entièrement sur le client. Aucune donnée n'a besoin de transiter vers un serveur, ce qui est important pour la confidentialité. Aucune demande n'engendre de frais de cloud computing, ce qui compte pour la facture en fin de mois. Et il n'y a pas de latence réseau entre l'action de l'utilisateur et la réponse du modèle, ce qui est important pour l'expérience.

Ajoutez cela à la quantification du modèle, qui réduit ONNX à une taille de téléchargement raisonnable, et vous obtenez une combinaison qui rend enfin l'IA dans le navigateur défendable dans le produit, pas seulement dans la démo.

Les limites à respecter

Voici la partie qui sépare l’enthousiasme de la responsabilité. WebNN n’est pas encore une technologie mature et stable partout. Au W3C, elle est au stade de recommandation candidate, c'est-à-dire qu'il s'agit d'une spécification avancée mais pas encore finalisée en tant que norme consolidée. Cela signifie que les détails peuvent changer.

Le soutien pratique est inégal. L'exécution accélérée des GPU et NPU de WebNN dans la plupart des navigateurs est en phase de prévisualisation ou en retard sur les indicateurs expérimentaux. Il fonctionne dans des environnements contrôlés, dans des versions spécifiques, avec des configurations spécifiques. Ce n'est pas quelque chose sur lequel vous pouvez compter de manière uniforme sur les appareils et les navigateurs de vos utilisateurs réels.

La recommandation est donc directe et peu romantique : ne placez pas encore WebNN comme une dépendance de production critique. À utiliser pour les prototypes, les preuves de concept et les fonctionnalités optionnelles qui se dégradent progressivement lorsque l'accélération n'est pas disponible. Ayez toujours un chemin de secours, généralement WebAssembly sur le processeur, lorsque l'accélération matérielle ne peut pas être déclenchée. Traiter une spécification dans Candidate Recommendation comme s’il s’agissait d’une infrastructure stable est le genre de pari qui vieillit mal.

Comment réfléchir à cette décision

Pour les concepteurs d'architecture, la pile ONNX plus ONNX Runtime Web plus WebNN constituent un pari judicieux à moyen terme, pas une base pour aujourd'hui. Le format ONNX et ONNX Runtime Web sont déjà suffisamment solides pour une utilisation réelle, y compris les routes CPU et GPU traditionnelles. La couche WebNN est l’avenir de la performance, mais un avenir qui reste à venir.

Une lecture honnête signifie séparer ce qui est déjà prêt de ce qui est encore mûr. Adoptez ONNX comme format sans crainte, il vous offre dès aujourd'hui la portabilité. Utilisez ONNX Runtime Web là où l'inférence côté client a du sens, en vous appuyant sur WebAssembly comme base fiable. Et traitez WebNN comme une optimisation progressive : lorsqu'elle est disponible et stable, elle s'accélère ; sinon, votre produit continue de fonctionner. Cette posture correspond bien à la maturité attendue du développement web en 2026, où des ressources de pointe s'ajoutent à un socle qui n'en dépend jamais.

Si vous élaborez une stratégie d'IA côté client, la décision prudente consiste à s'appuyer dès maintenant sur ONNX et ONNX Runtime Web, avec un repli solide, et à suivre l'évolution de WebNN pour activer l'accélération à mesure qu'elle mûrit. Commencez par ce qui est stable et laissez de la place à ce qui vient.