Ingénieur·e DevOps / SRE
Questions fréquentes sur le recrutement pour un poste de Ingénieur·e DevOps, et les erreurs qui le font le plus souvent échouer.
Erreurs de recrutement courantes pour ce poste
Le marché DevOps / SRE en France est tendu et les confusions de poste sont coûteuses. Ces erreurs sont récurrentes en PME et bien plus chères à corriger après embauche qu'à éviter au cadrage.
Confondre DevOps, SRE, et Sysadmin au moment du brief
Les trois rôles se touchent mais ne couvrent pas le même besoin. Le·la DevOps construit la plateforme d'ingénierie : IaC, CI / CD, observabilité, golden paths pour les dev. Le·la SRE possède la fiabilité opérationnelle : SLO, error budgets, posture incident, capacity planning. Le·la Sysadmin classique gère l'infrastructure existante sans posture produit (peu de IaC, peu de SLO, déploiements manuels). En PME de moins de 30 ingénieur·e·s, un·e seul·e profil porte souvent les trois casquettes ; au-delà, les rôles se spécialisent. Cherchez un·e SRE pour un·e profil qui doit principalement améliorer la fiabilité et vous obtiendrez un·e ingénieur·e frustré·e par les tâches plateforme, et inversement. Cadrez explicitement la répartition de temps attendue (60 % plateforme / 30 % fiabilité / 10 % support, par exemple) dans l'annonce.
Sous-estimer le poids de l'astreinte et la rareté du vivier
Le vivier DevOps / SRE en France est plus petit que celui du back-end (estimé entre 8 000 et 15 000 profils selon les définitions, contre 80 000 plus pour les back-end). Combiné à l'astreinte quasi systématique du rôle, cela rend les profils expérimentés très sollicités et exigeants sur les conditions. Une PME qui propose une rotation d'astreinte mal cadrée (fréquence trop élevée, alertes bruyantes, absence de runbooks, pas de compensation) ne recrutera pas les meilleur·e·s profils ou les perdra à 12 mois. Avant de publier l'annonce, auditez honnêtement votre dispositif d'astreinte et soyez prêt·e à le présenter en entretien : rythme, compensation (financière ou en récupération), état réel des runbooks, qualité du monitoring.
Évaluer sur la liste d'outils plutôt que sur la profondeur d'ownership
Un·e candidat·e qui liste 15 technologies sur son CV (Kubernetes, Terraform, Ansible, Pulumi, ArgoCD, Flux, Prometheus, Grafana, Datadog, Sentry, Jenkins, GitHub Actions, GitLab CI, Helm, Kustomize) sans pouvoir parler en profondeur d'au moins 3 d'entre elles est moins solide qu'un·e candidat·e qui maîtrise 5 outils en autonomie pendant 2 ans. Évaluez la profondeur d'ownership : « Sur cette plateforme Kubernetes, vous gériez quoi exactement ? Combien de clusters, combien de noeuds, combien d'équipes consommatrices, quels SLO ? ». Les listes d'outils sont des badges de surface ; l'ownership est le vrai signal.
Sauter le system design en pensant gagner du temps
Pour un poste DevOps / SRE mid-level, le system design plus la simulation d'astreinte est le stade le plus prédictif de la performance future. Une PME qui saute ce stade pour gagner une semaine sur le délai de recrutement embauche typiquement quelqu'un qui maîtrise les outils mais qui ne sait pas anticiper les modes de défaillance distribués (cohérence, blast radius, dégradation gracieuse, observabilité par défaut). Le coût d'un mauvais recrutement DevOps / SRE est particulièrement élevé : 18 mois de dette opérationnelle accumulée plus l'épuisement de l'équipe sur les astreintes mal gérées valent largement les 90 minutes d'un entretien de system design.