De l’exploitation à la fiabilité

La chaîne des jalons

Chaque jalon renvoie à sa fiche de parcours : problème traité, promesse, prérequis, jalons mensuels et pile technique.

Aboutissement : Manager Platform

Sommaire de la monographie

• —Résumé exécutif
• 01Le cursus en un coup d'œil
• 02Pourquoi cette voie — le contexte UEMOA
• 03Jalon 1 · Opérateur d'Exploitation Cloud Native (08)
• 04Jalon 2 · Ingénieur Observabilité (12)
• 05Jalon 3 · Site Reliability Engineer — SRE (14)
• 06La passerelle F1 → F6 — le franchissement décisif
• 07Jalon 4 · Manager Platform Engineering (95)
• 08Plan de mise en œuvre sur 30 mois
• 09Étude de cas — la trajectoire de Fatou
• 10Activer ce cursus — lecture RH & DSI
• 11Conclusion
• AAnnexe A — récapitulatif des quatre jalons
• BAnnexe B — compétences & certifications par jalon
• CAnnexe C — glossaire & repères
• DAnnexe D — variantes, bifurcations & cursus voisins
• EAnnexe E — indicateurs de progression par jalon
• FAnnexe F — ressources de montée en compétences

Résumé exécutif

Quatre jalons prouvés, une passerelle décisive : comment l'exploitation mène, en quelques années, au pilotage de la fiabilité.

Le cursus « De l'exploitation à la fiabilité » conduit un opérateur d'exploitation jusqu'au poste de Manager Platform Engineering. Il enchaîne trois trajectoires internes à la Famille 1 — Opérateur d'Exploitation, Ingénieur Observabilité, puis Site Reliability Engineer — qui transforment un exploitant réactif en ingénieur de la fiabilité, puis une unique passerelle vers la Famille 6 — Manager Platform — qui en fait le pilote de l'équipe.

Son enjeu se concentre sur un seul mouvement : le franchissement de l'ingénierie au management. Trois jalons relèvent de l'approfondissement ; le quatrième, du changement de nature. C'est sur ce franchissement, sa compétence-pont et ses conditions de réussite, que cette monographie insiste le plus, car c'est lui qui fait — ou défait — les managers issus de la fiabilité.

Pour les organisations de la zone UEMOA, ce cursus est un instrument de continuité et de succession : former en interne le manager qui connaît la fiabilité de bout en bout, plutôt que de dépendre d'un marché de profils SRE rares et chers. Ce document en détaille chaque jalon, le plan de mise en œuvre sur trente mois, une étude de cas chiffrée et la lecture RH & DSI pour l'activer.

01

Le cursus en un coup d'œil

De la tenue de la production à l'ingénierie de la fiabilité, puis au pilotage de l'équipe : quatre jalons, une seule passerelle, la voie qui fait de la disponibilité une discipline.

Le cursus « De l'exploitation à la fiabilité » relève de l'axe « Direction technique ». Il part d'un poste d'exploitation — l'Opérateur d'Exploitation Cloud Native — et conduit, en quatre jalons prouvés, jusqu'au poste de Manager Platform Engineering. Sa logique : trois trajectoires internes à la Famille 1 (Infrastructures) qui transforment un exploitant réactif en ingénieur de la fiabilité, puis une unique passerelle vers la Famille 6 (Management) qui fait de cet ingénieur le pilote de l'équipe.

Trois des quatre mouvements relèvent de la même logique : approfondir, prouver, capitaliser. Le mouvement central — le franchissement de l'ingénierie au management, du SRE au Manager Platform — est le moment décisif du cursus. C'est lui qui distingue un excellent SRE d'un dirigeant, et c'est sur lui que ce document insiste le plus.

Les quatre jalons

Jalon	Rôle (n°)	Famille	Niveau	Durée
1	Opérateur d'Exploitation Cloud Native (08)	F1 · Infrastructures	Exploiter	0 – 6 mois
2	Ingénieur Observabilité (12)	F1 · Infrastructures	Observer	6 – 14 mois
3	Site Reliability Engineer — SRE (14)	F1 · Infrastructures	Fiabiliser	14 – 24 mois
4	Manager Platform Engineering (95)	F6 · Management	Piloter	24 mois +

Profil d'entrée, profil de sortie

À l'entrée, un opérateur qui tient la production et éteint les incendies. À la sortie, un manager qui pilote l'équipe garante de la continuité des services critiques. Entre les deux, une transformation continue — de l'exploiter à l'observer, puis au fiabiliser, puis au piloter.

02

Pourquoi cette voie — le contexte UEMOA

Dans le paiement, l'indisponibilité se paie cash : pertes directes, confiance entamée, regard du régulateur. La fiabilité devient un actif stratégique — et ce cursus, une réponse à la pénurie d'ingénieurs SRE.

Dans la zone UEMOA, la continuité de service n'est pas une option. Un opérateur de mobile money interrompu, ce sont des millions de transactions bloquées, des marchands sans encaissement, des clients sans recours. La disponibilité conditionne la confiance, et la confiance conditionne l'adoption. Or les profils capables d'ingénierie de la fiabilité — mesurer, fiabiliser, tenir des engagements de service — sont rares, et plus rares encore ceux qui savent en diriger l'équipe.

