Une sauvegarde est disponible, mais l’application ne redémarre pas. La base a été copiée, les fichiers sont présents et l’hébergeur confirme que le serveur répond. Il manque pourtant un accès, une configuration ou une dépendance externe. Un plan de reprise doit restaurer un service utilisable, pas seulement remettre des fichiers dans un dossier.
La CNIL recommande de prévoir la continuité et la reprise, d’identifier les intervenants et de réaliser des exercices. Ce dossier propose une méthode opérationnelle adaptée à une petite application ou à un site professionnel. Les scénarios chiffrés sont fictifs ; les objectifs doivent être définis avec les personnes qui connaissent réellement l’activité.
En bref — Définissez l’interruption et la perte de données acceptables, inventoriez les dépendances, puis testez une restauration isolée. La reprise comprend aussi les comptes, les secrets, les tâches et la validation métier. Gardez une procédure accessible pendant la panne et un responsable capable de décider du retour en production.
Partir de ce que l’activité peut supporter
Le plan de reprise d’activité, ou PRA, organise le retour à un fonctionnement après un incident. Un plan de continuité traite la capacité à maintenir certaines activités malgré la perturbation. Les deux démarches peuvent se compléter, mais elles ne décrivent pas exactement les mêmes actions ni les mêmes délais.
Commencez par les fonctions essentielles. Pour une boutique, accepter les commandes peut être prioritaire ; pour un outil interne, accéder aux documents ou traiter une file de demandes peut compter davantage. La page d’accueil n’est pas forcément le bon indicateur de reprise lorsque les utilisateurs ne peuvent pas accomplir leur tâche.
Définissez ensuite la durée d’interruption visée et la perte de données tolérable. On utilise souvent les notions RTO, objectif de délai de reprise, et RPO, objectif de point de récupération. Ces objectifs doivent être interprétés dans votre procédure : point de départ du délai, périmètre fonctionnel et données concernées.
Un exemple fictif aide à voir la différence. Si une application doit reprendre en quatre heures mais qu’une copie quotidienne implique jusqu’à une journée de données non récupérables, le premier objectif ne résout pas le second. Redémarrer vite avec un état trop ancien peut être insuffisant pour l’activité.
La fréquence de sauvegarde ne garantit pas, seule, le RPO réel. Une copie peut échouer, être inutilisable ou porter sur un périmètre incomplet. La reprise dépend de la dernière sauvegarde exploitable et de ce qu’il est possible de rejouer ou de reconstruire sans inventer les opérations manquantes.
Faites accepter les objectifs par les personnes concernées.
Un objectif technique extrêmement court peut imposer des dépenses importantes. À l’inverse, un délai confortable pour l’informatique peut interrompre une activité critique. Écrivez le compromis, les priorités et les limites. Il est plus utile de connaître un objectif réaliste que d’afficher un chiffre ambitieux que personne n’a testé.
Dessiner les dépendances avant de rédiger la procédure
Listez les composants : application, base de données, fichiers envoyés par les utilisateurs, configurations, certificats, gestion des identités et services externes. Ajoutez les tâches planifiées, les emails, les paiements et les files de messages lorsque ces fonctions existent. Le service visible dépend souvent d’éléments moins visibles.
Pour chaque composant, notez son emplacement, son propriétaire, son moyen de restauration et ses accès. Une sauvegarde de base de données ne reconstitue pas nécessairement les documents stockés ailleurs. Une copie du code ne contient pas forcément les secrets et les paramètres nécessaires à son exécution.
Les secrets doivent être récupérables par les intervenants habilités sans être diffusés dans toutes les versions du plan. Décrivez le chemin d’accès et les contrôles, plutôt que coller des mots de passe dans un document partagé. Vérifiez que ce chemin ne dépend pas exclusivement du système qui vient de tomber.
Le domaine et le DNS peuvent également devenir des dépendances critiques. Qui peut modifier une entrée ? Quel compte permet d’accéder au fournisseur ? Que se passe-t-il si la messagerie habituelle est indisponible pour recevoir une validation ? Ces questions doivent être réglées avant l’urgence.
Le dossier sur le choix d’un hébergement et ses responsabilités aide à identifier les tâches qui restent à votre charge. Une prestation d’hébergement ne signifie pas automatiquement une reconstruction complète de votre application.
| Composant | Élément à récupérer | Validation de reprise |
|---|---|---|
| Application | Version du code et dépendances | Démarrage et parcours de démonstration |
| Base de données | Copie cohérente et version du moteur | Totaux, relations et opérations essentielles |
| Fichiers utilisateurs | Supports et correspondance avec la base | Ouverture des documents attendus |
| Identités | Comptes, rôles et mécanismes de secours | Accès autorisés, refus des autres |
| Services externes | Configuration et secrets autorisés | Échanges de test sans actions réelles |
| Tâches | Ordre, fréquence et état des traitements | Absence de doublons et reprise contrôlée |
Mesurer le temps de reprise
| Repère | Rôle et contrôle |
|---|---|
| Détection et décision | Identifier l’incident, qualifier le besoin de reprise et déclencher la procédure. |
| Restauration | Récupérer les données et les composants avec leurs dépendances. |
| Validation métier | Vérifier les opérations nécessaires au service, pas seulement le démarrage. |
| Retour en service | Mesurer la durée totale et suivre les écarts jusqu’à la stabilisation. |
Sauvegarder un état cohérent
Une application peut modifier sa base et ses fichiers pendant une copie. Si les deux éléments correspondent à des moments différents, la restauration peut contenir des références vers des documents absents ou des opérations incomplètes. La méthode doit tenir compte du fonctionnement du logiciel et du moteur de données.
Utilisez les mécanismes de sauvegarde adaptés, avec leurs conditions d’utilisation. Ne supposez pas qu’une copie brute d’un dossier de base active constitue une sauvegarde cohérente. Les documentations du moteur et de l’application expliquent les procédures prises en charge ; elles doivent guider le traitement.
Définissez aussi les versions nécessaires. Une sauvegarde produite dans un environnement peut demander un moteur, des extensions ou un logiciel compatible pour être restaurée. Conservez les informations de version et vérifiez leur disponibilité au moment de préparer le test.
Séparez les copies de leur environnement d’origine lorsque le risque le justifie. Une panne de plateforme ou un compte compromis peut toucher la production et une copie administrée au même endroit. La disponibilité d’un stockage cloud ne démontre pas à elle seule cette indépendance.
Le contrôle doit couvrir la création, la conservation et la restauration. Un fichier de sauvegarde dont la taille semble normale n’est pas une preuve de récupération réussie. Vérifiez les journaux et testez les données essentielles dans une procédure qui évite d’écraser la production.
Une restauration isolée protège le test et le service réel.
Préparez un environnement distinct, limité aux personnes autorisées. Neutralisez l’envoi d’emails, les notifications, les paiements et les appels qui pourraient produire des effets réels. Une copie de production contient parfois des tâches configurées pour reprendre immédiatement ; leur démarrage non contrôlé peut créer des doublons.
Utilisez des données de démonstration lorsque l’exercice ne nécessite pas des données réelles. Si une restauration réelle est indispensable, encadrez l’accès et la conservation selon les règles de l’organisation. Ne transformez pas une copie de test en environnement oublié accessible à davantage de personnes que la production.
Créez ensuite une liste de vérifications métier : ouvrir un document, rechercher un enregistrement, vérifier un total, simuler une opération et confirmer les droits. Les tests doivent montrer que le service remplit son rôle. Un serveur répondant à une requête réseau ne suffit pas.
Organiser l’ordre de redémarrage
Certaines dépendances doivent être disponibles avant d’autres. Une application peut démarrer sans sa file de messages mais perdre des traitements ; une tâche peut s’exécuter avant que les données nécessaires aient été restaurées. L’ordre doit être décrit avec des critères observables, pas seulement une liste de noms de serveurs.
Pour chaque étape, définissez ce qui permet de poursuivre. Par exemple : la base est restaurée, les contrôles sur un jeu connu sont réussis et les comptes applicatifs disposent des droits attendus. Une attente arbitraire de quelques minutes ne remplace pas une vérification de disponibilité.
Gardez les traitements automatiques suspendus tant que leur reprise n’est pas analysée. Déterminez quelles opérations ont été exécutées avant l’incident et lesquelles peuvent être rejouées. Une commande transmise à un service externe peut avoir réussi même si votre application n’a pas reçu la réponse.
L’idempotence, lorsqu’elle est prévue par l’application ou par le contrat d’une API, aide à gérer certaines répétitions. Elle ne doit pas être supposée pour toutes les actions. Une reprise doit distinguer lecture, recalcul, création et envoi pour éviter des effets multiples sur une même opération métier.
Prévoyez un point de contrôle avant l’ouverture aux utilisateurs. Le responsable doit connaître les données restaurées, les écarts restant à traiter et les fonctions momentanément indisponibles. Reprendre partiellement peut être acceptable si cette limite est décidée et communiquée ; elle ne doit pas être cachée derrière un statut « tout fonctionne ».
Mesurer le délai complet
Chronométrez l’exercice depuis le point de départ défini. Le téléchargement et la restauration ne représentent qu’une partie du temps. La détection, la décision, l’accès aux comptes, la reconstruction, les contrôles et le basculement peuvent aussi prendre une durée importante.
Dans un exemple fictif, la détection prend quinze minutes, la mobilisation trente minutes, la récupération des copies quarante-cinq minutes, la restauration cinquante minutes et les contrôles quarante minutes. Le total est de 180 minutes, soit trois heures. Dire uniquement « la base revient en cinquante minutes » masque l’essentiel du parcours.
Mesurez aussi les étapes qui peuvent réellement se dérouler en parallèle. Si une seule personne doit intervenir sur toutes les actions, additionner les délais peut être plus réaliste qu’un calendrier théorique où chaque tâche commence simultanément. Les contraintes de disponibilité humaine doivent apparaître dans le résultat.
Pour estimer un transfert, utilisez des unités cohérentes. Une copie fictive de 100 Go décimaux représente environ 800 gigabits. À 100 Mbit/s constants, son transport seul prend au minimum 8 000 secondes, soit un peu plus de deux heures et treize minutes, avant les autres contraintes. Ce calcul n’est pas une mesure de restauration.
Il peut montrer qu’un objectif très court exige une autre stratégie de conservation ou de réplication. Ne promettez pas une reprise en une heure lorsque le simple rapatriement de la copie demande davantage dans votre hypothèse de réseau.
Documenter les échecs de l’exercice.
Si la restauration échoue, notez l’étape, le message et le contexte. Une dépendance manquante, une procédure ambiguë ou un secret inaccessible sont des résultats utiles du test. Corrigez la cause, puis refaites les contrôles concernés ; ne classez pas l’exercice comme réussi parce qu’une solution improvisée a finalement permis de démarrer.
Conservez également les écarts métiers. Une application peut afficher des données tout en ayant perdu une relation ou une pièce jointe. Les contrôles doivent inclure ce qui compte pour les utilisateurs, notamment les dossiers récents et les opérations complexes.
Qui décide, qui intervient, qui informe ?
Le plan doit nommer les rôles, leurs relais et leurs canaux de contact. Une personne décide de l’activation, d’autres réalisent les opérations et un interlocuteur informe les utilisateurs. Dans une petite équipe, plusieurs rôles peuvent être tenus par la même personne, mais cette contrainte doit être explicite.
Préparez un annuaire accessible lorsque la messagerie ou le gestionnaire documentaire habituel ne fonctionne pas. Séparez les coordonnées utiles des secrets sensibles. Une copie hors du système affecté permet de commencer les actions sans dépendre de son retour.
Communiquez les limites connues : fonctions indisponibles, période de données concernée et prochain point d’information. Évitez d’annoncer une heure certaine sans résultat de contrôle. Une estimation assortie de conditions est plus exploitable qu’une promesse rapidement contredite.
Après la reprise, surveillez les erreurs, les files de traitements et les réconciliations nécessaires. Certaines conséquences apparaissent lorsque les utilisateurs recommencent à travailler. Le plan doit prévoir cette période de suivi et le transfert vers l’exploitation normale.
Un document vivant, lié aux changements.
Revoyez le PRA lorsqu’une dépendance, une version ou un contrat change. Une application qui ajoute un stockage externe ou un prestataire de paiement modifie son périmètre de reprise. La procédure précédente peut démarrer le code sans restaurer la nouvelle fonction.
Définissez des exercices proportionnés au risque : revue sur table, récupération de démonstration et test technique encadré. Aucun rythme universel ne remplace votre analyse. L’important est de conserver les résultats, les corrections et la date du dernier contrôle réellement réalisé.
Un PRA devient crédible quand une autre personne autorisée peut suivre ses étapes, obtenir les moyens nécessaires et vérifier le service. La preuve utile n’est pas la longueur du document, mais une reprise mesurée dont les limites sont connues. La sauvegarde constitue un point de départ ; l’exercice transforme ce point de départ en capacité opérationnelle.
Conservez aussi les coordonnées de remplacement : une procédure dépendant d’un seul téléphone professionnel perdu pendant l’incident reste difficile à exécuter. Vérifiez cet accès alternatif au cours de chaque exercice.
Je suis Romain, rédacteur passionné par tout ce qui touche au high-tech, à la crypto, et à l’innovation. Diplômé d’une école de marketing à Paris, je mets ma plume au service des dernières tendances et avancées technologiques.
