Module 3 Dépôt de candidature

Le présent module expose les principales étapes et modalités du dépôt d’une candidature à un nouveau gTLD. Y sont notamment détaillés des aspects essentiels comme la période et les limites de dépôt, la sauvegarde de la procédure de candidature, ou encore la mise en file d’attente et le classement prioritaire des dossiers.

Le module 3 traite également d’autres thèmes fondamentaux, parmi lesquels :

• la stabilité du DNS et les règles de génération d’étiquettes pour la zone racine ;

• les types de candidatures et de chaînes ;

• les frais et paiements ;

• les demandes de modification.

Ces informations ont pour objet d’éclairer la procédure de candidature, afin que les candidats puissent s’y préparer rigoureusement et l’aborder en toute confiance.

3.1 Soumission d’une candidature

3.1.1 Période de dépôt des candidatures

La période de dépôt de candidatures devrait débuter au plus tard le 30 avril 2026 à 23h59 UTC et rester ouverte pendant 105 jours, pour prendre fin le 12 août 2026 à 23h59 UTC.

Toute candidature, pour être recevable, devra impérativement être déposée avant la clôture de la période de dépôt, le système n’autorisant aucune soumission tardive. Les candidats sont encouragés à déposer leur candidature dûment remplie dès que possible après l’ouverture de la période de dépôt de candidatures. Attendre la fin de la période pour entamer la procédure ne laissera pas le temps nécessaire pour réaliser toutes les démarches requises et le dépôt d’un dossier complet dans les délais prévus.

Pour que sa candidature soit examinée, le candidat doit s’acquitter des frais d’évaluation de son gTLD dès réception de la facture et au plus tard sept jours après la clôture de la période de dépôt, conformément à la Section 3.3 Frais et paiements.

Une fois son dossier déposé, le candidat ne pourra y apporter de modifications qu’en suivant les procédures décrites à la Section 3.8 Demande de modification de dossier de candidature, lesquelles ne peuvent être soumises qu’après le jour de confirmation de la chaîne.

3.1.2 Système de gestion des candidatures aux TLD

Les dossiers de candidature doivent être soumis par voie électronique à travers le système de gestion des candidatures aux TLD (TAMS). Aucune candidature sur support papier ne sera admise. Il est recommandé aux candidats de consulter le Guide d’utilisation du TAMS, publié sur le site Web du programme des nouveaux gTLD¹, afin de bien maîtriser le fonctionnement du système avant de déposer leur dossier.

3.1.3 Questions du dossier de candidature

La candidature comprendra les sections suivantes, à remplir par l’utilisateur lors de son inscription :

1. Informations sur l’organisation candidate

2. Informations financières

3. Informations sur la candidature au gTLD

Pour que son dossier soit complet, l’utilisateur devra répondre à une série de questions, détaillées à l’Annexe 1 Questions du dossier de candidature, et fournir, le cas échéant, les pièces justificatives requises. Avant d’autoriser le dépôt de la candidature, le système s’assurera que tous les champs obligatoires sont dûment renseignés.

Si un candidat souhaite déposer plusieurs dossiers de candidature, le système TAMS lui demandera de saisir les informations sur l’organisation et les informations financières une seule fois, lors de la création du registre de l’organisation dans le système. Pour le dépôt d’autres dossiers par le même candidat, le système TAMS lui demandera uniquement de saisir les informations sur la candidature au gTLD concerné.

Cela veut dire que les informations sur l’organisation et les informations financières de l’entité candidate seront verrouillées après le dépôt du premier dossier de candidature. Avant de déposer le premier dossier de candidature, le candidat doivent vérifier que les informations sur l’organisation sont correctes et que les informations financières s’appliquent à tous les dossiers de candidature qu’il envisage de soumettre.

Une fois soumis, le dossier de candidature ne peut plus être modifié pendant toute la durée de la période de dépôt des candidatures. À l’issue de la période de dépôt des candidatures, le candidat a la possibilité de modifier son/ses dossier(s), en suivant les procédures décrites dans la Section 3.8 Demande de modification de dossier de candidature.

3.1.4 Chaînes d’une candidature à un gTLD

Chaque candidature porte sur un gTLD et peut inclure, le cas échéant, une ou plusieurs de ses variantes de chaîne allouables. Une candidature peut aussi porter sur une ou plusieurs variantes de chaînes allouables d’un gTLD déjà existant.²

3.1.5 Sélection d’une chaîne de remplacement

Afin de limiter les risques de conflit de chaînes, les candidats ont la possibilité de proposer des chaînes de remplacement, comme le prévoit la Section 5.1 Chaînes de remplacement.

3.1.6 Types de candidatures et de chaînes

La présente section expose les différents types de candidatures aux nouveaux gTLD : général, communautaire, nom géographique, nom réservé, marque, IDN, variante d’un gTLD existant, variante IDN principale d’un nouveau gTLD, ainsi que les candidatures émanant de gouvernements, d’organisations intergouvernementales (OIG) et de candidats bénéficiaires du programme de soutien (candidatures de type « gouvernement/OIG » et « candidat bénéficiaire du programme de soutien »). Chaque type peut être soumis à des exigences et à des phases de traitement qui lui sont propres, que le candidat se doit de connaître au moment du dépôt de sa candidature, conformément à la Section 7.1 Types de chaînes et de candidatures.

Le tableau ci-après récapitule les différents types de candidatures et précise les domaines où peuvent s’appliquer des exigences distinctes. Pour des informations détaillées, il convient de se reporter aux sections correspondantes, accessibles via les liens du Tableau 3-1.

Tableau 3-1 Aperçu des types de candidatures et des principales différences de traitement

3.1.7 Chaînes à usage exclusif (génériques fermés)

Selon le Contrat de registre de base (annexe 4), le terme « générique » correspond à une « chaîne consistant en un mot ou un terme qui désigne ou décrit une catégorie générale de biens, services, groupes, organisations ou choses, par opposition à une marque spécifique de biens, de services, de groupes, d’organisations ou de choses qui se distingue des autres ». Le contrat de registre de base décrit les gTLD « à usage exclusif » comme ceux qui imposent des critères d’éligibilité qui limitent les enregistrements à une seule personne physique ou morale et/ou aux « sociétés affiliées » de ladite personne. Les opérateurs de registre n’ont pas le droit d’exploiter des gTLD génériques à des usages exclusifs. On y fait souvent référence comme une interdiction des TLD « génériques fermés ». Parmi les exemples de chaînes potentiellement génériques, on peut citer .tree (.arbre) et .banana (.banane), mais il convient de noter que ces exemples pourraient également être éligibles en tant que TLD de marque.

Le Conseil d’administration de l’ICANN a décidé que les candidatures aux domaines génériques fermés ne seront approuvées qu’après l’établissement d’une méthodologie et de critères approuvés permettant d’évaluer si un domaine générique fermé proposé servirait l’intérêt public. Pendant la procédure de dépôt de candidature, les candidats devront certifier qu’ils ne demandent pas et n’ont pas l’intention d’exploiter une chaîne générique fermée.

Les TLD de marque ne décrivent pas une catégorie générale de biens, services, groupes, organisations ou choses, si bien qu’ils ne sont pas concernés par l’interdiction d’exploitation de génériques fermés. La section 9.3 de la spécification 13 du contrat de registre de base⁹ établit que « les TLD de marque sont des TLD pour lesquels : ii) l’opérateur de registre, ses sociétés affiliées ou les détenteurs de licences de la marque déposée sont les seuls titulaires des noms de domaine dans le TLD et contrôlent les enregistrements du DNS liés aux noms de domaine à tous les niveaux du TLD ». Pour en savoir plus, se reporter à la Section 7.3 Évaluation d’admissibilité au statut de TLD de marque.

3.1.8 Validation des chaînes préalable au dépôt

3.1.8.1 Identification des noms bloqués

Le système intègre un certain nombre de vérifications automatiques qui sont effectuées avant d’autoriser un candidat à poursuivre sa candidature. Lorsque le candidat saisit le nom de la chaîne faisant l’objet de sa candidature, le système vérifie automatiquement si cette chaîne, ainsi que ses variantes, apparaissent dans la liste de noms bloqués, comme cela est décrit dans la Section 7.2.1 Noms bloqués. Si la chaîne y figure, le système empêchera le candidat de poursuivre. Pour continuer, le candidat devra modifier sa saisie et opter pour une autre chaîne, non bloquée.

3.1.8.2 Identification des noms réservés

Lorsque le candidat saisit le nom de la chaîne faisant l’objet de sa candidature, le système vérifie automatiquement si cette chaîne, ainsi que ses variantes allouables, apparaissent dans la liste de noms réservés. Si la chaîne y figure, la procédure d’exception est alors enclenchée : le candidat est invité à téléverser les documents justifiant qu’il est bien l’entité pour laquelle le nom est réservé.

