1. Catastrophes naturelles (ex. : panne de centre de données, catastrophe régionale) : Si une catastrophe naturelle (inondation, tremblement de terre, incendie) affecte le centre de données hébergeant nos serveurs DigitalOcean (ou si une panne généralisée du cloud survient dans cette région), HGA exécutera son plan de reprise d’activité (PRA) afin de relocaliser ou de rétablir les opérations vers un emplacement alternatif [18] . DigitalOcean étant présent dans plusieurs régions, nous sommes en mesure de redéployer la plateforme vers une autre région si la région principale est indisponible. Procédure : – L’administrateur système communiquera avec DigitalOcean pour confirmer l’étendue de la panne et sa durée prévue. – Si la panne risque de dépasser notre objectif de temps de reprise (4 heures), l’administrateur système lancera une restauration à partir de sauvegardes situées dans une autre région ou un autre cloud. À l’aide de l’infrastructure en tant que code et d’images enregistrées, de nouvelles instances Droplet seront lancées dans une région opérationnelle et les dernières sauvegardes y seront restaurées. – Basculement DNS : Mise à jour des enregistrements DNS (ou utilisation d’un service DNS de basculement) pour rediriger les utilisateurs vers la nouvelle instance dès qu’elle sera prête. Notre durée de vie (TTL) DNS est relativement basse (par exemple, 5 minutes) afin de permettre une propagation rapide des modifications. – Vérifiez que la plateforme dans la nouvelle région fonctionne correctement, puis informez les parties que les services ont été restaurés (avec des performances éventuellement légèrement réduites si la région est plus éloignée pour certains utilisateurs – la continuité de service étant toutefois assurée). – Une fois la région/le centre de données d’origine restauré, évaluéz s’il convient d’y revenir ou de continuer dans la nouvelle région. L’architecture future pourrait envisager une déploiement multirégional actif-actif ou actif-passif afin de garantir une transition transparente, conformément aux meilleures pratiques du secteur en matière de résilience du cloud [19] [20] . Pour l’instant, il s’agit d’une transition manuelle, mais préparée. – Les catastrophes naturelles pourraient également affecter les bureaux ou le personnel de HGA. Bien que cela dépasse le cadre de cette plateforme numérique, il est à noter que si le personnel clé est indisponible, le personnel de remplacement est formé pour prendre en charge les tâches critiques de continuité d’activité et de reprise après sinistre (BCDR). De plus, si une catastrophe affecte l’Internet local, le personnel clé peut travailler à distance depuis des lieux sûrs pour mener à bien la reprise.
   
   
2. Cyberattaques (ex. : piratage, ransomware, DDoS) : En cas d’incident de cybersécurité ciblant la plateforme : – Fuite de données/Piratage : Si un accès non autorisé ou une fuite de données est détectée (via les journaux ou une anomalie), l’administrateur système prendra immédiatement des mesures de confinement, par exemple en désactivant les comptes utilisateurs ou les identifiants d’administrateur concernés, en révoquant les clés API volées ou en mettant temporairement le système hors ligne afin d’empêcher exfiltration de données supplémentaires. Une enquête forensique sera menée (conservation des journaux, recours éventuel à un consultant en sécurité). Dans l’intervalle, la priorité sera donnée au rétablissement de la sécurité : correction des vulnérabilités exploitées (ex. : application des correctifs de sécurité si une faille non corrigée a été utilisée), modification de tous les mots de passe/clés compromis et restauration des composants altérés ou compromis à partir de sauvegardes saines. Avant la remise en service complet du système, il convient de s’assurer que la menace est éradiquée (suppression des logiciels malveillants, fermeture des portes dérobées). La communication avec les utilisateurs sera assurée si nécessaire (en cas de fuite de données personnelles, respect des lois et politiques de notification des violations de données, en coordination avec l’équipe juridique/de direction de HGA). Après un incident, renforcez les mesures de sécurité (par exemple, règles de pare-feu plus strictes, authentification à deux facteurs, surveillance accrue) en tirant les leçons de l’expérience. – Ransomware/Malware : Si un ransomware chiffre des données ou qu’un malware corrompt les systèmes, l’isolation est cruciale : déconnectez les systèmes infectés. Ne payez pas la rançon  ; fiez-vous plutôt aux sauvegardes. Effacez le serveur ou le stockage affecté, réinstallez-le à partir d’images système propres, puis restaurez les données à partir de la dernière sauvegarde exempte de malware. Nous garantissons la disponibilité des sauvegardes hors ligne ou externalisées afin qu’elles ne soient pas infectées par le ransomware (les sauvegardes stockées sur AWS S3 sont logiquement séparées et versionnées). Une fois la restauration terminée, vérifiez l’absence de malware (effectuez des analyses antivirus/malware). Analysez également le point d’entrée du ransomware (phishing ? RDP ? etc.) et corrigez-le immédiatement. – Attaque DDoS (déni de service distribué) :Si la plateforme est la cible d’une attaque DDoS provoquant un ralentissement ou une interruption de service, activez nos mesures de protection DDoS. HGA utilise Cloudflare (ou un réseau de diffusion de contenu similaire) au sein de la plateforme pour absorber et filtrer le trafic indésirable en périphérie du réseau, si cette configuration est activée. Si ce n’est pas déjà le cas, l’administrateur système collaborera avec DigitalOcean pour appliquer une limitation de débit ou augmenter temporairement les ressources afin de gérer la charge. Communiquer avec l’équipe de lutte contre les abus du FAI ou du fournisseur de cloud peut aider à tracer et à atténuer l’attaque. La priorité est de rétablir l’accès normal pour les utilisateurs légitimes, éventuellement en mettant en place une règle de blocage d’adresse IP ou un système de contrôle d’accès (captcha) pour le trafic suspect. Une fois l’attaque terminée immédiatement, envisagez des solutions à long terme (service de nettoyage du trafic, de la capacité du réseau, etc.). – Exploitation d’une vulnérabilité critique (zéro-day) :
   
   Si une faille de sécurité globale est annoncée (par exemple, une vulnérabilité critique zero-day affectant notre infrastructure logicielle), l’administrateur système la considère comme une menace imminente. Même en l’absence d’attaque, il convient d’appliquer les correctifs d’urgence ou les solutions de contournement recommandées par les fournisseurs ou la communauté de la sécurité. Dans certains cas, une brève interruption de service pour l’application des correctifs est préférable à une situation de vulnérabilité persistante. Cette approche proactive permet d’éviter une catastrophe.