Ce cursus répond à trois besoins structurels du marché régional. D'abord la continuité de service : tenir une disponibilité élevée sur des services critiques, 24 heures sur 24. Ensuite la maîtrise du risque opérationnel : anticiper les dégradations plutôt que les subir, et répondre aux attentes de continuité du régulateur. Enfin la montée en valeur des talents internes, des exploitants vers le management, plus rapide et moins coûteuse qu'un recrutement externe.

Trois moteurs de la demande

Moteur	Ce qu'il impose	Rôle du cursus
Continuité du mobile money	Disponibilité 24/7, détection avant le client, reprise rapide.	Forme l'exploitant, puis le SRE qui ingénie la fiabilité.
Exigences de continuité (BCEAO)	Maîtrise du risque, engagements de service démontrables.	Construit la culture SLO et la gestion d'incidents structurée.
Pénurie d'ingénieurs fiabilité	Des SRE et des managers crédibles, issus du terrain.	Trace une voie interne vers le pilotage, ancrée sur la preuve.

Pour une direction des systèmes d'information de la zone, ce cursus est un instrument de continuité et de souveraineté opérationnelle. Le manager issu de la fiabilité connaît intimement ce qu'il pilote : il sait ce que coûte une minute d'indisponibilité, ce qu'exige un SLO tenu, ce que vaut une équipe qui anticipe au lieu de subir.

À qui ce cursus profite dans la zone

Employeur	Poste-cible	Pourquoi ce cursus
Opérateur mobile money / fintech	SRE, manager fiabilité	Disponibilité 24/7, coût de l'indisponibilité, montée en charge.
Banque / établissement financier	SRE, manager plateforme	Continuité réglementaire, maîtrise du risque opérationnel.
Opérateur télécom	SRE senior, manager d'exploitation	Plateformes critiques, astreinte industrialisée.
Hébergeur / cloud souverain	Ingénieur fiabilité, responsable d'exploitation	Engagements de service vendus aux clients.

03

Jalon 1 · Opérateur d'Exploitation Cloud Native (08)

• FamilleF1 · Infrastructures
• MouvementDépart
• NiveauExploiter
• Durée0 – 6 mois

Le point d'entrée du cursus : tenir la production, passer du run réactif à l'exploitation maîtrisée et documentée.

Le rôle

L'Opérateur d'Exploitation Cloud Native tient les services en production : déploiements, mises à jour, réponse aux incidents, astreinte, runbooks. Il est le garant de la disponibilité au quotidien. Souvent certifié CKA, il opère des clusters Kubernetes et les applications qui s'y exécutent. C'est un rôle d'« exploiter » : il agit, mais il agit proprement — en laissant des runbooks et des post-mortems plutôt que des interventions oubliées.

Beaucoup d'administrateurs et d'opérateurs entrent dans la filière fiabilité par ce poste, souvent dans une fintech ou une banque qui exploite ses services de paiement. Il ne demande pas une expertise rare, mais une discipline : tout incident se documente, toute action répétitive s'automatise, toute défaillance s'analyse. C'est là que se prennent les habitudes — bonnes ou mauvaises — qui détermineront la suite.

Missions principales

Mission	En quoi elle consiste
Tenir la production	Opérer clusters et services, gérer déploiements et rollbacks.
Répondre aux incidents	Diagnostiquer, rétablir le service, limiter l'impact.
Assurer l'astreinte	Prendre les alertes, intervenir hors heures, escalader si besoin.
Documenter	Tenir les runbooks et rédiger des post-mortems.
Sauvegarder & restaurer	Garantir la récupération des données et des services.

Compétences à acquérir

• Kubernetes en production : déploiements, mises à jour, diagnostic (CKA).
• Gestion d'incidents : méthode, communication, rétablissement.
• Runbooks et post-mortems : documenter pour ne pas réapprendre.
• Scripting d'automatisation : réduire les tâches manuelles répétitives.
• Bases réseau et stockage : comprendre la couche sous-jacente.
• Hygiène de production : sauvegardes, restauration, gestion des secrets.

Une semaine-type

Activité	Part du temps
Exploitation courante : déploiements, mises à jour, suivi	≈ 40 %
Réponse aux incidents et astreinte	≈ 30 %
Automatisation de tâches récurrentes	≈ 20 %
Runbooks, post-mortems, documentation	≈ 10 %

Le mouvement

C'est le départ du cursus. Le professionnel capitalise un socle d'exploitation — opération, incidents, automatisation, documentation — qui servira à chacun des jalons suivants. La qualité de ce socle conditionne la suite : un exploitant qui automatise et analyse déjà ses incidents deviendra un bien meilleur ingénieur observabilité que celui qui se contente d'éteindre les feux.

Pièges à éviter

• Rester réactif : éteindre les incendies sans jamais traiter les causes profondes.
• Négliger les post-mortems : perdre l'apprentissage de chaque incident.
• Subir le toil : répéter à la main des tâches qui devraient être automatisées.

04

Jalon 2 · Ingénieur Observabilité (12)

• FamilleF1 · Infrastructures
• MouvementTrajectoire interne (F1 → F1)
• NiveauObserver
• Durée6 – 14 mois

On ne fiabilise que ce que l'on mesure : instrumenter le système pour voir, anticiper et comprendre avant que le client ne subisse.

Le rôle

L'Ingénieur Observabilité conçoit la capacité de l'organisation à voir l'état de ses systèmes : métriques, journaux, traces distribuées, tableaux de bord, alerting pertinent et premiers indicateurs de niveau de service (SLI). Il fait passer l'équipe de « subir les incidents » à « les anticiper ». C'est un rôle d'« observer » : il ne se contente plus d'agir, il construit les yeux du système.

