Par Alexandre Nguyen – Practice Manager – Financial Markets – Maltem Consulting Group
Les activités bancaires au sense large ne constituent plus l’apanage des établissements financiers traditionnels tels que nous les connaissons. De nouveaux acteurs web 3.0 ont émergé ; Google, Facebook, Twitter, Spotify, Amazon, PayPal pour ne citer que quelques noms. En capitalisant sur leur ADN technologique, la « centricité » client inhérente à leurs plateformes d’échanges (cloud, réseaux sociaux…) et l’expansion exponentielle de leur données utilisateurs ultra ciblées (‘Big data’), ces derniers prétendent naturellement à l’obtention de licences bancaires pour la gestion des dépôts et crédits, gèrent déjà des paiements en ligne ou sans contact, envisagent d’assurer les utilisateurs et peuvent se targuer de déployer ces innovations en un temps record.
Ces nouveaux concurrents étant souvent perçus comme des précurseurs en terme d’innovations technologiques, le secteur bancaire tend de facto à s’inspirer de leurs méthodologies afin de rester résilient dans un environnement toujours plus imprédictible. Cela se matérialise par une dynamique itérative d’adaptabilité, l’objectif étant de réduire le délai existant entre la préparation d’une innovation (création, développement, tests) et sa mise à disposition auprès du public et/ou des clients (livraison). Dans l’univers financier, cet intervalle de temps, communément appelé « time-to-market » est un facteur clé de succès dans la course à l’innovation.
En effet, les institutions financières sont aujourd’hui confrontées à un flux continu de transformations législatives, à la nécessité de moderniser leur systèmes d’informations qui constituent dans certains cas de véritables anachronismes face aux attentes des clients « digitaux » désireux d’effectuer la moindre opération en ligne, sans frontière, sans contraintes temporelles.
L’Agilité, s’impose naturellement comme un nouveau paradigme. A cet égard il est intéressant de s’arrêter sur la transformation initiée par un établissement bancaire Néerlandais de premier ordre ; afin de rester compétitif les principes du Scaled Agile Framework « SAFE » et partiellement du Large Scale Scrum (LeSS) y sont en cours de déploiement. La logique du SaFE s’articule autour de trois niveaux (1);
– Le Portefeuille qui offre une vision sur les futures orientations, thématiques, architectures cibles… libellées sous la formes “d’ epics” en anglais (ou épopées en français bien que la portée sémantique soit différente) qui devront être livrés en fonction des priorités d’investissement de l’institution, par exemple; une rationalisation des systèmes d’informations utilisés pour les marchés financiers à l’horizon 2017.
-Cette vision est réalisée au niveau inférieur par un ou des Programmes comprenant une multitude de « fonctionnalités » qui seront déployées selon un planning défini. L’échelle de temps sera ici le trimestre voire le semestre, il est intéressant de noter que le concept de projet n’apparait plus dans la terminologie de cette sphère. La création d’un nouveau module de gestion de la liquidité pourrait illustrer une fonctionnalité type.
-Ces fonctionnalités une fois planifiées seront décomposées en «histoires» développées/délivrées par les équipes AGILE selon des méthodes itératives sur des périodes très courtes. L’échelle de temps sera alors le «sprint» 10 jours en moyenne. Chacune des histoires contribuera telle une pièce de puzzle à réaliser une fonctionnalité. Pour reprendre l’illustration précédente, la création du flux d’informations vers le module de liquidité constituera une «histoire» à livrer parmi la multitude d’histoires composant la fonctionnalité.
Au niveau des équipes, les itérations consistent à minimiser le temps écoulé entre la conception d’une «histoire» et sa validation par son utilisateur final. Ce cycle très court permet d’augmenter la fréquence des livraisons de solutions simples et immédiatement utilisables par les utilisateurs. L’épine dorsale de l’évolution rapide repose sur le concept de «Minimum Viable Product» dans l’univers AGILE.
En complément de l’Agilité, le modèle DevOps a été appliqué à l’échelon des equips. Le terme DevOps est un néologisme provenant de la combinaison des mots «Développements» et «Opérations». La ségrégation historique existant entre d’une part les développeurs, ainsi que les autres analystes participant à la création et d’autre part les analystes responsables du support et de l’entretien de ces créations n’existe plus dans l’univers DevOps. Les analystes sont re-qualifiés en «Ingénieurs DevOps». Ils deviennent pluridisciplinaires et polyvalents, ils conçoivent en étant très proches de leurs utilisateurs et intègrent dans le processus de création les éléments de maintenance, monitoring qui jadis faisaient défauts du fait de la segregation des tâches. Cette approche prend le contre-pied des modèles d’optimisation de la productivité développés sous le «Fordisme», «Taylorisme», «Toyotisme», etc… Le salarié n’est plus hyper-spécialisé dans une succession de tâches minimalistes chronométrées, il est dorénavant concepteur, testeur, développeur, analyste technique et fonctionnel, et technicien de maintenance. Les équipes DevOps participent à des ateliers réguliers permettant la création de nouveaux logiciels et fonctionnalités au cours d’événements très courts, des «Hackathon» ou «Idea-thon».
A terme les équipes DevOps opéreront en «tribus»; des groupes de travail autonomes réuniront les ingénieurs DevOps ainsi que l’ensemble des métiers contribuant au processus de création de nouvelles fonctionnalités/transformations au sein de la banque (Finance, Front-office, Opérations, Conformité, département juridique, Sécurité informatique, etc…).
Le champ lexical employé; «Sprint», «Hackathon», «Ideathon», «Livraisons continues», imprime la marque du changement permanent gouverné par l’augmentation de la vitesse de l’entreprise. D’un point de vue sociologique il sera certainement pertinent de mentionner, sans les développer, les principaux enjeux et défis auxquels seront confrontés les individus composant l’entreprise, et l’entreprise en tant qu’organisation globale:
-L’augmentation de l’autonomie des équipes se traduit par une réduction de l’espace managérial, dans quelle mesure la fonction managériale mandatée pour l’exécution de la transformation Agile/DevOps saura dépasser son interêt propre par rapport à celui de la structure?
-Selon le modèle des organisations formelles et informelles décrit par Michel Crozier (2), il faudra s’attendre à des deviances entre la structure formelle et rationnelle mise en place par les institutions adoptant ce modèle et l’organisation informelle qui sera renforcée par l’autonomie voulue des équipes Agile/DevOps.
-La culture identitaire très forte, le contrôle social quotidien, la permanence du mouvement a et aura un impact significatif sur les salariés dans leur ensemble (abstraction faite de la compression de la masse salariale globale permise par ce modèle). Plus particulièrement sur les employés seniors, garants de la connaissance et peu ou prou disposés à embrasser une nouvelle forme de polyvalence perçue comme contraignante. Les organisations devront s’atteler à relever ce défi en trouvant le juste équilibre face au «jeunisme» qui pourrait freiner la pérennité de cette transformation.
Le modèle AGILE/DevOps marque un tournant majeur dans la relation entre l’individu et l’entreprise. «L’individualisme méthodologique» (3) décrivant le salarié comme un acteur influençant et determinant la structure, semble progressivement céder le pas à la pensée «structuraliste» selon laquelle le salarié est en grande partie déterminé par l’entreprise.
Sources :
(1). www.scaledagileframework.com
(2). “Sociologie des organisations la pratique du raisonnement” Michel. Foudriat. Description de l’enquête de Michel Crozier à la SEITA.
(3). Wikipédia “Sociologie des organisations” : Les approches sociopolitiques
