Habituellement, sur ce blog, je vous parle de JavaScript, de TypeScript, de Node.js, d’architecture, de bonnes pratiques. Des sujets bien carrés, avec du code, des exemples concrets, des choses tangibles.

Aujourd’hui, pas de code.

Aujourd’hui, je vais vous parler de quelque chose que je n’avais pas du tout prévu : le jour où je suis devenu manager. Ça fait six ans maintenant. Et je mesure encore à quel point je n’étais pas préparé à ce qui m’attendait.

Moi, je voulais juste coder

Autant être honnête dès le départ : le management, ça ne m’a jamais fait rêver.

J’aime la tech. J’aime comprendre comment les choses fonctionnent sous le capot. J’aime débugger un problème tordu, explorer un framework, ne pas lâcher un bug tant que j’ai pas compris pourquoi il existe. J’aime quand les choses sont logiques, prévisibles, maîtrisables.

Le management ? Ça me semblait être un monde de réunions interminables, un monde flou, politique, où la compétence technique passe au second plan.

Et puis la réalité m’a rattrapé.

Quand tout ce qui ne devait pas arriver est arrivé

Je ne vais pas entrer dans tous les détails, mais voilà le tableau : j’ai évolué pendant un moment dans un environnement où à peu près tout ce qu’il ne faut pas faire était fait.

Des décisions prises sans consulter les équipes. Des objectifs qui changeaient en permanence sans explication. Zéro transparence. Zéro cadre. Des pratiques de management qui relevaient davantage du contrôle que de l’accompagnement. Le genre d’environnement où tu sens que quelque chose ne tourne pas rond, mais où personne ne le dit à voix haute.

Et un jour, le manager est parti. Du jour au lendemain. Sans transition, sans passation, sans filet.

L’équipe s’est retrouvée livrée à elle-même.

On avait les compétences. On avait les gens. Sur le papier, tout était là pour que ça fonctionne. Sauf que ça ne fonctionnait pas.

Une équipe compétente ne suffit pas

C’est une leçon qui paraît évidente avec le recul, mais que j’ai mis du temps à intégrer vraiment.

On peut réunir des développeurs talentueux, des gens motivés, des profils complémentaires : si la confiance n’est pas là, si le cadre est absent, si personne ne joue le rôle de liant, ça ne marche pas. Ou ça marche mal. Dans la douleur.

Sans quelqu’un pour absorber le bruit extérieur, pour clarifier les priorités, pour créer un espace où les gens se sentent en sécurité pour parler, l’équipe s’est mise à fonctionner en mode survie. Chacun dans son coin. Les échanges réduits au strict nécessaire. Les frustrations accumulées en silence. Les petits désaccords transformés en tensions sourdes.

Le code continuait de sortir. La delivery avançait, en apparence. Mais en dessous, tout s’effritait. Comme une application qui tourne en prod avec des erreurs silencieuses partout. De l’extérieur, tout semble normal. En interne, c’est un château de cartes.

Le jour où j’ai pris le rôle, pour l’équipe

Je n’ai pas décidé un matin de devenir manager par ambition ou par calcul. C’est arrivé progressivement, parce que je voyais l’équipe souffrir et que j’ai commencé à faire ce qui me semblait nécessaire.

Écouter les gens, vraiment. Débloquer un conflit entre deux collègues. Reformuler une décision mal comprise. Aller chercher de l’information en amont pour éviter les surprises. Prendre du recul pour comprendre pourquoi le sprint avait dérapé, et réaliser que le problème n’avait rien à voir avec la technique.

Le vrai bug était humain

Face au chaos, j’ai fait ce qu’on fait naturellement quand on vient de la tech : j’ai cherché la cause rationnelle.

Le process n’est pas bon ? On le redéfinit. Les tickets sont mal découpés ? On améliore le découpage. Les rituels sont inefficaces ? On les restructure. C’est rassurant, cette approche. On identifie un symptôme, on remonte à la cause, on applique un correctif.

Sauf que ça ne marchait pas. J’avais beau améliorer les process, rien ne bougeait en profondeur. Les mêmes tensions revenaient. Les mêmes silences pesants en daily.

Ce que j’observais (les retards, les frictions, la qualité qui baissait) c’étaient des symptômes. La cause, elle, était dans tout ce que l’environnement toxique avait abîmé.

La confiance avait été détruite. Les gens avaient appris à ne pas parler, à ne pas remonter les problèmes, à ne pas exprimer un désaccord. Parce qu’avant, dire les choses, c’était prendre un risque. Alors ils avaient arrêté.

Les attentes de chacun étaient devenues implicites, voire contradictoires. Les décisions passées avaient laissé des cicatrices que personne n’avait reconnues. Et les non-dits s’étaient empilés au point de devenir le mode de communication par défaut.

Résultat : une équipe techniquement solide, mais humainement fracturée.

Construire les fondations

C’est en vivant tout ce qu’il ne faut pas faire que j’ai fini par comprendre le vrai rôle d’un manager.