Ce jalon est le préalable indispensable au SRE. On ne peut pas fixer d'objectif de fiabilité sans mesurer la fiabilité réelle ; on ne peut pas réduire un temps de résolution sans le mesurer d'abord. L'ingénieur observabilité conçoit donc l'instrumentation et l'alerting qui rendront possible l'ingénierie de la fiabilité. Surtout, il combat un fléau : le bruit d'alerte, qui épuise les équipes et masque les vrais signaux.

Missions principales

Mission	En quoi elle consiste
Instrumenter	Outiller le code et l'infrastructure (OpenTelemetry, exporters).
Collecter les signaux	Métriques (Prometheus), journaux centralisés, traces distribuées.
Visualiser	Construire des tableaux de bord lisibles et orientés service.
Alerter juste	Concevoir un alerting basé sur les symptômes, réduire le bruit.
Définir les SLI	Choisir les indicateurs qui reflètent l'expérience réelle des clients.

Compétences à acquérir

• Les trois piliers de l'observabilité : métriques, journaux, traces.
• Outils : Prometheus, Grafana, OpenTelemetry, agrégation de journaux.
• PromQL et requêtage : extraire le signal utile des données.
• Conception d'alertes : alerter sur les symptômes, limiter la fatigue d'alerte.
• Définition des SLI : relier la mesure à l'expérience client.
• Corrélation : relier métriques, traces et journaux pour le diagnostic.

Une semaine-type

Activité	Part du temps
Instrumentation et collecte des signaux	≈ 35 %
Conception de tableaux de bord et d'alertes	≈ 30 %
Définition et suivi des SLI	≈ 20 %
Diagnostic, corrélation, accompagnement des équipes	≈ 15 %

Le mouvement

Trajectoire interne F1 → F1 (08 → 12). De l'exploitation à la mesure. L'opérateur qui subissait les incidents construit désormais les moyens de les anticiper. Ce jalon est décisif pour la suite : sans observabilité, pas de SLO crédible, pas d'error budget, pas d'ingénierie de la fiabilité. On ne fiabilise bien que ce que l'on a d'abord appris à voir.

Pièges à éviter

• Alerter sur tout : provoquer une fatigue d'alerte qui masque les vrais incidents.
• Empiler des tableaux de bord sans SLI : mesurer sans relier à l'expérience client.
• Instrumenter sans corréler : accumuler des signaux qu'on ne sait pas recouper.

05

Jalon 3 · Site Reliability Engineer — SRE (14)

• FamilleF1 · Infrastructures
• MouvementTrajectoire interne (F1 → F1)
• NiveauFiabiliser
• Durée14 – 24 mois

La fiabilité comme discipline d'ingénierie : du symptôme au système, des SLO aux error budgets, du toil à l'automatisation.

Le rôle

Le Site Reliability Engineer fait de la fiabilité une discipline d'ingénierie. Il définit des objectifs de niveau de service (SLO) et les error budgets associés, élimine le toil par l'automatisation, anticipe la montée en charge (capacity planning), conçoit la résilience (dégradation gracieuse, ingénierie du chaos), structure la gestion d'incidents et instaure une culture de post-mortem sans blâme. C'est le sommet technique de la filière fiabilité, et un rôle d'« ingénieur » au sens plein : il programme autant qu'il opère.

Le SRE introduit une idée puissante : la fiabilité n'est pas l'absence de panne, mais un niveau de service défini et tenu. Viser 100 % est irréaliste et ruineux ; on vise un objectif explicite (par exemple 99,9 %), et l'écart autorisé — l'error budget — devient un outil de pilotage. Tant qu'il reste du budget, on peut livrer vite ; quand il s'épuise, on stabilise. Cet arbitrage permanent entre fiabilité et vélocité est exactement la posture qui préfigure le management.

Le principe directeur : SLO et error budgets

Un principe guide le SRE : mesurer, fixer un objectif, en faire un budget. Le SLI mesure l'expérience réelle ; le SLO fixe la cible ; l'error budget — la différence entre la perfection et l'objectif — quantifie le droit à l'erreur. Ce budget n'est pas une faiblesse : c'est un instrument de décision partagé entre l'ingénierie et le produit, qui remplace les débats d'opinion par un arbitrage chiffré.

Missions principales

Mission	En quoi elle consiste
Définir les SLO	Fixer les objectifs de service et les error budgets associés.
Éliminer le toil	Automatiser les tâches manuelles récurrentes par du logiciel.
Anticiper la charge	Capacity planning : dimensionner avant la saturation.
Concevoir la résilience	Dégradation gracieuse, ingénierie du chaos, tolérance aux pannes.
Structurer les incidents	Rôles, communication, post-mortems sans blâme.
Fiabiliser les releases	Déploiement progressif, retours arrière automatiques.

Compétences à acquérir

• SRE : SLI, SLO, error budgets, gestion par le budget d'erreur.
• Automatisation : éliminer le toil par du code (IaC, opérateurs).
• Résilience : dégradation gracieuse, ingénierie du chaos, tolérance aux pannes.
• Capacity planning : anticiper et dimensionner la montée en charge.
• Gestion d'incidents avancée et culture de post-mortem sans blâme.
• Programmation : un SRE écrit du logiciel, il ne fait pas que l'opérer.

Une semaine-type