3.1.8.3 Examen de la stabilité du DNS

Les chaînes de nouveaux gTLD ne doivent en aucun cas compromettre la sécurité ou la stabilité du DNS. L’examen de la stabilité du DNS vise à déterminer si une chaîne faisant l’objet d’une candidature à un nouveau gTLD respecte les normes du DNS et les autres normes pertinentes. Cette évaluation comprend la vérification de la conformité de la chaîne aux exigences techniques qui lui sont applicables. Une candidature ne pourra progresser qu’à l’issue de ces contrôles.

La chaîne faisant l’objet d’une candidature doit satisfaire aux exigences suivantes :

1. L’étiquette ASCII doit correspondre soit à une étiquette NR-LDH¹⁰, soit à une étiquette A valide, comme décrit à la section 2.3 du RFC 5890¹¹.

2. L’étiquette NR-LDH doit se composer uniquement de lettres (caractères alphabétiques de a à z), conformément à la section 2.1 du RFC 1123¹².

3. Les chaînes de gTLD IDN doivent être conformes à la norme IDNA2008¹³ (RFC 5890-5893) ainsi qu’à tous les RFC de standardisation de l’Internet qui la mettent à jour.

4. Les chaînes gTLD IDN doivent se conformer aux règles de génération d’étiquettes pour la zone racine applicables.¹⁴ Se reporter à la Section 3.1.8.3.1 Règles de génération d’étiquettes pour la zone racine pour de plus amples informations sur les RZ-LGR et le traitement des dossiers de candidature.

5. Si une chaîne de gTLD est classée comme variante d’un gTLD existant dans la zone racine ou d’un gTLD principal faisant l’objet d’une candidature, elle doit en être une variante allouable (se reporter à la Section 3.1.9 Noms de domaine internationalisés). Les RZ-LGR sont l’unique référence pour le calcul des variantes d’une chaîne de gTLD principal et de leur statut (allouables ou bloquées).

Les vérifications susmentionnées sont intégrées au [TAMS] et y sont mises en œuvre, ce qui signifie qu’elles s’effectuent automatiquement dès que le candidat y saisit la chaîne dans sa candidature.

Si une chaîne échoue à l’une de ces vérifications, un message d’erreur expliquant les problèmes détectés s’affichera et la poursuite de la candidature sera bloquée.

La Section 7.7 Collision de noms et la Section 2.5 Sécurité et stabilité décrivent d’autres questions et exigences relatives à la sécurité et à la stabilité.

3.1.8.3.1 Règles de génération d’étiquettes pour la zone racine

3.1.8.3.1.1 Version applicable des RZ-LGR, et scripts et langues pris en charge

Les noms de domaine internationalisés (IDN) sont indispensables à l’avènement d’un Internet multilingue. Afin de préserver la sécurité et la stabilité du DNS, des règles de génération d’étiquettes pour la zone racine (RZ-LGR)¹⁵ ont été élaborées. Elles permettent de déterminer dans différents scripts la validité des chaînes principales faisant l’objet de candidatures, ainsi que de leurs variantes de chaînes allouables.

Le DNS servant à identifier et non à transcrire une langue ou rédiger à des fins littéraires, les RZ-LGR n’ont pas vocation à faciliter l’expression dans le DNS d’une langue naturelle dans toute sa richesse. De même, aucune chaîne générée par des RZ-LGR n’a besoin de constituer un mot existant dans la langue concernée.

C’est la version 6 des RZ-LGR qui sera appliquée. Elle intègre les scripts et systèmes d’écriture ci-après¹⁶, sur la base des propositions élaborées par des panels communautaires de génération de script (panels de génération) et intégrées par un panel de réviseurs experts (panel d’intégration).

arabe, arménien, bengali, chinois (Han), cyrillique, dévanagari, éthiopien, géorgien, grec, gujarati, gurmukhi, hébreu, japonais (hiragana, katakana et kanji [Han]), kannada, khmer, coréen (hangeul et hanja [Han]), lao, latin, malayalam, birman, oriya, cingalais, tamoul, télougou, thaana et thaï.

Les RZ-LGR comportent des LGR distinctes pour chaque script ou système d’écriture. Un système d’écriture peut lui-même regrouper plusieurs scripts ; ainsi, le système japonais comprend les scripts hiragana, katakana et kanji [han].

3.1.8.3.1.2 Candidatures pour des scripts non pris en charge

Les RZ-LGR ne valident que les chaînes appartenant aux systèmes d’écriture ou scripts qu’elles intègrent. Un candidat ne pourra donc pas déposer une candidature pour une chaîne d’un script non intégré à la version applicable des RZ-LGR.

Dans ce cas, le candidat potentiel devra d’abord œuvrer avec la communauté du script à l’intégration de celui-ci dans les RZ-LGR, en suivant la procédure relative aux RZ-LGR¹⁷, et ce avec le soutien actif de l’ICANN. Cette démarche peut être entamée à tout moment en contactant l’ICANN à l’adresse globalsupport@icann.org. Le candidat pourra alors postuler lors d’une prochaine période de candidature, sous réserve que le script ait été intégré et soit disponible dans la version applicable des RZ-LGR.

3.1.8.3.1.3 Choix des chaînes principales et ou de leurs variantes à l’aide des RZ-LGR

La chaîne principale est la chaîne principalement demandée par le candidat, et doit être valide selon le calcul des RZ-LGR. Les variantes de la chaîne principale, également calculées au moyen des RZ-LGR, sont quant à elles marquées comme variantes de chaîne allouables ou bloquées. Ensemble, la chaîne principale et ses variantes allouables et bloquées constituent un « ensemble de variantes ». Pour un gTLD existant, la chaîne principale correspond au gTLD par rapport auquel l’ensemble de variantes sera calculé et soumis.

Un candidat qui soumet une candidature pour une chaîne principale peut, dans la même candidature, solliciter des variantes de chaîne allouables additionnelles, mais en aucun cas des variantes bloquées de sa chaîne principale. De même, l’opérateur de registre d’un gTLD existant peut, dans une même candidature, solliciter des chaînes variantes allouables de ce gTLD, mais non des variantes bloquées.

Le choix de la chaîne principale (lorsqu’elle ne correspond pas à un gTLD existant) au sein d’un ensemble de variantes ne modifie pas le nombre total de chaînes de l’ensemble. Il peut néanmoins modifier les sous-ensembles de variantes de chaîne allouables et bloquées qui le composent. En sélectionnant leur chaîne principale, les candidats doivent donc prêter attention aux ensembles de variantes de chaîne allouables et bloquées qui en découleront. L’outil LGR que l’ICANN met à disposition sur https://lgrtool.icann.org/ permet de déterminer les variantes de chaîne allouables d’une chaîne principale.

3.1.8.3.1.4 Résultats de l’utilisation des calculs RZ-LGR

Les RZ-LGR seront appliquées à une chaîne principale afin d’en déterminer la validité en tant que TLD selon ces RZ-LGR.

Elles seront appliquées à une variante d’une chaîne principale ou d’un gTLD existant afin de :

1. déterminer si la variante est valide en tant que gTLD au regard des RZ-LGR ;

2. vérifier qu’il s’agit bien d’une variante de la chaîne principale identifiée par le candidat ou du gTLD existant identifié par le candidat ;

3. s’assurer qu’il s’agit d’une variante allouable de cette chaîne ou du gTLD existant.

Les chaînes mêlant des points de code issus de LGR de différents scripts peuvent être déclarées invalides.

3.1.8.4 Contestation de la validation des chaînes préalable au dépôt

Lorsqu’un candidat estime que c’est en raison d’une erreur d’application ou de codage des validations préalables que sa candidature est bloquée ou qu’il est contraint de fournir des documents supplémentaires, il peut former un recours au plus tard 14 jours avant la clôture de la période de dépôt des candidatures¹⁸, comme suit :

• Identification des noms bloqués : le classement erroné de la chaîne du candidat en tant que nom bloqué, dû à une erreur du système dans le processus automatisé d’identification, a empêché la soumission de la candidature. Se reporter à la Section 3.1.8.1

• Identification des noms réservés : le classement erroné de la chaîne du candidat en tant que nom réservé, dû à une erreur du système dans le processus automatisé d’identification, a contraint le candidat à fournir les justificatifs requis pour les exceptions relatives aux noms réservés avant de pouvoir soumettre sa candidature. Se reporter à la Section 3.1.8.2

