Sauvegarde et restauration du logiciel après refonte

La sauvegarde de la nouvelle application s’est terminée sans erreur. Lors du premier exercice, les dossiers reviennent, mais leurs pièces jointes manquent et les traitements ne peuvent plus s’authentifier auprès de l’ERP. La copie de la base existe ; le logiciel métier n’est pas encore utilisable.

Après une refonte, le périmètre à protéger a souvent changé : nouveaux stockages, fichiers déplacés, comptes techniques, tâches asynchrones ou services externes. Reprendre simplement le plan de sauvegarde de l’ancien serveur laisse ces dépendances hors du dispositif.

Le risque est de croire qu’une copie disponible rend déjà l’application utilisable. La sauvegarde doit couvrir la restauration et sa réception : un état cohérent, compatible avec une version connue du logiciel, dont les équipes savent vérifier les opérations prioritaires. Une notification verte ne remplace pas cet exercice ni le diagnostic des incidents qu’il peut révéler.

Dans une refonte de logiciel métier sur mesure, Dawap peut cadrer ces besoins avec votre DSI et l’exploitant désigné. Le périmètre, les procédures et les objectifs de reprise se décident selon vos usages, avant la bascule.

Pour qui : les équipes qui doivent retrouver une activité exploitable

Cette préparation concerne les logiciels qui portent des dossiers, commandes, documents, calculs ou workflows dont l’entreprise dépend. Le responsable métier précise les opérations à retrouver ; l’exploitant prépare la récupération ; l’équipe applicative vérifie la compatibilité et les traitements. Une même personne peut remplir plusieurs rôles, à condition de les rendre explicites.

Une application dont toutes les données sont reconstructibles depuis des systèmes maîtres ne demande pas nécessairement le même dispositif qu’un logiciel contenant une information unique. Cette reconstructibilité doit être démontrée : une donnée affichée dans un ERP n’y conserve pas forcément les annotations ou décisions ajoutées dans le logiciel sur mesure.

Sauvegarder l’ensemble nécessaire au logiciel

Les caches et index de recherche peuvent parfois être reconstruits. Il faut connaître leurs sources, la durée de reconstruction et le comportement pendant cette étape. Une information temporaire devenue indispensable au métier mérite un traitement explicite plutôt qu’une exclusion fondée sur le nom du composant.

Le premier signal faible est une procédure qui ne mentionne que « la base ». Faites préciser les pièces jointes, paramètres et services requis. Le second est une copie dont personne n’a vérifié les droits d’accès depuis une autre machine que celle de l’exploitation courante.

Définir perte de données et délai de reprise avec les métiers

Le RPO exprime l’objectif de perte de données acceptable dans le temps ; le RTO exprime l’objectif de délai de remise en service. Ces objectifs se définissent par activité. Une commande récente perdue peut demander davantage de rapprochements qu’un document facilement régénéré.

Pour les établir, décrivez les conséquences : opérations à ressaisir, engagements déjà envoyés à un client, état d’un dossier ou stock déjà consommé. Demandez qui dispose de l’information de secours et combien de temps le mode dégradé reste praticable. Les objectifs doivent correspondre aux moyens techniques et humains réellement disponibles.

Un exemple de discussion consiste à comparer une récupération au dernier état disponible avec une récupération plus récente mais plus complexe. Il faut chiffrer le travail métier restant, les dépendances et les exercices nécessaires. Aucun délai universel n’est proposé ici : il relève du cadrage et du contrat d’exploitation.

Choisir une copie cohérente avec les écritures du logiciel

Coordonner base, fichiers et version

Une base et un stockage documentaire copiés à des instants différents peuvent produire des références sans fichier ou des fichiers sans dossier correspondant. La méthode doit tenir compte de la manière dont l’application écrit ces éléments et de ce que les technologies permettent de figer ou de réconcilier.

La documentation PostgreSQL sur la sauvegarde distingue notamment export SQL, copie au niveau du système de fichiers et archivage continu. Ces approches ont des conditions différentes. La procédure doit suivre la documentation du moteur et de la version effectivement utilisés, au lieu de copier ses fichiers actifs sans méthode adaptée.

Conserver les conditions de lecture de l’état récupéré

Le dossier de sauvegarde doit identifier la version de schéma et le logiciel compatible. Un déploiement récent peut avoir transformé des champs ou supprimé une ancienne représentation. Restaurer les données sans savoir quel code leur correspond déplace la difficulté vers l’équipe qui intervient pendant l’incident.

