Se connecter S'inscrire Tableau de bord

Toutes les fiches de poste

France Informatique & systèmes d'information Confirmé·e

Ingénieur·e DevOps / SRE

Fiche de poste, salaire, sourcing, 15 questions d'entretien et plan 30/60/90 pour recruter un·e Ingénieur·e DevOps / SRE en PME française.

Compilé par l'équipe Join à partir de données publiques et de notre expérience de recrutement.

Mis à jour

En un coup d'œil

  • Salaire médian 62 000 € 52 000 € – 80 000 €
  • Délai de recrutement 50–75 jours
  • Expérience 3–7 ans

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), passez au modèle d’annonce ci-dessous.

Modèle de fiche de poste

Télécharger .docx

Ingénieur·e DevOps / SRE (H / F) PME française

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é].

Fourchette salariale

Salaire fixe annuel brut

25e centile
52 000 €
Médiane
62 000 €
75e centile
80 000 €

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

Où sourcer ce profil

  1. 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.

  2. Welcome to the Jungle

    Dès 990 € HT / offre

    Forte 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.

  3. Stack Overflow Jobs et communautés DevOps de niche

    Variable ; budget temps d'un·e ingénieur·e plus que budget cash

    Stack 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).

  4. 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.

Comparer tous les sites de ce marché →

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

Questions d'entretien structurées

  1. Comportementale Posture incident

    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 ?

    Ce 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.

  2. Comportementale Conduite du changement

    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 ?

    Ce 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.

  3. Comportementale Posture incident

    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 ?

    Ce 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.

Comment reconnaître un·e excellent·e Sales Manager

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.

Plan 30/60/90 jours

À J+30

  • Setup complet de l'accès à toutes les plateformes (cloud, observabilité, CI / CD, secrets) et premier déploiement (PR triviale) validé en production
  • Cartographie de l'existant : inventaire des services, environnements, pipelines, alertes, runbooks, dette opérationnelle identifiée
  • Première rotation d'astreinte en duo (shadow) avec un·e ingénieur·e expérimenté·e de l'équipe ; gestion d'au moins une alerte réelle
  • Premier 1:1 documenté avec la·le tech lead sur les priorités infra et les conventions de la plateforme

À J+60

  • Livraison en autonomie d'une amélioration plateforme substantive (refactor d'un module Terraform, nouvelle alerte avec runbook, automatisation d'une tâche manuelle récurrente)
  • Première rotation d'astreinte en autonomie avec gestion d'au moins un incident (diagnostic, mitigation, post-mortem partagé)
  • Documentation ou ADR rédigé sur une zone récemment touchée (golden path nouveau ou clarifié)
  • Audit complet des alertes d'astreinte : identification des alertes non actionnables, plan de réduction du bruit validé

