Piège 4 - Les personnes

Neuf femmes, un mois

Le programme a trois mois de retard. Le sponsor a une idée, et elle semble relever du bon sens : « Doublons l’équipe. »

Vingt nouvelles personnes arrivent en six semaines. Il leur faut des ordinateurs, des accès, un onboarding et quelqu’un pour leur expliquer le système. Ce quelqu’un est, bien sûr, l’une des rares personnes qui le connaissent vraiment. Les réunions s’allongent. Les questions se multiplient. Les ingénieurs les plus expérimentés arrêtent de coder et commencent à expliquer.

Trois mois plus tard, le programme a cinq mois de retard.

Fred Brooks l’a observé chez IBM dans les années 1960 et l’a écrit dans The Mythical Man-Month : ajouter des personnes à un projet logiciel en retard le retarde davantage. Son image est restée avec chaque génération d’ingénieurs depuis : neuf femmes ne font pas un bébé en un mois.

Cinquante ans plus tard, je vois encore la même décision prise en comité de pilotage presque chaque année. Pas parce que les gens n’ont pas lu Brooks, mais parce qu’ajouter des personnes est le seul levier que tout le monde sait actionner.

Les personnes ne sont pas de la capacité

Regardez comment la plupart des programmes parlent des personnes. « Il nous faut quatre ETP de plus. » « La capacité est insuffisante au T3. » « Peut-on emprunter deux développeurs à l’autre chantier ? » Le vocabulaire dit tout : les personnes sont comptées comme des unités de production, déplaçables et interchangeables.

Mais un programme ne se construit pas avec des effectifs. Il se construit avec un petit nombre de personnes qui comprennent le problème, se font confiance et savent à qui demander. Ce savoir, cette confiance et ce contexte prennent des mois à se construire et quelques minutes à se détruire.

Les personnes impliquées dans ce piège sont rarement négligentes. Les sponsors subissent une vraie pression. On demande aux managers de livrer avec les personnes qu’ils ont. Les processus RH sont conçus pour le régime de croisière, pas pour un programme qui monte en charge en trois mois. Chaque décision a un sens localement. Ensemble, elles transforment une équipe en tableau d’affectation.

C’est cela, le piège humain : gérer les personnes comme une capacité à allouer, plutôt que comme des équipes à construire, à faire grandir et à garder.

Les dix visages du piège

En 25 ans, je l’ai vu prendre dix formes, en trois familles : qui rejoint le programme, comment on l’organise, et comment on le dirige. La plupart des programmes en difficulté en présentent quatre ou cinq.

Qui rejoint

• Neuf femmes, un mois. Des personnes ajoutées tard, quand le programme est déjà en retard. Chaque nouvel arrivant ralentit les experts avant d’accélérer quoi que ce soit.
• Staffer selon les disponibilités. L’équipe est composée de ceux qui étaient libres, pas de ceux dont on avait besoin. Le programme récupère les personnes que personne d’autre n’a demandées, puis s’étonne des résultats.
• Recruter dans l’urgence. Le plan de montée en charge exige trente personnes d’ici juin. Les entretiens raccourcissent, la barre baisse discrètement, et l’onboarding devient « lis le wiki ». Un mauvais recrutement fait en une semaine prend un an à défaire.
• La réflexion externalisée. L’intégrateur conçoit, construit et comprend le système. L’équipe interne gère le contrat. Quand le contrat se termine, le savoir part avec lui, et l’entreprise possède un système qu’elle ne sait pas expliquer.

Comment on l’organise

• Conway ignoré. Melvin Conway a observé en 1968 que les systèmes reflètent la structure de communication des équipes qui les construisent. Dessinez les équipes d’une façon et l’architecture d’une autre, et l’organigramme gagne à chaque fois.
• Le héros. Une personne sait comment le système critique fonctionne vraiment, répond à chaque escalade et travaille chaque week-end. Tout le monde l’admire. Personne ne remarque que le programme dépend désormais de la santé et de la bonne volonté d’une seule personne.
• Des personnes découpées en pourcentages. Trente pour cent sur ce programme, quarante sur celui-là, le reste sur le run. Deux managers, trois stand-ups, pas de vraie équipe. Chaque tranche paie le coût complet du changement de contexte.

