Ôtons nous de l’idée que les logiciels que nous utilisons tous les jours sont exempts de bugs. Que cela soit des comportements non désirés, une situation de blocage, une ergonomie douteuse, ou une fonctionnalité non présente, on a toujours quelque chose à reprocher au logiciel.
Entre le reproche et la correction (si correction il y a), plusieurs étapes sont nécessaires pour aboutir à une solution, ou à défaut à un compromis satisfaisant pour l’utilisateur comme pour le développeur.
Première étape : le diagnostic
La première étape, essentielle, est le diagnostic. Or, le diagnostic ressemble trop souvent à ceci :
- « Ça ne marche pas ! »
(Très bien… mais encore ?) - « Voilà une capture d’écran du bug. »
(Idéalement en 40 x 100 pixels, sans aucun contexte, pour être sûr de ne rien distinguer.) - « Là ça ne marche pas parce que tu as fait comme ça, donc il faut faire comme ça. »
(Si la cause et la solution sont déjà identifiées, autant changer de rôle.) - « Des fois ça marche, des fois ça ne marche pas, c’est aléatoire. »
(En informatique, l’aléatoire est trés rare. Il cache presque toujours un facteur non identifié.)
Cependant, ce type de retour, bien que compréhensible, ne constitue pas un véritable diagnostic. Ce qu’attend le développeur, c’est une description factuelle et structurée :
- « En suivant tel processus, étape par étape, j’arrive systématiquement à telle situation, dans tel contexte. »
Seconde étape : le process de reproduction
Pour corriger les bugs, un développeur a besoin de deux éléments essentiels : être en mesure de se remettre dans la même situation et maîtriser le mode opératoire utilisé pour reproduire le dysfonctionnement.
À ce stade, le développeur utilise ce que l’on appelle couramment des « outils de debug ». Ils lui permettent au minimum d’analyser les données et idéalement, de reproduire pas à pas les étapes du problème. Ces outils sont rarement disponibles dans les environnements clients. Il doit donc pouvoir se placer dans une situation équivalente pour les exploiter efficacement.
Deux types d’environnements sont possibles. L’environnement de développement qui contient le fonctionnel du client, mais pas ses données réelles, ce qui permet de simuler le processus. Néanmoins, pour les problèmes dépendant de données spécifiques, l’environnement de préproduction est nécessaire. Il combine la possibilité de travailler sur le code et une copie complète et récente des données, suffisamment proche du contexte réel pour reproduire le problème.
Troisième étape : le process de correction
Lorsqu’il parvient à reproduire le problème, le développeur peut alors identifier sa cause et proposer une solution adaptée. Selon la situation, cette solution peut se limiter à une modification mineure, sans impact fonctionnel, comme la correction d’une erreur de données ou de traitement. mais parfois, elle peut également nécessiter des ajustements plus importants.
Dans ce cas, le développeur met à disposition des éléments permettant de tester la correction. Une fois celle-ci validée, la mise en production peut être programmée.
Il n’y a rien d’exceptionnel dans le processus que je décris. Par contre, dès lors qu’il implique au moins deux personnes, le processus se complexifie souvent lorsque les échanges ne sont ni clairs ni réguliers.
Concrètement, la qualification de l’utilisateur peut parfois être insuffisante. Même en laissant de côté l’ego du développeur (« moi, je ne fais pas de bugs, monsieur »), il est crucial que rien n’entrave la capacité du développeur à reproduire le problème.
Sans conditions de reproduction claires et accessibles, aucune analyse fiable ni correction efficace ne peuvent être envisagées.
Ce phénomène est malheureusement fréquent. De plus, il s’aggrave lorsque le développeur refuse de traiter le problème ou de se mettre dans le contexte, faute d’informations complètes.
La moralité tient en une phrase : bug qualifié = bug corrigé
Olivier, Apsynet
