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. Contexte et Enjeux

1.1. Finalité de l’Application

La plateforme BDES (Base de Données de l’Enseignement Supérieur) est un système d’information unifié pour la gestion de la qualité de l’enseignement supérieur et l’évaluation du personnel enseignant et chercheur au Bénin.

1.1.1. Contexte

La DCE (Délégation au Contrôle et à l’Éthique) a pour mission le contrôle, l’évaluation et l’assurance qualité de l’enseignement supérieur au Bénin. Les données de l’enseignement supérieur sont dispersées entre MESRS, universités publiques (UPB), établissements privés (EPES) et MTFP, rendant difficile le pilotage stratégique du secteur.

1.1.2. Modules de la plateforme

La plateforme BDES se compose de deux modules autonomes et complémentaires :

Module Description

bdes-evaluation

Digitalisation du processus d’évaluation du personnel enseignant-chercheur : constitution des dossiers, commissions techniques d’évaluation (CTE), évaluations pédagogiques anonymes par les étudiants, validation finale DCE.

bdes-referentiel

Référentiel consolidé des données de l’enseignement supérieur : établissements, enseignants, étudiants, programmes académiques. Exposé via X-ROAD pour l’interopérabilité inter-administrations.

1.1.3. Composants de support

En complément des modules métier, le projet comprend des composants transverses :

Composant Description

bdes-infra

Playbooks Ansible et manifestes Kubernetes pour le déploiement de l’infrastructure (livrable projet).

bdes-keycloak-terraform

Configuration as code (Terraform) pour le provisionnement Keycloak : realms, clients, rôles, mappers.

bdes-keycloak-theme

Thème Keycloak personnalisé pour respecter la charte graphique BDES.

bdes-keycloak-event-listener-spi

Extension Keycloak (SPI) pour la propagation des événements utilisateur vers users-api-ms.

bdes-migration

Scripts de migration des données existantes depuis les bases DCE legacy. Voir Stratégie de Migration.

bdes-reporting

Tableaux de bord et rapports décisionnels (TDR 4.1.6.1.e), servis par Metabase.

1.1.4. Stratégie technique

Architecture microservices cloud-native sur Kubernetes, avec interopérabilité X-ROAD pour l’échange sécurisé inter-administrations. Le module bdes-referentiel est provider X-ROAD pour les consommateurs externes ; les services de la plateforme consomment le référentiel par appel de service à service.

1.2. Contenu du Document

Ce document décrit l’architecture technique de la plateforme BDES, couvrant :

  • L’architecture fonctionnelle et les processus métiers

  • L’architecture applicative (services, frameworks, interfaces)

  • L’architecture des données

  • L’architecture physique (infrastructure, hébergement)

  • Les aspects sécurité

  • La haute disponibilité et les stratégies de migration

  • Les modalités d’exploitation

1.3. Limites du Document

Ce document ne couvre pas :

1.4. Planning

Le planning détaillé du projet (phases, jalons, livrables) est documenté dans le Rapport de Cadrage.

1.5. Parties Prenantes

1.5.1. Gouvernance (COPIL)

Le Comité de Pilotage assure la gouvernance du projet avec prise de décisions collégiales.

Organisation Rôle

DCE

Commanditaire, maîtrise d’ouvrage

ASIN

Maîtrise d’ouvrage déléguée, validation technique, gestion X-ROAD

MND

Gouvernance SI gouvernemental, conformité standards nationaux

DSI Présidence

Hébergement infrastructure datacenter

MESRS

Tutelle enseignement supérieur, source autoritaire principale

IT-NUM

Prestataire développement et support technique (1ère année)

1.5.2. Acteurs Métier

Rôle Partie prenante Domaine d’intérêt

Administrateur Technique

Équipe technique BDES

Administration de la plateforme, gestion des utilisateurs, maintenance, support

Délégué DCE

Membre de la DCE

Gestion des campagnes, affectation des évaluateurs, validation des dossiers

Enseignant

Corps enseignant des établissements supérieurs

Constitution et soumission de dossiers d’évaluation, consultation des retours

Étudiant

Étudiants des établissements supérieurs

Évaluation anonyme de la qualité pédagogique des enseignants

Évaluateur

Enseignants-chercheurs désignés

Évaluation des pairs, rédaction de rapports d’expertise, participation aux CTE

Superviseur CTE

Enseignants seniors ou experts

Coordination du CTE, validation collégiale des rapports

Responsable Académique

Chefs de département, Vice-Doyens

Suivi des enseignants de leur UFR, consultation des évaluations

Admin Référentiel

Équipe technique bdes-referentiel

Gestion quotidienne du référentiel, résolution des doublons, validation des données

1.5.3. Sources Autoritaires de Données

Source Données fournies

MESRS

Établissements, programmes, accréditations, nomenclatures officielles

UPB (Universités Publiques)

Enseignants, étudiants, programmes (UAC, UP, UNA, UNSTIM, etc.)

EPES (Établissements Privés)

Données des établissements privés d’enseignement supérieur

MTFP

Données RH des enseignants titulaires du secteur public

ANIP

Validation du NPI (Numéro Personnel d’Identification)

1.5.4. Acteurs Exploitation

Équipe Rôle Périmètre Contact

Équipe Infrastructure

Administration système

Serveurs, Kubernetes, réseau

IT-NUM puis Équipe Client

Équipe DBA

Administration BDD

PostgreSQL, sauvegardes

IT-NUM puis Équipe Client

Équipe Applicative

Support applicatif

Microservices, incidents N2/N3

IT-NUM puis Équipe Client

1.6. Besoins et Attentes

1.6.1. Besoins Fonctionnels

Les besoins fonctionnels sont détaillés dans les spécifications par module :

  • SFD bdes-evaluation : Campagnes d’évaluation, dossiers enseignants, CTE, évaluations pédagogiques anonymes, validation DCE

  • SFD bdes-referentiel : Référentiel de données consolidé, gestion des sources autoritaires, exposition X-ROAD

1.6.2. Exigences Non-Fonctionnelles

Exigence Description Cible Réf. TDR

Performance

Temps de traitement par transaction

< 5 secondes

4.1.6.2

Disponibilité

Disponibilité même en période de forte sollicitation

-

4.1.6.1

Qualité code

Taux d’erreurs dans le code

< 5%

4.1.6.1

