Souveraineté des données en Afrique et dans le Golfe : le point de vue d'un architecte

Posez la question à un directeur des systèmes d'information à Casablanca, Dakar ou Nairobi : où se trouvent physiquement les données de vos clients ? Souvent, la réponse arrive après un petit silence. Quelque part en Europe, peut-être aux États-Unis, « dans le cloud ». Ce n'est pas un reproche. Pendant des années, la question ne se posait tout simplement pas. Les outils étaient bons, pas chers, faciles à déployer, et personne ne demandait de comptes.

Ça change. Les régulateurs deviennent plus exigeants, les clients aussi, et l'arrivée de l'intelligence artificielle dans les entreprises fait passer le sujet du service juridique au bureau de la direction générale.

Cet article garde ce fil, mais il s'adresse à ceux qui doivent ensuite le traduire en architecture. Un avertissement d'abord : je suis architecte, pas juriste. Ce qui suit n'est pas un avis juridique. Les textes que je cite l'ont été à titre d'exemple, après vérification de leur existence, et leur application à un cas précis demande un avocat qui connaît la juridiction concernée.

De quoi parle-t-on vraiment ?

La souveraineté des données, ce n'est pas du repli sur soi, ni un refus de la technologie étrangère. C'est la capacité, pour une entreprise ou un État, de garder la main sur ses propres informations. En pratique, tout tient en trois questions :

Où ? Dans quel pays et dans quel centre de données vos informations sont-elles stockées et traitées ?
Qui ? Qui peut y accéder, y compris chez vos prestataires et leurs sous-traitants ?
Sous quelle loi ? Quel droit s'applique si un tribunal, une administration ou un gouvernement étranger demande à les consulter ?

Si vous ne pouvez pas répondre clairement à ces trois questions pour vos données les plus sensibles, vous n'en êtes pas vraiment maître. Quelqu'un d'autre l'est, au moins en partie.

Résidence, contrôle, juridiction : trois propriétés distinctes

Le vocabulaire est souvent mélangé, et c'est la première source d'erreurs de conception. Je distingue quatre propriétés, qui ne se déduisent pas les unes des autres.

Résidence : l'emplacement physique des octets, au repos et en traitement. C'est ce que mesure un region = "..." dans une configuration.
Contrôle opérationnel : qui peut agir sur les machines et les services : administrateurs du fournisseur, support, sous-traitants, automatisations.
Contrôle cryptographique : qui détient les clés et peut donc déchiffrer.
Juridiction : quel droit peut contraindre quel acteur à produire quoi.

