Pourquoi les logiciels ont-ils autant de bugs, et que peut-on y faire ?

Publié par l’Usine Nouvelle. 

 Tout le monde a été confronté à des bugs informatiques : « écran bleu » de windows, comportement erratique d’un logiciel, box internet qui doit être redémarrée… L’industrie logicielle est-elle vraiment pire que les autres ? Et si oui, que peut-on y faire ?

Les bugs coûtent cher, quelle que soit l’industrie

Le coût total des défauts logiciels est difficile à estimer, mais il est certainement très élevé. Les évaluations vont de 1% à 10% de la richesse nationale [1] (soit jusqu’à 200 milliards par an pour un pays comme la France), un montant comparable à celui du coût du crime organisé (dont le chiffre d’affaire mondial repose de plus en plus sur le cybercrime). Ce cout comprend trois composantes :

• 70 % de ce coût serait lié aux conséquences des malfaçons logicielles : ces défauts vont de la perte d’une sonde spatiale à cause de l’oubli d’un trait d’union dans un programme[2] à un processeur qui se trompe sur le résultat d’une opération élémentaire[3], en passant par toutes les failles exploitées par les hackers pour prendre le contrôle d’un système informatique ou le faire perdre ;
• 20 % correspondrait à des problèmes d’obsolescence – c’est-à-dire le fait de tarder à investir dans des technologies modernes et d’utiliser des logiciels archaïques de plus en plus difficiles à garder en état correct de fonctionnement ;
• 10% du coût total serait induit par l’échec total ou partiel de projets informatiques : les grands projets dans le génie civil, l’aérospatiale ou l’énergie finissent souvent hors délais, hors budget et avec des défauts [5]. Les grands projets informatiques n’y font pas exception : 20% des grands projets informatiques échouent, et la moitié des projets informatiques ne tiennent pas l’ensemble de leurs objectifs (coût, délais, spécifications).

L’industrie du logiciel est-elle plus touchée par les défauts que d’autres industries ? Il est difficile de trouver des études qui analysent le coût des défauts par industrie. Si l’on comparait avec le secteur automobile – un secteur plutôt en pointe pour les démarches de qualité – on pourrait noter qu’environ 10% des véhicules font l’objet de rappels chaque année aux Etats-Unis. Il est plus bas ailleurs car tous les pays n’ayant pas des réglementations aussi protectrice des consommateurs – on peut donc estimer que ce chiffre donne une idée du taux de défaut dans l’industrie.

Il y a par ailleurs un million de morts par an liés à l’automobile, ce qui représente un préjudice économique de l’ordre de mille milliards. Certes, la grande majorité est imputable à des causes multiples qui incluent des erreurs de conduite, l’état de la route ou des éléments extérieurs. Mais on trouve des situations similaires pour les logiciels : un problème de cybersécurité résulte de la rencontre entre une vulnérabilité dans un logiciel, un attaquant désireux de l’exploiter et une victime insuffisamment protégée. Autre effet indésirable, les véhicules automobiles émettent 3 milliards de tonnes de carbone, ce qui a un cout environnemental d’environ 300 milliards de dollars sur une base de 100 $ la tonne de carbone. Que des solutions censées nous faciliter la vie conduisent finalement à un réchauffement climatique couteux à éviter constitue certainement un très gros « bug » (qui concerne aussi le digital). Enfin on peut noter que les Parisiens ont perdu l’équivalent de 4 semaines de travail par automobiliste en 2021[6]. Il s’agit la moins d’un problème lié au véhicule que d’une saturation des infrastructures. Mais il en va de même pour des applications tellement lentes qu’elles en deviennent inutilisables en raison d’un manque de bande passante !

L’industrie logicielle « mange tout », au risque de faire des indigestions

L’une des raisons du nombre de bugs est la croissance du nombre d’applications et de leur complexité. On a coutume de dire que « le logiciel mange tout » – autrement dit de plus en plus de tâches sont réalisées par des logiciels qui remplacent peu à peu presque toutes les activités. Notons au passage que les directions informatiques sont les premières victimes de cette malédiction : la productivité de tout le monde augmente (assistantes, archivistes, comptable, magasiniers,…) mais au prix de dépenses supplémentaires en informatique et d’une dépendance accrue aux infrastructures : le moindre problème de disponibilité du réseau d’entreprise amène à la DSI des foules d’utilisateurs mécontents.

Au total les métiers de l’informatique sont, de loin, le premier débouché scientifique.

Etudiants dans les domaines scientifiques aux Etats-Unis (source : BLS, 2015)

Par conséquent, il y a de plus en plus de personnes qui réalisent des logiciels ou les paramètrent – avec pour conséquence une hausse du nombre d’erreurs. Et ce d’autant :