Couverture fonctionnelle

Fonctionnalités principales développées

90%

4.1.6.1

Couverture tests

Tests fonctionnels

95%

4.1.6.5

Intégration données

Taux de réussite des intégrations

95%

4.1.6.2

Sécurité

Conformité aux exigences gouvernementales

Validation ASIN

4.1.7.3

Interopérabilité

Échange de données inter-administrations

X-ROAD (XROADBJ)

4.1.6.3

Ergonomie

Interface intuitive, responsive design, support multilingue

FR/EN

-

1.6.3. Contraintes Techniques

  • Hébergement souverain : Datacenter d’État - DSI Présidence (TDR 4.1.6.6)

  • Conformité sécurité : Validation ASIN obligatoire (TDR 4.1.7.3)

  • Interopérabilité : X-ROAD (XROADBJ) prioritaire pour échanges inter-administrations (TDR 4.1.6.3)

  • Authentification : SSO centralisé

  • Maintenance : 12 mois de garantie après réception définitive (TDR 4.8)

  • Propriété intellectuelle : Code source propriété de la DCE (TDR 4.1.6.8)

2. Architecture Fonctionnelle

2.1. Vue d’ensemble des Domaines Fonctionnels

La plateforme BDES se structure en cinq domaines fonctionnels principaux :

Domaine Description

Évaluation

Gestion des campagnes, dossiers enseignants, commissions CTE, évaluations pédagogiques, validations DCE

Référentiel

Consolidation et exposition des données de référence (établissements, enseignants, programmes) via X-ROAD

Utilisateurs

Gestion des identités, réconciliation multi-sources, demandes de rôles

Notifications

Envoi de notifications email, gestion des templates

Reporting

Visualisation des données et statistiques, exports (CSV, Excel, PDF) - TDR 4.1.6.1.e

2.2. Processus Métier

Les processus métier sont détaillés dans les Spécifications Fonctionnelles Détaillées (SFD) de chaque module.

2.2.1. Module bdes-evaluation

Processus de bout en bout : Création campagne → Constitution dossier → Évaluation CTE → Validation DCE

Flux principaux :

  • Création et activation de campagne

  • Constitution et soumission de dossier

  • Assignation à un CTE

  • Évaluation par le CTE

  • Validation par le Délégué DCE

  • Évaluations pédagogiques anonymes par les étudiants

Voir : SFD bdes-evaluation - Vue d’ensemble fonctionnelle

2.2.2. Module bdes-referentiel

Processus de consolidation : Sources autoritaires → Validation → Déduplication → Données GOLDEN → Exposition API

Flux principaux :

  • Alimentation depuis les sources (API, dépôts Excel, synchronisation)

  • Détection et résolution des doublons

  • Exposition via X-ROAD pour les consommateurs

Voir : SFD bdes-referentiel - Vue d’ensemble fonctionnelle

2.3. Points d’Entrée

Interface URL Usage

Application Web Évaluation

evaluation.dce.presidence.bj

Interface utilisateurs (enseignants, évaluateurs, DCE)

Application Web Référentiel

referentiel.dce.presidence.bj

Interface administration données référentielles

API Gateway

apis.dce.presidence.bj

Point d’entrée API REST

Keycloak

auth.dce.presidence.bj

Authentification SSO

2.4. Flux Internes

2.4.1. Matrice des Flux

Source Destination Protocole Port Description

Navigateur

HAProxy

HTTPS

443

Accès IHM Frontend

Navigateur

Keycloak

HTTPS

443

Authentification OIDC/SSO

Frontend

API Gateway

HTTPS

443

Appels API avec JWT

API Gateway

Keycloak

HTTPS

443

Validation tokens JWT

API Gateway

Microservices

HTTP

8080

Routage interne

Microservices

PostgreSQL

JDBC

5432

Persistance données

Microservices

Kafka

TCP

9092

Événements asynchrones

Microservices

Redis

TCP

6379

Cache distribué

Microservices

MinIO

HTTPS/S3

443

Stockage fichiers

Microservices

SMTP

SMTP

587

Notifications email

bdes-evaluation

X-ROAD Security Server

HTTPS

5500

Interopérabilité gouvernementale

X-ROAD Security Server

bdes-referentiel

HTTPS

5500

Requêtes des consommateurs externes relayées vers le référentiel

Prometheus

Microservices

HTTP

8081

Scraping métriques

3. Architecture Applicative

3.1. Vue Contexte Système

Vue contexte système
Figure 1. Vue contexte - Plateforme BDES

3.2. Description des Services Applicatifs

3.2.1. Vue d’Ensemble des Services

La plateforme BDES est composée de microservices Spring Boot communiquant via API REST et événements Kafka.

3.2.2. Catalogue des Services

Service Type Responsabilités Dépendances

evaluation-api-ms

Microservice

Gestion des campagnes, dossiers, évaluations CTE, formulaires

PostgreSQL, Kafka, MinIO, Redis

users-api-ms

Microservice

Reflet des comptes Keycloak, demandes et attribution des rôles, réception des évènements d’identité

PostgreSQL, Kafka, Keycloak

notifications-api-ms

Microservice

Envoi notifications email, gestion templates

PostgreSQL, Kafka, SMTP

referentiel-api-ms

Microservice

Exposition des données référentielles consolidées, alimentation et consolidation

PostgreSQL, Redis

job-runner-ms

Microservice

Travaux périodiques : cycle de vie des campagnes, relances d’échéance, nettoyage des fichiers temporaires, reprise et purge de la file de notifications

PostgreSQL, les autres services

API Gateway

Gateway

Routage, authentification, rate limiting

Keycloak, Microservices

3.2.3. Flux entre Composants

Flux composants
Figure 2. Vue flux - Interactions entre composants et modules

3.2.4. Échanges entre Services de la Plateforme

Les échanges entre les services de la plateforme, et avec le référentiel, empruntent deux voies.

  • Appel de service à service pour les échanges internes à la plateforme. L’appelant porte un compte de service dont les habilitations ne sont jamais accordées à un utilisateur ; le service appelé vérifie l’autorisation sur le jeton présenté.

  • X-ROAD pour les consommateurs externes du référentiel : administrations et systèmes gouvernementaux, selon les contrats décrits au chapitre 2.

