Faire grandir une équipe tech : recruter sans allonger la file d’attente

Le réflexe est toujours le même. Les livraisons glissent, l’équipe dit qu’elle est débordée, et le dirigeant ouvre un poste. C’est la seule action visible qu’il ait sous la main : un recrutement, ça se budgète et ça se raconte au conseil. Six mois plus tard, l’équipe compte deux personnes de plus et livre à peine davantage. Parfois moins.

Une équipe ne grandit pas en recrutant. Elle grandit en déléguant des décisions, et le recrutement n’est que la conséquence de cette délégation. Chaque arrivée coûte avant de rapporter : du temps de ceux qui sont déjà là, des revues en plus, des questions qui convergent vers les mêmes trois personnes. Si vous n’avez pas décidé qui décide avant d’embaucher, vous n’ajoutez pas de la capacité. Vous ajoutez de la file d’attente.

J’ai vécu ce passage chez Ipedis, de lead dev à CTO, pendant que l’équipe produit passait de 5 à 25 personnes. Voici ce que j’en ai gardé.

PubliSpeak est né comme une preuve de concept. J’ai construit la V1, et le monolithe qui en est sorti a tenu jusqu’au moment précis où l’équipe a commencé à grossir. Ce n’est pas un hasard. À cinq, tout le monde touche à tout sans se marcher dessus. Au-delà, chaque fonctionnalité nouvelle rendait la mise en production plus risquée, pour des clients qui dépendaient de la plateforme au quotidien.

Nous avons donc mené les deux chantiers en même temps, parce qu’ils n’en faisaient qu’un. Côté technique, une migration incrémentale vers dix microservices, domaine métier par domaine métier, avec un bus événementiel RabbitMQ pour que les équipes cessent de dépendre les unes des autres à chaque déploiement. Pas de big bang, aucune interruption de service. Côté humain, le recrutement et la structuration en parallèle : responsabilités réparties, intégration structurée, montée en compétences continue.

La leçon tient en une phrase. Découper l’architecture et découper l’organisation, c’est la même décision : fixer ce que chacun peut changer seul et ce qui oblige à aller voir quelqu’un. Une équipe qui se coordonne pour la moindre fonctionnalité n’est pas trop petite. Ses frontières sont au mauvais endroit.

À cinq, votre meilleur développeur écrit du code, relit celui des autres, choisit les outils et répond à vos questions. Ça marche. À vingt-cinq, cette même personne est le goulot de toute l’entreprise. Elle le sait. Et elle ne lâchera rien, parce que personne ne lui a dit quoi lâcher.

Avant de recruter, posez la question qui fâche : qui porte l’architecture, qui conduit chaque équipe, qui arbitre les priorités, qui recrute ? Tant que la réponse est « lui » pour les quatre, vous n’avez pas une équipe. Vous avez une personne et des assistants.

C’est là qu’apparaît le lead dev. Il rend une équipe efficace dans un cadre : il découpe le travail, organise les revues, signale ce qui bloque. Le CTO fixe ce cadre avec vous. La différence est dans CTO ou lead dev. Ce que je retiens ici : nommer un lead dev sans lui retirer du code et sans lui confier de vraies décisions, c’est distribuer un titre à quelqu’un qui garde toute sa charge.

Puis découpez selon le produit, pas selon les compétences. Une équipe front et une équipe back se coordonnent pour chaque écran. Une équipe qui tient un périmètre métier de bout en bout livre seule. Si la plupart des changements demandent l’accord de trois équipes, ne recrutez pas. Déplacez les frontières.

Chez Gridky, j’ai demandé à un candidat s’il écrivait des tests automatisés. Non, m’a-t-il répondu, mais une demande à l’IA suffirait à en générer. Il croyait sincèrement bien répondre, et c’est ce qui m’a inquiété : il ne savait pas ce qu’un test protège, ni pourquoi on l’écrit. Il ne candidatait pas comme développeur. Il candidatait comme relais entre ma demande et un agent qui code.

J’appelle ça le candidat proxy, et vous allez en voir de plus en plus. Produire du code est devenu une commodité. Ce que j’achète, c’est quelqu’un qui comprend chaque enjeu du code qu’il livre, qu’il l’ait tapé ou non. Le test à la maison reste utile à une condition : on n’y évalue plus le code, on y évalue les choix, sur six points :

• la sécurité
• la performance
• les cas marginaux
• les choix d’architecture
• la gestion des erreurs
• la compréhension et la restitution de la demande initiale

Générer des tests avec une IA ne répond pas à ma question. La question est : sait-il les lire, les contester, et stabiliser dans la durée un projet aux règles métier fortes ?

Ensuite, sachez ce que vous achetez. Je ne recrute pas un junior pour lui confier seul les arbitrages d’architecture. Je lui dois de l’accompagnement et des décisions qu’il peut prendre à son niveau. Un senior arrivera avec une opinion forte sur votre projet, et c’est pour ça que vous le payez, à condition d’avoir décidé avant son arrivée qui tranche un désaccord. Sinon vous aurez payé cher pour un conflit.

Enfin, le rythme. Recrutez par petites vagues, quelques personnes à la fois, espacées. Une grande vague a l’air d’une décision forte. En pratique elle disperse ceux qui accompagnent, et l’équipe passe un trimestre à intégrer au lieu de livrer. Et ne faites pas traîner la sélection : les bons signent ailleurs pendant que vous délibérez.

