Infrastructures publiques numériques en Afrique : qui gouverne les domaines, les API et les identités techniques de l’État ?

L’Afrique accélère la construction de ses infrastructures publiques numériques. Mais derrière les plateformes d’identité, de paiement, de santé ou de fiscalité se développe une architecture moins visible : des domaines, des sous-domaines, des API, des certificats et des comptes techniques dont la maîtrise devient une question de souveraineté.

Ce 3 août 2026, une formation internationale consacrée à GovStack débute à Tallinn, en Estonie.

Organisée dans le cadre de l’ITU Academy, elle doit permettre à des responsables publics, spécialistes informatiques et acteurs de la transformation numérique d’apprendre à concevoir des services publics sécurisés, interopérables et centrés sur les citoyens.

Pendant cinq jours, jusqu’au 7 août, les participants travailleront notamment sur l’identité numérique, la sécurité, l’interopérabilité, les services transfrontaliers et l’utilisation de composants modulaires réutilisables.

Cette formation peut paraître technique. Elle révèle pourtant une transformation beaucoup plus profonde.

Les États ne construisent plus seulement des sites administratifs. Ils commencent à édifier de véritables infrastructures publiques numériques sur lesquelles reposeront progressivement l’identité, la fiscalité, les prestations sociales, les paiements, la santé, l’éducation et les échanges de données.

L’enjeu ne consiste donc plus simplement à mettre des formulaires en ligne.

Il s’agit de construire l’architecture numérique de l’État.

L’Afrique entre dans l’ère des infrastructures publiques numériques

Une infrastructure publique numérique, souvent désignée par l’acronyme anglais DPI, est un ensemble de systèmes numériques fondamentaux permettant aux citoyens, aux entreprises et aux administrations d’interagir de manière sécurisée.

Elle repose généralement sur trois grandes familles de composants :

• l’identité numérique,
• les systèmes de paiement,
• les mécanismes d’échange de données.

Ces briques peuvent ensuite être utilisées par plusieurs services : inscription scolaire, accès aux soins, versement d’une aide sociale, création d’entreprise, paiement d’une taxe ou authentification auprès d’une administration.

Le PNUD présente ces infrastructures comme la colonne vertébrale numérique des sociétés modernes. Lorsqu’elles sont bien conçues, elles permettent de dépasser les plateformes administratives isolées pour construire des services interconnectés, réutilisables et accessibles à grande échelle.

Pour l’Afrique, cette approche représente une opportunité considérable.

Elle peut éviter à chaque ministère, agence ou collectivité de reconstruire séparément les mêmes fonctions techniques. Elle peut également réduire les coûts, accélérer le déploiement des services publics et favoriser l’intégration régionale.

Mais la mutualisation crée aussi une nouvelle responsabilité.

Plus un composant est partagé, plus sa gouvernance devient critique.

GovStack et la logique des composants réutilisables

GovStack part d’un principe simple : les administrations ne devraient pas avoir à réinventer l’ensemble de leur architecture numérique pour chaque nouveau service.

L’initiative propose des spécifications et des composants fonctionnels réutilisables — les building blocks — pouvant être combinés pour construire des services publics adaptés aux besoins de chaque pays.

Une même brique d’identité, de notification, de paiement ou de médiation de données peut ainsi être utilisée par plusieurs administrations.

GovStack se veut indépendant des produits. Ses spécifications peuvent être mises en œuvre à partir de solutions ouvertes ou propriétaires, à condition que les composants respectent les exigences d’interopérabilité définies.

Cette logique est puissante.

Elle permet de passer d’un empilement de projets informatiques isolés à une architecture numérique cohérente à l’échelle de l’État.

Mais elle produit mécaniquement une multiplication des dépendances techniques.

Chaque composant doit être nommé. Chaque interface doit être identifiée. Chaque connexion doit être authentifiée. Chaque échange doit être sécurisé.

L’interopérabilité ne supprime donc pas la question de l’identité technique.

Elle la rend plus importante.

Un État peut disposer de logiciels ouverts, de données locales et de services interopérables tout en perdant la maîtrise des noms, des certificats et des accès qui permettent à son architecture de fonctionner.

Chaque composant public possède une identité numérique

Lorsqu’un citoyen accède à un service public, il voit généralement une page, un logo et un formulaire.

Derrière cette interface se trouvent pourtant de nombreuses identités techniques :

