Modernisation

Dominique GAYTE

Les applications métier hébergées sur les IBM i datent souvent du siècle dernier et ne correspondent plus aux demandes actuelles des utilisateurs. Les Directions Générales (ou les jeunes DSI !) envisagent souvent une rupture brutale en basculant l’application métier vers un autre système, souvent basé sur un ERP. Ce n’est pas sans risques et l’on ne compte plus les échecs retentissants se chiffrant parfois en dizaines, voire centaines de millions d’Euros.

Ce scénario n’est intéressant que si le métier de l’entreprise a évolué et que l’existant ne répond plus fonctionnellement aux besoins du métier. Dans ce cas, la rupture est inévitable.

Sinon, nous préconisons fortement la modernisation, au sens large, des applications existantes. Les avantages sont nombreux :

• Pas de big bang le jour du basculement. Toutes les évolutions peuvent se faire en douceur, au fil du temps
• Prendre un ERP, c’est un peu rentrer en religion, voir même dans une secte ! Il est difficile d’en sortir, on est fortement contraint, c’est l’éditeur qui décide de tout, y compris d’arrêter le support
• Le coût est généralement moins important et réparti sur une durée plus longue
• C’est une grossière erreur de penser que l’ERP va vous aider à vous structurer. Dans la plupart des cas, si vous n’êtes pas correctement organisés avant de mettre en place l’ERP, vous irez droit dans le mur. Il faut bien connaitre ses processus, et les avoir standardisés, pour pouvoir les intégrer dans un ERP sinon il faut trop de spécifique ce qui rallonge les délais et augmente l’addition finale.

La modernisation, pour nous, peut toucher tous les aspects du SI, notamment :

• Les interfaces, bien sûr, c’est la première chose à laquelle on pense, mais les interfaces Web n’arrangent pas tout le monde, notamment ceux (celles) qui font de la saisie en masse
• Les fonctionnalités. Les utilisateurs actuels ont besoins d’export Excel, de génération de PDF, de diagrammes
• La Base de données qui doit être transformée afin de prendre en compte toute la puissance de DB2 for i : utilisation massive de SQL qui est un standard connu de tous, utilisation des types Date, Horodatage, Heure et Null, mise en œuvre des tables temporelles afin d’avoir une vision des stocks passés pour n’importe quel jour à n’importe quelle heure, sécurisation avancée, enrichissement du moteur (trigger, points d’exit, procédures stockées…)
• L’organisation du développement intégrant plusieurs types de langages : coté métier (RPG IV, SQL, ILE), coté interface utilisateur (HTML, PHP, JAVA, JavaScript…) et coté standardisation des accès (PHP, PYTHON, Node.JS, JAVA…). Git peut être le repository des codes sources, même traditionnels (RPG, CL…) 
• L’interconnexion avec le reste du SI. Accès aux bases de données distantes et ouverture de celle de l’IBM i aux applications distantes, communication temps réel avec le site Web pour avoir les commandes qui viennent chercher les quantités disponibles en stock en temps réel,
• L’utilisation massive de Web Services afin de d’intégrer totalement l’IBM i dans une infrastructure de type micro-services. N’importe quelle application du SI autorisée peut accéder de manière standardisée à la quantité en stock d’un produit, à son prix pour un client, à une facture en PDF, à l’état d’une livraison…
• Les Ressources Humaines de la DSI qui doivent être formées afin de participer à cette modernisation : nouveaux langages, nouvelles méthodes, nouvelle organisation du développement
• L’architecture matérielle permettant notamment de créer simplement des partitions pour le développement, les tests, la validation, la préproduction
• La Sécurité qui était un des grands oubliés de l’ancienne architecture. Mais avec la recrudescence des actes malveillants et les contraintes du RGPD, il est essentiel de la prendre en compte dans tout projet de modernisation