Résumé

  • L’autorité de l’ICANN est distribuée entre ses statuts, ses accords relatifs aux fonctions IANA, la gestion de la zone racine et les contrats conclus avec les registres et bureaux d’enregistrement.
  • Les mécanismes de responsabilisation peuvent examiner certaines actions ou omissions du Conseil, mais ils ne constituent ni un appel général de toutes les décisions opérationnelles ni une garantie de réparation immédiate.

Le vrai sujet : séparer les pouvoirs qui sont souvent confondus

Dans le débat public, trois propositions sont régulièrement mélangées. La première affirme que l’ICANN coordonne les identifiants uniques. La deuxième lui attribue un pouvoir direct sur la racine du DNS. La troisième la décrit comme un régulateur mondial. Ces formulations ne sont pas équivalentes.

Les statuts de l’ICANN définissent sa mission, ses pouvoirs, sa structure et plusieurs obligations de responsabilisation. Ils organisent aussi des procédures permettant de contester certaines décisions du Conseil. Mais un texte constitutif ne suffit pas, à lui seul, à expliquer comment une modification de délégation devient une modification du fichier de zone racine ou comment une obligation de politique devient une obligation imposée à un opérateur commercial. Pour cela, il faut suivre les instruments qui relient la mission au fonctionnement quotidien.

La première distinction est celle entre coordination et autorité publique. Les documents de l’ICANN décrivent une institution de coordination mondiale. Ils ne montrent pas que l’organisation dispose, comme un gouvernement, d’une compétence générale sur tous les opérateurs de réseau, tous les noms de domaine ou toutes les juridictions. Sa capacité d’action est plutôt construite par un ensemble de règles, d’accords et de relations contractuelles. Cette limite est importante : elle empêche de confondre une position centrale dans l’architecture du DNS avec une souveraineté générale sur Internet.

Les statuts de l’ICANN constituent le premier étage de cette architecture. Ils établissent la mission de l’organisation, ses pouvoirs et ses obligations institutionnelles. Ils prévoient également des mécanismes de responsabilisation, dont la demande de réexamen et le processus de réexamen indépendant pour certaines contestations dirigées contre des actes ou omissions du Conseil. Le texte donne donc le cadre de légitimité interne : il permet de demander si une décision respecte les Articles of Incorporation ou les statuts, plutôt que de présumer que toute décision prise par l’institution est automatiquement valide.

Une chaîne opérationnelle, pas un bouton unique

Le deuxième étage apparaît dans la fonction de nommage IANA. L’accord relatif à la fonction de nommage IANA assigne des responsabilités opérationnelles et prévoit des exigences de performance, de rapport et de responsabilisation. Il transforme une fonction institutionnelle générale en obligations plus déterminées : il faut accomplir certaines tâches, respecter des attentes de service et rendre compte de leur exécution.

Cette contractualisation ne signifie pas que l’accord attribue à l’ICANN un pouvoir illimité. Elle signifie plutôt que le rôle de l’opérateur et les exigences de fonctionnement sont formulés dans un instrument vérifiable. L’accord peut alors servir à examiner ce qui devait être fait, par qui et selon quelles attentes. La question de la légitimité devient partiellement une question de conformité : l’acteur compétent a-t-il exécuté la responsabilité qui lui était attribuée, et l’existence d’un mécanisme de rapport permet-elle de le démontrer ?

La gestion de la zone racine ajoute une autre séparation. La description de la gestion de la zone racine présente une coordination entre l’ICANN, l’opérateur des fonctions IANA et l’entité qui autorise les changements de la zone racine. Une demande de délégation, de redélégation ou de modification n’est donc pas simplement l’expression d’une décision unilatérale de l’ICANN. Plusieurs rôles sont nécessaires pour que la décision de politique ou la responsabilité contractuelle produise un effet dans le système technique.

