Résumé

  • La continuité d’un service et la permanence d’un identifiant matériel ne sont pas une seule exigence. Une adresse privée peut permettre de reconnaître un retour dans un contexte limité.
  • Le RFC 9724 distingue plusieurs politiques de sélection. Les documentations actuelles d’Apple et d’Android montrent pourquoi « aléatoire » ne signifie ni « différent à chaque connexion » ni « renouvelé au même rythme partout ».
  • La décision utile porte sur le souvenir que le service doit conserver. Elle ne peut être déléguée à un libellé de réglage ou à une ancienne clé de base de données.

La demande paraît raisonnable : éviter qu’une personne doive recommencer son inscription après une courte interruption de Wi-Fi. Elle devient beaucoup plus large lorsqu’on la reformule ainsi : il faut que son appareil fournisse toujours son adresse matérielle. Entre le besoin et la solution, un périmètre a disparu.

Un service peut avoir besoin d’une continuité locale sans avoir besoin d’une reconnaissance identique dans tous les réseaux. C’est précisément l’intérêt d’une adresse privée persistante. Elle permet de poser une question plus exigeante que l’opposition habituelle entre confort et confidentialité : quel souvenir faut-il conserver pour rendre le service attendu ?

Cette question ne suppose pas que toute persistance soit abusive. Elle impose de distinguer une utilité démontrable d’une dépendance héritée. « Notre système fonctionne ainsi » est une explication de l’existant, pas encore une justification de la durée ou de l’étendue de son identification.

La promesse manquante dans le cahier des charges

Une exigence réduite à la prise en charge de la randomisation MAC ne dit pas quand l’adresse changera. Elle ne dit pas non plus ce qui constitue un nouveau contexte : un profil réseau, une autre association, un délai écoulé ou une session définie par l’implémentation. Or ces différences déterminent ce que le service pourra reconnaître.

Le RFC 9724, publié en mars 2025 à titre informatif, propose une nomenclature plutôt qu’un nouveau protocole normatif. Une adresse générée pour l’appareil peut être conservée toute sa vie ; d’autres politiques dépendent du démarrage, du réseau, d’une période ou d’une session. Plusieurs peuvent coexister dans un système. Le mécanisme de génération ne contient donc pas, à lui seul, une promesse d’oubli. RFC 9724

Il faut également éviter de substituer une géographie intuitive au contexte technique. Un réseau n’est pas nécessairement un bâtiment, et le propriétaire d’un lieu n’est pas nécessairement l’opérateur du service. Dire que les adresses diffèrent entre réseaux ne suffit pas à établir qu’elles diffèrent entre toutes les visites ou tous les lieux.

Le cahier des charges utile précise une transition. Le service doit-il reconnaître un retour après une interruption ? Pendant combien de temps ? Quel changement met fin à cette reconnaissance ? Sans ces réponses, deux fournisseurs peuvent satisfaire le même mot tout en livrant des comportements différents.

L’observation d’une adresse inchangée n’est donc pas un verdict. Elle peut être l’effet attendu d’une politique privée persistante. L’observation d’une nouvelle adresse n’est pas davantage la preuve que les anciennes traces sont devenues impossibles à relier.

Un délai n’est pas une coupure programmée

Android fournit un exemple particulièrement éclairant. Sa documentation de référence décrit la randomisation persistante comme le comportement par défaut. Le profil réseau participe à la détermination de l’adresse, notamment par le SSID, le type de sécurité ou le FQDN pour Passpoint. Oublier puis réajouter le même réseau ne suffit pas à produire une nouvelle valeur.

À partir d’Android 12, certains choix d’application ou une configuration optionnelle de réseau ouvert peuvent sélectionner une politique non persistante. Dans le comportement documenté, le renouvellement intervient au début d’une connexion, notamment si le bail DHCP est expiré et si la déconnexion dépasse quatre heures, ou si la valeur a plus de vingt-quatre heures. Sinon, elle peut être réutilisée. Le système ne coupe pas activement le Wi-Fi dans le seul but de renouveler l’adresse. Documentation AOSP

Cette dernière précision change l’interprétation opérationnelle. Une condition d’âge autorisant une nouvelle sélection n’est pas un rendez-vous auquel toute communication doit s’interrompre. Traduire un seuil en panne périodique, sans examiner l’événement qui déclenche l’action, produit un mauvais modèle avant même le premier essai.