Ces échanges ne sont pas en lecture seule : le module d’évaluation écrit dans le référentiel les maquettes de formation et les planifications des enseignements.

3.2.5. Description Détaillée par Service

Les spécifications techniques détaillées de chaque service sont documentées dans les STD correspondants.
3.2.5.1. Module bdes-evaluation

  • evaluation-api-ms : Gestion du cycle de vie des campagnes et dossiers d’évaluation

  • users-api-ms : Réconciliation des identités multi-sources, synchronisation Keycloak

  • notifications-api-ms : Envoi de notifications email, gestion des templates et préférences

Voir : STD bdes-evaluation - Building Blocks

3.2.5.2. Module bdes-referentiel

  • referentiel-api-ms : Consolidation et exposition des données référentielles via X-ROAD

Voir : STD bdes-referentiel - Building Blocks

3.3. Architecture des Batchs

3.3.1. Liste des Traitements Batch

Traitement Fréquence Fenêtre Description

Cycle de vie des campagnes

Toutes les 15 minutes

Permanente

Ouverture et clôture des campagnes selon leurs dates, et progression des dossiers qui en dépend

Relances de campagne

Quotidienne

08h00 UTC

Rappels aux enseignants et aux évaluateurs à 3 et 5 jours de l’échéance de soumission puis de fin

Reprise de la file de notifications

Toutes les 2 minutes

Permanente

Nouvelle tentative des notifications en échec, selon un délai croissant et un nombre d’essais plafonné

Purge de la file de notifications

Quotidienne

03h00 UTC

Suppression des entrées de la file au-delà de leur durée de conservation

Nettoyage des fichiers temporaires

Quotidienne

02h00 UTC

Suppression des dépôts temporaires de plus de 48 heures

Synchronisation des paramètres applicatifs

Toutes les 15 minutes

Permanente

Relecture de la table des paramètres, pour que les réglages modifiés en base s’appliquent sans redéploiement

Rafraîchissement de l’entrepôt analytique

Horaire

Permanente

Recalcul des vues consommées par l’outil décisionnel

3.3.2. Orchestration des Batchs

Les traitements ci-dessus sont portés par le service job-runner-ms, et non par des objets planifiés de l’orchestrateur. Chacun est décrit par une expression cron dans la configuration du service et porte son propre interrupteur d’activation, ce qui permet de l’arrêter sans redéployer les autres. Le rafraîchissement de l’entrepôt analytique fait exception : il est le seul à être planifié par un CronJob Kubernetes, parce qu’il s’exécute hors du service.

  • Planification par expression cron, versionnée avec la configuration du service

  • Un interrupteur d’activation par traitement

  • Reprise sur échec propre à chaque traitement, et non générique

  • Journaux centralisés dans Loki, métriques exposées à Prometheus, alertes routées par Alertmanager

3.4. Langages, Composants Techniques et Framework

3.4.1. Stack Backend

Composant Version Usage

Java

17 LTS

Langage principal backend

Spring Boot

3.x

Framework microservices

Spring Security

6.x

Sécurité, OAuth2/OIDC

Spring Data JPA

3.x

Persistance ORM

Spring Kafka

3.x

Messaging asynchrone

Resilience4j

2.x

Patterns de résilience (Circuit Breaker, Retry)

MapStruct

1.5.x

Mapping DTO/Entity

Flyway

9.x

Migration base de données

3.4.2. Stack Frontend

Composant Version Usage

Vue.js

3.x

Framework frontend

Nuxt

3.x

Framework SSR/SSG

TypeScript

5.x

Typage statique

Tailwind CSS

3.x

Framework CSS utilitaire

3.4.3. Stack Data

Composant Version Usage

PostgreSQL

16.x

Base de données principale

Redis

7.x

Cache distribué, sessions

Apache Kafka

3.7.x

Messaging, event streaming

MinIO

Latest

Stockage objets S3-compatible

PL/pgSQL

PostgreSQL 16

Transformation des données du référentiel, par fonctions embarquées dans la base

3.5. Interface avec d’Autres Applications ou Composants Externes

3.5.1. Systèmes Externes Consommés

Système Protocole Format Usage

Keycloak

HTTPS/OIDC

JWT

Authentification, autorisation, SSO

X-ROAD

HTTPS/SOAP

XML

Interopérabilité gouvernementale

ANIP

HTTPS/REST

JSON

Validation du NPI (optionnel)

Scolarités Universités

Divers (dépôts Excel, API)

Divers

Données étudiants, inscriptions

SMTP Gouvernemental

SMTP/TLS

RFC 5321

Envoi emails

3.5.2. Services Exposés

Service Protocole Format Consommateurs

API Évaluation

HTTPS/REST

JSON

Frontend, intégrations tierces

API Référentiel

HTTPS/REST

JSON

bdes-evaluation, systèmes gouvernementaux

X-ROAD Provider

HTTPS/SOAP

XML

Administrations via X-ROAD

3.6. Caractéristiques des Interfaces Applicatives

3.6.1. Standards API REST

Caractéristique Spécification

Format

JSON (application/json)

Authentification

Bearer JWT (OAuth2/OIDC via Keycloak)

Versioning

URL path (/api/v1/…​)

Pagination

Offset-based (page, size) ou Cursor-based

Erreurs

Format standardisé (code, message, traceId)

Documentation

OpenAPI 3.x (Scalar)

3.6.2. Contrats d’Interface

API Spécification OpenAPI Environnement

evaluation-api-ms

/scalar.html

apis.dce.presidence.bj/evaluation

referentiel-api-ms

/scalar.html

apis.dce.presidence.bj/referentiel

users-api-ms

/scalar.html

apis.dce.presidence.bj/users

notifications-api-ms

/scalar.html

apis.dce.presidence.bj/notification

3.6.3. Gestion des Erreurs

Format de réponse standardisé :

{
  "timestamp": "2025-01-15T10:30:00Z",
  "status": 400,
  "error": "Bad Request",
  "code": "ERR-EVAL-002",
  "message": "La période d'évaluation est expirée",
  "path": "/api/v1/evaluations/123/soumissions",
  "traceId": "abc-123-def-456"
}

3.6.4. Codes d’Erreur

Codes transverses (authentification/autorisation) :

Code Description

ERR-AUTH-001

Authentification échouée

ERR-AUTH-002

Token expiré ou invalide

ERR-AUTHZ-001

