@SURTITRE:CHRISTIAN LAPIE,

DIRECTEUR INFORMATIQUE GROUPE,

CREDIT LYONNAIS

@TITRE:"La réutilisation, un processus technique,

mais aussi culturel "

@CHAPO:La nouvelle architecture du Crédit Lyonnais entre en phase opérationnelle. Elle vise la réutilisation des composants logiciels mais aussi le dialogue entre informaticiens et utilisateurs.

@INTERVIEW QUESTION:Votre expérience d'une architecture de composants vous permet-elle déjà de tirer quelques conclusions sur leur réutilisabilité?

@INTERVIEW REPONSE:CHRISTIAN LAPIE. En 1993, nous nous sommes engagés dans une réflexion sur l'évolution de nos infrastructures. Et nous avons lancé le projet Club, avec Lyon Consultants. Il a pour objectif de normaliser notre architecture, en France et si possible dans les filiales. Un des premiers projets-pilotes est en production depuis six mois, sur 200 réseaux locaux et 1200 stations. Nous avons donc pu développer les composants au fur et à mesure des besoins, tester les concepts et bâtir notre courbe d'apprentissage en termes de productivité, de temps de développement, d'interfaçage avec l'existant, etc.

Notre politique n'est pas de livrer des produits finis, mais une manière de faire, et des composants que les développeurs, dans le filiales par exemple, peuvent utiliser soit directement, soit à titre d'archétype. Les composants applicatifs font plus de difficultés que les composants techniques. L'expérience des projets-pilotes nous a appris que les développeurs préféraient s'inspirer des composants plutôt que des les réutiliser directement. En effet, les composants métier comportent des concepts comme le client, la personne, l'employé... sur lesquels il faut s'entendre. En revanche, les composants purement techniques se normalisent au sein de l'informatique, malgré la tendance de chacun à toujours vouloir les particulariser.

La réutilisation doit se comprendre comme un processus, dont les aspects culturels comptent autant que les aspects techniques. Nous sommes sur la courbe d'apprentissage, en la matière. Mais nous allons dans le bon sens.

@INTERVIEW QUESTION:Disposez vous d'outils de métrologie pour évaluer vos résultats?

@INTERVIEW REPONSE:C.L. Oui, pour les projets classiques. Nous disposons d'outils d'évaluation de la charge et des effets des interventions. Mais, pour ces nouveaux types de développement, nous ne pouvons guère déterminer une métrologie a priori. Nous procédons donc pour l'instant de manière artisanale. Nous commençons à déterminer quelques points de métrologie. En particulier, nous caractérisons les classes en simples, moyennes et complexes. La technique s'appuie sur un comptage du nombre d'attributs et de méthodes. Ce procédé, plus proche du code que des fonctions, est tout de même plus subtil qu'un simple comptage de lignes.

Nous avons aujourd'hui déterminer a priori le nombre de classes d'un projet, et leur répartition: environ 20% de classes complexes, 40% de classes moyennes et 20% de classes simples. Nous mesurons les temps développement, tout compris, jusqu'à l'arrivée en phase pilote. A l'expérience (sur cinq projets représentant environ chacun 5 millions de F) on peut compter environ 15 jours par classe, avec des équipes mixtes associant des développeurs confirmés et des débutants.

@INTERVIEW QUESTION:Comment se déploie aujourd'hui le projet Club?

@INTERVIEW REPONSE:C.L. Pour éviter l'effet tunnel et pouvoir montrer rapidement des résultats, nous nous sommes appuyés sur des projets-pilotes. Nous les avons démarrés en parallèle avec la construction de l'architecture. Le premier projet, Sésame, aujourd'hui largement opérationnel, assure l'analyse de rentabilité des relations de la clientèle "entreprises". Il a nécessité la création de 80 classes purement applicatives et de 20 classes techniques.

Une application d'agence, testée actuellement dans notre filiale espagnole, nous a permis d'étudier le branchement de l'architecture Club sur nos systèmes existants

L'EIS (Executive information system) Siclad, offre aux directions comerciales des interrogations de tableaux de bord. Ce projet comprend un algorithme d'hypercube, et offre des composants réutilisables pour d'autres types de tableau de bord

De plus grande ampleur, la base de références des entreprises françaises, reprise de notre ancien fichier clients passera en phase opérationnelle à la fin de 1996. S'appuyant sur ce projet, une gestion des groupes d'entreprise, appuyée démarre en ce mois de mars.

