Des logiciels autodurcissables pour un avenir plus fiable

Notre dépendance au numérique nous pousse à investir beaucoup de ressources dans la sécurité technologique qui peut prévenir les pannes locales ou mondiales, comme l’explique Mauro Pezzè, professeur à la faculté d’informatique de l’université de Lugano (USI), dans un article publié par laRegione.

En juillet 2024, le monde s’est soudainement arrêté - les vols ont été annulés, les trains ont cessé de circuler, les médias se sont arrêtés, les banques et les centres financiers se sont emballés... - en raison d’une panne informatique mondiale, démontrant, s’il en était besoin, notre dépendance numérique. La faute à un bug dans la mise à jour de CrowdStrike, une société américaine de sécurité informatique comptant plus de 20 000 abonnés, qui a affecté les systèmes d’exploitation de Microsoft, avec des répercussions dans le monde entier.

Afin d’éviter ce genre d’épisodes, les informaticiens étudient comment développer non pas des systèmes exempts d’erreurs, mais des logiciels adaptatifs capables de les éviter et de s’auto-corriger de manière plus ou moins autonome. Mauro Pezzè , professeur de génie logiciel à la faculté d’informatique de l’université de Lugano et à l’université de Milan Bicocca, est l’un de ceux qui travaillent dans ce sens.

Professeur Pezzè, commençons par le cas de l’été dernier : comment une mise à jour peut-elle faire basculer le monde ?

Le logiciel est de loin le produit humain le plus complexe. Windows, par exemple, compte environ 50 millions de lignes de code. Nous avons atteint une telle taille qu’il n’est plus possible pour un seul esprit humain d’appréhender le système dans toute sa complexité, d’où la nécessité de créer une équipe composée de personnes aux compétences multiples. Lorsqu’un défaut est constaté, il est corrigé en ne touchant qu’à cet élément, qui doit être parfaitement intégré, sinon c’est la catastrophe. Windows est bien fait, mais il a presque 40 ans : quand on l’utilise, c’est comme si on volait sur un Boeing 747 des années 80, quand on le répare aussi

S’il n’y a pas de vue d’ensemble, n’y a-t-il pas de problèmes de connaissance ?

Bien sûr. C’est pourquoi, à l’Usi, nous n’enseignons pas seulement la programmation, mais aussi l’abstraction, c’est-à-dire la capacité à saisir la complexité et l’unicité du système au-delà des détails. Une capacité propre à l’être humain

Existe-t-il des logiciels sans erreur ?

Tout produit humain d’une certaine complexité ne peut être exempt d’erreurs. J’ai écrit un livre, je l’ai lu attentivement et à haute voix mot par mot, un éditeur l’a corrigé, il a été vérifié en prépresse, et pourtant il contient encore des erreurs. Et nous parlons d’un objet infiniment moins complexe qu’un logiciel.

Si quelque part le logiciel ou l’algorithme contient une erreur, n’y a-t-il pas un risque à continuer à le reproduire ?

Absolument. Les logiciels font autant d’erreurs que les humains, mais ils fonctionnent différemment et font donc des erreurs différentes. En effet, les logiciels ne sont pas intelligents, du moins pas au sens humain du terme. Ils nous permettent cependant de mieux travailler, de faire des choses que nous ne pourrions pas faire autrement ou que nous ferions en un temps presque infini.

Nous, les humains, lorsque nous faisons des erreurs, nous pouvons les remarquer et les corriger. Les logiciels ne le peuvent pas...

C’est précisément la raison pour laquelle l’Usi travaille sur ce qu’elle appelle un "système logiciel auto-cicatrisant", un système dans lequel le logiciel se corrige lui-même. Il est important que le logiciel soit toujours sous notre contrôle et qu’il soit utilisé intelligemment. Permettez-moi de vous donner un exemple. Personne ne construit un bâtiment pour qu’il brûle, mais un incendie est toujours possible, c’est pourquoi nous avons inventé des systèmes pour détecter le feu et l’arrêter avant qu’il ne se propage. En informatique, c’est la même chose : nous concevons le système de manière à ce qu’un court-circuit général ne puisse pas se produire

On ne corrige donc pas l’erreur, mais on bloque les conséquences....

Il y a deux axes de recherche : certains chercheurs étudient des systèmes pour corriger automatiquement l’erreur, quitte à suggérer des corrections au programmeur pour qu’il puisse la résoudre. D’autres, comme nous, tentent de la prédire et de la prévenir, car l’erreur ne peut être éliminée

Et ces systèmes fonctionnent-ils ?

Ils fonctionnent de la même manière que les systèmes de lutte contre les incendies : ce n’est pas qu’il n’y ait pas d’incendies aujourd’hui, mais il y en a beaucoup moins qu’au siècle dernier et que dans les pays qui accordent moins d’attention à la prévention. On peut donc dire que oui, ils fonctionnent bien, même si ce n’est pas de manière optimale. Bien sûr, l’auto-adaptation des systèmes de lutte contre les incendies a une histoire beaucoup plus courte et doit donc encore mûrir, mais sans elle, nous aurions eu plus de bogues qu’aujourd’hui

Arriverons-nous un jour à un logiciel capable de ne pas faire d’erreurs ?

