Culture bug
Je n'évoquerai pas ici le caractère tristement fatal de certains bugs (lisez plutôt ce post de mon ami Stéphane Dalbera au sujet du Therac-25), ni même les pratiques de développement susceptibles de diminuer l'occurrence de ces petites bestioles : typage statique, stratégies de tests et d'écriture de code guidée par les tests, programmation fonctionnelle et même avant cela la bonne modularité d'un grand système. Sans oublier les apports du Clean Code, car un code facile à lire est un code que l'on risque moins de casser en voulant le faire évoluer.
Certes, la compétence des développeurs est un sujet. Notre industrie manque tellement de main-d'œuvre qu'il est facile d'y rentrer sans un bagage théorique et pratique minimal. Trop de bootcamps*. Trop d'écoles qui ne parlent que de technologies, pas assez qui parlent des pratiques de développement. On forme ainsi des machines à créer de la dette technique – en plus des bugs.
Cependant, n'évoquer que la compétence des développeurs reviendrait à ignorer une dimension essentielle du problème : la conception fonctionnelle. Car si de nombreux bugs sont le fait de développements non conformes à la spécification du comportement attendu, une grande quantité de bugs est le fait de logiciels dont la conception laisse à désirer. Le Larousse définit d'ailleurs un bug comme "un défaut de conception ou de réalisation d'un programme informatique, qui se manifeste par des anomalies de fonctionnement de l'ordinateur".
Ayant fait mes armes à l'époque glorieuse des méthodologies waterfall, où le développement logiciel se réglait à grand coups de cahiers des charges, j'ai trop souvent entendu cette phrase : "ce n'est peut-être pas ce que vous vouliez, mais ce qui a été spécifié". Il faut dire, tout dans ce système rigide au possible (triangle de fer périmètre/coûts/délais) concourrait à faire échouer les projets de plusieurs millions d'Euros bradés au moment de l'appel d'offres. La préoccupation des maîtres d'œuvre était alors plus de maintenir la rentabilité à flots que de satisfaire leurs clients (et encore moins leurs utilisateurs).
L'utilisateur, justement, se fiche bien que le bug soit un défaut de réalisation ou de conception. On n'a jamais entendu un utilisateur dire "rien ne marche, mais comme le développement est conforme à la spécification tout va bien". Moi j'ai plutôt entendu des choses beaucoup plus crues, que la décence et ma mère m'interdisent de retranscrire ici. Non, ce qui l'intéresse, l'utilisateur, c'est que le logiciel lui permette de réaliser l'action qu'il souhaitait : par exemple réserver un billet de train sans faire 3 crises cardiaques (exemple bien innocent).
Avant les bonnes pratiques de développement, il faudrait donc évoquer les bonnes pratiques de conception fonctionnelle, au premier rang desquelles l'Example Mapping et celle du test utilisateur, véritable pendant des tests qu'écrivent les développeurs. Ces tests ne coûtent pas cher car ils sont réalisés sur base de maquettes, ou même de wireframes.
J'en viens ainsi au véritable sujet de ce post : soyons ambitieux et visons le Zero Bug, parce que les bugs ne sont pas une fatalité. Et si certains bugs passent au travers des mailles du filet et se retrouvent en production, une politique ambitieuse consisterait à les traiter en priorité par rapport à tout nouveau développement, indépendamment de leur criticité. Car un bug, même mineur, dévalue l'application et oblitère la confiance que l'utilisateur avait placée en elle. Un résultat incohérent sur un cas tout à fait mineur suffit à semer le doute : "et si d'autres résultats étaient faux sans que je m'en sois aperçu ?"
(*) NB : j'ai vu des développeurs formidables issus de bootcamps, mais ces personnes sont formidables probablement plus du fait de leur curiosité insatiable et de la rigueur qui leur est propre que du fait du bootcamp qu'elles ont fréquenté pendant 3 mois.