Le Crédit Agricole ose Cobol sur Windows

Une première en France : pour gagner en performances et réduire ses coûts matériels, la banque bascule son infocentre du mainframe vers la plate-forme Wintel. Un projet amorti en moins de vingt-six mois grâce à la recompilation du code Cobol existant en Cobol.Net.

Face à la volumétrie galopante des informations, le stockage sur mainframe devient un luxe qu'une entreprise ne peut plus se permettre. C'est du moins la conclusion que l'on peut tirer de l'expérience d'AMT (Association de moyens techniques), GIE du Crédit Agricole en charge des ressources et des moyens informatiques des caisses régionales de Savoie, Centre-Est, Haute-Loire, Sud-Rhône-Alpes, Champagne-Bourgogne, et Provence-Côte d'Azur. Le GIE vient, en effet, de balayer d'un seul coup vingt ans d'histoire estampillée Big Blue au profit d'une plate-forme Wintel. Le Crédit Agricole devient ainsi l'une des toutes premières entreprises françaises à exploiter l'ouverture de la plate-forme .Net à d'autres langages que ceux de Microsoft, et notamment au Cobol.

A la clé, 1 million d'euros d'économie par an

' Le pari était risqué, reconnaît Didier Mange, directeur général adjoint du GIE AMT-Crédit Agricole. Mais nous ne pouvions plus continuer comme cela. ' En effet, il y a environ un an, l'établissement bancaire arrête les compteurs, et dresse un bilan plutôt catastrophique. Son entrepôt de données hébergé sur mainframe, et sur lequel reposent des applications critiques (de détection des fraudes bancaires, notamment), lui coûte plus de 1 million d'euros par an. A savoir 350 000 euros pour la location de chacun des deux moteurs MIPS, soit 700 000 euros, auxquels il faut ajouter le coût du stockage de données, dont la volumétrie ne cesse de croître : 6 To aujourd'hui, plus de 21 To en 2008, d'après les projections effectuées par le GIE. ' Le calcul est relativement rapide, ajoute Didier Mange. En basculant sur une plate-forme Wintel, nous réalisons plus de 1 million d'euros d'économie par an, le coût de migration étant amorti en moins de vingt-six mois. 'Assurément, cette migration n'aurait pas été rentable aussi vite sans la récupération des programmes en Cobol existants. ' L'existant applicatif sur mainframe freine souvent ce type de projet, souligne Rakesh Kumar, vice-président de Gartner. En effet, la plupart des entreprises ne souhaitent pas investir du temps et, surtout, beaucoup d'argent dans le redéveloppement de millions de ligne de code. '

Aucune intervention humaine tant que le code répond aux normes

La solution est venue de Fujitsu. En guise de migration, le Crédit Agricole se contente de recompiler en Cobol. Net plus de 500 programmes, conçus à l'origine en Cobol et destinés à l'alimentation de son entrepôt ou à la création de datamarts. ' Tous les applicatifs Cobol ne sont pas forcément éligibles à cette recompilation ', précise toutefois Eric Ciesla, responsable du programme de transmigration de Fujitsu, visant à faire évoluer les applications basées sur mainframe vers un environnement Microsoft. ' La limite provient du code existant. Certaines entreprises ont conçu des choses exotiques, avec des bibliothèques autres que celles d'IBM, que notre compilateur ne saura pas interpréter, explique-t-il. Mais tant que le code est conforme aux normes, la migration est automatique, et ne suppose aucune intervention humaine. ' Si cette migration s'avère aussi rentable, c'est précisément parce que la recompilation des programmes est quasi automatique.Cependant, six mois de tests ont été nécessaires pour vérifier la faisabilité de l'opération. Entre avril et octobre 2006, l'établissement bancaire, avec le concours de Microsoft Consulting et de Fujitsu, a effectué des tests de recompilation, mais aussi de migration de quelque 900 tables DB2 sous MVS. Dans un premier temps, le Crédit Agricole ne prévoit aucune modification fonctionnelle de son existant, car la migration est purement technique. Ainsi, les tables sont migrées vers SQL Server 2005 à l'identique à l'aide de SSIS, l'ETL de Microsoft, et le partionnement initial a, lui aussi, été conservé.

SQL Server plus performant que DB2

Malgré cette bascule isofonctionnelle, le Crédit Agricole a été agréablement surpris lors de la phase des tests. Bien sûr, cette migration a été motivée par des aspects purement économiques. Mais l'établissement rencontrait aussi, sur son ancien système, des problèmes de performances avec certaines requêtes complexes, qui attaquent les 900 tables simultanément en temps réel. Et cela, dans le cadre d'une application liée à la détection du blanchiment d'argent. De surcroît, une nouvelle réglementation imposait d'établir ces requêtes sur un historique de treize mois, et non plus trois. L'exécution de cette requête (sur trois mois) sur DB2 7.1, version utilisée par le Crédit Agricole, demandait cinq minutes. Avec SQL Server, elle ne prend plus que trente seconde (pour le traitement des treize mois). Un gain de performances principalement du à l'optimiseur de requêtes de SQL Server dont la technologie récente s'avère plus évoluée que ce que l'on trouve d'ordinaire sur mainframe.

De plus grandes perspectives d'évolution avec Windows