Le réglage optionnel relatif aux réseaux ouverts n’est pas activé par défaut. Il serait donc tout aussi imprudent d’affirmer que tous les appareils Android changent d’adresse à chaque connexion ouverte. La description du cadre logiciel ne démontre d’ailleurs pas la conformité de chaque appareil commercialisé. Cette étude n’est pas un test de parc.

Apple présente une autre organisation. À partir d’iOS 18 et des générations correspondantes expressément citées pour ses autres systèmes, sa documentation distingue désactivation, adresse fixe et rotation. Une adresse privée fixe ne tourne pas périodiquement ; ce choix est le défaut documenté pour un nouveau réseau WPA2 ou plus sûr. La rotation, par défaut pour un nouveau réseau faiblement sécurisé ou sans sécurité, utilise un rythme de deux semaines. Des règles distinctes de réinitialisation et d’oubli limitent ce qu’on peut déduire du mot « fixe ». Documentation Apple

Ces modalités ne constituent ni une échelle universelle de confidentialité ni une certification de l’opérateur du réseau. Le mécanisme de sécurité de la liaison peut orienter un défaut logiciel sans révéler ce que l’institution fera des données observées.

La date de l’information est elle-même une condition de lecture. Les essais de systèmes d’exploitation inclus dans le RFC 9724 remontent explicitement à septembre 2021. Ils ne doivent pas être présentés comme un inventaire du comportement des terminaux en 2026. La nomenclature aide à poser les questions ; la documentation actuelle et l’observation répondent à des questions différentes.

La compatibilité n’accorde pas une mémoire illimitée

Le meilleur argument en faveur de la persistance est simple : elle peut préserver une fonction réellement utile. Une préférence retrouvée ou un parcours d’accès qui n’a pas à être recommencé peuvent justifier une continuité dans un contexte défini. Vouloir supprimer toute reconnaissance reviendrait parfois à supprimer le bénéfice recherché.

Mais la durée doit suivre ce bénéfice. Si la fonction n’a besoin que de retrouver un état à l’intérieur d’un service, pourquoi la solution exige-t-elle une valeur commune à des contextes sans rapport ? Si elle a besoin de plusieurs retours, quel événement clôt cette période ? La réponse peut varier entre services sans rendre la politique incohérente.

La tentation consiste à partir de la clé déjà utilisée dans les outils. Une valeur stable simplifie les rapprochements, et toute modification devient alors une menace pour les habitudes de travail. Le coût d’adaptation est réel ; il mérite une estimation. Il ne transforme pas automatiquement l’ancienne dépendance en exigence légitime imposée à tous les clients.

Cela vaut également pour le support. Demander de désactiver une protection afin de rétablir rapidement une fonctionnalité n’est pas toujours une simple intervention technique. Lorsque cette action élargit la reconnaissance possible, elle modifie le compromis de données. Le responsable du service doit pouvoir expliquer ce changement, plutôt que le laisser se généraliser par accumulation de tickets résolus.

Changer une valeur ne supprime pas tous les liens

L’adresse MAC n’est pas l’unique information transmise. Le RFC 7844 expose pourquoi les identifiants DHCP, les adresses IP et les adresses de liaison doivent évoluer de façon coordonnée pour l’objectif de confidentialité. Un identifiant inchangé peut relier les observations que l’autre changement devait séparer. Les profils d’anonymat limitent la divulgation ; ils n’éliminent pas toute empreinte radio ou logicielle. RFC 7844, section 2

Il ne faut pas en déduire que les réglages MAC décrits par Apple ou Android réalisent l’intégralité de ces profils. Les sources consultées ne le prouvent pas. Il ne faut pas non plus conclure qu’une protection partielle est inutile. Réduire un moyen simple de corrélation conserve un intérêt même si d’autres moyens existent.

Une réception sérieuse du service dit donc quel lien a été limité et ce qui reste hors de l’essai. Elle ne promet pas l’invisibilité générale. Elle ne transforme pas non plus un résultat limité en prétexte pour rétablir l’identifiant le plus persistant.

Le véritable objet à gérer est une continuité justifiée. Elle commence quelque part, rend un service précis et doit pouvoir finir. L’aléatoire aide à organiser cette continuité ; il ne prend pas la décision à la place de ceux qui l’exploitent.