Sommaire8
Un serveur qui ne redémarre plus, un compte cloud bloqué, une commande qui efface ce qu’il ne fallait pas, un centre de données qui brûle. Le jour où cela arrive, la question n’est plus technique : c’est de savoir quoi relancer d’abord, avec quoi, et qui décide. Si la réponse n’est écrite nulle part, elle s’improvise sous pression, et c’est là que les heures s’allongent.
Ce guide de notre rubrique Infrastructure et cloud décrit ce qu’un plan de reprise après sinistre doit contenir, les deux chiffres que la direction doit fixer, et comment savoir qu’il fonctionne avant d’en avoir besoin.
En bref
La continuité d’activité, c’est continuer à fonctionner, souvent en mode dégradé ; la reprise, c’est relancer ce qui s’est arrêté.
Deux chiffres par service : la durée d’arrêt acceptable et la perte de données acceptable. C’est une décision de direction, pas de technicien.
Le plan dit quoi relancer, dans quel ordre, avec quelles sauvegardes, avec quels accès, et qui prévenir.
Un plan jamais testé est une hypothèse : la restauration réelle donne le vrai délai.
Continuité, reprise : de quoi parle-t-on ?
La CNIL distingue clairement les deux dans sa fiche sur la continuité et la reprise d’activité : assurer la continuité, c’est prévoir des moyens de continuer à fonctionner, en général de manière dégradée ; la reprise englobe toutes les actions nécessaires pour relancer un système arrêté. Elle recommande de rédiger un plan de continuité (PCA) et un plan de reprise (PRA), même sommaires, avec la liste des intervenants.
Cet article porte sur le second. Un PRA ne demande pas un classeur de cent pages : pour une entreprise de 20 à 500 personnes, quelques pages précises valent mieux qu’un document exhaustif que personne n’ouvre.
Pourquoi l’écrire avant
Parce qu’un sinistre ne prévient pas, et qu’il peut emporter plus qu’un serveur. Le 10 mars 2021 à 0 h 47, un incendie s’est déclaré dans l’un des quatre centres de données d’OVHcloud à Strasbourg. Selon le communiqué de l’hébergeur, le feu a détruit le bâtiment SBG2 et a continué de menacer les centres voisins jusqu’à ce que les pompiers le maîtrisent.
Ce jour-là, un plan qui supposait que le centre de données existait toujours ne servait à rien. Un plan utile répond à la question : si ce lieu disparaît, d’où repart-on ? C’est pour cela que la règle 3-2-1 des sauvegardes demande une copie sur un autre site, comme l’explique notre guide des sauvegardes d’un serveur à soi.
Les sinistres les plus fréquents sont pourtant plus banals : une erreur humaine, une mise à jour qui casse, un compte compromis. Nous en avons vécu un.
Sur le terrain
Le 5 juillet 2026, une commande de nettoyage mal ciblée a détruit d’un coup les conteneurs de dix services sur notre propre serveur. Les données, rangées dans des volumes séparés, ont été sauvées, et les services ont été reconstruits. Ce que cet incident nous a appris tient en une phrase : ce qui sauve, ce n’est pas d’être prudent, c’est d’avoir écrit avant ce qu’on reconstruit et comment. Nos règles d’exploitation sont désormais écrites, y compris celles qui encadrent les commandes destructrices.
Les deux chiffres que la direction doit fixer
Définition
La durée d’arrêt acceptable (RTO)
Le temps pendant lequel un service peut rester en cours de reprise avant que l’arrêt nuise à l’activité. Le NIST la nomme recovery time objective, dans sa publication SP 800-34.
Définition
La perte de données acceptable (RPO)
Le point dans le temps auquel les données doivent être restaurées après une panne, autrement dit combien de travail récent on accepte de perdre. Le NIST la nomme recovery point objective, dans la même publication.
Ces deux chiffres se fixent service par service, et ce n’est pas au technicien de les choisir : ils engagent l’activité, donc la direction. Le CRM peut-il s’arrêter une demi-journée ? Peut-on perdre la saisie de la matinée, ou seulement les cinq dernières minutes ? La réponse décide de tout le reste : une sauvegarde chaque nuit donne au mieux une perte d’une journée, et un délai de reprise de quelques minutes demande un second système prêt à prendre le relais, qui a un coût.
À retenir
Plus les deux chiffres sont petits, plus la reprise coûte cher. Les fixer, c’est décider combien l’entreprise accepte de payer pour ne pas s’arrêter.
Ce que le plan doit contenir
- L’inventaire des services, par ordre de reprise.
Pour chacun, sa durée d’arrêt et sa perte de données acceptables, et ce dont il dépend : on ne relance pas le CRM avant la base de données qu’il utilise.
- Où sont les sauvegardes, et comment on les restaure.
Pour chaque service : l’emplacement des copies, la commande ou la procédure de restauration, et comment vérifier que le résultat est bon.
- Les accès de secours.
Les identifiants nécessaires à la reprise, rangés hors du système qui peut tomber : un coffre-fort de secrets accessible même si le serveur principal est perdu, et au moins deux personnes capables de l’ouvrir.
- Qui fait quoi, et qui prévenir.
Qui décide de déclencher le plan, qui restaure, qui informe les équipes, les clients et, le cas échéant, les autorités. La CNIL demande que les utilisateurs, prestataires et sous-traitants sachent qui alerter en cas d’incident.
- Le mode dégradé.
Comment l’activité continue pendant la reprise, sans baisser la sécurité des données : la CNIL met explicitement en garde contre ce risque.
- Le retour à la normale.
Comment on revient à la situation habituelle, et ce qu’on vérifie avant de déclarer l’incident clos.
Le troisième point est celui qui manque le plus souvent. Un plan parfait dont les mots de passe sont sur le serveur détruit ne sert à rien.
Sur le terrain
Sur Palmora Property, un portail immobilier que nous opérons, c’est la dépendance à une seule machine qui a motivé un coffre-fort de secrets auto-hébergé. Les sauvegardes partent hors du serveur, pour environ 6 dollars par mois, et une restauration y est jugée au nombre de tables et d’enregistrements retrouvés, pas au code de retour de l’outil, qui signale une erreur sur de simples avertissements.
Comment savoir que le plan marche
En le testant. La CNIL range parmi les erreurs à éviter le fait de ne pas tester les mesures de continuité ou de reprise en amont, et recommande de tester régulièrement la restauration des sauvegardes et l’application du plan.
Deux exercices, complémentaires :
- l’exercice sur table, une fois par an au moins : l’équipe déroule le plan à voix haute sur un scénario (« le serveur principal est perdu, il est 9 heures un lundi ») et note chaque trou ;
- la restauration réelle, chaque trimestre pour les services critiques : un service restauré dans un environnement jetable, chronométré, et validé sur son contenu.
Le temps mesuré pendant la restauration réelle est votre vrai délai de reprise. S’il dépasse la durée d’arrêt fixée par la direction, l’un des deux doit changer : le chiffre, ou les moyens.
Le plan dans le reste de l’infrastructure
Le plan de reprise s’appuie sur tout ce qui l’entoure : des sauvegardes testées, une supervision qui donne l’alerte avant les clients, un socle d’infrastructure aux règles communes. Le choix de l’hébergement le façonne aussi : sur un serveur unique, la reprise passe par la restauration ; avec un second serveur ou des services gérés, par la bascule, comme le détaillent serveur dédié, VPS ou cloud et Kubernetes : quand une PME n’en a pas besoin. Chaque niveau de redondance a un prix, que l’on retrouve dans les cinq postes qui gonflent une facture cloud.
La continuité est aussi l’un des objectifs du référentiel que l’ANSSI prépare pour NIS2, détaillé dans NIS2 en France : la loi toujours pas votée. Les autres articles de la rubrique complètent le tableau : les outils à sortir du SaaS en premier, le coût d’une sortie du SaaS sur trois ans, n8n auto-hébergé en production, la migration cloud sans tout casser et la dépendance au cloud américain.
Par où commencer
Réunissez la direction et la personne qui exploite vos systèmes pendant une heure. Listez les services, fixez pour chacun les deux chiffres, puis vérifiez que les sauvegardes existantes permettent de les tenir. Écrivez ensuite les six rubriques ci-dessus, même en une page chacune, et planifiez la première restauration réelle.
Si vos outils tournent sur un serveur à vous, notre sortie du SaaS est livrée avec des sauvegardes hors serveur, une restauration testée et une documentation d’exploitation qui dit comment restaurer et qui prévenir. Pour les accès de secours, le coffre-fort IA range vos mots de passe et vos clés dans un coffre ouvert à votre nom. Pour un plan sur une infrastructure existante, décrivez-nous vos services.
Questions fréquentes
Quelle est la différence entre un PCA et un PRA ?
Le plan de continuité d’activité (PCA) prévoit comment continuer à fonctionner pendant un incident, souvent en mode dégradé. Le plan de reprise d’activité (PRA) décrit comment relancer ce qui s’est arrêté. La CNIL recommande d’écrire les deux, même sommaires. Pour une entreprise de taille moyenne, le PRA est souvent le premier à rédiger, parce qu’il s’appuie sur des sauvegardes qui existent déjà.
Que signifient RTO et RPO ?
Le RTO est la durée pendant laquelle un service peut rester arrêté avant que l’activité en souffre. Le RPO est le point dans le temps auquel les données doivent être restaurées, donc la quantité de travail récent qu’on accepte de perdre. Les deux se fixent service par service, par la direction, et décident du type de sauvegarde et de redondance à payer.
À quelle fréquence tester un plan de reprise ?
La CNIL demande de tester régulièrement, sans fixer de rythme. Nous recommandons un exercice sur table au moins une fois par an, et une restauration réelle chaque trimestre pour les services critiques, chronométrée et validée sur le contenu. Le bon rythme reste celui que l’équipe tient vraiment : un test fait vaut mieux qu’un test prévu.
Une petite entreprise a-t-elle besoin d’un PRA ?
Oui, à sa mesure. Dès qu’un outil est indispensable à l’activité, il faut savoir comment le relancer et qui le fait. Pour une petite structure, quelques pages suffisent : la liste des services, les deux chiffres pour chacun, où sont les sauvegardes, les accès de secours et les personnes à prévenir. L’essentiel est qu’il soit écrit, accessible et testé.
Sources
- CNIL, Sécurité : prévoir la continuité et la reprise d’activité (nouvel onglet)cnil.fr
- OVHcloud, communiqué sur l’incendie du site de Strasbourg, 10 mars 2021 (nouvel onglet)community.ovhcloud.com
- NIST, glossaire, recovery time objective, d’après SP 800-34 Rev. 1 (nouvel onglet)csrc.nist.gov
- NIST, glossaire, recovery point objective, d’après SP 800-34 Rev. 1 (nouvel onglet)csrc.nist.gov
CNIL, Sécurité : prévoir la continuité et la reprise d’activité
Lire sur cnil.fr(nouvel onglet)OVHcloud, communiqué sur l’incendie du site de Strasbourg, 10 mars 2021
Lire sur community.ovhcloud.com(nouvel onglet)NIST, glossaire, recovery time objective, d’après SP 800-34 Rev. 1
Lire sur csrc.nist.gov(nouvel onglet)NIST, glossaire, recovery point objective, d’après SP 800-34 Rev. 1
Lire sur csrc.nist.gov(nouvel onglet)Jim · fondateur de Brain Plus AI
À lire aussi en infrastructure et cloud
Guide pratique8 min
Sauvegarder un serveur à soi : ce qui casse vraiment
La règle 3-2-1, tout le monde la connaît, mais ce qui fait perdre des données est plus banal : une sauvegarde jamais restaurée, un volume oublié, une commande de nettoyage global lancée en production. Voici ce que nous avons appris en exploitant notre propre serveur.
Guide pratique8 min
Supervision : savoir qu'un service tombe avant les clients
Une panne découverte par un client coûte deux fois : le service perdu, et la confiance. Ce qu'une supervision doit regarder, de l'extérieur comme de l'intérieur, qui doit recevoir l'alerte, et comment éviter celle que plus personne ne lit.
Guide pratique7 min
NIS2 en France : la loi toujours pas votée, que faire
Deux ans après la date limite européenne, la loi qui transpose NIS2 en France a encore été retirée de l'ordre du jour de l'Assemblée le 6 octobre 2026. Où en est le texte, qui sera concerné, et les mesures qui protègent dès maintenant, quelle que soit la date du vote.