• Vérification de la stabilité du DNS : l’échec du candidat à l’examen de la stabilité du DNS, dû à une erreur du système identifiée dans le calcul de l’outil automatisé, a empêché la soumission de la candidature. Ce mécanisme de contestation ne s’applique pas aux scripts non pris en charge par les RZ-LGR. Se reporter à la Section 3.1.8.3 et à la Section 3.1.8.3.1.2 Candidatures pour des scripts non pris en charge.

Le panel chargé de la contestation communiquera le résultat des validations des chaînes préalables au dépôt dans les cinq jours suivant le dépôt de la contestation par le candidat.

3.1.9 Noms de domaine internationalisés

Les noms de domaine internationalisés (IDN) sont des noms de domaine qui se composent de caractères autres que les caractères ASCII (lettres de a à z, pour les domaines de premier niveau). Ces noms de domaine emploient des caractères issus de scripts non ASCII, comme l’arabe ou le chinois.

L’ICANN s’attend à recevoir une grande diversité de candidatures à de nouveaux gTLD, notamment pour des IDN, ce qui ouvrira d’importantes perspectives en matière de nouveaux usages et d’avantages pour les internautes du monde entier, tout en favorisant le choix et l’inclusion numérique.

3.1.9.1 Règles applicables aux IDN et à leurs variantes

Tout IDN faisant l’objet d’une candidature doit être conforme à la norme IDNA2008¹⁹ (RFC 5890-5893²⁰) et à toutes ses versions successives. L’IDN doit également se conformer à la version applicable des RZ-LGR. Se reporter à la Section 3.1.8.3.1 Règles de génération d’étiquettes pour la zone racine.

Conformément à la norme IDNA2008, un IDN peut être représenté en caractères Unicode (dits « étiquette U ») ou par sa transcription ASCII équivalente, préfixée par « xn-- » (dite « étiquette A »). Les IDN faisant l’objet d’une candidature (au format étiquette U) doivent comporter plus d’un caractère. Cela signifie que l’étiquette U doit comporter au moins deux points de code dont la valeur²¹ de catégorie générale est « L », telle que définie par la norme Unicode. Les points de code dont la valeur de catégorie générale est « M » ne seront pas pris en compte dans la longueur pour déterminer si un IDN demandé est un caractère unique. Pour connaître d’autres exigences relatives aux chaînes, se reporter également à la Section 3.1.8.3 Examen de la stabilité du DNS.

Les RZ-LGR constituent la seule référence pour le calcul des variantes de chaîne et la détermination de leur statut (allouables ou bloquées), tant pour les gTLD existants que pour les chaînes principales faisant l’objet d’une candidature.

L’outil LGR que l’ICANN met à disposition permet de déterminer les variantes de chaîne allouables pour un gTLD principal ou pour une chaîne faisant l’objet d’une candidature.²²

3.1.9.2 Dépôt de candidature pour des IDN

Toute candidature à un IDN dont la chaîne est conforme aux exigences obligatoires, notamment à la norme IDNA2008 et au RZ-LGR, peut être soumise par l’intermédiaire du TAMS. Lorsque, lors du contrôle algorithmique, le calcul des RZ-LGR trouve qu’une chaîne de gTLD faisant l’objet d’une candidature est « invalide » ou « bloquée » (par exemple, si la chaîne faisant l’objet de la candidature est une variante de chaîne), le système de gestion des candidatures n’acceptera pas la candidature correspondant à la chaîne non conforme. Se reporter à la Section 3.1.8.3 Examen de la stabilité du DNS pour obtenir la liste complète des contrôles effectués. Le candidat peut contester le calcul RZ-LGR effectué par le système de gestion des candidatures. Se reporter à la Section 3.1.8.3 Règles de génération d’étiquettes pour la zone racine.

3.1.9.2.1 Dépôt de candidature pour un nouvel IDN principal et ses variantes de chaîne

Un candidat peut déposer une candidature pour un nouvel IDN principal, ainsi que pour une ou plusieurs des variantes de chaîne allouables de cet IDN. Ces variantes de chaîne ne seront allouées qu’au candidat du gTLD IDN principal et devront, pendant la durée de leur délégation, relever du même fournisseur de services de registre back-end.

La candidature pour des variantes de chaîne allouables doit porter sur des chaînes issues de l’ensemble généré à l’aide des RZ-LGR. La candidature pour une variante de chaîne allouable ne peut précéder celle de son gTLD IDN principal. Un gTLD IDN principal et l’ensemble de ses variantes de chaîne allouables pour lesquelles une candidature est déposée au cours de la même série doivent faire l’objet d’une seule et même candidature. Au terme d’une évaluation positive, le gTLD principal et ses variantes de chaîne allouables faisant l’objet de la candidature seront alloués au même opérateur de registre par le biais d’un seul contrat de registre. Le candidat ne peut déposer de candidature pour une variante de chaîne du nouvel IDN principal si celle-ci est considérée comme bloquée d’après le calcul des RZ-LGR. Pour le détail des frais de candidature applicables aux variantes de chaîne allouables, se reporter à la Section 3.3 Frais et paiements.

Une fois la candidature pour un gTLD IDN principal déposée, la chaîne de celui-ci ne peut plus être changée. Fait exception à cette règle la chaîne principale d’une candidature à un gTLD IDN de marque qui se trouve en situation de conflit de chaînes (se reporter à la Section 5.3 Demandes de changement de chaîne de TLD de marque).²³

Après le dépôt de la candidature, le candidat peut, en soumettant une Demande de modification de dossier de candidature (Section 3.8), retirer de sa candidature toute variante de chaîne sollicitée, mais ne peut y ajouter aucune variante de chaîne allouable qui n’y figurait pas à l’origine. Le retrait par un candidat de sa candidature à un gTLD IDN principal entraîne automatiquement le retrait de toutes les variantes de chaînes associées à la candidature.

3.1.9.2.2 Dépôt de candidature pour des variantes de chaîne de gTLD existants

Seule l’entité juridique opérateur de registre d’un gTLD peut déposer une candidature pour les variantes de chaîne de ce gTLD. Pendant la durée de leur délégation, toutes les variantes de chaîne doivent relever du même fournisseur de services de registre back-end que le gTLD existant. Ce fournisseur de services de registre back-end doit avoir été préalablement approuvé dans le cadre du programme d’évaluation des RSP.²⁴

Des variantes de chaîne allouables d’un gTLD existant peuvent faire l’objet d’une candidature limitée à l’ensemble généré au moyen des RZ-LGR, et figurer dans une seule et même candidature. Au terme d’une évaluation positive, les variantes de chaîne allouables faisant l’objet de la candidature seront allouées à l’opérateur de registre du gTLD existant. L’opérateur de registre devra basculer vers le contrat de registre de base 2026, et le gTLD existant ainsi que toutes les variantes de chaînes seront attribués dans le cadre d’un seul contrat de registre. Le candidat ne peut déposer de candidature pour une variante de chaîne d’un gTLD existant si celle-ci est considérée comme bloquée d’après le calcul des RZ-LGR. Pour le détail des frais de candidature applicables aux variantes de chaîne allouables, se reporter à la Section 3.3 Frais et paiements.

Après le dépôt de la candidature, le candidat peut en retirer toute variante de chaîne sollicitée, mais ne peut y ajouter aucune variante de chaîne allouable qui n’y figurait pas à l’origine.

3.1.9.3 Exigences et traitement

3.1.9.3.1 Traitement prioritaire des variantes de chaîne de gTLD existants

À titre d’exception unique, les candidatures relatives à des variantes de chaîne allouables de gTLD existants issus de la série de 2012 bénéficieront d’un traitement prioritaire sur toutes les autres candidatures, y compris sur celles des candidats à des IDN qui optent pour le tirage au sort de priorité. Se reporter à la Section 3.7 Ordre de traitement des candidatures et tirage au sort pour l’établissement des priorités de traitement

3.1.9.3.2 Pluralité de candidats pour la même chaîne principale ou ses variantes de chaîne

Si plusieurs candidats sollicitent des chaînes issues du même ensemble de variantes, leurs candidatures sont mises en concurrence et un seul d’entre eux sera retenu à l’issue du processus de résolution. En d’autres termes, les chaînes principales et leurs variantes de chaîne allouables faisant l’objet de la candidature participeront, en tant qu’ensemble, au mécanisme de résolution des conflits, qu’il s’agisse de l’évaluation de la priorité communautaire (Section 5.4) ou des enchères de l’ICANN pour les nouveaux gTLD (Section 5.6) (se reporter au Module 5 Résolution des ensembles conflictuels).

Toute candidature pour une variante de chaîne allouable d’un gTLD existant sera rejetée si elle émane d’un candidat autre que l’opérateur de registre de ce gTLD.

