Apple change le domaine de vos e-mails relais — et fait marche arrière sur la moitié

Le 24 août 2026, Apple a publié une note destinée aux développeurs, avec un titre peu spectaculaire : « Update: New domain for Sign in with Apple » (Mise à jour : nouveau domaine pour Sign in with Apple). Elle contient une phrase réellement intéressante, et ce n'est pas celle qui parle du nouveau domaine.

Après mûre réflexion et après avoir pris connaissance des retours de la communauté, les adresses iCloud+ Hide My Email resteront sur icloud.com.

C'est Apple qui revient sur une décision annoncée dix semaines plus tôt. Et la raison de ce revirement illustre bien un point que la plupart des gens comprennent mal sur le fonctionnement réel de ces fonctionnalités de confidentialité : pour un alias e-mail, être identifiable, c'est l'échec.

Points clés

• Les adresses relais de Sign in with Apple migrent de privaterelay.appleid.com vers private.icloud.com, à partir de plus tard cette année.
• Les adresses iCloud+ Hide My Email restent sur icloud.com. Apple prévoyait de les déplacer en juin, avant d'annuler ce projet en août.
• Rien de ce que vous utilisez déjà ne cesse de fonctionner. Les adresses existantes sur les anciens domaines continuent de fonctionner et de transférer le courrier.
• Ce revirement s'explique par le fait qu'un domaine dédié constitue une entrée de liste noire toute prête. Un site peut rejeter un domaine entier. Il ne peut pas rejeter icloud.com sans rejeter du même coup tous les véritables utilisateurs d'iCloud.
• Attendez-vous à ce que le phishing exploite ce changement. Un domaine Apple nouveau et inconnu qui apparaît dans votre boîte de réception est exactement le genre de changement autour duquel les attaquants construisent leurs campagnes.

Trois choses différentes, toutes appelées « privées »

Avant toute chose, il faut démêler tout cela, car le plan de juin ne semblait logique que si l'on confondait deux de ces éléments — et s'il était erroné, c'est justement parce qu'il ne s'agit pas du même produit.

1. Le relais e-mail privé de Sign in with Apple

Lorsque vous appuyez sur « Sign in with Apple » dans une application ou sur un site web et que vous choisissez de masquer votre adresse, Apple génère une adresse relais destinée à ce développeur en particulier et vous transfère son courrier. C'est gratuit avec n'importe quel Apple Account.

• Domaine actuel : @privaterelay.appleid.com
• Nouveau domaine : @private.icloud.com, pour les adresses nouvellement créées, à partir de plus tard cette année
• Gérable sur votre Mac dans System Settings → [votre nom] → Sign in with Apple

2. iCloud+ Hide My Email

Une fonctionnalité payante d'iCloud+. Vous créez vous-même des alias, pour absolument tout ce que vous voulez — une newsletter, un formulaire, une boutique — avec un libellé et une note pour vous souvenir de leur usage. Cette fonctionnalité n'est liée à aucun flux de connexion.

• Domaine : @icloud.com — inchangé
• Gérable sur votre Mac dans System Settings → [votre nom] → iCloud → Hide My Email
• Également accessible directement dans Safari et Mail, en cliquant dans un champ d'adresse et en choisissant Hide My Email

3. iCloud Private Relay

Ce n'est pas du tout de l'e-mail. Il s'agit d'un relais à deux sauts pour la navigation Safari et certains flux non chiffrés, conçu pour empêcher qu'une seule et même partie puisse voir à la fois qui vous êtes et ce que vous consultez. Il ne partage que le mot « relay » avec les deux autres, rien de plus. Nous avons détaillé un cas concret de défaillance de ce système dans iCloud Private Relay, quand il laisse fuiter votre véritable adresse IP.

Cette confusion n'est pas la faute du lecteur : les deux premières fonctionnalités affichent toutes deux un bouton intitulé « Hide My Email ». L'une vous donne une adresse privaterelay.appleid.com, l'autre une adresse icloud.com, et Apple n'a jamais vraiment mis en avant cette distinction. C'est très probablement ce libellé commun qui a rendu l'unification des domaines séduisante en juin.

Ce qu'Apple a dit, dans les deux versions

À lire côte à côte, tant le changement est précis.

