Modernisation de systèmes existants, sans arrêter l'activité.
La plupart des refontes de systèmes existants échouent pour la même raison : un seul pattern d'architecture est appliqué partout parce qu'il est familier, pas parce qu'il convient. Feneco choisit parmi un éventail de patterns éprouvés pour le système en présence, et migre les données et l'activité sous charge de production complète — pas une réécriture qui s'enlise silencieusement pendant un an.
Les patterns parmi lesquels nous choisissons — pas un seul par défaut
Un outil interne à forte dominante CRUD n'a pas besoin de la même architecture qu'un système traitant des transactions financières réglementées. Le pattern est une décision, prise par système :
Clean Architecture
Logique métier isolée des frameworks, bases de données et mécanismes de livraison — pour les systèmes qui doivent survivre à ce qui est à la mode cette année.
CQRS + DDD
Lectures et écritures modélisées séparément, agrégats et invariants imposés par le domaine lui-même — pour les systèmes où les règles métier sont la partie difficile.
Vertical Slice Architecture
Chaque fonctionnalité possède sa pile complète, de bout en bout, au lieu d'être répartie sur des couches partagées — pour les systèmes qui doivent ajouter des capacités rapidement sans faire grossir un socle commun.
REPR (Request-Endpoint-Response)
Un point de terminaison ciblé par cas d'usage, sans contrôleurs génériques qui font cinq choses sans rapport — pour les API où la clarté prime sur le DRY à tout prix.
Minimal APIs
Des points de terminaison légers, rapides et sans cérémonie, là où un pipeline MVC complet apporte plus de structure que le problème n'en a besoin.
Comment se déroule la migration
Auditer sous charge réelle
Cartographier ce que le système existant fait réellement — y compris les parties que personne n'a documentées — avant de décider ce qui change. Les points de défaillance uniques et les goulots d'étranglement sont identifiés face au trafic réel, pas à des hypothèses.
Migrer les données via les règles du domaine, pas des scripts
Une base de données existante a rarement un schéma propre à copier. Les données transitent par les mêmes méthodes et invariants de domaine que le nouveau système impose — ordonnées par dépendances, réconciliées, avec une restauration répétée avant la bascule.
Livrer sans arrêter l'activité
Déploiements sans interruption, fonctionnalité par fonctionnalité quand le pattern le permet (les tranches verticales aident ici), et un chemin de repli à chaque étape — la modernisation devient un risque dès qu'elle met l'activité hors ligne pour être livrée.
Preuves
Feneco a reconstruit le système existant PHP de ~1 500 fichiers de Liren Language & Communications en monolithe modulaire .NET sur CQRS et DDD, avec une migration de données ordonnée par dépendances et une restauration répétée avant la bascule — faisant désormais tourner les opérations de formation au Luxembourg, en Belgique, en France et aux Émirats arabes unis. Avant l'existence de Feneco, son ingénieur fondateur a appliqué la même discipline chez Commonwealth Bank, migrant la plateforme Buy Now Pay Later vers Clean Architecture sur AWS sous charge de production complète.
Quand la modernisation implique aussi une nouvelle infrastructure AWS, voir Architecture Cloud & AWS.
Si un système existant est ce qui empêche votre équipe de fonctionner comme l'entreprise en a réellement besoin, parlons-en.