Lorsque l’exercice inclut une mise à niveau après restauration, consignez ses étapes et ses vérifications. Distinguez ce qui doit exister dans la copie de ce qui sera reconstruit. Cette distinction évite qu’un fichier de configuration présent sur un serveur oublié devienne une dépendance irremplaçable.

Protéger les copies et les moyens de les récupérer

Une copie soumise aux mêmes accès et aux mêmes erreurs que l’original peut être touchée par le même incident. La séparation, les droits, la rétention et les protections disponibles doivent être étudiés ensemble. La conservation de plusieurs états aide aussi lorsque l’anomalie n’est découverte qu’après plusieurs cycles.

Les fondamentaux de sauvegarde de l’ANSSI constituent une référence pour organiser cette protection. Les décisions concrètes restent à adapter à la sensibilité des données, aux outils et à l’organisation qui exploite le logiciel.

Prévoyez également la récupération des moyens d’accès si l’environnement principal ou l’interlocuteur habituel n’est plus disponible. Les clés de déchiffrement, comptes et procédures doivent rester protégés et accessibles aux personnes habilitées. Un secret collé dans une fiche partagée ne constitue pas une solution de continuité.

Exercer une restauration dans une cible isolée

1. Choisir un incident représentatif et l’état que l’équipe souhaite retrouver.
2. Identifier la copie, son horodatage, ses composants et la version applicative associée.
3. Préparer une cible isolée dont les accès et la capacité correspondent à l’exercice.
4. Neutraliser les effets externes : envois, prélèvements, commandes et traitements productifs.
5. Restaurer les composants dans l’ordre prévu, en notant les difficultés et le temps réellement observé.
6. Faire exécuter les parcours de réception par les responsables métier désignés.
7. Consigner les écarts, supprimer ou protéger les données d’exercice selon la procédure, puis corriger le dossier.

La disponibilité de l’écran d’accueil est un premier contrôle technique. Elle doit être complétée par la lecture d’un dossier, l’ouverture d’un document, une recherche ou un calcul pertinent. Les droits et les refus d’accès font également partie du résultat à vérifier.

Télécharger la fiche de test de restauration pour identifier l’exercice, les composants, les preuves et les réserves. Les valeurs observées sont à renseigner pendant votre propre test ; le modèle n’annonce aucune performance obtenue.

Atelier reproductible : six situations de restauration sur des données fictives

Une copie SQLite, des documents et un état à retrouver

Nous avons exécuté un laboratoire local avec Python 3.14.8 et SQLite 3.51.2. La base contient deux dossiers inventés, chacun lié à un document texte fictif. Une copie est produite avec l’API de sauvegarde SQLite, puis plusieurs restaurations sont ouvertes dans des fichiers distincts. Les contrôles lisent réellement les lignes et les références après récupération.

Le script de l’atelier fictif peut être rejoué avec Python dans un répertoire temporaire créé par le programme. Il ne demande aucun accès réseau et ne charge aucune donnée d’un client. Le mécanisme de copie utilisé est décrit par la documentation Python de Connection.backup.

Ce que le laboratoire prouve et ce qu’il faut encore recevoir

Les cas A à E constatent des opérations sur SQLite et des références vers notre jeu de documents. F compare deux ensembles de références entièrement inventés ; aucun partenaire n’est appelé. Le résultat ne mesure ni une performance de restauration, ni la protection de copies, ni le fonctionnement de votre application. Il rend visibles des contrôles différents que le dossier d’exploitation doit rapprocher.

Le cas A n’est donc pas un certificat de reprise. Il démontre seulement que ses dossiers et ses références sont cohérents selon le contrôle exécuté. Votre exercice doit ajouter les pièces réelles autorisées, les droits, les traitements et les interfaces propres à votre logiciel. La sortie complète de l’atelier conserve le moteur utilisé et les observations, sans données personnelles.

Décider d’ouvrir, de reprendre les données ou de garder le service arrêté

Une restauration technique n’impose pas l’ouverture immédiate du logiciel. La décision compare les preuves aux invariants métier et aux conséquences de la remise en service. Définissez ces critères avant l’incident : documents indispensables, droits corrects, relations cohérentes et opérations externes rapprochées selon les risques du périmètre.

