Un plan de reprise décrit les fonctions prioritaires, le délai de retour et les données acceptables après une panne ou une perte d’infrastructure.
Une sauvegarde ne suffit pas à reprendre une activité. L’équipe doit savoir quel service restaurer en premier, où retrouver les secrets et comment vérifier les données. Le plan doit correspondre au travail réel de l’entreprise.
Fixer les objectifs
Définissez le délai maximal avant reprise et la perte de données acceptable pour chaque fonction. Les commandes, l’accès aux dossiers et les exports peuvent avoir des priorités différentes. Ces objectifs déterminent la fréquence des sauvegardes et l’architecture.
Documenter les dépendances
Listez la base, le stockage, l’authentification, les emails, les DNS et les fournisseurs externes. Pour chaque dépendance, indiquez le propriétaire et l’accès de secours. Un compte qui n’est connu que d’une personne est un risque opérationnel.
Restaurer dans l’ordre
Une restauration doit commencer dans un environnement isolé. Vérifiez la version du schéma, les fichiers, les tâches en attente et les droits. Le test de restauration des sauvegardes doit mesurer le délai réel.
Ne réactivez pas les écritures avant de savoir si la copie est cohérente. Une sauvegarde ancienne peut contenir une référence vers un fichier absent. Les contrôles métier doivent confirmer les totaux et les derniers états connus.
Tester avec l’équipe
Faites un exercice avec une panne simulée et notez les décisions prises. Vérifiez que le support peut informer les utilisateurs et que les accès de secours fonctionnent. Après l’exercice, corrigez le document et attribuez les actions restantes.
Sources : NIST, planification de continuité, AWS, reprise d’activité.
Le rapport d’exercice doit inclure le délai obtenu, les données contrôlées, les utilisateurs informés et les décisions restantes. Conservez la version du plan utilisée. Une revue à date fixe ne suffit pas lorsqu’un fournisseur, un schéma ou une fonction critique change.
Un exercice doit aussi vérifier le mode dégradé et le retour aux opérations normales. Comparez les files, les doublons, les fichiers et les droits avant de rouvrir les écritures. Attribuez une échéance aux corrections et rejouez le scénario après chaque changement d’infrastructure.
Conservez la version du plan utilisée, le délai obtenu et les contrôles réalisés. Le propriétaire confirme la reprise technique et la reprise métier avant de fermer l’incident.
Les copies restaurées doivent rester isolées jusqu’à la fin des contrôles. Après validation, la communication indique les fonctions disponibles et les éventuelles opérations à ressaisir.
Le rapport est signé par les responsables technique et métier.
Définir les priorités métier
Listez les parcours essentiels, les personnes responsables et les données nécessaires. Une entreprise peut accepter que les rapports attendent alors qu’elle doit reprendre l’accès aux commandes. Classez les fonctions et indiquez la dépendance qui doit être restaurée pour chacune.
Les objectifs de délai et de perte de données doivent être écrits en termes compréhensibles. Une perte de quelques minutes peut être acceptable pour une liste de tâches et non pour une facture. Ces objectifs déterminent les sauvegardes, les copies et les mécanismes de réplication.
Tester les accès
Une restauration peut échouer parce que le compte de stockage, le DNS ou le secret n’est pas disponible. Conservez une procédure d’accès de secours et vérifiez-la avec un exercice. Les secrets doivent avoir un propriétaire et une rotation connue.
Après restauration, contrôlez les schémas, fichiers, index, files et tâches planifiées. Une application qui démarre peut encore contenir des données incomplètes. Comparez un échantillon avec la dernière source confirmée et bloquez les écritures si la cohérence n’est pas établie.
Organiser la communication
Le plan doit indiquer qui informe les utilisateurs, qui contacte les fournisseurs et où publier l’état. Un message doit distinguer l’indisponibilité, la reprise partielle et le retour vérifié. Notez l’heure et la prochaine mise à jour.
Après l’exercice, mesurez le délai réel, les décisions manquantes et les accès qui n’ont pas fonctionné. Attribuez chaque correction et rejouez le scénario lorsqu’elle est terminée.
Prévoir le mode dégradé
Certaines fonctions peuvent rester disponibles pendant une panne. Indiquez si les utilisateurs peuvent consulter, créer un brouillon ou mettre une opération en attente. L’interface doit afficher l’état du service et empêcher une action qui créerait une incohérence.
Une file locale ou un traitement manuel doit avoir une limite et un propriétaire. À la reprise, comparez les opérations reçues, les doublons et les dates. Ne réinjectez pas automatiquement un fichier dont la règle métier a changé pendant l’interruption.
Vérifier les fournisseurs
Les DNS, certificats, stockage, emails et services de paiement doivent avoir un accès de secours et une procédure de remplacement. La rotation des secrets doit être testée hors production. Les dépendances font partie du plan, même lorsqu’elles ne sont pas installées sur votre serveur.
Conservez les contacts, contrats, objectifs et limites de chaque service. Après une reprise, demandez une confirmation technique et métier avant de fermer l’incident.