Faire monter une équipe technique : ce qui marche, ce qui coûte cher

Recruter des développeurs est la partie de mon travail où je me suis le plus trompé, et celle où les erreurs coûtent le plus longtemps. Un mauvais recrutement pèse dix-huit mois ; un mauvais choix technique se corrige en trois.

Voici ce que j’ai fini par retenir.

Sur quoi je recrute

La capacité à apprendre, pas la maîtrise d’une technologie précise. Une technologie s’apprend en quelques semaines quand on a les bases ; la façon de raisonner, non. Un bon développeur qui ne connaît pas notre stack sera productif au bout d’un mois, et il apportera un regard neuf.

La capacité à travailler avec d’autres. Le développement d’application métier est une activité collective : comprendre un besoin flou, poser des questions, accepter une revue, relire le travail d’un autre sans le braquer. Un excellent technicien incapable de ces choses ralentit l’équipe malgré sa production individuelle.

L’honnêteté sur ce qu’on ne sait pas. En entretien, je pose systématiquement une question hors du périmètre du candidat. Ce qui m’intéresse n’est pas la réponse : c’est de voir s’il dit « je ne sais pas » ou s’il improvise. En production, quelqu’un qui improvise sur ce qu’il ignore crée des problèmes coûteux.

Comment j’évalue, concrètement

J’ai abandonné les exercices d’algorithmique sous chronomètre. Ils mesurent la préparation aux entretiens, pas la capacité à livrer une application métier.

Ce que nous faisons à la place : une session de lecture de code. Je fournis un extrait réaliste de deux cents lignes, avec deux ou trois défauts volontaires, et je demande ce que la personne en pense.

Cet exercice montre presque tout : la capacité à comprendre du code qu’on n’a pas écrit — soit 90 % du métier —, le repérage des cas d’erreur non gérés, la formulation d’une critique, et l’humilité face à un contexte qu’on ne connaît pas.

Il a un autre mérite : il ressemble au travail réel, donc les candidats s’y montrent tels qu’ils sont.

Ce qui fait réellement progresser

La revue de code, systématique et dans les deux sens. C’est de loin le premier facteur. Relire et être relu expose à des façons de faire différentes, en continu, sur du code réel. Un développeur dont le travail est relu tous les jours progresse plus vite que par n’importe quelle formation.

Le binôme sur les sujets difficiles. Pas en permanence — c’est fatigant et coûteux — mais sur une conception structurante ou un bug tenace. Deux personnes sur un problème dur vont plus vite que deux personnes sur deux problèmes durs, et l’une des deux apprend.

La rotation sur les parties du système. Un développeur qui reste deux ans sur le même module devient irremplaçable, ce qui est un risque pour l’entreprise et une impasse pour lui. Nous faisons tourner, même quand c’est moins efficace à court terme.

Le droit de se tromper sans conséquence. Cela suppose une chaîne de déploiement qui permet de revenir en arrière. Un environnement où une erreur coûte cher produit des gens qui ne prennent aucune initiative — et l’on obtient exactement l’équipe qu’on a organisée.

Photo : Direct Media — licence CC0.

Ce qui marche moins bien que prévu

Les formations ponctuelles. Trois jours sur une technologie, sans mise en pratique dans le mois qui suit, ne laissent presque rien. Nous ne les avons pas supprimées, mais nous les programmons désormais juste avant un projet qui les utilisera.

Les certifications. Elles rassurent sur un socle, elles ne prédisent pas la capacité à livrer. Je n’en ai jamais tiré d’information utile en recrutement.

Le mentorat formalisé sans temps dédié. Désigner un référent sans lui allouer de temps produit un mentorat théorique : la personne est disponible « si tu as des questions », c’est-à-dire jamais, parce que personne n’ose déranger quelqu’un de visiblement surchargé.

L’erreur que j’ai répétée

Recruter un profil très expérimenté en pensant qu’il structurerait l’équipe tout seul.

Cela ne fonctionne que si l’organisation lui en donne les moyens : du temps qui n’est pas consommé par la livraison, un mandat clair, et le soutien de la direction quand il demande de ralentir pour améliorer quelque chose.

Sans cela, la personne est absorbée par l’urgence comme les autres, elle constate qu’elle ne peut rien changer, et elle part au bout d’un an. J’ai fait cette erreur deux fois avant de comprendre que le problème n’était pas le recrutement mais ce que nous en attendions.

Photo : Helloquence — licence CC0.

Faire entrer quelqu’un dans une base de code existante

L’intégration technique est l’endroit où l’on perd le plus de temps sans le voir, parce que la lenteur des premières semaines paraît normale.

Trois choses divisent ce délai par deux, et aucune ne coûte cher.

Un environnement qui démarre en une commande. Si installer le projet demande une journée et l’aide de deux collègues, ce coût se paye à chaque arrivée, et il indique en général que l’environnement de production est tout aussi artisanal.

Une première contribution utile dès la première semaine. Petite, réelle, mise en production. Ce qui compte n’est pas la contribution : c’est d’avoir parcouru toute la chaîne, du poste de travail au déploiement. Tant que ce parcours n’a pas été fait une fois, la personne ne sait pas comment le système vit.

Une carte du système, écrite. Deux pages : les composants, ce qui appelle quoi, où sont les données, ce qui est fragile. Ce document existe rarement, se rédige en une demi-journée, et épargne des dizaines d’interruptions.

Ce que je fais quand quelqu’un stagne

Cela arrive, et le laisser durer est la pire option — pour la personne d’abord.

Je commence par distinguer trois situations qui se ressemblent de l’extérieur et n’appellent pas la même réponse.

Un manque de contexte. La personne est compétente mais ne comprend pas le métier, donc ses décisions tombent à côté. Cela se corrige vite en l’exposant directement aux utilisateurs.

Un manque de retour. Personne ne lui a jamais dit ce qui n’allait pas, par gêne. C’est le cas le plus fréquent et le plus injuste : on ne peut pas corriger ce qu’on ignore.

Un décalage réel entre le poste et la personne. Il existe, et il vaut mieux le nommer tôt. Une conversation franche à six mois est infiniment plus respectueuse qu’un constat à deux ans.

Dans les trois cas, la même règle : c’est une conversation directe, pas un dispositif. Les processus d’évaluation servent à tracer une décision, jamais à la prendre.

Ce que je regarde pour savoir si une équipe va bien

Trois signaux, plus fiables que n’importe quel entretien annuel.

Les gens posent-ils des questions en public ? Une équipe où l’on n’ose pas dire qu’on n’a pas compris apprend lentement et cache ses problèmes.

Le code de chacun est-il relu par plusieurs personnes ? Si toutes les revues passent par la même personne, il y a un point unique de défaillance — et neuf autres qui n’apprennent pas à relire.

Quelqu’un peut-il partir en vacances trois semaines ? Si la réponse est non pour une personne, ce n’est pas de la compétence : c’est un risque, et il faut le traiter comme tel.