3.1.10 Sélection du fournisseur de services de registre

Pour qu’une candidature puisse aboutir à une délégation, les candidats sont tenus de désigner les fournisseurs de services de registre (RSP) qui assureront les services de registre essentiels. La liste des RSP déjà évalués peut être consultée sur la page dédiée aux candidatures des fournisseurs de services de registre (RSP).²⁵

Les candidats peuvent soit recourir à des RSP tiers externes, soit solliciter l’agrément de l’ICANN, via le programme d’évaluation des RSP, pour fournir eux-mêmes ces services critiques.

Un RSP n’est évalué qu’une seule fois, cette évaluation unique le qualifiant pour la fourniture de services de registre spécifiques, et ce, quel que soit le nombre de gTLD qu’il dessert.

3.1.10.1 Attentes sur le choix des RSP lors du dépôt de la candidature

Afin de prévenir tout retard de traitement, il est recommandé aux candidats de désigner leur RSP et de préciser les services de registre envisagés dès le dépôt de la candidature. Un candidat peut néanmoins soumettre sa candidature sans avoir encore arrêté son choix de RSP s’il le fait juste avant l’évaluation du candidat et de la candidature.

Il est vivement conseillé d’opérer cette sélection en amont, de préférence lors de la phase préparatoire, car une collaboration étroite avec les RSP est souvent importante pour renseigner correctement les sections afférentes du dossier de candidature.

Si, au moment de l’application des procédures d’évaluation du candidat (Module 6) et des procédures d’évaluation de chaînes et de candidatures (Module 7), aucun RSP n’a été désigné pour assurer les fonctions critiques minimales du registre, le candidat pourra opter pour une « évaluation approfondie », qui lui ménagera un délai supplémentaire pour obtenir les informations requises de la part des RSP choisis.

Après le dépôt de la candidature, le candidat conserve la possibilité de désigner ou de changer de RSP en recourant à la procédure de Demande de modification de dossier de candidature (Section 3.8).

Au cours de l’étape de passation de contrat, l’ICANN s’assurera auprès du RSP désigné qu’il confirme bien son intention de servir le candidat et le ou les gTLD concernés.²⁶

3.1.10.2 Fonctions de registre et types de RSP

Le contrat de registre de base exige aux opérateurs de registre d’assurer les fonctions de registre critiques ci-après : le système des noms de domaine (DNS), les extensions de sécurité du système des noms de domaine (DNSSEC), le protocole d’avitaillement extensible (EPP), le protocole d’accès aux données d’enregistrement des noms de domaine (RDAP) et l’entiercement de données. Il existe quatre types de RSP, chacun remplissant un ensemble de fonctions spécifiques, indispensables à l’exploitation des fonctions critiques du registre :

1. les RSP principaux, qui exploitent la base de données des enregistrements d’un gTLD, prennent en charge l’entiercement des données d’enregistrement des domaines et gèrent les services EPP et RDAP du gTLD. Un gTLD ne peut avoir qu’un seul RSP principal ;

2. les RSP du DNS, qui exploitent un ou plusieurs serveurs DNS pour le compte d’un gTLD. Un gTLD peut recourir à plusieurs RSP du DNS ;

3. les RSP de DNSSEC, qui effectuent les opérations cryptographiques requises par les DNSSEC. Un gTLD ne peut avoir qu’un seul RSP de DNSSEC ;

4. les RSP fiduciaires, qui procèdent à la validation des enregistrements pour garantir la conformité avec le droit local d’un territoire donné. Il s’agit là d’un service de registre additionnel et facultatif, soumis à l’approbation de l’ICANN dans le cadre du programme d’évaluation des RSP.²⁷ Un gTLD peut recourir à plusieurs RSP fiduciaires, chacun ouvrant l’accès à un territoire distinct.

Une organisation peut être évaluée pour un ou plusieurs types de RSP dans le cadre du programme d’évaluation des RSP.²⁸

Au cours de la procédure de candidature, le candidat devra indiquer les RSP auxquels il compte faire appel et, le cas échéant, les services de registre additionnels qu’il prévoit proposer pour les gTLD faisant l’objet de sa candidature. Il doit, au minimum, désigner un RSP principal, un RSP de DNSSEC et un RSP du DNS.

3.2 Contrôle administratif et préparation pour le jour du dévoilement

Une fois close la période de dépôt des candidatures, l’ICANN procédera aux diligences administratives raisonnables d’usage et s’assurera du bon encaissement des frais d’évaluation. L’ICANN examinera ensuite la liste des candidatures soumises et regroupera au sein d’ensembles conflictuels préliminaires celles qui portent sur des chaînes identiques, et ce, en prévision du jour du dévoilement.

Il est prévu que ce contrôle administratif soit mené à bien pour l’ensemble des dossiers en huit semaines environ, sous réserve du volume total des candidatures. Si toutefois un afflux de candidatures venait à empêcher l’ICANN de respecter ce délai, un calendrier actualisé serait publié dans les meilleurs délais.

3.3 Frais et paiements

La présente section présente les frais dus par le candidat et les modalités de paiement y afférentes.

3.3.1 Frais d’évaluation de gTLD

Les frais d’évaluation de gTLD sont calculés de sorte que l’ICANN puisse recouvrer l’intégralité des coûts associés à la prochaine série du programme des nouveaux gTLD. Ce principe garantit le financement intégral et la neutralité budgétaire du programme, qui ne sera donc pas subventionné par des contributions issues d’autres sources de financement de l’ICANN, notamment les frais des opérateurs de registre et des bureaux d’enregistrement de gTLD ou les contributions des ccTLD et des Registres Internet régionaux. L’ICANN estime que les processus d’évaluation, de passation de contrat et de délégation de la série 2026 s’étendront approximativement jusqu’au 30 juin 2030,²⁹ échéance à laquelle l’ensemble des candidatures déposées auront, en principe, franchi ces étapes du processus de candidature (Module 1). Les frais d’évaluation de gTLD couvrent toutes les évaluations requises durant cette période, y compris, le cas échéant, l’évaluation approfondie.

L’ICANN n’ignore pas que des cas exceptionnels puissent survenir et exiger, pour un nombre limité de candidatures, la prolongation de ces services au-delà de juin 2030.

Les frais d’évaluation de gTLD s’élèvent à 227 000 USD par candidature, sauf pour celles qui sont soumises par des candidats qualifiés au titre du programme de soutien aux candidats (ASP) ou qui concernent des variantes répondant aux critères décrits ci-après. Ces frais sont exigibles dès réception de la facture, et l’ICANN doit en recevoir le paiement intégral au plus tard sept jours après la clôture de la période de dépôt de candidatures. À défaut de règlement des frais d’évaluation de gTLD dans ce délai de sept jours, la candidature sera, en règle générale, écartée et annulée. Dans le cas peu probable où un candidat ayant soumis une demande à l’ASP attendrait encore les résultats de son évaluation, il pourrait devoir déposer sa candidature sans paiement. Cette candidature serait alors suspendue jusqu’à ce que les frais d’évaluation applicables soient fixés et le paiement reçu.

3.3.1.1 Frais d’évaluation de gTLD pour les candidatures incluant des variantes de chaîne

3.3.1.1.1 Nouveaux candidats

Les frais d’évaluation des gTLD couvrent une candidature pour un gTLD principal et un maximum de quatre variantes de chaîne. Tout candidat souhaitant solliciter plus de quatre variantes de chaîne rattachées à une même chaîne principale devra s’acquitter des frais d’évaluation de 227 000 USD pour chaque variante allouable au-delà de la quatrième. Des frais supplémentaires au titre d’évaluations conditionnelles (se reporter à la Section 3.3.2) pourraient s’appliquer.

3.3.1.1.2 Opérateurs de registre de gTLD existants de la série de 2012

Pour la série 2026, tout opérateur de registre de gTLD de la série de 2012 pourra solliciter jusqu’à quatre variantes de chaîne de son gTLD existant et, à titre d’exception unique, être exonéré des frais de candidature. Au-delà de quatre variantes de chaîne, il devra s’acquitter de l’intégralité des frais d’évaluation pour chaque variante allouable supplémentaire. Des frais supplémentaires au titre d’évaluations conditionnelles (se reporter à la Section 3.3.2) pourraient s’appliquer.

3.3.1.2 Frais d’évaluation de gTLD pour les candidats éligibles au programme de soutien aux candidats

