DevOps dans la banque, c'est possible

Au premier abord, la notion de « DevOps » résonne certainement comme un sujet purement technique, mais elle constitue un maillon essentiel – pourtant souvent écarté – dans la chaîne de l'agilité dont se targuent tant d'institutions financières. Capital One est l'une des rares dans le monde à mettre en œuvre ses principes sans restriction.
Commençons par préciser ce que signifie « DevOps » : pour faire simple, il s'agit d'une pratique informatique consistant à intégrer dans le développement logiciel les éléments qui permettront ultérieurement l'exploitation du livrable final en production. Grâce à la symbiose ainsi établie entre construction et opération, il est possible d'accélérer les déploiements, en partie ou totalement automatisés. Dans les organisations ayant atteint une maturité suffisante, les cycles d'implémentation deviennent même continus.
Depuis longtemps, cette approche est l'apanage (et un des avantages concurrentiels majeurs) des géants du web. Un responsable d'Amazon affirmait il y a quelques années que le site de e-commerce subissait un changement de code toutes les 11,6 secondes, en moyenne ! Dans les entreprises traditionnelles, banques en tête, qui fonctionnent souvent encore sur des fréquences trimestrielles, une telle rapidité paraît surnaturelle et suscite immédiatement un barrage d'excuses destinées à justifier l'immobilisme.
La première raison invoquée pour réserver le principe de déploiement continu à quelques niches non stratégiques (et non sans le dénaturer, dans la plupart des cas) est le risque d'erreurs, pouvant facilement entraîner des dysfonctionnements catastrophiques des services (en cascade, le cas échéant) ou des infractions aux réglementations en vigueur. Les bugs font partie intégrante du logiciel et on ne pourrait donc se permettre de valider un nouveau composant quelques minutes après qu'il ait été écrit !
Laissons de côté l'idée étrange que sous-entend ce raisonnement, selon laquelle les géants du web ne seraient pas aussi sensibles qu'une banque aux interruptions de service. Leur activité ne repose-t-elle pas entièrement sur leur infrastructure informatique ? Quoi qu'il en soit, pour Capital One, les inquiétudes étaient présentes mais elles ont été prises pour ce qu'elles sont : une peur du changement. La priorité a donc d'abord été placée sur la réduction, voire l'élimination, des craintes de « tout casser ».
Pour ce faire, un cadre rigoureux a été mis en œuvre, caractérisé par deux grandes initiatives. En amont, une sorte de salle blanche du développement logiciel définit et fait respecter un corpus de règles strictes, notamment en matière de contrôle. En aval, parce qu'il faut savoir anticiper les conséquences d'une anomalie, l'« ingénierie chaotique » comprend un ensemble de scénarios de perturbations, joués régulièrement (idéalement en continu) de manière à comprendre et maîtriser les impacts des erreurs éventuelles.
L'agilité tellement désirée dans les grandes entreprises ne peut se concrétiser que si tous les rouages de leurs processus offrent la même flexibilité et la même réactivité. Aussi insignifiante paraisse-t-elle, une approche DevOps en est une partie aussi importante que les autres et aucun argument ne peut justifier d'éviter sa mise en place sans remettre en cause l'objectif global. À défaut, pas d'innovation, pas d'expérimentations rapides, pas de personnalisation des offres, pas d'optimisation opérationnelle… Et Capital One prouve, avec quelques autres, que cette vision n'est pas une lointaine utopie.