On répète souvent, parfois pour rire et parfois pour éviter un sujet pénible : « Ce n’est pas un bug, c’est une fonctionnalité. » La phrase est vieille, presque trop connue, mais si elle continue à circuler, c’est peut-être parce qu’elle touche à quelque chose de vrai.
Dans un vrai projet, un bug n’est pas toujours seulement une erreur évidente à corriger. Parfois, il révèle une décision qui n’avait jamais été formulée clairement, un usage que personne n’avait prévu, une habitude qui s’est installée, ou un besoin métier que le produit ne couvre pas encore.
C’est là que les choses deviennent intéressantes. Parce qu’entre le bug évident et la fonctionnalité parfaitement assumée, il existe une zone grise. Et dans cette zone grise, corriger trop vite peut parfois créer autant de problèmes que ne rien corriger.
Tous les bugs ne sont pas aussi évidents qu’ils en ont l’air
On parle souvent des bugs comme s’ils étaient simples à identifier. Une fonctionnalité, en théorie, est quelque chose de voulu, pensé, conçu pour répondre à un besoin. Un bug, lui, serait un comportement non voulu. Cette distinction paraît claire sur le papier.
Mais dans la réalité d’un projet, elle devient parfois moins nette. Un comportement peut ne pas avoir été prévu au départ, sans être totalement incorrect. Il peut être techniquement imparfait, mais cohérent avec l’état actuel de l’application. Il peut même être gênant pour certains utilisateurs et utile pour d’autres.
C’est pour cela qu’un bug ne devrait pas toujours être traité comme une simple ligne à fermer dans une backlog. Avant de corriger, il faut parfois comprendre ce que le comportement raconte.
La zone grise entre bug et fonctionnalité
Il arrive qu’un comportement non prévu vive assez longtemps pour devenir familier. Les utilisateurs s’y adaptent. Ils apprennent le chemin. Ils construisent leurs habitudes autour. Certains finissent même par compter dessus, non pas parce que le comportement est parfait, mais parce qu’il est devenu leur manière de travailler.
À ce moment-là, le statut du bug change. Techniquement, il reste peut-être discutable. Mais côté usage, il n’est plus neutre. Le retirer brutalement peut donner l’impression de corriger le code tout en cassant l’expérience.
C’est là que la vieille phrase prend une autre couleur. « Ce n’est pas un bug, c’est une fonctionnalité » n’est pas toujours une excuse. Parfois, c’est le signe qu’un comportement non prévu a été absorbé par le réel.
Quand corriger peut créer un autre problème
Corriger est souvent nécessaire. Certains bugs doivent être traités rapidement, surtout lorsqu’ils bloquent un utilisateur, exposent une donnée, faussent un calcul ou créent une vraie perte de confiance. Il ne s’agit pas de romantiser les erreurs ni de transformer chaque défaut en philosophie.
Mais corriger intelligemment demande parfois plus que du code. Il faut comprendre qui est impacté, qui s’est adapté, qui s’est mis à compter sur le comportement actuel, et ce qui se passera si on change ce comportement demain.
Avant de toucher au code, certaines questions méritent d’être posées :
- est-ce que le comportement est vraiment incorrect ou simplement inattendu ?
- qui est gêné par ce comportement aujourd’hui ?
- qui l’utilise déjà comme une partie normale du parcours ?
- est-ce que la correction risque de casser une habitude existante ?
- faut-il corriger directement, prévenir les utilisateurs, ou accompagner le changement ?
Ces questions ne ralentissent pas le travail. Elles évitent parfois de livrer une correction techniquement juste, mais humainement confuse.
Le bug report qui révèle un besoin métier
Parfois, un utilisateur remonte un bug, mais ce qu’il décrit n’est pas seulement une erreur. C’est le symptôme d’un besoin mal servi. Il pense signaler un problème, alors qu’il est peut-être en train de montrer une attente que le produit n’a pas encore prise en compte.
Dans ce cas, le bug report devient plus qu’un ticket technique. Il devient une information produit. Il révèle une façon de travailler, une logique métier, une attente implicite ou une friction que l’équipe n’avait pas encore vue.
Tu pensais devoir fermer une anomalie. Tu découvres qu’il faut peut-être concevoir une amélioration. Et dans cette situation, chercher ne t’a pas seulement permis de corriger. Chercher t’a permis de mieux comprendre ce qu’il fallait construire.
L’état actuel n’est pas toujours l’intention initiale
Il y a une phrase que j’aime beaucoup dans ce genre de situation : « Ce n’est pas forcément un défaut, c’est ainsi que c’est conçu aujourd’hui. » Elle évite deux erreurs. La première, c’est de mentir. La seconde, c’est de dramatiser.
Dire cela ne veut pas dire que tout est parfait. Cela veut dire qu’on sait distinguer plusieurs choses : ce qui était voulu, ce qui est toléré, ce qui est temporaire, et ce qui mérite d’évoluer ensuite.
Dans un projet, surtout au début, tout n’a pas vocation à être définitif. Certaines décisions sont des décisions de phase 1. Certains comportements sont acceptables pour démarrer. Certaines limites sont connues dès le départ. Le tout, c’est de le savoir, de l’assumer et de pouvoir le dire proprement.
Rester positif ne veut pas dire repeindre les problèmes en rose. Rester positif, c’est garder une lecture constructive de ce qu’on découvre à mesure que le projet avance.
Un exemple simple, mais fréquent
Un client te dit : « Quand je fais cette action, l’application revient ici au lieu d’aller là. » Tu regardes, tu testes, et tu comprends que ce comportement n’était peut-être pas l’intention initiale. Mais il est cohérent avec l’état actuel de l’application et avec d’autres choix déjà faits.
La mauvaise réponse serait de paniquer. La mauvaise réponse serait aussi de promettre une correction immédiate sans mesurer les conséquences. Une réponse plus saine pourrait être :
Aujourd’hui, l’application se comporte comme ça. Ce n’était peut-être pas l’intention de départ, mais c’est ainsi qu’elle fonctionne pour le moment. Si on veut la faire évoluer, on peut le faire proprement en vérifiant l’impact sur les autres parcours.
Ce genre de réponse change beaucoup de choses. Tu ne nies pas le problème, tu ne dramatises pas, tu ne promets pas n’importe quoi. Tu montres que tu comprends l’existant et que tu sais distinguer l’état actuel, l’intention initiale et l’évolution possible.
Le bug comme information
Une erreur révèle toujours quelque chose. Elle peut révéler un manque d’attention, une ambiguïté, une hypothèse fragile, un besoin mal compris, une limite du système, ou simplement le fait qu’on est en train de construire quelque chose de vivant, donc imparfait.
L’erreur n’est pas toujours agréable, mais elle est souvent instructive. Et dans notre métier, il y a une forme de maturité qui commence précisément là : quand on arrête de voir chaque bug comme une humiliation personnelle, et qu’on commence à le lire comme une information.
Pas une attaque. Pas une preuve qu’on est nul. Une information. Parfois difficile à accepter, parfois mal formulée, parfois urgente, mais une information quand même.
Conclusion : un bug peut finir par se justifier
Tous les bugs ne se valent pas. Certains doivent être corrigés vite. Certains doivent être compris avant d’être corrigés. Certains révèlent un besoin plus profond. Certains sont devenus des habitudes. Et certains, avec le temps, l’usage ou le contexte, finissent presque par se justifier.
Pas parce qu’ils étaient parfaits. Pas parce qu’il faut tout excuser. Pas parce qu’il faut cacher les erreurs derrière une phrase amusante. Mais parce qu’un logiciel ne vit jamais uniquement dans le code. Il vit aussi dans les usages, les habitudes, les attentes et les compromis.
Alors oui, il faut corriger les bugs. Mais il faut aussi apprendre à les lire. Parce que parfois, avant d’être une erreur à supprimer, un bug est une information à comprendre.