Doctrine

Le Domain Name System : point de départ de la conquête de l'Internet par l'État ?


Le Domain Name System est une ressource fondamentale de l'Internet. Initialement développé et administré au sein d'instances privées, il est désormais la cible d'interventions étatiques, tant sur le plan national que sur le plan international. Cet article étudie tout d'abord l'évolution de ces interventions et la controverse qu'elles suscitent. Il examine ensuite les différentes pistes qui pourraient être suivies pour accorder aux États un véritable pouvoir de réglementation sur les noms de domaine. Cette évolution pourrait être un premier pas vers un contrôle étatique du Net.

The Domain Name System is a critical Internet resource. Initially developed and managed by private actors, it is the target of state intervention now, both on a national and international level. The first part of this article examines the evolution of these interventions and the controversy they give rise to. The second part focuses on different ways how to give the State a real regulatory power on domain names. This development might be a first step toward a state-controlled Internet.


INTRODUCTION

L'Internet s'est développé en dehors du giron étatique, au sein d'une communauté d'ingénieurs qui en édictaient eux-mêmes les protocoles et les règles, notamment au moyen de RFC (Request for Comments) pour le développement des standards techniques du réseau2. Le réseau a ainsi pu être décrit comme une zone de non-droit, sans frontières géographiques permettant l'application effective des règles de droit traditionnelles. Cette époque semble révolue : le réseau des réseaux fait désormais partie intégrante de la vie publique et les états cherchent à y appliquer des règles qu'ils édictent eux-mêmes. Le Domain Name System (DNS) pourrait servir de point de départ à cette conquête du Net.

Le DNS est une ressource fondamentale du réseau qui a pour objet la résolution de noms de domaine, c'est-à-dire la reconnaissance de l'adresse IP qui correspond à un nom de domaine, afin de permettre la communication. Il repose sur un ensemble hiérarchisé et distribué de « serveurs de noms de domaine », contenant la liste de paires noms-adresses relative à une portion de l'espace de nommage. Au sommet de la hiérarchie, on trouve une zone unique, la « racine », puis les zones de haut niveau, puis celles de second niveau et ainsi de suite. Un nom de domaine reflète la hiérarchie du DNS : il est en général composé de deux parties principales organisées hiérarchiquement de droite à gauche et séparées par des points : d'une part, un « nom de domaine de premier niveau » (Top-Level Domain ou TLD) qui détermine le domaine auquel appartient le site concerné (comme « .com », « .eu », « .be », ...) et, d'autre part, un « nom de domaine de second niveau » (Second-Level Domain ou SLD) qui est déterminé par celui qui en demande l'enregistrement. Au sein des noms de domaine de premier niveau, il convient encore de distinguer, d'une part, les noms de domaine génériques (generic Top-Level Domain ou gTLD) comme « .com », « .org », « .net », ... et, d'autre part, les noms de domaine nationaux (countrycode Top-Level Domain ou ccTLD) comme « .be », « .fr », « .de », ... Chaque TLD nécessite un registre (registry), une autorité centrale qui tient la liste officielle des SLD enregistrés sous le TLD. Cette autorité permet d'assurer que chaque SLD est unique. Les registres peuvent déléguer par contrat les fonctions d'enregistrement des noms de domaine à des bureaux d'enregistrement (registrars), placés au niveau suivant de la hiérarchie. Ce sont alors ces bureaux qui offrent aux usagers de l'Internet la possibilité d'enregistrer un nom de domaine de second niveau sous le TLD du registre.

Un aspect important du DNS tient à la nécessité de la centralisation et de la hiérarchisation de sa gestion. En effet, alors que la décentralisation du réseau est un des éléments de son succès, une forme de coordination technique centralisée est requise pour en assurer l'interopérabilité et pour garantir le caractère unique de chaque nom de domaine. Jusqu'en 1998, cette centralisation était assurée de manière plutôt informelle. Le DNS avait été créé et géré par un seul homme, Jon Postel, responsable également de la gestion des extensions génériques (gTLD) au sein de l'IANA (Internet Assigned Numbers Authority). C'est également lui qui procédait aux délégations des extensions nationales (ccTLD). Les activités de Postel étaient financées par le gouvernement américain. Le développement exponentiel du réseau, notamment avec l'autorisation du trafic commercial et l'invention du World Wide Web, a entraîné la mise sur pied d'une structure de gestion plus formelle. Cette évolution a mené à la privatisation de la gestion de son architecture et à la mise sur pied de l'ICANN (Internet Corporation for Assigned Name and Numbers), après la publication d'un Livre vert3 et d'un Livre blanc4 par le Département américain du Commerce (DoC). L'ICANN a été constituée sous la forme d'une société californienne sans but lucratif et a été dotée d'une structure complexe pour assurer la représentation des intérêts des différentes parties prenantes du réseau et une prise de décision ascendante (bottom up). Les politiques de l'ICANN sont en effet initiées et développées au sein d'organisations de soutien, la GNSO (Generic Names Supporting Organization) et la ccNSO (Country- Code Names Supporting Organization), puis soumises à l'approbation du Conseil d'administration. L'ICANN, qui regroupe gouvernements, secteur privé et société civile, a dès lors souvent été décrite comme un modèle de « gouvernance multi-parties prenantes ».

J'étudierai dans cette contribution les voies que pourrait emprunter l'état pour s'assurer un véritable pouvoir de réglementation sur le DNS (II). Avant cela, je procéderai à un état des lieux des relations entre les états et le DNS, en soulevant les principales controverses qui les entourent (I). Je conclurai en soulignant comment le DNS pourrait servir de tremplin à un véritable contrôle étatique du Net.

I. ÉTAT DES LIEUX

Trois aspects des relations entre les États et le DNS sont particulièrement controversés et méritent un examen approfondi : les pouvoirs exorbitants des États-Unis (A.), la montée en puissance du comité consultatif gouvernemental au sein de l'ICANN (B.) et la gestion des extensions nationales (C.).

A. Les pouvoirs exorbitants des États-Unis sur le DNS

Le gouvernement américain occupe une place de choix dans la gestion du DNS pour des raisons historiques. Malgré l'objectif de privatisation affiché lors de la mise sur pied de l'ICANN, celle-ci est encore, à de nombreux égards, soumise contractuellement au DoC (1.). Cette réalité a suscité de nombreuses critiques (2.), auxquelles le gouvernement américain a entendu répondre en entamant un processus de désengagement en 2006 (3.).

1. Les premières années

Dès l'origine, la tutelle américaine sur le DNS s'est opérée au moyen de trois instruments : un Memorandum of Understanding conclu entre le DoC et l'ICANN, le contrat permettant à l'ICANN d'assurer la fonction IANA et l'accord de coopération entre le DoC et Verisign.

Le Memorandum of Understanding (MoU)5 fut conclu en 1998 entre le DoC et l'ICANN pour formaliser le transfert de compétences dévolues à cette nouvelle entité. Toutefois, avant de procéder au transfert intégral de ces compétences, le DoC voulait s'assurer que l'ICANN était en mesure d'assumer de manière autonome les responsabilités importantes liées à la gestion technique du DNS. À cette fin, le MoU prévoyait une période de transition de deux ans au cours de laquelle l'ICANN collaborerait avec le DoC pour développer et tester les mécanismes, méthodes et procédures devant être mis en place pour assurer la gestion des fonctions du DNS. Cette période de transition s'avéra rapidement être une mainmise de longue durée du DoC sur le DNS. En effet, le MoU fut amendé à six reprises et quatre de ces amendements visaient entre autres à prolonger le terme du contrat. De plus, le gouvernement américain n'avait pas établi dans le texte du MoU des critères d'évaluation objectifs et précis pour mesurer la capacité de l'ICANN de gérer ses responsabilités de manière autonome. Ce qui revenait à dire, concrètement, que l'ICANN ne serait reconnue autonome par le gouvernement américain que lorsque celui-ci le voudrait bien6. Le MoU mettait aussi à charge de l'ICANN toute une série de tâches fondamentales à accomplir durant la période de transition et celle-ci était tenue de faire régulièrement rapport au DoC sur ses avancées dans leur exécution. Cette configuration permettait au DoC de définir les objectifs et priorités de la gestion du DNS, qui reflétaient clairement les intérêts du gouvernement américain7, tandis que seule la réalisation de ceux-ci était déléguée au secteur privé. Par ailleurs, il faut souligner que le DoC avait la capacité de menacer l'ICANN de la remplacer par une autre société, sans que celle-ci ne puisse s'y opposer : le premier amendement du MoU prévoyait dans ce cas de figure que l'ICANN transférerait au DoC tous les contrats conclus avec les registres et bureaux d'enregistrement8.

Les fonctions IANA recouvrent essentiellement l'allocation de blocs d'adresses IP aux Registres Internet Régionaux (RIR), les activités administratives associées à la gestion de la racine, comme la désignation d'administrateurs lors de délégations et de re-délégations de TLD, ainsi que la coordination des protocoles et des paramètres techniques. Le gouvernement américain approuva le transfert de ces fonctions à l'ICANN par un contrat conclu en février 20009. Ce contrat a été modifié et renouvelé depuis lors ; sa version en vigueur a été signée en 2006 et expirera le 31 mars 201210. Ce contrat est le plus important pour l'ICANN dans l'exercice de ses compétences. Sans lui, l'ICANN n'aurait que peu, voire pas du tout, d'autorité hiérarchique sur la coordination des systèmes d'identification sur l'Internet. Il faut cependant relever que ce contrat n'autorise pas l'ICANN à modifier, ajouter ou supprimer des informations contenues dans le fichier-zone racine11. L'accord de coopération conclu avec Verisign12 définit la relation des parties en ce qui concerne la racine du DNS et le rôle de Verisign en tant que registre des gTLD « .com » et « .net ». L'accord requiert de Verisign qu'elle mette en oeuvre toutes les décisions de coordination technique prises par l'ICANN et qu'elle attende les instructions écrites du DoC lorsque ces décisions concernent le fichier-zone racine13. Cette dernière disposition14 confère un véritable droit de veto au DoC, que le gouvernement américain revendique en raison de l'autorité suprême qu'il prétend détenir sur le fichier-zone racine. Pendant la création de l'ICANN, le gouvernement américain a indiqué plusieurs fois qu'il renoncerait à cette autorité et la déléguerait à l'ICANN15. En 2005, au cours du Sommet mondial sur la société de l'information, il annonça cependant sa volonté de ne pas abandonner ce pouvoir16. Bien plus que le MoU ou le contrat IANA, cet accord de coopération doit être considéré comme étant la principale source de l'autorité du DoC sur la racine17. Étant donné la structure hiérarchique du DNS, la capacité de modifier ou de refuser de modifier le fichier-zone racine contenu dans le serveur racine A confère une autorité de facto sur le DNS18. La date d'expiration de l'accord de coopération actuel est fixée au 30 septembre 201219.

Grâce à la combinaison des trois instruments présentés ci-dessus, le gouvernement américain était en mesure d'intervenir dans l'élaboration des politiques de l'ICANN - et ainsi de faire valoir ses intérêts. Jusqu'à ce qu'il estime la société californienne suffisamment autonome, il pouvait opposer son veto à toute décision prise par celle-ci visant à apporter une modification au fichier-zone racine et il pouvait mettre fin au transfert de compétences de l'ICANN selon son bon vouloir.

2. Contestations de l'hégémonie américaine sur le DNS

La situation décrite ci-dessus a évidemment suscité de nombreuses critiques. Le processus de « privatisation » du DNS souffrait d'une contradiction manifeste : l'ICANN, qui était formellement une entité privée, restait soumise contractuellement au DoC. Il s'agissait véritablement d'un régime global dans lequel le pouvoir de décision était délégué à des acteurs privés transnationaux sous la supervision d'un seul gouvernement20. Cette importance exceptionnelle accordée à un État dans le DNS contraste en effet singulièrement avec la gouvernance d'autres infrastructures internationales dédiées aux communications, comme l'Union postale universelle (UPU) ou l'Union internationale des télécommunications (UIT).

