Le principe de conception
Ce qui se partage, ce qui ne se partage pas
Distinguer les composants communs — interfaces, protocoles, référentiels, logiciels — des responsabilités et des données qui doivent rester sous contrôle national ou institutionnel.
C’est la ligne qui décide de la réussite d’un dispositif mutualisé. La franchir produit un projet que personne ne ratifie ; ne pas l’atteindre produit une mutualisation sans économie. Les modalités exactes dépendent des règles applicables à chaque pays.
Quatre échelles
| Échelle | Application pédagogique |
|---|---|
| Nationale | Services partagés entre ministères, universités, hôpitaux ou administrations |
| Régionale | Services communs à plusieurs pays d’une communauté économique |
| Continentale | Interconnexion de plateformes entre communautés régionales africaines |
| Internationale | Coopération entre infrastructures et institutions de plusieurs continents |
Six niveaux, quarante-neuf semaines
| Niveau | Objectif | Livrable |
|---|---|---|
| P0 · 3 sem. | Explorer — modèles de mutualisation, acteurs, licences, souveraineté ; comparer centralisé, fédéré et distribué | Cartographie d’un service partagé entre trois pays fictifs |
| P1 · 6 sem. | Shared Services Builder — construire un service réutilisable par plusieurs institutions | Interface mutualisée utilisée par trois organisations fictives |
| P2 · 8 sem. | Cross-Border Integrator — faire communiquer des systèmes nationaux hétérogènes par standards ouverts | Plateforme d’intégration entre trois pays simulés |
| P3 · 10 sem. | Regional Platform Engineer — déployer une infrastructure partagée, automatisée et distribuée | Cloud régional de laboratoire, sur plusieurs sites simulés |
| P4 · 10 sem. | Reliability & Security Engineer — sécurité, résilience et continuité d’un service transfrontalier | Plateforme éprouvée, rapports de résilience et de sécurité |
| P5 · 12 sem. | Continental & Global Systems Architect — architecture, gouvernance et modèle économique d’un service multinational | Dossier complet d’architecture et de gouvernance |
Douze domaines
- 01Gouvernance : accords multinationaux, responsabilités, organes de décision
- 02Architecture : systèmes fédérés, distribués, mutualisés
- 03Cloud : hybride, multi-fournisseurs, infrastructure partagée
- 04Identité : fédération, authentification unique, habilitations
- 05Données : interopérabilité, catalogues, résidence, partage
- 06Paiements : interconnexion et simulation de systèmes financiers
- 07Cybersécurité : confiance zéro, infrastructure à clés, réponse aux incidents
- 08Réseaux : interconnexion transfrontalière, résolution de noms, routage
- 09Chaîne de livraison : fabrique logicielle multi-institutions
- 10Exploitation : fiabilité, observabilité, continuité, reprise
- 11Économie : répartition des coûts, tarification, maîtrise des dépenses
- 12Coopération : communautés open source, fondations, standards
Chaque domaine donne lieu à une preuve vérifiable : architecture, code, configuration, procédure, test ou dossier de gouvernance.
Le laboratoire à trois pays
| Couche | Ce qu’elle porte |
|---|---|
| Portail régional | Catalogue commun, interfaces, gestion des accès |
| Plateforme mutualisée | Passerelle, identité fédérée, bus d’événements, registre de services, observabilité |
| Nœuds nationaux | Trois environnements simulés, chacun conservant ses responsabilités et ses données propres |
Un modèle pédagogique, non un déploiement de production validé. L’exercice fil rouge consiste à connecter trois environnements nationaux simulés à une plateforme commune — chaque pays conservant les données qui doivent rester sous son contrôle.
Les technologies candidates
| Technologie | Usage pédagogique |
|---|---|
| OpenStack | Infrastructure cloud mutualisée |
| Kubernetes | Orchestration des services |
| Keycloak | Fédération d’identité et gestion des accès |
| Apache Kafka | Échanges événementiels |
| Mojaloop | Simulation de l’interopérabilité des paiements |
| OpenTelemetry | Instrumentation et télémétrie |
| Prometheus | Collecte et interrogation des métriques |
Toute sélection pour un projet réel suppose de vérifier la version, la licence, la maintenance, la sécurité et l’adéquation aux exigences.
Dix services à construire
- 01Cloud régional mutualisé pour universités et institutions
- 02Identité académique fédérée
- 03Plateforme simulée de paiements interopérables
- 04Bibliothèque numérique continentale
- 05Réseau de données agricoles
- 06Plateforme régionale de coordination en cybersécurité
- 07Registre de compétences et de certifications
- 08Infrastructure partagée de recherche scientifique
- 09Plateforme d’interopérabilité administrative
- 10Observatoire continental des services numériques
Ce sont des propositions de travaux pratiques et de démonstrateurs — ni services existants, ni partenariats conclus.
Ce que la gouvernance doit produire
Sept documents, sans lesquels aucun service mutualisé ne survit à son premier désaccord.
| Dimension | Livrable |
|---|---|
| Gouvernance | Convention de coopération multinationale |
| Financement | Budget partagé et clés de contribution |
| Propriété intellectuelle | Politique de licences et de contributions |
| Données | Matrice de responsabilités et règles de partage |
| Exploitation | Catalogue de services et engagements de service |
| Sécurité | Politique commune et procédures d’incident |
| Réversibilité | Plan de sortie d’un membre ou d’un fournisseur |
Le dernier est celui qui rend les six autres signables. Une institution n’adhère à un dispositif partagé que si elle sait comment en sortir. C’est le même principe que le clausier de réversibilité du livre blanc, transposé à la coopération entre États.
Trois modèles économiques sont comparés : financement par les membres, facturation à l’usage, financement mixte. Les apprenants justifient leur choix à partir d’hypothèses explicites.
Le projet final : huit pays
Huit institutions nationales souhaitent partager une infrastructure numérique tout en conservant leurs responsabilités. Dix livrables attendus.
- ·Cartographie des besoins des huit institutions
- ·Architecture fonctionnelle et technique
- ·Choix argumenté des composants open source
- ·Modèle de fédération d’identité
- ·Architecture des données et flux transfrontaliers
- ·Modèle de gouvernance et de financement
- ·Plan de cybersécurité et de continuité
- ·Prototype fonctionnel sur trois sites simulés
- ·Tests de résilience et d’interopérabilité
- ·Dossier de déploiement et soutenance
L’évaluation combine preuves techniques, prototype, soutenance et regard indépendant. Le parcours ne constitue pas à lui seul une accréditation professionnelle reconnue par un organisme tiers. Les durées, certifications et architectures présentées sont des propositions, non des dispositifs accrédités ou déployés.
La mutualisation, déjà argumentée
Le livre blanc consacre une section entière à ce que les institutions financières de la zone peuvent mutualiser — socle technique, veille de sécurité, expertise rare, achat de support — et à ce qui ne le peut pas.
L’auteur
Lionel Sakiti
Program Manager Cloud & IA souveraines. Il travaille sur les infrastructures de paiement, les programmes de cloud et d’intelligence artificielle souverains et la gouvernance des données dans la zone UEMOA.