[{"data":1,"prerenderedAt":1789},["ShallowReactive",2],{"article-fr-\u002Fkubernetes\u002Fsovereign-govcloud-reference-architecture":3,"article-sibling-fr-\u002Fkubernetes\u002Fsovereign-govcloud-reference-architecture":918,"surround-fr-\u002Fkubernetes\u002Fsovereign-govcloud-reference-architecture":1752,"related-fr-\u002Fkubernetes\u002Fsovereign-govcloud-reference-architecture":1757},{"id":4,"title":5,"body":6,"date":894,"description":895,"draft":896,"extension":897,"img":898,"meta":899,"navigation":900,"path":901,"seo":902,"slug":903,"stem":904,"tags":905,"topics":911,"__hash__":917},"content\u002Fkubernetes\u002F3.sovereign-govcloud-reference-architecture.fr.md","Architecture de référence pour un cloud gouvernemental souverain",{"type":7,"value":8,"toc":877},"minimark",[9,24,27,30,33,38,41,234,237,241,244,247,250,253,256,260,263,266,269,272,275,278,281,285,288,390,393,400,406,412,418,424,427,431,434,437,440,443,446,449,452,455,458,461,465,468,471,474,477,480,483,486,489,493,496,499,502,505,508,511,515,518,521,524,527,530,533,536,539,543,546,549,552,555,558,561,564,567,571,574,577,580,583,586,589,592,596,599,772,775,778,782,785,788,791,794,798,874],[10,11,12,13,18,19,23],"p",{},"Deux articles ont préparé celui-ci. Le premier a cartographié ",[14,15,17],"a",{"href":16},"\u002Fblog\u002Fkubernetes\u002Fdecret-2018-062-kubernetes-gap","le décalage entre le Décret 2018-062 et le modèle mental de Kubernetes"," : un droit qui raisonne en entités stables et localisables, une plateforme qui dissout ces points d'ancrage, et quatre gaps réels qui en résultent. Le second a défendu que ",[14,20,22],{"href":21},"\u002Fblog\u002Fkubernetes\u002Fmulti-cloud-illusion","le multi-cloud ne répond pas à une question de juridiction"," et qu'il multiplie l'exposition au lieu de la diviser. Ces deux textes sont critiques par construction : ils disent ce qui casse et ce qui ne répare pas. Ils laissent ouverte la seule question qui intéresse vraiment une administration : alors on construit quoi.",[10,25,26],{},"Cet article y répond sous la forme d'une architecture de référence. Pas un tutoriel de déploiement, pas un retour d'expérience nommé, pas une liste de produits. Un document d'architecture au sens strict : un cahier des charges dérivé des textes applicables, une série de choix de conception justifiés par ces exigences, un modèle opérationnel qui dit ce qu'il faut d'équipe et de budget pour tenir l'ensemble, et surtout une exposition des limites, parce qu'une architecture de référence qui ne dit pas quand elle est inadaptée n'est pas une architecture de référence, c'est une plaquette commerciale.",[10,28,29],{},"La thèse tient en une phrase. La souveraineté n'est pas une clause contractuelle que l'on obtient d'un fournisseur, c'est une propriété d'architecture que l'on construit et que l'on doit pouvoir prouver. Le reste de cet article consiste à rendre cette phrase opérationnelle.",[10,31,32],{},"Une précision de méthode avant d'entrer dans le sujet. Cet article est écrit en mode architecture de référence pure. Les choix qui suivent sont informés par une pratique de terrain en exploitation de plateformes régulées, mais aucune organisation n'est nommée, aucune mesure attribuable n'est citée, aucune topologie identifiable n'est décrite. Les enseignements de terrain sont formulés au niveau du secteur, jamais au niveau d'un déploiement particulier.",[34,35,37],"h2",{"id":36},"le-cahier-des-charges-dérivé-du-texte","Le cahier des charges dérivé du texte",[10,39,40],{},"L'erreur classique consiste à concevoir la plateforme puis à chercher, après coup, comment la rendre conforme. Cette section fait l'inverse : elle transforme les obligations juridiques en exigences non fonctionnelles numérotées, chacune assortie d'un critère de vérification. C'est ce jeu d'exigences, et non une préférence d'outillage, qui justifie tous les choix des sections suivantes.",[42,43,44,63],"table",{},[45,46,47],"thead",{},[48,49,50,54,57,60],"tr",{},[51,52,53],"th",{},"Réf",[51,55,56],{},"Exigence",[51,58,59],{},"Source",[51,61,62],{},"Critère de vérification",[64,65,66,81,95,109,123,137,151,165,178,192,206,220],"tbody",{},[48,67,68,72,75,78],{},[69,70,71],"td",{},"EX-1",[69,73,74],{},"L'exploitant de la plateforme est une entité juridique établie sur le territoire national, identifiable et sanctionnable par le régulateur",[69,76,77],{},"Décret 2018-062 art. 58",[69,79,80],{},"Immatriculation, contrat d'exploitation, désignation nominative du responsable",[48,82,83,86,89,92],{},[69,84,85],{},"EX-2",[69,87,88],{},"Tout volume persistant et tout stockage éphémère susceptible de traiter des données à caractère personnel a une localisation physique connue et documentée ; tout franchissement de frontière est déclaré",[69,90,91],{},"Loi 2019-014 art. 28",[69,93,94],{},"Registre des traitements croisé avec l'inventaire des StorageClass et de leur ancrage matériel",[48,96,97,100,103,106],{},[69,98,99],{},"EX-3",[69,101,102],{},"Les journaux permettant d'identifier les accès sont conservés au moins douze mois",[69,104,105],{},"Décret art. 41, Arrêté 2022-040 D1.1.1",[69,107,108],{},"Échantillonnage réussi d'un journal à J moins 360",[48,110,111,114,117,120],{},[69,112,113],{},"EX-4",[69,115,116],{},"Chaque accès à une donnée à caractère personnel est rattachable à une identité humaine réelle, pas seulement à une identité technique de service",[69,118,119],{},"Décret art. 41 et 69",[69,121,122],{},"Reconstitution d'une chaîne d'accès complète depuis un identifiant d'agent jusqu'à l'enregistrement lu",[48,124,125,128,131,134],{},[69,126,127],{},"EX-5",[69,129,130],{},"Les enregistrements d'audit sont protégés contre toute modification, et toute tentative est détectable",[69,132,133],{},"Décret art. 69",[69,135,136],{},"Test documenté de tentative de modification sur le stockage de preuve",[48,138,139,142,145,148],{},[69,140,141],{},"EX-6",[69,143,144],{},"Les mesures de sécurité sont proportionnées au risque : moindre privilège, isolation réseau en refus par défaut, contrôle d'admission",[69,146,147],{},"Décret art. 52",[69,149,150],{},"Revue des rôles RBAC, des NetworkPolicy et des politiques d'admission",[48,152,153,156,159,162],{},[69,154,155],{},"EX-7",[69,157,158],{},"Les données sont chiffrées en transit, et au repos sur etcd, sur les Secrets et sur les volumes persistants",[69,160,161],{},"Décret art. 44 et 52, Arrêté G3.1.5",[69,163,164],{},"Inspection d'une sauvegarde brute d'etcd et d'un volume détaché",[48,166,167,170,173,175],{},[69,168,169],{},"EX-8",[69,171,172],{},"Tout incident de sécurité est notifié à l'organe de contrôle dans les vingt-quatre heures",[69,174,147],{},[69,176,177],{},"Runbook daté, horodatage de détection, exercice de notification",[48,179,180,183,186,189],{},[69,181,182],{},"EX-9",[69,184,185],{},"Des objectifs de continuité sont définis et vérifiés, et un plan d'arrêt d'activité existe",[69,187,188],{},"Décret art. 58, Arrêté R1",[69,190,191],{},"Test de restauration daté avec RTO et RPO mesurés, pas déclarés",[48,193,194,197,200,203],{},[69,195,196],{},"EX-10",[69,198,199],{},"Les données peuvent être restituées, transférées à un tiers ou détruites définitivement sur demande",[69,201,202],{},"Décret art. 71",[69,204,205],{},"Exercice d'export et de destruction avec preuve",[48,207,208,211,214,217],{},[69,209,210],{},"EX-11",[69,212,213],{},"Tout tiers qui accède à la donnée est lié par un contrat écrit et agit sur la seule instruction du responsable de traitement",[69,215,216],{},"Loi 2019-014 art. 20",[69,218,219],{},"Registre de la sous-traitance, contrats à jour",[48,221,222,225,228,231],{},[69,223,224],{},"EX-12",[69,226,227],{},"Chaque contrôleur autonome capable d'agir sur des données a un responsable nommé et un périmètre d'action documenté",[69,229,230],{},"Décret art. 47, gap identifié dans l'article 1",[69,232,233],{},"Inventaire des Operators avec leurs droits RBAC et leur propriétaire",[10,235,236],{},"Trois de ces exigences méritent d'être signalées d'emblée, parce que ce sont elles qui font basculer la décision d'architecture. EX-2, EX-4 et EX-12 sont précisément les trois que l'article 1 a identifiées comme des gaps structurels de Kubernetes, et ce sont aussi celles qu'un cluster managé chez un fournisseur étranger rend les plus difficiles à satisfaire : la géographie du stockage y est une propriété du service et non un choix documentable, l'identité s'arrête au ServiceAccount, et le périmètre d'action des contrôleurs du fournisseur n'est ni inventoriable ni négociable. Une architecture souveraine se juge d'abord sur ces trois lignes. Les autres, un bon opérateur les satisfait à peu près partout.",[34,238,240],{"id":239},"périmètre-et-hypothèses","Périmètre et hypothèses",[10,242,243],{},"Une architecture de référence sans périmètre déclaré est incritiquable, donc inutile. Voici ce que celle-ci vise et ce qu'elle exclut.",[10,245,246],{},"Les charges visées sont celles d'une administration : portails de services aux citoyens, registres administratifs (état civil, foncier, fiscalité, immatriculation), back-offices d'agences, API d'interopérabilité entre administrations, gestion électronique de documents, applications métier internes. L'ordre de grandeur retenu est de quelques dizaines à quelques centaines de services applicatifs, avec un trafic majoritairement diurne, national, et des pics largement prévisibles : échéances fiscales, campagnes d'inscription scolaire, périodes électorales, distribution d'aides. Cette prévisibilité est une propriété importante, on y revient dans la comparaison finale, parce qu'elle change complètement la valeur de l'élasticité.",[10,248,249],{},"Sont hors périmètre : le calcul haute performance, l'entraînement de modèles à grande échelle, le coeur de réseau d'un opérateur télécom, les systèmes temps réel critiques du soin ou de la défense. Ces domaines ont des contraintes et des cadres qui leur sont propres, et prétendre qu'une même architecture les couvre serait malhonnête.",[10,251,252],{},"Trois hypothèses conditionnent tout le reste, et si l'une tombe l'architecture doit être révisée. Premièrement, l'existence d'au moins deux salles machines distinctes, avec une liaison entre elles ; une salle unique interdit toute continuité sérieuse et le dire tôt évite de vendre une promesse que la topologie ne tient pas. Deuxièmement, la possibilité d'un investissement initial en matériel, ce qui n'est pas acquis dans un cadre budgétaire annualisé où le fonctionnement est plus facile à obtenir que l'investissement. Troisièmement, l'existence d'une équipe pérenne, et non d'un projet doté d'un prestataire pendant dix-huit mois puis livré à lui-même.",[10,254,255],{},"Un dernier élément de contexte régional pèse sur les choix : le transit international est coûteux et parfois instable, tandis que la latence vers une région lointaine dégrade l'expérience de services qui, eux, sont entièrement nationaux. L'hébergement local a donc une justification technique indépendante de la justification juridique, et cela vaut la peine de le noter, parce qu'un argument de souveraineté qui s'appuie aussi sur la performance est plus difficile à balayer qu'un argument purement réglementaire.",[34,257,259],{"id":258},"choix-fondamental-bare-metal-virtualisation-ou-les-deux","Choix fondamental : bare-metal, virtualisation, ou les deux",[10,261,262],{},"C'est la décision qui contraint toutes les suivantes, et elle se prend sur des critères de conformité autant que de performance.",[10,264,265],{},"Trois options sérieuses existent. Le bare-metal pur place Kubernetes directement sur les serveurs physiques : densité maximale, performance maximale, un seul plan de gestion à opérer, mais l'isolation entre charges repose entièrement sur les mécanismes de Kubernetes. La virtualisation complète installe un hyperviseur puis des clusters Kubernetes dans des machines virtuelles : deux plans de gestion, une perte de densité de l'ordre de quelques pour cent en calcul et davantage en mémoire, mais une frontière d'isolation matérielle et la capacité d'héberger à côté les systèmes hérités qui ne seront jamais conteneurisés. La troisième option, un Kubernetes managé chez un opérateur local, est traitée dans la comparaison finale ; elle change le modèle de responsabilité plus que l'architecture technique.",[10,267,268],{},"Le critère qui tranche n'est pas la performance, il est dans EX-6 lu avec l'oeil d'un auditeur. Dans un cluster mutualisé, l'isolation entre agences repose sur les namespaces, le RBAC et les NetworkPolicy. Ce sont des frontières logiques, appliquées par un noyau partagé et par un plan de contrôle partagé. Tant que les agences hébergées ont des exigences comparables, cette frontière est acceptable et défendable. Dès que deux agences ont des classifications différentes, ou que l'une traite des données dont la compromission engage la responsabilité de l'autre, la question posée en audit devient : qu'est-ce qui empêche matériellement une charge de l'agence A d'atteindre les données de l'agence B en cas d'évasion de conteneur. Répondre « le RBAC » n'est pas une réponse à cette question.",[10,270,271],{},"La recommandation de référence est donc mixte, et assumée comme un compromis. Une couche de virtualisation légère fondée sur KVM, exploitée par exemple avec Proxmox VE ou une distribution équivalente, sert de socle. Sur ce socle, un cluster Kubernetes mutualisé accueille la grande majorité des charges, en bare-metal du point de vue applicatif puisque les noeuds sont des machines virtuelles dédiées et non partagées avec autre chose. Les charges dont la classification l'exige reçoivent leur propre cluster, sur des hôtes physiquement séparés. Les systèmes hérités qui ne seront jamais conteneurisés vivent en machines virtuelles sur le même socle, ce qui évite d'avoir à maintenir deux infrastructures parallèles.",[10,273,274],{},"Ce choix coûte trois choses qu'il faut nommer. Une perte de densité et donc de matériel supplémentaire. Un second plan de gestion à exploiter, à sauvegarder et à mettre à jour, avec les compétences correspondantes. Et une complexité de diagnostic accrue, parce qu'un problème de performance peut désormais venir de deux couches au lieu d'une.",[10,276,277],{},"Une note sur le choix de l'hyperviseur, qui touche directement au sujet de l'article. La souveraineté d'une plateforme se juge aussi sur ses dépendances de licence. Le passage de VMware sous le contrôle de Broadcom, et la refonte du modèle de licence qui a suivi, ont rappelé qu'une couche d'infrastructure sous licence propriétaire est un levier détenu par un tiers étranger, indépendamment de l'emplacement des serveurs. Un État qui construit une plateforme souveraine sur un hyperviseur dont le tarif et les conditions peuvent être redéfinis unilatéralement depuis une autre juridiction reproduit à la couche basse exactement la dépendance qu'il cherchait à éviter à la couche haute. C'est un argument pour KVM et son écosystème ouvert, pas un argument de qualité technique comparée.",[10,279,280],{},"Deux mécanismes intermédiaires méritent d'être connus sans être recommandés par défaut. Les bacs à sable de conteneurs comme gVisor ou Kata Containers offrent une isolation renforcée sans le coût complet d'une machine virtuelle par charge. Ils ont un coût de performance réel et une charge d'exploitation non nulle, et ils compliquent le diagnostic. Ils sont pertinents pour un sous-ensemble de charges à risque au sein d'un cluster mutualisé, pas comme socle général.",[34,282,284],{"id":283},"la-couche-dorchestration","La couche d'orchestration",[10,286,287],{},"Les composants qui suivent forment la pile de référence. Chacun est justifié par une exigence, et chacun est présenté avec l'alternative sérieuse qui a été écartée et la raison de l'écarter. Une pile qui ne montre pas ses alternatives n'est pas justifiée, elle est décrite.",[42,289,290,306],{},[45,291,292],{},[48,293,294,297,300,303],{},[51,295,296],{},"Composant",[51,298,299],{},"Exigence servie",[51,301,302],{},"Alternative sérieuse",[51,304,305],{},"Pourquoi ce choix",[64,307,308,322,335,348,362,376],{},[48,309,310,313,316,319],{},[69,311,312],{},"Kubespray",[69,314,315],{},"EX-1, EX-9",[69,317,318],{},"RKE2, Talos Linux, kubeadm nu",[69,320,321],{},"Installation par Ansible avec inventaire versionné, exécution possible entièrement hors ligne depuis un registre local, aucun plan de contrôle exploité par un tiers",[48,323,324,327,329,332],{},[69,325,326],{},"Calico",[69,328,141],{},[69,330,331],{},"Cilium, Antrea",[69,333,334],{},"NetworkPolicy mature, exigences noyau modestes, exploitation bien documentée par des équipes de taille réduite",[48,336,337,340,342,345],{},[69,338,339],{},"MetalLB",[69,341,71],{},[69,343,344],{},"HAProxy en amont, keepalived",[69,346,347],{},"Fournit le type Service LoadBalancer sans dépendre d'un équilibreur de charge de fournisseur cloud",[48,349,350,353,356,359],{},[69,351,352],{},"cert-manager avec PKI interne",[69,354,355],{},"EX-7, EX-4",[69,357,358],{},"ACME public seul, gestion manuelle",[69,360,361],{},"Automatise l'émission tout en gardant la racine de confiance interne sous contrôle national",[48,363,364,367,370,373],{},[69,365,366],{},"Traefik",[69,368,369],{},"EX-6, EX-7",[69,371,372],{},"ingress-nginx, HAProxy, Envoy Gateway",[69,374,375],{},"Terminaison TLS et routage, intégration directe avec cert-manager, configuration déclarative",[48,377,378,381,384,387],{},[69,379,380],{},"Argo CD",[69,382,383],{},"EX-3, EX-12",[69,385,386],{},"Flux, pipelines CI poussant vers le cluster",[69,388,389],{},"Fait du dépôt Git l'état de référence, donc chaque changement devient une preuve horodatée et attribuable",[10,391,392],{},"Ces choix demandent des commentaires, parce que plusieurs sont des compromis et non des évidences.",[10,394,395,399],{},[396,397,398],"strong",{},"Sur l'installateur."," Kubespray est lourd, lent, et son inventaire Ansible devient vite un artefact qu'il faut soi-même maintenir. Ses deux qualités décisives dans ce contexte sont l'installation hors ligne, indispensable quand le transit international est cher ou coupé, et l'absence totale de dépendance à un service tiers pendant le cycle de vie du cluster. Les distributions plus récentes, RKE2 et surtout Talos Linux, réduisent significativement la surface d'attaque : Talos supprime le shell et le gestionnaire de paquets de l'hôte et pilote tout par API, ce qui sert directement EX-5 et EX-6. Une équipe qui n'a pas déjà de culture Ansible aura probablement plus de résultat avec RKE2 ou Talos qu'avec Kubespray. Le critère de décision est la compétence disponible, pas la supériorité intrinsèque.",[10,401,402,405],{},[396,403,404],{},"Sur le CNI."," Calico est ici le choix de la sobriété. Cilium, fondé sur eBPF, offre des politiques plus riches, une visibilité de niveau applicatif et, avec Hubble, une observabilité des flux qui contribuerait réellement à EX-3. C'est objectivement le meilleur outil pour l'audit réseau. Il demande aussi des noyaux récents, une compréhension d'eBPF pour diagnostiquer les cas tordus, et il déplace une partie du comportement réseau dans une couche que peu d'équipes savent inspecter. Recommander Calico ici est un choix d'exploitabilité assumé, pas un jugement de valeur : dans une équipe qui maîtrise eBPF, Cilium est le meilleur choix.",[10,407,408,411],{},[396,409,410],{},"Sur l'équilibrage de charge."," MetalLB en mode BGP est nettement supérieur au mode couche 2, qui concentre tout le trafic d'un service sur un seul noeud. Mais le mode BGP suppose une coopération avec l'équipe réseau, une session d'appairage sur les routeurs, et une compréhension partagée du plan d'adressage. Dans une administration, c'est presque toujours là que le projet se bloque, et le blocage est organisationnel et non technique. Anticiper cette discussion dès la conception fait gagner des mois.",[10,413,414,417],{},[396,415,416],{},"Sur la PKI, qui est le point le plus sous-estimé."," Il faut séparer deux plans de confiance que l'on confond couramment. Les services exposés au public ont besoin de certificats reconnus par des navigateurs que l'État ne contrôle pas : ACME et une autorité publique restent le choix rationnel, la contrainte étant subie et non choisie. Le trafic interne est une autre affaire. Le mTLS entre services, les certificats des composants du cluster, l'authentification des noeuds et des agents reposent sur une racine de confiance. Si cette racine est une autorité étrangère, alors l'authentification interne d'une plateforme souveraine dépend d'un tiers hors juridiction, avec sa politique de révocation, ses conditions d'utilisation et sa disponibilité. Une racine interne détenue par l'État, conservée hors ligne, avec des autorités intermédiaires émettant via cert-manager, résout cela proprement. C'est peu coûteux à mettre en place et rarement fait, et c'est un des rares endroits où la souveraineté se gagne réellement plutôt que de se déclarer.",[10,419,420,423],{},[396,421,422],{},"Sur GitOps comme mécanisme de preuve."," Argo CD n'est pas retenu ici pour le confort de déploiement mais pour sa valeur probante. Quand le dépôt Git est l'état de référence, chaque modification de la plateforme devient un commit signé, revu, horodaté, attribué à une personne nommée. Répondre à un auditeur qui demande qui a modifié la politique réseau de tel service et quand ne consiste plus à fouiller des journaux bruts, mais à montrer un historique conçu pour être lu. Cela sert EX-3 et contribue à EX-12.",[10,425,426],{},"Deux conditions rendent cette valeur probante réelle, et sans elles l'argument s'effondre. D'abord, l'accès direct en écriture au cluster doit être verrouillé : si les équipes peuvent encore appliquer des manifestes à la main, l'historique Git décrit un cluster imaginaire. Ensuite, le dépôt Git devient lui-même un actif réglementé, soumis aux mêmes exigences de rétention, d'intégrité et de contrôle d'accès que les journaux, ce qui implique de l'héberger sur la plateforme souveraine et non chez un hébergeur de code étranger. Une plateforme souveraine dont l'état de référence vit dans un dépôt sous juridiction étrangère a déplacé le problème sans le résoudre.",[34,428,430],{"id":429},"le-stockage","Le stockage",[10,432,433],{},"Le stockage est l'endroit où l'exigence EX-2 se gagne ou se perd, et c'est aussi celui où les équipes se surestiment le plus souvent.",[10,435,436],{},"Le principe directeur est simple : choisir la solution la plus simple qui satisfait les objectifs de continuité, et non la plus capable. La recommandation se fait par palier, parce qu'il n'y a pas de bonne réponse unique.",[10,438,439],{},"Pour un volume utile modeste, une salle principale et une équipe restreinte, une baie de stockage exposée en NFS ou en iSCSI, complétée par du stockage local pour les charges qui n'ont pas besoin de réplication, est un choix défendable. Il est compris par tout le monde, restaurable par tout le monde, et son échec est diagnosticable un dimanche à trois heures du matin.",[10,441,442],{},"Pour un volume intermédiaire, Longhorn apporte la réplication au niveau bloc entre noeuds, les instantanés, et la sauvegarde vers une cible objet, avec un coût d'exploitation nettement inférieur à celui d'un système distribué complet. Sa limite est réelle sur les charges très exigeantes en entrées-sorties, en particulier les bases de données actives.",[10,444,445],{},"Pour un volume important, plusieurs salles, ou un besoin de stockage objet en plus du bloc, Ceph est la réponse technique correcte : bloc avec RBD, objet avec RGW, système de fichiers avec CephFS, le tout dans un seul système répliqué. Il faut cependant être direct sur ce que cela implique. Ceph demande une compétence dédiée et permanente, pas une montée en compétence ponctuelle. Un Ceph mal dimensionné ou mal exploité est un mode de défaillance majeur, capable d'immobiliser l'ensemble de la plateforme, et sa remise en état demande une expertise que l'on ne trouve pas dans l'urgence. La règle pratique est qu'un Longhorn compris vaut mieux qu'un Ceph subi.",[10,447,448],{},"Sur le plan de la conformité, ce que ce choix apporte est décisif. Dans un cluster managé, une StorageClass est un nom qui masque un service régional dont la géographie de réplication n'est ni visible ni négociable. Ici, chaque StorageClass correspond à un ensemble de disques dont on connaît le châssis, la salle et l'adresse. EX-2 cesse d'être une déclaration de bonne foi pour devenir un inventaire vérifiable, et c'est exactement le premier gap identifié dans l'article 1 qui se referme.",[10,450,451],{},"Le chiffrement au repos (EX-7) se traite à deux niveaux qui ne se remplacent pas. Le chiffrement des disques sous-jacents, par LUKS sur les périphériques ou par le mécanisme natif du système de stockage, protège contre le vol de matériel et la mise au rebut mal gérée. Il ne protège pas contre un accès logique légitime au système en fonctionnement. Pour les données les plus sensibles, un chiffrement applicatif, dont les clés ne sont jamais détenues par la couche d'infrastructure, est la seule mesure qui résiste à un administrateur de la plateforme. Il faut décider explicitement quelles catégories de données méritent ce second niveau, plutôt que de chiffrer les disques et considérer la question close.",[10,453,454],{},"La sauvegarde combine trois choses distinctes qui sont souvent confondues : les instantanés de volume, qui protègent contre l'erreur applicative et vivent dans le même système de stockage ; la sauvegarde des objets Kubernetes et des volumes, par exemple avec Velero, vers une cible objet locale ; et la copie hors site, dans la seconde salle, qui est la seule qui protège contre la perte du site principal. Le verrouillage d'objet sur la cible de sauvegarde satisfait EX-5 en rendant les sauvegardes immuables pendant leur durée de rétention, ce qui est aussi la mesure la plus efficace contre un rançongiciel qui chercherait à détruire les sauvegardes avant de chiffrer la production.",[10,456,457],{},"Un point mérite d'être énoncé sans détour : une sauvegarde jamais restaurée n'est pas une sauvegarde, et EX-9 exige un RTO et un RPO mesurés, pas déclarés. Un exercice de restauration complète, planifié, chronométré et documenté, au moins deux fois par an, est la seule preuve recevable. C'est aussi le premier élément que la pression opérationnelle fait sauter.",[10,459,460],{},"Les bases de données méritent une décision explicite. Les opérer dans le cluster avec un Operator mature comme CloudNativePG apporte une automatisation réelle du basculement, des sauvegardes continues et de la restauration à un instant donné. Cela place aussi un contrôleur autonome sur le chemin critique de données personnelles, ce qui est exactement le gap d'imputabilité décrit dans l'article 1. La réponse n'est pas d'y renoncer, elle est de le documenter au titre d'EX-12 : quel Operator, quelles permissions, quelles actions destructrices possibles, quelle équipe responsable, quels garde-fous sur les opérations qui effacent ou déplacent des données.",[34,462,464],{"id":463},"identité-et-autorisation","Identité et autorisation",[10,466,467],{},"C'est ici que se joue la deuxième exigence structurelle, EX-4, et c'est la partie de l'architecture qui est la plus souvent traitée à la légère alors qu'elle porte l'essentiel de la valeur de conformité.",[10,469,470],{},"Le socle est un fournisseur d'identité unique, Keycloak dans cette architecture de référence, qui fédère les annuaires existants des agences plutôt que de prétendre les remplacer. Cette nuance compte : dans une administration, chaque agence a son annuaire, ses habitudes et sa gouvernance, et un projet qui exige la migration de tous les annuaires vers un référentiel central échoue pour des raisons politiques avant d'échouer pour des raisons techniques. La fédération permet de centraliser l'authentification sans centraliser la propriété des comptes.",[10,472,473],{},"L'accès humain au cluster passe par OIDC vers ce fournisseur. La conséquence pratique est l'élimination des fichiers kubeconfig à durée illimitée porteurs d'un certificat client, qui circulent par messagerie et survivent au départ de leur détenteur. Chaque accès administratif devient nominatif, expirable et révocable depuis un seul endroit, et l'audit du serveur d'API cesse d'enregistrer des identités anonymes.",[10,475,476],{},"Cela règle l'imputabilité des accès à la plateforme. Cela ne règle pas l'imputabilité des accès à la donnée, qui est ce que le droit demande réellement. C'est là qu'intervient la couche d'autorisation applicative.",[10,478,479],{},"L'architecture de référence retient un modèle fondé sur les relations, avec OpenFGA, inspiré du système Zanzibar de Google. Le raisonnement est le suivant. Les droits dans une administration ne se laissent pas décrire par des rôles globaux, parce qu'ils dépendent presque toujours de la relation entre l'agent et l'objet : l'agent instructeur de ce dossier précis, le supérieur hiérarchique du demandeur, l'agence de rattachement du citoyen concerné, le suppléant désigné pendant un congé, le service qui a délégué temporairement une compétence à un autre. Modéliser cela avec des rôles produit soit une explosion combinatoire de rôles, un par dossier ou par périmètre, soit une logique d'autorisation dispersée dans le code métier de chaque application, où elle devient invisible, non testable et non auditable. Un modèle relationnel exprime directement ces situations, et surtout il les centralise dans un artefact unique.",[10,481,482],{},"L'argument décisif pour cet article n'est pourtant pas la modélisation, il est la preuve. Une décision d'autorisation évaluée par un service dédié est un événement : un sujet, une relation, un objet, un résultat, un horodatage, un contexte. Journalisée, elle constitue exactement la trace que l'article 41 du décret et l'article 69 demandent, au niveau où ils la demandent, c'est-à-dire au niveau de la donnée et non de l'infrastructure. L'audit du serveur d'API sait dire que le ServiceAccount d'un déploiement a listé des Secrets ; il ne saura jamais dire qu'un agent nommé a consulté le dossier fiscal d'un citoyen nommé le mardi à quatorze heures. Le journal des décisions d'autorisation le sait, à condition que l'architecture le rende possible.",[10,484,485],{},"Cette condition est la propagation de l'identité de bout en bout. Elle mérite d'être énoncée précisément parce que c'est le point où la plupart des systèmes cassent la chaîne. L'identité de l'utilisateur doit voyager depuis l'authentification jusqu'à la couche d'accès aux données, sans être remplacée en chemin par une identité de service. Trois pratiques courantes rompent cette chaîne : un pooler de connexions qui mutualise tous les accès à la base sous un unique compte technique, une couche d'API intermédiaire qui réauthentifie avec sa propre identité, et un traitement par lots qui agit pour le compte d'un utilisateur sans conserver la référence à cet utilisateur. Chacune de ces ruptures transforme une trace nominative en trace de service, et rend EX-4 insatisfaisable quel que soit le reste de l'outillage. La conception doit donc traiter la propagation d'identité comme une exigence de premier ordre, pas comme un détail d'implémentation.",[10,487,488],{},"Les risques introduits par cette couche doivent être assumés. Le fournisseur d'identité devient un point de défaillance unique de premier ordre : s'il tombe, plus personne ne se connecte à rien, et il devient également la cible la plus intéressante de la plateforme. Il exige donc une redondance réelle, une sauvegarde testée de sa base et de ses clés de signature, et une surveillance dédiée. Le service d'autorisation ajoute un appel supplémentaire sur le chemin critique de chaque requête, avec ses conséquences en latence et en disponibilité, ce qui impose une stratégie de mise en cache et un comportement dégradé défini à l'avance : refuser ou autoriser en cas d'indisponibilité est une décision de politique, pas une valeur par défaut à découvrir en incident. Enfin, le modèle d'autorisation devient un artefact critique à versionner, tester et déployer avec la même rigueur que du code applicatif, parce qu'une erreur de modélisation y a l'effet d'une faille de sécurité.",[34,490,492],{"id":491},"observabilité-et-piste-daudit","Observabilité et piste d'audit",[10,494,495],{},"La confusion la plus coûteuse de toute cette architecture est de croire que l'observabilité couvre l'audit. Ce sont deux systèmes avec deux finalités, deux publics, deux politiques de rétention et deux niveaux d'exigence sur l'intégrité. Les fusionner produit une pile qui ne sert bien ni l'exploitation ni la conformité.",[10,497,498],{},"La télémétrie opérationnelle sert à exploiter. Métriques avec Prometheus, alertes avec Alertmanager, visualisation avec Grafana, journaux applicatifs avec Loki ou équivalent, traces distribuées si le paysage applicatif le justifie. Son public est l'équipe d'astreinte, son horizon utile se compte en jours ou en semaines, l'échantillonnage y est légitime, et une perte de données est un inconvénient. Elle doit être dimensionnée pour le confort de diagnostic, pas pour la preuve.",[10,500,501],{},"La piste d'audit réglementaire sert à prouver. Elle rassemble quatre sources qui ne sont pas interchangeables : l'audit du serveur d'API avec une politique explicite, généralement au niveau des métadonnées pour l'essentiel et au niveau des requêtes et réponses pour les ressources sensibles ; les journaux d'accès aux données personnelles émis par les applications ; les décisions d'autorisation ; et les journaux d'accès des bases de données. Son public est un auditeur ou un régulateur, son horizon est de douze mois au minimum selon EX-3, l'échantillonnage y est disqualifiant, l'intégrité y est exigée selon EX-5, et son accès doit lui-même être restreint et journalisé.",[10,503,504],{},"L'implication pratique est qu'il faut deux destinations de stockage et deux politiques distinctes. Un Loki dimensionné pour quinze jours de rétention ne prouve rien à J moins trois cents. Un échantillonnage de traces qui divise le volume par dix détruit la valeur probante de ce qu'il jette. Une politique de purge automatique conçue pour maîtriser les coûts de stockage peut effacer, sans intention et sans alerte, exactement la preuve qu'un contrôle réclamera. Ces trois erreurs sont fréquentes et se découvrent au pire moment.",[10,506,507],{},"L'exigence de notification en vingt-quatre heures (EX-8) demande sa propre attention, parce qu'elle est le plus souvent traitée comme une case documentaire alors que c'est un processus chronométré. Trois questions doivent avoir une réponse écrite avant tout incident. Quand l'horloge démarre : à la détection, ce qui est la lecture prudente, et non à la qualification juridique, sinon le délai devient extensible à volonté et indéfendable. Qui décide de notifier, avec un suppléant nommé, parce qu'un incident majeur survient rarement pendant les heures ouvrées. Par quel canal, avec quel contenu minimal, vers quel destinataire, et avec quelle trace de l'envoi. Une alerte Alertmanager n'est pas une notification réglementaire, et l'écart entre les deux se mesure en heures perdues à chercher qui a le numéro de qui.",[10,509,510],{},"Un dernier point de méthode : les tableaux de bord de conformité et les tableaux de bord d'exploitation doivent être séparés. Le premier répond à des questions comme la couverture du chiffrement, l'âge du dernier test de restauration, le nombre de charges sans NetworkPolicy, la proportion d'accès administratifs nominatifs. Ces indicateurs n'intéressent pas l'astreinte et se lisent une fois par mois, mais ils transforment la conformité d'un exercice annuel douloureux en une propriété observée en continu.",[34,512,514],{"id":513},"le-modèle-opérationnel","Le modèle opérationnel",[10,516,517],{},"Une architecture ne vaut que si une organisation peut la tenir dans la durée. C'est la partie que les documents d'architecture omettent le plus souvent, et c'est celle qui détermine si le projet existe encore dans trois ans.",[10,519,520],{},"Quatre rôles sont nécessaires, et il s'agit bien de rôles et non de personnes. L'exploitation de la plateforme couvre le cluster, le réseau, le stockage et les mises à jour. La sécurité et la conformité couvrent les politiques, la piste d'audit, la revue des accès et la réponse à incident. Le rôle données couvre les bases, les sauvegardes et les exercices de restauration. Un rôle de conception maintient la cohérence de l'ensemble et arbitre les demandes des agences hébergées, faute de quoi la plateforme dérive vers un assemblage de cas particuliers.",[10,522,523],{},"Ces rôles supposent une redondance. Un rôle tenu par une seule personne n'est pas tenu, il est emprunté à un individu jusqu'à son départ ou son congé. C'est un jugement d'expérience et je le donne comme tel : en dessous d'environ cinq à six personnes couvrant ces quatre rôles avec un doublement effectif, une plateforme de ce type est portée par des individus et non par une organisation, et le départ d'une seule personne devient un incident majeur. Ce seuil n'est pas une norme, c'est un ordre de grandeur destiné à être discuté au moment du dimensionnement plutôt que découvert après.",[10,525,526],{},"Les compétences réellement rares dans la sous-région sont identifiables et doivent guider les choix techniques. L'exploitation d'un système de stockage distribué, le réseau BGP, la gestion d'une PKI, la réponse à incident structurée, et l'exploitation de Kubernetes au sens propre, qui est autre chose que son utilisation. Ces compétences se recrutent difficilement et se retiennent encore plus difficilement, parce que le marché international les rémunère à des niveaux qu'une administration ne peut pas suivre. La conséquence architecturale a déjà été énoncée pour le stockage et vaut partout : préférer systématiquement le composant que l'équipe sait exploiter à celui qui est techniquement supérieur. Une architecture qui suppose des compétences que l'organisation n'a pas est une architecture qui échouera, quelle que soit sa qualité sur le papier.",[10,528,529],{},"Sur les coûts, je donne une méthode et non des chiffres, et cette décision mérite d'être justifiée. Publier des montants sans les avoir mesurés dans le contexte visé produirait un faux ancrage, et un chiffre importé d'un comparatif européen ou nord-américain n'est pas transposable : le coût de l'énergie, le coût salarial, les droits et taxes à l'importation du matériel, et le coût du transit international diffèrent d'un facteur suffisant pour inverser une conclusion. Une analyse chiffrée sérieuse est un travail à part entière, avec des sources locales, et elle mérite son propre article.",[10,531,532],{},"La méthode, elle, est stable. Un coût total de possession sur cinq ans se construit sur sept postes. Le matériel, serveurs, réseau et stockage, amorti sur cinq ans, avec un taux de remplacement annuel pour les pannes. L'hébergement physique, salle, énergie, refroidissement et redondance électrique, poste régulièrement sous-estimé et particulièrement sensible dans un contexte où l'alimentation du réseau public est irrégulière et où l'onduleur et le groupe électrogène ne sont pas des options. La connectivité, y compris la liaison entre les deux salles. Le support et les souscriptions, y compris les distributions et les outils commerciaux éventuellement retenus. Le coût humain, qui est le poste dominant sur cinq ans et de loin. La formation et la certification, qui ne sont pas une variable d'ajustement mais la condition du poste précédent. Et l'audit et la conformité, y compris le temps interne consommé par les contrôles.",[10,534,535],{},"Deux postes échappent à ces sept et doivent être ajoutés explicitement. Le coût de la montée en compétence, c'est-à-dire la période pendant laquelle l'équipe est payée à apprendre et produit moins. Et le coût de sortie, c'est-à-dire ce qu'il en coûterait de migrer hors de cette architecture si la décision était renversée, question que personne ne pose au moment de l'investissement et que tout le monde regrette de ne pas avoir posée.",[10,537,538],{},"La propriété économique structurante de cette architecture est que son coût est majoritairement fixe. Le coût unitaire par service hébergé baisse donc à mesure que la plateforme se remplit, ce qui est l'inverse exact d'une facture élastique. Cela déplace la bonne question. Il ne s'agit pas de savoir laquelle des deux options est moins chère dans l'absolu, mais à quel niveau d'usage les deux courbes se croisent, et de constater qu'une plateforme mutualisée entre plusieurs agences atteint ce point de croisement bien plus vite qu'une plateforme dédiée à une seule.",[34,540,542],{"id":541},"enseignements-de-terrain","Enseignements de terrain",[10,544,545],{},"Ce qui suit relève de schémas d'échec observés dans le secteur, formulés au niveau du secteur. Ils ne visent aucune organisation et n'en décrivent aucune. Leur intérêt est qu'ils sont répétitifs : ce sont les mêmes qui reviennent, et ce sont presque toujours des défaillances de discipline plutôt que de conception.",[10,547,548],{},"La dérive de configuration arrive en tête. Sans verrouillage effectif de l'accès direct au cluster, l'état réel s'éloigne progressivement de l'état déclaré, souvent pour de bonnes raisons dans l'urgence d'un incident. Le symptôme n'apparaît que bien plus tard : plus personne n'ose reconstruire un composant, parce que plus personne ne sait ce qui a été ajusté à la main et ne figure nulle part.",[10,550,551],{},"La sauvegarde jamais restaurée est le classique le plus coûteux. Le travail de sauvegarde s'exécute et rapporte un succès pendant deux ans, et la première tentative de restauration a lieu le jour où elle est vitale. C'est aussi ce jour-là que l'on découvre que la sauvegarde ne contenait pas la totalité de ce qu'il fallait, ou que le RTO réel est un ordre de grandeur au-dessus du RTO annoncé.",[10,553,554],{},"Le magasin etcd est régulièrement oublié. Beaucoup d'équipes sauvegardent soigneusement les volumes applicatifs sans sauvegarder séparément l'état du cluster, alors que sa perte est la perte du cluster, et que sa sauvegarde est à la fois triviale et rapide.",[10,556,557],{},"Le fournisseur d'identité installé provisoirement en instance unique reste en instance unique. Il est déployé tôt, pour débloquer les autres chantiers, avec l'intention sincère de le redonder plus tard. Il devient ensuite le composant dont dépendent tous les autres, et le redonder demande une fenêtre d'indisponibilité que plus personne ne veut assumer.",[10,559,560],{},"Les certificats causent plus d'incidents que les attaques. Le premier incident majeur d'une PKI interne n'est presque jamais une compromission, c'est une expiration, souvent sur un composant intermédiaire que personne n'avait inscrit dans un calendrier. L'automatisation de l'émission ne suffit pas : ce sont les certificats hors du périmètre de cert-manager, ceux des équipements et des systèmes hérités, qui expirent.",[10,562,563],{},"La montée de version repoussée transforme une opération de routine en projet. Kubernetes avance à un rythme soutenu, et deux ou trois versions de retard changent la nature de l'exercice : ce n'est plus une mise à jour, c'est une migration, avec des interruptions d'API à traiter et un risque qui justifie de repousser encore.",[10,565,566],{},"Enfin, la conformité découverte tardivement. Une architecture conçue avec les exigences dès le départ, comme le fait la première section de cet article, coûte une fraction de ce que coûte la même conformité rétrofitée trois semaines avant un contrôle. Ce n'est pas un argument moral, c'est une observation de coût.",[34,568,570],{"id":569},"limites-de-larchitecture","Limites de l'architecture",[10,572,573],{},"Une architecture de référence qui ne dit pas où elle échoue n'est pas exploitable. Voici les cas où celle-ci n'est pas le bon choix, et les limites de la souveraineté qu'elle procure.",[10,575,576],{},"Elle sert mal les charges à pic imprévisible. Le dimensionnement se fait sur le pic, donc une charge dont le pic est rare et très supérieur à la moyenne se paie en capacité dormante toute l'année. C'est précisément pourquoi le périmètre déclaré plus haut insiste sur la prévisibilité des pics administratifs : si cette hypothèse tombe, l'arbitrage économique change.",[10,578,579],{},"Elle ne donne pas accès aux services managés avancés. Les entrepôts analytiques à grande échelle, les services d'intelligence artificielle managés, les bases distribuées mondialement n'ont pas d'équivalent auto-hébergé à coût comparable. Reproduire ces services en interne coûte davantage que la dépendance que l'on cherchait à éviter, et il faut l'admettre plutôt que de prétendre que l'écosystème ouvert couvre tout.",[10,581,582],{},"Une salle unique ne fournit aucune continuité réelle, et deux salles proches ne protègent pas contre un sinistre régional, une coupure électrique étendue ou une inondation. La distance entre les sites est un paramètre de conception, pas un détail logistique.",[10,584,585],{},"La souveraineté obtenue est juridictionnelle et opérationnelle, pas industrielle, et c'est la limite la plus importante de tout cet article. Les serveurs, leurs micrologiciels, leurs contrôleurs d'administration hors bande, leurs composants réseau ne sont pas souverains : ils sont conçus et fabriqués ailleurs, et leur chaîne d'approvisionnement échappe entièrement à l'État qui les achète. Le contrôleur d'administration hors bande mérite une mention particulière, parce qu'il constitue une surface d'administration complète, souvent laissée dans un réseau mal segmenté, avec des identifiants par défaut et des micrologiciels rarement mis à jour. Une plateforme rigoureuse au niveau Kubernetes et négligente au niveau du contrôleur d'administration matérielle n'est pas sécurisée, elle est mal auditée.",[10,587,588],{},"La dépendance à l'amont open source est réelle. Les composants retenus sont développés par des communautés et des entreprises situées hors de la juridiction, avec leurs propres décisions de fin de support, leurs changements de licence, et leur rythme de correction des vulnérabilités. Sans veille organisée et sans capacité interne de correction, « open source » signifie « gratuit », pas « maîtrisé ». La chaîne d'approvisionnement logicielle prolonge ce constat : images de conteneurs, chartes Helm et opérateurs tirés de dépôts publics entrent dans la plateforme avec un niveau de vérification souvent nul. Un registre local avec analyse de vulnérabilités et vérification des signatures est nécessaire, faute de quoi l'indépendance s'arrête à la couche matérielle.",[10,590,591],{},"Enfin, la limite déjà posée dans l'article précédent reste entière et il faut la répéter ici pour éviter tout malentendu : un opérateur souverain mal exploité est moins sûr qu'un opérateur étranger bien exploité. Cette architecture ne dispense pas de l'audit indépendant, elle le rend possible. Être local n'est pas une qualification de sécurité, c'est une propriété de juridiction.",[34,593,595],{"id":594},"comparaison-honnête-avec-les-alternatives","Comparaison honnête avec les alternatives",[10,597,598],{},"Le tableau ci-dessous compare quatre options réalistes pour une administration ouest-africaine, sur les critères qui découlent du cahier des charges plutôt que sur des critères commerciaux.",[42,600,601,620],{},[45,602,603],{},[48,604,605,608,611,614,617],{},[51,606,607],{},"Critère",[51,609,610],{},"Bare-metal souverain (cette architecture)",[51,612,613],{},"Kubernetes managé chez un opérateur national",[51,615,616],{},"Hyperscaler avec région locale",[51,618,619],{},"Colocation chez un opérateur national, exploitation par l'État",[64,621,622,639,655,672,689,706,722,738,755],{},[48,623,624,627,630,633,636],{},[69,625,626],{},"Établissement responsable (EX-1)",[69,628,629],{},"Satisfait, l'État ou son opérateur est l'établissement",[69,631,632],{},"Satisfait si l'opérateur est établi localement",[69,634,635],{},"Partiellement, l'entité contractante peut être locale mais le contrôle remonte à la société mère",[69,637,638],{},"Satisfait",[48,640,641,644,647,650,653],{},[69,642,643],{},"Transfert vers pays tiers (EX-2)",[69,645,646],{},"Aucun transfert par conception",[69,648,649],{},"Aucun si l'opérateur ne sous-traite pas hors juridiction, à vérifier au contrat",[69,651,652],{},"Exposition persistante par le plan de contrôle et la juridiction du groupe",[69,654,646],{},[48,656,657,660,663,666,669],{},[69,658,659],{},"Plan de contrôle",[69,661,662],{},"Entièrement local et auditable",[69,664,665],{},"Local, mais exploité par un tiers dont il faut auditer les accès",[69,667,668],{},"Hors juridiction dans la plupart des cas",[69,670,671],{},"Entièrement local",[48,673,674,677,680,683,686],{},[69,675,676],{},"Piste d'audit unique (EX-3, EX-5)",[69,678,679],{},"Une seule piste, cohérente",[69,681,682],{},"Une seule piste, mais partagée avec l'opérateur",[69,684,685],{},"Format et rétention imposés par le fournisseur",[69,687,688],{},"Une seule piste",[48,690,691,694,697,700,703],{},[69,692,693],{},"Élasticité",[69,695,696],{},"Faible, dimensionnement au pic",[69,698,699],{},"Moyenne, limitée par la capacité de l'opérateur",[69,701,702],{},"Élevée",[69,704,705],{},"Faible",[48,707,708,711,714,717,720],{},[69,709,710],{},"Services managés avancés",[69,712,713],{},"Absents",[69,715,716],{},"Rares",[69,718,719],{},"Étendus",[69,721,713],{},[48,723,724,727,730,733,736],{},[69,725,726],{},"Structure de coût",[69,728,729],{},"Majoritairement fixe, coût unitaire décroissant",[69,731,732],{},"Mixte",[69,734,735],{},"Variable, coût unitaire stable",[69,737,732],{},[48,739,740,743,746,749,752],{},[69,741,742],{},"Compétences internes requises",[69,744,745],{},"Élevées, sur toute la pile",[69,747,748],{},"Moyennes, l'exploitation du socle est déléguée",[69,750,751],{},"Faibles sur le socle, élevées sur l'usage",[69,753,754],{},"Élevées, hors matériel et énergie",[48,756,757,760,763,766,769],{},[69,758,759],{},"Risque d'exécution",[69,761,762],{},"Élevé, concentré sur la capacité de l'organisation à tenir l'équipe",[69,764,765],{},"Moyen, déplacé vers la solidité de l'opérateur",[69,767,768],{},"Faible techniquement, élevé juridiquement",[69,770,771],{},"Élevé",[10,773,774],{},"Aucune de ces colonnes n'est gagnante partout, et c'est le point. La colocation avec exploitation par l'État est souvent le compromis le plus réaliste pour commencer : elle retire de l'équation le bâtiment, l'énergie et la redondance électrique, qui sont des métiers en soi, tout en gardant le plan de contrôle et l'imputabilité à l'intérieur du périmètre. Le Kubernetes managé chez un opérateur national est intéressant si et seulement si cet opérateur accepte un niveau d'audit comparable à celui que l'État s'imposerait à lui-même, et si le contrat interdit explicitement toute sous-traitance hors juridiction, y compris pour le support de niveau trois, qui est l'angle mort habituel de ces contrats.",[10,776,777],{},"L'hyperscaler avec région locale conserve un usage parfaitement légitime, déjà décrit dans l'article précédent : le contenu public non régulé, les charges sans données personnelles, et les besoins ponctuels de capacité de calcul sur des données non sensibles. Le rejeter en bloc serait aussi peu sérieux que de l'adopter en bloc.",[34,779,781],{"id":780},"limites-de-lanalyse-et-questions-ouvertes","Limites de l'analyse et questions ouvertes",[10,783,784],{},"Cet article est une architecture de référence, pas un retour d'expérience mesuré. Les choix y sont justifiés par des exigences dérivées de textes et par une pratique d'exploitation, non par des mesures publiées et reproductibles sur un déploiement identifié. Un lecteur qui cherche des chiffres de performance ou de coût comparés ne les trouvera pas ici, et c'est délibéré : les publier sans les avoir mesurés dans le contexte visé aurait produit une fausse précision.",[10,786,787],{},"La dérivation du cahier des charges repose sur la même extension d'interprétation que celle assumée dans l'article 1. Le Décret 2018-062 vise en premier lieu les prestataires de services de confiance, et traiter ses obligations comme un référentiel pour une plateforme de calcul générique est une lecture raisonnable mais discutable. Ces exigences sont formulées par un ingénieur et méritent d'être revues par un praticien du droit togolais avant d'être utilisées dans un document contractuel ou un cahier des charges d'appel d'offres.",[10,789,790],{},"Plusieurs questions restent ouvertes et je préfère les nommer plutôt que de les habiller. La qualification d'une plateforme gouvernementale mutualisée en opérateur de services essentiels au sens de l'Arrêté 2022-040 n'est pas évidente et change une partie des obligations. La valeur probante d'un historique Git signé devant un régulateur n'est, à ma connaissance, pas établie : l'argument me paraît solide sur le plan technique, mais il n'a pas été éprouvé dans un contrôle. Le statut d'un journal de décisions d'autorisation comme preuve d'accès à une donnée personnelle relève de la même incertitude. Enfin, une mutualisation régionale, une plateforme partagée entre plusieurs États de l'UEMOA, poserait une question de droit applicable que ni les textes nationaux ni les instruments communautaires actuels ne tranchent clairement, alors que c'est probablement la seule voie qui rende l'économie de ce modèle réellement favorable.",[10,792,793],{},"Le fond de l'affaire tient en une phrase. La souveraineté numérique ne s'achète pas dans un contrat, elle se conçoit dans une architecture et se prouve dans un audit. Le travail décrit ici n'est pas de reproduire un hyperscaler en plus petit, c'est de construire une plateforme dont chaque couche répond à une exigence nommée, dont chaque choix assume ce qu'il coûte, et dont les limites sont écrites avant que quelqu'un d'autre ne les découvre.",[34,795,797],{"id":796},"sources","Sources",[799,800,801,811,819,827,835,843,850,858,866],"ul",{},[802,803,804,805],"li",{},"Décret n°2018-062\u002FPR portant réglementation des transactions et services électroniques au Togo, ",[14,806,810],{"href":807,"rel":808},"https:\u002F\u002Farcep.tg\u002Fwp-content\u002Fuploads\u002F2020\u002F11\u002FDecret_2018_062_PR_portant_reglementation_des_transactions_services_electronique.pdf",[809],"nofollow","ARCEP",[802,812,813,814],{},"Loi n°2019-014 du 29 octobre 2019 relative à la protection des données à caractère personnel, ",[14,815,818],{"href":816,"rel":817},"https:\u002F\u002Fjo.gouv.tg\u002Fsites\u002Fdefault\u002Ffiles\u002FJO\u002FJOS_29_10_2019-64E%20ANNEE-N%C2%B026%20TER.pdf",[809],"Journal Officiel",[802,820,821,822],{},"Loi n°2017-007 relative aux transactions électroniques, ",[14,823,826],{"href":824,"rel":825},"https:\u002F\u002Fnumerique.gouv.tg\u002Fimportante-mise-a-jour-de-la-loi-n2017-007-du-22-juin-2017-relative-aux-transactions-electroniques\u002F",[809],"numerique.gouv.tg",[802,828,829,830],{},"Arrêté n°2022-040\u002FPMRT portant adoption des règles de cybersécurité en République togolaise, ",[14,831,834],{"href":832,"rel":833},"https:\u002F\u002Fcert.tg\u002Fwp-content\u002Fuploads\u002F2022\u002F07\u002F20220705-Arrete-n%C2%B0-2022-040-PMRT-portant-adoption-des-regles-de-cybersecurite-en-Republique-togolaise.pdf",[809],"CERT Togo",[802,836,837,838],{},"Kubernetes, Encrypting Confidential Data at Rest, ",[14,839,842],{"href":840,"rel":841},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Fadminister-cluster\u002Fencrypt-data\u002F",[809],"kubernetes.io",[802,844,845,846],{},"Kubernetes, Auditing, ",[14,847,842],{"href":848,"rel":849},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Fdebug\u002Fdebug-cluster\u002Faudit\u002F",[809],[802,851,852,853],{},"Kubespray, ",[14,854,857],{"href":855,"rel":856},"https:\u002F\u002Fgithub.com\u002Fkubernetes-sigs\u002Fkubespray",[809],"kubernetes-sigs\u002Fkubespray",[802,859,860,861],{},"R. Pang et al., Zanzibar: Google's Consistent, Global Authorization System, USENIX ATC 2019, ",[14,862,865],{"href":863,"rel":864},"https:\u002F\u002Fwww.usenix.org\u002Fconference\u002Fatc19\u002Fpresentation\u002Fpang",[809],"USENIX",[802,867,868,869],{},"OpenFGA, documentation du modèle d'autorisation, ",[14,870,873],{"href":871,"rel":872},"https:\u002F\u002Fopenfga.dev\u002Fdocs",[809],"openfga.dev",[10,875,876],{},"Ceci est une analyse d'ingénierie et d'architecture, pas un conseil juridique. Pour toute décision de conformité ou tout usage dans un document contractuel, consultez un praticien du droit togolais de la protection des données et des marchés publics.",{"title":878,"searchDepth":879,"depth":879,"links":880},"",2,[881,882,883,884,885,886,887,888,889,890,891,892,893],{"id":36,"depth":879,"text":37},{"id":239,"depth":879,"text":240},{"id":258,"depth":879,"text":259},{"id":283,"depth":879,"text":284},{"id":429,"depth":879,"text":430},{"id":463,"depth":879,"text":464},{"id":491,"depth":879,"text":492},{"id":513,"depth":879,"text":514},{"id":541,"depth":879,"text":542},{"id":569,"depth":879,"text":570},{"id":594,"depth":879,"text":595},{"id":780,"depth":879,"text":781},{"id":796,"depth":879,"text":797},"2026-08-15","Les deux articles précédents ont montré où le droit togolais et Kubernetes ne se rencontrent pas, puis pourquoi le multi-cloud ne répond pas à une question de juridiction. Celui-ci propose ce qu'il faut construire : une architecture de référence pour un cloud gouvernemental souverain en contexte UEMOA. Cahier des charges dérivé du texte, choix de couches justifiés un par un, modèle opérationnel, limites assumées et comparaison honnête avec les alternatives. Un document d'architecture, pas un tutoriel.",false,"md","https:\u002F\u002Fres.cloudinary.com\u002Fdpdwhd6ka\u002Fimage\u002Fupload\u002Ff_auto,q_auto\u002Fv1\u002FBlog\u002Fimages\u002Fhbcudyxllyjvbkjxvs7g",{},true,"\u002Fkubernetes\u002Fsovereign-govcloud-reference-architecture.fr",{"title":5,"description":895},"sovereign-govcloud-reference-architecture","kubernetes\u002F3.sovereign-govcloud-reference-architecture.fr",[906,907,908,909,910],"Sovereignty","Kubernetes","Reference-Architecture","Togo","Platform-Engineering",[912,913,914,915,916],"kubernetes","cloud","platform-engineering","security","authz","OeGRFBX0_M5Bd4_StQzLU0gvofZkb_-lJG9eOVKn9-A",{"id":919,"title":920,"body":921,"date":894,"description":1744,"draft":896,"extension":897,"img":898,"meta":1745,"navigation":900,"path":1746,"seo":1747,"slug":903,"stem":1748,"tags":1749,"topics":1750,"__hash__":1751},"content\u002Fkubernetes\u002F3.sovereign-govcloud-reference-architecture.md","A Reference Architecture for a Sovereign Government Cloud",{"type":7,"value":922,"toc":1729},[923,934,937,940,943,947,950,1124,1127,1131,1134,1137,1140,1143,1146,1150,1153,1156,1159,1162,1165,1168,1171,1175,1178,1269,1272,1278,1284,1290,1296,1302,1305,1309,1312,1315,1318,1321,1324,1327,1330,1333,1336,1339,1343,1346,1349,1352,1355,1358,1361,1364,1367,1371,1374,1377,1380,1383,1386,1389,1393,1396,1399,1402,1405,1408,1411,1414,1417,1421,1424,1427,1430,1433,1436,1439,1442,1445,1449,1452,1455,1458,1461,1464,1467,1470,1474,1477,1649,1652,1655,1659,1662,1665,1668,1671,1673,1726],[10,924,925,926,929,930,933],{},"Two articles set this one up. The first mapped ",[14,927,928],{"href":16},"the mismatch between Decree 2018-062 and the Kubernetes mental model",": a body of law that reasons in stable, locatable entities, a platform that dissolves those anchors, and four real gaps that follow. The second argued that ",[14,931,932],{"href":21},"multi-cloud does not answer a jurisdictional question"," and that it multiplies exposure rather than dividing it. Both are critical by construction: they say what breaks and what does not fix it. They leave open the only question a public administration actually cares about, which is what to build instead.",[10,935,936],{},"This article answers that in the form of a reference architecture. Not a deployment tutorial, not a named case study, not a product list. An architecture document in the strict sense: a set of requirements derived from the applicable legal texts, a series of design choices justified against those requirements, an operating model that states what team and what budget it takes to hold the whole thing together, and above all a statement of limits, because a reference architecture that never says when it is the wrong choice is not a reference architecture, it is a brochure.",[10,938,939],{},"The thesis fits in one sentence. Sovereignty is not a contractual clause you obtain from a vendor, it is an architectural property you build and must be able to prove. The rest of this article is about making that sentence operational.",[10,941,942],{},"One methodological note before the substance. This article is written in pure reference-architecture mode. The choices below are informed by hands-on practice operating regulated platforms, but no organisation is named, no attributable measurement is cited, and no identifiable topology is described. Field lessons are stated at the level of the sector, never at the level of a particular deployment.",[34,944,946],{"id":945},"requirements-derived-from-the-legal-texts","Requirements derived from the legal texts",[10,948,949],{},"The classic mistake is to design the platform first and then look for ways to make it compliant afterwards. This section does the opposite: it turns legal obligations into numbered non-functional requirements, each with a verification criterion. It is this requirement set, and not a tooling preference, that justifies every choice in the sections that follow.",[42,951,952,967],{},[45,953,954],{},[48,955,956,959,962,964],{},[51,957,958],{},"Ref",[51,960,961],{},"Requirement",[51,963,59],{},[51,965,966],{},"Verification criterion",[64,968,969,982,995,1008,1021,1034,1047,1060,1072,1085,1098,1111],{},[48,970,971,973,976,979],{},[69,972,71],{},[69,974,975],{},"The platform operator is a legal entity established on national territory, identifiable and sanctionable by the regulator",[69,977,978],{},"Decree 2018-062 art. 58",[69,980,981],{},"Registration, operating contract, named responsible officer",[48,983,984,986,989,992],{},[69,985,85],{},[69,987,988],{},"Every persistent volume and every ephemeral store that may process personal data has a known, documented physical location, and every border crossing is declared",[69,990,991],{},"Law 2019-014 art. 28",[69,993,994],{},"Processing register cross-checked against an inventory of StorageClasses and their hardware anchoring",[48,996,997,999,1002,1005],{},[69,998,99],{},[69,1000,1001],{},"Logs that identify access are retained for at least twelve months",[69,1003,1004],{},"Decree art. 41, Order 2022-040 D1.1.1",[69,1006,1007],{},"Successful sampling of a log entry at day minus 360",[48,1009,1010,1012,1015,1018],{},[69,1011,113],{},[69,1013,1014],{},"Every access to personal data is attributable to a real human identity, not only to a technical service identity",[69,1016,1017],{},"Decree art. 41 and 69",[69,1019,1020],{},"Reconstruction of a full access chain from an officer's identifier to the record read",[48,1022,1023,1025,1028,1031],{},[69,1024,127],{},[69,1026,1027],{},"Audit records are protected against modification, and any attempt is detectable",[69,1029,1030],{},"Decree art. 69",[69,1032,1033],{},"Documented tamper test against the evidence store",[48,1035,1036,1038,1041,1044],{},[69,1037,141],{},[69,1039,1040],{},"Security measures are proportionate to risk: least privilege, default-deny network isolation, admission control",[69,1042,1043],{},"Decree art. 52",[69,1045,1046],{},"Review of RBAC roles, NetworkPolicies and admission policies",[48,1048,1049,1051,1054,1057],{},[69,1050,155],{},[69,1052,1053],{},"Data is encrypted in transit, and at rest in etcd, in Secrets and on persistent volumes",[69,1055,1056],{},"Decree art. 44 and 52, Order G3.1.5",[69,1058,1059],{},"Inspection of a raw etcd backup and a detached volume",[48,1061,1062,1064,1067,1069],{},[69,1063,169],{},[69,1065,1066],{},"Any security incident is notified to the supervisory body within twenty-four hours",[69,1068,1043],{},[69,1070,1071],{},"Dated runbook, detection timestamp, notification exercise",[48,1073,1074,1076,1079,1082],{},[69,1075,182],{},[69,1077,1078],{},"Continuity objectives are defined and verified, and a wind-down plan exists",[69,1080,1081],{},"Decree art. 58, Order R1",[69,1083,1084],{},"Dated restore test with measured RTO and RPO, not declared ones",[48,1086,1087,1089,1092,1095],{},[69,1088,196],{},[69,1090,1091],{},"Data can be returned, transferred to a third party, or permanently destroyed on request",[69,1093,1094],{},"Decree art. 71",[69,1096,1097],{},"Export and destruction exercise with evidence",[48,1099,1100,1102,1105,1108],{},[69,1101,210],{},[69,1103,1104],{},"Any third party accessing the data is bound by a written contract and acts solely on the controller's instruction",[69,1106,1107],{},"Law 2019-014 art. 20",[69,1109,1110],{},"Subprocessor register, contracts up to date",[48,1112,1113,1115,1118,1121],{},[69,1114,224],{},[69,1116,1117],{},"Every autonomous controller able to act on data has a named owner and a documented scope of action",[69,1119,1120],{},"Decree art. 47, gap identified in article 1",[69,1122,1123],{},"Inventory of Operators with their RBAC rights and their owner",[10,1125,1126],{},"Three of these deserve to be flagged immediately, because they are the ones that swing the architectural decision. EX-2, EX-4 and EX-12 are precisely the three that article 1 identified as structural Kubernetes gaps, and they are also the ones a managed cluster at a foreign provider makes hardest to satisfy: storage geography there is a property of the service rather than a documentable choice, identity stops at the ServiceAccount, and the scope of action of the provider's own controllers is neither inventoriable nor negotiable. A sovereign architecture should be judged on those three lines first. The others, a competent operator satisfies more or less anywhere.",[34,1128,1130],{"id":1129},"scope-and-assumptions","Scope and assumptions",[10,1132,1133],{},"A reference architecture with no declared scope cannot be criticised, and is therefore useless. Here is what this one targets and what it excludes.",[10,1135,1136],{},"The target workloads are those of a public administration: citizen service portals, administrative registries (civil status, land, tax, vehicle registration), agency back offices, interoperability APIs between administrations, document management, internal line-of-business applications. The order of magnitude assumed is tens to a few hundred application services, with traffic that is mostly daytime, national, and with peaks that are largely predictable: tax deadlines, school enrolment campaigns, election periods, benefit disbursements. That predictability is an important property, and the final comparison comes back to it, because it changes the value of elasticity entirely.",[10,1138,1139],{},"Out of scope: high performance computing, large-scale model training, a telecom operator's network core, and real-time critical systems in healthcare or defence. Those domains have their own constraints and their own frameworks, and pretending a single architecture covers them would be dishonest.",[10,1141,1142],{},"Three assumptions condition everything else, and if one of them fails the architecture must be revisited. First, at least two distinct machine rooms with a link between them; a single room rules out any serious continuity story, and saying so early avoids selling a promise the topology cannot keep. Second, the possibility of an upfront hardware investment, which is not a given in an annualised budget framework where operating expenditure is easier to obtain than capital expenditure. Third, a permanent team, as opposed to a project staffed with a contractor for eighteen months and then left to itself.",[10,1144,1145],{},"One regional factor weighs on the choices: international transit is expensive and sometimes unstable, while latency to a distant region degrades the experience of services that are entirely domestic. Local hosting therefore has a technical justification independent of the legal one, and that is worth noting, because a sovereignty argument that also rests on performance is much harder to wave away than a purely regulatory one.",[34,1147,1149],{"id":1148},"the-foundational-choice-bare-metal-virtualisation-or-both","The foundational choice: bare metal, virtualisation, or both",[10,1151,1152],{},"This is the decision that constrains all the others, and it is settled on compliance grounds as much as on performance.",[10,1154,1155],{},"Three serious options exist. Pure bare metal puts Kubernetes directly on physical servers: maximum density, maximum performance, a single management plane to operate, but isolation between workloads rests entirely on Kubernetes mechanisms. Full virtualisation installs a hypervisor and then Kubernetes clusters inside virtual machines: two management planes, a density loss of a few percent on compute and more on memory, but a hardware isolation boundary and the ability to host alongside it the legacy systems that will never be containerised. The third option, managed Kubernetes at a national operator, is covered in the final comparison; it changes the responsibility model more than the technical architecture.",[10,1157,1158],{},"The deciding criterion is not performance, it is EX-6 read through an auditor's eyes. In a shared cluster, isolation between agencies rests on namespaces, RBAC and NetworkPolicies. Those are logical boundaries, enforced by a shared kernel and a shared control plane. As long as the hosted agencies have comparable requirements, that boundary is acceptable and defensible. As soon as two agencies carry different classifications, or one processes data whose compromise creates liability for the other, the audit question becomes: what physically prevents a workload belonging to agency A from reaching agency B's data in the event of a container escape. Answering \"RBAC\" is not an answer to that question.",[10,1160,1161],{},"The reference recommendation is therefore mixed, and owned as a compromise. A light virtualisation layer based on KVM, operated for instance with Proxmox VE or an equivalent distribution, provides the substrate. On top of it, a shared Kubernetes cluster hosts the large majority of workloads, effectively bare metal from the application's point of view since the nodes are dedicated virtual machines and not shared with anything else. Workloads whose classification demands it get their own cluster on physically separate hosts. Legacy systems that will never be containerised live as virtual machines on the same substrate, which avoids maintaining two parallel infrastructures.",[10,1163,1164],{},"That choice costs three things worth naming. Lost density, and therefore additional hardware. A second management plane to operate, back up and patch, with the skills that implies. And harder diagnosis, because a performance problem can now originate in two layers instead of one.",[10,1166,1167],{},"A note on hypervisor selection, which goes straight to the subject of this article. A platform's sovereignty is also judged on its licensing dependencies. VMware moving under Broadcom's control, and the licensing overhaul that followed, was a reminder that a proprietary infrastructure layer is a lever held by a foreign third party regardless of where the servers sit. A state that builds a sovereign platform on a hypervisor whose pricing and terms can be redefined unilaterally from another jurisdiction reproduces at the bottom layer exactly the dependency it was trying to avoid at the top. That is an argument for KVM and its open ecosystem, not a comparative technical quality judgement.",[10,1169,1170],{},"Two intermediate mechanisms are worth knowing without being the default recommendation. Container sandboxes such as gVisor or Kata Containers offer stronger isolation without the full cost of a virtual machine per workload. They carry a real performance cost and a non-zero operational burden, and they complicate diagnosis. They fit a subset of higher-risk workloads inside a shared cluster, not a general substrate.",[34,1172,1174],{"id":1173},"the-orchestration-layer","The orchestration layer",[10,1176,1177],{},"The components below form the reference stack. Each is justified by a requirement, and each is presented with the serious alternative that was rejected and the reason for rejecting it. A stack that does not show its alternatives is not justified, it is merely described.",[42,1179,1180,1196],{},[45,1181,1182],{},[48,1183,1184,1187,1190,1193],{},[51,1185,1186],{},"Component",[51,1188,1189],{},"Requirement served",[51,1191,1192],{},"Serious alternative",[51,1194,1195],{},"Why this choice",[64,1197,1198,1210,1221,1233,1246,1257],{},[48,1199,1200,1202,1204,1207],{},[69,1201,312],{},[69,1203,315],{},[69,1205,1206],{},"RKE2, Talos Linux, plain kubeadm",[69,1208,1209],{},"Ansible-driven install with a version-controlled inventory, fully offline execution from a local registry, no control plane operated by a third party",[48,1211,1212,1214,1216,1218],{},[69,1213,326],{},[69,1215,141],{},[69,1217,331],{},[69,1219,1220],{},"Mature NetworkPolicy, modest kernel requirements, well-documented operation for small teams",[48,1222,1223,1225,1227,1230],{},[69,1224,339],{},[69,1226,71],{},[69,1228,1229],{},"Upstream HAProxy, keepalived",[69,1231,1232],{},"Provides Service type LoadBalancer without depending on a cloud provider's load balancer",[48,1234,1235,1238,1240,1243],{},[69,1236,1237],{},"cert-manager with an internal PKI",[69,1239,355],{},[69,1241,1242],{},"Public ACME alone, manual issuance",[69,1244,1245],{},"Automates issuance while keeping the internal trust root under national control",[48,1247,1248,1250,1252,1254],{},[69,1249,366],{},[69,1251,369],{},[69,1253,372],{},[69,1255,1256],{},"TLS termination and routing, direct cert-manager integration, declarative configuration",[48,1258,1259,1261,1263,1266],{},[69,1260,380],{},[69,1262,383],{},[69,1264,1265],{},"Flux, CI pipelines pushing into the cluster",[69,1267,1268],{},"Makes the Git repository the source of truth, so every change becomes timestamped, attributable evidence",[10,1270,1271],{},"Several of these need commentary, because they are trade-offs rather than obvious calls.",[10,1273,1274,1277],{},[396,1275,1276],{},"On the installer."," Kubespray is heavy, slow, and its Ansible inventory quickly becomes an artifact you have to maintain yourself. Its two decisive qualities in this context are offline installation, which matters when international transit is expensive or cut, and the complete absence of any third-party service dependency across the cluster lifecycle. The newer distributions, RKE2 and especially Talos Linux, cut the attack surface significantly: Talos removes the host shell and package manager entirely and drives everything through an API, which serves EX-5 and EX-6 directly. A team with no existing Ansible culture will probably get further with RKE2 or Talos than with Kubespray. The deciding criterion is available skill, not intrinsic superiority.",[10,1279,1280,1283],{},[396,1281,1282],{},"On the CNI."," Calico is the sober choice here. Cilium, built on eBPF, offers richer policy, application-layer visibility and, with Hubble, flow observability that would genuinely contribute to EX-3. It is objectively the better tool for network auditing. It also demands recent kernels, an understanding of eBPF to debug the awkward cases, and it moves part of the network behaviour into a layer few teams can inspect. Recommending Calico here is an owned operability choice, not a value judgement: in a team fluent in eBPF, Cilium is the better call.",[10,1285,1286,1289],{},[396,1287,1288],{},"On load balancing."," MetalLB in BGP mode is clearly superior to layer 2 mode, which funnels all of a service's traffic through a single node. But BGP mode assumes cooperation with the network team, a peering session on the routers, and a shared understanding of the addressing plan. In a public administration this is almost always where the project stalls, and the blocker is organisational rather than technical. Anticipating that conversation at design time saves months.",[10,1291,1292,1295],{},[396,1293,1294],{},"On the PKI, which is the most underrated point here."," Two trust planes must be separated, and they are routinely conflated. Publicly exposed services need certificates trusted by browsers the state does not control: ACME and a public authority remain the rational choice, the constraint being endured rather than chosen. Internal traffic is a different matter. Service-to-service mTLS, cluster component certificates, node and agent authentication all rest on a trust root. If that root is a foreign authority, then the internal authentication of a sovereign platform depends on a third party outside the jurisdiction, with its revocation policy, its terms of service and its availability. An internal root held by the state, kept offline, with intermediate authorities issuing through cert-manager, solves this cleanly. It is cheap to set up and rarely done, and it is one of the few places where sovereignty is actually earned rather than declared.",[10,1297,1298,1301],{},[396,1299,1300],{},"On GitOps as an evidence mechanism."," Argo CD is chosen here not for deployment convenience but for its evidentiary value. When the Git repository is the source of truth, every platform change becomes a signed, reviewed, timestamped commit attributed to a named person. Answering an auditor who asks who changed a given service's network policy and when no longer means digging through raw logs, it means showing a history designed to be read. That serves EX-3 and contributes to EX-12.",[10,1303,1304],{},"Two conditions make that evidentiary value real, and without them the argument collapses. First, direct write access to the cluster must be locked down: if teams can still apply manifests by hand, the Git history describes an imaginary cluster. Second, the Git repository itself becomes a regulated asset, subject to the same retention, integrity and access control requirements as the logs, which means hosting it on the sovereign platform and not at a foreign code host. A sovereign platform whose source of truth lives in a repository under foreign jurisdiction has moved the problem rather than solved it.",[34,1306,1308],{"id":1307},"storage","Storage",[10,1310,1311],{},"Storage is where EX-2 is won or lost, and it is also where teams most often overestimate themselves.",[10,1313,1314],{},"The guiding principle is simple: pick the simplest solution that meets the continuity objectives, not the most capable one. The recommendation is tiered, because there is no single right answer.",[10,1316,1317],{},"For a modest usable volume, one primary room and a small team, a storage array exposed over NFS or iSCSI, complemented by local storage for workloads that do not need replication, is a defensible choice. Everyone understands it, everyone can restore from it, and its failure mode is diagnosable at three in the morning on a Sunday.",[10,1319,1320],{},"For an intermediate volume, Longhorn brings block-level replication across nodes, snapshots, and backup to an object target, at an operational cost far below that of a full distributed system. Its limit is real on I\u002FO-intensive workloads, particularly active databases.",[10,1322,1323],{},"For a large volume, multiple rooms, or a need for object storage alongside block, Ceph is the technically correct answer: block through RBD, object through RGW, filesystem through CephFS, all in one replicated system. But it is worth being blunt about what that implies. Ceph demands dedicated, permanent expertise, not a one-off ramp-up. A poorly sized or poorly operated Ceph is a major failure mode, capable of taking the whole platform down, and recovering it requires expertise you cannot acquire under pressure. The practical rule is that a Longhorn you understand beats a Ceph you endure.",[10,1325,1326],{},"On the compliance side, what this choice buys is decisive. In a managed cluster, a StorageClass is a name that hides a regional service whose replication geography is neither visible nor negotiable. Here, each StorageClass maps to a set of disks whose chassis, room and address are known. EX-2 stops being a good-faith declaration and becomes a verifiable inventory, which is exactly the first gap from article 1 closing.",[10,1328,1329],{},"Encryption at rest (EX-7) is handled at two levels that do not substitute for each other. Encrypting the underlying disks, through LUKS on the devices or the storage system's native mechanism, protects against hardware theft and mishandled decommissioning. It does not protect against legitimate logical access to a running system. For the most sensitive data, application-level encryption, with keys never held by the infrastructure layer, is the only measure that withstands a platform administrator. Which data categories deserve that second level should be an explicit decision, rather than encrypting the disks and considering the matter closed.",[10,1331,1332],{},"Backup combines three distinct things that are often conflated: volume snapshots, which protect against application error and live in the same storage system; backup of Kubernetes objects and volumes, with Velero for instance, to a local object target; and the off-site copy in the second room, which is the only one that protects against losing the primary site. Object lock on the backup target satisfies EX-5 by making backups immutable for their retention period, which is also the most effective control against ransomware that would try to destroy backups before encrypting production.",[10,1334,1335],{},"One point deserves to be stated without hedging: a backup never restored is not a backup, and EX-9 requires a measured RTO and RPO, not declared ones. A full restore exercise, scheduled, timed and documented, at least twice a year, is the only admissible evidence. It is also the first thing operational pressure drops.",[10,1337,1338],{},"Databases deserve an explicit decision. Running them in-cluster with a mature Operator such as CloudNativePG brings genuine automation of failover, continuous backup and point-in-time recovery. It also places an autonomous controller on the critical path of personal data, which is exactly the accountability gap described in article 1. The answer is not to give it up, it is to document it under EX-12: which Operator, which permissions, which destructive actions are possible, which team owns it, and what guardrails apply to operations that delete or move data.",[34,1340,1342],{"id":1341},"identity-and-authorisation","Identity and authorisation",[10,1344,1345],{},"This is where the second structural requirement, EX-4, is settled, and it is the part of the architecture most often treated lightly even though it carries most of the compliance value.",[10,1347,1348],{},"The foundation is a single identity provider, Keycloak in this reference architecture, federating the agencies' existing directories rather than claiming to replace them. That nuance matters: in a public administration each agency has its directory, its habits and its governance, and a project that requires migrating every directory into a central repository fails for political reasons before it fails for technical ones. Federation centralises authentication without centralising account ownership.",[10,1350,1351],{},"Human access to the cluster goes through OIDC against that provider. The practical consequence is the end of unlimited-lifetime kubeconfig files carrying a client certificate, which circulate over email and outlive their holder's departure. Every administrative access becomes named, expiring and revocable from one place, and the API server audit log stops recording anonymous identities.",[10,1353,1354],{},"That settles accountability for access to the platform. It does not settle accountability for access to the data, which is what the law actually asks for. That is the job of the application authorisation layer.",[10,1356,1357],{},"The reference architecture uses a relationship-based model, with OpenFGA, inspired by Google's Zanzibar system. The reasoning is as follows. Rights in a public administration do not decompose into global roles, because they almost always depend on the relationship between the officer and the object: the caseworker assigned to this specific file, the line manager of the applicant, the agency the citizen belongs to, the deputy designated during leave, the department that temporarily delegated a competence to another. Modelling that with roles produces either a combinatorial explosion of roles, one per file or per perimeter, or authorisation logic scattered through each application's business code, where it becomes invisible, untestable and unauditable. A relationship model expresses those situations directly, and more importantly it centralises them in a single artifact.",[10,1359,1360],{},"The decisive argument for this article, though, is not modelling, it is evidence. An authorisation decision evaluated by a dedicated service is an event: a subject, a relation, an object, a result, a timestamp, a context. Logged, it constitutes exactly the trail that article 41 of the decree and article 69 ask for, at the level they ask for it, which is the data level rather than the infrastructure level. The API server audit log can tell you that a deployment's ServiceAccount listed Secrets; it will never tell you that a named officer viewed a named citizen's tax file on Tuesday at two in the afternoon. The authorisation decision log can, provided the architecture makes that possible.",[10,1362,1363],{},"That proviso is end-to-end identity propagation. It deserves to be stated precisely, because it is the point where most systems break the chain. The user's identity must travel from authentication down to the data access layer without being replaced along the way by a service identity. Three common practices break that chain: a connection pooler that funnels all database access through a single technical account, an intermediate API layer that re-authenticates with its own identity, and batch processing that acts on a user's behalf without retaining the reference to that user. Each of those breaks turns a named trail into a service trail, and makes EX-4 unsatisfiable regardless of the rest of the tooling. Design must therefore treat identity propagation as a first-order requirement, not an implementation detail.",[10,1365,1366],{},"The risks this layer introduces must be owned. The identity provider becomes a first-order single point of failure: if it goes down nobody signs in to anything, and it also becomes the most attractive target on the platform. It therefore requires real redundancy, tested backups of its database and its signing keys, and dedicated monitoring. The authorisation service adds one more call on the critical path of every request, with its consequences for latency and availability, which forces a caching strategy and a predefined degraded behaviour: denying or allowing when it is unavailable is a policy decision, not a default to discover during an incident. Finally, the authorisation model becomes a critical artifact to version, test and deploy with the same rigour as application code, because a modelling error there has the effect of a security flaw.",[34,1368,1370],{"id":1369},"observability-and-the-audit-trail","Observability and the audit trail",[10,1372,1373],{},"The most expensive confusion in this whole architecture is believing that observability covers auditing. These are two systems with two purposes, two audiences, two retention policies and two levels of integrity requirement. Merging them produces a stack that serves neither operations nor compliance well.",[10,1375,1376],{},"Operational telemetry exists to run the platform. Metrics with Prometheus, alerting with Alertmanager, visualisation with Grafana, application logs with Loki or an equivalent, distributed tracing if the application landscape warrants it. Its audience is the on-call team, its useful horizon is days or weeks, sampling is legitimate, and data loss is an inconvenience. It should be sized for diagnostic comfort, not for proof.",[10,1378,1379],{},"The regulatory audit trail exists to prove. It brings together four sources that are not interchangeable: API server auditing with an explicit policy, generally at metadata level for most resources and at request-and-response level for sensitive ones; personal data access logs emitted by the applications; authorisation decisions; and database access logs. Its audience is an auditor or a regulator, its horizon is twelve months minimum under EX-3, sampling is disqualifying, integrity is required under EX-5, and access to it must itself be restricted and logged.",[10,1381,1382],{},"The practical implication is that you need two storage destinations and two distinct policies. A Loki sized for fifteen days of retention proves nothing at day minus three hundred. Trace sampling that divides volume by ten destroys the evidentiary value of what it discards. An automatic purge policy designed to control storage costs can erase, with no intent and no alert, exactly the evidence an inspection will demand. All three mistakes are common and are discovered at the worst possible moment.",[10,1384,1385],{},"The twenty-four hour notification requirement (EX-8) needs its own attention, because it is usually treated as a documentation checkbox when it is in fact a timed process. Three questions must have a written answer before any incident. When the clock starts: at detection, which is the prudent reading, and not at legal qualification, otherwise the deadline becomes indefinitely extensible and indefensible. Who decides to notify, with a named deputy, because major incidents rarely occur during office hours. Through which channel, with what minimum content, to which recipient, and with what record of sending. An Alertmanager alert is not a regulatory notification, and the gap between the two is measured in hours lost looking for who has whose phone number.",[10,1387,1388],{},"One last point of method: compliance dashboards and operational dashboards should be separate. The former answers questions such as encryption coverage, the age of the last restore test, the number of workloads without a NetworkPolicy, the proportion of named administrative accesses. Those indicators are of no interest to the on-call engineer and are read once a month, but they turn compliance from a painful annual exercise into a continuously observed property.",[34,1390,1392],{"id":1391},"the-operating-model","The operating model",[10,1394,1395],{},"An architecture is only worth what an organisation can sustain. This is the part architecture documents most often omit, and it is the part that determines whether the project still exists in three years.",[10,1397,1398],{},"Four roles are necessary, and these are roles rather than headcount. Platform operations covers the cluster, network, storage and upgrades. Security and compliance covers policy, the audit trail, access reviews and incident response. The data role covers databases, backups and restore exercises. A design role maintains the coherence of the whole and arbitrates the hosted agencies' requests, without which the platform drifts into a collection of special cases.",[10,1400,1401],{},"Those roles require redundancy. A role held by one person is not held, it is borrowed from an individual until they leave or take leave. This is an experience-based judgement and I give it as such: below roughly five or six people covering those four roles with effective doubling, a platform of this kind is carried by individuals rather than by an organisation, and one departure becomes a major incident. That threshold is not a standard, it is an order of magnitude meant to be argued about during sizing rather than discovered afterwards.",[10,1403,1404],{},"The genuinely scarce skills in the sub-region are identifiable and should guide the technical choices. Operating a distributed storage system, BGP networking, running a PKI, structured incident response, and operating Kubernetes in the proper sense, which is a different thing from using it. Those skills are hard to hire and harder to retain, because the international market pays for them at levels a public administration cannot match. The architectural consequence has already been stated for storage and holds everywhere: systematically prefer the component the team can operate over the one that is technically superior. An architecture that assumes skills the organisation does not have is an architecture that will fail, however good it looks on paper.",[10,1406,1407],{},"On costs, I give a method rather than figures, and that decision deserves justifying. Publishing amounts that have not been measured in the target context would create a false anchor, and a figure imported from a European or North American comparison does not transfer: energy cost, salary cost, import duties and taxes on hardware, and international transit cost differ by enough to invert a conclusion. A serious costed analysis is a piece of work in its own right, with local sources, and it deserves its own article.",[10,1409,1410],{},"The method itself is stable. A five-year total cost of ownership is built on seven items. Hardware, servers, network and storage, amortised over five years, with an annual replacement rate for failures. Physical hosting, room, energy, cooling and electrical redundancy, an item that is regularly underestimated and particularly sensitive in a context where public grid supply is irregular and where the UPS and the generator are not optional. Connectivity, including the link between the two rooms. Support and subscriptions, including whichever distributions and commercial tools are retained. Human cost, which is the dominant item over five years by a wide margin. Training and certification, which are not an adjustment variable but the condition of the previous item. And audit and compliance, including internal time consumed by inspections.",[10,1412,1413],{},"Two items fall outside those seven and must be added explicitly. The ramp-up cost, meaning the period during which the team is paid to learn and produces less. And the exit cost, meaning what it would take to migrate off this architecture if the decision were reversed, a question nobody asks at investment time and everybody regrets not asking.",[10,1415,1416],{},"The structuring economic property of this architecture is that its cost is mostly fixed. Unit cost per hosted service therefore falls as the platform fills up, which is the exact inverse of an elastic bill. That shifts the right question. It is not which of the two options is cheaper in absolute terms, but at what usage level the two curves cross, and to note that a platform shared across several agencies reaches that crossing point far sooner than one dedicated to a single agency.",[34,1418,1420],{"id":1419},"field-lessons","Field lessons",[10,1422,1423],{},"What follows are failure patterns observed across the sector, stated at sector level. They target no organisation and describe none. Their value is that they repeat: the same ones keep coming back, and they are almost always failures of discipline rather than of design.",[10,1425,1426],{},"Configuration drift leads the list. Without effective lockdown of direct cluster access, actual state gradually diverges from declared state, often for good reasons during the pressure of an incident. The symptom only appears much later: nobody dares rebuild a component any more, because nobody knows what was adjusted by hand and recorded nowhere.",[10,1428,1429],{},"The backup never restored is the most expensive classic. The backup job runs and reports success for two years, and the first restore attempt happens on the day it is vital. That is also the day you find out the backup did not contain everything it needed to, or that the real RTO is an order of magnitude above the announced one.",[10,1431,1432],{},"The etcd store is regularly forgotten. Many teams carefully back up application volumes without separately backing up cluster state, even though losing it is losing the cluster, and backing it up is both trivial and fast.",[10,1434,1435],{},"The identity provider installed temporarily as a single instance stays a single instance. It gets deployed early, to unblock other work, with a sincere intention to make it redundant later. It then becomes the component everything else depends on, and making it redundant requires a maintenance window nobody wants to own.",[10,1437,1438],{},"Certificates cause more incidents than attacks. The first major incident on an internal PKI is almost never a compromise, it is an expiry, often on an intermediate component nobody had put on a calendar. Automating issuance is not enough: it is the certificates outside cert-manager's scope, those on appliances and legacy systems, that expire.",[10,1440,1441],{},"The deferred upgrade turns routine into a project. Kubernetes moves at a sustained pace, and being two or three versions behind changes the nature of the exercise: it is no longer an upgrade, it is a migration, with API removals to handle and a risk profile that justifies deferring it again.",[10,1443,1444],{},"Finally, compliance discovered late. An architecture designed with the requirements from the start, as the first section of this article does, costs a fraction of what the same compliance costs when retrofitted three weeks before an inspection. That is not a moral argument, it is a cost observation.",[34,1446,1448],{"id":1447},"limits-of-this-architecture","Limits of this architecture",[10,1450,1451],{},"A reference architecture that does not say where it fails is not usable. Here are the cases where this one is the wrong choice, and the limits of the sovereignty it delivers.",[10,1453,1454],{},"It serves unpredictable peak workloads poorly. Sizing is done for the peak, so a workload whose peak is rare and far above its average is paid for in idle capacity all year. That is precisely why the scope declared above insists on the predictability of administrative peaks: if that assumption fails, the economic trade-off changes.",[10,1456,1457],{},"It does not provide access to advanced managed services. Large-scale analytical warehouses, managed artificial intelligence services and globally distributed databases have no self-hosted equivalent at comparable cost. Reproducing those services in house costs more than the dependency you were trying to avoid, and that should be admitted rather than papered over with the claim that the open ecosystem covers everything.",[10,1459,1460],{},"A single machine room provides no real continuity, and two rooms close together do not protect against a regional disaster, an extended power outage or a flood. The distance between sites is a design parameter, not a logistical detail.",[10,1462,1463],{},"The sovereignty obtained is jurisdictional and operational, not industrial, and that is the most important limit in this entire article. The servers, their firmware, their out-of-band management controllers and their network components are not sovereign: they are designed and manufactured elsewhere, and their supply chain is entirely beyond the reach of the state buying them. The out-of-band management controller deserves a special mention, because it constitutes a complete administrative surface, often left in a poorly segmented network, with default credentials and rarely updated firmware. A platform that is rigorous at the Kubernetes level and negligent at the hardware management level is not secure, it is badly audited.",[10,1465,1466],{},"The upstream open source dependency is real. The chosen components are developed by communities and companies outside the jurisdiction, with their own end-of-support decisions, their own licence changes, and their own pace of vulnerability fixes. Without organised monitoring and internal patching capacity, \"open source\" means \"free\", not \"under control\". The software supply chain extends that point: container images, Helm charts and operators pulled from public repositories enter the platform with a level of verification that is often nil. A local registry with vulnerability scanning and signature verification is necessary, failing which independence stops at the hardware layer.",[10,1468,1469],{},"Finally, the limit already set out in the previous article stands, and it bears repeating here to avoid any misunderstanding: a poorly operated sovereign platform is less safe than a well operated foreign one. This architecture does not remove the need for independent audit, it makes that audit possible. Being local is not a security qualification, it is a jurisdictional property.",[34,1471,1473],{"id":1472},"an-honest-comparison-with-the-alternatives","An honest comparison with the alternatives",[10,1475,1476],{},"The table below compares four realistic options for a West African administration, on criteria derived from the requirement set rather than from vendor positioning.",[42,1478,1479,1498],{},[45,1480,1481],{},[48,1482,1483,1486,1489,1492,1495],{},[51,1484,1485],{},"Criterion",[51,1487,1488],{},"Sovereign bare metal (this architecture)",[51,1490,1491],{},"Managed Kubernetes at a national operator",[51,1493,1494],{},"Hyperscaler with a local region",[51,1496,1497],{},"Colocation at a national operator, state-operated",[64,1499,1500,1517,1533,1550,1567,1584,1600,1616,1633],{},[48,1501,1502,1505,1508,1511,1514],{},[69,1503,1504],{},"Responsible establishment (EX-1)",[69,1506,1507],{},"Met, the state or its operator is the establishment",[69,1509,1510],{},"Met if the operator is locally established",[69,1512,1513],{},"Partial, the contracting entity may be local but control runs back to the parent",[69,1515,1516],{},"Met",[48,1518,1519,1522,1525,1528,1531],{},[69,1520,1521],{},"Transfer to a third country (EX-2)",[69,1523,1524],{},"No transfer by design",[69,1526,1527],{},"None if the operator does not subcontract outside the jurisdiction, to be verified contractually",[69,1529,1530],{},"Persistent exposure through the control plane and group jurisdiction",[69,1532,1524],{},[48,1534,1535,1538,1541,1544,1547],{},[69,1536,1537],{},"Control plane",[69,1539,1540],{},"Entirely local and auditable",[69,1542,1543],{},"Local, but operated by a third party whose access must be audited",[69,1545,1546],{},"Outside the jurisdiction in most cases",[69,1548,1549],{},"Entirely local",[48,1551,1552,1555,1558,1561,1564],{},[69,1553,1554],{},"Single audit trail (EX-3, EX-5)",[69,1556,1557],{},"One coherent trail",[69,1559,1560],{},"One trail, but shared with the operator",[69,1562,1563],{},"Format and retention imposed by the provider",[69,1565,1566],{},"One trail",[48,1568,1569,1572,1575,1578,1581],{},[69,1570,1571],{},"Elasticity",[69,1573,1574],{},"Low, sized for the peak",[69,1576,1577],{},"Medium, bounded by the operator's capacity",[69,1579,1580],{},"High",[69,1582,1583],{},"Low",[48,1585,1586,1589,1592,1595,1598],{},[69,1587,1588],{},"Advanced managed services",[69,1590,1591],{},"Absent",[69,1593,1594],{},"Rare",[69,1596,1597],{},"Extensive",[69,1599,1591],{},[48,1601,1602,1605,1608,1611,1614],{},[69,1603,1604],{},"Cost structure",[69,1606,1607],{},"Mostly fixed, decreasing unit cost",[69,1609,1610],{},"Mixed",[69,1612,1613],{},"Variable, stable unit cost",[69,1615,1610],{},[48,1617,1618,1621,1624,1627,1630],{},[69,1619,1620],{},"Internal skills required",[69,1622,1623],{},"High, across the whole stack",[69,1625,1626],{},"Medium, substrate operation is delegated",[69,1628,1629],{},"Low on the substrate, high on usage",[69,1631,1632],{},"High, excluding building and power",[48,1634,1635,1638,1641,1644,1647],{},[69,1636,1637],{},"Execution risk",[69,1639,1640],{},"High, concentrated on the organisation's ability to keep the team",[69,1642,1643],{},"Medium, shifted to the operator's robustness",[69,1645,1646],{},"Low technically, high legally",[69,1648,1580],{},[10,1650,1651],{},"None of these columns wins everywhere, and that is the point. Colocation with state operation is often the most realistic compromise to start with: it removes the building, the power and the electrical redundancy from the equation, all of which are trades in their own right, while keeping the control plane and accountability inside the perimeter. Managed Kubernetes at a national operator is attractive if and only if that operator accepts a level of audit comparable to what the state would impose on itself, and if the contract explicitly prohibits any subcontracting outside the jurisdiction, including for third-line support, which is the usual blind spot in those contracts.",[10,1653,1654],{},"The hyperscaler with a local region retains a perfectly legitimate use, already described in the previous article: unregulated public content, workloads with no personal data, and one-off compute capacity needs on non-sensitive data. Rejecting it wholesale would be as unserious as adopting it wholesale.",[34,1656,1658],{"id":1657},"limits-of-the-analysis-and-open-questions","Limits of the analysis and open questions",[10,1660,1661],{},"This article is a reference architecture, not a measured case study. The choices are justified by requirements derived from legal texts and by operating practice, not by published, reproducible measurements on an identified deployment. A reader looking for comparative performance or cost figures will not find them here, and that is deliberate: publishing them without having measured them in the target context would have produced false precision.",[10,1663,1664],{},"The requirement derivation rests on the same interpretive extension owned in article 1. Decree 2018-062 primarily targets trust service providers, and treating its obligations as a baseline for a general-purpose compute platform is a reasonable but contestable reading. These requirements are written by an engineer and deserve review by a Togolese legal practitioner before being used in a contract or a public tender specification.",[10,1666,1667],{},"Several questions remain open and I would rather name them than dress them up. Whether a shared government platform qualifies as an essential services operator under Order 2022-040 is not obvious and changes part of the obligations. The evidentiary weight of a signed Git history before a regulator is, as far as I know, not established: the argument looks solid technically, but it has not been tested in an inspection. The status of an authorisation decision log as proof of access to personal data carries the same uncertainty. Finally, regional pooling, a platform shared between several WAEMU states, would raise a question of applicable law that neither the national texts nor the current community instruments settle clearly, even though that is probably the only path that makes the economics of this model genuinely favourable.",[10,1669,1670],{},"The core of the matter fits in one sentence. Digital sovereignty is not bought in a contract, it is designed into an architecture and proven in an audit. The work described here is not about reproducing a hyperscaler in miniature, it is about building a platform where every layer answers a named requirement, every choice owns what it costs, and the limits are written down before somebody else discovers them.",[34,1672,797],{"id":796},[799,1674,1675,1681,1688,1694,1700,1705,1710,1715,1720],{},[802,1676,1677,1678],{},"Decree No. 2018-062\u002FPR regulating electronic transactions and services in Togo, ",[14,1679,810],{"href":807,"rel":1680},[809],[802,1682,1683,1684],{},"Law No. 2019-014 of 29 October 2019 on the protection of personal data, ",[14,1685,1687],{"href":816,"rel":1686},[809],"Official Journal",[802,1689,1690,1691],{},"Law No. 2017-007 on electronic transactions, ",[14,1692,826],{"href":824,"rel":1693},[809],[802,1695,1696,1697],{},"Order No. 2022-040\u002FPMRT adopting cybersecurity rules in the Togolese Republic, ",[14,1698,834],{"href":832,"rel":1699},[809],[802,1701,837,1702],{},[14,1703,842],{"href":840,"rel":1704},[809],[802,1706,845,1707],{},[14,1708,842],{"href":848,"rel":1709},[809],[802,1711,852,1712],{},[14,1713,857],{"href":855,"rel":1714},[809],[802,1716,860,1717],{},[14,1718,865],{"href":863,"rel":1719},[809],[802,1721,1722,1723],{},"OpenFGA, authorization model documentation, ",[14,1724,873],{"href":871,"rel":1725},[809],[10,1727,1728],{},"This is an engineering and architecture analysis, not legal advice. For any compliance decision or use in a contractual document, consult a Togolese practitioner in data protection and public procurement law.",{"title":878,"searchDepth":879,"depth":879,"links":1730},[1731,1732,1733,1734,1735,1736,1737,1738,1739,1740,1741,1742,1743],{"id":945,"depth":879,"text":946},{"id":1129,"depth":879,"text":1130},{"id":1148,"depth":879,"text":1149},{"id":1173,"depth":879,"text":1174},{"id":1307,"depth":879,"text":1308},{"id":1341,"depth":879,"text":1342},{"id":1369,"depth":879,"text":1370},{"id":1391,"depth":879,"text":1392},{"id":1419,"depth":879,"text":1420},{"id":1447,"depth":879,"text":1448},{"id":1472,"depth":879,"text":1473},{"id":1657,"depth":879,"text":1658},{"id":796,"depth":879,"text":797},"The two previous articles showed where Togolese law and Kubernetes fail to meet, then why multi-cloud does not answer a jurisdictional question. This one proposes what to build: a reference architecture for a sovereign government cloud in the WAEMU context. Requirements derived from the legal texts, layer-by-layer design choices with their justifications, an operating model, stated limits, and an honest comparison with the alternatives. An architecture document, not a tutorial.",{},"\u002Fkubernetes\u002Fsovereign-govcloud-reference-architecture",{"title":920,"description":1744},"kubernetes\u002F3.sovereign-govcloud-reference-architecture",[906,907,908,909,910],[912,913,914,915,916],"tG9oeG8xUFWWbsqs9Kj5P0bTayN8oZy8P5Cc0QycH3o",[1753,1756],{"title":1754,"path":1755},"L'illusion du multi-cloud pour l'État : la duplication n'est pas la souveraineté","\u002Fkubernetes\u002Fmulti-cloud-illusion.fr",null,[1758,1766,1776],{"path":1755,"title":1754,"description":1759,"date":1760,"tags":1761,"topics":1764},"Le multi-cloud est vendu aux États africains comme la réponse à la fois à la résilience et à la souveraineté numérique : répartir ses charges entre plusieurs hyperscalers diluerait le risque et le pouvoir du fournisseur. Sous la loi togolaise 2019-014 sur les données personnelles et le régime de cybersécurité de l'ANCY, cette promesse ne tient pas. Cet article défend que le multi-cloud ne divise pas l'exposition juridique, il la multiplie, et se termine par un cadre de décision sur quand il est légitime et quand il ne l'est pas.","2026-08-07",[1762,906,1763,907,909],"Multi-Cloud","Cloud-Act",[912,913,1765],"finops",{"path":1767,"title":1768,"description":1769,"date":1770,"tags":1771,"topics":1775},"\u002Fkubernetes\u002Fdecret-2018-062-kubernetes-gap.fr","Décret 2018-062 et Kubernetes : le gap entre le texte et l'implémentation","Le Décret 2018-062, qui précise l'application de la loi togolaise 2017-007 sur les transactions électroniques, impose des obligations de sécurité, de traçabilité, de conservation et de continuité. Mais ces obligations ont été rédigées avec un modèle mental de serveur physique ou de VM. Kubernetes introduit des pods éphémères, un scheduling dynamique, des volumes provisionnés à la volée et des Operators. Cet article cartographie chaque obligation vers son équivalent Kubernetes natif, expose les vrais gaps où l'outil ne répond pas au texte, et propose des patterns d'implémentation. Angle juridico-technique, pas un tutoriel.","2026-07-23",[1772,907,1773,909,1774],"Compliance","Data-Protection","Governance",[912,914,915],{"path":1777,"title":1778,"description":1779,"date":1780,"tags":1781,"topics":1787},"\u002Fsecurity\u002Fauthz\u002Frbac-to-rebac.fr","De RBAC a ReBAC : migrer un systeme de roles vers OpenFGA sans coupure","Les roles marchent, jusqu'au jour ou quelqu'un dit 'partage juste ce document avec juste cette personne'. Ce jour-la, RBAC atteint ses limites. Voici la migration pratique : mapper les tables de roles vers des tuples de relation, faire tourner OpenFGA en shadow a cote de vos controles SQL, backfiller sans risque, puis seulement debloquer le partage par objet et la hierarchie que les roles n'ont jamais pu offrir. Avec les pieges dont personne ne parle.","2026-07-19",[1782,1783,1784,1785,1786],"Authorization","ReBAC","RBAC","OpenFGA","Migration",[916,1788,914],"backend",1786887554328]