Il a pu ainsi être affirmé que l'établissement de l'ICANN et le transfert de la gestion du DNS à celle-ci ne constituaient pas l'abdication du gouvernement américain, mais ont au contraire permis l'affirmation des pouvoirs de celui-ci sur l'infrastructure du réseau, à une époque où ils étaient très contestés21. Selon K. Cukier, il s'agit avant tout d'une divergence de perspectives22. Le gouvernement américain considérait le transfert de la gestion du DNS à une entité privée comme la preuve de son renoncement volontaire à une source de pouvoir primordiale tandis que d'autres y voyaient plutôt une manoeuvre intelligente pour conserver, de manière moins flagrante, l'hégémonie des États-Unis sur le réseau. Il n'est dès lors pas étonnant que l'ICANN ait été perçue par les autres États souverains comme une menace pour leur souveraineté, malgré le fait qu'elle soit présentée comme une instance purement technique. De manière logique et prévisible, l'ICANN est ainsi devenue la cible de processus intergouvernementaux focalisés sur la gouvernance de l'Internet.

Le Sommet mondial sur la société de l'information (SMSI), qui s'est tenu de 2003 à 2005, fut le théâtre de ces affrontements. Il rassemblait des représentants des gouvernements, du secteur privé et de la société civile, dans le but de discuter de l'avenir de la société de l'information dans son ensemble. Ce sont cependant la gestion du DNS en général et l'ICANN en particulier qui ont été au centre des débats, durant lesquels des positions diamétralement opposées ont été défendues par les représentants des gouvernements. À l'issue du Sommet, un modèle de co-régulation fut proposé, afin de tenter de concilier les différents points de vue23. Cette solution de compromis fut jugée décevante par les pourfendeurs de l'hégémonie américaine car il n'était pas mis fin à la tutelle du gouvernement américain sur le DNS.

3. Après le Sommet mondial sur la société de l'information

Le gouvernement américain n'est pas resté sourd aux conclusions du SMSI et aux critiques qui ont été formulées à son encontre. Le pouvoir de contrôle du DoC sur l'ICANN fut allégé une première fois en 2006, lors d'un nouvel amendement du MoU, renommé à cette occasion Joint Project Agreement (JPA)24. Les aspects les plus prescriptifs de la tutelle du DoC furent abandonnés et remplacés par des mécanismes de responsabilité de l'ICANN. Au lieu de lui imposer l'accomplissement de tâches spécifiques dans un certain délai, une liste générale de ses responsabilités était dressée (Affirmation of Responsibilities), parmi lesquelles la prise en considération effective de l'avis des gouvernements sur les aspects de politique publique de la coordination technique de l'Internet. L'obligation de faire périodiquement rapport au DoC était quant à elle remplacée par la publication par l'ICANN d'un rapport annuel.

L'année 2009 peut être considérée comme un tournant dans les relations entre le DoC et l'ICANN. Pour la première fois de l'histoire de l'ICANN, le MoU-JPA ne fut pas renouvelé à l'expiration de son terme. Un nouvel accord, l'Affirmation of Commitments (AoC)25, fut au contraire conclu entre le DoC et l'ICANN. La nature juridique de cet accord, constitué par une série d'engagements pris par les deux parties, est assez vague26. M. Froomkin estime qu'il ne s'agit pas d'un contrat, car le DoC ne prend aucun engagement contraignant. Selon lui, le fait que le DoC laisse le JPA expirer ne constitue pas une contrepartie aux engagements de l'ICANN, car le JPA aurait de toute façon expiré si les deux parties ne s'accordaient pas pour le renouveler27. La grande nouveauté de l'AoC est le nouveau mécanisme d'auto-évaluation : l'ICANN s'engage à procéder tous les trois ans à la révision de son action dans quatre domaines (responsabilité et transparence, sécurité et stabilité, concurrence et WHOIS28) au moyen d'équipes composées conjointement par le président du GAC et le président du CA. Les recommandations qui résulteront des révisions seront ensuite transmises au CA. Une autre innovation de l'AoC est son caractère « permanent ». Contrairement au MoU-JPA, ce nouvel accord n'est pas conclu pour une période de trois ans renouvelables, mais peut être conjointement amendé à tout moment ou résilié unilatéralement moyennant un préavis de 120 jours. Il est également important de souligner que cet accord ne prévoit plus la possibilité pour le DoC, au cas où il résilierait l'AoC, de se voir attribuer les contrats de l'ICANN avec les registres et bureaux d'enregistrement.

En laissant expirer le JPA, l'administration Obama renonce à son moyen le plus visible de contrôler directement l'ICANN. Il convient toutefois de noter qu'il ne s'agit pas d'une abdication inconditionnelle. Le gouvernement américain a en effet obtenu dans cet accord que l'ICANN conserve son siège américain et reste ainsi soumise au droit américain. Il s'est également octroyé un siège dans l'équipe chargée de la révision des questions de responsabilité et de transparence. Le caractère permanent de l'AoC permet au DoC d'être assuré de conserver ces prérogatives. Par ailleurs, seul le MoU-JPA est concerné par l'AoC, le contrat IANA et l'accord de coopération avec Verisign sont inchangés.

B. La montée en puissance du GAC

L'ICANN a été constituée sous la forme d'une société de droit privé au sein de laquelle toute participation significative des états était exclue. Seul un rôle consultatif limité leur fut accordé en 1998, par l'intermédiaire du GAC (pour Governmental Advisory Committee) (1.). Les pouvoirs du GAC se sont ensuite substantiellement étendus (2.), ce qui suscite la controverse (3.).

1. La création du GAC : un comité uniquement consultatif

Le Livre blanc du DoC affirmait, sans ambiguïté, que ni les gouvernements en tant que souverains, ni les organisations intergouvernementales en tant que représentantes des gouvernements ne devraient participer à la gestion des noms et adresses Internet29. Néanmoins, pour répondre aux revendications de la Commission européenne et d'organisations intergouvernementales, le Livre blanc admettait que les gouvernements puissent agir comme usagers de l'Internet ou occuper une fonction consultative dépourvue de droit de vote30.

Les statuts originels de l'ICANN, conformément à ces recommandations, excluaient la participation de représentants gouvernementaux au Conseil d'administration31 et les confinaient à une fonction consultative au sein du GAC32. Ce comité était chargé d'examiner et de donner son avis sur les activités de l'ICANN quand elles concernaient des préoccupations gouvernementales, particulièrement quand il pouvait y avoir des interactions avec les diverses législations et réglementations nationales et internationales33.

Le GAC a établi en 1999 un ensemble de principes de fonctionnement34 qu'il met à jour régulièrement. Certains des principes, encore en vigueur aujourd'hui35, doivent être relevés. Le premier considérant du document illustre l'importance que les gouvernements accordent au DNS : le système de nommage et d'adressage est présenté comme une ressource publique qui doit être gérée dans l'intérêt de la communauté globale de l'Internet. Le GAC reconnaît ensuite qu'il n'est pas un organe de décision mais un forum de discussion pour les gouvernements. Il prévoit de se réunir au moins une fois par an et chaque fois qu'il l'estime approprié. Ces réunions sont en principe tenues en privé. Le GAC doit travailler en vue d'atteindre le consensus de ses membres, mais s'il n'est pas possible, le président, qui est élu parmi les membres, doit transmettre la totalité des points de vue exprimés au CA. Un quorum de présence, fixé à la majorité simple des membres en 1999 et aujourd'hui abaissé au tiers de ceux-ci, est nécessaire pour que des décisions puissent être prises à la réunion.

2. Évolution vers une plus grande implication

Le GAC ne resta pas longtemps cantonné à un rôle strictement consultatif. Dès février 2002, Stuart Lynn, le président de l'ICANN, publia un rapport sur la réforme de l'organisation qui appelait, entre autres, à un accroissement du rôle des gouvernements36. Il estimait que le choix d'un modèle totalement privé pour gérer le DNS n'était pas judicieux, entre autres parce qu'il isolait l'ICANN des institutions du « monde réel », les gouvernements. Selon lui, impliquer les gouvernements, « les représentants les plus légitimes de leurs populations », permettrait de résoudre certains des problèmes auxquels l'ICANN était confrontée : le défaut de participation d'acteurs-clés du DNS (notamment les gestionnaires de ccTLD), le manque de légitimité démocratique et le financement. S. Lynn n'allait pas jusqu'à préconiser une approche intergouvernementale traditionnelle, qui restait à ses yeux une « mauvaise idée ». Au contraire, il plaidait pour un partenariat public-privé équilibré, dans lequel notamment un tiers du CA serait nommé directement par le GAC ou les gouvernements nationaux.

Un comité composé d'administrateurs, l'Evolution and Reform Committee (ERC), fut chargé d'examiner cette proposition et d'élaborer des recommandations37. Ce processus de réflexion mena à l'amendement des statuts de l'ICANN par le Conseil d'administration en décembre 200238. Deux modifications furent apportées aux relations entre le GAC et le CA. D'une part, le GAC fut autorisé à envoyer au CA un agent de liaison, sans droit de vote39. D'autre part, des prérogatives particulières furent accordées au GAC en matière de politique publique40. Désormais, le CA est obligé de notifier en temps utile au GAC toute proposition soulevant des questions de politique publique, que lui-même ou une autre entité de l'ICANN soumet aux commentaires du public. Il doit prendre en compte toute réponse du GAC à cette notification avant de prendre des mesures. Le GAC peut également soumettre directement des questions au CA, par voie de commentaire, d'avis préalable ou de recommandation spécifique. Au cas où le CA déciderait de ne pas suivre l'avis du GAC, il doit informer celui-ci et exposer les raisons de son choix. Les statuts prévoient dans ce cas que le GAC et le CA doivent tenter de trouver, de bonne foi et en temps opportun, une solution acceptable par les deux parties. Si pareille solution ne pouvait être trouvée, le CA doit motiver, dans sa décision finale, son choix de ne pas suivre l'avis du GAC.

Cette première réforme ne modifia pas immédiatement le rôle du GAC au sein de l'ICANN. Il a fallu attendre 2005 pour le voir peser réellement sur une décision du CA, à l'occasion des discussions entourant l'introduction d'une extension « .  » réservée aux contenus à caractère pornographique41. Après l'avoir longuement examinée, le CA reconnut en juin 2005 que cette candidature émanant de la société privée ICM Registry répondait aux critères d'admissibilité42. Le GAC n'avait alors transmis aucun avis au CA au sujet de cette proposition. L'attitude de certains gouvernements changea après la médiatisation de la décision prise par l'ICANN et la polémique que celle-ci suscitait. Ils furent nombreux à écrire au CA pour lui faire part de leur inquiétude et pour lui demander de reconsidérer sa décision. Sous la pression, l'ICANN finit par retirer son approbation à la proposition d'ICM Registry en mai 200643. L'action du CA dans cette affaire fut, à la demande d'ICM, examinée par un panel indépendant, conformément à la procédure prévue dans les statuts de l'ICANN44. Son rapport fut très clair : la décision du CA violait l'obligation de l'ICANN de prendre ses décisions en appliquant des politiques « neutres, objectives et équitables »45. Ce rapport n'était pas contraignant mais le CA décida toutefois de reconsidérer la candidature d'ICM46. Le gTLD « .  » fut finalement approuvé, malgré l'avis négatif du GAC, le 18 mars 201147.

Au final, la croisade menée par le GAC contre le « .  » s'est donc soldée par un échec. Le succès sans précédent engrangé en 2006 a toutefois fait prendre conscience aux membres du GAC qu'il leur était possible d'imposer leurs vues au sein de l'ICANN. Les méthodes de travail du comité ont été revues pour lui permettre d'agir de manière plus proactive et plus systématique48. La matière des nouveaux gTLD est une illustration de cette nouvelle approche. En juin 2011, le CA a pris la décision historique de lever les restrictions qui pesaient sur l'introduction de nouveaux gTLD. Pour ce faire, il a soumis à l'avis du public un « Guide de candidature gTLD »49 qui inclut des propositions émanant du GAC50. Sans rentrer dans les détails, relevons que ce Guide prévoit des moyens d'assurer le respect des « noms géographiques » et des « principes généraux du droit international en matière de morale et d'ordre public, tels qu'ils sont formulés dans les accords internationaux appropriés ». L'ICANN expose que des restrictions peuvent s'appliquer pour assurer le respect de ces principes car l'exercice du droit à la liberté d'expression « implique des devoirs et des responsabilités spécifiques ». Le contrôle du contenu est ainsi devenu, à la demande du GAC, un des éléments-clés de cette nouvelle procédure. Le rôle de l'ICANN présente désormais des aspects éminemment politiques, car un rôle de pur coordinateur technique impliquerait la neutralité de l'ICANN à l'égard de la signification sociale des noms de domaine. Les vives tensions autour du « .  » et les pressions constantes du GAC ont ainsi changé la donne, l'ICANN cherche désormais à éviter de créer de nouvelles polémiques. M. Mueller estime cette évolution dangereuse pour la liberté d'expression, telle qu'elle est protégée par le Premier Amendement à la Constitution américaine. Selon lui, toute tentative de satisfaire tous les états souverains entraîne inévitablement l'application des formes de régulation de contenu les plus restrictives51. Le Comité des ministres du Conseil de l'Europe a aussi récemment exprimé son inquiétude à ce sujet et mis en garde contre le « risque que fait courir la réglementation excessive de l'espace des noms de domaine et des chaînes de noms à l'exercice de la liberté d'expression et du droit de recevoir et de communiquer des informations et à l'exercice de la liberté de réunion et d'association ». Il a précisé que « toute réglementation, en tant qu'elle constitue une forme d'ingérence, devrait remplir les conditions figurant aux articles 10 et 11 de la Convention européenne des droits de l'homme et être conforme à la jurisprudence correspondante de la Cour européenne des droits de l'homme »52.

