Modèle d’échelle de carrière

Modèle d’échelle de carrière pour développeurs

Cinq niveaux, de junior à Principal, sur six compétences : de la livraison du code au développement de l’équipe.

Commencer gratuitement Télécharger en CSV

Offre gratuite · Sans carte bancaire

Cette échelle de carrière s’adresse aux éditeurs de logiciels d’environ 20 à 200 personnes : les développeurs livrent des fonctionnalités de bout en bout, les équipes sont petites et personne aux RH ne rédige d’architecture des emplois. Elle décrit cinq niveaux, de la personne qui débute sa carrière à celle qui façonne l’orientation technique de toute l’entreprise. Son niveau le plus élevé, Principal Engineer, est un niveau expert ; le management des développeurs relève d’une échelle distincte, celle de l’engineering manager.

Chaque niveau se définit par ce que la personne fait, pas par ses années d’expérience. Lisez une ligne de la matrice de compétences de gauche à droite pour voir comment une attente évolue ; lisez la section d’un niveau pour voir d’un coup tout ce qui est attendu à ce niveau. Servez-vous-en pour expliquer ce que signifie le niveau suivant, pour structurer les auto-évaluations et les points de suivi, et pour rendre les dossiers de promotion comparables d’une équipe à l’autre.

Considérez-la comme un point de départ. Renommez les niveaux selon vos intitulés de poste, fusionnez ou supprimez les compétences qui ne correspondent pas à votre entreprise, et reformulez les attentes avec vos propres mots avant de publier l’échelle auprès de l’équipe.

Les niveaux en un coup d’œil

Développeur junior
Apprend à connaître la base de code et réalise des tâches bien définies avec un accompagnement.
Périmètre
Des tâches individuelles dans une partie du produit, généralement découpées par quelqu’un de plus expérimenté.
Développeur confirmé
Livre des fonctionnalités en autonomie et est un membre fiable de l’équipe.
Périmètre
Des fonctionnalités petites et moyennes dans le périmètre d’une équipe, d’une courte note de conception jusqu’à la production.
Développeur senior
Pilote des chantiers plus importants et élève le niveau d’exigence de l’équipe qui l’entoure.
Périmètre
Des projets qui couvrent plusieurs services ou plusieurs personnes, et les décisions techniques d’une équipe.
Staff Engineer
Résout des problèmes qui dépassent les frontières des équipes et oriente les décisions techniques au-delà d’une seule équipe.
Périmètre
Plusieurs équipes ou tout un domaine produit, y compris des problèmes dont aucune équipe n’est responsable.
Principal Engineer
Fixe l’orientation technique de l’entreprise et répond de sa santé technique à long terme.
Périmètre
Toute l’organisation technique et la stratégie technique de l’entreprise pour les prochaines années.

Matrice de compétences

Chaque ligne est une compétence et chaque colonne un niveau. Lisez une ligne de gauche à droite pour voir comment les attentes évoluent.

Ce que recouvre chaque compétence

Réalisation technique: Transformer des besoins en logiciel fonctionnel et maintenable, et le mettre entre les mains des utilisateurs.
Conception de systèmes: Choisir des structures, des interfaces et des compromis qui tiendront à mesure que le produit grandit.
Qualité et fiabilité: Garder le produit correct, observable et disponible, et tirer les leçons des incidents.
Collaboration et communication: Travailler efficacement avec les autres développeurs, le produit, le design et le reste de l’entreprise.
Responsabilité et impact produit: Comprendre pourquoi le travail compte et assumer la responsabilité des résultats, pas seulement des tâches.
Mentorat et développement de l’équipe: Aider les autres à progresser et rendre l’équipe plus forte que n’importe lequel de ses membres.