• le domaine principal de l’administration,
• les sous-domaines utilisés par les différents services,
• les adresses des interfaces API,
• les certificats numériques permettant d’authentifier les serveurs,
• les comptes techniques utilisés entre applications,
• les zones DNS et leurs serveurs autoritatifs,
• les plateformes cloud et leurs espaces d’administration,
• les adresses de messagerie servant aux notifications,
• les clés, jetons et secrets utilisés pour connecter les composants.

Une plateforme nationale d’identité peut, par exemple, communiquer avec un service fiscal, un système de santé et une solution de paiement.

Chacune de ces connexions repose sur une chaîne d’identifiants techniques.

Le domaine indique où se trouve le service. Le DNS permet de le résoudre. Le certificat permet de vérifier son authenticité. L’API organise les échanges. Le compte technique accorde les autorisations nécessaires.

La confiance du citoyen dépend donc d’une architecture qu’il ne voit pas.

Si l’un de ces éléments est mal administré, expiré, compromis ou abandonné, c’est l’ensemble du service public qui peut être fragilisé.

Domaines, API et certificats : les dépendances invisibles

Les administrations surveillent généralement leurs applications principales. Elles disposent parfois d’un inventaire de leurs serveurs, de leurs logiciels ou de leurs contrats.

Elles disposent beaucoup plus rarement d’une vision centralisée de leurs domaines, sous-domaines, certificats et identités techniques.

Cette absence d’inventaire crée plusieurs risques.

Des sous-domaines oubliés

Un prestataire crée un environnement de test. Le projet prend fin. Le service cloud est supprimé, mais l’enregistrement DNS reste actif.

Le sous-domaine officiel continue alors de pointer vers une ressource qui n’est plus contrôlée par l’administration.

Ce type de configuration peut permettre à un tiers de réutiliser l’adresse abandonnée et de faire apparaître un contenu malveillant sous une identité gouvernementale légitime.

Des certificats dispersés

Lorsque chaque administration commande et renouvelle ses propres certificats, l’État ne sait pas toujours :

• combien de certificats sont actifs,
• quelles autorités de certification sont utilisées,
• qui possède les clés privées,
• quels certificats approchent de leur expiration,
• quels anciens prestataires disposent encore d’un accès.

Une simple expiration peut rendre un service inaccessible. Une clé compromise peut permettre l’usurpation d’une identité officielle.

Des API dont personne ne possède la vue d’ensemble

La multiplication des composants entraîne celle des interfaces de programmation.

Certaines API sont publiques. D’autres sont réservées aux administrations. D’autres encore sont ouvertes temporairement à des partenaires ou à des intégrateurs.

Sans règles communes, chaque organisme choisit ses conventions de nommage, ses mécanismes d’authentification, ses durées de conservation et ses procédures de fermeture.

L’État devient alors interopérable sans être réellement gouvernable.

Le risque d’une gouvernance fragmentée entre administrations

La fragmentation commence souvent de manière innocente.

Un ministère achète un domaine. Une agence crée un sous-domaine. Un intégrateur ouvre un compte cloud. Un prestataire génère un certificat. Une équipe technique déploie une API.

Chacune de ces décisions peut être légitime prise isolément.

Le problème apparaît lorsque personne ne conserve une vue d’ensemble.

Au fil des années, l’État accumule alors :

• des domaines enregistrés au nom de collaborateurs ou de prestataires,
• des comptes administrateurs rattachés à des adresses personnelles,
• des services de test toujours accessibles depuis Internet,
• des certificats dont les responsables ont quitté l’organisation,
• des API sans propriétaire clairement identifié,
• des dépendances envers des fournisseurs impossibles à remplacer rapidement,
• des noms officiels ne respectant aucune doctrine commune.

La souveraineté ne se perd pas nécessairement lors d’une grande décision politique.

Elle peut se dissoudre progressivement dans des milliers de choix techniques non coordonnés.

Comment construire une politique nationale de nommage public

Une infrastructure publique numérique doit être accompagnée d’une véritable politique nationale de gouvernance des identités techniques.

Cette politique devrait reposer sur plusieurs principes.

1. Définir les domaines officiels de l’État

Les citoyens doivent pouvoir reconnaître immédiatement un service public authentique.

L’utilisation cohérente du domaine national, de zones gouvernementales clairement identifiées et de conventions communes pour les sous-domaines contribue à créer cette confiance.

Une administration ne devrait pas choisir son domaine selon la préférence d’un prestataire ou la disponibilité momentanée d’un nom.