Enfin, il faut encore noter que de nouvelles missions ont été confiées au GAC par l'intermédiaire de l'Affirmation of Commitments conclue entre le DoC et l'ICANN. Le GAC s'est vu reconnaître un rôle important dans un domaine sensible : les nouveaux mécanismes de révision de l'ICANN (cfr. supra). Il est cependant trop tôt pour pouvoir juger de l'impact qu'auront ces nouvelles procédures. La promesse de l'ICANN au sujet de l'action du Conseil d'administration est en effet très prudente et vague : « prendre des mesures » ne signifie certainement pas être d'accord avec les équipes de révision et n'engage pas le CA à exécuter leurs recommandations53.

3. Un comité controversé

La participation des gouvernements dans la société privée en charge du DNS suscite la controverse depuis la création de l'ICANN (a.). La relation du GAC avec le CA a fait l'objet d'une révision, conformément au nouveau mécanisme prévu dans l'AoC (b.).

a. De nombreuses inconnues

Le statut légal du GAC suscite tout d'abord de nombreuses questions. Est-il un organe conventionnel traditionnel ? Ou bien ne s'agitil que d'une réunion informelle de représentants étatiques ? Un accord international classique entre gouvernements est en principe soumis à un processus de ratification parlementaire au niveau national et, s'il est contraire à la constitution nationale, peut être contesté devant des juridictions étatiques. M. Mueller observe qu'aucun de ces moyens de contrôle démocratique ne s'applique à la relation entre l'ICANN et le GAC, car ce dernier n'est qu'un corps consultatif, formellement dépourvu de pouvoir de décision. M. Mueller est particulièrement critique face à cette situation car elle permet aux gouvernements d'agir sans contraintes légales en général et sans être tenus de respecter les droits de l'homme en particulier54.

La mesure dans laquelle ces représentants peuvent engager leurs états de manière contraignante est également peu claire.

