Ingénieur·e DevOps : questions d'entretien et salaire
En France, un poste de Ingénieur·e DevOps est rémunéré 62 000 € brut par an en médiane ; la moitié des salaires se situe entre 52 000 € et 80 000 €.
En un coup d'œil
- Salaire médian62 000 €
- Délai de recrutement50–75 jours
- Expérience3–7 ans
Salaire Ingénieur·e DevOps en France
Salaire fixe brut annuel
- 25e centile
- 52 000 €
- Médiane
- 62 000 €
- 75e centile
- 80 000 €
| Niveau | 25e centile | Médiane | 75e centile |
|---|---|---|---|
| Junior | 40 000 € | 46 000 € | 54 000 € |
| Confirmé·e | 52 000 € | 62 000 € | 80 000 € |
| Senior | 70 000 € | 85 000 € | 105 000 € |
Pour référence : le SMIC brut s'élève, depuis le 1er juin 2026, à 12,31 € de l'heure, soit 1 867,02 € par mois pour un temps plein (35 h). (service-public.gouv.fr : revalorisation du SMIC au 1er juin 2026)
Fourchette de référence pour un·e Ingénieur·e DevOps / SRE mid-level (3 à 7 ans d'expérience pro) en PME française. Île-de-France SaaS B2B et fintech tirent vers le haut (75-95 k€), surtout sur stacks Kubernetes plus Terraform plus observabilité moderne. Les régions et stacks plus classiques (Ansible, AWS managé sans Kubernetes, VMs) restent dans le cœur de fourchette. Les profils avec expertise plateformes internes (IDP type Backstage), FinOps cloud, ou sécurité plateforme démontrée ajoutent généralement 5 à 12 k€ sur la médiane. Salaire généralement supérieur de 5-10 k€ à un·e Back-end de même séniorité, du fait de la rareté du vivier et du poids opérationnel du rôle.
Sources: APEC, Baromètre 2025 de la rémunération des cadres tech; INSEE, DADS 2024 (PCS 388a, Ingénieurs informatiques); Talent.com, Salaire Ingénieur DevOps France 2025
Comment recruter un·e Ingénieur·e DevOps / SRE pour votre PME
Avant de rédiger l’annonce, posez-vous trois questions de cadrage. Elles déterminent le profil que vous cherchez réellement et évitent les confusions de poste fréquentes en PME tech.
Question 1 : DevOps, SRE, ou Sysadmin ? Les trois rôles se touchent mais ne se substituent pas. Le·la DevOps construit la plateforme d’ingénierie interne : IaC, pipelines CI / CD, observabilité, golden paths pour les dev. Le·la SRE possède la fiabilité opérationnelle : SLO, error budgets, posture incident structurée, capacity planning. Le·la Sysadmin classique gère l’infrastructure sans posture produit. En PME de moins de 30 ingénieur·e·s, un·e seul·e profil porte souvent les trois casquettes avec une répartition typique de 60 % plateforme, 30 % fiabilité, 10 % support. Cadrez explicitement cette répartition dans l’annonce ; un·e candidat·e qui pensait venir faire 80 % de SRE pure partira à 12 mois s’il·elle se retrouve sur 70 % de support.
Question 2 : Quelle est votre stack et quelle maturité plateforme portez-vous ? Un·e DevOps / SRE solide en AWS plus Kubernetes ne devient pas immédiatement productif·ve sur GCP plus Cloud Run ou sur un environnement on-premise sans 4 à 8 semaines de prise en main. La fit stack compte plus que la séniorité absolue pour un·e mid-level. Soyez explicite sur votre stack dans l’annonce (cloud provider, orchestration, IaC, observabilité, CI / CD) et sur le niveau de maturité actuel (greenfield, modernisation en cours, plateforme stabilisée). Vous filtrerez naturellement les profils mal-fittés. Les candidat·e·s expérimenté·e·s sondent ce sujet en entretien ; un·e candidat·e qui découvre une réalité différente après embauche partira dans les 12 mois.
Question 3 : Quelle est la posture astreinte que vous proposez réellement ? C’est le facteur de différenciation numéro un sur ce marché tendu. Un·e DevOps / SRE en PME participe quasi systématiquement à l’astreinte. Avant de publier l’annonce, auditez honnêtement votre dispositif : fréquence des rotations (1 semaine sur 3 est tenable, 1 sur 2 est limite, 1 sur 1 mène au burnout), qualité des runbooks (existent-ils, sont-ils à jour, sont-ils suivis), taux d’alertes actionnables (moins de 30 % d’alertes actionnables signale un dispositif cassé), compensation (financière ou en récupération, conforme à la convention collective applicable). Soyez prêt·e à répondre précisément à ces questions en entretien. Une PME qui présente honnêtement un dispositif imparfait mais en cours d’amélioration attire les bons profils ; une PME qui ment ou élude perd les meilleur·e·s à 12 mois.
Si les trois réponses convergent vers un·e Ingénieur·e DevOps / SRE à temps plein (et non un·e Back-end avec des notions d’infra ou un·e Sysadmin classique), retrouvez le modèle prêt à l’emploi dans la section Fiche de poste ci-dessous.
Modèle de fiche de poste Ingénieur·e DevOps
Mission. Concevoir, construire et maintenir la plateforme d'ingénierie interne (cloud, orchestration, IaC, CI / CD, observabilité) et garantir la fiabilité opérationnelle des services en production, en autonomie sur les sujets familiers et en collaboration sur les décisions structurantes. Vous reportez au·à la [Tech Lead / CTO / Dirigeant·e technique].
Responsabilités.
- Concevoir et faire évoluer l'infrastructure cloud (managed Kubernetes, services managés, networking, IAM) avec un focus sur la simplicité opérationnelle et le coût total.
- Construire et maintenir le code d'infrastructure (Terraform, Pulumi, ou équivalent) modulaire, testé, et lisible par toute l'équipe technique.
- Construire et maintenir les pipelines CI / CD multi-environnements avec rollback rapide et déploiements progressifs (rolling, blue / green, ou canary selon contexte).
- Concevoir et faire évoluer la stack d'observabilité (métriques, logs structurés, traces, alertes) et définir les SLI / SLO en collaboration avec les équipes produit.
- Participer à l'astreinte ou à l'on-call : diagnostic d'incident, mitigation, post-mortem partagé sans blâme, action systémique de prévention.
- Réduire activement le bruit d'astreinte : audit des alertes, écriture de runbooks, automatisation des résolutions répétitives.
- Construire des golden paths pour les équipes produit (templates de service, modules IaC réutilisables, documentation de la plateforme) et accompagner leur adoption par formation et pair-coding.
- Veiller à la sécurité plateforme : gestion des secrets, IAM least-privilege, scan de vulnérabilités automatisé, hardening des images, supply chain awareness.
- Documenter les décisions techniques importantes (ADR) et maintenir la documentation de la plateforme à jour.
Profil recherché.
- Indispensable : 3 à 7 ans d'expérience en DevOps, SRE, ou ingénierie de plateforme ; maîtrise solide d'au moins un cloud public (AWS, GCP, ou Azure) ; maîtrise d'au moins un outil d'IaC (Terraform, Pulumi, CloudFormation) ; expérience d'ownership d'une plateforme en production avec gestion d'incidents documentés ; expérience d'astreinte structurée.
- Apprécié : familiarité avec la stack [cloud provider, orchestration, IaC, observabilité, CI / CD] de notre plateforme ; expérience en PME ou scale-up (autonomie élevée, ownership large) ; expertise sur un sujet précis (FinOps cloud, sécurité plateforme, ingénierie de plateforme avec IDP, observabilité distribuée) ; certifications cloud ou Kubernetes (AWS SA, CKA / CKAD) ; contributions open source ou side-projects publics.
- Disqualifiant : aucune expérience d'ownership en production en autonomie ; refus de participer à l'astreinte ; absence totale de pratique d'IaC ou de monitoring structuré.
Conditions.
- Rémunération brute annuelle : fixe [52-80] k€ selon expérience. Pas de variable structurel ; BSPCE éventuels selon le stade de la société.
- Modalité : temps plein, hybride 2-3 jours / semaine sur site, base à [ville] / remote-friendly.
- Astreinte : [rythme de rotation, compensation financière ou en récupération, état actuel des runbooks et de l'observabilité, taux d'alertes actionnables si vous le mesurez].
- Avantages : [mutuelle, tickets resto, RTT, BSPCE, télétravail policy, budget matériel, budget formation et conférences DevOps / SRE].
- Stack actuelle : [à compléter : cloud provider, orchestration, IaC, file de messages éventuelle, infra réseau, CI / CD, observabilité].
Vous recrutez pour ce poste ? Job Studio transforme ce modèle en offre d’emploi prête à publier, avec une fourchette de salaire suggérée et le formulaire de candidature.
Questions d'entretien pour Ingénieur·e DevOps
15 questions structurées, regroupées par type. Chacune indique la compétence évaluée ; dépliez-la pour voir ce que révèle une bonne réponse.
Comportementale 3
Décrivez l'incident de production le plus sérieux que vous avez piloté en tant que lead ou co-lead. Symptôme, diagnostic, mitigation, post-mortem, action systémique ?
Posture incidentCe qu'une bonne réponse révèle
Méthode structurée et lisible : reproduction ou observation directe, hypothèses ordonnées, validation par les données (logs, métriques, traces), communication régulière à l'équipe pendant l'incident, post-mortem sans blâme, action systémique de prévention concrète (test, alerte, runbook, refactor d'infra). Honnêteté sur la durée totale et les fausses pistes. Les candidat·e·s qui décrivent un incident résolu « instinctivement en 5 minutes » sans diagnostic révèlent soit un cas trivial soit une faiblesse d'analyse. Bonus : la·le candidat·e cite ce qu'il·elle ferait différemment aujourd'hui.
Décrivez une fois où vous avez fait évoluer la plateforme ou un outil interne contre l'avis initial d'une partie de l'équipe ou de la direction. Comment avez-vous convaincu et conduit le changement ?
Conduite du changementCe qu'une bonne réponse révèle
Capacité à porter un changement structurel sans imposer : diagnostic chiffré du problème, proposition de migration progressive plutôt que big bang, formation et accompagnement des équipes consommatrices, mesure d'impact a posteriori. Bonus : la·le candidat·e mentionne une initiative dont il·elle reconnaît avoir mal géré le change management et ce qu'il·elle a appris. Les candidat·e·s qui décrivent un changement « évident » imposé d'autorité sans résistance révèlent soit un environnement très permissif soit une faiblesse de lucidité sur les frictions.
Parlez-moi d'une fois où votre rotation d'astreinte est devenue insoutenable pour vous ou pour votre équipe. Comment avez-vous diagnostiqué et corrigé la cause ?
Posture incidentCe qu'une bonne réponse révèle
Reconnaissance honnête d'une situation de burnout opérationnel passé ou frôlé. Diagnostic structuré : fréquence des alertes (réelles vs fausses), qualité des runbooks, couverture de la rotation, gestion de la nuit et des week-ends, compensation. Action concrète : audit des alertes pour supprimer le bruit, écriture de runbooks pour les alertes restantes, recalibrage de la rotation, négociation avec le management sur la compensation. Bonus : la·le candidat·e cite un indicateur quantitatif (pages par semaine et par personne, ratio nuit / jour, taux de page actionnable). Les candidat·e·s qui n'ont « jamais eu de problème d'astreinte » mentent ou n'ont pas servi en production réelle.
Situationnelle 3
Un·e dev senior demande à pousser une modification d'infra critique en production un vendredi à 17 h, juste avant un week-end de pont. Comment réagissez-vous ?
Pragmatisme et priorisationCe qu'une bonne réponse révèle
Cadrage avant de dire oui ou non : nature exacte du changement, criticité réelle du besoin, blast radius en cas de problème, présence d'un rollback rapide, disponibilité de l'astreinte du week-end. Proposition d'options : push avec rollback testé et présence pendant 2 h, report au lundi matin avec mitigation temporaire, push d'une version réduite. Les candidat·e·s qui acceptent sans cadrage ou qui refusent sans alternative révèlent une faiblesse de jugement opérationnel. Bonus : la·le candidat·e mentionne la convention d'équipe (« on ne déploie pas le vendredi après 16 h sauf hotfix critique avec présence »).
Vous arrivez sur une plateforme avec dette opérationnelle élevée : pas d'IaC, déploiements manuels via SSH, monitoring rudimentaire, alertes qui réveillent tout le monde la nuit pour rien. Quel est votre plan en 30 jours ?
Pragmatisme et priorisationCe qu'une bonne réponse révèle
Diagnostic d'abord, pas de grand soir : priorisation par risque opérationnel. Typiquement : (1) audit complet des alertes (supprimer le bruit, écrire des runbooks pour les vraies), (2) cartographier l'existant avant tout refactor (inventaire, schéma, dépendances), (3) sécuriser les déploiements critiques en premier (rollback rapide, environnement de staging fiable), (4) lancer l'IaC sur un périmètre limité (un seul service ou environnement) pour valider l'approche avant de généraliser. Validation explicite avec l'équipe avant d'engager des migrations risquées. Les candidat·e·s qui proposent de tout réécrire en Terraform en 30 jours révèlent un excès d'enthousiasme dangereux pour ce poste.
Une équipe produit veut son propre cluster Kubernetes pour avoir « plus de contrôle ». Comment cadrez-vous la discussion ?
Posture plateformeCe qu'une bonne réponse révèle
Posture plateforme : compréhension que la demande « cluster dédié » cache souvent un autre besoin (isolation de blast radius, autonomie de déploiement, contraintes réglementaires, performance). Clarification du besoin réel avant de discuter solution. Présentation honnête du coût total d'un cluster supplémentaire (charge opérationnelle, sécurité, observabilité, mise à jour). Proposition d'alternatives : namespaces isolés avec quotas, network policies, ressources dédiées, RBAC fin. Les candidat·e·s qui acceptent immédiatement ou refusent sèchement révèlent une faiblesse de posture plateforme.
Étude de cas 3
Pourquoi DevOps / SRE et pas Back-end ou Sysadmin classique ? Qu'est-ce qui vous tient dans ce métier au quotidien ?
Pensée systémiqueCe qu'une bonne réponse révèle
Articulation claire et personnelle de ce qui distingue le rôle : ingénierie de la fiabilité, plateforme comme produit interne, observabilité, automatisation à grande échelle, collaboration transverse. Pas de discours générique sur « rendre les choses fluides ». Bonus : la·le candidat·e cite un moment précis où il·elle a senti que c'était le bon métier (typiquement la résolution d'un incident complexe, ou la mise en place d'une automatisation qui a libéré du temps à toute une équipe). Les candidat·e·s qui décrivent le rôle comme « la même chose que sysadmin avec de meilleurs outils » manquent la dimension produit / plateforme.
Pourquoi notre PME plutôt qu'un grand groupe ou un pure player infra (Datadog, OVH, Scaleway) ?
Pensée systémiqueCe qu'une bonne réponse révèle
Compréhension lucide des trade-offs : en PME, l'ownership est plus large (de l'IaC à l'astreinte au coaching dev) mais la profondeur d'expertise sur un sujet précis est moindre qu'en pure player. Motivations cohérentes : envie d'impact direct sur le produit et l'équipe, proximité avec le métier, ownership de bout en bout, vitesse de décision. Bonus : la·le candidat·e mentionne ce qu'il·elle accepte de perdre en venant en PME (silos d'expertise pointue, échelle technique extrême, ressources dédiées). Les réponses centrées sur « la flexibilité » ou « moins de réunions » sans articulation positive révèlent un choix par défaut.
Quels sont les axes sur lesquels vous voulez progresser dans les 18 prochains mois ?
Pensée systémiqueCe qu'une bonne réponse révèle
Plan de progression clair, ancré dans des compétences concrètes et non dans des titres : par exemple « monter sur le FinOps cloud », « approfondir la sécurité plateforme et les supply chain attacks », « apprendre Rust pour les tooling internes performants », « passer du IaC déclaratif à du IaC dynamique avec un IDP type Backstage ». Bonus : la·le candidat·e cite comment il·elle compte progresser (lecture, side-projects, contributions open source, conférences). Les candidat·e·s qui répondent « devenir lead » ou « monter en séniorité » sans articulation de compétences révèlent une motivation principalement statutaire.
Technique 3
Différence pratique entre un déploiement rolling, blue / green, et canary ? Quand utiliser l'un plutôt que l'autre ? Quels sont les pièges de chacun ?
Maîtrise de l'infra cloudCe qu'une bonne réponse révèle
Compréhension solide : rolling (remplacement progressif, simple, mais rollback lent et coexistence temporaire de deux versions), blue / green (bascule atomique, rollback rapide, mais coût double en infra et complexité de migration de schéma de DB), canary (exposition progressive à un sous-ensemble de trafic avec mesure, idéal pour validation en production réelle, mais nécessite une infra de routing fine et des métriques fiables). Pièges classiques : compatibilité descendante des migrations de schéma, sessions stateful, caches partagés, routing par utilisateur·rice cohérent. Les candidat·e·s qui ne connaissent que « rolling » par défaut Kubernetes manquent de profondeur sur les stratégies de déploiement.
SLI, SLO, error budget : expliquez ces concepts et comment vous les avez utilisés concrètement sur un service en production.
Maîtrise de l'infra cloudCe qu'une bonne réponse révèle
Compréhension claire : SLI (indicateur mesurable de qualité de service, typiquement latence, disponibilité, qualité), SLO (objectif chiffré sur le SLI, par exemple « 99,9 % des requêtes API en moins de 500 ms sur 30 jours glissants »), error budget (complément de 100 % moins le SLO, dépensable en incidents ou en risques de déploiement). Exemple concret d'usage : définition initiale du SLO avec les équipes produit, mesure du budget consommé, arbitrage entre vélocité de déploiement et fiabilité quand le budget est épuisé. Bonus : la·le candidat·e cite un cas où le SLO a été révisé parce qu'il était trop strict ou trop lâche. Les candidat·e·s qui récitent les définitions sans exemple opérationnel n'ont pas vraiment vécu la mécanique.
Vous devez choisir entre managed Kubernetes (EKS, GKE) et un Kubernetes self-hosted pour une PME de 30 ingénieur·e·s. Comment arbitrez-vous ?
Sens de l'automatisationCe qu'une bonne réponse révèle
Arbitrage explicite par dimensions : coût total (cash plus charge opérationnelle), expertise interne disponible pour gérer un control plane, fréquence de mise à jour, exigences de souveraineté ou de sécurité, criticité du SLO. Conclusion pragmatique : managed presque toujours préférable en PME française (sauf souveraineté stricte ou stack très atypique). Bonus : la·le candidat·e mentionne une option intermédiaire (managed control plane avec node groups personnalisés, ou solutions souveraines type OVHcloud Managed Kubernetes Service pour les contraintes RGPD). Les candidat·e·s qui défendent self-hosted par principe en PME révèlent une faiblesse de jugement coût / valeur.
Valeurs 3
Comment recevez-vous une review critique sur un script Terraform ou une configuration Kubernetes que vous étiez convaincu·e d'avoir bien fait ?
Collaboration dev / opsCe qu'une bonne réponse révèle
Ouverture : capacité à dissocier le code d'infra de l'ego personnel. Bonus : la·le candidat·e cite une fois où il·elle a changé d'avis grâce à une review et explique ce qui l'a fait basculer (souvent un argument de blast radius, de maintenabilité, ou d'UX dev). Les candidat·e·s qui décrivent surtout avoir « expliqué leur logique » au reviewer au lieu de l'écouter révèlent une faiblesse de coachabilité critique pour un poste où la qualité de la plateforme est partagée et où une mauvaise décision d'infra coûte cher à corriger.
Vous êtes en astreinte un samedi à 3 h du matin. Vous êtes réveillé·e par une alerte qui s'avère être un faux positif. Que faites-vous en plus de retourner dormir ?
Posture incidentCe qu'une bonne réponse révèle
Posture systémique : la·le candidat·e ne se contente pas de silencer l'alerte. Action attendue : documenter l'incident le lendemain matin, retirer ou affiner l'alerte si elle est systématiquement fausse, ouvrir un ticket pour ajustement durable, partager avec l'équipe le lundi. Les candidat·e·s qui répondent « je note dans un coin » sans plus de précision révèlent une posture passive face au bruit d'astreinte, qui est le premier facteur de burnout opérationnel en PME. Bonus : la·le candidat·e mentionne un indicateur suivi (taux d'alertes actionnables, mean-time-to-acknowledge).
Quel rôle jouez-vous dans la transmission de la culture plateforme aux dev qui consomment votre infra ? Décrivez une initiative concrète.
Collaboration dev / opsCe qu'une bonne réponse révèle
Posture d'ingénierie de plateforme : la·le DevOps n'est pas un·e gardien·ne, mais un·e facilitateur·rice. Initiative attendue : documentation lisible des golden paths, formations courtes et répétées (lunch and learn, démos), pair-coding sur des tâches d'infra avec les dev, automatisation des tâches répétitives demandées par les équipes produit. En PME où l'équipe DevOps est souvent petite (1-3 personnes), la capacité à faire monter en compétence le reste de l'équipe technique est essentielle pour ne pas devenir le seul point de défaillance. Les candidat·e·s qui répondent « je documente sur le wiki » sans plus de précision révèlent une posture transactionnelle.
Salaire et recrutement par niveau
Le même poste à chaque niveau : la rémunération, l'expérience attendue et la durée habituelle du recrutement.
Ingénieur·e DevOps Junior
- Salaire fixe brut annuel
- 46 000 €40 000 € – 54 000 €
- Expérience
- 0–2 ans
- Délai de recrutement
- 35–55 jours
Ingénieur·e DevOps (Confirmé·e)
- Salaire fixe brut annuel
- 62 000 €52 000 € – 80 000 €
- Expérience
- 3–7 ans
- Délai de recrutement
- 50–75 jours
Ingénieur·e DevOps Senior
- Salaire fixe brut annuel
- 85 000 €70 000 € – 105 000 €
- Expérience
- 7–12 ans
- Délai de recrutement
- 70–100 jours
Salaire Ingénieur·e DevOps par pays
Le même poste, au même niveau, dans chacun des pays que nous couvrons ; les montants proviennent de sources du pays concerné.
| Pays | Bas de fourchette | Valeur centrale | Haut de fourchette |
|---|---|---|---|
| FranceCette pageSalaire fixe brut annuel | 52 000 € | 62 000 € | 80 000 € |
| AllemagneDeutschSalaire fixe brut annuel | 58 000 € | 72 000 € | 92 000 € |
| EspagneEspañolSalaire fixe brut annuel | 38 000 € | 48 000 € | 62 000 € |
| Pays-BasNederlandsSalaire fixe brut mensuel | 3 378 € | 4 935 € | 7 209 € |
| ItalieItalianoSalaire fixe brut annuelMilano · cloud e DevOps · DevOps · 2–5 anni di esperienza | 42 000 € | — | 48 000 € |
Les montants mensuels sont repris tels que la source les publie, sans être annualisés : aux Pays-Bas, une prime de vacances d’au moins 8 % vient en général s’ajouter au montant affiché.
Sources
- Allemagne (consulté en mai 2026) : Destatis Verdiensterhebung (April 2025), Berufsgruppe 43 IKT-Berufe · StepStone Gehaltsreport 2026, DevOps Engineer Deutschland · Glassdoor Gehaltsdaten DevOps Engineer Deutschland 2026 · Honeypot State of Software Engineering Germany 2025
- Espagne (consulté en mai 2026) : INE, Encuesta de Estructura Salarial 2024 (CNO 271, Analistas y diseñadores de software) · InfoJobs, Estado del Mercado Laboral en España 2025 · Glassdoor, salarios DevOps España 2025
- Pays-Bas (consulté en août 2026) : Indeed — salaris DevOps Engineer in Nederland
- Italie (consulté en octobre 2026) : Hays Italia Salary Guide 2026, Technology, Digital & New Media — Cloud & DevOps: DevOps, p. 67 (PDF Hays ospitato da QualEnergia) · Hays Italia Salary Guide 2026 (pagina ufficiale dell’edizione)
Où sourcer ce profil
LinkedIn
800-1 200 € / mois (Recruiter Lite, sourcing actif)Canal le plus profond pour les profils DevOps / SRE en France. Le sourcing actif (Recruiter Lite ou Premium plus InMails ciblés) est encore plus déterminant que pour le back-end : les bon·ne·s DevOps mid-level sont quasi systématiquement en poste, peu actif·ve·s sur les Job Posts, et reçoivent plusieurs sollicitations par mois. Filtrez précisément sur les combinaisons concrètes (« Kubernetes plus Terraform plus AWS », « SRE plus Prometheus plus on-call ») plutôt que sur des intitulés vagues. Personnalisez en citant votre stack réelle et votre posture sur l'astreinte ; les InMails génériques tombent en dessous de 4 % de taux de réponse pour ce profil.
Welcome to the Jungle
Dès 990 € HT / offreForte audience tech scale-up et PME modernes à Paris, Lyon, Bordeaux, Nantes, Toulouse. Les profils DevOps / SRE de WTTJ regardent en premier la stack d'infra (cloud provider, orchestration, IaC, observabilité), la maturité de la plateforme interne, et la posture astreinte (rotation, runbooks, compensation). Bien adapté pour les marques employeur qui assument une plateforme moderne et un récit d'ingénierie crédible. Moins efficace pour environnements on-premise sans cloud, ou pour les stacks legacy sans plan de modernisation lisible.
Stack Overflow Jobs et communautés DevOps de niche
Variable ; budget temps d'un·e ingénieur·e plus que budget cashStack Overflow Jobs reste pertinent pour toucher les profils techniques qui ne sont pas sur LinkedIn par défaut. Surtout efficace combiné avec une vraie présence de votre équipe sur les communautés DevOps de niche : Reddit r/devops, r/kubernetes, r/sre, serveurs Discord CNCF, groupes Slack tech français (Paris DevOps, StaffEng.fr). Un message « cold » d'une recruteuse aura peu de retour ; un message d'un·e ingénieur·e de l'équipe technique aura beaucoup plus. À combiner avec la participation à des meetups parisiens (Paris Container Day, DevOps REX, Devoxx).
Cooptation et réseau personnel de l'équipe technique
Pour un poste DevOps / SRE en PME, la cooptation reste le canal de plus forte conversion. Le vivier est petit (estimé entre 8 000 et 15 000 profils en France selon les définitions), tendu, et les profils circulent par recommandation entre anciens collègues bien plus que via les annonces publiques. Mettez en place une prime de cooptation visible (typiquement 2 000-4 000 € net pour un poste tech) et sollicitez explicitement votre équipe technique en réunion. Bénéfice secondaire : les profils cooptés ont un taux de rétention nettement supérieur à 18 mois.
Playbook d'évaluation
Le rôle d'Ingénieur·e DevOps / SRE se signale à travers quatre stades d'évaluation. Le stade 3 (system design plus simulation d'astreinte) est le plus prédictif pour ce poste : c'est là que se révèle la capacité à raisonner sur la fiabilité opérationnelle, le diagnostic sous pression, et la qualité des runbooks dont une PME a besoin pour éviter le burnout de l'équipe.
Stade 1: Lecture du CV
Cherchez l'ownership infra réel et la cohérence stack. Un·e DevOps qui a passé l'essentiel de son temps à configurer Jenkins sans toucher à la production n'est pas le·la candidat·e visé·e. Indices forts : ownership d'une plateforme en production (Kubernetes, ECS, GKE, ou équivalent), expérience d'astreinte réelle avec gestion d'incidents documentés, maîtrise d'au moins un outil d'IaC (Terraform, Pulumi, CloudFormation), exposition à au moins un stack d'observabilité (Prometheus plus Grafana, Datadog, ou équivalent). Stabilité minimale 18-24 mois par poste. Méfiez-vous des CV listant 15 technologies sans contexte de profondeur ; préférez 5 outils utilisés en autonomie pendant 2 ans.
Stade 2: Phone screen technique (30 min)
Trois questions ciblées : (1) « Décrivez la plateforme la plus complexe que vous avez possédée ; taille, nombre d'environnements, équipes consommatrices, SLO ? », (2) « Décrivez un incident de production majeur que vous avez piloté ; symptôme, diagnostic, mitigation, post-mortem, action systémique ? », (3) « Comment percevez-vous l'astreinte et l'on-call ? Quelle expérience en avez-vous ? ». Sortie : go ou no-go en 5 min. Le critère implicite : la·le candidat·e parle-t-il·elle des humains de l'équipe autant que de la technique ? Un·e DevOps qui ne parle que de tools sans jamais évoquer les dev qui consomment la plateforme est un drapeau orange.
Stade 3: System design plus simulation d'astreinte (90 min)
Stade le plus prédictif. Première moitié (45 min) : conception d'un cas concret proche de votre contexte (mise en place d'une plateforme Kubernetes pour 3-5 équipes produit, refonte d'un pipeline CI / CD multi-environnements, design d'une stack d'observabilité). Évaluez la clarification des contraintes (équipes consommatrices, fréquence de déploiement, SLO, budget, contraintes réglementaires), les arbitrages explicites (managed vs self-hosted, build vs buy, complexité vs simplicité opérationnelle), et la pensée plateforme (UX dev, golden paths, observabilité par défaut). Seconde moitié (45 min) : simulation d'incident. Présentez un scénario réaliste (pic de latence, OOM répétés, certificat expiré, déploiement défaillant) avec quelques métriques et logs. Évaluez la méthode : clarification, hypothèses ordonnées, validation par les données, communication à l'équipe pendant l'incident, action systémique en post-mortem.
Stade 4: Références (vérification structurée)
Appelez deux références : un·e ancien·ne manager ou tech lead direct et un·e ancien·ne dev qui consommait la plateforme construite par la·le candidat·e. Cette seconde référence est essentielle pour un poste DevOps / SRE : elle révèle l'UX dev réelle, qui n'apparaît pas dans les références hiérarchiques. Posez les mêmes 4 questions à chaque référence : « Sur quoi est-il·elle le plus fort·e ? », « Sur quoi recruteriez-vous quelqu'un de complémentaire ? », « Le·la reprendriez-vous demain ? », « Comment se comportait-il·elle pendant et après un incident de production ? ». La 4e question révèle le vrai signal de posture incident.
Comment reconnaître une excellente recrue
| Compétence | Sous la barre | Au niveau | Au-dessus |
|---|---|---|---|
| Maîtrise de l'infra cloud | Connaît un seul cloud de manière superficielle. Choisit par habitude ou par mode plutôt que par adéquation au besoin. Bute sur les concepts fondamentaux (VPC, IAM, networking, stockage objet vs bloc, scaling). | Maîtrise un cloud (AWS, GCP, ou Azure) en autonomie sur les services standards. Sait poser une architecture cloud-native simple et la justifier. Connaît les pièges classiques (coûts cachés, IAM permissif, single-AZ par défaut). | Référent·e cloud sur sa plateforme. Capable d'arbitrer entre managed et self-hosted avec lucidité. Connaît les coûts réels et sait les optimiser sans dégrader. Anticipe les pièges de scaling et de résilience multi-zone. Forme l'équipe. |
| Pensée systémique | Raisonne composant par composant sans vue d'ensemble. Optimise localement au détriment du système. Surconçoit ou sous-conçoit selon l'humeur. Ne sait pas articuler les SLO ou les error budgets. | Clarifie les contraintes (SLO, volumétrie, criticité) avant de concevoir. Arbitre entre simplicité et flexibilité future. Reconnaît ses zones d'incertitude et propose un POC ciblé. Pense observabilité dès le design. | Conçoit des plateformes qui vieillissent bien : abstractions justes, dépendances minimales, frontières claires, observabilité native. Forme l'équipe sur la pensée systèmes et écrit des ADRs lisibles par les nouveaux·elles arrivant·e·s. Anticipe les modes de défaillance et les capacités de récupération. |
| Posture incident | Diagnostique par essai-erreur sans modèle mental. Panique ou se fige sous pression. Ne documente pas les incidents. Cherche un·e coupable plutôt qu'une cause profonde. Subit l'astreinte. | Méthode de debug structurée : reproduction, hypothèses, validation par logs ou métriques. Communique calmement pendant l'incident. Rédige un post-mortem honnête sans blâme. Améliore les alertes au fil des incidents. | Référence de l'équipe en cas de crise. Calme contagieux, communication claire vers les équipes produit et la direction. Post-mortems systémiques avec actions concrètes suivies. Pilote la réduction durable du bruit d'astreinte. Forme l'équipe à la posture incident. |
| Collaboration dev / ops | Posture de gardien·ne : refuse les demandes ou impose des process sans pédagogie. Considère les dev comme des utilisateur·rice·s indisciplinés à éduquer. Communique mal sur les délais et les contraintes. | Posture de partenaire : challenge constructivement les demandes des équipes produit, propose des alternatives, documente les golden paths. Communique les délais et risques de manière transparente. Sait dire non avec une option. | Pont entre les équipes produit et l'infra. Anime des formations, écrit des golden paths que les dev adoptent spontanément, automatise les tâches répétitives des équipes consommatrices. La plateforme est perçue comme un produit interne désiré, pas comme une contrainte. |
| Sens de l'automatisation | Travaille beaucoup à la main, scripte rarement. Préfère le clic console au IaC. N'instrumente pas ses scripts. Considère l'automatisation comme un nice-to-have plutôt qu'un fondamental opérationnel. | Automatise par défaut les tâches répétitives. Maîtrise au moins un outil d'IaC (Terraform, Pulumi, CloudFormation). Met en place CI / CD avec tests et rollback. Documente ses choix d'automatisation. | Construit une plateforme d'ingénierie cohérente : IaC modulaire et testée, pipelines CI / CD réutilisables, ChatOps ou IDP type Backstage, runbooks scriptés. Évalue le ROI de chaque automatisation avant de la construire (pas d'over-engineering). Forme l'équipe sur les conventions. |
| Sécurité plateforme | Pas conscient·e des risques courants (secrets en clair dans Git, IAM trop permissif, dépendances vulnérables, exposition publique par défaut). Considère la sécurité comme « pas son problème ». | Connaît les principaux risques plateforme et les évite par défaut : gestion saine des secrets (vault), IAM least-privilege, scan de vulnérabilités automatisé, network policies, supply chain awareness. Sait pointer une vulnérabilité chez un·e collègue. | Référence sécurité plateforme dans l'équipe : revue régulière des permissions, hardening des images, signature et provenance des artefacts (SLSA, Sigstore), tests de pénétration coordonnés, gestion des incidents de sécurité avec le DPO ou RSSI. Veille active sur les CVE et les menaces du moment. |
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.