Résumé

  • L’autorité de l’ICANN est répartie entre les Articles of Incorporation, les Bylaws, les arrangements de responsabilité communautaire et les contrats conclus avec les acteurs de l’écosystème des identifiants.
  • Les recours ne forment pas un appel général : la reconsidération, l’Independent Review Process, les pouvoirs de l’Empowered Community et les mécanismes documentaires n’examinent ni les mêmes décisions, ni les mêmes normes, ni les mêmes formes de réparation.

Une chaîne d’autorité, pas un pouvoir uniforme

La première erreur d’analyse consiste à traiter l’ICANN comme si elle disposait d’un pouvoir public unique. Les documents constitutifs décrivent plutôt une organisation dont la mission, les pouvoirs et les limites sont définis par plusieurs instruments. Les Articles of Incorporation établissent l’ICANN comme une société californienne d’intérêt public à but non lucratif et énoncent des finalités liées à la coordination des systèmes mondiaux d’identifiants Internet et à des fonctions techniques connexes. Ils constituent le point de départ institutionnel, mais ne suffisent pas à expliquer comment une décision affecte concrètement un opérateur.

Les Bylaws ajoutent la structure de fonctionnement : mission, valeurs fondamentales, pouvoirs, conseil d’administration, élaboration des politiques et mécanismes de responsabilité. Ils organisent aussi les limites procédurales qui doivent encadrer l’exercice de l’autorité. Cette architecture est importante précisément parce qu’elle sépare la capacité de coordonner des ressources communes d’une compétence publique générale. Les sources disponibles établissent la mission et les mécanismes ; elles ne permettent pas, à elles seules, de conclure que l’ICANN possède le statut ou les pouvoirs d’un régulateur étatique.

La transition de la supervision de l’IANA en 2016 a ajouté une autre couche. Les documents de transition décrivent le passage de l’ancien cadre contractuel de supervision du gouvernement américain vers des arrangements de responsabilité élaborés par la communauté. Ils identifient les rôles de l’ICANN, de Public Technical Identifiers et de la communauté mondiale. Mais cette page de transition est un document explicatif : elle ne doit pas être confondue avec l’ensemble des instruments contractuels actuellement opératoires.

Le point de conversion : le contrat

La mission devient une capacité opérationnelle lorsque des acteurs déterminés acceptent des obligations contractuelles. Les dépôts d’accords de l’ICANN décrivent les relations avec les registres, les bureaux d’enregistrement, les opérateurs techniques et d’autres participants de l’écosystème. Les accords y sont présentés comme des instruments comprenant engagements, obligations de conformité, droits d’audit, procédures de différend et remèdes pouvant aller jusqu’à la suspension ou à la résiliation.

Les accords de registre illustrent ce mécanisme. Ils fixent les conditions applicables aux opérateurs de registres de domaines de premier niveau : responsabilités déléguées, exigences techniques, rapports, conformité et obligations liées aux différends. Leur fonction n’est pas simplement descriptive. Ils offrent le principal canal par lequel l’ICANN exerce une supervision contractuelle sur un opérateur qui a accepté ces conditions.

Le Registrar Accreditation Agreement opère selon une logique comparable pour les bureaux d’enregistrement accrédités. Le document de 2013 présenté dans les sources prévoit des obligations de bureau d’enregistrement, des dispositions de conformité et d’audit, des exigences concernant les données et la protection des consommateurs, ainsi que des conditions liées aux différends. Les sources indiquent également que les remèdes peuvent comprendre la suspension ou la résiliation, tout en avertissant que des accords et amendements ultérieurs peuvent être applicables pour des périodes plus récentes.

Le Base Registry Agreement de 2017 rend visible la profondeur de ce contrôle contractuel : exploitation du registre, conformité technique et politique, séquestre des données, rapports, audit et inspection, frais, règlement des différends et remèdes contractuels. La conséquence institutionnelle est nette. Une politique ne produit pas automatiquement un effet identique pour tous les acteurs ; son effet dépend du lien juridique ou contractuel qui la rattache à l’entité concernée et de la version de l’accord applicable.

Les remèdes ont des portes d’entrée différentes

La reconsidération est destinée à une partie affectée qui souhaite demander au Board Governance Committee de réexaminer une action ou une inaction déterminée du personnel ou du conseil de l’ICANN. Les sources la décrivent comme un mécanisme soumis à des conditions d’éligibilité et de dépôt. Son centre de gravité n’est pas une nouvelle appréciation générale du fond : elle examine en principe la compatibilité de l’action ou de l’inaction avec les politiques, les Bylaws ou les procédures documentées.

