On a doublé l'équipe et rien n'a accéléré - Une histoire de performance

Il y a quelques années, dans une scale-up où j'étais CTO, l'équipe technique a été divisée par deux. Contexte économique compliqué comme pour beaucoup d'entreprises. Sur le papier, c'était une catastrophe.

Sauf que la vélocité n'a pas chuté de moitié. Elle a baissé de 20 %, peut-être encore moins. Les standups étaient plus courts. Les PRs passaient plus vite. Les gens qui restaient savaient exactement quoi faire, et surtout, ils avaient enfin l'espace pour le faire.

Soyons honnête : ce qui a joué, c'est en partie que les bonnes personnes étaient restées. Celles qui faisaient réellement avancer les projets n'avaient pas bougé. Les domaines critiques étaient couverts. Le scope avait diminué. La réduction d'effectif n'avait rien amélioré en soi. Ce qui comptait, c'est qui était resté.

Et ça pose une question plus large : pourquoi certaines personnes pèsent-elles tellement plus que d'autres dans la capacité d'une organisation à livrer ?

Les porteurs

Dans n'importe quelle équipe, il y a deux ou trois personnes sans qui rien ne sort. Celles qui prennent un sujet flou, le découpent, embarquent les autres, poussent jusqu'à la mise en production.

Keith Rabois a mis un nom là-dessus en observant PayPal : sur 254 personnes, 12 à 17 portaient les projets de bout en bout. Il les appelle les barrels. Le reste, c'est de l'ammunition : ceux qui exécutent.

Le ratio est frappant. C'est aussi une heuristique tirée d'une boîte précise à une époque précise. Une fintech des années 2000, une plateforme SaaS B2B et une scale-up e-commerce n'ont pas les mêmes dynamiques. Mais l'intuition tient : dans la plupart des organisations, un petit nombre de personnes porte l'essentiel de la capacité à livrer.

Et « porter » ne veut pas dire la même chose partout. Le Staff Engineer qui sécurise l'architecture porte. L'EM qui débloque son équipe chaque semaine porte. Le PM qui tranche et protège le focus produit porte, sans écrire une ligne de code. Le SRE dont la fiabilité permet à tout le monde de construire sereinement, aussi. Des profils très différents, mais la même fonction : transformer une initiative en résultat.

La capacité réelle d'une organisation, c'est le nombre de ces gens-là. Pas l'effectif total.

Plus de gens, moins de vitesse

Face à un ralentissement, le réflexe est presque toujours le même : recruter. On regarde la roadmap, on compte les features, on divise par une capacité estimée par développeur, et on conclut qu'il faut quinze personnes de plus. Brooks a montré le problème dès 1975 : le coût de coordination croît en n(n-1)/2. Les équipes de 5-7 surperforment systématiquement celles de 15-20 en productivité par tête (QSM, sur des milliers de projets).

Parfois, l'effectif est réellement le goulot. Une équipe plateforme sous-dimensionnée, une couverture 24/7 à assurer, une multiplication de domaines métiers qui exige des compétences nouvelles. Dans ces cas-là, recruter est la bonne réponse.

Mais quand le problème est « on n'avance pas assez vite sur les sujets existants », c'est rarement un problème de bras. Dix développeurs de plus sans personne pour cadrer le projet, le découper, le débloquer quand ça coince : dix personnes qui attendent ou qui partent dans des directions différentes. Le goulot, c'est le nombre de gens capables de porter un sujet de bout en bout.

On ne recrute pas dans un système cassé

Sur une autre mission, j'ai subi une pression forte pour recruter dans une équipe en difficulté. Mon donneur d'ordre ne comprenait pas pourquoi je freinais. L'équipe galérait, donc il fallait plus de monde. Pour lui, c'était évident.

J'ai vu le résultat de cette logique dans un autre contexte : des personnes extérieures ajoutées à une équipe dysfonctionnelle. Elles n'ont pas poussé, ni apporté le regard neuf qu'on espérait. En quelques semaines, elles avaient adopté les mêmes contournements que le reste de l'équipe, les mêmes raccourcis en review, les mêmes sujets qu'on évite en standup. Les moyens étaient là, la bonne volonté aussi. Mais quand le système a des défauts structurels, les nouveaux ne les corrigent pas. Ils les absorbent.

Will Larson appelle ça la dette organisationnelle. On ne recrute pas dans un système cassé en espérant que les nouveaux vont le réparer malgré eux.

Identifier le goulot, pas combler l'effectif

