Ne pas corriger un bug : l'arbitrage clé de la dette technique

On a décidé de ne pas corriger un bug connu depuis 6 mois.

Pas par négligence. Par choix. Le bug existait, on le savait, il était documenté. Les utilisateurs concernés représentaient environ 3% de la base. Le cas d'usage était rare, l'impact faible, et le correctif touchait une partie critique du code - celle où une erreur de manipulation coûte beaucoup plus cher que le bug lui-même.

Alors on a fait quelque chose que peu d'équipes assument en réunion produit : on a décidé, explicitement, de ne pas le corriger. Et de passer à autre chose.

Six mois plus tard : zéro ticket support sur ce bug, zéro utilisateur perdu à cause de lui, et six mois de vélocité préservée sur des sujets qui comptaient vraiment. Cette décision n'a rien d'exceptionnel. C'est un cas concret de ce qui devrait être une pratique courante : arbitrer la dette technique au lieu de la subir.

Corriger un bug n'est jamais une opération gratuite

Un bug non corrigé a un coût visible : des utilisateurs gênés, un risque d'image, une friction produit. C'est ce coût que tout le monde voit et que personne ne veut assumer publiquement.

Mais corriger un bug a aussi un coût, presque toujours sous-estimé. Le temps de développeur mobilisé sur ce correctif n'est pas mobilisé ailleurs. Si le code touché est sensible - un moteur de facturation, une synchronisation de données, un système d'authentification - le correctif porte lui-même un risque de régression, parfois plus grave que le bug initial. Et une fois livré, il faut le tester, le surveiller, et parfois revenir dessus.

Traiter la correction d'un bug comme une action par défaut, sans peser ce qu'elle coûte en face de ce qu'elle rapporte, c'est piloter à l'aveugle. La question n'est jamais "faut-il corriger ce bug", elle est "qu'est-ce qu'on gagne à le corriger maintenant, comparé à ce qu'on gagnerait à faire autre chose avec le même temps".

La grille qu'on a utilisée pour trancher

Face à ce bug, l'équipe a répondu à quatre questions avant de décider quoi que ce soit.

1. Quelle est la surface réellement touchée ? Pas une estimation vague, un chiffre : combien d'utilisateurs, avec quelle fréquence, sur quel parcours. 3% de la base sur un cas d'usage secondaire n'a pas le même poids que 3% de la base sur le parcours de paiement.
2. Existe-t-il un contournement ? Un bug sans solution de rechange bloque un utilisateur. Un bug avec un contournement simple - même imparfait - transforme une urgence en gêne tolérable.
3. Quel est le risque du correctif lui-même ? Un correctif isolé dans un module périphérique n'a rien à voir avec un correctif qui touche une logique partagée par dix fonctionnalités. Plus le rayon d'impact du code est large, plus le correctif doit être justifié par un gain proportionné.
4. Qu'est-ce qu'on ne fera pas si on corrige ce bug maintenant ? C'est la question la plus souvent oubliée. Chaque ticket traité en a un autre non traité en face. Rendre ce compromis explicite change la nature de la décision.

Sur ce bug précis : surface faible, contournement existant, correctif risqué sur du code critique, et un backlog plein de sujets à plus fort impact. La décision de ne pas corriger n'était pas un pari optimiste. C'était la conclusion logique de la grille.

Ce que le silence de six mois a réellement prouvé

Le résultat n'était pas garanti à l'avance - c'est bien pour ça que c'était une décision, pas une évidence. Zéro ticket support, zéro churn identifié, zéro escalade. Le budget de développement économisé est allé sur des correctifs et des fonctionnalités qui ont eu un effet mesurable sur l'activité.

Ce résultat confirme un principe qu'on retrouve dans l'ingénierie de fiabilité logicielle sous une autre forme : accepter un niveau de défaut défini à l'avance, plutôt que de viser un objectif de perfection qui coûte plus cher qu'il ne rapporte au-delà d'un certain seuil. Le concept d'error budget documenté dans le SRE Book de Google - une réserve d'indisponibilité tolérée avant de bloquer les livraisons - repose sur la même logique : la fiabilité a un coût marginal croissant, et le zéro défaut absolu n'est ni atteignable ni souhaitable au-delà d'un certain point.

Un backlog de bugs fonctionne pareil. Viser zéro bug ouvert, c'est ignorer que chaque correctif a un coût d'opportunité. La vraie compétence n'est pas de tout corriger. C'est de savoir mesurer ce qu'un bug coûte réellement face à ce qu'il coûterait de le corriger.

Le vrai danger : la dette technique subie, pas la dette technique choisie

Il y a une différence fondamentale entre un bug qu'on décide sciemment de ne pas corriger, et un bug qu'on oublie parce que personne n'a pris le temps d'en discuter. La première est une dette assumée, documentée, réévaluable. La seconde est une dette qui s'accumule dans l'angle mort de l'équipe, jusqu'à ce qu'elle explose au pire moment.

Martin Fowler a formalisé cette distinction dans son quadrant de la dette technique : une dette contractée délibérément, en connaissance de cause, n'a pas le même profil de risque qu'une dette contractée par inadvertance, faute d'avoir identifié le problème à temps. La première se gère. La seconde se découvre, souvent trop tard.

C'est là que se joue la vraie différence entre une équipe qui maîtrise sa dette technique et une équipe qui la subit : pas dans le nombre de bugs ouverts, mais dans le fait que chaque bug non corrigé a été vu, discuté, et laissé ouvert pour une raison qu'on peut réciter.