Droits insuffisants

Les codes d’erreur spécifiques à chaque module sont documentés dans les STD correspondants :

4. Architecture de la Donnée

4.1. Données

4.1.1. Modèle de Données Global

La plateforme BDES gère deux domaines de données distincts :

  • Données d’évaluation (bdes-evaluation) : Campagnes, dossiers, évaluations CTE, formulaires

  • Données référentielles (bdes-referentiel) : Établissements, enseignants, programmes, étudiants

Les modèles de données détaillés sont documentés dans les SFD de chaque module :

4.1.2. Bases de Données par Service

Service Base de données Schéma principal Volumétrie estimée

evaluation-api-ms

PostgreSQL

ods, audit

users-api-ms

PostgreSQL

public

notifications-api-ms

PostgreSQL

ods, audit

job-runner-ms

PostgreSQL

ods

referentiel-api-ms

PostgreSQL

reference, golden, raw, staging, mdm, audit

4.1.3. Pattern Database per Service

Chaque domaine dispose de ses propres schémas, migrés par un projet Flyway central (bdes-db-migration). Les services d’un même domaine partagent ses schémas, garantissant :

  • Isolation : aucun service n’écrit dans les schémas d’un autre domaine

  • Cohérence : un jeu de migrations unique, versionné avec le code

  • Scalabilité : possibilité de porter un domaine sur une instance dédiée

  • Résilience : Panne d’une base n’affecte pas les autres services

4.1.4. Données de Référence

Référentiel Description Source

Universités

Établissements d’enseignement supérieur

MESRS

UFR/Départements

Structure organisationnelle

Universités

Enseignants

Personnel enseignant et chercheur

Universités, MESRS

Programmes

Formations et parcours

Universités

Grades

Grades académiques (Assistant, MC, Professeur)

Référentiel statique

Pays

Liste des pays

Référentiel statique

Villes

Villes et localités béninoises

Référentiel statique

Journaux académiques

Revues et journaux pour publications

Référentiel statique (bdes-evaluation)

Voir : SFD bdes-referentiel - Modèle de données pour la liste complète des entités.

4.1.5. Stockage Fichiers

Les fichiers sont déposés dans un bucket unique, bdes-data, où l’arborescence des clés distingue les natures ci-dessous.

Type Stockage Description

Documents enseignants

MinIO (S3)

CV, diplômes, publications

Pièces justificatives

MinIO (S3)

Documents joints aux dossiers et aux évaluations

La clé de chaque objet porte le dossier auquel il appartient : folders/{uuid du dossier}/{conteneur}/{entité}/files/{uuid}_{nom} pour les pièces des rubriques du dossier, folders/{uuid du dossier}/survey_files/{uuid}_{nom} pour celles déposées dans un formulaire. Cette clé est le nom interne enregistré en base : elle fait seule le lien entre un dossier et ses pièces.

4.2. Règles de Gouvernance

4.2.1. Propriété des Données

Domaine Propriétaire Responsabilités

Données Évaluation

DCE

Campagnes, dossiers, évaluations

Données Référentiel

MESRS / Universités

Établissements, enseignants, programmes

Données Utilisateurs

DCE

Comptes, rôles, permissions

4.2.2. Qualité des Données

Critère Description Seuil

Complétude

Pourcentage de champs obligatoires renseignés

> 95%

Conformité

Respect des formats (dates, codes, emails)

> 99%

Cohérence

Références valides, pas de contradictions

> 99%

Unicité

Pas de doublons sur clés uniques

100%

4.2.3. Cycle de Vie des Données

Type de données Rétention Action fin de vie

Données d’évaluation

À définir (DCE + ASIN)

Archivage cold storage

Logs d’audit

À définir (DCE + ASIN)

Archivage puis suppression

Notifications

30 jours après lecture

Suppression automatique

Sessions utilisateurs

24 heures

Invalidation automatique

Cache Redis

1-24 heures (TTL)

Expiration automatique

4.2.4. Conformité Réglementaire

  • Protection des données personnelles : Conformité aux réglementations nationales

  • Droit d’accès : Les utilisateurs peuvent consulter leurs données personnelles

  • Droit de rectification : Procédure de demande de correction

  • Anonymisation : Évaluations pédagogiques anonymisées (aucun lien traçable)

  • Audit trail : Journalisation complète des accès et modifications

4.2.5. Sauvegarde et Restauration

Voir : Chapitre Exploitation - Sauvegarde pour la politique de sauvegarde et les procédures de restauration.

5. Architecture Physique

5.1. Cartographie de l’Architecture Physique

Vue déploiement
Figure 3. Vue déploiement - Architecture physique Production

5.1.1. Architecture Multi-Tiers

Tier Composants

Tier Web

Application Vue.js/Nuxt (via HAProxy LB + Nginx Ingress)

Tier Application

API Gateway, Microservices Spring Boot (evaluation, users, notification, referentiel), Keycloak, Metabase, bdes-migration

Tier Données

PostgreSQL (CloudNativePG), Kafka (Strimzi), Redis Sentinel, MinIO

Tier Outils

Prometheus, Grafana, Loki, GlitchTip

5.1.2. Environnements

Environnement Usage Caractéristiques

DEV

Développement, tests unitaires

Ressources minimales, données anonymisées

STAGING

Tests d’intégration, recette

Miroir production (scaled down)

PROD

Production

Haute disponibilité

5.2. Caractéristiques des Machines

L’infrastructure est hébergée au Datacenter DSI Présidence (TDR 4.1.6.6 - Hébergement souverain).

5.2.1. Machines Physiques du Cluster

Type Quantité vCPU RAM Stockage Réseau

Masters K8s (Control Plane)

3

8

32 GB

200 GB SSD NVMe

10 Gbps

Workers K8s (Applications)

3+

16

64 GB

100 GB NVMe (OS) + 1 TB NVMe (données)

10 Gbps

Workers K8s (Data)

3+

16

64 GB

100 GB NVMe (OS) + 2 TB NVMe (stockage)

10 Gbps

Load Balancers (DMZ)

2

4

8 GB

50 GB SSD

10 Gbps

5.2.2. Spécifications Techniques

Caractéristique Valeur

Système d’exploitation

Ubuntu 22.04/24.04 LTS

Version Kubernetes

1.31.4

Runtime conteneurs

containerd

Stockage persistant

