Idée principale

Le schéma est répandu : un développeur livre une fonctionnalité, passe au sujet suivant, et les défauts qui apparaissent sont pris par quelqu'un d'autre — un développeur libre, une personne de rotation, une équipe support technique, parfois une équipe dédiée aux bugs. Le critère d'affectation est la disponibilité.

Optimiser la disponibilité a l'air d'un gain d'ordonnancement. L'effet réel est ailleurs. Celui qui a introduit le défaut ne voit jamais ce que sa livraison a coûté. Celui qui corrige doit reconstituer un contexte qu'il n'a pas créé, donc il paie deux fois : la correction et la compréhension. Et le temps perdu, devenu collectif, cesse d'être imputable à une livraison précise.

Le système émet alors un signal que personne ne formule : on peut livrer vite, et si cela casse, quelqu'un d'autre absorbera. « Je suis passé à autre chose » devient une réponse recevable.

Pourquoi c'est important

Cela déplace le diagnostic d'une équipe qui produit trop de défauts : avant de regarder ses compétences ou son outillage, on regarde sa règle d'affectation des corrections. Une règle qui optimise le débit à court terme peut être ce qui alimente le flux à corriger.

Cela donne aussi une lecture des équipes « dédiées aux bugs » : elles ne sont pas seulement un mode d'organisation, elles sont un dispositif qui coupe le lien entre une livraison et son coût.

Nuances et limites

L'affectation par disponibilité n'est pas toujours évitable — un développeur parti, un défaut issu de plusieurs contributions, une zone de legacy sans auteur identifiable, une personne objectivement mieux placée. Ces cas existent et ne se contestent pas.

Ce qui se conteste est leur usage : ils servent souvent à justifier la règle générale inverse, où la disponibilité décide par défaut plutôt qu'en exception.

Questions ouvertes

• Comment attribuer un défaut issu de plusieurs contributions successives sans transformer l'attribution en enquête plus coûteuse que la correction ?