Les candidats à l’ASP éligibles bénéficieront d’une réduction de 75 % à 85 % sur les frais d’évaluation de gTLD. Le montant des frais réduits d’évaluation des gTLD pour les candidats éligibles à l’ASP s’échelonnera donc entre 34 500 USD et 56 750 USD (dont 2 500 USD d’acompte versés pour confirmer la viabilité financière dans le cadre de l’ASP). Le montant final sera fonction du nombre total de candidats éligibles à l’ASP. L’ICANN informera les candidats ASP éligibles qu’ils peuvent bénéficier d’une réduction minimale de 75 %. Le montant final de la réduction devrait être communiqué 12 à 16 semaines après la fin de la période de soumission des demandes ASP. Comme il est précisé à la Section 3.3.1.1 Frais d’évaluation de gTLD pour les candidatures incluant des variantes de chaîne, la réduction sur les frais d’évaluation des gTLD comprend jusqu’à quatre variantes de chaînes. Les candidats bénéficiant du soutien qui sollicitent plus de quatre variantes devront s’acquitter des frais d’évaluation de 227 000 USD pour chaque variante supplémentaire.

3.3.2 Évaluations conditionnelles

Outre les évaluations obligatoires couvertes par les frais d’évaluation de gTLD, il existe des évaluations conditionnelles auxquelles les candidats peuvent ou doivent se soumettre pour obtenir un statut spécifique ou une dérogation. Les frais de ces évaluations conditionnelles, qui peuvent être effectuées ou encadrées par des prestataires tiers, sont également calculés de sorte à couvrir les coûts qu’elles engendrent. Ce principe garantit le financement intégral et la neutralité budgétaire du programme, qui ne sera donc pas subventionné par des contributions issues d’autres sources de financement de l’ICANN, notamment les frais des opérateurs de registre et des bureaux d’enregistrement de gTLD ou les contributions des ccTLD et des Registres Internet régionaux. Le choix de certaines évaluations conditionnelles, comme, par exemple l’examen du plan d’atténuation des risques élevés de collision de noms, ne sera proposé qu’à un stade ultérieur du processus d’évaluation. Pour une description détaillée de chaque évaluation, se reporter aux sections correspondantes du Tableau 3-2 Évaluations conditionnelles et frais.

L’ICANN notifiera aux candidats l’échéance de paiement des frais relatifs aux évaluations conditionnelles. Cette notification pourra intervenir peu après la clôture de la période de dépôt des candidatures ou au moment même des évaluations. Si un candidat ne paie pas les frais liés à une évaluation conditionnelle, selon le type d’évaluation conditionnelle, il pourrait être invité à soumettre une demande de modification de dossier afin de supprimer cette section de son dossier et de pouvoir poursuivre la procédure. Les évaluations conditionnelles requises doivent être payées en temps voulu afin d’éviter toute disqualification.³⁰

Les évaluations assorties d’un astérisque (*) ouvrent droit, pour les candidats éligibles à l’ASP, à un pourcentage de réduction identique à celui appliqué à leurs frais d’évaluation de gTLD. Avant d’octroyer cette réduction, l’ICANN demandera au candidat à l’ASP de justifier qu’il remplit toujours les critères d’admissibilité à une aide financière supplémentaire (voir également les conditions générales de l’ASP).³¹

L’évaluation du plan d’atténuation des risques élevés de collision de noms, assortie de deux astérisques (**), est obligatoire pour chaque chaîne désignée comme étant à risque élevé. En conséquence, les frais conditionnels correspondants devront être acquittés pour chaque chaîne de l’ensemble identifié à haut risque.

Tableau 3-2 Évaluations conditionnelles et frais

3.3.3. Remboursements

3.3.3.1 Remboursement des frais d’évaluation de gTLD

Dans certaines circonstances, les candidats peuvent solliciter le remboursement partiel³² des frais initialement versés à l’ICANN pour l’évaluation de leur candidature. Les modalités sont exposées ci-après. Le montant remboursé varie selon l’étape du processus à laquelle intervient le retrait de la candidature ou à laquelle la candidature est écartée (se reporter à la Section 3.9 Statut d’une candidature)

Le processus de candidature comprendra trois périodes de remboursement distinctes :

1. La première s’étend de la réception des frais d’évaluation de gTLD jusqu’à dix jours après le jour de confirmation de la chaîne. Durant cette période, le remboursement peut atteindre 65 % des frais versés.

2. La deuxième couvre la période allant du onzième jour après la confirmation de la chaîne jusqu’au début de l’évaluation de la candidature et du candidat. Le remboursement peut alors s’élever à 35 % des frais versés pour l’évaluation du gTLD. Les candidats seront informés de la date de début prévue pour l’évaluation de la candidature et du candidat. Cette notification interviendra après l’achèvement de l’évaluation de chaîne, ou bien, le cas échéant, après la résolution de l’ensemble conflictuel.

3. La troisième période s’étend du début de l’évaluation de la candidature et du candidat jusqu’à la signature du contrat de registre avec l’ICANN, et ouvre droit à un remboursement de 20 % des frais versés pour l’évaluation du gTLD.

Pour plus de précisions sur ces périodes et sur les évaluations et les processus qui s’y déroulent, il convient de se reporter au Module 1 Parcours du candidat.

Les frais acquittés pour des évaluations conditionnelles dont l’instruction n’a pas encore commencé peuvent également être remboursés si la candidature est marquée comme « Retirée », « Sans suite » ou « Écartée ».

3.3.3.1.1 Candidatures retirées

Un candidat peut retirer sa candidature à tout moment, tant qu’il n’a pas signé le contrat de registre avec l’ICANN. Tout candidat qui décide de retirer sa candidature peut demander un remboursement partiel des frais versés à l’ICANN, selon les conditions énoncées ci-après. La demande de remboursement doit impérativement être jointe à la demande de retrait. À défaut, le candidat perd définitivement son droit au remboursement.

3.3.3.1.2 Candidatures écartées

L’ICANN notifie au candidat que sa candidature n’ira pas plus loin et qu’elle est désormais écartée (se reporter à la Section 3.9 Statut d’une candidature). Dès réception de cette notification, le candidat peut demander un remboursement, dont le montant dépendra de la période applicable et du pourcentage des frais d’évaluation éligibles, comme détaillé ci-après. Pour pouvoir prétendre à un remboursement, le candidat doit en formuler la demande dans les 90 jours qui suivent la notification par l’ICANN que la candidature a été écartée. Tout candidat qui ne formule pas sa demande de remboursement dans ce délai de 90 jours sera considéré comme ayant renoncé à son droit au remboursement.

3.3.3.1.3 Remboursement consécutif à des modifications substantielles

Toute candidature retirée en raison de modifications ayant une incidence significative sur le Guide de candidature ou les processus du programme, tels que définis dans l’Annexe 6 Cadre de prévisibilité, a droit à un remboursement. Dans sa décision concernant toute modification ayant une incidence significative sur le Guide ou les processus du programme, le Conseil d’administration de l’ICANN confirmera l’éligibilité des candidats au remboursement ainsi que le pourcentage des frais d’évaluation versés pouvant être restitué. Un candidat qui retire sa candidature en raison de telles modifications doit produire une déclaration officielle, pièces justificatives à l’appui, démontrant que lesdites modifications : 1) ont altéré le statut de sa candidature ; 2) ont influé sur l’issue de son évaluation ; 3) lui ont imposé des charges financières ou opérationnelles non négligeables ; ou 4) ont eu une incidence non négligeable sur le calendrier de traitement et d’évaluation de sa candidature.³³ Conformément à la Section 3.3.3.1.1 Candidatures retirées, une demande de remboursement au titre de cette modification doit être effectuée dans le cadre de la demande de retrait.

3.3.3.1.4 Remboursement pour les chaînes présentant un risque élevé de collision de noms

Un candidat qui décide de retirer sa candidature dans les 90 jours suivant la classification de sa chaîne comme présentant un risque élevé de collision de noms, et qui ne soumet pas de plan d’atténuation à ce titre, est éligible à un remboursement de 100 % des frais d’évaluation de gTLD versés. Ne pourront prétendre à ce remboursement les candidatures portant sur des chaînes déjà désignées comme à haut risque ou écartées pour ce motif lors d’une série précédente (.HOME, .CORP, .MAIL).

3.3.3.1.5 Remboursement en cas d’élimination d’une chaîne au profit d’une candidature à un ccTLD IDN

Lorsqu’un candidat à un gTLD, bien qu’ayant obtenu l’appui ou la non-objection de l’autorité publique ou gouvernementale compétente, voit sa candidature rejetée en raison d’une similarité visuelle avec une chaîne sollicitée dans le cadre d’une candidature à un ccTLD IDN, il bénéficie du remboursement intégral des frais d’évaluation de gTLD. Ce remboursement n’est toutefois possible que si la candidature au gTLD a été déposée avant la publication du ccTLD retenu à l’issue d’une évaluation.

