Bugs : il est facile d'incriminer les développeurs

Je n'évoquerai pas ici le caractère tristement létal de certains bugs (lisez plutôt ce post  de mon ami Stéphane Dalbera au sujet du Therac-25), et que très brièvement 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 système informatique. 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.

Cela pour reconnaître, avant toute chose, que les bugs tiennent en partie à la piètre compétence des développeurs. 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 vendant monts et merveilles*, trop d'écoles qui ne forment qu'aux technologies du moment, et bien peu d'organisations qui enseignent réellement l'art du développement. On forme ainsi des machines à créer de la dette technique.

Mais n'évoquer que la compétence des développeurs reviendrait à ignorer une dimension essentielle du problème : la conception fonctionnelle. Car si une partie des bugs est le fait de développements non conformes à la spécification, une autre, probablement plus grande encore, est le fait de logiciels mal conçus. Les cas limites, en particulier, sont fréquemment oubliés, mais souvent c'est la conception dans son ensemble qui se révèle bancale. 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 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, ça me va". Moi, j'ai entendu des choses beaucoup plus crues, que la décence et ma mère m'interdisent de retranscrire ici. Parce que 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 .

Avant les bonnes pratiques de développement, il faudrait donc évoquer les bonnes pratiques de conception fonctionnelle, au premier rang desquelles l'Example Mapping , les tests utilisateurs et, plus en amont encore, l'étape cruciale de la Discovery. Car, avant de se jeter corps et âme dans la conception de l'application en réponse à un problème, il faut être sûr d'avoir précisément caractérisé ce dernier, et de traiter le bon problème…

En fait, les causes profondes sont, comme souvent, à rechercher dans l'organisation et la culture d'entreprise :