Vous avez probablement déjà vécu ce moment où le programme que vous utilisez cesse d'être l'outil qui vous permet d'avancer dans vos tâches. Ou bien de ce site web qui se met à afficher des résultats aberrants. Tout cela bien entendu exactement au moment où vous n'avez pas de temps à perdre.

En fait, même lorsque vous ne faites rien de bien important ou que vous n'êtes pas dans l'urgence, le défaut d'un programme devient rapidement irritant.

Alors vous râlez, vous pestez après ces maudits programmeurs. Vous trouvez ou ne trouvez pas une solution temporaire pour vous sortir de la situation et puis...

Et puis souvent, c'est tout. Le problème est oublié, jusqu'à la prochaine fois. Ou bien encore plus souvent, l'utilisateur fait avec et intègre sa solution temporaire à ses habitudes de travail.

Dans un article précédent, je montrais déjà comme il pouvait être dangereux de contourner un problème plutôt que de le résoudre. Dans le cas d'une utilisation de programme cependant, l'utilisateur n'a pas forcément la possibilité à court terme de résoudre la situation.

Mais si le contournement est intégré dans les habitudes, le danger est similaire : la dette est payée sur le long terme.

Ainsi, on voit parfois des utilisateurs de longue date d'un programme être moins efficace sur une tâche qu'un débutant. L'habitué évite un défaut dans le programme que le débutant n'a jamais rencontré, ce défaut ayant été corrigé entre temps.

Contre ce dernier soucis, l'habitude à prendre est de régulièrement analyser sa manière de faire et de suivre la documentation d'évolution du programme.

Prévenir les secours

L'utilisateur n'a donc pas de moyen immédiat de correction du défaut, mais il a cependant un moyen puissant de contribuer à cette résolution : le « rapport de bugs »¹.

Les développeurs sérieux ont tous à disposition un moyen de répertorier l'ensemble des défauts connus de leur logiciel. À chaque défaut est assigné plusieurs caractéristiques permettant de les trier. Parmi elles, on en trouve deux très importantes : la sévérité (est-ce que le défaut faire s'arrêter brutalement le programme ? ou pire, le programme corrompt-il silencieusement les données ?) et la fréquence (est-ce arrivé une seule fois ?, ou bien est-ce systématique sous certaines conditions d'utilisation ?).

Ainsi, on peut classer les défauts pour traiter en priorité les plus sévères et fréquents.

Ce que l'on voit rapidement, c'est que la fréquence, ou plus exactement l'occurrence, est un facteur multiplicatif : un défaut sévère mais qui ne se produit jamais (ex : car il survient dans le cadre d'une utilisation vraiment anormale du logiciel) sera moins prioritaire qu'un défaut juste un peu pénible (ex : une valeur qui ne se rafraîchit pas immédiatement) mais qui se produit chez tous les utilisateurs.

La fréquence d'un bug est donc très importante pour déterminer la priorité des défauts. Mais c'est aussi une valeur complexe à obtenir. En effet, elle nécessite la coopération des utilisateurs à travers le signalement des défauts.

Le développeur de logiciel à d'autre outils pour repérer les défauts d'un logiciel et nourrir la base de données qui les centralise. Mais sans retour utilisateur, celle-ci ne sera pas correctement triée ; dans le sens où, par ignorance de ce qui pourrait augmenter le plus rapidement possible la qualité perçue, elle sera probablement triée selon des critères purement techniques.

Un lourd passé

Malheureusement, l'histoire de l'informatique n'a pas fait grand chose pour montrer à l'utilisateur que son retour était essentiel. Celui-ci s'est souvent vu le cobaye involontaire de logiciels et systèmes d'exploitation présentant de nombreux défauts ; sans moyen facile de déclarer un défaut et d'en suivre son traitement ; sans aucune réactivité de la part du développeur.

À cela on peut ajouter le prix parfois élevé d'un logiciel qui à tendance à entraîner la fausse idée que s'il est cher, c'est que le développeur a les moyens de trouver les défauts seul².

Et parfois, un seul logiciel cumule le tout.

Des années de ce régime dans les logiciels parmi les plus populaires ont amené une situation terrible³ : la grande majorité des utilisateurs pense qu'un logiciel avec des défauts est normal et qu'il faut faire avec.

Faites-vous entendre

Qu'un logiciel ait des défauts, on peut s'y attendre. Les considérer comme une fatalité n'est pas normal. Et si par hasard le développeur du logiciel ne vous fournissez aucun moyen d'agir sur la qualité en signalant les défauts ou en ne les prenant pas en compte, vous devriez vous en méfier et regarder si un autre logiciel ne vous conviendrait pas mieux.

Et si vous avez la chance d'utiliser un logiciel développé par une équipe facilement accessible, par exemple dans votre propre entreprise, c'est encore plus simple car vous pouvez communiquer avec eux facilement.

N'hésitez pas ! S'ils sont un tant soit peu concernés par la qualité de ce qu'ils développent, ils n'attendent que ça !

J'espère vous avoir fait comprendre à quel point l'utilisateur avait la possibilité d'agir sur la qualité d'un logiciel, à quel point il était important qu'il ne se prive pas de le faire et à quel point un développeur devait prendre cela en compte.

Alors, la prochaine fois que vous êtes la victime d'un défaut logiciel, je compte sur vous pour râler, mais râler utilement⁴.