Nouveaux gTLD : le risque invisible des collisions de noms dans les réseaux d’entreprise africains

Une nouvelle extension peut sembler disponible dans la racine publique de l’Internet tout en étant déjà utilisée depuis des années à l’intérieur d’entreprises, d’administrations ou d’universités. Lorsqu’un même nom appartient soudainement à deux espaces différents, la collision peut provoquer des pannes, des fuites de données et des confusions d’identité.

Le 31 juillet 2026 marque la clôture de l’appel d’offres lancé par l’ICANN pour sélectionner le prestataire chargé de conduire l’évaluation initiale des risques de collision pour les chaînes demandées lors du nouveau round de gTLD.

Ce calendrier ne doit pas être confondu avec la période de dépôt des candidatures aux nouvelles extensions, qui reste ouverte jusqu’au 12 août 2026.

L’appel d’offres peut paraître très technique. Il touche pourtant à une question fondamentale : comment introduire de nouvelles extensions dans la racine publique de l’Internet sans perturber les réseaux privés qui utilisent déjà les mêmes chaînes ?

Une extension peut être absente du DNS public sans être réellement inutilisée.

Elle peut vivre depuis vingt ans dans les serveurs d’une banque, le système d’information d’une administration, les applications d’une université, les équipements d’un opérateur télécom ou les certificats internes d’un groupe industriel.

Le jour où cette chaîne devient une véritable extension Internet, deux mondes jusque-là séparés peuvent entrer en collision.

Pourquoi une chaîne apparemment libre peut déjà être utilisée

Dans le DNS public, une extension n’existe réellement que lorsqu’elle est inscrite dans la zone racine.

Mais les entreprises et les administrations ont souvent construit leurs propres espaces de nommage internes. Elles ont utilisé des suffixes tels que :

• .corp pour désigner un réseau d’entreprise,
• .home pour des équipements domestiques ou locaux,
• .mail pour des infrastructures de messagerie,
• des abréviations de marques, de ministères ou de projets,
• des mots génériques comme .intra, .groupe, .office ou .secure.

Ces chaînes ne sont pas nécessairement visibles depuis l’Internet. Elles peuvent uniquement fonctionner à l’intérieur d’un réseau privé, grâce à des serveurs DNS locaux.

Prenons un exemple fictif.

Une organisation utilise depuis plusieurs années l’adresse interne :

erp.groupe

Pour les salariés connectés au réseau de l’entreprise, ce nom permet d’accéder au logiciel de gestion.

Mais si .groupe devenait un jour une extension publique et que la requête interne échappait au réseau privé, l’utilisateur pourrait être dirigé vers une ressource située sur l’Internet public.

Le nom serait identique. Sa destination et son propriétaire seraient différents.

C’est précisément le mécanisme d’une collision de noms.

Une chaîne absente de la racine publique n’est pas nécessairement une chaîne libre. Elle peut déjà porter une histoire technique, des dépendances et des usages invisibles.

Le DNS public face aux espaces de nommage internes

Le DNS public constitue un espace mondial, hiérarchique et coordonné. Chaque extension déléguée dans la racine doit être unique.

Les espaces internes fonctionnent différemment. Une entreprise peut créer localement un nom sans le déclarer, sans l’enregistrer auprès d’un registrar et sans vérifier qu’il pourrait un jour exister dans le DNS public.

Tant que les requêtes restent à l’intérieur du réseau, le système peut sembler parfaitement stable.

Le problème apparaît lorsqu’une requête interne atteint un résolveur public. Cette fuite peut résulter :

• d’une mauvaise configuration DNS,
• d’un ordinateur utilisé en dehors du réseau de l’entreprise,
• d’une rupture de connexion VPN,
• d’une liste de suffixes de recherche mal configurée,
• d’une application utilisant un nom incomplet,
• d’un changement de fournisseur ou d’architecture cloud,
• d’un équipement ancien configuré avec un nom inscrit en dur.

Avant la délégation publique de la chaîne, la requête échouait généralement. Après la délégation, elle peut recevoir une réponse valide.

Cette différence est déterminante.

Une erreur visible peut devenir une connexion silencieuse vers une infrastructure extérieure.

Les risques : panne, fuite et confusion d’identité

Une collision de noms ne provoque pas systématiquement un incident grave. Mais lorsqu’elle touche une application critique, ses conséquences peuvent dépasser une simple erreur de résolution.

