211service.com
Pourquoi le logiciel est si mauvais
C'est l'une des plus anciennes blagues sur Internet, transmise sans cesse de boîte aux lettres en boîte aux lettres. Un magnat du logiciel, généralement Bill Gates, mais parfois un autre, prononce un discours. Si l'industrie automobile s'était développée comme l'industrie du logiciel, proclame le magnat, nous aurions tous conduit des voitures à 25 $ qui parcourraient 1 000 milles au gallon. Ce à quoi un cadre automobile rétorque, Oui, et si les voitures étaient comme des logiciels, elles se bloqueraient deux fois par jour sans raison, et lorsque vous appeliez le service, ils vous diraient de réinstaller le moteur.
La blague résume l'une des grandes énigmes de la technologie contemporaine. En un temps étonnamment court, les logiciels sont devenus essentiels à presque tous les aspects de la vie moderne. Des coffres de banque aux feux rouges de la ville, des réseaux téléphoniques aux lecteurs DVD, des airbags automobiles aux systèmes de contrôle du trafic aérien, le monde qui nous entoure est régi par un code. Pourtant, de nombreux logiciels ne fonctionnent tout simplement pas de manière fiable : demandez à quiconque a vu un écran d'ordinateur devenir bleu, effaçant des heures d'effort. Trop souvent, disent les ingénieurs logiciels, le code est gonflé, laid, inefficace et mal conçu ; même lorsque les programmes fonctionnent correctement, les utilisateurs les trouvent trop difficiles à comprendre. Gémissant sous le poids de manuels semblables à des briques, les étagères des librairies à travers le pays témoignent du dysfonctionnement persistant des logiciels.
Les logiciels sont tout simplement terribles aujourd'hui, déclare Watts S. Humphrey, membre du Software Engineering Institute de l'Université Carnegie Mellon, qui a écrit plusieurs livres bien connus sur la qualité des logiciels. Et c'est de pire en pire tout le temps. De l'avis de Humphrey, un bon logiciel est utilisable, fiable, sans défaut, rentable et maintenable. Et le logiciel n'est plus rien de tout cela. Vous ne pouvez pas sortir quelque chose de la boîte et savoir que cela va fonctionner. Au fil des ans, selon Edsger W. Dijkstra, informaticien émérite à l'Université du Texas à Austin, l'utilisateur moyen d'un ordinateur a été si mal servi qu'il s'attend à ce que son système plante tout le temps, et nous assistons à un énorme distribution mondiale de logiciels buggés pour lesquels nous devrions avoir profondément honte.
Jim McCarthy est plus généreux. Le fondateur, avec sa femme Michele, d'une entreprise de formation à la qualité des logiciels à Woodinville, WA, estime que la plupart des produits logiciels ont les fonctionnalités nécessaires pour valoir la peine d'être achetés, utilisés et adoptés. Mais, admet-il, seule l'extrême utilité des logiciels permet d'en tolérer les énormes carences. McCarthy commence parfois des discussions dans son école avec une présentation PowerPoint. La première diapositive se lit comme suit : La plupart des logiciels sont nuls.
Il est difficile de trop insister sur le caractère unique des problèmes des logiciels. Lorsque les ingénieurs automobiles discutent des voitures sur le marché, ils ne disent pas que les véhicules d'aujourd'hui ne sont pas meilleurs qu'il y a dix ou quinze ans. Il en va de même pour les ingénieurs aéronautiques : personne ne prétend que Boeing ou Airbus fabriquent des avions pourris. Les ingénieurs électriciens ne se plaignent pas non plus que les puces et les circuits ne s'améliorent pas. Comme l'historien de l'ingénierie Henry Petroski l'a suggéré dans son livre de 1992 L'évolution des choses utiles , le raffinement continuel est la règle habituelle en technologie. Les ingénieurs remarquent constamment des lacunes dans leurs conceptions et les corrigent petit à petit, un processus que Petroski décrit avec ironie comme la forme suit l'échec. En conséquence, les produits s'améliorent progressivement.
Le logiciel, hélas, semble différent. On pourrait s'attendre à ce qu'un programme de 45 millions de lignes comme Windows XP, le dernier système d'exploitation de Microsoft, ait quelques bogues. Et le génie logiciel est une discipline plus récente que le génie mécanique ou électrique ; les premiers vrais programmes ont été créés il y a seulement 50 ans. Mais ce qui est surprenant, en fait étonnant, c'est que de nombreux ingénieurs logiciels pensent que la qualité des logiciels ne s'améliore pas. Si quoi que ce soit, disent-ils, c'est de pire en pire. C'est comme si les voitures produites par Detroit en 2002 étaient moins fiables que celles construites en 1982.
À mesure que les logiciels deviennent de plus en plus importants, l'impact potentiel du mauvais code augmentera pour correspondre, selon Peter G. Neumann, informaticien chez SRI International, un centre de R&D privé à Menlo Park, en Californie. Au cours des 15 dernières années seulement, des défauts logiciels ont détruit un lancement de satellite européen, retardé l'ouverture de l'aéroport extrêmement coûteux de Denver d'un an, détruit une mission de la NASA sur Mars, tué quatre marines dans un accident d'hélicoptère, incité un navire de la marine américaine à détruire un avion de ligne civil et a fermé les systèmes d'ambulance à Londres, causant jusqu'à 30 décès. Et en raison de notre dépendance croissante à l'égard du Net, dit Neumann, notre situation est bien pire qu'il y a cinq ans. Les risques sont pires et les défenses ne sont pas aussi bonnes. Nous reculons, et c'est effrayant.
Certaines sociétés de logiciels répondent à ces critiques en réorganisant leurs procédures ; Microsoft, piqué par les accusations selon lesquelles ses produits sont bogués, ouvre la voie publiquement. Pourtant, les problèmes de qualité logicielle durent depuis si longtemps et semblent si insolublement ancrés dans la culture logicielle que certains codeurs commencent à penser l'impensable. À leur propre stupéfaction, ces personnes se sont demandé si le vrai problème avec les logiciels n'est pas qu'il n'y a pas assez d'avocats impliqués.
Un manque de logique
Microsoft a publié Windows XP le 25 octobre 2001. Le même jour, dans ce qui peut être un record, la société a publié 18 mégaoctets de correctifs sur son site Web : corrections de bogues, mises à jour de compatibilité et améliorations. Deux correctifs ont corrigé des failles de sécurité importantes. Ou plutôt, l'un d'eux l'a fait ; l'autre patch n'a pas fonctionné. Microsoft a conseillé (et conseille toujours) aux utilisateurs de sauvegarder les fichiers critiques avant d'installer les correctifs. Cependant, les acheteurs de la version familiale de Windows XP ont découvert que le système ne fournissait aucun moyen de restaurer ces fichiers de sauvegarde si les choses tournaient mal. Comme l'explique la base de connaissances en ligne de Microsoft, les disquettes de sauvegarde spéciales créées par Windows XP Home ne fonctionnent pas avec Windows XP Home.
De tels dérapages, disent les critiques, ne sont que des erreurs de surface, des signes que les développeurs du logiciel étaient trop pressés ou trop négligents pour corriger les défauts évidents. Les vrais problèmes résident dans la conception de base du logiciel, selon R. A. Downes de Radsoft, une société de conseil en logiciels. Ou plutôt, son manquer de de conception. Le populaire logiciel de programmation Visual Studio de Microsoft est un exemple de la façon de penser de Downes. En plaçant simplement le curseur sur la fenêtre de Visual Studio, Downes a découvert que l'unité centrale de traitement était invisiblement bombardée de milliers de messages inutiles, même si le programme ne fait rien. C'est cataclysmique. C'est le chaos total, se plaint-il.
Le problème, selon Dan Wallach, informaticien à l'Université Rice, n'est pas le barattage inutile du processeur - après tout, note-t-il, la puissance de traitement est bon marché. Les logiciels Microsoft ne sont pas non plus particulièrement défectueux ; les critiques utilisent souvent les produits de l'entreprise comme exemples plus parce qu'ils sont familiers que parce qu'ils sont exceptionnellement mauvais. Au lieu de cela, de l'avis de Wallach, la confusion florissante et bourdonnante dans Visual Studio et tant d'autres programmes trahit comment les techniques d'écriture de logiciels n'ont pas réussi à suivre l'augmentation explosive de sa complexité.
Les programmeurs écrivent du code dans des langages tels que Java, C et C++, qui peuvent être lus par des êtres humains. Des programmes spécialisés appelés compilateurs transforment ce code en chaînes de uns et de zéros utilisées par les ordinateurs. Il est important de noter que les compilateurs refusent de compiler du code avec des problèmes évidents - ils crachent des messages d'erreur à la place. Jusqu'aux années 1970, les compilateurs s'installaient sur de grands mainframes qui étaient souvent réservés des jours ou des semaines à l'avance. Ne voulant pas que les erreurs entraînent des retards, les codeurs - qui au début avaient tendance à être formés en tant que mathématiciens ou physiciens - sont restés tard dans leurs bureaux pour vérifier de manière exhaustive leur travail. Écrire un logiciel était un peu comme écrire des articles scientifiques. La rigueur, la documentation et le contrôle par les pairs étaient la coutume.
Mais à mesure que les ordinateurs se sont répandus, les attitudes ont changé. Au lieu de planifier méticuleusement le code, les programmeurs sont restés debout dans des sessions de piratage caféinées toute la nuit, faisant constamment rebondir les résultats sur le compilateur. Encore et encore, le compilateur crachait des messages d'erreur ; les programmeurs corrigeaient les erreurs une par une jusqu'à ce que le logiciel soit correctement compilé. L'attitude aujourd'hui est que vous pouvez écrire n'importe quel morceau de code bâclé et que le compilateur exécutera des diagnostics, explique Neumann de SRI. S'il ne crache pas de message d'erreur, cela doit être fait correctement, n'est-ce pas ?
Cependant, à mesure que la taille et la complexité des programmes augmentaient, les limites de cette approche de code et de correction sont devenues évidentes. En moyenne, les codeurs professionnels font 100 à 150 erreurs par millier de lignes de code qu'ils écrivent, selon une étude pluriannuelle de 13 000 programmes réalisée par Humphrey de Carnegie Mellon. En utilisant les chiffres de Humphrey, le système d'exploitation d'entreprise Windows NT 4, avec ses 16 millions de lignes de code, aurait ainsi été écrit avec environ deux millions d'erreurs. La plupart auraient été trop petits pour avoir un effet, mais quelques milliers de personnes auraient causé de graves problèmes.
Naturellement, Microsoft a testé de manière exhaustive NT 4 avant sa sortie, mais dans presque toutes les phases de tests, vous trouverez moins de la moitié des défauts, dit Humphrey. Si Microsoft avait subi quatre séries de tests, une procédure longue et coûteuse, la société aurait trouvé au plus 15 bogues sur 16. Cela va vous laisser quelque chose comme cinq défauts pour mille lignes de code, dit Humphrey. Ce qui est très faible, mais le logiciel contiendrait toujours jusqu'à 80 000 erreurs.
Les ingénieurs logiciels savent que leur code est souvent truffé de lacunes et ils recherchent depuis longtemps de nouvelles technologies pour les éviter. Pour gérer des projets de plus en plus étendus comme Windows, par exemple, ils ont développé une variété de techniques, dont la plus connue est peut-être la conception à base de composants. Tout comme les maisons sont construites avec des deux-par-quatre et des équipements électriques standardisés, les programmes basés sur des composants sont construits à partir d'éléments modulaires et interchangeables : un exemple est la barre de menu presque identique au-dessus de chaque programme Windows ou Macintosh. De tels composants standardisés, selon Wallach, ne sont pas seulement de bonnes pratiques d'ingénierie, ils sont le seul moyen de faire fonctionner quelque chose de la taille de Microsoft Office. Microsoft, dit-il, a été l'un des premiers promoteurs agressifs de cette approche - c'est la meilleure décision d'ingénierie qu'ils aient jamais prise.
Malheureusement, disent les critiques, les composants sont souvent collés ensemble sans véritable plan central, comme si les entrepreneurs essayaient d'ériger de grandes structures sans plans. Incroyablement, dit Humphrey, la conception des grands projets logiciels n'est parfois rien d'autre que quelques bulles au dos d'une enveloppe. Pire encore, pour des raisons de marketing, les entreprises intègrent autant de fonctionnalités que possible dans un nouveau logiciel, contrecarrant ainsi les avantages de la construction modulaire. L'exemple le plus répandu est Windows lui-même, dont Bill Gates a témoigné lors d'une session d'avril du procès antitrust de Microsoft ne fonctionnerait tout simplement pas si les clients supprimaient des composants individuels tels que les navigateurs, les gestionnaires de fichiers ou les programmes de messagerie. C'est une affirmation incroyable, dit Neumann. Cela signifie qu'il n'y a pas de structure ou d'architecture ou de rime ou de raison dans la façon dont ils ont construit ces systèmes, autre que de les rendre aussi groupés que possible, de sorte que si vous supprimez une partie, tout échouera.
La conception inadéquate des produits finaux, affirment les critiques, reflète une planification inadéquate dans le processus de création de ceux-ci. Selon une étude du Standish Group, une société de conseil à West Yarmouth, MA, États-Unis, les projets de logiciels commerciaux sont si mal planifiés et gérés qu'en 2000, près d'un quart ont été annulés purement et simplement, ne créant aucun produit final. Les projets annulés ont coûté 67 milliards de dollars aux entreprises ; les dépassements sur d'autres projets ont rapporté 21 milliards de dollars supplémentaires. Mais comme le code et les correctifs conduisent à des séries de tests aussi étendues et coûteuses, même les projets réussis peuvent être extrêmement inefficaces. Incroyablement, les projets logiciels consacrent souvent 80 pourcent de leurs budgets pour réparer les défauts qu'ils ont eux-mêmes produits - un chiffre qui n'inclut pas le processus encore plus coûteux consistant à fournir un support produit et à développer des correctifs pour les problèmes détectés après la publication.
Les tests du système se poursuivent pendant près de la moitié du processus, dit Humphrey. Et même quand ils le font enfin fonctionner, il n'y a toujours pas de design. En conséquence, le logiciel ne peut pas être mis à jour ou amélioré avec l'assurance que les mises à jour ou les améliorations n'introduiront pas de défauts majeurs. C'est ainsi que les logiciels sont conçus et construits partout - c'est ainsi dans les vaisseaux spatiaux, pour l'amour de Dieu.
Le logiciel est-il un cas particulier ?
Les risques potentiels des mauvais logiciels ont été illustrés de manière sinistre entre 1985 et 1987, lorsqu'une machine de radiothérapie contrôlée par ordinateur fabriquée par l'Énergie atomique du Canada, soutenue par le gouvernement, a massivement surdosé des patients aux États-Unis et au Canada, tuant au moins trois. Dans un examen exhaustif, Nancy Leveson, maintenant informaticienne au MIT, a attribué une grande partie de la responsabilité aux pratiques inadéquates d'ingénierie logicielle du fabricant. Parce que le programme utilisé pour régler l'intensité du rayonnement n'a pas été conçu ou testé avec soin, de simples erreurs de frappe ont déclenché des explosions mortelles.
Malgré cette expérience tragique, des machines similaires exécutant un logiciel fabriqué par Multidata Systems International, de St. Louis, ont massivement surdosé des patients au Panama en 2000 et 2001, entraînant huit décès supplémentaires. Une équipe de l'Agence internationale de l'énergie atomique a attribué les décès à la saisie de données d'une manière que les programmeurs n'avaient pas prévue. Comme le note Leveson, de simples erreurs de saisie de données ne devraient pas avoir de conséquences mortelles. Donc, cet échec, aussi, peut être dû à un logiciel inadéquat.
Les experts en programmation ont tendance à s'accorder sur le fait que de telles catastrophes sont terriblement courantes. Considérez le Mars Climate Orbiter et le Polar Lander, tous deux détruits en 1999 par des familiers, qui ont facilement évité les erreurs de codage. Mais certains soutiennent que les logiciels ne peuvent tout simplement pas être jugés, mesurés et améliorés de la même manière que d'autres produits d'ingénierie. C'est juste un fait qu'il y a des choses que d'autres ingénieurs peuvent faire que nous ne pouvons pas faire, dit Shari Lawrence Pfleeger, chercheur principal au groupe de réflexion Rand à Washington, DC, et auteur du volume 2001 Génie logiciel : théorie et pratique . Si un pont survit à un poids de 500 kilogrammes et à un poids de 50 000 kilogrammes, note Pfleeger, les ingénieurs peuvent supposer qu'il supportera toutes les valeurs intermédiaires. Avec un logiciel, dit-elle, je ne peux pas faire cette hypothèse, je ne peux pas interpoler.
De plus, les fabricants de logiciels sont soumis à des exigences extraordinaires. Ford et General Motors fabriquent le même produit - une boîte à quatre roues avec un moteur à combustion interne - depuis des décennies. En conséquence, explique Charles H. Connell, ancien ingénieur principal de Lotus Development (qui fait maintenant partie d'IBM), ils ont pu améliorer progressivement leurs produits. Mais les éditeurs de logiciels sont constamment invités à créer des produits - des navigateurs Web au début des années 90, de nouvelles interfaces de téléphones portables aujourd'hui - contrairement à tout ce qui a été vu auparavant. C'est comme si un constructeur automobile disait : « Cette année, nous allons fabriquer une fusée au lieu d'une voiture », déclare Connell. Bien sûr, ils auront des problèmes.
Le dilemme classique dans les logiciels est que les gens veulent continuellement de plus en plus de choses, explique Nathan Myhrvold, ancien directeur de la technologie de Microsoft. Malheureusement, note-t-il, la demande constante de nouveauté signifie que les logiciels sont toujours dans la phase de pointe, lorsque les produits sont intrinsèquement moins fiables. En 1983, dit-il, Microsoft Word n'avait que 27 000 lignes de code. Le problème, c'est qu'il n'a pas fait grand-chose, ce que les clients n'accepteraient pas aujourd'hui. Si Microsoft n'avait pas continué à gonfler Word avec de nouvelles fonctionnalités, le produit n'existerait plus.
Les utilisateurs sont extrêmement inconscients, ajoute Myhrvold. Chez Microsoft, dit-il, les entreprises clientes ont souvent demandé à l'entreprise d'ajouter simultanément de nouvelles fonctionnalités et d'arrêter d'ajouter de nouvelles fonctionnalités. Littéralement, je l'ai entendu d'un seul souffle, d'une seule phrase. Nous ne savons pas pourquoi nous devrions mettre à niveau vers cette nouvelle version - elle contient toutes ces choses dont nous ne voulons pas - et quand allez-vous mettre ces trois choses ?' Et vous dites, Whaaat ?' Le résumé sardonique de Myhrvold : Logiciel ça craint parce que les utilisateurs l'exigent.
Des normes plus élevées
En janvier, Bill Gates a lancé un appel aux employés de Microsoft pour qu'ils fassent de l'informatique fiable et sécurisée leur priorité absolue. Dans ce que la société a présenté comme l'une de ses initiatives les plus importantes depuis des années, Gates a exigé que Microsoft réduise considérablement le nombre de défauts dans ses produits. Un mois plus tard, la société a pris la décision sans précédent de suspendre toute nouvelle écriture de code pendant près de deux mois. Au lieu de cela, il a réuni des programmeurs, un millier à la fois, pour des sessions de formation de masse sur la fiabilité et la sécurité. À l'aide d'écrans géants dans un auditorium géant, les dirigeants de l'entreprise ont affiché des extraits embarrassants de code défectueux produits par les spectateurs.
L'initiative de Gates a apparemment été inspirée par l'explosion de critiques qui a englouti Microsoft en juillet 2001 lorsqu'un débordement de tampon - un type d'erreur bien connu - dans son logiciel de serveur Web Internet Information Services a laissé le ver Code Red victimiser des milliers de ses entreprises clientes. (Dans un débordement de tampon, un programme reçoit plus de données que prévu, comme si l'on remplissait l'espace d'un code postal avec un numéro à 50 chiffres. Dans un ordinateur, les informations supplémentaires se répandront dans les parties adjacentes de la mémoire, corrompant ou écrasant les données là-bas, à moins qu'elles ne soient soigneusement bloquées.) Deux mois plus tard, le ver Nimda a exploité d'autres failles du logiciel pour attaquer des milliers de machines supplémentaires.
Battus par de telles expériences, les développeurs de logiciels sont de plus en plus attentifs à la qualité. Alors même que Gates rassemblait ses troupes, des groupes de réflexion comme le Kestrel Institute, de Palo Alto, en Californie, développaient des kits d'outils de programmation corrects par construction qui obligeaient presque les codeurs à écrire des programmes fiables ( voir Premiers secours pour code défectueux ). Chez Microsoft même, selon Amitabh Srivastava, directeur du Centre de recherche sur la productivité des programmeurs de l'entreprise, les codeurs travaillent avec de nouveaux langages de niveau supérieur comme C# qui ne permettent pas certaines erreurs. Et en mai, Microsoft a cofondé le Consortium d'informatique durable de 30 millions de dollars basé à Carnegie Mellon avec la NASA et 16 autres entreprises pour promouvoir des moyens normalisés de mesurer et d'améliorer la fiabilité des logiciels. Les efforts de contrôle de la qualité peuvent porter leurs fruits : en aidant Lockheed Martin à réorganiser le logiciel de son avion C130J, Praxis Critical Systems, de Bath, en Angleterre, a utilisé de telles méthodes pour réduire les coûts de développement de 80 % tout en produisant un logiciel qui a réussi les examens rigoureux de la Federal Aviation Administration avec très peu d'erreurs.