Nous entrerons vraiment dans la migration d'Elan vers Club avec le module "particuliers-professionnels". Pendant un certain temps, il faudra gérer la cohabitation des deux générations. Quelque 20 000 stations devront supporter à la fois les anciennes et les nouvelles applications. Ce point, que nous testons aujourd'hui sur d'autres projets, caractérise les problèmes que pose l'évolution d'une entreprise comme la nôtre.

@INTERWIEW QUESTION:Au niveau des serveurs centraux, comment préparez-vous les années à venir?

@INTERVIEW REPONSE:C.L. Nous ne voyons pas l'ère des mainframes se terminer avant longtemps. simplement. Laissons à leur place les rêves du downsizing. Nous voyons plutôt les centres se regrouper, avec des machines très puissantes, pour économiser sur les licences de logiciel. D'ailleurs, le prix des mainframes a largement diminué. au point que notre politique traditionnelle d'achat de machines en seconde main perd de son intérêt. Notamment avec l'arrivée des machines CMos.

Pour les serveurs centraux, nous considérons que les grandes banques utiliseront encore longtemps MVS, et peu Unix, sinon pour les systèmes départementaux ou les serveurs spécialisés. Dans les grandes banques, la majeure partie des développements porte encore sur le batch et sa maintenance. La partie interactive ne touche que 20% des développements environ. Hélas, les nouvelles technologies logicielles ne s'intéressent qu'au client/serveur. Nous trouvons donc peu d'outils pour améliorer la productivité de nos développements classiques. Introduire un AGL à ce niveau comporte des effets structurants qui nous en ont dissuadé jusqu'à présent. Cela ne nous a pas empêchés de perfectionner nos applications: modèles généralisés, dictionnaire, etc. Nous comptons, pour l'avenir, sur le progrès de l'offre que les américains appellent "high end client/server". Même si l'on passait sous Unix, cela ne changerait pas l'importance du batch.

@INTERVIEW QUESTION:Techniquement, comment se construit alors votre architecture client-serveur?

@INTERVIEW REPONSE:C.L. Trois principes orientent notre nouvelle architecture. A la base, les stations de travail multifonctions. Le plan de migration vers ces nouvelles stations se déroule sur quatre ans environ, pour se terminer vers 1998. La configuration normale comporte un 496 DX266 avec 28 Mo de mémoire centrale et 268 Mo sur disque. La taille de la mémoire s'explique en partie par les exigences d'OS/2 (ou de NT), complété par Netware. A lui seul, cet investissement matériel représente un effort important, qui peut ralentir le rythme du déploiement.

Ensuite, l' indépendance des applications vis-à-vis de la technologie, c'est à dire des systèmes d'exploitation, des bases de données et des réseaux. Productivité et flexibilité de l'informatique conduisent à faire évoluer la technologie le plus indépendamment possible de l'extérieur. La stabilité de nos interfaces garantit cette indépendance. Nous l'avons vérifié à propos des bases de données. Nous avons pu passer d'Ingres à Oracle à peu de frais. Nous pourrions aussi intégrer Sybase (utilisée à la Direction des marchés) à notre architecture. Cela dit, plus il faut maintenir de produits, plus la complexité augmente, et donc les coûts.

L'indépendance s'applique aussi au au temps: nous devons pouvoir travailler en mode temps réel mais aussi asynchrone, ce dernier semblant aujourd'hui marquer fortement le marché. En 1993, nous estimions qu'il n'était pas souhaitable de se lier à un fournisseur, IBM en l'occurrence, car il n'avait pas la réputation d'être ouvert vis à vis des autres fournisseurs. Nous avons donc utilisé le mode RPC et l'asynchronisme pour produire une première norme (la première version est sortie en septembre 1995). Mais, depuis 1993, le marché a considérablement évolué. Des produits émergent, et nous pouvons remplacer certaines parties, certaines briques de notre architecture, par des produits consacrés par le marché. Les outils d'asynchronisme MQ Series, par exemple, ne font plus problème, car IBM a réellement montré que ses produits n'étaient pas spécifiquement destinés au monde MVS-OS/2. Nos plates-formes normalisées peuvent donc s'implanter aussi bien sous Windows NT que sous OS/2. Et probablement Windows 95, dès que nous l'aurons suffisamment testé.