Comment on le dirige

• Le changement culturel par note de service. Une transformation agile est annoncée, les valeurs s’affichent sur des posters, de nouveaux intitulés de poste apparaissent. Le processus budgétaire, la chaîne d’approbation et le comportement des dirigeants restent exactement les mêmes. Les gens croient ce que font les dirigeants, pas ce qu’ils disent.
• Le meilleur ingénieur devient manager. Le programme perd son ingénieur le plus solide et gagne un manager sans formation, sans soutien et sans temps. Les deux métiers en souffrent, et la personne aussi.
• Le management par la pression. Les échéances sont imposées d’en haut, les erreurs sont punies, et les questions sont vues comme de la résistance. Les gens arrêtent de remonter les problèmes, arrêtent de proposer des idées, et finissent par ne plus s’en soucier.

Construire une équipe, c’est comme épouser dix personnes

Ces dix visages ne sont que les plus courants. Les pièges humains prennent une myriade d’autres formes, parce qu’une équipe est un ensemble de relations, pas une liste de compétences.

Pensez au mariage. Deux personnes qui se sont choisies, partagent les mêmes valeurs et veulent le même avenir ont encore besoin d’années pour apprendre à vivre ensemble. Imaginez maintenant épouser dix personnes à la fois, choisies par quelqu’un d’autre, avec la date du mariage déjà fixée et la séparation prévue à la mise en production. C’est ce qu’un programme demande à son équipe. Dix personnes forment 45 relations, et chacune d’elles doit fonctionner.

Pourtant, nous choisissons les membres d’une équipe sur CV et grilles de compétences, et n’investissons presque rien pour faire fonctionner les relations. Le psychologue Bruce Tuckman a décrit en 1965 comment les groupes traversent quatre étapes : forming, storming, norming et, enfin, performing. Chaque remaniement renvoie l’équipe au départ.

Quelques autres visages rencontrés en chemin :

• L’adéquation culturelle, mal faite. Bien faite, l’adéquation culturelle signifie des valeurs partagées : l’honnêteté, le soin des utilisateurs, le sens des responsabilités. Mal faite, elle signifie recruter des gens qui nous ressemblent, pensent et parlent comme nous. L’équipe se sent à l’aise, et ses angles morts grandissent. Recrutez pour l’adéquation des valeurs et l’apport culturel, pas pour des clones.
• Le mauvais état d’esprit pour le moment. Des explorateurs qui adorent construire à partir de zéro, placés dans un programme qui a besoin d’une migration minutieuse. Ou des gardiens de la stabilité, placés dans un programme qui doit inventer. Aucun des deux états d’esprit n’est mauvais ; il est au mauvais endroit.
• Le mariage forcé. Des internes, deux intégrateurs et un groupe de freelances sous un même badge de programme, chacun avec ses propres contrats, incitations et loyautés. Un partenaire payé à la journée et un salarié jugé sur la livraison ne ressentent pas la même échéance.
• Jamais sorti du storming. Les personnes tournent chaque trimestre, donc l’équipe passe toute sa vie à apprendre à se connaître et n’atteint jamais l’étape du performing.
• Le génie toxique. Un très bon élément dont le comportement fait fuir les autres, toléré parce qu’« on ne peut pas se permettre de le perdre ». Le programme en perd trois à la place.
• Les incitations locales. Chaque équipe est récompensée sur ses propres objectifs. Personne n’est récompensé pour l’intégration, les risques partagés ou l’aide apportée à un voisin.
• L’équipe qui ne s’est jamais rencontrée. Répartie sur plusieurs sites et fuseaux horaires, sans aucun moment pour construire la confiance en personne. Chaque désaccord devient un ticket.
• La falaise de fin de programme. Six mois avant la mise en production, les meilleurs commencent à chercher leur prochain poste, parce que personne ne leur a dit ce qui viendrait après. Le savoir part exactement quand on en a le plus besoin.
• La ligne d’arrivée qui recule. La date de mise en production bouge, puis bouge encore : chaque trimestre, parfois chaque mois, chaque nouvelle date annoncée avec la même conviction que la précédente. Après le premier glissement, les gens poussent plus fort. Au troisième, ils ne croient plus à aucune date. Ils arrêtent de sprinter vers l’échéance et commencent à gérer leur effort pour une course sans fin. L’engagement ne meurt pas en une annonce ; il s’érode un peu à chaque échéance que personne n’a choisie et que personne n’a expliquée. Les meilleurs, qui ont besoin d’un objectif réellement atteignable, partent en premier. (Le piège de la planification traite du remède côté plan : des fourchettes plutôt que des dates.)

