Comment le Service de demande de données d’enregistrement (RDRS) de l’ICANN va-t-il remodeler l’accès aux données WHOIS non publiques jusqu’en 2027 ?

Introduction

La décision du conseil de l’ICANN du 30 octobre 2025 maintient le Service de demande de données d’enregistrement (ou « Registration Data Request Service » (RDRS)) en fonctionnement jusqu’en décembre 2027, tandis que la communauté débat de son évolution vers un modèle pérenne d’accès/divulgation standardisés (tel que le SSAD ou un dispositif successeur). La conséquence opérationnelle est immédiate : pendant les deux prochaines années, les acteurs devront composer avec un environnement « hybride », où les demandes de divulgation sont davantage standardisées dans leur forme, mais restent inégales en couverture, en délais de traitement et en mécanismes d’authentification.

Le RDRS : ce que c’est (et ce que ce n’est pas)

Le Registration Data Request Service (RDRS) est un service pilote lancé le 28 novembre 2023 afin de standardiser le format de soumission des demandes visant à obtenir des données d’enregistrement non publiques relatives aux gTLD auprès des bureaux d’enregistrement accrédités par l’ICANN. Il ne s’agit volontairement pas d’un cadre normatif final : c’est un instrument « grandeur nature » destiné à mesurer la demande, collecter des métriques d’usage et mettre en évidence les lacunes opérationnelles et juridiques, afin d’éclairer la conception d’un système durable (par exemple, le SSAD).
Concrètement, le RDRS standardise la porte d’entrée, pas l’issue : chaque bureau d’enregistrement conserve sa propre analyse juridique et sa décision de divulgation ou de refus, au regard du droit applicable et des politiques ICANN.

Ce que change, en pratique, la résolution du conseil de l’ICANN du 30 octobre 2025

Le conseil de l’ICANN a confirmé la poursuite du RDRS pour une durée pouvant aller jusqu’à deux ans au-delà du pilote, soit jusqu’en décembre 2027, pendant que la communauté poursuit les travaux d’alignement et les choix de trajectoire.
Sur le terrain, trois effets dominent :
• Continuité : les titulaires de droits et les services d’enquête conservent un canal opérationnel de demande, au lieu d’une extinction à la fin du pilote.
• Accélération de l’adoption : le conseil a encouragé une utilisation « la plus complète possible » par les demandeurs et les bureaux d’enregistrement, sans imposer à ce stade une obligation générale.
• Alignement de politiques : l’ICANN a ouvert une consultation publique sur l’Analyse de l’harmonisation des politiques du service de demande de données d’enregistrement (RDRS), conçu comme une feuille de route pour traiter des écarts structurants (accès aux données sous-jacentes en cas de privacy/proxy, délais pour demandes urgentes, authentification, etc.).

Ce que l’ICANN84 à Dublin a mis en évidence : les points de friction réels

L’ICANN84 s’est déroulé à Dublin du 25 au 30 octobre 2025 et a mis en lumière une réalité : le RDRS est utile, mais incomplet, et ses points faibles recoupent précisément les besoins de prévisibilité des titulaires de droits et des autorités.

La participation volontaire crée des angles morts structurels

La participation n’étant pas universelle, l’écosystème demeure fragmenté. Le GAC a notamment souligné que l’optionnalité se traduisait, au mieux, par une couverture d’environ 60 % des gTLD sous gestion accessibles via RDRS, ce qui réduit mécaniquement l’intérêt du service comme « canal unique ».

L’authentification, notamment des autorités, est un verrou

La question revient systématiquement : qui est le demandeur et peut-on s’appuyer sur cette identité suffisamment vite pour les cas urgents ? Les communications ICANN évoquent un travail en cours sur un protocole d’authentification des autorités pendant la période de prolongation.

L’intégration technique et l’efficacité de workflow sont déterminantes