15 juin 2026 :

Plus tard cet été, Apple va unifier les domaines e-mail utilisés par Sign in with Apple et iCloud+ Hide My Email sous un domaine unique et partagé : private.icloud.com.

Les nouvelles adresses générées pour ces deux fonctionnalités seront émises sur ce nouveau domaine. Par exemple :

• Les adresses Sign in with Apple, auparavant émises sur privaterelay.appleid.com, seront émises sur private.icloud.com.
• Les adresses iCloud+ Hide My Email, auparavant émises sur icloud.com, seront émises sur private.icloud.com.

Les adresses existantes sur les anciens domaines continueront de fonctionner et de transférer le courrier aux utilisateurs sans interruption.

24 août 2026 :

À partir de plus tard cette année, les nouvelles adresses Sign in with Apple, auparavant émises sur privaterelay.appleid.com, seront émises sur private.icloud.com. Les adresses existantes sur privaterelay.appleid.com continueront de fonctionner et de transférer le courrier aux utilisateurs sans interruption.

Après mûre réflexion et après avoir pris connaissance des retours de la communauté, les adresses iCloud+ Hide My Email resteront sur icloud.com.

Deux changements entre ces deux textes. Hide My Email sort du champ de la migration. Et le calendrier est passé de « plus tard cet été » à « à partir de plus tard cette année » — le calendrier initial a déjà été dépassé, ce qui mérite d'être noté si vous comptiez vous organiser en fonction.

Pourquoi conserver Hide My Email sur icloud.com est la bonne décision

Voici le mécanisme en jeu, et il mérite d'être compris car il se généralise à tous les services d'alias.

Un alias e-mail ne vous protège que si le destinataire ne peut pas identifier facilement qu'il s'agit d'un alias. Dès qu'un service est capable d'identifier les adresses alias, il peut les refuser — et les services ont de fortes incitations à le faire, car un alias représente un client qu'ils ne peuvent pas ré-identifier, qu'ils ne peuvent pas recouper avec les données d'un courtier en données, et qu'ils ne peuvent plus joindre si vous « brûlez » l'adresse.

John Gruber a résumé directement le point de vue de l'utilisateur lorsque ce revirement a été annoncé :

nous voulons souvent utiliser ce type d'adresses e-mail masquées sur des sites qui préféreraient bloquer ces adresses et nous forcer à utiliser nos adresses « réelles »

Un domaine dédié comme private.icloud.com n'est qu'une seule chaîne de caractères. N'importe quel formulaire d'inscription pourrait le rejeter en une seule ligne de validation. Tous les alias jamais émis par Apple deviendraient simultanément inutilisables sur tout site ajoutant cette ligne.

icloud.com ne peut pas être traité de cette manière. C'est le domaine que des centaines de millions de personnes utilisent pour leur messagerie personnelle ordinaire. Un service qui bloque icloud.com pour se débarrasser des alias bloque du même coup une grande partie de ses véritables clients. La protection de Hide My Email n'est pas de nature cryptographique — elle tient au fait que les alias se cachent parmi de vraies adresses. Les déplacer vers un domaine distinct aurait fait disparaître cette cachette.

C'est apparemment la conclusion à laquelle Apple est arrivée, et c'est la bonne. C'est aussi un exemple rare d'un plan déjà annoncé qui est retiré pour un argument de confidentialité plutôt que technique.

Et pourquoi la migration de Sign in with Apple ne pose pas le même problème

Il serait facile de conclure de ce raisonnement qu'Apple a laissé les utilisateurs de Sign in with Apple exposés. Ce n'est pas exact, et il vaut la peine d'expliquer précisément pourquoi.

Les adresses relais de Sign in with Apple se trouvaient déjà sur un domaine dédié, manifestement identifiable. privaterelay.appleid.com s'annonce de lui-même. Tout service souhaitant les rejeter le peut depuis 2019. Le passage à private.icloud.com est un déplacement latéral sur cet axe — un domaine identifiable différent, pas un domaine nouvellement identifiable.

