Skip to main content
Resources

Procédure révisée de l’ICANN pour le traitement des conflits entre les services d’annuaire de données d’enregistrement et les lois en matière de vie privée

Veuillez noter que seule la version anglaise des contenus et des documents traduits a un caractère officiel. Les traductions dans d'autres langues sont fournies uniquement à titre informatif.

Actualisée le 21 février 2024 pour intégrer les modifications indispensables à l’application de la Politique relative aux données d’enregistrement, la présente politique était précédemment connue sous le nom de Procédure révisée de l’ICANN pour le traitement des conflits entre le WHOIS et les lois en matière de vie privée. Les parties contractantes peuvent commencer à mettre en œuvre cette Politique révisée à partir du 21 août 2024, la mise en œuvre complète devant être achevée au plus tard le 21 août 2025.

Date de prise d’effet : 18 avril 2017

Consulter la version avec suivi des modifications de la Procédure révisée de traitement des conflits liés au RDDS.

Pour en savoir plus sur les données d’enregistrement, consulter la page dédiée aux données d’enregistrement sur le site web de l’ICANN.

Introduction et informations générales

0.1 En décembre 2003, [1] la Deuxième équipe spéciale WHOIS de la GNSO a recommandé l’élaboration d’une procédure permettant aux opérateurs de registre et bureaux d’enregistrement gTLD de signaler les cas où, en vertu de lois locales, ils seraient dans l’impossibilité de satisfaire pleinement aux dispositions des contrats de l’ICANN relatives aux données à caractère personnel du WHOIS.

0.2 En novembre 2005[2], la GNSO a achevé un processus d’élaboration de politiques consacré à la création de ladite procédure. Celui-ci faisait suite à la « recommandation bien fondée de mise en place d’une procédure », formulée par l’Équipe spéciale WHOIS et approuvée par le conseil de la GNSO. [3] En mai 2006, le Conseil d’administration de l’lCANN [4] a adopté la politique et demandé au personnel de l’ICANN d’élaborer et de publier une procédure pour le traitement des conflits.