À J+90

  • Livraison régulière (1 à 2 PRs infra par semaine) avec qualité validée par l'équipe en review
  • Première décision plateforme en autonomie sur un sujet ambigu (choix d'un nouvel outil, design d'un nouveau module IaC, conception d'une nouvelle alerte)
  • Mentorat informel d'un·e dev sur une tâche d'infra (pair-coding, review pédagogique d'une PR Terraform ou Kubernetes)
  • Bilan formel avec la·le tech lead : ramp validé, plan de progression sur 1-2 axes prioritaires (par exemple FinOps, sécurité plateforme, ou ingénierie de plateforme)

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.

  1. 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.

  2. 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.

  3. É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.

  4. 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.

Questions fréquentes

  • Quel est le salaire d'un·e Ingénieur·e DevOps / SRE en PME française ?

    La fourchette de référence pour un·e Ingénieur·e DevOps / SRE mid-level (3 à 7 ans d'expérience) en PME française est de 52 à 80 k€ bruts annuels (médiane autour de 62 k€). Île-de-France SaaS B2B et fintech tirent vers le haut (75-95 k€), surtout sur les 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. Le salaire est 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 (astreinte). Pas de variable structurel en PME ; BSPCE éventuels en scale-up.

  • Quelle différence entre un·e DevOps, un·e SRE, et un·e Sysadmin ?

    Le·la DevOps construit la plateforme d'ingénierie interne : IaC (Terraform, Pulumi), pipelines CI / CD, observabilité, golden paths pour les dev. Le·la SRE (Site Reliability Engineer) possède la fiabilité opérationnelle : SLO, error budgets, capacity planning, posture incident structurée. Le·la Sysadmin classique gère l'infrastructure existante sans posture produit (peu d'IaC, déploiements manuels, monitoring rudimentaire). En PME de moins de 30 ingénieur·e·s, un·e même profil porte souvent les trois casquettes (60 % plateforme / 30 % fiabilité / 10 % support typique) ; au-delà de 30, les rôles se spécialisent. Le titre « DevOps / SRE » utilisé dans cette fiche couvre l'archétype mixte le plus fréquent en PME française.

  • Combien de temps faut-il pour recruter un·e Ingénieur·e DevOps / SRE en France ?

    Comptez 50 à 75 jours entre la publication de l'annonce et la signature pour un·e profil mid-level. Le marché DevOps / SRE est plus tendu que le back-end en 2025-2026 du fait de la rareté du vivier (estimé entre 8 000 et 15 000 profils en France selon les définitions). Les délais s'allongent en septembre et janvier. Réduire le délai en dessous de 50 jours impose en général de sacrifier le system design ou les références, ce qui dégrade fortement la qualité du recrutement pour ce poste où le coût d'un mauvais recrutement est particulièrement élevé.

  • Quelle stack technique demander pour un poste DevOps / SRE en 2026 ?

    Cela dépend de votre stack existante ; n'imposez pas une stack que vous n'utilisez pas. Pour une PME française qui démarre, les choix les plus sûrs sont : un cloud managé (AWS, GCP, ou OVHcloud / Scaleway pour les contraintes souveraineté), Kubernetes managé (EKS, GKE) si la complexité produit le justifie sinon ECS / Cloud Run, Terraform comme IaC par défaut, Prometheus plus Grafana ou Datadog pour l'observabilité, GitHub Actions ou GitLab CI pour le CI / CD. Demandez surtout des fondamentaux solides (networking, IAM, observabilité, SLO, posture incident) plus que la mode du moment ; ces fondamentaux portent à travers les changements de stack.

  • Faut-il un diplôme spécifique pour recruter un·e Ingénieur·e DevOps / SRE ?

    Non. Le marché tech français accepte largement les profils autodidactes ou venus du sysadmin classique avec une montée en compétences sur les pratiques DevOps modernes (IaC, CI / CD, observabilité). Le diplôme d'école d'ingénieur ou de master informatique est rassurant pour les profils junior mais perd de l'importance après 5 ans d'expérience. Les certifications cloud (AWS Solutions Architect, CKA / CKAD pour Kubernetes) sont un signal complémentaire utile mais ne remplacent pas l'évaluation de l'ownership en production réelle. Évaluez sur la profondeur d'ownership, le system design, et la qualité du diagnostic d'incident, pas sur le pedigree académique.

  • L'astreinte est-elle obligatoire pour un poste DevOps / SRE ?

    En PME française, oui dans la grande majorité des cas. Un·e DevOps / SRE participe quasi systématiquement à l'astreinte ou à l'on-call, soit en rotation dédiée soit en rotation partagée avec les back-end seniors. Le cadre légal impose un encadrement clair : convention d'entreprise ou collective applicable, compensation financière ou en récupération, respect du droit à la déconnexion entre les rotations. Annoncez explicitement le dispositif dans l'annonce (rythme, compensation, état réel des runbooks et de l'observabilité). Les candidat·e·s expérimenté·e·s sondent ce sujet en entretien ; une PME avec astreinte mal cadrée perdra les meilleur·e·s profils. Si vous ne pouvez pas proposer d'astreinte structurée pour des raisons de taille (équipe d'une seule personne), assumez-le et arbitrez avec la·le candidat·e à quel niveau de service vous vous engagez (par exemple disponibilité best-effort en heures ouvrées seulement).

Recrutez ce poste avec Join Sourcing, présélection et entretiens au même endroit.
Commencer à recruter

Contacter Join