Rapport de stage de BTS SIO première année

Aloïs Zimmermann--Rosenthal BTS SIO Lycée du Parc des Loges

Rapport de stage de BTS SIO première année

Table des matières

Barème de notation du rapport de stage....................................................................3

Remerciements...........................................................................................................4

I. Présentation de l’entreprise.....................................................................................5

II. Thème du stage et travail à réaliser.......................................................................6

III. Analyse de l’existant et des besoins......................................................................7

a) Volumes de règlement .........................................................................................11

b) Volumes et valeurs de règlement.........................................................................11

c) Taux de règlement en valeur................................................................................11

IV. Réalisation et mise en place des solutions...........................................................13

a) Volumes de règlement..........................................................................................15

d) Volumes et valeurs de règlement.........................................................................16

e) Taux de règlement en valeur................................................................................17

Conclusion................................................................................................................ 17

1

https://www.google.fr/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&ved=2ahUKEwiE7MPd2a7iAhUGXRoKHUYqAjgQjRx6BAgBEAU&url=https://www.abbl.lu/t2slogo/&psig=AOvVaw0ddkvz3UFto5x4aHKmh4Ob&ust=1558599495010853


Barème de notation du rapport de stage

2


Remerciements

Je tiens à remercier Arnaud Giberd, mon maître de stage, ainsi queOlivier Bailly, mon responsable de stage, pour leur accueil et leuraccompagnement, tout au long de mon stage au service POP de laBanque de France de Paris.

Je les remercie également pour toutes les connaissances et lesréponses à mes questions qu’ils ont pu apporter. Elles m’ont permis deréaliser au mieux le travail demandé ainsi que mon rapport de stage.

Je remercie également tous les membres du service POP qui ont étébienveillants avec moi et qui auront parfois su m’aider dans laréalisation de mon travail, mais avant tout qui auront pu contribuer àmon intégration au sein du service et à la bonne ambiance durant lestage.

Enfin, je remercie France Rosenthal, ma mère, membre du servicePOP, sans qui je n’aurais pu réaliser ce stage qui était essentiel dansma poursuite d’étude.

3


I. Présentation de l’entreprise

Dans le cadre d’un stage pour ma formation de BTS SIO, j’ai réalisé monstage de première année de 5 semaines à la Banque de France, dans leservice informatique POP (Politique monétaire, Opérations de marché,systèmes de Paiement), situé à la place de la Bourse à Paris.

La Banque de France de Paris est une institution aujourd’hui indépendante,créée le 18 janvier 1800. Ses trois grandes missions sont la stratégiemonétaire, la stabilité financière et les services à l'économie. Son siège sesitue 31 rue Croix des Petits Champs 75 001 Paris CEDEX 1 mais elle disposed’autres locaux dans Paris, par exemple 48 rue Notre Dame des Victoires75 002 Paris, où se situe le service POP, où j’ai effectué mon stage. Denombreux autres services de la Banque de France sont répartis dans lesdifférents locaux.

En 2018, la Banque de France comptait 10 257 salariés équivalent tempsplein et 95 succursales. Elle compte également 6 filiales et entités. Pourl'exercice 2018, le dividende et l'impôt sur les bénéfices des sociétés verséspar la Banque de France à l’État français s’élève à 5,6 milliards d'euros.[

Au sein de la Direction des Projets (DIPRO), le Service Politique monétaire,Opérations de marché, systèmes de Paiement (POP) est le service demaitrise d’œuvre en charge du système d’information soutenant les activitéscœur de banque centrale que sont la politique monétaire, les opérations demarché, les systèmes de paiement, la stabilité financière et la gestion desrisques liée aux opérations de marché.

Ce service dans lequel j’ai pu réaliser mon stage travaille sur une mission àéchelle européenne : le projet T2S. [blablabla sur le projet]

Mon stage a porté sur la réalisation d’une application de gestion desstatistiques pour le projet T2S, que nous allons étudier dans les parties àvenir.

4


II. Thème du stage et travail à réaliser1) Contexte et définition du problème

La Banque de France produit quotidiennement des statistiques pour suivre l’activitédu moteur de règlement livraison de titres T2S au sein de plusieursenvironnements. La production des trois types de statistiques nécessite différentesinterventions manuelles : exécution de requête/traitement spécifique à unenvironnement et à une heure précise, utilisation d’outil bureautique spécifiquepour consolider les données, mise en forme finale.

