Module 2 Informations générales

L’ICANN, consciente de la complexité inhérente à la série 2026 du programme des nouveaux gTLD, a élaboré des orientations qui visent à répondre aux interrogations éventuelles des candidats. Ce module offre un accès direct à des informations essentielles, ainsi que des liens vers des ressources complémentaires, afin de permettre aux candidats et aux parties prenantes de mieux appréhender le programme.

Le Module 2 présente un aperçu des grands thèmes suivants :

• les langues et la documentation justificative ;

• l’acceptation universelle ;

• la sécurité et la stabilité ;

• la conformité juridique.

Il offre aux candidats un premier point de repère pour toute question d’ordre général.

2.1 Ressources et assistance

Diverses ressources, décrites ci-après, sont mises à disposition pour répondre aux questions relatives à la série 2026 du programme des nouveaux gTLD et à la procédure de candidature.

2.1.1 Foire aux questions

L’ICANN a constitué une série de foires aux questions (FAQ), regroupant les questions fréquemment posées. Ces FAQ présentent pour les candidats un intérêt tout particulier. Elles sont disponibles sur le site Web du programme des nouveaux gTLD.¹

2.1.2 Assistance pour les questions d’ordre général

Pour toute question d’ordre général concernant la série 2026 du programme des nouveaux gTLD, il convient de contacter le Centre international d’assistance de l’ICANN² ou d’adresser un courriel à globalsupport@icann.org.

Le Centre international d’assistance de l’ICANN met par ailleurs à la disposition des candidats des conseillers attitrés chargés de répondre aux questions sur le processus de dépôt de candidatures et de les orienter vers les ressources disponibles.

2.1.3 Système et questions relatives à des candidatures spécifiques

Afin de préserver la sécurité et la confidentialité des données des candidats, les candidats souhaitant poser des questions spécifiques à leur candidature doivent le faire par le biais du système TAMS. Pour soumettre une question dans le système TAMS, cliquez sur le lien « View My Organization » (Afficher mon organisation) dans le menu de gauche de la page d’accueil, qui vous redirigera vers la page « Organization Summary » (Résumé de l’organisation), où vous pourrez alors cliquer sur le bouton « Create Inquiry » (Créer une demande) en haut à droite.

Pour apprendre à créer une demande et pour toute autre information utile sur le système, veuillez consulter le Guide d’utilisation du TAMS, publié sur le site Web du programme des nouveaux gTLD.³

Comme expliqué dans la Section 2.1.2, les questions d’ordre général concernant le programme des nouveaux gTLD doivent être adressées au Centre international d’assistance de l’ICANN (globalsupport@icann.org).

2.2 Langues et documentation justificative

2.2.1 Guide de candidature et documents associés

Le Guide de candidature sera disponible dans les langues de l’ICANN : anglais, arabe, chinois, espagnol, français et russe.⁴ Les différentes traductions sont accessibles depuis la page d’accueil du Guide de candidature.⁵ Il est toutefois important de noter que seule la version anglaise fait foi, tant pour le Guide que pour les documents associés.

2.2.2 Langue des candidatures aux nouveaux gTLD

L’anglais est la principale langue de travail pour toutes les activités de l’ICANN. Tous les documents du dossier de candidature doivent être soumis en anglais, sauf indication contraire expresse indiquée dans une question du dossier de candidature.

2.2.3 Langue des pièces justificatives à fournir pour un dossier de candidature à un nouveau gTLD

S’agissant des pièces justificatives, les candidats sont priés de fournir les documents originaux. Pour tout document original soumis dans une langue autre que l’anglais, les candidats sont tenus de fournir :

1. le document original ;

2. la traduction anglaise de chaque document ;

3. un certificat d’exactitude de la traduction pour chaque document.

Le certificat d’exactitude de la traduction doit être rédigé en anglais et comporter les éléments suivants :

1. les qualifications du traducteur ;

2. une attestation d’exhaustivité et de conformité à l’original ;

3. l’identification et la langue d’origine du document traduit ;

4. le nom du traducteur, sa signature et la date.

La plupart des traducteurs professionnels ou agences de traduction sont en mesure d’établir un certificat d’exactitude, lequel n’a pas besoin d’être notarié. Un exemple de certificat d’exactitude de traduction est disponible sur le site Web de l’American Translators Association.⁶

La soumission de traductions certifiées en bonne et due forme peut accélérer l’examen et le traitement des documents.

2.3 Acceptation universelle des noms de domaine et des adresses de courrier électronique