M. Froomkin a observé à ce sujet que la majorité des décisions du GAC ne contiennent pas d'engagements des gouvernements mais suggèrent plutôt à d'autres acteurs du DNS (l'ICANN, les gestionnaires de ccTLD, ...) d'agir d'une certaine manière. Il estime néanmoins que la participation de délégués accrédités par des gouvernements du monde entier suggère que les communiqués du GAC sont l'expression d'une opinio juris, qui pourrait contribuer un jour à la formation d'une nouvelle norme internationale ou même à du droit international55.

Le manque de transparence du GAC est aussi dénoncé. En effet, le fonctionnement interne du comité demeure un mystère pour les observateurs extérieurs. Le GAC ne publie pas de compte rendu de ses réunions et il est dès lors difficile de savoir comment sont élaborés ses avis. Les états-Unis, le Canada et l'Union européenne sont souvent présentés comme les meneurs. L'ascension du GAC pourrait donc ne représenter qu'un transfert d'une autorité concentrée entre les mains américaines à un nouveau type d'alliance transatlantique56.

Le rôle du GAC au sein de l'ICANN est également controversé. Selon les statuts de la société, il ne s'agit que d'un comité consultatif. Depuis 2002, ses membres ont été reconnus comme responsables des questions de politique publique et des mécanismes ont été introduits pour assurer que le CA prenne en compte leurs recommandations. Cette situation a été critiquée car le CA peut désormais justifier le rejet d'une politique développée au sein d'une organisation de soutien en se fondant sur un avis du GAC.

M. Mueller estime que ce pouvoir arbitraire du CA menace le processus normal d'élaboration des décisions, fondé sur une approche ascendante et « multi-parties prenantes »57. Le GAC peut en effet, simplement par son opposition, bloquer ou renverser une décision qui a obtenu un soutien suffisant des autres parties de l'ICANN pour être adoptée. L'adoption par le CA des positions défendues par le GAC reviendrait donc à conférer à ce dernier un pouvoir de décision supérieur à celui des organisations de soutien, voire une forme de droit de veto, ce qui reviendrait à dénier le caractère essentiellement privé de l'ICANN58.

b. Les recommandations de l'ATRT

Conformément aux dispositions de l'AoC, un premier examen de la responsabilité et de la transparence de l'ICANN a été effectué en 2010. L'Accountability and Transparency Review Team (ATRT) a entre autres examiné les relations entre le CA de l'ICANN et le GAC. L'équipe a identifié une série de dysfonctionnements dans ces relations et a émis une série de recommandations en conséquence dans son rapport59.

Tout d'abord, l'ATRT relève que les statuts de l'ICANN ne définissent pas ce qui constitue l'avis du GAC et recommande une clarification de cette notion. Les membres du GAC semblent penser que toute communication émanant du comité, y compris les lettres de son président et les comptes rendus de réunion, constitue un avis du GAC, entraînant l'obligation pour le CA d'expliquer les raisons pour lesquelles il ne le suivrait pas. Les membres du CA, quant à eux, ne partagent pas cette vision, particulièrement quand le GAC leur transmet, à défaut d'avoir pu atteindre un consensus, un exposé des positions divergentes des membres du GAC. Dans ce cas, il leur est impossible de suivre partiellement l'avis sans provoquer des conflits et rivalités au sein du GAC.

L'ATRT souligne ensuite que, même si les statuts requièrent que le CA demande l'avis du GAC à chaque fois qu'il envisage une décision qui aurait des conséquences de politique publique, il n'existe aucun mécanisme formel pour introduire et enregistrer ces demandes. Dans les faits, il semble que le CA ne demande l'avis du GAC que s'il l'estime nécessaire. L'ATRT recommande donc la mise en place d'un processus formel de notification au GAC et de publication en ligne des avis reçus. Ce processus doit prendre en compte le fait que l'avis du GAC peut prendre un certain temps à être établi, pour deux raisons. D'une part, certains membres du GAC doivent procéder à des consultations avec le gouvernement qu'ils représentent avant de pouvoir entamer les négociations avec les autres membres du GAC. D'autre part, le GAC lui-même ne se réunit en moyenne que trois fois par an.

Un autre problème examiné est la prise en considération de l'avis du GAC par le CA. Les membres du GAC se plaignent du manque de réaction explicite du CA et ont souvent l'impression qu'ils n'ont pas été suffisamment écoutés et qu'ils n'ont d'autre choix que de répéter leurs demandes à la prochaine occasion. L'ATRT recommande l'établissement d'un processus déterminant les modalités de réponse du CA ainsi que les détails qu'il devra fournir s'il ne suit pas l'avis du GAC.

L'ATRT recommande aussi d'impliquer le GAC plus tôt dans le processus de décision. L'équipe estime qu'il serait bénéfique que les organisations de soutien reçoivent l'avis du GAC le plus tôt possible. Ne plus avoir à attendre que la question ait été transmise au CA par l'organisation de soutien pour pouvoir requérir l'avis du GAC permettrait de réduire les délais de prise de décision. Cela permettrait aussi de diminuer les allers-retours entre le GAC et l'ICANN qui, selon l'ATRT, n'ont été bénéfiques à personne dans les cas du « .  » et des nouveaux gTLD.

Ces recommandations ont été soumises au Conseil d'administration le 30 décembre 2010. Conformément à l'Affirmation of Commitments, le CA aurait dû prendre des mesures avant le 30 juin 2011. L'ATRT a publié, en juin 2011, un rapport sur l'action entreprise par le CA à la suite de ses recommandations. En ce qui concerne les recommandations liées au GAC, il constate que des discussions ont été entamées mais qu'il est probable que des décisions n'interviendront pas avant la fin de l'année 201160. Si les recommandations de l'ATRT sont suivies par le CA, il s'agirait d'un nouveau pas vers un plus grand pouvoir des états au sein de l'ICANN. La clarification de leur rôle et l'obligation faite au CA de demander leur avis et de répondre à leurs recommandations touchant aux politiques publiques apporteraient un poids nouveau au GAC. Autoriser le GAC à donner son avis directement aux organisations de soutien serait également un pas vers un processus de décisions impliquant réellement toutes les parties prenantes. Mais, dans son rapport, l'ATRT ne va pas jusqu'à proposer que le GAC obtienne plus qu'un rôle consultatif dans ce processus.

J. Weinberg estime d'ailleurs que les gouvernements ne sont peut-être pas prêts à sortir de ce rôle consultatif. En effet, si le GAC est impliqué au début du processus de décision, aux côtés des organisations de soutien, les gouvernements devront se plier aux règles de l'ICANN et accepter que leurs opinions ne prévalent pas toujours. Ce n'est qu'à cette condition que le GAC serait en mesure d'acquérir la crédibilité d'un participant au processus de décision ordinaire de l'ICANN61.

C. La problématique des ccTLD

La matière des noms de domaine de premier niveau nationaux (country-code Top-Level Domain ou ccTLD) est au coeur des préoccupations gouvernementales, tant sur le plan de la délégation des extensions au niveau de l'ICANN (1.) que de leur gestion quotidienne au niveau national (2.).

1. La délégation des noms de domaine nationaux

La politique de délégation des noms de domaine nationaux a progressivement été encadrée par différents textes, afin de mettre fin aux conflits apparus avec l'expansion du réseau (a.). Certaines questions suscitent cependant toujours la polémique (b.).

a. Les principes

La procédure de délégation d'un ccTLD consiste, après réception et examen d'une requête officielle, en l'inclusion d'un nouveau TLD correspondant à un code de pays dans le fichier-zone racine et en la désignation de la personne responsable de l'administration de son registre. Pour éviter d'avoir à se prononcer sur la question éminemment politique de savoir si un territoire était effectivement un état ayant vocation à obtenir un ccTLD, Jon Postel renvoyait à la liste de codes de pays contenue dans la norme ISO 3166-1 publiée par l'Organisation internationale de normalisation (ISO) et incorporée dans la RFC 920 en 198462. Le premier ccTLD, « .us » pour les états-Unis, fut créé et délégué en 1985. De manière générale, dans les années 1980, les décisions de création et de délégation de ccTLD étaient prises par Postel de manière informelle, sans accord écrit. La délégation d'un ccTLD était accordée à une « personne responsable », ce qui correspondait le plus souvent à la première personne, publique ou privée, qui en faisait la demande63, tant que certaines conditions de base, comme la présence sur le territoire symbolisé par le ccTLD et un équipement informatique adapté, étaient remplies. Cette manière informelle de procéder était un reflet de la nature fondamentalement privée et bénévole du réseau, car elle aboutissait le plus souvent à une délégation à une instance non gouvernementale, comme le département informatique d'une université. En cas de conflit, lorsque deux parties revendiquaient le même ccTLD, Postel encourageait le consensus et faisait pression pour que le différend soit réglé avant la délégation. Il menaçait par exemple de refuser de déléguer le ccTLD tant que les parties ne s'étaient pas accordées sur une solution64.

Les états, alors qu'ils considéraient la gestion des télécommunications comme une fraction de leur souveraineté, ne se sont pas intéressés aux délégations effectuées par Postel. Au début des années 1990, l'Internet est devenu un phénomène mondial et l'attitude des gouvernements a évolué. De plus en plus de pays comptaient des ordinateurs connectés au réseau. L'impact socio-économique des ccTLD devint évident et les demandes de délégation augmentèrent considérablement. L'expansion du réseau apporta aussi une dose de contentieux à la délégation de ccTLD. Dans certains pays, des agences gouvernementales et des entités privées se disputaient entre elles le droit de se voir déléguer le ccTLD. Jon Postel décida alors d'expliciter la base sur laquelle fonder une décision de délégation, clarification qui a vu le jour en 1994 sous la forme de la RFC 159165. Les prescriptions qu'elle contient sont assez sommaires. Elle dispose tout d'abord qu'il doit y avoir un gestionnaire désigné pour superviser l'espace de nommage du ccTLD. Ce gestionnaire agit en tant que « trustee » à la fois pour la nation et la communauté globale de l'Internet. C'est en raison de cette qualité qu'il doit « agir équitablement » envers tous ceux qui demandent l'enregistrement d'un nom de domaine sous ce ccTLD et faire « un travail satisfaisant ». Les « parties intéressées de manière significative » dans le ccTLD doivent ainsi s'accorder sur le fait que la délégation est appropriée. De plus, la RFC 1591 assure que l'IANA respectera strictement la liste ISO 3166-1 car ce n'est pas son travail de « décider ce qui est et ce qui n'est pas un pays ». Si un conflit devait naître, l'IANA tenterait « de faire parvenir les parties en conflit à un accord entre elles et en général de ne pas agir pour changer les choses à moins que les parties en conflit ne s'accordent sur ce point ». L'IANA n'interviendrait que dans le cas où le gestionnaire désigné se serait considérablement « mal conduit », sans indiquer toutefois ce qui pourrait constituer pareille mauvaise conduite. Après la publication de la RFC 1591, l'IANA a publié quelques « ccTLD News Memos », le plus souvent dans un but de communication. Le premier d'entre eux, néanmoins, énonce que l'IANA « prend les souhaits des gouvernements de pays au sérieux et les prendra en grande considération dans toute discussion de transition »66.

Le transfert de la fonction IANA vers l'ICANN n'a pas fondamentalement modifié ces principes de base. Le Livre blanc, qui déniait toute participation des gouvernements nationaux et des organisations intergouvernementales dans la gestion du DNS, concédait toutefois que ceux-ci avaient et continueraient à avoir l'autorité « de gérer ou d'établir des politiques pour leurs propres ccTLD »67. L'ICANN publia, peu après sa création, un nouveau document en matière d'administration et de délégation de ccTLD, l'ICP-1, qui combine la RFC 1591 et le « ccTLD News Memo #1 » et qui réaffirme que les souhaits des gouvernements seront pris très au sérieux68.

La matière des ccTLD est sans surprise au centre des préoccupations du GAC. Ses principes de fonctionnement, publiés en 1999, énoncent qu'un registre de ccTLD agit au nom des pouvoirs publics concernés, parmi lesquels les gouvernements qui ont la responsabilité ultime en matière de politique ayant trait à leur ccTLD, et ce conformément aux principes de la connectivité universelle de l'Internet69. L'année suivante, le GAC publia des principes spécifiques aux ccTLD, dans lesquels il revendiquait un rôle pour les gouvernements dans les procédures de délégation et de re-délégation70. La nouvelle version de ces principes, publiée en 200571, fait référence au principe de subsidiarité. Le GAC recommande en effet que les politiques en matière de ccTLD soient établies au niveau local, conformément au droit national, à moins qu'il ne soit démontré que la question ait un impact global et nécessite d'être résolue dans un cadre international.

b. Les difficultés

Deux questions concernant la gestion des ccTLD présentent des difficultés : le respect aléatoire de la norme ISO 3166-1 lors de la délégation (i.) et l'incertitude autour des procédures de re-délégation (ii.).

i. La norme ISO 3166-1

Pour apparaître dans l'ISO 3166-1, les noms et les codes doivent être enregistrés soit dans le « Bulletin de Terminologie Noms des pays » publié par les Nations Unies, soit dans les « Codes des pays et des régions pour utilisation statistique » maintenus par la Division de statistique des Nations Unies72. À défaut d'être repris dans un de ces documents, le nom n'entrera pas dans l'ISO 3166-1. Il faut souligner qu'il ne s'agit pas d'une liste d'états souverains mais d'un code international utilisé pour représenter des entités géographiques, qui contient par exemple le Sahara occidental et les Territoires palestiniens occupés.

Figurer dans la norme ISO 3166-1 est en principe la condition sine qua non pour pouvoir prétendre à l'inclusion d'un ccTLD dans le fichier-zone racine. Cette règle ne prévoit pas d'exceptions ; pourtant, dans les faits, elle n'a pas toujours été scrupuleusement respectée. En 1996, l'IANA a par exemple utilisé des codes ne figurant pas sur la liste officielle, mais réservés à l'époque par l'ISO aux services postaux pour attribuer des ccTLD à l'île de l'Ascension (« .ac »), Guernesey (« .gg »), Jersey (« .je ») et l'île de Man (« .im »). L'auteur de la RFC 3017 estime qu'il s'agit d'erreurs qui ne devraient pas servir de précédents73. En effet, ces codes réservés peuvent être demandés à l'ISO par toute personne souhaitant disposer d'un code pour l'exercice d'une activité spécifique. L'ICANN ou le candidat au ccTLD pourrait faire une telle demande à l'ISO, ce qui aurait pour conséquence qu'il n'y aurait plus de détermination externe de ce qui constitue une entité ayant vocation à se voir attribuer un ccTLD. De manière encore plus préoccupante, l'ICANN n'a pas toujours été neutre et objective, en accordant un ccTLD à des entités reprises seulement dans la liste des codes réservés et en le refusant à d'autres. Les cas de la Palestine et de l'Union européenne sont souvent comparés pour souligner que l'ICANN est parfois amenée, sous la pression des gouvernements, à prendre des décisions à connotation politique74. Dans le cas de la Palestine, la règle de la référence à la liste ISO 3166-1 a été strictement observée : ce n'est qu'après l'inclusion du code « ps » dans la liste officielle en 1999 que le ccTLD fut créé et délégué. Le fait que ce code figurait depuis 1996 sur une liste de réserve ne fut pas pris en compte75. Le traitement de l'Union européenne fut tout à fait différent. Malgré sa taille et son importance économique, l'Union ne figurait pas non plus dans la liste officielle ISO 3166-1, qui ne reprend pas les entités supranationales, mais apparaissait seulement sur une liste de réserve. En 1999, la Commission européenne a demandé à l'ISO l'autorisation d'étendre l'élément de code réservé EU aux applications liées à l'Internet. La réponse favorable de l'ISO permettait, selon la Commission, « d'utiliser l'élément de code EU comme un identifiant de type ccTLD, conformément à la pratique normale de mise en oeuvre de la liste ISO d'éléments de code réservés »76. Cette interprétation était démentie par le précédent palestinien mais elle fut suivie par le CA de l'ICANN qui approuva la délégation du ccTLD « .eu »77.

Au vu de ces décisions contradictoires, il ne fait désormais plus de doute que l'ICANN n'est pas qu'une organisation purement technique. Elle n'hésite plus à s'écarter de l'ISO 3166-1 pour se prononcer sur la souveraineté des territoires qui lui demandent l'attribution d'un ccTLD. L'absence de règles de conduite claires en la matière est évidemment à déplorer car elle ouvre la voie à des décisions arbitraires et des traitements de faveur du CA.

La re-délégation d'un ccTLD vise le changement de la personne responsable de l'administration du registre de ce ccTLD. L'ICP-1, qui a repris les principes développés dans la RFC 1591, prévoit deux procédures de re-délégation78. La première repose sur le consentement mutuel de l'ancien et du nouveau délégué tandis que la deuxième découle du droit que l'ICANN se réserve de révoquer une délégation dans les cas de « mauvaise conduite », de violation des dispositions de l'ICP-1 et de la RFC 1591 ou de problèmes persistant dans l'opération du domaine.

Les gouvernements se sentent évidemment concernés par le changement de la personne en charge du ccTLD représentant leur pays. L'ICP-1 prévoit que les souhaits des gouvernements seront pris au sérieux. Le GAC va plus loin et plaide pour que la re-délégation, qui est une question nationale, soit résolue au niveau national et conformément au droit national. Ce n'est qu'une fois qu'une décision finale formelle a été atteinte au niveau national que l'ICANN est invitée à initier le processus de re-délégation, en se basant sur les instructions contenues dans la décision nationale79.

Un précédent de re-délégation a fait grand bruit : celui du ccTLD «.us » car il a été l'occasion pour le gouvernement américain de démontrer qu'il était en mesure d'apporter unilatéralement des changements au fichier-zone racine. En effet, en octobre 2001, le gouvernement américain procéda lui-même à la re-délégation de son ccTLD, sans passer par l'ICANN et sans respecter les dispositions de l'ICP-1. Il informa ensuite l'ICANN, qui se trouva alors face à une alternative : soit accepter la re-délégation, soit créer une situation dans laquelle il y aurait des informations incohérentes dans ses bases de données80. Cela signifie donc que le gouvernement américain, par l'intermédiaire de Verisign, avait procédé lui-même à l'édition du fichier-zone racine. L'ICANN ne s'opposa pas à la re-délégation, afin de ne pas porter atteinte à la stabilité du DNS. Ce précédent est un motif d'inquiétude pour les autres états car en théorie, le DoC pourrait utiliser son autorité pour procéder à la suppression d'un ccTLD du fichier-zone racine et pour ainsi rendre inaccessibles toutes les adresses enregistrées sous ce ccTLD81. M. Froomkin tempère toutefois ces inquiétudes car ce précédent unique concerne le ccTLD américain et le GAC lui-même reconnaît que les ccTLD doivent être principalement gérés au niveau local. Rien ne permet d'affirmer que le gouvernement américain oserait agir de la sorte avec un autre TLD82.

2. L'intervention de l'État dans la gestion de son ccTLD

Les gouvernements ne se limitent pas à réclamer un droit de regard sur la délégation de leur ccTLD national. Ils interviennent également dans sa gestion au niveau national. Les formes que prend cette intervention sont assez variées (b.) tandis que les justifications invoquées à l'appui de l'action étatique sont souvent similaires (a.).

a. Les justifications de cette intervention

L'intervention des états dans leur ccTLD n'est pas innocente : l'extension nationale est vue comme un moyen d'établir la juridiction étatique sur le réseau. Selon M. Mueller, les gouvernements voudraient appliquer au DNS la configuration traditionnelle du monde physique, celle d'un monde divisé en territoires mutuellement exclusifs et contrôlés par des gouvernements souverains. Les noms de domaine nationaux étaient le point de départ le plus direct et le plus évident de cette vision. Si les gouvernements nationaux parvenaient à affirmer leur souveraineté sur leur ccTLD, ils pourraient être en mesure de traduire leur juridiction territoriale dans le cyberespace et dès lors disposer d'un rôle plus significatif dans la gouvernance de l'Internet83.

Le GAC a, dès sa première réunion, posé le principe selon lequel le DNS est une ressource publique qui doit être gérée dans l'intérêt de la communauté globale de l'Internet. Le GAC considère que les gouvernements sont les représentants des intérêts des habitants du pays ou territoire pour lequel le ccTLD a été délégué. Il en déduit que c'est à eux que revient la tâche d'assurer que le ccTLD est administré dans l'intérêt public. Il estime également que les gouvernements ont la responsabilité de protéger des « objectifs de politique publique » dans la gestion du ccTLD, tels que des pratiques transparentes, non discriminatoires et concurrentielles, l'égalité des usagers, le respect de la vie privée ou encore la protection des consommateurs. En raison de ces obligations, le GAC estime que la responsabilité ultime en matière d'élaboration de politiques applicables aux ccTLD revient aux gouvernements84. Le GAC assimile ainsi la gestion des ccTLD à une forme de « service public » pour légitimer l'intervention des pouvoirs publics.

De manière plus anecdotique, le gouvernement peut aussi justifier son intervention par la nécessité d'affecter les revenus importants générés par l'enregistrement sous son ccTLD à la réalisation d'objectifs d'intérêt général. Certains états se sont en effet vu attribuer une extension qui renvoie non seulement au code du pays dans la norme ISO 3166-1 mais qui correspond également à l'abréviation courante d'un domaine d'activités. Le ccTLD présente donc aussi un intérêt pour des personnes extérieures à l'état, comme s'il s'agissait d'un gTLD85. Rappelons que jusqu'en 2011, l'ajout de nouveaux gTLD était rare et strictement réglementé par l'ICANN. Détourner un ccTLD de sa fonction première permettait de contourner cette réalité. Le cas des îles Tuvalu et de leur très populaire extension « .tv » est célèbre à cet égard86.

b. Les formes de cette intervention

L'intervention de l'état dans la matière des ccTLD peut prendre deux formes. Elle peut d'une part s'opérer « en amont » lorsque le gouvernement contrôle l'administration du ccTLD (i.). D'autre part, l'état peut également édicter des règles spécifiques pour régler des conflits qui toucheraient le ccTLD « en aval » (ii.).

i. «En amont»

L'OCDE a réalisé en 2006 une étude sur l'évolution de la gestion des ccTLD87. Dans son rapport, elle observe que le statut des registres de ccTLD diffère d'un pays à l'autre, en partie par choix, en partie pour des raisons historiques. Une tendance est toutefois identifiée : l'intérêt et l'engagement croissants des gouvernements à l'égard de la gestion de leur ccTLD national. L'OCDE a relevé toute une série de pratiques des gouvernements en la matière, formelles ou informelles. La relation est formelle lorsque le registre du ccTLD est un organisme public mais aussi lorsque, via une déclaration des intéressés, un contrat ou l'adoption d'une législation, les modalités d'exercice de l'autorité publique sont déterminées. Le rôle du gouvernement est par contre considéré comme informel quand il se contente d'agir comme observateur ou conseiller. Les conclusions de l'OCDE concordent avec les résultats d'une précédente étude réalisée en 2004 par M. Geist à propos des relations de soixante-six gouvernements avec leurs ccTLD88.

Quelques exemples d'états européens permettent d'illustrer ces résultats. La gestion du ccTLD par un organisme public est plutôt rare en Europe. La Finlande fait figure d'exception : le registre responsable du ccTLD « .fi » est une agence gouvernementale, FICORA, qui est responsable depuis 1997 de l'administration des communications au sein du ministère finlandais des Transports et des Communications89.

Des formes de « partenariats public-privé » sont plus répandues90. La Norvège peut être citée comme exemple : le modèle complexe choisi pour la gestion du ccTLD « .no » a en effet été décrit comme permettant d'intégrer « le meilleur des deux mondes », en combinant les avantages des secteurs public et privé91. Dans ce modèle, les principes généraux applicables à l'enregistrement des noms de domaine - comme la transparence et la non-discrimination - sont déterminés par un règlement du gouvernement norvégien tandis que les conditions d'enregistrement détaillées sont établies par le registre Norid, un organisme sans but lucratif. Avoir accordé une base réglementaire à ces principes permet d'assurer qu'ils ne seront pas facilement modifiés. En revanche, les modalités de l'enregistrement sont fixées par Norid, après consultation de la communauté Internet norvégienne, au moyen de contrats de droit privé plus flexibles qu'un règlement. Ce modèle permet donc de réaliser un compromis entre réglementation étatique et autorégulation par les acteurs du réseau.

Un exemple de relation informelle peut être trouvé dans le modèle de gestion du ccTLD britannique «.uk ». Au Royaume-Uni, le registre Nominet est une association sans but lucratif indépendante de l'état. Toutefois, Nominet travaille avec le BIS, le département du gouvernement chargé du commerce et de la science. Cette collaboration profite aux deux parties. D'une part, le BIS a besoin d'être assuré que Nominet gère le ccTLD de manière appropriée car le commerce électronique dépend de la stabilité du DNS. D'autre part, Nominet a besoin d'être tenue informée de l'évolution du cadre législatif et réglementaire des questions liées à l'Internet92. Le gouvernement britannique, à côté d'autres parties prenantes, est également invité à participer au développement des politiques de Nominet, en proposant des questions et en ayant la possibilité de commenter les projets au cours du processus93.

ii. «En aval»

Les états sont également en mesure d'intervenir « en aval », soit au moyen de l'adoption de règles spécifiques aux noms de domaine, soit via le droit commun des contrats et des obligations.

Le législateur belge est par exemple intervenu dans la problématique du cybersquatting, en adoptant la loi du 26 juin 200394. Celle-ci introduit une nouvelle procédure de cessation au profit des personnes qui s'estiment lésées par l'enregistrement abusif d'un nom de domaine. Elle a été adoptée alors que des procédures alternatives étaient déjà en place pour traiter ce type de conflit, tant en matière de domaines génériques (UDRP) que du domaine « .be »95. Ces procédures connaissent un grand succès car elles sont rapides et efficaces, l'exécution forcée de la décision étant assurée par la complète maîtrise technique de l'ICANN et de DNS.be sur le système d'attribution des noms de domaine concernés96. Interrogé dès lors sur l'opportunité de l'introduction d'une procédure judiciaire aux objectifs et effets similaires, le ministre répondait qu'il serait « inadmissible que l'état renonce à son droit de rendre la justice, et ce, au seul bénéfice d'institutions d'arbitrage privées »97 car « cela ouvrirait la porte à l'autorégulation avec toutes les conséquences et les risques de contestation qu'elle comporterait »98. Cette affirmation illustre la volonté du gouvernement belge, étranger à la gestion en amont du « .be », d'intervenir coûte que coûte dans la matière des noms de domaine, même au prix d'une loi jugée peu utile et décevante99.

Dans une perspective plus générale, il faut souligner que le DNS consiste en un réseau de contrats, dont les obligations sont interprétées selon les règles du droit national des contrats et du droit international privé. Les contrats qui forment la base juridique de la gestion du DNS ne sont ainsi pas exempts de l'application de règles d'origine étatique. Le DNS n'est pas un ordre juridique parallèle, ni une zone de non-droit. De même, les tribunaux étatiques peuvent toujours fournir un remède ultime pour la résolution de conflits entre parties100, notamment entre titulaires de marque déposée et de nom de domaine, lorsque le demandeur souhaite réclamer des dommages et intérêts101.

La récente affaire Pirate Bay a montré les limites de l'intervention du juge étatique dans les matières touchant au DNS. En l'espèce, la cour d'appel d'Anvers avait ordonné à deux fournisseurs d'accès Internet le blocage de onze noms de domaine conduisant à des sites de télé-chargement illégal102. La Cour avait refusé le blocage des adresses IP, car il pouvait avoir un effet indésirable sur des tiers, et précisait que le blocage était limité aux noms énumérés. C'est là que le bât blesse : Pirate Bay s'est empressé de contourner l'interdiction en enregistrant un nouveau nom de domaine en néerlandais, non repris dans la liste de la Cour.

II. PISTeS POUR CONFÉReR AUX ÉTATS UN RÉeL POUVOIR SUR Le DNS

Tant en matière de gTLD que de ccTLD, les gouvernements nationaux estiment que le pouvoir de réglementer les noms de domaine leur revient, au moins en ce qui concerne les politiques publiques. Ces revendications étatiques ont mené à l'augmentation des pouvoirs du GAC et à une plus grande implication des autorités publiques dans la gestion de leur ccTLD au niveau national. L'augmentation des pouvoirs dévolus aux gouvernements annonce l'échec de la privatisation du DNS et de l'objectif d'autorégulation par les différentes parties prenantes du réseau. Il n'est plus inconcevable désormais d'imaginer le retour de l'état dans la production de normes contraignantes applicables à l'Internet. Deux voies pourraient ainsi être empruntées pour conférer aux acteurs publics un véritable pouvoir de réglementation sur le DNS. La première verrait la transformation de l'ICANN elle-même en organisation internationale classique (A.). La seconde, moins radicale, consisterait en la nationalisation des ccTLD (B.).

A. La mutation de l'ICANN en organisation intergouvernementale

Déterminer la nature publique ou privée de l'ICANN est loin d'être une sinécure. Formellement, il s'agit d'une entité privée sans but lucratif, soumise au droit californien. Toutefois, les gouvernements, et particulièrement le gouvernement américain, entretiennent une relation particulière, parfois tendue, avec l'ICANN, relation qui a évolué avec le temps vers une immixtion de plus en plus prononcée des autorités publiques dans le processus de contrôle et, dans une moindre mesure, dans le processus de prise de décision de l'ICANN. Le GAC est désormais bien plus qu'un comité strictement consultatif, ce qui laisse penser que la privatisation du DNS a échoué. Cette constatation est renforcée par le refus du gouvernement américain de renoncer à ses pouvoirs historiques sur la racine.

Il n'est dès lors pas déraisonnable de s'interroger sur l'évolution des pouvoirs du GAC : pave-t-elle la voie vers une mutation de l'ICANN en une organisation intergouvernementale classique ? Cette transformation permettrait de conférer à l'ICANN une légitimité démocratique (1.). Plusieurs options sont envisageables quant à la forme que devrait revêtir cette prise de contrôle gouvernementale (2.). Certains éléments, tenant à la nature de la mission de l'ICANN et aux pouvoirs du Département américain du Commerce sur le DNS, constituent cependant de sérieux obstacles à cette évolution (3.).

1. Le problème de légitimité de l'ICANN

Le principal argument en faveur de la transformation de l'ICANN en organisation intergouvernementale tient à son manque de légitimité démocratique. Il ne fait plus de doute aujourd'hui que l'ICANN n'est pas qu'une organisation de coordination purement technique. La société californienne, au cours de ses treize années d'existence, a été plus d'une fois amenée à prendre des décisions à connotation politique pour accomplir sa mission : on pense notamment à sa décision de libéraliser l'enregistrement des gTLD, aux préoccupations liées à la signification de ces nouveaux gTLD, à sa politique en matière de respect de la propriété intellectuelle, l'UDRP, et aux conflits en matière de délégation et re-délégation de ccTLD. Selon H. Klein et M. Mueller, les activités de régulation et de supervision de l'ICANN constituent une « politique publique globale », une tâche qui relève habituellement d'entités gouvernementales ou intergouvernementales103. Cette situation est critiquée car la représentation démocratique, la séparation des pouvoirs et la garantie des droits fondamentaux font défaut dans l'organisation actuelle de l'ICANN. Une expérience avait été menée en 2000 pour faire élire directement cinq administrateurs par la communauté des internautes au moyen d'un scrutin tenu en ligne : l'idée fut abandonnée au vu des faibles taux de participation104. En ce qui concerne la séparation des pouvoirs, R. Rijgersberg estime que l'ICANN cumule pouvoirs législatif et exécutif, en ce que les règles qu'elle produit sont appliquées par des registres qu'elle choisit elle-même et qui n'ont aucune latitude pour s'écarter de ces règles105. Des inquiétudes sont aussi exprimées autour de la protection de certains droits fondamentaux, comme la liberté d'expression, que l'ICANN restreint indirectement en limitant l'usage des noms de domaine correspondant à des marques déposées, et le respect de la vie privée, notamment en ce qui concerne le service WHOIS.

Dans la configuration actuelle de l'ICANN, deux processus parallèles d'élaboration des politiques se sont mis en place : le premier au sein des organisations de soutien, le second au sein du GAC. Ces processus sont totalement indépendants : les réunions du GAC ne sont pas ouvertes aux représentants de la GNSO et la ccNSO, au sein desquelles le GAC ne dispose que d'agents de liaison sans droit de vote. M. Mueller estime que ce système emporte le « pire des deux mondes »106. D'une part, les gouvernements, qui n'ont qu'un rôle consultatif auprès d'une société privée, sont libérés des contraintes habituellement applicables en cas de négociation de traités internationaux. L'avis du GAC n'est en effet pas soumis à la ratification des parlements nationaux et il n'y aucun moyen de contrôler sa conformité à une constitution nationale. D'autre part, le conseil d'administration n'a pas établi de critères clairs quant à l'attitude à adopter lorsque la proposition émanant des organisations de soutien et l'avis du GAC sont contradictoires : il peut choisir arbitrairement entre l'un ou l'autre, ce qui est un grand facteur d'instabilité selon M. Mueller.

2. Formes de la prise de contrôle gouvernementale

Plusieurs solutions conférant plus de pouvoirs aux gouvernements ont été envisagées pour résoudre les problèmes évoqués ci-dessus.

Une première approche consisterait à accorder aux représentants des gouvernements un statut égal à celui des autres parties prenantes. Le GAC serait supprimé et ses membres intégrés au sein des organisations de soutien. Cette solution permettrait aux gouvernements de négocier directement avec les autres parties prenantes du réseau pour défendre leurs propres intérêts. Actuellement, les membres du GAC doivent s'accorder sur une position consensuelle s'ils veulent que leur avis soit pris en compte par le conseil d'administration. Être investi dès le départ dans le processus de décision permettrait peut-être de voir se dégager de nouvelles coalitions, qui transcenderaient l'opposition entre GAC et organisations de soutien. De cette manière, un véritable mode de gouvernance multi-parties prenantes, avec un processus de décision participatif, pourrait émerger. Les gouvernements pourraient aussi prendre part, au sein des organisations de soutien, à l'élection des administrateurs. Une modification des statuts de l'ICANN pourrait même être envisagée pour permettre à des représentants étatiques de siéger au conseil d'administration. Cela permettrait d'atteindre la meilleure solution, selon P. de La Coste : une « architecture inspirée de l'ONU », comportant un « parlement » représentant tous les états et tous les acteurs internationaux concernés et un « gouvernement » représentant les forces en présence, c'est-à-dire les acteurs majeurs de l'Internet et des représentants élus des autres acteurs107.

Certains états réclament pour leur part la fin de la gouvernance multi-parties prenantes et la mise sur pied d'une organisation exclusivement intergouvernementale, excluant les représentants du secteur privé et de la société civile de la prise de décision. Ce sont en général les états restreignant l'accès à l'Internet à l'intérieur de leurs frontières qui réclament de la manière la plus véhémente cette transformation radicale108. Cette solution est loin de faire l'unanimité. Il s'agirait tout d'abord d'une négation de la nature privée du réseau et des bénéfices tirés de la coopération de ses acteurs, qui a permis d'en assurer la stabilité jusqu'à présent. Soumettre toute décision de l'ICANN à des procédures de négociations internationales, avec ratification au niveau national, risquerait de sérieusement ralentir le développement du réseau et l'innovation. Certains commentateurs américains craignent aussi que le transfert du contrôle du pouvoir sur la structure d'adressage de l'Internet à une organisation internationale ne soit une menace pour la liberté d'expression telle qu'elle est protégée par le Premier Amendement de la Constitution américaine. Il ne serait pas improbable que les états concluent un traité prévoyant le blocage et la suppression d'adresses de sites incitant à la haine ou contenant des propos blasphématoires. Des raisons de sécurité pourraient également mettre à mal le respect de la vie privée sur le réseau.

Le système de co-régulation proposé par l'Union européenne au cours du SMSI pourrait également être réexaminé. L'Union proposait un modèle de coopération internationale dans lequel gouvernements, secteur privé, société civile et organisations internationales agiraient de manière complémentaire, chacun dans son domaine de compétence. Une organisation intergouvernementale serait mise en place pour élaborer les politiques d'intérêt général que l'ICANN devrait suivre dans l'accomplissement de sa mission. Un point essentiel de la proposition européenne est le respect par toutes les parties des principes généraux établis lors de la première phase du Sommet à Genève mais aussi de principes spécifiques à l'architecture du réseau, l'interopérabilité, l'ouverture et le principe de bout-à-bout. Le respect du principe de bout-à-bout est particulièrement important : suggérer que le rôle du réseau se limite à transporter les paquets d'informations implique qu'il n'est pas supposé filtrer ces informations sur base de leur contenu, ni les authentifier, ni suivre leur trace ou les modifier109. V. Mayer-Schönberger et M. Ziewitz estiment que cette proposition aurait pu mener à un « moment constitutionnel » car elle ne se limite pas à recommander la délégation du pouvoir à une organisation internationale, elle prévoit aussi des principes et des règles auxquelles les gouvernements devront se soumettre dans l'exercice de ce pouvoir110. Les auteurs déplorent dès lors l'échec du SMSI et le maintien du statu quo. Ils affirment que le rejet de la proposition européenne par les états-Unis est une erreur à deux points de vue. D'un point de vue tactique, une alliance entre les états-Unis et l'Union européenne aurait permis de rassembler les états modérés et de marginaliser les propositions les plus radicales émises par des régimes autoritaires pratiquant la censure de l'Internet. D'un point de vue plus substantiel, il s'agissait d'une opportunité sans précédent d'établir des mécanismes de limitation des pouvoirs des états, tenus au respect des principes fondamentaux aux yeux de la communauté Internet. Les auteurs concluent que le SMSI ne constitue qu'une victoire à la Pyrrhus pour les états-Unis111. Notons que tout n'est peut-être pas perdu car la Commission européenne a rappelé en 2009 les principes-clés que l'Union défend en matière de gouvernance de l'Internet et ceux-ci sont un rappel de sa proposition présentée au SMSI112.

3. Obstacles

Conférer un rôle aux gouvernements en matière de « politique d'intérêt général » nécessite que l'on distingue ces questions de la gestion technique quotidienne du DNS dévolue à l'ICANN. Or, des critères clairs pour tracer cette frontière font défaut. Des conflits de compétences pourraient facilement émerger entre les gouvernements et l'ICANN, et le bon fonctionnement du réseau, lié à celui de l'ICANN, pourrait sérieusement en pâtir. Il conviendrait donc, avant tout transfert de compétences à une organisation intergouvernementale, de traiter ce problème en délimitant clairement les limites de sa mission.

L'obstacle le plus important à la mise sur pied d'un modèle gouvernemental efficace est sans aucun doute le droit de veto du gouvernement américain sur toute modification du fichier-zone racine. Celui-ci est prévu par l'accord de coopération avec Verisign, auquel l'ICANN n'est pas partie. Le transfert de compétences ou même la mutation de l'ICANN en organisation intergouvernementale n'emporterait en soi aucune révision de cet accord. Le gouverne-ment américain pourrait donc toujours s'opposer, avec succès, à des décisions prises par les gouvernements réunis au sein de l'ICANN et nécessitant une édition du fichier-zone racine. Ce droit de veto au bénéfice des seuls états-Unis est évidemment inacceptable. L'obligation de Verisign d'attendre les instructions du DoC avant de procéder à cette édition ne prendra toutefois fin que si le gouvernement américain y consent. Au vu de sa déclaration en 2005, celui-ci semble peu enclin à modifier cette situation et à partager son pouvoir sur la racine. Cela va bien sûr à l'encontre de la volonté qu'il avait affichée dans le Livre blanc de privatiser et d'internationaliser la gestion du DNS. Il faut toutefois remarquer un précédent dans lequel le gouvernement américain s'est abstenu d'utiliser ce droit de veto alors qu'il était opposé à l'ajout d'un nouveau gTLD approuvé par l'ICANN, le « .  ». Comme M. Mueller l'a remarqué, le gouvernement américain s'est servi du GAC pour couvrir et légitimer son intervention dans cette affaire. Au lieu d'agir unilatéralement à découvert, l'administration Bush a utilisé la composante « internationale » de l'ICANN pour exercer son influence. De manière un peu surprenante, elle a ainsi encouragé une plus grande participation du GAC dans le processus de prise de décision113.

Toute évolution dans la gestion du DNS reposera donc en grande partie sur le bon vouloir des états-Unis. L'intransigeance américaine n'est d'ailleurs pas sans risques : le statu quo comporte aussi un danger pour la stabilité du réseau. En effet, les états mécontents pourraient décider de créer leur propre système de nommage et d'adressage pour échapper à la supervision américaine. Le risque est grand que des systèmes parallèles ne soient pas parfaitement interopérables. L'existence de plusieurs racines ne permettrait plus d'assurer l'unicité des noms de domaine : un même nom de domaine pourrait mener à des adresses différentes selon le système auquel le serveur de noms de domaine appartient. Personne, et sûrement pas les états-Unis, ne sortirait gagnant d'une telle fragmentation.

B. La nationalisation des ccTLD

La nationalisation des ccTLD, une idée envisagée notamment par K. Cukier114, K. von Arx et G. Hagen115, apparaît comme la solution la plus praticable pour mettre un terme à une série de controverses qui agitent les acteurs du DNS. Tant le gouvernement américain que les participants réunis au Sommet mondial sur la société de l'information ont admis que les ccTLD constituaient avant tout un enjeu national et que d'autres états ne devraient pas intervenir dans leur gestion. La compétence de l'ICANN en matière de délégation et de re-délégation de ccTLD ainsi que la supervision du gouvernement américain créent depuis longtemps la polémique. La solution présentée ci-après, conférant, dans un premier temps, l'administration des ccTLD aux états sur le plan national (1.) pourrait mener, dans un deuxième temps, à deux attitudes différentes de ceux-ci sur le plan international (2.).

1. Sur le plan national

Dans un premier temps, l'état devrait se voir confier l'administration de son ccTLD. La manière la plus simple de procéder à une « nationalisation » des ccTLD consisterait à enclencher au niveau de l'ICANN un processus généralisé de re-délégation des ccTLD à des organismes publics. Des procédures analogues à l'expropriation pour cause d'utilité publique pourraient également être envisagées au niveau national. Ces décisions pourraient être justifiées par l'assimilation de l'administration d'un registre de ccTLD à un service public. Ce monopole de l'état sur le registre ne s'étendrait pas aux bureaux d'enregistrement, qui pourraient toujours être des acteurs privés agissant en concurrence et à qui l'état imposerait le respect des règles qu'il édicte en tant que registre.

La re-délégation du ccTLD de l'Afrique du Sud, « .za », est un précédent intéressant qui montre que l'ICANN ne s'opposerait pas à la nationalisation d'un ccTLD si l'état reconnaît l'autorité de l'ICANN116. En 2002, le parlement sud-africain a promulgué une loi (Electronic Communications and Transactions Act) qui prévoyait entre autres la désignation d'une nouvelle entité chargée de l'administration du « .za », sous la supervision du gouvernement. Ce changement s'est produit en dehors des procédures habituelles suivies par l'ICANN, qui n'a rien trouvé à redire à ce procédé et a approuvé a posteriori la re-délégation, en faisant notamment référence aux principes développés par le GAC117.

2. Sur le plan international

Les gouvernements, après avoir été investis des pouvoirs sur leur ccTLD, seraient face à une alternative sur le plan international : soit prendre part aux processus de décision de l'ICANN, au sein de la ccNSO, soit demander à l'ICANN le transfert de ses pouvoirs en matière de gestion des ccTLD à une nouvelle organisation intergouvernementale, destinée à développer des règles communes en matière d'extensions nationales. Dans les deux cas, les compétences de l'ICANN concernant la coordination du DNS et la gestion des gTLD resteraient inchangées.

La première branche de l'alternative n'apporterait pas de modification fondamentale à la structure de l'ICANN. Les gouvernements participeraient à l'élaboration des décisions au sein de la ccNSO, aux côtés des autres parties prenantes. Les projets seraient ensuite soumis au CA pour qu'il prenne la décision finale. Le seul changement à apporter aux procédures actuelles serait la suppression de l'avis du GAC en matière de ccTLD, étant donné que les gouvernements auraient déjà pu faire entendre leur voix au sein de la ccNSO. Selon K. Cukier, ce serait une façon élégante d'impliquer les gouvernements dans le fonctionnement formel de l'ICANN, plutôt que de tenter de renforcer le GAC118. Le GAC ne serait pas pour autant supprimé, son avis se justifiant encore pour les politiques ne concernant pas les ccTLD et son intervention restant nécessaire dans les mécanismes de révision.

Il est probable que les gouvernements optent plutôt pour la deuxième branche de l'alternative et choisissent de se dégager des mécanismes de l'ICANN pour gérer leurs ccTLD dans le cadre d'une organisation intergouvernementale traditionnelle. Les gouvernements pourraient requérir de l'ICANN qu'elle leur cède ses compétences en matière de ccTLD. Ce transfert de compétences devrait être subordonné à la promesse des gouvernements de respecter les principes fondamentaux de l'architecture de l'Internet et de ne pas mettre la stabilité du réseau en péril. L'ICANN devrait aussi obtenir l'engagement des gouvernements de ne pas mettre en place de racine parallèle pour les ccTLD et d'accepter qu'elle continue à exercer son rôle de coordinateur technique du réseau. Les gouvernements pourraient mettre ensuite en place des négociations multilatérales pour créer un cadre de régulation au sein duquel les nations reconnaissent mutuellement les domaines des autres nations119. L'étape suivante consisterait en l'élaboration d'un traité international établissant les règles en matière de délégation et de re-délégation de ccTLD, pour déterminer notamment quels territoires ont vocation à se voir attribuer une extension. Cette configuration permettrait de dégager l'ICANN de considérations éminemment politiques. Les gouvernements pourraient également s'accorder sur un traité prévoyant le respect de certains principes de base dans la gestion des ccTLD, conformément aux promesses faites à l'ICANN.

La gestion des ccTLD dans un cadre intergouvernemental procurerait également une forme d'internationalisation de la racine qui serait compatible avec les intérêts souverains des états-Unis ainsi que des autres pays. K. von Arx et G. Hagen ont exposé que ce changement de contrôle pourrait intervenir avec ou sans la coopération du gouvernement américain. Avec son accord, l'opération serait analogue à une partition, les états-Unis et les autres états s'accordant sur la modification de la structure hiérarchique du DNS pour permettre le contrôle national sur les ccTLD. Dans le scénario contraire, les états pourraient déclarer leur indépendance vis-à-vis des états-Unis, en refusant de reconnaître l'autorité du serveur racine A. Ils devraient dès lors créer un système de nommage et d'adressage alternatif, reconnaissant le contrôle national sur les ccTLD et libéré de la hiérarchie inhérente au DNS120. Ce cas de figure mènerait à une fracture totale du réseau, entre domaines génériques et domaines nationaux. Les états-Unis auraient donc plutôt intérêt à négocier avec les autres gouvernements. Chacun pourrait y trouver son compte : les états-Unis qui voient s'éloigner le spectre de la fragmentation du réseau et les autres gouvernements qui obtiennent enfin une diminution du contrôle américain sur leur ccTLD. Les états-Unis devraient par exemple s'engager à ne pas utiliser leur droit de veto quand Verisign est chargée d'éditer les informations concernant un ccTLD dans le fichier-zone racine. Selon S. Sonbuchner, si les états parviennent à assembler une organisation de gouvernance de l'Internet stable et fonctionnelle, les états-Unis pourraient même être enclins à reconnaître qu'une approche plus internationale de l'administration de la racine est possible et qu'un partage des pouvoirs ne menacerait pas la stabilité du réseau121.

Affirmer leur souveraineté sur leur ccTLD tant au niveau national qu'international conférerait ainsi un réel pouvoir de réglementation aux états sur leur extension nationale. Ce pouvoir devrait s'exercer dans le respect des principes fondamentaux du réseau et du rôle de coordinateur technique de l'ICANN, qui serait toujours en charge de la gestion des gTLD. La gouvernance multi-parties prenantes trouverait ainsi toujours à s'appliquer dans cette matière, pour laquelle le rôle des gouvernements réunis au sein du GAC resterait consultatif. Cette configuration permettrait aussi de mettre fin aux aspects les plus critiqués de l'hégémonie américaine.

CONCLUSION

Au vu de tout ce qui a été développé ci-dessus, nous pouvons conclure que le DNS n'est plus à l'abri de l'intervention étatique et pourrait servir de point de départ à une conquête générale de l'Internet par l'état.

La nationalisation des ccTLD pourrait conférer aux états un pouvoir de réglementation sur le DNS, non seulement au niveau national mais aussi sur la scène internationale. Les gouvernements pourraient requérir de l'ICANN le transfert des pouvoirs en matière de ccTLD vers une organisation intergouvernementale. En échange, les états s'engageraient à ne pas créer de systèmes parallèles, à accepter que l'ICANN conserve son rôle de coordination technique de l'ensemble du DNS et à respecter les principes fondamentaux de l'architecture du réseau. L'ICANN devrait elle s'engager à respecter les décisions prises par les états dans ce cadre tandis que le gouvernement américain devrait promettre de ne plus intervenir auprès de Verisign lorsqu'une édition du fichier-zone racine a été décidée par cette nouvelle organisation intergouvernementale. Cette configuration permettrait de satisfaire toutes les parties et pas seulement les états : la communauté Internet verrait en effet s'éloigner le risque de fragmentation du réseau agité par les états hostiles à l'hégémonie américaine. Cela permettrait aussi d'apporter une solution aux problèmes de légitimité de l'ICANN, en la déchargeant des questions politiques relatives aux ccTLD.

La transformation de l'ICANN elle-même en organisation exclusivement intergouvernementale est peu probable : le gouvernement américain et les parties prenantes non gouvernementales y sont farouchement opposés. Un modèle de co-régulation, tel que celui proposé par l'Union européenne, n'est toutefois pas à écarter si l'idée d'une organisation internationale en charge des ccTLD n'aboutit pas. L'ICANN pourrait ainsi servir de laboratoire à de nouvelles formes de gouvernance dans un monde globalisé, dans lesquelles les états participent à des réseaux coopératifs et arrangements consensuels avec d'autres acteurs du monde global. Cet exemple pourrait être repris dans d'autres domaines. En effet, si on laisse les controverses de côté, force est de constater, sur les plans juridique et organisationnel, que l'ICANN est une expérience fascinante de création d'une organisation internationale en dehors du cadre d'un traité et non limitée aux états. Une grande partie de l'histoire de la gouvernance du DNS est ainsi caractérisée par la volonté de conserver des éléments des arrangements informels originaux dans les nouvelles structures, plus formelles, rendues nécessaires pour des raisons sociales, économiques et juridiques.

En guise de conclusion, soulignons que ces discussions sur l'organisation de l'Internet qui, de prime abord, pourraient s'apparenter à des débats techniques quelque peu hermétiques aux yeux des juristes, sont primordiales au vu de l'évolution de notre société. L'Internet a largement dépassé le cadre de la recherche scientifique pour concerner la société dans son ensemble. Une partie de la vie publique se déroule désormais via la toile. Être en mesure de contrôler et de modifier son architecture n'est pas un pouvoir anodin. Contrôler le registre d'un TLD permet en effet de décider quels sites Internet seront accessibles aux internautes et permet également de connaître les coordonnées du titulaire du nom de domaine. La liberté d'expression et la protection de la vie privée sur la toile pourraient donc potentiellement être mises à mal si des états autoritaires parvenaient à obtenir le contrôle sans limitation de leur ccTLD, voire de l'ICANN. La résolution des questions liées à l'architecture et à la gestion des ressources sur le réseau est donc un préalable obligé à toute réglementation globale du réseau portant sur la régulation des contenus ou sur le respect de la propriété intellectuelle.

1. Master en droit public. Université libre de Bruxelles. Promotion 2011.

2. 2 Une Request for Comments invite la communauté Internet, via des listes de diffusion, à commenter des projets de décision rédigés par des experts techniques (notamment au sein de l'IETF, l'Internet Engineering Task Force). Ceux-ci tiennent ensuite compte des commentaires reçus lors de la prise de décision finale.

3. US Department of Commerce, NTIA, « Improvement of Technical Management of Internet Names and Addresses », Proposed rule - Request for public comment, Federal Register, vol. 63, no 34, 20 février 1998, pp. 8825-8833.

4. US Department of Commerce, NTIA, « Management of Internet Names and Addresses », Statement of policy, Federal Register, vol. 63, no 111, 10 juin 1998, p. 31741.

5. « Memorandum of Understanding between the U.S. Department of Commerce and Internet Corporation for Assigned Names and Numbers », 25 novembre 1998, http://www.icann.org/en/general/icann-mou-25nov98.htm.

6. F. Dumortier, « À propos du Sommet mondial sur la société de l'information - Les ambiguïtés de la gouvernance de l'Internet », R.D.T.I., 2006, no 25, p. 151.

7. M. Mueller, Networks and States - The Global Politics of Internet Governance, Cambridge (Massachusetts), MIT Press, 2010, p. 63.

8. « Amendement 1 to ICANN/DOC Memorandum of Understanding », 4 novembre 1999, http://www.icann.org/en/nsi/amend1-jpamou-04nov99.htm, § 5.

9. « Contract Between ICANN and the United States Government for Performance of the IANA Function », 9 février 2000, http://www.icann.org/en/general/iana-contract-09feb00.htm.

10. « Contract Between ICANN and the United States Government for Performance of the IANA Function », 14 août 2006, http://www.icann.org/en/general/iana-contract-14aug06.pdf. Le contrat, qui devait initialement expirer le 30 septembre 2011, a été prolongé jusqu'au 31 mars 2012 : « Modification 8 », 14 juin 2011, http://www.ntia.doc.gov/ files/ntia/publications/ianamod0008_07142011.pdf.

11. Ibid., point C.4.1.

12. « Cooperative Agreement Between the Department of Commerce and VeriSign (Network Solutions) », http://www.ntia.doc.gov/legacy/ntiahome/domainname/nsi.htm.

13. Le fichier-zone racine (root zone file) contient l'information relative au sommet de la hiérarchie des bases de données du DNS, c'est-à-dire la liste des adresses des serveurs de noms de domaine de premier niveau (TLD), répartis entre gTLD et ccTLD.

14. « Amendement 11 to the DOC/NSI Cooperative Agreement », 7 octobre 1998, http://www.ntia.doc.gov/legacy/ntiahome/domainname/agreements/Amend11_052206.pdf.

15. M. Mueller, op. cit., 2010, p. 63, note 22.

16. US Department of Commerce, NTIA, « US principles on the Internet's Domain Name and Addressing System », 30 juin 2005, http://www.ntia.doc.gov/ntiahome/domainname/USDNSprinciples_06302005.htm.

17. F. Dumortier, op. cit., p. 152.

18. J. Weinberg, « ICANN and the Problem of Legitimacy », Duke Law Journal, vol. 50, no 1, octobre 2000, p. 197.

19. « Amendement 30 to the DOC/NSI Cooperative Agreement », 29 novembre 2006, http://www.ntia.doc.gov/legacy/ntiahome/domainname/agreements/amend30_11292006.pdf.

20. M. Mueller, op. cit., 2010, p. 63.

21. J. Weinberg, « Governments, Privatization and "Privatization" : ICANN and the GAC » ; Wayne State University Law School Research Paper, no 10-24, 21 février 2011, disponible sur http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1766082##, p. 4.

22. K. Cukier, « Who will control the Internet - Washington Battles the World », Foreign Affairs, novembre-décembre 2005, vol. 84, no 6, p. 13.

23. Y. Poullet, « Tunis et Société de l'information : ouverture ou clôture d'un débat », R.D.T.I., 2006, no 24, pp. 5-9.

24. « Joint Project Agreement between the US Department of Commerce and the Internet Corporation for Assigned Names and Numbers », 29 septembre 2006, http://www.icann.org/en/general/JPA-29sep06.pdf.

25. « Affirmation of Commitments by the United States Department of Commerce and the Internet Corporation for Assigned Names and Numbers », 30 septembre 2009, http://www.icann.org/en/documents/affirmation-of-commitments-30sep09-en.pdf.

26. M. Mueller, op. cit., 2010, p. 249.

27. M. Froomkin, « Almost free : an Analysis of ICANN's "Affirmation of Commitments" », Journal of Telecommunications and High Technology Law, vol. 9, no 1, hiver 2011, p. 199.

28. Le terme WHOIS renvoie à un service de bases de données contenant des informations à propos des noms de domaine enregistrés, notamment les coordonnées de leurs titulaires. Ce service est controversé, notamment pour des raisons de protection des données personnelles.

29. US Department of Commerce, NTIA, op. cit., 10 juin 1998, p. 31744.

30. Ibid., p. 31750.

31. ICANN, « Bylaws », 6 novembre 1998, Article V, section 5, http://www.icann.org/en/general/archivebylaws/bylaws-06nov98.htm.

32. Ibid., article VII, section 3, a).

