La Société Générale en route vers l’agilité à l’échelle

Une marche vers les méthodes agiles initiée en 2011

Pour GBIS (Banque de Grande Clientèle et Solutions Investisseurs), et plus particulièrement au sein de la DSI de cette activité, le virage de l’agilité a été amorcé en 2011. « A cette époque, nous travaillions encore sur des cycles en V de manière très traditionnelle. Certaines de mes équipes sont venues m’expliquer qu’elles étaient d’ores et déjà en capacité de livrer du code toutes les 3 semaines. Leur approche était plus efficace car elle permettait d’avoir des retours métiers très rapidement sur leurs développements. » Fort de plusieurs expérimentations terrain réussies, le prédécesseur de Philippe Morère engage la DSI dans un déploiement des méthodes agiles de manière beaucoup plus large au sein de sa DSI.

S’il ne s’agit pas encore véritablement d’un projet agile à l’échelle de toute la Société Générale, les méthodes agiles, qu’il s’agisse de Scrum, Kanban ou, parfois, Scrumban progressent dans la DSI si bien que fin 2014, la moitié des équipes avaient déployé des pratiques d’agilité. Il ne s’agit encore que d’une approche adoptée à l’échelle des équipes applicatives, avec un représentant métier intégré à des équipes de développeurs travaillant sur des sprints de 2 à 3 semaines.

Les premières applications concernées étaient les applications directement utilisées par les clients de la banque, mais, dès le départ, le DSI a souhaité intégrer les applications backoffice dans la démarche : « Dès le début, nous avons considéré que si seules les applications Client ou Front Office bénéficiaient de cette accélération, nous trainerions un boulet au pied avec le reste du SI » explique Philippe Morère. « Nous devions absolument intégrer les applications downstream (Back Office, Risques…) à la démarche. Nous avons privilégié une approche holistique, avec cette logique d’intégrer l’ensemble du système d’information dans notre stratégie d’agilité. »

L’intégration continue s’est rapidement imposée comme indispensable pour aller plus loin

Si l’adoption des méthodes agiles permet alors aux équipes de développement de délivrer plus rapidement du code et ainsi d’avoir des retours utilisateur en moins de temps, l’approche de la DSI n’intégrait pas encore le volet production. Les phases de test étaient toujours basées sur une approche traditionnelle, ce qui empêchait la DSI de mettre en production ses applicatifs au rythme de la mise à disposition des nouvelles versions par les développeurs.

C’est en 2014 que la DSI de GBIS lance un plan « Continuous Delivery » afin de mettre en place des chaînes logicielles allant de la capture du besoin utilisateur et sa priorisation jusqu’à la mise en production. L’objectif est alors de privilégier l’automatisation des tests et du packaging du code pour déployer les build le plus rapidement possible. « Fin 2016, 50 % du code produit était mis en production grâce à ces chaînes d’intégration continue. Ainsi, l’application de gestion de risque sur les produits dérivés, application legacy de plusieurs millions de lignes de code, avait vu ses intervalles de livraisons majeures passer de 3 mois à 3 semaines seulement. Pour les applications plus récentes, les livraisons de code avaient lieu plusieurs fois par jour. »

A cette époque, l’agilité restait encore une approche essentiellement IT. C’est en 2017 que le mouvement vers l’agilité à l’échelle est véritablement lancé. « Nous avons souhaité adopter une logique de chaîne de valeur métier, à la façon Spotify : nos équipes travaillent désormais sur plusieurs applications pour répondre à toute la chaîne des besoins d’un métier. Le but est d’avoir à la fois l’autonomie et l’agilité d’une Feature Team avec un Product Owner métier tout en gardant  des pratiques transversales fortes (l’APIsation de nos applications en plateformes communes à toutes les équipes IT). » Le DSI le reconnaît aujourd’hui, c’est cette phase de transformation qui a nécessité le plus gros effort en termes de change management auprès des métiers.

Un passage à l’Agilité à l’échelle de grande ampleur

En termes de méthodologie, le DSI n’a pas souhaité appliquer à la lettre un framework « Agile at Scale » connu. Ses équipes ont pioché des idées dans divers frameworks existants pour ne retenir que ceux qui correspondaient le mieux à la culture d’entreprise de la Société Générale. « Tribus, Feature Teams, ligues, guildes, nous avons retenu un modèle opérationnel très proche de celui de Spotify. Néanmoins, sur de gros programmes qui nécessitent beaucoup de synchronisation entre plusieurs Feature Teams de différentes tribus, nous mettons en place la méthodologie Safe. »

Si le DSI estime que la mise en œuvre d’une telle méthodologie représente un coût de mise en œuvre important, celle-ci offre une valeur ajoutée sur les programmes complexes. « Pour des projets plus restreints qui touchent moins d’équipes, nous mettons en œuvre notre propre méthodologie avec quelques éléments de la méthodologie Safe qui nous semblent les plus importants. » A ce jour, Safe a été mis en œuvre sur une dizaine de programmes, notamment le FRTB (Fundamental Review of the Trading Book), un programme réglementaire qui touche l’ensemble des systèmes de gestion de risque de la plupart des grandes banques. Safe a aussi été mis en œuvre sur la revue de la chaîne de certification risque de la Société Générale ainsi que son projet MIFID II.

