Phase 1D · fiabilité avant activation

Une sauvegarde n’est utile qu’après une restauration prouvée.

KIIRAAY distingue disponibilité, sauvegarde, restauration, reprise et incident. Le plan public montre les contrôles sans révéler de chemin serveur, compte, secret, contact d’astreinte ou détail exploitable.

Actifhealth public minimisé
Non prouvérestauration propre
Non nomméastreinte et commandement
Bloquéactivation sensible

Objectifs provisoires

Une cible de planification n’est pas une promesse.

Pour le site public et les scénarios synthétiques seulement, le blueprint propose provisoirement une perte maximale de 24 heures et un retour en 4 heures. Ces valeurs ne sont ni approuvées ni mesurées. La future plateforme transactionnelle exige un objectif distinct.

RPO de planification24 h

Données publiques et synthétiques uniquement · non approuvé · non mesuré.

RTO de planification4 h

Retour cible du service public · non approuvé · non mesuré.

Transactionnel futurÀ définir

Aucun objectif réel n’est activé avant budget, architecture, propriétaires et exercice.

Cycle d’incident

De la détection au retour vérifié.

Chaque étape exigera un owner, un horodatage fiable, une décision traçable et une communication proportionnée.

  1. 01
    Détecter

    Mesurer un signal vérifiable sans journaliser de contenu personnel ou de secret.

  2. 02
    Déclarer

    Qualifier l’incident, nommer le commandement approuvé et créer une référence de preuve.

  3. 03
    Préserver

    Conserver les éléments utiles avec intégrité, accès limité et chaîne de garde.

  4. 04
    Contenir

    Fermer une fonction, révoquer un accès ou isoler un composant sans élargir l’exposition.

  5. 05
    Restaurer

    Revenir depuis un artefact et une sauvegarde contrôlés dans un environnement propre.

  6. 06
    Vérifier

    Comparer comptes, empreintes, règles et flags avant une réouverture progressive.

  7. 07
    Apprendre

    Documenter la cause, les décisions, l’impact, la correction et le suivi sans blâme.

Classification

Quatre niveaux, aucun commandant inventé.

SEV-1

Critique

Exposition de données, compromission, intégrité électorale ou indisponibilité nationale critique.

Brouillon · owner non nommé
SEV-2

Majeur

Fonction critique défaillante, abus limité ou perte d’intégrité contenue.

Brouillon · owner non nommé
SEV-3

Dégradation

Service ralenti ou partiellement indisponible avec alternative sûre.

Brouillon · owner non nommé
SEV-4

Anomalie

Défaut mineur sans impact sensible immédiat, à suivre et corriger.

Brouillon · owner non nommé

Preuve de restauration

Le test repart d’un environnement propre.

La restauration future devra reconstruire l’application, la base, les contrôles et les clés selon une procédure séparée. Elle ne pourra jamais rouvrir automatiquement une adhésion, un message, une carte, une identité, une voix ou une session.

01Inventorier

Artefact, configuration, migration, base, objet, clé et dépendance nécessaires.

02Vérifier

Empreinte, chiffrement, date, couverture, expiration et succès des jobs.

03Restaurer

Environnement isolé, secrets tournés et accès minimaux avant toute donnée.

04Réconcilier

Comptages, versions, retraits, révocations, audit et flags fermés.

05Mesurer

Perte réelle, temps réel, erreurs, décisions et écarts par rapport aux objectifs.

06Nettoyer

Supprimer l’environnement de test et conserver uniquement la preuve approuvée.

Douze contrôles

Onze preuves restent à produire.

La sonde publique existe. Tous les autres éléments restent bloquants jusqu’à test, attribution et approbation.

État public sûr

Le détail opérationnel reste privé.

Le public peut vérifier l’état général, les limites et les gates. Les contacts, chemins, comptes, sauvegardes, clés, preuves d’incident et instructions exécutables resteront dans un registre protégé.

Lire le health public →Lire l’état de préparation JSON →Voir les protections →