Annexe 6 Cadre de prévisibilité

Un cadre de prévisibilité a été établi par l’ICANN en vue de la gestion des processus opérationnels de la série 2026 du programme des nouveaux gTLD, afin de garantir un traitement efficace et transparent des imprévus. La survenance de toute situation non anticipée entraîne une concertation entre l’organisation ICANN et le Groupe de révision permanent de la mise en œuvre du cadre de prévisibilité (SPIRT),¹ les modalités de cette concertation variant en fonction de l’incidence potentielle de la situation non anticipée :

• Les modifications ayant une incidence substantielle² sur les candidats requièrent un accord entre l’organisation ICANN et le SPIRT sur une solution pérenne.

• En cas de modifications n’ayant pas d’ « incidence substantielle » sur les candidats, l’organisation ICANN en informera le SPIRT mais ne le consultera pas.³

Ce cadre ne peut toutefois :

• servir de mécanisme d’élaboration de politiques ;

• restreindre les prérogatives du Conseil d’administration de l’ICANN quant à la prise de décisions relatives au Programme ou à toute candidature spécifique ;

• prévaloir sur les recommandations de politique de la GNSO adoptées par le Conseil d’administration ;

• entraver les processus d’élaboration de politiques ou d’orientation du conseil de la GNSO (voir les annexes A, A-1, A-2 des statuts constitutifs de l’ICANN) ;⁴

• limiter la faculté des comités consultatifs (tel que le GAC) d’émettre des avis conformément au chapitre 12 des statuts constitutifs de l’ICANN.⁵

Toute modification apportée au Programme sera systématiquement consignée par l’ICANN (tel que décrit à la section A6.2 Description des modifications) dans un fichier journal public des modifications. En outre, toute modification opérationnelle qualifiée de non mineure fera l’objet d’une notification directe à l’ensemble des candidats.

A6.1 Parties concernées par le cadre

La mise en œuvre du cadre implique les parties suivantes, dont les rôles et responsabilités sont ici définis :

1. Candidats : entités ayant déposé une candidature à un nouveau gTLD dans le cadre de la série en cours.

2. Conseil de la GNSO : entité à l’origine du SPIRT, consultée selon les modalités ci-après.

3. Organisation ICANN : opérateur du programme et garant de son fonctionnement continu et efficace.

4. Conseil d’administration de l’ICANN : ses rôles et responsabilités sont définies dans les statuts constitutifs de l’ICANN.

5. SPIRT : travaille en collaboration avec l’organisation ICANN et le Conseil de la GNSO pour traiter et examiner des modifications opérationnelles non mineures, y compris d’éventuelles modifications de politiques.

Afin de faciliter une gestion et une communication fluides, l’ICANN et le SPIRT feront, si nécessaire, des points téléphoniques réguliers pour échanger sur des modifications potentielles et des difficultés de mise en œuvre du programme.

A6.2 Typologie des modifications

Aux fins du cadre de prévisibilité, les modifications apportées au programme sont classées en trois catégories :

• Modification opérationnelle mineure, laquelle s’entend de toute modification apportée à la série en cours du programme qui peut être mise en œuvre conformément aux recommandations de politiques existantes approuvées par le Conseil d’administration, et qui n’a pas d’incidence substantielle sur les candidats.

• Modification opérationnelle non-mineure, laquelle s’entend de toute modification apportée à la série en cours du programme qui peut être mise en œuvre conformément aux recommandations de politiques existantes approuvées par le Conseil d’administration, et qui a une incidence substantielle sur les candidats.⁶ L’organisation ICANN et le SPIRT doivent convenir d’une solution pérenne. Si aucun accord n’est conclu dans un délai de 30 jours, ou si des mesures plus urgentes sont nécessaires au bon fonctionnement du programme, l’ICANN peut mettre en œuvre une solution temporaire qui sera remplacée par la solution convenue entre l’ICANN et le SPIRT une fois celle-ci adoptée.

• Modification de politique, laquelle s’entend de toute modification intervenant pendant la série en cours qui ne peut pas être mise en œuvre conformément aux recommandations de politiques existantes et approuvées par le Conseil d’administration.⁷ Ce type de modification n’est envisageable qu’en circonstances exceptionnelles, si la continuité du programme est en jeu. Le cas échéant, le Conseil d’administration, l’organisation ICANN et le conseil de la GNSO, en consultation avec le SPIRT, définissent la solution qui s’impose pour garantir la continuité du programme et établir un processus de mise en œuvre adapté.⁸ La collaboration entre le conseil de la GNSO et le SPIRT sur ce point est régie par la charte du SPIRT et non par le présent cadre.

A6.3 Étapes de la procédure suivie pour la demande et la mise en œuvre de modifications

Le diagramme de flux des demandes de modification illustre la procédure applicable au comité consultatif (AC), au conseil de la GNSO, au Conseil d’administration de l’ICANN et à l’organisation ICANN s’ils jugent qu’une modification du programme est nécessaire.

A6.3.1 Demande de modification

Une demande de modification peut suivre quatre voies différentes :

• Voie 1 : l’organisation ICANN, constatant la nécessité d’une modification du programme, applique le cadre de prévisibilité et suit les étapes illustrées dans le diagramme de flux de mise en œuvre de modifications.

