Il y a quelques années, j’ai rejoint une équipe après une tentative de migration qui avait échoué.

Le client ne pouvait pas se permettre un nouvel échec, et l’organisation voulait avancer vite. C’était compréhensible. La pression était réelle. Les enjeux étaient élevés. Ce qui m’inquiétait, ce n’était pas l’urgence elle-même, mais la manière dont l’organisation y réagissait.

Quand je suis arrivé, l’équipe avait déjà trop de sujets ouverts. Chaque nouvelle demande avait une bonne raison d’exister. Chaque sujet semblait important. Chaque partie prenante avait un argument rationnel. Pris un par un, la plupart des sujets avaient du sens. Ensemble, ils recréaient exactement les conditions qui avaient fait échouer les tentatives précédentes.

J’ai donc pris une décision qui allait à l’encontre de la réaction attendue à ce moment-là. J’ai arrêté d’ouvrir de nouveaux sujets, et j’ai stoppé certains travaux déjà en cours.

Je ne disais pas non au besoin. Je disais non à la manière dont l’organisation essayait de l’absorber.

Cette distinction compte. Dans ce contexte précis, cette position aurait pu me coûter ma place. Mais continuer à tout accepter aurait été pire. Cela aurait protégé l’apparence de réactivité tout en détruisant la capacité de l’équipe à terminer.

Une fois que nous avons réduit le nombre de sujets ouverts, l’équipe a recommencé à livrer. Ce n’était pas parce que les personnes étaient soudainement plus motivées et ni pas parce qu’elles ont travaillé plus longtemps. Elles ont recommencé à livrer parce que le système leur permettait enfin de terminer ce qu’elles avaient commencé.

Cette expérience a rendu une chose claire pour moi. Changer les priorités n’est pas le vrai problème. Le vrai problème, c’est de changer les priorités sans décider ce qu’elles remplacent.

Le coût d’un oui non financé

Dans les discussions de planification, une nouvelle priorité a souvent l’air presque gratuite. C’est juste un élément de plus, une demande de plus, une exception de plus. L’organisation se raconte que l’équipe pourra probablement l’absorber.

Mais dans le système, le coût ne disparaît jamais.

Thinking in Systems de Donella Meadows est utile ici, parce que le livre nous oblige à regarder au-delà des événements isolés et à prêter attention à ce qui circule dans un système et à ce qui s’y accumule. Dans une organisation engineering, les flux visibles sont faciles à voir. Les demandes arrivent, les tickets avancent, les réunions ont lieu, les roadmaps changent. Les stocks sont plus difficiles à voir. Le travail ouvert s’accumule. Le coût de coordination s’accumule. La dette technique s’accumule. La fatigue s’accumule et la confiance s'érode. La capacité disponible se dégrade.

Quand une nouvelle priorité entre sans arbitrage, la quantité de travail ouvert augmente, mais la capacité de l’équipe à terminer n’augmente pas pour autant. C’est dans cet écart que le ralentissement commence.

Je vois cela comme un oui non financé. L’organisation accepte la priorité, mais personne ne décide où le coût sera absorbé.

Au début, l’équipe peut même sembler plus active. Plus de tickets bougent, plus de personnes sont impliquées, plus de discussions ont lieu. Mais l’activité n’est pas de la capacité, et le travail commencé n’est pas de la valeur livrée. Au bout d’un moment, tout est en mouvement, mais trop peu de choses arrivent réellement au bout.

La capacité n’est pas l’effectif

Une erreur fréquente dans les organisations engineering consiste à traiter la capacité comme une somme de personnes, de jours ou de points de sprint. C’est pratique, parce que c’est facile à compter. C’est aussi trompeur.

Une équipe engineering de six personnes n’a pas toujours la même capacité. Elle peut avoir le même effectif, le même niveau technique apparent et le même nombre de jours disponibles, tout en étant beaucoup moins capable de livrer.

La capacité n’est pas seulement une quantité de temps. C’est une propriété du système.

Elle dépend de la manière dont les décisions, l’information, les contraintes techniques et les personnes interagissent. Avoir de très bons ingénieurs ne suffit pas si les décisions arrivent trop tard. Avoir des priorités claires ne suffit pas si le système technique rend chaque changement risqué. Ajouter des personnes ne suffit pas si les nouvelles personnes rejoignent simplement les mêmes goulots d’étranglement.

C’est pour cette raison que certaines organisations augmentent leurs effectifs sans augmenter leur capacité. Elles ajoutent des personnes à un système déjà fragmenté, surchargé ou techniquement coûteux à faire évoluer. Le résultat n’est pas davantage de valeur livrée. C’est souvent plus de coordination.

La vraie question n’est pas de savoir combien de personnes sont disponibles. La vraie question est de savoir si l’organisation peut transformer une priorité en valeur livrée sans rendre la priorité suivante plus difficile à absorber.

La bonne volonté n’est pas une stratégie

Quand les priorités ne sont pas correctement financées, les organisations utilisent souvent une autre ressource sans la nommer. La bonne volonté.

Les personnes absorbent le changement. Elles restent tard. Elles font en sorte que ça passe. Elles protègent l’organisation des conséquences de son propre manque d’arbitrage.

Cela peut arriver une fois, pendant une vraie urgence. Le problème commence quand cela devient le modèle opérationnel.

Quand chaque nouvelle priorité dépend de l’engagement personnel, l’organisation ne finance pas ses décisions. Elle transfère le coût aux personnes.

