Résumé

  • Les statuts et règlements de l’ICANN délimitent une mission de coordination des identifiants uniques ; ils ne constituent pas, à eux seuls, un pouvoir général de réglementation d’Internet.
  • Les politiques communautaires deviennent surtout opératoires lorsqu’elles sont incorporées aux contrats des registres et des bureaux d’enregistrement. La contestation dépend ensuite de l’instrument concerné, du statut du demandeur et du recours disponible.

L’ICANN est souvent décrite soit comme une autorité mondiale de l’Internet, soit comme une organisation privée dépourvue de véritable pouvoir public. Les documents institutionnels examinés conduisent à une conclusion plus étroite : son influence est une chaîne, et chaque maillon possède sa propre source d’autorité.

Le premier maillon est la mission. Les règlements de l’ICANN présentent comme objet la coordination de systèmes d’identifiants uniques — notamment le système des noms de domaine, les ressources de numéros Internet, les paramètres de protocole et le système des serveurs racine. Ils indiquent aussi que la mission et les engagements d’intérêt public limitent l’action de l’organisation. Cette architecture est importante : elle autorise certaines fonctions de coordination tout en s’opposant à une prétention générale à contrôler les services, les contenus ou l’Internet dans son ensemble. Les règlements de l’ICANN constituent ici la source de référence, sous réserve de la version et des modifications applicables à la date de la décision étudiée.

Le deuxième maillon est institutionnel. Les actes constitutifs présentent l’ICANN comme une société californienne à but non lucratif d’intérêt public, et non comme une administration gouvernementale. Cette qualification ne rend pas ses décisions insignifiantes : elle permet d’expliquer pourquoi une partie de son contrôle passe par des relations contractuelles et par des procédures de gouvernance communautaire plutôt que par un pouvoir réglementaire général. Les actes constitutifs ne remplacent toutefois ni les règlements, ni les politiques, ni le contrat précis applicable à une opération.

Le troisième maillon est la politique communautaire. Les règles de développement des politiques et la liste des Consensus Policies décrivent un processus dans lequel certaines obligations peuvent être produites par les organisations et comités habilités, puis intégrées aux obligations des parties contractantes. Une politique ne devient donc pas nécessairement contraignante pour tous les utilisateurs d’Internet du seul fait qu’elle figure sur une page de l’ICANN. Sa portée dépend du sujet admissible, de la procédure suivie, de la date d’entrée en vigueur et de son incorporation dans le contrat applicable. L’index des Consensus Policies doit être lu avec les dispositions pertinentes des règlements et du contrat concerné.

Le quatrième maillon est le contrat. Les index des accords de registre et les documents de contractualisation des nouveaux domaines génériques montrent où rechercher les obligations d’un opérateur de registre. Le contrat exécuté — et non le modèle général — peut fixer les engagements relatifs aux politiques, à la continuité, à l’escrow des données, aux niveaux de service, au traitement des abus, aux audits, aux frais, à la résiliation et à la transition. L’index des accords de registre et les documents de contractualisation des nouveaux gTLD orientent vers ces instruments, mais ne prouvent pas à eux seuls les termes liant un opérateur déterminé.

Pour les bureaux d’enregistrement, la même logique apparaît dans le Registrar Accreditation Agreement. L’accord d’accréditation peut incorporer des politiques, imposer des obligations opérationnelles et prévoir des mécanismes de demande d’informations, de correction, de suspension, de résiliation, de transition et de règlement des différends. Mais il ne confère pas à l’ICANN une compétence illimitée : il lie d’abord les parties contractantes et doit être lu avec sa version, ses annexes et ses modifications en vigueur pendant la période examinée.

Cette chaîne explique la différence entre décision et exécution. Une décision du Conseil ou une politique communautaire peut ouvrir une obligation ; le contrat peut la rendre opposable à un registre ou à un bureau d’enregistrement ; l’opérateur contractant peut ensuite modifier un service ou une donnée. Le pouvoir institutionnel, le pouvoir contractuel et la capacité technique ne sont donc pas nécessairement détenus par la même personne. Dans un dossier concret, il faut demander : quelle règle autorise l’acte, quel contrat la reprend, qui possède la capacité de l’exécuter et quel événement observable démontre que l’exécution a eu lieu ?

