Disponibilité de WebNN, backends et confidentialité

WebNN est une API web qui représente les calculs d’apprentissage automatique sous forme de graphes exécutés par le navigateur. Elle peut permettre une inférence locale sans rendre tout le traitement dépendant d’un service distant. Le support varie selon les implémentations : prévoyez un repli et ne déduisez ni vitesse ni matériel de la seule présence de l’API.

Ce que représente WebNN

L’application décrit les opérations et les flux de données, puis demande au navigateur de construire, compiler et exécuter un graphe. L’API vise à laisser l’agent utilisateur affecter le calcul aux ressources disponibles, sans lier le modèle à l’interface d’un fabricant particulier (modèle de programmation du W3C).

WebNN ne concerne pas le rendu graphique. Pour le calcul et le rendu graphiques, consultez WebGPU et la confidentialité du navigateur. La présence d’une API ne signifie pas que l’autre est disponible.

Décrivez la tâche, pas le nom de l’API : une fonction photo peut avoir besoin d’un graphe d’image, une transcription d’un graphe audio et une fonction documentaire d’un graphe de texte. Chaque tâche peut avoir un modèle, une forme d’entrée, une interprétation de sortie et un repli différents.

Gardez ces décisions séparées pour ne pas présenter une capacité générale alors qu’une seule fonction a été testée. Vous pourrez ainsi expliquer quelle fonction est indisponible tout en laissant les parties sans rapport utilisables. Un graphe valide peut ne pas convenir à une entrée particulière, comme une image à disposition de couleurs inattendue ou un document contenant du texte non pris en charge. Validez aussi le parcours d’entrée et expliquez quelle partie doit être corrigée, sans demander à l’utilisateur de comprendre le modèle d’exécution du navigateur.

Disponibilité et choix d’exécution

Le support dépend de la maturité de l’implémentation, du canal de diffusion, du système, du matériel et de la configuration. Un navigateur peut n’exposer qu’une partie des fonctions prévues, voire aucune. La spécification prévoit une requête de support des opérateurs avec opSupportLimits() et n’expose pas le dispositif sélectionné (requête de support, considérations de confidentialité) : la disponibilité de l’API ne prouve donc pas quel backend exécute le graphe.

Ces décisions peuvent changer entre versions : un navigateur peut ajouter une opération, retirer un parcours expérimental ou modifier la planification d’un graphe ; une mise à jour système peut changer les ressources disponibles, et une installation administrée peut restreindre des fonctions pour des raisons de politique. Ce sont des détails d’implémentation qui affectent compatibilité et performances, pas un contrat stable pour identifier une machine.

Quand un résultat importe, consignez la version du navigateur, la famille du système, la version de l’application, la révision du modèle et le besoin du graphe. Ces éléments aident le responsable à modifier l’application, maintenir un repli ou différer une fonction, mais ne justifient pas une conclusion sur l’appareil physique d’une personne.

Le même graphe peut être accepté dans une version et refusé dans une autre si une opération n’est pas encore disponible ou si l’application dépend d’un comportement hors de sa politique de support. Consignez-le comme résultat de compatibilité, pas comme information sur une personne ou une machine.

Questions de confidentialité

L’inférence locale peut réduire l’envoi de certaines entrées à un service, mais elle ne rend pas automatiquement l’application privée. Celle-ci contrôle toujours le stockage, le transfert et les journaux. Une page peut aussi apprendre si une capacité existe. Utilisez cette réponse pour choisir une fonction, pas pour identifier une personne ou affirmer quel matériel elle possède. Le calcul local ne décrit pas le comportement réseau du reste de l’application : dans le cadre d’une revue des flux de données, vérifiez si elle téléverse séparément les données source, les résultats ou la télémétrie (considérations de confidentialité du W3C). La déclaration de confidentialité du W3C décrit le traitement des entrées par WebNN ; un téléversement indépendant par l’application constitue un autre flux de données.