Une chaîne standard d’extraction de données a été mise en place pour remplacer lamultitude d’extractions manuelles existantes. Les données sont automatiquementextraites aux heures adéquates au sein de fichiers au format CSV prédéfinis, et,envoyées par courriel en pièce jointe à une boîte de courriels.

Il faut désormais automatiser la génération des différentes statistiques à partir deces fichiers reçus dans la boîte de courriels. La Banque de France utilisantl’environnement bureautique Microsoft Office, une application devra être réalisée enutilisant les ressources du Visual Basic for Application (VBA) de Microsoft(notamment VBA pour Outlook et VBA pour Excel).

2) Objectif de l’application

L’application devra permettre la production des différentes statistiques à partir desdeux nouvelles extractions standards :

1. Les « volumes de règlement » actuellement générés que pour desenvironnements utilisateurs ;

2. Les « volumes et valeurs de règlement » actuellement générés que pourl’environnement de Production ;

3. Les « taux de règlement en valeur » actuellement générés que pourl’environnement de Production.

L’application devra permettre à l’utilisateur de générer chacune de ces troisstatistiques pour n’importe lequel des environnements disposant de la chaînestandard d’extraction de données d’un moteur de règlement livraison de titres T2S.

3) Cible de l’application

La cible de l’application est l’équipe du Support T2S de la Banque de France.

4) Documents à fournir

En plus de l’application, le projet devra inclure le cahier des charges, ladocumentation utilisateur, la documentation technique ainsi que la documentationdes tests unitaires.

5


III. Analyse de l’existant et des besoinsAvant la mise en place de cette nouvelle application, il en existait une, avecun tout autre fonctionnement et but, regroupant un grand nombre d’outils(voir image ci-dessous), qui permettait de tester la justesse des données etle fonctionnement des différents traitements, donc des différents codes ainsique de comparer les différentes statistiques et fichiers d’extractions.

Grâce à cet existant, j’ai pu reprendre un très grand nombre de codes quiétaient déjà présents, que j’ai pu modifier selon mes besoins ou sur lesquelsj’aurai pu fortement m’appuyer au cours de mes travaux.Ces codesregroupaient de nombreuses fonctionnalités concernant les fichiers destatistiques mais très peu voire aucunes concernant les fichiers de ratios.

Ainsi, presque toute la partie sur les ratios restait à faire.

En plus de cette application existante, pour comprendre ce qui devait être produitpar la nouvelle application, nous disposions de modèles des différentes données destatistiques.

6


1) Volumes de règlement

Les « volumes de règlement » étaient communiqués au sein du courriel de suivi del’activité des environnements utilisateurs envoyés à la fin d’une journée comptable(« [T2S] CRA USER journée du jj/mm/aaaa // […] ») :

Les « volumes de règlement » étaient générés pour lesdifférents environnements utilisateurs (UTEST, ITEF, EAC) via l’exécution,pour une date comptable donnée, de la procédure spécifique disponible dansle Query Management Facility (QMF) de l’environnement utilisateurconsidéré. Le tableau ainsi généré était alors ajouté dans le corps du courrielmanuellement.

5) Volumes et valeurs de règlement

Les « volumes et valeurs de règlement » étaient communiqués au sein du courrielde suivi de l’activité de l’environnement de Production envoyé à la fin d’une journéecomptable (« [T2S] CRA PROD journée du jj/mm/aaaa // […] ») :

7


Les « volumes et valeurs de règlement » étaient générées pourl’environnement de Production (PROD) via l’exécution, pour une datecomptable donnée, de la procédure spécifique disponible dans le QueryManagement Facility (QMF) de l’environnement de Production. Le tableauainsi généré était alors ajouté dans le corps du courriel manuellement.

6) Taux de règlement en valeur

Les « taux de règlement en valeur » étaient communiqués au sein de courriel desuivi de l’activité de l’environnement de Production pour deux moments différentsd’une journée comptable :

1. à la fin de la période de règlement de nuit (« Settlement figures after NTS(Business day jj/mm/aaaa) » ;

2. à la fin de la journée comptable (« Settlement figures EOD (Business dayjj/mm/aaaa) »).

A. À la fin de la période de règlement de nuitPour obtenir les taux de règlement envaleur après la période de règlement denuit, un job spécifique était lancémanuellement pour extraire les donnéesnécessaires dans un fichier au format CSVqui était envoyé dans une boîte mail, enpièce jointe. Le fichier ainsi obtenu étaitensuite pris en compte par un classeurExcel avec macros produisant alors les résultats ci-contre.

8


B. À la fin de la journéecomptable

Pour obtenir les taux de règlement envaleur à la fin de la journée comptable,un autre job spécifique était lancémanuellement pour extraire lesdonnées nécessaires dans un fichier auformat CSV qui était envoyé dans uneboîte mail, en pièce jointe. Le fichierainsi obtenu était ensuite pris encompte par un classeur Excel avecmacros produisant alors les résultats ci-contre.

7) Description fonctionnelleet technique de l’application

