Historique des versions

Version Date Rédacteur Description

1.0.0

18/06/2026

Équipe Technique

Version initiale

1.1.0

11/10/2026

Équipe Technique

Mise à jour d’ensemble. Les cas d’utilisation, les règles de gestion et les scénarios de recette sont alignés sur le comportement attendu de la solution. Les schémas de données, les vues d’exécution et les diagrammes de séquence sont repris sur le modèle et les échanges livrés. Le dictionnaire des données est ramené aux tables structurantes, le modèle complet étant porté en annexe. Les documents sont mis en cohérence entre eux sur les statuts, les rôles, les interfaces et les nomenclatures.

Diffusion

Destinataires Pour validation Pour information

COPIL

X

Validation

Représentants Valideur Date

DCE

MND

ASIN

MESRS - DSI

UNIVERSITÉS - DSI

DSI Présidence

1. Introduction et Objectifs

1.1. Vue d’ensemble

L’infrastructure BDESDCE (Base de Données sur l’Enseignement Supérieur - Délégation au Contrôle et à l’Éthique) est une plateforme cloud-native complète construite sur Kubernetes, fournissant des services de niveau entreprise pour la gestion des données d’enseignement supérieur, la collaboration institutionnelle et le contrôle éthique.

Cette infrastructure héberge les applications BDES : bdes-evaluation et bdes-referentiel, ainsi que l’ensemble des services techniques partagés nécessaires à leur fonctionnement.

1.1.1. Mission BDES

La plateforme Base de Données sur l’Enseignement Supérieur (BDES) supporte la Délégation au Contrôle et à l’Éthique (DCE) dans la gestion et l’analyse des données de l’enseignement supérieur à travers les institutions. Cette infrastructure permet :

  • Gouvernance des Données : Gestion centralisée des données institutionnelles avec contrôles d’accès appropriés

  • Supervision Éthique : Outils et workflows pour assurer les standards éthiques dans le traitement des données

  • Analyses Institutionnelles : Capacités d’analyses avancées pour les institutions

  • Gestion de Conformité : Infrastructure supportant la conformité réglementaire

  • Collaboration Sécurisée : Plateforme pour le partage sécurisé de données entre parties prenantes

1.1.2. Caractéristiques Clés

  • Plateforme : Kubernetes 1.31.4 sur Ubuntu 22.04/24.04 LTS

  • Pattern d’Architecture : Microservices cloud-native

  • Haute Disponibilité : Déploiements multi-réplicas avec équilibrage de charge

  • Sécurité : TLS partout avec certificats Let’s Encrypt automatisés

  • Stockage : Stockage distribué haute performance avec OpenEBS Mayastor

  • Surveillance : Stack d’observabilité complète avec Prometheus, Grafana et Loki

  • Recherche : OpenSearch avec synchronisation PostgreSQL temps réel

1.1.3. Environnements

  • DEV : Environnement de développement sur domaine dev.testbdes.yes.bj

  • STAGING : Environnement de pré-production pour validation fonctionnelle sur domaine testbdes.yes.bj

  • PROD : Environnement de production multi-sites avec haute disponibilité

1.2. Objectifs principaux

Objectif Description Indicateurs

Haute disponibilité

Uptime 99.9% minimum avec failover automatique en moins de 30 secondes. Architecture multi-réplicas pour tous les services critiques avec basculement transparent.

SLA 99.9%, Failover <30s, MTBF >8760h

Scalabilité

Auto-scaling horizontal selon la charge applicative. Capacité de supporter jusqu’à 50 000 utilisateurs concurrents avec un débit de 5000+ req/s en charge nominale.

HPA configuré, 50K users, 5000+ req/s

Sécurité

Architecture Zero Trust avec isolation réseau stricte (Network Policies Calico), secrets chiffrés at-rest et in-transit, RBAC Kubernetes granulaire, scan de vulnérabilités automatisé (Trivy).

TLS partout, Scan quotidien, RBAC actif

Observabilité

Monitoring centralisé multi-niveaux (infrastructure, plateforme, application) avec Prometheus/Grafana, logs agrégés avec Loki, métriques temps réel et alerting automatique.

