Rendre visible ton travail quand t’es développeur·se : la méthode STAR

Ça fait dix ans que j’interviewe des techs, des devs, des informaticiens qui ne connaissent pas la méthode STAR. J’ai vu passer des gens brillants. Mais j’en ai marre de devoir creuser 45 minutes pour que ça se voie.

Et franchement, j’en ai marre que la promotion parte à la mauvaise personne (cf notre article sur l’avenir des devs 😏).

Encore un pompier anonyme qui a sauvé le sprint. On n’a jamais eu de souci pour onboarder les juniors ? C’est parce qu’il y a quelqu’un qui les coache. Et pourtant, ça ne se voit pas. La prod a tenu après une migration mal cadrée ? Tu l’as gérée. Mais encore une fois, personne ne le sait.

Alors forcément, à l’entretien annuel, tu ne sais pas quoi répondre à la question “Leadership”. En qualif client, le freelance ne sait pas par où commencer dans ses dix ans d’expérience. Il répond à côté. En entretien d’embauche, je demande de me parler d’un projet. C’était intéressant… sauf que c’était tellement décousu que je n’ai rien pu écrire dans mon compte-rendu.

Pourtant, il y a une méthode, la méthode STAR. Et elle résout tous ces problèmes.

Je l’envoie à tous les candidats que je reçois. Pourquoi ? Parce que je ne cherche pas des gens « bons en entretien ». Je cherche la personne qui va performer le mieux sur le poste.

Ce n’est pas normal que seule une poignée de personnes y ait accès. La prochaine fois, c’est toi qui auras cette promotion que tu mérites. Je te l’explique avec des exemples qui parlent aux devs. C’est parti.

La méthode STAR est plus difficile à prendre en main quand on est développeur

C’est vrai que la première fois que je suis tombé sur la méthode STAR, je me suis dit que c’était un truc de commercial.
Surtout le R, pour Résultat.
Résultat ? Genre “+50 % de chiffre d’affaires”.

Quand on est dev, on a des objectifs rarement mesurables.
Est-ce que le projet est en retard ? La qualité du code, on s’en fout, c’est la TMA qui va gérer.
Est-ce que j’ai bien communiqué ? Bah en vrai, si je prends deux heures pour ta réunion, je vais mettre l’équipe en retard sur le Burndown Chart.

Mon code a servi à quoi ? Bah, je t’avoue que le PO a pas trop expliqué. C’était une migration, et il fallait la faire.
On était trois devs sur le projet. Enfin quatre, mais le quatrième était pas là tout le temps.

On a fini un peu en avance, donc on nous a collé du périmètre en plus.
Est-ce que les utilisateurs sont contents ? Je sais pas.
Est-ce que le décideur est content ? Je crois que le chef de projet a été félicité.

Comprendre ce que “Résultat” veut dire quand on est dev

Oui, si tu travailles sur le sujet après dix ans sans te poser les bonnes questions, c’est un peu beaucoup de boulot. Cela dit, il n’est jamais trop tard pour commencer.

Par exemple, cette application mobile a des milliers d’utilisateurs quotidiens. Ce backend, quant à lui, répond à des centaines de requêtes par minute. Notre application est utilisée par des centaines de collaborateurs pour gérer les commandes. De plus, cette infra a été optimisée pour réduire les coûts de 5 000 € par mois. Tout ça, c’est réel.

Alors, est-ce que j’ai bien contribué ? La cheffe de projet m’a remercié. Mes collègues ont demandé à ce que j’intervienne sur un autre projet. En parallèle, les nouveaux m’ont posé des questions sur mon code, et je les ai aidés. (Le code qui ne sert à rien ne génère aucune question.)

Situation, le S de la méthode STAR — parce que le contexte, c’est tout

On dit que la méthode STAR commence par la “Situation”. En réalité, elle commence par ta capacité à poser le décor. Et là, il y a deux façons de structurer ce que tu racontes.

Les 5 W (ou 5 Q) pour ancrer ton récit

La première méthode, c’est celle des 5 W du journalisme. En français, on parle parfois des “5 Q”, mais on ne va pas se mentir : c’est moins stylé. Who, What, When, Where, Why. Qui, Quoi, Quand, Où, Pourquoi. Ces cinq questions, c’est la base pour que ton interlocuteur puisse situer ton histoire dans le réel.