L’application devra permettre à l’utilisateur de générer n’importe laquelle des troisstatistiques présentées précédemment, pour n’importe lequel des« environnements T2S », et, pour n’importe laquelle des exécutions planifiées de lachaîne standard d’extraction de données.

L’utilisateur, avant de pouvoir déclencher la génération des statistiques, devrasélectionner :

1. l’« environnement T2S » cible au sein d’une liste :a. L’environnement de Production (PROD) ;b. L’environnement de tests utilisateur (UTEST) ;c. […] ;

2. la période d’extraction souhaitée au sein d’une liste :a. À la fin de la période de règlement de nuit (NTS) ;b. À la fin de la journée comptable (FULL) ; c. […] ;

3. le type de statistique souhaité parmi les trois considéré via une liste :a. « volumes de règlement » ;b. « volumes et valeurs de règlement » ;c. « taux de règlement en valeur » ; d. […] ;

4. la journée comptable souhaitée via une zone de saisie de texte ;Le contenu des listes utilisées par l’application n’est pas défini en dur dansl’application, mais stocké dans des tableaux de paramétrage spécifiques,modifiables par l’utilisateur.

L’application se présentera sous la forme d’un classeur Excel avec au moins unonglet de paramétrage et un onglet servant d’interface avec l’utilisateur.

A. Chargement des extractions dans l’applicationÀ l’ouverture du classeur Excel, l’application scannera les fichiers présents dans lerépertoire du classeur Excel pour y rechercher les courriels générés par la nouvelle

9


chaîne d’extraction standard (charge à l’utilisateur de les y déposer par drag anddrop, depuis Outlook vers l’explorateur de fichiers) afin de les charger dans lesystème de fichier de l’application.

Si possible, une fonction de scan de « la » boîte de courriels sera aussi mise enœuvre à l’ouverture du classeur Excel afin de charger les courriels générés par lanouvelle chaîne d’extraction standard dans le système de fichier de l’application.

L’application gèrera un système de fichiers, contenant un répertoire parenvironnement destiné à stocker les extractions de l’environnement considéré. Lescourriels ne seront pas stockés, seules les extractions le seront après renommagestandardisé.

C. Contexte de génération des statistiques

a) Volumes de règlement Les statistiques des « volumes de règlement » seront produites à partir du « fichierdes statistiques » (STATS FILE) correspondant aux critères de sélection del’utilisateur, et par consolidation des « données globales » (Scope Type = 'GLOB' etScope = 'T2SO').

Les devises pour lesquelles apparaît un cumul des transactions par devise en fin desstatistiques des « volumes de règlement » ne proviennent pas d’une listeparamétrée dans l’application, elles dépendent uniquement du contenu du « fichierdes statistiques » (STATS FILE) traité.

b) Volumes et valeurs de règlementLes statistiques des « volumes et valeurs de règlement » seront produites à partirdu « fichier des statistiques » (STATS FILE) correspondant aux critères de sélectionde l’utilisateur, et par consolidation des « données globales » (Scope Type = 'GLOB'et Scope = 'T2SO').

L’application devra disposer d’une liste de paramétrage de taux de conversiond’une devise en euro afin de pouvoir calculer des « ratios en valeur globaux » enn’utilisant qu’une seule devise : l’euro.

Les devises pour lesquelles figurent des « taux de règlement en valeur » neproviennent pas d’une liste paramétrée dans l’application, elles dépendentuniquement du contenu du « fichier des statistiques » (STATS FILE) traité.

c) Taux de règlement en valeurLes statistiques des « taux de règlement en valeur » seront produites à partir du« fichier des statistiques » (STATS FILE) correspondant aux critères de sélection del’utilisateur.

L’application devra disposer d’une liste de paramétrage des profondeursd’historique par environnement. La profondeur d’historique indique le nombre dejournée comptable précédent celle sélectionnée par l’utilisateur qui devront aussiapparaître dans les statistiques des « taux de règlement en valeur ».

