iCloud Private Relay laisse fuiter votre véritable adresse IP

Vous avez activé iCloud Private Relay pour une raison précise : empêcher les sites que vous consultez de voir d'où vous vous connectez. C'est toute la promesse. Apple relaie votre trafic Safari à travers deux sauts, de sorte qu'aucune partie prenante — ni votre fournisseur d'accès, ni le site web — ne puisse relier votre identité à votre destination. Pour une catégorie précise de requêtes, cette promesse ne tient pas.

Le 4 août 2026, les chercheurs en sécurité Tommy Mysk et Talal Haj Bakry ont publié des travaux montrant qu'un site web peut obtenir votre véritable adresse IP alors qu'iCloud Private Relay est activé et fonctionne normalement. La couverture médiatique a suivi le 5 août, relayée notamment par MacRumors, 9to5Mac, TechCrunch et The Hacker News. Il existe trois chemins de fuite distincts, sans rapport mécanique les uns avec les autres, et le plus tranchant des trois met en jeu les passkeys — la technologie d'authentification qu'Apple promeut depuis des années comme le remplacement plus sûr des mots de passe.

Cet article détaille ce que Private Relay promet réellement, ce que les chercheurs ont démontré, le fonctionnement de chacune des trois fuites, la manière de tester votre propre Mac et ce qu'il vaut sincèrement la peine de faire. Une précision de périmètre avant toute chose : il s'agit d'une fuite de votre identité réseau, pas de vos contenus de navigation ni de vos comptes. Personne ne lit votre trafic chiffré. Personne n'accède à votre iCloud. Ce qui fuit, c'est une adresse IP, et son importance dépend entièrement de qui vous êtes et de qui vous observe.

Points clés à retenir

• Trois vecteurs distincts, un même résultat. Mysk et Haj Bakry ont démontré que les cérémonies WebAuthn/passkey, le préchargement DNS et WebTransport peuvent chacun exposer votre véritable adresse IP à un site web alors que Private Relay est activé. Ce sont des bugs indépendants qui convergent vers la même défaillance.
• La fuite par passkey ne nécessite pas que vous possédiez une passkey. Les chercheurs ont constaté qu'il suffit qu'un site démarre la cérémonie — les sites qui utilisent les passkeys, ou qui font simplement semblant de les utiliser, peuvent déclencher la requête. Vous n'avez jamais besoin de cliquer sur quoi que ce soit ni de mener une connexion à son terme.
• C'est une fuite d'IP, pas une compromission. Rien du contenu chiffré de votre navigation n'est exposé, aucun compte n'est compromis et aucun CVE n'a été attribué. Ce qui est exposé, c'est l'identité réseau : votre adresse réelle et, dans le cas du DNS, votre véritable résolveur.
• Apple enquête et aucun correctif n'existe aujourd'hui. Apple a déclaré à 404 Media qu'elle examinait le rapport. 9to5Mac a rapporté que le message de statut d'Apple aux chercheurs indiquait qu'elle prévoyait de traiter le problème, avec un correctif visé pour l'automne 2026. MacRumors a décrit le problème comme inscrit dans le fonctionnement même de WebKit.
• Désactiver Private Relay est la mauvaise réaction. La fonction fait toujours un vrai travail face aux observateurs passifs de votre réseau. La montée en gamme raisonnable, si votre modèle de menace le justifie, est un véritable VPN, avec le compromis honnête suivant : vous déplacez votre confiance d'Apple vers un éditeur de VPN.

Ce qu'est réellement iCloud Private Relay, et ce qu'Apple promet

Avant de juger la fuite, il est utile d'être précis sur la promesse qui est mise à mal — car une bonne partie de la confusion autour de cette affaire vient de gens qui attendent de Private Relay quelque chose qui n'a jamais été vendu.

iCloud Private Relay est une fonctionnalité iCloud+, c'est-à-dire qu'elle est fournie avec un forfait de stockage iCloud payant et non avec le système d'exploitation. Le positionnement d'Apple est constant et plutôt étroit : la fonction est conçue pour dissimuler votre adresse IP et votre activité de navigation aux fournisseurs réseau et aux sites que vous visitez. Voilà la promesse. Ce n'est pas « nous allons tout chiffrer sur votre Mac » et ce n'est pas « nous allons vous rendre anonyme ».

La conception à deux sauts

L'architecture est la partie intéressante, et elle est réellement bien pensée. Lorsque Private Relay est actif, une requête émise par Safari ne voyage pas directement vers le serveur de destination. Elle traverse deux proxys successifs.

Le premier saut, le proxy d'entrée (ingress proxy), est exploité par Apple. Apple sait qui vous êtes — vous êtes connecté à un compte iCloud, après tout, et votre appareil s'est connecté depuis un réseau donné. Ce qu'Apple n'obtient pas, c'est la destination. L'adresse du site que vous consultez est chiffrée de telle sorte que le proxy d'entrée ne peut pas la lire.

Le second saut, le proxy de sortie (egress proxy), est exploité par un partenaire tiers de diffusion de contenu, et non par Apple. C'est ce proxy qui dialogue effectivement avec le site de destination. Il sait où vous allez. Il ne sait pas qui vous êtes, car il n'a jamais vu votre adresse IP d'origine ni votre identité iCloud — il a reçu la requête du proxy d'entrée d'Apple.

Le résultat est une séparation délibérée des connaissances. Aucune des deux parties ne détient les deux moitiés du couple sensible. Apple sait qui, mais pas où. Le partenaire sait où, mais pas qui. Le site en bout de chaîne voit l'adresse du proxy de sortie, pas la vôtre, et Apple propose en plus un réglage de localisation approximative pour que l'adresse vue par le site corresponde tout de même grossièrement à votre région — utile pour les résultats de recherche locaux et l'actualité, sans vous localiser précisément.

C'est une meilleure conception qu'on ne le dit généralement, et elle ne vous coûte pratiquement rien de plus si vous payez déjà pour du stockage iCloud. Si vous voulez un panorama plus large de la façon dont cette fonction s'inscrit parmi les autres protections de la plateforme, notre guide complet de sécurité et de confidentialité macOS Tahoe couvre les fonctionnalités environnantes.

Le cadrage essentiel : ce n'est pas un VPN

Voici le point qui compte pour comprendre la fuite. Private Relay n'est pas un VPN et Apple ne l'a jamais présenté comme tel.

Un VPN, lorsqu'il est correctement configuré, capture le trafic au niveau de la couche réseau. Chaque application de la machine, chaque protocole, chaque socket — tout passe par le tunnel parce que la table de routage du système d'exploitation l'y envoie. C'est pour cela que les VPN sont lourds, qu'ils cassent des choses et qu'ils ont parfois besoin d'une extension noyau ou d'une extension réseau système pour fonctionner.