Il existe aussi une raison structurelle qui rend cette exposition moins problématique. Une adresse relais Sign in with Apple n'est pas quelque chose que vous saisissez dans un formulaire. Elle est émise dans le cadre d'un flux d'authentification que le site a lui-même choisi de proposer. Un site qui ne veut pas d'adresses relais n'implémente tout simplement pas Sign in with Apple. Le scénario de blocage qui rend Hide My Email fragile ne se présente pratiquement pas ici.

Le résumé honnête est donc le suivant : Apple a protégé la fonctionnalité qui avait besoin de l'être, et a déplacé celle qui n'en avait pas besoin. Le plan de juin aurait endommagé l'une des deux, et Apple s'en est rendu compte à temps.

Ce qui change concrètement pour vous

Pour la plupart des gens, très peu de choses — mais les détails méritent d'être connus avant qu'ils ne vous surprennent.

Vos adresses existantes ne changent pas. Chaque adresse privaterelay.appleid.com que vous possédez déjà continue de fonctionner et de transférer le courrier. Apple le précise explicitement dans les deux annonces. Vous n'avez rien à mettre à jour, rien à réenregistrer, ni aucun compte à migrer.

Les nouvelles connexions produiront un domaine que vous n'avez encore jamais vu. Après le changement, utiliser Sign in with Apple sur un nouveau service émettra une adresse sur private.icloud.com. Si vous tenez un registre indiquant quel alias a été donné à quel service, attendez-vous désormais à voir deux domaines dans cette liste.

Un petit nombre de sites rejetteront le nouveau domaine. Tout service dont la validation d'inscription, la liste blanche ou la règle anti-abus code en dur privaterelay.appleid.com ne reconnaîtra pas private.icloud.com tant qu'il n'aura pas été mis à jour. La note d'Apple demande explicitement aux développeurs d'accepter les deux. Tous ne la liront pas.

Le filtrage du courrier en entreprise peut retenir des messages. Si vous utilisez Sign in with Apple pour quoi que ce soit lié au travail et que votre organisation filtre par domaine d'expéditeur ou de destinataire, un domaine flambant neuf peut se retrouver en quarantaine.

La fenêtre d'opportunité pour le phishing

C'est la partie qui a une réelle conséquence en matière de sécurité, et c'est celle dont personne ne parle.

Apple a publié cette information à destination des développeurs. Il n'existe aucune annonce grand public, aucune notification dans les réglages, aucun e-mail envoyé aux utilisateurs. Pour la plupart des gens, la première rencontre avec private.icloud.com se fera lorsqu'il apparaîtra simplement — dans une ligne « De », sur une page de réglages de compte, dans une entrée de gestionnaire de mots de passe.

Un domaine inconnu qui appartient réellement à Apple, apparaissant sans avertissement pendant une transition rendue publique, constitue des conditions proches de l'idéal pour une campagne de phishing. Les messages s'écrivent presque tout seuls : votre adresse relais Apple est en cours de migration, confirmez votre compte pour ne pas perdre l'accès aux services où vous vous êtes connecté.

Quelques règles qui restent valables indépendamment de ce changement :

• Apple ne vous demande rien pour cette migration. Tout message vous demandant de confirmer, vérifier, migrer ou ré-authentifier une adresse relais est frauduleux. Il n'existe aucune étape à effectuer côté utilisateur, tout simplement parce qu'il n'y en a aucune.
• N'agissez jamais sur la base d'un lien reçu dans un e-mail concernant votre Apple Account. Ouvrez vous-même System Settings et vérifiez. Si un changement est réel, il y sera visible.
• Vérifiez où un lien mène réellement. private.icloud.com appartient à Apple. private-icloud.com, privateicloud.com, private.icloud.com.example.net et icloud-private.com n'appartiennent pas à Apple. Les attaquants enregistrent ce type de domaines similaires précisément pour ce genre de moment.
• Une invite de mot de passe que vous n'avez pas provoquée est le signal d'alerte. Les invites de mot de passe macOS légitimes font suite à une action que vous venez d'effectuer. Nous avons détaillé à quel point cela peut être imité de façon convaincante dans la fausse invite de mot de passe imitant un rapport de plantage Mac.

Si vous voulez une passe de sécurisation plus large, notre guide de sécurité et de confidentialité pour Mac couvre les réglages associés.

Faire l'audit de ce que vous possédez réellement

C'est le bon moment pour vérifier, car la plupart des gens ne l'ont jamais fait.