Aucun de ces visages n’exige un recrutement parfait pour être corrigé. Ils exigent quelqu’un qui traite la construction d’équipe comme un vrai travail, avec du temps, de l’attention et du budget, comme n’importe quel autre livrable : des rituels partagés dès le premier jour, une réponse claire à « que vais-je devenir après la mise en production ? », et le courage de se séparer des personnes dont le comportement casse l’équipe.

L’arithmétique des personnes

L’intuition de Brooks repose sur une arithmétique simple. Dans une équipe de $n$ personnes, le nombre de canaux de communication possibles est :

Dix personnes ont 45 canaux. Vingt en ont 190. Cinquante en ont 1 225. Le travail croît avec l’effectif ; la coordination croît beaucoup plus vite.

Le deuxième coût est le savoir. Le vrai savoir-faire d’un programme n’est pas dans ses documents. Il est dans la tête des personnes qui ont pris les décisions, débogué les incidents et se souviennent de pourquoi les choses sont comme elles sont. Chaque départ en emporte une partie, et chaque nouvel arrivant a besoin de mois avant de devenir pleinement productif.

Le troisième coût est celui que les programmes remarquent en dernier : l’attrition. Les bonnes personnes quittent les programmes qui les traitent comme de la capacité, et elles partent en premier, parce qu’elles ont des options. Quand elles partent, elles emportent leur savoir et une partie du moral de l’équipe. Le programme recrute alors des remplaçants dans l’urgence, et le cycle recommence.

Le plus cruel : rien de tout cela n’apparaît dans le budget. Cela apparaît sous la forme de « problèmes de productivité », de « manques de compétences » et de « risques de livraison », longtemps après les décisions qui les ont causés.

Signaux précoces

On peut sentir le piège humain bien avant qu’il n’apparaisse dans les chiffres :

• On parle des personnes en ETP et en pourcentages, rarement par leur nom.
• La réponse à chaque retard est « il nous faut plus de monde ».
• Un même nom revient dans chaque escalade.
• Les nouveaux arrivants mettent plus d’un mois à livrer leur premier changement.
• Personne dans l’équipe interne ne pourrait faire tourner le système sans le fournisseur.
• La plupart des personnes appartiennent à deux ou trois programmes à la fois.
• La transformation a un slogan, mais le processus d’approbation n’a pas changé.
• Les nouveaux managers ont été promus le vendredi et managent le lundi, sans formation.
• Les gens ont cessé de poser des questions en réunion.
• Les meilleurs partent, et les entretiens de sortie disent « opportunité ailleurs ».
• La date de mise en production a changé trois fois en un an, et personne ne réagit quand elle change encore.
• Les agents produisent plus de changements que l’équipe ne peut en relire, et le temps de relecture ne cesse de diminuer.

Comment construire des équipes qui livrent

La réponse n’est pas un nouveau processus RH. C’est de traiter l’équipe comme le premier produit que l’on construit, et de la protéger comme l’actif le plus précieux du programme.

Staffing et recrutement

1. Staffer tôt, ou pas du tout. Constituez l’équipe cœur avant le début de la construction, et gardez-la stable. Si un programme en retard a besoin d’aide, ajoutez quelques experts pour lever un goulot d’étranglement précis, jamais une foule.
2. Staffer pour le travail, pas depuis le banc. Nommez les cinq ou six rôles sans lesquels le programme ne peut pas réussir, et battez-vous pour y placer les bonnes personnes. Le reste peut suivre.
3. Recruter lentement, intégrer délibérément. Des entretiens structurés, une mise en situation réaliste et au moins deux avis indépendants. Puis un parrain, un ordinateur prêt et des accès dès le premier jour, et un premier changement en production dans la première ou la deuxième semaine.
4. Garder la réflexion en interne. Les partenaires peuvent construire, mais les internes doivent posséder l’architecture, les décisions clés et le savoir. Faites travailler en binôme les ingénieurs internes avec ceux du fournisseur, et inscrivez le transfert de connaissances dans le contrat, avec des jalons.