Private Relay opère dans un périmètre bien plus étroit. Il couvre :

• Le trafic de navigation Safari. C'est le cas d'usage phare.
• La résolution DNS. Vos requêtes DNS sont censées passer par le relais afin que votre résolveur ne devienne pas un journal de tous les endroits où vous êtes allé.
• Une portion du trafic applicatif non chiffré. Les requêtes HTTP non sécurisées émises par des applications sont ramenées dans le relais, à titre de durcissement.

Voilà le périmètre. Le trafic de Chrome n'y passe pas. Le trafic de votre client de messagerie n'y passe pas. Le trafic chiffré des applications tierces n'y passe pas. Si une application ouvre sa propre connexion avec sa propre pile réseau, Private Relay n'est pas sur ce chemin et n'a jamais prétendu l'être.

Cette distinction n'est pas un détail technique — c'est tout le cadre d'évaluation des nouvelles découvertes. Deux des trois fuites trouvées par les chercheurs sont, à un certain niveau, des cas de requêtes qui s'échappent du périmètre tracé par Private Relay. Le bug n'est pas que ce périmètre existe. Le bug est que des requêtes issues de ce que l'utilisateur vit comme « naviguer dans Safari » se retrouvent en dehors, de manière invisible, sans aucun signal indiquant que quelque chose a quitté le tunnel.

Ce que les chercheurs ont trouvé

Tommy Mysk et Talal Haj Bakry ne sont pas des débutants en la matière. Ils ont un long historique de démontage des promesses de confidentialité sur les plateformes Apple — constatant souvent que l'écart entre le discours marketing et l'implémentation est plus large que quiconque ne l'imaginait. Leur méthode est constante : construire une démonstration, la publier, et laisser l'artefact porter l'argument plutôt qu'un communiqué de presse.

Leurs travaux sur Private Relay sont datés du 4 août 2026. La couverture médiatique est apparue le lendemain, le 5 août, chez MacRumors, 9to5Mac, TechCrunch et The Hacker News, entre autres.

L'affirmation centrale, en clair : un site web peut obtenir votre véritable adresse IP même lorsqu'iCloud Private Relay est activé. Pas via un canal auxiliaire exotique nécessitant que vous soyez d'abord attaqué, ni en exploitant une mauvaise configuration de votre côté. Via des fonctionnalités ordinaires de la plateforme web que n'importe quel site peut invoquer.

Les trois vecteurs sont :

1. WebAuthn / passkeys. La requête réseau émise lors d'une connexion par passkey est déclenchée par le service d'identifiants du système d'exploitation, et non par Safari : elle n'entre donc jamais dans le chemin relayé.
2. Le préchargement DNS. Une fonctionnalité de performance ajoutée à la génération OS 26, qui révèle le véritable résolveur DNS de l'utilisateur.
3. WebTransport. Une API de transport plus récente, ajoutée à la génération 26.4, capable d'ouvrir une connexion HTTP/3 directe qui contourne le proxy.

L'exposition concerne Safari et la navigation basée sur WebKit. Sur iOS, où la plupart des juridictions imposent encore à tous les navigateurs d'utiliser WebKit sous le capot, cela signifie que les navigateurs alternatifs sont également touchés — passer de Safari à un autre navigateur iPhone ne change pas le moteur qui fait le travail. Sur Mac, la situation est différente : l'exposition se concentre sur Safari et sur les applications qui intègrent WebKit pour leur navigation interne, tandis que les navigateurs non-WebKit comme Chrome et Firefox utilisent leurs propres moteurs et leurs propres piles réseau. C'est une différence significative pour les utilisateurs de Mac, et nous reviendrons sur ce que cela vous apporte — et ne vous apporte pas.

La réponse d'Apple, telle que rapportée : l'entreprise a déclaré à 404 Media qu'elle enquêtait sur le rapport. 9to5Mac a indiqué que le message de statut d'Apple aux chercheurs signalait qu'elle prévoyait de traiter le problème signalé, avec un correctif visé pour l'automne 2026. C'est l'étendue de ce qui a été publiquement attribué à Apple. Aucune version précise n'a été nommée, aucune date de livraison n'a été confirmée publiquement par Apple, et aucun CVE n'a été attribué à l'un des trois vecteurs.

Aucun correctif n'existe aujourd'hui. MacRumors a décrit le problème comme inscrit dans le fonctionnement même de WebKit — ce qui est une manière juste de caractériser une catégorie de bug dont la correction n'est pas un patch sur une fonction, mais une refonte de la question de savoir quel sous-système possède une requête réseau.

Le vecteur passkey, expliqué comme il faut

Des trois, c'est celui qui mérite d'être compris en détail. C'est le plus surprenant, le plus difficile à éviter, et celui dont l'implication est la plus inconfortable.

Ce qu'est réellement une cérémonie WebAuthn

Les passkeys reposent sur WebAuthn, un standard web d'authentification à clé publique. Le modèle mental que la plupart des gens ont est à peu près juste : au lieu d'envoyer un mot de passe à un serveur, votre appareil détient une clé privée, le serveur détient la clé publique correspondante, et se connecter revient à prouver que vous contrôlez la clé privée en signant un défi. Rien de réutilisable ne transite sur le réseau. Hameçonner une passkey ne fonctionne pas comme hameçonner un mot de passe, car la signature est liée à l'origine.

La séquence d'étapes qui accomplit cela s'appelle une cérémonie. Le JavaScript du site appelle le navigateur, le navigateur demande à la plateforme de produire ou de vérifier un identifiant, vous vous authentifiez localement avec Touch ID ou le code de votre appareil, et une assertion signée revient. Sur les plateformes Apple, l'identifiant lui-même réside dans l'app Passwords et se synchronise via iCloud Keychain. Si vous voulez le contexte plus large de ce qu'Apple construit de ce côté, nous l'avons examiné dans notre article sur l'app Passwords et le changement automatique de mot de passe.

Ce à quoi presque personne ne pense, c'est qu'une cérémonie n'est pas purement locale. Une partie implique de récupérer des données sur le réseau — la configuration de la partie utilisatrice (relying party), les données d'association qui lient le domaine d'un site aux identifiants autorisés à le servir. Quelque chose doit émettre une requête HTTPS pour obtenir cela.

Qui émet la requête

C'est ici que cela dérape. Pour citer ce qui a été rapporté de l'explication des chercheurs :

WebKit confie les cérémonies WebAuthn au service d'identifiants du système d'exploitation, qui émet lui-même la requête HTTPS, directement depuis l'appareil et sans avoir connaissance du proxy configuré par l'application hôte.

