Gouvernance
Dette technique ou patrimoine : une question d’équilibre avant tout
Par François Jeanne, publié le 25 octobre 2022
ERP, langages, AGL, historiques de données…. ces candidats à la dette technique
Il n’y a pas que les infrastructures à se transformer avec le temps en legacy et en cailloux dans la chaussure des DSI. Les bases de données et ce qu’elles contiennent, mais aussi les progiciels, ERP en tête, peuvent aussi devenir de redoutables îlots d’immobilisme dans le système d’information. Quant aux langages les plus récents et aux composants open source destinés aux environnements de travail, leur vitesse d’obsolescence en font de véritables pièges en puissance.
Il y a 25 ans, lorsque les premiers ERP se sont déployés dans l’entreprise en remplacement de logiciels maison dont le code avait été rendu inextricable avec le temps, les DSI de l’époque ont poussé un ouf de soulagement. Leurs successeurs doivent se demander pourquoi ils se retrouvent dans une situation finalement analogue, alors qu’un SAP, par exemple, pousse aujourd’hui ses clients à adopter SAP S/4HANA, en annonçant la fin du support de R3 d’ici 2030 (aux dernières nouvelles).
« Les ERP sont effectivement censés résorber de la dette technique, en amenant vers des standards. Mais les premières générations d’implémentations n’ont pas résisté à l’envie de vouloir tout rendre possible, en développant des spécifiques qui se révèlent aujourd’hui trop éloignés des standards pour que même de simples montées de versions puissent s’effectuer sans douleur », analyse Eric Delgove, senior technology partner chez Deloitte Conseil. À noter tout de même que l’éditeur allemand, sans doute conscient des réticences qui pourraient naître de cette marche forcée vers un standard imposé, propose avec SAP Business Technology Platform (BTP), une solution d’hébergement (PaaS) censée accueillir les spécifiques de ses clients, ceux qui existent déjà ou ceux à venir.
Trop de spécifiques alourdit la dette
Chez le concurrent Oracle, on reconnaît aussi la difficulté : « Avec le temps, nos clients ont utilisé nos produits pour leurs applications critiques, avec des exigences de MCO (Maintien en condition opérationnelle) élevées et le degré de customisation qui va avec. Ce sont du coup aussi les moins faciles à moderniser dans le SI », explique ainsi Christophe Negrier, VP Technology Oracle Europe du sud. Alors certes, désormais, les API et les approches low code permettent d’ouvrir l’ERP sans altérer la normalisation du noyau principal, mais le backlog des années 2000 est encore bien là. Et la DSI doit garder toute son attention en éveil pour éviter que de mauvaises pratiques n’éloignent de cet état d’équilibre.
Des données à archiver
D’autant qu’en matière d’ERP, ce n’est pas le seul danger. Au-delà de l’aspect fonctionnel, le contenu des bases de données doit aussi être surveillé. « Peu de DSI en sont conscients avant qu’un auditeur ne vienne leur en toucher un mot, mais les données de gestion dites fiscales que le progiciel renferme, sont censées rester disponibles à n’importe quel moment dans leur état d’origine, à des fins de contrôle fiscal informatisé », explique par exemple Thierry Julien, président de TJC Group. Sa société a créé, à la demande de certains de ses clients, un outil qui permet de récupérer ces données dans les bases SAP et de les convertir dans des fichiers à plat, conformes notamment aux exigences fiscales. Et ce n’est pas le seul intérêt de la démarche : « Ces fichiers peuvent aussi servir pour des contrôles RGPD et même
servir d’archives ultérieurement, pour des analyses statistiques avec une forte dimension historique,
par exemple pour vérifier l’évolution de la qualité des produits fabriqués par l’entreprise. »
Les nouveaux langages et les AGL vieillissent aussi
Et s’il n’y avait que les ERP ! Les langages aussi vieillissent mal… à l’exception de Cobol qui vient de fêter ses 60 ans ! Java est régulièrement pointé du doigt dans ses versions successives par exemple. On peut aussi trouver des bouts de code en assembleur dans certains systèmes d’information bancaires. Tant qu’il fonctionne, pas de souci, mais lorsqu’un problème survient, il est très difficile de trouver un expert capable d’intervenir.
Il y a d’autres points d’alerte. Le DSI de LCL, Olivier Biton, en a bien conscience : « Une version majeure d’Angular, le passage de Swarm à Kubernetes, c’est tout sauf une formalité. C’est même encore pire que Java ». Et d’ajouter, « ni Angular ni Kubernetes ne peuvent vous garantir des compatibilités ascendantes à 15 ans, comme dans des écosystèmes mainframe ». Au contraire même : « Je constate une échelle de temps qui se réduit, à cause du rythme de sortie des versions. Nous avons désormais des technologies qui, au bout de quatre ou cinq ans à peine, doivent être remplacées. Par exemple dans le domaine du big data avec l’évolution des distributions. »
Mais, si ces environnements modernes de développement se montrent instables, à l’autre bout de l’échelle du temps, ce n’est guère mieux : tous les AGL, stars des années 1990 qu’IBM avait notamment promus dans le cadre de son fameux programme AD/Cycle, ont fini par passer la main. Pacbase si présent dans le secteur bancaire, Synon ou Lansa sur les AS/400, c’est fini. Il ne reste guère que la solution Adelia de Hardis pour évoluer encore.
Des mauvaises pratiques qui défont à l’autre bout
Certaines pratiques ont également la vie dure : celles qui consistent à solutionner un problème immédiat avec une solution « bout de ficelle », censée être provisoire, mais qui s’installe durablement. Le cabinet Forrester pointe par exemple le danger des développements de RPA qui ont pu avoir lieu pendant la pandémie, pour permettre par exemple la continuité de certaines activités à distance (voir encadré). Selon lui, c’est une véritable bombe à retardement si l’on n’y prend pas garde.
Olivier Biton est bien d’accord : « Chaque pansement que l’on met crée du legacy et crée de la dette future. La RPA n’est que l’un de ces nombreux bouts de scotch ; en faire d’accord, mais avec une stratégie de transformation SI pour l’enlever rapidement ! » Sa philosophie quelle que soit la technologie utilisée ? « Se demander si l’on pourrait tout changer progressivement sur dix ans sans pour autant tout repayer. »
Ambitieux mais pourquoi pas, avec des fournisseurs sincères dans leur démarche d’éco-conception et donc à l’opposé de l’obsolescence programmée. C’est en tous cas ce que promettent certains d’entre eux. Par exemple, le fabricant de logiciels de stockage Pure Storage, en plus « d’avoir une
des technologies les plus récentes, donc avec la matrice de compatibilité la plus large du marché avec l’ensemble des protocoles en activité », comme l’indique son directeur technique France, Gabriel Ferreira, se targue de faciliter la réutilisation de ses composants et de ne plus jamais imposer de changements brutaux de produits à ses clients. Exemple à suivre ?
Le RPA pointé du doigt par Forrester
Dans une récente note de conjoncture, le cabinet Forrester explique d’abord pourquoi les décideurs se sont précipités sur ces technologies d’automatisation, en particulier pendant la pandémie : « Les décideurs les ont vues comme des solutions au manque de compatibilité entre des processus en silos, mais aussi comme une réponse immédiate aux besoins de productivité sur certaines tâches à faible valeur ajoutée. » Le tout avec la promesse de coûts et de délais raisonnables, donc avec un seuil de rentabilité assez proche. À plus long terme cependant, Forrester exprime des inquiétudes quant « à la hausse inexorable des coûts informatiques associés et aux ajouts de complexité dans le système d’information ». Cela pourrait contribuer à le scléroser encore plus durablement et du coup, gêner ses évolutions ultérieures en réponse aux demandes des métiers. Le cabinet utilise même le terme d’impasse technologique.
