Comment caractériser la malfaçon logicielle ?

Dans un article dans le magazine « Communication of the ACM » en novembre 2011, Poul-Henning Kamp [1] aborde la question de la responsabilité des créateurs de logiciels en cas de défaillance néfaste du système. La malfaçon se limite-t-elle à cela ?

The software industry is the problem
Dans cet article, l'auteur se base sur le discours de Ken Thompson "Reflections on trusting trust" lorsque qu'il reçoit le prix Turing en 1984 [2]. Ce dernier y insiste sur le fait qu'on ne peut pas avoir confiance en un système que l'on n'a pas entièrement développé. Comme le remarque très justement Poul-Henning, il en va de même pour une maison ou une voiture. Toutefois nous utilisons au quotidien du matériel et nous habitons des maisons construites par des professionnels en qui nous plaçons notre confiance.
L'article évoque cette confiance comme provenant du fait que la malfaçon a des conséquences négatives pour le professionnel et ce, depuis longtemps (amende, emprisonnement et même châtiment dans des temps plus anciens). Le logiciel fait exception à cette règle, hormis évidement en cas d'atteinte volontaire aux données et systèmes du client. Il propose donc l'introduction d'une responsabilité sous trois clauses :
1. Consulter le code pénal pour vérifier si tout dommage volontaire est préalablement prévu..
2. Remboursement du logiciel si une version complète du code source est fournie et que la licence permet la désactivation de toute fonctionnalité ou partie du code fournit par l’éditeur.
3. Dans les autres cas, l'éditeur du logiciel doit être considéré comme responsable des dégâts occasionnés lors d'une utilisation normale du système.

Comment caractériser la malfaçon logicielle ?
Dans leurs propos, Ken Thompson et Poul-Henning Kamp se focalisent sur les failles de sécurité induites par les logiciels. Toutefois à mon sens, la question de la malfaçon est plus profonde que la simple détérioration de donnée où une faille de sécurité. D'autres critères pourraient être pris en compte, comme la rapidité d'exécution ou encore la maintenabilité du système, sa capacité à évoluer vers des besoins futurs.
La rapidité dépend grandement des algorithmes et de la représentation des connaissances choisie. En utilisant des structures de données inadaptées, un programme « naïf », c'est à dire sans un minimum de réflexion, s'exécutera en plus d'une heure, là où un programme bien réfléchi fournira le même résultat en quelques secondes.
On observe beaucoup ce phénomène lorsque l'on touche à des programmes traitant un grand volume de données. Mais ce phénomène existe à tout niveau. Beaucoup de logiciels peinent à passer à une grande échelle, l'ajout de puissance de calcul étant rapidement bornée (voir la loi d'Amdhal [3] et l'observation de Gustafson [4] pour plus d'information). Cette constatation est, par ailleurs, également valable pour les systèmes se basant sur les méthodes de calculs distribués ou parallèles. Mais même lorsque que l’on utilise toute la puissance disponible (multi-core, GPGPU), le faire de manière incorrecte peut paradoxalement fournir un résultat moins performant.
Outre la modularité, la maintenabilité du code comprend l'ajout aisé de nouvelles fonctionnalités et la qualité du code source. Combien de fois, sur des applications internes, la mise en place d'un nouveau logiciel ou l'évolution de celui existant est devenue contraignante du fait d’une structure peu lisible, peu documentée et/ou par l'utilisation de techniques inadéquates ?

Vers un artisanat logiciel ?
Le peu d'exigence quant à la qualité intrinsèque des « logiciels métiers » pousse à défendre une notion de qualité plus ambitieuse. Le développement naïf n'est que trop répandu, souvent sous la contrainte du temps ou du coût, poussant les développeurs à ne pas tenir compte des problèmes futurs engendrés par ce choix.
C'est le parti pris du laboratoire ACSEL que de diffuser et de proposer des solutions innovantes et de qualité auprès des étudiants et des professionnels du secteur. Il est en effet important, tout en cultivant le dynamisme qui lui est caractéristique, d’apporter à l’industrie du logiciel et des services informatique les outils lui permettant de dévoiler son réel potentiel.
---------------------
[1] Poul-Henning Kamp, Software industry is the problem, Communication of the ACM, Nov. 2011.
[2] Ken Thompson, Reflexion on trusting trust, Communication of the ACM, Aug. 1984.
[3] Mark D. Hill et Michael R. Marty, Amdhal’s law in the multicore Era, research.google.com/pubs/archive/34400.pdf
[4] James Reinders, Intel Threading Building Blocks, O’Reilly, 2007