Organisation

5. Concevoir les équipes et l’architecture ensemble. Façonnez les équipes autour du système que vous voulez, pas de l’organigramme que vous avez : la « manœuvre de Conway inverse » décrite dans Team Topologies. Des équipes stables qui possèdent une capacité de bout en bout battent les escouades projet assemblées à chaque version. Avec des agents dans l’équipe, décidez délibérément qui cadre le travail et qui le vérifie.
6. Mettre le héros à la retraite, avec bienveillance. Remerciez-le, puis diffusez ce qu’il sait : binômage, rotation d’astreinte, runbooks écrits. Visez au moins deux personnes capables de gérer chaque système critique.
7. Une personne, une équipe principale. Au plus deux affectations par personne, dont une clairement principale. La concentration est une décision de management, pas une vertu personnelle.

Leadership et culture

8. Changer la culture par les systèmes et les comportements. La culture, c’est ce que font les dirigeants et ce que l’organisation récompense. Changez le modèle budgétaire, la chaîne d’approbation et la façon dont les dirigeants réagissent aux mauvaises nouvelles, et la culture suit. Commencez petit et rendez les premières victoires visibles.
9. Faire grandir les managers délibérément. Proposez une vraie filière d’expertise technique, pour que les meilleurs ingénieurs n’aient pas à manager pour progresser. Ceux qui choisissent le management reçoivent une formation, un mentor et des entretiens individuels réguliers avec leur propre manager.
10. Construire la sécurité psychologique. Le Project Aristotle de Google a montré qu’elle était le meilleur prédicteur de l’efficacité d’une équipe. Les dirigeants montrent l’exemple : ils admettent leurs erreurs, sollicitent le désaccord, mènent des post-mortems sans recherche de coupable, et ne punissent jamais le messager.

Et mesurez la santé de l’équipe comme la livraison : l’attrition, le temps d’intégration, le nombre de personnes par système critique et un court sondage régulier. Ce qui est mesuré est protégé.

Ce qu’il faut éviter

• Ajouter une foule à un programme en retard.
• Baisser la barre de recrutement pour tenir une date de montée en charge.
• Laisser le fournisseur posséder le savoir de vos systèmes cœur.
• Un organigramme dessiné sans regarder l’architecture.
• Célébrer les héros au lieu de corriger le système qui a besoin d’eux.
• Annoncer un changement culturel que les dirigeants ne vivent pas.
• Promouvoir des personnes au management sans les préparer.
• Traiter les questions et les mauvaises nouvelles comme de la résistance.
• Annoncer une nouvelle échéance sans dire ce qui a changé et sur quoi repose la nouvelle date.
• Supprimer des relecteurs et des testeurs parce que « ce sont les agents qui écrivent le code maintenant ».

Le tournant de l’IA : des équipes plus petites, de nouvelles formes

L’IA n’ajoute pas seulement de la capacité à une équipe. Elle change ce qu’est une équipe : qui fait quoi, combien de personnes il faut, et comment le travail circule entre elles. Les programmes qui greffent des agents sur l’organigramme de la décennie passée tomberont dans le piège humain plus vite que jamais.

Les rôles se compressent

Les frontières entre les métiers se dissolvent. Les product managers prototypent des écrans fonctionnels. Les designers livrent du code front-end. Les ingénieurs écrivent la spécification, les tests et la documentation avec leurs agents. Dans une enquête de Figma, plus de la moitié des répondants disaient prendre en charge des tâches hors de leur périmètre habituel.

La bonne nouvelle est réelle : moins de rôles, c’est moins de passages de relais, et la course de relais du Piège du gaspillage raccourcit. Mais la compression sans refonte crée trois nouveaux visages du piège :

