Un lundi à 8 h 12, les équipes ne peuvent plus valider les commandes. L’application interne affiche des erreurs intermittentes, le prestataire initial ne répond plus et personne ne sait si la sauvegarde de vendredi est exploitable. Un cas de sauvetage d’application métier critique ne commence presque jamais par une demande proprement formulée. Il commence par une activité bloquée, des décisions prises dans l’urgence et un système que personne ne maîtrise complètement.
Pour une PME, l’enjeu n’est pas de refaire une application « moderne ». Il faut rétablir une capacité de travail fiable, comprendre ce qui casse réellement, puis reprendre le contrôle sans créer une seconde panne. C’est un travail de diagnostic et d’exécution. Pas une démonstration de framework.
Le contexte : une application encore vivante, mais déjà dangereuse
L’application concernée gérait les opérations quotidiennes d’une entreprise de distribution B2B : commandes, stocks, préparation et facturation. Elle était utilisée toute la journée par une trentaine de personnes. Le logiciel n’était pas élégant, mais il portait des règles métier accumulées sur huit ans : tarifs négociés, exceptions clients, calculs logistiques et exports comptables.
Le problème visible était simple : des lenteurs, des erreurs 500 et des traitements nocturnes qui terminaient parfois au matin. Le problème réel était plus large. Le code avait été modifié par plusieurs intervenants. Les déploiements se faisaient directement sur le serveur de production. Les logs étaient incomplets. Les sauvegardes existaient, sans procédure de restauration testée. Enfin, une tâche planifiée supprimait certains fichiers temporaires sans vérifier qu’ils étaient encore utilisés par les imports en cours.
C’est le schéma classique d’une application qui fonctionne « assez bien » jusqu’au jour où le volume, un changement externe ou une erreur opérationnelle révèle les faiblesses accumulées. À ce stade, ajouter une nouvelle fonctionnalité ou migrer toute la stack serait une mauvaise réponse. La priorité est de réduire l’incertitude.
La première décision : stabiliser avant de corriger
Dans un sauvetage, la tentation est forte de corriger immédiatement l’erreur affichée. C’est parfois nécessaire, mais intervenir sans état des lieux peut détruire des indices, aggraver une incohérence de données ou rendre un retour arrière impossible.
La première phase a donc consisté à figer les changements non essentiels. Pas de nouvelle feature, pas de mise à jour de dépendances « pendant qu’on y est », pas de migration de serveur. Les accès ont été recensés, les variables de configuration sauvegardées et une copie cohérente de la base de données a été réalisée avant toute modification.
Cette discipline paraît lente lorsqu’une équipe attend une résolution. En pratique, elle accélère le travail. Un environnement de production fragile devient vite illisible quand plusieurs personnes modifient à la fois le code, les paramètres et les données.
Ce qui doit être vérifié dans les premières heures
Le diagnostic initial ne cherche pas à tout auditer. Il vise les points qui déterminent si l’activité peut être protégée : disponibilité des sauvegardes, état de la base de données, saturation des ressources, erreurs applicatives, flux externes et mécanisme de déploiement.
Dans ce cas précis, les sauvegardes de base étaient valides, mais le stockage des documents générés n’était pas inclus. Les fichiers étaient sur un volume local non sauvegardé. Cette découverte a changé les priorités : il fallait d’abord sécuriser les données opérationnelles et les documents avant de traiter les lenteurs.
Les métriques ont ensuite montré que les pics CPU n’étaient pas causés par le trafic web. Un job nocturne recalculait l’ensemble des stocks au lieu de ne traiter que les mouvements récents. Quand ce job prenait du retard, il entrait en concurrence avec l’activité des utilisateurs le matin. L’erreur 500 n’était qu’une conséquence secondaire de timeouts et de connexions base de données épuisées.
Lire le code avant d’en écrire
Un projet abandonné contient rarement une documentation fiable. La source de vérité est dans le code, les données et le comportement observé en production. Lire le code avant d’en écrire n’est pas une formule. C’est ce qui évite de casser une règle métier invisible.
L’analyse a porté sur les chemins réellement utilisés : création de commande, réservation de stock, génération de facture, import fournisseur et traitement nocturne. Les zones non sollicitées n’étaient pas prioritaires. Il ne s’agissait pas de produire une cartographie exhaustive pour un rapport de 80 pages, mais d’identifier les dépendances qui pouvaient arrêter l’entreprise.
Cette lecture a révélé trois causes structurelles : une requête non indexée exécutée dans une boucle, des transactions ouvertes trop longtemps pendant des appels vers un service externe, et une logique de recalcul global déclenchée par défaut. Chacune était corrigeable. Ensemble, elles rendaient le système imprévisible sous charge.
Le compromis compte ici. Réécrire le module de stock aurait offert une architecture plus propre, mais aurait pris des semaines avec un risque fonctionnel élevé. La correction ciblée, accompagnée de tests sur des données anonymisées et d’un déploiement réversible, répondait au besoin immédiat. La dette n’avait pas disparu. Elle était devenue visible, mesurable et planifiable.
Reprendre la production sans jouer à quitte ou double
La remise en état s’est faite par étapes courtes. D’abord, la tâche de recalcul a été limitée aux mouvements pertinents et déplacée hors de la plage de démarrage des équipes. Ensuite, les requêtes les plus coûteuses ont été corrigées et indexées. Les appels externes ont été sortis des transactions critiques avec une gestion explicite des échecs et des reprises.
Chaque changement avait un objectif observable : réduire la durée du job, diminuer le nombre de connexions simultanées, ou empêcher une commande de rester bloquée lorsque le service tiers ralentissait. Les modifications ont été versionnées. Un mécanisme de déploiement reproductible a remplacé la copie manuelle de fichiers sur le serveur.
Le retour arrière doit être prévu avant la mise en production, pas après. Pour les changements de schéma, cela implique parfois une migration compatible avec l’ancienne version du code. Pour une PME, ce niveau de précaution est souvent plus utile qu’une chaîne d’outils complexe. Pragmatique et ennuyeux - comme cela doit l’être.
La supervision n’est pas un supplément
Après la correction, l’application ne pouvait plus dépendre d’une personne qui remarque un problème au hasard. Une supervision minimale a été mise en place : disponibilité du service, erreurs applicatives, temps de réponse, espace disque, état des sauvegardes et durée des traitements planifiés.
Le point décisif n’est pas d’accumuler des tableaux de bord. C’est de définir ce qui exige une réaction, par qui, et dans quel délai. Une alerte sur une sauvegarde en échec mérite une action immédiate. Une hausse légère de latence mérite parfois une observation. Sans cette hiérarchie, les alertes deviennent du bruit et finissent ignorées.
Les sauvegardes ont également été séparées entre base de données, documents et configuration. Surtout, une restauration a été exécutée dans un environnement isolé. Une sauvegarde non testée est une hypothèse, pas un dispositif de reprise.
Ce qu’un cas de sauvetage doit laisser derrière lui
Une intervention réussie ne se mesure pas seulement au retour du service à 10 h 30. Elle laisse l’entreprise dans une position moins dépendante et mieux informée. Dans ce cas, les livrables comprenaient une description de l’architecture réelle, les accès et responsabilités, la procédure de déploiement, les points de fragilité connus, ainsi qu’un plan de travaux priorisé.
Ce plan distinguait trois horizons. Les corrections immédiates protégeaient l’exploitation. Les travaux à court terme traitaient les tests, les droits d’accès et certains flux externes. Les décisions de moyen terme concernaient la refonte progressive du module de stock et la sortie d’un composant non maintenu. Tout ne devait pas être fait maintenant, mais tout devait être documenté et arbitré.
C’est souvent là que la valeur d’un intervenant senior apparaît. Il ne promet pas qu’un système ancien deviendra neuf en quelques jours. Il sépare ce qui est urgent, ce qui est risqué et ce qui peut attendre. Rocket Services intervient précisément dans cette zone : reprendre un environnement réel, le rendre compréhensible, puis produire des décisions techniques exploitables.
Le bon réflexe quand votre application tient encore
N’attendez pas l’arrêt complet pour vérifier vos sauvegardes, vos accès de production et le déroulé d’un déploiement. Une application métier critique ne devient pas critique le jour de la panne : elle l’est déjà lorsque la facturation, les opérations ou la relation client dépendent d’elle.
Le meilleur moment pour organiser une reprise est quand le système fonctionne encore suffisamment pour être observé calmement. À ce moment-là, on peut corriger avec méthode plutôt que négocier chaque décision sous la pression d’une journée d’activité perdue.