Situation réelle

“Quand est-ce que je serai senior ?” Cette question revient constamment. Réponse courte : quand tu arrêtes de penser en lignes de code et commences à penser en impact et en équipe.

Ce que j’ai observé : devenir senior n’est pas juste coder mieux. C’est un changement de perspective, de responsabilités, et d’attentes.

Le faux problème

Le faux problème serait de croire que senior = X années d’expérience. En réalité, certains sont senior à 3 ans, d’autres jamais après 10 ans. C’est une question de compétences ET de mindset.

Un autre faux problème : penser que c’est juste une promotion et une augmentation. En réalité, les attentes changent radicalement.

Le vrai enjeu

Le vrai enjeu est de comprendre ce qui change vraiment :

Les 5 changements majeurs junior → senior :

Changement 1 - De l’exécution à l’impact : Junior : “Donne-moi une tâche, je la fais.” Focus sur exécution correcte. Senior : “Quel problème on résout ? Quelle est la meilleure solution ? Quel impact business ?” Focus sur impact et contexte. Exemple concret : Junior implémente feature demandée. Senior questionne feature (“Pourquoi ? Alternatives ? Trade-offs ?”), propose meilleure approche si pertinent. Message : penser stratégie, pas juste exécution.

Changement 2 - De “mon code” à “notre système” : Junior : ownership tâches individuelles, focus qualité de son code. Senior : ownership composants/domaines entiers, focus architecture globale, dette technique, maintenabilité long terme. Exemple concret : Junior optimise sa fonction. Senior pense “Cette optimisation locale crée-t-elle dette ou complexité ailleurs ?” Message : vision système, pas juste local.

Changement 3 - De consommateur à multiplicateur : Junior : consomme connaissance (apprend, demande aide). Senior : multiplie connaissance (documente, mentore, partage, crée patterns réutilisables). Exemple concret : Junior résout bug complexe, passe à la suite. Senior résout, documente, partage learning, améliore processus pour que ça ne se reproduise pas. Message : impact via l’équipe, pas juste individuel.

Changement 4 - De l’évitement à l’ownership de l’incertitude : Junior : évite problèmes flous, préfère tâches bien définies. Senior : embrasse incertitude, définit le problème, propose solutions dans l’ambiguïté. Exemple concret : Junior : “Specs sont floues, j’attends clarification.” Senior : “Specs floues, voici 3 interprétations possibles, je recommande X car Y, validation ?” Message : réduction d’incertitude, pas attente de clarté.

Changement 5 - De technique pur à technique + humain : Junior : focus 95% technique, 5% communication. Senior : focus 60% technique, 40% communication (alignement, mentoring, influence, négociation). Exemple concret : Senior passe temps significatif à : aligner stakeholders, mentorer juniors, influencer décisions, négocier compromis techniques. Message : soft skills deviennent aussi critiques que hard skills.

Les 7 compétences attendues d’un senior :

Compétence 1 - Autonomie technique complète : Attente : résoudre problèmes complexes sans supervision, débloquer autres devs, produire code production-ready sans multiples itérations review. Indicateur : manager te confie projet complexe, part en vacances, serein.

Compétence 2 - Design et architecture : Attente : designer composants/services scalables, maintenables, choisir patterns appropriés, anticiper edge cases et trade-offs. Indicateur : tes designs sont discutés mais rarement rejetés, équipe suit tes architectural decisions.

Compétence 3 - Mentoring effectif : Attente : monter en compétences juniors/mid-level, code reviews pédagogiques, créer documentation, partager connaissance. Indicateur : juniors progressent visiblement sous ton mentoring.

Compétence 4 - Communication technique : Attente : expliquer décisions complexes simplement, documenter clairement, présenter à stakeholders non-tech. Indicateur : tes docs sont référence, tes présentations clarифient.

Compétence 5 - Jugement et trade-offs : Attente : évaluer options, comprendre trade-offs (vélocité vs qualité, complexité vs flexibilité), recommander avec contexte. Indicateur : tes recommandations sont écoutées, même si parfois non suivies.

Compétence 6 - Ownership et initiative : Attente : identifier problèmes avant qu’on te les signale, proposer solutions, porter amélioration continue. Indicateur : tu n’attends pas qu’on te dise quoi améliorer.

Compétence 7 - Impact au-delà du code : Attente : améliorer processus, réduire friction équipe, influencer tech stack, contribuer culture. Indicateur : équipe marche mieux grâce à tes initiatives hors code direct.

Cadre de décision

Voici comment progresser vers senior :

1. Auto-évaluation sur 7 compétences Exercice : note 1-10 chaque compétence. <7 = area à travailler. Cette lucidité guide progression.

2. Élargir scope progressivement Actions : prendre ownership composant, mentorer junior, proposer amélioration architecture. Ces actions développent compétences senior.

3. Penser impact, pas tâches Mindset : chaque tâche, demander “Quel impact ? Comment maximiser ?” Ce mindset est signature senior.

4. Documenter et partager systématiquement Pratique : chaque learning significatif → doc/article/présentation. Ce partage multiplie impact.

5. Demander feedback sur compétences senior One-on-one : “Où suis-je sur chemin junior → senior ? Quoi améliorer ?” Ce feedback calibre efforts.

Retour terrain

Ce que j’ai observé chez différents profils :

Le faux senior : 8 ans expérience, excellent techniquement, mais : jamais mentore, pas de doc, scope étroit, attend qu’on lui dise quoi faire. Résultat : bloqué mid-level malgré ancienneté. Message : ancienneté ≠ séniorité.

Le vrai senior rapide : 3 ans expérience mais : ownership composant critique, mentore 2 juniors, documente, propose améliorations, impact visible. Promu senior à 3.5 ans. Message : mindset et impact > ancienneté.

L’exemple du shift : Mid-level technique excellent. Shift vers senior : commence mentorer, documenter, penser architecture globale. 18 mois : promu senior. Feedback : “Ton impact a changé de dimension.” Message : changement mindset visible transforme trajectoire.

Le plateau technique : Dev excellent techniquement, refuse mentoring (“pas mon job”), ownership étroit. 10 ans : toujours mid. Part frustré. Message : refuser dimension humaine plafonne carrière.

Erreurs fréquentes (et comment les éviter)

Erreur 1 - Focus uniquement technique Piège : “Je code mieux donc je serai senior.” Réalité : senior = technique + humain + stratégie. Correction : développer soft skills activement.

Erreur 2 - Attendre la promo pour agir en senior Piège : “Quand je serai promu, je mentorerai.” Réalité : tu es promu PARCE QUE tu mentores déjà. Correction : agir en senior avant le titre.

Erreur 3 - Scope étroit Piège : “Mon code est parfait, ça suffit.” Réalité : senior pense système et équipe. Correction : élargir ownership au-delà du code individuel.

Erreur 4 - Éviter l’incertitude Piège : “Problème flou, j’attends clarification.” Réalité : senior réduit incertitude. Correction : embrasser ambiguïté, proposer structures.

Message de responsabilité

Devenir senior dépend de toi :

  • Tu es responsable d’élargir ton scope au-delà du code
  • Tu es responsable de mentorer et partager connaissance
  • Tu es responsable de penser impact et système, pas juste tâches
  • Tu es responsable de développer soft skills activement

La promo senior n’est pas donnée, elle est gagnée en démontrant impact senior avant le titre.

Pour aller plus loin

Le livre "Être ou ne pas être CTO" explore les différents niveaux de séniorité et leurs attentes.

Tu peux aussi consulter l’article "IC vs management" ou les autres contenus du pilier "Trouver sa place".