Limitez les vérifications aux besoins visibles de la fonction, ne demandez que les informations nécessaires et examinez la télémétrie avant d’y enregistrer des résultats. La confidentialité dépend du flux complet, pas seulement du lieu du calcul : un graphe local peut garder une entrée sur l’appareil, mais l’application peut encore stocker une image source, mettre un modèle en cache, exporter un résultat ou envoyer un rapport d’erreur. Un repli distant peut nécessiter un téléversement, un compte et une autre durée de conservation ; expliquez ce choix avant de déplacer les données. Pour le support, préférez un état simple, fonction disponible, repli choisi ou tâche inachevée, à l’objet complet de capacités. Les entrées peuvent contenir visages, voix ou documents personnels et nécessitent des règles distinctes d’accès et de suppression. Le choix d’exécution du navigateur ne répond pas à ces questions produit.

Tests de compatibilité

Testez le graphe requis et son résultat attendu dans chaque famille de navigateurs prise en charge. Prévoyez un parcours pour les navigateurs sans WebNN et vérifiez que le passage au repli ne perd pas de données et ne laisse pas une tâche inachevée. Évaluez le résultat fonctionnel séparément des attentes de performance. Tenez un relevé compact de la version du navigateur, du système, du résultat de la fonction et du repli ; ne décidez pas à partir d’un seul poste, ne transformez pas la durée en seuil de publication ni en étiquette de l’appareil. Utilisez des fixtures représentatifs et non sensibles pour les entrées valides et invalides, les données de modèle manquantes, les opérations indisponibles, l’annulation et les résultats que l’interface ne sait pas présenter. Évaluez séparément le sens du résultat, la stabilité mémoire, l’interaction, l’accessibilité et la possibilité de corriger le résultat. Gardez les vérifications propres à chaque fonction lorsque les modèles prennent en charge des graphes différents, au lieu de créer un état global « prêt ». Consignez tâche, classe d’entrée, état d’achèvement et repli visible sans conserver de description permanente du navigateur.

Gérer les changements de version

Lorsque le support change, relancez les tests du graphe et vérifiez le repli. Un changement de backend justifie une revue s’il affecte les résultats ou les ressources dont dépend l’application, mais la disponibilité publique ne permet pas d’en déduire le backend.

La revue des versions du navigateur permet de comparer les versions. La maturité de WebNN et sa surface peuvent évoluer indépendamment du support WebGPU. Pour chaque version candidate, testez la compilation prise en charge et la révision du modèle sur les mêmes fixtures, y compris la mise à jour d’un modèle en cache. Distinguez une interface indisponible, une sortie inacceptable et une exécution incomplète : elles peuvent nécessiter un autre parcours, une modification du modèle ou de la compilation, ou une annulation récupérable.

Couvrez chaque famille de navigateurs et plage de systèmes annoncée ; fixez révision d’application, modèle et fixtures afin d’attribuer les changements. Une fonction facultative ne doit pas désactiver le reste de la page. Documentez tâche, résultat observé et plage prise en charge, sans promettre une sortie ou une vitesse identique partout.

Lors de l’analyse d’un changement, ne faites varier qu’un élément de version à la fois lorsque c’est possible. Comparez d’abord une mise à jour du navigateur seul avec le même modèle et le même prétraitement, puis une mise à jour du modèle seul sur une version connue du navigateur.

Cela distingue l’acceptation du graphe, la conversion d’entrée, le comportement du modèle et le choix du repli. Pour les images, vérifiez disposition des couleurs, orientation, alpha et redimensionnement, y compris transparence et changement de taille. Pour l’audio, faites varier fréquence d’échantillonnage et nombre de canaux ; incluez silence, écrêtage, voix avec bruit de fond et extraits courts et longs. Vérifiez que rééchantillonnage et conversion des canaux suivent le prétraitement déclaré. Pour le texte, couvrez entrées vides et longues, ponctuation inhabituelle, plusieurs écritures et document d’une langue différente de celle du modèle sélectionné.