• Ouvrir le périmètre reçu. Les contrôles critiques sont satisfaits et les réserves restantes sont explicitement acceptées par les responsables compétents.
• Limiter l’usage. Un parcours autonome est reçu, mais une interface ou une fonction reste bloquée et effectivement désactivée.
• Rattraper avant ouverture. Les opérations manquantes sont connues et peuvent être réintroduites selon une méthode vérifiée.
• Refuser l’ouverture. La version est incompatible, les droits sont faux ou les effets déjà produits ne peuvent pas encore être expliqués.

Si un document manque sur un dossier qui doit être traité immédiatement, alors le métier doit connaître cette limite avant de reprendre le travail. En revanche, une fonction secondaire peut rester indisponible si son absence est acceptée et n’invalide pas les parcours ouverts. Le seuil pertinent vient de l’opération à réaliser, pas d’un pourcentage global de fichiers récupérés.

En réalité, une récupération plus récente n’est pas toujours le meilleur état de départ. Elle peut déjà contenir la corruption ou la suppression à l’origine de l’incident. L’exploitant doit retrouver une copie jugée exploitable, puis examiner les écritures à réconcilier. L’âge de la copie et sa cohérence répondent à deux questions distinctes.

Rapprocher les opérations déjà réalisées dans les systèmes connectés

Une base restaurée peut ignorer une commande déjà reçue par l’ERP ou un courriel déjà envoyé. Rejouer tous les traitements en attente risque alors de créer des doublons ou des actions contradictoires. La remise en route doit prévoir les références de rapprochement et la manière de décider quoi reprendre.

Par exemple, dans ce cas fictif, le logiciel est ramené à un état antérieur à l’envoi d’une demande d’expédition. Le transporteur, lui, a déjà accepté cette demande. L’équipe doit rechercher la référence connue chez le destinataire avant de relancer le traitement. Le comportement dépend du contrat de son API et des protections implémentées.

Cette reprise des échanges dépasse la récupération des fichiers. Elle rejoint le PRA de l’application métier après refonte, les priorités métier et les limites du mode dégradé. La recette métier des données reprises aide à formaliser les invariants qui ne peuvent pas être jugés sur le seul nombre de lignes.

Exemple de réception d’un dossier avec une demande déjà transmise

Dans ce cas fictif, l’exploitant fournit en entrée l’état restauré et son horodatage ; le métier apporte la référence du dossier, le document attendu et la demande d’expédition. Le responsable de l’interface retrouve l’accusé du destinataire dans le canal autorisé. La sortie attendue est un dossier cohérent dont le statut explique l’opération déjà réalisée, avec une preuve de rapprochement et un responsable de validation.

Si le destinataire ne peut pas confirmer la référence, alors le traitement reste suspendu et le support instruit la réserve. La procédure de repli consiste ici à empêcher une nouvelle émission, sans bloquer les autres dossiers reçus. La journalisation garde la décision, les dépendances examinées et l’identité de l’intervenant autorisé. La reprise n’est acceptée qu’après correction et nouvelle vérification du parcours concerné.

Attribuer déclenchement, exécution et validation

Le responsable d’incident décide de lancer la procédure avec les personnes habilitées. L’exploitant prépare les ressources et la récupération. L’équipe applicative traite compatibilité et traitements. Le métier confirme les opérations autorisées à reprendre. Les mêmes rôles doivent être prévus lorsque l’une des personnes habituelles est absente.

Pour un hébergement géré par le client, le prestataire applicatif ne possède pas nécessairement tous les accès. Pour un hébergement géré par un tiers, la DSI garde des décisions à prendre sur les utilisateurs et les données. La matrice de choix d’hébergement permet d’identifier ces frontières.

Le contrat de maintenance applicative doit préciser ce qui est couvert : préparation, fréquence des exercices, intervention, horaires et assistance au métier. Évitez qu’une ligne « sauvegardes incluses » masque des tâches nécessaires mais non attribuées.

Conserver un compte rendu qui permet la relève

Le dossier relie les entrées de l’exercice à ses sorties : copie retenue, version, dépendances, déroulé, durées observées et contrôles métier. La journalisation identifie l’étape atteinte et les réserves sans inscrire les secrets dans le compte rendu. Une autre personne doit pouvoir savoir où reprendre le diagnostic sans relancer aveuglément toutes les opérations.

