Battery Status API : vie privée et disponibilité
Comprendre les informations exposées par Battery Status API, ses limites de compatibilité et son usage sans créer un profil utilisateur.
Vous voulez la documentation structurée pour Empreinte ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
Battery Status API peut indiquer l’état de charge actuel du navigateur, le niveau de batterie et une durée estimée de charge ou de décharge. Il s’agit d’un signal de capacité optionnel et peu largement disponible, pas d’une identité de l’appareil ni d’une garantie sur la durée d’une session. L’application doit détecter la fonctionnalité, conserver un comportement par défaut utile et utiliser le résultat uniquement pour une décision réversible et visible.
Ce que fournit Battery Status API
Lorsque le navigateur expose navigator.getBattery(), l’application peut l’appeler. Le BatteryManager renvoyé peut exposer charging, level, chargingTime et dischargingTime, ainsi que des événements de changement. Ces valeurs décrivent l’état d’alimentation observé par le navigateur ; elles ne constituent ni un inventaire matériel, ni une garantie précise d’autonomie, ni une mesure de la santé de la batterie.
Elles peuvent changer pendant la visite et être absentes, arrondies ou limitées par la politique du navigateur. Considérez-les comme des indications pour la tâche en cours. Une page peut différer une animation facultative ou réduire les actualisations en arrière-plan lorsque l’appareil ne charge pas, mais elle ne doit pas supprimer le contenu nécessaire ni déduire l’identité de la personne.
Une absence de prise en charge est une branche normale
MDN classe Battery Status API parmi les fonctionnalités à disponibilité limitée. Une page de production ne peut donc pas supposer que navigator.getBattery existe ni que sa promesse aboutira. La prise en charge peut varier selon le navigateur, sa version, le contexte et la politique de l’agent utilisateur. Détectez la méthode, gérez le rejet et gardez le même parcours de base en l’absence de valeur.
N’utilisez pas le nom du navigateur à la place de la détection de fonctionnalité. Testez le comportement réellement nécessaire : la page doit rester utilisable si l’API manque, si une valeur change ou si la demande échoue. Le guide des capacités du navigateur applique cette approche de repli à une autre API optionnelle.
Une décision limitée et réversible
Commencez par une expérience de base qui fonctionne sans donnée de batterie. Si une valeur est disponible, choisissez entre quelques politiques, par exemple normale ou avec moins de travail en arrière-plan. Conservez navigation, formulaires, alternatives multimédias et commandes d’accessibilité. Expliquez tout changement important en termes compréhensibles et laissez la personne choisir lorsque le transfert, la qualité ou l’attente sont concernés.
L’état de la batterie ne doit pas piloter l’autorisation, la facturation, la récupération d’un compte ni une requête nécessaire. Le serveur ne doit pas dépendre d’une valeur JavaScript qui peut manquer ou changer entre deux requêtes. Si la personne choisit explicitement un mode d’économie de données ou d’effets réduits, envoyez ce choix plutôt que les champs bruts de batterie.
Limites de confidentialité et minimisation
Les mesures de batterie peuvent contribuer à l’empreinte lorsque d’autres signaux y sont associés. Gardez-les dans la décision qui en a besoin et supprimez les valeurs brutes après le choix de la politique. Par défaut, n’ajoutez pas level, l’état de charge ou les durées aux identifiants de compte, aux URL, aux étiquettes analytiques ou aux dossiers de support conservés longtemps.
Les journaux opérationnels n’ont généralement besoin que de la politique choisie et du résultat, par exemple power_policy=reduced et la réussite d’une tâche facultative. Si un dossier de support exige davantage, expliquez le but, limitez l’accès, fixez une courte durée de conservation et supprimez les champs à sa clôture. Le guide des bases de la confidentialité du navigateur présente d’autres choix de minimisation.
Tester le repli, pas une valeur précise
Les tests doivent couvrir une API indéfinie, le rejet de getBattery(), un changement de level ou charging, et un navigateur qui ne fournit que le parcours de base. Vérifiez que le contenu et les commandes nécessaires restent disponibles, que le travail facultatif peut être annulé et que la personne peut reprendre après un changement. Ne testez pas qu’un appareil donné renvoie un pourcentage ou une durée donnée.
Respectez l’intention et l’accessibilité dans chaque branche. Un mode réduit peut retarder un aperçu ou diminuer la fréquence en arrière-plan, mais il doit préserver le sens de la tâche et proposer une manière claire de continuer. Évitez les boucles de nouvelle tentative et ne demandez pas d’affaiblir un réglage de confidentialité pour activer une amélioration.
L’API décrit l’état observé par ce contexte, et non une garantie du système d’exploitation.
Le navigateur peut renvoyer une valeur un peu ancienne ou réduire sa précision.
Le code doit accepter qu’une valeur change juste après sa lecture.
Le comportement par défaut doit être correct avant le résultat asynchrone.
Une promesse rejetée et une méthode absente signifient que l’amélioration est indisponible.
Ce résultat ne doit pas devenir une alerte qui bloque la page.
Au retour de visibilité du document, une décision courte peut être recalculée.
Il ne faut pas répéter les demandes pour faire apparaître un signal manquant.
Un profil géré, un cadre intégré ou un contexte privé peuvent modifier la disponibilité.
Décrivez le comportement testé sans promettre la prise en charge d’une famille entière de navigateurs.
Si l’aperçu facultatif manque, l’article et ses commandes doivent rester utilisables.
Une opération longue peut proposer une pause ou une qualité réduite.
Conservez les données saisies et rendez la reprise sûre et répétable.
Quand la charge change, réévaluez seulement le travail facultatif concerné.
Ne modifiez pas silencieusement le contenu ou la qualité au milieu d’une interaction.
Les rapports d’erreur et les SDK tiers peuvent aussi copier des champs de batterie.
Les événements sortants doivent utiliser une liste explicite de champs autorisés.
Une politique limitée à un onglet peut rester en mémoire.
Poursuivre l’expérience normale en l’absence de l’API réduit la création d’un historique d’alimentation.
Sources
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.