Lisez attentivement, car chaque proposition compte. WebKit n'exécute pas la cérémonie lui-même ; il la délègue à un service système qui détient les identifiants. Ce service émet ensuite sa propre requête HTTPS sortante. Et surtout, il est sans connaissance du proxy configuré par l'application hôte — le service d'identifiants ne sait pas et ne se soucie pas du fait que Safari a été configuré pour router son trafic par le chemin à deux sauts de Private Relay. C'est un processus différent, avec une configuration réseau différente, qui fait ce pour quoi il a été conçu.

La conséquence, toujours selon ce qui a été rapporté :

Parce que la requête est émise par le service d'identifiants du système d'exploitation plutôt que par Safari, elle n'entre jamais dans le chemin relayé de Private Relay.

La requête part donc directement de votre appareil, depuis votre véritable adresse IP, vers un serveur contrôlé par le site web. Le site voit la connexion. Il journalise l'adresse. Private Relay tournait pendant tout ce temps et n'était simplement pas sur ce chemin.

D'un point de vue architectural, on comprend comment cela a pu arriver sans négligence de personne. La gestion des identifiants devrait être isolée du navigateur — cette séparation est une propriété de sécurité, pas une erreur. Garder le matériel cryptographique hors d'un processus qui exécute du JavaScript non fiable provenant de sites arbitraires est exactement la bonne approche. Le problème est que l'isolation a été tracée pour la sécurité et que personne n'a redessiné la frontière de confidentialité pour qu'elle corresponde. Le service d'identifiants a hérité de l'isolation de processus mais pas de la configuration du proxy.

Le point le plus tranchant : vous n'avez pas besoin d'avoir une passkey

Voici le détail qui transforme cela d'une curiosité architecturale en véritable problème de confidentialité.

Les chercheurs notent que cela se déclenche sur les sites qui utilisent les passkeys ou font simplement semblant de les utiliser. Un site peut déclencher la cérémonie sans que vous meniez aucune connexion à son terme. Vous n'avez pas besoin d'avoir une passkey pour ce site. Vous n'avez même pas besoin d'y avoir un compte. Vous n'avez pas besoin de cliquer sur un bouton de connexion, d'approuver une invite Touch ID ni d'interagir avec quoi que ce soit.

Une page peut invoquer l'API et la requête réseau part. Que la cérémonie finisse par réussir, échouer ou être abandonnée n'a aucune importance pour la fuite, car la fuite se produit au moment de la requête, avant que la moindre logique d'authentification n'entre en jeu.

Cela inverse le sens de la fonctionnalité. WebAuthn existe pour rendre l'authentification plus sûre. Dans cette configuration, la simple invocation de la machinerie d'authentification devient un déclencheur de désanonymisation que n'importe quelle page peut actionner, silencieusement, au chargement. Un traqueur n'a besoin de compromettre quoi que ce soit. Il lui suffit d'inclure un fragment de code qui démarre une cérémonie que personne ne terminera jamais, et il récolte l'IP réelle de chaque utilisateur de Private Relay qui charge la page.

Aucun signal visible par l'utilisateur n'accompagne cela. Pas d'invite, pas de feuille d'autorisation, pas d'indicateur dans la barre d'outils. L'hypothèse de conception était que démarrer une cérémonie d'identifiants est un acte bénin, et dans des circonstances normales c'est le cas.

Le vecteur du préchargement DNS

La deuxième fuite a un impact moindre mais elle est instructive, car elle montre le même schéma sous-jacent dans un sous-système complètement différent.

À quoi sert le préchargement

Charger une page web est une chaîne de résolutions dépendantes. Le navigateur récupère le HTML, découvre qu'il référence une feuille de style sur un domaine, une police sur un deuxième, un script d'analytics sur un troisième et des images sur un quatrième. Chacun de ces domaines nécessite une résolution DNS avant même qu'une connexion puisse commencer, et la résolution DNS prend du temps — quelques dizaines de millisecondes quand tout va bien, considérablement plus sur une mauvaise connexion mobile.

Le préchargement DNS est une optimisation simple pour cela. Pendant que le navigateur analyse encore la page, il regarde en avant les liens et ressources référencés et résout ces noms d'hôte à l'avance. Quand l'analyseur arrive au point où une connexion est réellement nécessaire, l'adresse est déjà en cache et la connexion démarre immédiatement. C'est le genre de changement qui se traduit par une amélioration réelle des métriques de chargement de page, ce qui explique précisément pourquoi les ingénieurs de navigateurs continuent d'ajouter ce type de fonctionnalité.

Cette implémentation particulière est arrivée avec la génération OS 26 — les versions de l'ère Tahoe sur l'ensemble des plateformes Apple.

Ce qu'il expose

Les chercheurs ont constaté que ces requêtes de préchargement révèlent le véritable résolveur DNS de l'utilisateur.

En fonctionnement normal de Private Relay, le DNS est censé faire partie de ce que couvre le relais. C'est délibéré et important : si vos requêtes partaient en clair vers le résolveur de votre FAI, celui-ci détiendrait une liste horodatée de chaque domaine consulté, soit un historique de navigation quasi complet, quelle que soit la qualité du chiffrement du trafic lui-même. Private Relay existe en grande partie pour briser exactement ce lien.

Lorsque les requêtes de préchargement s'échappent de ce chemin, elles partent vers le résolveur que votre appareil est effectivement configuré à utiliser — généralement celui fourni par DHCP sur votre réseau actuel, ce qui signifie le plus souvent votre FAI, votre employeur, ou l'exploitant du Wi-Fi sur lequel vous êtes.

Ce qui fuit ici est plus étroit qu'une adresse IP brute. Un observateur apprend quel résolveur vous utilisez, ce qui est un signal fort sur le réseau où vous êtes et souvent sur le fournisseur qui vous dessert. Combiné à d'autres signaux, cela contribue à une empreinte. Cela signifie également que l'exploitant du résolveur voit des résolutions qui étaient censées lui être masquées.

C'est un problème plus petit que le vecteur passkey et il produit un signal plus grossier. Ce n'est pas rien pour autant. Si vous vous êtes déjà battu avec le comportement DNS de macOS en faisant tourner un tunnel, une partie de tout ceci vous semblera familière — l'interaction entre les résolveurs système et le trafic relayé est une source persistante de confusion, et notre guide de dépannage VPN sur macOS couvre la forme générale de ces problèmes.

Le vecteur WebTransport

La troisième fuite met en jeu la plus récente des trois technologies, et c'est l'illustration la plus nette du problème structurel.

À quoi sert WebTransport

WebTransport est une API web moderne de communication bidirectionnelle à faible latence entre un navigateur et un serveur. Voyez-la comme le successeur des WebSockets, bâtie sur HTTP/3 et QUIC plutôt que sur TCP.