10


L’application devra disposer d’une liste de paramétrage de taux de conversiond’une devise en euro afin de pouvoir calculer des « ratios en valeur globaux » enn’utilisant qu’une seule devise : l’euro.

La liste des CSD apparaissant dans les statistiques des « taux de règlement envaleur » devra être paramétrable dans l’application par environnements et parpériodes d’extraction.

Pour la période d’extraction correspondant à la fin de la journée comptable, lesstatistiques des « taux de règlement en valeur » devront faire apparaître sur ladernière ligne un cumul global prenant en compte tous les CSD mêmes ceux quin’ont pas été sélectionnés pour l’environnement considéré.

D. Contexte de restitution des statistiquesLes statistiques des « volumes de règlement » seront stockées dans l’arborescencede l’application sous forme de fichier texte (extension « .TXT ») protégé en écriture.La restitution à l’utilisateur se fera par l’ouverture de ce fichier texte au sein d’unenouvelle instance de l’application Bloc-Notes.

Les statistiques des « volumes et valeurs de règlement » seront stockées dansl’arborescence de l’application sous forme de fichier texte (extension « .TXT »)protégé en écriture. La restitution à l’utilisateur se fera par l’ouverture de ce fichiertexte au sein d’une nouvelle instance de l’application Bloc-Notes.

Les statistiques des « taux de règlement en valeur » seront stockées dansl’arborescence del’application sousforme de fichierExcel sans macros(extension« .XLSX ») protégéen écriture. Larestitution àl’utilisateur se feravia un ongletdédié del’applicationreprenant lesfonctionnalités duclasseur Excelavec macros« Stats àenvoyer.xlsm » ci-contre (liste deparamétrage,envoi par courriel, …).

11


12


IV. Réalisation et mise en place des solutions1) Analyser pour mieux avancer

Afin de répondre au mieux aux besoins de l’entreprise pour la conception del’application, toute la première semaine a été consacrée à l’analyse des différentsdocuments servant de « base », listant les fonctions que devrait regrouperl’application afin de comprendre au mieux ce qui était demandé. Il a fallu, de plus,étudier les statistiques existantes, les différents fichiers à traiter, et les outils déjàprésents pour voir comment il était possible de traiter les données. Il a égalementfallu concevoir le cahier des charges, très important dans la réalisation à venir etcommencer l’apprentissage du langage Visual Basic que je n’avais jamais utiliséavant ce stage et qui était essentiel à la conception de l’application.

8) Cadrer pour être plus efficace

Une fois que le cahier des charges était prêt, les grandes lignes de l’applicationétaient déjà plus visibles. Mais pour éviter de se lancer dans du code sans savoirprécisément ce qu’il faudrait faire, il était mieux de prendre du temps, pour engagner plus tard, pour élaborer les spécifications de l’application. Le but étaitd’avoir une bonne organisation et de la précision afin d’être efficace dans ledéveloppement à venir.

Le document des spécifications de l’application a constitué une bonne partie de lasemaine avec également l’écriture d’autres documents comme la volumétrie. Cedernier avait pour but d’évaluer si le volume de production créé par l’applicationpourrait être stocké sur le réseau convenablement ou si le volume de donnéesserait trop important pour pouvoir garder tous les fichiers générés.

Le document des spécifications servait principalement à décrire avec un maximumde détails, sans rentrerdans des notions decodage, tout lefonctionnement del’application. Il devaitêtre illustré dedifférentes maquettescomme le design del’interface utilisateurprésent ci-contre oubien des maquettesdes statistiques quiavaient été préparées la semaine passée.

Il détaillait avec plus de précisions que le cahier des charges, les grandes lignes del’application, l’organisation des différents fichiers, le fonctionnement de l’interface

13


avec l’utilisateur, l’organisation des statistiques générées ainsi que les règles decalculs des différentes statistiques.

Tout ce développement écrit a permis de bien comprendre, avec beaucoup dedétails, ce qui devrait, plus tard, être fait dans le code. En effet, certaines formulesde calculs pouvaient être très complexes à comprendre ou bien des fonctions del’application peu claires. Avec ce document, le cadre était posé et les possibilités degrosses erreurs dans l’application, par exemple dues à de l’incompréhension desbesoins, s’en voyaient fortement réduites.

9) Coder pour réaliser