Goldratt l'a posé dans The Goal : le throughput d'un système est limité par un seul goulot à la fois. Optimiser autre chose est du gaspillage. Dans The Phoenix Project, Brent est celui par qui tout passe, celui sans qui rien n'avance. Redistribuer sa charge est le seul levier. Recruter à côté de lui ne sert à rien.

Dans l'équipe que j'ai vue se réduire de moitié, c'est ce qui s'est passé naturellement. Moins de monde, donc moins de projets en parallèle. Ceux qui restaient avaient enfin la bande passante pour mener leurs sujets de bout en bout, sans être interrompus pour coordonner.

Skelton et Pais posent la même idée autrement dans Team Topologies : la vraie contrainte, c'est la charge cognitive, pas le headcount. Quand une équipe est surchargée, il faut réduire la surface, le scope par personne, le nombre de domaines à tenir en tête. Pas ajouter des têtes.

Et souvent, le goulot ne se trouve même pas dans l'engineering. Il est dans la décision produit. Des priorités floues, des arbitrages qui ne se font pas, des dépendances business que personne ne tranche. On peut avoir tous les porteurs techniques qu'on veut : si personne côté produit ne tient la vision et ne protège le focus, l'équipe construit vite des choses qui ne convergent pas.

Fabriquer des porteurs

Les porteurs ne se distinguent pas par leur niveau technique. Ils se distinguent par leur réaction face à l'ambiguïté.

Sur une mission récente, j'avais besoin de porteurs dans une équipe qui en manquait. Plutôt que de recruter directement, j'ai confié un rôle à responsabilité à une dizaine de profils, en rotation. Mêmes conditions, même périmètre, même niveau d'attente.

En quelques semaines, la différence était visible. Certains se sont saisis du rôle : ils découpaient les problèmes d'eux-mêmes, posaient des questions sur le pourquoi pas seulement sur le comment. Ils se sentaient responsables du résultat au-delà de leur bout. D'autres avaient encore besoin d'accompagnement, et c'est normal. Pas un jugement de valeur, un constat de maturité à un instant donné.

Là où certains attendaient des instructions ou escaladaient, ceux-là commençaient à avancer.

Ça prend du temps. C'est moins spectaculaire qu'un recrutement senior qui arrive avec un CV impressionnant. Mais les gens qu'on fait grandir en interne connaissent le contexte, le produit, les dettes. Ils n'ont pas besoin de trois mois d'onboarding. Et surtout, ils ont la confiance de l'équipe. Ça ne se décrète pas.

L'IA ne fabrique pas de porteurs

Tout ça a été observé et théorisé avant que chaque équipe ait accès à l'IA. L'IA ne change pas l'équation. Elle l'aggrave.

Todd Gagne pose une analogie qui aide à y voir clair. Quand l'électricité est arrivée dans les usines au XIXe siècle, les premiers industriels ont remplacé la machine à vapeur par un moteur électrique en gardant la même architecture de production. Le gain a été marginal. Il a fallu repenser entièrement l'organisation des usines pour que l'électricité libère son vrai potentiel.

L'IA, c'est la même histoire. Déployer Copilot ou Cursor sur une équipe qui manque de porteurs, c'est mettre un moteur électrique dans une usine à vapeur. L'IA génère du code, des tests, de la documentation. Mais elle ne sait pas quoi construire, elle ne sait pas prioriser, et elle ne pousse rien en production.

Une équipe sans porteurs armée d'IA produit plus de code que personne n'amène en production. Le résultat, c'est du bruit, pas du débit.

Les porteurs ne se distinguent pas par leur niveau technique. Ils se distinguent par leur capacité à transformer l'incertitude en exécution.

Quand une organisation ralentit, la première question n'est pas : « Combien de personnes nous manque-t-il ? » La première question est : « Qui transforme réellement les sujets flous en résultats concrets ? »

Tant que ces personnes restent le goulot, recruter davantage ne change pas fondamentalement la trajectoire.

Sources

Keith Rabois, How to Operate — Stanford/YC, 2014. Le concept barrels vs ammunition.
Fred Brooks, The Mythical Man-Month, 1975. Le coût de coordination en n(n-1)/2.
Will Larson, Sizing Engineering Teams — et An Elegant Puzzle, 2019. Dette organisationnelle et taille d'équipe.
Eliyahu Goldratt, The Goal, 1984. Theory of Constraints.
Gene Kim et al., The Phoenix Project, 2013. Le personnage de Brent comme goulot humain.
Matthew Skelton & Manuel Pais, Team Topologies, 2019. Charge cognitive comme contrainte réelle.
Todd Gagne, The Barrels Paradox, 2025. L'analogie électricité/IA et pourquoi le jugement humain devient le vrai goulot.