1. L’interruption de services

Une application interne peut ne plus atteindre le serveur attendu. Un système d’authentification, un progiciel, une imprimante, une base de données ou une interface d’administration peut devenir indisponible.

Dans une banque, un ministère ou un opérateur télécom, quelques noms mal résolus peuvent perturber une chaîne de services bien plus large.

2. La redirection de communications

La requête peut être envoyée vers une adresse publique contrôlée par un tiers.

Des logiciels peuvent alors tenter de transmettre des identifiants, des données techniques, des journaux, des notifications ou des informations de configuration à une infrastructure qui n’était pas le destinataire prévu.

3. La fuite de requêtes DNS

Même lorsqu’aucune connexion n’est établie, les requêtes elles-mêmes peuvent révéler des informations.

Les noms demandés peuvent indiquer :

• l’existence d’une application interne,
• le nom d’un projet confidentiel,
• la structure d’un réseau,
• le type d’équipement utilisé,
• l’organisation interne d’un ministère ou d’une entreprise.

La fuite DNS devient alors une source de renseignement technique pour un acteur extérieur.

4. Une confiance trompeuse dans les certificats

L’utilisation de TLS et de certificats numériques ne suffit pas toujours à neutraliser le risque.

Certaines infrastructures anciennes utilisent des certificats privés, des autorités de certification internes ou des configurations devenues difficiles à cartographier. Lors d’une migration, les noms contenus dans les certificats doivent également être identifiés et remplacés.

Un navigateur ou une application peut par ailleurs présenter une connexion comme sécurisée alors que la ressource atteinte n’est pas celle qui était initialement recherchée.

Le cadenas protège la connexion avec le serveur contacté. Il ne garantit pas, à lui seul, que l’utilisateur a contacté le bon espace de nommage.

5. Des applications anciennes difficiles à corriger

Les noms internes peuvent être inscrits directement dans :

• le code d’une application,
• des scripts d’automatisation,
• des configurations de pare-feu,
• des annuaires d’entreprise,
• des équipements industriels,
• des routeurs, imprimantes ou objets connectés,
• des logiciels qui ne sont plus maintenus par leur éditeur.

La difficulté ne consiste donc pas seulement à modifier une zone DNS. Elle consiste à retrouver toutes les dépendances créées autour du nom.

Ce que l’ICANN évaluera dans le round 2026

Le Guide de candidature 2026 prévoit que chaque chaîne demandée, ainsi que ses éventuelles variantes attribuables, passe par une évaluation initiale du risque de collision.

L’analyse reposera notamment sur :

• les données du Name Collision Observatory,
• les requêtes observées au niveau des serveurs racine,
• certaines données issues de résolveurs DNS récursifs,
• le volume et la diversité des requêtes,
• leur origine, leur type et leur évolution dans le temps,
• les données DITL et les indicateurs techniques ITHI,
• des éléments qualitatifs permettant d’évaluer la gravité potentielle du dommage.

Le volume brut ne sera pas le seul critère.

Une chaîne recevant peu de requêtes pourrait néanmoins concerner une infrastructure sensible. À l’inverse, un grand volume de requêtes ne signifie pas automatiquement qu’une délégation provoquerait un dommage grave.

Lorsque les données le justifieront, l’analyse qualitative cherchera notamment à déterminer si les requêtes sont associées à :

• une zone géographique particulière,
• un secteur économique,
• une organisation identifiable,
• une famille d’équipements ou de logiciels,
• un usage dont l’interruption aurait des conséquences importantes.

Lors du round précédent, environ 1 400 chaînes uniques avaient été demandées. Trois chaînes, .corp, .home et .mail, avaient été considérées comme présentant un risque élevé.

Pour le round 2026, une chaîne qui n’est pas classée à haut risque lors de l’évaluation initiale doit encore passer par une phase de délégation temporaire. Cette étape permettra d’observer son comportement avant une délégation définitive.

Les chaînes considérées à haut risque pourront être inscrites sur une liste dédiée. Le candidat devra alors présenter un plan de réduction du risque, soumis à évaluation, pour espérer poursuivre la procédure.

Le candidat ne peut donc pas considérer la collision comme un problème exclusivement interne à l’ICANN.

Il doit comprendre le passé technique de la chaîne qu’il souhaite exploiter.

Pourquoi les organisations africaines doivent inventorier leurs usages

