Aller au contenu principal

Domaine principal

Gouvernance de l’Internet et routage

Au sein de la facette Domaine principal, l'analyse Gouvernance de l’Internet et routage regroupe les articles par domaine principal afin que les lecteurs puissent suivre un périmètre précis de l'infrastructure Internet, de la gouvernance, des marchés de connectivité ou du capital numérique. Cette page rassemble les articles associés, les preuves publiques, les institutions, les entreprises, les personnes, l'exposition régionale, les dépendances opérationnelles et le contexte de marché qui pourraient sinon être répartis entre différentes pages de catégories. Elle explique le domaine, la classe d'acteurs probable, le contexte de marché ou de gouvernance, ainsi que les sources que les lecteurs devraient utiliser pour comparer les signaux. Opérateurs, analystes et lecteurs de gouvernance peuvent voir comment un même domaine se manifeste à travers les événements, les profils, les évolutions de marché, les preuves issues de sources publiques, les dépendances régionales et les décisions d'infrastructure à plus long cycle au fil du temps.

ICANN : de la coordination des identifiants à l’exécution contractuelle

ICANN

ICANN : de la coordination des identifiants à l’exécution contractuelle

L’autorité d’ICANN ne vient pas d’un pouvoir public général. Elle se construit par couches: objet social et statuts, règles élaborées par une communauté multipartite, contrats conclus avec les registres et bureaux d’enregistrement, puis opérations techniques qui maintiennent les…

9 sept. 2026
IETF-W3C : deux systèmes d’autorité sous une même étiquette

IETF

IETF-W3C : deux systèmes d’autorité sous une même étiquette

L’étiquette IETF-W3C suggère parfois une institution unique. Les textes de référence décrivent pourtant deux systèmes de contrôle distincts: le processus de normalisation de l’IETF, ses organes et ses voies d’appel d’une part; le processus technique, les accords d’adhésion et les…

9 sept. 2026
Les recours d’ICANN ne sont pas interchangeables : qui peut contester quoi ?

ICANN

Les recours d’ICANN ne sont pas interchangeables : qui peut contester quoi ?

Chez ICANN, une objection ne devient pas automatiquement un recours. Elle doit entrer dans un instrument précis, franchir ses conditions d’accès et atteindre l’organe auquel les statuts confient la décision. Cette architecture distingue le pouvoir de la communauté de rejeter…

9 sept. 2026
DATAMATIX et AS210973 : ce que les registres et le routage peuvent réellement prouver

Récits

DATAMATIX et AS210973 : ce que les registres et le routage peuvent réellement prouver

Une enquête sur la différence entre une inscription publique, une déclaration de politique de routage, une observation BGP et une continuité opérationnelle démontrée.

8 sept. 2026
La 5e variante attribuable déclenche de nouveaux frais d’évaluation

ICANN

La 5e variante attribuable déclenche de nouveaux frais d’évaluation

Pour un nouveau demandeur, les quatre premières chaînes de variantes peuvent être incluses; chaque variante attribuable supplémentaire au-delà de la quatrième entraîne des frais complets d’évaluation de 227 000 USD.

8 sept. 2026
Une candidature gTLD déposée garde un délai de paiement de sept jours

ICANN

Une candidature gTLD déposée garde un délai de paiement de sept jours

Un dépôt gTLD dans les délais ne suffit pas: l’ICANN doit recevoir les frais d’évaluation pendant la fenêtre de paiement distincte.

6 sept. 2026
Le contrôle administratif est un filtre de dépôt, pas une décision au fond

ICANN

Le contrôle administratif est un filtre de dépôt, pas une décision au fond

Le contrôle administratif de l’ICANN vérifie le dépôt et prépare les ensembles de chaînes identiques sans constituer une décision au fond.

6 sept. 2026
Une évaluation RSP peut couvrir plusieurs gTLD — seulement pour les services qualifiés

ICANN

Une évaluation RSP peut couvrir plusieurs gTLD — seulement pour les services qualifiés

Une évaluation peut être réutilisée pour plusieurs gTLD, mais la qualification ICANN reste liée à des services précis.

6 sept. 2026
La couverture RSP est une carte de fonctions, pas un nombre de prestataires

ICANN

La couverture RSP est une carte de fonctions, pas un nombre de prestataires

