Résumé

  • La portée d’ICANN résulte d’une combinaison de mission corporative, de procédures multipartites, de contrats et d’arrangements techniques, et non d’un transfert unique de souveraineté.
  • Le véritable test de responsabilité consiste à savoir si un recours peut atteindre l’acte contractuel ou technique qui produit le dommage, avec un remède suffisamment rapide, contraignant et exécutoire.

La question que le mot « gouvernance » laisse ouverte

ICANN est une société californienne à but non lucratif d’intérêt public. Ses statuts décrivent une mission liée à la coordination des systèmes d’identifiants uniques de l’Internet et à la stabilité opérationnelle du réseau (statuts constitutifs d’ICANN). Cette forme juridique compte : elle ne constitue pas, à elle seule, une délégation de pouvoir législatif, de police, de licence ou de jugement.

Les statuts d’ICANN ne sont donc pas la source d’une souveraineté numérique générale. Ils établissent une capacité corporative et un objet. Les limites deviennent plus explicites dans les statuts internes : la mission vise la coordination des identifiants uniques et l’élaboration de politiques raisonnablement liées à ces fonctions techniques. Les Bylaws indiquent aussi qu’ICANN ne dispose pas d’une autorité réglementaire accordée par un gouvernement et ne peut pas réglementer les services ou les contenus qui utilisent les identifiants au-delà de sa mission (Bylaws d’ICANN).

Cela ne signifie pas qu’ICANN n’a aucun effet réglementaire. Une règle incorporée à un accord de registre ou de bureau d’enregistrement peut conditionner l’accès à une ressource indispensable. Une décision de conformité peut menacer une relation contractuelle. Une modification technique peut affecter la continuité d’un service. L’effet pratique peut ressembler à une réglementation tout en reposant sur un contrat privé, une dépendance technique ou une coordination institutionnelle.

La distinction n’est pas sémantique. Elle détermine qui peut contester la décision, devant quel forum, selon quel standard et avec quelle chance d’obtenir une suspension, une annulation ou une réparation effective.

Une chaîne d’autorité plutôt qu’un centre de commandement

L’histoire de la fonction IANA montre pourquoi il est trompeur de chercher un détenteur unique du pouvoir. Avant la transition de 2016, la fonction IANA était inscrite dans un contrat d’achat public des États-Unis, qui liait le rôle d’ICANN à un cadre de supervision de la NTIA et à des responsabilités relatives à la gestion de la zone racine (ancien contrat des fonctions IANA). Ce document est historique : il ne décrit pas à lui seul l’autorité actuelle d’ICANN.

La proposition de transition de 2016 a plutôt conçu un dispositif distribué. Elle prévoyait un rôle pour Public Technical Identifiers, un contrat entre ICANN et PTI pour la fonction de nommage, un suivi par le Customer Standing Committee, des revues périodiques et spéciales de la fonction IANA, ainsi que des arrangements distincts avec les registres Internet régionaux et l’IETF (proposition de transition de la supervision IANA). La transition n’a donc pas transformé ICANN en détenteur plénier des ressources. Elle a redistribué des tâches, des contrôles et des possibilités de recours.

Pour le nommage, le contrat ICANN-PTI décrit des services opérationnels, des obligations de performance, des rapports, des niveaux de service et des mécanismes d’escalade (contrat de la fonction de nommage IANA). PTI est une société affiliée contrôlée par ICANN. Le mécanisme est ainsi contractuel, mais il n’est pas un simple achat auprès d’un fournisseur indépendant.

La maintenance de la zone racine ajoute une autre séparation. L’accord conclu avec Verisign distribue les responsabilités techniques entre ICANN ou PTI et le mainteneur de la zone racine. Il traite notamment des niveaux de service, de la gestion des changements, de la sécurité, de la performance et des remèdes contractuels (accord de maintenance de la zone racine). La capacité de faire fonctionner une partie du système n’est donc pas identique à la capacité d’en fixer toutes les politiques.