L’acceptation universelle (UA) est un principe fondamental selon lequel l’ensemble des applications, dispositifs et systèmes connectés à Internet devraient pouvoir prendre en charge tous les noms de domaine et toutes les adresses de courrier électronique, quels que soient le script, la langue ou la longueur d’un TLD. Ce principe permet aux internautes de naviguer et de communiquer en ligne en utilisant des noms de domaine et des adresses de courrier électronique qui correspondent à leurs préférences culturelles et linguistiques.

2.3.1 Avis concernant les enjeux de l’acceptation universelle des noms de domaine et des adresses de courrier électronique dans les nouveaux gTLD

Il importe que tous les candidats comprennent que l’approbation de l’ICANN et la signature d’un contrat de registre ne garantissent pas une prise en charge immédiate et universelle du nom de domaine sur Internet. L’expérience montre en effet que les opérateurs de réseau ne prennent pas toujours en charge, immédiatement et pleinement, les nouveaux domaines de premier niveau, même lorsque ces domaines ont été délégués dans la zone racine du DNS, l’adaptation de logiciels tiers pouvant être nécessaire. De même, certaines applications logicielles peuvent parfois ne pas reconnaître des domaines de premier niveau nouveaux ou inconnus lorsqu’elles tentent de valider un nom de domaine.

N’étant pas en mesure d’imposer l’acceptation des nouveaux domaines de premier niveau par les logiciels, l’ICANN la facilite par la mise à disposition de ressources. Elle publie la liste des domaines de premier niveau valides et a élaboré un outil de base permettant aux fournisseurs d’applications d’utiliser les données actualisées de la zone racine. Les candidats sont invités à se familiariser avec ces difficultés potentielles d’intégration et à en tenir compte dans leurs plans de démarrage et de lancement. Les candidats retenus pourraient être amenés à déployer des efforts considérables auprès des fournisseurs afin de garantir l’acceptation du gTLD faisant l’objet de leur candidature.

Pour de plus amples informations, les candidats sont invités à consulter la page Web consacré à l’acceptation universelle⁷ . Les candidats à des noms de domaine internationalisés (IDN) sont encouragés à examiner les documents relatifs aux expériences menées dans la zone racine avec des chaînes IDN d’essai.⁸

2.3.2 Informations détaillées sur l’acceptation universelle

L’ICANN et la communauté œuvrent à faire progresser l’état de préparation à l’UA dans tout l’écosystème Internet. L’ICANN communique des informations détaillées à ce sujet sur la page Web consacrée à l’acceptation universelle, qui contient également le dernier rapport annuel sur l’état de préparation à l’UA. Ce rapport dresse un état des lieux de la compatibilité technologique avec l’UA, notamment au niveau des langages de programmation, des outils et services de messagerie électronique, des utilitaires de réseau, des applications de réseaux sociaux, des systèmes de gestion de contenu et des outils d’authentification, entre autres. Il présente également le travail en cours en matière de signalement et de correction de bogues. Les rapports sur l’UA, ainsi que les supports de formation technique et les orientations visant à rendre les systèmes compatibles avec l’UA, sont disponibles sur la page Web consacrée à l’acceptation universelle. La Section 1.2 du contrat de registre de base (Annexe 4) inclut une disposition relative à la faisabilité technique des chaînes.

2.4 Liberté d’expression des candidats

L’ICANN respecte la liberté d’expression des candidats, droit consacré par les principes juridiques internationalement reconnus, notamment ceux prévus dans la Convention de Paris pour la protection de la propriété industrielle, la Déclaration universelle des droits de l’homme et le Pacte international relatif aux droits civils et politiques.

S’il est vrai qu’un candidat peut poser sa candidature à tout chaîne disponible, cette possibilité doit néanmoins être conciliée avec certaines restrictions motivées par les normes techniques, les listes de noms réservés et d’autres interdictions détaillées dans le Guide de candidature, sans oublier les limites inhérentes à la liberté d’expression. Au moment de déterminer s’il y a lieu de déposer une objection pour intérêt public limité (Section 4.5.1.3), l’objecteur indépendant prendra en considération la liberté d’expression au même titre que les autres facteurs pertinents. Une candidature pourra être rejetée si la chaîne proposée contrevient aux lois applicables ou enfreint des droits, des exigences ou des interdictions.

2.5 Stabilité et sécurité

Le nombre de TLD délégués dans la zone racine du DNS ne devrait pas augmenter de plus de 5 % environ par mois.⁹

Les candidatures sont traitées selon leur ordre de priorité. La délégation d’un nouveau gTLD dans la zone racine est engagée lorsque, une fois ce nouveau gTLD est prêt, l’opérateur de registre soumet une demande à cet effet.¹⁰ Sauf circonstances extraordinaires, les demandes de délégation sont traitées selon l’ordre d’arrivée, jusqu’à atteinte éventuelle de la limite mensuelle de modification de la zone racine. Toutefois, les demandes de délégation visant d’autres types de TLD¹¹ primeront sur celles de nouveaux gTLD.