33. Ibid., article VII, section 3, a).

34. GAC, « Operating Principles », 25 mai 1999, http:// www.icann.org/en/committees/gac/operating-principles-25may99.htm.

35. GAC, « Operating Principles », version amendée en 2010 à la réunion de Nairobi, https://gacweb.icann. org/download/attachments/1540127/GAC_Operating_Principles_1.pdf.

36. S. Lynn, « President's Report : ICANN - The Case for Reform », 24 février 2002, http://www.icann.org/en/ general/lynn-reform-proposal-24feb02.htm.

37. Committee on ICANN Evolution and Reform, « ICANN : A Blueprint for Reform », 20 juin 2002, http://www.icann.org/en/committees/evol-reform/blueprint20jun02.htm.

38. ICANN, « Bylaws », 15 décembre 2002, http://www. icann.org/en/general/archive-bylaws/bylaws-15dec 02.htm.

39. Ibid., article XI, section 2, point f.

40. Ibid., article XI, section 2, points h à k.

41. Pour un compte rendu détaillé du cas « .  » : Berkman Center for Internet and Society, « Accountability and Transparency at ICANN : An Independant Review », 20 octobre 2010, http://www.icann.org/ en/reviews/affirmation/atrt-review-berkman-finalreport-20oct10-en.pdf, pp. 90-124.

