Doc fonctionnelle : décrit le quoi et le pourquoi (point de vue utilisateur / chef de projet).
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.
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.
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 »).
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.
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.
../../.claude/technical-docs/platform/backups.md