Développeur : attentes par compétence et par niveau
Compétence	Développeur junior	Développeur confirmé	Développeur senior	Staff Engineer	Principal Engineer
Réalisation technique	Mène à bien des tâches bien cadrées avec un code lisible et des tests, demande de l’aide après quelques heures de blocage plutôt que quelques jours, et traite les commentaires de revue avant le merge.	Porte une fonctionnalité d’une courte note de conception jusqu’à la production sans qu’on le tienne par la main, la découpe en pull requests faciles à relire, et donne des estimations réalistes pour un travail familier.	Livre des projets qui couvrent plusieurs services ou contributeurs, ordonne le travail pour que quelque chose d’utile sorte tôt, et lève les risques avant qu’ils ne bloquent l’équipe.	Débloque la livraison entre équipes : démêle les dépendances partagées, construit l’outillage ou mène les migrations dont plusieurs équipes ont besoin, et maintient le cap des projets multi-équipes.	Façonne la manière dont toute l’organisation livre — pratiques de mise en production, choix de plateforme, outils de build et de déploiement — pour que chaque équipe livre plus vite et plus sûrement.
Conception de systèmes	Suit les patterns existants de la base de code et sait expliquer pourquoi le code qu’il a modifié est structuré ainsi.	Conçoit des composants au sein d’un service existant, rédige une courte note de conception pour les changements non triviaux, et compare au moins deux options avant d’en choisir une.	Pilote la conception de fonctionnalités qui couvrent plusieurs services, consigne les compromis pour que d’autres les relisent, et relit de façon constructive la conception des autres développeurs.	Définit l’architecture au-delà des frontières des équipes — modèles de données partagés, contrats entre services, décisions de développer ou d’acheter — et anticipe la façon dont le système devra évoluer dans les un à deux ans.	Porte la stratégie technique de l’entreprise : sur quelles technologies parier, lesquelles abandonner, et comment l’architecture doit évoluer avec l’activité sur plusieurs années.
Qualité et fiabilité	Écrit des tests pour ses propres changements, vérifie son travail avant la mise en production, et corrige les bugs dans le code qu’il a touché.	Ajoute du monitoring et des alertes pour les fonctionnalités qu’il construit, participe à l’astreinte, et gère les incidents courants à l’aide du runbook.	Pilote la réponse aux incidents sur les systèmes de l’équipe, rédige des post-mortems sans recherche de coupable, et s’assure que les actions de suivi sont réellement menées.	Repère les risques de fiabilité et de sécurité qui traversent plusieurs systèmes, fixe des standards comme la stratégie de test et les objectifs de niveau de service, et fait avancer les corrections entre équipes.	Définit ce que fiabilité, sécurité et qualité signifient pour l’entreprise, les arbitre face à la vitesse avec l’équipe de direction, et reste le dernier niveau d’escalade pour les incidents les plus difficiles.
Collaboration et communication	Partage ouvertement son avancement et ses blocages, et pose des questions claires quand un besoin n’est pas clair.	Travaille directement avec le produit et le design pour clarifier les besoins, explique les contraintes techniques en termes simples, et rédige des descriptions de pull request que les relecteurs peuvent suivre.	Représente l’équipe dans la planification, négocie le périmètre et les compromis avec le produit, et rédige des documents compréhensibles par des personnes extérieures à la tech.	Aligne plusieurs équipes et fonctions autour d’un plan technique, résout les désaccords entre équipes, et explique le risque technique à la direction.	Est une voix de confiance dans les décisions au niveau de l’entreprise, traduit la stratégie business en orientation technique et inversement, et représente la tech auprès des clients, des partenaires ou des investisseurs si nécessaire.
Responsabilité et impact produit	Comprend la finalité de ses tâches, vérifie que ce qu’il a livré fonctionne pour les utilisateurs, et assure le suivi jusqu’à ce que ce soit le cas.	Reste responsable d’une fonctionnalité après son lancement : suit son usage et ses erreurs, corrige ce qui ne va pas, et propose des améliorations à partir de ce qu’il apprend.	Porte un domaine du produit de bout en bout, remet en question les besoins qui ne servent pas les utilisateurs, et propose du travail qui fait avancer les objectifs de l’équipe.	Identifie les problèmes à plus fort effet de levier dans un domaine produit — y compris ceux qu’aucune équipe n’a pris en charge — et s’assure qu’ils soient résolus.	Relie l’investissement technique aux résultats de l’entreprise, et plaide pour ou contre les grands paris selon leur impact technique et business.
Mentorat et développement de l’équipe	Demande du feedback et en tient compte, et consigne ce qu’il a appris pour que le prochain arrivant démarre plus facilement.	Fait des revues de code soignées, aide à intégrer les nouveaux membres de l’équipe, et travaille en binôme avec les développeurs juniors sur les parties du code qu’ils connaissent mal.	Accompagne délibérément un ou deux développeurs en mentorat, donne un feedback qui les aide à atteindre le niveau suivant, et participe aux entretiens de recrutement.	Fait progresser les développeurs seniors de plusieurs équipes, façonne le processus de recrutement et les pratiques d’ingénierie, et est quelqu’un vers qui les autres se tournent pour un conseil.	Construit la culture technique de l’entreprise — la manière dont les décisions se prennent et dont les connaissances se partagent — et forme la prochaine génération de Staff Engineers.