Activité	Part du temps
Automatisation et élimination du toil (logiciel)	≈ 35 %
SLO, error budgets, capacity planning	≈ 25 %
Résilience, ingénierie du chaos, fiabilisation des releases	≈ 20 %
Gestion d'incidents, post-mortems, coordination	≈ 20 %

Le mouvement

Trajectoire interne F1 → F1 (12 → 14), et point culminant de la Famille 1 sur l'axe fiabilité. L'ingénieur qui mesurait conçoit désormais la fiabilité du système entier. Ce jalon est décisif pour la suite : c'est en pilotant des error budgets et en coordonnant des incidents transverses que le SRE acquiert la posture d'arbitrage qui rendra crédible son passage au management. On ne dirige bien que ce que l'on a su fiabiliser.

Pièges à éviter

• Des SLO cosmétiques : afficher des objectifs que personne ne tient ni n'arbitre.
• Viser le 100 % : poursuivre une perfection irréaliste et ruineuse.
• Conserver une culture du blâme : tuer l'apprentissage que permettent les post-mortems.

06

La passerelle F1 → F6 — le franchissement décisif

Le moment où l'ingénieur de la fiabilité devient dirigeant. Ce qui change, ce qui se conserve, et la compétence-pont qui rend le saut possible.

Les deux premiers mouvements du cursus relèvent d'une logique d'approfondissement technique. Le troisième — le passage du SRE (14) au Manager Platform Engineering (95) — est d'une autre nature. C'est le franchissement de famille : de la Famille 1 (Infrastructures) à la Famille 6 (Management). C'est lui qui transforme un parcours d'expert en cursus de leadership, et le moment le plus délicat de toute la trajectoire.

La compétence-pont

Une passerelle ne se franchit jamais à vide : elle s'appuie sur une compétence commune aux deux familles. Ici, cette compétence-pont est la posture d'arbitrage que le SRE exerce déjà à travers les error budgets, couplée à la coordination des incidents transverses. Le SRE tranche en permanence entre fiabilité et vélocité, fait dialoguer ingénierie et produit, et orchestre des équipes en situation de crise. Le management ne lui demande pas d'oublier cela : il lui demande de l'exercer sur des personnes, un budget et une roadmap plutôt que sur des budgets d'erreur.

Ce qui change, ce qui se conserve

Dimension	Avant (Site Reliability Engineer)	Après (Manager Platform)
Objet du travail	Des systèmes, des SLO, des budgets d'erreur	Des personnes, un budget, une roadmap
Mesure du succès	Fiabilité tenue, toil éliminé	Performance et croissance de l'équipe
Compétence centrale	Ingénierie de la fiabilité	Leadership, en conservant la crédibilité technique
Horizon	La fiabilité du service	La trajectoire de l'équipe et de la plateforme

Ce qui se conserve est essentiel : la crédibilité technique. Un manager qui ne comprendrait plus les SLO qu'il pilote perdrait son autorité auprès de ses SRE. Ce qui s'ajoute l'est tout autant : faire grandir les autres, arbitrer un budget, dialoguer avec les équipes clientes et la direction. Le saut n'est pas un abandon de la technique, c'est son élargissement.

Conditions de réussite

• Avoir réellement arbitré des error budgets et coordonné des incidents : la légitimité vient de là.
• Accepter de ne plus fiabiliser soi-même : déléguer et faire grandir les SRE.
• Acquérir vite les fondamentaux du management : 1:1, feedback, gestion de la performance.
• Conserver un lien avec la technique sans y retomber : arbitrer, pas re-fiabiliser à la place.

Signes qu'un SRE est prêt à franchir

Tous les excellents SRE ne deviennent pas — et ne souhaitent pas devenir — managers. Avant d'engager la passerelle, quelques signaux distinguent ceux pour qui le franchissement sera naturel de ceux qu'il mettrait en difficulté.

Signe de maturité	Ce qu'il révèle
Il fait grandir les autres SRE spontanément	Il tire satisfaction du succès collectif, pas seulement du sien.
Il pense « équipe » et « budget »	Il raisonne déjà au-delà de la seule fiabilité technique.
Il dialogue avec le produit et la direction	Il sait traduire la fiabilité en valeur et en risque.
Il accepte de déléguer la résolution	Il est prêt à coordonner plutôt qu'à intervenir lui-même.

Un programme de préparation en trois mois

Le franchissement se prépare comme un jalon à part entière. Sur trois mois, en parallèle de la fin du jalon de SRE, le futur manager amorce sa transition sans quitter brutalement la technique.

Mois	Action de préparation	Résultat visé
Mois 1	Encadrer un ou deux SRE, mener les premiers 1:1	Premier contact avec la posture de manager
Mois 2	Co-piloter la roadmap fiabilité avec le manager en place	Compréhension concrète du pilotage d'équipe
Mois 3	Prendre une responsabilité budgétaire ou d'astreinte limitée	Validation de l'appétence avant la bascule complète

07

Jalon 4 · Manager Platform Engineering (95)

• FamilleF6 · Management
• MouvementPasserelle franchie (F1 → F6)
• NiveauPiloter
• Durée24 mois +

L'aboutissement du cursus : diriger l'équipe garante de la fiabilité, son budget et sa roadmap, en restant techniquement crédible.

Le rôle