L’Independent Review Process se situe ailleurs dans la chaîne. Il fournit un mécanisme de contrôle externe pour certaines allégations selon lesquelles le conseil ou le personnel de l’ICANN aurait agi de manière incompatible avec les Articles of Incorporation ou les Bylaws. Les sources le décrivent comme de nature juridictionnelle ou adjudicative, avec des déclarations ou d’autres résultats définis par les Bylaws et les règles applicables. Cette différence de norme est essentielle : un demandeur ne doit pas confondre une contestation de procédure interne avec une allégation portant sur la conformité aux instruments constitutifs.

La synthèse des mécanismes de responsabilité ajoute l’Ombudsman, les demandes d’informations documentaires et les pouvoirs communautaires. Ces mécanismes diffèrent par la qualité pour agir, l’objet du contrôle, le décideur, la forme du soulagement disponible et le caractère contraignant ou consultatif du résultat. Les citer comme une liste homogène masquerait donc leur fonction réelle.

Les demandes documentaires peuvent produire des éléments utiles pour évaluer ou contester une décision, mais la divulgation n’est pas automatique. Les documents de transparence mentionnent des exceptions et des protections de confidentialité. Ce canal peut donc renforcer le dossier probatoire d’une contestation sans constituer, à lui seul, une voie de recours contre le fond d’une décision.

Le levier collectif

Après la transition, l’Empowered Community a reçu des pouvoirs déterminés sur certaines décisions du conseil et sur des modifications fondamentales des Bylaws. Les exemples publiés comprennent le rejet de budgets ou de plans stratégiques, la révocation de certains administrateurs, la révocation de l’ensemble du conseil et l’approbation ou le rejet de certaines actions fondamentales, sous réserve d’exigences procédurales.

Ce levier ne transforme pas l’ICANN en administration publique. Il déplace plutôt une partie du contrôle vers une architecture communautaire dotée de pouvoirs définis. La page consacrée à ces pouvoirs est toutefois présentée comme une explication : les dispositions opératoires se trouvent dans les Bylaws en vigueur et dans les documents constitutifs de l’Empowered Community. Pour une contestation liée à une date précise, il faut donc identifier la version applicable avant de tirer une conclusion sur la portée exacte du pouvoir.

Ce que la chaîne permet, et ce qu’elle ne permet pas d’affirmer

La chaîne d’autorité peut être résumée ainsi : les Articles établissent la personne morale et ses finalités ; les Bylaws organisent les pouvoirs, les procédures et les limites ; les arrangements communautaires répartissent certaines capacités de surveillance ; les contrats appliquent des obligations à des participants déterminés ; les mécanismes de responsabilité offrent des voies de contrôle qui varient selon la nature de la décision.

Cette chaîne explique pourquoi l’effet pratique d’une décision ne se déduit pas du seul mot « ICANN ». Il faut demander quel instrument est invoqué, quelle relation lie l’organisation à l’acteur visé, quelle version du document s’applique, quelle procédure a été suivie et quel remède est juridiquement ou institutionnellement disponible. Les sources réunies ici ne permettent pas de résoudre un litige historique particulier sans vérifier les textes opératoires et leurs amendements.

Elles permettent en revanche de distinguer coordination, obligation contractuelle, contrôle institutionnel et pouvoir public — distinction indispensable pour analyser la légitimité et la contestabilité d’une décision de l’ICANN.

Sources et limites

Les références principales sont les Bylaws de l’ICANN, les Articles of Incorporation, les documents de transition de la supervision de l’IANA, les accords et politiques de l’ICANN, les accords de registre, le Registrar Accreditation Agreement et le Base Registry Agreement. Les voies de contrôle sont décrites dans les documents relatifs à la reconsidération, à l’Independent Review Process, aux mécanismes de responsabilité, à la transparence documentaire et aux pouvoirs de l’Empowered Community.

Les pages et résumés utilisés ici signalent plusieurs incertitudes : l’ICANN publie différentes versions et amendements, certains dépôts ont changé de taxonomie et les textes explicatifs ne remplacent pas nécessairement les instruments opératoires. Toute analyse d’un différend précis doit donc vérifier la version applicable, les délais, la qualité pour agir et la forme de réparation prévue à la date concernée. La fiche de l’ICANN dans le répertoire BTW fournit le point d’accès éditorial à l’entité suivie, mais ne remplace aucun des textes sources.