Faites défiler le tableau horizontalement pour voir tous les niveaux.

Télécharger en CSV S’ouvre dans Excel, Google Sheets ou Numbers.

Développeur junior : ce qui est attendu

Apprend à connaître la base de code et réalise des tâches bien définies avec un accompagnement. Des tâches individuelles dans une partie du produit, généralement découpées par quelqu’un de plus expérimenté.

Réalisation technique: Mène à bien des tâches bien cadrées avec un code lisible et des tests, demande de l’aide après quelques heures de blocage plutôt que quelques jours, et traite les commentaires de revue avant le merge.
Conception de systèmes: Suit les patterns existants de la base de code et sait expliquer pourquoi le code qu’il a modifié est structuré ainsi.
Qualité et fiabilité: Écrit des tests pour ses propres changements, vérifie son travail avant la mise en production, et corrige les bugs dans le code qu’il a touché.
Collaboration et communication: Partage ouvertement son avancement et ses blocages, et pose des questions claires quand un besoin n’est pas clair.
Responsabilité et impact produit: Comprend la finalité de ses tâches, vérifie que ce qu’il a livré fonctionne pour les utilisateurs, et assure le suivi jusqu’à ce que ce soit le cas.
Mentorat et développement de l’équipe: Demande du feedback et en tient compte, et consigne ce qu’il a appris pour que le prochain arrivant démarre plus facilement.

Développeur confirmé : ce qui est attendu

Livre des fonctionnalités en autonomie et est un membre fiable de l’équipe. Des fonctionnalités petites et moyennes dans le périmètre d’une équipe, d’une courte note de conception jusqu’à la production.

Réalisation technique: Porte une fonctionnalité d’une courte note de conception jusqu’à la production sans qu’on le tienne par la main, la découpe en pull requests faciles à relire, et donne des estimations réalistes pour un travail familier.
Conception de systèmes: Conçoit des composants au sein d’un service existant, rédige une courte note de conception pour les changements non triviaux, et compare au moins deux options avant d’en choisir une.
Qualité et fiabilité: Ajoute du monitoring et des alertes pour les fonctionnalités qu’il construit, participe à l’astreinte, et gère les incidents courants à l’aide du runbook.
Collaboration et communication: Travaille directement avec le produit et le design pour clarifier les besoins, explique les contraintes techniques en termes simples, et rédige des descriptions de pull request que les relecteurs peuvent suivre.
Responsabilité et impact produit: Reste responsable d’une fonctionnalité après son lancement : suit son usage et ses erreurs, corrige ce qui ne va pas, et propose des améliorations à partir de ce qu’il apprend.
Mentorat et développement de l’équipe: Fait des revues de code soignées, aide à intégrer les nouveaux membres de l’équipe, et travaille en binôme avec les développeurs juniors sur les parties du code qu’ils connaissent mal.

