Informatique éternelle : comment faire pour que le code reste fonctionnel pendant des décennies ?
Toute personne qui a déjà dû reprendre du code écrit par quelqu’un d’autre connaît les défis de la maintenance en développement informatique. « Les logiciels modélisent le monde, et le monde change. Du coup on doit les maintenir et les faire évoluer » explique Stéphane Ducasse, directeur de recherche de l’EVREF à l’INRIA. L’EVREF ? C’est l’équipe commune à l’INRIA et à l’éditeur de logiciel historique Berger-Levrault, qui a pour but « l’évolution réflexive des systèmes logiciels éternels ». À l’initiative du terme d’informatique éternelle, Stéphane Ducasse détaille le cas typique auquel cherche à répondre son équipe. « Berger-Levrault avait la plus grosse application GWT [Google Web Toolkit] au monde. Problème : Google cesse de maintenir cet ensemble d’outils. L’entreprise veut migrer l’application vers un nouveau langage, mais cela prendrait 36 années-homme pour se faire. Nous leur avons fourni une plateforme pour migrer vers Angular en réduisant ce temps de 60% ».
Cela illustre bien les problèmes qu’ont les entreprises qui doivent maintenir de larges programmes informatiques sur plusieurs années, voire plusieurs décennies. L’environnement change, et il change vite.
Parfois c’est le langage utilisé qui n’est plus adapté. « La fonction GOTO [présente dans les anciennes version de Fortran, le BASIC, etc] est depuis longtemps considérée comme une mauvaise pratique, et est quasiment impossible à maintenir », assène Marie-Claude Gaudel, professeur émérite à l’université Paris Sud et grande théoricienne du code informatique.
Autre problème : même si le code lui-même peut être maintenu, il dépend toujours de la machine sur laquelle il fonctionne, ou plus précisément de son architecture. Pour simplifier, tous les grands langages de programmation modernes sont conçus pour être à peu près compréhensibles par un être humain, avec des instructions en anglais comme « while… », « if… », etc. Ces instructions sont traduites par un compilateur en langage machine, soit une suite de chiffres binaires. Cette suite de chiffres est spécifique à une architecture de processeur. Plusieurs générations de processeurs peuvent utiliser la même architecture, comme l’architecture x64 sous laquelle fonctionnent la plupart des processeurs depuis 2003. Changer de processeur n’implique donc pas forcément de devoir recompiler tout un programme. Il existe aussi d’autres architectures, comme l’ARM utilisé notamment par Apple dans ses ordinateurs et smartphones. C’est pourquoi on trouve souvent des logiciels ayant une version PC, et une version ARM.
Mais comment faire si le logiciel phare de son entreprise a été écrit avant 2003 dans une ancienne architecture ?
« Il y a longtemps, j’avais discuté avec un développeur qui était chargé de la maintenance des postes d’aiguillage Alstom. Or, la SNCF demande une garantie de plus de 40 ans. Il fallait donc prévoir de garder en état de marche des anciens ordinateurs dans un entrepôt, avec le système d’exploitation de l’époque », raconte Marie-Claude Gaudel. Il est possible de créer une VM (machine virtuelle, un clone numérique d’un matériel informatique précis) de l’architecture en question, mais cela prend du temps et de l’argent, et reste donc en général une solution propriétaire qui n’est pas toujours adaptée.
Enfin, il existe ce que Stéphane Ducasse nomme prosaïquement le truck factor, ou facteur camion/bus. Que se passe-t-il si l’un des développeurs clé d’un projet se fait renverser par un bus, tombe malade, part chez le concurrent, ou se retrouve en incapacité de continuer à contribuer d’une manière ou d’une autre ?
Si cette dépendance critique n’a pas été gérée par les ressources humaines, il faut pouvoir continuer à avancer dans le projet, même sans cette personne. Cette vulnérabilité peut d’ailleurs provenir de l’extérieur de l’entreprise, comme l’exemple de XZ Utils l’a démontré. Cette bibliothèque de compression open source, gérée par un seul volontaire depuis des années, s’était retrouvée hackée en 2021 par une personne mal intentionnée, affectant des millions d’utilisateurs en les exposant à une attaque de type backdoor. Il lui avait suffit de proposer plusieurs contributions au code, et de faire pression sur ce volontaire pour qu’il accepte de lui accorder des droits de modification sur le code source du logiciel. D’où l’importance pour les entreprises de contribuer financièrement et humainement aux projets open source dont leur infrastructure dépend.
Comment faire, alors, pour pallier ces problèmes fondamentaux qui minent la durabilité du code dans le temps ? L’équipe EVREF apporte un début de solution avec un outil capable d’automatiser en partie la mise à jour d’un programme informatique de grande taille. « L’outil va venir lire toutes les lignes de code dans l’application, et en retirer un modèle. Au lieu de voir des lignes de code, on va voir cette application sous forme de boîtes et de flèches, et savoir qui appelle quelle fonction », expose Benoit Verhaeghe, manager de projet scientifique chez Berger-Levrault. « Cela permet, par exemple, d’identifier un élément à moderniser, comme un élément d’interface graphique, et la plateforme va traduire en code la nouvelle boîte, qu’il restera à intégrer manuellement. »
L’idée est d’éviter de devoir lire chaque ligne du programme à moderniser ou migrer à la main, et de le considérer comme une boîte noire avec ses entrées et sorties. « Il faut prendre l’exécutable comme oracle », imagine Marie-Claude Gaudel. « La possibilité de faire des requêtes et de questionner le système est très importante », renchérit Stéphane Ducasse. « Nous avons besoin d’une cartographie des fonctions sous-jacentes du logiciel, de sa logique. Notre plateforme est comme un rayon X permettant de comprendre son fonctionnement, trouver le code mort, etc. Avec notre outil, ces requêtes peuvent être automatisées ». À noter que cela n’est possible que si l’entreprise dispose encore du matériel nécessaire pour faire tourner le code.
La plateforme de l’EVREF, dénommée MOOSE, sert aussi à définir et automatiser les tests d’une application, des indicateurs qui font remonter les erreurs lors de l’exécution du code. « Si l’on veut faire un parallèle avec l’industrie traditionnelle, notre outil permet de faire de la maintenance préventive pour une machine. Comme si l’on avait développé un scanner HD pour code informatique qui nous permettait d’identifier les problèmes avant qu’ils arrivent Comme si l’on avait développé un scanner HD pour code informatique qui nous permettait d’identifier les problèmes », expose Benoît Verhaeghe.
Les entreprises comme Berger-Levrault peuvent alors faire appel à l’EVREF et identifier de manière automatisée les parties problématiques de leur code, ou bien en identifier le schéma logique pour le faire migrer ou le mettre à jour. « Parfois dans un programme les abstractions sont cachées. Ce qui est intéressant c’est le modèle sous-jacent, les règles métier », synthétise Stéphane Ducasse.
En prenant de la hauteur, il s’agit en effet de penser le code non pas comme un jeu d’instructions gravé dans le marbre, mais au contraire comme une traduction forcément éphémère d’une logique propre à un secteur d’activité. Les besoins d’une entreprise, d’un laboratoire ou d’une administration sont convertis en code à un moment T. Si ce code est bien écrit, bien commenté et bien maintenu, il pourra durer plusieurs décennies, peut-être à moindre coût grâce à des outils comme ceux d’EVREF. Mais garder en tête une vision algorithmique, une vision purement logique des opérations qu’effectuent le code, c’est garder le savoir-faire numérique sur le temps long.
« Ce que fait EVREF est un premier pas [vers l’informatique éternelle], il adapte le code », reconnaît Marie-Claude Gaudel. Mais pour atteindre la notion de programme informatique réellement durable dans le temps, il faut aller plus loin. Première étape : préserver le matériel sur lequel le code tourne, soit en l’état, comme pour le poste d’aiguillage Alstom, soit à l’aide d’une machine virtuelle. Il existe plusieurs associations vouées à la conservation du matériel électronique et informatique, comme Aconit et WDA, mais la question reste peu abordée au niveau national et institutionnel.
Le choix du langage de programmation est aussi fondamental pour sa durabilité dans le temps. La plateforme de conception automatique de tests MOOSE a par exemple plus de mal à traiter le Python, un langage où l’espace a un sens, et les langages anciens comme Fortran et Cobol. Le meilleur langage pour la préservation ? « Le langage algorithmique, compréhensible par tous », lance Marie-Claude Gaudel. Soit une écriture purement logique, qui ne dépend pas d’un langage de programmation en particulier.
Enfin, il ne faut jamais oublier que tout programme informatique est conçu par des humains, pour des humains. « L’expertise d’un domaine est souvent codée dans le logiciel. Règles comptables, d’administration… » explique Stéphane Ducasse. Penser le code comme un dépositaire forcément temporaire et imparfait de l’expertise humaine permet de comprendre l’atout que représente les spécialistes d’une industrie ou d’un domaine. Préserver le code, c’est donc aussi préserver le savoir-faire humain.