Construire la confiance, et accepter que ça prend du temps. Tout part de là. Sans confiance, le reste ne tient pas. La confiance ne s’installe pas du jour au lendemain. Elle se construit interaction après interaction, décision après décision. Tenir ses engagements. Être transparent, y compris quand la réponse c’est « je ne sais pas ». Avoir les conversations difficiles au lieu de les éviter. Et surtout, être constant. Rien ne détruit la confiance plus vite qu’un manager imprévisible. La cohérence, c’est la première forme de leadership.

Donner du contexte, pas juste des directives. Les gens ne veulent pas juste savoir quoi faire. Ils veulent comprendre pourquoi. Pourquoi cette priorité plutôt qu’une autre. Pourquoi cette décision a été prise. Quel est l’objectif derrière le ticket. Quand tu donnes du contexte, les gens prennent de meilleures décisions tout seuls. Quand tu ne donnes que des ordres, tu crées de la dépendance et de la frustration.

Créer un espace où les gens peuvent vraiment travailler. Une équipe où les gens ont peur de poser des questions, de remonter un problème ou de dire « je me suis trompé », c’est une équipe qui avance les yeux bandés. Le manager doit créer l’espace où l’erreur est permise, où le désaccord est sain, où poser une question « bête » ne te coûte rien. Ce n’est pas du confort pour le confort. C’est la condition pour que les gens donnent vraiment le meilleur d’eux-mêmes.

Absorber le bruit pour que l’équipe puisse avancer. Les demandes contradictoires, les urgences de dernière minute, la politique interne : tout ça existe dans toute organisation. La question c’est qui les gère. Quand personne ne joue ce rôle, tout atterrit directement sur l’équipe. Dans mon ancien environnement, c’était exactement ça : la pression descendait en cascade, sans filtre, sans explication. Les gens passaient plus d’énergie à décrypter ce qui tombait d’en haut qu’à faire leur travail. Un manager absorbe ce bruit. Pas pour cacher la réalité, mais pour la traduire en quelque chose d’utile et d’actionnable.

Faire grandir les gens

Pratiquer les 1:1 avec intention. Les 1:1 sont les moments les plus sous-estimés du rôle de manager. Ce sont des espaces dédiés à la personne : à ce qu’elle vit, à ce qui la freine, à ce qu’elle veut développer. C’est là qu’on capte ce qui ne se dit pas en réunion : un silence prolongé, un ton qui change, quelqu’un qui décroche progressivement. Un bon 1:1, c’est le manager qui écoute plus qu’il ne parle.

Donner du feedback direct, même quand c’est inconfortable. Éviter une conversation difficile, c’est abandonner quelqu’un à ses angles morts. Ne rien dire, c’est laisser les gens stagner et leur faire croire que tout va bien alors que ça ne va pas. Le feedback, ce n’est pas un événement annuel. C’est un réflexe, au fil de l’eau, ancré dans des faits concrets.

Accompagner les trajectoires, pas juste les sprints. Faire grandir quelqu’un, ce n’est pas juste lui déléguer des tâches. C’est comprendre où cette personne en est, où elle veut aller, et construire avec elle un chemin pour y arriver. Certains veulent progresser techniquement, d’autres veulent évoluer vers du lead, d’autres encore ne savent pas encore. Le rôle du manager, c’est d’avoir ces conversations de carrière régulièrement, pas une fois par an lors d’un entretien formel, mais en continu. C’est aussi de créer les opportunités : confier un sujet difficile à quelqu’un qui n’en a jamais eu la responsabilité, laisser quelqu’un mener une décision technique, exposer quelqu’un à des situations nouvelles en le soutenant plutôt que de toujours prendre sa place.

Déléguer de l’ownership, pas des tâches. C’est une distinction fondamentale. Déléguer une tâche, c’est dire « fais ça ». Déléguer de l’ownership, c’est dire « ce périmètre est à toi, tu es responsable des décisions qui s’y rapportent ». La différence est énorme : dans le premier cas, tu restes le point de décision. Dans le second, tu fais émerger des leaders. Un dev qui prend l’ownership d’un sujet, qui le porte de bout en bout, qui défend ses choix et assume les résultats, c’est quelqu’un qui grandit. Et c’est aussi ce qui permet à l’équipe de fonctionner sans que tout repose sur une seule personne.

Au final, un manager s’occupe de tout ce qui se passe entre les lignes de code. Ce truc qu’on appelle parfois le glue work : ce travail qui ne se voit pas, qui ne se mesure pas, mais qui fait souvent la différence entre une équipe qui tient et une équipe qui s’effrite.

Ce que j’ai dû désapprendre

Le plus dur dans cette transition, ça n’a pas été d’apprendre de nouvelles compétences. Ça a été de désapprendre certains réflexes de dev.

Mon réflexe de vouloir tout résoudre vite. En développement, c’est une qualité. Mais quand un collègue vient te parler d’un problème, il n’attend pas toujours une solution. Il a parfois juste besoin d’être entendu. Vouloir aller trop vite vers la résolution, c’est souvent passer à côté du vrai sujet.

