Zéro bug : arrêtons de gérer des stocks de défauts

Porsche a publié un retour d'expérience intéressant sur la zero bug policy, appliquée à My Porsche. L'idée peut sembler irréaliste au premier abord. Tout le monde sait qu'un logiciel sans bug n'existe pas. Même les meilleurs produits ont des défauts, des régressions, des comportements inattendus, des cas limites.

Mais ce n'est pas le sujet.

Une politique zéro bug ne promet pas un code parfait. Elle vise autre chose : ne plus accepter de conserver des bugs connus comme un stock permanent à prioriser, requalifier et repousser.

Le vrai problème des bugs n'est pas seulement leur existence. Le vrai problème, c'est l'organisation qui s'habitue à les garder.

On ouvre un ticket. On lui met une priorité. On le classe. On le revoit deux semaines plus tard. On change sa priorité. On en parle en comité. On le repousse parce qu'une feature roadmap est plus urgente. Puis un client se plaint, le bug remonte, et l'équipe traite dans l'urgence ce qu'elle aurait dû décider clairement depuis longtemps.

À ce moment-là, le bug n'est plus seulement un défaut logiciel. C'est un défaut de décision.

Les bugs ne comptent pas jusqu'à l'urgence

Dans beaucoup d'organisations, les bugs sont dans un entre-deux étrange.

Ils existent. Tout le monde les voit. Ils consomment de l'énergie. Ils irritent les clients. Ils encombrent le support. Mais ils ne comptent pas vraiment dans la planification.

La roadmap avance. Les features prévues arrivent. Les délais sont visibles. Les arbitrages sont faits sur les nouveaux sujets. Et les bugs restent à côté, comme une charge implicite que l'on traitera quand on aura le temps.

Sauf qu'on n'a jamais le temps.

Alors les bugs deviennent prioritaires seulement quand ils sont trop visibles : un gros client se plaint, une démo casse, le support sature, une régression touche un flux critique, un dirigeant tombe dessus.

Cette logique oppose artificiellement roadmap et qualité. Comme si les features étaient le vrai travail, et les bugs un bruit à gérer autour. Mais un bug consomme de la capacité. Il consomme aussi de la confiance client, de la crédibilité interne, du temps support et de l'attention produit.

Ne pas le compter ne le rend pas gratuit.

Ce que veut vraiment dire "zéro bug"

Une politique zéro bug ne signifie pas qu'il n'y aura jamais de bug.

Cela signifie : zéro bug connu non décidé.

La nuance est essentielle. L'objectif n'est pas d'éliminer l'inconnu. L'objectif est de ne pas organiser l'acceptation permanente de défauts connus.

Quand un signal arrive, l'équipe doit décider rapidement : est-ce un défaut ou non ?

Si c'est un défaut, on corrige.

Si ce n'est pas un défaut, on ne le traite pas comme bug. Cela peut être une amélioration. Cela peut être une demande de feature. Cela peut être une incompréhension. Cela peut être un sujet intéressant, mais hors priorité.

Dans tous les cas, il y a une décision.

Ce que la politique zéro bug refuse, c'est le troisième état : "On sait que c'est un bug, mais on le garde dans une liste pour plus tard."

Ce "plus tard" est souvent le vrai problème.

Le piège du backlog de bugs

Un backlog de bugs donne une impression de maîtrise.

Tout est listé. Chaque bug a une priorité. Certains sont blocker, d'autres major, minor, trivial. On peut filtrer. On peut trier. On peut faire un comité. On peut produire des tableaux. On peut dire que le sujet est sous contrôle.

Mais prioriser un bug tous les mois n'est pas le traiter.

C'est souvent seulement accepter qu'il reste là.

Le stock de bugs crée son propre travail. Il faut vérifier si le bug existe toujours. Il faut savoir s'il est encore prioritaire. Il faut savoir si le client concerné est encore client. Il faut savoir s'il est toujours reproductible. Il faut savoir s'il doit passer devant une autre anomalie. Il faut relire, requalifier, replanifier.

L'organisation dépense alors de l'énergie à administrer des défauts plutôt qu'à restaurer la qualité.

Et le plus absurde, c'est que beaucoup de ces bugs ne seront jamais corrigés.

On le sait. L'équipe le sait. Le support le sait. Le Product Manager le sait. Mais le ticket reste ouvert, parce que fermer revient à assumer une décision que personne ne veut porter.

Une politique zéro bug force cette décision.

Deux décisions : défaut ou non-défaut