En cas de cyberattaque, une communication étroite avec le responsable du développement commercial est effectuée afin de gérer avec discrétion les communications externes aux clients (par exemple, informer les utilisateurs d’une panne sans susciter d’inquiétude excessive et fournir ultérieurement des rapports d’incident si nécessaire). Un conseiller juridique peut être consulté si l’incident a des implications réglementaires (comme la déclaration d’une violation de données).

3. Pannes matérielles ou logicielles : Toutes les interruptions de service ne sont pas dues à des catastrophes ou à des attaques ; Une simple panne matérielle ou un bug logiciel peut également entraîner une indisponibilité. Notre approche : – Panne matérielle du serveur : (Dans le contexte du cloud, il peut s’agir d’une panne de l’hôte sous-jacent d’un Droplet). L’infrastructure de DigitalOcean gère généralement les pannes d’hôte par migration des Droplets. Toutefois, si notre VM devient indisponible, le gestionnaire système fournit rapidement un serveur de remplacement (nous conservons des scripts de déploiement automatisés et des sauvegardes de configuration à cet effet). À l’aide de la dernière sauvegarde ou d’une image snapshot, le nouveau serveur peut être rapidement mis en service et restauré à son dernier état fonctionnel connu. Comme il s’agit d’une « restauration sur un nouveau matériel », elle est couverte par nos procédures de restauration de sauvegarde. Nous envisageons également d’ajouter des configurations de haute disponibilité pour les composants critiques (par exemple, une instance de base de données secondaire qui peut prendre le relais en cas de panne de l’instance principale). Dans la configuration actuelle, le basculement est manuel : le RTO de 4 heures tient compte du temps nécessaire à la mise en service et à la restauration sur le nouveau matériel. – Défaillance logicielle/applicative (bug ou plantage) : Si le déploiement d’un nouveau code provoque un plantage ou un dysfonctionnement de la plateforme, la première étape consiste à revenir à la version stable précédente. Notre système de gestion de versions et nos pipelines CI/CD permettent de redéployer rapidement une version antérieure. L’équipe de développement sera alertée (si elle n’a pas déjà découvert le problème) et procédera à un correctif immédiat ou à une restauration. Si la plateforme est indisponible en raison de ce problème, une notification d’indisponibilité pourra être publiée. Toutefois, comme ce type d’incident est généralement sous notre contrôle, nous prévoyons de le résoudre dans les délais impartis. Si un bug critique dans un logiciel tiers (par exemple, le moteur de base de données) provoque un plantage, nous suivrons les recommandations du fournisseur, en volontairement des correctifs ou en migrant vers une version stable. – Plantage ou erreurs de base de données :Si le logiciel de base de données plante en raison d’erreurs internes (et non d’une corruption de données), tentez de redémarrer le service. Analysez les journaux d’erreurs ; s’il s’agit d’un problème connu (comme une limite de ressources atteinte), allouez davantage de ressources ou optimisez la configuration, puis redémarrez. Si la base de données ne redémarre pas correctement, considérez-la comme corrompue, puis procédez à une restauration sur une nouvelle instance (après avoir pris une sauvegarde de l’état actuel à des fins d’analyse forensique). – Problèmes de réseau ou de connectivité :
   Si le problème est lié au réseau (impossibilité d’accéder au serveur suite à une panne ou une erreur de configuration), l’administrateur système vérifie l’état du réseau HGA (le cas échéant) et celui du réseau DigitalOcean. Bien souvent, les problèmes de routage se résolvent rapidement. Dans le cas contraire, il peut être nécessaire de déplacer le serveur vers un autre réseau ou d’utiliser un VPN de secours. Par exemple, si une panne de connexion Internet empêche les utilisateurs d’accéder au cloud, ils peuvent se connecter à une source Internet de secours ou utiliser les réseaux cellulaires. Si la plateforme est multi-niveaux et que le réseau interne est défaillant (par exemple, le serveur d’applications ne peut pas accéder à la base de données à cause du pare-feu), le problème est résolu en reconfigurant les règles réseau ou en basculant vers un chemin réseau de secours (certaines déployées DigitalOcean autorisent un réseau privé entre les composants ; assurez-vous qu’il est opérationnel, etc.).