Sa raison d'être est qu'une catégorie significative d'applications web a besoin de mieux que du requête/réponse. Les jeux multijoueurs doivent pousser de l'état en permanence et tolèrent mieux une mise à jour perdue de temps en temps qu'un délai. Les applications vidéo et audio en direct ont le même besoin. Les éditeurs collaboratifs, les outils de bureau à distance, les tableaux de bord de télémétrie en temps réel — tous veulent un canal persistant à faible surcharge, avec la possibilité d'envoyer des datagrammes non fiables quand la fiabilité ne vaut pas son coût en latence.

WebTransport apporte cela en s'appuyant sur QUIC, un transport basé sur UDP avec chiffrement intégré et sans blocage de tête de ligne entre flux. C'est de la très bonne ingénierie pour le problème qu'elle résout.

L'implémentation d'Apple est arrivée avec la génération 26.4.

Pourquoi une connexion HTTP/3 directe met le proxy en échec

Le proxying de Private Relay est construit autour du trafic web conventionnel — les schémas de requêtes que produit le chemin réseau normal de Safari. Ceux-là passent par la chaîne à deux sauts entrée/sortie.

Les chercheurs ont constaté que WebTransport peut ouvrir une connexion HTTP/3 directe qui contourne le proxy. Une fois cette connexion établie directement de l'appareil au serveur de destination, le serveur voit l'adresse réelle de l'appareil, exactement comme pour n'importe quelle connexion non relayée.

Le schéma est ici identique au cas des passkeys, alors même que le code impliqué est totalement indépendant. Une nouvelle capacité a été ajoutée à la plateforme. Cette capacité ouvre des connexions réseau. La couche de proxying a été bâtie avec un modèle de ce que signifie « connexion réseau » qui précède la nouvelle capacité. Rien ne relie les deux, et la nouvelle capacité opère discrètement en dehors du périmètre.

C'est pourquoi le cadrage de MacRumors — le problème est inscrit dans le fonctionnement même de WebKit — dépasse la simple rhétorique. L'évolution du moteur ne cesse d'ajouter des sous-systèmes capables de parler au réseau. À moins que la frontière du proxy ne soit appliquée à un niveau que tous doivent traverser, chaque nouveau sous-système est un candidat au même bug. Corriger trois fuites spécifiques n'empêche pas, en soi, l'apparition d'une quatrième.

Comment tester votre propre Mac

Les chercheurs ont construit un outil de test public, ce qui est la chose la plus utile de cette divulgation du point de vue du lecteur. Vous n'avez à croire personne sur parole.

L'outil se trouve à l'adresse https://leaks.psylo.app/.

Exécuter le test

1. Confirmez d'abord que Private Relay est activé. Inutile de tester la fuite si le relais ne tourne pas. Ouvrez Réglages Système, cliquez sur votre compte Apple en haut de la barre latérale, sélectionnez iCloud, puis Private Relay, et confirmez que la fonction est activée. Passez directement à la section sur la vérification de l'état de Private Relay si vous avez un doute — la fonction se désactive plus souvent que la plupart des gens ne le réalisent.
2. Notez à quoi devrait ressembler votre IP relayée. N'importe quel service du type « quelle est mon IP », chargé dans Safari avec le relais actif, vous affichera une adresse appartenant au partenaire de sortie d'Apple plutôt que la vôtre. C'est votre référence : l'adresse qu'un site est censé voir.
3. Visitez la page de test dans Safari. Utilisez Safari spécifiquement, puisque les vecteurs sont propres à WebKit sur macOS. L'outil exécute ses vérifications et rapporte ce qu'il a pu observer de votre connexion.
4. Comparez les résultats. Un résultat propre signifie que les adresses observées par l'outil via chaque vecteur testé correspondent à votre adresse relayée — le proxy a tenu. Un résultat fuyant signifie qu'au moins un vecteur a fait surgir une adresse qui n'est pas celle du relais, et cette adresse est la vôtre.
5. Testez sur chaque réseau qui compte pour vous. Les résultats peuvent différer entre votre réseau domestique, un réseau d'entreprise et un Wi-Fi public, notamment parce que la disponibilité même de Private Relay varie d'un réseau à l'autre.

La mise en garde honnête

Un outil de test vous renseigne sur les vecteurs qu'il implémente. Il ne vous renseigne pas sur tous les vecteurs possibles.

Cela compte plus que l'avertissement d'usage habituel, à cause du point structurel évoqué plus haut. Si le problème de fond est que de nouveaux sous-systèmes WebKit peuvent ouvrir des connexions réseau hors de la frontière du proxy, alors l'ensemble des vecteurs n'est pas figé — c'est simplement ce qui a été découvert jusqu'ici. Un résultat propre sur un outil qui vérifie trois choses signifie que ces trois choses n'ont pas fui lors de ce test, sur ce réseau, à cet instant. C'est nettement mieux que de ne pas savoir. Ce n'est pas un certificat d'anonymat.

Traitez ce test comme n'importe quel résultat de sécurité négatif : comme l'absence de preuve pour un ensemble précis de problèmes, non comme une preuve d'absence en général.

Ce que vous pouvez réellement faire dès maintenant

Il n'y a aucun correctif à installer. Ce qui suit est classé approximativement par utilité réelle, et chaque point indique ce qu'il vous coûte, car une mesure d'atténuation dont le compromis n'est pas énoncé relève de l'argumentaire commercial plutôt que du conseil.

1. Utilisez un vrai VPN si votre modèle de menace le justifie

C'est la mesure d'atténuation rapportée par la presse, et la seule option de cette liste qui traite le problème à la bonne couche. Un VPN correctement configuré capture le trafic au niveau réseau, en dessous du point où opèrent ces trois vecteurs. La requête HTTPS du service d'identifiants, la requête DNS de préchargement et la connexion QUIC de WebTransport passent toutes par la pile réseau du système d'exploitation, et un VPN au niveau système se place sous l'ensemble.

Le compromis est réel et vous devriez le formuler à voix haute avant d'agir : vous déplacez votre confiance d'Apple vers un éditeur de VPN. La conception à deux sauts de Private Relay est spécifiquement construite pour qu'aucune partie ne voie à la fois votre identité et vos destinations. Un VPN classique à saut unique n'a pas cette propriété. Votre fournisseur de VPN voit les deux. Vous pariez sur sa politique de journalisation, sa juridiction, sa sécurité opérationnelle et son honnêteté, et contrairement à l'architecture d'Apple, ce pari n'est pas garanti par la conception — il est garanti par une promesse dans une politique de confidentialité.

Ce n'est pas un argument contre les VPN. C'est un argument pour en choisir un délibérément : audité de façon indépendante, clair sur sa juridiction, avec un modèle économique qui ne dépend pas de vos données. Si vous prenez cette voie, attendez-vous à passer un moment sur des bizarreries de configuration ; notre guide de dépannage VPN sur macOS couvre les modes de défaillance qui piègent les gens spécifiquement sur macOS.