Le Manager Platform Engineering dirige l'équipe qui conçoit, opère et fiabilise la plateforme. Il recrute, fait monter en compétences, définit la roadmap, gère un budget, négocie les engagements de service avec les équipes clientes et garantit les standards d'exploitation. Il reste techniquement crédible — il comprend chaque SLO et chaque arbitrage — mais son temps se déplace vers les personnes, la planification et les parties prenantes. C'est le premier rôle où l'on est jugé sur un collectif plutôt que sur une contribution individuelle.

Ce poste est le garant institutionnel de la fiabilité : c'est lui qui porte les engagements de service au niveau de l'organisation, qui organise l'astreinte et la réponse aux incidents majeurs, et qui arbitre entre nouvelles fonctionnalités et dette d'exploitation. Dans une organisation où la continuité est stratégique, le manager de plateforme est un acteur central, en dialogue direct avec la direction technique.

Du contributeur au manager : ce qui change au quotidien

Au quotidien	Contributeur (SRE)	Manager (Platform)
Emploi du temps	Automatisation, SLO, incidents	Entretiens, planification, parties prenantes
Source de satisfaction	Un système fiable	Une équipe qui tient la fiabilité et progresse
Unité de mesure	Sa propre fiabilisation	La fiabilité produite par le collectif
Réflexe en incident	Résoudre soi-même	Coordonner, protéger l'équipe, communiquer

Missions principales

Mission	En quoi elle consiste
Management d'équipe	Recruter, mener les 1:1, évaluer la performance, faire grandir les SRE.
Roadmap fiabilité	Prioriser les chantiers de fiabilité et d'automatisation.
Budget & FinOps	Construire et tenir le budget, maîtriser les coûts d'exploitation.
Engagements de service	Porter les SLA/SLO au niveau de l'organisation.
Parties prenantes	Aligner équipes clientes et direction sur les priorités.

Compétences à acquérir

• Leadership : donner une direction, motiver, faire grandir une équipe.
• Gestion de la performance : objectifs, feedback, entretiens individuels.
• Planification & roadmap : prioriser et séquencer les chantiers de fiabilité.
• Budgétisation & FinOps : construire un budget, arbitrer les coûts.
• Communication exécutive : porter la fiabilité en langage de valeur et de risque.
• Socle technique conservé : comprendre et challenger les SLO et arbitrages.

Le mouvement

C'est la passerelle F1 → F6 franchie (14 → 95), et l'aboutissement du cursus. Le saut de famille est accompli : de l'ingénierie de la fiabilité au management de l'équipe qui la produit. Il repose sur la compétence-pont « arbitrage des error budgets + coordination d'incidents » et sur la conservation de la crédibilité technique. Ce rôle ouvre lui-même de nouveaux horizons : direction de plateforme élargie, puis direction technique (CTO) via les cursus voisins.

Pièges à éviter

• Redevenir SRE : reprendre la résolution technique au lieu de faire grandir l'équipe.
• Micro-manager : contrôler chaque détail au lieu de fixer un cap et de faire confiance.
• Négliger le budget et les parties prenantes, dimensions nouvelles du rôle.

08

Plan de mise en œuvre sur 30 mois

Un jalon à la fois, une preuve à chaque étape : la cadence qui sécurise la progression de l'exploitant au manager de plateforme.

Le cursus complet se déploie sur une trentaine de mois, de l'exploitation au management de plateforme. La règle est constante : chaque jalon mobilise plusieurs mois, le temps de produire une preuve déployable avant d'ouvrir le suivant. La phase de passerelle chevauche volontairement les jalons de SRE et de manager.

Phase	Mois	Objectif	Preuve attendue
Jalon 1	M1 – M6	Maîtrise de l'exploitation Cloud Native	Incident géré de bout en bout + post-mortem actionné
Jalon 2	M7 – M14	Conception de l'observabilité	MTTD/MTTR réduits, bruit d'alerte maîtrisé, SLI définis
Jalon 3	M15 – M24	Ingénierie de la fiabilité (SRE)	SLO + error budgets en place, toil réduit, dispo améliorée
Passerelle	M21 – M24	Acquérir les fondamentaux du management	Coordination d'équipe, premiers 1:1, co-pilotage
Jalon 4	M24 – M30	Diriger l'équipe plateforme	Engagements de service tenus + équipe renforcée + budget

Le détail mois par mois

Période	Focus	Livrable de la période
M1 – M6	Exploitation, incidents, automatisation, runbooks	Tenue d'un service critique + post-mortem de fond
M7 – M10	Instrumentation, métriques, journaux, traces	Observabilité de bout en bout sur un service
M11 – M14	Alerting juste, tableaux de bord, SLI	Bruit d'alerte réduit + SLI des services critiques
M15 – M19	SLO, error budgets, automatisation du toil	SLO en place + toil mesurablement réduit
M20 – M24	Résilience, chaos, coordination d'incidents	Disponibilité améliorée + arbitrages par budget d'erreur
M21 – M24	Préparation au management (1:1, roadmap)	Prise de responsabilité partielle sur l'équipe
M25 – M30	Management : performance, budget, parties prenantes	Équipe pilotée, engagements tenus, budget maîtrisé

09

Étude de cas — la trajectoire de Fatou

Comment WaariPay forme en interne, en trente mois, la manager de l'équipe garante de la continuité de ses paiements — sans recrutement externe.

Le point de départ