OpenEBS Mayastor (NVMe-over-TCP)

Load Balancer

HAProxy 2.8.x + Keepalived (actif/passif)

5.3. Détail des Composants Physiques

5.3.1. Services d’Infrastructure

Composant Version Réplicas Ressources (requests)

PostgreSQL

16 (CloudNativePG)

1 primary + 2 replicas

4 CPU, 8GB RAM par instance

Kafka

3.7.x (Strimzi)

3 brokers

2 CPU, 4GB RAM par broker

Redis

7.x (Sentinel)

3 masters + 3 replicas

1 CPU, 2GB RAM par nœud

MinIO

Latest

4 nœuds

2 CPU, 4GB RAM par nœud

Loki

3.x

3 nœuds

4 CPU, 8GB RAM par nœud

Keycloak

26.x

3 pods

2 CPU, 4GB RAM par pod

Harbor Registry

2.x

2 réplicas

2 CPU, 4GB RAM

5.3.2. Applications BDES

Microservice Réplicas Ressources (requests)

Frontend Vue.js

3 pods

0.5 CPU, 512MB RAM

API Gateway

3 pods

1 CPU, 2GB RAM

evaluation-api-ms

3 pods

1 CPU, 2GB RAM

referentiel-api-ms

2 pods

1 CPU, 2GB RAM

users-api-ms

2 pods

1 CPU, 2GB RAM

notifications-api-ms

2 pods

0.5 CPU, 1GB RAM

Metabase

2 pods

1 CPU, 2GB RAM

bdes-migration

1 pod (CronJob)

0.5 CPU, 1GB RAM

5.3.3. Outils d’Observabilité

Composant Réplicas Ressources (requests)

Prometheus

2 réplicas

2 CPU, 4GB RAM

Grafana

2 réplicas

1 CPU, 2GB RAM

GlitchTip

2 réplicas

1 CPU, 2GB RAM

5.3.4. Configuration Kubernetes

Ressource Configuration

Namespaces

Un espace par environnement applicatif — dev, default, preprod, prod — et un espace par service d’infrastructure : postgres, kafka, redis, minio, keycloak, harbor, opensearch, monitoring, logging, ingress-nginx, cert-manager, openebs

Ingress Controller

NGINX Ingress Controller, TLS 1.3, cert-manager pour certificats

Storage Classes

OpenEBS Mayastor (PostgreSQL, Kafka), MinIO replicated (fichiers)

Network Policies

Isolation inter-namespaces, whitelist explicite

Pod Security Standards

Restricted profile : non-root, read-only filesystem

HPA (Horizontal Pod Autoscaler)

CPU > 70% trigger, min/max pods définis par service

5.3.5. Domaines et Points d’Accès

Service URL

Frontend Évaluation

https://evaluation.dce.presidence.bj

API Évaluation

https://apis.dce.presidence.bj/evaluation

API Référentiel (X-ROAD)

https://xroad.dce.presidence.bj/r1/bdes-referentiel

Keycloak

https://auth.dce.presidence.bj

Grafana

https://monitoring.dce.presidence.bj (accès interne)

5.4. Caractéristiques des Interfaces Techniques

5.4.1. Ports et Protocoles

Service Port Protocole Description

HAProxy (Frontend)

443

HTTPS

Point d’entrée utilisateurs

API Gateway

8080

HTTP

Routage interne

Microservices

8080

HTTP

APIs REST

PostgreSQL

5432

TCP/JDBC

Base de données

Kafka

9092

TCP

Messaging (PLAINTEXT interne)

Kafka (SSL)

9093

TCP/SSL

Messaging (clients externes)

Redis

6379

TCP

Cache

MinIO

9000

HTTPS

API S3

Prometheus

9090

HTTP

Métriques

Grafana

3000

HTTP

Dashboards

5.4.2. Certificats TLS

Usage Type Validité

Frontend HTTPS

Certificat EV gouvernemental

1 an

API Gateway

Let’s Encrypt (ACME)

90 jours (auto-renew)

Inter-services (mTLS)

Cert-manager (self-signed CA)

1 an (auto-renew)

PostgreSQL SSL

Cert-manager

1 an (auto-renew)

Kafka SSL

Cert-manager

1 an (auto-renew)

5.5. Connectivité

5.5.1. Architecture Réseau

Segment Configuration

DMZ

VLAN 100 : 10.100.100.0/24

Cluster K8s

VLAN 200 : 10.200.200.0/24

Storage

VLAN 240 : 10.240.240.0/24

5.5.2. Règles Firewall Principales

Source Destination Port Action

Internet

HAProxy DMZ

443

ALLOW

HAProxy

API Gateway

8080

ALLOW

API Gateway

Microservices

8080

ALLOW

Microservices

PostgreSQL

5432

ALLOW

Microservices

Kafka

9092

ALLOW

*

*

*

DENY (default)

5.6. Hébergement

5.6.1. Localisation

L’infrastructure BDES est hébergée au Datacenter DSI Présidence conformément aux exigences d’hébergement souverain (TDR 4.1.6.6).

5.6.2. Haute Disponibilité

Voir : Chapitre Haute Disponibilité pour les mécanismes HA par composant, les objectifs RPO/RTO et les scénarios de reprise.

6. Sécurité

Les aspects sécurité spécifiques à chaque module sont documentés dans les STD correspondants :

6.1. Authentification et Autorisation

6.1.1. Keycloak - Serveur d’Authentification

Paramètre Configuration

Version

26.x

Realm

BDES (un realm par environnement : DEV, STAGING, PROD)

Protocole

OAuth2 / OpenID Connect (OIDC) avec PKCE

Fédération

IdP gouvernementaux (SSO inter-administrations)

Provisionnement

Terraform (configuration as code)

6.1.2. Configuration des Clients OAuth2

Client Type Usage

bdes-spa-client

Public

Application Nuxt/Vue, flux de code d’autorisation avec PKCE

bdes-evaluation-api

Confidential

Service du domaine évaluation

bdes-referentiel-api

Bearer-only

Service du domaine référentiel

bdes-users-api

Bearer-only

Service des comptes et des rôles

bdes-users-api-admin

Confidential

Administration du royaume depuis users-api : groupes, rôles, réinitialisation de mot de passe

bdes-notifications-api

Bearer-only

Service de notification

bdes-job-runner-api

