VPN et Relais privé iCloud : j’avais deux protections activées, mais une seule décidait réellement de l’IP et du DNS

J’avais deux protections activées et je ne savais plus laquelle me protégeait.

Sur mon Mac, Relais privé iCloud était bien activé.

Mon VPN aussi.

J’ai ouvert Safari, demandé mon adresse IP et obtenu une adresse qui n’était pas celle de ma box. Jusque-là, très bien.

Puis j’ai lancé un test DNS.

Là, je me suis arrêté.

Est-ce que je regardais la sortie du VPN ? Celle du relais privé ? Safari passait-il d’abord par Apple puis par mon VPN ? Ou l’inverse ? Et si les deux réglages restaient activés, avais-je réellement deux couches de protection ?

Je pensais qu’empiler deux outils de confidentialité ne pouvait qu’améliorer le résultat.

En réalité, j’avais surtout rendu plus difficile la réponse à une question assez simple :

qui décidait réellement de ce qu’Internet voyait ?

L’actualité d’août m’a donné une bonne raison de vérifier

La question aurait pu rester une curiosité de réglages.

Puis, début août 2026, les chercheurs Talal Haj Bakry et Tommy Mysk ont publié trois chemins permettant à certaines fonctions de WebKit de contourner des protections reposant sur un proxy et, dans leurs tests, Relais privé iCloud. Le DNS prefetching pouvait utiliser le chemin DNS normal de l’appareil ; WebAuthn et WebTransport pouvaient également provoquer des connexions révélant l’adresse IP réelle.

TechCrunch a ensuite reproduit l’exposition de l’adresse IP sur le site de démonstration des chercheurs.

Ce qui m’a intéressé n’était pas de conclure que Relais privé était soudain inutile. C’était de comprendre pourquoi une protection pouvait fonctionner normalement dans Safari tout en laissant certains chemins réseau lui échapper.

La différence tient à l’endroit où la protection intervient.

Relais privé s’appuie sur des relais pour le trafic qu’il prend en charge. Un VPN système crée, lui, un tunnel au niveau du système pour le trafic qu’il capture. Les chercheurs notaient que les contournements WebKit qu’ils avaient trouvés n’affectaient pas de la même manière un VPN système, précisément parce que ce trafic reste pris dans le tunnel.

Tout à coup, ma question « VPN ou Relais privé ? » me semblait mal formulée.

Je devais d’abord comprendre lequel possédait réellement la route.

Relais privé ne cherche pas à être un VPN généraliste

Apple décrit son fonctionnement assez clairement.

Lorsque je navigue dans Safari avec Relais privé, ma requête passe par deux relais indépendants. Le premier, exploité par Apple, connaît mon adresse IP mais pas la destination que je visite. Le second reçoit les informations nécessaires pour joindre le site et utilise une adresse IP temporaire, sans connaître mon adresse IP d’origine. Les informations DNS sont protégées dans ce processus.

J’aime bien cette architecture.

Mais elle ne signifie pas « tout mon Mac est derrière un VPN Apple ».

Dans sa documentation destinée aux développeurs, Apple décrit un périmètre comprenant la navigation Safari, les résolutions DNS et une partie limitée du trafic des applications. Les connexions au réseau local ou à des domaines privés, par exemple, ne suivent pas Relais privé.

Et surtout, Apple précise quelque chose qui répondait presque directement à ma question : une extension réseau fournissant un VPN n’utilise pas Relais privé, pas plus que le trafic des applications qui passe par cette extension.

Autrement dit, ce n’est pas nécessairement :

moi → VPN → Relais privé → Internet.

Ni :

moi → Relais privé → VPN → Internet.

Quand le VPN prend en charge le trafic, Relais privé peut simplement cesser d’être la couche qui décide de son trajet.

C’est cette différence que je voulais voir, plutôt que la déduire de deux interrupteurs.

J’ai commencé par enlever le VPN

J’ai gardé Relais privé activé dans iCloud et déconnecté le VPN.

Dans Safari, mon adresse IP habituelle n’apparaissait plus. J’obtenais l’adresse temporaire associée au relais.

C’était le comportement attendu.

J’ai ensuite ouvert un autre navigateur sur le Mac et comparé. L’adresse visible n’était plus nécessairement celle que Safari venait de me montrer.