Le Registry Services Evaluation Process illustre cette conversion. Il fournit une voie structurée pour examiner des services de registre nouveaux ou modifiés au regard de questions de sécurité, de stabilité et, selon le cas, de concurrence. La page du RSEP peut conduire aux demandes, évaluations, déterminations et renvois pertinents. Elle ne doit toutefois pas être généralisée à toutes les décisions de registre, de bureau d’enregistrement, de politique ou du Conseil.

Le contrôle contractuel constitue ensuite une voie d’action distincte. Les ressources de Contractual Compliance, la description de l’approche et du processus, les avis de mise en conformité et le formulaire de plainte décrivent une progression possible : plainte ou information, demande de documents, réponse de la partie contractante, correction et, si nécessaire, mesure contractuelle. Un avis d’infraction établit cependant la position de l’ICANN ; il ne constitue pas nécessairement une décision finale sur tous les faits ou toutes les responsabilités.

La question du recours ne se résout donc pas par une réponse unique. Les règlements et les ressources consacrées à la Reconsideration et à l’Independent Review Process, ainsi que les procédures supplémentaires de l’IRP, indiquent des mécanismes formels pour certaines actions ou omissions de l’ICANN. Leur portée dépend de l’éligibilité, des délais, de la norme de contrôle et de la nature exacte de l’acte contesté. Un recours institutionnel n’est pas automatiquement une action en dommages-intérêts, une procédure d’appel générale ou un moyen de suspendre toute opération.

D’autres voies ont une fonction différente. La Cooperative Engagement Procedure, la Documentary Information Disclosure Policy, le Bureau de l’Ombudsman, le Complaints Office et l’Empowered Community peuvent aider à obtenir une information, à exposer un grief, à faciliter un engagement ou à exercer une forme de surveillance institutionnelle. Ils ne produisent pas tous le même effet : certains éclairent une décision, d’autres examinent un processus, d’autres encore peuvent participer à des pouvoirs de gouvernance prévus par les textes.

Le mécanisme causal est ainsi limité mais puissant : mission, procédure communautaire, incorporation contractuelle, exécution opérationnelle, puis contrôle ou recours. La faiblesse possible se situe à chaque transition. Une mission générale ne prouve pas qu’une mesure particulière entre dans le champ autorisé. Une politique publiée ne prouve pas son incorporation dans le contrat d’un opérateur. Un contrat ne prouve pas que la procédure de conformité a été respectée. Un recours disponible sur le papier ne garantit pas qu’il intervienne avant qu’une modification technique ou administrative ne produise ses effets.

Pour analyser une décision future, il faut donc conserver quatre pièces : la version des règlements applicable à la date pertinente, le texte de politique et son historique d’entrée en vigueur, le contrat exécuté et ses amendements, puis le dossier de mise en œuvre ou de contestation. Les pages générales de l’ICANN sont utiles pour localiser ces pièces, mais les textes applicables à la date de l’événement demeurent déterminants. La recherche utilisée pour ce briefing n’a pas permis de vérifier en direct les versions actuelles, les redirections, les dates d’effet, les amendements ni l’issue de dossiers individuels.

Toute conclusion sur une décision précise doit donc être reprise à partir des documents exécutés et des registres contemporains.

L’autorité de l’ICANN est finalement moins un bloc qu’un assemblage. Elle devient vérifiable lorsque le lecteur peut relier une compétence limitée à une politique admissible, une politique à une obligation contractuelle, l’obligation à une action identifiable et l’action à une voie de réexamen. Lorsqu’un de ces liens manque, il faut parler d’autorité alléguée ou de capacité opérationnelle apparente, non d’un pouvoir établi.

Sources

Répertoire : https://btw.media/fr/directory/internet-corporation-for-assigned-names-and-numbers.