Résumé

  • L’inventaire actuel de l’ICANN classe la ccPDP4 parmi les recommandations en attente d’une action du Conseil d’administration ; il ne s’agit ni d’une politique adoptée ni d’une mise en œuvre.
  • Le rapport final lie un cas précis de suppression ISO 3166-1 à un déclencheur de retrait, tout en réservant la décision territoriale à une source extérieure.
  • Daniel Kade recommande un reçu de déclencheur externe qui distingue source, clause, portée du nom, compétence, examen et action opérationnelle. Ce reçu n’est pas une règle de l’ICANN.

Le repère extérieur ne transfère pas la compétence

Les listes de référence rendent la coordination possible parce qu’elles évitent à chaque système de reconstituer le monde. Mais cette économie institutionnelle crée une tentation : décrire l’acteur qui réagit à une liste comme s’il avait décidé le fait que la liste enregistre. Le raccourci est particulièrement coûteux lorsqu’il concerne un nom de pays ou de territoire.

La ccPDP4 propose une politique relative aux chaînes de caractères de ccTLD IDN associées aux entrées de codes pays d’ISO 3166-1. Dans le cas où un nom de territoire disparaît de cette liste à la suite d’une division ou d’une fusion, le rapport en fait le déclencheur d’une procédure de retrait des chaînes sélectionnées et, le cas échéant, de leurs variantes. Puis il refuse de se faire juge de la prémisse : la décision de retirer le nom est extérieure ; elle est hors du mécanisme de révision, car IANA/ICANN n’a pas pour mission de déterminer ce qu’est un pays ou un territoire.

Il ne s’agit pas de dire qu’une liste ISO ne produit jamais de conséquences. Il s’agit de savoir qui fait quoi. La maintenance ISO fournit un fait de référence. La politique de la ccNSO définit une voie conditionnelle. Le Conseil d’administration peut, ou non, agir dans son champ. Une instruction et une opération ultérieure ont encore une autre nature. Aucun maillon ne doit absorber les compétences des autres.

L’ouverture d’une procédure n’est pas sa conclusion

Le rapport rend lui-même impossible l’automatisme. Dans l’hypothèse d’une fusion, une chaîne IDN sélectionnée ne devrait pas être retirée si elle reste une représentation signifiante dans une langue désignée et bénéficie du soutien des parties significativement intéressées du territoire fusionné. Il mentionne aussi le critère d’une chaîne par langue désignée et ses conséquences lorsqu’une autre chaîne existe déjà.

Cela ne permet aucune affirmation sur un cas réel. Les sources vérifiées ne signalent ni modification actuelle d’ISO 3166-1, ni retrait d’un ccTLD IDN, ni contentieux territorial. Elles montrent en revanche que l’événement externe, le champ précis d’une chaîne, les conditions de représentation et de soutien, un examen et une exécution sont des objets séparés.

Les confondre revient à blanchir un mandat. Une vérification technique ne statue pas sur la prémisse politique. Une action IANA ne crée pas le fait extérieur. Une contribution de communauté peut être pertinente dans un test défini, sans devenir un vote de souveraineté. La présence ou l’expertise sont des preuves possibles ; elles ne constituent pas une compétence illimitée.

Le statut présent reste celui d’une clarification et d’une considération

La situation actuelle appelle la même retenue. L’inventaire de l’ICANN place la ccPDP4 dans les recommandations en attente d’action du Board, distinctes des projets de mise en œuvre. Des documents publics de 2026 indiquent que le Conseil de la ccNSO a reçu quatre demandes de clarification ou de confirmation d’interprétation d’un Board Caucus menant une évaluation de faisabilité de l’implémentation. Le Conseil a adopté une réponse en juillet et demandé qu’elle soit communiquée après prise d’effet. Le 2 septembre, l’aperçu de l’atelier du Board annonçait une discussion des recommandations.

Une question de clarification est significative, mais n’est pas une adoption. La réponse d’un Conseil exprime une étape de processus, mais n’est pas une décision finale du Board. Un atelier annoncé n’est pas une résolution. Dire « en attente d’action » avec précision protège mieux le public que de produire l’atmosphère trompeuse d’une politique déjà en vigueur.

Un reçu de déclencheur externe

Daniel Kade propose donc un reçu de déclencheur externe limité. Il identifierait le gestionnaire de la référence, son édition, sa date d’effet, le changement cité et une source durable, en précisant que ce n’est pas une constatation de l’ICANN. Il citerait la clause ccPDP4, sa version et son statut : rapport final, politique adoptée, clarification et procédure d’exécution doivent rester explicitement distincts.

Il circonscrirait aussi la chaîne IDN et les variantes concernées, sans utiliser un pays ou une communauté linguistique comme substitut imprécis de l’objet. Il montrerait la compétence : qui peut constater un critère, décider l’étape suivante, revoir une décision ou la corriger, et ce qui demeure hors mandat. Enfin, il séparerait une décision du Board, une instruction d’exécution et une opération effective, avec date, portée et voie de correction.

Le reçu ne transforme pas des champs de données en règlement territorial. Il ne révèle pas des soumissions privées ni des détails opérationnels sensibles. Il rend seulement plus difficile qu’une institution de coordination emprunte, par une phrase de statut, l’autorité que possède réellement une autre.

Une frontière plus importante encore pour les écritures locales

Un ccTLD IDN n’est pas un identifiant interchangeable. Il peut être une porte d’entrée dans une langue et une écriture auxquelles les utilisateurs associent une continuité réelle. Un résumé imprécis d’une opération technique risque alors d’être lu comme reconnaissance ou déni. L’obligation de continuité ne disparaît pas ; elle exige au contraire une chaîne publique plus claire entre prémisse extérieure, règle interne, décision autorisée et action.

Limites des preuves

Cet Article ne rapporte aucun changement ISO en cours, aucun retrait concret, aucun différend territorial, aucune résolution du Board ni aucune action IANA. Il ne prétend pas que la ccPDP4 est aujourd’hui adoptée. Le reçu proposé est une recommandation éditoriale de Daniel Kade, non une instruction adressée à ISO, l’ICANN, la ccNSO ou IANA.

Sources

  1. Final Report ccNSO PDP4 (de-)selection of IDNccTLDs
  2. ICANN policy implementation inventory
  3. PDP (de-)selection of IDN ccTLD Strings Working Group
  4. Questions Board Caucus IDNccPDP4
  5. Draft agenda ccNSO Council meeting 231
  6. Chair's Blog: September Board Workshop Preview
  7. ICANN Bylaws
  8. RFC 1591
  9. RFC 5890
  10. Heng Lu — The Multi-Stakeholder Mirage