La qualité appartient à ceux qui livrent

Une politique zéro bug permet de ne plus gérer des stocks de défauts.

Mais elle ne suffit pas.

Si l'équipe corrige les bugs plus vite sans changer la manière dont elle produit, elle reste dans une boucle de réparation. Le backlog diminue, puis remonte. Les urgences disparaissent, puis reviennent. Le support respire, puis sature à nouveau.

Le vrai sujet est en amont.

Comment éviter de produire autant de bugs ?

On ne réduit pas les bugs seulement avec une meilleure organisation de tri. On les réduit en responsabilisant ceux qui livrent, en refusant les spécifications trop floues, en testant plus tôt, et en donnant à la QA un rôle de politique qualité plutôt qu'un rôle de rattrapage.

La qualité n'est pas quelque chose que l'on délègue après coup.

La qualité appartient à ceux qui livrent.

Corriger les bugs des autres dilue la responsabilité

Dans beaucoup d'équipes, l'organisation ressemble à ceci.

Un développeur travaille sur une feature. Il livre. Il passe à un autre sujet. Des bugs apparaissent. Comme il est déjà occupé, quelqu'un d'autre les prend. Un développeur disponible. Une personne de rotation. Une équipe support technique. Parfois une équipe dédiée aux bugs.

Sur le papier, cela semble efficace. On optimise la disponibilité.

En réalité, on dilue la responsabilité.

Celui qui a introduit le défaut ne voit pas toujours le coût de ce qu'il a livré. Celui qui corrige doit comprendre un contexte qu'il n'a pas créé. Le temps perdu devient collectif, donc moins visible. Et chacun peut se protéger derrière une phrase classique : "Je suis passé à autre chose."

Ce système crée un mauvais signal.

Il dit implicitement : tu peux livrer, et si ça casse, quelqu'un d'autre absorbera.

Même si personne ne le formule comme ça, l'effet existe.

Celui qui crée le bug le corrige

La règle la plus saine est simple : celui qui crée le bug le corrige.

Pas parce qu'il faut punir.

Pas parce qu'il faut humilier.

Parce que la responsabilité de correction doit rester attachée à la responsabilité de production.

Si un développeur sait que ses bugs lui reviendront directement, il livrera différemment. Il testera davantage. Il relira mieux. Il évitera de pousser un changement fragile juste pour tenir un délai. Il acceptera moins facilement de produire sur une ambiguïté forte.

Ce n'est pas une garantie. Mais c'est une incitation saine.

Bien sûr, il y a des exceptions.

Le développeur peut être absent. Le bug peut venir de plusieurs contributions. Le problème peut être dans du legacy. La responsabilité peut être partagée. Une autre personne peut parfois être mieux placée pour corriger.

Ces cas existent.

Mais ils ne doivent pas devenir une excuse pour abandonner la règle générale.

Dans la plupart des cas, si un développeur a créé le défaut, il doit le corriger. Même s'il est passé à un sujet important. Même si cela perturbe le planning. Même si cela ralentit la feature suivante.

La qualité consomme de la capacité. La cacher ne la rend pas gratuite.

Responsabilité n'est pas culpabilisation

Il faut ici distinguer responsabilité et culture de blâme.

Responsabiliser ne veut pas dire chercher un coupable. Cela ne veut pas dire afficher publiquement celui qui a cassé. Cela ne veut pas dire créer une peur de livrer.

Une culture de blâme détruit la qualité. Les gens cachent les problèmes, minimisent les défauts, évitent de prendre des risques, documentent pour se protéger, et l'équipe apprend moins vite.

La responsabilité utile est différente.

Elle dit : tu es propriétaire de ce que tu livres, donc tu participes à sa correction, à son apprentissage et à son amélioration.

On ne cherche pas à punir. On cherche à fermer la boucle.