2. Ne désactivez pas Private Relay

C'est le réflexe le plus courant, et il est à l'envers.

Private Relay fait toujours un vrai travail face aux observateurs passifs. Votre FAI ne peut toujours pas construire un journal de navigation à partir de vos requêtes DNS pour tout ce qui passe effectivement par le relais. L'exploitant du Wi-Fi du café ne peut toujours pas observer les sites que vous visitez. La grande majorité de votre trafic Safari est toujours relayée et masque toujours votre adresse aux sites que vous consultez. Les fuites sont des chemins spécifiques qui s'échappent, et elles exigent que le site tente activement quelque chose — une page doit invoquer une cérémonie passkey, ou utiliser WebTransport, ou déclencher un comportement de préchargement.

Désactiver le relais ne referme aucune de ces fuites. Cela ne fait que réintroduire toute l'exposition que le relais évitait avec succès. Vous vous retrouvez avec strictement moins de confidentialité qu'avant, en échange de rien.

3. Soyez délibéré sur les sites auxquels vous laissez démarrer une cérémonie

Ce conseil est plus faible qu'il n'en a l'air, et il vaut la peine d'être honnête sur les raisons.

Le vecteur passkey se déclenche sans interaction. Vous ne pouvez pas refuser une cérémonie dont on ne vous a jamais parlé. Il n'y a donc aucun réglage à basculer et aucune invite à refuser.

Ce qu'il vous reste, c'est le contrôle sur les pages que vous chargez tout court. Si vous faites quelque chose où l'exposition de votre IP compte réellement, ayez conscience que toute page ouverte — y compris celle sur laquelle vous atterrissez depuis un lien, y compris une vue de navigateur intégrée dans une app — est une page susceptible d'invoquer le vecteur. Cela plaide pour le cloisonnement : effectuez la navigation sensible dans un environnement délibérément choisi plutôt que dans la même session que tout le reste. Cela ne plaide pas pour une liste de sites à éviter, car les sites qui exploiteraient cela ne sont pas de ceux qui s'annoncent.

4. Comprenez ce que le mode Isolement fait — et ne fait pas — ici

Le mode Isolement (Lockdown Mode) est le réglage de protection extrême d'Apple pour les utilisateurs exposés à des attaques ciblées. Il désactive une longue liste de technologies web, dont la compilation JavaScript à la volée et diverses fonctionnalités complexes, sur le principe qu'une surface d'attaque que vous n'avez pas ne peut pas être exploitée.

Il mérite d'être envisagé si vous appartenez à la population pour laquelle il a été conçu, puisque toute son approche consiste à retirer des fonctionnalités plutôt qu'à corriger des bugs précis, et une fonctionnalité retirée ne peut pas fuiter. Mais soyez prudent dans le raisonnement : le mode Isolement est une posture de durcissement, pas un correctif ciblé pour ces trois vecteurs, et aucun article de presse ne le présente comme un remède à ce problème. Considérez-le comme une chose raisonnable à évaluer si vous en êtes déjà un candidat, pas comme la réponse à ce problème précis. Il casse aussi une grande partie de la navigation web ordinaire, ce qui est voulu et explique pourquoi Apple ne le recommande pas pour un usage général.

5. Sachez ce que change le changement de navigateur — et où cela ne change rien

La plateforme compte, ici.

Sur iOS, changer de navigateur n'aide pas. La plupart des juridictions imposent encore à tout navigateur d'utiliser WebKit comme moteur : le navigateur alternatif que vous installez n'est donc qu'une interface différente sur le même moteur, avec les mêmes vecteurs. Chrome sur iPhone n'est pas le moteur de Chrome.

Sur Mac, la situation diffère réellement. Les navigateurs non-WebKit utilisent leurs propres moteurs et leurs propres piles réseau : ils se comportent donc différemment vis-à-vis de ces vecteurs spécifiques issus de WebKit. Mais notez bien ce que cela vous apporte et ce que cela ne vous apporte pas : Private Relay ne relaie de toute façon pas le trafic des navigateurs autres que Safari. Passer à Chrome ou Firefox sur macOS ne vous place pas derrière le relais — cela vous en fait sortir entièrement. Vous n'avez pas corrigé une fuite ; vous avez renoncé à la protection. Ce n'est une amélioration que si vous l'associez à un VPN qui couvre tout. Si vous passez l'essentiel de votre temps dans Safari et voulez en tirer davantage, notre guide Safari pour utilisateurs avancés mérite mieux votre attention qu'une migration de navigateur entreprise pour la mauvaise raison.

Ne vous promettez pas trop avec tout ceci. Les options 2 à 5 réduisent l'exposition ou évitent d'aggraver les choses. Seule l'option 1 traite les vecteurs à la couche où ils opèrent, et elle le fait en substituant une relation de confiance à une autre.

Qui devrait réellement s'en préoccuper

Les histoires de vie privée récompensent l'hystérie et punissent le sens des proportions ; soyons donc précis sur qui est concerné et dans quelle mesure.

Pour la plupart des gens, c'est une érosion, pas une urgence

Si vous êtes un utilisateur ordinaire avec un modèle de menace ordinaire, voici l'évaluation honnête : une fonctionnalité que vous payez en fait moins que promis dans des circonstances précises, ce qui est agaçant et mérite qu'Apple corrige, et la conséquence pratique pour vous est proche de zéro.

Regardez ce qui fuit réellement. Votre adresse IP, vers un site qui est délibérément allé la chercher. La plupart des sites disposent déjà d'identifiants bien meilleurs vous concernant — vous êtes connecté, vous avez des cookies, vous avez une empreinte de navigateur considérablement plus distinctive qu'une adresse IP qui change quand vous passez d'un réseau à l'autre. Pour l'écosystème publicitaire, une adresse IP est un signal d'appoint, pas le joyau de la couronne. Les entreprises qui exploitent cela, s'il y en a, sont celles qui vous pistent déjà de façon exhaustive par des moyens que Private Relay n'allait de toute façon jamais arrêter.

Ce que vous perdez, c'est une couche de défense en profondeur que vous aviez de bonnes raisons de croire présente. C'est une réclamation légitime. Ce n'est pas une raison de changer votre façon de vivre.

Qui doit agir

Les personnes qui doivent prendre cela au sérieux sont celles dont le modèle de menace inclut réellement la désanonymisation par adresse IP. Concrètement :

