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 l’exécution correcte.

Senior : “Quel problème on résout ? Quelle est la meilleure solution ? Quel impact business ?” Focus sur l’impact et le contexte.

Exemple concret :

  • Junior implémente la feature demandée
  • Senior questionne la feature (“Pourquoi ? Alternatives ? Trade-offs ?”), propose une meilleure approche si pertinent

Message : Penser stratégie, pas juste exécution.

Changement 2 - De “mon code” à “notre système”

Junior : Ownership de tâches individuelles, focus sur la qualité de son code.

Senior : Ownership de composants/domaines entiers, focus sur l’architecture globale, la dette technique, la maintenabilité long terme.

Exemple concret :

  • Junior optimise sa fonction
  • Senior pense “Cette optimisation locale crée-t-elle de la dette ou de la complexité ailleurs ?”

Message : Vision système, pas juste local.

Changement 3 - De consommateur à multiplicateur

Junior : Consomme de la connaissance (apprend, demande de l’aide).

Senior : Multiplie la connaissance (documente, mentore, partage, crée des patterns réutilisables).

Exemple concret :

  • Junior résout un bug complexe, passe à la suite
  • Senior résout, documente, partage le learning, améliore le 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 les problèmes flous, préfère les tâches bien définies.

Senior : Embrasse l’incertitude, définit le problème, propose des solutions dans l’ambiguïté.

Exemple concret :

  • Junior : “Les specs sont floues, j’attends une 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 : Un senior passe un temps significatif à :

  • Aligner les stakeholders
  • Mentorer les juniors
  • Influencer les décisions
  • Négocier des compromis techniques

Message : Les soft skills deviennent aussi critiques que les hard skills.

Les 7 compétences attendues d’un senior :

Compétence 1 - Autonomie technique complète

Attente :

  • Résoudre des problèmes complexes sans supervision
  • Débloquer les autres devs
  • Produire du code production-ready sans multiples itérations de review

Indicateur : Ton manager te confie un projet complexe, part en vacances, et est serein.

Compétence 2 - Design et architecture

Attente :

  • Designer des composants/services scalables et maintenables
  • Choisir les patterns appropriés
  • Anticiper les edge cases et trade-offs

Indicateur : Tes designs sont discutés mais rarement rejetés, l’équipe suit tes architectural decisions.

Compétence 3 - Mentoring effectif

Attente :

  • Monter en compétences les juniors/mid-level
  • Code reviews pédagogiques
  • Créer de la documentation
  • Partager la connaissance

Indicateur : Les juniors progressent visiblement sous ton mentoring.

Compétence 4 - Communication technique

Attente :

  • Expliquer des décisions complexes simplement
  • Documenter clairement
  • Présenter à des stakeholders non-tech

Indicateur : Tes docs sont des références, tes présentations clarifient.

Compétence 5 - Jugement et trade-offs

Attente :

  • Évaluer les options
  • Comprendre les 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 les problèmes avant qu’on te les signale
  • Proposer des solutions
  • Porter l’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 les processus
  • Réduire les frictions de l’équipe
  • Influencer la tech stack
  • Contribuer à la culture

Indicateur : L’é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".