En cas d’instabilité avérée ou potentielle des services DNS, l’ICANN se réserve le droit de modifier le rythme des délégations, à sa seule et raisonnable appréciation. Dans l’éventualité où une telle modification se révélait nécessaire, tout candidat concerné en sera avisé. Aucun retard de l’ICANN dans la délégation d’une chaîne ne sera imputé à l’opérateur de registre au regard de son obligation de mener à bien les tests et procédures de prédélégation dans les délais stipulés dans l’Article 2.20 du contrat de registre de base (Annexe 4).

2.6 Conformité juridique

Le candidat reconnaît que l’ICANN est tenue de se conformer à toutes les lois applicables, notamment aux lois, règles et règlementations des États-Unis. Au nombre desdites règlementations figure le programme de sanctions économiques et commerciales géré par le Bureau du contrôle des avoirs étrangers (OFAC pour ses sigles en anglais) du département du Trésor des États-Unis.¹² Ces sanctions ont été appliquées à certains pays, individus et entités figurant sur la liste dite « Liste de ressortissants spécialement désignés et de personnes bloquées » (la « liste SDN ») de l’OFAC. L’ICANN n’a pas le droit de fournir un certain nombre de biens et de services aux résidents de pays ou à des entités gouvernementales faisant l’objet de sanctions ou figurant sur la liste SDN sans autorisation ou dérogation officielle du gouvernement américain. En règle générale, l’ICANN ne cherchera pas à obtenir une autorisation pour fournir des biens ou des services à tout individu ou entité figurant sur la liste SDN. Par le passé, lorsqu’il a été demandé à l’ICANN de fournir des services à des individus ou à des entités ne figurant pas sur la liste SDN mais résidant dans des pays faisant l’objet de sanctions, l’ICANN a demandé et obtenu les autorisations requises. Toutefois, le candidat reconnaît que l’ICANN n’est pas tenue de demander de telles autorisations et que, dans tous les cas, l’OFAC pourrait décider de ne pas délivrer l’autorisation demandée.

2.7 Mécanismes de responsabilité

L’ICANN a pris l’engagement de faire preuve de responsabilité et de transparence dans toutes ses pratiques. Les principes de responsabilité et de transparence constituent pour l’ICANN des garanties fondamentales pour assurer l’efficacité de son modèle multipartite ascendant. Les mécanismes par lesquels l’ICANN assure la responsabilité et la transparence sont intégrés à tous les niveaux de son organisation et de son mandat, à commencer par ses statuts constitutifs¹³, détaillés dans les principes et cadres de responsabilité et de transparence¹⁴ (adoptés par le Conseil d’administration de l’ICANN en 2008) et réaffirmés chaque année dans le plan stratégique et opérationnel.¹⁵ Afin de renforcer sa transparence et sa responsabilité, l’ICANN a institué des mécanismes de responsabilité pour l’examen de ses propres actions. Pour en savoir plus, veuillez consulter les Mécanismes de responsabilité¹⁶ de l’ICANN.

2.8 Séries ultérieures de candidatures

L’ICANN entend organiser de futures séries de candidatures à des intervalles réguliers et prévisibles, en évitant la mise en place de révisions de durée indéterminée. Sauf circonstances extraordinaires, le déroulement des procédures de candidature ne sera interrompu que sur recommandation d’une pause par le conseil de la GNSO, dûment approuvée par le Conseil d’administration de l’ICANN.

Le Conseil d’administration peut lancer une nouvelle série même si les étapes de traitement et de délégation des candidatures antérieures ne sont pas achevées. Des candidatures à des variantes allouables de chaînes de gTLD existants pourront également être soumises lors de la série 2026 et des séries ultérieures.

Le Conseil d’administration arrêtera le calendrier de la prochaine série de candidatures dès que possible, et au plus tard, dans l’idéal, lors de la deuxième réunion du Conseil d’administration si les conditions suivantes sont remplies :

1. la confirmation de la liste des chaînes ayant fait l’objet de candidatures pour la série en cours et la clôture de la période de demande de modification de chaîne. Les candidats à une série ultérieure sauront ainsi quelles chaînes pourront faire l’objet d’une candidature ;

2. l’absence d’obstacle majeur à la réception et au traitement, par l’ICANN, de nouvelles candidatures.

Les révisions et processus d’élaboration de politiques futurs, notamment la prochaine révision de la concurrence, de la confiance et du choix du consommateur (CCT), devront se dérouler indépendamment des séries ultérieures de candidatures aux gTLD, et, sauf circonstances extraordinaires, ne devront ni interrompre ni retarder ces séries.

