La fiche rassemble l’identité de l’application, ses objectifs de reprise, sa protection, ses dépendances et les processus BIA qui s’appuient sur elle. Les blocs sous l’identité sont repliés à l’ouverture : un clic sur le titre les déplie.

Bandeau

• Retour : liste des applications du projet.
• Imprimer : ouvre la fiche imprimable. La case Inclure dans l’impression, dans le bloc Tests et Exercices, décide si ce bloc figure sur l’impression. Le choix est mémorisé dans le navigateur.
• Analyse IA : lance une analyse de résilience. Une confirmation rappelle que le nom, le type, les responsables, les dépendances, les sauvegardes, les processus BIA, les localisations et les actifs sont transmis à un service d’IA externe.
• MAP : carte des liens de l’application.
• Architecture : schéma technique. Ce bouton n’apparaît que si l’option d’architecture est activée sur la plateforme.

Identité

• Nom de l’application et Code applicatif. Le code alimente la colonne Code de la liste.
• Société : société de rattachement. 
• Emplacement, Hôte et Type : les trois colonnes correspondantes de la liste.
• Responsable de l’application (RA) : responsable technique ou applicatif.
• Serveur hébergeant l’application : nom du ou des serveurs. Ce texte sert aussi à rapprocher l’application des politiques de sauvegarde.
• Associer des actifs existants : recherche dans les actifs de la société, puis pastilles. Retirer une pastille retire le lien, pas l’actif du référentiel Gestion.
• Information : description libre, avec mise en forme. Le bouton IA propose un texte à partir de la fiche. On choisit le moteur (DeepSeek ou Mistral), on relit le résultat, puis on l’insère dans le champ. Rien n’est enregistré tant que la fiche n’est pas enregistrée.
• Note : commentaire interne.

Gestion des applications

Versions, documentation et contrat :

• Version de référence et Version déployée.
• Lien vers la documentation.
• Architecte référent et Responsable métier.
• Technologie, Éditeur, Intégrateur.
• Licence requise, Contrat et Coût licence (€).

Localisation (Datacenter)

Grille des salles des datacenters actifs du projet. Chaque case coche indique que l’application est présente dans cette salle. Les salles se créent depuis le bouton DC du tableau de bord.

Tests et exercices

Trois lignes, chacune avec un objectif et des mesures :

• Test de reprise après sinistre (DR Test) : redémarrage sur l’infrastructure de secours et conformité des données.
• Test de continuité (BC Test) : usage en mode dégradé.
• Test d’injectivité de défauts : tolérance aux pannes injectées.

Si l’objectif est vide, un texte d’exemple est proposé. Il est enregistré tel quel si on le laisse.

Temps de reprise

Deux couples d’indicateurs.

Un tiret sur le DMIA ou le PDMA signifie qu’aucun BIA validé ne fournit encore de valeur.

Écart (Temps) compare le DMIE au DMIA. Écart (Données) compare le PDME au PDMA.

• Négatif ou nul, en vert : l’estimé est meilleur ou égal à l’objectif.
• Positif, en rouge : l’estimé dépasse l’objectif. La reprise serait plus lente, ou la perte de données plus grande, que ce que le métier accepte.

Risque / Actions accueille la décision : accepter l’écart, ou l’action qui le réduit.

Synthèse application critique

Reprend sur une ligne le nom, le DMIA, le DMIE, le PDMA, le PDME, les deux écarts et le texte Risque / Actions. Les couleurs des écarts sont les mêmes que dans Temps de reprise.

Sauvegarde

Ce bloc n’apparaît que si une politique de rétention a été calculée pour une activité BIA liée à cette application. Il affiche les versions journalières, hebdomadaires, mensuelles et annuelles, le nombre de points de restauration, le chiffrement, la localisation et la justification. Le tableau détaille ensuite le cycle fils, père, grand-père, ancêtre, uniquement pour les durées réellement prévues. Voir détails ouvre la rétention de l’activité BIA.

Protection

Quatre cases décrivent l’hébergement : machine virtuelle, serveur autonome, cluster actif/actif, cluster actif/passif. Si la case VM est cochée, trois questions supplémentaires apparaissent : haute disponibilité (HA), tolérance aux pannes (FT) et réplication vers un autre site (DR).

Le bloc Règle du 3-2-1-1-0 porte les contrôles de sauvegarde :

• 3 copies : production plus deux sauvegardes ;
• 2 supports : au moins deux types de médias ;
• 1 hors-site : au moins une copie hors du site de production. Si cette case est cochée, une question complémentaire demande si l’application peut être restaurée et démarrée sur le site qui détient cette copie ;
• WORM et Air-Gap : les deux doivent être cochés pour que la copie soit considérée immuable ;
• MFA sur la console de sauvegarde ;
• Indépendance AD : comptes de sauvegarde séparés de l’annuaire principal ;
• Segmentation : serveur de sauvegarde dans un VLAN d’administration isolé ;
• Fréquence des tests de restauration complète : Mensuel, Trimestriel, Semestriel ou Annuel ;
• 0 erreur : dernier test validé sans erreur ;
• Scan anti-malware des sauvegardes avant archivage ;
• Supervision : alerte dès l’échec d’une tâche de sauvegarde.

Sur un projet CARE-D2 Résilience Technique, un bandeau résume le résultat.

• Bandeau vert : sauvegarde conforme.
• Bandeau rouge : au moins un contrôle manque.

La fréquence Annuel ne suffit pas. La conformité exige Mensuel, Trimestriel ou Semestriel, plus toutes les cases ci-dessus, WORM et Air-Gap compris. Ce résultat alimente la colonne Conforme de la liste et la bordure rouge de la tuile Applications. Il est recalculé à l’enregistrement.

Dépendances

Applications du même projet dont celle-ci a besoin pour fonctionner. La recherche ajoute des pastilles. Une application ne peut pas dépendre d’elle-même.

Le tableau Analyse des dépendances reprend le DMIE et le PDME de chaque application liée.

• En rouge : la dépendance a une durée plus longue. La recommandation indique la durée à retenir, car l’application ne peut pas reprendre plus vite que ce dont elle dépend.
• En vert : la durée de la dépendance est plus courte ou égale. Elle est compatible.
• Sans durée des deux côtés : pas de données à comparer.

Si l’application en cours n’a ni DMIE ni PDME, l’écran propose la durée la plus longue constatée parmi ses dépendances.

Dépendances architecturales

Cases à cocher issues du référentiel d’infrastructure, regroupées lorsqu’elles existent : Réseau, IAM, Hébergement, Bases de données, Stockage, DevOps. Elles décrivent les briques techniques dont l’application dépend, en complément des autres applications. Ces briques techniques sont modifiables et configurables par société.

Processus

Liste des activités BIA qui déclarent cette application, avec le processus, l’activité, le DMIA et le PDMA. Le nom du processus ouvre sa fiche BIA.

Pour un processus validé, le DMIE et le PDME de l’application sont comparés à ces objectifs :

• OK : le délai estimé tient dans l’objectif du processus.
• KO : le délai estimé dépasse l’objectif.
• Un tiret : le processus n’est pas validé, ou l’une des deux valeurs manque.

S’il n’existe aucun lien, le bloc indique qu’aucun processus BIA n’utilise cette application.

Référentiel documentaire

Visible seulement lorsque des documents du référentiel Gestion sont rattachés à l’application. Le tableau donne le titre, le nom du fichier et Ouvrir, qui affiche le document dans un nouvel onglet.