Quelles applications utilisent Sign in with Apple :

Sur un Mac, ouvrez System Settings, cliquez sur votre nom en haut de la barre latérale, puis sur Sign in with Apple. Vous obtenez la liste de toutes les applications et de tous les sites où vous l'avez utilisé, et vous pouvez cesser d'utiliser Sign in with Apple pour chacun d'entre eux individuellement.

Lisez attentivement cette liste avant de révoquer quoi que ce soit. Désactiver Sign in with Apple pour un service casse l'adresse relais, ce qui signifie que ce service ne peut plus vous joindre — y compris pour les réinitialisations de mot de passe. Si vous n'avez enregistré aucune autre méthode de connexion pour ce service, vous risquez de vous retrouver bloqué à l'extérieur de votre propre compte. Configurez d'abord une méthode de connexion alternative.

Quels alias Hide My Email existent :

System Settings → [votre nom] → iCloud → Hide My Email. Chaque entrée affiche son libellé, sa note, et l'adresse vers laquelle elle transfère le courrier. Vous pouvez désactiver un alias dont vous ne voulez plus, ce qui arrête la livraison sans supprimer l'enregistrement de son usage.

Vers où le courrier est transféré :

Même panneau. Si vous avez plusieurs adresses personnelles sur votre Apple Account, l'une d'elles sert de cible de transfert pour tous vos alias. Assurez-vous que c'est une adresse que vous consultez encore — une adresse de transfert abandonnée est une défaillance silencieuse qui ne se révèle que le jour où vous avez besoin d'un message de récupération de compte.

Deux choses à faire pendant que vous y êtes

Étiquetez correctement vos alias. Le champ de note existe pour que, dans deux ans, vous puissiez encore savoir à quoi servait tel alias. Un alias non étiqueté est une adresse que vous n'oserez plus jamais désactiver.

Vérifiez que vos méthodes de récupération de compte ne dépendent pas d'un relais. Si la seule adresse de contact d'un compte critique est un relais Sign in with Apple et que vous révoquez ultérieurement l'accès de cette application, la récupération de ce compte disparaît avec lui. Conservez au moins une méthode qui ne transite pas par un relais que vous pourriez un jour désactiver.

Pour les développeurs et les administrateurs

Si vous exploitez quoi que ce soit qui manipule des adresses e-mail, il y a ici un travail concret à mener. Ce qu'Apple demande :

Les développeurs dont les applications ou les sites web utilisent Sign in with Apple doivent s'assurer que leurs systèmes de comptes, leur logique de validation des e-mails et leurs listes blanches acceptent les adresses sur le nouveau domaine private.icloud.com, en plus du domaine existant privaterelay.appleid.com.

Concrètement :

1. Acceptez les deux domaines. Il ne s'agit pas d'un remplacement — les deux doivent être acceptés. Les adresses existantes sur privaterelay.appleid.com restent valides indéfiniment.
2. Trouvez les chaînes codées en dur. Passez votre base de code et votre configuration au grep à la recherche de privaterelay.appleid.com. Cette chaîne se cache dans les regex de validation, les règles anti-fraude, la segmentation analytique, les listes blanches de délivrabilité et les outils de support.
3. Vérifiez les règles de votre fournisseur de service e-mail. Le routage basé sur le domaine, les listes de suppression et les règles de réputation vivent hors de votre dépôt de code, et c'est là qu'il est le plus facile de rater ce changement.
4. Ne mettez pas en place de nouveau blocage sur private.icloud.com. Au-delà d'être hostile envers vos propres utilisateurs, une adresse que vous rejetez à l'inscription représente un client que vous n'avez pas acquis, et Sign in with Apple est une méthode d'authentification que votre application a elle-même choisi de proposer.
5. Testez l'ensemble du parcours. Inscription, e-mail de vérification, réinitialisation de mot de passe, et récupération de compte. Une règle de validation qui accepte l'adresse à l'inscription mais la rejette lors de la réinitialisation du mot de passe est un bug réellement pénible, et c'est la forme la plus fréquente de cette défaillance.

