Wasm et NPU sur l’appareil : déployer l’IA côté client sans sacrifier la latence
Déployer une intelligence artificielle directement dans le navigateur n’est plus une simple démonstration technique. Pour les applications web interactives, l’exécution locale répond à deux exigences devenues stratégiques : réduire la latence perçue et limiter l’exposition des données sensibles. La question n’est donc plus de savoir si l’IA côté client est possible, mais sur quel accélérateur elle doit s’exécuter.
Dans cette architecture, WebAssembly, WebGPU et WebNN forment une pile complémentaire. Wasm apporte une exécution proche du natif pour les traitements CPU, WebGPU exploite le GPU et WebNN peut router les graphes vers un GPU, un NPU ou un autre accélérateur spécialisé. Associés intelligemment, ils permettent de construire une IA côté client rapide, résiliente et adaptée aux capacités réelles de chaque appareil.
Pourquoi l’IA côté client change la gestion de la latence
Une requête envoyée à un serveur dépend de plusieurs étapes : transmission réseau, mise en file, calcul, retour de la réponse et rendu dans l’interface. Même avec un backend performant, cette chaîne introduit une variabilité difficile à éliminer, notamment sur les réseaux mobiles ou dans les environnements professionnels fortement filtrés.
Avec une inférence locale, le calcul est embarqué dans le navigateur ou dans l’application web. Une transcription, une classification d’image, une recherche sémantique ou une étape de prétraitement peut alors démarrer immédiatement, sans attendre un aller-retour réseau. Le gain le plus visible concerne la latence perçue : l’interface réagit plus vite et reste fonctionnelle même lorsque la connexion est instable.
Le traitement on-device apporte également un bénéfice de confidentialité. Les données peuvent rester sur le terminal, ce qui réduit les transferts vers le serveur et simplifie certains scénarios de conformité. Cette approche ne supprime pas les besoins backend, mais elle permet de réserver le cloud aux tâches qui nécessitent réellement une puissance ou un contexte centralisé.
Wasm, la fondation CPU de l’inférence dans le navigateur
WebAssembly reste la brique « near-native » de référence pour exécuter du code performant côté navigateur. Son modèle binaire compact, son exécution sandboxée et son intégration avec JavaScript en font une base adaptée au portage de bibliothèques de calcul, de runtimes ML et d’optimisations existantes.
Dans la pratique, une grande partie des applications d’inférence IA sur le web s’appuie déjà sur Wasm, soit pour réaliser les calculs sur CPU, soit pour faire le lien avec des moteurs spécialisés. Un module peut être compilé, instancié puis appelé depuis JavaScript, ce qui facilite l’intégration progressive dans une application existante sans réécrire toute la logique métier.
Les progrès récents des moteurs de navigateur réduisent aussi le coût de démarrage. Les observations de JetStream 3 en 2026 soulignent l’efficacité accrue de l’instanciation des modules Wasm. Pour les applications qui chargent de petits modèles ou qui déclenchent ponctuellement une inférence, cette amélioration contribue directement à une meilleure expérience utilisateur.
WebNN et NPU : déplacer les opérations vers le bon matériel
Wasm est particulièrement pertinent pour les workloads CPU-bound, mais il n’est pas toujours le meilleur choix pour les réseaux neuronaux modernes. Les NPU, conçus pour les opérations d’IA, peuvent exécuter certains graphes avec une consommation énergétique et une latence inférieures à celles d’un CPU généraliste.
WebNN a précisément pour objectif d’offrir une API web capable d’exploiter les accélérateurs disponibles sur le terminal. Selon la plateforme, le graphe peut être exécuté sur CPU, GPU, NPU ou un autre moteur spécialisé. Cette abstraction évite de cibler directement chaque constructeur tout en permettant au navigateur de sélectionner le chemin d’exécution le plus adapté.
Les résultats de recherche récents illustrent le potentiel de cette approche. Un benchmark réalisé sur Snapdragon X Elite rapporte, pour un scénario RAG exécuté sur appareil, jusqu’à quatre fois moins de latence de bout en bout et quatre fois moins d’énergie qu’une exécution CPU. Le pré-remplissage d’un modèle de langage y est également annoncé jusqu’à 18,1 fois plus rapide sur NPU, selon la configuration testée.
Une pile hybride : Wasm, WebGPU et WebNN
La meilleure architecture n’oppose pas Wasm au NPU. Elle répartit les responsabilités. Wasm peut prendre en charge le prétraitement, la logique de contrôle, les opérations non supportées et les modèles légers. WebGPU convient aux calculs parallèles nécessitant une grande flexibilité, tandis que WebNN peut déléguer les opérateurs compatibles au NPU ou à un autre accélérateur du système.
Cette hybridation doit être pensée au niveau du graphe d’inférence. Une partie du modèle peut être exécutée via WebNN, pendant qu’une autre reste dans un runtime Wasm ou WebGPU. Le partitionnement doit cependant limiter les copies mémoire et les conversions de formats, car les transferts entre backends peuvent annuler les gains obtenus grâce à l’accélération matérielle.
Un mécanisme de détection progressive est donc essentiel. L’application peut commencer par vérifier les capacités WebNN, les opérateurs disponibles, les formats pris en charge et la mémoire accessible. Elle sélectionne ensuite un chemin NPU, GPU ou CPU Wasm, avec un modèle de secours lorsque le terminal, le navigateur ou le système d’exploitation ne fournit pas les API nécessaires.
Le NPU n’est pas magique : les contraintes de production
Un NPU performant ne garantit pas automatiquement une inférence rapide. Les travaux récents sur les LLM mobiles montrent que l’efficacité dépend fortement du backend logiciel, de la compilation et de la qualité du partitionnement des graphes. Un modèle théoriquement adapté à un NPU peut perdre une grande partie de son avantage si certains opérateurs repassent régulièrement sur le CPU.
La préparation du modèle devient donc une étape critique. Quantification, réduction de précision, fusion d’opérateurs, choix de la taille des tenseurs et limitation des allocations temporaires influencent directement la latence et la consommation. Il faut également mesurer le temps de chargement, l’initialisation du runtime et les transferts mémoire, pas uniquement le temps d’exécution d’un opérateur isolé.
La température et la stabilité dans le temps doivent aussi entrer dans les tests. Un appareil peut afficher d’excellentes performances pendant quelques secondes puis réduire sa fréquence sous l’effet de la chauffe. Les benchmarks doivent comparer CPU, GPU et NPU sur des séquences réalistes, avec des mesures de latence de bout en bout, de débit, d’énergie et de comportement thermique.
Concevoir une expérience web robuste et progressive
Une application d’IA côté client doit traiter l’accélération comme une capacité optionnelle, et non comme une hypothèse universelle. Le navigateur, le système d’exploitation, le modèle de terminal et les pilotes peuvent modifier le résultat. Une stratégie progressive commence par un chemin Wasm fiable, puis active WebGPU ou WebNN lorsque les conditions sont favorables.
Le chargement du modèle doit être optimisé avec autant d’attention que l’inférence. Mise en cache, téléchargement différé, découpage des ressources et préchauffage du runtime permettent de réduire le délai avant la première réponse. Pour les modèles volumineux, une approche mixte peut charger rapidement un petit modèle local, puis compléter l’expérience avec un modèle distant lorsque le réseau et le consentement utilisateur le permettent.
La sécurité reste un autre argument en faveur de Wasm et du traitement local. Le sandboxing du navigateur limite l’exposition du code exécuté, tandis que les propriétés de résistance au détournement du flot de contrôle renforcent le cadre d’exécution. Ces garanties ne remplacent pas une politique de sécurité complète, mais elles constituent une base utile pour traiter des données directement sur l’appareil.
Évaluer le retour sur investissement technique
Le choix d’une architecture locale doit partir du cas d’usage, et non d’un effet de mode matériel. Une fonctionnalité de résumé, de correction ou de classification peut bénéficier d’un petit modèle Wasm. Une analyse d’image ou une inférence répétitive peut tirer parti de WebGPU ou du NPU. Un agent complexe, en revanche, nécessitera souvent une combinaison entre contexte distant et calcul local.
Les indicateurs à suivre doivent refléter l’expérience réelle : délai avant la première réponse, latence au percentile 95, temps d’initialisation, consommation mémoire, autonomie et taux de repli vers le serveur. Il est également utile de segmenter les résultats par navigateur, système d’exploitation, architecture processeur et génération de terminal.
Cette démarche permet de transformer l’accélération en décision produit mesurable. Au lieu de promettre une performance identique partout, l’équipe définit plusieurs profils d’exécution et rend le comportement observable. Les données collectées, idéalement de manière respectueuse de la vie privée, servent ensuite à ajuster les modèles, les seuils de bascule et les stratégies de cache.
En 2026, le client-side AI ne se résume plus à exécuter un modèle dans le navigateur. Le sujet central est le choix dynamique de l’accélérateur : CPU via Wasm, GPU via WebGPU ou NPU via WebNN. Cette complémentarité permet de préserver une expérience fluide tout en tenant compte des contraintes de compatibilité, d’énergie et de confidentialité.
Pour les équipes produit et les développeurs, la stratégie la plus solide consiste à construire une architecture progressive, mesurée et hybride. Wasm fournit une base largement disponible, tandis que WebNN et les NPU ouvrent une voie vers une IA web locale plus rapide et plus économe. L’objectif n’est pas de supprimer le serveur, mais d’embarquer le calcul là où il réduit réellement la latence et améliore l’expérience.
