Un domaine africain suffit-il à rendre un service numérique africain ?

Un service peut utiliser un domaine national africain, être hébergé sur le continent et pourtant dépendre d’infrastructures situées à des milliers de kilomètres. La souveraineté numérique ne se lit donc pas uniquement dans une extension ou dans l’adresse d’un data center. Elle se mesure sur toute la chaîne technique.

Cette semaine, à Kigali, une partie de l’infrastructure invisible de l’Internet africain se retrouve dans une même salle.

L’African Peering and Interconnection Forum – AfPIF 2026 réunit du 18 au 20 août les opérateurs de réseaux, points d’échange Internet, data centers, fournisseurs de contenus, opérateurs de transit et acteurs qui déterminent, très concrètement, la manière dont les données circulent sur le continent.

C’est un sujet beaucoup moins visible que l’intelligence artificielle, le cloud ou les plateformes numériques.

Pourtant, il touche directement à une question qui m’intéresse depuis longtemps : qu’est-ce qu’un service numérique réellement africain ?

Prenons un exemple volontairement simple.

Une institution marocaine utilise un domaine en .ma. Son site est hébergé dans un data center à Casablanca.

À première vue, l’ensemble paraît parfaitement local.

Mais que se passe-t-il si son DNS est opéré hors d’Afrique ? Si son application dépend d’un cloud international ? Si ses mécanismes d’authentification, de protection DDoS ou ses API reposent sur des infrastructures étrangères ? Et surtout, si une partie du trafic échangé entre deux réseaux marocains doit quitter le territoire avant de revenir ?

Le domaine et le serveur ne racontent qu’une partie de l’histoire.

Le ccTLD : un signe de souveraineté, pas une preuve suffisante

Je considère les extensions nationales comme des infrastructures importantes.

Un .ma, un .sn, un .ci, un .ng ou un .za rattache une identité numérique à un espace national identifiable.

Le ccTLD peut participer à la confiance, à la visibilité d’un écosystème numérique local et, selon les pays, à des politiques nationales de nommage.

Mais il faut éviter un raccourci.

Un nom de domaine national ne détermine ni l’endroit où le service est hébergé, ni l’endroit où son DNS est opéré, ni le chemin emprunté par son trafic.

Une administration peut parfaitement utiliser un domaine national tout en dépendant presque entièrement d’infrastructures techniques externes.

Inversement, un service utilisant un domaine générique peut disposer d’une architecture locale extrêmement robuste.

Le domaine est donc une première couche de souveraineté.

Il n’en constitue pas, à lui seul, la démonstration.

La souveraineté numérique ne peut pas se résumer à ce que l’utilisateur voit dans sa barre d’adresse. Elle commence précisément là où l’utilisateur ne voit plus rien.

Qui contrôle réellement le DNS ?

Lorsqu’un utilisateur saisit un domaine, le DNS lui indique où trouver le service. Cette fonction paraît élémentaire. Elle est pourtant déterminante.

Pour une infrastructure stratégique, plusieurs questions devraient être posées :

• qui fournit le DNS autoritatif ?
• où sont situés ses différents nœuds ?
• quelle architecture de redondance est utilisée ?
• le domaine est-il protégé par DNSSEC ?
• qui contrôle les clés et les configurations ?
• que se passe-t-il si le fournisseur devient indisponible ?
• peut-on transférer rapidement la zone vers un autre opérateur ?

L’Anycast permet aujourd’hui à de grands fournisseurs DNS de distribuer leurs infrastructures à travers le monde. La question ne consiste donc pas nécessairement à exiger que chaque serveur soit physiquement installé dans le pays.

La vraie question est plus intéressante :

où se situent les dépendances critiques et quelles sont les capacités de contrôle en cas de crise ?

C’est une distinction importante.

La souveraineté n’est pas nécessairement la localisation absolue.

Elle est d’abord une maîtrise des dépendances.

L’adresse IP et le routage : l’infrastructure que l’utilisateur ne voit jamais