La force de l'approche Porsche tient à sa simplicité.

Au lieu de multiplier les catégories, l'équipe réduit la décision :

• defect : c'est un défaut, donc on corrige ;
• no defect : ce n'est pas un défaut, donc on ne le traite pas comme bug.

Cette simplification ne veut pas dire que tout devient brutal ou automatique. Il faut toujours comprendre l'impact, le contexte, le client, la fréquence, la gravité. Mais la discussion doit mener à une décision, pas à une nouvelle catégorie.

Une amélioration peut être utile sans être un défaut.

Une demande client peut être pertinente sans être un bug.

Un comportement peut être frustrant sans être prioritaire.

Ce qui compte, c'est de ne pas cacher l'arbitrage derrière une typologie.

Si c'est un défaut réel, on le traite. Si ce n'en est pas un, on l'assume. Mais on ne garde pas indéfiniment un bug connu dans une file qui sert surtout à éviter de choisir.

Bug ou feature : le client s'en moque

Du point de vue du client, la distinction entre bug et feature a peu d'intérêt.

Le client ne se demande pas s'il souffre d'un bug, d'une feature absente, d'une feature mal faite ou d'une feature qui ne correspond pas à son besoin. Il ressent une douleur.

Un logiciel peut n'avoir aucun bug technique et pourtant ne pas répondre au besoin du client. La douleur reste réelle.

À l'inverse, certains bugs sont objectivement des défauts, mais leur impact est faible. Si l'utilisateur doit cliquer deux fois sur un bouton, ce n'est pas idéal. Mais si, à côté, une feature absente l'empêche de faire une déclaration fiscale ou légale obligatoire, l'absence de feature est plus critique que le bug mineur.

C'est pour cela que la catégorie du ticket ne doit pas remplacer l'analyse de la douleur.

La vraie question n'est pas : "Est-ce un bug ou une feature ?"

La vraie question est :

• quelle douleur cela crée-t-il ?
• pour qui ?
• à quelle fréquence ?
• avec quel impact ?
• est-ce bloquant ?
• est-ce réglementaire ?
• est-ce que cela génère du support ?
• est-ce que cela détruit la confiance ?

La typologie peut aider à mesurer. Elle ne doit pas décider à la place de l'équipe.

Assumer une position radicale : plus de cartes bug séparées

On peut aller plus loin.

Dans beaucoup d'organisations, je supprimerais les cartes de bugs séparées dans Jira ou les outils équivalents. Je ne garderais que des cartes de travail.

Pourquoi ?

Parce que la séparation bug / feature finit souvent par créer deux systèmes de priorité. Les features sont pilotées par la roadmap. Les bugs sont pilotés par l'urgence, le support, la pression client ou des comités de priorisation. Et entre les deux, personne ne regarde vraiment l'ensemble sous l'angle de la douleur et de la valeur.

Une carte de travail devrait porter un problème à traiter.

Parfois ce problème vient d'un défaut logiciel. Parfois il vient d'une capacité absente. Parfois il vient d'une mauvaise conception. Parfois il vient d'une dette technique. Mais l'arbitrage doit rester le même : quelle douleur, quelle valeur, quel impact, quelle décision ?

Le daily du matin peut alors servir à décider ce qui compte vraiment maintenant. Pas à débattre pendant vingt minutes pour savoir si l'élément est un bug, une feature, une amélioration ou un rework.

Bien sûr, certaines organisations ont besoin de reporting qualité. On peut garder des tags, des métriques, des catégories minimales. Mais ce sont des informations secondaires. Elles ne doivent pas structurer toute la décision.

Soit on traite maintenant, soit on refuse

Le pire statut d'un bug n'est pas "non corrigé".

Le pire statut, c'est "à prioriser plus tard".

"Plus tard" semble raisonnable. En réalité, c'est souvent une manière polie de ne pas décider.

Certains bugs doivent être traités tout de suite.

D'autres doivent être explicitement refusés. On peut écrire une carte minimale si l'on veut garder une trace : "On ne fera pas." Mais il ne faut pas alimenter un backlog de bugs interminable pour se donner l'impression que le sujet existe encore.

La discipline est simple :

• si c'est un défaut réel et important, on corrige ;
• si ce n'est pas un défaut, on le sort de la gestion bug ;
• si c'est trop faible pour être traité, on l'assume ;
• si cela revient souvent, on le réévalue avec des signaux.

L'objectif n'est pas de devenir dogmatique. L'objectif est de forcer l'organisation à produire une décision.