Le développeur qui corrige son propre bug comprend mieux ce qui a cassé. Il voit où sa compréhension était insuffisante. Il voit si le test manquait. Il voit si la spec était floue. Il voit si l'architecture rendait l'erreur probable.

C'est cette boucle qui crée de la qualité.

Les développeurs ne sont pas des exécutants

Cette responsabilité suppose une autre idée : les développeurs ne sont pas des exécutants.

Ils ne sont pas là pour "pisser du code".

Ils sont des créateurs de valeur.

Le Product Manager est responsable des choix produit : pourquoi ce sujet, pour quelle cible, avec quel impact, dans quelle priorité. Mais les développeurs sont responsables de la qualité technique, de la code base et de ce qu'ils livrent.

Chacun a une zone de responsabilité.

Si le Product Manager fait un mauvais arbitrage produit, il doit l'assumer.

Si les développeurs livrent un code fragile, peu testé, mal compris ou difficile à maintenir, ils doivent aussi l'assumer.

Cela ne veut pas dire que les responsabilités sont isolées. Elles se parlent. Un bon produit se construit dans le dialogue entre choix produit, faisabilité, usage, qualité et contraintes techniques.

Mais le dialogue ne doit pas servir à dissoudre la responsabilité.

Une spécification trop floue doit être refusée

Un défaut ne vient pas toujours d'un mauvais code.

Il peut venir d'une spécification incomplète, d'une décision produit ambiguë, d'un cas non pensé, d'un flux mal compris.

Mais cela ne signifie pas que personne n'est responsable.

Si une spec est trop floue, les développeurs doivent pouvoir refuser de produire.

Refuser ne veut pas dire bloquer. Cela veut dire : le cadre n'est pas assez clair pour livrer correctement.

Il vaut mieux demander une clarification avant de coder que créer une fonctionnalité bancale qui générera ensuite des bugs, du support, du rework et des discussions interminables.

Un développeur responsable ne se contente pas d'exécuter une demande ambiguë. Il cherche à comprendre le comportement attendu, les cas limites, les critères d'acceptation, les risques, les données, les dépendances.

S'il ne peut pas comprendre ce qu'il doit livrer, il ne peut pas garantir la qualité de ce qu'il livre.

La responsabilité produit et la responsabilité technique se rejoignent là : le Product Manager doit clarifier le choix produit ; les développeurs doivent refuser de transformer une ambiguïté forte en code fragile.

Le TDD : le quoi avant le comment

Le TDD, Test Driven Development, est une réponse concrète à cette logique.

Au lieu d'écrire d'abord le code, puis de vérifier ensuite s'il fonctionne, on écrit d'abord le test.

Le test décrit le quoi.

Le code implémente le comment.

C'est une distinction importante. Le test formalise une partie de la spécification : voilà le comportement attendu, voilà ce qui doit rester vrai, voilà ce qui ne doit pas casser.

Ensuite, le code peut évoluer. Il peut être refactoré. Il peut interagir avec de nouvelles données. D'autres fonctionnalités peuvent arriver autour. Mais si le comportement attendu est cassé, le test casse.

Idéalement, le problème est détecté sur le poste du développeur ou en qualification, pas en production.

Le TDD ne supprime pas tous les bugs. Il ne remplace pas la réflexion produit. Il ne transforme pas une mauvaise spec en bon produit.

Mais il change une chose essentielle : il oblige à rendre une partie de la qualité vérifiable avant l'implémentation.

Dans une organisation qui veut moins de bugs, cette discipline compte.

La QA n'est pas un filet de sécurité

La QA ne doit pas être l'endroit où les développeurs déposent leur responsabilité qualité.

Si la QA est seulement un filet de sécurité en fin de chaîne, elle arrive trop tard. Elle teste ce qui aurait dû être pensé, clarifié, automatisé ou évité plus tôt. Elle devient le dernier barrage avant la production, donc l'endroit où l'organisation externalise ses défauts.

Ce n'est pas suffisant.

La QA peut jouer un rôle beaucoup plus stratégique.