Cette chaîne permet de distinguer au moins quatre questions : qui formule ou applique la politique ; qui vérifie qu’une demande satisfait aux critères ; qui prépare ou traite la modification opérationnelle ; et qui autorise le changement dans la zone racine. Selon le cas, les réponses peuvent relever d’organisations différentes. L’ICANN peut occuper une position centrale dans la coordination sans être l’unique acteur capable de faire apparaître le résultat dans la base ou le fichier faisant autorité.

Cette distinction compte lors d’un incident. Si une décision est contestée, il ne suffit pas de demander pourquoi l’ICANN l’a prise. Il faut aussi identifier l’étape où l’effet a été produit, l’acteur qui détenait la capacité technique correspondante et le document qui encadrait cette capacité. Une plainte adressée au mauvais acteur peut confirmer l’existence d’un recours formel tout en laissant intact le risque opérationnel.

Le levier le plus concret : les contrats d’opérateurs

La troisième partie de la chaîne est contractuelle. Les accords de registre imposent aux opérateurs de domaines génériques de premier niveau des obligations relatives à l’exploitation technique, à la conformité, à la conservation des données, aux politiques consensuelles, au règlement de certains litiges et aux rapports. Les conditions varient selon les accords et leurs avenants. Il serait donc incorrect de traiter un accord unique comme une règle universelle applicable à tous les registres.

Le point commun est toutefois clair : l’ICANN ne dépend pas uniquement d’une persuasion institutionnelle. Pour les opérateurs liés par un accord, elle peut agir à travers des obligations contractuelles et des mécanismes d’exécution prévus par le texte applicable. Les remèdes peuvent comprendre une notification de manquement, une période de correction, des mesures liées à la conformité, voire une suspension ou une résiliation lorsque l’accord le permet. La portée exacte dépend du contrat, de la violation alléguée et de la procédure suivie.

Les accords d’accréditation des bureaux d’enregistrement montrent une autre version du même levier. Un bureau d’enregistrement accrédité n’est pas placé sous une compétence réglementaire mondiale générale de l’ICANN. Sa relation avec l’organisation passe principalement par l’accréditation, les obligations contractuelles, les politiques consensuelles et les mécanismes de conformité ou de fin de relation prévus dans l’accord applicable.

Cette structure explique pourquoi l’ICANN peut disposer d’un contrôle important sur certains points sans être l’autorité de tout ce qui arrive autour d’un nom de domaine. Un registre exploite une extension. Un bureau d’enregistrement fournit des services aux titulaires. Un opérateur de serveur racine assure un rôle technique distinct. Une autorité publique peut appliquer son propre droit. L’ICANN peut établir des règles ou faire respecter certains engagements contractuels, mais elle ne remplace pas automatiquement ces acteurs dans leurs propres domaines de responsabilité.

La différence entre coordination, contrat et autorité publique est donc pratique, pas seulement terminologique. La coordination décrit la mise en relation de responsabilités. Le contrat crée des obligations opposables entre parties déterminées. L’autorité publique repose sur une compétence juridique attribuée par un État ou un autre ordre juridique habilité. Présenter l’un comme l’autre produit une analyse exagérée du pouvoir de l’ICANN et masque les lieux où un recours pourrait réellement fonctionner.

Quand le contrôle passe par l’accréditation

Le cas des bureaux d’enregistrement permet de rendre la chaîne plus concrète. L’ICANN peut exiger le respect de certaines obligations parce qu’un accord d’accréditation lie l’opérateur à l’organisation. Une défaillance peut alors ouvrir une procédure de conformité ou une mesure contractuelle. Mais ce mécanisme ne transforme pas l’ICANN en tribunal chargé de statuer sur tous les droits substantiels liés à un nom.

Un conflit portant sur une marque, une fraude, une ordonnance judiciaire ou la propriété alléguée d’un nom peut engager des acteurs et des procédures différents. L’ICANN peut appliquer une politique ou un engagement contractuel dans le périmètre qui lui est attribué ; elle ne peut pas nécessairement trancher la totalité de la question juridique sous-jacente. La décision administrative, l’exécution par un opérateur de registre ou de bureau d’enregistrement et le jugement d’un tribunal peuvent se succéder sans avoir la même source de légitimité.

