Pourquoi j'ai lâché le management pour redevenir dev

Wed, 16 Sep 2026 00:00:00 GMT

Revenir à la technique n’est pas une régression. C’est juste se rendre compte qu’on est peut-être plus à sa place dans le code.

Bon. Voilà. J’ai un « blog » depuis presque une décennie et je n’ai jamais pris le temps d’écrire un seul article. Clairement, le syndrome classique du développeur qui a passé plus de temps à choisir son générateur de site statique (encore toute une histoire, ça) qu’à écrire le moindre mot dessus. Alors pour enfin faire passer le rendement de zéro à un article tous les dix ans (haha), j’ai décidé de commencer par un sujet qui compte vraiment pour moi : comment j’ai accidentellement fini manager, ce que ça m’a coûté pendant trois ans, et comment je suis revenu vers le code.

La promotion que je n’ai pas vraiment choisie

Un petit peu de contexte : le projet a été construit autour d’une nouvelle équipe d’ingénieurs juniors. Nous sommes presque tous arrivés le même jour, on a grandi ensemble dans le même codebase et survécu aux mêmes incidents en prod.

Nous étions plus qu’une équipe : nous avions le même âge, on était amis. Mais fatalement, après cinq ou six ans sur le projet, un grand nombre d’entre eux ont voulu voir d’autres horizons. Le groupe a commencé à se disperser et je me suis retrouvé être celui qui restait. Je suis devenu, en quelque sorte, le gars qui connaissait tous les recoins du code et dont les nouveaux avaient besoin pour ne pas se perdre.

Avec le recul, je sais que je ne suis pas parti pour deux raisons :

La peur, et le sentiment de « on n’est pas si mal que ça ici, finalement ».
Et plus les départs se succédaient, plus je me sentais redevable, par fidélité, de rester.

Alors quelques années plus tard, quand mon manager est monté d’un cran et qu’on m’a proposé sa place, j’ai dit oui. Pas par calcul de carrière, plutôt par loyauté envers l’équipe et le projet, et parce qu’à l’époque, si tu voulais progresser, il n’y avait qu’une seule route visible : le management. Le rôle de Staff Engineer, dont tout le monde parle aujourd’hui comme d’une évidence, était encore flou, presque inexistant.

Je n’étais pas prêt. Je l’ai découvert assez vite.

Le choc de la réalité managériale

Je ne suis généralement pas très client des formations, j’apprends plus par moi-même. Eh ben là, du coup, j’étais servi. Le passage développeur → manager a été un vrai speedrun. Pas de formation, quasiment pas de biseau (comprendre : aucune vraie passation). Certains me diront que c’est la preuve d’une entière confiance de la hiérarchie 😏.

Prendre un poste de manager, c’est déjà un métier entier. Le faire en pleine bascule COVID vers le full remote imposé, dans une organisation qui découvrait ça en même temps que tout le monde, ça n’a rien simplifié. Il fallait jongler entre des équipes locales très autonomes et exigeantes, et des équipes offshore qui avaient besoin d’un accompagnement beaucoup plus serré. Le grand écart était permanent.

Mais le plus stressant pour moi, c’était les évaluations annuelles. Et ça joue beaucoup : j’avais une bonne équipe. On avait un système de notation avec des quotas stricts, où il était structurellement impossible de mettre tout le monde dans la bonne case. Il y a aussi cette différence de perception entre le micro et le macro : on peut avoir la sensation d’avoir accompli toutes ses tâches et de mériter plus, alors qu’à l’échelle de l’équipe, l’impact individuel est beaucoup plus compliqué à mesurer. Je suis persuadé que sans cette vision macro, qu’on acquiert vraiment en devenant manager, il est difficile de s’en rendre compte. Au final, je ne m’y suis jamais habitué. C’était assez violent, même si personne ne le faisait volontairement : c’était simplement le système qui nous obligeait à le faire.

À ça s’ajoutait la position d’étau du middle management, très courante dans les grands groupes (je suppose, cf. mon CV) : faire respecter une méthodologie et des cycles de livraison aux équipes, pendant que ces mêmes plannings se faisaient régulièrement bousculer par des décisions prises plus haut, sans qu’on ait son mot à dire dessus. J’avais parfois l’impression d’être un reverse-proxy ! Mon seul but était de faire tampon, jour après jour, pour soulager au maximum mon équipe.

C’est un peu comme devenir papa : tu passes de « toi » à « lui », le bébé devient ta priorité, et le « toi » passe clairement au second plan. Ici, l’équipe, c’était « lui »…

La technique comme refuge et bouclier psychologique