Ma confiance absolue dans le rationnel. En tant que dev, on pense en systèmes logiques. Sauf que dans un collectif, une décision parfaitement rationnelle peut être vécue comme une injustice si elle est mal amenée. Le « quoi » compte, mais le « comment » et le « pourquoi » comptent au moins autant.

Mon besoin de contrôle. On ne gère pas de l’humain comme on gère une codebase. On ne fait pas un git revert sur une conversation qui a mal tourné. On accompagne. On influence. On cadre. On soutient. On confronte parfois. Mais on ne maîtrise jamais complètement.

Mon réflexe de tout porter seul. C’est l’erreur classique du début. J’ai tout pris sur moi : absorber, traduire, décider. J’étais devenu le point de passage unique. L’équipe allait mieux, mais elle allait mieux à travers moi. J’avais créé une nouvelle dépendance sans m’en rendre compte. Ce n’est que plus tard que j’ai compris que le vrai travail, ce n’était pas de porter l’équipe, c’était de distribuer ce leadership. Donner de l’ownership à ceux qui étaient prêts. Accepter que d’autres prennent des décisions différentes des miennes, et que ce soit OK.

Non, je n’ai pas quitté la tech

Je tiens à clarifier un truc, parce que c’est le malentendu le plus courant quand on parle de cette transition : non, je n’ai pas arrêté de coder.

Je code toujours. J’aime toujours autant ça. Je continue d’explorer des technos, de faire de la veille, de mettre les mains dans le code. Ce blog existe toujours, et ce n’est pas un hasard : la tech reste au cœur de ce qui me passionne.

Ce qui a changé, c’est la focale. Je code toujours, mais ce n’est plus l’essentiel de ce que j’apporte à l’équipe. Ce que j’ai compris avec le temps, c’est que quand le relationnel va bien dans une équipe, la tech suit. Quand les gens se font confiance, qu’ils communiquent bien, qu’ils n’ont pas à gérer des tensions sous-jacentes, ils produisent un meilleur travail. Naturellement.

Je reste dans la boucle technique. Je lis les pull requests. Je challenge les choix d’architecture. Je comprends les problèmes que l’équipe rencontre. Et c’est fondamental, parce qu’un manager qui se coupe de la tech perd quelque chose d’essentiel : la légitimité. En tant que dev, on aime être compris et challengé par quelqu’un qui parle notre langage. Un manager qui ne comprend plus les enjeux techniques est un manager qui perd progressivement la confiance de son équipe.

Mais il faut être honnête sur un point : ce curseur se déplace avec le temps. Avec six ans de recul, je code moins qu’avant. Non pas parce que je n’en suis plus capable, mais parce que mon impact est ailleurs. Plus l’équipe grandit, plus garder la main sur tout devient contre-productif : si tu restes celui qui review chaque PR, qui tranche chaque choix technique, tu empêches les autres de prendre cette place. Tu occupes l’espace au lieu de le créer. Rester dans la boucle technique, ce n’est pas s’accrocher au code. C’est garder la compréhension suffisante pour poser les bonnes questions, challenger les bons choix, et surtout, savoir quand faire confiance et laisser l’équipe porter.

Devenir manager, ce n’est pas quitter la tech. C’est changer de focale.

Tu passes du zoom sur le code au grand angle sur l’équipe. Le sujet n’est plus une fonction à optimiser, mais un groupe de personnes à faire avancer ensemble. Ce n’est pas moins technique, c’est autrement complexe.

Le piège, c’est de croire qu’il faut choisir. Poser le clavier et enfiler un autre costume. Mais les meilleurs managers tech sont ceux qui gardent les deux yeux ouverts : un œil sur les gens, un œil sur le terrain. Assez proches pour comprendre, assez loin pour voir ce que l’équipe ne voit pas encore.

Changer de focale, ce n’est pas perdre la mise au point. C’est décider sur quoi elle porte.

Pour conclure

Si je devais résumer tout ça en une phrase, ce serait celle-ci : les problèmes qui font vraiment mal dans une équipe technique sont rarement purement techniques.

La tech peut amplifier. La tech peut masquer. La tech peut cristalliser. Mais quand on creuse, on retrouve presque toujours de l’humain. De la communication qui a dérapé. De la confiance qui n’a jamais pris. Du contexte qu’on n’a pas partagé. De la fatigue qu’on n’a pas vue. Des attentes qui se sont croisées sans jamais se rencontrer.

C’est inconfortable à admettre quand on vient d’un monde où on aime les systèmes logiques et les solutions reproductibles. Mais c’est aussi ce qui rend ce rôle fascinant.

Parce qu’au fond, on ne construit pas que des systèmes. On travaille avec des gens. Et une équipe, même brillante, ne peut rien donner si les fondations humaines ne sont pas là.

C’est la leçon que mon expérience dans un environnement toxique m’a apprise. Et c’est probablement la plus précieuse de ma carrière.