Métriques <30s, Logs centralisés, Alertes temps réel

Performance

Latence P95 < 500ms pour 95% des requêtes, stockage haute performance avec OpenEBS Mayastor (>50K IOPS), latence réseau <5ms entre nœuds.

P95 <500ms, >50K IOPS, Latence réseau <5ms

Déploiement automatisé

CI/CD GitOps avec déploiement automatique, rolling updates sans downtime, rollback automatique en cas d’échec, validation automatisée post-déploiement.

GitLab CI/CD, Rollback auto, Zero downtime

Résilience

Tolérance aux pannes avec réplication de données, sauvegarde automatisée (RPO < 4 h, RTO < 2 h sur le site principal), reprise d’activité sur le site de secours (RTO 4 h).

RPO < 4 h, RTO < 2 h sur site, 4 h sur bascule

1.3. Parties prenantes

Les parties prenantes de la plateforme BDES sont documentées de manière centralisée dans le Document d’Architecture Technique (DAT).

Voir : DAT - Contexte et Enjeux > Parties Prenantes

2. Contraintes d’Architecture

Les contraintes générales (sécurité, conformité, hébergement souverain) sont documentées dans le DAT.

Ce document liste les contraintes spécifiques au provisionnement infrastructure.

2.1. Contraintes Plateforme

Contrainte Valeur

Kubernetes

1.31.4+ (containerd, Calico CNI)

OS

Ubuntu 22.04/24.04 LTS uniquement

Stockage

OpenEBS Mayastor

Swap

Désactivé sur tous les nœuds

2.2. Contraintes Réseau Provisionnement

Élément Configuration

Ports Control Plane

6443, 2379-2380, 10250, 10259, 10257

Ports Workers

10250, 30000-32767

Ports OpenEBS

10124, 8420

Packages Système

open-iscsi, lvm2 (modules iscsi_tcp, libiscsi)

2.3. Contraintes Open-Source

Pas de licences commerciales :

  • Orchestration : Kubernetes

  • Stockage : OpenEBS

  • BDD : PostgreSQL (CloudNativePG)

  • IAM : Keycloak

  • Monitoring : Prometheus/Grafana

3. Contexte et Périmètre

L’architecture fonctionnelle, les composants et les interfaces sont documentés dans :

Ce document définit le périmètre du provisionnement infrastructure.

3.1. Périmètre Infrastructure

3.1.1. Dans le Périmètre (provisionné par ce STD)

  • Cluster Kubernetes multi-master HA

  • Stockage distribué OpenEBS Mayastor

  • Load balancing HAProxy + Keepalived

  • Stack monitoring (Prometheus, Grafana, Loki)

  • CI/CD GitLab Runner

3.1.2. Hors Périmètre

  • Applications métier (bdes-evaluation, bdes-referentiel) → STD applicatifs

  • Réseau physique (switches, routeurs, pare-feux hardware)

  • Infrastructure datacenter (alimentation, climatisation)

  • X-ROAD Security Server (infrastructure gouvernementale externe)

3.2. Topologie Réseau

network topology

3.3. Segmentation VLANs

VLAN Réseau Usage

100 (DMZ)

10.100.100.0/24

Load Balancers, exposition publique

200 (Cluster)

10.200.200.0/24

Nœuds K8s, communication pods

240 (Storage)

10.240.240.0/24

Trafic OpenEBS Mayastor

3.4. Interfaces Externes

external interfaces
Système Mode d’Intégration

X-ROAD Gateway

API REST via Security Server, mTLS

SMTP Gateway

SMTP/TLS port 587

Keycloak

OIDC, déployé dans le cluster

ANIP API

API REST via X-ROAD

4. Stratégie de solution

Les stratégies transversales (HA, sécurité, monitoring, CI/CD) sont documentées dans le DAT :

Ce document détaille les aspects spécifiques au provisionnement infrastructure.

4.1. Piliers Stratégiques

Pilier Approche Infrastructure

Cloud-Native

Kubernetes on-premise, Infrastructure as Code (Ansible, Helm)

Haute Disponibilité

Multi-site actif/passif, stockage répliqué, load balancing

Observabilité

Stack Prometheus/Grafana/Loki intégrée