Derrière le domaine se trouvent ensuite des adresses IP. Puis des réseaux.

Puis des Autonomous System Numbers – les ASN – qui permettent aux différents réseaux constituant Internet d’échanger des informations de routage.

En Afrique, AFRINIC joue le rôle de registre Internet régional pour les ressources numériques telles que les adresses IPv4, IPv6 et les ASN.

Mais posséder ou utiliser une adresse IP africaine ne suffit pas davantage à garantir que le trafic restera sur le continent.

Internet repose notamment sur le protocole BGP, par lequel les réseaux annoncent les chemins permettant d’atteindre leurs ressources.

Ces chemins peuvent changer.

Ils dépendent des accords de peering, du transit acheté, des opérateurs présents, des câbles disponibles et des politiques de routage appliquées par chaque réseau.

Le RPKI apporte ici une couche de sécurité importante en permettant notamment de vérifier qu’un réseau est autorisé à annoncer certains préfixes IP.

Nous entrons alors dans une dimension de la souveraineté rarement évoquée dans le débat public :

qui contrôle les routes permettant d’atteindre un service numérique ?

Héberger en Afrique ne signifie pas nécessairement rester en Afrique

Installer des serveurs dans un data center africain est évidemment positif. Cela rapproche le calcul, les données et les applications de leurs utilisateurs. Mais là encore, la localisation physique ne dit pas tout.

Un service hébergé à Casablanca, Dakar ou Abidjan peut utiliser :

• un fournisseur DNS mondial,
• un CDN international,
• une plateforme de protection DDoS externe,
• des API hébergées dans d’autres régions,
• un service d’authentification étranger,
• un cloud dont le plan de contrôle est situé ailleurs,
• ou du transit faisant passer certaines communications par l’Europe.

Il devient donc possible d’avoir un serveur africain et une architecture largement extraterritoriale. Ce n’est pas nécessairement un problème.

Cela devient un problème lorsque personne ne connaît réellement ces dépendances, lorsque leur criticité n’est pas mesurée ou lorsqu’aucune solution alternative n’existe.

IXP et peering : pourquoi le trafic local doit pouvoir rester local

C’est ici que le sujet actuellement discuté à AfPIF prend toute son importance.

Un Internet Exchange Point – IXP permet à plusieurs réseaux de se rencontrer et d’échanger directement du trafic.

Sans interconnexion locale efficace, deux utilisateurs ou deux services géographiquement proches peuvent dépendre de chemins beaucoup plus longs que nécessaire.

Le trafic peut alors sortir du pays, parfois du continent, avant de revenir vers sa destination.

Ce phénomène augmente potentiellement :

• la latence,
• les coûts de transit,
• le nombre d’intermédiaires,
• la dépendance aux liaisons internationales,
• et l’exposition à certaines pannes extérieures.

L’Internet Society documente depuis plusieurs années l’effet du développement des IXP et du peering en Afrique.

Entre 2012 et 2020, par exemple, le Kenya et le Nigeria sont passés d’environ 30 % à 70 % de trafic échangé localement dans les études consacrées à leurs écosystèmes d’interconnexion.

L’enjeu dépasse largement la performance.

Lorsqu’un trafic national peut rester national, une partie de la dépendance à l’infrastructure internationale diminue.

Et lorsqu’un trafic régional africain peut être échangé efficacement à l’intérieur du continent, c’est progressivement une architecture Internet africaine plus dense qui apparaît.

Le Maroc offre d’ailleurs un exemple intéressant avec le développement de CAS-IX à Casablanca, soutenu pour renforcer l’interconnexion locale et attirer davantage de réseaux et de fournisseurs de contenus.

Un IXP n’est donc pas seulement un équipement réseau.

C’est une infrastructure de proximité, mais aussi un outil de résilience économique et numérique.

La réversibilité : peut-on changer de fournisseur sans perdre son service ?

Il existe enfin un critère que je considère comme essentiel : la capacité à sortir d’une dépendance.

