Pacbase : le casse-tête de la gestion de l’obsolescence

Jean-Marie Orsini, directeur de l’offre IT de Cognitis, rappelle l’historique de Pacbase, cet atelier de génie logiciel français générant du Cobol et conçu par CGI, avant d’être racheté par IBM : «Il s’est beaucoup développé dans les années 1980, dans le tertiaire financier français.» Un particularisme local mais pas uniquement : «il a aussi été adopté aux Etats-Unis, en Allemagne, en Espagne et au Benelux. À ma connaissance, le marché français représente environ 50 % de la base installée, soit de l’ordre de 80 clients », explique Jean-Marie Orsini, en soulignant qu’il ne s’agit pas là de chiffres officiels publiés par IBM. Mais en tant que «partenaire historique» d’IBM Rational, Cognitis dispose d’une certaine vision du marché.

IBM prévoit de supporter Pacbase jusqu’en 2015, au moins, le temps de faire migrer la base installée sur Rational Developer for Z, basé sur Eclipse. Et cela pose de lourdes questions, pour certains clients. Jean-Marie Orsini explique ainsi que «BPCE, Crédit Agricole SA, Banque Postale, Groupama, ont utilisé massivement Pacbase pour une majeure partie de leurs applications mainframe. Pour certains de ces clients, et même la plupart, tous les nouveaux développements mainframe se font encore avec Pacbase ». Alors, certes, ce n’est pas le cas pour tous : «évidemment, il y a de très grandes disparités dans ces clients [...] parfois, Pacbase n’a servi qu’à quelques projets isolés, limités à un site.» Pour cela, l’abandon programmé de Pacbase n’est pas un problème. Ni même pour ceux pour qui ce n’est plus qu’une question de maintenance, ayant choix de sortir des systèmes Z d’IBM, «comme la Caisse des Dépôts et Consignations », explique Jean-Marie Orsini. Eux «ont engagé une trajectoire de sortie des systèmes Z depuis plusieurs années. Ils utilisent Pacbase mais uniquement pour la maintenance ». Et de préciser toutefois que «Pacbase n'est pas uniquement un AGL pour systèmes Z. Il peut générer du code pour différentes plateformes : Unix, Windows, etc. Pacbase génère du Cobol pour les systèmes Unisys, Bull... entre autres.»

La question de la maturité de l’offre...

Mais la question de l’environnement de développement apparaît presque comme une fausse question : «IBM a proposé des solutions, avec notamment Rational Developer for Z (Rdz), Rational PurifyPlus (Rpp), et Rational Team Concert (RTC).» L’éditeur propose donc des alternatives. Se pose donc la question de la dépendance à IBM, et tout particulièrement de l’historique, notamment en matière de gestion de gestion des configurations : «tout cela s’inscrit dans une architecture cible de Rational où RTC est aussi le nouveau gestionnaire de configuration. Et, jusqu'à présent, seule la version pour systèmes Z a été commercialisée. C'est la limite de l'offre actuelle mais IBM prévoit de commercialiser rapidement des versions Unix et Bull », explique Jean-Marie Orsini.

Dès lors, deux questions se posent. La première est celle de la maturation de l’offre Rational. Mais elle est intimement liée à une seconde, celle de la dépendance à Pacbase : «tous les clients Pacbase qui se posent la question de son remplacement s'interrogent sur le délais de maturation de la solution Rational. Les clients se rendent compte que les projets de gestion d'obsolescence sont très impactants et coûteux. Et par les temps qui courent, faire passer un projet technique avec une faible plus value métiers, c'est très complexe.» Car si Rational emmène petit à petit vers un codage Cobol natif, dans Eclipse - «quitte à aller vers Cobol, pourquoi ne pas abandonner le générateur ?» -, il ne règle pas la question clé de la gestion des configurations.  

à la gestion des configurations...

De fait, «RTC amène aussi une nouvelle gestion des configurations». Du coup, pour les clients, l’adoption des solutions Rational dépasse la simple continuité : «la question qu’ils se posent est de savoir s’ils en profitent pour rationaliser, en parallèle, la gestion des configurations. Avec ce que cela implique de dépendance - ou d’indépendance - vis-à-vis de l’éditeur». Une question importante pour certains clients Pacbase tandis que d’autres préfèreraient jouer la sécurité. «Historiquement, les systèmes Pacbase ont été énormément customisés, avec l’intégration d’un référentiel assorti des définitions des données manipulées - données élémentaires et structurées. Dans certains cas, tout le descriptif des tables des bases de données du SI est défini dans Pacbase. Parfois même, Pacbase est le référentiel documentaire de l'ensemble des développements mainframe.» 

et à l’ingénierie des développements.

Mais Pacbase intègre aussi un système de gestion des sources. Pour Jean-Marie Orisini, «il y a là toute une ingénierie de développement customisée autour de Pacbase ». Une solution comme celle de RainCode - proposée par Cognitis, aux côtés des solutions IBM Rational - apporte une part de réponse : «les habitués de Pacbase n'ont pas l'habitude de maintenir le code Cobol de Pacbase; et les gens du Cobol n'ont pas l'habitude de ce code. Le Cobol Pacbase est très verbeux.» RainCode propose une solution qui permet de restructurer le code Cobol de Pacbase. Mais elle ne s’applique pas uniformément à tous les cas : «aller vers la filière cobol, c’est poser la question de refaire uer ingénierie de développement », relève Jean-Marie Orsini. 

Dès lors, les projets trainent : «les clients mettent du temps à se décider », reconnaît-il, soulignant que l’interrogation principale porte sur la plus-value à présenter aux métiers. Et quelque soit la stratégie retenue - migrer vers la filière Cobol ou jouer la carte IBM Rational -, la gestion de l’obsolescence de Pacbase «s'inscrit dans projet beaucoup plus large ».

On parle là de projets lourds, avec une échéance à un an et demi/trois ans. Et, selon Jean-Marie Orsini, nous n’en sommes qu’au début : «aucun client français n'est encore sorti de Pacbase, parmi les grands et moyens comptes. Quelques projets viennent d'être lancés mais ils ne sont pas encore fortement avancés.»