Sécurité Zero Trust

Segmentation VLAN, Network Policies, chiffrement TLS

4.2. Stratégie OpenEBS (Spécifique Infrastructure)

4.2.1. Classes de Stockage

Classe Répliques Moteur Usage

mayastor-double-replica

2

Mayastor (NVMe)

PostgreSQL, Kafka, ETCD

mayastor-single-replica

1

Mayastor

Prometheus, Grafana

openebs-hostpath

1

LocalPV

Cache, configurations

4.2.2. Prérequis Matériels OpenEBS

  • HugePages : 1024 pages de 2Mi par nœud storage

  • IOMMU : Activé dans BIOS pour passthrough NVMe

  • Modules Kernel : nvme, nvme-tcp, vfio-pci

  • Réseau dédié : VLAN 240 (10.240.240.0/24) pour trafic iSCSI

4.3. Stratégie Multi-Site

4.3.1. Topologie

infra multisite

4.3.2. Interconnexion Sites

Paramètre Spécification

Lien Principal

Fibre optique 10Gbps, latence <5ms

Lien Backup

MPLS VPN 1Gbps, latence <20ms

Réplication données

Asynchrone PostgreSQL, lag <30s

Failover

Manuel (RTO 4 h pour la bascule de site), automatisable

4.4. Stratégie Infrastructure as Code

4.4.1. Outils de Provisionnement

Outil Usage Repository

Ansible

Provisionnement OS, configuration réseau, installation K8s

bdes-infra/ansible/

Helm

Déploiement applications sur K8s

bdes-infra/helm/

Terraform

Configuration Keycloak (realms, clients)

bdes-keycloak-terraform/

4.4.2. Procédure de Reconstruction

En cas de disaster :

  1. Provisionnement hardware : Déploiement OS via PXE/Ansible

  2. Installation Kubernetes : Playbook site.yml (45min)

  3. Déploiement composants : Helm charts infra + apps (30min)

  4. Restauration données : Backup PostgreSQL + configurations (variable)

RTO : 4 heures pour une reprise complète sur le site de secours ; la reprise sur le site principal vise 2 heures

5. Vue en Briques

5.1. Architecture Kubernetes BDES

infra building blocks

5.2. Namespaces Kubernetes

Namespace Contenu Isolation

bdes-evaluation-{env}

Pods bdes-evaluation, PostgreSQL, ConfigMaps/Secrets

Network Policy : trafic intra-namespace + bdes-infra

bdes-referentiel-{env}

Pods bdes-referentiel, PostgreSQL, ConfigMaps/Secrets

Network Policy : trafic intra-namespace + bdes-infra

bdes-infra

Keycloak, PostgreSQL, Kafka, Redis, Harbor, X-ROAD

Accessible par eval et ref

monitoring

Prometheus, Grafana, Alertmanager, exporteurs

Lecture seule des métriques

logging

Loki, Promtail

Réception des journaux de tous les namespaces

ingress-nginx

NGINX Ingress Controller

Point d’entrée unique HTTPS

5.3. Composants clés

  • Deployments : Applications stateless (bdes-evaluation, bdes-referentiel)

  • StatefulSets : Services stateful (PostgreSQL, Kafka, Redis)

  • Services : Exposition interne (ClusterIP) et externe (LoadBalancer/NodePort)

  • Ingress : Routage HTTPS vers applications

  • ConfigMaps : Configuration applicative

  • Secrets : Credentials (DB, API keys, certificates)

6. Vue Déploiement

Le dimensionnement des composants, les versions et la configuration Kubernetes sont documentés dans le DAT - Architecture Physique.

Les procédures CI/CD et de sauvegarde sont documentées dans le DAT - Exploitation.

6.1. Environnements

L’infrastructure est conçue pour supporter une architecture multi-site (actif/passif).

6.1.1. Environnements de développement et de recette

Env Domaine Cluster

DEV

*.testbdes.yes.bj

Partagé (4 workers)

STAGING

*.testbdes.yes.bj

Partagé (4 workers)

6.1.2. Cible (Infrastructure Client)

Env Domaine Cluster

STAGING

staging.dce.presidence.bj