Le même principe apparaît dans les services de numérotation. L’accord de niveau de service de l’IANA place ces services dans une relation contractuelle avec ICANN et les registres Internet régionaux, tandis que la politique de numérotation se développe dans le système des RIR (accord de niveau de service pour les services de numérotation IANA). Pour les paramètres de protocole, le mémorandum entre l’IETF et ICANN distingue l’élaboration des politiques et standards, relevant des processus de l’IETF, du travail technique de tenue des registres (mémorandum IETF-ICANN).

Dans chacun de ces cas, la question utile est la même : qui peut agir sur le registre, la publication, la modification ou la continuité du service ? La réponse peut varier selon la couche examinée.

Quand une politique devient une contrainte

Le point où la gouvernance acquiert une force pratique se trouve souvent dans les contrats conclus avec les registres et les bureaux d’enregistrement. Le dépôt des accords de registres montre que les exploitants de domaines génériques sont régis par des accords propres à chaque TLD, des amendements, des spécifications et des politiques incorporées (dépôt des accords de registres). Les accords de base et leurs spécifications couvrent, selon les cas, l’exploitation technique, l’entiercement des données, les services de données d’enregistrement, les contacts d’abus, les frais, les audits, la conformité, les manquements et la résiliation (accord de base des registres, spécifications approuvées).

Les bureaux d’enregistrement sont eux aussi soumis à des politiques consensuelles et à des obligations contractuelles (politiques consensuelles applicables aux bureaux d’enregistrement). Une politique née d’un processus multipartite ne devient pas automatiquement une loi. Elle acquiert cependant une portée opérationnelle lorsqu’elle est adoptée selon les instruments compétents puis intégrée à une relation dont dépend l’accès à une fonction essentielle.

Cette chaîne comporte plusieurs points de friction. Une organisation peut contester la procédure d’adoption. Un opérateur peut soutenir que la règle dépasse la mission d’ICANN. Une partie non contractante peut subir les effets de la règle sans disposer d’un droit contractuel direct. Un acteur soumis à une mesure de conformité peut avoir un recours formel, mais pas nécessairement un moyen de suspendre l’exécution avant la perte d’un domaine, d’un service ou d’une position commerciale.

La question de l’autorité doit donc être reformulée. Il ne suffit pas de demander si ICANN « réglemente ». Il faut identifier l’instrument qui permet de conditionner l’action d’un autre acteur, puis le mécanisme qui peut arrêter ou corriger cette condition.

Des recours nombreux, mais pas interchangeables

ICANN publie plusieurs voies de conformité et de responsabilité : conformité, demande de réexamen, Independent Review Process, Ombudsman, Empowered Community, Customer Standing Committee et revues de la fonction IANA (page de conformité; réexamen; Independent Review Process; procédures supplémentaires de l’IRP; Ombudsman; Empowered Community; Customer Standing Committee).

Leur simple existence ne permet pas de conclure qu’ils offrent le même niveau de protection. Ils peuvent différer par leurs conditions d’accès, leurs délais, leurs standards de contrôle, leurs pouvoirs provisoires, leur caractère contraignant, leur coût et leur capacité à atteindre l’acte qui a produit le dommage.

Le réexamen peut viser une action ou une inaction du Board, mais il ne constitue pas nécessairement une suspension automatique d’une mesure opérationnelle. L’IRP peut examiner la conformité d’une action avec les statuts, les Bylaws ou certaines obligations, mais sa portée pratique dépend du type de décision, de la recevabilité et de la mise en œuvre du résultat. L’Ombudsman peut offrir une voie de résolution ou de médiation, sans être un tribunal doté du même pouvoir de contrainte. L’Empowered Community dispose de remèdes structurels, mais son intervention repose sur des seuils et des procédures propres.

La responsabilité institutionnelle se joue ainsi en quatre étapes : l’organisation doit-elle expliquer sa décision ? Quelqu’un peut-il la faire examiner ? Le recours peut-il empêcher ou corriger le dommage ? Le résultat peut-il être imposé à l’acteur qui contrôle le point technique ou contractuel ? Une réponse positive à la première question ne garantit pas les trois suivantes.

