Sauvegarde d'une boutique : prouver la restauration des commandes et du catalogue

Une sauvegarde n’est pas démontrée par la présence d’un fichier téléchargé. Pour savoir si la boutique peut reprendre, il faut vérifier ce qui peut être reconstruit : catalogue, commandes, médias, réglages et liens avec les services qui continuent d’agir. L’export, la restauration et la remise en service sont des étapes différentes.

La méthode proposée prépare un test isolé, à autoriser séparément. Elle ne copie aucune donnée client et n’exécute aucune restauration. Shopify sert d’exemple documenté ; une application de sauvegarde ou une autre plateforme demande la lecture de ses propres limites.

Définir ce qu’il faut retrouver et à quelle date

Commencer par le scénario : suppression de produits, erreur de configuration, incident de sécurité ou indisponibilité d’un prestataire. Ces situations ne demandent pas toutes la même reconstruction. Définir les données critiques, la période couverte et les opérations qui peuvent continuer pendant la reprise.

L’ANSSI recommande de relier la stratégie de sauvegarde à la perte de données et à la durée d’interruption admissibles. Ces objectifs sont des arbitrages métier, pas des valeurs standard à recopier. Ils doivent correspondre aux capacités réellement prévues et exercées.

Le dossier de contrôle nomme donc les objets attendus et les dépendances : produits et variantes, images, commandes et lignes, clients utiles au rapprochement, stocks, applications, règles et documents. Une liste ne prouve pas leur couverture ; chaque objet doit rejoindre une source sauvegardée et une voie de restauration.

Lire les limites de la plateforme avant l’incident

La documentation Shopify sur la sauvegarde et la duplication distingue les informations exportables de celles qu’il faut reprendre autrement. Les commandes ne sont pas importables par l’interface administrateur ; la documentation évoque des applications ou l’API, sans démontrer leur adéquation à chaque reprise.

Elle signale aussi des limites pour les cartes émises, codes de réduction, rapports et données de trafic. Certaines applications et configurations doivent être réinstallées ou reconfigurées. Copier le thème ne reconstruit donc pas les objets qui résident ailleurs.

Le contrôle d’import CSV traite les écrasements et variantes du catalogue. La restauration ajoute la question de la cohérence globale : retrouver des fiches ne suffit pas si les commandes ou les services externes pointent vers d’anciens identifiants.

Vérifier la cohérence des exports

Conserver la date d’extraction, son périmètre, le format et les exclusions. Deux fichiers pris à des instants différents peuvent décrire des états incompatibles. Une commande créée après l’export peut déjà avoir été encaissée ou envoyée, alors que le stock restauré reflète l’état précédent.

La documentation d’export des commandes Shopify précise que les transactions exportées portent les paiements capturés, sans les données d’autorisation. Il serait donc incorrect de considérer cet export comme un inventaire complet des possibilités financières encore ouvertes.

Comparer les objets attendus et ceux retrouvés, avec leurs relations. Une commande à plusieurs lignes ne doit pas être comptée comme plusieurs commandes. Les références externes, les pièces jointes et les médias doivent être examinés selon la couverture promise, sans déduire leur présence de la seule taille de l’archive.

Préparer un environnement réellement isolé

Le test doit empêcher les effets involontaires : emails clients, captures de paiement, remboursements, expéditions, synchronisations ou publications. Faire définir les accès et les mécanismes de blocage par les responsables de l’environnement. Changer seulement le nom visible de la boutique ne démontre pas cet isolement.

Utiliser les données nécessaires et autorisées, avec les protections adaptées. Les sauvegardes contiennent souvent des informations sensibles ; les dupliquer dans un espace de test crée aussi un traitement à maîtriser. Les recommandations ANSSI soulignent la protection de l’infrastructure et des opérations de sauvegarde.

Faire également vérifier si la compromission de l’administration principale permettrait de supprimer les copies, leurs clés ou les moyens de restauration. Identifier les protections et accès indépendants effectivement disponibles, avec leurs garanties et leurs limites. Une application SaaS ou le mot sauvegarde ne démontre pas cette indépendance ; l’architecture et le contrat du dispositif doivent l’étayer.

Après un incident de sécurité, qualifier aussi la confiance dans la source utilisée. Une archive disponible peut contenir la modification indésirable. Rejouer le même état sans examen peut réintroduire le problème.

Restaurer dans un ordre qui respecte les dépendances

La recommandation est d’écrire l’ordre avant le test : services nécessaires, configuration, objets, relations puis contrôles des parcours. L’ANSSI demande également une stratégie et un ordre de restauration, adaptés aux dépendances et à la criticité.

Pour chaque étape, relever l’attendu, l’obtenu, les erreurs et les données non couvertes. Vérifier les variantes, les montants, les statuts et les liens plutôt que conclure à partir d’un écran qui s’ouvre. Les identifiants nouvellement créés peuvent demander une correspondance avec ceux des autres outils.

Le test reste incomplet tant qu’une catégorie importante n’a pas de voie de restauration démontrée. Cette limite peut conduire à revoir le contrat de sauvegarde ou l’objectif de reprise ; elle ne doit pas disparaître du compte rendu.

Comparer la reprise aux objectifs métier

Préparer une fiche de recette en texte avec le point de sauvegarde utilisable, la dernière opération récupérée, les opérations manquantes et la méthode de rapprochement. Un horodatage de fichier n’établit pas à lui seul le dernier état cohérent retrouvé. Pour le périmètre choisi, comparer la perte constatée à la perte de données maximale décidée par le métier.

Noter aussi le début de l’interruption, le début du travail de reprise, la fin de restauration technique et le moment où le service répond de nouveau aux critères métier définis. Mesurer la durée sur l’intervalle retenu à l’avance pour l’objectif d’interruption. Une restauration rapide après plusieurs heures d’attente ne signifie pas que cet objectif a été respecté.

La décision proposée sépare donc deux résultats : la reconstruction fonctionne-t-elle, et les objectifs de perte et d’interruption sont-ils tenus ? Si un objet critique manque ou si la reprise arrive trop tard, consigner l’échec correspondant et la correction nécessaire, même si le site s’ouvre. Les horaires, journaux et comptages devront provenir du test réel ; aucun résultat n’est inventé ici.

Réconcilier les flux avant de remettre en service

Rapprocher les commandes restaurées des opérations connues du paiement, de la préparation et de la livraison. Une commande absente de l’archive ne devient pas impayée ; une commande recréée ne doit pas déclencher une seconde exécution d’une action déjà réalisée.

La reprise des effets externes demande une décision distincte de la restauration des données. Identifier les événements en attente et les issues incertaines, puis lever les écarts avec le système qui a exécuté l’opération. Ne pas relancer aveuglément pour obtenir un statut rassurant.

Le dossier de choix de stack aide à distribuer ces responsabilités. Accepter la reprise lorsque les objets critiques sont rapprochés, les objectifs métier de perte et d’interruption respectés et les flux expressément autorisés. Dans le cas contraire, maintenir l’écart ouvert et traiter sa cause avant de relancer les effets externes. Aucun test de ce type n’a été réalisé pour cet article.

Sources consultées le 23 octobre 2026. Le plan doit être adapté aux contrats et à la plateforme ; export disponible et sauvegarde annoncée ne garantissent pas une restauration complète.