Contexte
Plateforme SaaS logistique, secteur Transport. La contrainte de départ : faire évoluer le produit sans jamais couper le service à ceux qui l'utilisaient déjà tous les jours.
realisations/1:Project
Vertigo Logistics
- Client
- Plateforme SaaS logistique
- Secteur
- Transport
- Stack
- .NET · Angular
Résultat clé4×temps de chargement
Le projet
Migration monolithe → ASP.NET Core modulaire, refonte Angular, CI/CD complète.
Notre approche
Migration monolithe → ASP.NET Core modulaire, refonte Angular, CI/CD complète.
Résultats
4× sur « temps de chargement ». 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
Sortir d'un monolithe n'est pas un problème de découpage, c'est un problème de calendrier. Le système continue de servir des clients pendant qu'on le transforme, et chaque semaine où l'ancienne et la nouvelle version coexistent ajoute du travail de synchronisation. La question n'est donc jamais « comment découper » mais « dans quel ordre, pour que chaque étape soit livrable ».
Le transport ajoute une contrainte de sa propre nature : les traitements sont saisonniers et les pics ne se négocient pas. Un déploiement raté un jour de forte activité coûte davantage qu'une semaine de développement, ce qui change la façon dont on arbitre entre aller vite et aller sûrement.
Les décisions qui ont compté
Découper par cas d'usage, pas par couche technique
Le réflexe est de séparer d'abord la base, puis les services, puis l'interface. C'est le pire ordre possible : on obtient trois chantiers dont aucun ne produit de valeur tant que les trois ne sont pas finis. Nous découpons par fonction métier complète, verticalement, de l'écran jusqu'à la table.
Chaque tranche part en production seule, derrière une façade qui décide si la requête va vers l'ancien système ou le nouveau. À aucun moment il n'existe une version « en cours de migration » qu'on ne saurait pas livrer. C'est plus lent sur le papier et bien plus rapide en pratique, parce qu'on ne cumule jamais des mois de travail non livré.
La refonte de l'interface, en même temps ou après
Refondre le back-end et le front-end simultanément double le nombre de variables à chaque incident : on ne sait plus si le défaut vient de la nouvelle API ou du nouvel écran. Séparer les deux dans le temps est plus sûr, mais impose aux utilisateurs une longue période où rien ne change visiblement.
L'arbitrage se joue sur qui subit quoi. Quand la lenteur perçue est le motif du projet, l'interface doit bouger tôt, sinon personne ne croit que le chantier avance. Nous acceptons alors la complexité supplémentaire et nous la compensons par des drapeaux de fonctionnalité qui permettent de revenir à l'ancien écran sans redéployer.
La chaîne de déploiement d'abord, pas en dernier
Sur une migration progressive, le nombre de mises en production explose : c'est le principe même de la méthode. Installer la chaîne d'intégration au début n'est donc pas un confort, c'est la condition qui rend le reste possible. Une migration par tranches avec des déploiements manuels s'arrête d'elle-même au bout de quelques semaines.
Nous traitons la durée de cette chaîne comme une contrainte de conception. Au-delà de dix minutes, l'équipe regroupe ses changements pour éviter l'attente, les livraisons regrossissent, et on retrouve exactement le comportement qu'on cherchait à quitter.
Ce que ce type de projet apprend
- L'ordre du découpage compte plus que le découpage lui-même.
- Une façade devant l'existant permet de revenir en arrière à chaque tranche.
- La chaîne de déploiement conditionne la méthode, elle ne la suit pas.
- Un pic d'activité connu à l'avance est une contrainte de calendrier, pas un aléa.
Ce que le chiffre annoncé mesure
Le facteur quatre porte sur le temps de chargement des écrans les plus consultés, mesuré côté navigateur sur des sessions réelles. Il ne dit rien du temps de traitement des lots de nuit, qui relève d'un autre chantier, ni du ressenti sur une connexion dégradée, où l'écart se resserre. Il ne dit pas non plus que tout le système a été migré : la migration progressive signifie précisément que certaines fonctions tournent encore sur l'ancien socle.
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.