42. ICANN, « Special Meeting of the Board - Minutes », 1er juin 2005, http://www.icann.org/en/minutes/ minutes-01jun05.htm.

43. ICANN, « Special Meeting of the Board - Minutes », 10 mai 2006, http://www.icann.org/en/minutes/ minutes-10may06.htm.

44. ICANN, « Bylaws », 24 juin 2011, op. cit., article IV, section 3.

45. International Centre For Dispute Resolution, « ICM Registry v. ICANN - Declaration of the Independent Review Panel », réf. 50 117 T 00224 08, 19 février 2010, http://www.icann.org/en/irp/icm-v-icann/irp-paneldeclaration-19feb10-en.pdf, p. 70.

46. ICANN, « Adopted Board Resolutions », 25 juin 2010, http://www.icann.org/en/minutes/resolutions-25jun 10-en.htm, § 5.

47. ICANN, « Adopted Board Resolutions », 18 mars 2011, http://www.icann.org/en/minutes/resolutions-18mar 11-en.htm#5, § 5.

48. J. Weinberg, op. cit., 2011, p. 11.

49. ICANN, « Guide de candidature gTLD », 30 mai 2011, http://www.icann.org/fr/topics/new-gtlds/rfp-clean30may11-fr.pdf.

50. GAC, « GAC Principles Regarding New gTLDs », 28 mars 2007, https://gacweb.icann.org/download/attachments/1540128/gTLD_principles_0.pdf.

