Hide My Email reste en @icloud.com, mais les développeurs ont un autre domaine à accepter
Apple a séparé, le 24 août 2026, deux changements de domaine qu’elle avait initialement réunis. Selon sa mise à jour destinée aux développeurs, les adresses iCloud+ Hide My Email resteront en @icloud.com, tandis que les nouvelles adresses Sign in with Apple seront émises en @private.icloud.com plus tard en 2026.
Le revirement concerne donc Hide My Email, pas le changement prévu pour Sign in with Apple. Les anciennes adresses en @privaterelay.appleid.com continueront de fonctionner et de transférer les messages sans interruption, mais les services d’inscription doivent désormais accepter le nouveau domaine sans supprimer l’ancien.
Deux fonctions, deux décisions de domaine
Les deux fonctions évitent de communiquer directement l’adresse principale d’une personne, mais elles n’interviennent pas au même endroit. Hide My Email permet à un abonné iCloud+ de créer des adresses aléatoires qui transfèrent les messages reçus, alors que Sign in with Apple peut produire une adresse de relais lorsqu’un utilisateur masque son courriel pendant la connexion à une application ou à un site.
- iCloud+ Hide My Email : les adresses continueront d’utiliser icloud.com. La migration de cette fonction vers private.icloud.com, annoncée auparavant, est abandonnée.
- Sign in with Apple : les nouvelles adresses passeront de privaterelay.appleid.com à private.icloud.com plus tard dans l’année.
- Adresses Sign in with Apple existantes : celles déjà émises en privaterelay.appleid.com resteront actives et ne doivent pas être converties.
Le suffixe private.icloud.com ne permettra donc pas de conclure qu’une adresse provient de Hide My Email. Il signalera, dans le cadre décrit par Apple, une nouvelle adresse de relais créée par Sign in with Apple après le début de la transition.
Pourquoi @icloud.com reste important pour Hide My Email
Le maintien du domaine actuel conserve une difficulté pratique pour les sites qui voudraient refuser systématiquement les alias. Les adresses Hide My Email partagent leur suffixe avec les adresses iCloud ordinaires : bloquer tout le domaine icloud.com toucherait donc aussi des comptes qui n’utilisent pas cette fonction de masquage.
À l’inverse, le projet de domaine dédié aurait offert un critère de reconnaissance immédiat. L’analyse de TechCrunch relève que le passage à @private.icloud.com aurait facilité le refus de ces adresses pendant une inscription et que des utilisateurs avaient critiqué cette conséquence.
Rester en @icloud.com ne garantit pas qu’un alias ne puisse jamais être détecté ou refusé par d’autres moyens. La décision supprime seulement le signal simple qu’aurait constitué un sous-domaine exclusivement associé aux adresses masquées de cette fonction.
Ce que les services utilisant Sign in with Apple doivent adapter
Le travail demandé aux développeurs demeure concret. Trois zones sont à vérifier : les systèmes de comptes, la logique de validation des adresses électroniques et les listes d’autorisation. Toutes doivent accepter private.icloud.com en plus de privaterelay.appleid.com.
Une validation limitée à la syntaxe générale d’une adresse ne devrait pas dépendre d’un suffixe Apple précis. Le risque se concentre plutôt dans les règles internes qui énumèrent des domaines autorisés, reconnaissent uniquement privaterelay.appleid.com comme relais Apple ou classent les domaines inconnus comme temporaires ou indésirables.
- Repérer les règles figées : rechercher privaterelay.appleid.com dans la validation, les listes d’autorisation, les filtres par domaine et les traitements particuliers appliqués aux comptes Sign in with Apple.
- Ajouter sans remplacer : autoriser private.icloud.com tout en conservant privaterelay.appleid.com pour les comptes existants.
- Tester la création de compte : vérifier qu’une adresse au nouveau suffixe est acceptée par l’application, l’API, le fournisseur d’identité et les éventuels contrôles antifraude.
- Tester la continuité : s’assurer qu’un compte existant en privaterelay.appleid.com peut toujours se reconnecter et recevoir les messages nécessaires.
- Vérifier les courriels essentiels : contrôler les confirmations, codes de connexion et procédures de récupération acheminés par le relais.
Ces vérifications ne répondent pas à une interruption annoncée. Elles visent à empêcher qu’une règle locale rejette les nouvelles adresses lorsqu’Apple commencera à les émettre.
Les anciennes adresses ne sont pas à migrer
Le changement porte sur les adresses créées après la transition, et non sur une réécriture générale des comptes. Remplacer automatiquement privaterelay.appleid.com par private.icloud.com dans une base de données fabriquerait une autre adresse au lieu de mettre à jour celle qu’Apple avait réellement attribuée.
Les deux domaines devront donc coexister dans les systèmes. Une règle qui suppose que toute adresse Sign in with Apple se termine par privaterelay.appleid.com deviendra incomplète, tandis qu’une règle qui n’accepte plus que private.icloud.com rompra la compatibilité avec les comptes antérieurs.
Cette coexistence concerne aussi les recherches de comptes, les rapprochements de profils et les outils d’assistance lorsqu’ils utilisent le domaine pour reconnaître une adresse de relais. Le domaine peut servir à orienter un traitement, mais il ne doit pas conduire à modifier l’identifiant enregistré.
Le calendrier exact reste inconnu
Le calendrier public s’arrête à une mise en œuvre plus tard en 2026. La chronologie de MacGeneration précise que la modification n’est pas encore effective et qu’aucun jour de bascule n’a été communiqué.
L’état confirmé est ainsi limité mais sans ambiguïté : Hide My Email conserve icloud.com, les anciennes adresses Sign in with Apple en privaterelay.appleid.com restent fonctionnelles et seules les nouvelles adopteront private.icloud.com. La prochaine précision attendue concerne le début effectif de cette émission, pas une migration des alias Hide My Email.
À lire aussi:
Abonnez-vous à notre newsletter
Recevez directement les dernières actualités sur le Web3, l’IA et les cryptomonnaies.