Support legacy
Nous modernisons les applications existantes par étapes, en protégeant les processus, les données et les intégrations qui conservent leur valeur métier.
Moderniser ne consiste pas à remplacer tout ce qui est ancien. Une application utilisée depuis longtemps peut contenir des règles métier essentielles, des exceptions, des données clients et des intégrations dont le remplacement créerait plus de risque que de valeur. La bonne question est donc d’abord métier : faut-il accélérer le traitement, réduire le risque opérationnel, simplifier les livraisons ou faire évoluer un domaine précis ?
La technologie est au service de cet objectif. Un framework récent, le cloud, les microservices, une nouvelle interface ou l’IA ne justifient pas à eux seuls une reconstruction.
Avant toute modification, nous identifions les workflows critiques, l’endroit où l’application est responsable des données, les intégrations qui influencent le résultat et les problèmes établis plutôt que supposés. L’audit rapproche comportement en production, demandes au support, code, dépendances, données et déploiement. En présence d’incidents, la priorité est la stabilisation : rendre les échecs visibles, protéger les workflows importants et organiser la reprise.
Système existant + objectifs métier
│
▼
audit et évaluation du risque
│
┌────────┴────────┐
▼ ▼
stabilisation changement ciblé
│ │
└────────┬────────┘
▼
déploiement et vérificationLe résultat ne doit pas forcément être une réécriture complète. Il peut être plus pertinent de conserver un module stable, de supprimer un goulot d’étranglement ou de mieux isoler une intégration.
Une étape sûre a un objectif et une frontière clairs : reporting, catalogue, import de données ou facturation, par exemple. Elle précise quel système fait foi pour les données, qui peut les modifier, comment traiter une synchronisation en échec et à quelles conditions l’ancien module sera retiré.
L’ancien et le nouveau code peuvent cohabiter si le routage est maîtrisé, si la responsabilité des données n’est pas dupliquée et si les résultats peuvent être comparés. Cela ne garantit pas l’absence d’interruption et ne convient pas à tous les cas. Le remplacement d’un petit module d’un seul coup, ou une réécriture plus large, peut parfois être plus sûr selon le périmètre, le risque et les dépendances.
Utilisateur
│
▼
Routage contrôlé des demandes
├── module existant ──┐
└── module modernisé ─┼── règles communes et contrôle d’accès
│
un système de référence désigné
│
comparer les résultats → retirer l’ancien moduleImaginons une application Symfony qui gère commande, paiement, facturation, notifications et espace opérationnel. Cet exemple est fictif et ne décrit pas un projet client GiSoft. Le checkout peut fonctionner alors que les appels de paiement sont dispersés dans les contrôleurs et que la facturation reste bloquée après des délais dépassés.
La première évolution ne doit pas remplacer l’application. On peut conserver le formulaire de commande et les règles de prix, introduire un adaptateur de paiement, enregistrer l’état de commande qui fait foi et exécuter la facturation dans un job contrôlé. Un e-mail ne doit pas déterminer si une commande est payée.
Checkout et règles de commande ── état enregistré ──► facturation
│ │ │
▼ ▼ ▼
adaptateur de paiement vue opérationnelle système comptable
│
└── validation, délais d’attente, historique des tentativesUn délai dépassé ne signifie pas automatiquement que le paiement ou la facture a échoué. Une relance sûre exige un état durable, la maîtrise de la concurrence, des contraintes d’unicité dans la base et un comportement compatible du fournisseur. Un identifiant de commande ne suffit pas à garantir l’idempotence. Si l’action externe a pu avoir lieu, vérifier le statut ou appliquer une correction est parfois plus sûr qu’une relance aveugle.
Mettre à niveau PHP, Symfony, Laravel ou les dépendances peut améliorer la maintenance et la sécurité, mais impose une vérification de compatibilité, la protection des règles critiques et un déploiement fiable. Toute application n’a pas besoin d’une nouvelle interface, de conteneurs ou de services séparés. Une interface rendue côté serveur ou basée sur jQuery peut rester pertinente si elle répond aux besoins et ne bloque pas l’évolution attendue.
Il en va de même pour la base. Nous analysons d’abord les performances, la responsabilité des données, la qualité des migrations et la possibilité d’annuler un changement local. Le SQL direct peut être justifié. Lors du remplacement d’un module, des migrations versionnées, un système de référence convenu et des imports contrôlés sont plus sûrs qu’une synchronisation bidirectionnelle permanente sans responsable.
Les tests de caractérisation capturent le comportement actuel avant le refactoring. Les plus utiles couvrent commande, prix, droits d’accès, paiements, factures et intégrations critiques. Après une livraison, nous contrôlons aussi configuration, migrations, workers, tâches planifiées et signaux de production.
Revenir en arrière sur le code n’annule pas un paiement capturé, un e-mail ou un document transmis à un ERP. Ces effets demandent une reprise vers l’avant : état final vérifié, correction sûre et responsabilité claire. La supervision doit relier les signaux techniques à l’identifiant métier sans enregistrer inutilement de données sensibles.
La modernisation couvre aussi authentification, autorisation côté serveur, rôles, isolation des organisations, secrets et identifiants d’intégration actuels. Un changement de framework ou d’infrastructure ne procure pas ces garanties automatiquement.
GiSoft priorise selon la valeur métier, le risque, la fréquence du problème, les dépendances et le coût de maintenance à venir. Un changement petit et vérifiable convient à un problème bien circonscrit. Le remplacement d’un module convient à une responsabilité claire. Une réécriture plus large est envisagée lorsque les frontières, les données ou la sécurité rendent les étapes progressives impraticables.
L’IA peut être utile dans un workflow maîtrisé, mais ne justifie pas une reconstruction. Les sources de données, les droits, la piste d’audit et la responsabilité de l’application pour les actions finales doivent d’abord être clairs.
Le résultat dépasse le nouveau code : c’est un plan mesurable qui indique ce qui a changé, comment les workflows ont été protégés, comment la livraison a été vérifiée, quel risque subsiste et pourquoi l’étape suivante a un intérêt métier.