Résumé

  • Dans sa lettre du 11 mai, le GAC a demandé un calendrier pour un objectif qu’il formule comme la collecte et la mise à disposition publique des données des personnes morales.
  • Le 24 août, la présidente du Conseil d’ICANN a distingué cet objectif du mandat adopté : un ou plusieurs champs techniques et des bonnes pratiques, sans nouvelle obligation contractuelle pour les registres et bureaux d’enregistrement.

Le mot « mise en œuvre » paraît précis jusqu’au moment où deux institutions l’emploient pour désigner deux résultats différents.

Le 11 mai 2026, le président du Governmental Advisory Committee, Nicolas Caballero, a écrit à la présidente du Conseil d’administration d’ICANN, Tripti Sinha. Le GAC estimait que les travaux permettant la collecte et la publication des données d’enregistrement des personnes morales n’avaient pas progressé depuis l’adoption des recommandations EPDP phase 2A en mars 2022. Il rappelait sa position : les parties contractantes devraient collecter et rendre publiques les données des personnes morales. Il sollicitait un calendrier et se disait prêt à rejoindre une Implementation Review Team.

La réponse datée du 24 août et publiée le lendemain fournit un repère : sous réserve de l’achèvement de projets mobilisant les mêmes ressources, ICANN org prévoit de pouvoir commencer la mise en œuvre pendant FY2027. Ce n’est ni une date d’achèvement ni une garantie.

La réponse corrige surtout une ambiguïté de fond. L’équipe de la phase 2A n’a pas modifié les exigences de Consensus Policy relatives à la distinction entre personnes morales et personnes physiques. La Registration Data Policy autorise les registres et bureaux d’enregistrement à tenir compte de la nature juridique du titulaire ou de la présence de données personnelles lorsqu’ils décident d’appliquer les règles de masquage dans le RDDS ; elle ne les y oblige pas. Les bonnes pratiques à venir ne créeront pas d’obligations contractuelles.

Le retard allégué et l’écart de mandat sont donc deux questions séparées. On peut mesurer l’avancement d’un programme contre ce qui a été adopté. On ne peut pas attendre de ce programme qu’il produise, par glissement de vocabulaire, une obligation que le texte adopté ne contient pas.

Les verbes de 2022 fixent la portée

Le Conseil d’ICANN a adopté quatre recommandations le 10 mars 2022. La première exige la création d’un ou plusieurs champs facilitant la distinction entre données de personnes morales et physiques, et/ou entre données personnelles et non personnelles. Le champ peut être utilisé par les parties contractantes qui choisissent de différencier.

La deuxième recommandation invite celles qui font ce choix à suivre les orientations du rapport. La troisième prévoit de prendre ces orientations en considération si un code de conduite GDPR est développé au sein d’ICANN par les responsables et sous-traitants concernés. La quatrième demande aux parties qui choisissent de publier une adresse électronique fondée sur le titulaire ou l’enregistrement d’évaluer l’avis juridique recueilli par l’équipe EPDP.

Il existe donc bien une décision contraignante pour ICANN org : le Conseil a ordonné au président-directeur général, ou à ses délégués, d’élaborer et d’exécuter un plan de mise en œuvre conforme aux orientations du GNSO Council. La création du mécanisme technique n’est pas facultative pour l’organisation simplement parce que son utilisation reste facultative pour les parties contractantes.

Mais cette obligation institutionnelle ne se transmet pas automatiquement aux acteurs contractuels. Dans sa motivation de 2022, le Conseil précisait que les recommandations ne leur imposaient aucune obligation nouvelle. Il rappelait aussi que des bonnes pratiques situées hors du Registry Agreement, du Registrar Accreditation Agreement et des Consensus Policies ne fournissent pas à ICANN Contractual Compliance un fondement contractuel d’exécution.

La lettre du 24 août répartit le travail de la même manière. Les recommandations 1, 2 et 4 alimentent un document de bonnes pratiques. Les recommandations 1 et 3 demandent également des actions à ICANN org. La recommandation 1 figure dans les deux ensembles parce qu’elle possède un volet de conseil et un volet technique. Cette double présence ne transforme pas le conseil en règle contractuelle.

Publier n’est pas seulement classer

La Registration Data Policy organise déjà plusieurs opérations : collecte, transfert vers le registre, dépôt sous séquestre, publication, masquage, consentement et divulgation sur demande légitime. Les confondre ferait perdre le lieu exact où une décision doit être justifiée.

La section 9.2.1 impose les règles de masquage lorsqu’elles sont nécessaires au respect du droit applicable. Elle permet aussi leur application dans certaines autres situations. Pour déterminer s’il convient de les appliquer, un registre ou un bureau d’enregistrement peut considérer que les données concernent une personne morale ou contiennent des données personnelles. Le texte ajoute qu’il n’y est pas tenu.