Toute modification majeure des procédures de dépôt de candidatures découlant de ces révisions et processus d’élaboration de politiques s’appliquera à la série de candidatures qui suivra, après l’adoption des recommandations pertinentes par le Conseil d’administration. La mise en œuvre desdites recommandations constituera une condition préalable à l’établissement du calendrier de la série suivante de candidatures.

2.9 Jours calendaires et échéances

Sauf indication contraire, les délais pour tous les processus mentionnés dans le Guide de candidature sont exprimés en jours calendaires et prennent effet à 00h01 UTC du lendemain de l’annonce du lancement du processus. Sauf indication contraire toutes les heures limites sont, sauf indication contraire, fixées en temps universel coordonné (UTC).

2.10 Obligations fondamentales des opérateurs de registre vis-à-vis des bureaux d’enregistrement

Cette section décrit les obligations des opérateurs de registre associées à leur interaction avec les bureaux d’enregistrement. Voir l’Annexe 4 Contrat de registre de base pour connaître toutes les obligations des opérateurs de registre.

L’enregistrement d’un nom de domaine dans un gTLD s’effectue par l’intermédiaire d’un bureau d’enregistrement accrédité par l’ICANN, hormis quelques exceptions limitées prévues dans le contrat de registre de base et autorisant un opérateur de registre à enregistrer un nom pour son propre compte. Se reporter à la Section 2.9 du contrat de registre de base.

Un opérateur de registre est tenu d’utiliser un contrat uniforme avec tous ses bureaux d’enregistrement autorisés à enregistrer des noms (contrat entre opérateur de registre et bureaux d’enregistrement, RRA). Ce RRA définit les exigences applicables aux bureaux d’enregistrement et doit comporter certaines clauses spécifiées dans le contrat de registre de base. Il peut par ailleurs en inclure d’autres, propres au TLD. L’opérateur de registre est tenu de notifier à l’avance toute modification tarifaire à l’ensemble des bureaux d’enregistrement, et ce dans les délais prévus au contrat. Pour en savoir plus, veuillez vous reporter aux sections 2.9 et 2.10 du contrat de registre de base.

Tous les opérateurs de registre sont tenus de se conformer au Code de conduite des opérateurs de registre, sauf exemption accordée par l’ICANN à un opérateur éligible qui en fait la demande.¹⁷ Ledit code impose à l’opérateur de fournir un accès non discriminatoire à ses services de registre à tous les bureaux d’enregistrement accrédités par l’ICANN qui passent un RRA pour le TLD, et qui s’y conforment. Se reporter à la spécification 9, section 1(a) du contrat de registre de base.

En outre, le Code de conduite exige des opérateurs de registre qui fournissent également des services de bureau d’enregistrement ou de revendeur que ces services soient proposés par l’intermédiaire d’une entité juridique distincte de l’opérateur de registre, avec une comptabilité séparée. Pour toute question de propriété hybride, l’ICANN se réserve le droit de saisir l’autorité compétente en matière de concurrence. Se reporter à la spécification 9, Section 2 du contrat de registre de base.

Un opérateur de registre doit savoir qu’aucun bureau d’enregistrement accrédité par l’ICANN n’est obligé de prendre en charge un gTLD particulier ni de l’offrir à ses clients. Bien que les bureaux d’enregistrement soient encouragés à suivre l’actualité du programme des nouveaux gTLD pour rester informés des gTLD délégués, il leur appartient d’évaluer s’il convient de conclure un accord RRA avec chaque opérateur de registre.

L’ICANN continuera à fournir une assistance aux opérateurs de registre de gTLD pendant le lancement et la gestion des opérations dudit registre. L’ICANN offre aux opérateurs de registre de gTLD un point de contact pour leur apporter une assistance permanente. Le site Web de l’opérateur de registre¹⁸ et la Section « Après la passation de contrats » du site Web du programme des nouveaux gTLD¹⁹ peuvent également être consultés pour obtenir plus d’informations.

Le département de l’ICANN en charge de la conformité contractuelle procède à des audits réguliers pour s’assurer que les opérateurs de registre de gTLD respectent leurs obligations contractuelles, et enquête sur toute situation de non-conformité. Pour en savoir plus sur les activités de conformité contractuelle en cours, veuillez consulter la page Web du service en charge de la conformité contractuelle.²⁰

Les statuts constitutifs de l’ICANN lui imposent d’agir de manière ouverte et transparente, et d’assurer l’équité dans le traitement des opérateurs de registre. L’ICANN a pour mission de préserver la sécurité et la stabilité du réseau Internet mondial. Pour ce faire, elle cherche à bâtir une relation constructive et coopérative avec les futurs opérateurs de registre gTLD.