Dédié (6 workers)

PROD

*.dce.presidence.bj

Multi-site (12+ workers)

6.2. Architecture Multi-Site (PROD - Cible)

Cette section décrit l’architecture cible de production.

6.2.1. Topologie Réseau

VLAN Site Principal Site Secondaire

DMZ (100/110)

10.100.100.0/24

10.110.110.0/24

Cluster (200/210)

10.200.200.0/24

10.210.210.0/24

Storage (240/250)

10.240.240.0/24

10.250.250.0/24

6.2.2. Interconnexion

  • Lien principal : Fibre dédiée 10Gbps

  • Lien backup : MPLS 1Gbps

  • Mode : Actif/Passif (bascule manuelle, RTO 4 h)

6.3. Namespaces Kubernetes

Namespace Contenu

bdes-evaluation-{env}

Application Évaluation

bdes-referentiel-{env}

Application Référentiel

bdes-infra

Keycloak, PostgreSQL, Kafka, Harbor, X-ROAD

monitoring

Prometheus, Grafana, Alertmanager

logging

Loki, Promtail

6.4. Procédure de Déploiement

6.4.1. Provisionnement Initial

# 1. Provisionnement OS (Ansible)
ansible-playbook -i inventory/prod site.yml

# 2. Installation Kubernetes
ansible-playbook -i inventory/prod kubernetes.yml

# 3. Déploiement infrastructure
helm install bdes-infra charts/bdes-infra -n bdes-infra

# 4. Déploiement applications
helm install bdes-evaluation charts/bdes-evaluation -n bdes-evaluation-prod
helm install bdes-referentiel charts/bdes-referentiel -n bdes-referentiel-prod

6.4.2. Mise à jour Applications

  • DEV : Automatique sur push branche dev

  • STAGING : Automatique sur merge vers main

  • PROD : Manuel avec approbation (GitLab DSI Présidence)

6.5. Checklist Déploiement PROD

Cette liste s’exerce le jour de la mise en production. Elle énumère les contrôles à passer avant d’ouvrir la fenêtre, et se coche à cette occasion ; ses cases sont donc vierges ici.

  • Tests STAGING validés

  • Approbation change management

  • Fenêtre de maintenance communiquée

  • Backup pré-déploiement effectué

  • Rollback plan préparé

  • Équipe support en alerte

7. Concepts Transversaux

Les concepts transversaux (sécurité, HA, monitoring, CI/CD, backup) sont documentés dans le DAT :

Ce document fournit une checklist opérationnelle pour le provisionnement infrastructure.

7.1. Checklist Provisionnement Cluster

Cette liste est le formulaire de contrôle du provisionnement d’un cluster : elle s’exerce à l’installation, case par case. Elle énumère les points à vérifier, et ses cases sont vierges par construction — elles ne décrivent l’état d’aucun environnement.

7.1.1. Prérequis Système

  • HugePages configurées (1024 x 2Mi pour OpenEBS Mayastor)

  • IOMMU activé dans BIOS (passthrough NVMe)

  • Modules kernel chargés : nvme, nvme-tcp, vfio-pci

  • Réseau storage VLAN 240 configuré

7.1.2. Sécurité (avant déploiement)

  • RBAC : ServiceAccounts par namespace créés

  • Network Policies : isolation inter-namespaces appliquée

  • Pod Security Standards : profil restricted activé

  • External Secrets Operator : connecteur vault configuré

  • Trivy : scan images activé dans pipeline CI

7.1.3. Haute Disponibilité

  • PodDisruptionBudget configuré par déploiement critique

  • Anti-affinity rules appliquées (spread workers)

  • Probes readiness/liveness définies par service

7.1.4. Observabilité

  • Prometheus ServiceMonitors créés par namespace

  • Alertmanager : routes notification configurées

  • Promtail : parser logs applicatifs configuré

  • Grafana : dashboards namespace importés

7.1.5. Backup

  • Velero : schedule backup quotidien configuré

  • PostgreSQL : backup automatique CloudNativePG vérifié

  • ETCD : snapshot schedule activé

8. Glossaire

Le glossaire commun de la plateforme BDES est documenté dans le DAT - Glossaire.