HAL Id: dumas-00524184
https://dumas.ccsd.cnrs.fr/dumas-00524184
Submitted on 7 Oct 2010
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
Installation de la nouvelle version d’un logiciel bancaire
Vincent Augerd
To cite this version:
Vincent Augerd. Installation de la nouvelle version d’un logiciel bancaire. Génie logiciel [cs.SE]. 2010. �dumas-00524184�
CO N S E R V A T O I R E NA T I O N A L D E S AR T S E T ME T I E R S L Y ON ME M O I R E P R E S E N T E E N V U E D’O B T E N I R L E DI P L O M E D’ IN G E N I E U R CN AM E N IN F O R M A T I Q U E P A R VI N C E N T AU G E R D
INSTALLATION DE LA NOUVELLE VERSION D’UN
LOGICIEL BANCAIRE
SO U T E N U L E 2 5/ 06 / 20 1 0 J U RY PR E S I D E N T : Christophe PICOULEAU ME M B R E S : Bertrand DAVID Claude GENIER Jean-François PRINCE Florence JULLIENRemerciements
En tout premier lieu je tiens à souligner l’importance du CNAM et des personnes qui y travaillent dans le système d’apprentissage français. Cette institution rend de précieux services et offre une formation de qualité reconnue au sein des entreprises.
Ensuite, je souhaite adresser mes remerciements les plus sincères aux personnes qui m'ont apporté leur aide tout au long de mes études et qui ont contribué à l'élaboration de ce mémoire et plus particulièrement :
• GCE Technologies, mon employeur, qui a insisté pour que je fasse mon mémoire d’ingénieur sur un projet de l’entreprise et notamment :
o Stéphanie DUBREUIL qui a suivi mon dossier de près,
o Jean-François PRINCE qui m’a affecté sur un projet éligible au mémoire,
o Florence JULLIEN qui m’a fait confiance tout au long du projet o et Philippe GABILLON pour tous ses conseils avisés et sa
bienveillance.
• Les membres du jury qui consacrent beaucoup de temps aux auditeurs du CNAM notamment lors des épreuves probatoires et de mémoire
• Ma famille qui m’encourage depuis le début, merci à ma fidèle lectrice
Table des Matières
Introduction ... 7
PARTIE I CADRE DU PROJET... 9
1. GCE Technologies ... 9
1.1. GCE Technologies dans le groupe BPCE... 9
1.2. PIA et financement... 11
1.3. Son histoire récente : un système d’information unique... 11
1.4. Son organisation ... 12
1.5. MySys, sa plateforme informatique ... 13
2. L’auditeur et GCE Technologies ... 14
2.1. La situation de l’auditeur dans l’organisation ... 14
2.2. Référent adjoint de la BAFI ... 15
3. Présentation de la BAFI ... 15
3.1. La BAFI ... 15
3.2. Sa mise en œuvre au sein des établissements financiers ... 17
3.3. Ses contraintes ... 17
4. La BAFI chez GCE Technologies... 17
4.1. Organisation... 17
4.2. Utilisation d’un progiciel : Evolan Report ... 19
4.3. Alimentation du logiciel Evolan Report... 21
4.4. D'autres applications autour de Evolan Report ... 21
4.5. Principe de fonctionnement... 22
4.6. Architecture technique ... 24
4.7. Architecture organisationnelle ... 25
4.8. Langages utilisés ... 26
4.9. Les environnements... 26
5. Réforme de la BAFI : SURFI ... 27
5.1. Présentation de la réforme ... 27
5.2. Impacts dans les établissements financiers ... 28
5.3. Impacts pour GCE Technologies ... 28
5.4. Contraintes de la réforme... 28
6. Conclusion ... 29
PARTIE II LE PROJET ... 31
1. Equipe projet et méthodologie ... 31
1.1. Découpage en chantiers ... 31
1.2. Les ressources intervenant sur le projet ... 31
1.3. Suivi de projet ... 33
1.4. Méthodologies et leur application au sein du projet ... 34
1.5. Planning du chantier Unix/Windows... 38
2. Un environnement technique à construire... 39
2.1. Mise en place de la configuration logicielle ... 39
2.2. Montage d’environnements de recette ... 42
3. Utilisation d’un nouveau langage : XBRL ... 44
3.1. Introduction au langage XBRL ... 44
3.2. Les enjeux du langage XBRL... 46
3.3. Les contrôles... 47
4. Des analyses et des solutions... 47
4.1. La vision utilisateurs... 48
4.2. Etude d’impact ... 48
4.3. Réorganisation des traitements... 50
4.4. Nouveaux transferts de fichiers... 56
4.5. Mémoire Java et des risques à éviter... 60
5. La réalisation... 62
5.1. Nouvelle organisation : identifier les acteurs ... 62
5.2. Transformer l’étude d’impact en plan d’action... 64
5.3. Coordonner l’intervention des acteurs... 66
5.4. Développer... 67
5.5. Documenter ... 68
6. Les tests... 69
6.2. Tests et table de vérité... 72
6.3. Recette utilisateur et sa préparation... 73
7. La mise en production... 74
7.1. Sécurisation de la mise en production ... 74
7.2. Plan de démarrage... 76
8. Conclusion ... 77
PARTIE III SYNTHESE ET BILAN ... 79
1. Synthèse des actions ... 79
1.1. Le point de départ : l’analyse ... 79
1.2. Proposer des solutions et choisir ... 79
1.3. Mobiliser et coordonner... 80
1.4. Tester... 80
1.5. Mise en production sécurisée... 80
2. Difficultés rencontrées... 81
2.1. Nouvelle organisation... 81
2.2. Mobilisation des acteurs... 81
2.3. Mise en référentiel non aboutie ... 81
3. Les succès ... 82
3.1. Respect des délais... 82
3.2. Méthodologie ... 82
3.3. Procédure de test... 82
3.4. Responsabilité du chantier Unix/Windows ... 82
Conclusion... 83
Liste des figures... 85
Glossaire ... 87 Références bibliographiques ... 89 1. Livres ... 89 2. Revues et publications ... 89 3. Sites internet ... 89 Résumé ... 91
I
NTRODUCTION
La crise financière du deuxième semestre de l’année 2008 a révélé au grand public le rôle majeur que tiennent les établissements financiers dans la santé économique d’un pays. Au-delà des pays, l’économie mondiale est dépendante de la situation de ces établissements financiers. Mais bien avant cette crise, les autorités de tutelle ont mis en place des mécanismes pour surveiller et protéger la bonne santé du secteur bancaire.
La BAFI (Base des Agents FInanciers) fait partie de l’arsenal mis en place pour jauger la situation économique des établissements financiers. Elle permet de présenter officiellement la situation financière et comptable aux autorités de tutelle (Banque de France et Banque Centrale Européenne). Mise en place en 1993, la BAFI fait l’objet d’une réforme sous l’impulsion du Secrétariat Général de la Commission bancaire ainsi que de la Banque de France ; cette réforme permettra le remplacement de la BAFI par SURFI (Système Unifié de Reporting FInancier).
GCE Technologies qui développe et exploite le système d’information des Caisses d’Epargne joue un rôle important dans la mise en œuvre de la BAFI au sein du groupe BPCE (Banque Populaire et Caisse d’Epargne). BPCE a choisi le progiciel Evolan Report de la société Sopra pour la production des états réglementaires ; états qui sont ensuite envoyés aux autorités de tutelle. GCE Technologies exploite ce progiciel et l'alimente avec les données bancaires du système d'information mises au format attendu. Cette réforme qui permet le remplacement de la BAFI par SURFI concerne donc directement GCE Technologies.
Ce mémoire rend compte de notre travail dans le projet « SURFI, réforme de la BAFI », projet qui a pour objectif la mise en œuvre de la réforme SURFI au sein de GCE Technologies. Notre travail a été principalement axé sur l’installation de la nouvelle version du progiciel Evolan Report mais aussi sur les évolutions à apporter au socle technique UNIX.
Pour mieux comprendre dans un premier temps le cadre dans lequel s’est déroulé le projet, nous présentons l’entreprise GCE Technologies, puis notre situation et notre rôle dans cette entreprise. Ensuite nous abordons la BAFI de manière générale et sa mise en œuvre au sein de GCE Technologies. Pour terminer de poser le cadre, nous expliquons les enjeux de la réforme SURFI.
Dans un deuxième temps nous abordons le projet lui-même : son équipe et son environnement technique ainsi que l’utilisation d’un nouveau format d’échange d’informations financières : XBRL (eXtensible Business Reporting Language). Nous décrivons les phases d’analyse, de proposition de solution et de réalisation. Et enfin, les tests réalisés et la préparation à la mise en production.
Une dernière partie est consacrée à un bilan du projet et à la description des différents rôles que nous avons tenus. Les difficultés rencontrées y sont décrites ainsi que les succès qui ont jalonné le projet.
PARTIE I
CADRE DU PROJET
1. GCE Technologies
1.1. GCE Technologies dans le groupe BPCE
Le groupe BPCE est issu du rapprochement de 2 réseaux coopératifs bancaires : les Banques Populaires et les Caisses d’Epargne. Le groupe compte 37 millions de clients, 7 millions de sociétaires et comporte 120 000 collaborateurs. De par leur importance, ces chiffres montrent la place prépondérante de la BPCE dans le paysage bancaire français.
Figure 1 : Organigramme financier du groupe BPCE1
1
Les Caisses d’Epargne et les Banques Populaires participent financièrement à hauteur de 50% envers l’organe central du groupe BPCE. Ce dernier possède quant à lui plus de 70% de Natixis mais aussi des filiales comme des sociétés d’assurance ou bien d’autres réseaux bancaires nationaux ou internationaux. Enfin les Caisses d’Epargne et les Banques Populaires possèdent des participations dans d’autres sociétés bancaires ou immobilières.
GCE Technologies est un GIE (Groupement d’Intérêt Economique) filiale du groupe BPCE. Elle assure les activités de maîtrise d’œuvre informatique des Caisses d’Epargne en répondant à leurs besoins correspondant à la stratégie informatique définie par le groupe BPCE. La maîtrise d’ouvrage du système d’information est, quant à elle, assurée par un deuxième GIE : GCE Business Services (GCE BS). Notons qu’une part importante des besoins en informatique des Caisses d’Epargne provient de contraintes réglementaires imposées.
Figure 2 : Gouvernance du système d'information
Les missions de GCE Technologies sont les suivantes :
• Spécification des besoins exprimés par les métiers et proposition de solutions
• Développement et exploitation du système d’information des Caisses d’Epargne et des filiales
• Gestion des interfaces avec les systèmes interbancaires
• Gestion d’activités industrielles bancaires telles que l’édition de documents, le traitement de valeurs ou la surveillance d’automates bancaires.
1.2. PIA et financement
GCE Technologies est financé par l’ensemble des Caisses d’Epargne à travers le PIA (Plan Informatique Annuel). Le PIA constitue pour les Caisses d’Epargne et BPCE la formalisation de l’engagement de GCE BS et GCE Technologies de livrer les nouvelles fonctionnalités du système d’information.
Un PIA est élaboré de la façon suivante : des réunions organisées par métier permettent d’exprimer les besoins d’évolution du système d’information. Les équipes de maîtrise d’ouvrage recensent, hiérarchisent et formalisent les besoins exprimés. Ceux ci sont chiffrés puis un arbitrage se fait compte tenu de l’enveloppe budgétaire. Les projets retenus constituent le PIA. La réalisation du PIA par GCE BS et GCE Technologies est financée par les Caisses d’Epargne.
1.3. Son histoire récente : un système d’information unique
1.3.1. Vers un système d’information unique
Auparavant chaque Caisse d’Epargne régionale avait son propre service informatique. Chaque service informatique, même s’il élaborait les mêmes produits, avait un fonctionnement, des socles techniques, une culture d’entreprise propres à chacun.
Afin de rester concurrentielles en France, des Caisses d’Epargne Régionales se sont regroupées ayant pour conséquence le même regroupement au niveau de leurs services informatiques. Ainsi, en 2000 ne restaient plus que huit plateformes applicatives pour gérer l’informatique des Caisses d’Epargne.
Le projet stratégique du Groupe Caisse d’Epargne pour les années 2000-2003 consacrait une large place à la rationalisation de l’informatique. Dès 2000 il avait été décidé de n’avoir plus que 3 plateformes informatiques : Arpège, RSI et SIRIS. Ce sera chose faite en 2003.
Fin 2006, les Caisses d’Epargne décident d’adopter un système d’information unique pour des enjeux aussi bien commerciaux que financiers. Simultanément les Caisses d’Epargne régionales continuent de fusionner entre elles. Toutes les Caisses d’Epargne ont migré sur ce nouveau système en mai 2010. Pour ce faire, le projet PSI (Performance du Système d’Information) est lancé. La plateforme informatique de SIRIS est choisie pour supporter le futur système d’information unique des Caisses d’Epargne, il s’appelle désormais MySys.
1.3.2. Le dernier acte pour construire la plateforme unique
Comme nous venons de le voir, le regroupement des Caisses d’Epargne sur un seul système d’information se termine en mai 2010. Le projet PSI a donc permis de passer de trois à une plateforme mais également d’effectuer des fusions de Caisses d’Epargne. Ce qui nous intéresse ici, c’est d’exposer les grands principes de ce programme et de montrer les impacts sur le déroulement des projets d’édition.
Dans le cadre du projet PSI une nouvelle organisation au sein de GCE Technologies a été mise en place. Nous souhaitons nous attarder sur ce dernier point pour souligner les changements opérés et leurs impacts sur les projets. Cette nouvelle organisation a entrainé une importante réorganisation des services. Les équipes ont changé, de nouveaux processus ont été mis en place, des cultures d’entreprise différentes ont dû cohabiter. Notre projet a débuté dans cet environnement ce qui a entraîné un travail supplémentaire pour maitriser les nouveaux processus et identifier les différents services à solliciter pour intervenir au sein de notre projet.
1.3.3. La restructuration Caisses d’Epargne et Banques Populaires
Le rapprochement des Caisses d’Epargne avec les Banques Populaires impactent peu MySys pour le moment. Les deux banques ont leur propre système d’information. Des changements apparaissent au niveau des applications de consolidation au niveau groupe. A contrario, notre projet se déroule quasiment à l’identique d’une situation sans les Banques Populaires ; cette restructuration nous impacte très peu.
1.4. Son organisation
GCE Technologies est dirigée par un directoire sous lequel se trouvent 4 directions : l’Edition, les Grands Projets, les Relations Adhérents et la Production. L’organisation est résumée dans la figure 3. Nous avons mis en couleur les principaux départements concernés par le projet.
1.5. MySys, sa plateforme informatique
1.5.1. L’architecture de MySys
Le projet PSI évoqué précédemment a permis de disposer d’une plateforme informatique unique au service des Caisses d’Epargne. Cette plateforme a été baptisée MySys (contraction de My System : Mon Système en Français).
MySys se veut une plateforme d’accueil multi-bancaire (des banques autres que les Caisses d’Epargne y sont hébergées), multi-canal (les clients peuvent accéder à leur banque via Internet, leur téléphone portable, les automates bancaires, les points de vente, etc...) et multiservices (différents services proposés : banque de détail, d’investissement, de développement régional, etc.). Elle est constituée de divers éléments qui interagissent entre eux :
• Le système central : il est le constituant principal du système ; il fournit les principaux services bancaires tels que la gestion client, l’octroi de crédits, la gestion des produits bancaires (comptes de dépôt, livrets, cartes bancaires, etc.). Ce système central est constitué de machines IBM zSeries gérées par le système d’exploitation z/OS. Les données sont stockées dans des bases de données DB2.
• Les systèmes péricentraux : ils hébergent des applications ne nécessitant pas une implantation sur un système central ou bien ne pouvant être hébergées sur un système central. Ces systèmes péricentraux sont alimentés majoritairement par des données en provenance du système central. Ils supportent des applications de crédit, de banque à distance (Internet), de backoffice (gestion du risque, décisionnel), etc. Les données sont stockées dans diverses bases de données (SQL Server, Oracle, Informix, etc.).
• Les postes de travail : dans les Caisses d’Epargne ils permettent la réalisation des opérations bancaires. Dans les centres informatiques ils permettent les évolutions et le pilotage de MySys ainsi que sa maintenance.
1.5.2. Deux instances de production
La plateforme MySys, nous l’avons vu, est basée sur celle de SIRIS. Cette dernière était multi établissement. Autrement dit chaque fichier de données qui venait alimenter les traitements comportait les informations de tous les établissements. Nous étions en présence d’une seule instance de production. Nous entendons par instance de production l’ensemble des traitements nécessaires à la gestion d’un groupe d’établissement.
La fusion des trois plateformes informatiques en une seule a entrainé des opérations de migration : les Caisses d’Epargne hébergées sur les systèmes RSI et Arpège, systèmes non retenus, migrent petit à petit sur le système MySys. Afin d’absorber la nouvelle charge de traitement des nouvelles Caisses d’Epargne, il a été décidé de mettre en place une deuxième instance de production parallèle à l'instance historique baptisée IP1 (Instance de Production 1). La nouvelle instance se nomme IP2. Tous les traitements de IP1 ont été clonés sur IP2. Ainsi chaque programme est installé deux fois sur MySys.
Cette architecture technique n’a théoriquement pas d’impact pour les projets de développement car, par principe, les deux instances de production doivent être strictement identiques. Les mises en production des évolutions logicielles se font en « Y ».
Sur la figure 4, nous pouvons voir qu’une évolution d’un traitement est mise en production simultanément sur les deux instances de production de manière identique. Cela forme un « Y » à l’envers. Chaque instance traite les données d’un ensemble de Caisses d’Epargne définies.
Figure 4 : Deux instances de production
2. L’auditeur et GCE Technologies
2.1. La situation de l’auditeur dans l’organisation
Nous nous trouvons au sein de la direction de l’Edition, dans le département Finance Risque Pilotage. Ce département est découpé en 4 pôles dont le pôle Comptabilité, Finance et Recouvrement au sein duquel nous travaillons. Ce département a la responsabilité du développement et de l’évolution de diverses applications liées à la comptabilité (comme l’intégration de progiciels comptables permettant la comptabilité des établissements), à la finance (gestion de bilan par exemple) mais aussi au recouvrement de créances. Il compte une quarantaine de collaborateurs.
La grande majorité des projets de développement au sein de ce pôle sont à destination d’utilisateurs de backoffice des Caisses d’Epargne (agences ou sièges).
2.2. Référent adjoint de la BAFI
Au sein du pôle Comptabilité, Finance et Recouvrement, les collaborateurs organisés en binôme sont responsables d’applications (ou de domaines) privilégiées sur lesquelles ils sont amenés à travailler prioritairement. Ce sont des référents et référents adjoints. Ceci leur permet d’acquérir une expertise poussée de l’application qu’ils ont en responsabilité.
Dans notre cas, notre rôle de référent adjoint du domaine de la BAFI (que nous allons présenter dans le chapitre suivant) sur MySys nous amène à travailler prioritairement sur cette application. Nous tenons ce rôle depuis 2008. Auparavant nous travaillions sur le système d’information Arpège et sur d’autres applications. Nous avons hérité d’une application gérée par une équipe de collaborateurs qui travaillaient exclusivement sur celle-ci depuis de nombreuses années. Leur connaissance de l’application était grande, ils n’avaient pas éprouvé le besoin de disposer d’une documentation produit complète. Notre premier travail a été de produire cette documentation qui n’existait pas ou que partiellement. Cette documentation s’est révélée par la suite indispensable dans le projet qui nous intéresse. Elle nous a permis d’une part d’acquérir une bonne connaissance de l’application et de ses particularités et d’autre part de disposer d’un support exhaustif pour les futures études d’impact de notre projet.
3. Présentation de la BAFI
3.1. La BAFI
3.1.1. Historique
Dans les années soixante-dix, les systèmes d’information conçus par les banques étaient principalement orientés vers la collecte d’informations comptables. Avec les années quatre-vingt apparaissent les bases de données et les fichiers permettant un regroupement des informations concernant un même client (lieu de résidence, catégorie d’agent économique, etc.). Les années quatre-vingt-dix voient apparaître la gestion globale du risque nécessitant un système d’information complet et performant. C’est ainsi qu’a été mise en place la Base des Agents FInanciers, la BAFI en 1993.
3.1.2. Qu’est-ce que la BAFI ?
La BAFI est un système homogène de collecte d’informations que les établissements financiers doivent transmettre. Cette collecte permet de répondre aux besoins du contrôle prudentiel mais aussi à l’élaboration de statistiques monétaires. La BAFI permet de donner une vision globale de l’activité d’un établissement (et donc de sa santé) puisqu’elle se fait selon deux axes : les données issues de la gestion (situation fin de mois des comptes courants, des
crédits, etc.) et les données issues de la comptabilité (soldes de chaque compte comptable). Un rapprochement est effectué entre les deux sources afin d’en vérifier la cohérence.
La collecte est restituée sous forme d’états informatiques transmis périodiquement. Ces états informatiques, une fois alimentés, sont encapsulés dans des fichiers de format propriétaire suite à une action de « déclaration » de la part des utilisateurs. Effectuer une déclaration signifie créer le fichier qui contient l’ensemble des états à envoyer à la Banque de France. L’alimentation des états se fait en fonction de critères différents pour chacun. Une même opération peut être analysée de manière différente en fonction du critère qu’on lui attribue.
Outre la production d’états réglementaires, la mise en place de la BAFI en 1993 s’est accompagnée de l’alimentation d’une piste d’audit sur les données traitées. C'est-à-dire une nécessité de garder une traçabilité ascendante et descendante sur toute donnée d’alimentation de la BAFI. En effet, une donnée peut avoir été produite à partir de plusieurs données ; il est nécessaire de garder une trace de cela.
La figue 5 nous donne l’exemple d’une opération bancaire en agence et de sa répercussion jusque dans la BAFI. Cet exemple est simplifié car le niveau de détail des états réglementaires ne va pas jusqu’au client. Il y a toute une série d’agrégations qui sont tracées dans la piste d’audit.
3.2. Sa mise en œuvre au sein des établissements financiers
La mise en place de la BAFI au sein d’un établissement financier nécessite un certain degré d’informatisation des données de gestion et a demandé une remise à plat de certains systèmes d’information. En effet, l’information demandée est riche et la mise en place d’une piste d’audit implique l’identification de certaines données en permanence à l’aide d’opérations techniques automatisées. Par contre lors de la mise en place de la BAFI les établissements sont restés libres quant à l’organisation interne de l’information pour autant que la fiabilité des données soit assurée par l’existence d’une piste d’audit.
3.3. Ses contraintes
Comme nous l’avons vu précédemment, la BAFI est réglementaire et doit donc respecter certaines contraintes imposées par les autorités de tutelle.
3.3.1. Fiabilité des données
La fiabilité des informations fournies est assurée par une piste d’audit qui permet à partir de n’importe quelle donnée de la BAFI d’effectuer une remontée à la source et de consulter les informations qui ont contribué à l’alimentation de celle-ci. Des inspections de la commission bancaire sont réalisées au sein des établissements pour vérifier la conformité de cette piste d’audit.
3.3.2. Délais de remise
Des contraintes de délai de restitution des états réglementaires sont imposées par les autorités de tutelle (Commission Bancaire et Banque de France). Les états sont restitués chacun à des périodicités différentes : il y a ainsi des états mensuels, trimestriels et annuels. Ensuite pour chaque état, l’autorité impose une date buttoir de remise au-delà de laquelle l’établissement financier subit de lourdes pénalités financières dissuasives. Les établissements financiers font ainsi le maximum pour arriver dans les temps.
3.3.3. Synthèse
Ces contraintes ne sont pas anodines et remontent de toute évidence jusqu’au système d’information qui doit fournir un service de qualité, rapide et robuste. Nous verrons plus loin que cette contrainte des délais a pris une place importante dans notre phase d’analyse du projet.
4. La BAFI chez GCE Technologies
4.1. Organisation
Nous évoquons ici l’organisation de la BAFI de manière générale au quotidien. L’organisation mise en place par le projet qui nous intéresse est détaillée plus loin dans ce mémoire.
Nous avons vu précédemment que nous nous situions dans le département Finance Risque et Pilotage (FRP) au pôle Comptabilité, Finance et Recouvrement. Nous sommes référent BAFI, de ce fait, nous participons prioritairement aux projets liés à la BAFI. Cela concerne ici la partie développement logiciel. La partie maintenance des applications est quant à elle, assurée par des équipes dédiées qui interviennent en cas de soucis lorsque les applications sont en production. L’équipe de maintenance de la BAFI est également dans le département FRP mais dans un pôle différent : « Pilotage Etablissement et Maintenance ». Nous verrons par la suite que nous avons été amenés à établir un dialogue permanent avec cette équipe, source de conseils lors de nos analyses du projet. De même, lorsqu’un projet est en développement, l’équipe de maintenance intervient pour s’informer des évolutions apportées et éventuellement effectuer des réserves quant à la conception.
Enfin nous devons également mentionner l’équipe d’exploitation qui veille au bon déroulement des traitements informatiques et donc ceux de la BAFI. Ces équipes sont plutôt en relation avec les équipes de maintenance, mais nous les avons également sollicitées pour avoir leur avis sur certains points précis du projet.
La figure 6 nous présente les différentes interactions qu’il y a entre les acteurs participant au fonctionnement de la BAFI chez GCE Technologies.
4.2. Utilisation d’un progiciel : Evolan Report
Différents éditeurs proposent des solutions logicielles pour la production des états réglementaires BAFI. Ainsi des sociétés comme Sopra, Viveo ou Invoke tiennent une large place dans le domaine du reporting financier et donc de la BAFI.
La solution retenue pour MySys est celle de l’éditeur Sopra : le logiciel « Evolan Report ». A part le module Client, le reste du logiciel peut être indifféremment installé sur des socles UNIX, Windows ou encore z/OS (gros système IBM).
Evolan Report se compose de quatre modules ayant chacun son propre rôle : Client, Server, Engine et Références croisées (que nous appelons XRef pour plus de lisibilité). La figure 7 nous donne les interactions existantes entre chacun des modules ainsi que le point d’entrée des données. Nous voyons que deux bases de données sont présentes, la première alimentée par le module Server et la deuxième par le module Engine.
Figure 7 : Architecture du logiciel Evolan Report
4.2.1. Principe général de fonctionnement
Le fonctionnement général d’Evolan Report est le suivant : l’utilisateur effectue des demandes de fabrication d’états réglementaires à travers le module client. Ces demandes transformées en fichiers par le module Server sont envoyées au module Engine qui, à l’aide des données bancaires, fabrique les résultats. Ceux-ci sont ensuite renvoyés vers le module Server puis chargés dans la base de données.
4.2.2. Le module Client
Ce module permet d’offrir aux utilisateurs une interface graphique à travers laquelle ils effectuent toutes les opérations nécessaires à la production des états réglementaires :
• envoi des demandes de fabrication
• consultation/modification des états
• production des fichiers réglementaires
• paramétrage
• etc.
La figure 8 nous montre un état réglementaire alimenté tel qu’il apparaît à l’utilisateur à travers le module Client.
Figure 8 : Etat Evolan Report.
4.2.3. Le module Server
A l’écoute permanente du Client, le module Server prend en compte les demandes faites par l’utilisateur pour les transmettre ensuite au module Engine. A l’inverse ; il permet la transmission des résultats de fabrication produits par Engine vers le Client. Ce module possède sa base de données dans laquelle il stocke les demandes faites par l’utilisateur ainsi que les résultats de fabrication.
4.2.4. Le module Engine
Le module Engine est en activité lors de traitement batch. Engine prend en compte les demandes de l’utilisateur transmises par le Server et produit des résultats de fabrication qui permettent d’alimenter les états à partir des données bancaires. Engine possède sa base de données dans laquelle sont stockées les données bancaires.
4.2.5. Le module Références Croisées
Le module Xref, basé sur un serveur Web, propose à l’utilisateur d’effectuer des recherches d’informations croisées selon différents axes ; par exemple, quels attributs alimentent un état ou alors quels états sont concernés par un compte comptable.
Dans la figure 9, nous pouvons visualiser le résultat d’une requête Xref qui montre les attributs concernés par un état.
Figure 9 : Résultat d'une requête références croisées
4.3. Alimentation du logiciel Evolan Report
Nous avons vu précédemment que la BAFI était alimentée d’une part avec les données des applications de gestion et également avec les données de la comptabilité. Chez GCE Technologies, ces deux catégories de données sont produites sur gros système z/OS sous forme de CRI (Compte Rendu d’Inventaire). Ces CRI ne peuvent être présentés tels quels à l’entrée d’Evolan Report. En effet, Evolan Report attend des ESTD (Entrées standards), c'est-à-dire des enregistrements ayant une structure déterminée : chaque enregistrement possède une partie fixe non modifiable imposée par Sopra et une partie variable comportant les attributs. Dans cette dernière les attributs sont structurés à la discrétion de l’entreprise.
Ce format particulier des données nécessite de transformer les CRI en ESTD. C’est le rôle de l’interfaçage.
4.4. D'autres applications autour de Evolan Report
4.4.1. GEIDE
Les traitements du module Engine produisent des états contenant des informations sur les données d'alimentation (ESTD). Certaines données sont notamment rejetées car non-conformes à ce qui est attendu (attribut non renseigné ou montant à zéro par exemple). Ces états sont récupérés en fin de
traitement Engine pour ensuite être envoyés vers le z/OS. A l'arrivée des états sur z/OS, un traitement les transfère sur le serveur GEIDE (Gestion Electronique d’Informations et de Documents de l’Entreprise). Les états sont alors accessibles via une interface web par les utilisateurs.
4.4.2. BO
Nous avons vu précédemment qu'une piste d'audit est en place concernant la constitution des données d'alimentation de la BAFI. Les traitements du z/OS fabriquent des fichiers de piste d'audit qui sont transférés sur le serveur UNIX pour être enfin chargés dans une base de données.
Les utilisateurs, via le logiciel BO (Business Object), peuvent consulter cette piste d'audit depuis leur poste et donc interroger le détail des données qui sont fournies par le z/OS en entrée du logiciel Evolan Report.
4.5. Principe de fonctionnement
Nous allons expliciter les notions fondamentales du fonctionnement du logiciel Evolan Report : la session, le traitement Engine et l’organisation générale.
4.5.1. La session
La notion de base du logiciel Evolan Report est la « session ». A une session correspond un environnement de travail. Par exemple, dans la session numéro un, l’utilisateur travaille sur la constitution des états à remonter mensuellement et sur la session numéro deux, il travaille sur les états trimestriels. Ou encore plusieurs utilisateurs d’une même Caisse peuvent travailler simultanément sur des sujets différents et donc sur des sessions différentes. Chaque Caisse d’Epargne dispose de vingt sessions.
Les sessions sont étanches et indépendantes les unes des autres au niveau de leurs données. Ainsi un utilisateur peut effectuer une modification d’une donnée en entrée du module Engine, cette modification ne se fait que pour la session en question. Les autres sessions ne sont pas impactées par cette modification.
Une session peut faire l’objet de différentes actions/demandes qui, pour être complètes, doivent toutes être soumises à un traitement Engine :
• Ouverture : L’utilisateur ouvre une session en effectuant une sélection d’états (parmi une liste prédéfinie) qui participent à la session. D’autres paramètres sont à saisir pour définir la session tels que la périodicité de la session, la date d’arrêté traitée, le nom de la session, etc.
• Fabrication : ne peut se faire que sur une session ouverte, l’utilisateur effectue des modifications de paramétrage ou de données en entrée d’Engine et demande une nouvelle fabrication des états
• Fermeture : L’utilisateur n’a plus besoin de la session, il a produit ses fichiers de déclaration à envoyer à la Banque de France, il peut donc fermer sa session
• Archivage : la session est archivée dans des fichiers physiques qui sont conservés sur la machine UNIX. Cette session peut faire l’objet d’une
restauration. A noter que les données qui ont participé à l’élaboration de la session sont également archivées et peuvent également être restaurées.
• Restauration : une session archivée est mise à disposition de l’utilisateur dans l’interface du logiciel
4.5.2. Le traitement Engine
Le module Engine se compose de programmes qui sont lancés en batch. Le batch prend en compte les demandes faites par le client (ouverture, fabrication ou fermeture de session) et y répond à l’aide des données envoyées par le z/OS. Il produit des résultats de fabrication qui sont ensuite chargés dans une base de données du module Server. Ces résultats sont alors consultables via le client à travers les états remplis.
4.5.3. Fonctionnement général
Figure 10 : Les journées de la BAFI
La figure 10 donne un aperçu des traitements dans le cas d’un utilisateur qui travaille sur quatre sessions simultanément.
Le cycle de production des états BAFI n’est pas instantané et répond à une organisation des traitements qui est la suivante : en journée, les utilisateurs effectuent autant de demandes qu’ils souhaitent. Ces demandes sont traduites par le module Server en fichiers « Pilfab » (pilotage de fabrication) qui sont stockés en attente d’envoi au module Engine. La nuit le traitement Engine se déroule : prise en compte des Pilfab et production des résultats de fabrication (Resfab) à partir des données envoyées par le z/OS. Les résultats de fabrication sont donc disponibles le lendemain pour les utilisateurs.
4.6. Architecture technique
4.6.1. Architecture technique générale
La figure 11 nous donne une description de l’architecture technique chez GCE Technologies.
Figure 11 : Architecture technique de la BAFI chez GCE Technologies
Les trois modules Engine, Server et XRef sont hébergés sur un serveur UNIX de type AIX. Le module Client quant à lui se trouve sur une machine Windows.
Nous pouvons également mentionner la partie alimentation des données qui se trouve sur serveur central z/OS et qui vient en entrée du batch du module Engine pour la fabrication des résultats.
Nous découvrons également sur le module Server un service appelé Maestro. Celui-ci est à l’écoute des demandes du client et les transmet à un deuxième service appelé Process. Ce dernier fabrique des fichiers, traduisant les demandes faites par l’utilisateur, appelés « fichiers de pilotage ». Ils sont envoyés à Engine.
4.6.2. Architecture technique du module Client
Afin d’accroitre les performances et garantir la disponibilité de l’application Evolan Report, un système de double serveur Windows avec équilibre de charge a été mis en place pour supporter le module Client.
Le module Client, tout comme les autres modules, est installé sur MySys et non dans les Caisses d’Epargne. Chaque utilisateur dans les établissements accède donc à Evolan Report à distance, rien n’est installé sur son poste. Cet accès se fait via une connexion Citrix. Cela veut dire que plusieurs utilisateurs de plusieurs établissements accèdent simultanément au module Client.
Une seule machine ne peut supporter toutes les connexions pendant un long moment et l’apparition d’une panne est synonyme de coupure de service pour l’ensemble des établissements. Deux machines ont été montées sur chaque instance de production. Le module Client d’Evolan Report a donc été installé deux fois par instance. Les deux machines fonctionnement en équilibre de charge. Ainsi, la coupure d’une machine n’entraîne pas une coupure de service puisque la deuxième peut prendre temporairement le relais. Les performances sont accrues car l’ensemble des établissements d’une instance de production se partagent deux machines.
Figure 12 : Machines Windows
4.7. Architecture organisationnelle
Nous décrivons ici le fonctionnement global de la BAFI et les interactions entre les différents acteurs que sont les utilisateurs, MySys et BPCE. Il s’agit de comprendre notamment les différents échanges pratiqués entre chacun.
Voici le détail de chacun des échanges observés sur la figure 13 :
1 : L’utilisateur se connecte à l’interface d’Evolan Report et émet une demande de fabrication
2 : La demande de fabrication est transmise immédiatement au module Server puis la nuit au module Engine qui traite les demandes et crée des résultats de fabrication qu’il renvoie au module Server
4 : Les états sont remplis et à disposition de l’utilisateur
5 : L’utilisateur peut consulter les états à partir de l’interface Evolan Report 6 : L’utilisateur effectue une déclaration : des fichiers contenant les états déclaratifs sont produits sur son poste et envoyés à BPCE via une interface dédiée.
7 : BPCE envoie les fichiers de tous les établissements du groupe à la Banque de France.
Figure 13 : Architecture des échanges de la BAFI
4.8. Langages utilisés
La BAFI s’appuyant sur une solution à base de progiciel, il faut distinguer deux catégories : d’une part les langages utilisés dans le logiciel Sopra et d’autre part ceux mis en oeuvre pour l’intégration du logiciel Evolan Report dans MySys. Nous pourrions ne pas nous intéresser aux langages du logiciel de Sopra, mais certains livrables Sopra sont adaptés pour fonctionner sur MySys, il est donc important de les mentionner. Ainsi nous rencontrons du Cobol, du SQL et du Korn-Shell dans le logiciel Evolan Report. Des programmes utilisant ces deux derniers langages ont été modifiés pour permettre un fonctionnement optimal sur le système d’information MySys.
Concernant l’intégration du logiciel à MySys, les programmes sont développés en Korn-Shell et SQL pour la partie UNIX et en batch DOS pour la partie Windows. Enfin, tous les traitements Unix sont lancés de manière automatique par un ordonnanceur. Sur MySys, l’ordonnanceur est Visual TOM (VTOM).
4.9. Les environnements
Au commencement du projet SURFI en début d’année 2009, la BAFI possédait deux environnements : la production sur laquelle tourne le logiciel au profit des Caisses d’Epargne et un environnement de test qui n’était pas à l’image de la
production (en terme notamment d’architecture technique). Cet environnement permettait à l’équipe de maintenance d’effectuer leur travail au quotidien et notamment le test des correctifs à chaud.
Pour des questions de sécurisation, nous n’avons pas voulu que le projet SURFI se déroule dans ces conditions techniques avec un manque important d’environnement de développement et de recette conformes à l’architecture technique de l’environnement de production. Nous avons donc fait la demande de montage d’un environnement de développement qui nous permettrait d’effectuer les tests unitaires et d’un environnement de recette utilisateur, à l’image de la production. Nous avons obtenu l’environnement de recette utilisateur seulement. Le suivi du montage et sa réception font l’objet d’une description plus loin dans ce mémoire.
Parallèlement à ces demandes, au lancement du projet, la maîtrise d’ouvrage a exprimé le besoin de disposer, pour la recette du projet, d’un environnement de volumétrie réelle. Cette demande fait également l’objet d’une description plus tard dans le texte. Il a été monté avec la plus grosse Caisse d’Epargne en termes de volumétrie de données et a nécessité un investissement en temps important pour sa construction et sa mise au point.
5. Réforme de la BAFI : SURFI
5.1. Présentation de la réforme
Nous décrivons maintenant les raisons qui ont conduit les autorités de tutelle à lancer une réforme de la BAFI.
Nous l’avons vu la BAFI permet la collecte d’informations en provenance de la gestion et de la comptabilité. Nous pouvons rajouter que deux familles d’états se côtoient : les états 4000 (états périodiques et comptables) et les états 8000 (états statistiques et monétaires) incluant la surveillance des grands risques.
Des critiques sont apparues en provenance aussi bien des établissements financiers que des autorités de tutelle sur le fond et sur la forme. La BAFI souffre d’un format propriétaire pour la production des états, lourd à faire évoluer et non homogène avec les autres reportings (par exemple le COREP). Enfin certaines informations sont redondantes, une rationalisation de celles-ci doit être faite.
En 2007, la Banque de France et la Commission bancaire décident de lancer une réforme de la BAFI intitulée le SURFI (Système Unifié de Reporting FInancier). Cette réforme a les objectifs suivants :
• Réduire de 25% la charge de travail nécessaire à la production des reportings tout en continuant à garantir la continuité de supervision. Ceci en réduisant le nombre d’informations demandées et en supprimant les redondances.
• Fournir des données statistiques demandées par la BCE (Banque Centrale Européenne) améliorant la qualité de la supervision.
• Changer de format d’échange entre les établissements financiers et la Banque de France, à l’instar du COREP, en utilisant le XBRL (eXtensible Business Reporting Language) permettant ainsi une meilleure exploitation des informations.
5.2. Impacts dans les établissements financiers
Les impacts se rencontrent à deux niveaux : du côté du backoffice de chaque établissement financier et au niveau des systèmes d’information.
Au niveau des systèmes d’information :
• Production de nouvelles données dans les systèmes de gestion.
• Evolution majeure du logiciel de fabrication des états réglementaires Au niveau du backoffice :
• Nouvelles méthodes de remise à la Banque de France. Cette dernière met en place un nouveau portail intitulé « Onegate » à partir duquel les fichiers des états réglementaires seront déposés à partir de juillet 2010.
• Réduction des délais de remise à la Banque de France : J+25 calendaires à J+10 ouvrés pour l’équivalent des états de bilan trimestriels.
5.3. Impacts pour GCE Technologies
Chez GCE technologies, la mise en place de SURFI entraine :
• La production de nouvelles données en provenance des applications de gestion et à mettre en entrée du batch Engine
• La modification des interfaces de mise au format ESTD pour prendre en compte les nouvelles données à alimenter
• Une montée de version du logiciel Evolan Report
• Une logique de transfert des fichiers de déclaration à revoir 5.4. Contraintes de la réforme
La contrainte majeure de la réforme se trouve au niveau des délais. En effet, tous les établissements financiers doivent effectuer une déclaration SURFI sur les données de fin de mois au 30 juin 2010. Cela donne peu de marge de manœuvre en cas de difficultés et amène, nous le verrons, une sécurisation accrue de la mise en production du projet.
Une autre contrainte est liée à l’utilisation du logiciel Evolan Report provenant d’un éditeur externe. Nous sommes en effet dépendants de la date de livraison des composants. Or GCE Technologies possède des normes de mise en production basées sur un système de version. Une version correspond à l’ensemble des évolutions apportées au système d’information MySys à une date prédéfinie. GCE Technologie, de manière générale, propose deux dates par an à l’occasion desquelles le système d’information peut être modifié par l’installation d’une version. SURFI va être mise en production lors de la version de juin. Or une
version possède des jalons qu’un projet doit respecter. La livraison en plusieurs lots du logiciel Evolan Report a nécessité des aménagements par rapport aux contraintes de la version.
6. Conclusion
Cette première partie nous a permis de tracer le cadre du projet SURFI. SURFI, Système Unifié de Reporting FInancier est une réforme de la BAFI, mécanisme de reporting financier imposé par les autorités de tutelle. GCE technologies, exploitant le système d’information des Caisses d’Epargne dans le groupe BPCE, met en œuvre ce reporting et doit donc mettre en place la réforme SURFI. Nous avons ainsi décrit le fonctionnement de la BAFI chez GCE Technologies et les contraintes apportées par la réforme.
Nous pouvons maintenant décrire le projet tel qu’il s’est déroulé et plus particulièrement les actions que nous avons effectuées. Ceci est l’objet de la deuxième partie.
PARTIE II
LE PROJET
Nous l’avons vu précédemment, la réforme de la BAFI initiée par la Banque de France doit être mise en place dans les établissements financiers à la mi-2010. Cela s’est traduit chez GCE Technologies par la mise sur pied d’un projet qui s’intitule « SURFI, réforme de la BAFI ». Ce mémoire s’appuie sur ce projet et plus particulièrement sur l’un des chantiers du projet. Nous décrivons ici sa mise en place, son déroulement et nos interventions au sein de celui-ci.
1. Equipe projet et méthodologie
1.1. Découpage en chantiers
Nous l’avons déjà évoqué précédemment, les impacts de la mise en place de SURFI sont d’une part de nouvelles alimentations de données et donc une modification des interfaces et d’autre part une montée de version du logiciel Evolan Report. Ces deux impacts concernent des technologies différentes. Ainsi tout ce qui concerne l’alimentation et l’interfaçage des données est réalisé sur gros système, type z/OS alors que le logiciel Evolan Report est installé sur de l’UNIX et du WINDOWS. Il a été décidé de découper le projet en deux chantiers techniques :
• un chantier z/OS ayant pour responsabilité les évolutions à apporter à l’alimentation et l’interfaçage des données
• un chantier UNIX/Windows ayant en charge la montée de version du logiciel Evolan Report ainsi que toutes les évolutions de technologies Windows et UNIX.
Ce deuxième chantier est le support de notre mémoire. 1.2. Les ressources intervenant sur le projet
Du côté de la réalisation du projet, celui-ci s’articule autour de trois personnes principales: le chef de projet maîtrise d’œuvre (MOE), le responsable du chantier
z/OS et le responsable du chantier Unix/Windows, responsabilité qui nous a été confiée.
La figure 14 nous montre qu’à côté de ces trois personnes, d’autres intervenants participent au projet, nous avons :
• le chef de projet maîtrise d’ouvrage (MOA) du GIE GCE Business Services qui permet de faire le lien entre le projet et les utilisateurs.
• Le chef de projet « Production » qui appartient au pôle « Gestion Opérationnelle Projet ». Il permet de coordonner et faciliter les relations entre les équipes de la division de l’Edition (dont nous faisons partie) et les équipes de la division de la Production. Nous pouvons qualifier sa fonction de « facilitateur ».
• Une autre personne de GCE Business Services intervient également lors des recettes avec les utilisateurs : l’assistance MOA, elle assure la préparation des recettes, assiste les utilisateurs et effectue le reporting des recettes.
• Des responsables d’application de gestion, ces applications qui livrent les données sous forme de CRI (Compte Rendu d’Inventaire) avant l’interfaçage. Ces responsables sont en liaison avec le chantier z/OS qui coordonne les évolutions à apporter dans les applications de gestion.
• Des personnes de l’industrialisation. Les personnes sont différentes en fonction des technologies : il y a une personne pour le chantier z/OS et une pour le chantier Unix/Windows. L’industrialisation permet l’intégration des composants développés par un projet dans des chaînes de traitement automatisées. Ces personnes appartiennent au pôle « Gestion Applications Projet » (GAP). Ainsi ce sont ces équipes qui programment l’ordonnanceur Visual TOM (dit VTOM).
• Un administrateur de base de données (DBA) Oracle effectuant les modifications dans la base de données accédée par le logiciel Evolan Report.
• Une personne pour le montage des environnements de développement qui se trouve dans le pôle « Services Système d’Information Edition » (SSIE). Elle-même a plusieurs interlocuteurs qu’elle coordonne. Elle effectue également des installations de programme sur les environnements de l’édition.
Figure 14 : Les ressources intervenant sur le projet
1.3. Suivi de projet
Les suivis du budget et du planning ne sont pas sous notre responsabilité mais incombent au chef de projet. Néanmoins, il est important d’en avoir connaissance, notre travail doit être réalisé en conservant à l’esprit que le budget n’est pas extensible et que le respect du planning est essentiel.
1.3.1. Aspect budgétaire
Les charges budgétaires calculées en jours/homme sont estimées au lancement du projet. Une répartition des charges est effectuée selon les différentes phases du projet (Conception, Réalisation, Recettes, Déploiement, Pilotage). Ces charges sont revues à l’issue de la phase de conception.
Le suivi du budget est réalisé à l’aide de l’outil Clarity, cet outil permet d’avoir une vision synthétique du consommé et du reste à faire.
1.3.2. Planning
Un planning prévisionnel est réalisé au lancement du projet. Certaines dates sont données à titre indicatif et seront adaptées en fonction de la charge nécessaire à la réalisation des actions.
Des points projets hebdomadaires permettant un suivi régulier et précis de l’avancement du projet sont réalisés entre le chef de projet, le responsable du chantier z/OS et le responsable du chantier Unix/Windows. Ceux-ci permettent une réactualisation du planning de manière régulière et éventuellement la création d’alertes en cas de dérive trop importante du planning. Ces alertes sont ensuite suivies d’un plan d’actions destinées à contrer ces dérives.
1.4. Méthodologies et leur application au sein du projet
1.4.1. Théorie
Chez GCE Technologies, les projets sont gérés selon la méthodologie SDM/S et conçus selon la méthode Merise.
La méthode SDM/S utilisée classiquement pour le développement de grands projets de systèmes d’information, prévoit un découpage du projet en dix phases distinctes, comme le montre la figure 15.
• Demande de Service - Etude d’opportunité DS/EO
• Définition des besoins (DBS)
• Choix d’architecture (CAS)
• Spécifications externes (SES)
• Spécifications internes (SIS)
• Programmation (PROG) • Tests (TST) • Conversion (CONV) • Installation (INST) • Bilan Figure 15 : Phases de SDM/S2 2 D’après [LAF03]
Quant à la méthode Merise, la figure 16 nous montre les différentes étapes.
Figure 16 : Les phases de Merise
La combinaison de ces deux méthodes donne, chez GCE Technologies, les phases projets suivantes :
• L’expression de besoin : phase qui décrit les besoins de la maîtrise d’ouvrage en termes de nouveau système ou d’évolution du système.
• Le lancement du projet : cette phase permet d’identifier :
o la portée du projet c'est-à-dire de préciser les enjeux et objectifs, les résultats attendus, le champ de l’étude (étude de l’existant)
o Les modalités de déroulement du projet : Organisation du projet, découpages en phase, la structure du projet (ressources), l’assurance et contrôle qualité
o Le planning du projet
• Les spécifications externes qui permettent de décrire les évolutions apportées avec une vision métier. Ces spécifications doivent être validées par la maîtrise d’ouvrage.
• Les spécifications internes qui décrivent techniquement les évolutions apportées.
• Les développements et tests unitaires associés qui permettent la réalisation des programmes nécessaires à l’évolution demandée.
• La recette utilisateurs
• La qualification
1.4.2. Mise en pratique dans notre projet
Si nous venons de brosser les différentes phases d’un projet de développement chez GCE Technologies, nous allons maintenant préciser la démarche que nous avons retenue pour notre projet et plus particulièrement pour le chantier Unix/Windows. Des phases mentionnées précédemment ne seront pas abordées dans la suite car incombant au projet global (sous responsabilité du chef de projet) et non au chantier Unix/Windows.
Le chantier Unix/Windows concerne principalement l’installation d’une nouvelle version du logiciel Evolan Report. D’autres évolutions ont également été menées au niveau de l’intégration du logiciel, évolutions non obligatoires pour le projet SURFI mais qu’il était intéressant de mettre en œuvre simultanément.
Sopra, au regard des délais de réalisation demandés pour le projet SURFI par la Banque de France, ne pouvait livrer une nouvelle version complète rapidement. Par ailleurs les contraintes des établissements financiers au niveau de leur système d’information nécessitent le respect de jalons internes incompatibles avec une livraison tardive du logiciel. Aussi Sopra a décidé de livrer les évolutions par le biais de quatre lots étalés entre décembre 2009 et juin 2010.
Les Banques Populaires ont été volontaires pour tester la béta version du logiciel Evolan Report. Ceci signifie qu’ils ont eu accès à des livraisons de composants en avance par rapport aux autres clients (les Caisses d’Epargne entre autres). Or les Banques Populaires sont dans le groupe BPCE ; nous avons donc bénéficié de ces livraisons avancées. Notons que les beta versions n’étant pas définitives, le travail réalisé sur celles-ci a été considéré comme prévisionnel et n’a pu être validé que lors de la réception officielle des composants.
Compte-tenu des contraintes liées aux dates de livraison et au lotissement du logiciel par l’éditeur, la démarche méthodologique que nous avons retenue pour le chantier Unix/Windows est la suivante :
• 1ère phase : Etude d’impact réalisée à réception de la beta version. Cette phase nous a permis de produire une liste exhaustive des modifications du système à entreprendre et donc des ressources à mobiliser pour les réaliser.
• 2ème phase : Plan d’action. Construit à partir de l’étude d’impact, ce plan d’action nous a permis de tracer une ligne directrice dans l’évolution du système.
• 3ème phase : réalisation et tests unitaires. Lors de cette phase, nous nous sommes directement appuyés sur le plan d’action de la phase précédente. Cette phase de réalisation nous a permis de découvrir que certaines actions n’avaient pas été prévues. Dans ces cas, nous sommes retournés dans la phase 2 pour mettre à jour le plan d’action.
Notons, qu’outre le plan d’action, une autre documentation permet la réalisation de l’ordonnanceur Visual TOM (autrement dit VTOM, il s’agit d’un outil permettant le lancement automatique de traitements selon des conditions prédéfinies). Cette documentation sera décrite plus précisément un peu plus loin.
• 4ème phase : Recettes. Phase permettant de tester la non régression et le bon fonctionnement des évolutions apportées. Une fois cette phase réussie, le plan d’action est alors adapté pour devenir une procédure de mise en production. Cette phase permet de valider la fin du chantier Unix/Windows et de lancer les recettes utilisateurs.
Ces quatre phases sont réitérées à chaque nouvelle livraison d’un lot Evolan Report. Les documents créés lors de la première itération (étude d’impact, plan d’action et procédure de mise en production) sont mis à jour à chaque itération. Une fois sortis de ces itérations nous disposons d’une version logicielle finale qui sera installée en production et que nous pouvons désormais présenter à l’équipe de maintenance qui en aura la charge.
Une dernière phase intervient après la mise en production, il s’agit de la vérification de service régulier (VSR). C’est une période de garantie qui engage l’équipe projet à intervenir en tant qu’expert si des anomalies surviennent sur la nouvelle application en production. La période de VSR est déterminée conjointement entre l’équipe projet et l’équipe de maintenance. Elle est généralement d’un mois.
Nous observons que le lotissement du logiciel Evolan Report nous a poussé à adapter la pratique méthodologique de GCE Technologies notamment en y ajoutant un système d’itérations déclenchées par l’arrivée des nouveaux lots du logiciel.
Cette méthodologie nous a permis de gagner du temps en disposant d’un plan d’actions quasiment finalisé avant l’arrivée officielle des composants du logiciel. Cette avance a été mise à profit pour mobiliser rapidement les ressources devant intervenir sur le sujet et ainsi garantir de manière sûre les délais de réalisation. Nous avons également gagné du temps lors de la transformation des documents : étude d’impact plan d’actions mise en production. Le passage naturel d’un document à l’autre a été source de gain de temps.
1.5. Planning du chantier Unix/Windows
Le planning décrit dans la figure 18 nous montre que les différentes phases du chantier Unix/Windows ont démarré à des dates différentes mais qu’elles se poursuivent toutes quasiment jusqu’à la fin du projet. Le lotissement de la livraison des composants explique cette caractéristique.
Notons également que la phase de test, une fois démarrée ne s’interrompt pas. En effet cette phase est plus marquée après la réalisation des lots mais reste en tâche de fond tout le long du projet. Cela démontre l’importance de cette tâche.
2. Un environnement technique à construire
L’arrivée du projet SURFI a conduit à mettre en place un environnement technique complet et fiable permettant d’amener sécurité et industrialisation absents jusque là.
2.1. Mise en place de la configuration logicielle
La gestion des composants de l’application BAFI chez GCE Technologies a toujours été faite manuellement, sans processus industrialisé, à la discrétion des responsables d’application. Cet état de fait entraîne des installations en production entièrement manuelles, complexes, fastidieuses et risquées.
De nombreuses applications Unix de GCE Technologies sont dans le même cas. Un projet de mise en GCL (Gestion de Configuration Logicielle), autrement nommé mise en référentiel, de l’ensemble des applications de l’entreprise a été lancé. Nous nous sommes donc insérés dans ce projet afin de mettre en référentiel l’application BAFI et pouvoir bénéficier des outils d’installation automatiques.
2.1.1. La Gestion de Configuration Logicielle
La GCL permet de connaître à chaque instant l’état de chaque composant d’une application. Elle permet de valider des états stables pour ces composants (lors de mise en production par exemple), lorsque nous disposons de l’ensemble des composants dont l’état est stable, cela constitue une version de l’application. Le développement en équipe est facilité par la GCL puisqu’elle détecte les conflits (dans le cas où deux développeurs souhaitent modifier en même temps un même composant). De même il peut coexister plusieurs lignes de versions facilitant la coordination entre les équipes de développement et les équipes de maintenance. Une GCL permet également de mettre à disposition des outils d’installation automatique facilitant les mises en production. En cas de nécessité, il est possible d’installer une version complète de l’application notamment dans le cas de crash informatique.
Une GCL, de par sa gestion d’états stables référencés et connus par les équipes de développement, permet un accroissement de la sécurité lors des déploiements en production.
Chez GCE Technologies, la GCL des applications Unix et Windows est assurée par le logiciel CM-Synergy de Télélogic.
2.1.2. Evolan Report et CM-Synergy, une étude fonctionnelle
Sous l’appellation Evolan Report nous parlons du logiciel livré par l’éditeur mais aussi des composants développés par GCE Technologies autour du logiciel pour l’intégrer à la plateforme MySys ; cela va jusqu’à la documentation.
La mise en GCL d’une application nécessite d’effectuer un découpage fonctionnel. Chaque partie fonctionnelle fait l’objet d’un « Project », notion CM-Synergy qui permet une organisation cohérente des composants. Chaque composant appartient à un domaine fonctionnel et donc à un « project ».
Ainsi nous avons effectué une revue complète de l’application et déterminé les différents découpages fonctionnels. Nous avons identifié cinq domaines fonctionnels. Une fois ce découpage fonctionnel effectué, nous avons, pour chaque « project » pratiqué un autre découpage cohérent à plusieurs niveaux pour organiser au mieux les composants. Ce deuxième découpage peut s’apparenter à un système de répertoires dans lesquels les composants seront rangés. Pour cela, nous avons choisi d’une part de découper par type de composant (KSH, exécutable, paramétrage, cobol, SQL, etc.) et d’autre part en fonction de la provenance du composant (Editeur ou GCE Technologies) ;
Figure 19 : Découpage fonctionnel Evolan Report
La figure 19 nous montre les cinq parties fonctionnelles correspondant aux quatre modules Evolan Report plus l’audit. Nous pouvons remarquer que ces cinq « project » sont regroupés dans deux projets (evolan_unix et evolan_windows) qui sont purement techniques et propres à l’outil de GCL ; ils correspondent aux socles techniques.
L’étude s’est terminée par le recensement de l’ensemble des composants et leur affectation dans chacun des répertoires. A titre d’exemple, nous présentons un extrait du découpage effectué dans le « project » evolan_engine dans la figure 20.