• Tout le monde peut, personne ne possède. Quand n’importe qui peut toucher n’importe quelle partie du travail, personne n’est responsable de sa qualité, de sa sécurité ou de son accessibilité. Les tâches partagées ont toujours besoin de propriétaires nommés pour les résultats.
• Large mais superficiel. Un généraliste avec de bons agents atteint 80 % de la réponse presque partout. Les 20 % restants (performance, sécurité, données, réglementation) sont là où les programmes échouent, et ils exigent toujours de la profondeur. Gardez des spécialistes, et partagez-les entre équipes comme références plutôt que comme points de passage obligés.
• Trois métiers, un seul intitulé. Une personne porte désormais les décisions que trois rôles se partageaient, avec le même intitulé, le même salaire et aucune formation. Le travail va plus vite ; la personne s’épuise.

Des équipes deux pizzas aux équipes sandwich

Amazon dimensionnait célèbrement ses équipes pour qu’elles puissent être nourries avec deux pizzas. Avec des agents qui font une grande partie de la construction, l’équipe qui livre une capacité peut être encore plus petite, et elle prend une nouvelle forme. Je l’appelle l’équipe sandwich : des humains de chaque côté, des agents au milieu.

L’idée s’appuie sur le workflow du « sandwich IA », où les humains cadrent une tâche, l’IA produit, et les humains relisent. L’équipe sandwich l’applique à l’équipe elle-même, avec une règle : la garniture peut grossir, mais le pain doit la tenir. Cela tourne mal de trois façons :

• Trop de garniture. Les agents produisent plus de changements que la tranche du dessous ne peut réellement vérifier. La relecture devient un tampon automatique, et le risque passe silencieusement en production. (La revue de code au rythme de l’IA explique comment proportionner l’examen au risque.)
• Pas de pain dessous. Les relecteurs sont les premiers supprimés, parce que « ce sont les agents qui écrivent le code maintenant ». La qualité et la sécurité reposent alors sur l’espoir.
• Pain du dessus trop fin. Une intention vague, des spécifications floues, des contraintes non dites. Les agents ne lèvent pas l’ambiguïté ; ils l’amplifient à la vitesse de la machine.

La loi de Conway s’applique aussi au sandwich : le système reflétera l’endroit où se trouvent les humains. Si personne n’est dans la tranche du dessous, personne ne possède la production.

Ce qui ne change pas

La loi de Brooks s’applique aussi aux agents. Dix agents qui écrivent du code créent dix flux de changements à relire, intégrer et comprendre. Le goulot d’étranglement passe de l’écriture au jugement, et le jugement dépend toujours des quelques personnes qui connaissent vraiment le système.

La tranche du dessous a aussi un problème d’approvisionnement caché. Les ingénieurs juniors apprennent en faisant le travail simple que l’IA fait désormais instantanément. Bien vérifier demande une expérience acquise en construisant. Si les juniors ne déboguent jamais, ne se battent jamais avec une conception, ne possèdent jamais un petit système, d’où viendront les relecteurs de 2035 ? Les programmes qui se soucient du long terme donneront délibérément de vraies responsabilités aux juniors, avec l’IA comme tuteur plutôt que comme remplaçant.

Et il y a une vraie aide. L’IA peut raccourcir considérablement l’onboarding : un nouvel arrivant peut interroger la base de code, les fiches de décision et les runbooks dès le premier jour. Elle peut aussi capturer ce que savent les héros, si quelqu’un prend le temps de leur demander.

Les programmes, ce sont des personnes

Les meilleurs programmes sur lesquels j’ai travaillé n’avaient pas les plus grandes équipes. Ils avaient des équipes stables qui se connaissaient, des dirigeants qui les protégeaient, et assez de confiance pour que les mauvaises nouvelles circulent vite. Chaque succès dont je suis fier est en réalité une équipe dont je suis fier.

Alors la prochaine fois que quelqu’un propose d’ajouter des personnes, posez d’abord une question en douceur : auprès de qui vont-elles apprendre, et qu’est-ce que cette personne va cesser de faire ? La réponse change généralement la décision.

Quelle est la meilleure équipe dont vous avez fait partie, et qu’est-ce qui la faisait fonctionner ? J’aimerais sincèrement entendre votre histoire.

Toutes les situations décrites ici sont des composites, tirés de nombreux programmes sur 25 ans.