• Voie 2 : le Conseil d’administration de l’ICANN, constatant la nécessité d’une modification à la série en cours du programme, il mandate l’organisation ICANN pour mettre en œuvre la modification. Si cette modification nécessite l’adaptation de la série en cours, l’organisation ICANN applique le cadre de prévisibilité et suit les étapes illustrées dans le diagramme de flux de mise en œuvre de modifications.

• Voie 3 : le SPIRT, constatant la nécessité d’une modification à la série en cours, collabore avec le conseil de la GNSO pour en informer l’organisation ICANN. Si l’organisation ICANN partage cet avis, elle applique le cadre de prévisibilité et suit les étapes illustrées dans le diagramme de flux de mise en œuvre de modifications. Si, au contraire, l’organisation ICANN ne trouve pas nécessaire ladite modification à la série en cours, le SPIRT consulte le conseil de la GNSO. Si ce dernier maintient la nécessité de la modification, il saisit le Conseil d’administration de l’ICANN. Si le Conseil d’administration abonde dans ce sens, il donne pour instruction à l’organisation ICANN d’appliquer le cadre de prévisibilité. L’organisation ICANN suivra alors les étapes illustrées dans le diagramme de flux de mise en œuvre de modifications.

• Voie 4 : un comité consultatif ou le conseil de la GNSO fournit un avis ou une orientation au Conseil d’administration de l’ICANN. Si, après examen, le Conseil d’administration adopte ledit avis ou ladite orientation, il mandate l’organisation ICANN pour mettre en œuvre la modification. Si cette modification nécessite l’adaptation de la série en cours, l’ICANN applique le cadre de prévisibilité et suit les étapes illustrées dans le diagramme de flux de mise en œuvre de modifications.

Figure A6-1 Diagramme de flux de mise en œuvre de modifications 1⁹

A6.3.2 Mise en œuvre de modifications

Le diagramme de flux de mise en œuvre de modifications illustre trois cas de figure pour la mise en œuvre d’une modification du programme :

1. Le premier cas est celui d’une modification opérationnelle mineure qui peut être mise en œuvre dans le respect des recommandations de politiques existantes approuvées par le Conseil d’administration, et sans incidence substantielle pour les candidats.¹⁰ L’organisation ICANN la consigne au fichier journal des modifications dans les meilleurs délais, et de préférence avant la mise en œuvre.

2. Le deuxième cas est celui d’une modification opérationnelle qui, bien que compatible avec les recommandations de politiques existantes approuvées par le Conseil d’administration, ne peut être mise en œuvre sans incidence substantielle pour les candidats. L’organisation ICANN la classe comme « modification opérationnelle non mineure », en informe le SPIRT et suit la procédure prévue dans le diagramme de flux de mise en œuvre de modifications. Une fois la modification opérationnelle non mineure mise en œuvre, l’ICANN en informe les candidats.

3. Le troisième cas concerne une modification jugée nécessaire, mais qui ne peut être mise en œuvre dans le respect des recommandations de politiques existantes approuvées par le Conseil d’administration. Dans ce cas, l’organisation ICANN en informe le SPIRT, lequel en réfère au conseil de la GNSO. Si ce dernier constate qu’aucune solution de rechange compatible avec les politiques existantes ne peut être arrêtée, la modification est alors considérée comme une « modification de politique », et les étapes subséquentes prévues dans le diagramme de flux de mise en œuvre de modifications sont suivies.¹¹

Figure A6-2 Diagramme de flux de mise en œuvre de modifications 2

A6.4 Fichier journal des modifications

L’organisation ICANN consignera toute modification apportée au programme dans un fichier de journalisation public des modifications. Elle mettra également en place une liste de diffusion à archives publiques à l’intention de toute partie souhaitant être informée de ces modifications. Toute modification opérationnelle qualifiée de non mineure sera directement communiquée par l’organisation ICANN à l’ensemble des candidats. Si une modification fait suite à des questions sensibles ou ayant trait à la sécurité, les informations communiquées pourront, le cas échéant, être expurgées.

L’organisation ICANN consignera toute modification opérationnelle mineure dans le fichier journal des modifications dans les cinq jours ouvrables suivant leur mise en œuvre.

Si, contrairement à l’évaluation de l’organisation ICANN, un membre du SPIRT estime qu’une modification jugée par l’ICANN comme une modification opérationnelle mineure est susceptible d’avoir une incidence substantielle pour les candidats, le SPIRT pourra soumettre la question à l’organisation ICANN via la liste de diffusion désignée ou lors d’un des appels périodiques entre le SPIRT et l’organisation ICANN. Si l’organisation ICANN et le SPIRT déterminent que la modification a une incidence significative sur les candidats, la modification sera considérée non mineure et l’ICANN et le SPIRT conviendront d’une solution pérenne mutuellement acceptable. En attendant, la solution initiale de l’ICANN restera en place.

A6.5 Définition de l’« incidence substantielle » aux fins du cadre de prévisibilité

Dans le contexte du cadre de prévisibilité, le terme « incidence significative » s’entend de la mise en œuvre de nouvelles procédures ou activités pour la série 2026 du programme de nouveaux gTLD, ou bien de modifications aux procédures et activités de l’ICANN déjà en place, susceptibles : 1) d’altérer le statut d’une candidature ; 2) d’influer sur l’issue de son évaluation ; 3) d’imposer aux candidats des charges financières ou opérationnelles non négligeables ; ou 4) de modifier de manière notable le calendrier de traitement des candidatures, jusqu’à la phase de délégation.