Modernisation applicative
Sortir du legacy sans arrêter l’activité.
Nous migrons pas à pas les applications desktop et les applications .NET vieillissantes vers des architectures web modernes, avec des tests automatisés qui garantissent le comportement à chaque étape.
Les signaux d’alerte
- Une application desktop critique tourne sur quelques postes et seules quelques personnes la comprennent.
- Chaque modification du code legacy casse quelque chose sans rapport.
- Le schéma de base de données a grossi pendant dix ans sans conception d’ensemble.
- La réécriture est sans cesse repoussée parce que le risque semble trop élevé.
Ce que nous faisons
Évaluation du code existant
Analyse statique avec des outils comme NDepend pour cartographier les dépendances et les points chauds, suivie d’une feuille de route technique.
Architecture cible
Découpage en couches SOLID, patterns repository et unit of work, injection de dépendances, dimensionnés pour l’application plutôt que copiés d’un modèle.
Migration incrémentale
Fonctionnalités migrées module par module, avec l’ancien et le nouveau système en parallèle lorsque c’est nécessaire.
Filet de sécurité
Tests d’acceptation SpecFlow et Selenium écrits sur le comportement actuel, avant toute modification.
Refonte des données
Refonte de la base de données, modélisation de datamart et flux SSIS.
Ce que vous obtenez
- Un audit et une feuille de route de migration
- Une suite de tests d’acceptation automatisés
- Des modules migrés en production
- Un pipeline CI/CD
Réalisations associées
Migrer vers le web une application desktop de billetterie
Migration d’une application desktop de billetterie, de vente en ligne et de réservation d’événements vers une application web ASP.NET MVC, menée en tant que team lead.
Lire l’étude de casLogiciel d’assurance collective pour un grand assureur
Processus métier cœurs et interface web repensée pour une suite d’assurance couvrant l’assurance collective, la prévoyance, l’IARD, la facturation et la comptabilité.
Lire l’étude de casQuestions fréquentes
Faut-il tout réécrire ?
Rarement. Une migration incrémentale continue d’apporter de la valeur et fait apparaître les surprises tôt. Nous ne recommandons une réécriture que si l’audit montre que le code existant ne peut pas porter l’architecture cible.
La migration peut-elle se faire pendant que l’équipe continue de livrer des fonctionnalités ?
Oui. C’est tout l’intérêt d’une migration module par module, avec des tests qui garantissent le comportement.