Départ · Dakar
Arrivée
W
MD
I
ÉA
I
TK
C
IA
O
ER
D
R
E
SÀ l’heure
Il transforme « ça marche à peu près » en une disponibilité mesurée, promise et tenue.
L’ingénieur fiabilité, ou SRE (Site Reliability Engineer), applique les méthodes du développement logiciel à l’exploitation : il mesure la disponibilité réelle d’un service, fixe avec le métier le niveau à tenir et automatise tout ce qui permet d’y parvenir.
Sa matière première, c’est la mesure. Des indicateurs de service (SLI) suivis dans Prometheus, un objectif (SLO) négocié avec l’équipe produit, et un budget d’erreur : la marge d’indisponibilité que l’équipe peut consommer avant de geler les mises en production pour renforcer la stabilité.
Quand un service tombe, il mène l’incident, puis rédige un post-mortem sans blâme : ce qui s’est passé, minute par minute, et ce qui empêchera que cela se reproduise. Pour une plateforme de paiement en Afrique de l’Ouest comme pour une boutique en ligne en Europe, c’est lui qui sait dire si la promesse de disponibilité faite au client est tenue, chiffres à l’appui.
Définir les indicateurs et les objectifs de niveau de service avec le métier : par exemple, un objectif de 99,9 % de disponibilité sur trente jours pour une API de paiement, soit un budget d’erreur d’environ quarante-trois minutes d’indisponibilité par mois.
Instrumenter les services et construire les tableaux de bord : par exemple, une alerte Alertmanager qui ne réveille la personne d’astreinte que si le budget d’erreur s’épuise trop vite, et non à la première erreur isolée.
Organiser l’astreinte et mener les incidents : par exemple, un planning de rotation dans PagerDuty, une procédure par type de panne et un canal unique où l’on tient le journal de l’incident en temps réel.
Analyser chaque incident sans chercher de coupable : par exemple, après une panne de base de données un soir de paie, une chronologie précise, les causes profondes et trois actions correctives datées, suivies jusqu’à leur clôture.
Automatiser les gestes répétitifs d’exploitation : par exemple, remplacer le redémarrage manuel d’un service par une sonde de santé Kubernetes qui le relance seule, puis corriger le code pour supprimer la cause.
Anticiper la charge et tester les pannes : par exemple, un test de charge Grafana k6 sur une plateforme de paiement des frais de scolarité avant la rentrée, et la coupure volontaire d’un nœud en préproduction pour vérifier que la bascule se fait sans perte.
De la base vers le haut : ce qu'il manie chaque jour.
Langages
Supervision
Déploiement
Cloud
Astreinte et incidents
Tests et résilience
À trois heures du matin, il doit diagnostiquer avec méthode sans aggraver la situation.
Un objectif de disponibilité qu’on maquille ne protège personne, et le client finit toujours par mesurer lui-même.
Chaque geste manuel répété est une panne en attente ; il préfère le remplacer par du code.
Un post-mortem qui cherche un coupable fait taire les équipes, et la panne suivante arrive sans prévenir.
0 à 2 ans
Il tient l’astreinte en binôme, ajoute des sondes et des tableaux de bord, traite les alertes courantes et rédige ses premiers post-mortems, relus par un pair.
3 à 5 ans
Il définit les indicateurs et les objectifs d’un service, règle les alertes pour qu’elles restent utiles, mène les incidents jusqu’au rapport et automatise l’exploitation.
6 ans et plus
Il fixe la politique de fiabilité de la plateforme, arbitre entre vitesse de livraison et stabilité grâce aux budgets d’erreur, et forme les équipes à l’astreinte et aux post-mortems.
Formation en informatique ou en systèmes et réseaux, presque toujours après quelques années comme développeur, administrateur système ou ingénieur DevOps. Les certifications Kubernetes (CKA) ou cloud aident ; un historique d’incidents bien documentés convainc davantage.
Des réalisations Wiicode où ce métier est au cœur de la stack.
Ingénieur plateforme, architecte cloud, responsable de l’exploitation, responsable de l’ingénierie de fiabilité.
Vous ne trouvez pas votre métier ?Candidature spontanée
