La plateforme Equity & Derivatives de Société générale a mis en œuvre un système de pilotage de la qualité logicielle et de la performance des équipes. Objectifs : livrer des produits de meilleure qualité aux métiers, avec moins d’incidents en production, améliorer la productivité des équipes et détecter les défauts le plus vite possible.
La plateforme Equity & Derivatives de Société générale, l’une des plus importantes plateformes dans ce domaine, est soumise à quatre facteurs d’évolution : d’abord une augmentation des volumes, sous l’effet de la croissance des transactions et des flux de marché.
Ensuite, une croissance du business : « Les systèmes d’information sont très sollicités et, dans la mesure où le monde de la finance est en constante évolution, les systèmes d’information doivent continuellement s’adapter et anticiper les changements à venir », précise Carlos Goncalves, Responsable adjoint des systèmes d’information de Société générale Corporate & Investment Banking. à cela s’ajoutent les contraintes réglementaires bien connues dans le monde financier (normes IAS, Bâle II, Mifid…) et l’optimisation des investissements.
« Dans la banque d’investissement, souligne Carlos Goncalves, chaque élément du système d’information est un élément clé de la compétitivité du business et une part importante de l’activité est réalisée de façon automatisée. Les systèmes doivent sans cesse être adaptés ou renouvelés. »
Chaque élément du système d’information est critique et pourrait engendrer des risques de pertes si un élément était indisponible, ne donnait pas les résultats escomptés, et des interruptions dans les processus métiers pourrait se traduire par des pertes. La DSI de la plateforme Equity & Derivatives gère plus d’une centaine d’applications avec une durée de vie moyenne de trois à cinq ans (pour les applications de front-office) et de sept à quinze ans pour les middle et back-office. « Nos ressources se répartissent à 50-50 entre maintenance et développement, essentiellement à Paris, mais avec quelques équipes locales aux états-Unis et en Asie », précise Carlos Goncalves.
Afin de minimiser les indisponibilités, la Société générale a mis en œuvre un processus qualité, en 2007, avec un volet spécifique pour la qualité logicielle. « Les objectifs étaient de livrer des produits de meilleure qualité au métier (avec moins d’incidents en production), d’améliorer la productivité de nos équipes et de réduire les coûts grâce à une détection des défauts au plus tôt », rappelle Carlos Goncalves.
Deux axes principaux ont ainsi été définis : le contrôle de la qualité du code dans l’environnement de développement et le pilotage de la qualité logicielle des applications tout au long du processus de gestion des nouvelles versions (avec les outils de l’éditeur Cast). « Une mauvaise qualité logicielle peut avoir deux impacts importants : d’une part, sur la performance du business, précise Carlos Goncalves, les incidents de production touchant directement le compte d’exploitation.
D’autre part, un impact sur la performance de l’IT avec une augmentation des charges de tests, moins de possibilités de réutilisation, une hausse du coût des évolutions, moins de fluidité possible dans les équipes de développement, un besoin de profils très spécifiques et des applications plus consommatrices de ressources en production. »
Le processus d’analyse suit plusieurs phases. L’ensemble des applications suit un rythme projet basé sur des versions successives. Chacune d’entre elles est elle-même découpée en une phase de développement et une phase de tests (intégration/acceptation des utilisateurs/tests). Une préanalyse permet au chef de projet de se rassurer sur la qualité de la release en cours : « Il peut, à ce stade, décider d’engager des actions correctrices s’il juge que certaines anomalies sont inacceptables, mais cette préanalyse n’est pas « publique » : elle n’est pas prise en compte dans le tableau de bord global », précise Carlos Goncalves.
L’analyse produite lors de la mise en production d’une version permet de suivre l’état de santé de l’application : « Elle vient compléter un historique d’analyse, permettant de connaître l’évolution dans le temps de la qualité de l’application, elle peut donner lieu à la mise en place d’un plan de « remédiation », qui viendra s’insérer dans la phase de développement de la version suivante », complète Carlos Goncalves. Cette analyse publique est communiquée au chef de projet ainsi qu’à son management.
Trois niveaux d’analyse
Plusieurs outils d’analyse sont alors produits. D’abord un tableau de bord global, destiné au top management. L’élaboration d’un tableau de bord implique, d’une part, que les équipes projets soient associées à la démarche : « Cela suppose de désigner un « key user » par application, avec un processus d’analyse standardisé pour l’ensemble des applications et un format standard de reporting des analyses », conseille Carlos Goncalves.
D’autre part, cela suppose aussi une implication du top management : « Il lui faut un tableau de bord standard, mensuel, présentant les résultats d’analyse pour l’ensemble des applications avec une vision synthétique et historique», ajoute Carlos Goncalves.
En parallèle du tableau de bord, un compte-rendu d’analyse est destiné au chef de projet : « Il présente le résultat d’une analyse donnée, intégrant à la fois une vue sur l’état de santé global de l’application ainsi que sur la différence produite entre la version courante et la précédente », ajoute Carlos Goncalves. Troisième niveau d’analyse : l’outil standard de restitution de la solution (Cast), qui propose plusieurs vues destinées aux différentes populations qui participent à un projet : chef de projet, architecte, développeur.
« Il permet de facilement naviguer dans les résultats, avec un principe de « drill down » : on part de la note globale, puis on zoome sur un facteur de santé, puis sur un indicateur précis… pour finir sur la ligne de code où l’anomalie a été détectée », précise Carlos Goncalves.