• Les journalistes travaillant avec des sources, lorsque le lien entre un reporter et un lieu ou un réseau est lui-même une information sensible.
• Les militants et organisateurs dans des environnements où une adresse réseau correspond à une identité réelle porteuse de risque.
• Les personnes cherchant à échapper à un individu précis — un harceleur, un ex-partenaire violent, quelqu'un ayant les moyens techniques et la motivation d'exploiter un site ou un lien et de lire ce qui s'y connecte. C'est le cas où une adresse IP est réellement dangereuse, car elle peut approcher une localisation et confirmer qu'une personne donnée a consulté un lien donné.
• Les personnes dont l'employeur ou l'institution ne devrait pas savoir ce qu'elles recherchent, en particulier sur un réseau contrôlé par cette institution.

Si vous appartenez à l'un de ces groupes, la posture correcte n'a jamais été Private Relay seul. C'était un VPN bien choisi ou Tor, un cloisonnement approprié, et l'hypothèse que toute fonctionnalité de confort peut échouer. Cette divulgation est un rappel de ce principe plutôt qu'un changement de celui-ci. Notre guide de sécurité et de confidentialité sur Mac approfondit la construction d'un dispositif en couches, et si vous réfléchissez à réduire votre exposition plus largement, faire tourner les outils d'IA en local plutôt que dans le cloud applique le même raisonnement à une autre partie de la pile.

Le terrain intermédiaire

Entre « cela ne vous concerne pas » et « votre sécurité en dépend » se trouve tout le monde, et la posture raisonnable y est le calibrage plutôt que l'action. Comprenez que la couverture de Private Relay est plus étroite que le modèle mental que la plupart des gens ont. Cessez de le traiter comme un VPN, car il n'en est pas un et vous disposez désormais d'une démonstration concrète de la différence. Gardez-le activé, puisqu'il aide toujours contre les observateurs pour lesquels il a été conçu. Et si vous vous retrouvez à faire quelque chose où être identifié compterait vraiment, saisissez un outil conçu pour ce travail plutôt que de vous en remettre à celui qui se trouve déjà activé.

Comment vérifier si Private Relay est seulement actif

Il y a de fortes chances que Private Relay soit actuellement désactivé sur au moins un réseau que vous utilisez, sans que vous en ayez la moindre idée. La fonction se désactive d'elle-même dans plusieurs situations, sans grand cérémonial : avant de s'inquiéter des fuites, il vaut donc la peine de confirmer que le relais tourne tout court.

Le réglage principal

Sur un Mac :

1. Ouvrez Réglages Système.
2. Cliquez sur votre compte Apple en haut de la barre latérale.
3. Sélectionnez iCloud.
4. Trouvez Private Relay dans la liste et ouvrez-le.
5. Confirmez que l'interrupteur est activé. Pendant que vous y êtes, vérifiez le réglage Localisation de l'adresse IP — « Conserver la localisation générale » maintient le fonctionnement des contenus régionaux, tandis que « Utiliser le pays et le fuseau horaire » élargit davantage votre localisation apparente.

Si vous ne voyez pas Private Relay du tout, l'explication habituelle est que vous n'êtes pas sur un forfait iCloud+ payant. C'est une fonctionnalité iCloud+ et elle n'apparaît pas sur le palier de stockage gratuit.

L'interrupteur par réseau que presque personne ne connaît

Celui-ci piège les gens en permanence. Private Relay possède un état activé/désactivé distinct pour chaque réseau Wi-Fi individuel, indépendant du réglage global.

Pour le vérifier : ouvrez Réglages Système, allez dans Wi-Fi, cliquez sur Détails à côté de votre réseau connecté, et cherchez-y l'option Private Relay. Elle peut être désactivée pour ce réseau précis alors que le réglage global est activé.

C'est un comportement réellement utile — c'est ainsi que l'on garde le relais actif en général tout en le désactivant pour l'unique réseau d'entreprise qui casse sans cela — mais cela signifie que « j'ai activé Private Relay » et « Private Relay tourne en ce moment » sont deux affirmations différentes. Vérifiez le réglage par réseau sur tout réseau où un test donne des résultats inattendus.

Les manières dont il se désactive silencieusement

Au-delà des deux interrupteurs, plusieurs conditions désactivent le relais sans avertissement bien visible :

• Réseaux non pris en charge. Certains réseaux bloquent les protocoles ou les points de terminaison dont Private Relay dépend. Dans ce cas, macOS propose généralement de choisir entre utiliser le réseau sans le relais ou ne pas se connecter, et le choix fait à ce moment-là persiste.
• Réseaux d'entreprise et gérés. Les entreprises désactivent fréquemment Private Relay de façon délibérée, car un proxy qui masque les adresses de destination est fondamentalement incompatible avec le filtrage et la surveillance de contenu au niveau réseau. Les appareils gérés peuvent l'avoir désactivé par profil de configuration, sans aucun interrupteur accessible à l'utilisateur.
• Restrictions de pays et de région. Private Relay n'est pas disponible partout. Apple a confirmé son indisponibilité dans un certain nombre de juridictions, et dans ces régions la fonctionnalité ne tourne tout simplement pas, quels que soient vos réglages.
• Configurations des opérateurs mobiles. Certains opérateurs ont livré des configurations qui la désactivent sur leurs réseaux.
• Configuration VPN ou DNS conflictuelle. Faire tourner un VPN système signifie généralement que Private Relay se met en retrait, puisque le VPN prend le trafic en premier. Des réglages DNS personnalisés et certains profils de filtrage DNS peuvent également le désactiver.

Le fil conducteur est que Private Relay échoue en silence plutôt que bruyamment. Il cesse de fonctionner et vous continuez à naviguer. C'est un choix de conception défendable pour une fonctionnalité de confort — l'alternative étant de casser l'accès Internet des gens — mais cela implique que la vérification périodique est le seul moyen de connaître votre état réel.

À quoi devrait ressembler un correctif

Il vaut la peine de réfléchir à ce qu'Apple doit réellement construire ici, car cela explique pourquoi le calendrier annoncé se compte en mois plutôt qu'en mise à jour mineure.

Le correctif superficiel consiste à traiter chaque vecteur individuellement. Rendre le service d'identifiants conscient de la configuration de proxy de l'application hôte et router ses requêtes de cérémonie en conséquence. Ramener les requêtes DNS de préchargement dans le chemin DNS du relais. Router les connexions QUIC de WebTransport par la chaîne de proxys, ou refuser de les établir directement quand le relais est actif. Trois modifications ciblées, trois trous refermés.

Cela corrigerait les problèmes signalés et ne corrigerait pas la condition sous-jacente. Le schéma est le même dans les trois cas : un sous-système capable d'atteindre le réseau a été construit sans hériter de la frontière du proxy. Cela continuera de se produire tant que cette frontière sera quelque chose auquel chaque sous-système doit adhérer volontairement plutôt que quelque chose d'imposé en dessous de tous.

