L’Afrique veut mutualiser ses GPU : qui contrôlera les identités et les accès de sa future infrastructure IA ?

Smart Africa veut créer un marché fédéré de puissance de calcul pour rendre les GPU accessibles aux institutions, aux entreprises et aux chercheurs africains. L’initiative est stratégique. Mais une infrastructure IA panafricaine ne reposera pas uniquement sur des processeurs : elle dépendra aussi des domaines, du DNS, des API, des certificats, des identités machines et des règles permettant de savoir qui contrôle réellement les accès.

Le 15 juillet 2026, Smart Africa a lancé un appel à manifestation d’intérêt destiné aux opérateurs privés capables de fournir de la puissance de calcul dédiée à l’intelligence artificielle sur le continent.

L’objectif est ambitieux : identifier des fournisseurs, des opérateurs cloud, des centres de données et des consortiums susceptibles de participer à une preuve de valeur, avant un éventuel déploiement à plus grande échelle.

Smart Africa ne propose pas seulement de mettre davantage de GPU à disposition. L’organisation souhaite tester un modèle dans lequel les capacités de plusieurs fournisseurs et juridictions pourraient être regroupées, distribuées et attribuées à la demande.

Une institution située dans un pays africain pourrait ainsi utiliser une infrastructure hébergée dans un autre, à travers une plateforme interopérable et des interfaces communes.

La date limite de dépôt des candidatures est fixée au 12 août 2026 à 17 heures, heure de Kigali. Il ne s’agit pas encore d’une attribution de marché, mais d’une phase de préqualification pouvant conduire à une preuve de valeur, puis à un passage à l’échelle.

Le projet mérite une attention immédiate.

Il peut contribuer à réduire le coût du calcul, faciliter l’accès des startups et des chercheurs aux infrastructures avancées et rapprocher certaines capacités d’IA des utilisateurs africains.

Mais il ouvre aussi une question plus profonde :

Comment construire une infrastructure panafricaine de calcul sans reproduire, au niveau des identités et des accès, les dépendances que l’Afrique cherche précisément à réduire ?

L’Afrique face à la rareté du calcul IA

L’intelligence artificielle est souvent décrite à travers ses modèles, ses applications ou ses performances. En amont se trouve pourtant une ressource physique devenue rare et stratégique : la puissance de calcul.

Les GPU permettent notamment :

• d’entraîner de grands modèles,
• d’adapter des modèles existants à des usages spécifiques,
• d’effectuer des calculs scientifiques intensifs,
• de traiter des images, des vidéos ou des données massives,
• de faire fonctionner des services d’IA à grande échelle.

Or, cette puissance demeure coûteuse, concentrée et inégalement répartie.

Smart Africa constate que les chercheurs, les startups, les institutions publiques et les entreprises africaines utilisent encore fréquemment des capacités hébergées hors du continent. Cette situation soulève des problèmes de coût, de latence, de résilience et de souveraineté des données.

Le GPU devient ainsi davantage qu’un composant informatique.

Il devient une infrastructure de développement économique, de recherche, de défense, de santé, d’éducation et de modernisation de l’action publique.

Un pays qui ne peut pas accéder à une puissance de calcul suffisante dépendra de ceux qui la possèdent. Il devra accepter leurs prix, leurs conditions contractuelles, leurs limitations techniques et parfois leurs règles juridictionnelles.

La mutualisation peut répondre à cette difficulté. Tous les États africains ne pourront pas financer seuls de grands centres de calcul. En revanche, plusieurs capacités nationales ou privées peuvent être réunies dans un ensemble continental.

L’idée est pertinente. Mais elle ne sera souveraine que si l’architecture reste gouvernable.

Le projet de marché fédéré de GPU

Le modèle envisagé par Smart Africa repose sur une fédération de fournisseurs.

Les capacités pourraient provenir :

• de grands opérateurs cloud,
• de centres de données africains,
• de fournisseurs spécialisés dans le GPU à la demande,
• d’acteurs académiques ou de la recherche,
• de consortiums réunissant plusieurs opérateurs.

Une plateforme commune serait chargée de rendre ces ressources accessibles selon différents modèles : paiement à l’usage, abonnement, capacité réservée ou partage de revenus.

Smart Africa demande notamment aux candidats de pouvoir participer à un marché fédéré, de supporter les échanges transfrontaliers et d’adopter des standards ouverts pour l’identité, la portabilité des charges de travail, l’orchestration et la facturation.

L’appel prévoit une progression en quatre étapes :

1. conception et intégration de la preuve de valeur,
2. exécution sur des cas d’usage sélectionnés,
3. évaluation des performances, des coûts, de la sécurité et de la souveraineté,
4. extension à d’autres pays, fournisseurs et usages.

Cette approche permet d’avancer progressivement.

