Société Générale associe devops, flux agiles et qualité du code

Si certains pensent encore qu'en France, la démarche devops relève de l'incantation plus de la réalité, la conférence DevOps Rex consacrée à des retours d'expérience sur le sujet aura démontré que celle-ci suscite un réel intérêt au sein des équipes IT dans l'Hexagone. Sa 1ère édition s’est jouée à guichets fermés, hier à Paris, en réunissant 400 personnes au Grand Rex. Après l’événement anglophone Devopsdays l’an dernier, qui reviendra à Paris en 2017, l’un des objectifs consistait à proposer cette fois des retours d’expérience en français avec des témoignages d’experts venant principalement d’acteurs du secteur du numérique comme Orange Digital Factory, Microsoft, Kudelski, Cellenza, Theodo ou GetNext IT.

Pour leur première édition, les organisateurs de DevOps REX ont dû refuser des inscriptions. (crédit : LMI)

Parmi les intervenants figuraient également deux coaches devops à Société générale, Adrien Blind et Laurent Dussault, qui ont relaté de quelle façon, en trois ans, ils ont mis en place une culture devops au sein du groupe bancaire. Dans cette entreprise capitalisant sur un fort historique, il ne s’agissait pas simplement d’appliquer de nouvelles pratiques, mais de les diffuser au sein du contexte existant.

L’objectif était triple. « Nous voulions apporter de la valeur pour les métiers de la banque, améliorer le time to market d’ensemble et accélérer tout ce qui allait de la captation d’un besoin dans une équipe jusqu’à la livraison de la fonctionnalité répondant à la demande initiale », a exposé Adrien Blind. L'objectif était de transformer le patrimoine applicatif tout en intégrant la dimension qualité. « Dès 2011, notre DSI nous avait demandé de prendre comme exemple les Gafa [Google, Apple, Facebook, Amazon], nous avons donc regardé quels étaient leurs outils et leurs pratiques », a indiqué de son côté Laurent Dussault en soulignant néanmoins que les interactions entre les personnes passaient avant les outils.

A la DSI de Société Générale, les deux experts agissent en fait dans un contexte plus large que le seul devops. Leur démarche est articulée autour de trois axes complémentaires : les flux agiles, le craftsmanship et devops. Il existait déjà dans la banque un centre agile avec une logique de flux d’intégration, au sein d’une équipe projet. « Nous avons pérennisé tout ce qu’on faisait autour de l’agilité en embarquant davantage le métier en amont et en prolongeant ces principes d’agilité en aval avec les équipes de déploiement et les ops qui opèrent les applications », a expliqué Adrien Blind. « Nous avons ensuite travaillé l’angle du craftsmanship qui englobe toutes les techniques de développement consistant à créer un code robuste, durable, pérenne pour améliorer sa qualité, avant d’accélérer avec le devops. »