Fatou est opératrice d'exploitation chez WaariPay : six ans d'expérience, certifiée CKA, à l'aise dans la tenue de la production de paiement. Mais elle passe ses nuits à éteindre les mêmes incendies, faute d'outils pour anticiper. Elle automatise spontanément et rédige des post-mortems soignés. La DSI, qui veut industrialiser sa fiabilité et préparer sa relève, identifie en elle un potentiel et active le cursus « De l'exploitation à la fiabilité ».

La trajectoire, trimestre par trimestre

Trimestre	Jalon	Preuve produite
T1 – T2	Opérateur d'Exploitation (08)	Incident de paiement géré de bout en bout, post-mortem avec actions de fond.
T3 – T4	Ingénieur Observabilité (12)	Observabilité des paiements : détection avant le client, alerting assaini, SLI définis.
T5 – T8	Site Reliability Engineer (14)	SLO et error budgets sur les paiements, toil réduit de moitié, disponibilité en hausse.
T9	Passerelle (amorce)	Coordination de deux SRE, co-pilotage de la roadmap fiabilité, premiers 1:1.
T10	Manager Platform Engineering (95)	Équipe de fiabilité pilotée, engagements de service tenus, budget maîtrisé.

Le bilan

En une trentaine de mois, Fatou est passée d'une exploitation réactive au management de l'équipe garante de la continuité des paiements de la banque. Chaque étape s'est validée par une preuve déployable, ce qui a permis à la DSI de sécuriser sa progression sans pari. La relève sur un sujet critique — la fiabilité — est désormais interne et maîtrisée.

Les trois décisions-clés de la DSI

La réussite de Fatou ne tient pas au hasard mais à trois décisions de la DSI. D'abord, choisir le bon profil : non la plus rapide à éteindre les feux, mais celle qui cherchait à ne plus les revoir. Ensuite, garantir le temps et l'accompagnement : un mentor SRE puis un mentor manager, et un temps protégé à chaque jalon. Enfin, exiger la preuve : aucune étape validée sans livrable déployable, ce qui a permis d'avancer sans pari.

Le calcul économique

	Recrutement externe	Cursus interne (Fatou)
Délai	6 – 12 mois de recherche, profil SRE rare	Progression planifiée, disponibilité immédiate
Coût	Prime de rareté, package élevé, risque d'échec	Accompagnement (mentors, temps, outils) bien moindre
Risque	Intégration incertaine, départ possible	Profil connu, fidélisé, ancré dans l'organisation
Continuité	À reconstruire	Connaissance native des services et de leurs incidents

10

Activer ce cursus — lecture RH & DSI

De l'intention au pilotage : comment une direction RH ou DSI met concrètement ce cursus en mouvement.

Quatre usages pour une direction

Usage	Ce que le cursus permet
Continuité de service	Internaliser l'ingénierie de la fiabilité sur des services critiques.
Plan de succession	Préparer la relève sur un sujet stratégique, du terrain au management.
Fidélisation	Offrir aux exploitants une perspective lisible jusqu'au leadership.
Maîtrise du risque	Garder en interne la connaissance des incidents et de leur prévention.

Une feuille de route en 90 jours

À J+30, repérer les exploitants à fort potentiel (ceux qui automatisent et analysent leurs incidents) et le poste-cible critique (SRE, manager de fiabilité). À J+60, valider l'appétence des candidats au parcours et désigner sponsor et mentors (SRE, puis manager). À J+90, lancer le jalon 1 avec une preuve attendue clairement définie et une revue de fin de jalon planifiée.

Facteurs de réussite & risques

Facteur de réussite	Risque symétrique à éviter
Sponsor et mentors désignés pour le cursus	Lancer le parcours sans accompagnement ni temps dédié
Preuve déployable validée à chaque jalon	Valider la progression sur la seule bonne volonté
Soin particulier au franchissement F1 → F6	Promouvoir manager sans préparer au management
Rythme soutenable, un jalon à la fois	Accélérer et fragiliser les preuves

11

Conclusion

Une voie directe vers le pilotage de la fiabilité, à condition d'en respecter la discipline : la preuve à chaque jalon, et un franchissement préparé.

« De l'exploitation à la fiabilité » est l'un des cursus les plus stratégiques de la zone, car il adresse un besoin vital : la continuité. Il a pour lui la cohérence : trois trajectoires internes qui transforment un exploitant en ingénieur de la fiabilité, une passerelle unique qui en fait le pilote d'une équipe. Il a contre lui une exigence : ce franchissement ne s'improvise pas. Promouvoir un excellent SRE au management sans l'y préparer, c'est risquer de perdre un excellent SRE et de rater un manager.

Pour le professionnel, ce cursus offre une perspective rare : commencer comme exploitant et viser, en quelques années, le pilotage de l'équipe garante de la continuité. Pour l'employeur, il offre un instrument de continuité et de succession : former en interne le manager qui connaît la fiabilité de bout en bout, plutôt que de dépendre d'un marché tendu. Pour la zone UEMOA, il répond à un besoin structurel : faire émerger des ingénieurs et des managers de la fiabilité, capables de tenir les services dont dépend l'économie numérique.

Trois principes à retenir

• La preuve, pas la promesse : chaque jalon se valide par un livrable déployable.
• Le franchissement se prépare : la passerelle F1 → F6 est le vrai sujet du cursus.
• La crédibilité technique se conserve : on pilote d'autant mieux que l'on a su fiabiliser.

Pour aller plus loin

Ce cursus dialogue avec ses voisins de l'axe « Direction technique ». « Du socle au sommet » (cursus 1) prolonge le rôle de Manager Platform jusqu'au CTO ; « Du code à la direction » (cursus 2) mène à la direction par le génie logiciel. Une organisation peut activer plusieurs de ces voies en parallèle, selon ses viviers et ses postes critiques.