Pour les administrateurs : si vous filtrez le courrier entrant par domaine, ajoutez private.icloud.com à la liste sur laquelle figure déjà privaterelay.appleid.com, avant que vos utilisateurs ne commencent à signaler des messages manquants — pas après.

Ce que le relais masque réellement

Un point sur lequel il vaut la peine d'être précis, car les gens étendent leur confiance envers ces fonctionnalités au-delà de ce qu'elles couvrent réellement.

Ce que le développeur n'obtient pas : votre véritable adresse e-mail. Il obtient une adresse relais à laquelle il peut envoyer du courrier, qu'Apple se charge de transférer. Si vous révoquez l'accès, le relais s'arrête et l'adresse qu'il détient pour vous devient inactive.

Ce que le développeur obtient :

• Un identifiant stable vous concernant au sein de son application. Sign in with Apple émet un identifiant utilisateur propre à chaque développeur, qui persiste entre les sessions et les appareils, et c'est ce qui permet au développeur de vous reconnaître comme utilisateur récurrent. Cet identifiant est propre à ce développeur — le même Apple Account produit un identifiant différent chez un autre développeur, si bien que deux applications ne peuvent pas croiser leurs données sur cette base.
• Votre nom, si vous avez choisi de le partager, et vous pouvez le modifier au moment de la connexion.
• Tout ce que vous lui communiquez par la suite. Le relais couvre votre adresse, pas votre comportement. Si vous saisissez votre vrai nom dans un champ de profil, vous le lui avez livré vous-même.
• Tout ce que ses outils d'analyse collectent. Le fingerprinting de l'appareil, l'adresse IP et les identifiants publicitaires sont entièrement en dehors du périmètre de cette fonctionnalité.

Ce qu'Apple obtient : le courrier transite par les serveurs d'Apple pour être transféré. Apple affirme ne pas lire ni conserver le contenu au-delà de ce qui est nécessaire à sa livraison, mais le relais est, par construction, un chemin qui passe par Apple, pas un chemin qui le contourne.

La manière la plus claire d'y penser : une adresse relais est un canal révocable, pas de l'anonymat. Elle résout le problème « cette entreprise a vendu mon adresse à un courtier en données et je ne peux plus arrêter le courrier ». Elle ne résout pas le problème « cette entreprise sait qui je suis ».

C'est un problème dont la résolution a une réelle valeur, et la révocabilité en est la moitié sous-estimée — pouvoir couper la capacité d'une entreprise à vous joindre, sans avoir à changer votre adresse ailleurs, est quelque chose qu'une boîte mail ordinaire n'a jamais offert.

Comparaison avec les services d'alias tiers

Apple n'est pas la seule option, et la comparaison éclaire bien l'argument de la blocabilité.

Les services d'alias dédiés — SimpleLogin, AnonAddy et autres du même genre — vous donnent des alias illimités, généralement sur des domaines partagés avec tous leurs autres utilisateurs. Ce domaine partagé est exactement la cible de liste noire que le plan de juin aurait créée pour Hide My Email, et c'est pour cela que ces services sont largement rejetés par les formulaires d'inscription. Les meilleurs vous permettent d'utiliser votre propre domaine, ce qui restaure la non-blocabilité, au prix de l'enregistrement et du paiement d'un nom de domaine — et du fait que ce domaine devient identifiable comme étant uniquement le vôtre si quelqu'un fait le lien.

Fastmail et les fournisseurs similaires proposent des adresses masquées sur votre propre domaine ou sur le leur, avec le même compromis.

Hide My Email d'iCloud+ chez Apple se distingue précisément par ce qui vient d'être préservé : ses alias vivent sur icloud.com, aux côtés de centaines de millions d'utilisateurs ordinaires. C'est le seul grand service d'alias dont les adresses ne se distinguent pas des adresses réelles. Il s'agit d'un avantage structurel qu'aucun concurrent ne peut reproduire, car aucun concurrent n'exploite un domaine de messagerie grand public à une telle échelle.

Les limites sont réelles. Les alias d'Apple transfèrent vers une seule adresse, il n'existe pas d'envoi « en tant que » depuis un alias en dehors de Mail sur les appareils Apple, et vous ne pouvez pas utiliser votre propre domaine. Si vous voulez un routage fin et pouvoir répondre depuis n'importe quel client de messagerie, un service dédié fait davantage. Si vous voulez un alias qui soit simplement accepté partout, celui d'Apple reste l'option la plus solide disponible — et il vient justement de le rester.

