Par Philippe Leyland, Directeur des solutions de migration et de modernisation chez Micro Focus France
Le nombre de clients gérant un patrimoine Pacbase a diminué de façon conséquente. IBM positionne sa suite Rational comme solution pour pérenniser le patrimoine Pacbase. Enfin, la pénurie de compétences annoncée par le départ à la retraite de nombreux développeurs maîtrisant l’AGL fait peser un risque réel sur la capacité à maintenir les applications à moyen terme. Ajoutons qu’au sein de la communauté Pacbase, le sentiment prévaut qu’il ne sert à rien de chercher à fuir l’inévitable.
Une fois le changement acté et l’échéance fixée, les entreprises doivent réfléchir à la meilleure stratégie à adopter pour pérenniser leur patrimoine applicatif, en tenant compte de trois principales contraintes opérationnelles. Il leur faut tout d’abord minimiser l’impact sur le code afin d’éviter au maximum les tests de non régression. Car lorsqu’une entreprise dispose de millions de lignes de code écrites il y a 10 ou 20 ans, sa connaissance fonctionnelle est limitée et la simple perspective de réaliser des tests apparaît comme un cauchemar pour les développeurs et les DSI.
Le second point de vigilance est ne pas diminuer la productivité des équipes de développement. Pacbase a permis de gagner environ 35 à 40% de productivité pour générer le code des applications. Certes son caractère propriétaire et la baisse annoncée du nombre de compétences constituent ses limites. Mais il ne faudrait pas que les solutions choisies marquent un retour en arrière en termes de productivité du développement logiciel.
Dernier aspect : il faut que les entreprises confrontées à l’arrêt de Pacbase anticipent les changements et accompagnent leurs équipes de développement habituées à travailler sur Pacbase depuis 10 ans ou plus.
Quatre scenarii sont dès lors envisageables : privilégier la continuité en allant vers les offres IBM, ne rien faire et maintenir l’existant avec un nouvel éditeur Cobol, opter pour une conversion vers Java ou .Net, ou enfin adopter le standard Cobol.
Lorsqu’une entreprise privilégie le plan de convergence, qui consiste à remplacer Pacbase par le nouvel outil de développement IBM, elle se prémunie des efforts de tests puisque l’AGL en question génère le même code. Mais la solution reste propriétaire puisqu’on change une boîte grise contre une boîte noire. Et il faut aussi se demander si l’AGL sera utilisé par tous les développeurs ou uniquement par les Pacbasiens – avec dans le second cas, un choix qui finalement n’adresse qu’un nombre d’utilisateurs limité et appelé à diminuer.
Si l’entreprise choisit de maintenir ses applications Pacbase avec un outil de développement Cobol, elle opte sans doute pour une solution économiquement rentable et à moindre risque à court terme. Mais elle aura besoin de ressources disposant d’une compréhension approfondie de la structure de Pacbase et connaissant suffisant Cobol pour pouvoir intervenir manuellement sur le code généré. Le coût de la maintenance sera au bilan plus élevé tandis que le retour sur investissement sera plus faible. Et la complexité qu’implique le maintien du Cobol généré sans Pacbase rend cette option valable uniquement pour les applications non stratégiques requérant très peu d’évolutions métier.
Dans le cadre d’une conversion vers Java ou .Net, l’optique est de s’affranchir complètement de Pacbase, mais une telle approche augmente considérablement les risques lors de la phase de test de non régression. Sans compter l’importance de l’investissement à consacrer, ce qui rend cette option pertinente uniquement pour des applications stratégiques nécessitant une forte évolution dans les années à venir.
Dernière option qui nous semble offrir le meilleur ratio risques/ bénéfices : parier sur les standards, et en premier lieu sur le standard Cobol qui est le plus proche du patrimoine Pacbase. Opter pour le standard Cobol minimise en effet l’effort d’adaptation du patrimoine applicatif. La démarche est par ailleurs similaire à ce qui est actuellement mené dans les environnements mainframe où les langages propriétaires en perte de vitesse ont tendance à être remplacés par des standards – et a fortiori le standard Cobol, Cobol restant le langage numéro un dans le monde. Enfin, le mouvement vers les standards atténue la question de la rareté des compétences – les outils visés ayant fait leurs preuves et regroupant un nombre d’utilisateurs bien supérieur à celui des utilisateurs Pacbase. Sans compter que les AGL générant du standard Cobol fonctionnent de manière efficace sur les cibles de déploiement comme Bull CGOS 7 et 8, z/OS, Unix, Linux et Windows.
Définir sa stratégie face à l’arrêt de Pacbase impose donc une réflexion profonde sur les options possibles. Dans tous les cas, pour réussir sont projet, il faudra au préalable cartographier son patrimoine applicatif, mesurer l’impact sur son système d’information de l’arrêt de Pacbase pour les aspects à la fois techniques, humains, financiers, organisationnels et stratégiques, mener une analyse de risques et définir un plan d’action concret avec estimation du ROI.
Une fois toutes ces conditions réunies, l’entreprise aura les cartes en main pour envisager la fin de Pacbase comme une opportunité de moderniser son patrimoine applicatif.
******
Les facteurs clés de réussite d’un projet de modernisation
– Ne pas envisager le remplacement de Pacbase uniquement comme un projet technique mais l’inscrire dans une perspective globale de modernisation des applications, cohérente avec le schéma directeur du système d’information.
– Cartographier l’ensemble du patrimoine applicatif.
– Mesurer l’impact sur le système d’information de l’arrêt de Pacbase.
– Intégrer les impacts techniques, humains, financiers, organisationnels et stratégiques.
– Mener une analyse de risques.
– Estimer le retour sur investissement.
– Elaborer un plan d’action concret et pragmatique en fonction des enjeux business.