Le correctif plus profond est architectural — imposer le relais à une couche que tout chemin réseau adjacent à WebKit doit traverser, de sorte qu'une nouvelle capacité ne puisse pas le contourner par simple ignorance. C'est un changement de grande ampleur, avec un risque réel de casse, et c'est le genre de travail qui atterrit dans une version majeure plutôt que dans une mise à jour de sécurité. Il faudrait aussi une politique claire sur le sort des requêtes qui ne peuvent véritablement pas être relayées : échouer fermé et casser la fonctionnalité, ou échouer ouvert et fuiter. Aucune des deux réponses n'est confortable, et en choisir une relève d'une décision produit autant que d'ingénierie.

Un troisième volet, sans doute le plus précieux, est visible par l'utilisateur : un signal quelconque lorsqu'une requête échappe au relais. Aujourd'hui, la fonctionnalité est entièrement muette sur sa propre couverture. Vous ne pouvez pas savoir si la page sur laquelle vous êtes a été entièrement relayée, partiellement relayée, ou pas du tout. Cette opacité est ce qui a transformé trois lacunes d'implémentation en une histoire de promesse rompue, car les utilisateurs n'avaient aucun moyen d'observer la différence entre « ça marche » et « ça ne marche pas ».

Ce qu'il faudra surveiller dans les versions de l'automne 2026

D'après ce que 9to5Mac rapporte du message de statut d'Apple aux chercheurs, un correctif est visé pour l'automne 2026. C'est ce qui a été rapporté — Apple ne s'est pas engagée publiquement sur une version ou une date précise, et vous ne devriez pas le prendre pour une garantie.

Si et quand quelque chose sort, voici ce qu'il vaudra la peine de vérifier :

• Si les trois vecteurs sont traités ou seulement celui des passkeys. Le vecteur passkey a fait les gros titres. Les deux autres sont plus discrets et pourraient plausiblement être différés.
• Si le correctif est ciblé ou structurel. Les notes de version le disent rarement directement, mais les chercheurs referont vraisemblablement leurs tests et publieront leurs conclusions, et leur outil de test donne à tout le monde un moyen de vérifier de façon indépendante.
• Si quoi que ce soit apparaît côté utilisateur. Toute indication de la couverture du relais page par page serait une amélioration significative par rapport au silence actuel.
• Si le périmètre de Private Relay est redécrit. Si Apple resserre le langage sur ce que couvre la fonctionnalité, c'est informatif aussi — cela suggérerait que la résolution porte en partie sur les attentes plutôt qu'entièrement sur le code.

D'ici là, la situation reste inchangée : les fuites sont réelles, le relais fait toujours un travail utile contre les observateurs passifs, et c'est dans l'écart entre les deux que vous devez prendre votre propre décision.

Résolution des problèmes courants

Private Relay est grisé ou totalement absent

Problème : vous allez dans Réglages Système, votre compte Apple, iCloud, et soit Private Relay n'est pas listé, soit l'interrupteur ne répond pas.

Solution : passez les causes en revue dans l'ordre. D'abord, confirmez que vous êtes sur un forfait iCloud+ payant — Private Relay n'existe pas sur le palier gratuit, et c'est l'explication la plus courante de son absence. Ensuite, vérifiez votre région : la fonctionnalité est indisponible dans plusieurs pays et n'apparaît pas là où elle n'est pas proposée. Troisièmement, si le Mac est géré par un employeur ou un établissement scolaire, regardez dans Réglages Système sous Général, puis Gestion des appareils, s'il existe un profil de configuration — les organisations désactivent couramment Private Relay parce qu'il met en échec le filtrage réseau, et une restriction au niveau du profil ne peut pas être outrepassée localement. Quatrièmement, vérifiez que vous êtes connecté à iCloud avec le compte qui porte l'abonnement iCloud+, et non un compte secondaire. Si ces quatre points sont bons et que l'interrupteur reste inerte, déconnectez-vous d'iCloud puis reconnectez-vous, et redémarrez.

Private Relay se désactive tout seul sur un réseau précis

Problème : le relais fonctionne à la maison mais est systématiquement désactivé au bureau, dans un café particulier ou sur le Wi-Fi d'un hôtel donné.

Solution : vérifiez d'abord l'interrupteur par réseau, car c'est presque toujours la cause. Ouvrez Réglages Système, allez dans Wi-Fi, cliquez sur Détails à côté de ce réseau, et cherchez-y le réglage Private Relay. Il est indépendant de l'interrupteur global, et si vous avez un jour écarté l'invite « ce réseau bloque Private Relay » en choisissant de continuer sans lui, ce choix a été mémorisé pour ce réseau. Réactivez-le et voyez si la connexion fonctionne toujours. Si le réseau bloque réellement le relais, vous serez de nouveau invité à choisir, et à ce moment-là vous savez que le blocage est en amont plutôt qu'un réglage périmé. Les réseaux d'entreprise en particulier ont tendance à le bloquer délibérément au niveau du pare-feu, et il n'existe aucun contournement côté client — si vous avez besoin de confidentialité d'adresse sur un tel réseau, un VPN est la seule voie, à supposer que le réseau en autorise un.

L'outil de test signale une fuite et vous voulez savoir quoi faire

Problème : vous avez visité l'outil des chercheurs, il a signalé que votre adresse réelle était visible via un ou plusieurs vecteurs, et vous voulez une prochaine étape.

Solution : premièrement, n'interprétez pas cela comme une compromission. Un résultat fuyant signifie qu'un site pourrait apprendre votre adresse IP ; il ne signifie pas que quoi que ce soit a été volé, consulté ou compromis, et il n'y a aucun compte à sécuriser ni mot de passe à changer. Deuxièmement, confirmez que le résultat porte bien sur les vecteurs et non sur un relais désactivé — vérifiez les réglages Private Relay global et par réseau puis refaites le test, car un relais désactivé montrera votre adresse réelle par tous les chemins et constitue un problème complètement différent, à la solution facile. Troisièmement, si le relais est confirmé actif et que la fuite persiste, vous avez reproduit le comportement signalé et il n'existe aucun correctif côté utilisateur. Décidez selon votre modèle de menace : pour la plupart des gens, la réponse correcte est d'en prendre note et de continuer ; pour ceux qui ont réellement besoin de confidentialité d'adresse, un VPN est la mesure d'atténuation disponible, avec le compromis de confiance décrit plus haut. Refaites le test après toute mise à jour de l'automne 2026.

Des sites vous bloquent ou dysfonctionnent parce que vous utilisez Private Relay

Problème : un site bancaire refuse de se charger, un service de streaming affirme que vous êtes dans le mauvais pays, le paiement d'une boutique échoue, ou un site vous soumet sans cesse à des CAPTCHA.

