Support legacy
Nous remettons sous contrôle le risque opérationnel d’une application existante avant une modernisation, une migration ou un développement plus important.
Une application ancienne ne devient pas problématique parce qu’elle utilise une version antérieure de PHP ou de Symfony. Elle contient souvent des règles métier, des exceptions et des intégrations construites au fil des années : commandes, paiements, factures, documents, comptes clients ou validations internes. Le risque apparaît lorsque personne ne peut expliquer ce qui s’est produit pendant un incident, ni dire si la prochaine livraison perturbera le travail quotidien.
La stabilisation permet de reprendre cette maîtrise. Elle ne promet pas une application sans défaillance. Elle réduit la probabilité et les conséquences des incidents et, lorsqu’ils surviennent, facilite leur détection, leur traitement et l’apprentissage avant le changement suivant.
Avant un chantier important, il est utile de distinguer trois types d’intervention. Une correction urgente ne doit pas devenir une réécriture improvisée, et une modernisation ne doit pas commencer sur une base instable.
PROTECTION IMMÉDIATE STABILISATION MODERNISATION
limiter le dommage actuel reprendre le contrôle préparer l’avenir
bloquer une action erronée tests des workflows critiques mise à niveau PHP/framework
retirer un secret exposé supervision et statuts remplacer un module/intégration
stopper les doublons déploiements reproductibles frontière API ou migration
procédures de repriseLes frontières ne sont pas toujours nettes, mais les objectifs diffèrent. La protection immédiate limite le dommage. La stabilisation rend le système actuel suffisamment prévisible pour être exploité. On peut ensuite décider sur des bases concrètes de mettre à niveau, migrer, remplacer ou conserver un module stable.
Le point de départ est constitué des processus qui font tourner l’entreprise : connexion et droits d’accès, commande, confirmation de paiement, facturation, gestion documentaire, imports ERP, notifications et traitements en arrière-plan. Tous les défauts techniques n’ont pas la même urgence. Un rapport lent peut attendre ; un client débité deux fois ou une facture introuvable exige une analyse rapide.
Nous évaluons l’effet sur les clients et les équipes, la fréquence, l’existence d’un contournement manuel sûr, la dépendance à un fournisseur externe et la difficulté de rétablir l’état métier correct. Cette démarche donne un ordre de travail réaliste, plutôt qu’une liste dictée par l’âge apparent du code.
Imaginons une application Symfony qui prend les commandes et les paiements, demande l’émission des factures à un système comptable, envoie des confirmations par e-mail et propose un espace de gestion. Il s’agit d’un exemple fictif, pas d’un projet client GiSoft.
Les commandes peuvent être créées correctement, tandis que des factures restent dans une file après le ralentissement d’un service externe. Après un déploiement, un worker peut encore utiliser l’ancienne version de l’application. Le support reçoit une réclamation, mais ne sait pas si la facture n’a jamais été créée ou si seule sa confirmation n’est pas revenue. Une relance manuelle sans vérification de l’historique peut créer un second document.
La première étape consiste à établir quel statut de commande fait foi, quel événement déclenche la facturation et où chaque tentative est enregistrée. Le parcours peut alors être protégé contre un double traitement involontaire et rendu compréhensible pour l’équipe qui gère les exceptions.
Commande → confirmation de paiement → état de commande enregistré
│
▼
job d’émission de facture
│
┌─────────────────┴─────────────────┐
▼ ▼
résultat confirmé erreur ou délai dépassé
statut mis à jour tentative enregistrée + supervision
│
▼
relance sûre ou vérification humaineUn délai dépassé ne prouve pas que le système comptable n’a rien fait. La décision de relancer doit s’appuyer sur l’état enregistré, la réponse du fournisseur, la possibilité de vérifier ses propres enregistrements et la règle métier. Si l’action externe a déjà pu avoir lieu, une vérification ou une correction est parfois plus sûre qu’une relance automatique.
Une relance sûre répète la même action métier sans créer un nouvel effet. Un identifiant stable, tel qu’un numéro de commande ou l’identifiant d’une demande de paiement, est utile, mais ne garantit pas à lui seul l’idempotence.
La protection dépend de sa mise en œuvre : état conservé de manière durable, vérification et création atomiques, gestion des requêtes concurrentes, contraintes d’unicité dans la base et comportement du fournisseur externe. Une intégration bien conçue reconnaît une tentative précédente, renvoie le résultat connu ou oriente le dossier vers une vérification. Elle ne masque pas l’incertitude derrière des relances illimitées.
Un journal serveur suffit rarement à la personne qui doit répondre à un client. La supervision technique doit montrer les arrêts de workers, les temps de réponse des intégrations, les files, les requêtes lentes et la version déployée. Une vue opérationnelle doit permettre de retrouver le dossier métier, son étape, le nombre de tentatives, une catégorie d’erreur exploitable et la prochaine action appropriée.
Il n’est pas nécessaire de journaliser des documents complets ou des échanges avec les clients. Le lien utile associe un identifiant métier aux seules informations nécessaires au diagnostic et à l’audit. Les données sensibles, les secrets et les données d’une autre organisation ne doivent pas apparaître dans les logs par simple commodité de débogage.
Les tests de caractérisation décrivent d’abord le comportement actuel, même lorsque le code est difficile à faire évoluer. Un projet de stabilisation ne commence pas par des milliers de tests. Il protège en priorité les scénarios à fort enjeu : un callback répété ne crée pas un second débit, un utilisateur non autorisé ne voit pas les données d’une autre organisation, et une facture en échec reste visible et suit une procédure définie.
Le déploiement demande la même rigueur. Nous documentons la configuration et l’ordre des migrations, vérifions les dépendances, enregistrons la version applicative, confirmons le redémarrage des workers et contrôlons les workflows critiques après la livraison. Un plan de retour arrière doit distinguer les changements locaux des effets externes. Annuler du code ou une migration ne retire pas un e-mail envoyé, un paiement déjà capturé ni une opération transmise à un ERP. Ces situations exigent un état final vérifié, une procédure de correction et un responsable identifié.
Stabiliser ne signifie pas remplacer automatiquement la base, les requêtes SQL ou les intégrations. On établit d’abord la cause. Une liste de clients lente peut nécessiter une pagination, moins de données chargées ou un index après analyse de la requête. Du SQL direct peut être pertinent s’il est lisible, protégé et sous la responsabilité d’une équipe.
Pour les intégrations, nous clarifions les délais d’attente, la validation des réponses, la vérification des webhooks, les identifiants, les responsabilités et la présentation des erreurs. La sécurité couvre l’authentification, l’autorisation côté serveur, les rôles, l’isolation des organisations, les comptes désactivés, les accès d’administration et le stockage des secrets. Masquer un bouton dans l’interface ne constitue pas un contrôle d’accès : l’application doit appliquer les droits côté serveur.
Si une seule personne sait déployer l’application, redémarrer une file ou corriger des données après un incident, l’entreprise dépend d’un savoir privé plutôt que d’un processus. Des guides d’exploitation, des responsables d’intégration, des procédures d’accès, un historique des incidents et de courtes passations font donc partie de la stabilisation.
GiSoft part des éléments vérifiables : incidents en cours, demandes au support, comportement en production, déploiements, jobs en échec, code et dépendances. Le résultat est une vision priorisée des risques, une protection des workflows essentiels, des changements vérifiables et une base pour décider de la suite. Elle peut conduire à une mise à niveau de PHP ou du framework, à une frontière d’intégration plus claire ou au maintien assumé d’un module stable.
La stabilisation ne conserve pas toutes les anciennes décisions techniques. Elle donne à l’entreprise assez de contrôle pour exploiter son application avec plus de sûreté et préparer la modernisation à partir de faits.