Questions d'entretien responsable cloud & DevOps, plateforme et incidents

Le responsable cloud & DevOps choisit la plateforme sur laquelle tournent les applications, dirige l'équipe qui l'exploite et répond du budget qu'elle consomme. Les bons candidats racontent des arbitrages précis, comme un engagement de dépense, une organisation d'astreinte ou un plan de sortie de fournisseur.

Recevoir la fiche complète

Mis à jour le Par l'équipe Delectus5 min de lecture

La fiche Responsable cloud & DevOps : technologies, chaîne du poste, une question et la grille d'évaluation

Les offres parlent de responsable cloud et DevOps, de head of platform, de responsable DevOps infra, de manager SRE ou de responsable du centre d'excellence cloud. Les missions se recoupent. Il encadre une équipe plateforme, souvent avec des prestataires, fixe les standards de CI/CD et d'infrastructure as code, tient le budget cloud et répond de la disponibilité de la production. Les questions d'entretien d'un responsable cloud DevOps partent du périmètre réel : nombre de personnes, part de prestataires, clouds utilisés, astreinte.

Les candidats arrivent par deux chemins. Les uns sont d'anciens ingénieurs DevOps ou SRE devenus managers, solides techniquement mais peu exposés aux budgets et aux contrats. Les autres viennent du pilotage d'infrastructure : ils ont géré des fournisseurs et des budgets, avec moins de pratique de Kubernetes ou de la CI/CD. Les candidats solides citent des chiffres qu'ils ont suivis eux-mêmes, comme la facture mensuelle, la fréquence de déploiement, les incidents majeurs de l'année ou la taille de l'équipe.

Le poste reste technique. Un responsable qui ne sait pas lire un post-mortem ou discuter une montée de version Kubernetes ne pourra pas contrôler les choix de son équipe. Le PDF répartit 30 questions sur six axes et ajoute un cas de 20 minutes sur une plateforme qui a grandi sans règles.

Les sujets dont répond un responsable cloud & DevOps

Stratégie cloud et fournisseurs

Choix du ou des clouds, part de services managés, place d'un cloud qualifié SecNumCloud, réversibilité. Le Data Act européen encadre depuis septembre 2025 le changement de fournisseur cloud. Le candidat doit savoir défendre ces choix devant la direction avec leurs coûts.

Landing zone et gouvernance des comptes

La structure des comptes, abonnements ou projets, les règles imposées à toute l'organisation et la création automatisée des environnements. C'est la base de la sécurité et de l'allocation des coûts. Un responsable qui l'a construite ou reprise sait expliquer ses règles et ses exceptions.

Plateforme interne et libre-service

Clusters Kubernetes, modèles d'infrastructure, portail développeur comme Backstage, chemins standard pour déployer. L'équipe plateforme la gère comme un produit pour les développeurs. Un bon candidat parle d'adoption et de délai, pas seulement d'outils.

CI/CD et infrastructure as code

GitLab CI, GitHub Actions ou Azure DevOps, Terraform ou OpenTofu, GitOps avec Argo CD ou Flux. Le responsable fixe les standards et les règles de sécurité de la chaîne, sans écrire lui-même tous les pipelines.

FinOps

Allocation des coûts, budgets, engagements, coût unitaire. Le cadre de la FinOps Foundation découpe la démarche en trois phases : informer, optimiser, opérer. Le responsable doit avoir déjà construit un budget cloud et expliqué un dépassement.

SLO, astreinte et post-mortems

Objectifs de niveau de service et budgets d'erreur, organisation de l'astreinte, gestion des incidents majeurs et post-mortems sans recherche de coupable. C'est sur ce sujet que l'expérience réelle se voit le plus vite.

Indicateurs DORA

Cinq indicateurs de livraison logicielle, du délai de mise en production au taux de reprise des déploiements. Ils servent à suivre une tendance par service. Un candidat qui veut les transformer en objectifs individuels n'a pas compris leur usage.

Sécurité des accès et de la chaîne

Identités fédérées, droits limités dans le temps, comptes d'urgence, fédération d'identité pour la CI/CD, gestion des vulnérabilités des images. Le responsable en répond devant le RSSI.

