Contexte
Espace conseiller, secteur Finance. La contrainte de départ : faire évoluer le produit sans jamais couper le service à ceux qui l'utilisaient déjà tous les jours.
realisations/5:Project
Northline Bank
- Client
- Espace conseiller
- Secteur
- Finance
- Stack
- .NET · Angular
Résultat clé99.98%uptime annuel
Le projet
Application interne critique migrée sur Clean Architecture, tests & observabilité.
Notre approche
Application interne critique migrée sur Clean Architecture, tests & observabilité.
Résultats
99.98% sur « uptime annuel ». Derrière ce chiffre : une base de code couverte par des tests, une documentation à jour dans le dépôt, et une équipe interne capable de reprendre la main.
Stack technique
Réalisé avec .NET, Angular, sur une chaîne d'intégration et de déploiement continue montée avec le projet. Les technologies ont été choisies pour ce contexte-là, pas parce que nous les préférons.
Le problème d'ingénierie
Sur une application interne critique, l'enjeu n'est pas la performance mais la capacité à changer sans casser. Une application qui tourne bien et qu'on n'ose plus modifier est déjà en difficulté : les demandes s'accumulent, les contournements manuels se multiplient, et la valeur se dégrade sans qu'aucun indicateur technique ne bouge.
Le passage à une architecture propre sert exactement cela. Ce n'est pas une élégance : c'est ce qui permet de remplacer une brique d'infrastructure sans toucher aux règles métier, et de tester ces règles sans monter toute l'application.
Les décisions qui ont compté
Des tests de caractérisation avant toute réécriture
Sur du code existant sans tests, écrire des tests unitaires avant de refactoriser est souvent impossible : le code n'est pas testable, c'est précisément le problème. On commence donc par figer le comportement actuel tel qu'il est, sans juger s'il est correct.
Ces tests servent de filet et de rien d'autre. Ils autorisent à déplacer du code en sachant dans la minute si un comportement a changé. L'ordre inverse — refactoriser d'abord, tester ensuite — revient à réécrire à l'aveugle des règles dont plus personne ne connaît le détail exact, et à découvrir les écarts en production.
Isoler les règles métier de tout le reste
L'objectif concret est qu'un test d'une règle de calcul s'exécute sans base de données, sans serveur web et sans réseau. Quand c'est vrai, la suite tourne en secondes et l'équipe la lance avant chaque envoi. Quand ce n'est pas vrai, elle tourne en minutes, personne ne la lance, et elle finit par ne plus être maintenue.
Cette isolation a un bénéfice qu'on mesure au moment où l'on ne s'y attend pas : le jour où une dépendance externe doit être remplacée, l'opération ne touche qu'une couche. La valeur de l'architecture ne se constate jamais le jour où on l'écrit.
L'observabilité comme partie du produit
Sur une application critique, savoir qu'un incident a lieu est une fonctionnalité au même titre que le reste. Journaux structurés, traces distribuées et indicateurs métier sont posés en même temps que le code, pas ajoutés après le premier incident sérieux.
Nous distinguons les indicateurs techniques des indicateurs métier, parce qu'ils ne servent pas les mêmes personnes. Un taux d'erreur HTTP intéresse l'exploitation ; le nombre de dossiers bloqués à une étape intéresse le métier, et c'est souvent lui qui révèle un problème que les indicateurs techniques ne voient pas passer.
Ce que ce type de projet apprend
- Le filet de tests vient avant la réécriture, jamais après.
- Une suite qui tourne en secondes est lancée ; une suite en minutes ne l'est pas.
- L'architecture ne prouve sa valeur que le jour d'un changement d'infrastructure.
- Les indicateurs métier détectent ce que les indicateurs techniques laissent passer.
Ce que le chiffre annoncé mesure
Les 99,98 % correspondent à la disponibilité annuelle mesurée sur la période annoncée, soit de l'ordre d'une heure et demie d'indisponibilité cumulée sur l'année. Un taux de disponibilité ne dit rien de la gravité : une heure et demie en une seule fois, un jour de clôture comptable, n'a pas le même coût que la même durée répartie en interruptions de quelques secondes la nuit. C'est pour cela que nous suivons aussi le délai de rétablissement, qui décrit mieux ce que vivent les utilisateurs.
Et ce qu'il ne mesure pas. Un indicateur qu'on n'explique pas ne vaut rien.
Continuer:Project[3]
Autres réalisations
Un projet en tête ? Donnons-lui vie.
Dites-nous ce que vous cherchez à construire ou à reprendre. Réponse sous 24 heures ouvrées, sans engagement, et un avis franc sur la faisabilité même si la réponse ne nous arrange pas.