Un bref historique, et pourquoi l'ancien domaine a toujours été étrange

Sign in with Apple a été lancé en 2019, et les directives d'examen de l'App Store d'Apple imposaient aux applications proposant des options de connexion tierces de proposer également Sign in with Apple — ce qui explique pourquoi cette fonctionnalité est apparue presque partout d'un coup plutôt que progressivement. Le relais e-mail privé en était la fonctionnalité la plus distinctive : les autres fournisseurs de connexion transmettent votre adresse au développeur, tandis qu'Apple proposait de ne pas le faire.

L'adresse distribuée à la place était @privaterelay.appleid.com. C'est difficile à prononcer, elle se trouve sur un domaine que la plupart des utilisateurs n'ont jamais rencontré par ailleurs, et elle révèle sa propre nature. Cela avait du sens du point de vue d'Apple — appleid.com étant le domaine où résidait l'infrastructure des comptes — mais du point de vue de l'utilisateur, cela a toujours un peu ressemblé à quelque chose qu'un kit de phishing aurait pu inventer.

La consolidation vers private.icloud.com corrige ce problème. icloud.com est un domaine que les gens ordinaires reconnaissent, et un sous-domaine de celui-ci paraît légitime d'une manière que privaterelay.appleid.com n'a jamais vraiment réussi à atteindre. Pour le relais de connexion, il s'agit d'une amélioration simple et directe, et c'est vraisemblablement le raisonnement à l'origine de tout cet exercice.

Le plan de juin l'a ensuite appliqué de manière excessive. La consolidation est bénéfique pour l'adresse qui était déjà visible. Elle était activement nuisible pour celle dont la valeur reposait précisément sur sa discrétion. Le fait que la correction ait pris dix semaines et nécessité une réaction publique constitue un petit cas d'école montrant comment un changement qui améliore un produit peut, discrètement, dégrader un autre produit avec lequel il partage un nom et un bouton.

Résolution des problèmes courants

Un site web rejette ma nouvelle adresse relais Apple comme invalide

Problème : la validation e-mail du site ne reconnaît pas encore private.icloud.com.

Solution : signalez-le au site — c'est leur bug, et Apple en a déjà publié la correction. En attendant, un alias iCloud+ Hide My Email sur icloud.com sera accepté, puisque ce domaine ne change pas et reste indiscernable d'une adresse iCloud ordinaire. C'est précisément la propriété qu'Apple a préservée.

Le courrier d'un service où je me suis connecté avec Apple n'arrive plus

Problème : plusieurs possibilités : l'adresse de transfert sur votre Apple Account est une adresse que vous ne consultez plus, vous avez révoqué Sign in with Apple pour cette application, ou votre fournisseur de messagerie filtre un domaine inconnu.

Solution : vérifiez dans System Settings → [votre nom] → Sign in with Apple que l'application est toujours active, puis vérifiez votre adresse de transfert sous Hide My Email. Vérifiez ensuite vos dossiers de courrier indésirable et de quarantaine pour le nouveau domaine.

J'ai révoqué Sign in with Apple et je ne peux plus me connecter

Problème : révoquer l'accès invalide l'adresse relais, et si cette adresse était la seule méthode de contact du compte, la réinitialisation du mot de passe n'a plus aucune destination.

Solution : contactez directement le support du service et expliquez la situation — c'est un cas connu, et la plupart disposent d'une procédure manuelle. Pour éviter ce problème, enregistrez une méthode de connexion alternative avant de révoquer quoi que ce soit.

J'ai reçu un e-mail m'annonçant un changement de mon adresse relais Apple

Problème : Apple n'envoie aucun e-mail aux utilisateurs à ce sujet. Cette migration ne requiert rien de votre part.

Solution : traitez-le comme du phishing. Ne cliquez sur rien. Vérifiez tout ce qui vous inquiète en ouvrant vous-même System Settings.

Je ne trouve pas Hide My Email dans les réglages

Problème : il s'agit d'une fonctionnalité d'iCloud+, qui nécessite un abonnement payant iCloud+ ou Apple One. Sans abonnement, seul le relais gratuit de Sign in with Apple est disponible.

