Pas de chiffre sans test de restauration

Architecture actuelle

• Une instance de calcul Scaleway exécute l’API et le worker sous deux services systemd.
• Les fichiers résident dans Scaleway Object Storage en région fr-par.
• Les comptes, métadonnées et événements d’audit résident dans PostgreSQL managé.
• Le DNS est opéré chez OVH et le certificat wildcard est renouvelé automatiquement par CertMagic.
• Aucun CDN ni seconde instance active n’absorbe une panne de l’origine.

Comportements de reprise implémentés

systemd redémarre les processus selon les unités déployées. À son démarrage, le worker traite immédiatement les publications expirées pendant son arrêt, puis reprend un passage toutes les cinq minutes. CertMagic réessaie les renouvellements TLS et le service surveille l’échéance du certificat.

Après un déploiement, le runbook vérifie depuis l’extérieur la santé de l’API, du site public et du dashboard. Ce contrôle confirme une réponse au moment du déploiement ; il ne constitue pas une surveillance continue ni une mesure de disponibilité mensuelle.

Sauvegardes de métadonnées

La base est un service PostgreSQL managé, mais le dépôt ne publie pas la configuration effective de sauvegarde, sa fréquence, sa rétention ou sa région. Le runbook exige encore d’effectuer et documenter une restauration réelle. Tant que cet exercice n’est pas daté, aucun RPO ou RTO de la base n’est annoncé.

Sauvegardes des artefacts

L’application écrit les fichiers dans l’Object Storage et ne crée pas elle-même de seconde copie, d’archive ou de réplication. Le versioning, une politique de sauvegarde fournisseur et leur comportement après suppression ne sont pas attestés dans le dépôt.

EZOU.EU est un moyen de publication temporaire, pas un système d’archivage. Le publieur doit conserver ses fichiers sources et pouvoir republier. Cette précaution s’applique aussi aux publications dites permanentes.

RPO et RTO

RPO

Non défini contractuellement. Le dépôt ne permet pas de quantifier la quantité maximale de métadonnées récupérables après incident.

RTO

Non défini contractuellement. L’instance unique, la disponibilité du fournisseur, le DNS, les clés et la restauration de base influencent le délai.

SLA

Aucun engagement de disponibilité chiffré hors contrat spécifique signé.

Risques suivis

• instance de calcul unique ;
• expiration programmée de la clé S3, sans alerte automatisée documentée dans le dépôt ;
• dépendance au renouvellement DNS-01 et aux clés OVH ;
• restauration PostgreSQL non encore exercée dans le runbook public ;
• absence de contrôle externe continu alimentant une page de statut.