Digitalisation des banques: passez à la vitesse supérieure!

Dans un monde en pleine transformation digitale, «ce ne sont plus les gros poissons qui mangent les plus petits, mais ce sont les poissons les plus rapides qui mangent les plus lents» (Klauss Schwab, fondateur et président du World Economic Forum). Pour les banques, un des enjeux de la digitalisation est d’ouvrir leur système d’information aux nouvelles opportunités et aux nouveaux outils du numérique. Il doit continuellement faire preuve d’adaptabilité tout en restant consistant et sous contrôle. Une organisation Agile des projets informatiques et une industrialisation des développements permet de réduire considérablement le time to market des développements applicatifs afin d’entrer dans la course à l’innovation.

Vous n’êtes pas encore Agile?

Les méthodes «traditionnelles» de gestion de projet ont été élaborées au 20e siècle, lorsque le développement informatique était alors orienté exécution plutôt qu’innovation. Les capacités des ordinateurs étaient limitées, les outils restreints et les langages informatiques évoluaient à une vitesse modérée. Projets après projets, de nombreuses tâches devenaient répétitives et, de fait, prédictibles. Finalement, quand un projet était bien préparé, chaque développeur savait ce qu’il avait à faire mais savait, surtout, par avance, comment le faire.

Aujourd’hui, les tâches répétitives peuvent (et doivent!) être réalisées par une machine. La réalisation d’un logiciel devient moins prédictible et chaque projet s’avère sensiblement différent du précédent. Par ailleurs, les produits et services bancaires sont devenus des consommables. Et, à l’ère digitale, ils doivent être toujours plus nombreux, toujours plus simple d’utilisation, mais surtout, toujours en avance sur la concurrence. Dans ces conditions, il convient d’adopter un cadre de travail adaptatif plutôt que prédictif qui garde comme objectif principal la livraison de produits de grande valeur. Le retour d’expérience, ainsi que les possibilités d’amélioration et de changement, doivent être permanents et rapides. Le but des méthodes Agiles est d’adapter continuellement le logiciel qui est en train d’être construit mais aussi d’ajuster continuellement les méthodes pour le construire. Elles reposent sur les principes de bases du Lean Management, une forme d’organisation qui vise à éliminer les gaspillages tout en augmentant la satisfaction client et qui prône, entre autres, la simplicité, l’amélioration de l’apprentissage, et la vélocité de livraison.

Parmi les diverses méthodes disponibles, Scrum et Kanban sont devenus des références en matière d’encadrement Agile. La méthode Kanban peut être utilisée pour orchestrer de petits projets, mais elle est surtout particulièrement adaptée à la coordination des activités de support et de maintenance de logiciel. Elle offre une très grande flexibilité en autorisant des changements à n’importe quel moment. C’est une méthode de contrôle du flux de travail qui limite le nombre de tâches simultanées et qui permet d’identifier les goulots d’étranglement. Elle minimise les cycles de développement et permet, même, de supprimer les itérations, on parle alors de livraisons continues. Kanban permet un passage à l’Agile progressif, sans changement radical de l’organisation déjà en place.

Scrum est la méthode la plus connue et, certainement, la plus utilisée pour l’encadrement de projets Agile. Elle est particulièrement adaptée aux projets de taille conséquente. Elle donne le pouvoir aux décideurs métiers en leur permettant de déterminer les priorités, de faire évoluer et même de modifier leurs besoins régulièrement. Elle repose sur quelques règles permettant à une équipe de s’organiser afin de construire un logiciel de manière itérative et incrémentale. Elle permet de livrer un produit fonctionnel à chaque itération (généralement, de 2 et 4 semaines). Elle est conçue pour se concentrer sur l’innovation et sur la résolution des problèmes.

Enfin, Scrum et Kanban sont généralement associées aux bonnes pratiques techniques de l’Extreme Programming (XP) qui prône, entre autres une simplicité du design et pose la première pierre de l’automatisation: l’intégration continue, qui assure, à minima, la compilation du code et sa non-régression grâce aux tests unitaires. Cette intégration continue constitue les prémices du mouvement DevOps.

DevOps: réconciliez les équipes de développement et d’exploitation!

Traditionnellement, les équipes de développement écrivent un logiciel pour répondre à un besoin et les équipes d’exploitation l’installent et assurent son bon fonctionnement. Malheureusement, il n’est pas rare que l’équipe de développement ne se soit pas souciée des ressources nécessaires au bon fonctionnement du logiciel, de la façon de le déployer, ou encore, de la façon de surveiller sa bonne santé. Les causes sont diverses, bien souvent ces besoins ne sont pas dans le cahier des charges initial ou, trop souvent, l’équipe de développement se hâte de terminer un projet en retard. Les répercussions sont bien connues: déploiements risqués et non déterministes, applications au comportement différent entre postes de développement et serveurs de production, utilisateurs qui téléphonent pour signaler une application ne fonctionnant plus… Ces conséquences coûteuses peuvent véhiculer une image négative de la qualité d’un logiciel. Pire, elles conduisent à la peur du changement… Une fois qu’une application est «stabilisée» en production, tout le monde appréhende une nouvelle version. Pour tenter d’enrayer le problème, les équipes de développement et d’exploitation sont souvent fractionnées en analystes, développeurs, architectes, testeurs, responsables de «release», administrateurs de base de données, administrateurs systèmes, etc. Cette réponse entraine de lourds processus organisationnels et, de surcroit, contribue au renforcement des phénomènes de clans et à la déresponsabilisation des intervenants. Par conséquent, les temps de cycle de développement explosent sans pour autant augmenter significativement la qualité des logiciels produits.

Le mouvement DevOps (réunion des mots anglais «development» et «operations») est basé sur l’idée que l’utilisation des bons outils et un changement radical d’attitude peuvent révolutionner le monde du développement informatique tout en produisant de meilleurs logiciels et en dépensant moins d’argent!

DevOps est ainsi le prolongement logique des méthodes Agiles appliquées au monde de l’exploitation. Le maître mot est «automatisation». L’automatisation rend les processus déterministes, constants et visibles. Le Saint Graal du DevOps est, non seulement, le déploiement automatisé et continu du logiciel en production (en passant par les tests d’acceptation automatisés), mais aussi le déploiement et la configuration automatisés de l’infrastructure supportant le logiciel (déploiement de machines virtuelles, installation de serveurs d’application, configuration des firewalls, etc.). On parle alors d’Infrastructure as Code (IaC), pratique rendue possible, entre autres, grâce aux services Cloud (public ou privé) tel qu’Infrastructure as a Service (IaaS) et Platform as a Service (PaaS).

Une transition compliquée à gérer

Les choix des bonnes méthodes et des outils adéquats sont spécifiques à chaque entreprise. L’adoption des méthodes Agiles et DevOps au sein de la banque est d’autant plus délicate que le système d’information est, très souvent, techniquement complexe et composé de nombreux intervenants. Une transition mal menée peut-être très mal vécue par les équipes mais aussi par la direction, tant ces méthodes mettent rapidement en lumière les processus déficients et les défauts d’une organisation. Leur adoption ne peut se faire sans une formation adéquate du personnel et un accompagnement régulier des différentes équipes du système d’information.