Les bureaux d’enregistrement déjà dotés de procédures de divulgation éprouvées refusent une duplication des flux. La tendance est donc à l’intégration technique (notamment via API), permettant d’absorber les demandes RDRS dans les outils internes, de réduire le traitement manuel et d’améliorer la cohérence des délais, sans imposer une interface unique à tous.

RDRS vs SSAD : pourquoi la distinction est décisive pour la stratégie et la conformité ?

Le SSAD (System for Standardised Access/Disclosure) n’est pas un synonyme du RDRS. Le SSAD est un dispositif de politique issu de la Phase 2 de l’EPDP, structuré autour de 18 recommandations interdépendantes (accréditation, critères d’accès, exigences de réponse, journalisation, audit, niveaux de service, etc.).
Les travaux d’évaluation de la conception opérationnelle montrent pourquoi le SSAD est resté complexe et coûteux à mettre en œuvre, et pourquoi la communauté teste désormais ce qui peut être amélioré de manière incrémentale via le RDRS pendant que les arbitrages de politique se poursuivent.
Conclusion pratique : le RDRS est le « pont » opérationnel jusqu’en 2027 ; le SSAD (ou un successeur) est l’éventuelle « autoroute ». Il faut planifier l’évolution, pas la stabilité.

Protection des données en Europe : comment la logique RGPD structure les décisions de divulgation ?

Pour les acteurs européens, la décision de divulgation est rarement « purement politique » : il s’agit d’une analyse de risque juridique fondée sur les principes RGPD (base légale, nécessité, proportionnalité, transparence, minimisation, durée de conservation, responsabilité).

Base légale et test de l’« intérêt légitime »

Dans la plupart des cas portés par des titulaires de droits, la demande s’inscrit dans la logique de l’intérêt légitime (article 6(1)(f) RGPD), qui suppose : (i) un intérêt légitime, (ii) la nécessité du traitement, (iii) une mise en balance avec les droits et attentes raisonnables de la personne concernée. La doctrine et les ressources françaises, notamment CNIL, s’appuient régulièrement sur cette grille.

Un DNS mondial, des seuils juridiques locaux

Un même nom de domaine peut impliquer un bureau d’enregistrement dans un pays, un réservataire dans un autre, et un dommage réparti sur plusieurs marchés. Le RDRS standardise les entrées, mais n’unifie pas les seuils juridiques : les résultats resteront variables tant que des standards opposables (SLA, authentification, délais) ne seront pas stabilisés.
Point de comparaison utile en France : la logique de divulgation AFNIC
Même si le RDRS vise les gTLD, les praticiens français connaissent déjà des mécanismes structurés de levée d’anonymisation au niveau ccTLD. L’AFNIC illustre qu’un triptyque « demande structurée + preuves + intérêt légitime » peut fonctionner, tout en demeurant très dépendant des faits.

Les impacts opérationnels selon les parties prenantes

Bureaux d’enregistrement et registres : se préparer à une pression de standardisation

• L’absence de participation peut exposer à un décalage opérationnel et réputationnel au regard de l’orientation « adoption large » portée par l’ICANN, même avant toute bascule vers une obligation.
• La différenciation se jouera sur la maturité : qualité d’instruction des demandes, critères documentés, circuits d’escalade pour l’urgence, capacité d’intégration technique.
Pour aller plus loin, nous vous invitons à consulter notre analyse des mesures de politique relatives aux données d’enregistrement ICANN et de leurs impacts.

Titulaires de droits et enquêteurs : utiliser le RDRS comme un canal parmi d’autres

Le RDRS est utile, mais non exclusif. Nous recommandons de le traiter comme :
• Un canal standardisé de première intention pour les gtld ;
• Un outil de constitution de dossier, renforçant les démarches ultérieures (takedown, escalade de bureaux d’enregistrement, UDRP/URS, mesures judiciaires) en cas de refus ou de lenteur.
Pour aller plus loin, nous vous invitons à consulter notre guide complet sur l’UDRP, Syreli et les alternatives internationales.

Services privacy/proxy : s’attendre à un resserrement des marges de manœuvre

