Skip to main content
Resources

Mécanismes de responsabilité

Cette page est disponible en:

L'ICANN s'est clairement engagée à adopter des pratiques responsables et transparentes. Les principes de responsabilité et de transparence sont pour l'ICANN des garanties fondamentales pour assurer l'efficacité de son modèle multipartite ascendant. Les mécanismes utilisés par l'ICANN pour assurer la responsabilité et la transparence sont présents à chaque niveau de son organisation et de son mandat ; ces mécanismes sont prévus par ses statuts constitutifs, détaillés dans ses principes et cadres de responsabilité et transparence (adoptés par le Conseil d'administration de l'ICANN en 2008) et renforcés tous les ans dans son plan stratégique et opérationnel. Afin de renforcer sa transparence et sa responsabilité, l'ICANN a défini des mécanismes de responsabilité permettant de contrôler les actions de l'ICANN. Les textes complets des mécanismes de responsabilité sont prévus aux chapitres IV et V des statuts constitutifs de l'ICANN. Voici une synthèse de ces mécanismes.

Processus de réexamen

Le réexamen est un mécanisme prévu par le chapitre IV, article 2 des statuts constitutifs via lequel toute personne ou entité affectée de manière significative par une action (ou inaction) de l'ICANN peut demander une révision ou un réexamen de cette action par le Conseil d'administration.

Toute personne ou entité pourra déposer une demande de réexamen ou de révision d'une action ou inaction de l'ICANN (« Demande de réexamen ») si la personne ou l'entité a été affectée par :

  1. une ou plusieurs actions ou inactions du personnel contraires à la ou aux politiques établies par l'ICANN ; ou
  2. une ou plusieurs actions ou inactions du Conseil d'administration de l'ICANN décidées sans tenir compte d'informations importantes, sauf si la partie qui dépose la demande a omis de soumettre au Conseil d'administration, alors qu'elle aurait pu le faire, ces informations au moment où l'action ou l'inaction a été décidée ; ou
  3. une ou plusieurs actions ou inactions du Conseil d'administration de l'ICANN dont la mise en place a été décidée sur la base d'informations importantes fausses ou inexactes.

Ces conditions doivent être respectées car le processus de réexamen n'est en aucun cas un mécanisme de réexamen d'une action (ou d'une inaction) du seul fait que la personne ou l'entité en question n'est pas d'accord avec l'action (ou l'inaction).

Toutes les demandes de réexamen doivent être soumises dans un délai de quinze jours à compter de :

  1. dans le cas des demandes contestant des actions du Conseil d'administration, la date à laquelle l'action contestée du Conseil d'administration est publiée dans une résolution, à moins que la publication de la résolution ne soit pas accompagnée de fondements. Dans ce cas, la demande doit être présentée dans un délai de 15 jours à compter de la publication initiale des fondements ; ou
  2. dans le cas des demandes concernant des actions du personnel, la date à laquelle la partie soumettant la demande a pris connaissance ou aurait normalement dû prendre connaissance de l'action contestée du personnel ; ou
  3. dans le cas des demandes contestant une inaction du Conseil d'administration ou du personnel, la date à laquelle la personne affectée a raisonnablement conclu, ou aurait normalement dû conclure, que l'action ne serait pas mise en œuvre en temps voulu.

Les demandes de réexamen sont examinées par le Comité de gouvernance du Conseil d'administration (« BGC »). Pour toutes les demandes de réexamen concernant une action ou une inaction du personnel, le Conseil d'administration déléguera au BGC le pouvoir de prendre une décision finale et une recommandation à cet égard. Le Conseil d'administration n'est pas tenu d'examiner la recommandation. Si le BGC l'estime nécessaire, il peut formuler une recommandation qui devra être examinée par le Conseil d'administration et sur la base de laquelle ce dernier prendra une mesure.

Le BGC prendra une décision finale, ou une recommandation, qui sera transmise au Conseil d'administration, dans un délai de trente jours à compter de la réception de la demande de réexamen, sauf si cela est irréalisable. Si le BGC formule une recommandation au Conseil d'administration, ce dernier devra rendre sa décision eu égard à la recommandation du BCG dans un délai de soixante jours à compter de la réception de la demande de réexamen ou le plus tôt possible après la réception.

L'ICANN a indiqué que le processus de réexamen peut parfaitement être engagé afin de contester les décisions d'experts rendues par des panels formés par des fournisseurs de services de règlement de litiges tiers dans le cadre du programme des nouveaux gTLD s'il est allégué que le panel n'a pas suivi les politiques ou processus établis pour rendre sa décision, ou que le personnel n'a pas suivi ses politiques ou processus relatifs à l'acceptation de cette décision.

Pour de plus amples informations sur le processus de réexamen de l'ICANN, veuillez consulter le chapitre IV des statuts constitutifs sur http://www.icann.org/en/about/governance/bylaws#IV, ou la page consacrée au réexamen.