Solution : cela arrive parce que le site voit l'adresse du proxy de sortie plutôt que la vôtre, et soit il ne reconnaît pas cette adresse comme résidentielle, soit l'adresse se géolocalise à un endroit inattendu, soit elle appartient à une plage partagée qui a été signalée. Commencez par le réglage de localisation : dans le panneau Private Relay, basculez Localisation de l'adresse IP sur « Conserver la localisation générale » si elle est réglée sur l'option plus large au niveau du pays, ce qui résout la plupart des incohérences géographiques. Si cela ne suffit pas, utilisez l'interrupteur par réseau pour désactiver le relais uniquement sur ce réseau plutôt que globalement, ou utilisez un autre navigateur pour ce site précis — en gardant à l'esprit que les navigateurs autres que Safari sont de toute façon hors du relais sur macOS. Désactiver le relais globalement pour régler un site récalcitrant est une surcorrection que vous oublierez d'annuler.

Un VPN et Private Relay entrent en conflit

Problème : vous connectez un VPN et Private Relay se signale comme inactif, ou les deux ensemble produisent un DNS cassé, des connexions qui échouent ou une navigation d'une lenteur inutilisable.

Solution : comprenez d'abord que c'est largement attendu. Un VPN système capture le trafic au niveau réseau avant que Private Relay ne le voie ; macOS met donc généralement le relais en retrait lorsqu'un VPN est actif — ce n'est pas un bug et cela ne vous laisse pas sans protection, puisque le VPN couvre désormais strictement plus de trafic que le relais n'en couvrait. Le conseil pratique est d'en choisir un et de le laisser posséder le chemin. Si vous faites tourner un VPN pour les raisons évoquées dans cet article, le retrait du relais est le résultat correct. Si vous constatez une véritable casse plutôt qu'un simple relais signalé inactif, les coupables habituels sont une configuration DNS conflictuelle, un client VPN qui ne capture le trafic que partiellement, ou une extension réseau résiduelle d'un VPN précédemment installé. Supprimez les anciens profils de configuration VPN dans Réglages Système avant d'aller plus loin dans le diagnostic, car les profils périmés causent une part disproportionnée de ces problèmes.

FAQ

Cela signifie-t-il que mon historique de navigation a été exposé ?

Non. Ce qui fuit, c'est votre adresse IP — l'identité réseau, pas le contenu. Les contenus chiffrés de votre navigation restent chiffrés, et rien sur les pages que vous lisez n'est révélé par ces vecteurs, au-delà du fait que vous vous êtes connecté à un site qui cherchait déjà à vous identifier. Aucun identifiant de compte n'est en jeu et aucun compte n'a été compromis.

Devrais-je arrêter d'utiliser les passkeys à cause de cela ?

Non. Les passkeys restent nettement plus sûres que les mots de passe — elles résistent à l'hameçonnage et rien de réutilisable ne transite sur le réseau. La fuite n'est pas une faiblesse de l'authentification par passkey elle-même ; c'est la requête réseau qui soutient la cérémonie qui contourne Private Relay. Abandonner les passkeys reviendrait à échanger un gain de sécurité réel contre un gain de confidentialité marginal.

Un CVE a-t-il été attribué à ce problème ?

Aucun CVE n'a été signalé pour l'un des trois vecteurs. Les travaux ont été publiés par Mysk et Haj Bakry le 4 août 2026 et repris par la presse le lendemain. Apple a déclaré à 404 Media qu'elle enquêtait. Méfiez-vous de toute source citant un identifiant CVE précis pour ce problème, puisqu'aucun n'a été publié.

Utiliser Chrome ou Firefox sur mon Mac règle-t-il le problème ?

Pas de la façon dont les gens l'imaginent. Ces navigateurs utilisent leurs propres moteurs et ne sont pas affectés par ces vecteurs propres à WebKit, mais Private Relay n'a jamais relayé leur trafic au départ. Changer de navigateur ne vous place pas derrière le relais — cela vous en retire entièrement. Cela n'aide que si vous l'associez à un VPN couvrant l'ensemble.

Est-ce différent sur mon iPhone et sur mon Mac ?

Oui. Sur iOS, la plupart des juridictions imposent à tous les navigateurs d'utiliser WebKit : chaque navigateur de l'appareil partage donc la même exposition et changer d'application ne change rien. Sur Mac, seuls Safari et les applications intégrant WebKit sont concernés, puisque les autres navigateurs embarquent leurs propres moteurs. Les vecteurs eux-mêmes se comportent de la même manière sur les deux plateformes.

Quand Apple corrigera-t-elle cela ?

9to5Mac a rapporté que le message de statut d'Apple aux chercheurs indiquait que l'entreprise prévoyait de traiter le problème, avec un correctif visé pour l'automne 2026. Apple ne s'est pas engagée publiquement sur une version ou une date précise, au-delà de sa confirmation à 404 Media qu'elle enquête. Aucun correctif n'est disponible aujourd'hui, et MacRumors a décrit le problème comme inscrit dans le fonctionnement même de WebKit.

Conclusion

Les travaux de Mysk et Haj Bakry sont réels, ils sont bien documentés, et ils méritent qu'Apple les corrige correctement plutôt que de les rustiner étroitement. Trois sous-systèmes WebKit distincts — le service d'identifiants qui traite les cérémonies passkey, le préchargement DNS et WebTransport — peuvent chacun placer votre véritable adresse IP sous les yeux d'un site web qui va la chercher, pendant que Private Relay se signale tranquillement comme activé. Le vecteur passkey est le plus tranchant des trois, car il suffit qu'un site démarre la cérémonie, sans la terminer, et sans rien exiger de vous.

Ce que ceci n'est pas : une compromission, un piratage de compte, ni une raison de s'alarmer. Private Relay n'a jamais été un VPN, n'a jamais prétendu l'être, et fait toujours le travail pour lequel il a été construit contre les observateurs qu'il devait arrêter — votre FAI, le réseau sur lequel vous êtes assis, les observateurs passifs qui voient le trafic sans pouvoir amener un site à vous sonder activement. Cette protection est intacte, et désactiver la fonctionnalité reviendrait à l'abandonner en échange de rien.

Ce que ceci est : une démonstration claire que la couverture de la fonctionnalité est plus étroite que le modèle mental que la plupart des gens ont, et que la frontière n'est imposée nulle part où les nouvelles capacités de la plateforme devraient la respecter. Si votre modèle de menace inclut réellement quelqu'un qui apprendrait votre adresse IP, la réponse a toujours été un outil conçu pour ce travail, avec le compromis de confiance compris et accepté. Si ce n'est pas le cas, prenez-en note, gardez le relais activé, faites le test si la curiosité vous prend, et observez ce qui sortira à l'automne.

Lecture associée : Guide de sécurité et de confidentialité sur Mac 2026