HCCF soumet à l’ICANN sa candidature pour le domaine .self dédié au self-hosting

30 avril 2026. L’ICANN ouvre la fenêtre de candidature du programme New gTLD 2026, la seconde vague de noms de domaine génériques de l’histoire. 12 août 2026. La fenêtre se referme. Semaine du 14 août 2026. La newsletter selfh.st annonce que la Human-Centered Computing Foundation (HCCF) a « officiellement soumis sa candidature » pour un domaine bien particulier : .self, pensé pour le self-hosting.

L’idée tient en une phrase : donner aux projets qui rendent à l’utilisateur le contrôle de ses données et de son identité un espace de noms qui le dise, au niveau le plus bas de l’adresse web. C’est ambitieux, daté, et surtout — c’est une question de gouvernance autant que de DNS.

Ce que HCCF demande, et ce que l’ICANN exige

La Human-Centered Computing Foundation est une association à but non lucratif dont le plaidoyer tourne autour d’un constat : les grandes plateformes ont exploité l’infrastructure du web pour collecter des données et verrouiller l’identité des utilisateurs dans des systèmes fermés. Sa réponse commence à la couche du nommage : créer un espace où les projets peuvent signaler des engagements autour des données personnelles, de l’autonomie et d’une informatique centrée sur l’humain.

Pour y parvenir, HCCF a rejoint l’Applicant Support Program (ASP) de l’ICANN, un dispositif destiné aux candidats à ressources limitées. L’ASP apporte du conseil, un accès à des prestataires bénévoles, et surtout une réduction de 75 à 85 % des frais d’évaluation — plus des frais d’opérateur de registre réduits si la délégation aboutit. C’est ce soutien qui rend une candidature de cette ampleur envisageable pour une structure associative.

Mais l’ICANN est claire sur un point : l’acceptation à l’ASP ne garantit rien. HCCF doit encore déposer une candidature complète, passer l’évaluation, affronter d’éventuelles objections, choisir un prestataire de registre et démontrer qu’elle peut exploiter un espace de noms avec la disponibilité, la réponse aux abus et les contrôles de politique qu’exige l’ICANN. Le chemin est long — l’évaluation d’un nouveau TLD se compte en années, pas en mois.

Un registre peut faire des règles, pas des miracles

L’argument le plus solide de HCCF n’est pas le nom, c’est le modèle de registre. Un opérateur de TLD peut imposer des conditions que ni .com ni .org n’imposent : un code de conduite pour les titulaires, des pratiques de données publiées, le DNSSEC obligatoire, la portabilité des données, voire des procédures de revue pour les projets qui détournent le nom.

C’est ce qui distinguerait .self d’un énième TLD décoratif. Si HCCF fait de ces règles des obligations contraignantes, l’adresse devient un marqueur de confiance — à la manière d’un label — plutôt qu’un simple suffixe. Si elle n’y parvient pas, .self n’aura qu’une valeur de slogan.

Le risque est symétrique. Le terme « technologie centrée sur l’humain » couvre aussi bien des outils de confidentialité, des projets d’identité numérique, des logiciels de santé ou des produits d’IA. Sans critères publics et vérifiables, n’importe quelle équipe pourra utiliser le langage de l’éthique comme simple vernis de marque. La crédibilité du TLD dépendra entièrement de la rigueur de ses critères d’enregistrement.

Le vrai débat : un TLD aide-t-il les auto-hébergeurs, ou les désigne-t-il ?

La communauté self-hosted a posé une question plus inconfortable, visible dans les commentaires du billet fondateur de HCCF. Un domaine dédié au self-hosting ne dit pas seulement « ceci est à moi » : il dit aussi « ceci est auto-hébergé ». Or l’auto-hébergement, c’est précisément ce que beaucoup d’utilisateurs préfèrent ne pas annoncer. Comme le résume un commentateur : « la seule chose qu’un TLD apporterait, c’est de donner aux attaquants davantage de confiance qu’un auto-hébergeur a installé son serveur ici ».