3.3.3.2 Remboursement lié au volume de candidatures

L’ICANN a adopté une approche prudente en estimant le recouvrement de ses coûts de mise en œuvre avant même la réception de la première candidature. Afin de garantir ce recouvrement, la part des frais d’évaluation de gTLD destinée à couvrir les dépenses de mise en œuvre a été calculée sur la base d’une hypothèse de 1 000 candidatures entièrement payées. En conséquence, un remboursement fondé sur le volume peut être applicable si deux conditions sont remplies : 1) plus de 1 000 candidatures ont été reçues; et 2) les coûts de mise en œuvre de la série 2026 ont été recouvrés.

Au moment de soumettre leur dossier, les candidats devront indiquer s’ils souhaitent bénéficier d’un remboursement en fonction du volume, le cas échéant.³⁴ Tout candidat qui ne coche pas cette option sera considéré comme ayant renoncé à son droit à ce type de remboursement. Après le jour du dévoilement, les candidats qui ont choisi l’option de remboursement en fonction du volume seront informés par l’ICANN si celle-ci est applicable. Le montant du remboursement lié au volume sera calculé sur la base du nombre de candidatures reçues et le montant total des coûts encourus pour la mise en œuvre. Seules les candidatures payantes pour la série 2026 seront éligibles au remboursement pour volume. Les candidatures ASP admissibles recevront un remboursement proportionnel au montant des frais payés.

3.3.4 Frais requis dans certains cas

Des frais supplémentaires peuvent être facturés aux candidats lorsque des étapes de processus spécialisées s’appliquent. De plus amples informations figurent dans les sections consacrées à ces processus. Il s’agit notamment des frais suivants :

• Frais d’objection et de recours (se reporter à la Section 4.5.6 Frais d’objection et de recours).

• Enchères (se reporter à la Section 5.6 Enchères de l’ICANN pour les nouveaux gTLD).

• Vérification des documents relatifs à une demande de changement de chaîne de TLD de marque (se reporter à la Section 5.3 Demandes de changement de chaîne de TLD de marque).

3.3.5 Frais d’exploitation du registre

Les candidats qui franchissent toutes les étapes du processus de candidature et deviennent opérateurs de registre devront s’acquitter d’autres frais en tant qu’opérateurs de registre. Ces frais, qui sont détaillés dans l’Annexe 4 Contrat de registre de base, comprennent les frais fixes de registre et les frais de transaction au niveau du registre.

3.3.6 Modes de paiement

Les paiements à l’ICANN s’effectuent par virement bancaire, par l’Automated Clearing House (ACH), par paiement SWIFT international ou par tout autre moyen approuvé par l’ICANN. Ne sont acceptés ni les chèques, ni les espèces, ni les paiements par carte de crédit. Les instructions de paiement seront disponibles dans le système TAMS.

Les paiements destinés aux fournisseurs de services de règlement de litiges s’effectuent conformément aux règles établies par chaque fournisseur Se reporter à la Section 4.5.6 Frais d’objection et de recours.

3.4 Jour du dévoilement

Sauf circonstances exceptionnelles, l’ICANN prévoit de publier la liste de toutes les candidatures ayant réussi le contrôle administratif, ainsi que les chaînes demandées et toutes les variantes et chaînes de remplacement (le cas échéant), sur le site Web du programme des nouveaux gTLD³⁵ le jour du dévoilement, au plus tard neuf semaines après la fin de la période de dépôt des candidatures. Les parties publiques de chaque dossier seront également consultables, tout comme une liste des ensembles conflictuels correspondant à des candidatures pour des chaînes identiques. Certaines communications et activités seront interdites à partir du jour du dévoilement pour les candidatures en litige. Se reporter à la Section 5.2.3.1 Communications et activités interdites

3.5 Période de remplacement

Une fois que les candidats auront accès à la liste complète des chaînes sollicitées, ainsi qu’à toutes les variantes et chaînes de remplacement, ils auront la possibilité de remplacer la chaîne initialement sollicitée par leur chaîne de remplacement. Les candidats ayant choisi une chaîne de remplacement éligible disposeront d’une période de 14 jours pour notifier à l’ICANN, via le système TAMS, leur intention de remplacer la chaîne initialement demandée par la chaîne de remplacement indiquée dans leur dossier. Se reporter à la Section 5.1 Chaînes de remplacement.

3.6 Jour de confirmation des chaînes

Le jour de la confirmation des chaînes, l’ICANN publiera la liste actualisée des candidatures et des chaînes retenues (originales ou de remplacement, comme susmentionné). Une liste mise à jour des ensembles conflictuels correspondant à des candidatures pour des chaînes identiques sera également publiée. Se reporter à la Section 5.2.4.1 Ensemble conflictuel résultant de candidatures pour des chaînes identiques

3.7 Ordre de traitement des candidatures et tirage au sort pour l’établissement des priorités de traitement

Le numéro de priorité attribué à une candidature définit l’ordre général de traitement par l’ICANN lors des étapes successives du processus de candidature. Ce numéro sert également à fixer l’ordre de publication des résultats d’évaluation et de signature des contrats de registre.³⁶

Une fois attribué, le numéro de priorité d’une candidature ne pourra être ni modifié, ni transféré à un autre candidat ou à une autre candidature.

L’établissement de l’ordre des priorités pour les candidatures IDN obéit à des règles spécifiques. Se reporter à la Section 3.7.3 Établissement de l’ordre de priorité pour les candidatures IDN

3.7.1 Tirage au sort pour l’établissement des priorités de traitement

La priorité de traitement des candidatures sera déterminée lors d’un événement retransmis en direct : le tirage au sort pour l’établissement de l’ordre de priorité de traitement (le tirage au sort). Au cours de cet événement, un ticket papier représentant chaque candidature inscrite sera tiré manuellement au sort et un numéro de priorité lui sera attribué.

La participation au tirage au sort est facultative. Les modalités d’attribution de la priorité de traitement aux candidatures non inscrites au tirage au sort sont détaillées à la Section 3.7.4 Candidatures exclues du tirage au sort pour l’établissement des priorités de traitement.

3.7.2 Participation au tirage au sort

Le tirage au sort devrait avoir lieu au plus tard 30 jours après le jour de confirmation des chaînes. Les tickets de participation au tirage au sort, d’un coût de 100 USD, devront être achetés sur place ; aucun achat en ligne ne sera possible. Pour participer au tirage au sort, le candidat, par l’intermédiaire de son représentant désigné ou de son fiduciaire, doit acheter sur place un ticket pour chaque candidature qu’il souhaite voir traitée en priorité.

Les candidats ne sont pas autorisés à assister en personne au tirage au sort, mais pourront suivre l’événement en direct à distance.

L’ICANN prévoit de communiquer l’ensemble des modalités du tirage au sort au minimum 30 jours à l’avance.

Un seul ticket peut être acheté par candidature. Tout candidat qui soumet plusieurs candidatures doit acheter un ticket distinct pour chacune de celles qu’il souhaite inscrire au tirage au sort.

3.7.3 Établissement de l’ordre de priorité pour les candidatures IDN

Les candidatures inscrites seront tirées au sort par groupes de 500, jusqu’à ce que toutes aient reçu un numéro de priorité. Le traitement prioritaire des candidatures IDN lors du tirage au sort obéit à l’ordre et aux règles qui suivent :

1. Candidatures IDN pour des variantes de chaîne allouables de gTLD IDN de la série 2012.

   • À titre exceptionnel pour la présente série, les candidatures portant sur des variantes de chaîne allouables de gTLD IDN de la série 2012 seront traitées avant toutes les autres candidatures à des nouveaux gTLD, y compris les candidatures aux chaînes principales IDN inscrites au tirage au sort. Ces candidatures seront automatiquement inscrites au tirage, sans que les candidats aient à acheter un ticket. Elles seront isolées du reste et tirées au sort en premier.

2. Une fois tirées au sort toutes les candidatures relatives à des chaînes de variantes de gTLD IDN de la série 2012, s’il reste moins de 125 candidatures IDN inscrites au tirage :

   • Toutes ces candidatures IDN seront tirées au sort en premier et se verront attribuer leur numéro de priorité avant toute candidature non IDN.

3. Toutefois, s’il reste 125 candidatures IDN ou plus inscrites au tirage :

   • 25 % (soit 125) du premier groupe de 500 candidatures seront des candidatures IDN, sélectionnées au hasard dans le cadre du tirage. Ces candidatures IDN seront alors tirées au sort en premier et recevront leur numéro de priorité.

   • Les 75 % restants (soit 375) de ce premier groupe comprendront indifféremment des candidatures IDN et non IDN. Celles-ci seront sélectionnées aléatoirement parmi le lot de candidatures restantes participant au tirage, puis se verront attribuer un numéro de priorité de manière aléatoire.

