---
title: "Sauvegardes du SI"
module: platform
type: functional
status: active
updated: 2026-10-02
---

# Sauvegardes du SI

> Doc fonctionnelle : décrit le **quoi** et le **pourquoi** (point de vue utilisateur / chef de projet).

## À quoi ça sert

Une sauvegarde devient un objet à part entière du système d'information, et non plus deux champs
texte (RPO / RTO) de la fiche application. Une même sauvegarde couvre plusieurs applications,
matériels ou machines virtuelles, et l'écran *Informatique > Sécurité > Sauvegardes* donne la vue
d'ensemble : ce qui est sauvegardé, comment, où, et si la restauration a été testée.

## Comment ça marche (côté utilisateur)

### La fiche Sauvegarde

- **Identification** : nom, type de données (bases de données, fichiers, VM, système, messagerie,
  SaaS…), criticité notée de 1 à 5 étoiles — comme la criticité d'une application.
- **Politique** : solution (Veeam, Acronis, snapshot NAS…), type (complète, incrémentale…),
  fréquence, rétention, RPO et RTO en heures. Le RPO (perte de données maximale admissible) et
  le RTO (durée maximale d'interruption admissible) sont expliqués sous chaque champ et en
  infobulle, sur le formulaire comme sur la carte de la fiche.
- **Localisation des copies** : localisation primaire et secondaire (sur site, distante, cloud,
  hors ligne) avec leur précision, et la question « Respect de la règle 3-2-1 » (3 copies, sur
  2 supports différents, dont 1 hors site), à laquelle on répond Oui ou Non, expliquée sous le
  champ et en infobulle.
- **Suivi** : dernière sauvegarde réussie, dernier test de restauration.
- **Contacts et notes** : contact technique, contact métier, notes.

Sont **obligatoires** : le nom, le type de données, la solution, le type de sauvegarde, la
fréquence, la localisation primaire, le contact technique — ce sans quoi une sauvegarde ne
peut être ni restaurée ni suivie — et la réponse Oui / Non à la règle 3-2-1 : « Non » est une
réponse, seule l'absence de réponse rend la fiche incomplète. Les sauvegardes enregistrées
avant que la question devienne obligatoire avec la case décochée sont passées à « non
renseignée » : une case décochée ne disait pas si la règle était respectée ou jamais vérifiée.

Une fiche incomplète (créée rapidement, récupérée d'un modèle, reprise des anciens champs)
affiche un bandeau « Fiche incomplète » ; son prochain enregistrement réclame les champs
manquants. Les champs que le compte a lui-même rendus obligatoires comptent aussi.

La carte d'identité, à gauche de la fiche, résume l'état : criticité, test de restauration
(rouge si jamais testé, orange au-delà de 12 mois, vert sinon), règle 3-2-1, RPO / RTO. La
**vue synthétique** (bouton « Aperçu ») présente la même fiche en lecture, avec la liste des
éléments couverts.

### Rattacher une sauvegarde

- Depuis la fiche Sauvegarde, onglets **Applications**, **Matériels** et **Machines virtuelles**.
- Depuis la fiche d'une application, d'un matériel ou d'une VM, onglet **Sauvegardes** : rattacher
  une sauvegarde existante, ou en créer une par son seul nom (le créateur en devient le contact
  technique ; le reste se complète sur la fiche).
- Seules les applications **déployées** sur le compte (instance en production) peuvent recevoir
  une sauvegarde.

### L'écran Sécurité > Sauvegardes

Toutes les sauvegardes du compte, avec leur couverture (applications, matériels, VM) et des
filtres : test de restauration (jamais / plus de 12 mois / récent), règle 3-2-1 (respectée /
non respectée / non renseignée), sauvegardes rattachées à aucun élément, criticité, type de
données (icône par type), solution. Un bandeau
signale les sauvegardes jamais ou anciennement testées, et celles qui ne couvrent rien. Une icône
d'avertissement suit le nom d'une sauvegarde à laquelle manque un champ obligatoire ; son
infobulle liste les champs à compléter (même règle que le bandeau « Fiche incomplète »).

### Modèles ISI-GROUPE

ISI-GROUPE saisit une sauvegarde dans son propre compte et la propose comme **modèle** : une
politique de sauvegarde type, qui ne dépend d'aucune application. Un client qui lui a délégué
l'accès la récupère depuis *Informatique > Sécurité > Sauvegardes*, bouton « Modèles
ISI-GROUPE ». Il obtient une copie liée, rattachée à rien, et arrive sur sa fiche pour la
rattacher à **ses** applications, matériels et machines virtuelles. Un même modèle peut être
récupéré plusieurs fois (une copie par usage) ; la liste indique « Déjà récupéré » le cas échéant.
ISI-GROUPE peut ensuite repousser la politique du modèle (type de données générique, solution,
type, fréquence, rétention, localisations, RPO / RTO, règle 3-2-1) vers toutes les copies. Les
rattachements, dates de suivi, contacts, notes et la criticité restent ceux du client. Si la délégation du client n'est plus active, sa copie n'est plus mise à jour (elle
reprend si la délégation est rétablie). Le client peut à tout moment ne plus suivre le modèle.

Sur la fiche du modèle, ISI-GROUPE voit **quels clients l'ont récupéré** : compte client (et
entité si la copie est portée par une entité fille), date de récupération, et un badge « À jour »
ou « Différente du modèle » (le modèle a changé depuis la dernière mise à jour des copies, ou le
client a modifié la sienne). Les copies des clients dont la délégation n'est plus active sont
seulement comptées, sans nom. La liste reste visible quand le modèle n'est plus proposé : les
copies existent toujours chez les clients.

### Reprise des anciens champs

Les champs RPO / RTO de la fiche application ont été repris : chaque fiche qui en renseignait un
est devenue une sauvegarde rattachée à l'application, durées converties en heures (« 48h »,
« 6j », « 2 semaines »…) et saisie d'origine conservée dans les notes. Les champs ont ensuite été
retirés de la fiche application.