Confidential

Exécuteur des traitements planifiés

bdes-keycloak-event-listener-spi

Confidential

Transmission des évènements du fournisseur d’identité vers users-api

uac-bulk-data

Confidential

Dépôt en masse de données référentielles par l’Université d’Abomey-Calavi
Les appels de service à service ne passent pas par un client partagé : chaque client confidentiel dispose de son propre compte de service, porteur des seules habilitations dont il a besoin. Le compte de service d'`bdes-evaluation-api`, par exemple, ne reçoit du Référentiel que la lecture et la recherche de personnes.

6.1.3. Tokens JWT

Paramètre Valeur

Access Token TTL

15 minutes

Refresh Token TTL

24 heures

Algorithme signature

RS256 (asymétrique)

Claims personnalisés

userId, roles, permissions

6.1.4. Gestion des Rôles (RBAC)

Rôle Permissions

ROLE_USER_BASE

Accès de base, demande de rôles supplémentaires

ROLE_ETUDIANT

Soumission évaluations pédagogiques anonymes

ROLE_ENSEIGNANT

Consultation/constitution dossier personnel

ROLE_EVALUATEUR

Évaluation dossiers assignés (CTE)

ROLE_SUPERVISEUR

Coordination CTE, assignation dossiers

ROLE_RESPO_ACADEMIQUE

Consultation enseignants UFR

ROLE_DELEGUE

Administration, validation finale DCE

ROLE_ADMIN

Administration technique, Keycloak

6.1.5. Synchronisation Utilisateurs

  • Event Listener SPI : Keycloak déclenche des webhooks vers users-api-ms lors des événements utilisateur (création, modification, suppression, changement de groupe). La réception est authentifiée par signature HMAC-SHA256 sur l’horodatage et le corps, avec une tolérance de cinq minutes

  • Reflet des identités : users-api-ms tient le reflet local des comptes Keycloak, dans ce seul sens. Le rattachement à une fiche du Référentiel se fait par revendication, lors d’une demande de rôle

  • Identifiant national : son format est contrôlé, dix chiffres

6.2. Chiffrement

6.2.1. Chiffrement des Données au Repos (At-Rest)

Composant Méthode Algorithme

PostgreSQL

Transparent Data Encryption (volumes)

LUKS / AES-256

MinIO

Server-Side Encryption

AES-256

Kafka

Chiffrement disque

LUKS / AES-256

Secrets Kubernetes

Sealed Secrets / HashiCorp Vault

AES-256-GCM

Secrets de déploiement

Ansible Vault (dépôt d’infrastructure)

AES-256-GCM

6.2.2. Chiffrement des Données en Transit (In-Transit)

Flux Protocole Version minimale

Client → HAProxy

HTTPS

TLS 1.3

HAProxy → API Gateway

HTTPS

TLS 1.2

API Gateway → Microservices

HTTP (interne) ou mTLS

TLS 1.2

Microservices → PostgreSQL

SSL

TLS 1.2

Microservices → Kafka

SSL

TLS 1.2

X-ROAD

HTTPS + Signatures

TLS 1.2

6.3. Protection des Données

6.3.1. Classification des Données

Classification Description Exemples

Public

Données accessibles sans restriction

Liste universités, programmes

Interne

Données accessibles aux utilisateurs authentifiés

Formulaires, rapports agrégés

Confidentiel

Données personnelles, accès restreint

Dossiers enseignants, évaluations

Sensible

Données hautement protégées

Credentials, clés API

6.3.2. Minimisation des Données

  • Collecte uniquement des données nécessaires

6.4. Audit et Traçabilité

6.4.1. Journalisation des Événements

Type Événements journalisés

Authentification

Login, logout, échecs, MFA

Autorisation

Accès refusés, changements de rôles

Données

Création, modification, suppression (qui, quand, quoi)

Administration

Actions admin, modifications configuration

6.4.2. Stockage et Rétention

Type Stockage Rétention

Logs applicatifs

Loki

À définir (DCE + ASIN)

Logs d’audit

Loki (flux en lecture seule)

À définir (DCE + ASIN)

Logs Keycloak

Loki

À définir (DCE + ASIN)

6.5. Sécurité Applicative

6.5.1. Conformité OWASP

Les développements respectent les recommandations du OWASP Top 10 (2021) pour la prévention des vulnérabilités applicatives les plus critiques. Les mesures de protection incluent :

  • Contrôle d’accès : RBAC via Keycloak, validation côté serveur

  • Chiffrement : TLS 1.3, AES-256, secrets chiffrés (Sealed Secrets)

  • Injection : Prepared statements, validation des entrées

  • Composants vulnérables : Scans CVE automatisés (Trivy)

  • Intégrité : Images Docker signées, SBOM (Software Bill of Materials)

6.5.2. Sécurité des Headers HTTP

Header Valeur

Strict-Transport-Security

max-age=31536000; includeSubDomains

X-Content-Type-Options

nosniff

X-Frame-Options

DENY

Content-Security-Policy

default-src 'self'; …​

X-XSS-Protection

1; mode=block

6.6. Audits de Sécurité

La conformité sécurité est validée par l’ASIN (TDR 4.1.7.3).

Type Description

Scan de vulnérabilités

Automatisé dans CI/CD (Trivy, SonarQube)

Audit de code

Revue automatique des dépendances via Renovate (open-source, GitLab-compatible)

7. Haute Disponibilité et Migration

7.1. Haute Disponibilité

7.1.1. Objectifs

Métrique Cible Description

Disponibilité

À définir (DCE + ASIN)

Disponibilité même en période de forte sollicitation (TDR 4.1.6.1)

Temps de failover

< 30 secondes

Bascule automatique intra-site

7.1.2. Haute Disponibilité par Composant

Composant Mécanisme HA Failover

API Gateway

3 réplicas, HPA

Automatique (K8s)

Microservices

Multi-réplicas, HPA

Automatique (K8s)

PostgreSQL

1 primary + 2 replicas

Automatique (CloudNativePG)

Kafka

3 brokers, RF=3

Automatique (Strimzi)

Redis

3 masters + 3 replicas

Automatique (Sentinel)

HAProxy

Actif/Passif + Keepalived

Automatique (VRRP)

7.2. Migration de l’Existant

La stratégie de migration complète est documentée dans Stratégie de Migration.

