--- id: "disclosure-request" kind: "glossary-term" title: "demande de divulgation" language: "fr" category: "Données d'enregistrement et vie privée" updated: "2026-10-10T23:12:43Z" canonical: "https://tldlog.com/fr/glossaire/demande-divulgation/" translations: en: "https://tldlog.com/glossary/disclosure-request/" es: "https://tldlog.com/es/glosario/solicitud-divulgacion/" de: "https://tldlog.com/de/glossar/offenlegungsantrag/" it: "https://tldlog.com/it/glossario/richiesta-divulgazione/" pt-BR: "https://tldlog.com/pt/glossario/solicitacao-divulgacao/" ru: "https://tldlog.com/ru/glossariy/zapros-raskrytie-dannykh/" zh-Hans: "https://tldlog.com/zh/cihui/pilu-qingqiu/" --- # demande de divulgation Demande adressée à un bureau d'enregistrement ou à un registre pour obtenir des données d'enregistrement soustraites à la vue du public, comme le nom ou l'adresse électronique du titulaire. Le demandeur, par exemple la police ou un avocat spécialisé en marques, explique pourquoi il en a besoin. Le bureau d'enregistrement ou le registre décide de les divulguer ou non. Une demande de divulgation permet de demander les informations sur le titulaire d'un nom de domaine qui sont masquées au public, comme un nom ou une adresse électronique. La demande est adressée à l'entreprise qui vend ou gère le nom de domaine et doit préciser qui la fait et pourquoi. C'est cette entreprise, et non l'ICANN, qui décide de communiquer ou non les données. ## Ce qu'est une demande de divulgation Depuis 2018, en application de la spécification temporaire relative aux données d'enregistrement des gTLD (Temporary Specification for gTLD Registration Data), une grande partie des données personnelles des enregistrements de gTLD est masquée (accès par niveaux). Aujourd'hui, la matière est régie par la Politique relative aux données d'enregistrement (Registration Data Policy), en vigueur depuis le 21 août 2025 et révisée le 12 mai 2026 : les bureaux d'enregistrement et les registres doivent masquer les données personnelles lorsque la loi l'exige, et peuvent le faire dans certains autres cas. L'ICANN désigne officiellement ces demandes sous le nom de Reasonable Requests for Lawful Disclosure (demandes raisonnables de divulgation licite). La demande est adressée au bureau d'enregistrement ou à l'opérateur de registre, et celui qui la reçoit décide. L'ICANN ne prend pas la décision et ne la réexamine pas. ## Qui peut demander et pour quels motifs Tout le monde peut faire une demande. En octobre 2026, une demande doit contenir au moins : - l'identité, les coordonnées et la catégorie du demandeur (entreprise ou particulier), avec la preuve de son pouvoir lorsqu'il agit pour le compte d'un tiers ; - les éléments de données souhaités ; - les droits du demandeur et le motif précis de la demande ; - une déclaration de bonne foi et l'engagement de traiter les données de manière licite. Le bureau d'enregistrement ou le registre doit examiner chaque demande correctement formulée au cas par cas. Lorsque la loi l'exige, il met en balance l'intérêt légitime du demandeur et les droits du titulaire, et il peut tenir compte d'autres facteurs, comme la juridiction. Pendant la phase pilote du RDRS, les titulaires de droits de propriété intellectuelle ont envoyé 1 202 des 3 721 demandes, et les forces de l'ordre 605. En octobre 2026, dans l'Union européenne (UE), l'article 28, paragraphe 5, de la directive NIS2 impose aux États membres de veiller à ce que les registres de TLD et les bureaux d'enregistrement fournissent des données d'enregistrement précises aux demandeurs d'accès légitimes, sur demande licite et dûment motivée, dans le respect du droit de l'UE sur la protection des données, et répondent dans un délai de 72 heures. ## Comment envoyer une demande, étape par étape Pour un nom en gTLD, en octobre 2026 : 1. Consulter les données publiques avec ICANN Lookup, pour confirmer que les données sont masquées et identifier le bureau d'enregistrement. 2. Suivre la procédure du bureau d'enregistrement. Chaque bureau d'enregistrement et chaque registre doit proposer, depuis sa page d'accueil, un lien vers une page indiquant le format des demandes, le mode d'envoi des réponses et le délai prévu. 3. Ou utiliser le RDRS (Registration Data Request Service, service de demande de données d'enregistrement), gratuit, qui nécessite un compte ICANN. Le demandeur choisit une catégorie, décrit ce qu'il souhaite, peut joindre jusqu'à cinq fichiers PDF de 5 Mo chacun au plus, et s'engage à respecter le droit de la protection des données. 4. Si le bureau d'enregistrement ne participe pas, le RDRS permet au demandeur d'enregistrer le formulaire en PDF pour l'envoyer directement. Dans tous les cas, la divulgation éventuelle a lieu en dehors du RDRS, selon la méthode choisie par le bureau d'enregistrement. En octobre 2026, le RDRS est facultatif pour les bureaux d'enregistrement. À la fin de sa phase pilote, en novembre 2025, les bureaux d'enregistrement participants couvraient 46 % des noms de domaine gérés. Le Conseil d'administration de l'ICANN l'a prolongé de deux ans au plus : jusqu'en décembre ou en novembre 2027, selon le document de l'ICANN. Le RDRS ne couvre pas les ccTLD et ne permet pas de déposer une plainte UDRP. Les ccTLD appliquent leurs propres règles et leur propre droit ; le demandeur s'adresse donc au registre. EURid, par exemple, propose un formulaire pour les données du .eu. Le registre du .es n'est lié ni par la politique de l'ICANN ni par le RDRS ; pour un nom en .es, il convient donc de se renseigner auprès de Red.es ou d'un avocat. ## Délais de réponse et demandes urgentes En octobre 2026, un bureau d'enregistrement ou un registre doit accuser réception d'une demande correctement formulée dans un délai de 2 jours ouvrables et y répondre dans un délai de 30 jours calendaires après l'accusé de réception, sauf circonstances exceptionnelles. Pendant la phase pilote du RDRS, les approbations ont pris 7 jours en moyenne et les refus 17. L'option Expedited (accélérée) du RDRS n'oblige pas le bureau d'enregistrement à se hâter : pendant la phase pilote, 169 des 220 demandes de ce type ont été requalifiées en demandes standard, et en cas d'urgence l'ICANN conseille aux demandeurs de ne pas s'y fier et de contacter directement le bureau d'enregistrement. Les demandes urgentes ont été ajoutées à la politique le 12 mai 2026. Elles ne peuvent émaner que d'une autorité chargée de l'application de la loi ou d'une autre autorité de confiance authentifiée, en cas de menace imminente pour la vie, de lésions corporelles graves, de menace pour une infrastructure critique ou d'exploitation d'enfants. La réponse serait due dans les 24 heures, délai pouvant être prolongé sur justification jusqu'à 72 heures au plus après réception. En octobre 2026, cette règle n'est pas en vigueur : elle ne s'appliquera qu'une fois que l'ICANN aura mis en œuvre une politique d'authentification des demandeurs. L'ICANN prépare un test avec les forces de l'ordre, auquel participent INTERPOL et le Federal Bureau of Investigation (FBI) des États-Unis. En octobre 2026, le RAA impose à chaque bureau d'enregistrement de gTLD de disposer d'un contact pour les abus surveillé en permanence à l'intention des autorités de son propre pays, et d'examiner leurs signalements fondés dans les 24 heures : il s'agit de signalements, et non de divulgation. ## En cas de refus Un refus doit être motivé de manière précise et, lorsque cette mise en balance s'applique, expliquer comment les droits du titulaire ont été mis en balance avec l'intérêt du demandeur. Les refus sont fréquents. Entre son lancement et le 30 juin 2026, le RDRS a enregistré 4 275 demandes : 1 072 approuvées et 2 540 refusées. Pendant la phase pilote, les motifs les plus courants étaient que la loi interdisait la divulgation et que la demande était incomplète. Le demandeur peut alors envoyer une nouvelle demande avec davantage d'informations, ou saisir le service de conformité contractuelle de l'ICANN (ICANN Contractual Compliance) si le bureau d'enregistrement n'a pas répondu ou n'a pas respecté les règles ; l'ICANN ne réexaminera pas la décision elle-même. Le 12 mars 2026, le Conseil d'administration de l'ICANN a décidé de ne pas adopter les 18 recommandations relatives au SSAD (système normalisé d'accès aux données d'enregistrement non publiques et de divulgation) et a invité le Conseil de la GNSO à achever de nouveaux travaux pendant la prolongation du RDRS, qui prend fin en novembre 2027. La participation obligatoire des bureaux d'enregistrement, des niveaux de service pour les réponses et l'authentification des forces de l'ordre sont en discussion ; en octobre 2026, rien n'est décidé. ## Sources - [Registration Data Policy](https://www.icann.org/en/contracted-parties/consensus-policies/registration-data-policy) - [Frequently Asked Questions for the Registration Data Request Service (RDRS) for Requestors](https://www.icann.org/en/system/files/files/rdrs-requestors-faqs-25apr24-en.pdf) - [RDRS Two-Year Pilot Summary Report](https://www.icann.org/en/system/files/files/rdrs-two-year-pilot-summary-report-27feb26-en.pdf) - [Approved Resolutions | Regular Meeting of the ICANN Board | 12 March 2026](https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-12-03-2026-en) ## termes associés - [masquage](https://tldlog.com/fr/glossaire/masquage/) - [RDRS](https://tldlog.com/fr/glossaire/rdrs/) - [Politique relative aux données d'enregistrement](https://tldlog.com/fr/glossaire/politique-relative-donnees-enregistrement/)