Au Joyeux Ragondin

Dans un article sur Wired, Bruce Schneier propose de rendre les éditeurs de logiciels responsables (légalement) des bugs dans leurs logiciels pour, dit-il, créer un encouragement à améliorer leur qualité. Slashdot s'interroge naturellement sur les conséquences d'une telle responsabilité sur les logiciels libres, qui sont en grande partie développés par des bénévoles.

Un constat tout simple : actuellement il y a un encouragement financier à laisser des bugs dans son logiciel, à deux niveaux ; premièrement, il faut tenir les délais de livraison du produit, et donc plus on essaye de corriger les bugs plus on prend de retard ; deuxièmement, s'il reste des bugs génants on aura peut-être une mauvaise réputation, mais on pourra aussi vendre des mises à jour. Ce constat fait, on peut se dire qu'en rendant les éditeurs responsables, on crée un encouragement à corriger les bugs qui pourrait inverser la tendance et améliorer la qualité globale des logiciels qui, au moins pour les logiciels grand public, est catastrophique.

Qu'est-ce qu'un bug ? À priori, ce mot désigne n'importe quel comportement du logiciel qui n'était pas prévu par ses développeurs. Une observation importante : il est extrêmement difficile, et souvent impossible, de prouver qu'un logiciel fait ce que l'on veut, ni plus, ni moins. D'autant plus lorsque l'interaction avec l'extérieur (par exemple Internet) rend les choses imprévisibles. Il faut donc au minimum distinguer quelques catégories de bugs :

• Les bugs idiots, qui auraient pu être évités facilement par un étudiant en première année. Par exemple, un buffer overflow à cause de l'utilisation de strcpy au lieu de strncpy. Typiquement, ce sont des bugs qui peuvent être détectés par des logiciels, ou résolus en utilisant des langages de plus haut niveau.
• Les bugs de protocole, qui font trop confiance. Quelque part au niveau de la communication entre deux trucs, un développeur a supposé que la communication était fiable, qu'aucun des trucs n'était piégé, ou d'une manière ou d'une autre a permis que quelqu'un de mal intentionné abuse. Ces bugs sont plus difficiles à résoudre, il n'y a pas toujours de règles simples, mais avec de la discipline on peut s'en sortir.
• Les bugs compliqués, par exemple un système multithread où, dans certains cas très rares, une interaction entre deux bouts de code a des conséquences inattendues qui, si elles sont utilisées par quelqu'un de mal intentionné, peuvent être désastreuses. C'est compliqué parce qu'il y a deux niveaux de bug : d'abord il faut se rendre compte qu'un truc imprévu peut se produire bien que cela n'arrive jamais dans les tests, et ensuite il faut se rendre compte que cela peut être exploité (par exemple). On peut encore s'en sortir, mais cela prend énormément de temps, et donc coûte très cher.
• Les bugs impossibles à résoudre. Il y a des cas où on ne peut pas garantir que le programme fait bien toujours ce que l'on veut. Dans ce genre de cas, la solution de sécurité consiste à limiter les fonctionnalités pour reprendre un peu de contrôle. Par exemple, un navigateur équippé d'une machine virtuelle Java pose des limites à ce que peuvent faire des applets Java, de sorte que si les limites sont bien posées, les applets ne peuvent rien faire de catastrophique. Mais est-ce toujours une solution possible ? On ne peut pas faire de preuve formelle de tous les programmes, alors comment garantir que son programme fonctionne lorsqu'on n'a pas cette preuve ?

Évidemment, si l'on rend les éditeurs responsables des bugs, il faut tracer une limite quelque part. Quand on trouve un bug idiot dans un logiciel vendu très cher, c'est qu'il y a un problème. Quand l'utilisation d'un langage un peu strict aurait évité un bug, on peut s'en prendre à celui qui a décidé des outils à utiliser ou aux développeurs peu rigoureux. Mais pour les cas où une preuve est hors de portée, que faire ? Et pour le cas où le coût de détection des erreurs est trop élevé ?

Schneier parle d'un encouragement à corriger les bugs, pas d'une punition. Ça se comprend assez bien dans le domaine des logiciels pour le grand public, mais quand des vies sont en jeu, je suppose que les choses se compliquent. Un exemple intéressant, toujours dans les logiciels « communs » : Don Knuth, développeur de TeX, offre aux découvreurs de bugs un chèque dont la valeur augmente au fil du temps. Au début, la récompense était d'un cent, et elle a été doublée régulièrement depuis 1985. Évidemment, quand on a un chèque de Knuth, on ne l'encaisse pas : on l'encadre. Est-ce que Schneier pensait à ce genre de choses ? Il pensait plus probablement à rembourser les acheteurs de logiciels défectueux. Deux solutions différentes pour deux modes de développement différents ?