7.2.1. Systèmes Existants

Système Description Action

Drupal

Portail web existant

Remplacement par Application Vue.js

KoboToolbox

Application gestion évaluations (Toolbox)

Remplacement par bdes-evaluation

Bases legacy

Données enseignants/établissements

Migration vers bdes-referentiel

7.2.2. Migration des Données

Données Source Stratégie

Enseignants

KoboToolbox / Sources universitaires

ETL vers Référentiel GOLDEN

Établissements

Base MESRS

ETL vers Référentiel GOLDEN

Historique évaluations

KoboToolbox

Non migré (incompatibilité format KoboToolbox vs SurveyJS)

L’historique des évaluations depuis KoboToolbox ne sera pas migré. Les formulaires KoboToolbox (format XLSForm/XForm) sont incompatibles avec SurveyJS utilisé par bdes-evaluation.

7.3. Décommissionnement

Hors scope du projet BDES. Le décommissionnement des systèmes legacy (Drupal, KoboToolbox) relève de la responsabilité du client (DCE).

8. Exploitation

8.1. Mise en Production

8.1.1. Checklist Pré-Production

Cette liste s’exerce avant chaque mise en production et se coche à cette occasion. Elle énumère les contrôles attendus ; ses cases sont vierges ici et ne renseignent pas sur une livraison particulière.

  • Tous les tests passent (unitaires, intégration, E2E)

  • Revue de code complète

  • Documentation mise à jour

  • Scripts de migration testés sur STAGING

  • Rollback plan validé

  • Communication utilisateurs planifiée

  • Fenêtre de maintenance réservée

  • Équipe de support informée

8.1.2. Stratégie de Déploiement

Rolling Update : Déploiements standards avec 0 downtime via Kubernetes.

8.2. Intégration / Déploiement Continue

8.2.1. Stack CI/CD

Outil Version Usage

GitLab CI

Latest

Pipeline CI/CD, runners

Harbor

2.x

Registry images Docker

Helm

3.x

Packaging applications K8s

SonarQube

10.x

Analyse qualité code

8.2.2. Pipeline CI (Build)

stages:
  - build
  - test
  - scan
  - package
  - publish
Stage Actions

build

Compilation Maven/npm, génération artifacts

test

Tests unitaires, couverture code (>80%)

scan

SonarQube, scan vulnérabilités (Trivy)

package

Build image Docker, tag version

publish

Push image vers Harbor, signature

8.2.3. Pipeline CD (Deploy)

Environnement Trigger

DEV

Automatique sur merge branche dev

STAGING

Automatique sur merge branche staging

PREPROD

Automatique sur merge branche preprod

PROD

Sur merge branche main, avec approbation - GitLab DSI Présidence

Le pipeline de production est exécuté sur le GitLab de la DSI Présidence pour des raisons de sécurité et d’isolation.

8.3. Gestion de la Configuration

8.3.1. Stratégie

La plateforme BDES utilise une gestion de configuration entièrement native Kubernetes, sans serveur de configuration centralisé (Spring Cloud Config).

Mécanisme Usage Sécurité

Kubernetes ConfigMaps

Configuration applicative non sensible : URLs, paramètres métier, limites, timeouts

Stockage clair, versionné dans Git

Kubernetes Secrets

Configuration sensible : credentials BD, clés API, tokens

Chiffrement at-rest (etcd encryption)

Ansible Vault

Secrets de déploiement versionnés chiffrés dans le dépôt d’infrastructure

Chiffrement symétrique, déchiffrement au déploiement

Sealed Secrets

Secrets versionnés dans Git de manière sécurisée

Chiffrement asymétrique, déchiffrement uniquement dans cluster

External Secrets Operator

Synchronisation secrets depuis HashiCorp Vault (optionnel)

Rotation automatique, audit centralisé

8.3.2. Injection dans les Applications

  • Variables d’environnement : injection automatique via envFrom dans les manifests K8s

  • Volumes montés : fichiers de configuration montés dans /config

  • Spring Profiles : dev, staging, prod activés via SPRING_PROFILES_ACTIVE

8.3.3. Refresh Dynamique

  • Sans redémarrage : /actuator/refresh pour rechargement ConfigMaps (Spring Cloud Kubernetes)

  • Avec redémarrage : redéploiement pods via kubectl rollout restart si secrets modifiés

Les paramètres spécifiques à chaque module sont documentés dans les STD correspondants.

8.4. Sauvegarde

8.4.1. Politique de Sauvegarde

Composant Type Fréquence Rétention Stockage

PostgreSQL

Full + WAL

Quotidien + continu

À définir (DCE + ASIN)

MinIO S3

MinIO

Incrémental

Quotidien

À définir (DCE + ASIN)

MinIO S3

Kafka

Topics critiques

Quotidien

À définir (DCE + ASIN)

MinIO S3

Configuration K8s

Export YAML

À chaque modification

Indéfini

Git

Secrets

Backup chiffré

Quotidien

À définir (DCE + ASIN)

Vault / MinIO

8.5. Archivage

Responsabilité client. La définition de la politique d’archivage (critères, rétention, format) relève de la responsabilité de la DCE, avec le support technique d’IT-NUM pour sa mise en œuvre.

8.6. Supervision

8.6.1. Stack de Monitoring

Outil Version Fonction

Prometheus

2.x

Collecte métriques (scraping)

Grafana

10.x

Visualisation, dashboards

Alertmanager

0.27.x

Gestion alertes, routing

Loki

3.x

Centralisation des journaux

Grafana (journaux)

11.x

Consultation des journaux

GlitchTip

Latest

Error tracking (Sentry-compatible)

OpenTelemetry

Latest

Distributed tracing

8.6.2. Métriques Collectées

Catégorie Métriques

Infrastructure

CPU, RAM, disk, network, pods status

Application

Request rate, latency (P50, P95, P99), error rate

Base de données

Connexions, queries/s, slow queries, replication lag

Kafka

Consumer lag, throughput, partition status

Business

Évaluations créées, soumissions, rapports générés

8.6.3. Dashboards Grafana

Dashboard Contenu

Overview

Santé globale, SLA, alertes actives

Microservices

Métriques par service (RED: Rate, Errors, Duration)

PostgreSQL

Connexions, performances requêtes, réplication

Kafka

Topics, consumer groups, lag

Kubernetes

