Feuille de route des compétences DevOps engineer pour 2026

Le DevOps en 2026, c'est du platform engineering plus du SRE plus une réputation résiduelle de « personne du CI/CD » que certaines entreprises entretiennent encore. Cette feuille de route couvre la stack moderne — Kubernetes, Terraform, observabilité, SLO, secrets — et un plan sur 12 mois pour devenir un DevOps/platform engineer recrutable.

Beaucoup d'entreprises ont cessé d'appeler le rôle « DevOps » et l'appellent désormais « platform engineer », « SRE » ou « infrastructure engineer ». Le travail se recoupe largement. Si vous savez faire tourner un cluster Kubernetes, écrire du Terraform qui ne fait pas fuiter d'identifiants, livrer un CI/CD que les développeurs apprécient réellement et répondre à une astreinte de 3 h du matin sans aggraver les choses, vous trouverez un poste sous l'un au moins de ces intitulés.

Qu'est-ce qu'un DevOps engineer en 2026

Un DevOps/platform engineer est responsable du chemin du code à la production. Concrètement :

• Conçoit et maintient des pipelines CI/CD que les développeurs peuvent utiliser sans ouvrir de tickets.
• Est responsable de l'infrastructure cloud as code — Terraform/Pulumi, avec des PR relisibles et un état stocké qui ne perd pas de données.
• Exploite le cluster Kubernetes de production (ou l'équivalent serverless) et en assure l'astreinte.
• Est responsable de l'observabilité : métriques, logs, traces, alertes, runbooks, budgets d'erreur.
• Gère les secrets, l'IAM, les politiques réseau et les parties ennuyeuses de la sécurité que personne d'autre ne se porte volontaire pour faire.

DevOps junior : écrit une GitHub Action, débogue un pipeline. Mid : est responsable de l'infra d'un service de bout en bout, tableaux de bord inclus. Senior : conçoit la plateforme sur laquelle plusieurs équipes construisent, fixe les SLO, pilote le processus de revue d'incident.

Stack de base — ce qu'il faut réellement apprendre

Compétences transverses et pensée systémique

• Empathie développeur. La plateforme que vous construisez est destinée à d'autres ingénieurs. S'ils ouvrent des tickets pour l'utiliser, vous avez construit la mauvaise plateforme.
• Discipline du post-mortem sans blâme. Les pannes sont systémiques. Montrez l'exemple : assumez votre part de l'échec, concentrez-vous sur les correctifs systémiques.
• Conscience des coûts. Les factures cloud dérapent vite. Un DevOps engineer senior réduit la facture de 20 à 30 % dans les mois qui suivent son arrivée dans la plupart des entreprises.
• L'ennuyeux, c'est bien. Une infrastructure ennuyeuse est une infrastructure fiable. Résistez à l'envie d'utiliser le tout dernier outil.
• La documentation comme habitude. Runbooks, schémas d'architecture, registres de décisions. L'ingénieur qui documente est responsable de la couche.

Plan suggéré sur 3 / 6 / 12 mois

Mois 1–3 : Linux + Docker + bases du cloud

• Soyez à l'aise en ligne de commande. Montez un homelab ou un compte cloud au palier gratuit.
• Apprenez Docker correctement : builds multi-stage, réseaux, volumes, Compose.
• Choisissez un cloud. Déployez un petit service manuellement. Apprenez l'IAM, le VPC et les bases du réseau.

Mois 4–6 : Kubernetes + IaC

• Faites tourner un cluster Kubernetes (k3s, kind ou managé). Déployez une vraie application avec ingress, secrets et volumes persistants.
• Apprenez Terraform. Gérez votre cluster, votre DNS, votre store de secrets par le code.
• Mettez en place un pipeline CI/CD (GitHub Actions ou GitLab CI) qui build, teste et déploie sur votre cluster.
• Lisez « The Phoenix Project » et le « Google SRE Book » (gratuit en ligne).

Mois 7–12 : observabilité, SRE, entretiens

• Branchez Prometheus + Grafana + Loki + Alertmanager sur votre cluster. Construisez un vrai tableau de bord.
• Définissez un SLO pour votre application et un budget d'erreur. Lancez une expérience de chaos qui l'épuise.
• Entraînez-vous au system design DevOps : concevez une plateforme CI/CD, un pipeline de logging, un déploiement multi-régions.
• Postulez avec un portfolio qui inclut un dépôt GitHub avec IaC complète, CI/CD et captures d'écran de tableau de bord.

Projets personnels à construire

• Une plateforme GitOps complète dans un seul dépôt. Terraform pour le cluster, ArgoCD pour les applications, la stack Prometheus pour l'observabilité. Démontre tout réuni.
• Une organisation IaC multi-environnements. Dev/staging/prod avec séparation par workspace ou répertoire, détection de dérive, plan-on-PR. Montre une structure du monde réel.
• Un opérateur Kubernetes (petit). Écrivez un contrôleur pour une ressource personnalisée. Démontre une profondeur au-delà du kubectl de surface.
• Un compte-rendu d'optimisation de coûts. Prenez une facture réelle ou simulée et montrez les étapes pour la réduire de 30 %. Le FinOps fait de plus en plus partie du rôle.

SLO, budgets d'erreur et santé de l'astreinte

Les pratiques SRE qui distinguent les DevOps engineers seniors des ingénieurs « qui construisent des pipelines » viennent d'un seul changement de mentalité : on ne peut pas maximiser simultanément la fiabilité et la vélocité des fonctionnalités, il faut donc rendre le compromis explicite.

• Choisissez un SLI par service. Disponibilité pour une API. Latence de bout en bout pour un parcours utilisateur critique. Taux de succès des jobs pour un worker. Choisissez-en un qui correspond à l'expérience utilisateur, pas à des métriques internes.
• Fixez le SLO au bon niveau. 99,9 % paraît raisonnable jusqu'à ce que vous réalisiez que c'est 43 minutes de budget d'indisponibilité par mois. 99,99 %, c'est 4 minutes par mois, et vous ne pouvez pas déployer chaque semaine à ce niveau.
• Utilisez le budget d'erreur. Si vous avez 30 minutes de budget d'indisponibilité ce trimestre, dépensez-en 20 sur des déploiements risqués. Si vous épuisez le budget, gelez les déploiements de fonctionnalités jusqu'à la fenêtre suivante.
• Les runbooks battent les héros. Chaque alerte renvoie à un runbook avec les trois premières commandes de diagnostic. L'ingénieur d'astreinte qui n'a jamais touché ce service ne devrait pas avoir à appeler l'expert à 3 h du matin.
• Alertez sur l'actionnable, pas sur l'informatif. Une alerte qui ne nécessite pas d'action humaine ne devrait pas déclencher d'astreinte. Déplacez-la vers un tableau de bord, un rapport hebdomadaire, ou supprimez-la. La fatigue d'astreinte est le tueur silencieux de la qualité d'astreinte.
• Post-mortems sans blâme. Les actions correctives se concentrent sur le système, pas sur la personne. « L'ingénieur X a déployé sans staging » n'est pas une cause racine ; « le pipeline a autorisé un déploiement en prod sans staging au vert » en est une.
• Game days. Planifiez-en un par trimestre, cassez quelque chose volontairement en staging, déroulez l'incident. La compétence du commandement d'incident se dégrade vite sans pratique.

Dans les entretiens senior, la question est rarement « connaissez-vous K8s ». C'est « racontez-moi le dernier incident de production que vous avez géré ». Ayez la chronologie, les étapes de diagnostic, le correctif immédiat et le changement systémique prêts.

Comment décrocher le poste de DevOps

• Mots-clés du CV. Kubernetes, Terraform, AWS ou GCP, outil CI/CD, Prometheus, Grafana, OpenTelemetry, Helm, GitHub Actions, ArgoCD le cas échéant.
• Un dépôt avec tout branché. L'artefact au plus fort signal — une plateforme déployable et documentée.
• Manches d'entretien : dépannage Linux/réseau, system design (construire un pipeline CI/CD ou d'observabilité), comportemental avec des histoires d'astreinte, parfois un exercice à la maison (écrire un module Terraform).
• La manche de dépannage. Souvent en direct : « voici un deployment Kubernetes cassé, réparez-le ». Entraînez-vous sur des clusters cassés exprès.
• L'histoire d'astreinte. Ayez 4 à 5 histoires d'incident prêtes. Ce qui a cassé, comment vous l'avez trouvé, ce que vous avez changé, quel correctif systémique a suivi.

FAQ