Ce détail a rendu la différence beaucoup plus concrète.

Relais privé n’était pas une grande couverture posée uniformément sur toutes les connexions du Mac. Il protégeait un périmètre défini, avec Safari comme usage le plus évident.

Je suis revenu dans Safari et j’ai lancé un test DNS. Là encore, les résultats correspondaient au chemin protégé plutôt qu’à une simple résolution directement attribuable à ma connexion habituelle.

Je pouvais donc attribuer ce premier état :

VPN coupé, Relais privé actif : Safari et le trafic DNS concerné suivent le mécanisme de Relais privé.

Puis j’ai changé une seule chose.

J’ai laissé Relais privé activé et connecté le VPN

Je n’ai pas touché au réglage iCloud.

Je voulais justement voir ce qui se passait lorsque les deux restaient activés.

J’ai ouvert OnlydogVPN sur le Mac et choisi le mode confidentialité.

Connexion.

Retour dans Safari.

Nouvelle adresse IP.

Cette fois, ce n’était plus la sortie que j’avais observée avec Relais privé seul. Le navigateur suivait la sortie du VPN.

J’ai ouvert l’autre navigateur.

Même sortie.

Puis j’ai relancé le test DNS.

Le résolveur que j’observais sans le VPN n’apparaissait plus. Le DNS suivait lui aussi le chemin protégé par le tunnel.

C’était enfin le résultat que je cherchais.

Pas « deux protections sont allumées ».

Pas « deux logos de confidentialité apparaissent dans mes réglages ».

Mais quelque chose que je pouvais vérifier :

quand le tunnel système était actif, l’adresse IP et le DNS observés suivaient ce tunnel.

J’ai déconnecté le VPN.

Safari est revenu au comportement de Relais privé.

J’ai reconnecté.

La sortie du VPN a repris la main.

À partir de là, les deux réglages ont cessé de me sembler contradictoires.

Le DNS m’avait embrouillé parce que je cherchais un propriétaire unique

C’est probablement la partie la plus facile à compliquer inutilement.

Relais privé protège normalement les résolutions DNS qui entrent dans son fonctionnement. Apple explique qu’il s’applique aux requêtes de résolution de noms dans son périmètre, tout en précisant que le trafic pris en charge par une extension VPN ne passe pas par Relais privé.

Les deux affirmations vont ensemble.

J’ai fini par l’imaginer comme deux guichets capables de répondre à la même question : « Où se trouve ce site ? »

Sans VPN, Relais privé peut envoyer la demande DNS par son propre guichet.

Quand le VPN prend la connexion en charge et fournit le chemin DNS du tunnel, la demande part par l’autre guichet.

Je n’avais donc pas besoin de déterminer quel service était « au-dessus » de l’autre dans l’absolu. Je devais regarder quelle route avait réellement pris le trafic.

Il existe évidemment des configurations particulières — split tunneling, applications exclues, profils DNS séparés — qui peuvent modifier le résultat. Mais ce n’était pas la configuration que j’utilisais.

Avec le tunnel complet de mon test, l’IP et le DNS visibles suivaient le VPN.

J’ai compris pourquoi certains utilisateurs pensent que les deux services « se battent »

Cette confusion ne vient pas seulement des tests d’adresse IP.

Apple explique qu’un VPN ou un logiciel de filtrage peut installer sur Mac des réglages incompatibles avec Relais privé. macOS peut alors afficher une alerte indiquant que certains réglages système empêchent Relais privé de fonctionner.

Une discussion récente sur r/MacOS illustre assez bien le désordre que cela crée côté utilisateur. Une personne voyait constamment « Private Relay Unavailable » et soupçonnait le profil de son VPN. Certains participants pensaient également que le profil était en cause ; un autre expliquait utiliser un autre VPN avec Relais privé sans rencontrer le même problème.

Ce témoignage ne permet pas de généraliser à tous les VPN, et ce n’est pas son intérêt.

Il montre plutôt pourquoi « les deux sont activés » ne répond pas à la question « les deux transportent-ils mon trafic ? »

Ce sont deux choses différentes.

Et pour moi, cela a changé le critère de comparaison.

Je ne voulais plus savoir si Relais privé restait « activé »

Je voulais savoir si j’avais encore besoin de deviner par où passaient mes connexions pendant que le VPN tournait.

