TechWeek 2019 : les recettes de la "Générale" pour développer plus vite

Une Software Factory au cœur de la transformation du système d’information

On sait ainsi que la Générale est engagée dans un vaste plan de déplacement vers le cloud, avec l'objectif d’avoir migré 80 % de ses applications en 2020. La banque a aussi mis en place une Migration Factory afin d’accélérer une migration de ses applications vers les technologies Open Source. Cet événement a aussi été l’occasion d’en savoir un peu plus sur les leviers mis en œuvre par la DSI pour mener à bien cette transformation et en ce sens, le rôle de la Software Factory est bien évidemment primordial.

La banque travaille sur la question depuis de nombreuses années et dispose désormais d’une plateforme qui supporte aujourd’hui les processus de développement/maintenance de 1 200 applications et compte environ 10 000 utilisateurs plus ou moins avancés. « Mettre en place une chaine de CI/CD permet de normaliser le processus, définir des normes et mettre tout le monde dans un même moule », résume David Vicente, ingénieur DevOps et expert en intégration continue à la Société Générale.

La chaîne d’intégration continue du groupe s’appuie sur un entrepôt Github déployé en interne, dans sa version on-premise. En termes d’orchestrateur, la banque utilise Jenkins ou TeamCity la solution éditée par JetBrains, afin d’automatiser le processus de build. Les fichiers d’orchestration sont eux-mêmes stockés dans Github.

« Nous sommes dans une approche où tout devient code et où tout doit être stocké dans Github, qui est notre référence globale. Les binaires sont entreposés dans un repository de type Nexus ou JFrog Artifactory. Cela nous permet d’éviter à refaire le build à de multiples reprises, notamment lorsqu’on fournit des briques à d’autres équipes de développement. Un logiciel centralise tous les indicateurs de qualité du code, le nombre de tests réalisés, la couverture de test, la non-régression du code, ce code pourra-t-il rester bon dans le temps, avec Sonar Qube ». Cette solution permet aux équipes de développement de traquer les obsolescences dans le code, notamment l’utilisation de librairies obsolètes, etc.

Autre composante de la chaîne CI/CD devenue extrêmement importante vis-à-vis des régulateurs, c’est l’analyse de sécurité du code : « nous ouvrons de plus en plus nos applications à l’externe via les API notamment, il est donc de plus en plus important de nous assurer que celui-ci ne comporte pas de failles de sécurité. Nous utilisons Black Duck et Checkmarx, des solutions très largement utilisées dans ce domaine ».

L’équipe Software Factory met à disposition cette plateforme pour tous les développeurs du groupe, mais va plus loin afin d’en favoriser l’adoption. « Nous n’avons généralement pas besoin de convaincre ceux qui sont les plus en pointe, par contre il faut aussi convaincre la masse, leur fournir du support pour gérer le changement mais aussi apporter un budget externe. Nous leur fournissons des gens compétents pour les aider à faire évoluer leurs pratiques. Nous assumons les coûts qui vont être engendrés par le projet, car les métiers - les Product Owners - payent pour avoir des développements, pour obtenir des fonctionnalités dont ils espèrent pouvoir tirer de la valeur ajoutée. Pour eux, un changement du mode de travail de l’informatique ne leur rapporte rien. C’est en leur apportant des experts, c’est en formant les équipes et en assumant le poids de ce changement que l’on peut emporter l’adhésion des métiers ».

L’équipe assure le maintien en condition opérationnelle de la plateforme de CI/CD, une plateforme qui représente aujourd’hui environ 800 serveurs en production. Celle-ci supporte tous les besoins de la banque avec le même niveau d’automatisation, qu’il s’agisse d’applications internes de core banking ou d’applications externes dans le cloud. Cette capacité permet à l’IT de la troisième banque française de supporter la phase de transition des applications de core banking qui sont peu à peu exposées sous forme d’API.

Un catalogue de près de 5 000 API accessibles à tous

Autre élément-clé de la transformation de l’IT de la Société Générale, sa stratégie d'APIsation de ses applicatifs. La banque a mis en ligne un catalogue qui recense toutes les API développées en interne, ainsi que les widgets et sources de données. Ce catalogue est accessible en interne mais aussi pour partie aux clients et partenaires de la banque. Celui-ci compte actuellement la description de 4 800 API et plus de 300 widgets.

L’objectif numéro un est de promouvoir les widgets auprès des développeurs afin de favoriser la « réutilisabilité » du code en interne.

L’objectif numéro un est de promouvoir les widgets auprès des développeurs afin de favoriser la « réutilisabilité » du code en interne. Un expert de la Société Générale souligne : « pour nous, le widget est le composant qui doit permettre d’accéder à la donnée. C’est lui qu’il faut privilégier, mais s’il n’existe pas de widget répondant à l’usage que souhaite faire le développeur, alors celui-ci peut aller voir les API. Ce n’est que s’il n’existe pas d’API, que celui-ci va aller chercher la donnée directement afin de créer une API ou un widget ».

De manière assez surprenante, le portail est accessible de manière publique à l’adresse developer.sgmarkets.com, car outre les développeurs internes, celui-ci s’adresse aussi aux clients et partenaires de la Société Générale. Ainsi, une startup qui souhaite accéder aux données bancaires des clients de la Société Générale conformément à la directive DSP2 va trouver toutes les informations techniques sur le jeu d’API mis en ligne par la banque qui lui sont nécessaires pour connecter son application. De même, un client de la banque qui veut gérer des produits structurés sans passer par l’interface Web mise en ligne par SG peut trouver les API qui lui permettront de le faire à partir de ses propres applications.

Enfin, les clients corporate peuvent connecter leurs outils analytiques au backoffice SG par ce moyen. C’est la brique IAM de la Société Générale, SG Connect qui assure la sécurité de l’accès au portail, le contenu affiché à l’utilisateur étant bien évidemment infiltré en fonction de la nature de son profil.

« En interne, tout le groupe a potentiellement l’accès à l’outil afin de déclarer les API, et en faire la publicité. Il s’agit véritablement d’une approche marketplace de nos API dans une philosophie de type self-service. Nous souhaitons que les utilisateurs soient libres de déclarer leurs API, puissent souscrire, monitorer le fonctionnement de leurs API », explique-t-on à la Société Générale. « En interne on dispose de beaucoup plus d’informations, notamment quelles sont les conditions pour souscrire à l’API, où se situe-t-elle dans le système d’information, son niveau de sécurité, etc. »

Si la Société Générale dispose d’un catalogue d’API unique, du point de vue strictement technique, celui-ci masque plusieurs plateformes d’API management, du fait de la diversité du système d’information de Société Générale. « Nous essayons bien évidemment de rationaliser nos coûts, mais il faut aussi tenir compte de l’existant, donc tout n’est pas géré par une même solution d’API management. Mais toutes nos API sont bien référencées dans ce catalogue, quelle que soit la technologie de gateway, d’hébergement ou d’exposition mise en œuvre derrière. Dans ce mouvement d’APIsation, nous travaillons au cas par cas, en fonction de nos contraintes internes, des contraintes fixées par le régulateur et bien évidement des contraintes de sécurité. C’est ainsi que l’on décide de ce qui est éligible pour aller dans le cloud public, ce qui doit rester dans le cloud privé, ce qui va être exposé sous forme d’API via des gateways, etc. »

Le catalogue lui-même expose des API qui permettent aux développeurs de déclarer leurs API par appel d’API (!). Le catalogue reçoit ainsi plusieurs millions d’appels d’API par jour sur la plateforme par les utilisateurs, mais aussi des robots qui viennent consulter le catalogue, vérifier la disponibilité de mises à jour, etc.