“C’est quoi un Senior chez nous exactement ?” “Pourquoi lui a été promu et pas moi ?” “Comment je fais pour progresser ?”

Ces questions, on les a entendues de plus en plus souvent il y a quelques années chez Deepki. À l’époque, notre département Engineering grandissait vite : le nombre d’équipes avait doublé, on recrutait beaucoup de nouveaux Deepkies, et une nouvelle ligne de management venait d’arriver pour encadrer tout ça. Le problème ? On n’avait pas de framework de progression formalisé. Chaque manager appliquait ses propres critères, les conversations de promotion devenaient inconfortables, et le recrutement patinait faute de définitions partagées. Pour sortir de ce flou organisationnel, on a décidé de construire notre career path : Ma Trajectoire.

Dans cet article, je vous propose de partager ce qu’on a appris en chemin — les principes qui ont guidé notre réflexion, les pièges dans lesquels on est tombés, et les choix qu’on a faits. Si vous êtes manager, RH ou développeur dans une équipe en croissance où les promotions deviennent source de frustration, cet article est pour vous.

Pourquoi un career path ?

Les problèmes qu’on voulait résoudre

Sans career path, plusieurs problèmes émergent à mesure que l’on grandit.

Chaque manager développe sa propre vision de ce qu’est un “Senior” ou un “Lead”, et sans langage commun, impossible de garantir que les décisions de promotion ou les offres de recrutement soient cohérentes d’une équipe à l’autre. Chez nous, le rôle de Lead Developer par exemple était très hétérogène d’une équipe à l’autre — certains étaient des référents techniques tandis que d’autres faisaient du management de facto.

Côté développeurs, la frustration monte : ils veulent savoir où ils en sont et comment progresser, mais sans framework, cette conversation reste floue. Et côté entreprise, ce flou crée une dette organisationnelle qui ralentit l’exécution. Les managers passent plus de temps à arbitrer qu’à développer leurs équipes. La rétention des profils seniors devient fragile. Et le recrutement perd en crédibilité quand on ne sait pas expliquer clairement ce qu’on attend d’un Senior ou d’un Lead.

Notre enquête d’engagement interne confirmait ce ressenti. Trois items ressortaient systématiquement en rouge : “Je vois comment ma carrière pourrait évoluer”, “Je me sens encouragé et reconnu pour mes efforts”, “Je comprends clairement comment mes performances sont évaluées”. Les développeurs nous disaient clairement : on ne sait pas où on va, on ne comprend pas comment on est évalués, et on ne se sent pas reconnus.

Inutile de créer un framework sophistiqué pour une équipe de 5 personnes. Mais attendre trop longtemps crée de la dette organisationnelle difficile à rattraper. Quand les promotions génèrent de l’incompréhension ou du ressentiment, c’est le signe qu’il manque un cadre.

Ce que c’est — et ce que ce n’est pas

On a passé du temps à clarifier ce qu’on attendait de cet outil. Un career path, ce n’est pas une checklist de promotion ! Ce n’est pas non plus un document figé qu’on écrit une fois et qu’on oublie dans un wiki. Et ce n’est surtout pas un instrument de contrôle. C’est un outil pour expliciter les attentes à chaque niveau. Un guide pour les conversations — en 1:1, en évaluation, en recrutement. Et un document vivant qui évolue avec les retours du terrain. Un choix important : on a volontairement évité d’en faire une grille de compétences techniques. Pas de case “maîtrise TypeScript” ou “certifié AWS”. Ces aspects relèvent d’un autre outil (une cartographie des compétences techniques) porté par le leadership technique. Ma Trajectoire se concentre sur les comportements, les postures et l’impact. À notre taille, c’est ce qui fait vraiment la différence entre les niveaux.

La philosophie qu’on a adoptée tient en une équation : simple + transparent = juste.

La méthode

Impliquer les bonnes personnes

