Une autre raison de moderniser les logiciels

Une publication à vocation légèrement propagandiste de Google, vantant les mérites de ses outils de développement maison, nous procure aujourd'hui l'occasion d'évoquer une raison trop souvent négligée de moderniser les logiciels qui s'accumulent dans les systèmes d'information des grands groupes, du secteur financier ou autre.
L'exemple provient de Mercari, une place de marché généraliste japonaise, qui a entièrement réécrit les interfaces graphiques de son application mobile pour la plate-forme Android (vieilles de 7 ans et comprenant plus de 130 écrans) avec le kit de développement de dernière génération Jetpack Compose. Elle a pu de la sorte réduire son volume de code de 355 000 lignes, ce qui représente plus des deux tiers (69%) de l'ancienne version, en améliorant au passage l'ergonomie, la rapidité d'exécution…
Les arguments classiques destinés à justifier les programmes de refonte de grande ampleur relèvent habituellement de ces dernières considérations, en invoquant les progrès technologiques au bénéfice de services enrichis et plus performants pour les utilisateurs. Dans le cas des entreprises, telles que les banques et les compagnies d'assurance, qui entretiennent un patrimoine âgé de plusieurs décennies, l'obsolescence des plates-formes sous-jacentes est également un puissant levier de décision.
L'expérience de Mercari en souligne donc un autre, aussi sensible, que je résume à la capacité à garder le contrôle sur un actif en expansion permanente et irrémédiablement soumis aux lois de l'entropie. Deux effets complémentaires se combinent afin de résorber les empilements de code aux conséquences délétères (dérivées de la complexité croissante à en appréhender une vision globale et à en comprendre le fonctionnement, exigences essentielles pour une gestion efficace de la maintenance et des évolutions).
En premier lieu, un remplacement complet de l'existant, y compris s'il se contentait d'une réplique à l'identique, permet d'éradiquer les vestiges des ajouts et remaniements partiels historiques, de rationaliser l'architecture de l'ensemble et de repartir d'une base « propre ». Peut-être moins évidente mais encore plus percutante est la simplification radicale que peut apporter un outillage récent, grâce à une abstraction toujours plus élevée, autorisant la création d'une même opération avec moins d'instructions.
Entre une structure générale plus claire et un code beaucoup plus sobre, les développeurs, notamment ceux qui interviennent ultérieurement, gagnent en lisibilité, surtout dans l'hypothèse d'adoption d'une approche qui privilégie un modèle déclaratif (à l'instar de Jetpack Compose) par rapport à la programmation, et peuvent ainsi mieux détecter les erreurs présentes et éviter d'en introduire d'autres. La qualité des livraisons comme la productivité s'en ressentent immédiatement, comme le confirme Mercari.
Naturellement, la médaille a son revers, à savoir la dépendance grandissante vis-à-vis des fournisseurs de ces solutions. Car les services de haut niveau qu'ils proposent embarquent nécessairement la complexité qu'ils masquent à leurs utilisateurs et ils sont exposés aux dysfonctionnements comme les autres. En revanche, leur exploitation dans de nombreux contextes, par une vaste population de professionnels, limite en principe ces risques… en tous cas pour les éditeurs les plus sérieux et les plus populaires.
La conservation de logiciels pendant des durées excessives constitue une cause majeure d'immobilisme, en particulier dans les grandes organisations, et les tentatives de « digitalisation » poussives qui s'appuient sur de tels socles en fournissent la preuve chaque jour. Afin d'éliminer ce goulet d'étranglement de l'innovation, il serait indispensable de fixer une date de péremption sur chaque composant, dès sa conception, et d'inscrire dès l'origine les modalités de décomissionnement dans le plan du projet correspondant.