Cette séparation évite aussi de surestimer la portée d’une mesure contractuelle. Une suspension ou une résiliation peut réduire la capacité d’un opérateur à fournir un service dans le cadre de son accord avec l’ICANN. Elle ne prouve pas à elle seule qu’un tribunal aurait reconnu une violation civile ou pénale. Inversement, l’absence d’une mesure contractuelle ne prouve pas que le comportement est juridiquement licite. Chaque résultat doit être attribué à l’instrument qui le produit.

Le recours : vérifier une décision, pas promettre son annulation

La présentation du processus de réexamen indépendant décrit un mécanisme permettant à un demandeur admissible de contester une action ou une omission alléguée du Conseil. Un groupe de réexamen évalue si l’action contestée est compatible avec les Articles of Incorporation et les statuts de l’ICANN. Le mécanisme est donc conçu comme un contrôle de conformité institutionnelle.

Cette description impose deux limites. Premièrement, l’IRP n’est pas un appel général de chaque décision de politique, de conformité ou d’exploitation. L’éligibilité, le type d’acte contesté, les délais et les autres conditions de procédure déterminent si le mécanisme peut être utilisé. Deuxièmement, l’existence d’un contrôle ne signifie pas qu’il produira immédiatement le résultat opérationnel recherché par le demandeur. Une décision peut examiner la conformité d’un acte sans reproduire toutes les formes de réparation disponibles devant un tribunal.

La page consacrée aux mécanismes de responsabilisation de l’ICANN situe l’IRP parmi d’autres outils : demandes de réexamen, processus de l’Ombudsman et pouvoirs communautaires issus des réformes de gouvernance postérieures à la transition. Ces mécanismes ont des périmètres, des conditions d’accès et des résultats distincts. Ils forment un système de contraintes, pas une voie unique de correction automatique.

La question de la légitimité doit donc être posée en deux temps. Le premier est institutionnel : la décision a-t-elle été prise conformément aux pouvoirs, procédures et limites prévus par les textes ? Le second est opérationnel : même si une contestation est recevable et fondée, le mécanisme peut-il agir assez tôt pour empêcher ou inverser la conséquence concrète ? Ces deux tests ne donnent pas toujours la même réponse.

Un recours tardif peut établir qu’une procédure a été violée tout en laissant une modification technique, une relation contractuelle ou une position de marché évoluer entre-temps. À l’inverse, une mesure provisoire ou une suspension dans un processus peut préserver une situation sans résoudre la question de fond. Il faut donc éviter de présenter « recours disponible » comme synonyme de « résultat réparable ».

Ce que l’ICANN peut contrôler — et ce qu’elle ne contrôle pas seule

À partir des instruments publics recensés, le contrôle de l’ICANN peut être décrit sur trois surfaces.

La première est normative. Les statuts et les politiques déterminent la mission, les procédures, les critères et les obligations applicables dans le système de coordination. Cette surface répond à la question : quelle règle ou quel mandat prétend guider la décision ?

La deuxième est contractuelle. Les accords IANA, les accords de registre et les accords d’accréditation traduisent certaines responsabilités en engagements, rapports, obligations de conformité et mesures en cas de manquement. Cette surface répond à la question : quelle relation permet d’exiger un comportement déterminé d’un opérateur déterminé ?

La troisième est institutionnelle. Les demandes de réexamen, l’IRP, l’Ombudsman et les pouvoirs communautaires créent des voies de surveillance ou de contestation. Cette surface répond à la question : qui peut demander qu’une décision soit examinée, selon quelle norme et avec quelle forme de résultat ?

