Durant plusieurs décennies, tout le monde s’est posé la question du divorce de l’entreprise avec son mainframe et son code legacy. La désillusion fut grande car il s’est avéré impossible de rompre trente ans de vie commune sans d’insupportables conséquences. On a donc admis comme une évidence, notamment pendant les quinze dernières années, qu’il fallait continuer à payer le prix fort pour maintenir l’exploitation du backoffice. Il faut revoir cette position et évaluer les nouvelles technologies permettant de balayer le dogme mainframe-legacy-argent.

Dette technique ?

Dès le début des années 80, les mainframes semblaient vivre leurs dernières heures. Trop encombrant, trop chers, trop compliqués. Les années 90 ont ainsi vu naître un grand nombre de chantiers pour diminuer la place de ces équipements au sein des services informatiques des grands organismes publics et entreprises privées. Le résultat : un échec. En effet, les compétences relatives à ces machines particulièrement complexes se faisaient alors de plus en plus rares : une documentation quasi inexistante, un personnel vieillissant, peu d’attrait des jeunes ingénieurs pour ces technologies dépassées à l’heure de l’émergence d’Internet, etc. Aboutir à l’isofonctionnalité en migrant sur des équipements modernes s’est révélé un casse-tête inextricable à l’époque. Pour achever le scénario, l’épouvantail « bug de l’an 2000 » finit par pousser définitivement les DSI à abandonner ces projets.

Pourtant, personne ne serait en mesure de remettre en question le fait que l’ensemble des activités informatiques critiques sont encore aujourd’hui hébergées sur des mainframes et que la grande majorité des programmes associés sont écrits en COBOL, PL/I et autres langages obsolètes. Alors, sommes-nous pieds et poings liés ? Il serait tout à fait contre-productif de considérer cet état comme un fait irrémédiable et de simplement se contenter de faire avec cette soi-disant dette technique. Le fatalisme est un luxe que la pression budgétaire et le manque de flexibilité de ces systèmes mainframe rend inopérant.

Dépenser de l’argent pour investir dans le futur ou pour s’acquitter d’une dette technique ?

Nombreux sont ceux qui prônent l’isofonctionnalité par la réécriture : migrer son patrimoine applicatif et le traduire en langage moderne. Cela pourrait sembler être LA bonne idée : se débarrasser enfin des passifs archaïques pour passer à Java ou C#. Mais cette opération prend beaucoup de temps, coûte cher, peut être dangereuse, voire inutile. En effet, il est ici question de millions de lignes et il est impossible d’arrêter ces grands systèmes pour de longues périodes. Trop d’applications critiques et essentielles en dépendent. De plus, quel intérêt y aurait-il à réécrire ces programmes en répliquant les bugs, voire en en générant de nouveaux ? Quel intérêt aurait un entrepreneur du bâtiment à reconstruire un immeuble neuf, mais en conservant les défauts de l’ancien ?

Comment ne pas subir cette situation, mais plutôt en profiter ? Comment optimiser son SI et tirer profit de cet état de fait ?

La réponse : ne pas toucher au code source, mais le confier à des compilateurs, dans un processus de rehosting. Les compilateurs permettent de transformer un langage structurel en langage machine. Le rehosting complète la démarche en migrant les bases de données ou les moniteurs transactionnels vers des outils plus actuels ou des émulateurs.

Le rehosting affiche des atouts techniques et financiers qui ont le mérite supplémentaire de rassurer les marchés.

Ce processus ne présente pratiquement aucun risque technologique s’il est reversible, puisque le code originel, et donc fonctionnel, n’est pas altéré. Il peut être recompilé et dupliqué sur une nouvelle machine, en conservant le mainframe en parallèle. De cette manière, l’entreprise s’assure une continuité de service, avec la possibilité en prime de pouvoir transférer ses programmes progressivement, de corriger le code source au fur et à mesure, de revenir en arrière si nécessaire, et ce, sans interruption et sans risque. De plus, cela coûte beaucoup moins cher et lui permet d’investir les économies réalisées dans de nouveaux développements.

Avancer pas à pas

Pour y parvenir, plusieurs étapes sont indispensables:

• Une phase d’inventaire, pour collecter des métriques du système (taille, complexité, couverture des fonctionnalités des plateformes techniques
• Relever les erreurs et supprimer le « code mort » ;
• Construire un plan d’action et procéder progressivement ;
• Imaginer de nouvelles pistes pour le code de destination.

La réversibilité, la continuité de service et le faible coût du processus de rehosting évolué sont des gages de stabilité pour l’entreprise. Il faut désormais considérer les systèmes legacy comme des sources d’optimisation potentielles et les faire vivre avec des risques maîtrisés et des ressources humaines disponibles, sans révolution.