La critique porte aussi sur la vérification. Le concept « une personne, un domaine » avancé dans le pamphlet de HCCF pose la question de l’identité : comment vérifier qu’un titulaire est bien celui qu’il prétend être, sans reproduire les systèmes d’identité centralisés que la fondation entend justement contourner ? À ce stade, HCCF n’a ni montant de financement, ni partenaire de registre, ni procédure d’enregistrement publiés. Les réponses détermineront si .self devient une infrastructure ou un exercice de communication.

Le précédent de 2012 : un TLD ne fait pas une communauté

Le dossier .self s’inscrit dans une histoire qu’il faut se rappeler pour lire l’annonce à sa juste valeur. La première vague de nouveaux gTLD, lancée en 2012, a produit plus de 1 200 candidatures et une leçon simple : obtenir un suffixe ne crée ni communauté ni usage. Des noms techniques comme .app ou .dev ont fini entre les mains de grandes entreprises ; d’autres, portés par des structures à la communication généreuse, ont été délégués puis abandonnés faute de modèle économique.

Le coût est un filtre en soi. La candidature à un gTLD se chiffre historiquement en centaines de milliers de dollars — frais d’évaluation, caution, puis frais annuels de registre une fois délégué. C’est exactement ce que l’ASP de l’ICANN cherche à corriger pour les structures associatives comme HCCF, avec une réduction de 75 à 85 % des frais. Mais la réduction ne finance pas l’exploitation sur la durée : il faudra un partenaire de registre et un flux de revenus pour tenir pendant les années d’évaluation.

La conséquence est nette : .self est un pari de gouvernance à long terme, pas un produit disponible. Entre le dépôt d’une candidature et la première délégation, il s’écoulera des années, et rien ne garantit l’issue. C’est une raison de suivre le dossier avec intérêt, et une raison supplémentaire de ne rien fonder dessus aujourd’hui.

Ce qui garantit votre identité aujourd’hui, indépendamment de .self

Pendant que l’évaluation de l’ICANN suivra son cours, une vérité technique reste stable : un nom de domaine ne protège pas par lui-même. La surveillance, les dark patterns et la faiblesse des mots de passe passent à travers n’importe quel suffixe. Ce qui protège réellement une présence auto-hébergée, c’est ce que vous contrôlez : un domaine dont vous détenez la propriété, une chaîne DNSSEC signée, une infrastructure à vous, et des services exposés avec méthode.

# La garantie réelle, aujourd'hui, c'est la signature de votre zone, pas son suffixe
dig +dnssec SOA votredomaine.com | grep -E "RRSIG|status"

Cette commande vous en dit plus long sur la robustesse de votre identité en ligne que l’appartenance à n’importe quel TLD. Un enregistrement DNSSEC signé et vérifiable est une garantie cryptographique ; un suffixe .self serait, au mieux, une garantie contractuelle — qui ne vaut que par les règles qu’une fondation saura rendre contraignantes, et par sa capacité à les faire appliquer.

Verdict

Si vous auto-hébergez déjà, ne changez rien à votre infrastructure pour .self : le TLD n’est pas délégué, son évaluation prendra des années, et son intérêt réel — des règles d’enregistrement contraignantes — n’est encore qu’une promesse. Votre priorité reste ce que vous contrôlez : propriété du domaine, DNSSEC, sauvegardes, exposition maîtrisée.

Si l’idée vous séduit, suivez le dossier pour ce qu’il est : une tentative, inédite par son objet, d’utiliser la couche du nommage comme levier de gouvernance. Son succès se mesurera à la rigueur de ses critères d’enregistrement et à sa capacité à les faire appliquer — pas au suffixe lui-même.

Le signal de fond est que le self-hosting cherche désormais à se nommer autant qu’à se techniquer. C’est un signe de maturité du mouvement — mais la maturité, ici, s’obtiendra par des règles vérifiables et une exécution rigoureuse, pas par un nom de domaine.

Références

• selfh.st — Self-Host Weekly (14 August 2026)
• HCCF — Reclaiming Our Digital Selves: HCCF’s Vision for a Human-Centered Top-Level Domain, 21 juin 2026
• LavX News — HCCF pitches .self domain for human-centered technology, 30 juin 2026
• ICANN — 2026 New gTLD Program, Round 2
• ICANN — Applicant Support Program