Idée principale

La roadmap porte les fonctionnalités prévues. Les délais y sont visibles, les arbitrages s'y font, les engagements s'y prennent. Les défauts restent à côté, comme une charge implicite qu'on traitera « quand on aura le temps ».

Ils consomment pourtant la même capacité : du temps de développeur au moment de la correction, du temps de support à chaque contournement expliqué, de l'attention produit à chaque relecture de ticket. Et ils consomment ce qui ne se planifie pas — la confiance du client qui rencontre deux fois le même comportement, la crédibilité interne d'une équipe dont on sait que les irritants ne bougent pas.

Ne pas les inscrire ne les rend pas gratuits. Cela les rend invisibles au seul endroit où l'on arbitre.

Couche apportée par « La qualité appartient à ceux qui livrent » (2026-06-03). Le même constat se retourne contre l'objection de planning qu'on oppose à toute règle de qualité : ramener un développeur sur son propre défaut perturbe le sprint, repousse la fonctionnalité suivante, coûte visiblement. La qualité consomme de la capacité, et l'exclure du plan ne la rend pas gratuite — cela retire seulement la dépense du seul endroit où elle se compare aux autres.

Pourquoi c'est important

Cela défait l'opposition entre roadmap et qualité, qui fait passer les fonctionnalités pour le vrai travail et les défauts pour un bruit à gérer autour. Les deux tirent sur le même budget ; un seul est compté.

La question n'est donc pas de trouver du temps pour les défauts, mais de les faire entrer dans le plan où le temps se distribue.

Nuances et limites

Inscrire ne suffit pas. Une file de défauts est une inscription, et elle peut rester indéfiniment sans arbitrage réel.

Et la charge n'est pas uniforme : un défaut jamais rencontré ne consomme rien tant que personne ne le croise.

Questions ouvertes

• Comment chiffrer la charge support d'un défaut avant de l'avoir corrigé ?