Cette prudence n’est pas un détail sémantique. Une inscription au nom d’une société peut contenir le nom, l’adresse, le téléphone ou l’adresse électronique d’une personne identifiable. Le statut de personne morale n’efface donc pas, à lui seul, la présence éventuelle de données personnelles.

Le champ Registrant Organization montre la logique actuelle. Le bureau d’enregistrement doit permettre au titulaire de le renseigner et doit recueillir la valeur si elle est fournie. Il doit expliquer que cette valeur sera publiée avec l’accord du titulaire et que l’organisation sera alors considérée comme titulaire du nom enregistré. En cas d’accord, la valeur doit être publiée ; sans accord, elle peut être masquée dans les conditions prévues par la politique.

Ce mécanisme ne répond pas à toutes les situations. Il établit néanmoins qu’une étiquette « personne morale » ne suffit pas pour connaître le sort de chaque donnée. Il faut encore savoir quelle valeur est concernée, si elle renvoie à une personne identifiable, quelle règle s’applique, si le consentement intervient et quelle partie assume la décision.

Le champ transporte une qualification, pas son autorité

ICANN prévoit une coordination avec la communauté technique sur l’ajout de champs de différenciation dans EPP, puis une mise à jour du profil RDAP des gTLD. Cette étape a une utilité tangible. Sans vocabulaire commun, un fournisseur peut enregistrer une chaîne libre, un autre un booléen sans documentation et un troisième une inférence impossible à corriger. Un modèle partagé peut définir les valeurs, l’absence d’information, les changements et la circulation entre systèmes.

Il faut toutefois protéger la modestie de cette couche. La syntaxe d’un champ ne décide pas qui doit le remplir. Une valeur ne révèle pas nécessairement la preuve de la qualification. Son passage dans EPP ne commande pas sa présence dans une réponse RDAP. Son apparition dans un profil n’écarte ni la Registration Data Policy, ni le droit applicable, ni la responsabilité du décideur.

La norme rend une distinction interopérable. Elle ne lui confère pas un mandat politique absent.

Une table de concordance avant les lignes de code

Le plan de mise en œuvre gagnerait à être accompagné d’un document court qui relie chaque attente à son instrument. Il devrait comporter au moins cinq lignes.

La première présenterait la position du GAC, sa source, sa qualité consultative et l’objectif de publication qu’il défend. La deuxième citerait mot pour mot les recommandations adoptées et le mandat donné à ICANN org. La troisième renverrait aux clauses contractuelles actuelles sur la collecte, le masquage, le consentement, la publication et la divulgation. La quatrième décrirait le travail EPP/RDAP et son seul effet d’interopérabilité. La cinquième identifierait le décideur responsable au niveau d’un enregistrement réel.

Pour chaque ligne, la concordance devrait indiquer la version du texte, l’acteur responsable, l’état du livrable, la force de la règle et la procédure capable de la modifier. Une demande de rendre la différenciation obligatoire devrait ainsi pointer vers le processus habilité à changer la politique, non vers une tâche de schéma. L’achèvement d’un profil RDAP ne devrait pas être présenté comme l’achèvement de l’objectif plus large du GAC.

Une telle table ne tranche pas le débat entre transparence et protection des données. Elle empêche simplement le mot « mise en œuvre » de faire le travail d’une décision qui n’a pas été prise.

FY2027 ouvre une étape

La formulation du 24 août reste conditionnelle. ICANN org « anticipe pouvoir commencer » en FY2027 après l’achèvement de projets existants utilisant des ressources dédiées. La lettre invite aussi le GAC à participer au cycle de planification FY2028.

Il faudra donc vérifier l’ouverture du chantier, la publication du plan, la constitution d’une équipe de revue, l’apparition de propositions techniques et la disponibilité des bonnes pratiques. Il ne faudra pas déduire d’un début annoncé une date de livraison, ni d’un document livré une adoption généralisée.

Les rôles peuvent rester complémentaires. Le GAC peut défendre un résultat de politique publique. Le GNSO peut délibérer sur une modification de Consensus Policy. Le Conseil peut adopter et ordonner. ICANN org peut mettre en œuvre. Les spécialistes techniques peuvent définir une représentation. Les parties contractantes peuvent appliquer leurs obligations et le droit pertinent à chaque enregistrement.

La confusion commence lorsque la participation devient amendement contractuel, lorsque le schéma devient autorisation de divulguer ou lorsque le suivi de projet devient politique. La lettre d’ICANN vient de tracer la frontière. La qualité de la phase 2A dépendra désormais de sa capacité à ne pas l’effacer.

Sources

  1. Index de la correspondance ICANN
  2. Tripti Sinha à Nicolas Caballero, 24 août 2026
  3. Nicolas Caballero à Tripti Sinha, 11 mai 2026
  4. Décision du Conseil sur la phase 2A, 10 mars 2022
  5. Rapport final EPDP phase 2A
  6. Recommandations de la phase 2A soumises au Conseil
  7. Registration Data Policy d’ICANN
  8. Ressources RDAP d’ICANN