Summary

  • Connaître l’état de la batterie peut aider une application à espacer les consultations du courrier ou à enregistrer un texte avant l’extinction.
  • Des valeurs très fines de charge et de durée peuvent également distinguer un appareil. Les archives du W3C montrent l’arrivée de ce souci dans le travail de normalisation, puis l’attention portée à la précision, à l’autorisation et aux limites d’accès.

Quand la batterie baisse, une boîte aux lettres qui interroge son serveur toutes les quelques secondes manque de tact. Un éditeur qui sauve le paragraphe avant l’arrêt en a davantage. La proposition du W3C de 2016 donne ces deux exemples. Le navigateur transmet une indication d’énergie ; l’application décide de travailler moins ou de sauver ce qu’elle a déjà fait. La batterie vote pour la première solution, l’auteur pour la seconde.

Au départ, le mécanisme tenait davantage de l’alerte que de l’appel getBattery() connu ensuite. Le premier projet public d’avril 2011 détachait les événements de batterie d’une vaste API d’information système. Il envisageait le branchement, la charge, un niveau de zéro à cent et le temps restant en secondes. Le groupe cherchait encore des usages convaincants pour plusieurs champs. Un exemple se contentait d’inscrire le niveau dans la console. La jauge était sur la table ; le droit de chaque page à lire toutes ses graduations restait à définir.

Une indication assez fine pour gérer les tâches peut aussi décrire la visite. Niveau, état de charge et durée estimée composent un portrait temporaire de l’appareil. Le chiffre bouge, justement : cette trajectoire peut apporter une information supplémentaire. Une page n’a pas besoin d’ouvrir le carnet d’adresses pour apprendre quelque chose de distinctif sur l’ordinateur. L’outil qui devait économiser des ressources offrait une ressource nouvelle à celui qui cherche à reconnaître un visiteur.

La question apparaît noir sur blanc dans un courriel du groupe de travail W3C en juillet 2015. Son président Frederick Hirsch relaie des propositions issues d’une recherche originale : signaler le risque de reconnaissance par lecture très précise, envisager une permission, rendre l’usage de l’API visible. C’est la trace d’une discussion concrète sur l’interface. Elle ne prouve pas que tous les sites ont suivi leurs visiteurs à la jauge ; elle montre que le risque ne pouvait plus être rangé derrière l’étiquette « simple batterie ».

Le texte de mars 2016 conseille aux navigateurs d’éviter une précision excessive, et leur permet de demander un accord ou de brouiller la valeur. navigator.getBattery() fournit alors un BatteryManager : charge en cours, niveau, durée avant charge complète ou épuisement. Si le navigateur ne peut communiquer l’état réel, ses valeurs par défaut ressemblent à une batterie pleine et branchée. Ce faux plein a une fonction : le site ne doit pas dégrader son service parce qu’une information a été retenue. Le voyant vert peut être un rideau tiré devant la machine.

Dans le projet W3C d’octobre 2024, getBattery() est une fonction de contexte sécurisé. La politique de permissions battery autorise par défaut 'self' ; un document privé de ce droit reçoit NotAllowedError. L’avertissement sur la précision demeure, ainsi que les possibilités de demander la permission ou d’obscurcir le résultat. Le navigateur conserve donc une place pour dire « moins exactement » ou « pas ici » quand une page s’approche du cadran.

L’historique des publications W3C va des projets de 2011 aux travaux de 2016, puis aux révisions de 2024. Ces dates racontent la norme, sans donner une date de comportement identique pour tous les navigateurs. Le changement de fond est plus simple : un indice utile à la sobriété devient indiscret lorsqu’il répond avec une précision de laboratoire.

La messagerie peut toujours patienter entre deux vérifications. L’éditeur peut toujours enregistrer le texte. Pour être prévenant, un site n’a pas besoin de chronométrer la dernière respiration de la batterie.