Héberger dans le pays règle la première. Cela ne règle ni la deuxième (un opérateur étranger peut administrer un centre de données local à distance), ni la troisième (les clés peuvent être chez lui), ni la dernière (la loi qui s'applique à l'entreprise qui exploite le service ne dépend pas de l'adresse du bâtiment).

Les quatre couches de la souveraineté. La résidence n'est que la couche du bas : sans contrôle opérationnel, cryptographique et juridique, elle ne garantit pas grand-chose.

Un cadre juridique qui se met en place

Un nombre croissant de pays africains ont adopté une loi sur la protection des données personnelles. Le Maroc avec la loi 09-08 et la CNDP, le Sénégal, la Tunisie, le Kenya avec son Data Protection Act de 2019, le Nigeria avec le Nigeria Data Protection Act signé en juin 2023 (qui crée la Nigeria Data Protection Commission), l'Afrique du Sud avec POPIA. À l'échelle du continent, la Convention de l'Union africaine sur la cybersécurité et la protection des données à caractère personnel, dite convention de Malabo, adoptée en 2014, est entrée en vigueur le 8 juin 2023, trente jours après le dépôt de la quinzième ratification. Elle reste ratifiée par une minorité des États membres, ce qui limite sa portée pratique pour l'instant.

Le Golfe suit la même tendance, avec des textes récents : le décret-loi fédéral n° 45 de 2021 aux Émirats arabes unis (en vigueur depuis le 2 janvier 2022), et la loi saoudienne de protection des données personnelles (PDPL), dont l'entrée en vigueur a été fixée au 14 septembre 2023 après un amendement, avec ensuite une période de mise en conformité d'un an. Les sources divergent sur certaines dates exactes de publication : pour un dossier réel, il faut aller à la source officielle.

Ces textes ne sont pas identiques, mais ils vont dans la même direction : encadrer les transferts de données hors des frontières, exiger des garanties, donner des droits aux personnes. Je n'entre pas dans le détail de leurs obligations : elles diffèrent selon le texte, le secteur (banque, santé, télécoms) et parfois l'autorité sectorielle, et je préfère ne pas les résumer de mémoire. Ce que l'architecte doit retenir est plus modeste et plus utile : le cadre bouge, il varie selon les pays, donc l'architecture doit pouvoir changer de lieu de traitement sans être réécrite. C'est une exigence d'ingénierie avant d'être une exigence juridique.

Le risque qu'on ne voit pas : dépendre des autres

Au-delà de la conformité, il y a une question plus simple. Que se passe-t-il le jour où votre fournisseur change les règles ?

Un prestataire américain reste soumis au droit américain, même quand ses serveurs sont ailleurs. Le CLOUD Act, signé le 23 mars 2018, modifie le Stored Communications Act : un fournisseur de services de communication électronique ou de stockage à distance relevant de la loi américaine peut être tenu de produire les données qui sont en sa « possession, sa garde ou son contrôle », qu'elles soient situées aux États-Unis ou à l'étranger. Il est né de l'affaire opposant les États-Unis à Microsoft, à propos de serveurs situés à Dublin. Le texte ouvre aussi des voies de contestation limitées, notamment lorsque la demande entre en conflit avec le droit d'un gouvernement étranger « qualifié ». D'autres pays ont des règles comparables. Ce n'est pas une théorie du complot, c'est écrit dans la loi.

La notion de « contrôle » est le point technique qui compte ici. Elle est interprétée largement par les tribunaux américains, et la loi ne la définit pas précisément. Pour un architecte, cela se traduit ainsi : la question n'est pas « où est le disque ? », mais « qui, parmi ceux qui peuvent lire ces octets, est justiciable d'un droit qui peut le contraindre à les produire ? ». Un fournisseur local filiale d'un groupe étranger, ou un opérateur local qui s'appuie sur la plateforme d'un grand fournisseur, peut se retrouver dans ce périmètre selon sa structure : c'est une analyse juridique à faire au cas par cas.

Il y a aussi des risques plus terre à terre : une hausse de tarif brutale, un service qui s'arrête, un compte suspendu, une sanction internationale qui coupe l'accès à une plateforme du jour au lendemain. Si toutes vos données et vos applications vivent chez un seul acteur étranger, votre marge de manœuvre pour négocier, ou pour partir, reste très mince.

Classifier les données et cartographier les flux

Avant tout choix de technologie, deux inventaires. Le premier est la classification : à quel niveau de sensibilité appartient chaque jeu de données. Le second, plus négligé, est la cartographie des flux : qui lit quoi, où, par quel chemin.

Une classification utile tient en quatre ou cinq niveaux, pas en vingt. Chaque niveau doit se traduire en règles vérifiables par la machine, sinon il reste un document que personne n'applique. Voici une forme possible, illustrative :

classes:
  public:
    exemples: [brochures, FAQ]
    localisation: libre
    cles: gerees_par_le_fournisseur
  interne:
    exemples: [wiki, tickets non clients]
    localisation: region_ou_pays
    cles: gerees_par_le_client
  confidentiel:
    exemples: [dossiers clients, contrats]
    localisation: pays
    cles: gerees_par_le_client_hsm_dedie
    journalisation: acces_complet
  restreint:
    exemples: [donnees de sante, secrets bancaires, dossiers d'administration]
    localisation: pays_infrastructure_controlee
    cles: hors_fournisseur
    sortie_hors_pays: interdite_sauf_derogation_ecrite

La cartographie des flux est l'exercice qui fait le plus de surprises. Un schéma d'architecture montre l'application et sa base de données. Il oublie ce qui sort : les journaux envoyés à un SaaS d'observabilité (avec des identifiants clients dedans), les rapports d'erreur contenant des charges utiles, les sauvegardes répliquées dans une autre région par défaut, les e-mails transactionnels, les exports vers un outil d'analyse, les prompts envoyés à une API d'IA. Pour chaque flux, je note la source, la destination, la classe de la donnée, le chemin réseau, qui peut déchiffrer en bout de chemin et sous quel droit se trouve ce destinataire.

Le trajet d'une donnée sensible, avec un point de contrôle à chaque étape. Le point à vérifier en premier est la sortie : c'est là que les fuites silencieuses se produisent.

Une règle pratique : traiter les sorties comme une liste blanche. Tout flux sortant vers un tiers doit être déclaré et rattaché à une classe. Un pare-feu applicatif ou une passerelle de sortie qui refuse par défaut transforme la cartographie en contrôle, pas seulement en document.

Chiffrement : ce qu'il règle, ce qu'il ne règle pas

Le chiffrement au repos et en transit est une base, pas une stratégie de souveraineté. Au repos, il protège contre le vol d'un disque ou d'une sauvegarde. En transit, TLS protège le chemin réseau. Aucun des deux ne protège contre celui qui a légitimement les clés ou les droits d'accès : l'administrateur du fournisseur, un compte applicatif compromis, une réquisition adressée à l'opérateur.

Le schéma courant est le chiffrement par enveloppe : chaque objet est chiffré par une clé de données (DEK), elle-même chiffrée (« enveloppée ») par une clé de chiffrement de clés (KEK) conservée dans un KMS ou un HSM.

écriture : DEK aléatoire -> chiffre l'objet -> KEK enveloppe la DEK
           stockage : objet chiffré + DEK enveloppée
lecture  : appel KMS (unwrap DEK, journalisé) -> déchiffre l'objet

L'intérêt : la KEK ne quitte jamais le KMS ou le HSM, et chaque lecture passe par un appel journalisé et révocable. La question de souveraineté devient : qui contrôle le KMS, et qui peut lui demander de déchiffrer ?

Gestion des clés : quatre modèles

On parle de BYOK, de HYOK, de clés gérées par le client, et le vocabulaire varie d'un fournisseur à l'autre. Je décris les modèles par ce qui compte, la localisation du matériel de clé et de l'opération cryptographique.

Clés gérées par le fournisseur : le fournisseur génère, stocke et utilise les clés. Simple, rien à opérer, et le contrôle cryptographique lui appartient.
Clés gérées par le client dans le KMS du fournisseur (CMK) : vous contrôlez la politique d'accès, la rotation et la révocation, mais le matériel de clé et l'opération vivent dans l'infrastructure du fournisseur.
BYOK (apportez votre clé) : vous générez la clé ailleurs et l'importez. Cela vous donne une copie de référence et la possibilité de la retirer, mais une fois importée, elle est utilisée dans l'infrastructure du fournisseur.
HYOK ou magasin de clés externe : la clé reste dans un HSM ou un gestionnaire de clés que vous exploitez, et chaque opération de chiffrement ou de déchiffrement est déléguée à votre système. La documentation d'AWS KMS décrit ce modèle sous le nom de « external key store » (XKS) : KMS ne parle qu'à un proxy que vous fournissez, et le fournisseur lui-même qualifie cette option de rupture importante avec le modèle de responsabilité partagée, avec une charge opérationnelle supplémentaire, à réserver aux charges de travail qui l'exigent.

Comparaison de trois modèles de gestion des clés selon l'endroit où la clé est utilisée. Plus le contrôle augmente, plus la charge opérationnelle et le risque de panne augmentent aussi.

Les limites réelles

Quelques réalités qu'on omet souvent dans les présentations.

La disponibilité devient votre problème. En HYOK, si votre HSM ou le lien réseau vers lui est indisponible, les données chiffrées sont illisibles. Latence ajoutée à chaque appel, haute disponibilité à concevoir, procédures de reprise à tester.
Le traitement exige souvent le clair. Si le service du fournisseur doit lire la donnée pour l'indexer, l'analyser ou la servir, il la déchiffre en mémoire, quelle que soit la façon dont la clé a été fournie. Les clés externes protègent surtout les données au repos dans des services qui n'ont pas besoin du clair.
Compatibilité inégale. Tous les services d'un fournisseur ne supportent pas tous les modèles de clés ; il faut le vérifier service par service, à la date de la décision.
Une clé retirée n'est pas une garantie juridique. Elle rend les données illisibles pour le fournisseur, mais n'empêche pas une autorité d'exiger de vous-même la clé ou les données en clair, si vous êtes justiciable de ce droit.
Ceux qui détiennent la clé comptent. Les lignes directrices européennes sur les mesures supplémentaires de transfert (recommandations 01/2020 du CEPD) considèrent le chiffrement comme efficace seulement si les clés restent sous le contrôle exclusif de l'exportateur ou d'une entité située dans un territoire jugé adéquat. Ce texte est européen, mais le raisonnement est utile : la protection cryptographique vaut ce que vaut la juridiction de celui qui tient les clés. Je n'ai lu que des commentaires sur ce texte et non son contenu complet : à vérifier directement avant de s'en servir.

Informatique confidentielle : utile, mais pas magique

L'informatique confidentielle vise la donnée « en cours d'utilisation » : le traitement s'exécute dans un environnement d'exécution de confiance (TEE) matériel, attesté. Le Confidential Computing Consortium définit trois propriétés visées : confidentialité des données, intégrité des données et intégrité du code. L'attestation permet à un tiers de vérifier à distance quel code tourne dans l'enclave avant de lui remettre une clé.

Le schéma de souveraineté utile est celui-ci : la clé n'est libérée par votre KMS qu'à une charge de travail dont l'attestation correspond à une mesure attendue. Le fournisseur d'infrastructure ne peut alors pas lire la mémoire de la machine virtuelle.

Les limites, honnêtement :

La racine de confiance reste le fabricant du matériel. Vous remplacez la confiance dans l'opérateur du cloud par la confiance dans le fabricant du processeur et dans son micrologiciel.
Les attaques par canaux auxiliaires existent. Des recherches ont démontré des attaques contre plusieurs implémentations de TEE ; les correctifs passent par du microcode et du logiciel. Ce n'est pas une garantie absolue.
Elle ne dit rien de la juridiction. Un traitement confidentiel chez un opérateur reste dans un périmètre juridique : l'opérateur peut être contraint à d'autres mesures, comme suspendre le service.
Coût d'intégration. L'attestation, le déploiement et l'observabilité demandent un travail réel, et la prise en charge des GPU dans ces environnements, pour l'IA, dépend du matériel et de la plateforme : à vérifier au moment du choix.

Je la recommande comme une couche pour les cas où le fournisseur d'infrastructure fait partie du modèle de menace, pas comme remplaçante du contrôle des clés et de la localisation.

L'IA change l'échelle du problème

Avec l'intelligence artificielle, le sujet prend une autre dimension. Quand un collaborateur colle un contrat, un dossier médical ou un fichier clients dans un assistant IA grand public, ces informations quittent l'entreprise. Selon les conditions d'utilisation, elles peuvent être conservées, analysées, parfois utilisées pour améliorer les modèles. Le plus souvent, personne ne l'a décidé. C'est arrivé, c'est tout.

Sur le plan de l'architecture, un appel à une API d'IA externe est simplement un flux sortant de plus dans la cartographie : il appartient à la même liste blanche que les autres. Une passerelle interne qui journalise, filtre selon la classe de la donnée et route les requêtes sensibles vers un modèle hébergé chez vous est plus efficace qu'une interdiction écrite. J'en détaille l'architecture dans IA souveraine : architecture et le déploiement local dans IA en local.

Il y a un deuxième enjeu, moins visible. Les grands modèles sont surtout entraînés sur des données venues d'Amérique du Nord, d'Europe et d'Asie. Ils connaissent mal la darija, le wolof ou le swahili, et encore moins les réalités administratives et fiscales locales. Si les données africaines servent à entraîner des systèmes conçus ailleurs, la valeur créée part ailleurs elle aussi. Garder la maîtrise de ses données, c'est aussi garder la possibilité de construire des outils qui comprennent vraiment son marché.

Souveraineté ne veut pas dire tout faire soi-même

Soyons honnêtes : aucune entreprise n'a besoin de construire son propre centre de données pour être souveraine. Et toutes les données ne se valent pas. Une plaquette commerciale peut vivre sur n'importe quel service en ligne. Des données de santé, des informations bancaires ou les dossiers d'un ministère, non.

L'approche raisonnable consiste à trier. Les données sensibles restent sur une infrastructure que vous contrôlez, sur site ou dans un cloud privé hébergé dans le pays ou la région. Côté IA, il existe aujourd'hui des modèles ouverts performants qu'on peut installer chez soi, sans envoyer une seule ligne à l'extérieur. Pour le reste, on peut continuer à utiliser les services du marché, en connaissant les règles du jeu.

Arbre de décision simplifié de localisation, du moins au plus sensible. Les seuils réels dépendent de la loi, du secteur et du contrat : ce tableau est un point de départ, pas une règle.

Journalisation et auditabilité

Une promesse de souveraineté sans preuve ne vaut que ce que vaut la confiance. Trois éléments rendent la preuve possible.

Journaux d'accès aux données et aux clés. Chaque appel au KMS (déchiffrement, enveloppement, changement de politique) doit être journalisé hors du périmètre qu'il surveille, avec l'identité de l'appelant et la ressource concernée. Une rafale d'appels de déchiffrement hors des horaires habituels est un signal exploitable.
Immutabilité et séparation. Les journaux sont écrits sur un stockage en ajout seul ou immuable, avec des droits distincts de ceux des administrateurs qu'ils contrôlent.
Journaux de sortie. Les flux sortants vers des tiers (dont les API d'IA) sont journalisés avec la classe de la donnée, jamais avec la donnée elle-même.

Un piège classique : les journaux deviennent eux-mêmes des données sensibles, souvent dans une région ou chez un fournisseur différent. Il faut les classifier comme le reste.

Réversibilité et portabilité

Le critère de souveraineté le plus négligé est la capacité de partir. Se demander comment récupérer ses données et changer de fournisseur doit se faire avant de signer, car après, le coût de sortie est une dépendance en soi.

Quelques vérifications concrètes :

Format. Les données sont-elles exportables dans des formats ouverts (SQL standard, Parquet, formats d'objets documentés), ou seulement dans un format propriétaire ?
Volume et coût de sortie. Combien de temps prend l'export complet, et quels frais de transfert sortant s'appliquent ? Le calcul est simple : volume divisé par la bande passante réelle, plus la durée de validation. À mesurer sur un échantillon, pas à estimer.
Services gérés spécifiques. Plus vous utilisez de services propriétaires (bases, files, fonctions), plus la sortie est une réécriture. L'architecture hexagonale, avec des adaptateurs entre la logique métier et les services, limite la casse.
Les clés. Si vos données sont chiffrées avec des clés du fournisseur, les exporter en clair vous coûte une opération de déchiffrement de masse. Avec des clés que vous détenez, la sortie se fait en un bloc cohérent.
L'exercice réel. Une sortie jamais testée n'existe pas. Je recommande un exercice annuel : restaurer un jeu de données représentatif dans un autre environnement, et chronométrer.

Un modèle de menace réaliste

Pour décider quoi mettre en place, il faut nommer l'adversaire. Les mesures coûteuses (HYOK, HSM dédié, enclaves) n'ont de sens que face à certains adversaires. Je distingue trois familles, sans prétendre à l'exhaustivité.

Trois familles d'adversaires et ce qui y répond. La voie juridique est la moins visible dans les schémas techniques et la plus difficile à corriger par la technique seule.

La plupart des incidents réels viennent plutôt de la deuxième colonne : un compte trop privilégié, un bucket ouvert, une clé d'API dans un dépôt. Un budget souveraineté qui n'en tient pas compte, en finançant seulement la voie juridique, se trompe d'ordre de priorité. Je ne cite pas de statistique ici : je n'en ai pas de vérifiée, et mon propos relève de l'expérience de terrain plutôt que d'un chiffre.

Checklist de décision pour un architecte

Pour chaque jeu de données ou chaque service, dans l'ordre :

Quelle est sa classe, et qui l'a décidée ?
Quels flux sortants existent, et sont-ils tous dans le registre ?
Qui peut lire les octets en clair, et sous quel droit cet acteur se trouve-t-il ?
Où est la clé, qui peut l'utiliser, et que se passe-t-il si elle est révoquée ?
L'accès aux données et aux clés est-il journalisé hors du périmètre surveillé ?
Le modèle de menace justifie-t-il le surcoût (HYOK, enclave, hébergement dédié), ou un CMK suffit-il ?
Combien de temps faut-il pour tout récupérer et repartir ailleurs, et l'a-t-on testé ?
Que dit le droit local et sectoriel, confirmé par quelqu'un qui est qualifié pour le dire ?

Par où commencer

Pas besoin d'un grand programme de transformation pour avancer. Quelques étapes suffisent pour y voir clair :

Faire l'inventaire. Lister les données que vous traitez et repérer celles qui sont vraiment sensibles.
Savoir où elles vont. Pour chaque outil et chaque prestataire, vérifier où les données sont hébergées et quel droit s'applique.
Encadrer l'usage de l'IA. Définir ce que les équipes peuvent partager ou non avec des outils externes, et leur proposer une alternative interne pour les usages sensibles.
Prévoir la sortie. Avant de signer, se demander comment récupérer ses données et changer de fournisseur si besoin.
Former les équipes. La meilleure architecture ne sert à rien si personne ne sait pourquoi elle existe.

Ce qu'il faut retenir

La souveraineté des données est un empilement de propriétés, pas un label d'hébergement. La résidence est la plus facile à obtenir et la moins décisive. Le contrôle des clés et la maîtrise de la juridiction pèsent plus, mais coûtent en exploitation et en disponibilité, et aucune technique ne remplace une analyse juridique sérieuse. Mon conseil pratique est de commencer par la classification et la cartographie des flux : elles ne coûtent presque rien en infrastructure, et elles révèlent en général ce qui mérite vraiment qu'on y investisse. La question ouverte reste celle de l'IA : à mesure que les modèles ouverts progressent, la part des charges de travail qu'on peut garder chez soi augmente, et c'est probablement là que les arbitrages de ces prochaines années se joueront.