À la veille de la fermeture du round 2026 des nouveaux gTLD, un chiffre mérite davantage d’attention que le nombre de futures extensions : au 31 juillet, aucune organisation africaine n’avait soumis de candidature pour devenir Registry Service Provider. L’Afrique pourrait donc obtenir de nouvelles extensions tout en continuant à dépendre d’infrastructures techniques opérées depuis d’autres continents.
- 33 organisations : au 31 juillet 2026, 33 organisations avaient soumis au moins une candidature RSP auprès de l’ICANN.
- Afrique : zéro : aucune organisation africaine n’avait atteint ce stade, contre 16 en Europe, 10 en Asie-Pacifique, 6 en Amérique du Nord et 1 en Amérique latine/Caraïbes.
- Infrastructure critique : les RSP assurent des fonctions telles que le DNS, DNSSEC, RDAP, EPP ou certaines opérations liées aux données du registre.
- Dépendance ≠ faiblesse : faire appel à un opérateur étranger peut être parfaitement rationnel, à condition de maîtriser la relation technique et contractuelle.
- Enjeu stratégique : l’Afrique doit progressivement développer sa propre capacité à opérer les infrastructures techniques des extensions Internet.
Demain, 12 août 2026 à 23 h 59 UTC, deux fenêtres importantes du système mondial des noms de domaine vont se fermer : celle des candidatures aux nouveaux gTLD et celle permettant de déposer une candidature au Registry Service Provider Evaluation Program de l’ICANN.
L’attention se porte naturellement sur les futures extensions : combien seront déposées, quelles marques participeront, quelles villes, quelles communautés, quels projets émergeront ?
Mais une autre question, beaucoup moins visible, me paraît tout aussi importante.
Qui fera réellement fonctionner ces extensions ?
Car une extension Internet peut être africaine par son nom, par son propriétaire, par sa communauté ou par sa mission, tout en reposant techniquement sur une infrastructure opérée depuis Paris, Londres, Toronto, Pékin ou ailleurs.
Et c’est là que commence une autre lecture de la souveraineté numérique.
Une extension Internet cache une infrastructure complexe
Pour le grand public, une extension se résume souvent aux caractères situés à droite du point.
.tech.
.bank.
.paris.
.africa.
Pourtant, derrière quelques lettres se trouve une infrastructure qui doit fonctionner en permanence.
Il faut notamment gérer les échanges avec les registrars, publier et maintenir les informations nécessaires à la résolution des noms, assurer les services DNS, signer les zones avec DNSSEC, fournir les données d’enregistrement accessibles par RDAP et garantir différents mécanismes opérationnels indispensables au registre.
L’ICANN regroupe une grande partie de ces responsabilités techniques autour des Registry Service Providers, ou RSP. Le programme distingue plusieurs fonctions, notamment les services de registre principaux, le DNS et DNSSEC.
Un candidat à une nouvelle extension n’est donc pas obligé de construire lui-même toute cette infrastructure.
Il peut s’appuyer sur un ou plusieurs prestataires spécialisés.
Et c’est précisément ce que feront probablement une grande partie des futurs registres.
Le RSP : l’acteur invisible derrière le registre
Il faut distinguer deux fonctions.
L’opérateur du registre porte l’extension, son projet, sa gouvernance et sa relation contractuelle avec l’ICANN.
Le Registry Service Provider fournit tout ou partie de l’infrastructure technique permettant à cette extension de fonctionner.
L’ICANN impose ainsi aux candidats du round 2026 d’identifier un ou plusieurs RSP ayant réussi son processus d’évaluation. Un candidat peut faire appel à un prestataire extérieur ou chercher lui-même à être qualifié comme RSP.
Cette distinction change profondément la lecture d’une extension.
Posséder le registre ne signifie pas nécessairement en maîtriser toutes les couches techniques.
Un ministère africain pourrait demain soutenir une extension stratégique. Une grande entreprise du continent pourrait déposer son .brand. Une ville pourrait envisager une extension géographique.
Le projet serait africain.
La gouvernance pourrait être africaine.
Le financement pourrait être africain.
Mais le moteur technique pourrait être entièrement opéré ailleurs.
Les chiffres du round 2026 : où est l’Afrique ?
C’est ici que les dernières statistiques publiées par l’ICANN deviennent intéressantes.
Au 31 juillet 2026, 33 organisations avaient soumis au moins une candidature pour devenir RSP :
- Europe : 16
- Asie-Pacifique : 10
- Amérique du Nord : 6
- Amérique latine et Caraïbes : 1
- Afrique : 0
Parmi elles, 28 organisations avaient déjà réussi au moins une évaluation RSP.
Pour l’Afrique, le chiffre restait encore une fois à zéro.
Une organisation africaine apparaissait bien dans les statistiques, mais uniquement au stade très préliminaire consistant à fournir les premières informations relatives à l’organisation. Elle n’avait donc pas encore atteint le stade d’une candidature RSP soumise.
La photographie officielle disponible au moment où j’écris ces lignes renforce le constat.
La liste des RSP publiée par l’ICANN, actualisée le 10 août 2026, fait apparaître des opérateurs comme AFNIC, CIRA, CentralNic, Google Registry, CORE, Identity Digital, Nominet, GoDaddy Registry, Tucows, ainsi que plusieurs acteurs européens et asiatiques.
Aucun opérateur qui y figure n’est localisé en Afrique.
Ce chiffre ne signifie pas que l’Afrique ne possède aucune compétence DNS ou registre.
Ce serait faux.
Il signifie quelque chose de beaucoup plus précis : dans le mécanisme actuellement mis en place par l’ICANN pour fournir les services techniques aux futurs nouveaux gTLD, la capacité africaine qualifiée est pour l’instant absente.
Et cette nuance est essentielle.
Une extension n’est pas souveraine uniquement parce que son nom appartient à l’Afrique. Il faut également regarder qui opère son infrastructure, qui contrôle ses dépendances et dans quelles conditions elle peut changer de fournisseur.
Dépendre d’un RSP étranger n’est pas nécessairement un problème
Il serait tentant de transformer ces chiffres en opposition entre opérateurs africains et étrangers.
Ce serait une mauvaise lecture.
Les infrastructures de registre exigent un haut niveau de disponibilité, de sécurité, d’automatisation, de supervision et d’expérience opérationnelle.
S’appuyer sur des acteurs établis peut apporter :
- une infrastructure éprouvée,
- des compétences immédiatement disponibles,
- une capacité mondiale de DNS,
- des économies d’échelle,
- une conformité déjà maîtrisée avec les exigences de l’ICANN,
- une réduction du risque opérationnel au lancement.
La souveraineté numérique ne consiste pas à reconstruire systématiquement ce que d’autres savent déjà très bien faire.
Elle consiste à savoir pourquoi on externalise, ce que l’on externalise, à qui, avec quelles garanties et avec quelle possibilité de reprendre ou déplacer le service.
Quand la dépendance devient un enjeu de souveraineté
Le problème apparaît lorsque l’externalisation devient invisible. Lorsqu’un registre ne connaît plus précisément ses dépendances techniques.
Lorsqu’il n’existe aucune capacité locale permettant d’auditer le prestataire.
Lorsque la sortie contractuelle est théorique. Lorsque les compétences sont entièrement concentrées chez le fournisseur.
Ou lorsqu’une infrastructure considérée comme stratégique ne peut fonctionner qu’à travers des décisions prises sous une autre juridiction.
La question pertinente n’est donc pas :
« Le RSP est-il africain ? »
Elle est :
« Le registre garde-t-il réellement la maîtrise de son infrastructure et de ses dépendances ? »
DNS, DNSSEC, données et continuité : ce qu’il faut mesurer
Pour un gouvernement, une institution ou une entreprise africaine souhaitant porter une nouvelle extension, le choix d’un RSP devrait dépasser largement le prix du service.
Il faudrait notamment examiner :
- l’architecture et la résilience du DNS,
- la répartition géographique des infrastructures,
- la gestion des clés et des procédures DNSSEC,
- la disponibilité et la supervision des services critiques,
- la gestion des données et des sauvegardes,
- les mécanismes de réponse aux incidents,
- les sous-traitants et dépendances techniques du RSP lui-même,
- les juridictions applicables,
- les conditions de portabilité et de migration,
- la capacité du registre à changer de prestataire sans mettre en danger son extension.
L’ICANN identifie elle-même parmi les services techniques associés aux RSP le DNS, DNSSEC, RDAP, EPP, l’accès aux fichiers de zone ou encore les mécanismes de dépôt de données du registre.
Ce ne sont pas des détails techniques. Pour une extension stratégique, ce sont des questions de continuité.
Construire une capacité africaine d’opération de registres
L’absence observée en 2026 ne doit pas conduire à réclamer artificiellement cinquante nouveaux RSP africains.
Le continent n’en a pas besoin.
Il a besoin de quelques capacités solides, crédibles, mutualisées et capables de fonctionner à une échelle régionale ou continentale.
Une trajectoire réaliste pourrait commencer par cinq actions.
1. Cartographier les compétences existantes
Les registres de ccTLD, opérateurs DNS, universités, points d’échange Internet, télécoms et data centers africains disposent déjà d’une partie des compétences nécessaires.
Il faut commencer par les identifier et les connecter.
2. Construire des capacités régionales
Tous les pays n’ont pas besoin de leur propre infrastructure complète.
Des plateformes régionales pourraient mutualiser ingénierie, supervision, DNS, sécurité et investissement tout en servant plusieurs registres.
3. Entrer progressivement dans la chaîne RSP
Le modèle de l’ICANN distingue plusieurs catégories de services RSP. Cela ouvre la possibilité de développer progressivement des compétences spécialisées, notamment autour du DNS ou de DNSSEC, avant d’envisager des capacités plus larges de back-end de registre.
4. Transformer les ccTLD en réservoirs de compétences
Les extensions nationales africaines ne sont pas seulement des actifs souverains.
Elles peuvent devenir des écoles opérationnelles du DNS, de DNSSEC, de la sécurité des registres et de la gouvernance technique.
Le développement de compétences autour des ccTLD peut progressivement nourrir une industrie africaine du registre dépassant les seules extensions nationales.
5. Intégrer la souveraineté dans les appels d’offres
Lorsqu’un futur registre africain choisira son RSP, la souveraineté ne devrait pas signifier « fournisseur local obligatoire ».
Elle devrait devenir une grille d’évaluation :
résilience, transparence, auditabilité, transfert de compétences, juridiction, réversibilité et maîtrise des dépendances.
L’enjeu dépasse largement le round 2026
Demain soir, la fenêtre des candidatures se fermera.
Les chiffres définitifs du round permettront ensuite de savoir quelles extensions ont réellement été demandées et quelle place l’Afrique occupera parmi les candidats.
Mais le signal donné par le programme RSP mérite déjà d’être retenu.
L’Afrique peut obtenir davantage de noms dans la racine de l’Internet sans pour autant augmenter dans les mêmes proportions sa capacité à les faire fonctionner.
Ce n’est pas nécessairement un problème pour le prochain round.
Cela en deviendrait un si la situation restait identique dans dix ans.
Car il existe plusieurs niveaux de souveraineté numérique.
Pouvoir utiliser une infrastructure.
Pouvoir la financer.
Pouvoir la gouverner.
Pouvoir l’auditer.
Pouvoir la remplacer.
Et, lorsque cela devient stratégique, être également capable de l’opérer.
L’Afrique ne doit pas chercher à tout héberger, tout posséder ou tout reconstruire. Elle doit s’assurer qu’aucune infrastructure essentielle à son identité numérique ne devienne une dépendance qu’elle ne comprend pas, ne contrôle pas et ne peut pas remplacer.
Pour les futurs registres africains, le choix d’un Registry Service Provider ne devrait donc jamais être considéré comme une simple décision technique. Il appartient pleinement à la stratégie de gouvernance, de résilience et de souveraineté de l’extension.
- ICANN RSP Program Statistics – July 2026 31 juillet 2026
- ICANN Registry Service Provider Evaluation Program
- ICANN List of Evaluated MAIN, DNS, DNSSEC, PROXY, and IDN Support Level Applications 10 août 2026
- ICANN ICANN 2026 Round Registry Service Provider Evaluation Program Closes 12 August 8 juillet 2026