51. M. Mueller, op. cit., 2010, pp. 201-204.

52. Conseil de l'Europe, « Déclaration du Comité des ministres sur la protection de la liberté d'expression et d'information et de la liberté de réunion et d'association en ce qui concerne les noms de domaine d'internet et les chaînes de noms », 21 septembre 2011.

53. M. Froomkin, op. cit., 2011, p. 202.

54. M. Mueller, op. cit., 2010, p. 243.

55. M. Froomkin, «When we say USTM, we mean it!», Houston Law Review, vol. 41, no 3, 2004, pp. 865-866.

56. J. Weinberg, op. cit., 2011, pp. 13-14.

57. M. Mueller, op. cit., 2010, p. 244.

58. J. Weinberg, op. cit., 2011, pp. 17-18.

59. ATRT, « Final Recommendations », 31 décembre 2010, http://www.icann.org/en/reviews/affirmation/ atrt-final-recommendations-31dec10-en.pdf, spéc. pp. 29-39.

60. ATRT, « Board Action on, and Implementation of, the ATRT Final Report », juin 2011, http://www.icann.org/ en/accountability/atrt-report-25jun11-en.pdf, spéc. pp. 39-56.

61. J. Weinberg, op. cit., 2011, p. 18.

62. J. Postel et J. reyNolDS, « Domain Requirements », RFC 920, octobre 1984, p. 1, http://www.rfc-editor.org/rfc/rfc920.txt