On a monté un groupe de travail avec les RH, des managers et des développeurs de différents niveaux. L’objectif : ne pas construire un outil théorique qui ne correspond pas à la réalité du terrain. On a organisé plusieurs workshops pour faire émerger les vrais sujets. Qu’est-ce qui pose problème aujourd’hui ? Qu’est-ce qu’on attend vraiment d’un Senior ? D’un Lead ? C’est quoi la différence entre un Lead Dev et un Staff Engineer ? Les échanges étaient parfois animés — et c’est justement là qu’on a appris le plus. Quelques questions qui ont fait débat :

  • “Le terme Staff, c’est un niveau ou un rôle ?” — Dans l’industrie, Staff désigne un niveau, mais ce niveau recouvre plusieurs rôles différents (architecte, solver, tech lead…). Ça créait de la confusion. On a décidé de clarifier en séparant explicitement “Niveau” et “Rôle”.

  • “Pourquoi personne ne veut devenir manager ?” — Le career path en Y (deux branches équivalentes : expertise technique ou management) n’existait pas vraiment chez nous. On a travaillé pour que la track management devienne une vraie option, pas une voie de garage.

  • “Qui est responsable de mon évolution ?” — On a clarifié les rôles : le collaborateur est acteur de sa trajectoire, le Lead Dev est mentor sur les aspects techniques, le Manager accompagne sur le respect du cadre et le delivery.

Tester avant de déployer

Avant de publier Ma Trajectoire, on l’a appliqué à des cas réels. On prenait des personnes de l’équipe et on se demandait : “Si on évalue Marie avec cette grille, ça donne quoi ? Est-ce que le résultat correspond à la perception qu’on a d’elle ?” Si le résultat ne collait pas à la réalité perçue, c’est le framework qui avait tort, pas Marie. On a itéré plusieurs fois avant d’arriver à une grille qui reflétait ce qu’on observait sur le terrain.

Ce qu’on a construit

Les briques fondamentales : Niveau × Rôle × Modificateur

Chez Deepki, chaque collaborateur est défini par trois éléments :

  • Le niveau (1 à 5) définit l’ampleur de l’impact — c’est la base de la rémunération.
  • Le rôle définit la nature des activités : Software Engineer, Lead Developer, Staff Engineer…
  • Le modificateur (optionnel) ajoute des responsabilités spécifiques sans changer de track.
Titre complet Niveau Rôle Modificateur
Junior Software Engineer SE-1 Software Engineer —
Senior Software Engineer Dataviz SE-3 Software Engineer Dataviz
Staff Engineer SE-4 Staff Engineer —

Pourquoi cette séparation ? Un même niveau peut correspondre à plusieurs rôles. Un Lead Developer (référent technique d’une équipe) et un Staff Engineer (impact transverse multi-équipes) peuvent être au même niveau — leur impact est équivalent, mais il s’exerce différemment. Les modificateurs nous permettent d’éviter de multiplier les intitulés de poste. Un Senior qui prend des responsabilités sur une expertise bien définie n’a pas besoin de changer de track — il ajoute un modificateur en accord avec son manager.

Un socle commun pour tous, puis des rôles pour chacun

Les trois premiers niveaux (SE-1 à SE-3) constituent un socle commun : tout le monde est Software Engineer. Junior, Confirmed, Senior — la progression se fait sur les mêmes axes, avec des attentes croissantes en autonomie et en impact. C’est le passage obligé pour acquérir les fondamentaux de l’ingénierie logicielle.

À partir du niveau 4, les chemins divergent. On ne parle plus de “Software Engineer niveau 4” mais de rôles distincts avec des missions différentes :

  • Lead Developer — Référent technique d’une équipe, expertise profonde sur un domaine
  • Staff Engineer — Impact transverse multi-équipes, connecte les points entre systèmes
  • Engineering Manager — Management d’équipe, développement des personnes

Un Lead Developer, un Staff Engineer et un Engineering Manager sont au même niveau (SE-4), avec la même grille salariale. Leur impact est équivalent, mais il s’exerce différemment : le Lead en profondeur sur son équipe, le Staff en largeur sur plusieurs équipes, le Manager sur le développement des personnes et l’efficacité collective.

Cette séparation est importante : on ne veut pas que la seule façon de progresser soit de devenir manager. Un excellent développeur peut évoluer jusqu’à Principal Engineer sans jamais encadrer personne.

4 axes, 5 niveaux : soyons modestes et géniaux

