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.

[mhj5730]

Pour ma part aussi, je considère que le processus consistant à évaluer des développeurs seniors avec des « tests de code algorithmique » relève des limites du système de recrutement. J’ai l’impression qu’un développeur senior qui mérite son salaire est quelqu’un qui s’est rapproché de l’essence du problème, ou qui est capable de s’en rapprocher.

[elbanic]

Cet article montre bien que tout dépend du point de vue. Pour ma part, je pense que le critère qui distingue un ingénieur senior d’un ingénieur intermédiaire, c’est simplement le périmètre.
La capacité à concrétiser l’ambiguïté fait partie des fondamentaux du métier d’ingénieur, et j’ai l’impression qu’à partir du niveau intermédiaire, il faut savoir le faire pour que le titre d’ingénieur soit vraiment approprié. Du coup, pour moi, cet article peut servir de critère pour distinguer un ingénieur intermédiaire d’un ingénieur débutant (associate).

[bichi]

Pour un test de développeur senior, je peux encore comprendre qu’il y ait une épreuve de programmation,
mais quand on te sort un problème d’algorithme, c’est vraiment absurde (j’étais tellement abasourdi que je ne m’en souviens même plus).

[mbh023]

L’excellence technique, lorsqu’on n’a pas réussi à définir clairement le problème, ne revient qu’à « résoudre avec élégance le mauvais problème ».

Une phrase vraiment glaçante

[baeba]

1. L’art de poser des questions et le capital social (Social Capital)

• Ignorance stratégique : les questions d’un senior ne viennent pas de l’ignorance, mais d’un acte intentionnel visant à éliminer l’incertitude. Poser sans honte des questions élémentaires (« Que signifie cet acronyme ? ») est une compétence clé.
• Mobilisation du capital social : contrairement à un junior, un senior a déjà construit un « capital social » (la confiance), ce qui lui permet de poser des « questions idiotes » sans être jugé incompétent. Le rôle du senior est d’utiliser cela pour lever les ambiguïtés en réunion.
• Prise en compte du contexte politique : face à des managers qui évitent la clarté, des questions trop directes peuvent être perçues comme une menace. Il faut donc un grand sens politique pour choisir des questions à la fois sûres sur le plan relationnel et utiles à l’avancement du projet.

2. Autonomie et gestion du risque (Autonomy & Risk)

• Résolution de problèmes sans filet de sécurité : la capacité à percer les blocages et à mener une tâche à bien par soi-même, sans aide extérieure ni consignes claires, est un critère de séniorité.
• Maîtrise du chaos (Chaos) : plutôt que de rechercher une clarté absolue, le senior décide selon le contexte s’il faut « s’arrêter » ou « avancer ». Au lieu d’attendre des spécifications parfaites, il pose des hypothèses raisonnables et livre (Ship) pour réduire la confusion.
• Prise de risque calculée : assumer des décisions techniques audacieuses qu’un junior ne peut pas prendre — comme corriger à l’exécution du code qui ne compile pas, ou lancer un refactoring à grande échelle — et en assumer les conséquences.

3. Inflation des titres et contradiction structurelle du recrutement

• Inflation des titres (Title Inflation) : la pratique consistant à promouvoir au rang de senior des juniors qui ne sont pas prêts, afin d’atteindre des indicateurs de performance, est très répandue. Cela crée un décalage entre le titre et les compétences réelles.
• Limites des méthodes de recrutement : les entreprises recrutent en se focalisant uniquement sur la résolution de problèmes d’algorithmes (LeetCode), au lieu d’évaluer la capacité à transformer des exigences floues en éléments concrets. Résultat : on produit des « seniors » incapables de faire quoi que ce soit sans spécifications.
• Substitution au rôle de PM : on voit des senior engineers passer leur temps à concrétiser des specs incomplètes (Half-baked spec) jetées par des PM paresseux. C’est certes une compétence d’ingénieur, mais aussi le signe d’une inefficacité organisationnelle.

4. Ancienneté (Tenure) vs pratique délibérée

• Différence qualitative dans l’expérience : il faut distinguer clairement « 10 ans de progression » de « 1 an d’expérience répété 10 fois ». Un vrai senior se forme par une pratique délibérée et par des défis qui le sortent de sa zone de confort.
• If vs What-if : le junior se concentre sur le traitement des conditions données (If), tandis que le senior anticipe ce qui se passe si les conditions changent (What-if).
• Définition des étapes de progression : le standard le plus courant dans l’industrie est : « phase encadrée (Junior) » → « phase d’exécution autonome (Regular) » → « phase d’encadrement des autres (Senior) ».

5. Regard sceptique sur le titre de senior

• Simple grade salarial (Pay Grade) : selon une vision cynique, l’appellation senior n’est pas un indicateur de compétence, mais seulement une classification administrative créée par les RH pour fixer les salaires.
• Écart entre entreprises : les écarts de compétence et de traitement sont énormes entre les seniors de la big tech (capables de résoudre des problèmes très ambigus et de grande ampleur) et ceux des entreprises ordinaires (souvent de simples salariés de longue date).