4. Corruption ou perte de données : En cas de corruption de données (par exemple, suite à une erreur logicielle, un problème de stockage ou une suppression accidentelle), l’objectif principal est de préserver l’intégrité des données et de récupérer les données perdues  : – L’administrateur système arrête d’abord tous les processus susceptibles de continuer à altérer les données (afin d’éviter la propagation de la corruption). Par exemple, si un processus automatisé écrit des données erronées (par exemple, un bogue écrivant des entrées incorrectes), il faut l’interrompre. – Il faut identifier l’étendue de la corruption : quels jeux de données ou tables sont affectés et à quel moment la corruption a probablement commencé. C’est là que disposer de plusieurs points de sauvegarde s’avère précieux. L’administrateur système peut restaurer une sauvegarde dans un environnement distinct afin de comparer les données et de déterminer la cause du problème. – Une fois l’étendue de la corruption connue, il faut définir une stratégie de récupération : il peut s’agir d’une restauration complète à partir de la dernière sauvegarde valide connue (entraînant la perte des modifications effectuées depuis, ce qui correspond à la tolérance du RPO) ou d’une réparation ciblée si possible. Par exemple, si une table est corrompue mais que les autres sont intactes, on peut restaurer cette table à partir d’une sauvegarde plutôt que la base de données entière. Cela réduit la perte de données. – Après la restauration, il faut réconcilier les données manquantes. À l’aide des journaux d’application ou des saisies de données par les utilisateurs, essayez de reprendre ou de récupérer les transactions effectuées après la sauvegarde. Dans certains cas, si seulement quelques transactions sont perdues, le développeur métier pourra contacter les utilisateurs concernés pour les informateurs et leur demander de ressaisir manuellement les données ou de les soumettre à nouveau si possible. Si la perte de données est plus importante, une communication plus large pourrait être nécessaire (par exemple : « Les transactions effectuées entre 8 h et 10 h ont été perdues et doivent être refaites »). – À l’avenir, mettre en œuvre des mesures pour détecter rapidement toute corruption de données. Cela peut inclure l’activation des sommes de contrôle de la base de données, l’exécution de validations de données régulières et la vérification que notre système de surveillance peut signaler les anomalies. Si la corruption est due à un bogue logiciel, corrigez-le et supprime éventuellement des contrôles au niveau de l’application pour empêcher de telles opérations de données erronées.
   
   

Dans tous ces scénarios, la continuité des opérations demeure une priorité absolue : le responsable du développement commercial et les autres membres de l’équipe mettront en œuvre les solutions manuelles ou les procédures alternatives nécessaires pour assurer la continuité de l’activité. Par exemple, en cas d’indisponibilité de la plateforme suite à un sinistre, le personnel peut utiliser un modèle Excel préétabli pour consigner les interactions et les transactions clients, puis les importer ultérieurement. Si les paiements Stripe sont temporairement indisponibles, HGA peut enregistrer les paiements en attente et informer les clients que les paiements seront traités dès le rétablissement des systèmes (ou proposer un autre moyen de paiement en cas d’indisponibilité prolongée). L’objectif est que HGA puisse continuer à fournir des services essentiels, ou au moins une communication claire avec ses clients, même en cas de dysfonctionnement de sa plateforme numérique habituelle.