Pourquoi les logiciels fiables sont-ils surprenants ?

Joao Correia

28 juin 2024 - Évangéliste technique

Post Views : 15

Les logiciels se présentent sous toutes les formes et tailles : applications monolithiques, petits utilitaires, intergiciels courants, plateformes web, applications mobiles, etc. Mais il semble qu'il soit de plus en plus difficile d'en trouver un qui fonctionne réellement comme annoncé.

Une agréable surprise

Récemment, j'ai eu l'occasion de participer à une série d'entretiens avec certains de nos partenaires et clients, afin d'évaluer leur satisfaction et d'obtenir un retour d'information sur nos produits. Un point commun revenait sans cesse : "votre logiciel [KernelCare Enterprise] fonctionne tout simplement. Nous l'avons déployé et nous ne nous en sommes jamais vraiment préoccupés par la suite.

Mon opinion, évidemment très partiale, est que "bien sûr que ça marche". Mais c'est à peine si j'ai effleuré la surface. Le vrai problème est qu'il s'agit d'un fait pertinent en soi - les logiciels fonctionnant comme prévu, sans conditions ni scénarios bizarres, semblent si rares qu'il est intéressant de noter que quelque chose "fonctionne tout simplement".

Pensez-y : combien de fois avez-vous utilisé un logiciel dans lequel vous n'avez pas eu à lutter contre des paramètres par défaut mal définis, des options peu judicieuses, des interactions bizarres ou des bogues difficiles à reproduire déclenchés par quelqu'un qui toussait un peu fort dans la pièce d'à côté ?

Pourquoi les logiciels ne sont-ils pas fiables ?

Il est plus difficile à définir que ce à quoi il ressemble. La première réponse, la plus évidente, est qu'il est tout simplement trop complexe à créer. Il existe un nombre de plus en plus complexe d'éléments nécessaires pour réaliser même l'ensemble de fonctionnalités le plus basique (selon les normes actuelles), de sorte que même les applications les plus basiques utilisent de nombreux cadres, bibliothèques et codes tiers, de sorte qu'il est difficile de les relier de manière fiable sans conséquences imprévues.

Le problème de la complexité croissante est particulièrement délicat à résoudre, car à mesure que le code devient de plus en plus complexe, il faut de plus en plus de puissance cérébrale pour le résoudre. Le cerveau humain n'évolue pas assez vite pour rivaliser, il faut donc augmenter le nombre de cerveaux pour résoudre le problème. Il s'avère que il s'avère que nous n'avons pas assez de développeurs pour résoudre le problème de manière significative. Par conséquent, nous laissons la complexité croître sans contrôle.

Mais ce n'est là qu'un aspect du manque de fiabilité des logiciels. Un autre aspect intéressant est que les cycles de développement des logiciels, bien que plus complexes, sont également soumis à une pression croissante pour être plus courts et plus rapides. Comme verser du gaz sur une flamme nue, c'est un autre moyen infaillible d'introduire des failles dans le code qui conduisent à des failles dans le programme.

Mais nos méthodologies de test évoluent-elles aussi et permettent-elles de détecter davantage de bogues avant la mise en production ? Eh bien, pas au même rythme. Il est vrai que les essais de logiciels, en tant que sous-ensemble du développement de logiciels et partie intégrante du cycle de développement de logiciels, ont également évolué. De meilleurs outils et de meilleures pratiques permettent de tester et d'identifier les bogues plus tôt dans le processus, idéalement à un stade où il est encore possible d'y remédier sans retarder considérablement les dates de livraison. Toutefois, cela permet de lutter directement contre la complexité et le raccourcissement des cycles et, une fois encore, il ne suffit pas de résoudre tous les problèmes en permanence.

Nous avons également tendance à attendre des logiciels qu'ils fonctionnent plus longtemps que leur durée de vie prévue. Une application conçue, développée et publiée cette année, avec une base de déploiement solide, sera probablement encore utilisée quelque part, d'une manière ou d'une autre, d'ici 5 ou 10 ans. Cela nécessite une maintenance. Il ne s'agit pas nécessairement d'ajouter de nouvelles fonctionnalités, mais de boucher les trous qui apparaîtront inévitablement au fil du temps, ne serait-ce qu'en raison des interactions inattendues et imprévisibles avec d'autres logiciels au fil des ans. Ce travail de maintenance est effectué par des personnes issues du même vivier, déjà rare, de développeurs talentueux qui écrivent des logiciels.

La cybersécurité suscite également une inquiétude croissante qui n'existait pas il y a dix ans. De plus en plus de logiciels sont soumis à des tests de vulnérabilité, et de plus en plus de ces vulnérabilités sont découvertes dans les codes les plus improbables. Ce fait aggrave le problème de fiabilité en transformant ce manque de fiabilité d'un problème d'utilisation en un problème de sécurité.

Et ce n'est même pas un problème nouveau. Nous ("nous" comme dans l'espace informatique collectif) nous préoccupons de la fiabilité des logiciels depuis des décennies. préoccupés par la fiabilité des logiciels depuis des décennies (à tel point que même les sources des travaux de recherche sur la fiabilité les plus anciens ne sont plus disponibles et que la plupart de ces travaux sont antérieurs à l'Internet).

Des idées pour y remédier ?

En d'autres termes, nous devons faire plus de développeurs, et la méthode biologique pour y parvenir semble un peu lente pour résoudre correctement le problème existant aujourd'hui. À moins que cela ne se produise, les alternatives viables impliqueront probablement une combinaison de réduction de la complexité dans le développement de logiciels - en réduisant la portée des applications, par exemple. Toutes les applications n'ont pas besoin d'une composante IA, ni même d'une composante en ligne.

Les possibilités de réduire la complexité du développement de logiciels sont nombreuses : s'assurer que les décideurs sont conscients qu'il vaut mieux, pour de multiples raisons, prendre plus de temps pour développer et publier des applications résilientes et plus utiles que de se précipiter sur le code dès qu'un ensemble de fonctionnalités minimalement viables est atteint, ce qui laisse aux développeurs plus de temps pour tester et détecter les problèmes ; automatiser les tâches qui peuvent déjà l'être en utilisant les outils et méthodes existants plutôt que d'essayer de réinventer la roue pour chaque application, comme, par exemple, mettre à jour des mécanismes qui sont différents selon les applications alors qu'ils ne devraient pas l'être et qu'ils n'ont aucune raison de l'être ; et adopter une posture de cybersécurité qui privilégie des logiciels plus fiables plutôt que le dernier et le plus grand battage médiatique du moment.

Mais en vérité ? Nous aimons les lumières brillantes et aveuglantes de tout ce qui est nouveau. Nous montons à bord du prochain train à grande vitesse avec autant d'enthousiasme que le précédent, après des promesses vides et des livraisons décevantes. Puis nous nous plaignons que les choses ne fonctionnent pas comme elles le devraient, et nous sommes surpris par les rares exemples où la fiabilité est une caractéristique déterminante.

C'est un environnement intéressant où quelque chose qui devrait être banal devient suffisamment pertinent pour briller.