Qualifier une remontée de bug sur un outil sur mesure : vrai bug, décision oubliée ou choix jamais fait

Le ticket « bug » qui n'en est pas un

Quelques mois après la mise en production d'un outil sur mesure, les remontées changent de nature. Les premières semaines, elles signalent de vraies pannes : un bouton qui ne répond pas, un calcul faux, un export vide. Puis arrivent des messages d'un autre genre. Une donnée saisie en brouillon qui disparaît quand on quitte l'écran. Une commande dupliquée qui ne reprend pas les pièces jointes de l'originale. Une pause qui reste appliquée alors qu'on vient de raccourcir les horaires d'une équipe. L'utilisateur écrit « bug » dans l'objet, souvent avec une pointe d'agacement, et le ticket atterrit dans la même file que les pannes réelles.

Le développeur qui ouvre ce ticket découvre alors que le code fait exactement ce qu'il a été écrit pour faire. Rien n'est cassé. Ce qui manque, c'est soit une fonctionnalité que personne n'a jamais demandée, soit la mémoire d'un choix fait il y a longtemps, pour de bonnes raisons, et que l'utilisateur n'a jamais connu. Le mot « bug » décrit l'expérience de l'utilisateur, pas la nature du problème. Et tant que personne ne fait la différence, chaque remontée est traitée comme une urgence technique.

Pourquoi tout arrive étiqueté comme un bug

L'utilisateur n'a qu'un seul point de comparaison : ce qu'il attendait. Il ne connaît ni la spécification, ni les arbitrages de conception, ni la liste de ce qui a été reporté à une version ultérieure. De son point de vue, un comportement surprenant est un comportement défectueux, et « bug » est le seul mot à sa disposition pour le dire. C'est légitime. Le problème commence quand l'équipe projet reprend ce mot tel quel, parce qu'elle accepte alors implicitement que l'outil est en tort, et que la réponse attendue est une correction.

Trois natures derrière le même mot

Une remontée étiquetée « bug » recouvre en réalité trois situations distinctes, qui n'appellent ni la même priorité ni le même interlocuteur. Le vrai bug est un écart entre ce que l'outil fait et ce qui avait été décidé qu'il fasse : il se corrige, et vite s'il bloque le travail. Le choix jamais fait est un comportement qui n'a jamais été défini, parce que le cas n'avait pas été imaginé ou avait été volontairement laissé de côté : c'est une évolution, qui se priorise comme les autres. La décision oubliée est un comportement voulu, argumenté, implémenté, mais dont la raison n'a été ni écrite ni transmise aux personnes en contact avec les utilisateurs.

« [...] il n'y a pas de doute à avoir parce que 90% des choses qui remontent et on le sait c'est pas des bugs c'est juste des décisions qui a été prise soit par nous, soit par eux, et qui remonte. »

Cette proportion est l'estimation d'un développeur sur un produit précis, pas une mesure. Mais elle dit quelque chose que la plupart des équipes qui maintiennent un outil métier reconnaîtront : la part des vraies pannes dans les remontées baisse à mesure que l'outil mûrit, et la part des décisions mal transmises augmente.

La décision oubliée, la plus coûteuse des trois

Sur un outil de planification d'équipes, un comportement signalé comme bug s'est révélé être une décision consciente prise plusieurs mois plus tôt : conserver une pause lors d'un changement d'horaires, pour éviter à l'utilisateur de tout reconfigurer. La décision n'avait jamais été tracée, ni communiquée aux personnes qui gèrent la relation client. L'équipe a d'abord douté d'elle-même, au point de remettre en cause des fonctionnalités qu'elle n'avait pas retestées depuis longtemps, puis a repris la discussion depuis zéro et fini par changer le comportement. Non pas parce que la première décision était mauvaise, mais parce qu'elle n'existait plus nulle part ailleurs que dans le code.

C'est ce qui rend la décision oubliée si coûteuse. Elle ne produit pas seulement un ticket inutile, elle rouvre un débat déjà tranché, sans les arguments qui avaient permis de le trancher, et elle installe chez l'utilisateur l'idée que l'outil est imprévisible. À force, c'est le service rendu qui se met à suivre les choix techniques plutôt que l'inverse.

« J'ai l'impression qu'on adapte le service qu'on rend à nos utilisateurs finaux aux décisions techniques qui ont été prises il y a deux semaines, un mois, deux mois, trois mois. »

Qualifier avant corriger : trois questions de tri