A

Annexe A — récapitulatif des quatre jalons

Jalon	Rôle (n°)	Famille	Mouvement	Durée
1	Opérateur d'Exploitation Cloud Native (08)	F1	Départ	0 – 6 mois
2	Ingénieur Observabilité (12)	F1	Interne	6 – 14 mois
3	Site Reliability Engineer — SRE (14)	F1	Interne	14 – 24 mois
4	Manager Platform Engineering (95)	F6	Passerelle F1 → F6	24 mois +

• Enchaînement complet08 → 12 → 14 → 95
• · FamillesF1 → F1 → F1 → F6
• · AboutissementManager Platform Engineering (95).

B

Annexe B — compétences & certifications par jalon

Jalon	Compétences clés	Certification / preuve cible
Opérateur d'Exploitation (08)	Kubernetes, incidents, runbooks, automatisation, astreinte	CKA, gestion d'incidents
Ingénieur Observabilité (12)	Métriques, journaux, traces, Prometheus/Grafana/OTel, SLI	Observabilité, PromQL
Site Reliability Engineer (14)	SLO, error budgets, toil, résilience, chaos, automatisation	SRE, programmation
Manager Platform (95)	Leadership, performance, roadmap, budget, communication	Management, agile à l'échelle

C

Annexe C — glossaire & repères

Terme	Définition
SLI	Service Level Indicator : mesure de l'expérience réelle (disponibilité, latence).
SLO	Service Level Objective : objectif chiffré fixé sur un SLI (ex. 99,9 %).
Error budget	Budget d'erreur : écart autorisé entre la perfection et le SLO ; outil d'arbitrage.
Toil	Travail manuel répétitif, automatisable, sans valeur durable — à éliminer.
MTTD / MTTR	Temps moyen de détection / de résolution d'un incident.
Observabilité	Capacité à comprendre l'état interne d'un système via métriques, journaux, traces.
Chaos engineering	Injection contrôlée de pannes pour éprouver et améliorer la résilience.
Post-mortem sans blâme	Analyse d'incident centrée sur les causes systémiques, pas sur les personnes.
Passerelle	Franchissement d'une famille de métiers à une autre, porté par une compétence-pont.
Compétence-pont	Compétence commune à deux familles, qui rend possible le passage de l'une à l'autre.

D

Annexe D — variantes, bifurcations & cursus voisins

« De l'exploitation à la fiabilité » n'est pas l'unique destin d'un exploitant. Plusieurs bifurcations s'ouvrent en chemin, et s'arrêter en route reste une carrière pleine et entière.

Ce cursus décrit une voie directe, mais le graphe des compétences en autorise d'autres. Le Site Reliability Engineer (14) est en particulier un rôle-charnière : depuis ce point, plusieurs trajectoires divergent vers d'autres familles ou d'autres formes de leadership. Connaître ces bifurcations aide une direction à orienter chaque talent vers la voie qui lui convient.

Trois bifurcations fréquentes

Bifurcation	Point de départ	Vers	Cursus voisin
Vers la sécurité	SRE (14)	DevSecOps, sécurité de la production, RSSI	C2 · De l'infra à la sécurité
Vers la donnée / l'AIOps	Observabilité (12)	Data, détection d'anomalies, AIOps	B/D · Vers la donnée
Vers la direction technique	Manager Platform (95)	Direction de plateforme élargie, CTO	A1 · Du socle au sommet

S'arrêter en chemin

Tous les professionnels n'iront pas jusqu'au management, et c'est légitime. S'arrêter au jalon de SRE constitue une carrière technique complète, recherchée et bien rémunérée, sans jamais franchir vers le management. L'expertise en fiabilité vaut le leadership : une organisation a besoin de SRE seniors autant que de managers. Le cursus n'impose pas le franchissement ; il rend la voie lisible pour ceux qui le visent.

E

Annexe E — indicateurs de progression par jalon

Comment objectiver l'avancement : pour chaque jalon, des indicateurs de maîtrise et leur cible, à revoir avant d'ouvrir le suivant.

Jalon	Indicateur de maîtrise	Cible de fin de jalon
1 · Exploitation (08)	Qualité de la réponse aux incidents	Incident géré de bout en bout + post-mortem actionné
1 · Exploitation (08)	Réduction du toil	Automatisation des tâches récurrentes les plus coûteuses
2 · Observabilité (12)	Détection avant le client	Dégradations détectées avant les utilisateurs
2 · Observabilité (12)	Qualité de l'alerting	Bruit d'alerte réduit, SLI des services critiques définis
3 · SRE (14)	Pilotage par le budget d'erreur	SLO + error budgets en place et réellement arbitrés
3 · SRE (14)	Disponibilité réelle	Disponibilité améliorée, toil mesurablement réduit
4 · Manager (95)	Tenue des engagements de service	SLA/SLO respectés au niveau de l'organisation
4 · Manager (95)	Santé de l'équipe	Rétention et montées en compétences mesurables

F

Annexe F — ressources de montée en compétences

Pour chaque jalon, les modalités d'apprentissage les plus efficaces : la pratique d'abord, la preuve ensuite, le mentorat tout du long.