Commencer par le “Pourquoi”

Et parmi ces cinq-là, il y en a une qui fait souvent la différence : le Why. Il y a un marketeur qui en a même fait un best-seller : Start With Why. C’est une très bonne stratégie si tu veux capter l’attention de ton recruteur ou de ton client.

Parce que le “Pourquoi”, c’est l’enjeu. Qu’est-ce qui se passe si on ne fait pas cette migration ? Si on ne livre pas avant Noël, les enfants n’auront pas leurs cadeaux. Si on ne sort pas la feature avant le concurrent, c’est le churn assuré. Le logiciel de caisse va planter au 1ᵉʳ janvier. Ok, on ne sauve pas le monde en informatique. Mais comme on attend toujours la dernière minute pour mettre les moyens, il y a souvent de la tension.

Un cadre simple pour structurer ta situation

Tu peux t’appuyer sur ce canevas :

• Qui : ton rôle, ton équipe, les profils autour de toi

• Quoi : la mission, le produit, la problématique (migration, refonte, build from scratch…)

• Où : chez un client, en centre de service, en startup, dans une DSI ; avec ou sans budget

• Quand : ton niveau d’expérience, ton ancienneté, la phase du projet

• Pourquoi : l’enjeu business, la contrainte, le risque ou l’urgence

Le triangle d’or du chef de projet

Deuxième outil utile : le triangle d’or de la gestion de projet. Temps, budget, périmètre. C’est la trinité sacrée du PMBOK. Et crois-moi, ce triangle te raconte souvent plus de choses que les intitulés de poste.

Une appli mobile, par exemple, peut coûter 20 000 ou 200 000 €. On peut la faire seul ou à dix. On peut la sortir en 20 jours ou en 6 mois. Ça peut être un MVP stylé ou une refonte d’un monolithe qui fait 3 millions de chiffre d’affaires par jour.

On peut pas deviner tout ça à ta place. C’est indispensable de l’expliciter.

Tâche, le T de STAR — ce qu’on attendait de toi

C’est pas l’objectif du projet. C’est ton objectif à toi.

La Tâche de la méthode STAR, ce n’est pas “on devait sortir une nouvelle appli mobile”.
C’est “je devais m’assurer que l’authentification marchait avec le nouvel IdP”, ou “ma mission, c’était d’intégrer la brique de paiement dans la V2”.

Autrement dit : ce qu’on attendait de toi dans ce projet, pas du projet dans sa globalité.

🎯 Si on t’avait fait un ticket JIRA, il aurait eu ton nom dessus. C’est ça, ta tâche.

Comment savoir si t’as bien posé la tâche ?

Pose-toi une de ces questions :

• Si tu ne l’avais pas fait, qu’est-ce qui se serait mal passé ?

• Est-ce que c’était ta priorité principale ?

• Est-ce que ton lead ou ton client t’avait dit “on te confie cette partie-là” ?

• Est-ce qu’un autre dev aurait pu faire autre chose pendant que toi, tu faisais ça ?

Même dans une équipe où tout le monde fait “un peu de tout”, on a toujours des bouts de mission attribués, même tacitement. Le but ici, c’est de les rendre visibles.

Exemples de formulation de Tâche (claires et utiles)

• “Ma mission, c’était de fiabiliser la synchro entre notre outil et Salesforce, qui plantait régulièrement.”

• “J’étais chargé de créer les composants UI réutilisables dans le design system.”

• “On m’avait confié la migration de la base Postgres 9 vers 14, avec zéro downtime autorisé.”

• “Je devais reprendre un module legacy écrit par un prestataire parti sans doc.”

Si tu veux commencer tout de suite, je te propose un Prompt pour ChatGPT, Gemini, Mistral, enfin celui qui est là avec toi dans la pièce 👀.

Je suis développeur•se et j’apprends à présenter mes expériences avec la méthode STAR.
Tu as lu Work Rules! de Laszlo Bock, et tu sais que structurer ses réponses en entretien est une compétence essentielle pour faire reconnaître son impact.

Voici un texte où je raconte une mission, mais c’est brut, pas très structuré. Aide-moi à reformuler ça en suivant la méthode STAR (Situation, Tâche, Action, Résultat), sans trahir le fond. Je veux une réponse claire, crédible et orientée impact, comme si je parlais à un recruteur technique.

[Colle ici ton texte]