Le renversement pédagogique
L’objectif n’est pas d’enseigner séparément Linux, la base de données, l’orchestrateur ou la gestion des identités.
| Approche classique | Approche du laboratoire |
|---|---|
| Un cours par logiciel, dans un ordre imposé | Une entreprise, un système d’information, des besoins métiers |
| L’apprenant sait installer | L’apprenant sait pourquoi le composant existe et à quel besoin il répond |
| Les exercices sont indépendants | Les choix d’une semaine contraignent ceux de la suivante |
| La réussite se mesure au bon fonctionnement | La réussite se mesure à la capacité d’exploiter, restaurer, faire évoluer et documenter |
L’entreprise-école
Une entreprise fictive mais réaliste, dont le système d’information doit progressivement couvrir treize fonctions.
- ·Direction générale
- ·Finance et gestion intégrée
- ·Ressources humaines
- ·Ventes et relation client
- ·Achats
- ·Gestion de projets
- ·Documents et collaboration
- ·Communication
- ·Support et gestion des services
- ·Données et décisionnel
- ·Sécurité
- ·Production métier
- ·Production informatique
Les apprenants ne construisent donc pas une infrastructure : ils informatisent une entreprise entière.
Quinze domaines technologiques
Un catalogue pédagogique de référence — et non une obligation universelle. Les apprenants doivent apprendre à comparer les solutions et à justifier leurs choix selon la maturité, la communauté, le support, les compétences disponibles, les contraintes réglementaires, les risques et le coût total de possession.
| Domaine | Technologies candidates |
|---|---|
| Systèmes serveurs | Debian, Ubuntu Server, Rocky Linux |
| Virtualisation | KVM, Proxmox VE |
| Cloud privé | OpenStack |
| Conteneurs | containerd |
| Orchestration | Kubernetes |
| Stockage | Ceph, MinIO |
| Réseau | FRRouting, Open vSwitch, Cilium |
| Noms et adressage | BIND, Kea |
| Identités et accès | Keycloak |
| Bases de données | PostgreSQL, MariaDB |
| Messagerie | Apache Kafka, RabbitMQ |
| Gestion des interfaces | Apache APISIX, KrakenD |
| Observabilité | Prometheus, Grafana, Loki, OpenTelemetry |
| Chaîne de livraison | GitLab ou Forgejo, Argo CD, Ansible |
| Sécurité | Wazuh, Suricata, OpenBao, Trivy |
Six niveaux
Sept cent vingt heures au total, sur douze à dix-huit mois, dont environ soixante pour cent de pratique. L’admission directe à un niveau supérieur reste possible après évaluation pratique des prérequis.
| Niveau | Capacité démontrée | Durée |
|---|---|---|
| P0 | Explorer — comprendre l’écosystème et présélectionner une technologie | 40 h |
| P1 | System Builder — construire les fondations du système d’information | 120 h |
| P2 | Integrator — faire communiquer les systèmes | 120 h |
| P3 | Platform Engineer — industrialiser déploiement et exploitation | 160 h |
| P4 | Reliability & Security Engineer — sécuriser et rendre le système résilient | 160 h |
| P5 | Enterprise Architect — concevoir et gouverner le système global | 120 h |
La compétence clé et le projet de chaque niveau
Chaque palier se clôt sur un projet appliqué à l’entreprise-école. C’est lui, et non le programme parcouru, qui atteste de la compétence.
| Niveau | Compétence clé | Projet |
|---|---|---|
| P0 | Évaluer et justifier un choix technologique | Choisir une solution de gestion des identités pour l’entreprise |
| P1 | Déployer un environnement fonctionnel et reproductible | Construire le système d’information initial |
| P2 | Intégrer applications et données de bout en bout | Le processus complet de l’embauche au départ |
| P3 | Construire une plateforme applicative automatisée | Une plateforme partagée par plusieurs équipes |
| P4 | Maintenir le service, restaurer et réduire les risques | Rendre l’entreprise résiliente |
| P5 | Concevoir une architecture d’entreprise et la faire évoluer | Un plan de transformation sur trois ans |
Le changement de formulation visé. À la sortie, l’apprenant ne dit plus « je connais Kubernetes ». Il démontre qu’il sait contribuer à la conception et à l’exploitation d’un système d’information d’entreprise, et déterminer dans quels contextes une solution open source répond aux exigences.
Apprendre par les événements
Le système d’information évolue avec l’entreprise. Les incidents et les demandes ne sont pas des exercices ajoutés : ils sont le programme.
| Semaine | Ce que l’entreprise annonce |
|---|---|
| 3 | Recrutement de cent collaborateurs |
| 5 | Ouverture d’une nouvelle agence |
| 8 | La base de données principale devient indisponible |
| 10 | Un compte d’administration est compromis |
| 12 | La direction générale exige un plan de reprise |
| 15 | Passer de cinq cents à cinquante mille clients |
Face à chaque événement, les équipes analysent, architecturent, construisent, testent, exploitent et documentent.
Le laboratoire de la panne
Une partie importante de l’apprentissage consiste à provoquer volontairement des incidents contrôlés : perte d’un nœud, panne de la base principale, disque saturé, certificat expiré, saturation processeur, coupure réseau, perte d’un site, erreur de configuration.
Un exemple de mission : l’arrivée d’un collaborateur
Le niveau d’intégration ne s’enseigne pas par les protocoles mais par un cas que toute entreprise connaît. Une embauche traverse cinq systèmes, et chacun doit rester cohérent avec les autres.
Le départ est l’exercice symétrique, et le plus révélateur : révocation des accès, clôture des demandes en cours, conservation des données conforme aux obligations. Une organisation qui sait créer un compte et ne sait pas le fermer n’a pas intégré ses systèmes.
Les huit incidents provoqués
Au niveau de la fiabilité, le jury injecte des pannes contrôlées. Chacune a un objectif précis, et la réussite se mesure au rétablissement, pas à l’explication.
| Incident | Ce qu’il faut démontrer |
|---|---|
| Perte d’un nœud d’orchestration | Maintenir ou restaurer les applications |
| Panne de la base de données principale | Basculer et contrôler les données |
| Saturation du stockage | Détecter, contenir, rétablir |
| Certificat expiré | Restaurer les communications sécurisées |
| Compromission simulée d’un compte | Révoquer et analyser les traces |
| Perte du site principal | Exécuter le plan de reprise, mesurer les objectifs de reprise et de perte de données |
| Suppression de données | Restaurer et vérifier l’intégrité |
| Absence d’un expert | Faire intervenir le binôme à partir des procédures écrites |
Le huitième incident n’est pas technique. Il applique au laboratoire le principe de haute disponibilité humaine : chaque composant critique a un titulaire et un binôme, et l’exercice consiste à retirer le titulaire. La matrice de compétences, les procédures d’exploitation et les exercices de remplacement en constituent les preuves.
Comment un niveau se valide
Six dimensions, pondérées. La réalisation technique ne pèse que trente pour cent : le reste mesure ce qui fait la différence entre un exploit individuel et une capacité transmissible.
| Dimension | Poids indicatif |
|---|---|
| Réalisation technique | 30 % |
| Tests et preuves | 20 % |
| Soutenance et justification | 15 % |
| Documentation et reproductibilité | 15 % |
| Connaissances et compréhension | 10 % |
| Collaboration et disponibilité humaine | 10 % |
Un seuil indicatif de 70 sur 100, et quatre règles. Aucun défaut critique non résolu en sécurité ou en restauration n’est admis. Les preuves doivent être vérifiables. La démonstration reste individuelle, même lorsque le projet est collectif. Et un score élevé ne compense jamais un critère éliminatoire.
Le projet final
Une promotion devient une véritable direction des systèmes d’information, répartie en huit équipes : infrastructure et cloud, réseau, cybersécurité, ingénierie de plateforme, fabrique logicielle, données, applications d’entreprise, architecture.
Le formateur joue successivement les rôles de direction générale, de direction informatique, de métier, de client, d’auditeur et de gestionnaire d’incident.
Les métiers visés
La progression ne conduit pas à un diplôme généraliste : chaque palier rapproche d’un rôle identifiable sur le marché.
- ·Administrateur systèmes et réseaux
- ·Ingénieur DevOps ou ingénieur de plateforme
- ·Ingénieur sécurité et centre opérationnel de sécurité
- ·Ingénieur données
- ·Architecte systèmes
- ·Architecte d’entreprise
- ·Responsable infrastructure
- ·Consultant open source
Une réserve qui mérite d’être lue. Ces métiers représentent des perspectives de développement professionnel, et non des emplois garantis par le cursus. Les durées, proportions et seuils indiqués sur cette page sont des propositions pédagogiques, non des certifications ou des normes externes.
L’organisation d’une promotion
Une cohorte pilote de vingt-quatre apprenants, répartis en quatre équipes de six : infrastructure et cloud, applications et données, plateforme et intégration, sécurité et fiabilité.
Les périmètres tournent à chaque cycle. L’objectif est double : développer la polyvalence, et empêcher qu’une équipe devienne l’unique détentrice d’une compétence — le point de défaillance humain que le laboratoire enseigne précisément à supprimer.
Une précaution d’exploitation. Le système d’information de référence doit être sauvegardé et rester distinct des environnements isolés utilisés pour les tests destructifs. Une promotion ne doit jamais pouvoir détruire le travail de la précédente.
Les promotions successives
Ce que le laboratoire produit pour l’institution
Au-delà des compétences formées, six actifs réutilisables — c’est ce qui distingue un cursus d’un dispositif reproductible.
- 01Le référentiel de connaissances et de compétences
- 02Le plan d’architecture et de déploiement du système-école
- 03Le cadre d’évaluation pratique : épreuves, critères, preuves, jurys
- 04Le radar technologique, catalogue vivant des technologies évaluées
- 05Le manuel d’exploitation du laboratoire : sécurité, sauvegardes, coûts
- 06Le kit de déploiement pour les universités partenaires
Les référentiels consultés
Ces ressources aident à bâtir le cursus. Leur mention n’implique aucune accréditation ni reconnaissance officielle du programme, et une matrice de correspondance reste à établir entre les compétences visées et ces référentiels.
| Domaine | Ressource |
|---|---|
| Compétences numériques | SFIA |
| Gouvernance open source | TODO Group |
| Communautés et maturité | Apache Software Foundation |
| Sécurité open source | OpenSSF |
| Cloud natif | CNCF |
| Fiabilité des services | Google SRE Books |
| Architecture d’entreprise | The Open Group — TOGAF |
Choisir, et savoir le justifier
Le laboratoire ne fournit pas la réponse technique. Il apprend à la construire : la méthode de sélection des technologies en est le complément indispensable.
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.