Ce coût n’est pas théorique. L’Engineering Leadership Report 2025 de LeadDev a montré que parmi plus de 600 développeurs et responsables engineering interrogés, 22 % déclaraient des niveaux critiques de burnout, tandis que 24 % déclaraient un burnout modéré. Le même article indique que 65 % des développeurs et engineering leaders interrogés ont vu leurs responsabilités s’élargir, et que 40 % des engineerings leaders ont déclaré que leurs équipes étaient moins motivées qu’un an auparavant.

Source : LeadDev, Burnout is on the rise as layoffs reshape the tech industry.

C’est pour cela que la discussion sur la vitesse ne peut pas être réduite à la discipline d’exécution. Quand une organisation continue à demander aux équipes d’absorber plus avec le même système, elle peut préserver l’illusion de vitesse pendant un certain temps, mais elle consomme souvent de l’énergie, de la confiance, du focus, de la qualité, de la rétention et de la capacité future.

Une priorité doit être financée

Une priorité n’a pas besoin d’être rejetée pour être traitée correctement. Mais elle doit être financée.

Financer une priorité signifie décider, au moment où elle entre dans le système, comment l’organisation va l’absorber. Parfois, cela signifie arrêter quelque chose. Pas prétendre que le sujet reste vivant quelque part, mais réellement l’arrêter. Parfois, cela signifie reporter quelque chose, avec une place claire dans le temps plutôt qu’une promesse vague. Parfois, cela signifie réduire le périmètre sans dégrader silencieusement la qualité. Parfois, cela signifie accepter un risque, mais le nommer clairement.

Le risque lui-même n’est pas toujours le problème. Le problème, c’est de prendre le risque sans dire qui l’a choisi.

C’est là que le leadership engineering compte. Le rôle n’est pas seulement de répondre à la question de savoir si l’équipe peut essayer. Le rôle est de rendre le compromis explicite. Si ce sujet entre maintenant, qu’est-ce que nous arrêtons, déplaçons, réduisons ou risquons ?

Cette discussion doit avoir lieu au moment où la décision est prise. Pas trois semaines plus tard, quand le système a déjà absorbé le coût en silence.

Déplacer la capacité, ce n’est pas créer de la capacité

Il y a une autre distinction importante. Déplacer de la capacité n’est pas la même chose que créer de la capacité.

Déplacer de la capacité signifie prendre du temps, de l’attention ou des personnes à un endroit pour faire passer une priorité ailleurs. Parfois, c’est nécessaire. Mais si c’est le seul mouvement que l’organisation sait faire, elle ne devient pas plus capable. Elle ne fait que redistribuer une capacité limitée.

Créer de la capacité, c’est différent. Cela signifie améliorer la manière dont le système fonctionne afin que la priorité suivante soit plus facile à absorber. Cela peut vouloir dire réduire le coût de livraison, clarifier la prise de décision, accroître l’autonomie des personnes, améliorer l’outillage, réduire les frictions techniques, renforcer les boucles de feedback ou rendre le travail plus facile à terminer.

Le point important, c’est que la création de capacité ne concerne pas seulement la priorité actuelle. Elle change les conditions de la suivante.

Une organisation qui veut rester rapide ne peut pas seulement demander ce qu’elle doit livrer maintenant. Elle doit aussi demander ce que la décision actuelle est en train de consommer, et ce qui doit être reconstruit pour que le prochain changement soit plus facile à absorber.

Sans cette deuxième question, l’organisation peut livrer la priorité actuelle tout en rendant la suivante plus difficile. C’est ainsi que la vitesse se dégrade. Progressivement, puis soudainement.

Rendre le compromis visible

Cette trace n’a pas besoin d’être un document de dix pages. Elle n’a pas besoin de devenir un nouveau processus. Mais elle doit exister.

Au minimum, l’organisation doit pouvoir voir ce qui entre, ce qui est arrêté ou déplacé, quel risque est accepté et ce qui devra être reconstruit ensuite. Cela suffit à créer une compréhension partagée entre le produit, le business et l’engineering.

Mais une trace ne sert à rien si personne n’y revient. C’est pour cela qu’une date de revue est importante. Pas pour faire du reporting, mais pour vérifier que ce qui était censé être temporaire est bien resté temporaire.

Sans revue, une dette temporaire devient une dette permanente. Un effort supplémentaire temporaire devient la nouvelle baseline. Une exception ponctuelle devient le modèle opérationnel.

La question à poser avant de demander plus de vitesse

« Si cette priorité entre maintenant, qu’arrêtons-nous, que déplaçons-nous, que réduisons-nous ou quel risque acceptons-nous explicitement ? »

Si votre équipe ralentit alors que l’organisation continue à demander plus de vitesse, commencez par anal le travail ouvert. Regardez ce que l’équipe traite actuellement et demandez-vous si chaque sujet a encore une raison claire d’être actif maintenant.

Ensuite, rouvrez la discussion avec le business et le produit. C’est souvent là que vous découvrirez les compromis qui n’ont jamais vraiment été faits.

À partir de là, reprenez le contrôle. Arrêtez, déplacez ou réduisez le périmètre quand c’est nécessaire. Pour chaque nouvelle priorité, rendez visible ce qu’elle remplace, le risque qu’elle crée et ce qui doit être reconstruit.

Puis choisissez une action concrète pour recréer de la capacité. Pas cinq. Une.

Il ne s’agit pas du confort de l’équipe. Il s’agit de la capacité de l’organisation à continuer à changer ses priorités sans casser sa capacité à livrer.

Podcast audio : Vous exigez de la vitesse, Alors pourquoi tout ralentit ?