Infrastructure cloud souveraine pour l’enseignement supérieur béninois

Infrastructure cloud souveraine pour l'enseignement supérieur béninois

Le contexte

Le Bénin compte quatre universités publiques — l’Université d’Abomey-Calavi (UAC), l’Université Nationale d’Agriculture (UNA), l’Université Nationale des Sciences, Technologies, Ingénierie et Mathématiques (UNSTIM), et l’Université de Parakou (UP). Ensemble, elles accueillent plus de 200 000 étudiants.

Avant RBER, chaque université gérait son infrastructure de façon isolée — serveurs vieillissants, licences coûteuses, données dispersées, pas de continuité de service. La question n’était pas seulement technique : c’était une question de souveraineté numérique.

L'architecture choisie

Après audit des contraintes — budget, compétences locales, exigences de disponibilité, capacité réseau — nous avons opté pour une stack full open-source sur serveurs HPE DL380 Gen10+, déployée sur deux sites géographiques.

Hyperviseur	Harvester HCI, HPE DL380 Gen10+, 2 sites HA
Orchestration	RKE2 Kubernetes, 3 etcd nodes, 3 control plane, 3 workers
Stockage	Longhorn, MinIO S3, ReadWriteMany PVCs
Base de données	CloudNativePG, PostgreSQL 16, Barman backups
Réseau	MetalLB, HAProxy Ingress, Cert-manager
Identité	Keycloak SSO, LDAP federation, OIDC / SAML
Observabilité	Prometheus, Thanos, Loki, Grafana, Alertmanager
Backups	Velero, HPE StoreOnce, Synology NAS

Deux sites, une seule plateforme

Le site principal est à Fidjrossè, Cotonou. Le site secondaire à Parakou assure la résilience géographique. Les deux sont interconnectés via les VLANs universitaires dédiés à chaque établissement.

Site	Rôle	Infrastructure	Statut
Fidjrossè	Primaire — cluster RKE2 complet	3 etcd + 3 CP + 3 workers · HAProxy VIP	Opérationnel
Parakou	Secondaire — extension UP	Harvester nodes · HAProxy local	Opérationnel

Les services déployés

Chaque université dispose d’un namespace Kubernetes isolé. Voici les services communs à toutes les instances :

Hyperviseur	Harvester HCI, HPE DL380 Gen10+, 2 sites HA
Orchestration	RKE2 Kubernetes, 3 etcd nodes, 3 control plane, 3 workers
Stockage	Longhorn, MinIO S3, ReadWriteMany PVCs
Base de données	CloudNativePG, PostgreSQL 16, Barman backups
Réseau	MetalLB, HAProxy Ingress, Cert-manager
Identité	Keycloak SSO, LDAP federation, OIDC / SAML
Observabilité	Prometheus, Thanos, Loki, Grafana, Alertmanager
Backups	Velero, HPE StoreOnce, Synology NAS

Isolation par namespace — l'exemple Moodle

Chaque université dispose de son propre namespace Kubernetes, son cluster PostgreSQL CloudNativePG, son volume Longhorn et ses secrets. Zéro partage de données entre établissements.

yaml · namespace moodle-uac

# Cluster PostgreSQL dédié UAC — CloudNativePG
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: uac-pg-cluster
  namespace: moodle-uac
spec:
  instances: 3   # 1 primary + 2 replicas
  storage:
    size: 80Gi
    storageClass: longhorn
  backup:
    barmanObjectStore:
      destinationPath: s3://rber-backups/moodle-uac/
    retentionPolicy: "30d"

Ce qu'on a appris

Ce projet était notre premier déploiement de cette échelle en production sur infrastructure HCI locale. Voici les points les plus structurants :

01- Longhorn thin provisioning ≠ usage réel. L’allocation affichée peut dépasser 80% alors que l’utilisation effective est sous 15%. Toujours vérifier « Actual Size » avant d’intervenir sur le stockage.
02- Les NetworkPolicies ne sont pas optionnelles en production. Le modèle « default deny all » avec règles explicites a sauvé plusieurs fois des incidents de propagation. Chaque namespace a son propre jeu de 117 politiques réseau.
03- MetalLB pour les services mail, pas NodePort. iptables bloque le trafic direct sur NodePort pour les protocoles TCP mail — seul un LoadBalancer MetalLB avec IP dédiée fonctionne correctement à grande échelle.
04- MinIO : toujours utiliser l’IP interne pour les uploads multipart. L’endpoint public via HAProxy génère des erreurs 400. L’accès direct à 10.29.112.150:9000 est indispensable pour les backups et archivages WAL.
05- La documentation en temps réel fait la différence. Chaque incident résolu a produit un runbook. La base de connaissances est maintenant le premier réflexe de l’équipe avant toute intervention.

La suite

La plateforme RBER est opérationnelle mais pas figée. Les prochains chantiers incluent :

Court terme : migration Moodle UNSTIM depuis l’ancien serveur legacy, déploiement Moodle UAC/UNA/UP, intégration LDAP par université.

Moyen terme : fédération AfricaConnect et eduGAIN pour ouvrir la plateforme aux réseaux académiques africains et mondiaux, quatrième nœud worker RKE2 pour rééquilibrer les réplicas Longhorn, déploiement Kea DHCP pour l’isolation VLAN des campus.

Long terme : extension du modèle RBER à d’autres pays d’Afrique de l’Ouest. L’architecture est documentée, reproductible, et entièrement open-source.

admin 21/05/2026