Solution : vérifiez votre abonnement dans System Settings → [votre nom] → iCloud. Si vous n'êtes pas abonné, l'option de masquage d'adresse de Sign in with Apple fonctionne quand même, gratuitement — elle est simplement limitée aux flux de connexion plutôt qu'utilisable partout.

FAQ

Dois-je faire quelque chose ?

Non. Les adresses existantes continuent de fonctionner, et le changement ne s'applique qu'aux nouvelles adresses Sign in with Apple émises. Il n'existe aucune étape de migration côté utilisateur, ce qui explique précisément pourquoi tout message affirmant le contraire est frauduleux.

Mes anciennes adresses privaterelay.appleid.com vont-elles cesser de fonctionner ?

Non. Apple précise dans les deux annonces que les adresses existantes continuent de fonctionner et de transférer le courrier sans interruption. Apple n'a annoncé aucune date de fin pour ces adresses.

Pourquoi Apple a-t-il changé d'avis à propos de Hide My Email ?

La formulation d'Apple elle-même est « après mûre réflexion et après avoir pris connaissance des retours de la communauté ». Le fond de ces retours était qu'un domaine dédié rend les adresses alias trivialement blocables, ce qui annule l'intérêt de la fonctionnalité. Les conserver sur icloud.com signifie qu'elles restent indiscernables des adresses iCloud ordinaires.

Hide My Email est-il la même chose que l'adresse masquée de Sign in with Apple ?

Non, même si les deux affichent un bouton portant ce nom. Hide My Email est une fonctionnalité payante d'iCloud+ qui produit des alias icloud.com que vous créez pour n'importe quel usage. Le relais de Sign in with Apple est gratuit, lié à une application spécifique, et c'est celui qui migre vers private.icloud.com.

Quand exactement ce changement aura-t-il lieu ?

Apple indique « à partir de plus tard cette année ». L'annonce de juin disait « plus tard cet été » — le calendrier a donc déjà été décalé une fois. Aucune date précise n'a été publiée.

Cela affecte-t-il iCloud Private Relay ?

Non. iCloud Private Relay est une fonctionnalité de confidentialité réseau pour la navigation Safari, et n'a rien à voir avec les adresses e-mail, malgré le mot commun.

Devrais-je plutôt basculer mes comptes importants vers Hide My Email ?

Pour les comptes qui comptent vraiment, la question la plus utile est de savoir si votre méthode de récupération survit à la désactivation de l'alias. Les deux systèmes sont solides. Le risque est identique dans les deux cas : si un alias est la seule méthode de contact d'un compte et que vous le désactivez plus tard, la récupération devient difficile. Conservez une seconde méthode pour tout ce que vous ne pouvez pas vous permettre de perdre.

Conclusion

Le changement principal est modeste et ne requiert rien de votre part : les nouvelles adresses Sign in with Apple arriveront sur private.icloud.com, les anciennes continuent de fonctionner, et les seules personnes ayant un véritable travail à faire sont les développeurs qui ont codé en dur une chaîne de domaine quelque part.

Ce qui mérite d'être retenu, c'est la partie qu'Apple a défaite. Une fonctionnalité de confidentialité que tout le monde peut identifier n'est pas une fonctionnalité de confidentialité — et le plan de juin d'Apple, qui ressemblait à une consolidation pleine de bon sens, aurait pris un système d'alias dont toute la protection tient au fait qu'il se fond dans le courrier ordinaire, pour lui coller une étiquette sur laquelle n'importe qui pourrait filtrer. Cette erreur a été repérée, publiquement, et corrigée en dix semaines. C'est à la fois un bon dénouement et un rappel que l'instinct de conception consistant à « unifier ces deux choses qui partagent un bouton » mérite d'être reconsidéré lorsque l'une des deux dépend justement du fait de passer inaperçue.

En attendant : Apple ne vous enverra aucun e-mail à ce sujet. Quiconque le fait n'est pas Apple.

Pour aller plus loin : iCloud Private Relay, quand il laisse fuiter votre véritable adresse IP, le guide de sécurité et de confidentialité pour Mac, et les fausses invites de mot de passe sur Mac et comment les repérer.