Le secret des ingénieurs qui valent leur salaire : l’art de transformer l’« inconnu (ambiguïté) » en « faisable »

Points clés :

• La différence décisive entre un ingénieur senior et un ingénieur intermédiaire réside dans la capacité à rendre concrets des problèmes incertains et ambigus.
• La valeur d’un senior ne vient pas de sa seule compétence en code, mais de sa capacité à éliminer les risques d’un projet et à les convertir en plan d’exécution concret.
• Les pratiques de recrutement actuelles (tests d’algorithmes, etc.) échouent à évaluer cette compétence.
• La vraie progression commence par l’entraînement à définir clairement le problème avant même d’écrire du code.

---

Introduction : repenser la définition d’un ingénieur senior

• En général, un ingénieur senior est défini par une liste de compétences variées : conception d’architecture, communication, leadership, etc.
• Mais si l’on met de côté le titre, le salaire et les années d’expérience, la compétence essentielle qui distingue un ingénieur senior — ou au-delà — est une seule chose : la capacité à réduire l’ambiguïté.
• Toutes les autres compétences (comme l’exécution technique) en découlent.

Développement

1. Différence d’approche dans la résolution de problèmes : clarté vs ambiguïté

• Ingénieur intermédiaire (Mid-level) : il excelle lorsqu’on lui donne une spécification claire (spec) et des contraintes précises. Il est à l’aise pour résoudre des problèmes bien définis.
• Ingénieur senior : il se distingue lorsqu’il reçoit des demandes floues et abstraites comme « il faut améliorer les performances », « les plaintes utilisateurs augmentent » ou « il faut penser à la scalabilité ».
• Le senior ne se contente pas d’exécuter un problème ambigu : il l’analyse, le décompose et le transforme en tâches concrètes.

2. Le rôle central d’un senior : éliminer les risques du projet

• Face à un problème vaste et abstrait, un ingénieur senior lève l’incertitude avec une approche de ce type :

• poser les questions essentielles que les autres ne posent pas ;

• séparer les signaux importants du bruit (noise) ;

• décider de ce qu’il faut exécuter tout de suite et de ce qu’il faut reporter.

• Ce processus réduit les risques du projet (de-risking) et transforme un état de « on ne sait même pas exactement ce que c’est » en « petits projets actionnables et éléments à éliminer ».

• Quand un senior fait bien ce travail, le projet avance avec fluidité et paraît facile vu de l’extérieur, mais c’est en réalité le résultat d’une énorme quantité de « travail invisible » effectuée en amont.

3. Approches concrètes pour lever l’ambiguïté

• Avant de coder, un ingénieur senior pose des questions comme celles-ci pour clarifier le problème :
• Nature du problème : quel est le vrai problème de fond que nous essayons de résoudre, plutôt que la solution que nous pensons vouloir ?
• Définition de l’utilisateur : à quelle douleur précise de quelles personnes cherchons-nous à répondre ? (éviter le terme trop large de « utilisateur »)
• Validation des hypothèses : quelles hypothèses erronées se cachent dans le plan actuel ?
• Évaluation des risques : quel est le pire scénario si notre jugement est faux ?

4. Limites du système de recrutement et mauvaise sélection des seniors

• La plupart des entreprises recrutent en se concentrant sur une liste de technologies ou sur la capacité à résoudre des problèmes d’algorithmes (LeetCode).
• Cette approche ne permet pas de vérifier la capacité à transformer des exigences produit ambiguës en plan d’exécution concret.
• Résultat : on produit en masse des ingénieurs « seniors » en apparence, excellents en code, mais incapables d’agir face à une spécification incomplète.

Conclusion : conseils pour progresser

• Les compétences en architecture ou en communication sont importantes, mais elles ne prennent vraiment de valeur qu’une fois que ce qu’il faut construire est clair.
• L’excellence technique, si elle ne s’accompagne pas de réduction de l’ambiguïté, revient seulement à « résoudre élégamment le mauvais problème ».
• Pour savoir si l’on est au niveau senior, il faut regarder sa réaction face à une tâche abstraite : attend-on que quelqu’un d’autre clarifie la demande, ou la rend-on soi-même suffisamment concrète pour que l’équipe puisse exécuter ?
• Ce n’est pas un talent inné mais une compétence qui se travaille : lorsqu’on reçoit un ticket ambigu, il faut s’entraîner à concrétiser le problème plutôt que de se mettre immédiatement à coder.