4. Pour chaque groupe subséquent de 500 candidatures inscrites au tirage :

   • Les premiers 10 % de chaque groupe seront constitués de candidatures IDN sélectionnées au hasard, qui seront tirées au sort et qui recevront un ordre de priorité, jusqu’à épuisement des candidatures IDN.

   • Les candidatures restantes de chaque groupe seront tirées au sort et recevront un ordre de priorité de manière aléatoire à partir du lot de candidatures IDN et non IDN restantes.

3.7.4 Candidatures exclues du tirage au sort

Les candidatures non inscrites au tirage au sort se verront également attribuer, par tirage aléatoire, un numéro de priorité par groupes de 500, mais uniquement après que toutes les candidatures inscrites auront été tirées au sort et reçu un ordre de priorité. À titre d’exemple, si le dernier numéro de priorité attribué lors du tirage est 1 000, le numéro le plus bas qu’une candidature non inscrite pourra recevoir sera 1 001.

Dans chaque groupe de 500 candidatures, la première tranche de 10 % devra être constituée de candidatures IDN, jusqu’à épuisement de celles-ci. Les candidatures restantes de chaque groupe seront tirées au sort et recevront un ordre de priorité à partir du lot de candidatures IDN et non IDN restantes.

3.7.5 Exceptions au traitement selon le numéro de priorité

L’ICANN veillera à respecter l’ordre de priorité des candidatures à chaque étape de leur traitement. Cet ordre peut néanmoins être modifié en fonction de la capacité opérationnelle de l’ICANN et d’autres facteurs liés à la candidature, notamment des objections, un avis de consensus du GAC, une évaluation approfondie, un ensemble conflictuel, un mécanisme de responsabilité de l’ICANN ou une suspension du traitement due à une Demande de modification de dossier de candidature. Le traitement d’une candidature sera vraisemblablement suspendu jusqu’à la clôture de ces procédures. Afin d’éviter tout retard et de garantir la continuité du traitement des autres candidatures, l’ICANN passera à la candidature suivante dans l’ordre de priorité. Dès que l’ICANN constatera que les problèmes qui affectaient la candidature suspendue sont résolus, elle en reprendra le traitement conformément au numéro de priorité qui lui a été attribué.

3.8 Demande de modification de dossier de candidature

La présente section expose la procédure qui permet aux candidats d’actualiser les informations inexactes ou obsolètes de leur dossier et d’y apporter, le cas échéant, toute autre modification. Ces demandes de modification de dossier de candidature (ACR) sont examinées par l’ICANN au regard des critères de décision concernant ces demandes (se reporter à la Section 3.8.2 Critères pris en compte pour les décisions liées aux demandes de modification) et sont soumises à l’approbation de l’ICANN.

Toute ACR substantielle fera l’objet d’une publication et d’une période de consultation publique de 30 jours, conformément à la Section 3.8.3 Types de demandes de modification de dossier de candidature et processus requis, afin que le public puisse formuler des observations.

3.8.1 Vue d’ensemble des demandes de modification de dossier de candidature

Les candidats peuvent solliciter des modifications ou des mises à jour des informations relatives à leur organisation, à leurs finances ou à leur candidature, à tout moment du processus, depuis le jour de la confirmation de la chaîne jusqu’à la signature du contrat de registre.

Si, à tout moment pendant la durée du programme, les informations fournies en réponse aux questions du dossier de candidature (Annexe 1) ou les informations relatives à l’organisation deviennent fausses, inexactes ou obsolètes, par exemple à la suite d’un accord entre l’ICANN et le candidat à l’issue d’une évaluation, ³⁷le candidat doit soumettre sans délai une ACR (et dans tous les cas dans les sept jours suivant la prise de connaissance du fait ou de la circonstance donnant lieu à cette obligation). En cas de modification substantielle³⁸ de la candidature, l’ICANN se réserve le droit d’exiger la réévaluation du dossier, ce qui pourrait entraîner des frais supplémentaires. Toute omission de notifier à l’ICANN un changement qui rendrait fausse ou trompeuse une information fournie dans la candidature peut empêcher la poursuite du processus.

Un candidat peut demander la modification de nombreux aspects de son dossier de candidature, comme le précise la Section 3.8.3 Types de demandes de modification de dossier de candidature et processus requis. Toutefois, un candidat ne peut pas modifier la chaîne demandée, sauf dans les cas où il est admissible en tant que TLD de marque (se reporter à la Section 7.3 Évaluation de l’admissibilité au statut de TLD de marque) et où il est en litige. Les demandes de modification de dossier pour les candidatures à des TLD de marque suivent le processus décrit dans la Section 5.3 Demandes de changement de chaîne de TLD de marque.³⁹

Certaines ACR peuvent nécessiter des réexamens ou d’autres procédures détaillées dans la Section 3.8.3 Types de demandes de modification de dossier de candidature et processus requis, et engendrer des frais supplémentaires pour le candidat. Pour de plus amples informations sur les évaluations et les frais, se reporter au Module 6 Procédures d’évaluation du candidat, Module 7 Procédures d’évaluation de chaînes et de candidatures et la Section 3.3 Frais et paiements.

Les ACR émanant de candidats bénéficiaires du programme de soutien aux candidats seront également examinées au regard de leur éligibilité à continuer de bénéficier de l’aide financière offerte par ce programme. Pour en savoir plus, se reporter aux Conditions générales du programme de soutien aux candidats.⁴⁰

3.8.2 Critères pris en compte pour les décisions liées aux demandes de modification

Pour évaluer une ACR, l’ICANN examine l’ensemble des informations disponibles à l’aune de sept critères. Ceux-ci ont été conçus pour autoriser la mise à jour nécessaire des candidatures ou des informations propres aux candidats tout en garantissant la justesse et l’équité du processus pour tous. Le poids de chaque critère peut varier selon les particularités de la demande de changement et celles de la candidature, notamment le candidat et les chaînes en jeu. L’approbation d’une modification dépendra de la mise en balance des facteurs suivants :

1. Correction d’erreurs de soumission : ce critère s’applique quand un candidat demande un changement qui vise à rectifier une erreur. Le candidat doit alors dûment justifier sa demande. Bien que rares, de telles demandes, lorsqu’elles sont présentées, revêtent un poids considérable.

L’affirmation selon laquelle la modification vise uniquement à corriger une erreur est-elle étayée par des preuves ?

2. Explication : ce critère impose au candidat de motiver sa demande de changement. Lorsqu’aucune motivation n’est fournie, il est donné au candidat la possibilité d’y remédier.

Le candidat a-t-il fourni une explication satisfaisante ?

3. Motif de changement :

La modification fait-elle suite à la contribution d’un tiers (commentaire sur la candidature, objection, avis de consensus du GAC, alerte précoce d’un membre du GAC) ? La modification vise-t-elle à acter un changement organisationnel (changement de raison sociale, d’adresse postale, etc.) ?

4. Précédents : l’ICANN détermine si l’approbation de la demande créerait un précédent ou si elle s’inscrirait dans la lignée de demandes similaires déjà acceptées. À ce stade du programme des nouveaux gTLD, il est peu probable que des demandes susceptibles de créer un précédent soient approuvées.

La modification est-elle similaire à d’autres modifications préalablement approuvées ? Risque-t-elle d’inciter d’autres candidats à solliciter des changements similaires, susceptibles d’affecter des tiers ou d’avoir des effets préjudiciables sur le programme ?

5. Incidence sur des tiers, y compris sur d’autres candidats : l’ICANN évalue si la demande de changement a une incidence substantielle sur des tiers, et plus particulièrement sur d’autres candidats. Si un changement risque d’affecter de manière substantielle le statut d’un autre candidat, ce critère acquiert un poids prépondérant.

Quelle incidence, positive ou négative, le changement pourrait-il avoir sur des tiers, notamment sur d’autres candidats ? Le fait d’autoriser la modification visée sera-t-il juste vis-à-vis de la communauté en général ? Créerait-il un avantage ou un désavantage déloyal ?

6. Envergure : l’ICANN évalue l’incidence de la demande de changement sur le statut de la candidature et des dossiers concurrents, sur la chaîne, sur l’ensemble conflictuel et sur tout autre processus du programme, comme l’évaluation de la priorité communautaire. Une modification substantielle n’entraîne pas un rejet automatique, mais exercera une influence sur la pondération des autres critères.

La modification risquerait-elle d’influer sur les résultats des évaluations, sur un conflit de chaînes, ou de susciter des objections ?