Pods, nodes, resources usage

Business KPIs

Métriques métier temps réel

8.6.4. Canal de Notification

Email : Toutes les alertes et rapports sont envoyés par email.

8.7. Tierce Maintenance Applicative

IT-NUM assure la maintenance applicative pendant les 12 premiers mois après la réception définitive, conformément au contrat (TDR 4.8).

8.8. Disponibilité

L’objectif de disponibilité est défini avec le client (TDR 4.1.6.1).

9. Glossaire

Terme Définition

ANIP

Agence Nationale d’Identification des Personnes. Organisme gouvernemental responsable de l’identification unique des citoyens via le Numéro d’Identification Personnelle (NIP).

API Gateway

Point d’entrée unique pour toutes les requêtes API du système. Assure l’authentification, l’autorisation, le routage et le rate limiting.

bdes-evaluation

Système pour l’évaluation des enseignants, avec IHM + backend, NON exposé via X-Road, récupère des données référentielles de bdes-referentiel, hébergé sur evaluation.dce.presidence.bj.

bdes-referentiel

Système qui agrège des données de sources autoritaires (scolarités, ministères, etc.) via un pipeline de traitement (déduplication, etc.), exposé via X-ROAD.

Blue/Green Deployment

Stratégie de déploiement avec deux environnements identiques (Blue et Green). Déploiement sur Green, bascule du trafic, rollback vers Blue si problème.

CAMES

Conseil Africain et Malgache pour l’Enseignement Supérieur. Organisme régional d’accréditation et d’harmonisation des formations.

Circuit Breaker

Pattern de résilience empêchant l’appel répété d’un service défaillant. Évite la propagation des pannes en cascade.

Code d’accès

Code unique et sécurisé généré pour chaque événement d’évaluation, permettant l’accès anonyme au formulaire par les répondants.

DCE

Délégation au Contrôle et à l’Éthique dans l’Enseignement Supérieur. Structure gouvernementale responsable du contrôle qualité de l’enseignement supérieur.

EC

Élément Constitutif. Sous-division d’une Unité d’Enseignement (UE), généralement correspondant à un cours ou un module spécifique.

EES

Établissement d’Enseignement Supérieur. Université, institut ou école du supérieur (UAC, UP, UNA, UNSTIM, etc.).

Événement d’évaluation

Instance concrète d’une évaluation planifiée, avec période d’activation, formulaire associé, ressource cible et codes d’accès.

Failover

Bascule automatique vers un système de secours en cas de défaillance du système principal. Objectif : minimiser l’interruption de service.

HAProxy

Load balancer open-source haute performance utilisé pour répartir la charge entre les nœuds des tiers Web, App, DB et Tools.

JWT (JSON Web Token)

Standard de token sécurisé pour l’authentification et l’échange d’informations. Composé de 3 parties : header, payload (claims), signature.

Kafka

Plateforme de streaming distribué pour messagerie asynchrone, événements métier et intégration inter-services.

Keycloak

Serveur open-source d’authentification et d’autorisation (IAM). Support OAuth2, OIDC, SAML, fédération d’identités et SSO.

Microservices

Architecture logicielle basée sur des services indépendants, déployables séparément, communiquant via APIs REST ou messagerie.

MFA (Multi-Factor Authentication)

Authentification multi-facteurs. Combinaison de plusieurs méthodes de vérification (mot de passe + SMS/OTP/biométrie).

MTTR (Mean Time To Resolution)

Temps moyen de résolution d’un incident. Indicateur clé pour mesurer l’efficacité de la réponse aux incidents.

NIP

Numéro d’Identification Personnelle. Identifiant unique national délivré par l’ANIP à chaque citoyen béninois.

OIDC (OpenID Connect)

Couche d’identité au-dessus d’OAuth2, permettant l’authentification des utilisateurs via tokens standardisés (ID Token).

Prometheus

Système open-source de monitoring et d’alerting. Collecte métriques time-series, requêtes PromQL, alerting.

RBAC (Role-Based Access Control)

Contrôle d’accès basé sur les rôles. Attribution de permissions aux utilisateurs via leur appartenance à des rôles prédéfinis.

Redis

Base de données clé-valeur en mémoire (in-memory). Utilisée pour cache distribué, sessions, et données temporaires haute performance.

RPO (Recovery Point Objective)

Objectif de Point de Reprise. Perte de données maximale acceptable en cas d’incident.

RTO (Recovery Time Objective)

Objectif de Temps de Reprise. Durée maximale d’interruption de service acceptable.

SLA (Service Level Agreement)

Accord sur le niveau de service. Contrat définissant les engagements de disponibilité, de performance et de support.

SPA (Single Page Application)

Application web monopage. Interface utilisateur dynamique développée en Vue.js, communiquant avec le backend via APIs REST.

Spring Boot

Framework Java pour développement rapide de microservices. Intégration Spring, configuration automatique, serveur embarqué.

SSO (Single Sign-On)

Authentification unique. L’utilisateur s’authentifie une seule fois pour accéder à plusieurs applications (via Keycloak).

TLS (Transport Layer Security)

Protocole de sécurisation des communications réseau. Les versions retenues par flux figurent au chapitre Sécurité du DAT.

UAC

Université d’Abomey-Calavi. Principale université publique du Bénin.

UE (Unité d’Enseignement)

Regroupement cohérent de plusieurs Éléments Constitutifs (EC) au sein d’un programme de formation.

UFR (Unité de Formation et de Recherche)

Structure académique regroupant plusieurs départements ou filières au sein d’une université (ex: UFR Sciences, UFR Lettres).

UNA

Université Nationale d’Agriculture. Université publique spécialisée dans les sciences agronomiques.

UNSTIM

Université Nationale des Sciences, Technologies, Ingénierie et Mathématiques.

UP

Université de Parakou. Deuxième université publique du Bénin, située dans le nord du pays.

Vue.js

Framework JavaScript progressif pour la construction d’interfaces utilisateur réactives. Version 3 utilisée dans bdes-evaluation.

WAF (Web Application Firewall)

Pare-feu applicatif web. Filtre et surveille le trafic HTTP/HTTPS pour bloquer les attaques (injection SQL, XSS, CSRF).

X-ROAD

Plateforme d’interopérabilité gouvernementale permettant l’échange sécurisé de données entre administrations publiques.