Elle présente néanmoins un point de vigilance : la preuve de valeur devrait reposer principalement sur les contributions des fournisseurs et sur des conditions commerciales négociées, sans engagement de financement initial ou de volume minimal de la part de Smart Africa.

Le risque, par conséquent, est que les premiers choix techniques proposés par les partenaires deviennent progressivement les fondations permanentes du système.

Une architecture provisoire peut rapidement devenir difficile à remplacer lorsqu’elle gère les accès, les comptes, les données, les API et la facturation de plusieurs pays.

Mutualiser la puissance ne signifie pas mutualiser la confiance

Plusieurs centres de données peuvent partager leurs GPU. Mais ils ne partagent pas automatiquement les mêmes règles de sécurité, les mêmes autorités de certification, les mêmes procédures d’identification ou les mêmes obligations juridiques.

La puissance de calcul peut être additionnée.

La confiance, elle, doit être organisée.

Pour accéder à une infrastructure fédérée, chaque utilisateur, institution, serveur et application devra être reconnu. Le système devra pouvoir répondre à des questions simples en apparence :

• Quelle organisation demande la ressource ?
• Quelle machine exécute le traitement ?
• Quel pays est responsable du service ?
• Quel opérateur héberge les données ?
• Quelle autorité a délivré les identifiants ?
• Qui peut suspendre, révoquer ou modifier un accès ?
• Comment vérifier qu’une API appartient bien à l’organisation annoncée ?

Ces éléments forment une infrastructure de confiance.

Elle est moins visible qu’un centre de données, mais elle détermine le fonctionnement réel de l’ensemble.

On peut mutualiser des GPU en quelques contrats. Construire une confiance transfrontalière exige une doctrine, des responsabilités et des identités qui ne puissent pas être déplacées au gré d’un fournisseur.

Domaines, API et certificats : les portes d’entrée invisibles

Une infrastructure IA ne se présente pas uniquement sous la forme de serveurs installés dans un bâtiment.

Pour ses utilisateurs, elle existe à travers des points d’accès :

• un portail institutionnel,
• un nom de domaine,
• des sous-domaines techniques,
• une interface API,
• un système d’authentification,
• des certificats numériques,
• des clés et des identités machines.

Le nom attribué au service n’est pas un simple choix de communication. Il devient une référence technique utilisée pour identifier les interfaces, délivrer les certificats et vérifier l’identité des serveurs.

Les standards de l’IETF décrivent précisément la manière dont une application utilise un nom DNS, une adresse ou un identifiant de service pour vérifier que le certificat présenté appartient bien au serveur attendu. Cette correspondance entre le nom, le service et le certificat participe directement à la protection contre l’interception et l’usurpation.

Dans une infrastructure continentale, il faudra donc définir :

• le ou les domaines officiels du dispositif,
• la politique de création des sous-domaines,
• les opérateurs autorisés à administrer les zones DNS,
• les règles de délégation aux États et aux fournisseurs,
• la protection contre le cybersquatting et les domaines similaires,
• la signature DNSSEC des zones sensibles,
• la délivrance, le renouvellement et la révocation des certificats,
• la gestion des identités machines et des comptes privilégiés.

Une plateforme peut être hébergée en Afrique tout en dépendant d’un domaine administré ailleurs, d’un DNS contrôlé par un prestataire étranger, d’une autorité de certification unique ou d’un fournisseur d’identité impossible à remplacer.

La localisation du serveur ne suffit donc pas à démontrer la souveraineté de l’architecture.

Souveraineté des données et souveraineté des identités

La souveraineté des données est devenue un sujet central. Il faut savoir où elles sont hébergées, qui peut les consulter, sous quelle juridiction elles sont traitées et comment elles peuvent être transférées.

Smart Africa demande aux candidats de respecter les règles nationales de protection et de localisation des données, ainsi que, lorsque cela s’applique, la Convention de Malabo. L’appel mentionne également les réflexions relatives aux ambassades de données et à un modèle régional de cloud souverain.

Mais la souveraineté des données ne peut pas être séparée de celle des identités.

Une donnée peut être stockée localement, tout en restant accessible par une identité créée, contrôlée ou révoquée depuis une infrastructure externe.

Un centre de données peut être situé sur le continent, tandis que :

• le compte administrateur principal dépend d’un fournisseur étranger,
• les certificats sont délivrés par une chaîne de confiance non maîtrisée,
• les journaux d’authentification sont envoyés hors du pays,
• les API reposent sur des domaines appartenant à un partenaire,
• les clés de chiffrement sont conservées dans un autre environnement juridique.

La véritable question ne consiste donc pas seulement à demander : « Où sont les données ? »

Il faut aussi demander :

Qui possède les noms ? Qui attribue les identifiants ? Qui détient les clés ? Qui peut modifier les règles d’accès ? Qui peut révoquer une machine ou suspendre un service ?

Réversibilité, incidents et continuité transfrontalière

