Dans une grande banque, quelles sont les mécaniques IT derrière une librairie financière et quel est le rôle de l’automatisation dans l’évolution de cette librairie ? Qu’il s’agisse de livrer de nouvelles versions, de maîtriser la dette technique ou de réduire les temps de calcul, l’automatisation IT est ici le fil conducteur d’une démarche tournée vers l’amélioration continue.

La librairie a pour vocation de mettre en place les modèles de valorisation des produits financiers développés par la banque. Intégrée dans un vaste système d’informations, cette librairie évolue régulièrement : chaque mise en production d’une nouvelle version peut apporter des évolutions, corrections de bugs, du refactoring ou des optimisations. Alexis Capron, Responsable R&D Summit Taux/Crédit chez Natixis, nous explique ici quelles solutions d’automatisation ont été mises en place pour faire évoluer cette librairie, en prenant en compte les contraintes de développement, de dette technique et de maîtrise des temps de calcul.

Gérer les contraintes de développement

La première et la plus forte des contraintes, c’est celle de la garantie de l’existant: « Nos modifications doivent être transparentes pour les utilisateurs,  et ne casser aucune fonctionnalité existante » explique Alexis Capron. Cela implique de réaliser des tests de non régression qui soient le plus exhaustifs possibles, et d’automatiser ces process :

• Automatisation de la génération de tests unitaires via les logs utilisateurs
• Automatisation de l’usine de tests, générés par des grilles de machines afin de réduire au maximum les temps d’attente des résultats

La génération des modèles pour monitorer les prix a également été automatisée de façon à être standardisée, et éviter les erreurs manuelles.

Faire évoluer l’architecture et l’environnement de développement

Autre défi de taille : l’évolution de l’architecture et de l’environnement de développement. L’intégration se fait dans un écosystème vaste et complexe : trois types de binaires différents sont générés par la librairie, et ceci implique que leur compatibilité soit garantie par les versions utilisées. Si une version supérieure ne garantit pas la compatbilité des binaires, alors il n’est pas possible d’upgrader. La question de la dette technique est également essentielle pour l’évolutivité.

Prendre en compte la dette technique

Une librairie avec 15 ans d’existence et 2 millions de lignes de code accumule nécessairement un certain passif, et s’il n’est pas possible de résorber sa dette technique, il faut faire en sorte de ne pas l’aggraver. « Pour maîtriser l’évolution de notre dette technique, nous avons défini un cadre de développement, et de bonnes pratiques de développement : la façon de coder, mais également de documenter son code et de créer des tests de non-régression » nous confie Alexis Capron. Pour que le code soit partageable, qu’il puisse être transférable au fur à et mesure de l’évolution de l’équipe, il doit être générique et non spécifique. Cela implique de faire également du refactoring dès que c’est possible, et d’automatiser la surveillance avec un outil comme SONAR.

Pour ce qui est de la fiabilité du code, l’équipe a mis en place une usine de build automatisée Jenkins. Chaque modification lance une compilation : toute l’équipe est automatiquement notifiée en cas d’erreur dans la compilation. « Le pipeline Jenkins automatisé permet un véritable gain de temps et de fiabilité, puisqu’il y a des dizaines de configurations de compilations différentes, et qu’il est impossible de demander aux développeurs de compiler dans toutes les configurations.« 

Maîtriser les temps de calcul

Avec l’obligation de délivrer quotidiennement le reporting à heures fixes, la maîtrise des temps de calcul est également un enjeu clé. Or ceux-ci augmentent de façon mécanique sous l’effet de différents facteurs : les modèles sont plus sophistiqués, les produits sont plus complexes et plus nombreux, et les normes réglementaires (Bâle III) obligent à mettre en place des stress test, c’est-à dire des scénarios où des situations de marché extrêmes sont simulées afin de voir comment le système réagit.

Tous ces facteurs viennent potentiellement mettre à mal les objectifs de performance et de maîtrise des temps de calcul. Parmi les moyens mis en oeuvre pour améliorer les temps de calcul, citons :

• le calcul distribué (augmentation du nombre de machines)
• le calcul parallèle (GPU, multi threading)
• l’optimisation via des outils de profiling type Vtunes
• des techniques numériques ou mathématiques (comme la différenciation automatique, méthode mathématique de parallélisation de calcul de dérivée)

La place de l’automatisation

Depuis plusieurs années, la question de l’automatisation est centrale : qu’est-ce qui peut être automatisé ? Comment peut-on non seulement se faciliter la tâche, mais surtout fiabiliser les opérations récurrentes ? Une erreur humaine est souvent à l’origine de la décision d’automatisation d’une tâche. Comme évoqué plus haut, tout le pipeline de compilation et de livraison a été automatisé; de même que les tests unitaires sous unix, et les tâches de chargement de bases de données. Même si une tâche ne demande que deux lignes de commandes, il est toujours plus rentable de l’automatiser en créant un job Jenkins : charger une base ne demande alors plus que de pousser un bouton sur une interface user friendly. Le seul bémol qu’on pourrait mettre à cette automatisation est la dépendance à l’automate et à celui qui le crée. Mais les avantages sont bien plus profitables, comme nous le confirme Alexis Capron : « Les gains de fiabilité sont évidents et l’intégration de nouveaux membres dans l’équipe est facilitée par le fait d’avoir des process automatisés.«