Rendre visible ce qu'on choisit de ne pas corriger

Un backlog de bugs n'est pas une liste de honte à faire disparaître au plus vite. C'est une liste de décisions à prendre, et à documenter une fois prises.

Concrètement, pour chaque bug qu'on choisit de ne pas corriger dans l'immédiat, on note trois choses : pourquoi on ne le corrige pas maintenant, ce qui ferait changer cette décision, et quand la revoir. Ce n'est pas de la paperasse - c'est ce qui évite qu'un arbitrage raisonnable se transforme en oubli permanent.

• La raison de l'arbitrage : surface, contournement, risque du correctif, coût d'opportunité. Les mêmes critères que la grille initiale.
• Le déclencheur de réévaluation : un seuil de tickets support, un changement de code sur la zone concernée, une croissance de la base d'utilisateurs qui change la proportion touchée.
• Une date de revue, même approximative. Un arbitrage sans date de revue devient une décision qu'on ne reconsidère jamais, même quand le contexte a changé.

Ce système transforme un backlog de bugs en outil de pilotage plutôt qu'en source d'angoisse permanente. Il rend la dette technique traçable, au lieu de la laisser devenir un non-dit collectif.

Quand la bonne décision d'hier devient la mauvaise décision d'aujourd'hui

Un arbitrage n'est jamais définitif. Le bug qui touchait 3% de la base peut en toucher 15% après une levée de fonds qui change le profil des utilisateurs. Le module "critique" d'hier peut avoir été refactoré et devenir beaucoup moins risqué à modifier. Le contournement qui suffisait peut devenir intenable si le volume d'utilisateurs concernés explose.

C'est pour ça que la date de revue n'est pas une formalité. Une équipe qui n'a jamais rouvert un arbitrage ancien n'a probablement pas une bonne discipline de dette technique - elle a simplement cessé d'y penser. Rouvrir un dossier n'est pas un aveu d'erreur. C'est la preuve que la décision initiale était bien une décision, prise avec les informations disponibles à ce moment-là, et pas un renoncement définitif.

FAQ : arbitrer un backlog de bugs et la dette technique

Faut-il toujours corriger tous les bugs connus d'un produit ?

Non. Corriger systématiquement chaque bug ignore le coût d'opportunité : le temps passé sur un bug à faible impact n'est pas disponible pour des sujets à plus fort effet sur le produit ou le business. La bonne pratique consiste à arbitrer chaque bug selon sa surface réelle, l'existence d'un contournement, et le risque du correctif lui-même, plutôt que de viser un backlog vide par principe.

Comment décider si un bug mérite d'être corrigé immédiatement ?

En croisant quatre critères : le nombre d'utilisateurs réellement touchés et la fréquence du problème, l'existence d'un contournement acceptable, le niveau de risque du correctif sur le code concerné, et ce que l'équipe ne fera pas si elle mobilise du temps sur ce correctif maintenant. Un bug à faible surface, avec contournement, sur du code critique, est un candidat naturel pour être reporté plutôt que corrigé dans l'urgence.

Qu'est-ce que la dette technique "assumée" par opposition à la dette technique "subie" ?

La dette technique assumée est un choix explicite de ne pas corriger un problème identifié, documenté avec sa raison et une date de revue. La dette technique subie est un problème connu mais jamais discuté collectivement, qui s'accumule dans l'angle mort de l'équipe jusqu'à devenir un incident. La différence ne porte pas sur le nombre de bugs ouverts, mais sur le fait que chacun ait été vu et arbitré.

Comment éviter qu'un bug non corrigé soit oublié définitivement ?

En documentant, pour chaque bug laissé ouvert volontairement, la raison de l'arbitrage, le seuil ou l'événement qui déclencherait une réévaluation, et une date de revue même approximative. Sans ce mécanisme, un arbitrage raisonnable pris à un instant donné se transforme silencieusement en négligence quand le contexte change.

Un backlog de bugs ouvert est-il un signe de mauvaise qualité produit ?

Pas nécessairement. Un backlog de bugs ouvert et arbitré, avec des décisions documentées et revues régulièrement, traduit une équipe qui priorise consciemment. Un backlog de bugs ignoré, sans discussion ni suivi, traduit en revanche une dette technique non maîtrisée - c'est cette absence d'arbitrage qui est le vrai signal de risque, pas le nombre de lignes dans le backlog.

Ce que je recommande, en tant que CTO hands-on

Tout corriger est une illusion confortable à défendre en réunion, et coûteuse à financer sur la durée. Savoir ce qu'on choisit de ne pas corriger, et pourquoi, est une compétence - une compétence qui se construit avec une grille de décision claire, pas avec de l'instinct au coup par coup.

En mission CTO hands-on, c'est un des premiers chantiers que je mets en place avec une équipe : transformer un backlog de bugs subi en backlog de décisions assumées, avec des critères d'arbitrage partagés entre product et tech, et un mécanisme de revue pour ne pas figer une décision devenue obsolète. Ce n'est pas un audit ponctuel - c'est une discipline que je porte au quotidien, aux côtés de l'équipe, que ce soit sur une mission courte de structuration ou un accompagnement long.

Un backlog de bugs vide n'a jamais été la preuve d'un bon produit. Un backlog de bugs arbitré, si.

---

Sources :

• Martin Fowler, Technical Debt Quadrant
• Google, SRE Book - Embracing Risk (Error Budgets)