Le test du contrôle effectif

Pour analyser une décision d’ICANN, il faut suivre son parcours concret.

Première étape : identifier la source de la règle. S’agit-il des statuts, des Bylaws, d’une politique élaborée par une organisation de soutien, d’une résolution du Board, d’un contrat, d’une spécification ou d’un arrangement technique ?

Deuxième étape : identifier le mécanisme de transformation. La règle a-t-elle été incorporée à un accord ? A-t-elle déclenché une obligation de conformité ? A-t-elle été transmise à PTI, à Verisign, à un registre ou à un bureau d’enregistrement ?

Troisième étape : identifier l’acte qui produit l’effet. Est-ce une décision de ne pas déléguer, une modification du registre, une suspension, une demande de correction, une publication technique ou une résiliation ?

Quatrième étape : tester le recours au même endroit. Le forum saisi peut-il ordonner une mesure à l’acteur qui contrôle cet acte ? Peut-il suspendre l’exécution ? Peut-il imposer une correction ? Peut-il protéger une personne qui n’est pas partie au contrat ?

C’est ici que la distinction entre responsabilité et remède devient essentielle. Une procédure peut fournir une explication convaincante après l’événement sans pouvoir préserver la ressource pendant le litige. Elle peut déclarer qu’une décision était irrégulière sans disposer d’un moyen direct de rétablir l’état antérieur. Elle peut être ouverte à l’opérateur contractant tout en laissant le tiers affecté sans accès équivalent.

Ce que les sources établissent — et ce qu’elles ne permettent pas encore d’affirmer

Le dossier public établit une architecture de capacités distribuées. Les statuts et les Bylaws définissent la forme corporative, la mission et certaines limites. Les contrats donnent une force opérationnelle à des politiques dans les relations avec les registres et les bureaux d’enregistrement. Les accords IANA répartissent des tâches techniques et des contrôles entre plusieurs institutions. Les mécanismes de responsabilité offrent des voies distinctes de contestation.

En revanche, les sources utilisées ici ne suffisent pas à établir la version actuellement en vigueur de chaque instrument, l’historique complet de ses amendements, ni les délais et coûts comparés de chaque recours. Elles ne fournissent pas non plus une décision judiciaire, une loi indépendante ou une analyse experte tranchant définitivement la question d’une éventuelle autorité publique réglementaire. Les documents officiels d’ICANN sont particulièrement solides pour décrire le texte des instruments et la position institutionnelle, mais ils ne constituent pas à eux seuls une analyse indépendante des effets de pouvoir contestés.

Une enquête complète devrait donc reconstruire un cas concret : une politique, son adoption, son incorporation contractuelle, l’acte de conformité ou d’exécution technique, puis le recours engagé par la partie touchée. Sans cette reconstruction, il est impossible de savoir si la responsabilité existe seulement sur le papier ou si elle atteint le point où le dommage se produit.

Conclusion : l’autorité se mesure au point où l’effet devient réel

ICANN n’est ni un gouvernement mondial, ni un simple forum sans prise sur le réel. Son influence vient d’une combinaison plus précise : capacité corporative, procédures multipartites, contrats, dépendances techniques et dispositifs de contrôle. Cette combinaison peut produire des effets réglementaires dans la pratique sans démontrer, à elle seule, une délégation de souveraineté.

Le prochain test de légitimité ne sera pas de compter les mécanismes de responsabilité. Il consistera à demander si une personne ou une organisation affectée peut atteindre l’acte concret qui a causé le préjudice, obtenir une décision suffisamment rapide, puis faire exécuter la réparation par l’acteur qui tient effectivement le levier.

Tant que cette chaîne n’est pas reconstruite sur un cas précis, l’architecture d’ICANN reste mieux décrite comme un système distribué de coordination et de contrôle contractuel que comme un pouvoir public unifié.