Chez Deepki, on a choisi 4 axes qui reflètent ce qu’on valorise vraiment :

Axe Ce qu’il couvre
🔧 Maîtrise technique Construire des solutions solides
🚀 Délivrer de la valeur Transformer du code en impact utilisateur
🤝 Esprit collectif Démultiplier l’impact des autres
👑 Leadership technique Guider et faire grandir (à partir du niveau 4)

4 axes × 5 niveaux = 20 cases. C’est gérable, maintenable, et suffisant pour couvrir l’essentiel. Un point sur lequel on a beaucoup itéré : les descriptions de niveau doivent être observables. “Autonome” ou “excellent communicant” ne veulent rien dire — ce sont des jugements subjectifs qui ouvrent la porte à tous les biais. On a préféré expliciter les attentes pour chaque axe avec des verbes d’action :

Niveau Verbe Ce que ça veut dire
SE-1 Junior APPLIQUER Suit les guidelines et bonnes pratiques
SE-2 Engineer AMÉLIORER Contribue à l’amélioration du code et des pratiques
SE-3 Senior CONCEVOIR Conçoit l’architecture, introduit des patterns durables
SE-4 Lead SYNCHRONISER Pilote l’architecture multi-équipes, aligne les choix
SE-5 Principal ORIENTER Définit les standards techniques organisationnels

Pourquoi des verbes ? C’est observable — on peut voir si quelqu’un “conçoit” ou “améliore”. Ça raconte une progression — APPLIQUER → AMÉLIORER → CONCEVOIR. Et ça évite les débats stériles : au lieu de discuter pendant des heures pour savoir si quelqu’un est “vraiment senior”, on regarde s’il conçoit ou s’il améliore. On a complété cette approche avec une notion d’impact :

Niveau Impact
SE-1 Junior Sur ses propres tâches
SE-2 Confirmé Sur ses user stories
SE-3 Senior Sur les epics / l’équipe. Peut porter un périmètre délégué (projet, expertise, domaine).
SE-4 Lead Sur plusieurs équipes
SE-5 Principal Sur l’organisation entière

Cette double grille — verbes d’action + impact — nous permet d’avoir des conversations claires : “Tu maîtrises bien l’architecture, mais ton impact reste limité à tes propres user stories. Pour passer Senior, il faut que ton expertise bénéficie davantage à l’ensemble de l’équipe. “

Ce que ça a changé

Après deux ans d’utilisation, les effets les plus visibles :

  • Alignement sur les attentes — les managers parlent le même langage, les développeurs savent ce qu’on attend d’eux
  • Promotions plus sereines — on passe moins de temps à débattre, les décisions sont plus faciles à expliquer
  • 1:1 plus cadrés — le framework donne une structure aux conversations de progression
  • Recrutement plus crédible — on sait expliquer aux candidats ce qu’est un Senior ou un Lead chez nous

Quelques conseils avant de se lancer

  • Ne copiez pas un framework existant sans l’adapter à votre contexte
  • Ne construisez pas seul dans votre coin — impliquez les acteurs de terrain (managers, développeurs, RH)
  • Ne multipliez pas les axes ni les niveaux
  • Ne confondez pas niveau et rôle — séparez-les explicitement
  • Ne décrivez pas les niveaux avec des adjectifs vagues — utilisez des verbes observables
  • Ne déployez pas sans tester sur des cas réels

À suivre…

Construire un career path, c’est bien. Le faire vivre, c’est mieux. Dans un prochain article, on partagera comment on a ancré Ma Trajectoire dans notre quotidien — 1:1, promotions, recrutement — notre process de progression par les pairs, et les limites qu’on a identifiées après deux ans d’utilisation. On ouvrira aussi sur les alternatives : entreprise libérée, Holacracy, Reinventing Organizations… parce qu’un career path classique n’est pas la seule façon de faire.

En attendant, vos retours en commentaires sont les bienvenus !

Ressources

  • progression.fyi — Collection de frameworks publics
  • The Manager’s Path de Camille Fournier
  • Staff Engineer de Will Larson (2021)
  • The Staff Engineer’s Path de Tanya Reilly (2022)