Continuité d'activité
Onesurance garantit la continuité des services d'assurance critiques grâce à une infrastructure redondante, des procédures DR documentées et des tests réguliers. Notre programme de continuité d'activité est conforme DORA et adapté aux exigences du secteur de l'assurance.
Continuité d'activité en un coup d'oeil
- SLA 95% de disponibilité — Disponibilité garantie dans le cadre de la fenêtre de service
- Sauvegardes quotidiennes — Sauvegardes complètes quotidiennes avec 30 jours de rétention
- Redondance multi-AZ — Implémentation multi-zone Azure pour haute disponibilité
- Conforme DORA — Conforme aux exigences du Digital Operational Resilience Act
Stratégie de continuité
Onesurance applique une stratégie de continuité d'activité multicouche conçue pour minimiser l'impact des perturbations et garantir une reprise rapide des services.
Haute disponibilité
Notre infrastructure fonctionne sur Azure multi-zone dans la région West-Europe. Cela signifie que nos services sont répartis sur plusieurs datacenters physiquement séparés (Availability Zones). Si une zone tombe en panne, les zones restantes prennent automatiquement le relais sans interruption de service.
Stratégie de sauvegarde
- Sauvegardes complètes quotidiennes — Chaque jour, une sauvegarde complète de tous les systèmes et données critiques est réalisée
- 30 jours de rétention — Les sauvegardes sont conservées au minimum 30 jours pour une récupération point-in-time
- Sauvegardes des logs de transaction — Toutes les 10 minutes, les logs de transaction sont sauvegardés pour minimiser la perte de données
Procédures de reprise après sinistre
Toutes les procédures DR sont entièrement documentées et testées annuellement. Le plan DR couvre les scénarios de perte de données, d'interruption de service et d'incidents de sécurité.
Plateforme GRC
Onesurance utilise Eramba comme plateforme de Gouvernance, Risque et Conformité (GRC). Tous les plans de continuité d'activité, risques, contrôles et résultats de tests y sont gérés et surveillés de manière centralisée.
Plan de reprise après sinistre
Notre plan DR décrit les procédures de restauration des services après une perturbation. Le plan est testé annuellement et mis à jour en fonction des résultats des tests et de l'évolution des besoins.
Stratégie de sauvegarde (Détail)
| Type | Fréquence | Rétention | Description |
|---|---|---|---|
| Sauvegarde complète | Quotidienne | 30 jours | Sauvegarde complète de toutes les bases de données, configurations et données applicatives |
| Sauvegarde différentielle | Toutes les 24 heures | 30 jours | Modifications depuis la dernière sauvegarde complète |
| Log de transaction | Toutes les 10 minutes | 30 jours | Logs de transaction continus pour une récupération point-in-time |
Procédures de récupération
En cas de panne d'une zone de disponibilité, le trafic est automatiquement redirigé vers les zones disponibles. Azure Load Balancer détecte la panne et reroute le trafic en quelques secondes. Aucune intervention manuelle n'est nécessaire pour le basculement au niveau de la zone.
Grâce aux sauvegardes de logs de transaction toutes les 10 minutes, la base de données peut être restaurée à n'importe quel moment dans la période de rétention de 30 jours. Cela minimise la perte de données en cas de suppression accidentelle, de corruption ou d'autres incidents.
En cas d'interruption totale de service, le processus de récupération est lancé à partir de la sauvegarde la plus récente. L'Infrastructure-as-Code permet de reconstruire l'environnement complet. L'objectif est de restaurer le service complet dans les 24 heures, avec les services critiques dans les 4 heures.
Plan de communication clients
En cas de perturbation ayant un impact sur les clients, le protocole de communication suivant est appliqué :
- Première notification — Les clients sont informés dans l'heure de la perturbation et de l'impact attendu
- Mises à jour de statut — Mises à jour régulières sur l'avancement de la récupération
- Rapport post-incident — Après la récupération, les clients reçoivent un rapport complet avec la cause, l'impact et les mesures prises
Objectifs RTO & RPO
Le Recovery Time Objective (RTO) et le Recovery Point Objective (RPO) définissent nos objectifs de récupération en cas de perturbation.
Recovery Time Objective (RTO)
| Service | RTO | Description |
|---|---|---|
| Services critiques | <4 heures | Fonctionnalités de base pour les processus d'assurance, y compris la gestion des polices et le traitement des sinistres |
| Service complet | <24 heures | Toutes les fonctionnalités y compris les rapports, tableaux de bord et modules non critiques |
Recovery Point Objective (RPO)
RPO formel : <24 heures
Le RPO formel est fixé à moins de 24 heures, conformément aux accords SLA avec les clients et aux exigences DORA.
RPO effectif : ~10 minutes
Grâce aux sauvegardes de logs de transaction toutes les 10 minutes, la perte de données effective en cas d'incident est limitée à environ 10 minutes maximum.
Fenêtre de service
Fenêtre de service supportée : lundi au vendredi, 08:30 - 17:30 CET.
En dehors de la fenêtre de service, la surveillance se poursuit. Les incidents critiques (P1) sont également pris en charge en dehors des heures de bureau via le protocole d'escalade. La maintenance planifiée a lieu en dehors de la fenêtre de service, avec notification préalable aux clients.
Tests & Validation
Le plan de continuité d'activité est régulièrement testé et validé pour garantir son efficacité. Les résultats des tests sont documentés dans Eramba et conduisent à des actions d'amélioration concrètes.
Test DR annuel
Au moins une fois par an, nous réalisons un test complet de reprise après sinistre. Le processus de récupération est exécuté de bout en bout, y compris la validation client de l'environnement restauré.
Scénarios de test
Perte de données
Simulation de suppression accidentelle ou de corruption de données. Test de la récupération point-in-time et vérification de l'intégrité des données après récupération.
Interruption de service
Simulation d'une interruption complète d'un ou plusieurs services. Test des mécanismes de basculement et des procédures de récupération manuelle.
Incident de sécurité
Simulation d'un incident de sécurité ayant un impact sur la disponibilité. Test de la collaboration entre l'IRT et l'équipe DR.
Planification de capacité
- Revue trimestrielle — Chaque trimestre, la capacité de tous les systèmes est évaluée sur la base de l'utilisation actuelle et des prévisions de croissance
- Mise à l'échelle proactive — En cas de croissance prévue, la capacité est augmentée à l'avance pour éviter les goulets d'étranglement
Réponse aux pannes cloud
En cas de panne de la plateforme Azure, le protocole d'escalade est activé dans un délai de <15 minutes. L'équipe surveille le tableau de bord Azure Service Health, communique proactivement avec les clients et initie si nécessaire des procédures de basculement manuel.
Continuité du personnel
- Rôles de secours — Pour chaque fonction critique, au moins un remplaçant est désigné et formé
- Partage des connaissances — Les procédures sont documentées pour que le personnel de secours puisse agir de manière autonome
- Formation croisée — Les membres de l'équipe sont régulièrement formés à des tâches en dehors de leur rôle principal
Des questions sur la continuité d'activité ?
Notre Délégué à la Protection des Données se tient à votre disposition pour toute question relative à la sécurité, la conformité ou la confidentialité.