Par défaut, quand on parle d’IA dans un produit, on imagine un appel à un serveur. L'utilisateur tape quelque chose, les données circulent à travers le réseau, un grand modèle les traite sur une machine distante et la réponse revient. Cette conception fonctionne, évolue et domine le marché. Mais ce n'est pas le seul.
Il existe une tendance croissante, et techniquement solide, à exécuter l'inférence sur le propre appareil de l'utilisateur, dans le navigateur, sans envoyer les données nulle part. C’est le sujet de cet article : de quoi s’agit-il, pourquoi c’est important et où cela n’a plus de sens.
Je traiterai le sujet comme une ingénierie et non comme une tendance. La question n’est pas de savoir si c’est l’avenir, mais plutôt dans quels cas précis le compte est clôturé aujourd’hui.
Que signifie l'inférence locale dans le navigateur
L'inférence est l'étape au cours de laquelle un modèle déjà formé produit une réponse à partir d'une entrée. Former un modèle est coûteux et fastidieux. L'exécution d'inférences à partir d'un petit modèle, selon le cas, est suffisamment légère pour se produire sur l'appareil.
L'inférence locale dans le navigateur signifie que le modèle est chargé et exécuté sur la machine de l'utilisateur, en utilisant le propre CPU, GPU ou NPU de l'appareil. Les données d'entrée ne sortent pas de là. La réponse est calculée sur le client.
Ce n'est pas exotique. Un correcteur de texte qui suggère le mot suivant, un filtre qui identifie les visages sur une photo, une transcription audio qui s'exécute hors ligne : tout cela peut se produire sans serveur d'inférence.
Les quatre raisons qui justifient l'effort
Le premier est la vie privée. Si les données ne quittent pas l'appareil, il n'y a pas de transit d'informations sensibles sur le réseau ni de stockage sur un serveur tiers. Pour certaines catégories de données, cela cesse d’être une commodité et devient une exigence.
La seconde est la latence. Il n’y a pas d’échanges sur Internet. La réponse est pratiquement instantanée, limitée uniquement par le traitement local. Pour les interactions en temps réel, comme les suggestions lors de la saisie, cette différence définit si l'expérience est fluide ou bloquée.
Le troisième est le coût. L’inférence côté serveur est facturée par appel. Chaque requête consomme du GPU payant, s'ajoute à la facture et augmente avec le nombre d'utilisateurs. L'inférence locale décharge ce traitement sur le matériel dont l'utilisateur dispose déjà. Le coût marginal de l’inférence tombe à près de zéro.
La quatrième consiste à travailler hors ligne. Un modèle chargé dans le navigateur continue de répondre même sans connexion. Pour les applications devant fonctionner dans des réseaux instables ou des environnements déconnectés, il s'agit d'un avantage de conception difficile à reproduire sur le serveur. Cet ensemble de propriétés s'inscrit directement dans la philosophie local-first, qui place l'appareil au centre.
Comment cela fonctionne en pratique
L'élément qui rend ce scénario possible est le runtime d'inférence qui fonctionne dans le navigateur. Le plus établi aujourd’hui est ONNX Runtime Web. Il charge les modèles au format ONNX et les exécute sur le client, en utilisant WebAssembly, WebGPU et, à mesure qu'il mûrit, WebNN pour accéder à l'accélération matérielle.
Le flux conceptuel est direct. Vous entraînez ou obtenez un modèle, le convertissez dans un format compris par le runtime, optimisez la taille et la précision, puis chargez-le dans l'application Web. À partir de là, l’inférence se fait localement.
La tendance qui rend cela viable est celle des petits transformateurs. Les modèles compacts, souvent distillés à partir de modèles plus grands puis quantifiés pour occuper moins de mémoire, peuvent s'adapter à un téléchargement raisonnable et fonctionner avec des performances acceptables. Ils ne rivalisent pas en capacité avec les modèles géants, mais ils résolvent facilement des tâches bien définies. Pour comprendre cette compression, il convient de connaître les modèles quantifiés dans le navigateur.
Là où l'approche atteint son plafond
C’est là que je préfère être clair plutôt qu’optimiste. L'inférence locale dans le navigateur a des limites concrètes, et les ignorer est une source de frustration.
Les grands modèles ne conviennent pas. Un modèle avec des milliards de paramètres n'est pas viable à télécharger ou à exécuter dans un onglet de navigateur commun. Ceux qui ont besoin de la capacité des modèles frontières continueront de dépendre du serveur. Il n’existe aucune astuce pour contourner la physique et la mémoire.
Le matériel utilisateur varie beaucoup. Un ordinateur portable récent doté d'un NPU dédié et un ancien téléphone portable offrent des expériences radicalement différentes pour un même modèle. Vous construisez pour une flotte hétérogène d’appareils, sans aucun contrôle sur celle-ci. Ce qui vole dans une machine s’étouffe dans une autre.
Il y a aussi le coût initial du téléchargement. Charger un modèle, même petit et quantifié, signifie télécharger des mégaoctets avant la première utilisation. Cela pèse sur la première expérience et nécessite une stratégie de mise en cache et de chargement.
Et il y a l'entretien. Les modèles côté client doivent être versionnés, mis à jour et distribués. Résoudre un problème dans le modèle signifie déployer une nouvelle version sur tous les appareils, avec toute la complexité de déploiement que cela implique.
Il existe également une limite moins évidente : l'observabilité. Lorsque l'inférence s'exécute sur le serveur, vous voyez tout, mesurez la qualité, détectez les dégradations et ajustez. Lorsqu'il s'exécute sur l'appareil de l'utilisateur, cette boucle de rétroaction devient plus opaque. Vous ne pouvez pas voir les entrées ou les résultats sans collecter de télémétrie, et la collecte de télémétrie sur quelque chose que vous avez choisi de garder local peut contredire la raison même de ce choix. Il existe une véritable tension entre la confidentialité et la capacité d'améliorer le modèle, et il doit être conçu exprès, et non découvert plus tard.
Comment choisir entre local et serveur
Le choix n’est pas idéologique, il est situationnel. Les tâches de petite taille, sensibles à la confidentialité, à la latence ou nécessitant une connexion hors ligne sont des candidats naturels pour un traitement local. Il est préférable d'effectuer les tâches qui nécessitent des modèles volumineux, un contrôle centralisé ou des mises à jour fréquentes sur le serveur.
Le dessin le plus abouti est rarement pur. De nombreux produits combinent les deux : un modèle local pour une réponse rapide et privée dans le cas courant, avec une escalade vers le serveur lorsque la tâche est plus exigeante. Un hybride bien pensé l’emporte généralement sur le purisme des deux côtés.
L’important est de considérer cela comme une décision architecturale, avec des critères explicites, et non comme une adoption de mode. L’IA dans les produits concerne les processus, la gouvernance des données et la mesure des résultats. Le navigateur ouvre simplement une option supplémentaire sur la table.
Un détail souvent négligé : l’inférence locale change qui paie la facture informatique. Sur le serveur, le coût est à votre charge et augmente avec le succès du produit. Sur l'appareil, le coût est à la charge de l'utilisateur, en termes de batterie et de traitement. Cela semble génial jusqu'à ce que vous vous souveniez que les batteries s'usent et que les téléphones portables chauffent. Un modèle mal optimisé fonctionnant à chaque contact peut dégrader silencieusement l'expérience, et l'utilisateur le ressentira sans savoir pourquoi. L’optimisation ici n’est pas un luxe, c’est une exigence d’expérience.
Si vous envisagez de déplacer une partie de l'inférence vers l'appareil de l'utilisateur, la meilleure première étape consiste à mesurer : prenez le cas d'utilisation le plus simple, exécutez une preuve de concept avec un petit modèle et mesurez les performances réelles sur les appareils de votre public. Vous souhaitez discuter de la pertinence de votre cas ? Je suis ici.
A lire aussi
- IA sur appareil : la décision stratégique entre le serveur et le sur appareil
- WebNN : l'API qui apporte l'accélération matérielle au navigateur
- Modèles quantifiés : la clé pour exécuter l'IA dans le navigateur
- WebNN et ONNX Runtime Web : la pile d'inférence accélérée dans le navigateur -L'inférence à la périphérie : lorsque l'exécution de l'IA sur l'appareil a plus de sens que dans le cloud
- [Qu'est-ce que les données synthétiques et pourquoi est-ce important pour les dirigeants]9