Ah, j’y pense, vous ai-je dit que mon poste de senior backend dev n’avait jamais été remplacé ? Surprise : non, pas de remplacement. Je me suis retrouvé à faire les deux boulots à la fois. Le jour, manager. Le soir, entre deux réunions (voire très souvent pendant certaines réunions, on ne va pas se le cacher), développeur. Quitte à avoir une double vie, j’aurais préféré être milliardaire à Gotham City le jour, et en collants avec plein de gadgets la nuit.

C’est là qu’un mécanisme s’est installé, d’abord sans que je m’en rende compte, puis de façon de plus en plus consciente : je me réfugiais dans le code chaque fois que le reste devenait trop lourd.

Le code, c’est simple et rassurant pour moi, c’en est même une passion. Ce n’est pas une corvée, j’aime coder et résoudre des problèmes. Les résultats sont lisibles : ça marche ou ça ne marche pas. Pas d’ambiguïté, pas de charge émotionnelle à porter. L’humain, par contre, ne se résout jamais aussi proprement. Même du code assembleur (et pourtant, je suis une quiche en assembleur) me paraît plus compréhensible.

Naturellement, j’ai fini par utiliser la charge technique comme excuse légitime (« désolé pour l’administratif, il y a un souci en prod ») pour repousser les tâches managériales qui m’étaient les plus inconfortables. J’ai involontairement masqué mon malaise derrière ma performance technique, et ça a fonctionné assez longtemps pour que je ne me pose pas trop de questions.

Étais-je un bon manager ? Je n’ai jamais osé poser la question. Aurais-je dû ? Je ne pense pas que j’étais bon, pas non plus mauvais (j’espère). J’ai fait de mon mieux. Mais en tout cas, j’avais l’impression de ne pas être à ma place. J’avais le sentiment que je serais beaucoup plus performant en développant, en architecturant, en réfléchissant et en résolvant des problèmes techniques à temps plein.

La fausse promesse du « simple dev »

Un jour, ma femme et moi, nous avons eu le projet de déménager loin de notre ville actuelle. J’ai décidé de tenter une mobilité en interne. Logiquement, j’ai proposé de garder mon poste actuel et d’opérer l’équipe à distance : c’est rare dans notre groupe, mais il existe des précédents, et puis bon, avec le COVID, ça n’allait pas me changer des masses ! Je n’ai même pas essayé de chercher un autre poste ou un autre projet au sein du groupe. Je ne me voyais pas abandonner mon équipe pour un projet de vie personnel ; en proposant cet arrangement, j’avais l’impression de corriger le tir.

Bon, au final, pour des raisons internes, ça a été refusé. Ce déménagement s’est quand même réalisé grâce à l’opportunité de rejoindre un tout nouveau projet au sein du groupe, à condition de ne plus être… manager (ce poste étant déjà occupé par quelqu’un d’autre sur ce projet).

Ce qui est marrant, c’est toutes les pincettes qu’ils avaient prises pour m’annoncer que je ne pourrais être que « simple dev » et plus manager… Où est-ce que je signe ?

Ça m’a sorti de cette routine. Et le soulagement, en revenant à un poste purement technique, a été immédiat. Plus d’évaluations à distribuer, plus d’arbitrages politiques. J’avais l’impression de respirer après une trop longue apnée.

Mais cette tranquillité a eu ses limites. Après quelques mois, une fois mes marques prises, une forme de lassitude s’est installée. Avoir goûté à la vision globale rend difficile le retour à la pure exécution. Traiter des tickets sans influencer la roadmap ou l’architecture me donnait le sentiment de ne plus utiliser une partie de ce que je savais faire.

L’aboutissement sur le rôle de Staff Engineer

C’est là que j’ai compris quelque chose de très clair sur moi-même : je ne voulais plus gérer d’évaluations de performance ni de carrières. Mais je ne pouvais plus non plus me satisfaire d’exécuter sans avoir de prise sur la direction générale. Il me fallait un entre-deux, qui n’existait pas clairement à l’époque de ma première promotion.

L’équipe que j’avais rejointe venait d’être rachetée, et étant légèrement plus âgé que la moyenne, je venais un peu plomber leurs statistiques de jeunesse ! Mon expérience et ma connaissance de l’entreprise m’ont rapidement permis d’apporter une vision plus large. Les gens se reposaient sur mon vécu, ma technique et mon réseau.

Mais ce genre de rôle ne tombe pas du ciel. Je n’ai pas attendu qu’on me propose un périmètre étendu : j’ai commencé à prendre des sujets qui dépassaient le cadre de mon équipe, à aider sur des décisions d’architecture, à faire le lien avec d’autres pôles et, petit à petit, à devenir un point de référence.

J’en ai aussi parlé avec mon management direct pour affirmer ce besoin d’un rôle purement technique, mais avec davantage d’impact au-delà de mon périmètre direct. Le besoin était là, même si personne n’avait vraiment mis de nom dessus.