Le nommage public doit relever d’une doctrine nationale.

2. Attribuer un responsable à chaque actif

Chaque domaine, sous-domaine, certificat, API et compte technique doit être rattaché à :

• une institution propriétaire,
• un responsable opérationnel,
• une finalité documentée,
• un prestataire éventuel,
• une date de création,
• une procédure de renouvellement ou de fermeture.

Un actif sans responsable identifié est déjà un actif à risque.

3. Organiser tout le cycle de vie

La gouvernance ne doit pas s’arrêter au moment du déploiement.

Elle doit encadrer la création, la modification, la surveillance, le renouvellement, le transfert et la suppression de chaque identité technique.

La fermeture d’un projet doit notamment entraîner la révocation des accès, la suppression des certificats inutiles et le nettoyage des enregistrements DNS.

4. Sécuriser l’infrastructure DNS

La sécurité du DNS doit inclure la séparation des rôles, la protection des comptes, la journalisation, la redondance des serveurs, la surveillance des zones et, lorsque cela est pertinent, le déploiement de DNSSEC.

L’initiative KINDNS de l’ICANN fournit justement un cadre de bonnes pratiques destiné aux opérateurs de serveurs DNS autoritatifs et de résolveurs récursifs.

5. Intégrer la réversibilité dans les marchés publics

Un prestataire ne devrait jamais être le seul à connaître l’architecture de nommage d’un service public.

Les contrats doivent préciser :

• qui détient les comptes,
• qui contrôle les domaines,
• où sont conservées les clés,
• comment les données et configurations peuvent être exportées,
• comment les accès seront restitués,
• comment le service pourra être transféré vers un autre opérateur.

L’ouverture du code ne suffit pas lorsque les identités techniques restent prisonnières du fournisseur.

La proposition NAAM : un registre central des identités techniques de l’État

Chaque État devrait disposer d’un référentiel national des identités techniques publiques.

Il ne s’agirait pas de centraliser toutes les opérations dans une seule administration, mais de créer une source d’information commune et constamment actualisée.

Ce référentiel pourrait recenser :

• les domaines et sous-domaines officiels,
• les bureaux d’enregistrement et titulaires administratifs,
• les zones DNS et fournisseurs utilisés,
• les certificats numériques et leurs dates d’expiration,
• les API publiques et privées,
• les comptes de service et leurs propriétaires,
• les environnements cloud associés,
• les prestataires disposant d’un accès,
• les dépendances critiques,
• les procédures d’urgence et de récupération.

Des niveaux de criticité pourraient être attribués à chaque actif.

Une API de consultation publique ne présente pas le même risque qu’un composant permettant d’accéder au registre national d’identité. Un domaine d’information institutionnelle n’a pas les mêmes exigences qu’une plateforme de paiement ou de santé.

Cette cartographie permettrait donc de concentrer les contrôles sur les services dont l’indisponibilité, l’usurpation ou la compromission pourrait affecter directement la population.

L’ouverture n’a de valeur que si elle reste gouvernable

La stratégie de transformation numérique de l’Union africaine place les infrastructures, l’identité numérique, l’interopérabilité, la cybersécurité et la gouvernance parmi les fondations du développement numérique du continent. Des initiatives plus récentes insistent également sur la nécessité de construire des infrastructures interopérables, fiables et souveraines.

GovStack peut aider les États africains à accélérer.

Les composants réutilisables peuvent réduire les coûts. Les standards ouverts peuvent limiter certaines dépendances. Les architectures modulaires peuvent rendre les services publics plus efficaces.

Mais aucune spécification technique ne remplacera une responsabilité institutionnelle.

Un État peut ouvrir son code tout en perdant ses domaines.

Il peut héberger ses données localement tout en dépendant d’un certificat contrôlé ailleurs.

Il peut disposer d’une architecture interopérable tout en ignorant le nombre exact d’API, de sous-domaines ou de comptes techniques qui la composent.

La souveraineté numérique ne réside donc pas seulement dans le lieu où se trouvent les serveurs.

Elle réside dans la capacité à identifier, attribuer, surveiller, sécuriser, transférer et fermer chaque composant de l’architecture publique.

Les infrastructures publiques numériques seront les nouvelles routes de l’État. Les domaines, les API et les certificats en seront les panneaux, les carrefours et les clés d’accès. On ne peut pas gouverner une infrastructure dont on ne maîtrise pas l’identité.