0.3 Le 3 décembre 2006, le personnel de l’ICANN a publié une version préliminaire de la procédure de l’ICANN pour le traitement des conflits entre le WHOIS et la loi en matière de vie privée [insérer une note de bas de page, https://gnso.icann.org/issues/whois-privacy/whois_national_laws_procedure.htm]. L’ICANN a sollicité les contributions du Comité consultatif gouvernemental (GAC) sur cette version préliminaire. Le libellé du point 1.4 ci-après a été révisé et modifié.

0.4 Le 5 octobre 2015, le Groupe consultatif sur la mise en œuvre consacré aux conflits entre le WHOIS et le droit national1 a publié son rapport, dressant une liste d’améliorations possibles à ladite procédure. Ce rapport a été soumis à commentaire public du 5 octobre au 17 novembre 2015. Le rapport final a été soumis au conseil de la GNSO pour examen lors de la réunion de celui-ci de mai 2016.

0.5 La procédure qui suit explique comment l’ICANN répondra aux cas où un bureau d’enregistrement/opérateur de registre [5] indique être, en vertu de lois ou régulations locales/nationales en matière de vie privée, dans l’impossibilité de satisfaire aux dispositions du contrat de l’ICANN relatives à la collecte, à l’affichage et à la diffusion de données personnelles via le Service d’annuaire de données d’enregistrement (« RDDS »). L’utilisation de cette procédure est réservée au personnel de l’ICANN. Si la procédure prévoit des mesures possibles pour les opérateurs de registre ou bureaux d’enregistrement gTLD concernés, elle n’introduit aucune nouvelle exigence pour ces derniers ni pour aucun tiers. Elle vise à communiquer aux opérateurs de registre, bureaux d’enregistrement et autres la démarche qui sera suivie en cas de conflit entre les exigences contractuelles de l’ICANN en matière de RDDS et d’autres obligations légales.

Première étape :

  1. notification de procédure RDDS

    1.1 Lorsqu’un opérateur de registre ou bureau d’enregistrement est notifié de l’existence d’une enquête, poursuite judiciaire, procédure réglementaire ou autre action en justice publique ou civile, susceptible de les empêcher de satisfaire aux dispositions du contrat d’accréditation de bureau d’enregistrement (RAA) ou autre accord contractuel passé avec l’ICANN relatives à la collecte, l’affichage ou la diffusion de données d’identification par le biais du Service d’annuaire de données d’enregistrement (Procédure RDDS), ils doivent, dans les plus brefs délais, fournir au personnel de l’ICANN les éléments suivants :

    • une brève description de la nature et du statut de l’action (enquête, instruction, contentieux, menace de sanctions, etc.) ainsi que des résultats possibles ;
    • les coordonnées du responsable officiellement chargé de résoudre le problème au sein du bureau d’enregistrement ou opérateur de registre ;
    • le cas échéant, les coordonnées de l’autorité publique territoriale responsable ou autre partie requérante, ainsi qu’une déclaration du bureau d’enregistrement ou opérateur de registre autorisant l’ICANN à communiquer avec lesdites autorités ou parties requérantes concernant l’affaire. Dans l’éventualité où le droit applicable empêche le bureau d’enregistrement ou opérateur de registre d’accorder ladite autorisation, la notification doit inclure, d’une part,
    • le texte de la disposition législative ou réglementaire sur laquelle se fonde l’action ou l’enquête de l’autorité locale ou autre partie requérante, lorsque ledit texte a été indiqué par cette instance ou partie,
    • et de l’autre, une description des efforts déployés pour satisfaire à la fois aux lois locales et aux obligations à l’égard de l’ICANN.

    1.2 Le respect de l’exigence de notification permet au bureau d’enregistrement ou opérateur de registre de participer aux enquêtes et de répondre aux décisions de justice, régulations et autorités d’application des lois de la manière et dans les délais jugés appropriés par ses conseillers juridiques.

    1.3 En fonction des circonstances spécifiques de la procédure relative au RDDS, l’opérateur de registre ou bureau d’enregistrement peut demander à l’ICANN de garder confidentielle toute correspondance entre les parties en attendant l’issue de la procédure RDDS. L’ICANN donnera généralement une suite favorable à ce type de demandes lorsqu’elles n’interfèrent pas avec d’autres responsabilités qui lui incombent au regard de la loi et avec les principes de transparence applicables aux opérations de l’ICANN.

    1.4 Un bureau d’enregistrement ou opérateur de registre faisant l’objet d’une procédure RDDS devrait se concerter avec les autorités nationales concernées afin d’assurer sa conformité aux lois et régulations locales, au droit international et aux conventions internationales applicables.

  2. Autre déclencheur possible : déclaration écrite d’une instance publique

    1.5 En l’absence de procédure RDDS, un opérateur de registre ou bureau d’enregistrement peut communiquer à l’ICANN une déclaration écrite de l’instance :

    • (a) précisant les faits à l’examen, à savoir,
      • (i) la partie contractante spécifique concernée (opérateur de registre ou bureau d’enregistrement) ;
      • (ii) les conditions de service/accords d’enregistrement applicables que l’instance a examinés ;
      • (iii) les dispositions applicables du contrat ICANN visé ;
      • (iv) la loi applicable qu’elle a analysée ;
    • (b) énonçant et analysant les incohérences constatées par l’instance entre le droit national et les obligations contractuelles, en spécifiant les dispositions légales ou contractuelles en cause ; et
    • (c) certifiant que l’instance est légalement habilitée à faire appliquer la loi nationale qu’elle a jugée incompatible avec les obligations contractuelles, et qu’elle est compétente à l’égard de la partie contractante aux fins d’une telle application.

Deuxième étape : consultation

2.1 Le processus de consultation a pour but de résoudre le problème tout en préservant au mieux la capacité du bureau d’enregistrement ou opérateur de registre à satisfaire à ses obligations contractuelles relatives au RDDS.

2.1.1 À moins que cela ne soit impossible dans la pratique, l’ICANN contactera le bureau d’enregistrement ou opérateur de registre dès réception et examen de la notification. Lorsque les circonstances s’y prêtent, l’ICANN se concertera, le cas échéant, avec les autorités locales/nationales d’application de la loi ou autre partie requérante, ainsi qu’avec le bureau d’enregistrement ou opérateur de registre.

2.1.2 Conformément à la recommandation du Comité consultatif gouvernemental de l’ICANN, l’ICANN sollicitera l’avis du gouvernement concerné quant au bien-fondé de la demande de dérogation aux exigences de l’ICANN relatives au RDDS.

2.2 Lorsque la procédure RDDS s’achève sans nécessiter de modifications dans les pratiques du bureau d’enregistrement ou opérateur de registre, ou lorsque lesdites modifications ne constituent pas, de l’avis de l’ICANN, un écart par rapport au RAA ou autres obligations contractuelles, aucune autre mesure n’est requise de la part de l’ICANN et du bureau d’enregistrement ou opérateur de registre.

2.3 Lorsque le bureau d’enregistrement ou opérateur de registre est contraint par les autorités locales d’application de la loi ou par une autorité judiciaire locale d’introduire à ses pratiques, avant qu’un processus de consultation n’ait pu se dérouler, des modifications de nature à affecter ses obligations contractuelles relatives au RDDS, le bureau d’enregistrement ou opérateur de registre devrait rapidement informer l’ICANN des modifications introduites ainsi que des lois/régulations sur lesquelles elles se fondent.

2.4 Le bureau d’enregistrement ou opérateur de registre peut demander à l’ICANN de garder confidentielle toute correspondance entre les parties en attendant l’issue de la procédure RDDS. L’ICANN donnera généralement une suite favorable à ce type de demandes lorsqu’elles n’interfèrent pas avec d’autres responsabilités qui lui incombent au regard de la loi et avec les principes de transparence applicables aux opérations de l’ICANN.

2.5 Dans les cas où l’autre déclencheur possible s’applique, l’étape de consultation comprend une consultation publique au cours de laquelle toutes les parties intéressées peuvent examiner la déclaration écrite émise lors de l’étape de notification et formuler des observations sur tout aspect de celle-ci. Dans de tels cas, l’ICANN consultera également le représentant au GAC du pays en question (le cas échéant), conformément à la section 2.1.2 de la procédure.

Troisième étape : analyse et recommandation du Conseiller juridique

3.1 Lorsque la Procédure RDDS aboutit (avant, pendant ou après le processus de consultation décrit ci-haut) à des modifications qui, de l’avis du Conseiller juridique de l’ICANN, font obstacle au respect des obligations contractuelles en matière de RDDS, le personnel de l’ICANN peut, à titre provisoire, s’abstenir de prendre des mesures contre le bureau d’enregistrement ou l’opérateur de registre pour non-respect des dispositions contractuelles, en attendant que l’ICANN prépare un rapport public avec des recommandations au Conseil d’administration pour décision. Avant la publication du rapport, le bureau d’enregistrement ou opérateur de registre peut demander l’expurgation de certaines informations (entre autres, les communications entre l’opérateur de registre/le bureau d’enregistrement et l’ICANN, ainsi que d’autres informations protégées/confidentielles). Le Conseiller juridique peut, par ailleurs, expurger de la version publique du rapport des informations concernant l’avis juridique reçu par l’ICANN ou l’avis rendu par le conseiller juridique de l’ICANN, dont la publication, à ses yeux, devrait être limitée en raison de leur nature protégée ou des risques éventuels qui en découlent pour l’ICANN. Le rapport peut contenir ce qui suit :

  1. une synthèse de la loi ou régulation concernée par le conflit ;
  2. le détail des obligations contractuelles relatives au RDDS auxquelles l’opérateur de registre ou bureau d’enregistrement ne peut pleinement se conformer ;
  3. le résumé du processus de consultation qui s’est déroulé, le cas échéant, dans le cadre de la deuxième étape ; et
  4. une recommandation sur la meilleure solution à apporter au problème, indiquant notamment si l’ICANN devrait accorder au bureau d’enregistrement ou opérateur de registre concerné par le conflit une dérogation à certaines dispositions contractuelles relatives au RDDS. Le rapport devrait inclure une justification détaillée de ladite recommandation, notamment l’effet prévu sur la stabilité, la fiabilité, la sécurité opérationnelle et l’interopérabilité mondiale du système d’identificateurs uniques d’Internet en cas d’adoption ou de refus de la recommandation.

3.2 Le bureau d’enregistrement ou opérateur de registre sera fourni une opportunité raisonnable de présenter un commentaire au Conseil d’administration. Il peut demander à l’ICANN de garder ledit rapport confidentiel en attendant une résolution du Conseil d’administration. L’ICANN donnera généralement une suite favorable à ce type de demandes lorsqu’elles n’interfèrent pas avec d’autres responsabilités qui lui incombent au regard de la loi et avec les principes de transparence applicables aux opérations de l’ICANN.

3.3 Dans les cas où l’autre déclencheur possible s’applique, le Conseil d’administration prendra en considération tout commentaire public reçu sur la déclaration écrite émise lors de l’étape de notification, ainsi que toute contribution reçue du représentant au GAC du pays en question (le cas échéant), conformément à la section 2.1.2 de la procédure.

Quatrième étape : résolution

4.1 Le Conseil d’administration examine le dossier en tenant compte de l’effet prévu sur la stabilité, la fiabilité, la sécurité opérationnelle et l’interopérabilité mondiale des systèmes d’identificateurs uniques d’Internet, et prend une décision appropriée dès que possible, en se fondant sur les recommandations contenues dans le rapport du Conseiller juridique. Le Conseil d’administration peut, entre autres :

  • approuver ou refuser les recommandations du rapport, avec ou sans modifications ;
  • demander des renseignements complémentaires au bureau d’enregistrement ou opérateur de registre concerné, ou à des tiers ;
  • établir une période de consultation publique sur le rapport ; ou
  • envoyer le rapport à la GNSO pour examen et commentaires dans un délai déterminé.

Cinquième étape : avis au public

5.1 La décision du Conseil d’administration, assortie du rapport du Conseiller juridique, est normalement publiée et archivée sur le site web de l’ICANN (avec tout autre document pertinent) à des fins de recherche ultérieure. Avant la publication de ces informations, le bureau d’enregistrement ou opérateur de registre peut demander d’expurger certaines parties de l’avis au public (entre autres, les communications entre l’opérateur de registre/bureau d’enregistrement et l’ICANN, ainsi que d’autres informations protégées/confidentielles). Le Conseiller juridique peut, par ailleurs, expurger de la version publique du rapport des informations concernant l’avis juridique reçu par l’ICANN ou l’avis rendu par le conseiller juridique de l’ICANN, dont la publication, à ses yeux, devrait être limitée en raison de leur nature protégée ou des risques éventuels qui en découlent pour l’ICANN. Si lesdites expurgations rendent difficile la transmission au public de la nature des mesures mises en œuvre par le bureau d’enregistrement ou opérateur de registre, l’ICANN veillera à fournir au public un avis approprié qui, dans la mesure du possible compte tenu des circonstances, expose les mesures prises et leur fondement.

5.2 Sauf décision contraire du Conseil d’administration, lorsque la résolution du conflit aboutit à la suppression ou à une moindre disponibilité de certains éléments de données de l’opérateur de registre ou bureau d’enregistrement dans le RDDS, l’ICANN publiera un avis communiquant au public la décision ainsi que les raisons ayant amené l’ICANN à accepter une telle dérogation à la disposition contractuelle visée.

Sixième étape : examen continu

6.1 L’ICANN examinera annuellement l’efficacité du processus, en tenant compte des retours d’information des opérateurs de registre et bureaux d’enregistrement concernés, ainsi que de toutes les unités constitutives de l’ICANN.


[1] Deuxième équipe spéciale WHOIS, Rapport préliminaire, juin 2004 ; https://gnso.icann.org/issues/whois-privacy/Whois-tf2-preliminary

[2] Procès-verbal du conseil de la GNSO, 28 novembre 2005 ; https://gnso.icann.org/meetings/minutes-gnso-28nov05

[3] Rapport final de l’équipe spéciale WHOIS de la GNSO, 2  octobre 2005 ; https://gnso.icann.org/issues/tf-final-rpt-25oct05.htm

[4] Procès-verbal du Conseil d’administration, 10 mai 2006 ; https://www.icann.org/minutes/minutes-10may06.htm

[5] Dans le présent document, toute référence aux « opérateurs de registre » couvre les opérateurs de registre et les organismes parrains.


1 https://community.icann.org/display/WNLCI/WHOIS+and+national+law+conflicts+IAG+Home

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."