Pour chaque réserve, attribuez la correction, sa priorité et la vérification à rejouer. Le coût caché se trouve souvent dans les tâches humaines non prévues : retrouver un accès, demander une confirmation au partenaire ou refaire un document. Ces attentes doivent être observées séparément du temps pendant lequel la base est effectivement recopiée.

Réviser le dispositif quand le logiciel refondu évolue

Une nouvelle fonctionnalité peut ajouter un stockage, modifier le schéma ou changer la manière dont un document est produit. Le lot doit indiquer si la procédure de restauration reste valable et quelle partie de l’exercice doit être rejouée. Les copies existantes doivent rester accompagnées des informations nécessaires pour retrouver une version compatible.

La fréquence des exercices dépend de la criticité, des changements et des moyens convenus. Une date périodique ne remplace pas l’examen d’une transformation importante. Un déplacement de documents ou un changement de gestion des identités peut justifier un test ciblé avant la prochaine échéance prévue.

À faire d’abord : inventorier les composants nouveaux et retrouver les moyens d’accès. À différer : l’automatisation d’un compte rendu dont les contrôles ne sont pas encore définis. À refuser : retirer l’ancien mécanisme de reprise avant de savoir restaurer le périmètre qui le remplace. La supervision doit signaler l’échec d’une copie, tandis que les exercices vérifient ce qu’un succès permet réellement de récupérer.

Erreurs fréquentes qui rendent la sauvegarde insuffisante

• Assimiler réplication et conservation d’un état antérieur. Une suppression ou une corruption peut être reproduite sur plusieurs composants disponibles.
• Tester uniquement le téléchargement d’une archive. Le logiciel, les droits et les pièces jointes restent alors non réceptionnés.
• Réactiver immédiatement les traitements externes. Les effets déjà produits doivent être rapprochés avant une nouvelle émission.
• Conserver une procédure ancienne après la refonte. Un nouveau stockage ou une nouvelle identité peut manquer au dossier.
• Annoncer un délai sans exercice représentatif. Les conditions de restauration et le temps de validation métier restent à établir.

La priorité est de faire fonctionner un périmètre complet et représentatif. Différez les automatismes secondaires si nécessaire, mais corrigez les composants manquants et les accès inopérants avant d’appeler le dispositif une capacité de reprise.

Relier les tests de reprise à la livraison et à l’observabilité

La CI peut vérifier qu’une migration sait lire un jeu ancien autorisé et que les références documentaires restent contrôlables. Ces tests ne remplacent pas l’exercice sur une cible isolée, avec les accès et les composants d’exploitation. Ils détectent plus tôt une incompatibilité introduite par un déploiement. L’observabilité complète ce dispositif en signalant une copie échouée ou un traitement suspendu ; elle doit permettre de retrouver le contrôle concerné sans exposer les documents ou les secrets dans les journaux.

Plan d’action : réceptionner la restauration avant la fin de la refonte

Commencez par l’inventaire des actifs et la perte de données acceptable par les métiers. Faites ensuite choisir la méthode par les intervenants qui devront l’exécuter. Réservez une cible d’exercice et une disponibilité des responsables métier dans le planning du projet.

Après le test, distinguez trois résultats : copie disponible, application techniquement démarrée et activité métier réceptionnée. Documentez les écarts entre ces étapes. Réexaminez le dispositif lorsque changent le schéma, le stockage, les intégrations ou les responsabilités d’exploitation.

Le dossier de réception dans le SI du client doit contenir cette preuve avec les autres conditions de livraison. La restauration devient ainsi un élément reçu du logiciel, plutôt qu’une hypothèse reportée à son premier incident.

Conclusion : accepter une capacité de restauration, pas seulement une copie

Le logiciel refondu se compose de données, de documents, de code et de dépendances qui doivent retrouver un état compatible. L’inventaire et la procédure doivent couvrir cet ensemble, avec les moyens d’accès nécessaires aux personnes habilitées.

Le test isolé révèle les écarts qu’une notification de sauvegarde ne peut pas montrer. La réception doit atteindre les opérations métier et examiner les effets déjà produits dans les systèmes connectés.

Les objectifs de reprise appartiennent au cadrage de l’exploitation. Ils deviennent crédibles lorsqu’ils correspondent à une procédure praticable, à des responsabilités attribuées et à des exercices dont les écarts sont traités.

Dawap peut vous accompagner pour cadrer avec votre DSI la refonte de votre logiciel et ses conditions de restauration, afin que fonctionnalités sur mesure, données et exploitation soient reçues dans un même projet.