Le principe qu'on peut nommer qualifier avant corriger impose une étape de quelques minutes entre la réception d'une remontée et l'affectation d'un développeur. Cette étape tient en trois questions, posées dans l'ordre. Le comportement observé contredit-il une règle écrite quelque part, dans la spécification, un ticket validé ou un compte rendu d'atelier ? Si oui, c'est un bug, et il suit le circuit de correction. Sinon, ce comportement a-t-il été choisi par quelqu'un, même sans trace écrite ? Le développeur qui a écrit le code ou la personne qui a porté le besoin le savent généralement en une minute. Si oui, c'est une décision oubliée. Si personne ne l'a choisi, c'est un choix jamais fait.

Chacune des trois réponses oriente vers un interlocuteur différent. Le bug va à l'équipe technique. Le choix jamais fait va à la personne qui porte le besoin métier, parce que c'est à elle de dire si ce comportement mérite d'être défini et avec quelle priorité. La décision oubliée va aux deux : il faut retrouver la raison du choix, décider si elle tient toujours, puis l'écrire et la transmettre. C'est cette dernière étape qui manque presque toujours, et c'est elle qui empêche la même remontée de revenir trois mois plus tard sous un autre nom.

Le signal qui trahit une amélioration déguisée

Un indice pratique aide à trier sans même consulter l'historique : l'ampleur de la correction. Quand un « bug » demande plusieurs jours de développement, une migration de données ou la reprise d'un écran entier, il y a de fortes chances qu'il s'agisse d'une évolution. Une vraie panne se corrige rarement en redessinant le comportement. Dans ce cas, la bonne pratique est de sortir le sujet de la version en cours plutôt que de retarder tout le reste, et de le verser dans la file des évolutions, que nous traitons dans notre article sur la priorisation des demandes de maintenance par plafond.

Ce que la qualification change dans la relation avec les utilisateurs

Nommer correctement une remontée protège l'équipe et remet l'arbitrage à sa place. Sur une plateforme de commande, un client signalait comme des bugs la perte de données saisies en brouillon et l'absence de duplication de certaines informations lors de la copie d'une commande. Le développeur a immédiatement répondu que ce n'étaient pas des bugs mais des comportements jamais spécifiés. Les tickets ont été créés comme des évolutions et classés en priorité basse, sans dramatisation ni correction dans l'urgence. La conversation a changé de terrain : elle ne portait plus sur un outil défaillant, mais sur des fonctionnalités à arbitrer.

Ce recadrage exige un préalable. Il n'est crédible que si l'équipe corrige vite les vrais bugs, sans négocier, et si elle ne se sert pas de la qualification pour repousser tout ce qui la dérange. Une équipe qui répond « ce n'est pas un bug » à chaque remontée perd la confiance des utilisateurs aussi sûrement qu'une équipe qui corrige tout dans la panique. La qualification n'est pas un argument de défense, c'est un tri honnête, qui donne tort à l'outil aussi souvent que nécessaire. La recette fonctionnelle reste d'ailleurs le meilleur moment pour faire émerger les choix jamais faits, avant qu'ils ne remontent de la production.

Une règle connue et imparfaite vaut mieux qu'un comportement imprévisible

Beaucoup de décisions oubliées portent sur des arbitrages où aucune option n'est parfaite : garder un réglage ou le réinitialiser, enregistrer un brouillon ou non. Chaque option générera un jour une plainte. La tentation est alors de rouvrir le débat à chaque remontée, dans l'espoir de trouver la solution qui ne dérange personne. Elle n'existe pas. Ce qui compte est que la règle retenue soit connue : écrite, envoyée aux utilisateurs concernés, accessible à ceux qui répondent au support. Une règle imparfaite que tout le monde connaît produit une remarque. La même règle inconnue produit un ticket, une urgence et un doute sur tout le reste de l'outil. C'est l'intérêt, sur la durée, de la documentation au fil de la construction, appliquée ici non pas à l'architecture mais aux arbitrages de comportement.

Le test à faire sur vos vingt dernières remontées

Reprenez les vingt dernières remontées étiquetées « bug » sur votre outil métier et classez-les avec les trois questions : règle écrite contredite, choix fait sans trace, ou choix jamais fait. Si les vrais bugs sont minoritaires, votre file de correction traite en réalité des arbitrages produit, et votre équipe technique les tranche par défaut. Commencez alors par un geste simple : ouvrez un document d'une page où chaque décision de comportement tient en une ligne, avec sa raison, l'alternative écartée et la personne qui doit en être informée, et versez-y dès cette semaine les décisions retrouvées pendant le tri.