Le jour où quelqu’un arrive, votre capacité baisse. Il faut lui expliquer le produit, lui ouvrir des accès, relire ses premières contributions, répondre à ses questions, et ces questions tombent précisément sur les personnes qui formaient déjà le goulot. Ce que l’on ne lui dit qu’à l’oral sera redit au suivant. Une équipe qui n’écrit rien paie chaque arrivée au prix fort.

Ma règle : chaque arrivant a un buddy, une personne vers qui se tourner pour tout, et un buddy n’accompagne jamais plus de deux arrivants à la fois. Cette règle a une vertu cachée : elle fixe la taille de la vague. Deux buddies disponibles, et vous ne recrutez pas six personnes ce mois-ci, quoi qu’en dise le plan.

L’intégration est un processus, et un processus se teste : l’environnement de développement, le vocabulaire métier, qui répond à quoi, et une première modification réelle, petite, livrée en production. Puis demandez au nouvel arrivant ce qui manquait. Il est le seul à voir encore ce que tout le monde suppose acquis. Dans un mois, il ne le verra plus.

Et tracez les accès : qui a reçu quoi, quand, pour quoi faire. Sans cette trace, chaque arrivée ouvre des portes que l’on oubliera, et chaque départ en laisse une entrouverte. J’ai décrit le même mécanisme pour les outils dans les accès qui survivent aux outils : l’usage s’arrête, l’accès demeure. Car une équipe qui grandit connaît aussi des départs. Des accès tracés permettent de refermer au départ ce que l’on a ouvert à l’arrivée.

Vous la connaissez. Elle seule sait comment fonctionne la facturation, ou le déploiement. Les questions convergent vers elle, ses revues sont obligatoires, ses vacances bloquent les livraisons. Tout le monde le sait. Personne ne le règle.

Je me méfie de l’explication par la mauvaise volonté. Il arrive que les urgences ne laissent simplement aucun temps pour transmettre. Il arrive aussi qu’être indispensable soit devenu une place que la personne ne sait plus comment quitter. Demander de « documenter » sans dégager de temps ni discuter de la suite ne traite aucun de ces deux cas.

Commencez donc par une carte. Pour chaque partie du système, trois noms : qui peut la modifier, la déployer, la réparer en pleine nuit. Les zones à un seul nom sont vos vraies urgences, bien avant la prochaine fiche de poste. Binômez dessus, faites tourner les revues, et faites écrire la documentation par quelqu’un d’autre que l’expert : lui au moins saura ce qu’il n’a pas compris.

Et donnez à l’indispensable autre chose à être : la conduite d’un domaine, l’accompagnement des nouveaux, l’architecture d’ensemble. Vous ne lui retirez pas sa place, vous lui en offrez une plus grande, et c’est la seule manière que j’aie vue fonctionner.

Quand une équipe de quinze livre moins vite qu’une équipe de huit, je commence par regarder ce qui attend : la relecture, les tickets, le déploiement. Chacun de ces passages protège la qualité. Chacun devient un entonnoir dès que l’équipe grandit plus vite que le nombre de gens capables de l’assurer.

La revue de code d’abord. Si deux personnes relisent tout, chaque recrutement allonge leur file. Répartissez la relecture, écrivez ce qu’une revue doit vérifier, faites relire les nouveaux tôt. Les tickets ensuite. Si une seule personne rédige toutes les demandes, l’équipe attend son travail. Donnez à chaque équipe le droit d’écrire les tickets de son périmètre. Le déploiement enfin. Il ne devrait dépendre ni d’une personne ni d’un créneau. J’ai raconté ce que coûte cette attente dans une correction terminée mardi et livrée la semaine suivante.

Les réunions suivent la même pente : chaque palier de croissance en ajoute, presque aucune n’est retirée. Gardez celles qui produisent une décision ou lèvent un blocage. Le reste se remplace par un écrit.

Un signal ne trompe pas : si le temps d’attente augmente avec l’effectif, un processus n’a pas suivi. Si les développeurs coordonnent plus qu’ils ne produisent, une réunion est de trop ou une frontière est mal placée. Lire ce ralentissement dans les tickets et les métriques de livraison est le sujet de l’article sur la santé d’une équipe de développement.

Je ne jugerais jamais la croissance d’une équipe à son effectif. Seulement à ce qu’elle livre, comparé à avant. Le radar de santé d’équipe ouvre une autre lecture : les mêmes questions à la direction et à l’équipe pour voir où leurs perceptions divergent. Ce ne sont pas des mesures de livraison.

Avant chaque vague, je répondrais par écrit à quatre questions :

• pourquoi ce poste, quel profil, quelle séniorité
• quel buddy pour chaque arrivant, deux au plus par buddy, et qui écrit ce qui se dit à l’oral
• quels accès seront ouverts, et où ils seront tracés
• quelle revue va saturer la première : le code, les tickets ou le déploiement

Si une réponse manque, je préciserais ce qu’elle empêche de préparer avant de fixer la date d’arrivée. Un recrutement peut justement apporter la capacité de revue ou de transmission qui manque. La décision dépend alors du temps d’accompagnement disponible et du coût d’attendre, pas d’un délai imposé à chaque embauche.

Le rythme d’Ipedis ne convient peut-être pas à votre marché. Je garderais cette exigence : savoir quelles décisions le poste permettra de répartir et qui accompagnera l’arrivée, plutôt que de compter seulement une personne de plus. La page sur l’organisation de l’équipe technique prolonge ces questions. Et si personne chez vous ne peut porter ces arbitrages pendant que l’équipe grandit, c’est le travail que je fais comme CTO à temps partagé, sur une durée convenue.