De l’exploitation IT au SRE : les compétences à construire

La progression en un coup d’œil

Le chemin est à peu près : Exploitation IT → Ingénierie de production → DevOps ou Platform Engineering → Ingénierie de fiabilité (SRE). Chaque étape ajoute une couche : profondeur d’exploitation, puis automatisation, puis livraison et infrastructure as code, puis ingénierie de fiabilité avec des SLO. On ne saute pas d’étapes — on construit sur chacune. Le point de départ est le rôle de Analyste IT operations, et la destination est Ingénieur SRE.

Étape 1 — Construire la profondeur Linux et systèmes

L’exploitation vous donne une connaissance fonctionnelle de Linux ; le SRE exige de la profondeur. Vous devez lire la performance au niveau du noyau, comprendre la mémoire et les E/S, et déboguer un hôte malade sans deviner. C’est la fondation sur laquelle tout le reste repose. Notre guide Compétences Linux essentielles pour l’exploitation IT est écrit pour exactement cette transition. Le premier saut concret est de l’analyste d’exploitation vers Ingénieur de production.

Étape 2 — Apprendre le scripting et l’automatisation

Le SRE est un poste d’ingénierie logicielle, donc vous devez programmer. Choisissez Python ou Go et écrivez de vrais outils d’automatisation — pas des one-liners, mais des outils et des services qui réduisent la charge. Bash est un début ; un langage généraliste est la destination. L’automatisation est ce qui transforme un ingénieur de production en quelqu’un qui supprime le travail répétitif au lieu de le faire. C’est la compétence qui ouvre la porte vers Ingénieur DevOps.

Étape 3 — Ajouter l’observabilité et le cloud

La fiabilité moderne tourne sur Kubernetes, Terraform et l’observabilité. Apprenez à instrumenter les services avec métriques, logs et traces (Prometheus, Grafana, OpenTelemetry), à exploiter des conteneurs et à provisionner l’infrastructure as code. Les catégories d’outils sont décrites dans Outils de supervision pour les carrières NOC et exploitation IT. Une profondeur cloud sur un fournisseur (AWS, Azure ou GCP) est attendue à ce stade. Un rôle d’Ingénieur observabilité s’inscrit naturellement sur cette partie du chemin.

Étape 4 — Apprendre les concepts de fiabilité : SLO, SLI et budgets d’erreur

Le cœur du SRE est de mesurer la fiabilité par la donnée au lieu de promettre zéro interruption. Un SLI est un signal mesuré (taux de succès des requêtes) ; un SLO est l’objectif que vous engagez (99,9 %) ; le budget d’erreur est la marge entre le SLO et la perfection. Quand le budget est consommé, la fiabilité prime sur les fonctionnalités. Ce changement de mentalité — du pompiérisme à la fiabilité ingéniée — est ce qui fait de vous un SRE. Le rôle complet est décrit sur la fiche Ingénieur SRE.

Roadmaps existantes pour chaque saut

Vous n’avez pas besoin d’inventer le chemin — les roadmaps de transition existent déjà dans le dataset. Les roadmaps liées ci-dessous couvrent les sauts réalistes : analyste d’exploitation vers ingénieur de production, ingénieur de production vers DevOps, et les passages finaux vers le SRE. Suivez-les dans l’ordre, sautez ce que vous savez déjà, et ajoutez de la profondeur à chaque étape plutôt que de vous précipiter sur le titre.

Projets pratiques à construire en chemin

Lire sur les SLO et les budgets d’erreur ne suffit pas — il faut construire quelque chose de réel pour intérioriser la mentalité. Ces trois projets correspondent aux trois étapes ci-dessus et donnent des preuves concrètes des compétences, pas seulement des affirmations sur un CV.

• Automatiser une tâche opérationnelle récurrente : choisir quelque chose que vous faites chaque semaine (redémarrer un service, vérifier un batch, nettoyer des logs) et écrire un script Python qui le fait sûrement, avec journalisation et gestion d’erreurs. Cela prouve l’étape d’automatisation.
• Instrumenter un petit service avec OpenTelemetry : ajouter métriques et traces, les visualiser dans Grafana ou Jaeger, et répondre à « où passe le temps ? » pour une requête lente. Cela prouve l’étape d’observabilité.
• Définir un SLO pour un service que vous exploitez : choisir un SLI vu par l’utilisateur (taux de succès des requêtes ou latence), fixer un SLO (ex. 99,9 %), calculer le budget d’erreur mensuel et le présenter à un product owner. Cela prouve la mentalité d’ingénierie de fiabilité.

Pièges fréquents sur ce chemin

• Se précipiter sur le titre SRE sans construire d’abord la profondeur en programmation. Le titre suit la compétence, pas l’inverse.
• Collectionner les outils au lieu de la profondeur. Connaître cinq outils de supervision superficiellement est plus faible qu’en maîtriser un de bout en bout.
• Sauter la fondation d’exploitation. Les SRE qui n’ont jamais vécu un vrai incident d’astreinte peinent à concevoir la fiabilité pour ceux qui la vivront.