Une infrastructure fédérée doit être conçue pour fonctionner lorsque tout va bien, mais surtout lorsque l’un de ses membres rencontre un incident.

Que se passe-t-il si :

• un fournisseur cesse son activité,
• un centre de données devient indisponible,
• une autorité suspend un transfert transfrontalier,
• un certificat critique expire,
• un domaine est compromis,
• un compte administrateur est détourné,
• un partenaire refuse de restituer les configurations ou les journaux ?

La continuité ne peut pas reposer uniquement sur la duplication des GPU.

Elle doit également prévoir la portabilité des identités, des noms, des certificats, des politiques d’accès, des configurations et des traces d’audit.

Chaque composant critique devrait disposer :

• d’un propriétaire clairement identifié,
• d’une juridiction de référence,
• d’un opérateur principal et d’une solution de remplacement,
• d’une procédure de révocation d’urgence,
• d’un mécanisme de reprise,
• d’un plan de sortie du fournisseur.

ICANN considère la sécurité, la stabilité et la résilience du système des identifiants Internet comme une composante de l’infrastructure critique permettant l’accès aux services, au commerce et aux opérations essentielles. Cette logique doit être intégrée dès la conception d’une infrastructure IA continentale.

Une plateforme que l’on ne peut pas déplacer, renommer ou reprendre en main n’est pas véritablement fédérée.

Elle est seulement distribuée.

La proposition NAAM : une gouvernance africaine du nommage pour l’IA

L’initiative de Smart Africa constitue une occasion rare de penser simultanément la puissance de calcul et la confiance numérique.

Le continent ne doit pas attendre le déploiement pour s’intéresser aux domaines, au DNS et aux identités techniques. À ce stade, une architecture de confiance devrait déjà intégrer sept exigences.

1. Un espace de nommage officiel et protégé

Le dispositif doit disposer de domaines clairement identifiés, durablement contrôlés et protégés dans les extensions stratégiques.

Les variantes, fautes typographiques et noms susceptibles d’être exploités pour le phishing doivent également être anticipés.

2. Une gouvernance DNS documentée

Les responsabilités relatives aux zones, aux sous-domaines, aux délégations, aux changements et aux incidents doivent être réparties entre Smart Africa, les États et les opérateurs.

Aucun fournisseur ne devrait pouvoir devenir, par défaut, le propriétaire opérationnel de l’identité continentale du projet.

3. Une identité vérifiable pour chaque service

Chaque portail, API, nœud de calcul et service d’administration doit disposer d’un identifiant stable, authentifiable et rattaché à une organisation responsable.

4. Une gestion souveraine des certificats et des clés

La délivrance, le renouvellement, la révocation et le stockage des clés doivent être audités.

La dépendance à une seule autorité ou à un seul prestataire doit être évitée.

5. Une cartographie des juridictions

Pour chaque ressource, il faut pouvoir connaître le pays d’hébergement, le droit applicable, l’opérateur, le lieu de traitement des données et les conditions de transfert.

6. Une réversibilité testée

Il ne suffit pas d’inscrire la portabilité dans un contrat. Elle doit être démontrée pendant la preuve de valeur.

Un service, une identité ou une charge de travail devrait pouvoir migrer sans perdre son nom, ses droits, ses journaux ou sa chaîne de confiance.

7. Un audit indépendant de la confiance

L’évaluation ne devrait pas mesurer uniquement la disponibilité des GPU, leur performance ou leur coût.

Elle devrait aussi mesurer :

• la résilience DNS,
• la maîtrise des domaines,
• la qualité de la gestion des certificats,
• la sécurité des identités machines,
• la concentration des dépendances,
• la capacité de sortie d’un fournisseur.

La puissance de calcul ne suffit pas à créer une puissance numérique

La création de l’Africa AI Council traduit une volonté de faire de l’Afrique un acteur de l’intelligence artificielle, et non un simple marché de consommation. Son mandat couvre notamment les infrastructures, les données, les marchés, les compétences, les investissements et la gouvernance.

Le projet de mutualisation des GPU constitue l’une des premières traductions concrètes de cette ambition.

Il faut maintenant éviter une erreur classique : considérer la couche de calcul comme l’infrastructure principale et tout le reste comme un sujet secondaire.

Les domaines indiquent où se trouve le service.

Le DNS organise le chemin permettant de l’atteindre.

Les certificats permettent de vérifier son identité.

Les API organisent les échanges entre les systèmes.

Les identités machines déterminent qui peut agir.

Les juridictions définissent les droits et les responsabilités.

Ensemble, ces éléments décident de la confiance réelle que l’on peut accorder à l’infrastructure.

La puissance de calcul est un territoire numérique. Ses frontières ne sont pas seulement dessinées par les centres de données, mais par les noms, les identités, les clés et les règles d’accès qui permettent de l’utiliser.