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

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.

L'illusion du multi-cloud pour l'État : la duplication n'est pas la souveraineté

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.

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.

Comment le verrouillage à deux phases empêche vos transactions bancaires concurrentes de corrompre vos données

Deux virements touchent le même compte à la même milliseconde et un paiement s'évapore. C'est la mise à jour perdue, et c'est pour ça que tout registre de paiement repose sur une couche de contrôle de concurrence. Cet article construit la théorie depuis un exemple fintech jusqu'au verrouillage à deux phases (2PL) : le modèle de transaction, les maths de la conflit-sérialisabilité et le graphe de précédence, pourquoi le théorème du 2PL garantit la correction, le contrôle pessimiste contre optimiste dans PostgreSQL, le 2PL strict, et comment les interblocages sont détectés et évités.

Algorithmes de load balancing : chacun repare le defaut du precedent

Repartir des requetes sur N serveurs sonne comme un one-liner : choisir un serveur, envoyer la requete. Puis un backend est plus lent, ou plus gros, ou tient une session, et le choix naif s'effondre. On parcourt les algorithmes classiques comme une chaine ou chacun existe pour reparer l'angle mort du precedent : round robin, pondere, least connections, power of two choices, et consistent hashing, en Go, jusqu'a la panne que tous les tutos oublient.

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.