Contrats et prestataires

Engagements de dépense avec les fournisseurs cloud, licences d'outillage, contrats d'infogérance et d'ESN. Le poste demande de lire un contrat, de préparer un renouvellement et de garder la maîtrise technique quand une partie de l'équipe est externe.

Le responsable cloud & DevOps rend compte en général au DSI, au CTO ou au head of engineering, et encadre de quelques personnes à plusieurs équipes. Les offres demandent souvent de cinq à dix ans d'expérience en DevOps ou en infrastructure, dont plusieurs en management, et mentionnent la gestion de prestataires. Le titre ne dit pas tout : selon le poste, il pilote surtout le budget et les fournisseurs, ou reste proche de la technique et intervient lui-même sur la plateforme. Cette part mérite d'être précisée dans l'offre et dans les questions, car un excellent gestionnaire d'infrastructure peut manquer de pratique de Kubernetes, et l'inverse est aussi fréquent.

Ce qu'un responsable cloud & DevOps doit avoir déjà piloté

  • Stratégie cloud et réversibilité
  • Organisation des équipes plateforme et SRE
  • Pilotage FinOps et budget cloud
  • Fiabilité, SLO et gestion de crise
  • Sécurité et gouvernance des accès
  • Fournisseurs, contrats et reporting

Cinq questions de direction de plateforme, réponses attendues incluses

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.

  1. Question 1 · senior

    Vous prenez le poste et personne ne sait dire quelle équipe consomme quoi sur une facture cloud de plusieurs centaines de milliers d'euros par an. Par quoi commencez-vous ?

    Une bonne réponsePar l'allocation des coûts. Il impose des étiquettes obligatoires (application, équipe, environnement) contrôlées par des policies, s'appuie sur une structure de comptes ou d'abonnements par équipe et par environnement, et envoie l'export détaillé de facturation vers un outil de suivi, au format FOCUS si possible. Les coûts partagés sont répartis par une clé connue de tous. Viennent ensuite un rapport mensuel par équipe, puis des budgets et des alertes. Les économies rapides (hors production éteinte la nuit, ressources orphelines, redimensionnement, engagements) arrivent une fois la consommation visible.

    Signal d'alerteCommencer par négocier une remise avec le fournisseur ou couper des ressources au hasard. Un tableur trimestriel rempli à la main.

  2. Question 2 · senior

    Huit ingénieurs DevOps sont répartis dans les équipes produit, chacun avec ses outils. Comment construisez-vous une équipe plateforme sans casser ce qui marche ?

    Une bonne réponseIl commence par l'inventaire des pratiques et repère ce qui est commun à toutes les équipes : CI/CD, clusters, observabilité, gestion des secrets. L'équipe plateforme traite ce socle comme un produit, avec les développeurs comme utilisateurs : chemins standard documentés et plus simples à suivre que les solutions maison, migration progressive, relais conservés dans les équipes. Il mesure l'adoption et la satisfaction, et fixe clairement qui est d'astreinte sur quoi.

    Signal d'alerteImposer un outil unique par décision le premier mois. Ou créer une équipe qui traite des tickets et devient le goulot de toutes les livraisons.

  3. Question 3 · senior

    La plateforme Kubernetes de production est tombée pendant quatre heures et plusieurs applications ont été coupées. Comment gérez-vous la crise, puis la semaine qui suit ?

    Une bonne réponsePendant l'incident : un responsable de l'incident désigné (pas forcément lui), un canal unique, des rôles séparés pour la technique et la communication, un point régulier à la direction et aux équipes touchées avec l'heure du point suivant, et la priorité au rétablissement, par exemple par un retour arrière, avant la recherche de cause. Ensuite : un post-mortem sans recherche de coupable dans les jours qui suivent, une chronologie, les causes contributives, des actions avec un responsable et une date, puis leur suivi jusqu'à clôture. Il revoit aussi les alertes qui auraient dû prévenir plus tôt.

    Signal d'alerteSe mettre lui-même à déboguer pendant que personne ne communique. Chercher un coupable, ou écrire un post-mortem dont les actions ne sont jamais suivies.

  4. Question 4 · senior

    La direction demande un plan multicloud pour ne plus dépendre d'un seul fournisseur. Comment instruisez-vous la demande ?

    Une bonne réponseIl fait préciser le risque visé : panne d'un fournisseur, hausse de prix, exigence de souveraineté, fin de contrat. Il chiffre le multicloud actif (deux jeux de compétences, outillage commun, services managés abandonnés, trafic entre clouds) et le compare à des réponses moins chères : plan de réversibilité documenté et testé, infrastructure en code et conteneurs pour la portabilité, sauvegardes hors du fournisseur principal, clauses contractuelles, second cloud réservé à certains usages. Il connaît le Data Act, qui encadre le changement de fournisseur. Il présente des options chiffrées et laisse la direction trancher.

    Signal d'alerteAccepter et déployer chaque application sur deux clouds. Ou refuser sans analyse parce que « c'est trop compliqué ».

  5. Question 5 · confirmé

    Un audit révèle des comptes administrateurs partagés et des accès console sans MFA sur la production. Quel plan lancez-vous ?

    Une bonne réponseTout de suite : MFA obligatoire, suppression des comptes partagés, rotation des secrets exposés. Ensuite : identités fédérées par l'annuaire de l'entreprise, droits d'administration attribués à la demande et limités dans le temps, comptes d'urgence protégés et surveillés, journalisation centralisée des actions, revue périodique des droits. Des policies au niveau de l'organisation empêchent le retour en arrière. Il suit l'avancement avec des indicateurs et rend compte au RSSI.

    Signal d'alerte« On traitera ça après le projet en cours. » Ou un rappel des bonnes pratiques envoyé par e-mail sans contrôle technique.

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