Début 2007, après cette période de tests concluante, le Crédit Agricole attaque la migration proprement dite. Le projet est prévu sur quatorze mois, et devrait prendre fin en mars 2008. Date à laquelle l'entrepôt stocké dans SQL Server devrait contenir plus de 21 To de données, contre 6 To actuellement sous DB2/MVS. Les 17 datamarts existant sous DB2, utilisés par la couche de restitution décisionnelle, seront reproduits à l'identique à l'aide d'Analysis Services, le moteur Olap livré avec SQL Server. Mais d'ores et déjà, Catherine Traversier, responsable décisionnelle d'AMT-Crédit Agricole, envisage d'enrichir sa plate-forme : ' L'environnement Windows est bien plus ouvert que celui du grand système. Nos perspectives d'évolution se sont donc multipliées, car le marché des outils pour Windows est bien plus fourni que celui du mainframe. Sans oublier le potentiel d'Office 2007, énorme en matière de décisionnel. '[e-mail]

L'infocentre de la banque bascule de DB2/MVS vers SQL Server

Dans l'architecture cible, c'est toujours le mainframe, sur lequel sont hébergées les applications de production de la banque, qui déclenche l'ordonnancement des batchs Windows. Les fichiers de données extraites des applications de production par les traitements en Cobol.Net sont encodés en EBCDIC (mode de codage des caractères sur 8 bits créé par IBM). Format que SQL Server ne sait pas interpréter. Ils sont traduits à la volée en ASCII avant d'être récupérés par l'infocentre.

Résultat net : 787,4 M d'euros.
Effectif : 700 personnes.
Postes de travail gérés : 15 000.
Automates bancaires gérés : 4 200.

Puissance utilisée sur mainframe : 900 Mips en 2006, soit environ 2 M d'euros par an (coût du Mips : 2 160 euros-ht par an). 1 100 Mips pour 2008.
Consommation d'espaces disques sur mainframe : 12 To en 2006, soit environ 650 000 euros (augmentation de 20 % par an).
Comparaison du coût du gigaoctet : 18 euros sur Wintel, 54 euros sur MVS.
Coût global du projet de migration : 3,213 M d'euros.
Durée : 14 mois (6 de tests).
Tables migrées de DB2 vers SQL Server : 900.
Volumétrie de la base de données : 6 To en 2007, 21 To en 2008.
Programmes recompilés en Cobol.Net : 500 (batchs d'alimentation de l'infocentre et création des datamarts).

Questions/Réponses

Peut-on recompiler n'importe quel type d'application ?
Selon Fujitsu, la seule limite serait la conformité aux normes du code Cobol existant. L'utilisation d'assembleur, par exemple, pourrait constituer un frein. Les traitements du Crédit Agricole sont des programmes batchs peu complexes. Mais le compilateur a déjà été utilisé avec succès sur des applications métier sophistiquées. Notamment en Italie, où l'Institut national de la protection sociale a migré plus de 300 applications métier.

Existe-t-il d'autres exemples de migration de ce type ?
En France, le Crédit Agricole est la première entreprise à migrer des applications Cobol en Cobol.Net. Fujitsu annonce deux autres projets français en cours, dans le secteur bancaire. L'éditeur compte déjà quelques références internationales - en particulier, le département d'Etat de Washington et Atos Euronext, qui ont déjà migré plusieurs millions de lignes de code.

Le Crédit Agricole avait-il envisagé d'autres solutions ?
Oui, deux autres solutions ont été étudiées. Le statu quo, avec des mesures d'optimisation. Mais il supposait une dégradation du service, sauf si la banque augmentait de façon significative les Mips et le stockage, et donc son budget. Une étude avait aussi été menée sur une solution de migration de l'entrepôt sur Linux/DB2 et AIX/DB2 en réécrivant les programmes Cobol dans le langage de l'ETL Datastage. Le coût de cette solution s'élevait à 4,098 millions d'euros, contre 3,213 millions d'euros pour la migration vers Windows/SQL Server.

Interview : Didier Mange (GIE AMT-Crédit Agricole) : ' une évolution en douceur pour les développeurs '

Avez-vous rencontré des réticences de la part de la direction générale ?
Didier Mange : Avec plus de vingt ans d'historique sur mainframe, nous sommes bien un ' compte bleu '. Mais cela ne nous empêche pas de voir où sont nos intérêts. A partir du moment où les avantages financiers de la migration et les gains en performances ont été démontrés, et que, de surcroît, l'ouverture de la plate-forme Windows nous apportait une plus-value en termes d'outillage, nous n'avons rencontré aucune réticence. Au contraire, les gens se sont montrés plutôt pressés de passer à la nouvelle phase.

Comment envisagez-vous d'assurer la maintenance du Cobol.Net ?
DM : Une quinzaine de personnes se consacrent aujourd'hui à la maintenance et à l'évolution des traitements d'alimentation en s'appuyant sur l'AGL Pacbase, qui génère le Cobol. Elles continueront de le faire par la suite, car nous préférons conserver leur environnement de travail habituel et migrer à la volée les modifications avec le compilateur de Fujitsu. Toutefois, nous n'excluons pas la possibilité d'?"uvrer sur de nouvelles chaînes de traitements en utilisant l'ETL SSIS, voire de marier nos programmes Cobol à des traitements en C#. Pour l'instant, nous n'en sommes qu'au stade de la réflexion, mais ces hypothèses sont très probables.

Les développeurs acceptent-ils bien le passage du développement procédural à l'objet ?
DM : Bien que très fortement estampillés mainframe, nous avons un parc varié de 1 400 serveurs applicatifs (principalement du Java/IBM - NDLR). Sur l'ensemble de nos collaborateurs, seuls deux ont baissé les bras quand il a fallu passer du mode procédural à l'objet. Nous restons, bien entendu, très vigilants et avons prévu un accompagnement et des formations. Mais, globalement, cette évolution ne présente pas de problèmes. D'autant que les développeurs impliqués dans la maintenance de l'entrepôt ont tout simplement été emballés par le projet. C'est un défi qui ne nous fait pas peur. Nous sommes habitués à bouger.