En France, l'intitulé recouvre plusieurs réalités. Le head of engineering s'appelle aussi directeur des développements, responsable R&D logiciel ou directeur technique. Il encadre des engineering managers et des tech leads, découpe les équipes, fixe les règles de livraison et d'astreinte, et construit le budget avec la direction financière. Là où un CTO existe, celui-ci garde la stratégie technologique et la relation externe, et le head of engineering tient l'exécution.
Les candidats arrivent souvent avec un discours rodé sur la culture d'équipe et l'agilité. Demandez des chiffres et des décisions : combien de personnes encadrées et combien de managers, quel rythme de déploiement avant et après leur arrivée, quelle facture cloud, quelle réorganisation menée et ce qu'elle a coûté. Quelqu'un qui a tenu le poste cite aussi ses erreurs et ce qu'il a changé ensuite.
La culture technique compte encore. Le head of engineering ne code plus, mais il doit pouvoir discuter une migration d'architecture, lire un post-mortem et repérer un plan de montée de version irréaliste. Le PDF couvre six axes en 30 questions, avec un cas de 20 minutes et une grille de 1 à 4.
Le périmètre d'un head of engineering, sujet par sujet
Organisation des équipes
Le découpage en équipes produit, souvent par domaine, avec une équipe plateforme quand l'outillage commun devient lourd. Le head of engineering décide qui possède quel service et combien de personnes chaque manager encadre. Un mauvais découpage se paie en dépendances et en réunions.
Échelle de carrière
Les niveaux d'ingénieur, de junior à staff ou principal, et la double voie entre expertise et management. Sans grille écrite, les promotions et les augmentations se négocient au cas par cas et les meilleurs profils techniques partent ou deviennent managers à contrecœur.
Delivery et indicateurs DORA
Le rythme de livraison de plusieurs équipes et les dépendances entre elles. Les indicateurs DORA servent de repère : fréquence de déploiement, délai de mise en production, taux d'échec des changements, temps de rétablissement après un déploiement raté, et depuis peu la part de déploiements non planifiés.
Architecture cible et dette technique
Le head of engineering ne dessine pas chaque service, mais il fixe comment les décisions d'architecture se prennent et se tracent, souvent par des ADR. Il arbitre la place des chantiers de fond (monolithe à découper, framework en fin de support) face aux fonctionnalités.
Fiabilité et astreinte
SLO, alertes, astreinte et post-mortems. Le sujet touche autant les personnes que la technique : une astreinte mal organisée use toujours les mêmes ingénieurs. En France, elle donne droit à une contrepartie financière ou en repos.
Sécurité applicative
Gestion des dépendances et des vulnérabilités, accès à la production, secrets. Pour un logiciel mis sur le marché européen, le Cyber Resilience Act impose depuis septembre 2026 de signaler les vulnérabilités activement exploitées, avant des obligations complètes en décembre 2027.
Budget, cloud et prestataires
Masse salariale, facture cloud, licences et prestataires externes. Le head of engineering suit le coût d'infrastructure rapporté à une unité métier, arbitre entre construire et acheter, et garde la maîtrise du code produit par des prestataires.
Recrutement à grande échelle
Processus d'entretien, grilles par niveau, formation des ingénieurs qui mènent les entretiens, intégration des arrivants. Quand l'équipe double en un an, la qualité du processus décide du niveau de l'équipe deux ans plus tard.
Le poste apparaît en général quand l'équipe technique compte plusieurs équipes et que le CTO ne peut plus suivre à la fois la stratégie, les recrutements et la livraison. Le head of engineering rend compte au CTO ou directement au CEO. Son périmètre couvre le plus souvent l'organisation des équipes, les échelles de carrière, la roadmap technique, la fiabilité, la sécurité applicative et une part du budget (masse salariale, prestataires, cloud). Les offres publiées en France mélangent les intitulés head of engineering, VP engineering, directeur des développements et responsable développement logiciel, et certaines regroupent produit et ingénierie sous un head of product and engineering.
Six compétences à établir avant de faire une offre
- Organisation des équipes et des rôles
- Pilotage du delivery multi-équipes
- Architecture cible et dette technique
- Fiabilité, sécurité et astreinte
- Budget, build or buy et prestataires
- Recrutement et carrières en ingénierie
Des décisions de head of engineering à faire raconter
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 · direction
L'équipe doit passer de 25 à 60 développeurs en dix-huit mois. Comment découpez-vous les équipes, et qui encadre qui ?
Une bonne réponseUn découpage par domaine produit, avec des équipes stables de cinq à huit personnes qui possèdent leurs services de bout en bout, propriétaire écrit à l'appui. Une équipe plateforme apparaît quand plusieurs équipes refont la même chose (CI, observabilité, environnements). Les engineering managers encadrent six à huit personnes, chaque équipe a un tech lead, et quelques staff engineers portent les sujets transverses. Le candidat recrute d'abord les managers et les seniors, puis remplit les équipes, et cite la loi de Conway : l'architecture finit par ressembler à l'organisation.
Signal d'alerteDes équipes par couche technique (front, back, recette) qui dépendent toutes les unes des autres. Un manager pour quinze personnes, ou une réorganisation à chaque trimestre.
Question 2 · senior
Trois équipes dépendent les unes des autres et la release trimestrielle glisse à chaque fois. Que changez-vous ?
Une bonne réponseIl cartographie les dépendances puis réduit le couplage : contrats d'API versionnés, feature flags, déploiement indépendant de chaque équipe. La planification trimestrielle se fait en commun, dépendances écrites et datées. Le but est de remplacer la grosse release par des livraisons fréquentes et petites. Il mesure le délai de mise en production et le taux d'échec des changements, avant et après.
Signal d'alerteUn chef de projet de coordination et des réunions en plus, de la pression sur les dates, ou des renforts ajoutés à la dernière minute.
Question 3 · senior
Le monolithe ralentit toutes les équipes et deux tech leads veulent passer aux microservices. Comment décidez-vous ?
Une bonne réponseIl part du problème mesuré : temps de build, conflits de merge, déploiements bloqués par une autre équipe, zones qui changent le plus. Il compare deux voies, un monolithe modulaire avec des frontières de modules vérifiées par l'outillage, ou l'extraction progressive des domaines les plus actifs (strangler fig). Il chiffre le coût des microservices : observabilité, données réparties, astreinte, compétences. La décision est écrite dans un ADR avec ses critères de réussite.
Signal d'alerteTout réécrire avec un gel des fonctionnalités pendant un an, ou décider parce que « tout le monde fait des microservices ».
Question 4 · senior
Un incident a coupé le paiement pendant deux heures un samedi. Lundi matin, que mettez-vous en place ?
Une bonne réponseUn post-mortem sans recherche de coupable dans la semaine : chronologie, cause, délai de détection, actions avec responsable et date. Il revoit l'astreinte (rotation, escalade, compensation), les alertes, qui doivent porter sur ce que voit l'utilisateur, et les procédures de reprise. Les actions sont suivies jusqu'à leur clôture, et la direction reçoit un compte rendu factuel.
Signal d'alerteChercher qui a fait l'erreur, ou ajouter une validation manuelle sur chaque mise en production.
Question 5 · direction
La facture cloud a doublé en un an alors que le trafic a augmenté de 20 %. Que faites-vous ?
Une bonne réponseIl répartit la facture par service et par équipe grâce aux étiquettes, puis cherche les causes habituelles : environnements hors production allumés en permanence, machines surdimensionnées, logs et stockage jamais purgés, transferts réseau. Chaque équipe voit sa part (showback). Les engagements de capacité viennent une fois la charge stabilisée. Il suit un coût par unité métier, par commande ou par client actif, et arbitre ce chantier face aux fonctionnalités.
Signal d'alerteCouper au hasard, lancer une migration de cloud dans l'urgence, ou classer le sujet comme « le prix de la croissance ».
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
Recrutement d'un head of engineering : les points qui reviennent
Head of engineering, VP engineering ou CTO : qui porte quoi ?
Head of engineering et VP engineering désignent en général le même poste : organisation des équipes, livraison, recrutement, fiabilité et budget de l'ingénierie. Le CTO porte la stratégie technologique, les choix structurants et la relation avec les investisseurs ou les grands clients. Dans une petite structure, une seule personne cumule les deux sous le titre de CTO ou de directeur technique. Lisez la fiche de poste avant l'entretien pour savoir lequel des deux profils vous recherchez.
Quel niveau technique attendre d'un head of engineering ?
Il ne code plus au quotidien, mais il doit comprendre ce que ses équipes construisent. Il discute une architecture avec un staff engineer, lit un post-mortem, juge si un plan de migration tient la route et repère une estimation fantaisiste. Demandez-lui une décision technique qu'il a prise ou bloquée, avec ses raisons. Un candidat qui reste dans le vocabulaire du management pendant toute la réponse n'a probablement pas suivi la technique de près.
Quelle mise en situation proposer à un head of engineering ?
Un test technique de code n'a pas de sens à ce niveau. Une étude de cas de vingt à trente minutes fonctionne mieux : une organisation qui ralentit, des incidents, une facture cloud en hausse et des recrutements à faire. Demandez au candidat ses 90 premiers jours, les données qu'il réclame et les décisions qu'il prend. Notez chaque axe sur la même grille pour comparer les candidats finalistes.
Quels chiffres demander sur son poste précédent ?
La taille de l'équipe et le nombre de managers encadrés, l'évolution de la fréquence de déploiement et du nombre d'incidents pendant son passage, le budget géré et la part du cloud, le nombre de recrutements et de départs. Un candidat solide connaît ces ordres de grandeur sans les arrondir à son avantage et sait expliquer ce qui les a fait bouger. Des réponses vagues sur tous ces points doivent vous alerter.
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.
