Les logiciels sont omniprésents dans nos vies : apps, logiciels bancaires, gestion des ressources humaines, salaires, gestion des hôpitaux, réservations de billets, voitures, mais aussi outils de surveillance du territoire, serveurs, machines-outils, lance-missiles et bien d’autres encore. Autant de logiciels qui doivent évoluer pour prendre en compte le fait que les règles, les usages et la société changent. Qui voudrait être forcé de réserver son billet de train sur un bon vieux Minitel ? Personne. Qui voudrait être forcé d’être opéré avec du matériel médical de 1970 ? Personne. De même, les logiciels doivent être constamment adaptés et améliorés pour prendre en compte les changements incessants de nos vies et sociétés.
Imaginons un monde où, tous les 10 ans, l’écartement des rails des trains, la résistance des poutres de rails, le format et le voltage des prises électriques changeraient. Et bien, ce monde est le monde du développement logiciel.
Dans ces conditions, on pourrait imaginer qu’il serait judicieux de juste jeter les vieux logiciels pour en développer de nouveaux. Or, cela s’avère compliqué pour plusieurs raisons.
Pourquoi on ne jette pas les anciens logiciels
Tout d’abord, ces logiciels sont souvent indispensables au bon fonctionnement des sociétés qui les utilisent : sans eux, plus de business. Personne n’imagine un supermarché sans logiciel de gestion de stock ! Il n’est donc pas possible de s’en abstraire.
Ensuite, développer un logiciel est un processus long et coûteux pour les entreprises. Ceci est d’autant plus vrai que près d’un projet sur trois est un échec : soit il a été abandonné avant la fin de son développement, soit il a connu des dépassements en temps de développement ou en argent, soit il ne répond pas parfaitement aux besoins des utilisateurs. Réécrire un logiciel veut également dire être capable de bien capturer correctement le business et le domaine dans lequel il devra s’inscrire. Il y a quelques années, la refonte du logiciel de paye des militaires a été un tel fiasco que le ministre lui-même a dû prendre des mesures. Ce chantier a d’ailleurs coûté énormément d’argent à l’état français.
Par ailleurs, tout développement de logiciel apporte son lot de bugs. Les techniques de développement (telles que le développement agile, l’utilisation intensive des tests, l’intégration continue…) permettent de réduire leur nombre avant de livrer le logiciel aux clients, mais il est fréquent qu’il en reste. En conséquence, réécrire les logiciels s’avère souvent dangereux : un logiciel qui a évolué les 30 dernières années a eu des années de correctifs visant à corriger ses failles et ses bugs.
Enfin, les utilisateurs sont réticents aux changements. Il arrive fréquemment que des utilisateurs se plaignent car la position ou la couleur d’un bouton a changé. Face à un logiciel entièrement nouveau, avec de nouvelles interfaces graphiques, ils peuvent se retrouver complètement perdus.
Dans ces conditions, on peut aisément comprendre que les entreprises, quelles qu’elles soient, cherchent à garder le plus longtemps possible un logiciel sur lequel s’appuie une grande partie de leur fonctionnement.
Il va donc falloir maintenir ces logiciels pour répondre à de nouveaux besoins des utilisateurs, à de nouvelles lois, à de nouvelles technologies… En effet, seuls les logiciels qui sont des succès, c’est-à-dire qui sont utilisés, sont maintenus.
La maintenance des logiciels
Il existe deux grands types de maintenance : celle qui intervient au jour le jour et qui concerne une infime partie du logiciel, et celle qui intervient plus rarement, mais qui concerne une grande partie du logiciel. Dans le premier cas, une vision microscopique est suffisante, alors que dans le second une vision à la fois macroscopique et microscopique, globale, mais précise est nécessaire. C’est de ce type de maintenance qu’il est question ici.
La maintenance d’un logiciel est souvent très compliquée, et engendre souvent un très gros stress sur les développeurs et les sociétés qui doivent maintenir ces logiciels. Ceci peut s’expliquer par plusieurs raisons.
La complexité des logiciels. Bien qu’abstrait pour la plupart des personnes et occupant autant d’espace sur un disque dur que quelques chansons MP3, un logiciel a souvent une très grande complexité. À titre d’exemple, si on avait imprimé en 1993 le code de Windows sur du papier A4, on aurait eu plus de pages que l’Encyclopædia Britannica (en 15 volumes) ou un étage d’immeuble. Dix ans plus tard, imprimer le code de Windows 2003 aurait donné une pile de papiers plus haute que la Statue de la Liberté. Depuis, la quantité de code n’a fait qu’augmenter.
La durée de vie des logiciels et le renouvellement des équipes. La durée d’un logiciel est dictée par le business, la possibilité de répondre aux besoins des clients dans un temps donné et la possibilité d’investissement de la société éditrice. Il est clair que la majorité des applications mobiles n’ont pas la même durée de vie que des logiciels qui font tourner des sociétés entières. Ceux-ci peuvent avoir une durée de vie de 20 à 30 ans.
Cette longue durée de vie implique que, souvent, les développeurs qui ont conçu ces logiciels ne sont pas ceux qui doivent (ou devront) les maintenir. Cela rend l’évolution des logiciels encore plus délicate : il est difficile de travailler sur des programmes que l’on ne connaît pas et que l’on ne comprend qu’imparfaitement. De plus, il est fréquent que plusieurs personnes ayant des façons de coder différentes soient intervenues.
L’utilisation de langages de programmation aujourd’hui inconnus. Finalement, certains très grands systèmes (utilisés entre autres par les banques ou les assurances, et ayant un rôle central pour ces entreprises) sont écrits dans des langages que même Google ne « connaît » pas (comme Mantis). D’autres langages ont très peu de documentation en ligne (comme Natstar). Cela veut dire que très peu de personnes les connaissent.
Un exemple de besoin de maintenance. La société Berger-Levrault utilise de façon massive dans les logiciels qu’elle développe du GWT (Google Web Toolkit) pour leurs parties graphiques. Enfin, ça, c’était avant. En effet, GWT n’a plus évolué depuis 2015 et n’est plus maintenu par Google. En conséquence, les nouveaux navigateurs web ne supporteront bientôt plus cette technologie, et il devient difficile pour les développeurs de faire des corrections ou des améliorations. Il est donc indispensable pour l’entreprise de changer de technologie et d’en utiliser une plus récente. L’entreprise a estimé qu’il lui faudrait plus de 8000 jours-homme (c’est-à-dire le travail d’une personne pendant environ 22 ans), et donc plusieurs années avec une équipe de plusieurs développeurs, pour migrer une application vieillissante et passer les interfaces graphiques de GWT à Angular. Or, d’ici là, la technologie cible d’aujourd’hui sera devenue obsolète ; ils devront recommencer une deuxième migration avant même d’avoir fini la première.
Cependant, des outils informatiques peuvent aider à raccourcir ce type de migration.
Radiographier les vieux logiciels pour une migration plus efficace
Pour faire face à ces défis modernes, notre équipe, RMOD, ainsi que d’autres équipes dans le monde, développent des outils qui vont aider les développeurs à mieux connaître leur logiciel, et aider à la prise de décisions.
Nos outils fonctionnent comme les rayons X pour le corps humain, mais sur les logiciels. Grâce à eux, les développeurs peuvent obtenir des cartes de leurs logiciels à différents niveaux de granularité. Les informations retirées des logiciels peuvent être de plusieurs natures :
Comment le logiciel est structuré ?
Quelle est la partie la plus utilisée ?
Est-ce que la qualité d’une partie est bonne pour être réutilisée ?
Quelles sont les parties qui sont testées ?
De plus, un architecte ou développeur peut aussi définir des requêtes spécifiques que seul lui (en tant expert du domaine et du logiciel) peut avoir envie ou besoin d’exprimer. Il est difficile pour nous d’illustrer sans être technique, mais voici quelques exemples. Quels sont les sous-programmes qui utilisent la classe X, sachant que normalement il ne doit y avoir qu’un seul utilisateur de la classe X ? Est-ce que l’on peut couper ce programme en deux, en considérant que les données bleues sont toutes appelées par des opérations bleues, et pareil pour les rouges (si on considère ces couleurs comme des propriétés d’éléments de programmes) ? Quelles sont les opérations qui utilisent à la fois les deux couleurs et empêchent le découpage ?
Mais nous pouvons aussi extraire des informations relatives aux développeurs responsables de telle ou telle partie du logiciel. En effet, il existe une métaphore un peu macabre qu’on appelle le Truck factor (le « facteur camion »), qui exprime la chose suivante : quel est le risque pour le logiciel (et donc pour l’organisation qui l’utilise) si un des développeurs est écrasé par un camion, ou, d’une manière moins violente, s’il quitte son emploi ? Quelle quantité de savoir ce développeur emmène-t-il avec lui ? Quelle information la société perd-elle sur son logiciel ? En effet, nous l’avons vu plus haut, devoir travailler sur un logiciel que l’on ne connaît pas ou peu est bien plus délicat que si on le connaît parfaitement.
Enfin, nos outils permettent également d’aider les développeurs à réorganiser leur système, par exemple pour le rendre plus modulaire. Ainsi une partie pourra être changée ou utilisée séparément sans impacter le reste du système, rendant ainsi la maintenance plus simple et moins chère.
De telles solutions permettent de migrer automatiquement une partie de l’application, et peuvent faire gagner plus de 60 % du temps. Par exemple, une architecte d’une grande firme allemande nous disait passer 7 mois pour une tâche de restructuration manuelle du code d’une application stratégique pour la société alors qu’avec nos outils, elle fait la même tâche en deux semaines.
Cet article a été écrit en collaboration avec Nicolas Anquetil, maître de conférence en informatique et génie logiciel à l'Université de Lille