Elle peut définir les critères de qualité. Les politiques de test. Les standards de livraison. Les seuils de régression acceptables. Les risques à couvrir. Les zones du produit à sécuriser. Les tests à automatiser. Les signaux qui montrent qu'une équipe livre mieux ou moins bien.

Avec l'intelligence artificielle et l'automatisation, ce rôle devient encore plus important.

Comme pour beaucoup de métiers, l'IA permet de réduire une partie de l'opérationnel répétitif pour se concentrer davantage sur la stratégie. Pour la QA, cela signifie moins de tests manuels répétitifs, moins de régressions rejouées écran par écran, et plus de réflexion sur le système qualité.

La valeur de la QA se déplace.

Moins : refaire mécaniquement les mêmes vérifications.

Plus : définir quoi vérifier, pourquoi, avec quel niveau d'automatisation, sur quels risques, avec quels critères.

La QA ne remplace pas la responsabilité des développeurs. Elle construit le cadre dans lequel cette responsabilité devient praticable, mesurable et durable.

Les métriques doivent servir la qualité

Mesurer peut être utile.

Le rework, par exemple, peut montrer qu'une équipe repasse trop souvent sur les mêmes sujets. Le cycle time peut révéler que des reprises ralentissent fortement la livraison. Les régressions peuvent montrer que certaines zones du produit cassent trop souvent.

Ces signaux sont utiles s'ils servent à améliorer le système.

Ils deviennent toxiques s'ils recréent une obsession administrative.

Il ne sert à rien de passer un temps infini à savoir si un défaut est un bug, une feature, une amélioration, une reprise, une anomalie QA ou autre chose, si cette qualification ne change pas la décision.

La mesure doit éclairer.

Elle ne doit pas remplacer le jugement.

L'objectif reste simple : sortir vite ce qui compte, avec un niveau de qualité acceptable, et réduire la douleur réelle.

Le legacy du futur

Le legacy existe.

Toutes les équipes doivent, à un moment, travailler avec du code ancien, des décisions passées, des architectures fragiles, des dépendances mal documentées, des choix qui avaient peut-être du sens hier et qui compliquent tout aujourd'hui.

On ne peut pas toujours éviter le legacy existant.

Mais on peut éviter de fabriquer le legacy de demain.

Un bug transféré à quelqu'un d'autre, une spec floue acceptée sans discussion, un test jamais écrit, une régression manuelle répétée sans automatisation, une QA utilisée comme filet final, un code livré vite mais mal compris : tout cela devient du legacy futur.

Responsabiliser les développeurs ne règle pas tout. Mais cela change la trajectoire.

Quand celui qui livre possède la qualité de ce qu'il livre, il produit différemment. Quand il peut refuser une spec trop ambiguë, il évite de transformer du flou en complexité. Quand le TDD formalise une partie de la spécification, le produit devient plus robuste. Quand la QA définit une politique qualité, le système entier devient plus clair.

Le legacy futur n'est pas une fatalité.

C'est souvent le résultat de responsabilités mal placées aujourd'hui.

Conclusion

Une équipe qui veut moins de bugs ne doit pas seulement mieux les classer.

Elle doit rendre la qualité impossible à déléguer.

La politique zéro bug traite le stock de défauts connus. Mais la qualité de livraison empêche de recréer ce stock. Pour cela, chacun doit tenir sa responsabilité.

Le Product Manager possède le choix produit.

Les développeurs possèdent la qualité technique de ce qu'ils livrent.

La QA construit le cadre qualité : critères, standards, risques, tests, automatisation.

Et l'équipe, collectivement, doit refuser les organisations où les bugs deviennent toujours le problème de quelqu'un d'autre.

Responsabilité ne veut pas dire blâme. Cela veut dire ownership.

La qualité appartient à ceux qui livrent, parce que ce sont eux qui peuvent la construire au moment où elle coûte le moins cher : avant que le bug existe.