Distinguez échecs de validation, prétraitement, création et exécution du graphe, post-traitement et présentation. Évaluez l’utilité sémantique du résultat, pas seulement l’exécution du graphe, et séparez acceptation fonctionnelle de latence et mémoire. Une répétition avec la même entrée révèle un état conservé par erreur ; une autre fixture vérifie que le changement de modèle ou de langue change le parcours. Présentez les problèmes sous une forme que l’utilisateur peut corriger, comme choisir un autre fichier ou une autre langue ; ne blâmez pas le navigateur si l’entrée sort de la plage prise en charge par le modèle.

Pour chaque modèle, documentez avec ses fixtures les formes et plages d’entrée et de sortie, la normalisation et le mappage des étiquettes. Incluez des valeurs juste à l’intérieur et à l’extérieur des limites et vérifiez qu’un refus reçoit un message propre à l’entrée avant l’exécution du graphe. Comparez les sorties à des critères d’acceptation par tâche, sans exiger des valeurs internes identiques entre implémentations. Le manifeste doit indiquer les révisions du modèle et du prétraitement, la classe d’entrée, le résultat attendu et si une personne doit examiner ou corriger ce résultat.

En classification, vérifiez le mappage des étiquettes et traitez un score comme indicatif sauf si le modèle en définit le sens. En transcription, vérifiez les omissions de parole et la gestion de la langue ; pour les résumés, comparez les affirmations clés à la source. Définissez les critères d’acceptation de chaque type de résultat.

La livraison du modèle exige des règles de cycle de vie explicites. Gardez active une révision connue comme fonctionnelle pendant le téléchargement de son remplacement ; vérifiez le nouvel actif avec une tâche simple avant de le sélectionner et récupérez proprement après une interruption. Étiquetez les actifs en cache avec les révisions du modèle et du prétraitement et une note de compatibilité ; distinguez actifs complets et téléchargements partiels, et évitez de réutiliser une ancienne langue ou un ancien prétraitement après activation. Si la connexion tombe ou que le stockage est plein, ne supprimez que l’actif temporaire incomplet, gardez la révision utilisable et laissez l’utilisateur choisir de réessayer ou de télécharger plus tard.

Si l’espace est limité, indiquez quel actif serait supprimé et proposez un modèle plus léger ou un service ; ne supprimez jamais le seul modèle local fonctionnel avant que son remplacement ait réussi cette vérification. Notez les contraintes de licence.

Une mise à jour peut changer étiquettes, interprétation de confiance, couverture linguistique ou texte d’accessibilité même si les opérations du graphe restent identiques ; expliquez ces changements visibles et permettez de garder la version précédente si politique et stockage le permettent.

Testez le repli comme un parcours complet avec la tâche et le fixture qui ont révélé le graphe non pris en charge ou en échec. Un parcours sans inférence peut permettre de modifier une transcription manuellement, de rechercher un document normalement ou d’appliquer un filtre sans classification ; un modèle plus petit doit indiquer ses limites d’entrée ou de qualité ; un service peut nécessiter compte et téléversement. Gardez l’entrée originale jusqu’à ce que l’utilisateur accepte le résultat, proposez l’annulation et laissez un état récupérable après perte réseau, permission refusée, stockage plein ou départ de la page. Indiquez si une requête inachevée a été annulée, peut reprendre ou a laissé un résultat partiel ; ne présentez pas celui-ci comme terminé. Avant tout téléversement, identifiez le service et sa conservation puis demandez une confirmation explicite. Lors d’une nouvelle tentative, indiquez si le traitement reste local ou franchit cette frontière. L’utilisateur doit pouvoir revenir sans perdre la source ni accorder une permission sans rapport ; ne basculez jamais silencieusement du local vers l’envoi parce qu’un graphe est indisponible.

