Ingénieur·e DevOps / SRE

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.