Dans ma boîte, le terme « Staff Engineer » n’existe d’ailleurs même pas officiellement (oui, je vous ai un peu menti depuis le début de cet article). Officiellement, je suis « Technology Senior Manager », et je n’ai personne sous moi… Tel notre bon vieux Napoléon Bonaparte, je me suis auto-promu Staff Engineer. C’est finalement comme ça que ce rôle s’est construit : par les actions, l’impact et l’influence, bien plus que par une fiche de poste.

Généralement, j’accorde peu d’importance au titre, mais ma position actuelle, un peu bâtarde pour les standards de mon entreprise, m’a forcé à réfléchir sur mon statut, ma place, et donc mon rôle. Je travaille en binôme avec un People Manager dédié, qui gère à 100 % l’humain et les carrières. Moi, je porte :

La vision technique et l’architecture.
Les connexions entre les équipes.
La gestion des crises et des incidents de production.
Le mentorat et la culture d’ingénierie.
L’amélioration de la Developer Experience (DX).

Concrètement, ça peut vouloir dire passer une semaine à débloquer une décision d’architecture, puis passer la suivante à refondre notre façon de gérer les incidents de prod. C’est identifier les points de friction des développeurs et de l’équipe qualité pour leur fournir les bons outils et de meilleurs processus. C’est aussi produire des PoCs, des démos et porter des présentations techniques.

Je ne m’ennuie pas, et c’est l’équilibre que je cherchais sans savoir le nommer.

Ce que trois ans de management ont apporté au Staff Engineer

Avec le recul, et même si sur le moment j’aurais signé pour écourter l’expérience, je ne renie pas ces trois ans. Ils m’ont donné des choses que je n’aurais jamais eues en restant simplement devant mon écran.

D’abord, j’ai vu l’autre côté du miroir. Une fois de l’autre côté, on se rend vite compte que c’est rarement aussi simple. Il y a des contraintes qu’on ne voit pas d’en bas, des arbitrages qu’on ne comprend pas tant qu’on n’a pas dû les faire soi-même.

Ça m’a aussi donné une vraie empathie envers les managers. Pas la fausse empathie de circonstance, genre « ouais je comprends, ça doit être dur », mais quelque chose de plus concret. Je sais maintenant ce que ça fait d’annoncer une mauvaise nouvelle qu’on n’a pas choisie, ou de porter une pression qu’on ne peut pas redescendre à son équipe.

Et puis il y a la compréhension du business. Ça aide énormément aujourd’hui en tant que Staff, pour parler le même langage que les gens côté produit ou direction. Ça se traduit très concrètement : plutôt que d’expliquer une contrainte technique en jargon, je sais maintenant la reformuler en impact business direct, ce qui simplifie beaucoup les réunions de priorisation.

Ce que j’en retiens

Si c’était à refaire, je repasserais par ces trois années de management. Pas parce que j’ai aimé chaque instant, loin de là, mais parce que ça m’a transformé. J’ai tellement appris. Et même si je suis repassé dans la branche du Contributeur Individuel, je sais maintenant à quel point les deux voies sont complémentaires. À partir d’un certain niveau de séniorité, comprendre ces différentes voies et savoir travailler avec elles devient essentiel. Encore plus avec l’avènement de l’IA (ouais, encore elle, l’IA 🤖…), où la technique brute va devenir moins déterminante.

Si vous êtes ingénieur et qu’on vous pousse gentiment vers le management parce que « c’est la suite logique », sachez que revenir en arrière n’est ni un échec ni une régression. On a le droit de réaliser que ce n’est tout simplement pas là qu’on s’épanouit. Ça m’a pris trois ans et pas mal de fatigue pour le comprendre. J’espère que ça ira plus vite pour vous.

Pour aller plus loin

Si le sujet vous parle, voici quelques lectures sur le même thème. Je les ai volontairement découvertes après avoir écrit mon billet, pour ne pas me laisser influencer en cours de route, donc si vous y trouvez des similitudes avec ce que je raconte, c’est purement une question de vécu partagé, pas de copie.

🇬🇧 The Engineer/Manager Pendulum de Charity Majors, le texte fondateur sur l’idée qu’on n’a pas à choisir une voie pour la vie.
🇬🇧 Pros and Cons of Going from Management Back to Individual Contributor, un retex très proche du mien.
🇬🇧 Pros and Cons of Going from Individual Contributor Back to Manager, par le même auteur, sur le chemin inverse.
🇫🇷 Comment je suis devenu manager malgré moi sur Code Heroes, qui me ressemble pas mal, sauf que lui, contrairement à moi, est resté manager.
🇬🇧 Returning to the IC track in the age of AI sur LeadDev, avec des chiffres récents sur cette tendance.

thibaud.dev