Jalon	Modalités de montée en compétences
Opérateur d'Exploitation (08)	Astreinte encadrée, simulations d'incidents, préparation CKA en conditions réelles, rédaction de post-mortems ; mentorat d'un exploitant senior.
Ingénieur Observabilité (12)	Mise en place d'une stack d'observabilité de bout en bout, ateliers PromQL, conception d'alertes ; mentorat d'un ingénieur observabilité.
Site Reliability Engineer (14)	Définition de SLO réels, projets d'automatisation du toil, exercices de chaos engineering, lectures SRE de référence ; mentorat d'un SRE confirmé.
Manager Platform (95)	Formation au management (1:1, feedback, performance), accompagnement par un manager expérimenté ; coaching.

G	Annexe G — anti-modèles à éviter dans ce cursus

Les erreurs récurrentes qui font dérailler le parcours — et l'antidote correspondant, à garder en tête à chaque jalon.

Anti-modèle	Pourquoi il nuit	Antidote
Le pompier permanent	Éteindre les feux sans traiter les causes condamne à les revivre.	Post-mortems de fond et automatisation dès le jalon 1.
La fatigue d'alerte	Alerter sur tout noie les vrais signaux et épuise l'équipe.	Alerter sur les symptômes, mesurer et réduire le bruit.
Le SLO cosmétique	Un objectif affiché mais jamais arbitré ne sert à rien.	Des error budgets réellement utilisés pour décider.
La quête du 100 %	Viser la perfection est irréaliste et ruineux.	Fixer un objectif explicite et soutenable, pas absolu.
La culture du blâme	Chercher un coupable tue l'apprentissage des incidents.	Post-mortems sans blâme, centrés sur le système.
Le manager-pompier	Reprendre la résolution sous pression fait échouer le rôle.	Coordonner, protéger l'équipe, déléguer la résolution.

H	Annexe H — DevOps, SRE, Platform : trois approches de la fiabilité

Trois termes souvent confondus, trois manières complémentaires d'organiser la fiabilité : les distinguer aide à cadrer les rôles et les attentes.

Le vocabulaire de la fiabilité prête à confusion. DevOps, SRE et Platform Engineering ne sont ni synonymes ni concurrents : ce sont trois approches qui se complètent. Les situer clarifie ce qu'on attend de chaque rôle de ce cursus.

Approche	Ce qu'elle est	Apport à la fiabilité
DevOps	Une culture : rapprocher développement et exploitation.	Brise les silos, accélère et fiabilise la livraison.
SRE	Une discipline d'ingénierie de la fiabilité (SLO, error budgets).	Rend la fiabilité mesurable, arbitrable, ingéniérable.
Platform Engineering	Une offre : une plateforme interne en self-service.	Industrialise les bonnes pratiques pour toutes les équipes.

Ce cursus les traverse dans l'ordre : il part de l'exploitation (héritière de la culture DevOps), passe par l'observabilité et le SRE (la discipline), et aboutit au management de la plateforme (l'offre). Le manager de plateforme orchestre les trois : il porte la culture, garantit la discipline et délivre la plateforme.

I	Annexe I — questions fréquentes

Les interrogations les plus courantes des directions et des candidats au moment d'engager ce cursus.

Faut-il déjà être un expert Kubernetes pour entrer ?

Une maîtrise opérationnelle de Kubernetes — du niveau CKA — est le socle attendu à l'entrée, puisque le cursus part d'un poste d'exploitation. En revanche, l'observabilité et le SRE s'acquièrent au fil des jalons : il ne faut pas les maîtriser avant de commencer, il faut l'appétence pour les apprendre.

Combien de temps faut-il réellement ?

Une trentaine de mois pour aller de l'exploitation au management de plateforme. Le rythme dépend autant des opportunités d'organisation que du candidat : le cursus trace le chemin et ses preuves, il ne garantit pas le calendrier. Mieux vaut un jalon tenu que deux jalons entamés.

Peut-on sauter le jalon d'observabilité ?

C'est fortement déconseillé. L'observabilité est le préalable du SRE : sans mesure fiable, pas de SLO crédible ni d'error budget arbitrable. Passer directement de l'exploitation au SRE prive l'ingénieur des fondations sur lesquelles repose toute l'ingénierie de la fiabilité.

Et si le candidat ne veut pas devenir manager ?

C'est un choix légitime, et fréquent. S'arrêter au jalon de SRE constitue une carrière complète et recherchée. Le rôle de la direction est alors d'ouvrir une bifurcation technique — vers la sécurité ou la donnée (voir l'annexe D) — plutôt que de forcer un franchissement non désiré, qui se solderait par un échec.

Comment fixer un premier SLO sans se tromper ?

En partant de l'expérience client, pas de l'infrastructure : on choisit un SLI qui reflète ce que vit l'utilisateur (un paiement aboutit-il, et assez vite ?), on fixe un objectif soutenable plutôt qu'ambitieux, puis on l'ajuste avec les données réelles. Un SLO se découvre par itérations ; il ne se décrète pas parfait du premier coup.

Ce cursus convient-il aux petites structures ?

Oui, en adaptant l'échelle. Dans une petite fintech, une même personne peut cumuler l'exploitation, l'observabilité et le SRE avant d'évoluer vers le management. La logique des jalons et des preuves reste la même ; seules la taille des équipes et la séparation des rôles varient.

Ce document constitue l'approfondissement du Cursus 3 · De l'exploitation à la fiabilité, troisième des treize cursus de la collection « Les cursus intra & inter familles » de la Méthode SAKITI.