L’un des sujets les plus sensibles porte sur l’accès aux données sous-jacentes derrière les services de privacy/proxy, et sur la manière dont ces demandes doivent s’intégrer à une architecture standardisée. Les travaux d’alignement relient explicitement l’évolution RDRS aux chantiers privacy/proxy.

Directions juridiques et groupes internationaux : anticiper la gouvernance interne

Les organisations mondiales devront cadrer :
• Qui a mandat pour déposer des demandes RDRS ;
• Quel niveau de preuves est requis (fraude, usurpation, phishing, atteinte consommateurs) ;
• Comment tracer, conserver et auditer les demandes et les données reçues pour répondre aux exigences internes de conformité.

Conclusion

Le Service de demande de données d’enregistrement de l’ICANN (ou « Registration Data Request Service » (RDRS)) n’est plus une expérimentation marginale : maintenu jusqu’en décembre 2027, il devient le principal pont opérationnel pour les demandes de données d’enregistrement non publiques relatives aux gTLD, pendant que la communauté débat d’un durcissement éventuel (obligation, authentification, SLA). En Europe, la performance reposera sur des preuves solides, une qualification juridique disciplinée de la demande et une stratégie d’exécution séquencée, robuste même en cas de refus de divulgation.

Le cabinet Dreyfus et Associés accompagne ses clients dans la gestion de dossiers de propriété intellectuelle complexes, en proposant des conseils personnalisés et un soutien opérationnel complet pour la protection intégrale de la propriété intellectuelle.

Le Cabinet Dreyfus et Associés est en partenariat avec un réseau mondial d’avocats spécialisés en Propriété Intellectuelle.

Nathalie Dreyfus avec l’aide de toute l’équipe du cabinet Dreyfus

FAQ

1) Le RDRS remplace-t-il le WHOIS/RDDS ?

Non. Le WHOIS/RDDS reste le système de consultation des données d’enregistrement (souvent partiellement masquées), tandis que le RDRS est un canal distinct pour déposer des demandes de divulgation.

2) Le RDRS permet-il d’obtenir automatiquement les données WHOIS non publiques ?

Non. Il n’y a aucune divulgation automatique : chaque demande est analysée par le bureau d’enregistrement au cas par cas, au regard du cadre juridique applicable et des preuves fournies.

3) Qu’est-ce que le SSAD et en quoi diffère-t-il du RDRS ?

Le SSAD est l’architecture de politique proposée par la Phase 2 de l’EPDP, incluant des recommandations sur l’accréditation, les critères d’accès, les exigences de réponse, l’audit et les SLA. Le RDRS est un service pilote opérationnel qui collecte des données d’usage et de l’expérience pendant que ces choix de politique restent débattus.

4) Pourquoi l’authentification des autorités est-elle un point central ?

Parce que les demandes urgentes et transfrontalières nécessitent de vérifier de manière fiable l’identité du demandeur, afin de soutenir des délais de traitement compatibles avec la lutte contre la fraude et les atteintes graves.

5) Comment les titulaires de droits dans l’UE doivent-ils cadrer une demande RDRS au regard du RGPD ?

Les demandes doivent être strictement proportionnées, étayées par des preuves, et articulées autour d’une base légale (souvent l’intérêt légitime), de la nécessité et d’une mise en balance documentée.

6) Si le RDRS échoue, quelles alternatives rapides permettent de stopper un abus ?

Selon les faits, il est possible d’engager des démarches d’abus auprès des bureaux d’enregistrement et/ou des hébergeurs, de solliciter la désactivation des contenus sur les plateformes concernées, et, lorsque l’objectif est la suspension ou le transfert du nom de domaine, d’envisager une procédure UDRP/URS ou les mécanismes propres au ccTLD applicable.

Cette publication a pour objet de fournir des orientations générales au public et de mettre en lumière certaines problématiques. Elle n’a pas vocation à s’appliquer à des situations particulières ni à constituer un conseil juridique.