Aujourd’hui, près de la moitié de la DSI de GBIS, soit plus de 3 000 personnes, a basculé dans cette organisation agile à l’échelle. La DSI compte 60 tribus, c’est-à-dire des ensembles de « Feature Teams » relatives à un domaine donné. Chaque tribu représente entre 100 à 150 personnes, avec une moyenne de 10 personnes par Feature Team soit un bataillon de 500 à 600 Feature Teams opérationnelles. Côté métier, ce sont entre 200 à 300 Product Owners et Product Managers qui ont rallié cette organisation.

Feature Team : l’autonomie dans le respect des standards

Si les Feature Teams et leurs Product Owners bénéficient d’autonomie quant à leur planning de développement et de livraison, les développeurs n’ont pas pour autant une grande latitude dans leurs choix techniques : « Nous avons des standards d’architecture technique et fonctionnelle imposés. Pour autant, nous proposons une vraie diversité de stacks techniques, par exemple, en termes de langage, si nous privilégions Java et C#, nous proposons aussi Python et C++. Nous avons aussi à notre catalogue un ensemble de middleware, de bases de données, donc un patrimoine technique assez large. » Le DSI souligne que des pratiques fortes en termes de production et d’architecture sont des prérequis nécessaires avant de se lancer dans l’agile à l’échelle.

« Cette mise à disposition de plateformes standards éprouvées, permet aux équipes de se concentrer sur la valeur métier. De plus, cela permet à celles-ci d’entrer dans une logique de cocréation. Nos référentiels de code Github sont ouverts à l’ensemble de nos équipes et chacune d’elles peut contribuer en tant qu’inner source à l’amélioration du code d’autres équipes et contribuer aussi à l’amélioration de nos frameworks techniques » ajoute Philippe Morère.

Pour le DSI, l’intégration des Ops au sein des Feature Teams est une opportunité pour les ingénieurs d’exploitation qui vont parfois se retrouver à réaliser des tâches de Business Analyst, ou même de développement pour ceux qui font du support technique. « Cela tire les gens vers le haut et génère une plus grande valeur ajoutée pour la banque, pour les métiers. L’approche ‘You build it, you run it’ crée un véritable cercle vertueux qui pousse vers un code de meilleure qualité, bien monitoré, exploitable en production. De plus, les métiers gagnent en visibilité et en compréhension des sujets de maintenance applicative».

Agilité et développements offshore peuvent cohabiter

Une telle transformation dans le fonctionnement de la DSI demande une phase de gestion du changement non négligeable et il faut compter environ 6 mois pour qu’une tribu atteigne une première étape de transformation (MVP, produit viable au minimum) stable et acquise. Contrairement à ce que l’on pourrait penser, le recours à l’offshore n’a pas été remis en cause par ce passage à l’agile. « Nous nous appuyons sur des centres de développement en Inde, mais ceux-ci sont internes à la Société Générale. Cette approche n’a pas été remise en cause par notre transition vers l’agile à l’échelle et cela marche bien ! »

Parmi les recettes appliquées par la Société Générale, les Feature Teams ont été colocalisées, c’est-à-dire tous les membres de l’équipe IT sont au même endroit, que ce soit à Paris, New York ou Londres, ou en Inde. « Cette approche fonctionne bien car elle donne de l’autonomie à la Feature Team, même si le Product Owner n’est pas physiquement au même endroit. Celui-ci est en communication au quotidien avec son équipe par visio, chat, email, des business trip sont organisés de temps à autre. C’est un modèle qui fonctionne bien. » De même, les prestataires informatiques qui travaillent pour la DSI de la Société Générale en France sont pleinement intégrés aux Feature Teams, même si le droit du travail pousse la banque à faire tourner ses prestataires IT tous les 3 ans.

Philippe Morère estime que 80 % des équipes auront basculé vers l’Agile à l’échelle d’ici mi-2020. Outre les classiques indicateurs clés de fonctionnement de la DSI, des sondages de satisfaction effectués auprès des équipes IT et des utilisateurs montrent que 80 % des répondants s’estiment satisfaits de ce nouveau mode de fonctionnement. Aucun Product Owner ne souhaite revenir en arrière.

En 2019 un nouveau mode de gestion va être instauré : chaque tribu gère elle-même son propre budget, tant pour financer les évolutions de ses logiciels que leur exploitation et maintenance. S’il y aura des revues stratégiques tous les 4 à 6 mois, ce sont désormais aux Product Owners et à la Project Management Team (constitué des managers des Product Owners côté métier) de gérer leurs budgets, un vrai changement de culture considérable pour une DSI de cette taille.