A. Adaptation de l’applicationAprès avoir passé une bonne partie du stage à préparer des documents pourfaciliter le travail futur, je pouvais enfin commencer à réaliser du code pourl’application. En premier lieu, il fallait adapter la lecture du système de fichier afinque l’application prenne en compte les fichiers de ratio qui étaient ignorés jusqu’ici.J’ai donc repris le code existant pour l’adapter mais nous avons décidé plus tard, àcause de la mauvaise génération des fichiers de ratio par la chaîne d’extraction,qu’ils ne seraient pas utilisés pour l’application et que seuls les fichiers destatistiques seront utiles. Mais pour une potentielle modification de l’applicationfuture, elle peut maintenant traiter deux types de fichiers.

E. Création de l’interface utilisateurUne maquette de l’interface utilisateur avait été réalisée pour le document desspécifications. Il fallait maintenant la rendre fonctionnelle. J’ai donc associé àchaque liste de paramètre, le tableau dont il fallait prendre les valeurs et égalementgérer la saisissabilité de la case de la profondeur d’historique en fonction du type destatistiques choisi à l’aide d’une macro en Visual Basic. Après avoir généré toutel’interface, il fallait contrôler les données saisies. Il n’est normalement pas possiblede mettre d’autres valeursque celles des listes pour les3 premiers paramètres maisune gestion d’erreur étaitquand même prévue. Pour ladate comptable, le formatDB2 demandé (AAA-MM-JJ)était vérifié puis la validitéde la date (voir la fonctionci-contre). Pour laprofondeur d’historique,lorsqu’elle était nécessaire,il était vérifié que c’était bien un entier.

Bien sûr, pour chaque paramètre demandé, une erreur était retournée s’il était vide.

14


F. Réadaptation de l’arborescenceL’arborescence actuelle consistait en la présence d’un fichier par environnement àla racine de l’application. Cependant, cette arborescence était adaptée pour leregroupement d’un seul type de fichier, ici, des extractions. Le besoin étaitmaintenant de créer deux fichiers, un pour les extractions, l’autre pour lesstatistiques générées, avec la même arborescence interne (un fichier parenvironnement). J’ai donc à nouveau repris le code qui gérait cette arborescencepour l’adapter à ce nouveau besoin. Il existait un système d’archivage desextractions pour le cas où une nouvelle extraction du même nom était ajoutée aufichier (par exemple une nouvelle version). Il fallait modifier cet archivage afin qu’ilarchive les statistiques associées à cette extraction (en effet, deux extractionsdifférentes ne génèrent pas le même contenu). Cette modification m’a poséquelques problèmes au niveau de la correspondance des statistiques par rapport àl’extraction mais j’y suis finalement parvenue.

Comme je ne disposais pas encore de statistiques réelles, j’ai pris un fichier auhasard que j’ai nommé selon les noms qui seraient donnés aux statistiques afin devoir comment l’application gérait ces archivages.

G. Récupération du fichier d’extractionMaintenant que l’interface utilisateur et que la gestion de l’arborescence étaientfonctionnels, je pouvais commencer à rechercher le fichier correspondant auxparamètres saisis par l’utilisateur.

Le traitement était le même pour les Volumes de Règlement et les Volumes etvaleurs de règlement car ils nécessitaient un seul fichier mais les Taux de règlementen valeur pouvaient en nécessiter plusieurs alors un traitement adapté était mis enplace.

Nous pouvons observer sur l’extrait de code ci-dessous, que la recherche étaitpremièrement faite dans les fichiers générés. S’il était trouvé, il était affiché àl’utilisateur (depuis la fonction SearchOFile). Sinon, il était cherché dans lesextractions et s’il était trouvé, les statistiques étaient générées puis affichées. S’iln’était pas trouvé, une erreur était renvoyée. Pour les Taux de règlement en valeur,deux listes étaient récupérées, un d’archives et un d’extractions, puis comparéesafin de récupérer la maximum de fichiers selon la profondeur d’historique et les plusrécents possibles selon la date comptable.

15


Une seule liste triée était gardée, pouvant contenir des extractions ou des fichiersdéjà générés, un traitement était alors fait pour n’avoir au final que des fichiersgénérés.

H. Génération des statistiques

a) Volumes de règlementUne fois que nous disposions du fichier d’extraction de statistiques, nous pouvionscommencer le traitement de la génération des statistiques en volumes derèglement. Pour m’aider dans ma réalisation, le document des spécifications del’application était là pour me faciliter la tâche.