Développeur senior : ce qui est attendu

Pilote des chantiers plus importants et élève le niveau d’exigence de l’équipe qui l’entoure. Des projets qui couvrent plusieurs services ou plusieurs personnes, et les décisions techniques d’une équipe.

Réalisation technique: Livre des projets qui couvrent plusieurs services ou contributeurs, ordonne le travail pour que quelque chose d’utile sorte tôt, et lève les risques avant qu’ils ne bloquent l’équipe.
Conception de systèmes: Pilote la conception de fonctionnalités qui couvrent plusieurs services, consigne les compromis pour que d’autres les relisent, et relit de façon constructive la conception des autres développeurs.
Qualité et fiabilité: Pilote la réponse aux incidents sur les systèmes de l’équipe, rédige des post-mortems sans recherche de coupable, et s’assure que les actions de suivi sont réellement menées.
Collaboration et communication: Représente l’équipe dans la planification, négocie le périmètre et les compromis avec le produit, et rédige des documents compréhensibles par des personnes extérieures à la tech.
Responsabilité et impact produit: Porte un domaine du produit de bout en bout, remet en question les besoins qui ne servent pas les utilisateurs, et propose du travail qui fait avancer les objectifs de l’équipe.
Mentorat et développement de l’équipe: Accompagne délibérément un ou deux développeurs en mentorat, donne un feedback qui les aide à atteindre le niveau suivant, et participe aux entretiens de recrutement.

Staff Engineer : ce qui est attendu

Résout des problèmes qui dépassent les frontières des équipes et oriente les décisions techniques au-delà d’une seule équipe. Plusieurs équipes ou tout un domaine produit, y compris des problèmes dont aucune équipe n’est responsable.

Réalisation technique: Débloque la livraison entre équipes : démêle les dépendances partagées, construit l’outillage ou mène les migrations dont plusieurs équipes ont besoin, et maintient le cap des projets multi-équipes.
Conception de systèmes: Définit l’architecture au-delà des frontières des équipes — modèles de données partagés, contrats entre services, décisions de développer ou d’acheter — et anticipe la façon dont le système devra évoluer dans les un à deux ans.
Qualité et fiabilité: Repère les risques de fiabilité et de sécurité qui traversent plusieurs systèmes, fixe des standards comme la stratégie de test et les objectifs de niveau de service, et fait avancer les corrections entre équipes.
Collaboration et communication: Aligne plusieurs équipes et fonctions autour d’un plan technique, résout les désaccords entre équipes, et explique le risque technique à la direction.
Responsabilité et impact produit: Identifie les problèmes à plus fort effet de levier dans un domaine produit — y compris ceux qu’aucune équipe n’a pris en charge — et s’assure qu’ils soient résolus.
Mentorat et développement de l’équipe: Fait progresser les développeurs seniors de plusieurs équipes, façonne le processus de recrutement et les pratiques d’ingénierie, et est quelqu’un vers qui les autres se tournent pour un conseil.

Principal Engineer : ce qui est attendu

Fixe l’orientation technique de l’entreprise et répond de sa santé technique à long terme. Toute l’organisation technique et la stratégie technique de l’entreprise pour les prochaines années.