## Règles d'accès

- Module **Informatique** souscrit, et droits du profil sur la fiche Sauvegarde (lecture pour
  consulter, création / modification / suppression selon le profil).
- Rattacher ou détacher un élément exige aussi le droit de modifier la fiche de cet élément,
  quel que soit le côté d'où l'on agit.
- L'onglet Applications d'une sauvegarde exige l'accès au domaine Applications.
- Une sauvegarde n'est visible que du compte qui la détient. Une sauvegarde archivée reste
  consultable, en lecture seule, et se restaure depuis sa fiche ou le centre des archives — dans
  les deux cas avec les droits de modification et de suppression des sauvegardes : un profil en
  lecture seule ne la réactive pas.
- Proposer une sauvegarde comme modèle et repousser sa politique sont réservés à ISI-GROUPE, sur
  ses propres sauvegardes, avec le droit de modification. Récupérer un modèle demande le droit
  de création et une délégation d'accès active vers ISI-GROUPE.

## Points d'attention

- Un matériel ou une VM masqué par les restrictions de visibilité du parc n'est jamais affiché,
  mais compte : la sauvegarde qui le couvre n'est pas « rattachée à rien », et l'écran indique
  « +N masqué(s) ».
- La réponse à la règle 3-2-1 est déclarative : rien ne la vérifie, elle doit être cohérente
  avec les localisations saisies.
- La règle 3-2-1 fait partie de la politique d'un modèle : repousser un modèle dont la règle
  n'est pas renseignée remplace la réponse des clients et rend leurs copies incomplètes. Un
  modèle devrait être complet avant d'être repoussé.
- Un type de données ajouté par ISI-GROUPE pour lui-même n'est pas transmis aux copies de ses
  clients (il n'existe pas chez eux) : seuls les types génériques le sont.

## Voir aussi

- Doc technique : `../../.claude/technical-docs/platform/backups.md`