Un candidat peut nommer plusieurs prestataires de services de registre tout en laissant une fonction critique sans couverture. Le cadre ICANN du cycle 2026 distingue les rôles Main, DNS, DNSSEC et Proxy facultatif, avec des fonctions et des limites de nombre propres à chacun.

6 sept. 2026
Nommer un RSP ne vaut pas confirmation lors de la contractualisation

ICANN

Nommer un RSP ne vaut pas confirmation lors de la contractualisation

Un candidat peut désigner un prestataire de services de registre dans son dossier, tandis que l’ICANN lui demande séparément une confirmation lors de la contractualisation. Le choix du candidat, la demande de l’ICANN et toute réponse effective du RSP constituent des preuves…

6 sept. 2026
Le choix des RSP peut attendre l’évaluation, pas indéfiniment

ICANN

Le choix des RSP peut attendre l’évaluation, pas indéfiniment

Les règles ICANN 2026 permettent de déposer une candidature sans nommer les prestataires de services de registre, mais exigent la couverture des fonctions critiques minimales au stade de l’évaluation.

6 sept. 2026
Les ensembles de variantes entrent ensemble en concurrence

ICANN

Les ensembles de variantes entrent ensemble en concurrence

Les règles ICANN 2026 traitent la chaîne principale et ses variantes attribuables demandées comme une seule unité de concurrence lorsque plusieurs candidats visent le même ensemble de variantes.

6 sept. 2026
Les demandes de variantes de gTLD existants sont prioritaires, sans être approuvées

ICANN

Les demandes de variantes de gTLD existants sont prioritaires, sans être approuvées

ICANN accorde une place plus précoce dans l’ordre de traitement à une catégorie de demandes: les variantes attribuables de gTLD existants issus du cycle 2012. Cette priorité modifie l’ordre, pas l’issue de fond.

6 sept. 2026
Les variantes d’un gTLD existant placent le registre sous un seul contrat 2026

ICANN

Les variantes d’un gTLD existant placent le registre sous un seul contrat 2026

Un opérateur qui demande des variantes attribuables d’un gTLD existant n’ajoute pas des libellés isolés à un contrat inchangé. Les règles ICANN 2026 imposent le passage au nouveau contrat de registre de base et réunissent le gTLD existant et ses variantes dans un seul contrat.

6 sept. 2026
Seul l’opérateur du gTLD existant peut demander ses variantes IDN

ICANN

Seul l’opérateur du gTLD existant peut demander ses variantes IDN

Pour le cycle ICANN 2026, le demandeur de variantes IDN d’un gTLD existant doit être la même personne morale que l’opérateur de registre de ce gTLD.

6 sept. 2026
Les variantes IDN doivent partager le prestataire de registre du gTLD principal

ICANN

Les variantes IDN doivent partager le prestataire de registre du gTLD principal

Pour le cycle ICANN 2026, un gTLD IDN principal et ses variantes doivent utiliser le même prestataire de services de registre back-end pendant leur délégation.

5 sept. 2026
Le retrait d’une demande IDN principale retire aussi ses variantes

ICANN

Le retrait d’une demande IDN principale retire aussi ses variantes

Pour le cycle ICANN 2026, le retrait d’une demande visant un IDN principal entraîne aussi le retrait de toutes les chaînes variantes demandées avec lui.

5 sept. 2026
Une demande de variante IDN ne peut pas précéder sa chaîne principale

ICANN

Une demande de variante IDN ne peut pas précéder sa chaîne principale

Pour le cycle ICANN 2026, une demande portant sur une variante IDN allouable ne peut pas être déposée avant celle du gTLD IDN principal auquel elle se rattache.

5 sept. 2026
Pour un IDN principal proposé, le choix peut changer les variantes allouables

ICANN

Pour un IDN principal proposé, le choix peut changer les variantes allouables

Lorsque le principal proposé n’est pas un gTLD existant, le nombre total de chaînes de l’ensemble de variantes RZ-LGR reste inchangé, mais les sous-ensembles de variantes allouables et bloquées peuvent changer avec ce choix.

5 sept. 2026
ICANN autorise le retrait de variantes IDN après le dépôt, mais pas leur ajout

ICANN

ICANN autorise le retrait de variantes IDN après le dépôt, mais pas leur ajout

Pour le cycle 2026, le dépôt fixe l’ensemble initial formé par l’IDN principal et ses variantes demandées: il peut ensuite être réduit par retrait, mais pas élargi.

5 sept. 2026