|
| |
|
|
 |
| Comment le Crédit Agricole recense le parc applicatif de ses caisses régionales |
| C'est le logiciel Essor, développé par Sodifrance, qui permet à l'un des GIE de la banque verte de développer et maintenir le système d'information, notamment en établissant des relations entre les composants.
(21/04/2005) |
|
Premier groupe bancaire français, le Crédit Agricole a historiquement toujours laissé chacune de ses caisses régionales gérer de façon autonome son système d'information. Mais depuis quelques années, la banque a rationalisé son organisation informatique et a réalisé la fusion de plusieurs de ses GIE informatiques, au nombre de 5 aujourd'hui.
L'un de ces GIE
- le GIE Comète - représente les caisses régionales de Charente-Périgord, Charente-Maritime / Deux-Sèvres, Normandie-Seine, Oise et Nord de France. Sa mission est de développer et maintenir le système d'information, en particulier le parc applicatif, pour les caisses régionales dont il a la charge.
"Depuis 2001, nous utilisons régulièrement Essor, suite logicielle de Sodifrance qui nous permet de recenser l'ensemble des programmes du système d'information, en établissant les relations entre les composants et en contrôlant les programmes qui sont touchés en cas de changement", déclare Bruno Lukasik, responsable normes, outils et études au sein du GIE Comète.
Peu avant l'an 2000, Comète avait commencé à mener une réflexion sur l'évolution de son système d'information, souhaitant abandonner l'architecture technique Bull au profit de celle d'IBM. Cette migration devait lui permettre d'être référencé au niveau national et se rendre attractif pour d'autres caisses régionales qui n'auraient pas encore choisi de système d'information parmi ceux référencés.
"Nous avions déjà eu l'occasion d'apprécier la qualité des solutions logicielles proposées par Sodifrance, qui avait mené le projet de migration an 2000. Nous cherchions un outil de références croisées pour être certains de considérer tous les éléments du patrimoine applicatif concernés par la migration. Encouragés par les conseils d'une autre caisse régionale de Crédit Agricole qui avait fait ce choix, nous avons opté pour Essor", précise Bruno Lukasik.
| Migration de 30 000 composants sous Bull à plus de 45 000 sur IBM |
A l'époque sur système Bull avec des bases de données IDS2, Comete utilise donc cet outil pour mesurer l'impact de la migration sur les 30 000 composants que compte alors le système d'information.
Avec ce changement de système d'architecture, Comète va connaître une évolution majeure.
Le GIE souhaite en effet basculer vers un coeur de système sur mainframe IBM, avec un moteur transactionnel CICS et une base de données DB2 sans changer le poste client bancaire, développé en Cobol Microfocus.
Le générateur Cobol Delta est conservé pour ne pas modifier les programmes lors de la migration, les évolutions IBM étant intégrées dans les squelettes du Générateur Cobol. "Nous avons préparé cette migration pendant 2 ans. Nous sommes passés de 30 000 composants sous Bull à plus de 45 000 sur IBM. Cette différence représente les composants d'accès aux données générés lors de la migration. C'est pour cela qu'un outil comme Essor nous est indispensable pour signaler toutes les conséquences liées à une évolution du système d'information", note
Bruno Lukasik.
| Aujourd'hui, le développement de nouvelles applications est organisé en mode version |
Aujourd'hui, le développement de nouvelles applications est organisé en mode version, ce qui signifie que trois versions sont en permanence en cours de développement. Afin de pouvoir livrer une plate-forme qui soit prête à être intégrée dans la version précédente et compatible avec celle qui suit, Comète doit s'assurer d'être constamment à jour.
"Comme solution de gestion de versions, nous avons choisi Continuus, de Telelogic", ajoute Bruno Lukasik. Continuus est utilisé comme outil maître pour gérer les phases de développement et de cycle de vie des composants. Il assure aux équipes de développeurs la gestion des modifications, vérifie l'historique des évolutions et gère les conflits en fonction des versions sur lesquelles ils travaillent.
| Depuis la dernière version, l'application est accessible via un client HTTP |
Couplé à cet outil, Essor est alors utilisé à plusieurs étapes du processus de développement. Lors de l'établissement du cahier des charges, il permet, grâce à l'estimation des programmes impactés, de calibrer le nombre de jours de développement nécessaires.
"Nous l'utilisons également pour retrouver les programmes générés lors de la migration et non développés par Comète. Ou encore pour faciliter la mesure d'impact lors des phases de développement", observe Bruno Lukasik.
"Indéniablement, Essor nous a permis d'améliorer la qualité de ce que nous livrons. Nous contrôlons mieux les charges de travail et la planification des développements, s'enthousiasme-t-il.
D'autant que, depuis la dernière version, l'application est accessible via un client HTTP. "Les requêtes sont lancées via un simple navigateur. Nous avons créé des requêtes standards pour les développeurs, ce qui simplifie grandement les choses", conclut le responsable.
|
|
|
|
Dossier 