Si nous faisons la distinction entre erreur et fiabilité, nous y sommes déjà : nous ne pouvons pas garantir que le pont ne s’effondrera pas, nous ne pouvons pas garantir que l’avion ne tombera pas, mais nous pouvons garantir un certain degré de fiabilité, ce qui signifie précisément que le logiciel est conçu pour éviter les erreurs. Exemple trivial : lorsque l’avion atterrit, il s’arrête et redémarre. À quoi cela sert-il ? Un homme au péage n’éteint pas et ne rallume pas sa voiture, n’est-ce pas ? L’intérêt est que si je sais qu’une erreur se produira tôt ou tard, mais que je sais aussi que cela ne se produira pas avant un certain temps (disons 24 heures), chaque fois que j’atterris, je réinitialise le système et je recommence à compter. C’est ce qu’on appelle le "temps moyen entre les défaillances" : personne ne peut garantir qu’un logiciel ne fera pas d’erreurs, mais on peut garantir qu’il fonctionnera de manière fiable pendant un temps suffisant.

Est-il possible de passer à l’étape suivante, celle des logiciels intelligents ou para-intelligents, qui sont non seulement auto-adaptatifs mais aussi auto-réparateurs ?

Oui et non. Nous parviendrons à des logiciels autoguérisseurs, c’est certain. En ce qui concerne le mot "intelligent", nous devrions en discuter. Nous, les humains, sommes capables de nous protéger contre certaines erreurs grossières parce que nous pouvons juger si quelque chose a du sens. Ce n’est pas le cas des logiciels. C’est pourquoi aujourd’hui, malgré tous les progrès, nous sommes toujours obligés d’écrire dans un langage strict, parce qu’il est ensuite interprété de manière stricte. Le langage naturel est ambigu, le langage de programmation est précis

Écrira-t-on encore des programmes ?

Les compétences vont se déplacer de plus en plus de l’écriture vers le test du programme. Quand j’ai commencé ma carrière, on disait que les tests étaient faits par ceux qui ne savaient pas programmer ; aujourd’hui, ceux qui sont ingénieurs logiciels font beaucoup de tests, parce qu’on est passé de la difficulté de programmer à la difficulté de vérifier la justesse du programme. Selon toute vraisemblance, un changement profond se produira : au lieu qu’un programmeur écrive le code, c’est une machine que quelqu’un vérifiera qui s’en chargera

Le comprendrons-nous ?

Probablement pas, tout comme nous ne comprenons pas beaucoup de choses complexes. Aucun ingénieur ne connaît tous les détails d’une voiture ou d’un avion, aucun linguiste tout le vocabulaire italien, mais un homme d’intelligence moyenne et d’éducation moyenne est capable de décrypter un texte, selon le niveau, d’une manière plus ou moins correcte et profonde. David Parnas, un universitaire qui a fait l’histoire du génie logiciel et qui a reçu un doctorat honorifique de l’Usi en 2009, affirme que le génie logiciel est une discipline qui nécessite le travail de plusieurs personnes : un programmeur peut lire et comprendre le fonctionnement de milliers de lignes de code, mais il n’est pas capable d’examiner un logiciel de la taille de ceux d’aujourd’hui en un temps fini

Les machines et les humains parlent-ils deux langues différentes ou similaires ?

Le langage de programmation est écrit de manière à ce que la machine comprenne non pas le sens de la chose, mais la manière de la faire, c’est donc un langage qui n’est pas intuitif. Peut-être qu’un jour la machine commencera à comprendre les termes du vocabulaire, elle comprendra alors les mots non plus comme un ordre de travail mais comme une entité en soi, un concept qu’elle appliquera ensuite

Il y aura donc une évolution sémantique ?

Probablement.

Vous avez expliqué qu’à l’USI vous n’enseignez pas seulement la programmation aux étudiants, mais aussi l’abstraction. À la lumière des dernières déclarations, qu’est-ce que cela signifie ?

Cela signifie que l’enseignement du langage de programmation n’est pas une fin en soi, mais un moyen. Je ne peux pas enseigner comment écrire un poème, mais je peux enseigner comment utiliser le langage pour écrire un poème. Nous enseignons différents langages de programmation non seulement parce que la richesse du langage est importante, mais aussi parce qu’elle permet de comprendre le concept de programmation qui les sous-tend, afin de pouvoir communiquer de la meilleure façon possible avec la machine. Un système d’autoréparation comporte quatre éléments de base : il doit surveiller le système, comprendre ce qu’il fait, prédire ou interpréter et enfin mettre en œuvre. En collaboration avec d’autres instituts de recherche, nous travaillons actuellement sur la deuxième composante, à savoir les données dont nous avons besoin et la manière dont nous pouvons les utiliser pour prédire une erreur. Je me rendrai bientôt en Suède pour participer à un atelier sur invitation où je présenterai nos résultats sur la prédiction des défaillances dans les nuages dynamiques

Existe-t-il d’autres domaines de recherche ?

Nous nous intéressons également aux "solutions de contournement automatiques", une idée qui me semble promise à un bel avenir. Il s’agit, lorsqu’une erreur est identifiée, de demander au logiciel de trouver - de manière précisément automatique - un morceau de code équivalent capable de faire la même chose que celui qui ne fonctionne pas. Jusqu’à présent, nous l’avons essayé sur Google Maps, avec de bons résultats.

Contenu produit et publié en collaboration avec laRegione.