• que les excellents développeurs sont rares. La productivité ou la qualité du travail peut varier dans un rapport de 1 à 20 d’un développeur à l’autre, ce qui explique à la fois l’envolée des salaires dans les entreprises qui cherchent à attirer ls meilleurs talents et les problèmes de qualité rencontrés par les entreprises qui pratiquent au contraire une politique de « low cost » sur leurs moyens informatiques ;
• que le développement logiciel est devenu en grande partie un travail d’ensemblier de système complexe, consistant à assembler des composantes commerciales ou open source (, D3.js, R, TensorFlow, Keras, Serverless, Apache, PrestaShop, Log4j…). Personne n’a une connaissance intime de chaque ligne de chacune de ces composantes, et chacune d’entre elles aura son lot de problèmes de qualité. On peut citer par exemple le problème massif posé récemment par Log4J [6]
• qu’une partie de ces développements est réalisée en dehors de tout cadre assurant un niveau minimum de qualité ou avec un sens des priorités douteux, à l’image de la citation prêtée à un responsable produit d’un éditeur logiciel « Je préfère un mauvais logiciel à un logiciel en retard : on pourra toujours faire un patch plus tard. »

Eviter les bugs : six causes à combattre

Le problème des défauts logiciels ne date évidemment pas d’hier et les analyses séparent six types de défauts :

1. les erreurs de spécifications (~2%) : le logiciel fait ce qui a été demandé, mais la demande ne correspondait pas au besoin – par manque d’écoute des utilisateurs finaux ou parce que les phases de pré-étude ont été bâclées ;
2. les erreurs de design (~12%), liées à des choix de solutions inadaptés pour répondre au besoin. Il peut s’agir d’erreurs techniques (choisir un algorithme déficient) ou d’interface utilisateur (application confuse à utiliser). Dans cette catégorie, on trouve par exemple la majorité des problèmes de l’application SNCF Connect ;
3. les erreurs de programmation (~17%), liées à une erreur d’un développeur. C’est l’exemple du bug d’Ariane 5, lié à un choix de type de variable inadapté [8] ;
4. les erreurs de documentation (~6%), liées à une documentation utilisateur fausse ou inadaptée. On peut classer dans cette catégorie les accidents aériens liés au fait que les pilotes n’ont pas été correctement préparés à agir dans les cas ou le logiciel de bord atteint ses limites [9];
5. les erreurs liées à des tests insuffisants ou les erreurs introduites lors de correction d’erreurs et (~16%). Une grande partie des erreurs est normalement corrigée en phase de tests, mais à l’inverse les « patchs » visant à corriger les erreurs de programmes mis sur le marché sont eux-mêmes des programmes, qui présentent leurs propres risques d’erreur (estimé entre 7% et 25% selon la complexité du système concerné). C’est le cas, par exemple, du problème rencontré par Windows en 2019 [10] ;
6. les erreurs de composants (38%), liés à des composants utilisés par le logiciel (base de données, site web,…), comme le composant Log4J évoquée plus haut.

Un développement réalisé par un éditeur leader dans son domaine contiendra 10 à 20 défauts par millier de lignes de code détectés durant la phase de tests. Il restera un à cinq défauts pour dix mille lignes de code dans les produits mis sur le marché, en fonction de l’intensité des efforts de l’entreprise [11] pour améliorer la qualité de ses logiciels, dont environ deux tiers seront identifiés lors de la première année d’utilisation. L’idée selon laquelle les utilisateurs d’un logiciel nouveau sont des « testeurs malgré eux » repose donc sur une réalité statistique !

On notera que cette analyse n’e comprend pas les erreurs liées au matériel – en effet aucun ordinateur n’est parfaitement fiable, et des phénomènes tels que les rayons cosmiques causent régulièrement des modifications du contenu de la mémoire des ordinateurs [12] [13] à un taux estimé à environ une erreur pour 256 mégaoctet. Les mémoires haut de gamme comprennent à cet effet des systèmes de correction d’erreur.

Une liste exhaustive des méthodes pour assurer une meilleure qualité logiciel dépasse largement le cadre de cet article, mais on peut citer l’existence d’une démarche de qualité de bout en bout (incluant le soucis de qualité et la conception des jeux de test dès le début du projet plutôt qu’en fin de développement), l’organisation du projet (une approche silotée séparant le projet d’amélioration des processus du projet informatique se traduit souvent par des écarts entre attentes et solutions), la qualité de la planification (des délais irréalistes ou une pression excessive sur les dernières phases de développement produisent immanquablement des erreurs) ou les méthodes de développement (les méthodes agiles bien maîtrisées responsabilisent plus les équipes au succès d’un projet digital).

(c) https://longterme.org https://longterme.fr

[1] The Cost of Poor Software Quality in the US: A 2020 Report, Consortium for Information & Software Quality

[2] https://fr.wikipedia.org/wiki/Mariner_1

[3] https://en.wikipedia.org/wiki/Pentium_FDIV_bug

[4] https://thestack.technology/cobol-in-daily-use/

[5] https://www.usinenouvelle.com/blogs/vincent-champain/le-digital-au-service-des-projets-complexes.N994949

[6] https://inrix.com/press-releases/2021-traffic-scorecard/

[7] https://fr.wikipedia.org/wiki/Log4j

[8] https://www.bugsnag.com/blog/bug-day-ariane-5-disaster

[9] https://flightsafety.org/asw-article/ice-blocks-a330-pitot-probes/

[10] https://www.zdnet.fr/actualites/bug-de-patch-windows-problemes-de-demarrage-aussi-sur-windows-10-39883523.htm

[11] Code Complete: A Practical Handbook of Software Construction, Steve McConnell

[12] https://www.bbc.com/future/article/20221011-how-space-weather-causes-computer-errors

[13] https://www.cnet.com/culture/google-computer-memory-flakier-than-expected/