7. Moment de formulation de la demande : ce critère sert à déterminer si le moment où la demande est formulée a une incidence sur les critères 4 à 6. Si tel est le cas, ce critère sera fortement pondéré.

Le moment de la demande entrave-t-il d’une façon ou d’une autre le processus d’évaluation ?

Toute modification qui altère de manière substantielle les volets publics de la candidature sera soumise à une période de consultation de 30 jours.⁴¹ Les modifications qui exigent une telle période de consultation seront publiées sur le site Web du programme des nouveaux gTLD, où les informations modifiées seront affichées.⁴²

3.8.3 Types de demandes de modification de dossier de candidature et processus requis

Le tableau ci-après dresse une liste non exhaustive des types d’ACR possibles, en indiquant pour chacun s’il est autorisé et les processus qu’il requiert. Le tableau distingue également les deux flux de travail distincts que chaque type d’ACR déclenche. De plus amples informations figurent ci-dessous, à la Section 3.8.4 Flux de travail des demandes de modification de dossier de candidature.

Sauf indication contraire dans le tableau, les évaluations pertinentes telles que les Procédures d’évaluation de chaînes et de candidatures (Module 7) et les Procédures d’évaluation du candidat (Module 6), seront réitérées selon les domaines touchés par l’ACR, au cas par cas.

L’approbation des modifications peut dépendre de faits et de circonstances propres à l’ACR et à la candidature, au candidat et aux chaînes concernées. Si l’approbation d’une ACR entraîne une réévaluation, des frais supplémentaires pourront être facturés.

Tableau 3-3 Types de demandes de modification de dossier de candidature et processus requis

3.8.4 Flux de travail des demandes de modification de dossier de candidature

Les différents types d’ACR déclenchent des flux de travail distincts, comme décrits ci-après. Plus précisément, sauf circonstances extraordinaires, chaque ACR suivra l’un des deux flux de travail définis ci-dessous.

• Demande de modification de dossier de candidature - flux de travail 1: ce flux s’applique à toutes les ACR, à l’exception de celles qui portent sur les politiques d’enregistrement communautaire et sur les engagements volontaires de registre. Se reporter à la Section 3.8.4.1

• Demande de modification de dossier de candidature - flux de travail 2 : ce flux s’applique précisément aux ACR portant sur des politiques d’enregistrement communautaire et des engagements volontaires de registre.

Chaque flux de travail est adapté aux exigences et considérations propres aux types d’ACR concernés. Se reporter à la Section 3.8.4.2

3.8.4.1 Demandes de modification de dossier de candidature : flux de travail 1

Le flux de travail décrit ci-après s’applique à toute demande de changement de dossier de candidature (ACR), sauf à celles qui portent sur les politiques d’enregistrement communautaire et les engagements volontaires des opérateurs de registre.

1. Soumission : le candidat dépose une ACR.

2. Examen administratif : l’ICANN vérifie si le type d’ACR est en principe autorisé, en se référant au tableau de la Section 3.8.3 Types de demandes de modification de dossier de candidature et processus requis. Si la modification sollicitée n’est pas autorisée, l’ICANN notifie au candidat le rejet de l’ACR.

3. Examen par l’ICANN : l’ICANN évalue les pièces de la demande au regard des sept critères de décision énoncés plus haut. Si des informations complémentaires s’avèrent nécessaires, elle en fait la demande auprès du candidat.

4. Décision : à l’issue de l’examen, l’ICANN communique sa décision au candidat comme suit :

   1. en cas de rejet de l’ACR, le candidat en est avisé ;

   2. en cas d’approbation de l’ACR, les modifications proposées sont publiées sur le site Web du programme des nouveaux gTLD, la candidature est mise à jour et le candidat en est avisé. Le candidat est en outre informé de l’une des suites données à sa demande :

      1. aucune période de consultation publique ni de réévaluation n’est requise (le flux de travail prend fin) ;

      2. une période de consultation publique est requise (voir étape 5) ;

      3. une période de consultation publique ainsi que des réévaluations sont requises (voir étapes 5 et 6).

5. Période de commentaires : lorsqu’une période de consultation publique s’impose, l’ACR est publiée pour une durée de 30 jours. Ce délai permet à la communauté d’examiner les éléments modifiés de la candidature et de formuler ses commentaires.

6. Réévaluation : le cas échéant, l’ICANN émet une facture au titre de la réévaluation. Dès acquittement de la facture, l’ICANN procède à la réévaluation des volets concernés, laquelle se déroule parallèlement à la période de consultation publique.

Figure 3-1 Demandes de modification de dossier de candidature - Flux de travail 1

3.8.4.2 Demandes de modification de dossier de candidature : flux de travail 2

Le flux de travail ci-après régit les ACR qui portent sur les politiques d’enregistrement communautaire et les engagements volontaires de registre (RVC).

1. Soumission : le candidat dépose une ACR.

2. Examen administratif : l’ICANN vérifie si le type d’ACR est en principe autorisé, en se référant au tableau de la Section 3.8.3 Types de demandes de modification de dossier de candidature et processus requis. Si la modification sollicitée n’est pas autorisée, l’ICANN notifie au candidat le rejet de l’ACR.

3. Examen par l’ICANN : l’ICANN évalue les pièces de la demande au regard des sept critères de décision énoncés plus haut. Si des informations complémentaires s’avèrent nécessaires, elle en fait la demande auprès du candidat.

4. Décision : l’ICANN établit le caractère substantiel ou non de la modification et agit en conséquence :

   1. si la modification n’est pas substantielle, les changements proposés sont publiés sur le site Web du programme des nouveaux gTLD, la candidature est mise à jour et le candidat en est informé (le flux de travail prend fin ici) ;

   2. si la modification est substantielle, se reporter à l’étape 5.

5. Évaluation des engagements d’un opérateur de registre (RCE): toute modification substantielle impose de procéder à une RCE.

6. Décision : au terme de la RCE, l’ICANN statue sur la modification sollicitée. Sa décision entraîne l’une des issues suivantes :

   1. si la modification est validée par la RCE, passer à l’étape 7 ;

   2. si la modification n’est pas validée par la RCE, la candidature n’est pas actualisée et poursuit son cours sans la modification sollicitée ;

   3. si la modification n’est pas validée par la RCE ou si elle a été demandée à la suite d’un avis de consensus du GAC ou d’une décision d’expert rendue dans le cadre d’une objection et qu’il a été établi que la candidature ne pouvait poursuivre son cours sans elle, la candidature est alors invalidée. Pour en savoir plus sur ce type de RVC, consulter la Section 7.8.3.4 Ajouts, modifications et suppressions de RVC ».

7. Publication : tous les RVC et les politiques d’enregistrement communautaire soumis sont publiés avec la décision rendue par l’ICANN à l’issue de la RCE. Si, au terme des négociations entre le candidat et l’ICANN, des modifications sont apportées aux RVC ou aux politiques d’enregistrement communautaire soumis en vue de leur approbation, la version approuvée est publiée parallèlement à la version originale déposée par le candidat.

8. Période de commentaires : une période de consultation publique de 30 jours est alors ouverte. L’ICANN se réserve le droit de rouvrir les négociations ou d’examiner avec le candidat les commentaires reçus durant cette période.

Figure 3-2 Demandes de modification de dossier de candidature - Flux de travail 2

3.9 Statut d’une candidature

Toute candidature se voit attribuer l’un des statuts ci-après :

• Active : la candidature progresse normalement dans le cadre du programme des nouveaux gTLD.

• En attente : la progression de la candidature est suspendue par des activités en instance qui pourraient l’affecter, telles que des objections ou des mécanismes de responsabilité.

• Retirée : le candidat met fin de son propre chef à sa candidature. Cette décision est irréversible.

• En instance de clôture : la candidature ne satisfait pas aux critères du Guide de candidature et ne peut poursuivre son cours au sein du programme. Le candidat est tenu de retirer sa candidature sous 60 jours, à défaut de quoi l’ICANN pourra faire passer son statut à « Écartée ».

• Écartée : la candidature ne sera pas traitée dans le cadre du programme et le demandeur a épuisé tous les recours et contestations disponibles.⁴⁸

• Désactivée : ce statut est attribué à toute candidature que le candidat n’a pas choisi de poursuivre après la période de remplacement de chaîne. Ces candidatures cessent d’être actives dans le programme et n’avancent pas vers les étapes d’évaluation ou de délégation.

• Contractualisée : ce statut est attribué après la signature en bonne et due forme du contrat de registre. Le candidat acquiert alors le statut d’opérateur de registre pour la/les chaîne(s) faisant l’objet de sa candidature.

• Déléguée : le TLD a été ajouté à la zone racine du DNS.