63. J. Postel, cité par M. Mueller, Ruling the Root - Internet Governance and the Taming of Cyberspace, Cambridge (Massachussetts), MIT Press, 2002, p. 89.

64. P.K. Yu, «The origins of ccTLD policymaking », Cardozo Journal of International and Comparative Law, vol. 12, automne 2004, p. 391.

65. J. Postel, « Domain Name Structure and Delegation », RFC 1591, mars 1994, http://www.ietf.org/rfc/rfc1591.txt?number=1591.

66. IANA, « ccTLD News Memo #1 », 23 octobre 1997, § 2, http://www.iana.org/reports/1997/cctld-newsoct1997.html.

67. US Department of Commerce, NTIA, op. cit., 10 juin 1998, p. 31744.

68. ICANN, « ICP-1 : Internet Domain Name System Structure and Delegation (ccTLD Administration and Delegation) », mai 1999, http://www.icann.org/en/icp/ icp-1.htm.

69. GAC, « Operating Principles », 25 mai 1999, op. cit., considérant 4.

70. GAC, « Principles and guidelines for the delegation and administration of country code top level domains », 23 février 2000, http://www.icann.org/en/ committees/gac/gac-cctldprinciples-23feb00.htm.

71. GAC, « Principles and guidelines for the delegation and administration of country code top level domains », 5 avril 2005, https://gacweb.icann.org/ download/attachments/1540115/ccTLD_Principles_0. pdf.

72. Consultable à l'adresse suivante : http://unstats. un.org/unsd/methods/m49/m49alpha.htm.

73. J. Klensin, J., « Reflections on the DNS, RFC 1591, and Categories of Domains », RFC 3071, février 2001, p. 6, http://www.ietf.org/rfc/rfc3071.txt.

74. F. Dumortier, F., op. cit., pp. 156-158.

75. IANA, « IANA Report on Request for Delegation of the. ps Top-Level Domain », 22 mars 2000, http://www. icann.org/general/ps-report-22mar00.htm.

76. Commission européenne, « Communication de la Commission au Parlement européen et au Conseil - Système de noms de domaines Internet - Création du nom de domaine de premier niveau.EU », COM (2000) 421final, p. 4, http://eur-lex.europa.eu/LexUriServ/ LexUriServ.do?uri=COM:2000:0421:FIN:FR:PDF.

77. ICANN, « Special Meeting of the Board Minutes », 25 septembre 2000, http://www.icann.org/en/ minutes/minutes-25sep00.htm.

78. ICANN, « ICP-1 : Internet Domain Name System Structure and Delegation (ccTLD Administration and Delegation) », op. cit., (e) et (f ).

79. GAC, « Principles and guidelines for the delegation and administration of country code top level domains », 5 avril 2005, op. cit., § 7.1.

80. ICANN, « Redelegation of.us Country-Code Top-Level Domain », 19 novembre 2001, http://www.icann.org/ en/announcements/announcement-19nov01.htm.

81. S. Sonbuchner, « Master of Your Domain : Should the U.S. Government Maintain Control over the Internet's Root ? », Minnesota Journal of International Law, vol. 17, no 1, hiver 2008, p. 203.

82. M. Froomkin, op. cit., 2011, p. 205.

83. M. Mueller, op. cit., 2002, p. 205.

84. GAC, « Principles and guidelines for the delegation and administration of country code top level domains », 23 février 2000, op. cit., §§ 5.1 et 5.2.

85. M. Mueller, op. cit., 2002, p. 244. 86 P.K. yu, op. cit., p. 403.

87. Organisation de Coopération et de Développement économiques, « évolution de la gestion des noms de domaine de premier niveau de code de pays », rapport DSTI/ICCP/TISP(2006)6/FINAL, 30 janvier 2007, http://www.oecd.org/officialdocuments/publi cdisplaydocumentpdf/?cote=DSTI/ICCP/TISP(2006)6/ FINAL&docLanguage=Fr.

88. M. Geist, « Governments And Country-Code Top Level Domains : A Global Survey », février 2004, http:// www.michaelgeist.ca/resc/Governments%20And%20Country-Code%20Top%20Level%20Domains%20 (V.2).pdf, p. 4.

89. J. bing, et L. bygrave, Internet Governance - Infrastructures and Institutions, Oxford University Press, Oxford, 2009., p. 158.

90. G. Christou et S. Simpson, « New Governance, the Internet, and Country Code Top-Level Domains in Europe », Governance : An International Journal of Policy, Administration, and Institutions, vol. 22, no 4, octobre 2009, pp. 610-617.

91. Pour un exposé détaillé de ce modèle, voy. : http:// www.norid.no/regelverk/rammer/forvaltningsmodell. en.html.

92. J. Bing et L. Bygrave, op. cit., p. 203.

93. Pour plus de détails, voy. : http://www.nominet.org. uk/policy/process.

94. Loi du 26 juin 2003 relative à l'enregistrement abusif des noms de domaine, M.B., 9 septembre 2003, p. 45225.

95. Voy. le § 10 des « Conditions d'enregistrement des noms de domaine sous le domaine ‘‘.be'' opéré par DNS.be », version 5.0, 14 mai 2011, http://www.dns. be/library/documents/312_enduser_terms_and_ conditions_fr_v50.pdf et le règlement spécifique du CEPANI, http://www.cepani.be/upload/files/nom dedommaine-reglement-2011.pdf.

96. A. Cruquenaire, « La loi du 26 juin 2003 relative à l'enregistrement abusif des noms de domaine : et la montagne accoucha d'une souris... », J.T., 2004, p. 546.

97. Projet de loi relatif à l'enregistrement abusif des noms de domaine, Rapport fait au nom de la Commission de l'économie, de la politique scientifique, de l'éducation, des institutions scientifiques et culturelles nationales, des classes moyennes et de l'agriculture par M. Dehu, Doc. parl., Ch. repr., sess. ord. 2002-2003, no 1069/005, p. 7.

98. Projet de loi relative à l'enregistrement abusif des noms de domaine, Rapport fait au nom de la Commission des finances et des affaires économique par M. de Clippele, Doc. parl., Sénat, sess. ord. 2002-2003, no 1519/2, p. 5.

99. A. Cruquenaire, op. cit., 2004, pp. 551-552.

100. Rijgersberg, The State of Interdependence - Globalization, Internet and Constitutional Governance, La Haye, T.M.C. Asser Press, 2010, p. 95.

101. J. Mifsud Bonnici, Self-Regulation in Cyberspace, La Haye, T.M.C. Asser Press, p. 109.

102. Anvers (1re ch.), 26 septembre 2011, inédit.

103. H. Klein et m. Mueller, «What to Do about ICANN : A Proposal for Structural Reform », Concept Paper by the Internet Governance Project, 5 avril 2005, http:// www.internetgovernance.org/pdf/igp-icannreform. pdf, p. 2.

104. J. Paifrey, «The End of the Experiment: How ICANN's Foray into Global Internet Democracy Failed », Harvard Journal of Law & Technology, vol. 17, no 2, printemps 2004, pp. 446-450.

105. Rijgersberg, op. cit., 2010, pp. 80-81.

106. M. Mueller, op. cit., 2010, p. 243.

107. P. De la Coste, « La gouvernance internationale de l'Internet », Politique étrangère, vol. 71, no 3, automne 2006, p. 517.

108. K. Cukier, op. cit., 2005, p. 12.

109. V. Mayer-Schönberger et m. Ziewitz, « Jefferson Rebuffed - The United States and the Future of Internet Governance », The Columbia Science and Technology Law Review, vol. VIII, 30 avril 2007, p. 202.

111. Ibid., p. 228.

112. Commission européenne, « Communication de la Commission au Parlement européen et au Conseil - La gouvernance de l'Internet : les prochaines étapes », COM(2009)277, 18 juin 2009, § 7.

110. Ibid., pp. 204-205.

113. M. Mueller, op. cit., 2010, p. 73.

114. K. Cukier, « Eminent Domain : Initial Policy Perspectives on Nationalizing Country-Code Internet Addresses », juin 2002, http://www.cukier.com/inet02.html.

115. K. von Arx et G. Hagen, « Sovereign Domains - A Declaration of Independence of ccTLDs from Foreign Control », The Richmond Journal of Law and Technology, vol. IX, no 1, automne 2002, pp. 1-46.

116. Y.J. Park, «The National ccTLD Disputes : Between States Actors and Non-State Actors », International Journal of Communications Law & Policy, no 13, hiver 2009, p. 193.

117. IANA, « Report on the Redelegation of the.za TopLevel Domain », novembre 2004, http://www.iana.org/ reports/2005/za-report-05aug05.pdf.

118. K. Cukier, op. cit., 2002.

119. K. von Arx et G. Hagen, op. cit., p. 32.

120. Ibid., pp. 32-33.

121. S. Sonbuchner, op. cit., p. 205.

Fermer la fenêtre