Une entreprise peut raisonnablement choisir un fournisseur mondial de cloud, de DNS ou de cybersécurité.

Une institution publique peut faire exactement le même choix. La question n’est pas de refuser ces technologies.

Elle est de savoir ce qui se passerait demain si la relation devait prendre fin.

Peut-on :

• changer rapidement de fournisseur DNS ?
• récupérer l’intégralité de ses configurations ?
• migrer ses données dans un format exploitable ?
• déplacer ses services vers un autre cloud ?
• changer de CDN ou de protection DDoS ?
• modifier ses opérateurs de transit ?
• conserver ses adresses IP lorsque cela est techniquement possible ?
• reconstruire le service sans dépendre du fournisseur précédent ?

Une infrastructure peut être parfaitement fonctionnelle et pourtant extrêmement dépendante.

C’est lorsque l’on tente de la déplacer que cette dépendance apparaît.

La meilleure manière de mesurer une dépendance technologique est parfois très simple : demander combien de temps il faudrait pour en sortir.

Vers une mesure africaine de la souveraineté numérique

C’est probablement sur ce point que le débat africain devrait évoluer.

Plutôt que d’opposer artificiellement infrastructures nationales et fournisseurs étrangers, nous pourrions commencer à mesurer les architectures.

Pour un service numérique critique, sept dimensions me paraissent particulièrement intéressantes :

• Nommage : domaine, registre, registrar et protection de l’identité numérique.
• DNS : opérateurs, DNSSEC, résilience et localisation des dépendances.
• Routage : IP, ASN, BGP, RPKI et diversité des chemins.
• Hébergement : localisation physique, juridiction et contrôle des données.
• Interconnexion : présence dans les IXP, peering local et dépendance au transit international.
• Services critiques : cloud, CDN, sécurité, authentification, messagerie et API.
• Réversibilité : capacité réelle à migrer et à reconstruire le service.

Une telle cartographie donnerait une vision beaucoup plus fidèle de la souveraineté numérique qu’une simple question : « Le serveur est-il situé dans le pays ? »

Elle ferait surtout apparaître les points uniques de dépendance. Et c’est peut-être là que se situe l’enjeu principal.

La souveraineté numérique n’est probablement jamais absolue sur un réseau mondial conçu précisément pour interconnecter des systèmes indépendants.

Elle peut en revanche être comprise, mesurée, organisée et renforcée.

Le domaine est le début de la chaîne, pas sa fin

Je reste convaincu que les noms de domaine et les extensions nationales occupent une place particulière dans cette architecture.

Ils matérialisent l’identité.

Ils constituent le premier point par lequel une organisation est recherchée, reconnue et atteinte. Mais derrière ce nom existe tout un système.

DNS. IP. Routage. Peering. Transit. Hébergement. Cloud. Sécurité. Câbles. Juridictions. Contrats.

La souveraineté numérique africaine se trouve dans l’articulation de ces couches. AfPIF est intéressant précisément pour cette raison.

Pendant quelques jours à Kigali, ce ne sont pas seulement des opérateurs qui discutent de routes Internet ou de capacité réseau.

Ils participent à quelque chose de beaucoup plus stratégique : la construction des chemins par lesquels circulera l’économie numérique africaine.

Pour les gouvernements, régulateurs, banques, entreprises et institutions du continent, comprendre ces chemins devrait progressivement devenir aussi important que de connaître l’emplacement de leurs data centers ou le nom de leur fournisseur cloud.

Car un domaine africain est une identité. Un serveur africain est une infrastructure.

Mais une véritable capacité de souveraineté apparaît lorsque l’on sait qui contrôle chaque maillon, où circulent les données, quelles dépendances existent et comment reprendre la main lorsque cela devient nécessaire.

La souveraineté numérique n’est pas seulement l’endroit où se trouve le serveur. C’est la capacité à savoir par où passe le service, qui peut l’interrompre et comment le reprendre en main.