Architecture de référence pour un cloud gouvernemental souverain

Deux articles ont préparé celui-ci. Le premier a cartographié 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 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.

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.

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.

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.

Le cahier des charges dérivé du texte

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.

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.

Périmètre et hypothèses

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.

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é.

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.

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.

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.

Choix fondamental : bare-metal, virtualisation, ou les deux

C'est la décision qui contraint toutes les suivantes, et elle se prend sur des critères de conformité autant que de performance.

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.

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.

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.

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.

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.

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.

La couche d'orchestration

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.

Ces choix demandent des commentaires, parce que plusieurs sont des compromis et non des évidences.

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.

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.

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.

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.

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.

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.

Le stockage

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Identité et autorisation

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é.

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.

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.

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.

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.

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.

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.

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é.

Observabilité et piste d'audit

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é.

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.

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é.

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.

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.

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.

Le modèle opérationnel

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.

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.

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.

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.

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.

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.

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.

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.

Enseignements de terrain

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.

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.

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é.

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.

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.

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.

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.

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.

Limites de l'architecture

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.

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.

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.

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.

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.

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.

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.

Comparaison honnête avec les alternatives

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.

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.

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.

Limites de l'analyse et questions ouvertes

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.

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.

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.

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.

Sources

• Décret n°2018-062/PR portant réglementation des transactions et services électroniques au Togo, ARCEP
• Loi n°2019-014 du 29 octobre 2019 relative à la protection des données à caractère personnel, Journal Officiel
• Loi n°2017-007 relative aux transactions électroniques, numerique.gouv.tg
• Arrêté n°2022-040/PMRT portant adoption des règles de cybersécurité en République togolaise, CERT Togo
• Kubernetes, Encrypting Confidential Data at Rest, kubernetes.io
• Kubernetes, Auditing, kubernetes.io
• Kubespray, kubernetes-sigs/kubespray
• R. Pang et al., Zanzibar: Google's Consistent, Global Authorization System, USENIX ATC 2019, USENIX
• OpenFGA, documentation du modèle d'autorisation, openfga.dev

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.