Le risque de collision n’est pas spécifiquement africain. Mais certains contextes peuvent en compliquer la détection et la résolution.

De nombreuses infrastructures du continent ont été construites par étapes, avec plusieurs générations de prestataires, de logiciels et d’équipements.

Une administration peut faire coexister :

• un ancien annuaire d’entreprise,
• des applications développées localement,
• des équipements importés et préconfigurés,
• plusieurs réseaux ministériels,
• des services cloud récents,
• des certificats internes,
• des systèmes exploités par différents sous-traitants.

Dans cet environnement, personne ne possède nécessairement une vue complète de l’espace de nommage.

Le responsable réseau connaît les zones DNS. L’équipe cybersécurité surveille les flux. Le prestataire applicatif connaît les noms intégrés dans son logiciel. L’autorité de certification gère les certificats. Le registrar protège les domaines publics.

Mais ces informations restent souvent séparées.

La collision révèle alors une faiblesse plus profonde : l’absence de gouvernance globale du nommage numérique.

Une organisation qui ne connaît pas ses noms internes ne connaît pas complètement son infrastructure. Elle ne sait ni ce qui dépend d’elle, ni ce qui peut sortir de son périmètre.

Comment réduire le risque avant une délégation

La première protection consiste à ne plus créer de nouveaux espaces internes autour de chaînes arbitraires susceptibles d’être un jour déléguées dans la racine.

La pratique la plus robuste consiste à utiliser un sous-domaine rattaché à un nom officiellement enregistré et contrôlé par l’organisation.

Une entreprise propriétaire de entreprise.ma peut, par exemple, organiser ses ressources internes sous :

• intra.entreprise.ma,
• corp.entreprise.ma,
• services.entreprise.ma,
• interne.entreprise.ma.

Cette approche inscrit l’espace interne dans une hiérarchie dont l’organisation maîtrise officiellement la base.

Elle suppose néanmoins de protéger durablement le domaine utilisé : registrar fiable, renouvellement sécurisé, verrouillage, contrôle des accès et continuité administrative.

Pour les espaces existants, la migration doit être progressive.

Elle peut comprendre :

1. l’inventaire des zones DNS, suffixes de recherche, annuaires, certificats, applications et équipements,
2. l’analyse des journaux DNS afin d’identifier les requêtes qui quittent le réseau interne,
3. la cartographie des dépendances associées à chaque nom,
4. la création d’une nouvelle hiérarchie sous un domaine officiellement contrôlé,
5. une période de coexistence entre anciens et nouveaux noms,
6. le remplacement des certificats et des configurations applicatives,
7. la supervision des anciens noms jusqu’à la disparition des dernières requêtes.

La migration ne doit jamais commencer par la suppression brutale de l’ancienne zone.

Elle doit commencer par l’observation.

La proposition NAAM : intégrer le nommage interne à la gouvernance DNS

La gouvernance des noms de domaine est encore trop souvent limitée au portefeuille public : domaine principal, variantes défensives, extensions nationales, messagerie et renouvellements.

Cette vision est incomplète.

Le territoire numérique d’une organisation comprend également :

• ses sous-domaines techniques,
• ses espaces de nommage internes,
• ses zones DNS privées,
• ses certificats,
• ses dépendances applicatives,
• ses suffixes de recherche,
• ses identités de service,
• les requêtes qui s’échappent de son réseau.

NAAM propose d’intégrer ces éléments dans l’analyse de la souveraineté DNS des entreprises, institutions et administrations africaines.

Un Audit Souveraineté DNS ne doit pas seulement répondre à la question :

« Qui gère notre nom de domaine ? »

Il doit également permettre de savoir :

« Quels noms structurent réellement notre système d’information, qui les contrôle et que se passerait-il s’ils entraient demain en collision avec le DNS public ? »

Le round 2026 ne créera pas ces fragilités. Il les rendra visibles.

Les organisations qui commencent maintenant leur inventaire pourront corriger leurs dépendances avec méthode. Les autres risquent de découvrir leurs espaces de nommage internes au moment où ceux-ci cesseront de fonctionner comme prévu.

La prochaine génération d’extensions Internet ne doit donc pas être considérée uniquement comme une opportunité commerciale.

Elle constitue aussi un test mondial de maturité pour la gouvernance DNS.

Avant de créer de nouveaux territoires dans la racine de l’Internet, nous devons comprendre les territoires invisibles que nos organisations ont déjà construits.