Processus de révision indépendante (IRP)

Outre le processus de réexamen, l'ICANN a également mis en place un processus distinct permettant à un tiers indépendant d'examiner des actions (ou inactions) du Conseil d'administration jugées, par la partie soi-disant lésée, contraires aux statuts constitutifs ou à l'Acte constitutif de l'ICANN. Voir le chapitre IV, article 3 des statuts constitutifs de l'ICANN.

Toute personne affectée de manière significative par une décision ou une action du Conseil d'administration qu'elle juge contraire à l'Acte constitutif ou aux statuts constitutifs de l'ICANN peut soumettre une demande d'examen indépendant de cette décision ou action. Pour être affectée de manière significative, la personne doit subir un préjudice ou un dommage directement lié à, ou présentant un lien de causalité avec, la supposée violation par le Conseil d'administration des statuts constitutifs ou de l'acte constitutif, et qui ne résulte pas d'actions de tiers conformes à l'action du Conseil d'administration.

Une demande d'IRP doit être déposée dans un délai de trente jours à compter de la publication du procès-verbal de la réunion du Conseil d'administration (et, le cas échéant, des documents d'information du Conseil d'administration) qui, selon la partie requérante, démontre que l'ICANN a violé ses statuts constitutifs ou son Acte constitutif. Les demandes d'IRP relatives à une décision du BGC portant sur une demande de réexamen doivent être déposées dans un délai de trente jours à compter de la publication du procès-verbal de la réunion du BGC au cours de laquelle la décision en cause a été prise.

Avant d'engager un processus de révision indépendante, le plaignant est prié d'engager une coopération avec l'ICANN en vue de résoudre ou d'atténuer les problèmes qui pourraient être soumis à l'IRP. Voir http://www.icann.org/en/news/irp/cep-11apr13-en.pdf.

Pour de plus amples informations sur le processus de révision indépendante de l'ICANN, veuillez consulter le chapitre IV, section 3 des statuts constitutifs sur http://www.icann.org/en/about/governance/bylaws#IV, ou la page consacrée au processus de révision indépendante.

Médiateur

Le médiateur de l'ICANN est une personne indépendante, impartiale et neutre dont la fonction consiste à fournir une évaluation interne indépendante des plaintes émanant des membres de la communauté de l'ICANN qui estiment avoir été injustement traités par le personnel de l'ICANN, le Conseil d'administration ou un organe constitutif de l'ICANN eu égard à des questions qui n'ont pas été soumises au processus de réexamen ou au processus de révision indépendante. Le médiateur agit objectivement en faveur de l'équité et cherche à évaluer et, si possible, à résoudre les plaintes relatives à un traitement injuste ou inapproprié de la part du personnel de l'ICANN, du Conseil d'administration ou des organes constitutifs de l'ICANN, en éclaircissant les problèmes et en utilisant des outils de règlement de litiges tels que la négociation, la facilitation et les « navettes diplomatiques » afin d'obtenir des résultats. Voir le chapitre V des statuts constitutifs de l'ICANN.

Le médiateur n'a pas le pouvoir de prendre, modifier ou annuler une politique, une décision administrative ou une décision, un acte ou une omission du Conseil d'administration. Le médiateur a le pouvoir d'enquêter sur ces événements et d'utiliser des méthodes alternatives de règlement de litiges (ADR) pour les résoudre. Le médiateur est autorisé à faire part au Conseil d'administration de la suite donnée à une affaire spécifique, résolue ou non, s'il le juge nécessaire.

Pour de plus amples informations sur le médiateur de l'ICANN, veuillez consulter le chapitre V des statuts constitutifs sur http://www.icann.org/en/about/governance/bylaws#V ou la page du médiateur.

Qu'est-ce que la communauté habilitée ?

La communauté habilitée est le mécanisme à travers lequel les organisations de soutien (SO) et comités consultatifs (AC) de l'ICANN peuvent s'organiser en vertu du droit californien afin d'exercer légalement les pouvoirs communautaires. Les pouvoirs communautaires et les règles qui régissent la communauté habilitée sont définis dans l'acte constitutif et les statuts constitutifs de l'ICANN.

Qui peut participer à la communauté habilitée ?

Toutes les organisations de soutien de l'ICANN, ainsi que le Comité consultatif gouvernemental et le Comité consultatif At-Large, peuvent participer à la communauté habilitée, notamment :

Comment la communauté habilitée fait-elle usage de ses pouvoirs ?

La communauté habilitée dispose d'un processus de signalement d'irrégularités concernant une action ou une inaction du Conseil d'administration de l'ICANN ou de l'organisation ICANN. Ce processus d'escalade donne la possibilité aux SO et AC d'engager des discussions avec le Conseil d'administration de l'ICANN afin de trouver des solutions.

Pour en savoir plus, cliquez ici pour accéder à la page web de la communauté habilitée.

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."