Les offres françaises parlent de coach DevOps, de coach technique DevOps ou de coach DevSecOps, souvent pour une mission longue dans une grande DSI. Elles mêlent l'outillage (GitLab CI, Jenkins, Argo CD, Sonar, tests automatisés, TDD et BDD) et la culture, souvent résumée par le modèle CALMS. Les questions d'entretien pour un coach DevOps dépendent de la part technique du poste. Un coach qui ne sait pas relire un pipeline perd vite la confiance des développeurs.
Les candidats arrivent par deux chemins. Les anciens ingénieurs DevOps et tech leads connaissent la chaîne de livraison, mais ont rarement mené un changement sur plusieurs équipes. Les coachs agiles savent accompagner une équipe et connaissent moins les pipelines et les tests. Le candidat décrit un accompagnement précis : combien d'équipes, quelles mesures au départ, ce qui avait changé six mois plus tard, ce qui a échoué.
Une réponse qui ne parle que d'outils, ou que de culture, doit alerter. Les bons profils partent d'une mesure, comme le délai de livraison, le taux d'échec des changements ou le temps d'attente entre deux étapes, et rattachent chaque action à cette mesure. Le PDF propose l'entretien complet en 30 questions sur six axes, avec un cas de 20 minutes.
Les pratiques et repères qu'un coach DevOps utilise
Métriques DORA
Les indicateurs de livraison publiés par le programme DORA de Google Cloud : délai entre le commit et la production, fréquence de déploiement, temps de rétablissement après un déploiement raté, taux d'échec des changements, et, depuis le rapport 2024, taux de déploiements de reprise. Ils se mesurent par application, pas par personne. Un coach qui en fait des objectifs individuels ou un classement entre équipes les a mal compris.
Cartographie de la chaîne de valeur
Le value stream mapping suit une demande de l'idée à la production, étape par étape, avec le temps de travail réel et le temps d'attente. Il montre où le temps se perd : validation manuelle, environnement de recette partagé, comité de changement hebdomadaire. C'est souvent le premier atelier d'un coach qui arrive dans une DSI.
Team Topologies
Le modèle de Matthew Skelton et Manuel Pais décrit quatre types d'équipes (alignée sur un flux, plateforme, facilitatrice, sous-système complexe) et trois modes d'interaction. Il sert à discuter de la charge cognitive des équipes et de la place d'une équipe plateforme. Le coach DevOps occupe en général la position d'équipe facilitatrice, qui se retire une fois la pratique acquise.
CI/CD et trunk-based development
Le coach doit savoir lire un pipeline GitLab CI, Jenkins ou GitHub Actions et repérer ce qui le ralentit. Le trunk-based development, avec des branches courtes et des feature flags, conditionne une livraison fréquente. Les offres citent aussi Argo CD pour le déploiement GitOps et des outils de release comme Digital.ai Release, l'ancien XL Release.
Tests automatisés, TDD et BDD
La pyramide de tests, le TDD et le BDD reviennent dans presque toutes les offres de coach technique. Sans tests fiables, déployer plus souvent fait monter les incidents. Le coach doit pouvoir mener une séance de TDD sur le code d'une équipe, pas seulement en présenter le principe.
Post-mortems sans recherche de coupable
Après un incident, l'équipe reconstitue la chronologie, cherche les causes dans le système et le processus, puis suit des actions datées. Le livre SRE de Google l'a popularisée et la fait remonter à la santé et à l'aviation ; DORA la recommande avec le modèle de culture de Ron Westrum. Le coach installe ce rituel et vérifie que les actions sont faites.
CALMS et DevSecOps
CALMS (culture, automatisation, lean, mesure, partage) sert de grille de diagnostic dans beaucoup d'offres françaises. Le volet DevSecOps ajoute l'analyse du code et des dépendances dans le pipeline, avec Sonar, Fortify ou Nexus IQ. Le coach règle ces contrôles avec l'équipe sécurité pour qu'ils ne bloquent pas chaque livraison.
SAFe et agilité à l'échelle
Dans les grandes DSI, le coach DevOps travaille souvent à côté d'un dispositif SAFe, avec ses trains, ses PI planning et son pipeline de livraison continue. Il doit y placer les pratiques DevOps sans ajouter de couche de processus. Le DevOps Health Radar de SAFe sert d'auto-évaluation, à croiser avec des mesures réelles.
Le coach DevOps intervient le plus souvent en mission, rattaché à la DSI, à un centre d'excellence DevOps ou à la direction d'un programme agile. Il n'a pas d'autorité hiérarchique sur les équipes qu'il accompagne. Selon l'offre, le poste penche vers le coaching technique, avec pipelines, tests et programmation en binôme avec les développeurs, ou vers la transformation, avec l'organisation des équipes, les indicateurs et la formation des managers. La certification DASA DevOps Coach existe, comme les certifications SAFe, mais aucune ne prouve la pratique. Le candidat décrit un accompagnement terminé, avec ses mesures avant et après.
Les savoir-faire attendus d'un coach DevOps
- Diagnostic de maturité et métriques DORA
- Cartographie de la chaîne de valeur
- Pipelines CI/CD, tests et trunk-based
- Organisation des équipes et plateforme
- Conduite du changement sur plusieurs équipes
- Post-mortems et culture de l'incident
Diagnostic, mesure et adoption : cinq questions d'entretien de coach DevOps
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
La direction veut suivre les métriques DORA de toutes les équipes dans un tableau de bord. Comment les mettez-vous en place, et que refusez-vous ?
Une bonne réponseIl définit chaque mesure avant de choisir l'outil : délai entre le commit et la mise en production, fréquence de déploiement, taux d'échec des changements, temps de rétablissement, éventuellement taux de déploiements de reprise. Il les calcule par application à partir du pipeline, du gestionnaire de tickets et des incidents. Il refuse les objectifs chiffrés imposés, les classements entre équipes et l'usage en évaluation individuelle, qui poussent à arranger les chiffres.
Signal d'alerteUn objectif du type « dix déploiements par jour pour tous d'ici la fin de l'année », ou la fréquence de déploiement présentée seule comme le niveau DevOps d'une équipe.
Question 2 · confirmé
Le pipeline d'une équipe dure 45 minutes et échoue une fois sur cinq sans raison claire. Comment l'aidez-vous ?
Une bonne réponseIl lit le pipeline avec l'équipe et mesure chaque étape. Pistes : cache des dépendances, tests parallélisés, étapes lancées inutilement sur chaque branche, images de build trop lourdes. Pour les échecs aléatoires, il isole les tests instables, les met en quarantaine avec un ticket et corrige leur cause (ordre d'exécution, horloge, données partagées, service externe). Il fixe avec l'équipe une durée cible pour le retour sur une merge request.
Signal d'alerteRelancer le job jusqu'à ce qu'il passe, ou désactiver les tests en échec sans suivi.
Question 3 · confirmé
Une évolution simple met six semaines à arriver en production. Comment trouvez-vous où passe le temps ?
Une bonne réponseUne cartographie de la chaîne de valeur faite avec les personnes de chaque étape : demande, ticket, développement, revue, tests, recette, demande de changement, mise en production. Pour chaque étape, le temps de travail effectif, le temps d'attente et la part de travail renvoyé à l'étape précédente. L'attente domine presque toujours (file de recette, comité de changement, environnement indisponible). Il s'attaque d'abord à la plus longue.
Signal d'alerteAccélérer le build qui dure dix minutes sur six semaines, ou cartographier le processus décrit dans la documentation sans suivre une vraie demande.
Question 4 · confirmé
Une équipe expérimentée refuse les déploiements automatisés parce que la dernière tentative a cassé la production. Comment avancez-vous ?
Une bonne réponseIl prend l'objection au sérieux et demande ce qui a cassé. Il propose un premier pas réversible et mesuré : automatisation sur la recette, puis en production avec un retour arrière testé et une personne de l'équipe aux commandes. Il compare avec l'équipe les incidents et le temps passé avant et après. L'équipe décide de la suite sur ses propres chiffres.
Signal d'alertePasser par le manager pour imposer l'outil, ou laisser l'équipe de côté et avancer avec les autres.
Question 5 · senior
Chaque équipe produit a son propre ingénieur DevOps et ses propres outils. La DSI envisage une équipe plateforme. Comment l'aidez-vous à décider ?
Une bonne réponseIl part du travail réel : ce que chaque équipe refait seule (pipelines, clusters, observabilité), ce qui diverge et ce que cela coûte. Une équipe plateforme se justifie quand plusieurs équipes ont les mêmes besoins. Elle gère son offre comme un produit, avec des utilisateurs, une documentation et du libre-service, et ne devient pas un guichet de tickets. Il propose une montée progressive, en commençant par un chemin de déploiement standard.
Signal d'alerteRenommer l'ancienne équipe d'exploitation en équipe plateforme sans changer sa façon de travailler, ou regrouper d'un coup tous les ingénieurs DevOps.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Coach DevOps, les questions qui reviennent
Quelle différence entre un coach DevOps et un coach agile ?
Le coach agile travaille surtout sur l'organisation du travail : rôles, rituels, priorisation, lien avec le métier. Le coach DevOps travaille sur la chaîne qui va du code à la production, avec les pipelines, les tests automatisés, le déploiement, l'infrastructure as code et la gestion des incidents, et sur l'organisation des équipes autour de cette chaîne. Les deux rôles se croisent dans les programmes SAFe. Un coach agile sans pratique des pipelines aura du mal à convaincre des développeurs sur un sujet technique.
Un coach DevOps doit-il savoir coder ?
Pour un poste de coach technique, oui. Il fait du TDD avec les équipes, relit des pipelines et des fichiers Terraform, et doit comprendre pourquoi un test échoue au hasard. Pour un poste centré sur la transformation, une lecture solide du code et des outils peut suffire, à condition de rester crédible face aux développeurs. Dans les deux cas, le candidat commente un vrai fichier de pipeline pendant l'entretien.
Comment se vérifient les résultats d'un coach DevOps sur ses missions passées ?
Comptent les mesures au départ et à la fin : délai de livraison, fréquence de déploiement, taux d'échec, durée des pipelines. Un coach qui a suivi les effets de son travail les cite, avec leurs limites. Il raconte aussi un accompagnement qui n'a pas marché et ce qu'il a changé ensuite. Pour les références, un manager d'équipe accompagnée en dit plus que le seul sponsor de la mission.
Quel test technique pour un coach DevOps ?
Un exercice en deux temps fonctionne bien. D'abord un pipeline réel anonymisé, lent et instable, à analyser à voix haute : ce que la personne changerait et dans quel ordre. Ensuite une mise en situation de diagnostic à partir de la description d'une équipe, avec ses chiffres et ses irritants. Le premier exercice montre la profondeur sur l'outillage, le second la méthode d'accompagnement.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