La vélocité doit absorber la qualité

Corriger immédiatement un défaut peut affecter la vélocité.

Cela peut empêcher de finir une feature. Cela peut perturber un sprint goal. Cela peut repousser un sujet roadmap. C'est désagréable, mais c'est normal.

La qualité consomme de la capacité.

Quand une équipe ignore les bugs pour préserver sa vélocité, elle protège une métrique au détriment du produit. Elle donne l'impression d'avancer vite, mais elle accumule de la friction, du support, de la dette et de la défiance.

Une politique zéro bug rend ce coût visible.

Si les défauts ralentissent l'équipe, ce n'est pas la politique zéro bug qui crée le problème. Elle révèle simplement que le système produit trop de défauts ou les détecte trop tard.

La bonne réponse n'est pas de cacher les bugs dans un backlog. La bonne réponse est d'améliorer le système de production : tests, QA, TDD, automatisation, clarification des specs, responsabilité des développeurs.

Ce sera le sujet de l'article suivant.

Comment démarrer avec un stock existant

La difficulté arrive quand l'équipe a déjà un stock de bugs.

On peut prendre une option radicale : fermer tous les bugs existants et repartir à zéro. C'est propre, mais politiquement difficile. Cela demande une forte confiance interne et une capacité à assumer les refus.

On peut aussi prendre une option progressive.

L'article Porsche propose une logique de réduction par paliers : prioriser une dernière fois, traiter un petit nombre de défauts par sprint, et définir un nouveau zéro temporaire. L'important est que cette phase reste une transition, pas une nouvelle forme normale de backlog.

Une méthode très efficace consiste à passer par le support.

Chaque semaine, le support liste le top 3 des retours clients liés à des bugs.

Ce top 3 devient le top 3 bugs à traiter.

La semaine suivante, si un, deux ou trois bugs ont été traités, le support propose les suivants.

On avance par Pareto. On traite d'abord ce qui revient le plus souvent, ce qui fait le plus mal, ce qui génère le plus de charge support. On ne commence pas par reprioriser cent tickets. On traite les irritants qui encombrent réellement l'organisation.

Cette méthode a un double avantage.

D'abord, elle réduit la douleur client visible.

Ensuite, elle désengorge le support.

Le support voit que ses retours servent à quelque chose. L'équipe produit traite les problèmes qui reviennent vraiment. Les développeurs ne se dispersent pas dans une liste abstraite. La direction voit des irritants disparaître.

Pour sortir d'un stock de bugs, il ne faut pas commencer par tout reprioriser. Il faut traiter ce qui revient le plus souvent et fait le plus mal.

Les métriques utiles, sans obsession administrative

Il ne s'agit pas de supprimer toute mesure.

Certaines métriques sont utiles :

• le rework ;
• le cycle time ;
• les régressions ;
• les défauts trouvés avant production ;
• les défauts trouvés en production ;
• la charge support liée à certains bugs.

Ces mesures peuvent éclairer la qualité. Elles permettent de voir si l'équipe refait trop souvent son travail, si certains flux cassent régulièrement, si une zone du produit génère trop de support, si les défauts sont détectés trop tard.

Mais la métrique doit rester un outil.

Si l'équipe passe plus de temps à qualifier les défauts qu'à améliorer le système, elle recrée le problème qu'elle voulait résoudre. On remplace alors le backlog de bugs par un backlog de catégories.

La finalité n'est pas de tout mesurer. La finalité est de réduire la douleur et d'améliorer le flux.

Conclusion

Une politique zéro bug ne rend pas le logiciel magique.

Elle rend seulement impossible de cacher les défauts connus derrière un backlog.

Elle oblige à décider. Elle rend la qualité visible. Elle empêche les bugs de devenir un stock administratif. Elle force l'organisation à choisir : corriger, refuser, ou requalifier comme autre chose.

C'est radical, mais c'est précisément ce qui rend l'approche utile.

Tant qu'un bug peut dormir dans un backlog pendant six mois, personne n'est vraiment responsable de la décision. Une politique zéro bug remet cette responsabilité au centre.

Mais elle ne suffit pas.

Si l'équipe corrige vite sans changer la manière dont elle livre, elle restera dans une boucle de réparation. Le vrai sujet suivant est donc la prévention : responsabilité des développeurs, spécifications claires, TDD, QA, automatisation, legacy futur.

Autrement dit : une politique zéro bug traite le stock. La qualité de livraison empêche de le recréer.