Bugs : le développeur, un coupable trop facile

• Artisanat/craft

Un bug en production. À qui la faute ?

Les bugs, un sujet de développement ?

Il y a, bien sûr, un sujet de compétence. Notre industrie manque tellement de main-d’œuvre qu’il est facile d’y rentrer sans presque rien connaître du métier. 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 (comprenez-moi : j’ai rencontré des développeurs formidables issus de bootcamps, mais je dis que ces personnes étaient formidables intrinsèquement, sans que le bootcamp y soit pour quelque chose). On forme ainsi des machines à créer de la dette technique.

Pourtant, des pratiques bien établies existent, qui permettent de diminuer l’occurrence des bugs : typage statique (n’en déplaise aux aficionados du JavaScript), pratiques de tests simples et avancées (allant jusqu’au Test-Driven Development), sans oublier la programmation fonctionnelle (vivent les fonctions pures), et, bien avant tout cela, le travail sur la modularité, dont on sous-estime souvent la portée.

Mais à dire vrai, si j’évoque le sujet de la compétence, c’est pour l’évacuer plus rapidement. Car la question « à qui la faute » est une très mauvaise question. Pointer du doigt ne suffit pas, il faut réparer, il faut aider, et avant cela reconnaître que le problème est, comme souvent, de nature systémique.

La conception fonctionnelle en cause

N’évoquer que la compétence des développeurs, c’est 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, 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 à grands 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é ». L’utilisateur, lui, 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…

L’analyse et la conception fonctionnelle, comme tout, s’apprennent et se travaillent. Là aussi, il existe des pratiques bien établies, au premier rang desquelles l’Example Mapping. Ce savoir est d’autant plus intéressant que plus un bug est détecté tard, plus sa correction coûte cher. Idéalement, le bug sera donc détecté avant que la moindre ligne de code n’ait été écrite, et l’on parlera de « défaut de conception ».

À bien y regarder, la distinction entre conception fonctionnelle et développement (en caricaturant : pensée vs. action) est peut-être un problème en soi. C’est donc l’organisation qu’il faut mettre en cause.

Des causes organisationnelles

Comme souvent, les causes profondes sont d’ordre organisationnel, et c’est un drame, car une mauvaise organisation l’emportera toujours sur les meilleures volontés.

Voici quelques pistes :

• La pression des délais : le management qui demande l’impossible, des délais intenables sauf à contracter une immense dette technique, un classique du genre. Dans le pire des cas, c’est le PoC qu’on passe en production, faute de savoir faire la différence…

• Le turnover : qui dit « rotation des équipes » dit « perte de connaissance ». Un développeur se retrouve bientôt à faire évoluer un système qu’il ne comprend pas, sur un métier qu’il ne comprend pas. Il faut donc se demander pourquoi l’organisation échoue à stabiliser ses équipes.

• Il y a ensuite la définition même des équipes. On le sait (loi de Conway), l’architecture logicielle reflète les structures de communication de l’organisation. Si vous n’avez pas correctement étudié la modularité à l’échelle du système d’information, il y a de grandes chances que vous ayez constitué des équipes en dépit des frontières naturelles de votre domaine et créé une intarissable source de bugs.

• Et décidément, l’enfer est pavé de bonnes intentions : même la création d’une cellule qualité peut jouer contre vous et devenir une incitation à créer des bugs. Un paradoxe qui s’explique par le fait que l’on ne peut pas dissocier le faire et le faire mieux.

• C’est enfin une question de culture d’entreprise et d’ambition : tolérer les bugs, c’est déjà les favoriser. A contrario, une politique Zéro Bug, consistant à traiter les bugs en priorité par rapport à tout nouveau développement, est un signal fort, que tout le monde perçoit, du développeur à l’utilisateur. 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 mineur suffit à semer le doute : « et si d’autres résultats étaient faux sans que je m’en sois aperçu ? »

Incriminer les développeurs est facile. Construire une organisation qui ne produit pas de bugs l’est beaucoup moins : c’est précisément pour cela que c’est un sujet de direction, pas seulement de développement.