Comment répondre à 'Parlez-moi d'un projet difficile'
Intention de recherche : Candidats qui choisissent le mauvais projet (trop petit, trop ancien) ou qui passent toute leur réponse sur le contexte et oublient la partie « ce que j'ai fait. »
Deux erreurs qui font couler cette réponse
La question sur le projet difficile paraît simple — mais la plupart des candidats y répondent d'une de ces deux façons incorrectes :
Ils choisissent un projet qui n'était pas vraiment difficile. Une livraison classique avec un délai serré n'est pas un défi — c'est une semaine normale. Les recruteurs voient tout de suite quand le « défi » est gonflé.
Ils passent toute la réponse à expliquer le contexte. Trois minutes pour décrire le projet, l'entreprise, les parties prenantes, le système legacy — puis 15 secondes sur ce qu'ils ont réellement fait, suivi de « et ça a marché. » Le recruteur n'a rien appris sur le candidat.
La solution aux deux erreurs est la même : choisissez une histoire où l'obstacle était réel et où vos décisions spécifiques ont fait la différence.
Ce qui rend un projet « difficile » en termes d'entretien
Un projet vaut la peine d'être évoqué s'il comportait au moins l'un de ces éléments :
- Ambiguïté technique — pas de solution claire, vous avez dû la trouver
- Contraintes de ressources — périmètre trop grand, équipe trop petite, délai trop serré, et vous avez quand même livré
- Conflits de parties prenantes — des priorités concurrentes que vous avez dû naviguer et aligner
- Enjeux élevés — des conséquences significatives en cas d'échec (impact client, chiffre d'affaires, fiabilité système)
- Votre responsabilité sur quelque chose qui a cassé — vous avez piloté ou construit quelque chose qui a échoué en cours de route et vous avez dû vous en remettre
Les projets classiques avec une semaine difficile ne sont pas éligibles. Un projet où vous avez touché le fond, pris des décisions dans l'incertitude et abouti à un résultat concret — celui-là l'est.
La structure : Problème → Vos décisions → Résultat
L'approche STAR standard fonctionne ici, mais l'accent doit être mis sur la section Action — spécifiquement les décisions que vous avez prises dans les moments les plus difficiles.
Situation (15 %) : Une ou deux phrases. Quel était le projet et pourquoi était-il à enjeux élevés ?
Tâche (10 %) : De quoi étiez-vous responsable ?
Action (55 %) : Détaillez le vrai défi et votre réponse. Pas celle de votre équipe — la vôtre. Qu'avez-vous analysé, décidé, construit ou changé ? Si vous avez rencontré plusieurs obstacles, choisissez le plus significatif et allez en profondeur.
Résultat (20 %) : Qu'a livré le projet ? Soyez précis — chiffres, délais, impact en aval.
Mauvaise réponse
« On avait un gros projet de refonte d'infrastructure l'an dernier. C'était vraiment complexe avec beaucoup de pièces mobiles entre différents systèmes. L'équipe a vraiment travaillé dur et on a réussi à le terminer, même si ça a pris plus longtemps que prévu. Le nouveau système est bien plus stable. »
« Pièces mobiles » et « vraiment complexe » sont des remplisseurs — ils signalent que le candidat ne peut pas décrire la complexité réelle. « A pris plus longtemps que prévu » sans explication du pourquoi ou de comment c'a été géré est un signal d'alerte. « Bien plus stable » n'est pas mesurable.
Bonne réponse
« J'ai piloté la migration d'un moteur de pricing en temps réel d'une installation on-premise mono-tenant vers un service cloud multi-tenant. Le défi était qu'on ne pouvait pas le mettre hors ligne — il traitait des transactions en direct pendant les heures de marché. Toute indisponibilité représentait une perte de revenus directe.
À mi-parcours, on a découvert que les exigences de latence étaient plus strictes que la spécification initiale : le nouvel environnement avait 40 ms d'overhead réseau supplémentaire par rapport à notre baseline on-premise. On avait environ deux semaines avant notre date de mise en production externe.
J'ai mené un spike — trois jours de profiling et de tests — pour isoler si l'overhead venait du réseau, de la sérialisation ou du calcul. C'était la sérialisation. On a switché de JSON à un protocole binaire, ce qui a récupéré 35 ms. Pas parfait, mais dans le seuil acceptable. J'ai décidé de livrer avec ce correctif plutôt que de retarder, j'ai documenté le risque résiduel et obtenu le feu vert des responsables produit et trading.
On a tenu la date de mise en production. La latence était 18 ms au-dessus de la baseline — bien dans les tolérances. Zéro interruption de transaction dans les 30 premiers jours. »
Cette réponse nomme un obstacle technique spécifique et réel (régression de latence), décrit le processus de diagnostic du candidat, montre une décision concrète sous pression (livrer avec risque résiduel connu) et se conclut sur un résultat vérifiable.
Comment choisir le bon projet
Posez-vous ces questions :
- Suis-je le personnage principal ? Si votre histoire porte surtout sur ce que votre équipe a fait, trouvez une autre histoire.
- L'obstacle était-il réel ? Quelqu'un aurait-il raisonnablement pu échouer ici, ou c'était juste du travail intense avec un résultat certain ?
- Ai-je un résultat spécifique ? Si vous ne pouvez pas dire ce qui a changé grâce à ce projet, l'histoire n'est pas prête.
- Est-ce récent ? Sauf si vous êtes en début de carrière, utilisez quelque chose des quatre dernières années.
- Est-ce pertinent ? Le défi doit correspondre à quelque chose que le nouveau poste rencontrera.
Entraînez-vous maintenant
La partie la plus difficile de cette réponse n'est pas l'histoire — c'est de savoir quand arrêter de donner du contexte et commencer à parler de ce que vous avez fait.