Sauvegarde et reprise d’activité pour les applications métier

Disposer d’une sauvegarde ne suffit pas à garantir la reprise d’une application métier. Encore faut-il pouvoir restaurer les bonnes données, reconstruire les composants nécessaires et rendre le service utilisable. Le plan de reprise organise ces opérations ainsi que les décisions et les responsabilités associées.

La priorité n’est pas de choisir l’architecture la plus sophistiquée, mais celle qui répond aux conséquences réelles d’une interruption. Pour y parvenir, commencez par les applications critiques, fixez des objectifs mesurables et vérifiez-les en conditions de test.

Définir les objectifs à partir des besoins métier

Recensez les applications qui soutiennent les activités essentielles et évaluez les effets de leur indisponibilité. Cartographiez aussi leurs dépendances : authentification, bases de données, prestataires de paiement, interfaces et stockage documentaire. Les responsables métier et les équipes techniques doivent convenir ensemble des priorités.

Pour chaque application, définissez deux indicateurs :

• RTO, ou objectif de délai de reprise : durée maximale acceptable entre l’interruption et le rétablissement du service.
• RPO, ou objectif de point de reprise : perte de données maximale acceptable, exprimée en durée.

À titre d’exemple, un RTO de quatre heures et un RPO d’une heure signifient que l’on vise un retour du service en quatre heures au plus, avec une perte inférieure ou égale à une heure de modifications. Ce sont des objectifs, pas des garanties : la seule fréquence des sauvegardes ne prouve pas que le RPO sera respecté. Les recommandations AWS sur la continuité d’activité relient ces choix à l’analyse d’impact métier.

Sauvegarder tout ce qui permet de reconstruire

La base de données de production ne représente qu’une partie du périmètre. Pensez aussi aux fichiers déposés par les utilisateurs, au code, aux définitions d’infrastructure, à la configuration, aux certificats, aux clés de chiffrement et à la documentation des services externes. Protégez ces éléments sensibles tout en prévoyant un accès pour les personnes autorisées si le système d’identité principal est indisponible.

La fréquence et la durée de conservation doivent couvrir aussi bien les erreurs récentes que les problèmes détectés tardivement. La réplication peut améliorer la disponibilité, mais elle peut également propager une modification indésirable : conservez séparément des versions historiques restaurables. Le guide #StopRansomware de la CISA recommande des sauvegardes chiffrées hors ligne et des tests réguliers de leur disponibilité et de leur intégrité.

Limitez les droits de modification et de suppression, séparez si possible l’administration des sauvegardes de celle de la production et surveillez les échecs. Le stockage immuable peut renforcer la protection pendant une durée définie, sans remplacer une copie hors ligne, une gestion sûre des clés ou un test de restauration.

Clarifier les responsabilités dans le cloud et les logiciels SaaS

Les mécanismes de disponibilité d’un fournisseur ne correspondent pas nécessairement aux points de restauration historiques ou au périmètre de reprise dont vous avez besoin. Vérifiez pour chaque service la conservation, l’export, la restauration, les accès, la localisation des données et les engagements contractuels. Par exemple, Microsoft distingue les copies de reprise de Microsoft 365 des sauvegardes historiques ; les fonctionnalités et conditions varient selon les produits.

Choisir une architecture de reprise exploitable

Le cadre AWS Well-Architected présente plusieurs approches dont les compromis permettent aussi d’éclairer des décisions hors AWS :

• Sauvegarde et restauration : reconstruire l’infrastructure et restaurer les données au besoin. L’approche est généralement plus simple et moins coûteuse à maintenir, mais la reprise peut être plus longue.
• Pilot light : maintenir les composants essentiels et les données répliquées, puis démarrer ou déployer le reste lors de la reprise.
• Warm standby : faire fonctionner une copie du service à capacité réduite, prête à être renforcée. La reprise peut être plus rapide, au prix de ressources actives en permanence.
• Actif-actif : servir les utilisateurs depuis plusieurs environnements. Cette option peut améliorer la disponibilité, mais complique notamment la cohérence des données et le basculement.

Aucune de ces approches ne garantit à elle seule un RTO ou un RPO. Comparez les coûts complets — infrastructure, stockage, transferts, licences, exploitation et tests — aux conséquences d’une interruption. Tenez compte du scénario : un second environnement dans la même région ne protège pas forcément contre une panne touchant toute cette région.

Tester la reprise du service, pas seulement la sauvegarde

Rédigez un guide opérationnel précisant les contacts, les pouvoirs de décision, les étapes de reprise et les communications à prévoir. Dans un environnement de test sécurisé, restaurez une application représentative et ses dépendances, contrôlez l’intégrité des données, connectez-vous et réalisez une transaction métier significative. Mesurez le temps écoulé entre l’interruption simulée et le retour d’un service utilisable ; comparez aussi le point de restauration obtenu au RPO.

Répétez les exercices régulièrement et après une modification importante de l’architecture. Prévoyez des scénarios comme une base corrompue, un fournisseur d’identité indisponible ou un compte administrateur compromis. Consignez les écarts, attribuez les actions correctives et leurs échéances, puis effectuez un nouveau test. Après un incident de sécurité, évaluez la fiabilité de l’environnement et des données restaurées avant de rétablir le trafic, en coordination avec l’équipe de réponse à incident.

Que demander à un partenaire de réalisation ?

Une mission utile peut livrer un inventaire priorisé, des RTO et RPO validés, un choix d’architecture documenté, un guide de reprise et les résultats d’un exercice de restauration. Définissez qui est responsable des sauvegardes, des accès, de la surveillance, des décisions en cas d’incident, des tests et des mises à jour. Prévoyez également la remise de la documentation et le maintien des accès à la fin de la mission.

À l’international, examinez aussi la localisation des données, les dépendances aux fournisseurs et les exigences contractuelles ou réglementaires applicables avec les interlocuteurs compétents. Les services de développement logiciel et de conseil technologique d’Altweeb offrent un cadre pertinent pour discuter des dépendances applicatives, des choix de réalisation et de la coordination avec les prestataires d’infrastructure et de sécurité déjà en place. Le périmètre et les responsabilités sont à définir pour chaque mission.

Conclusion

Commencez par une application critique : fixez les pertes et délais acceptables, protégez les éléments nécessaires à sa reconstruction et mesurez une reprise réelle lors d’un exercice. Les résultats serviront à améliorer le dispositif avant de l’étendre aux autres applications.

Pour approfondir ce sujet, découvrez aussi Conseil technologique et transformation digitale.