Pensez à deux managers que vous avez eus — un qui vous a rendu meilleur, et un qui ne l'a pas fait. Celui qui ne l'a pas fait vous gardait probablement occupé : tickets assignés, revues signées, standups suivis. Celui qui vous a vraiment rendu meilleur a probablement fait quelque chose de plus subtil. Il vous a donné un problème légèrement trop grand, est resté assez proche pour vous rattraper si vous tombiez, et a regardé pendant que vous vous en sortiez. C'est tout le métier du mentorat, là.
J'ai dirigé des équipes d'ingénierie de huit à onze personnes dans des startups et des scale-ups, et la différence entre les équipes qui grandissaient vite et celles qui plafonnaient venait presque toujours à une chose : si les personnes senior investissaient dans les juniors. Pas les surveiller. Pas faire leur travail. Investir — avec du temps, de la confiance, et une difficulté soigneusement conçue.
Cet article est tout ce que j'aurais souhaité que quelqu'un me dise avant ma première tentative de mentorer un ingénieur. C'est aussi, honnêtement, un registre des erreurs que j'ai faites et que j'ai dû désapprendre. Si vous êtes un ingénieur senior à qui on a confié quelqu'un à mentorer, ou un tech lead qui construit une équipe, j'espère que ça vous épargnera certaines de ces leçons.
Pourquoi le mentorat est un levier
Il y a une tentation — surtout si vous êtes venu en tant que contributeur individuel — de penser au mentorat comme à un coût. Le temps que vous passez à expliquer un concept est du temps pendant lequel vous n'écrivez pas de code. Mais ce cadrage a les mathématiques exactement à l'envers.
Si vous avez huit ingénieurs dans votre équipe, votre production en tant qu'équipe représente le travail de huit personnes. Au moment où vous aidez quelqu'un qui fonctionnait à 60 % de capacité à atteindre 80 %, vous avez ajouté 20 % d'une personne à la production de votre équipe — sans recruter, sans les coûts d'intégration, sans les trois mois qu'il faut à un nouvel embauché pour devenir efficace. Multipliez ça à travers une équipe et sur une année, et le mentorat est parmi les investissements à plus fort levier que vous puissiez faire.
Il y a aussi un effet d'élévation du plafond. Les meilleures équipes auxquelles j'ai appartenu n'étaient pas celles qui avaient le plus de stars — c'étaient celles où le plancher était le plus élevé. Quand chaque ingénieur de l'équipe peut être fait confiance pour gérer un problème difficile indépendamment, vous pouvez avancer bien plus vite qu'une équipe qui canalise tout à travers une ou deux personnes senior. Le mentorat élève ce plancher.
Et il y a l'angle de la rétention, qui compte plus que les gens ne l'admettent. Les ingénieurs ne quittent pas les emplois — ils quittent la stagnation. La raison numéro un que j'ai entendue d'ingénieurs qui quittaient des équipes est une version de « j'ai arrêté de progresser ». Une culture où les personnes senior investissent dans les juniors est une culture où les gens restent, et où vos connaissances institutionnelles ne quittent pas par la porte tous les dix-huit mois.
Rencontrez les gens là où ils en sont
La plus grande erreur de mentorat que je vois — et que j'ai moi-même faite tôt — est de calibrer le défi au mauvais niveau. Donnez à quelqu'un une tâche qu'il peut faire les yeux fermés et il s'ennuie. Donnez-lui quelque chose de genuinement hors de sa portée et il s'effondre. La magie se produit dans une bande entre les deux.
Le psychologue du développement Lev Vygotsky a appelé cela la zone de développement proximal. L'idée est simple : il y a des choses que vous pouvez faire indépendamment, des choses que vous ne pouvez pas faire même avec de l'aide, et — entre les deux — des choses que vous pouvez presque faire, que vous seriez capable de faire avec le bon soutien. Cette zone médiane est là où l'apprentissage se passe vraiment. C'est là que vit l'épreuve sans panique.
En pratique, cela signifie trouver la tâche qui est un pas au-delà de ce qu'ils ont déjà fait, pas dix pas. Un junior qui a géré des endpoints API simples est prêt à posséder une fonctionnalité de complexité modérée, pas une refonte complète du système. Un ingénieur mid-level qui a livré plusieurs fonctionnalités seul est prêt à diriger une qui implique une coordination entre équipes, pas à devenir le tech lead du jour au lendemain.
Comment savoir où se trouve la zone de quelqu'un ? Vous demandez, et vous observez. Demandez-leur quelles parties d'une tâche semblent claires et lesquelles semblent obscures. Observez où ils ralentissent dans une session de binômage. Remarquez quel type de questions ils posent (les grandes questions architecturales signalent généralement qu'ils sont près du bord ; les petites questions de syntaxe généralement pas). Vous vous calibrerez rapidement si vous faites attention.
Outils d'enseignement concrets
Il y a une poignée de techniques auxquelles je reviens encore et encore. Aucune n'est exotique.
Le binômage, bien fait
Le binômage est le moyen le plus rapide de transférer les connaissances tacites — le genre qui ne vit pas dans les docs, les instincts sur l'endroit où un problème se cache généralement ou pourquoi ce pattern cause de la douleur plus tard. Mais le binômage n'enseigne que quand c'est le junior qui conduit, pas le senior. Si vous vous asseyez et commencez à taper pendant qu'il observe, vous avez démontré votre compétence. Vous ne l'avez pas aidé à en développer une.
La version du binômage qui fonctionne vraiment : mettez le clavier devant eux, asseyez-vous à côté d'eux, et narrez ce que vous remarquez. « Je regarderais d'abord les cas limites ici — que se passe-t-il si cette liste est vide ? » Attendez. Laissez-les penser. Laissez-les se tromper. L'inconfort de ne pas intervenir est le prix d'entrée pour enseigner vraiment quelque chose.
La revue de code comme canal d'enseignement
La plupart des revues de code se concentrent sur le code. Un bon mentorat la transforme en conversation sur la pensée. Au lieu de simplement signaler qu'une fonction est trop longue, expliquez pourquoi — ce qui devient difficile à comprendre, ce qui casse en premier à mesure que la base de code grandit. J'ai écrit plus sur la mécanique de le faire avec bienveillance et efficacité dans Comment Réviser le Code avec Bienveillance, mais l'angle du mentorat mérite d'être ajouté ici : les revues sont l'un des rares endroits où vous pouvez saisir le raisonnement de quelqu'un et le rediriger avant qu'il ne devienne une habitude.
Une chose que j'ai appris à faire : poser des questions dans les revues plutôt que d'émettre des corrections. « Que se passerait-il si deux requêtes touchaient ça simultanément ? » est plus utile que « ce n'est pas thread-safe ». Ça les invite à réfléchir au problème ; ça ne leur donne pas simplement la réponse.
Expliquez votre raisonnement à voix haute
Les ingénieurs seniors ont d'énormes quantités de connaissances compressées et invisibles — ils ont juste oublié qu'ils les avaient. Quand vous prenez une décision, narrez-la. « Je vais avec une simple map en mémoire ici plutôt que d'atteindre Redis, parce qu'à cette échelle la complexité supplémentaire n'en vaut pas encore la peine. » Cette phrase, qui prend trois secondes à dire, peut prendre à un ingénieur junior des mois d'essais et d'erreurs à apprendre seul.
Vous n'avez pas besoin de narrer tout. Mais rendre votre raisonnement visible — surtout aux points de décision où la réponse n'est pas évidente — est l'une des choses à plus fort rendement que vous puissiez faire pour quelqu'un qui apprend le métier.
Les tâches d'épreuve avec un filet de sécurité
Le mouvement d'enseignement le plus efficace que je connaisse est d'assigner quelque chose de légèrement trop grand, puis de rester proche. Pas à planer — ils ont besoin d'espace pour se débattre — mais disponible. Vérifiez à des jalons naturels. Laissez-les venir vous voir avec des blocages plutôt que d'en anticiper chacun. L'objectif est qu'ils se sentent indépendants même si le filet de sécurité est là.
Une garde-fou importante : les tâches d'épreuve ont besoin d'une vraie deadline avec de vrais enjeux, mais pas des enjeux si élevés qu'un échec soit catastrophique. L'ingénieur junior qui épuise tout un week-end d'astreinte sur une tâche pour laquelle il n'était pas prêt sera plus réfractaire au risque, pas plus capable. Adaptez la taille de l'épreuve à combien le système peut se permettre que les choses aillent mal.
Ne le résolvez pas pour eux
C'est le plus difficile. Quand quelqu'un est bloqué et que vous connaissez la réponse, il faut une vraie discipline pour ne pas la donner. Mais au moment où vous le faites, vous êtes passé de l'enseignement à l'exécution. La prochaine fois qu'ils rencontreront un problème similaire, ils reviendront vous voir plutôt que de le travailler eux-mêmes.
Ce qui fonctionne à la place : posez la bonne question guidante. « Que dit réellement le message d'erreur ? » « Avez-vous regardé comment on a géré le cas similaire dans le module de paiements ? » L'objectif est de leur donner la prochaine étape dans leur propre réflexion, pas la réponse.
Quand quelqu'un vous apporte un problème, attendez trente secondes avant de dire quoi que ce soit. Souvent ils répondront à leur propre question pendant ce temps. Si ce n'est pas le cas, votre première réponse devrait être une question, pas une solution.
L'échelle d'autonomie
L'un des modèles mentaux les plus clairs que j'ai trouvés pour le mentorat est de penser à l'autonomie comme à une échelle. Où vous en êtes sur l'échelle détermine combien de contexte vous devez donner, à quelle fréquence vous vérifiez, et quel type de tâches vous assignez. L'objectif du mentorat est toujours de faire monter quelqu'un d'un échelon — pas de le tirer jusqu'en haut du jour au lendemain, mais de le garder en mouvement.
| Échelon | Comment ils opèrent | À quoi ressemble votre implication |
|---|---|---|
| 1 — Dirigé | A besoin d'instructions étape par étape ; incertain sur la plupart des décisions. Demande avant d'agir sur presque tout. | Vous définissez la tâche en détail, révisez chaque PR de près, vérifiez quotidiennement et narrez constamment votre raisonnement. |
| 2 — Guidé | Peut gérer le travail familier indépendamment ; a besoin d'input dans les nouvelles situations. Apporte les blocages plutôt que de deviner. | Vous fixez des objectifs clairs, définissez la portée et révisez les décisions clés. Vous vérifiez tous les quelques jours, pas quotidiennement. |
| 3 — Collaboratif | Propose sa propre approche, réfléchit aux compromis et signale les risques de façon proactive. Apporte des options, pas seulement des problèmes. | Vous agissez plus comme une caisse de résonance que comme un guide. Vous révisez l'approche avant l'exécution mais faites confiance à l'exécution. |
| 4 — Délégué | Prend possession complète d'un problème : périmètre, exécution, communication avec les parties prenantes. Escalade uniquement quand c'est vraiment nécessaire. | Vous vérifiez aux jalons. Vous êtes disponible quand ils veulent un deuxième avis, mais ils conduisent entièrement. |
| 5 — Approuvé | Vous leur confieriez n'importe quel problème de l'équipe, y compris ceux dont vous n'êtes pas sûr de savoir les résoudre vous-même. | Relation de pairs. Vous apprenez mutuellement l'un de l'autre. Votre rôle est de leur donner de la portée et de vous écarter. |
La plupart des nouveaux diplômés commencent à l'échelon un. La plupart des ingénieurs embauchés avec deux ou trois ans d'expérience atterrissent à l'échelon deux. Le chemin à partir de là dépend fortement de la façon dont leur manager et leur équipe investissent délibérément dans leur progression.
L'erreur la plus courante que je vois est de traiter quelqu'un comme s'il était à un échelon plus bas que celui qu'il a mérité. Si quelqu'un fonctionne à l'échelon trois mais que vous le managez encore à l'échelon un — en révisant chaque PR en détail, en vérifiant quotidiennement — vous le ralentissez, pas vous ne l'aidez. La confiance est quelque chose que vous étendez progressivement ; ce n'est pas une récompense que vous distribuez quand quelqu'un a définitivement « prouvé ».
La confiance s'étend avant la certitude — c'est ce qui en fait de la confiance. Si vous attendez que quelqu'un ait un bilan parfait avant de lui faire confiance avec quelque chose de difficile, vous lui avez refusé les conditions nécessaires pour construire ce bilan en premier lieu.
Faire croître les seniors, pas seulement fermer les tickets
Beaucoup d'attention au mentorat va aux juniors — et à juste titre, parce que le delta de junior à mid-level est raide et le besoin de soutien est évident. Mais les ingénieurs mid-level qui plafonnent en ferme-tickets et n'atteignent jamais le niveau senior sont l'une des pertes les plus courantes et les plus évitables dans une équipe d'ingénierie.
L'écart entre mid-level et senior est moins une question de compétence technique que la plupart des gens ne le pensent. Les ingénieurs mid-level techniquement forts plafonnent parce qu'ils n'ont pas eu l'opportunité de posséder quelque chose d'assez grand pour développer le jugement qui vient avec la portée.
Faire croître un senior signifie leur donner :
- De la portée, pas seulement des tâches. Un ingénieur mid-level auquel on donne une séquence de tickets terminera ces tickets et rien d'autre. Donnez-leur un problème — une zone du système à posséder, une capacité à construire — et ils doivent développer le jugement pour le décomposer, le séquencer et faire des compromis. Ce jugement est ce qui définit le senior.
- Une possession visible. Mettez-les dans la salle où les décisions sur leur domaine sont prises. Laissez-les présenter leur approche aux parties prenantes. Laissez-les la défendre quand elle est contestée. C'est inconfortable au début et inestimable avec le temps.
- La responsabilité du mentorat. Mettre un ingénieur mid-level en binôme avec un junior à mentorer est l'un des meilleurs accélérateurs que je connaisse pour leur croissance. Enseigner nécessite une compréhension à un niveau différent de faire. Ça les force aussi à articuler des jugements qu'ils prenaient intuitivement, ce qui est exactement l'étape de mid-level à senior.
- Une influence technique au-delà de leur travail immédiat. Les amener à piloter une décision de standards, écrire un ADR, ou mener un post-mortem technique — tout cela construit la largeur d'influence qu'un ingénieur senior a besoin d'avoir.
Erreurs de mentorat qui méritent d'être nommées
J'en ai fait la plupart. Celles que je n'ai pas faites personnellement, je les ai regardées d'autres bons ingénieurs les faire sans s'en rendre compte.
- Sauver trop tôt. Intervenir au moment où quelqu'un se débat semble utile. Ce n'est pas le cas. La lutte productive est là où se produit la croissance. Le sauvetage est pour quand quelqu'un est bloqué depuis trop longtemps sans voie à suivre — pas au premier signe de difficulté.
- Les retours vagues. « Ça pourrait être plus propre » ne dit rien à quelqu'un. « Cette fonction fait trois choses — la nommer d'après l'une d'elles serait trompeur, et ce sera difficile à tester » est un retour sur lequel il peut agir. La précision est de la bienveillance.
- Ne déléguer que le travail ennuyeux. Si les tâches que vous confiez aux ingénieurs juniors sont toujours les moins risquées, les moins visibles et les plus mécaniques, vous gardez l'apprentissage intéressant pour vous-même et leur donnez une carrière de corvées. Ils remarquent. Ils partent. Les tâches d'épreuve doivent aussi inclure les bonnes choses.
- Ne pas investir vraiment du temps. « Je suis disponible pour des questions » n'est pas du mentorat. Le mentorat nécessite du temps planifié et protégé — un tête-à-tête régulier avec un agenda de mentorat, pas seulement des mises à jour de statut ; une revue de code intentionnelle ; des sessions de binômage délibérées. Si vous le faites correctement, ça vous coûte deux à trois heures par semaine. Si ça ne vous coûte rien, vous ne le faites probablement pas de façon significative.
- En faire une affaire personnelle. L'objectif est leur croissance, pas votre satisfaction d'avoir un mentoré réfléchi. Parfois le bon choix pour eux implique des opportunités dans une autre équipe, ou un retour que votre base de code a des problèmes qui rendent leur apprentissage plus difficile. Les bons mentors mettent le mentoré en premier.
Comment le mentorat fonctionne à différentes échelles
Les principes fondamentaux ne changent pas avec la taille de l'entreprise, mais l'infrastructure autour d'eux change énormément.
| Stade de l'entreprise | Comment le mentorat fonctionne typiquement | Attention à |
|---|---|---|
| Startup (<30 ing.) | Informel et piloté par les relations. Le mentorat se passe dans le flux du travail — binômage, revue et proximité quotidienne. Pas de programme formel, mais souvent très intense parce que le travail lui-même est une tâche d'épreuve. | Les ingénieurs seniors trop enterrés dans la production pour investir dans les autres. Le mentorat se fait écraser par l'urgence. |
| Scale-up (30–150 ing.) | L'entreprise est assez grande pour avoir des grilles de carrière mais n'a souvent pas encore construit d'infrastructure de mentorat formelle. La qualité du mentorat varie énormément par équipe. Certains seniors sont excellents ; d'autres n'y ont jamais pensé. | Des résultats inconsistants. Un junior dans une équipe progresse vite ; un junior dans une autre équipe stagne pendant deux ans. L'équité devient un vrai problème. |
| Enterprise (150+ ing.) | Des programmes formels : binômes de mentorat, cadres de carrière structurés, budgets d'apprentissage, allocations de temps dédiées. Plus de processus, ce qui est parfois utile et parfois de la paperasse qui supplante la vraie relation. | Le processus se substituant à un investissement sincère. Un binôme de mentorat sur le papier qui se traduit par un café mensuel et aucun vrai défi. |
Dans une startup où j'ai travaillé, il n'y avait pas de programme de mentorat formel, mais les trois seniors de l'équipe avaient un accord tacite : chaque ingénieur junior serait le propriétaire principal d'au moins une fonctionnalité significative dans ses six premiers mois. Les fonctionnalités étaient périmètrées pour être réalisables avec du soutien, pas triviales. Les seniors se binômeraient sur les parties délicates et réviseraient tout de près, mais le junior conduisait. À la fin d'un an, ces ingénieurs juniors étaient des mid-levels en tout sauf le titre.
Dans une plus grande entreprise que j'ai rejointe plus tard, il y avait un programme de mentorat très sophistiqué — des binômes officiels, des points trimestriels, un modèle de document partagé pour les objectifs. Et ça ne fonctionnait surtout pas, parce que le modèle de document est devenu le mentorat. Personne ne suivait si les ingénieurs juniors obtenaient vraiment un meilleur travail ou juste une meilleure paperasse. La leçon que j'en ai tirée : la relation et le défi délibéré sont ce qui compte. Tout le reste est de l'échafaudage.
Points clés à retenir
- Le mentorat est un levier. Développer la capacité d'un ingénieur a des retours composés sur la production de l'équipe et la rétention — bien plus que les heures que ça coûte.
- La zone d'épreuve est là où se produit l'apprentissage. La tâche devrait être un pas au-delà de leur capacité actuelle, pas dix. Trop facile engendre l'ennui ; trop difficile engendre la paralysie.
- Les outils d'enseignement qui fonctionnent : le binômage conduit par le junior, les questions-pas-corrections dans la revue de code, narrer votre raisonnement à voix haute, les tâches d'épreuve avec des filets de sécurité, et résister à l'envie de résoudre pour eux.
- L'échelle d'autonomie vous donne un langage partagé sur où se trouve quelqu'un et où il va. Étendez la confiance un échelon devant là où vous en êtes certain.
- La croissance de mid-level à senior se passe à travers la portée, la possession, le mentorat des autres et l'influence technique — pas juste des tickets plus difficiles.
- Les pièges courants : sauver trop tôt, les retours vagues, ne déléguer que le travail ennuyeux, et ne pas investir de temps réel.
- La relation est le programme. Les structures formelles aident à grande échelle, mais elles sont de l'échafaudage. Le vrai travail est le défi délibéré, le retour honnête et la confiance étendue avant la certitude.
C'est le deuxième article d'une petite série sur la culture d'ingénierie. Si vous ne l'avez pas déjà fait, la première partie sur réviser le code avec bienveillance couvre la mécanique de donner des retours d'une façon qui enseigne sans démoraliser — la même compétence, appliquée au niveau de la PR. Plus d'écrits sur la culture, le recrutement et comment les équipes fonctionnent vraiment sont à venir.