Négoce : sauvegardes, restauration et PRA (guide complet 2026)

Négoce : sauvegardes, restauration et PRA (guide complet 2026)

Si votre application Négoce s’arrête (panne, erreur de manipulation, incident réseau, attaque), vous avez deux problèmes à résoudre vite : remettre le service en ligne et retrouver des données cohérentes. La différence entre une sauvegarde “qu’on a” et une sauvegarde “qui sauve” tient souvent à un seul point : avoir déjà restauré en conditions réelles.

Dans ce guide, on déroule une approche simple et robuste pour :

• cadrer vos objectifs (RPO / RTO) ;
• protéger la base et les fichiers/documents ;
• automatiser, chiffrer et surveiller ;
• exécuter une restauration sans improviser ;
• préparer un plan de reprise d’activité réaliste.

Si vous cherchez une option d’hébergement managé avec backups automatiques, rétention longue et scaling, regardez la page Hébergement Négoce sur adgents.cloud.

1) Définir RPO et RTO (avant de parler d’outils)

Deux questions business déterminent tout le reste :

RPO (Recovery Point Objective) : combien de données pouvez-vous perdre ?

• Exemple : “au pire, on accepte de perdre 1 heure de saisie”.
• Conséquence : il faut des sauvegardes au moins horaires (et une stratégie de cohérence).

RTO (Recovery Time Objective) : combien de temps pouvez-vous rester à l’arrêt ?

• Exemple : “le service doit repartir en moins de 2 heures”.
• Conséquence : vous devez connaître votre temps réel de restauration (pas juste l’estimer).

Pour une PME, viser un RPO de 1h et un RTO de 2–4h est souvent un point de départ raisonnable. Si Négoce pilote la facturation, l’achat/vente, ou la préparation de commandes, vous voudrez parfois descendre plus bas.

Pour aller plus loin sur le sujet : RTO/RPO : définition, différences et rôle dans le PRA.

2) Cartographier ce qu’il faut sauvegarder (sinon vous oublierez un morceau)

Sur une application “métier” type Négoce, on retrouve presque toujours :

1. Base de données : clients, articles, tarifs, mouvements, historiques, etc.
2. Documents / fichiers : pièces jointes, PDF, exports, imports, images, etc.
3. Configuration applicative : variables d’environnement, secrets, paramètres, connecteurs.
4. Accès : comptes, rôles, journaux d’audit éventuels.

Si vous ne sauvegardez que la base, vous restaurerez une appli “vide de documents”. Si vous ne sauvegardez que les fichiers, vous restaurerez une coquille sans données métiers.

3) Stratégie de sauvegarde : simple, chiffrée, testable

La règle de base : versionning + copies multiples

Une approche très robuste (à adapter) :

• 1 copie “proche” pour restaurer vite ;
• 1 copie “hors site” pour survivre à un incident plus large ;
• 1 rétention assez longue pour remonter avant une corruption “silencieuse” (ex : suppression détectée tard).

Fréquences recommandées (point de départ)

• Base : toutes les heures (si le volume le permet), sinon toutes les 4h + quotidienne.
• Fichiers/documents : quotidienne + versionning (ou synchronisation incrémentale).

Chiffrement

• Chiffrez avant stockage ou utilisez un stockage qui chiffre côté serveur (l’idéal : les deux selon le contexte).
• Gérez la clé : sans clé, une sauvegarde chiffrée est inutilisable ; avec une clé mal stockée, c’est un risque.

4) Restaurer : la méthode opérationnelle (la partie que personne ne fait assez)

Une restauration maîtrisée suit presque toujours la même séquence :

Étape A — Isoler l’incident

• Bloquer l’accès si besoin (éviter que l’incident continue).
• Geler l’état : copie “forensic” si suspicion d’attaque.

Étape B — Choisir le point de restauration

• “Dernière sauvegarde” n’est pas toujours la bonne (ex : corruption introduite avant).
• Gardez plusieurs points : J-1, J-7, J-30 selon le risque.

Étape C — Restaurer la base

• Restaurer dans un environnement propre.
• Vérifier la cohérence : comptes, dernières écritures, totaux critiques.

Étape D — Restaurer les fichiers/documents

• Même date/période que la base, sinon incohérences (documents manquants ou en avance).

Étape E — Rejeu et contrôles

• Test fonctionnel : création/édition, génération PDF, import/export, permissions.
• Vérifier les jobs planifiés et les intégrations (emails, webhooks).

Si vous utilisez aussi des automatisations, prévoyez un “mode dégradé” documenté. Exemple : si Négoce est intégré à des workflows, vous pouvez basculer une partie sur une file d’attente temporaire via n8n sur adgents.cloud, le temps de stabiliser.

5) Tester sans risquer la prod : staging + exercices de reprise

Un test utile n’est pas un “test théorique”. Faites au minimum :

• 1 test mensuel sur un environnement de staging (restauration complète).
• 1 exercice trimestriel “de bout en bout” avec chronométrage (mesure du RTO réel).

Sur adgents.cloud, vous pouvez vous appuyer sur un environnement séparé (staging) pour valider vos restaurations avant de toucher à la production : Déployer Négoce sur adgents.cloud.

Vidéo (FR) utile pour cadrer le sujet côté dirigeant :

6) Erreurs fréquentes (et comment les éviter)

1) “On a des sauvegardes” (mais jamais restauré)

Solution : planifier des tests, les documenter, conserver les temps mesurés.

2) Sauvegarder la base mais oublier les fichiers

Solution : recenser précisément où sont stockés les documents (volumes, buckets, montages).

3) Une seule copie, au même endroit

Solution : au moins une copie hors site, plus une rétention suffisante.

4) Sauvegardes trop lourdes et lentes

Solution : incrémental, compression, rotation, et surtout dimensionner selon le RPO/RTO.

5) Accès trop larges aux sauvegardes

Solution : principe du moindre privilège, comptes dédiés, rotation des clés, logs d’accès.

7) Modèle de “runbook” de reprise (à adapter)

Voici un modèle simple que vous pouvez reprendre pour Négoce :

1. Qui décide la bascule (nom + contact)
2. Critères de déclenchement (panne, corruption, indisponibilité)
3. Objectifs RPO/RTO
4. Où se trouvent les sauvegardes (et qui y a accès)
5. Procédure restauration base
6. Procédure restauration fichiers
7. Tests de validation (fonctionnels + données)
8. Plan de communication (interne/externe)
9. Retour d’expérience : ce qui a pris du temps, ce qui a bloqué

Si vous cherchez un exemple plus “métier” (application + documents + base), l’article Backups MediaWiki : stratégie + restauration testée donne un bon cadre transposable.

8) Conclusion : une sauvegarde qui sauve, c’est une restauration répétée

Pour Négoce, le duo gagnant est :

• des sauvegardes fréquentes (dimensionnées par le RPO) ;
• une restauration testée et chronométrée (pour connaître le RTO réel) ;
• une séparation claire prod/staging ;
• du chiffrement et des accès maîtrisés.

Pour héberger Négoce avec des options orientées production (backups automatiques, rétention longue, scaling), consultez adgents.cloud — Hébergement Négoce.