Bugs à répétition, performances dégradées, failles débouchant sur des cyberattaques, retards dans les projets, dépassements de budget, plaintes récurrentes des utilisateurs ou clients, fastidieuses opérations de corrections. Les conséquences de la mauvaise qualité logicielle sont bien connues. Mais combien coûtent-elles ? C'est ce qu'a tenté d'estimer le CISQ, l'acronyme de Consortium for Information & Software Quality, dans un rapport paru en décembre dernier. En 2022, le consortium évalue à 2 410 Md$ le coût du phénomène pour l'économie américaine. Un total très significatif puisqu'il représente environ 10% du PIB des Etats-Unis. Et un total en croissance de 16% par rapport au précédent rapport du CISQ, en 2020. Notons que ce chiffre n'inclut qu'une partie de la dette technique qu'accumulent les entreprises et administrations américaines, une dette que le CISQ évalue globalement à 1 520 Md$ (voir graphique ci-dessous).

Le coût de la non-qualité logicielle selon le CISQ.

Le dernier rapport du consortium souligne un certain nombre de tendances alourdissant la facture de la mauvaise qualité applicative. La première d'entre elles réside dans la montée des menaces cyber. Le CISQ rappelle que les pertes directes associées aux cyberattaques ont bondi de 64% entre 2020 et 2021. En 2022, le coût moyen d'une violation de données aux États-Unis s'élevait à 9,44 m$, contre 9,05 millions l'année précédente. « Un autre bon moyen de voir à quel point la cybercriminalité est devenue un problème majeur consiste à rappeler la quantité d'argent que diverses organisations vont dépenser pour se protéger », glisse le CISQ, citant notamment les 10 Md$ que Google va consacrer au sujet sur cinq ans.

82% des composants open source sont obsolètes

Le rapport souligne également les conséquences de l'utilisation de composants standards, en particulier Open Source. En 2021, selon le rapport, 77% des organisations américaines ont accru leur recours au logiciel Open Source. Selon le CISQ, le nombre de défaillances dues à des failles dans des composants Open Source a progressé de 650% entre 2020 et 2021. Une croissance qui s'explique notamment par la vulnérabilité découverte dans la bibliothèque Open Source Log4j. « Une application de taille moyenne (moins de 1 million de lignes de code) exploite en moyenne 200 à 300 composants tiers », écrivent les auteurs du rapport, pour souligner l'importance prise par le phénomène de la supply chain logicielle. Et ses inévitables répercussions en matière de sécurité. D'autant que les organisations peinent souvent à estimer l'ampleur de leur dépendance aux composants Open Source. Une étude du cabinet Synopsys, parue en 2020 et basé sur l'audit de plus de 1 200 applications dans 17 secteurs d'activité, révélait ainsi que la quasi-totalité d'entre elles embarquaient des composants Open Source et que 82% de ces composants étaient obsolètes (soit non patchés, soit dans une version qui n'étaient plus supportée).

Troisième tendance clef soulignée par le CISQ : l'impact croissant de la dette technique, concept inventé en 1992 par l'informaticien américain Ward Cunningham qui regroupe tous les coûts différés générés par un code de mauvaise qualité. Pour le consortium, l'importance prise par ce phénomène en fait aujourd'hui « le principal obstacle à toute modification des bases de codes existantes ». Et le CISQ de souligner qu'en 2025, 40% des budgets IT pourraient être engloutis dans le maintien de la dette technique, devenant la première cause d'échec des projets de modernisation. « Une grande partie de la dette actuelle provient de techniques de développement "quick and dirty", par exemple, du développement agile sans discipline de génie logiciel », écrivent les auteurs du rapport. Un fardeau qui pèse sur le quotidien des développeurs. Une étude estime ainsi que ces derniers consacrent un tiers de leur temps de travail tant pour réduire la dette technique qu'en efforts supplémentaires dus à l'existence de cette dette.

Les promesses des nouveaux outils et standards

Si le rapport dresse un état des lieux assez alarmant, il souligne également la montée en puissance de nouveaux outils pour cartographier et gérer les dépendances logicielles, ainsi que l'existence de standards et outils pour réduire la dette logicielle. « Il s'agit là des leviers les plus prometteurs pour commencer à reprendre le contrôle sur le problème de la mauvaise qualité des logiciels », écrit le CISQ, soulignant notamment les promesses de l'IA et du Machine Learning dans l'ingénierie logicielle. Mais ce sont avant tout les pratiques des entreprises qu'il faut transformer, observent les auteurs. « En pratique, un pourcentage important du coût d'un projet logiciel n'est pas consacré à l'activité créative de construction du logiciel, mais plutôt à l'activité corrective de débugage et de correction d'erreurs. Une tâche intrinsèquement complexe. La plupart des systèmes ne disposent pas de spécifications formelles décrivant le comportement prévu du programme. Or, sans une documentation formelle ou systématique du comportement correct, la définition d'une "erreur" ou d'un "bug" réside souvent dans l'esprit de l'ingénieur logiciel ou dans les attentes - parfois nébuleuses - de l'utilisateur. » Sur la durée de vie moyenne d'une application de grande ampleur - soit 25 ans -, environ 50 centimes de chaque euro dépensé partent dans la détection et la correction de bogues.