Aucune de ces surfaces ne suffit à établir un contrôle absolu. La fonction technique peut être exécutée par une organisation ou une équipe distincte. La modification de la zone racine implique des rôles coordonnés. Les registres et bureaux d’enregistrement restent des opérateurs liés par leurs propres accords. Les serveurs racine ne deviennent pas des agences de l’ICANN par le seul fait qu’ils participent à la résolution DNS. Les gouvernements conservent leurs compétences juridiques et leurs pouvoirs d’exécution.

La formulation la plus exacte est donc la suivante : l’ICANN détient une capacité institutionnelle et contractuelle de coordination et de contrainte dans des périmètres définis, mais cette capacité produit ses effets par l’intermédiaire d’autres acteurs, d’autres instruments et d’autres ordres juridiques. La robustesse du système dépend de l’alignement de ces éléments, pas de la seule existence d’une organisation centrale.

Le test de durabilité : suivre le dossier jusqu’à l’effet réel

Pour mesurer si la responsabilisation est durable, un observateur devrait suivre une décision au-delà de sa publication initiale. Quatre éléments sont particulièrement importants.

D’abord, le dossier doit permettre d’identifier la norme invoquée : statut, politique, accord IANA, accord de registre, accord d’accréditation ou règle d’une autre institution. Sans cette identification, le débat reste au niveau des descriptions générales.

Ensuite, il faut identifier l’acteur qui a pris la décision et celui qui a pu l’exécuter. Une décision du Conseil, une instruction opérationnelle, une modification de registre et une action d’un bureau d’enregistrement peuvent être liées sans être le même acte.

Troisièmement, le recours doit être évalué selon son calendrier. Quels délais s’appliquent ? Une demande suspend-elle l’effet de la décision ? Une mesure provisoire existe-t-elle ? Une décision favorable peut-elle restaurer l’état antérieur, ou seulement constater une irrégularité et demander une nouvelle décision ?

Enfin, il faut regarder la trace publique laissée par le processus. Les documents montrent-ils ce qui a été demandé, examiné, refusé, corrigé ou transmis ? Les mécanismes de responsabilisation de l’ICANN sont utiles précisément parce qu’ils permettent de poser ces questions, mais leur existence ne dispense pas de vérifier le dossier concret.

Cette méthode évite deux erreurs symétriques. La première consiste à conclure que l’ICANN est toute-puissante parce qu’elle occupe une position centrale. La seconde consiste à conclure qu’elle n’a aucun pouvoir parce qu’elle n’est pas un gouvernement. Son pouvoir réel est plus étroit et plus technique : il réside dans la combinaison d’un mandat institutionnel, de procédures, de contrats et de relations d’exécution.

Conclusion : la légitimité se mesure au point où le recours rencontre l’exécution

Les instruments publics examinés dessinent une architecture de pouvoir distribuée. Les statuts définissent le mandat et les mécanismes internes de contrôle. L’accord relatif à la fonction de nommage IANA formule des responsabilités opérationnelles. La gestion de la zone racine coordonne plusieurs acteurs. Les accords de registre et d’accréditation donnent à l’ICANN des leviers contractuels sur certains opérateurs. L’IRP et les autres mécanismes de responsabilisation peuvent examiner certaines décisions du Conseil selon des normes et des conditions déterminées.

Ce dispositif ne doit être décrit ni comme une souveraineté mondiale ni comme une simple conversation entre organisations. Il produit des effets matériels dans le DNS, mais ces effets passent par des contrats, des opérateurs, des procédures et des autorités distinctes. La question la plus importante pour un opérateur, un registre, un bureau d’enregistrement ou un gouvernement n’est donc pas seulement « l’ICANN a-t-elle décidé ? ». C’est : quel instrument autorise cette décision, quel acteur peut la mettre en œuvre, quel délai laisse le recours et quelle réparation demeure possible après l’exécution ?

Le prochain test empirique serait de suivre un dossier précis de délégation, de conformité ou de contestation depuis la règle invoquée jusqu’à la modification effectivement appliquée. Tant que cette chaîne n’est pas documentée, on peut établir la structure de l’autorité, mais pas encore mesurer sa durabilité dans un cas concret.