(agrandir l'image) Le framework de livraison continue réalisé par les coaches devops où l’on voit apparaître l’amplitude de leur initiative qui va du métier, en amont, jusqu’aux équipes opérationnelles et à l’infrastructure, en aval. Les trois axes principaux, agilité, craftsmanship et DevOps, sont identifiés selon un code couleur différent. « Le thème central, c’est la notion de pratiques », insiste Adrien Blind en ajoutant que si les outils sont sous-jacents, ils ne constituent pas une finalité. Le framework fait apparaître l'importance des mesures et la dimension infrastructure as a code. Le tout est sous-tendu par un pipeline qui va permettre d’automatiser et de fluidifier le déploiement des applications.

Obtenir l'engagement de la direction

Avant de démarrer leur projet devops, les experts se sont inspirés de grands auteurs et de conférences sur le sujet et ils ont cherché à replacer ces démarches dans le contexte de la Société générale. « Il ne s'agissait pas de créer une tour d’ivoire, mais d’accompagner toutes les équipes de la DSI et elles sont nombreuses », a expliqué Adrien Blend. Le but était d'envoyer sur le terrain des coaches qui, en entrant dans la vie des équipes, allaient leur permettre d’adopter les pratiques et les outils pour conjuguer accélération et meilleure qualité. 

Pour donner au projet tous les gages de réussite, il fallait aussi un engagement fort de la part de la direction. Le projet est remonté jusqu’au DG, Frédéric Oudéa, auquel ont été exposées les problématiques de frictions entre les développeurs et les équipes opérationnelles qui ne partagent pas les mêmes objectifs. « Nous avons expliqué les axes choisis pour mettre en place une culture devops à base d’automatisation, de mesures et de partage », a indiqué Laurent Dussault qui souligne l’importance d’avoir l’engagement de la DSI dès le début car cette dimension implique des moyens. « Il faut donc expliquer très haut quelle est l'ambition pour obtenir la mise en oeuvre de ces moyens. Dès que l'on se pose la question d'apporter de la valeur aux métiers, il faut aller au-delà des murs ».

(agrandir l'image) Les problématiques de friction entre les équipes chargées de développer les applications et celles chargées de les déployer telles que présentées à la direction de Société Générale.

Rapprocher les équipes, infrastructure as a code

Un mur de confusion se dresse généralement entre les équipes projets (développeurs et analystes métiers) et celles qui sont opérationnelles sur les applications ou sur les infrastructures, rappellent les coaches devops. Ils ont donc proposé aux équipes de travailler différemment en rapprochant celles des produits historiques, qui construisent les fonctionnalités des applications pour le métier de la banque, et celles qui travaillent en aval du cycle, sur le déploiement ou le run des applications. « Ces équipes, qui sont devenues de plus en plus pluridisciplinaires, ont été engagées collectivement sur le cycle de vie entier de l’application. L’objectif, c’est de créer de la proximité et de l’émulation », a expliqué Adrien Blind sur DevOps REX. « On a tous connu une mise en production qui se passe mal », a évoqué le coach. Dans ces cas-là, opérationnels et développeurs se renvoient la balle, les uns accusant le code, les autres arguant que les tests ont été faits. « On perd du temps de façon inutile », alors qu'en rapprochant les équipes, on peut créer des engagements communs autour des produits. 

La démarche a également conduit à bâtir une infrastructure as a service au sein de l'entreprise. « L'intérêt, c'est que l'on va pouvoir ainsi créer un environnement de façon programmatique en décrivant tout ce qu'il va contenir, les serveurs, le middleware, etc. et que l'infrastructure as a code devient du logiciel. Les personnes qui ont commencé à construire ça ont ainsi pu s'approprier les principes du craftsmanship et de l'agilité », fait remarquer Adrien Blind qui, au passage, pointe son intérêt pour Docker, la technologie de containers qui s'installe de façon programmatique et se déploie sur différents environnements. Selon lui, c'est peut-être l'artefact de demain qui réconcilie l'applicatif et l'infrastructure. 

Mettre en place des indicateurs pour prendre les décisions

Autre point important, celui de la métrologie qui consiste à effectuer des mesures et à les interpréter. « Pour pouvoir prendre une décision, on ne peut pas se baser uniquement sur du ressenti et du reporting, il faut prendre le pouls des applications dans l’instant », rappelle Laurent Dussault. Dès le début de l’histoire, insiste-t-il, il faut mettre en place les KPI en incluant dans la boucle les équipes de support qui pourront indiquer quels sont les indicateurs qui permettent de prendre des décisions autour des différentes fonctionnalités (en cas de surcharge par exemple) et rendre ces données accessibles à tout le monde. « Nous stockons un maximum d’informations qui vont toucher la production un jour ou l’autre. Il faut aussi mesurer votre usine de développement pour servir tout le monde, les développeurs, les opérationnels et les utilisateurs ».

Avant de faire ces transformations, toute la DSI a été évangélisée sur les concepts ainsi définis. Au cours de sessions de sensibilisation, les coaches ont proposé des jeux pour exposer les problématiques et les solutions qui pouvaient être mises en place. A partir des briques de bois du jeu de construction Kapla, les développeurs devaient construire une tour compliquée que les opérationnels devaient déplacer sur des socles représentant leur production. Au bout de plusieurs essais, on s’apercevait que les équipes ne connaissaient pas leurs objectifs ni leur KPI respectifs. Ce faisant, elles ne connaissaient donc pas leurs contraintes respectives. Dès lors, « on ne comprend pas le comportement de l’autre et on lui en veut d’avoir mal agi ».

S'approprier la démarche dans le modèle de son organisation

En résumé, devops, c'est bien mais, selon les deux experts de Société Générale, des synergies encore plus puissantes peuvent être obtenues lorsque la démarche s'intègre dans un processus de livraison continue. Ils soulignent aussi l'importance pour chaque entreprise de s'approprier la démarche dans le modèle de sa propre organisation : « chacun sa route », insistent-ils. A l'instar d'un Spotify qui explique publiquement son modèle en avertissant bien qu'il ne s'agit pas d'un modèle à suivre. Quant au rôle des coaches, il consiste à faire émerger les solutions des équipes elles-mêmes. « Il faut donner confiance aux équipes pour qu'elles trouvent leurs solutions ». Et si une équipe ne veut pas de devops, ne pas lui mettre de pression. Il faut chercher pourquoi sans brusquer. Il n'est pas question ici de réorganisation. « Ces trois dernières années, nous avons physiquement rapproché des opérationnels et des équipes avec lesquelles ils travaillaient, mais la réorganisation n'est pas un sujet sur lequel nous avons spécifiquement travaillé », ont-ils conclu en réponse à une question posée par l'auditoire de DevOps REX.