Quand je n’utilise pas de VPN, je garde volontiers Relais privé. Safari bénéficie de son architecture à deux relais et je n’ai rien à lancer.

Quand je veux une route plus cohérente pour mon appareil — Safari, les autres applications prises en charge par le tunnel et le DNS — j’active le mode confidentialité du petit service.

Je ne cherche plus à fabriquer un mystérieux « double VPN Apple + VPN commercial ».

Je veux une route dont je peux observer le résultat.

C’est aussi ce que la découverte d’août 2026 a changé dans ma manière de regarder ces outils. Les chercheurs avaient trouvé des fonctions WebKit capables de sortir du chemin proxy de Relais privé. Le VPN système, lui, capturait ces connexions à un autre niveau.

Une comparaison technique assez abstraite devenait soudain très simple : ce qui m’intéressait n’était plus le nombre de couches affichées dans mes réglages, mais l’endroit où le trafic était effectivement pris en charge.

Sur l’iPhone, j’ai refait le test au lieu de faire confiance au Mac

J’ai failli considérer le résultat du Mac comme suffisant.

Puis je me suis souvenu que tout mon problème venait justement de mes suppositions.

J’ai donc pris l’iPhone.

Relais privé actif.

VPN coupé.

Safari affichait la sortie correspondant au relais.

Puis j’ai connecté le même mode confidentialité.

J’ai refait le test d’adresse IP et le test DNS.

La sortie observée a basculé vers celle du VPN, et le DNS que je voyais auparavant n’apparaissait plus.

J’ai ouvert d’autres applications avec le tunnel toujours actif. Je n’avais plus Safari d’un côté, un autre navigateur de l’autre et une interrogation sur le DNS au milieu.

Dans ce test, la connexion du VPN me donnait une route cohérente sur les usages que je voulais protéger.

C’était précisément ce que j’étais venu chercher.

Ce n’est pas une raison de jeter Relais privé

Ce serait une conclusion trop facile.

Relais privé possède un avantage réel : il est intégré à l’écosystème Apple et son architecture à deux relais est justement conçue pour éviter qu’un seul acteur puisse associer à la fois l’utilisateur et les destinations qu’il consulte dans Safari.

Je continue donc à le trouver utile lorsque je navigue sans VPN.

Mais ce n’est plus ce que je choisirais comme unique réponse lorsque ma question devient :

« Quelle adresse IP mes applications exposent-elles et par où part réellement mon DNS ? »

Pour cela, je préfère un tunnel système dont je peux tester directement la sortie.

Le petit service a moins de régions et beaucoup moins d’historique public que certains fournisseurs VPN établis. Quelqu’un qui privilégie une immense sélection géographique ou des années d’évaluations indépendantes peut accorder davantage de poids à un acteur plus ancien.

Mon problème était différent.

Je voulais que mon iPhone et mon Mac cessent de me donner plusieurs réponses selon l’endroit où je regardais.

Une fois le tunnel actif, c’est ce que j’ai obtenu.

Alors, qui décide réellement du DNS et de l’adresse IP ?

Pas l’interrupteur dont le nom semble le plus protecteur.

La couche qui prend effectivement en charge le trafic.

Sans VPN, Relais privé peut masquer l’adresse IP utilisée par Safari et protéger le DNS entrant dans son périmètre.

Lorsqu’un VPN système prend ce trafic en charge et lui fournit sa route, c’est le tunnel qui devient le chemin déterminant. Apple le formule elle-même très simplement : le trafic utilisant une extension VPN ne passe pas par Relais privé.

C’est la distinction que je cherchais depuis le début.

Je pensais avoir besoin de savoir dans quel ordre empiler Relais privé et un VPN.

Après avoir regardé l’adresse IP et le DNS changer à chaque connexion et déconnexion, j’ai compris que la bonne question était beaucoup plus utile : quel outil possède réellement la route en ce moment ?

Sur mon iPhone comme sur mon Mac, quand j’ai voulu une réponse cohérente pour Safari, mes autres connexions et le DNS, j’ai laissé le tunnel système prendre la main.

Relais privé pouvait rester activé dans iCloud ; au moment où je connectais le VPN, je n’avais plus besoin de deviner par quelle porte mon iPhone ou mon Mac sortait réellement sur Internet.