Sauvegarder une plateforme de livraison : préparer aussi la restauration

Identifier ce qui doit être récupérable

Une plateforme contient le programme, la base de données, les pièces et les paramètres d'exploitation. Une copie du code source ne contient pas nécessairement les envois et les paiements. Un export de colis peut omettre les relations ou les documents nécessaires à une reprise.

Établissez la liste des éléments et leur emplacement avec le prestataire. Les accès au domaine, au serveur et aux services tiers font également partie de la continuité. Ils doivent rester détenus et documentés par les personnes autorisées, sans être publiés dans une archive accessible à tous.

Définir la fréquence selon le besoin

La fréquence des copies dépend de la perte de données acceptable et du rythme des opérations. Une activité qui évolue pendant toute la journée ne peut pas choisir son dispositif uniquement par habitude. Définissez ce que l'équipe doit pouvoir reprendre et dans quel délai.

La durée de conservation doit tenir compte de vos besoins et obligations. Ne gardez pas toutes les copies indéfiniment sans politique d'accès. Faites préciser ce qui est inclus dans l'offre d'hébergement et qui contrôle que les sauvegardes se produisent réellement.

Séparer les copies et les accès

Une sauvegarde stockée au même endroit que l'application peut être touchée par le même incident. Étudiez une copie séparée et les contrôles d'accès correspondants. La séparation doit être vérifiée techniquement plutôt que déduite du nom d'un répertoire.

Les archives contiennent souvent des données sensibles. Limitez les personnes qui peuvent les télécharger et évitez les répertoires publics. Les modalités de chiffrement, de stockage et de rotation sont à définir avec l'équipe technique selon les besoins. Une sauvegarde protège la continuité seulement si elle reste lisible et accessible aux bonnes personnes.

Tester la restauration dans un environnement distinct

Une copie annoncée comme réussie n'est pas une preuve de reprise. Préparez un test de restauration sur une instance séparée, avec les précautions nécessaires pour les données et les accès. Vérifiez les dossiers, les documents et les liens utiles.

Le test ne doit pas envoyer des messages réels ou déclencher des actions partenaires par erreur. Faites isoler les intégrations et les tâches automatiques. Documentez les étapes, la durée observée et les éléments manquants. Cette preuve est plus utile qu'une simple capture de la liste des archives.

Préparer la décision en cas d’incident

Définissez qui décide de la reprise et comment l'équipe est informée. Pendant une interruption, les opérations manuelles éventuelles doivent conserver des références et être rapprochées au retour. Une reprise sans contrôle peut recréer des doublons ou perdre les événements effectués après la dernière copie.

Après intervention, vérifiez les comptes, les intégrations et les dossiers récents. Conservez un bilan de l'incident et corrigez la procédure. Le dispositif doit être réévalué après une modification importante du logiciel ou de l'hébergement.

Contrôler les sauvegardes sans exposer les données

Le responsable doit savoir si la copie s'est produite, sur quel périmètre et avec quel résultat. Il n'a pas nécessairement besoin de télécharger les archives pour chaque contrôle. Définissez une information de suivi compréhensible et un traitement des échecs avec la personne technique.

Les journaux peuvent eux-mêmes contenir des détails sensibles. Partagez uniquement ce qui est nécessaire pour comprendre l'incident. Une copie qui existe mais reste inaccessible à toute personne autorisée n'est pas exploitable au moment de la reprise. À l'inverse, une archive accessible publiquement expose les données. Le dispositif doit équilibrer disponibilité de la reprise et restriction des accès.

Préparer le rapprochement après restauration

Après reprise, les opérations effectuées depuis la dernière copie doivent être identifiées. Les éventuelles listes manuelles, les documents et les échanges partenaires peuvent contenir des événements absents du système restauré. Une réintroduction non contrôlée risque de créer des doublons ou des montants incohérents.

Choisissez un responsable du rapprochement et une date de référence. Vérifiez les dossiers ouverts et les paiements avant de reprendre un traitement automatique général. Les clés et les connexions doivent être contrôlées selon l'incident. Le bilan doit expliquer ce qui a été récupéré, ce qui reste à vérifier et les améliorations du dispositif. La restauration est donc un parcours métier autant qu'une opération technique.

Préparer une ouverture maîtrisée

L'ouverture doit être fondée sur un périmètre et des résultats observables. Choisissez les utilisateurs, les opérations et les supports nécessaires au démarrage. Préparez des références fictives et un responsable de la validation. Une liste d'actions cochées n'est utile que si chacun comprend le résultat attendu. Les points non vérifiés restent visibles et les anomalies sont classées selon leur impact sur les données, les accès et les paiements.

Contrôlez les cas habituels et les exceptions. L'équipe doit pouvoir créer, retrouver et poursuivre un dossier, puis signaler une difficulté avec les informations utiles. Les comptes et les coordonnées doivent être vérifiés avant d'accueillir de vrais utilisateurs. Les données de démonstration doivent rester séparées et les actions automatiques testées sans contacter de personnes réelles par erreur. La procédure doit couvrir les supports employés, notamment le téléphone sur le terrain.

Préparez la continuité : sauvegardes, reprise et contact d'assistance. Définissez ce qui peut être fait pendant une interruption et comment ces opérations seront rapprochées ensuite. La personne qui décide de reprendre doit connaître les dossiers et les montants à contrôler. Une copie technique ne suffit pas sans compréhension des événements métier. Les accès temporaires et les comptes inutiles doivent également être revus selon le processus retenu.

Une première période limitée permet d'observer l'usage réel et de corriger les consignes. Conservez les décisions et distinguez une demande nouvelle d'une anomalie sur le périmètre convenu. Les prestations annoncées par Maroc Livraison sont à préciser dans votre devis et à valider dans la version installée. La préparation vise un fonctionnement compréhensible et reproductible ; elle ne peut pas garantir qu'aucune question ou interruption ne se produira après le lancement.

À vérifier avant de valider

• Relier chaque contrôle au périmètre convenu et à un résultat observable sur des données fictives ou correctement protégées.
• Faire exécuter les scénarios par les utilisateurs concernés puis documenter les difficultés et les corrections nécessaires.
• Vérifier les accès, la continuité et les contacts d’assistance avant de décider d’un pilote et de son suivi.

Questions fréquentes

Le code source constitue-t-il une sauvegarde complète ?

Non. Les données, les documents et les paramètres nécessaires à la reprise doivent être couverts.

Faut-il tester en production ?

Préférez un environnement distinct et isolé. Une restauration d'essai ne doit pas remplacer les données réelles.