LiteRT.js : exécuter une IA locale dans le navigateur avec une solution de repli claire

LiteRT.js est l'interface de Google pour exécuter de l'inférence d'intelligence artificielle (IA) dans le navigateur. Elle peut utiliser WebAssembly sur l'unité centrale de traitement (CPU) et WebGPU lorsqu'une accélération compatible existe. La conception doit prévoir dès le départ les appareils qui ne couvrent pas le chemin préféré.

Le cas pratique évaluera la qualité d'une photo avant son envoi. Le modèle local détectera un flou ou une mauvaise exposition et affichera une recommandation. Si le navigateur ne peut pas exécuter le modèle, l'application expliquera la limite et proposera un autre chemin.

LiteRT.js amène le modèle sur l'appareil

Au 15 juillet 2026, Google documentait LiteRT.js comme un environnement web pour charger et exécuter des modèles compatibles. Le guide de démarrage montre une API de chargement et de compilation ainsi qu'un chemin accéléré par WebGPU. La compatibilité réelle dépend du navigateur, du matériel et du modèle.

Exécuter sur l'appareil peut réduire les allers-retours réseau pendant l'inférence. Cela permet aussi des réponses même quand la connexion est instable, à condition que l'application et le modèle soient déjà disponibles. Cela n'élimine pas le coût de téléchargement, de compilation et de mémoire.

Avant de le choisir, définissez ce qu'il apporte au cas de la photographie. Un avertissement immédiat avant l'envoi peut éviter un téléversement inutile et garder l'image hors du serveur. Cet avantage n'existe que si les autres parties de la page ne transmettent pas non plus la photo.

La détection précède le téléchargement

Vérifiez les capacités avant de télécharger un gros modèle. Détectez les API nécessaires, relevez la mémoire disponible quand c'est possible et tenez compte du type d'appareil. L'interface doit rester utilisable pendant le choix du chemin.

Pour la photo, affichez d'abord le sélecteur et une courte explication. Si le navigateur remplit les conditions, lancez le chargement du modèle avec une progression visible. Sinon, proposez une évaluation distante facultative ou laissez continuer sans analyse.

N'utilisez pas une détection fondée uniquement sur le nom du navigateur. Versions, pilotes et politiques peuvent varier dans une même famille. Exécutez un test de capacité et interceptez l'erreur d'initialisation.

Le chargement exige des états et des limites clairs

Le modèle ajoute des octets, du temps de démarrage et de la mémoire au parcours. Indiquez que l'analyse locale se prépare et permettez d'annuler quand le téléchargement traîne. Ne mettez en cache que si la politique du produit et le stockage disponible le permettent.

Une barre complète ne prouve pas que le modèle est prêt. Distinguez téléchargement, compilation et première inférence. Pour le cas pratique, activez « Analyser la photo » après avoir confirmé que le chemin local répond à une entrée de test.

Définissez un temps maximal et une reprise. Si la compilation échoue, libérez les ressources et activez le repli. Une boucle de nouvelles tentatives silencieuse consomme la batterie et laisse la personne sans décision.

La qualité se mesure avec des photos représentatives

Préparez des images de test de bonne qualité, floues, sombres et de tailles différentes. Comparez la sortie du modèle à une classification relue et notez les erreurs importantes. Une démonstration avec une seule photo ne permet pas d'évaluer le comportement.

Mesurez aussi le temps jusqu'au premier résultat, la latence suivante, la mémoire et la chaleur perçue sur de longues sessions. Incluez des téléphones de milieu de gamme, un appareil sans WebGPU et des navigateurs représentatifs. Les benchmarks de l'éditeur servent de référence, pas d'acceptation pour votre produit.

Si l'analyse conclut qu'une photo est floue, expliquez l'action : stabiliser l'appareil, améliorer la lumière ou refaire la prise. Un score sans contexte n'aide pas. Le guide des prompts applique le même principe de résultat vérifiable.

La confidentialité dépend de tout le parcours

L'inférence locale décrit où le modèle s'exécute, pas tout ce que fait l'application. Analytique, journaux d'erreur, stockage, miniatures ou services de sauvegarde peuvent envoyer des données. Documentez chaque sortie réseau avant d'affirmer que l'image reste sur l'appareil.

Inspectez le réseau pendant la sélection, l'analyse et le rejet. Refaites le test avec le repli distant et affichez une demande de consentement avant l'envoi. Le texte doit distinguer clairement les deux chemins.

Évitez de journaliser l'image, son contenu extrait ou des identifiants inutiles. Si vous avez besoin de télémétrie, mesurez des durées et des codes d'état sans y joindre de données personnelles. La personne doit pouvoir continuer si elle refuse le repli.

Le repli fait partie du produit

Un chemin alternatif n'est pas une erreur honteuse à dissimuler. Expliquez que l'analyse locale n'est pas disponible sur cet appareil et proposez des options concrètes : continuer sans évaluation, utiliser un serveur avec consentement ou essayer une autre image. Préservez la fonction principale tant que c'est sûr.

Le repli distant a besoin de ses propres règles de conservation, d'accès et de suppression. Ne l'activez pas en arrière-plan. L'approche responsable du vibe coding exige de tester le chemin principal comme le chemin dégradé.

Consignez combien de sessions empruntent chaque chemin et pourquoi le local échoue. Cette preuve permet de décider s'il faut changer de modèle, réduire sa taille ou retirer une fonction. Ne transformez pas le pourcentage en promesse sans date ni échantillon représentatif.

Les limites apparaissent dans le téléchargement, la mémoire et la compatibilité

Un modèle peut être trop lourd pour une connexion mobile ou épuiser la mémoire au fil des inférences. WebGPU peut exister et échouer malgré tout à compiler une opération. Interceptez les deux cas et remettez l'interface en état.

La qualité peut aussi varier sur des groupes d'images absents de l'évaluation. Revoyez éclairages, appareils et contextes divers. Un résultat local incorrect reste un résultat incorrect.

Enfin, le navigateur partage ses ressources avec le reste de la page. Évitez plusieurs inférences simultanées et libérez les tenseurs ou sessions inutilisés. Une interface fluide compte autant que le chiffre isolé d'une inférence.

Vérifiez l'expérience avant de la publier

Parcourez ces cases sur plusieurs appareils. Chaque réponse doit s'appuyer sur une mesure, une inspection réseau ou un comportement visible.

• L'application détecte les capacités avant de télécharger le modèle.
• Chargement, compilation, exécution et erreur ont des états compréhensibles.
• Les photos de test couvrent qualité, tailles et appareils différents.
• Tout le parcours des données, télémétrie comprise, est documenté.
• Le repli distant exige information et consentement explicites.
• Une panne libère les ressources et permet de continuer sans risque.

LiteRT.js ouvre un chemin utile pour l'IA locale, mais une architecture fiable inclut aussi l'appareil qui ne peut pas s'en servir. Détectez, chargez, exécutez, mesurez et activez un repli déclaré. Cette séquence transforme une démonstration en fonction maintenable.