Ces statistiques n’étaient pas très compliquées à générer car elles ne prenaient quedes valeurs et il n’y avait aucune formule complexe. La difficulté résultait

majoritairement dans l’adaptationdynamique des statistiques pourl’affichage des différentes devises quele fichier d’extraction présentait.

Il a donc fallu placer chaque valeurdans des variables et faire un tableaupour les devises, puisque nous neconnaissions pas le nombre de devisesprésentes. Nous pouvons observer ci-contre, le code traitant l’incrémentationdans le tableau des devises.

16


Une fois que nous avions toutes les valeurs nécessaires aux statistiques, la mise enforme du texte était faite dans une variable (voir l’incrémentation ci-dessous), quiserait ensuite transférée dans un fichier texte pour la restitution finale desstatistiques.

Une fois que les statistiques étaient présentes dans lefichier texte, ce dernier était enregistré sous un nomadapté selon nos règles de nommage des statistiqueset stocké dans l’arborescence en fonction de sonenvironnement. Les statistiques en volumes derèglement ainsi obtenues étaient alors affichées àl’utilisateur.

d) Volumes et valeurs de règlementPour la génération de ces statistiques, le codage a été plus complexe mais jedisposais à nouveau de toutes les formules nécessaires à la réalisation duprogramme.

Il y avait beaucoup de critères à prendre en compte et plusieurs tris à mettre enplace. Pour faciliter le travail, nous avons procédé aux tris dans une feuilletemporaire d’Excel ce qui a évité des erreurs dans du traitement de tableaux.

Les formules ont parfois été complexes à mettre en place et il fallait également fairetrès attention à la justesse des données traitées. De plus, comme pour lesprécédemment, il fallait adapter dynamiquement les statistiques aux différentesdevises rencontrées.

Une fois que nous avions toutes les valeurs nécessaires aux statistiques, la mise enforme du texte était faite dans une variable, qui serait ensuite transférée dans unfichier texte pour la restitution finale des statistiques.

Une fois que lesstatistiques étaientprésentes dans lefichier texte, cedernier étaitenregistré sous unnom adapté selonnos règles denommage desstatistiques etstocké dans

17


l’arborescence en fonction de son environnement. Les statistiques en volumes etvaleurs de règlement ainsi obtenues étaient alors affichées à l’utilisateur.

e) Taux de règlement en valeurLa génération de ces statistiques au niveaudes données à produire n’a pas été le plusdifficile. Le plus complexe a été de réussir àfaire un tri « parfait » des différentsdocuments mis à disposition. Il a fallu enpremier lieu aller chercher dans les fichiersinternes le nombre de fichiers maximumpar rapport à la profondeur d’historiquesouhaitée. S’il n’y avait aucuns fichiers, ilfallait aller les chercher dans les fichiersd’extraction et même lorsque nousdisposions déjà de fichiers internes, il fallaitcomparer avec les fichiers d’extraction pourvoir s’il n’en existait pas de plus récents.Enfin, s’il n’y avait eu aucuns fichiersinternes pour une date donnée mais qu’unfichier d’extraction avait été trouvé pourcette date, il fallait à nouveau aller chercherdes fichiers internes pour des datesantérieures. Une fois que ce tri fonctionnait,le plus difficile avait déjà été réalisé.

J’ai manqué de temps dans la réalisation deces dernières statistiques, c’est donc Olivierqui s’est occupé de la mise en pagedesstatistiques dans un document excel et del’envoi final du mail.

Les taux de règlement en valeur avec une profondeur d’historique donnée étaientalors affichés à l’utilisateur.

ConclusionDurant ces 5 semaines de stage, j’ai pu réaliser la part la plus importante dutravail demandé. En effet, l’application souhaitée par l’entreprise de laBanque de France a été rendue globalement fonctionnelle dans sonintégralité. J’ai cependant manqué de temps pour les documentations et lesphases finales de tests.

En plus de m’avoir appris un nouveau langage informatique et de m’avoirpermis de développer de nouvelles techniques de travail plus adaptées à un

18


gain de temps, ce stage m’a permis de m’immerger dans un vrai contexteinformatique durant plus d’un mois. J’ai pu travailler au sein d’un serviceimportant de la Banque de France avec des personnes compétentes ce qui arenforcé ma capacité à travailler en équipe.

C’est avec plaisir que je retournerai dans ce service où règne une très bonneambiance qu’il est rare de trouver à un tel niveau dans le mondeprofessionnel.

19