Réalisation technique: Façonne la manière dont toute l’organisation livre — pratiques de mise en production, choix de plateforme, outils de build et de déploiement — pour que chaque équipe livre plus vite et plus sûrement.
Conception de systèmes: Porte la stratégie technique de l’entreprise : sur quelles technologies parier, lesquelles abandonner, et comment l’architecture doit évoluer avec l’activité sur plusieurs années.
Qualité et fiabilité: Définit ce que fiabilité, sécurité et qualité signifient pour l’entreprise, les arbitre face à la vitesse avec l’équipe de direction, et reste le dernier niveau d’escalade pour les incidents les plus difficiles.
Collaboration et communication: Est une voix de confiance dans les décisions au niveau de l’entreprise, traduit la stratégie business en orientation technique et inversement, et représente la tech auprès des clients, des partenaires ou des investisseurs si nécessaire.
Responsabilité et impact produit: Relie l’investissement technique aux résultats de l’entreprise, et plaide pour ou contre les grands paris selon leur impact technique et business.
Mentorat et développement de l’équipe: Construit la culture technique de l’entreprise — la manière dont les décisions se prennent et dont les connaissances se partagent — et forme la prochaine génération de Staff Engineers.

Comment adapter cette échelle

Alignez les niveaux sur vos intitulés
Si vos intitulés sont Développeur I, II et III, renommez les niveaux, mais gardez un niveau pour chaque vrai palier de périmètre. La plupart des entreprises de moins de 100 développeurs n’ont pas encore besoin d’un niveau Principal : laissez-le de côté jusqu’à ce que quelqu’un fasse réellement ce travail.
Gardez cinq à sept compétences
Au-delà de sept, personne ne les lit ; en dessous de quatre, des profils très différents se ressemblent. Fusionnez les compétences que vous évaluez toujours ensemble, et n’en ajoutez une que si elle changerait une vraie décision.
Formulez les attentes en comportements visibles
Pour chaque case, demandez-vous si un manager pourrait citer un exemple des six derniers mois. Remplacez des mots comme « solide » ou « approfondi » par ce que la personne fait réellement, par exemple « pilote la réponse aux incidents sur les services de l’équipe ».
Testez-la sur de vraies personnes avant de la publier
Demandez à deux ou trois managers de positionner les membres de leur équipe sur le brouillon. Là où ils ne sont pas d’accord, la formulation est ambiguë : corrigez-la, publiez l’échelle et convenez de la revoir dans six mois.

FAQ

Questions sur cette échelle

Combien de niveaux doit compter une échelle de carrière de développeur ?

Quatre à six, c’est la norme pour une entreprise de 20 à 200 personnes. Avec moins, les promotions deviennent rares et énormes ; avec plus, l’écart entre deux niveaux est trop mince pour être décrit. Ce modèle en utilise cinq : Développeur junior, Développeur confirmé, Développeur senior, Staff Engineer et Principal Engineer.

Les développeurs doivent-ils devenir managers pour progresser ?

Non. C’est une échelle du parcours expert : les Staff et Principal Engineers gagnent en périmètre et en influence sans manager personne. Utilisez-la avec l’échelle de l’engineering manager, pour que passer au management soit un changement de parcours et non une promotion.

Comment utiliser l’échelle pour les décisions de promotion ?

Promouvez les personnes qui travaillent déjà régulièrement au niveau suivant, pas celles qui pourraient le faire. Demandez à la personne et à son manager de réunir des exemples concrets pour chaque compétence du niveau visé, et comparez chaque dossier à la même matrice pour que les décisions restent cohérentes d’une équipe à l’autre.

Quelle place l’échelle a-t-elle dans les points de suivi et les 1:1 ?

Faites-en l’ordre du jour des points de suivi réguliers : la personne s’évalue par rapport à son niveau actuel, le manager fait de même, et les écarts entre les deux deviennent quelques actions de développement concrètes pour les mois à venir.

À quelle fréquence faut-il mettre à jour l’échelle ?

Revoyez-la une ou deux fois par an, et chaque fois que l’entreprise change de forme — par exemple quand vous créez une équipe plateforme ou commencez à recruter des Staff Engineers. Réécrivez une case dès que les évaluations butent régulièrement dessus.

Construisez cette échelle de carrière dans LadderKit — gratuitement

Configurez ses niveaux et ses compétences pour votre équipe, évaluez chacun par rapport à eux lors des points de suivi et gardez des décisions de promotion cohérentes.

Commencer gratuitement Découvrir la démo Sans inscription