Responsable cloud & DevOps : les questions fréquentes

Quelle différence entre un responsable cloud & DevOps et un head of engineering ?

Le head of engineering dirige les équipes de développement et répond de la livraison du produit. Le responsable cloud & DevOps tient la plateforme sur laquelle ces équipes déploient : socle cloud, CI/CD, clusters, observabilité, astreinte et budget d'infrastructure. Dans une petite structure, une même personne peut couvrir les deux. Dans une organisation plus grande, le responsable cloud & DevOps rend souvent compte au head of engineering ou au CTO.

Un responsable cloud & DevOps doit-il encore être technique ?

Oui, même s'il ne code plus au quotidien. Il valide des choix d'architecture, lit des post-mortems, arbitre entre un service managé et une solution auto-hébergée, et doit repérer un plan de montée de version irréaliste. Sans cette base, il dépend entièrement de son équipe ou de ses prestataires pour juger les risques. Le candidat doit pouvoir expliquer en détail un incident récent ou une décision technique qu'il a prise.

Comment se vérifie l'expérience d'un candidat sur le budget cloud ?

Il cite l'ordre de grandeur de la facture qu'il suivait, la façon dont les coûts étaient répartis entre équipes et le dernier dépassement qu'il a dû expliquer. Il décrit aussi un engagement signé avec un fournisseur et ce qui comptait dans cet engagement. Un candidat qui a réellement tenu un budget cite des mécanismes précis, comme les étiquettes obligatoires, les budgets avec alertes ou le coût unitaire.

Faut-il un test technique pour un responsable cloud & DevOps ?

Un exercice technique classique a peu d'intérêt à ce niveau. Une mise en situation est plus parlante : le candidat reçoit la description d'une plateforme avec ses coûts, ses incidents et son organisation, puis propose un diagnostic et un plan pour les trois premiers mois. La revue d'un vrai post-mortem anonymisé complète l'exercice. On voit à la fois la profondeur technique et la capacité à prioriser.

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.

Les fiches voisines

Toutes les fiches →

Voyez Delectus sur vos propres offres.

Commencez gratuitement. Passez à l'échelle quand vous êtes prêt.

Demander une démo

Votre ATS, connecté à Delectus

  • Workable
  • Teamtailor
  • iCIMS
  • Lever
  • SmartRecruiters
  • Jobvite
  • Greenhouse
  • Pinpoint