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 pour la société des défauts de logiciels est difficile à estimer, mais il est certainement très élevé. Les évaluations vont jusqu’à 10% de la richesse nationale [1] –200milliards par an pour un pays comme la France–, soit un montant comparable à celui du coût du crime organisé (dont le chiffre d’affaires mondial repose de plus en plus sur le cybercrime). Ce coût comprend plusieurs composantes:
- 70% du coût sont liés aux conséquences des malfaçons logicielles. De tels défauts vont de la perte d’une sonde spatiale due à 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 détruire;
- 20% du coût sont liés à des problèmes d’obsolescence –c'est-à-dire le fait de tarder à réinvestir dans des technologies modernes et d’utiliser des logiciels archaïques de plus en plus difficiles à maintenir. On estime qu’il reste plus de 800milliards de lignes écrites en langage Cobol [4], dont les principes datent de 1959, encore en fonctionnement. Les défauts liés à l’obsolescence sont autant des problèmes logiciels que la conséquence de sous-investissements –de la même façon que les problèmes mécaniques d’une voiture dont le compteur atteint 500000kilomètres sont difficiles à imputer uniquement à ses concepteurs!
- 10% du coût total sont liés à l’échec total ou partiel des grands 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% d’entre eux échouent et la moitié ne tient pas l’ensemble des 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 –plutôt à la 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 États-Unis. Ce taux est plus bas dans d’autres pays car tous n’ont pas des réglementations aussi protectrices des consommateurs. On peut donc estimer qu’il donne une idée du taux de défauts dans l’industrie. En outre, la plupart des véhicules ont des difficultés à fonctionner normalement dans des conditions extrêmes (forte chaleur, grand froid, grêle ou pluie exceptionnelle, neige…). On compte par ailleurs un million de morts par an dues à l’automobile –soit un préjudice économique de l’ordre de 1000milliards de dollars. 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.
La situation est similaire pour les coûts de cybersécurité, qui résultent 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 3milliards de tonnes de carbone, soit un coût environnemental d’environ 300milliards de dollars sur une base de 100dollars la tonne de carbone. Que des solutions censées nous faciliter la vie conduisent finalement à un réchauffement climatique coûteux à éviter constitue un très gros «bug», qui concerne aussi le digital. Enfin, on peut noter que les automobilistes parisiens ont perdu l’équivalent de quatresemaines de travail dans les embouteillages en 2021 et arrivent à la deuxième place du classement effectué par la société Inrix [6]. Il s’agit là 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 que de plus en plus de tâches sont réalisées par des logiciels. Les directions informatiques sont les premières victimes de cette malédiction. La productivité de tout le monde (assistantes, archivistes, comptable, magasiniers…) augmente, mais entraîne des dépenses supplémentaires en informatique et une dépendance accrue aux infrastructures. Le moindre problème de disponibilité du réseau d’entreprise mécontente désormais d’innombrables utilisateurs. Dans les chiffres, les métiers de l’informatique sont, de loin, le premier débouché scientifique. Par conséquent, de plus en plus de personnes réalisent des logiciels ou les paramètrent, avec pour conséquence une hausse du nombre d’erreurs.
Étudiants dans les domaines scientifiques (STEM) (États-Unis, source: BLS, 2015)
Et ce d’autant plus que:
- les excellents développeurs sont rares. La productivité ou la qualité du travail d’un développeur peut facilement varier dans un ratio de 1 à 20, ce qui explique à la fois l’envolée des salaires dans les entreprises «digital natives» qui cherchent à attirer les meilleurs talents et les problèmes de qualité rencontrés par celles qui pratiquent au contraire une politique de «low cost» informatique;
- 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 le problème massif posé récemment par Log4J [6];
- une partie de ces développements est parfois réalisér en dehors de tout cadre assurant un niveau minimum de qualité ou avec un sens des priorités douteux. En témoigne 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.»
Éviter les bugs: six causes à combattre
Le problème des défauts logiciels ne date pas d’hier et les analyses en identifient six types:
- les erreurs de spécifications (environ 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;
- les erreurs de design (environ 12%), liées à des choix de solution 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). La majorité des problèmes de l’application SNCF Connect entre dans cette catégorie;
- les erreurs de programmation (environ 17%), liées à une erreur d’un développeur. C’est l’exemple du bug d’Ariane5, conséquence d’un choix de type de variable inadapté [8];
- les erreurs de documentation (environ 6%), dues à une documentation utilisateur fausse ou inadaptée. On peut classer dans cette catégorie les accidents aériens lorsque les pilotes n’ont pas été correctement préparés à agir dans les cas où le logiciel de bord atteint ses limites [9];
- les erreurs attribuables à des tests insuffisants ou celles introduites lors de correction d’erreurs et (environ 16%). Une grande partie est normalement corrigée en phase de test, 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és 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];
- les erreurs liées aux composants (38%) utilisés par le logiciel (bases de données, site web…), comme le composant Log4J évoqué 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] 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!
La liste exhaustive des méthodes pour assurer une meilleure qualité logicielle 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 les 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 un écart 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), 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).
-----
[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
