Entretien comportemental : pourquoi les bons devs se plantent

Tu as grindé LeetCode trois semaines. Le system design, tu gères. Et là on te sort : « Parle-moi d’un conflit avec un collègue. »

Blanc total.

J’y suis passé. Plusieurs fois. Et j’ai vu des collègues largement meilleurs que moi sur le technique se faire recaler sur exactement ce type de question. Le truc c’est que personne ne t’apprend à répondre à ça — on suppose que si tu sais coder, tu sais aussi raconter ta vie professionnelle de manière convaincante. Spoiler : c’est faux.

Ce que les recruteurs cherchent vraiment

Franchement, oublie l’idée que le behavioral c’est pour vérifier que t’es « sympa ». C’est une grille structurée. Ils évaluent des trucs précis : comment tu gères un désaccord, ton impact mesurable sur un projet, ta capacité à prendre des initiatives sans qu’on te le demande, ta réaction quand tout part en vrille.

Chaque question cible une dimension. Et chaque erreur entretien comportemental, c’est un signal négatif que tu envoies sans t’en rendre compte.

Le pire ? Tu sors de là en te disant que c’était pas mal. Deux jours après : refus. Sans savoir pourquoi.

Le vague, c’est l’ennemi

« En général, quand il y a un conflit, j’essaie de comprendre les deux côtés. »

Ça sonne raisonnable. Ça ne vaut absolument rien.

Les recruteurs sont formés — littéralement formés — à repérer les réponses hypothétiques. Dès que tu dis « en général » ou « d’habitude », c’est grillé. Ce qu’ils veulent c’est une situation réelle avec des détails. « Lors de la migration Kubernetes chez [boîte], un désaccord a éclaté entre l’infra et le produit sur la stratégie de rollout… » Là tu existes. Là c’est tangible.

Et puis il y a le piège du « nous ». En tant que dev, on bosse en équipe. Dire « on a fait ci, on a décidé ça », c’est naturel. Sauf qu’en entretien, l’évaluateur cherche ton impact à toi. Dire « je » c’est pas de l’arrogance — c’est de la précision. Tu peux reconnaître le collectif et quand même zoomer sur ta contribution : « L’équipe bossait sur la refonte du paiement. Moi j’ai conçu la couche d’abstraction pour migrer sans interruption de service. » Net. Honnête. Évaluable.

La méthode STAR — utile mais surcotée

Bon, tout le monde te dit d’utiliser STAR. Situation, Tâche, Action, Résultat. Je vais pas te mentir : ça aide. Mais c’est pas la formule magique que certains prétendent.

Le vrai secret c’est la répartition du temps. Passe 15 % sur le contexte — bref, factuel, on s’en fout des détails. 10 % sur ta responsabilité spécifique. Et puis 60 % sur ce que tu as concrètement fait. Le reste, c’est le résultat avec des chiffres.

Compare ces deux réponses :

« On avait un souci de perf sur l’API, j’ai regardé, on a corrigé, ça allait mieux. »

Versus : « Notre API servait 2M requêtes/jour, les temps de réponse avaient doublé en deux semaines. J’ai instrumenté avec du tracing distribué, identifié des requêtes N+1 responsables de 80 % de la latence, mis en place du batching et du caching. Le p99 est passé de 1200 ms à 180 ms. »

La première version c’est du bruit. La deuxième c’est une preuve. Mais attention — réciter une structure parfaite comme un robot, ça se voit aussi. L’idée c’est d’avoir le squelette STAR en tête, pas de le dérouler mécaniquement.

L’erreur que personne ne veut admettre : esquiver les échecs

« Je n’ai jamais vraiment eu de conflit. » « Je ne me souviens pas d’un échec significatif. »

Signal d’alarme immédiat. Pour le recruteur, ça veut dire manque d’expérience, manque de lucidité, ou peur d’être vulnérable. Aucune de ces options n’est bonne.

Le truc que j’ai mis du temps à comprendre : les questions sur les échecs ne sont pas des pièges. Elles évaluent ta maturité. Un dev qui raconte un vrai plantage, qui explique ce qu’il aurait fait différemment, et qui montre ce qu’il a changé depuis — ça inspire confiance. Bien plus que le candidat zéro-défaut.

Choisis un échec réel. Pas un faux défaut déguisé en qualité (le classique « je suis trop perfectionniste »… pitié). Décris ce qui s’est passé. Ce que tu aurais fait autrement. Ce que tu as changé concrètement dans ta pratique.

C’est cette trajectoire qui intéresse les gens en face.

S’entraîner pour de vrai

La théorie ça va cinq minutes. Ce qui change la donne c’est la simulation.

Prépare 6 à 8 histoires distinctes avant l’entretien. Un conflit technique résolu, un échec avec les leçons tirées, un projet sous pression, une initiative que personne ne t’avait demandée, un moment où tu as influencé une décision… Pour chaque histoire, rédige une fiche de 5 à 10 lignes avec les points clés. Pas un script — juste les grandes lignes.

Après, demande à un collègue de te poser des questions comportementales. Les classiques style Amazon Leadership Principles ou Google behavioral. Enregistre-toi. Réécoute-toi. C’est pénible, je sais. Mais c’est comme ça que tu repères tes tics : le « nous » systématique, les réponses vagues, les résultats sans chiffres.

Un truc qu’on oublie souvent : dans la plupart des grandes boîtes, un « no hire » sur le comportemental c’est un veto. Tu peux avoir cartonné sur le technique. Si le behavioral est mauvais, c’est fini. Les compétences techniques se développent. Les comportements problématiques… beaucoup moins.

FAQ

Est-ce que la méthode STAR est vraiment obligatoire ? Non, pas obligatoire au sens strict. Mais si tu n’as aucune structure dans tes réponses, le recruteur va décrocher au bout de trente secondes. STAR c’est un guide, pas un carcan. Garde le squelette, adapte la forme.

Combien de temps je dois passer à préparer le comportemental ? Minimum 3 à 4 heures, étalées sur plusieurs jours. Rédige tes fiches, entraîne-toi à voix haute, fais au moins une simulation complète avec quelqu’un. La plupart des devs passent 20 heures sur le technique et zéro sur le behavioral. C’est un déséquilibre absurde vu le poids de cette partie.

Et si je n’ai pas beaucoup d’expérience professionnelle ? Puise dans tes projets perso, tes contributions open source, tes projets d’école. Ce qui compte c’est la qualité du récit et ta capacité à montrer de la réflexion, pas le prestige de l’entreprise.

Les questions sont-elles les mêmes partout ? Les thèmes reviennent : conflit, échec, leadership, pression. Mais chaque boîte a ses obsessions. Amazon pousse fort sur les Leadership Principles, Google insiste sur la collaboration cross-team. Renseigne-toi avant.

Tu veux aller plus loin ? Rejoins la communauté