Projet Agile From Scratch par Max Loriot

Projet Agile From Scratch par Max Loriot

Projet Agile From Scratch

Contexte

Ce projet IT prend place dans l’architecture informatique d’une société d’Asset Management française. Elle fait partie du top 5 national en termes d’actifs sous gestion avec plus de 150 milliards d’euros. Ce montant est réparti sur 300 portefeuilles et plus de 60 de types d’actifs.

Dans ce contexte, ce gestionnaire d’actifs a récemment signé un accord de partenariat avec un Asset Manager majeur au niveau mondial. Ce rapprochement a accentué un besoin critique pour la Direction des Risques (DR). Un outil de calculs de métriques de risque a donc été commandé à la direction des systèmes d’information. La DR souhaite pouvoir analyser et monitorer les risques financiers des positions/portefeuilles.

L’accord de partenariat stipulait aussi certaines contraintes vis-à-vis de cet outil. D’un point de vue technique, il doit être développé dans le langage propriétaire Matlab avec une base de données MS SQL. Les résultats doivent eux être restitués sous forme de rapports via l’application BI propriétaire Spotfire. En complément, ce projet doit être mis en œuvre selon la méthode Agile. Il s’agit de construire cette application à partir de rien : pas de base de données, pas de code réutilisé. Seule la librairie de fonction/classe Matlab peut être reprise.

Une équipe de 6 personnes a alors été montée en Septembre 2015 pour réaliser ce défi. Elle comptait 3 IT Quant, deux Business Analyste et un chef de projet.

Définition

 

Une métrique de risque est un indicateur permettant rapidement d’estimer le risque d’un instrument, d’une position ou d’un portefeuille. C’est souvent une valeur numérique mais cela peut aussi prendre la forme d’une notation. La métrique de base la plus classique est la sensibilité du prix d’un instrument par rapport à un facteur de marché. Il donne le montant de perte ou de gain (PnL) que le prix peut générer pour une variation unitaire d’un facteur de marché. Par exemple, la DV01 correspond au PnL du prix pour une augmentation absolue de 0.01% des taux d’intérêt. On peut aussi citer la Value At Risque. Ce montant de PnL traduit un niveau maximum de perte pour une probabilité donnée (99% généralement). Par exemple, une VaR 1 jour 99% d’un portefeuille égale à 1 million d’euros se traduit par « Dans 99% des cas, ce portefeuille ne perdra pas plus 1 million en une journée ».

Il existe de multiples versions de la méthode Agile. Ce sont toutes des pratiques de pilotage et de réalisation de projets. L’objectif premier de cette méthodologie est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. Au cours de la vie du projet, les changements de besoins sont pris en compte et redirigent les objectifs courants. Le projet est alors découpé en périodes de temps assez courtes (quelques semaines), appelées « Sprint ».     

Il s’agit de définir en début de Sprint ce qui doit être prioritaire et donc ce qui doit être livré à l’issue de cette période. Les membres de l’équipe projet, le chef de projet (Scrum master) et le client (Project Owner) doivent donc travailler ensemble et échanger quotidiennement tout au long du projet. Le développement Agile, appelé aussi développement adaptatif, se caractérise donc par un style de conduite de projet itératif incrémental, centré sur l’autonomie des ressources humaines impliquées dans la spécification, la production et la validation d’une application intégrée et testée en continu (méthode Agile).

 

Les challenges d’un tel projet

Le premier défi fut bien sûr ce mode de gestion de projet. La méthodologie Agile n’avait jamais encore été appliquée chez le client ou par des membres de l’équipe projet. Nous avons donc dû nous former et adapter les grands préceptes de ce mode de gestion de projet. Un des points majeurs que je retiendrai c’est le rythme soutenu de cette méthode et les dérives qui en découlent. Par exemple, nous avions connaissance dès le début des grands besoins métiers (user story dans la méthodologie) mais il a fallu dès le premier Sprint spécifier, coder, tester et livrer. Avec du recul, une période de réflexion et préparation par rapport aux futurs livrables aurait pu nous faire gagner du temps. Nous avons récemment dû revoir un point structurant de l’architecture de la base de données alors que ceci aurait pu être anticipé dès le début.

J’en arrive donc au second challenge : la modélisation et l’évolution constante de la base de données. Une grande partie des premiers Sprints était consacrée à cette tâche. Or, aucun membre de l’équipe n’avait de réelle expertise en SQL pour jouer le rôle de DBA. La réunion de nos connaissances nous a permis de surmonter ces problèmes mais ce fut au détriment d’un temps précieux (particulièrement dans la méthode Agile). Encore aujourd’hui, nous investissons bien un tiers de notre temps dans des sujets SQL.

Enfin, le dernier exploit que je tiens à souligner est la constitution d’une équipe projet efficace et en parfaite harmonie dans un laps de temps assez court. Il y a bien sûr eu quelques ratés au début mais nous avons réussi à tous travailler à l’unisson et de manière coordonnée. Il n’est jamais facile, voire même impossible parfois, de faire travailler aussi bien des personnes ne se connaissant pas et d’horizons différents.

Les succès

La méthodologie Agile, ainsi que ce départ depuis une feuille blanche, nous ont autorisés une souplesse et une créativité quasi sans limite. Nous étions les seuls maitres de notre architecture de base de données et de nos algorithmes au niveau du code.

D’un point de vue métier, nous avons travaillé sur un éventail extrêmement large de produits financiers et donc de modèles de valorisation et de calculs de métriques de risque. L’un d’eux est par exemple le principe de transparisation. Il permet de remplacer une position sur un fond par l’ensemble des positions du fond, modulées bien sûr par un certain coefficient. Cela semble simple sur le papier mais l’implémentation ne va pas de soit et les conséquences sur la base sont nombreuses. Il vous faut en effet prévoir de nouvelles clés primaires dans vos tables car la transparisation conduit à de nombreuses lignes en double.

Enfin, nous pouvons nous vanter de suivre quasiment en temps réel les nouvelles réglementations récemment votées. Par exemple, les calculs de notations PRIIPs (Packaged Retail Investment and Insurance-based Products) votés cette année par le parlement européen sont en cours de développement.

 

Bilan personnel

Ces deux années sur ce projet prennent donc place parmi mes plus belles expériences professionnelles. J’ai particulièrement apprécié travailler en Agile et sur un panel de produits financiers aussi large.

L’équipe projet ainsi constituée fut aussi d’un grand soutien. Nous avons toujours travaillé dans le respect de l’autre et dans la bonne humeur. Nous avons fait face en groupe à des moments difficiles mais notre cohésion nous a permis de les surpasser et d’aller de l’avant.

Je tiens donc ici à tous les remercier.

Merci à la responsable du projet chez le client de nous avoir fait confiance.

Merci à tous les membres de mon équipe (nos deux docteurs, Ceausescu et le motard, notre geek festive et notre stagiaire padawan).

Et bien sûr, un grand merci à l’équipe CAPFI pour cette formidable mission.

Partager

Vous aimerez aussi

+
+
+