Intégrez l’accessibilité au même relevé de version. Une étiquette prévue doit être lisible par un lecteur d’écran ; un indicateur uniquement coloré doit avoir un autre signal ; l’utilisateur doit pouvoir corriger ou ignorer un résultat indicatif. Annoncez clairement la progression et gardez-la compréhensible après zoom ou lorsque le focus va sur Annuler. Testez au clavier seul de la sélection d’entrée à la correction du résultat et à l’annulation ; vérifiez que le focus ne se perd pas au changement de modèle ou de repli. Pour les fonctions vocales ou d’image, dites si le résultat est une suggestion, une transcription ou un export final. Gardez un parcours manuel si le résultat est incertain ou si l’utilisateur ne peut accorder la permission demandée.

Pour l’exploitation et le support, ne conservez que les versions du navigateur et de la famille du système, révisions de l’application et du modèle, besoin du graphe, classe d’entrée, étape en échec et résultat attendu par rapport au résultat visible nécessaires à la reproduction. Préférez un code de résultat et un fixture synthétique aux images, enregistrements, documents ou graphes complets. Notez si la personne a choisi le traitement local ou un service, et supprimez les fixtures et diagnostics temporaires à la clôture du dossier. Définissez une durée de conservation et informez les utilisateurs des champs collectés lorsqu’ils choisissent de signaler un problème. Si le média source est indispensable, obtenez-le au moyen de consentements et commandes de suppression séparés dans le processus de support. Comparez tâches terminées, replis, annulations et tâches incomplètes entre versions prises en charge sans créer de profil navigateur permanent ; gardez les autres fonctions disponibles et expliquez la tâche touchée.

Réexaminez la confidentialité lorsque le flux de données ou le comportement du modèle change. L’inférence locale indique où s’exécute le graphe, pas si l’application stocke ou transmet entrées sources, résultats ou télémétrie. Examinez ces parcours séparément : une image choisie peut être mise en cache localement, un résultat exporté et un rapport envoyé même si le graphe reste sur l’appareil. Ne liez pas d’objets de capacité détaillés à des identifiants de compte lorsqu’un résultat agrégé suffit. Séparez les données nécessaires au fonctionnement de la fonction de celles du support : l’inférence peut nécessiter une entrée temporaire, tandis que la télémétrie n’a parfois besoin que de savoir si une fonction a abouti, utilisé un repli ou été annulée. Les diagnostics doivent être choisis par l’utilisateur, limités à la reproduction, assortis d’un objectif et d’une durée de conservation déclarés, avec suppression possible des dossiers, modèles en cache et résultats temporaires. Pour la reproductibilité, reliez versions du navigateur, de l’application et du modèle au prétraitement, post-traitement, invalidation du cache, gestion d’entrée et résultats exportés lorsque la tâche dépend de leur combinaison ; examinez ces couches séparément si une seule change. Évaluez fonctionnalité, mémoire, interaction et explications accessibles comme des critères distincts. Dites si un résultat est indicatif et comment le corriger ; ne retirez un repli qu’après avoir retesté la même tâche sur toute la plage prise en charge. Une installation administrée peut appliquer une politique différente d’un navigateur personnel : documentez les configurations prises en charge et gardez un parcours utilisable si l’administrateur désactive un graphe facultatif.

Correspondance affirmations-sources

• Le modèle de programmation du graphe et la limite entre construction et exécution par le navigateur sont définis dans le modèle de programmation du W3C.
• La disponibilité par opérateur se vérifie avec opSupportLimits() ; cela ne révèle ni le backend ni le matériel.
• La limite nuancée de confidentialité sur les capacités et le traitement des entrées figure dans les considérations de confidentialité du W3C ; les téléversements, le stockage et la télémétrie de l’application sont des flux distincts.
• La spécification WebNN est la référence pour la validation, l’exécution et la compatibilité ; les tests décrits sont des critères d’acceptation de l’application, pas des garanties normatives du navigateur.

Sources publiques

• Spécification WebNN du W3C
• API WebNN, groupe communautaire Web Machine Learning du W3C