@INTERVIEW QUESTION:Quel est votre rôle dans le groupe Crédit Lyonnais

@INTERVIEW REPONSE:C.L. Dans le cadre de la Direction centrale des traitements de l'information, la direction que j'anime doit organiser la synergie, le transfert des connaissances, la normalisation. Ce sont les unités informatiques opérationnelles, par métier, qui développent les projets, en tant que maître d'oeuvres par rapport aux directions opérationnelles.

L'Informatique groupe doit organiser le transfert des connaissance vers les informatiques métier. Il faut environ quatre mois à un développeur classique (mais de qualité) pour devenir un développeur Club complet: 15 jours de formation en salle, deux mois de parrainage sur un projet, plus un mois de mise en train avant de devenir complètement opérationnel. Nous en avons formé aujourd'hui une trentaine.

Il ne faut pas exagérer la complexité de ces nouvelles technologies. Nos développeurs s'y adapteront, certains plus vite que d'autres. Et l'évolution ne touchera que 20% ou 30%, peut-être 40% d'entre eux, d'ici à quatre ou cinq ans. Pour faire comprendre le projet à tous nos collaborateurs, nous avons réalisé un film, qui comporte aussi bien des interventions de notre Direction générale que des séquences en image de synthèse. Les clins d'oeil de la petite souris, son personnage principal, feront passer le message essentiel de Club: une plate-forme commune pour maîtriser les coûts et améliorer la réactivité grâce à une boite à outils de composants réutilisables.

@SIGNATURE:Propos recueillis par PIERRE BERGER

@ENCADRE TITRE:LES OBJECTIFS DE CLUB

@ENCADRE TEXTE:

- Produire des applications à moindre coût par la réutilisation d'outils et composants logiciels

- Favoriser les échanges entre informaticiens et utilisateurs par le prototypage

- Constituer un poste de travail intégré

- Fluidifier les traitements grâce aux mécanismes asynchrones

- Intégrer les services grâce à un middleware portable et à la liberté par rapport aux plates-formes techniques (OS, SGBD, télécom).

- Echanger données et logiciels au sein du groupe grâce aux normes portées par l'architecture commune

- Permettre aux DSI opérationnelles d'appliquer ses particularités fonctionnelles ou techniques;

Pour répondre à ces objectifs, Club s'appuie sur un AGL (NatStar), et définit trois niveaux d'architecture: métier (langage commun pour les notions de base du métier), services fonctionnels ou techniques, process (mécanismes techniques d'échanges en client/serveur). Des outils d'administration complètent l'architecture: gestion des données d'infrastructure, configuration des logiciels ou des systèmes, surveillance des anomalies.

Poste de travail 02/2 ou Windows (95 ou NT). Serveur local OS/2 Netware, NT Server ou Unix Server. Bases de données Oracle. Réseau local IPX/SPX ou TCP/IP. Télécomunications SNA ou TCP/IP. Serveurs centraux MVS/CICS, bases DB2. Serveurs intermédaires Unix.

@LEGENDE ICONO:L'architecture de process de Club

////////////////En réserve, s'il y a de la place:

@INTERVIEW QUESTION:Dès votre projet Elan, lancé en 1974, vous aviez déjà pris une orientation client/serveur, même si le mot n'existait pas encore?

@INTERVIEW REPONSE:C.L. Exactement. Nous avons d'ailleurs souffert d'être des pionniers dans ce domaine. Mais nous sommes maintenant en position d'aborder la phase suivante, la nouvelle infrastructure, avec une expérience dans ce domaine. Nous avons aujourd'hui 22 000 stations déployées sous le plan Elan, qui traite l'ensemble des opérations de banque (pour la France, et à l'exception de la Direction des marchés)

A l'époque du développement d'Elan, les produits et les interfaces graphiques n'existaient pas tous sur le marché, ce qui nous a conduit à certains développements prioritaires qui induisent aujourd'hui une certaine lourdeur.

@INTERVIEW QUESTION:Que pensez-vous des projets de "Network computers", avancés par IBM, Oracle et Sun ?

@INTERVIEW REPONSE:C.L. Nous y penserons pour les phases ultérieures. En pratique, il s'agit pour l'instant de prospective, de pré-veille technologique. Le remplacement des PC du type que nous connaissons aujourd'hui ne se fera pas du jour au lendemain, et ces solutions seront sans doute complémentaires.