Sauvegarde du cabinet : prouvez que vos données sont restaurables

Le tableau de bord peut afficher « sauvegarde réussie » tous les matins et laisser pourtant le cabinet sans dossier exploitable le jour d’une panne. La copie peut être incomplète, chiffrée avec une clé introuvable, contaminée par le même rançongiciel ou impossible à réimporter dans le logiciel. Vos données ne sont réellement restaurables qu’après une restauration testée, chronométrée et vérifiée.

Ce guide donne une méthode concrète pour sauvegarder les données d’un cabinet d’ostéopathie et tester leur restauration sans toucher à la production. Il permet de définir ce qui doit reprendre, de construire une architecture diversifiée, de poser les bonnes questions au prestataire et de produire un procès-verbal utile. Il ne fixe pas une fréquence universelle : les objectifs et les contrôles doivent rester proportionnés aux données, aux dépendances et aux risques du cabinet.

La règle de sécurité : tout exercice se déroule dans un environnement isolé, avec un jeu de données fictives ou des données protégées selon une procédure validée. Ne supprimez jamais une donnée de production pour « voir si elle revient » et ne reconnectez pas une sauvegarde suspecte au réseau courant.

La réponse courte : sauvegarder ne suffit pas

Un cabinet dispose d’une stratégie crédible lorsque ses données utiles sont copiées selon une fréquence cohérente avec la perte maximale qu’il accepte, sur des supports qui ne partagent pas tous la même panne, avec au moins une copie distante et une copie isolée du réseau courant. Ces copies sont chiffrées, surveillées et restaurées dans un environnement distinct. Le résultat du test est contrôlé sur les dossiers, les pièces jointes, les droits, les paramètres et le temps de reprise, puis consigné.

Les cinq preuves minimales à pouvoir montrer

• un inventaire daté des systèmes, données et dépendances couverts ;
• une politique précisant fréquence, rétention, emplacements et responsabilités ;
• un historique des exécutions et des alertes réellement traitées ;
• un procès-verbal de restauration avec périmètre, durée et contrôles ;
• un plan de correction lorsque le résultat n’est pas conforme.

Ce que ce guide ne promet pas

Il n’existe pas de durée de rétention, de fréquence de copie ou de délai de reprise identique pour tous les cabinets. La sauvegarde ne démontre pas à elle seule la conformité au RGPD, la certification HDS d’un service, l’absence de violation de données ou la continuité clinique. Elle complète la démarche RGPD du cabinet, la gestion des accès et le plan de réaction ; elle ne les remplace pas.

Distinguer copie, synchronisation, export, archive et sauvegarde

De nombreuses fausses sécurités viennent d’un mot utilisé pour plusieurs mécanismes. Avant de demander « avons-nous une sauvegarde ? », il faut nommer le service rendu et le scénario auquel il répond.

Une synchronisation n’est pas nécessairement une sauvegarde

La synchronisation maintient plusieurs emplacements dans le même état. Elle est utile pour travailler sur plusieurs appareils, mais elle peut répliquer très vite une suppression, une corruption ou le chiffrement de fichiers. Un historique de versions apporte une marge de retour, à condition que sa profondeur, sa durée et ses règles soient connues. Il ne garantit ni l’indépendance des accès ni la restauration de toutes les dépendances.

Un disque branché en permanence au poste principal pose le même problème : le fichier existe ailleurs, mais reste exposé au vol, à l’incendie, à la surtension, à une erreur d’administration ou à un logiciel malveillant capable de parcourir les volumes connectés.

Un export n’est pas encore une reprise

Un export CSV peut contenir des lignes de patients sans restituer les pièces jointes, les liens entre rendez-vous et dossiers, les historiques, les consentements, les factures ou les droits d’accès. Un PDF est lisible mais rarement réimportable. Une image complète de serveur peut être inutilisable sans la bonne version du logiciel, les certificats, les secrets et la documentation technique. Le contrôle de l’export et de la réversibilité répond donc à une question différente, mais étroitement liée.

Une archive répond à un autre besoin

L’archive vise la conservation maîtrisée d’un contenu stabilisé, avec des exigences d’intégrité, de durée et de consultation. La sauvegarde vise le retour à un état exploitable après une perte ou une altération. Utiliser une sauvegarde comme archive permanente accumule des données sans gouvernance ; utiliser une archive comme seul mécanisme de reprise peut rendre la remise en service trop lente ou incomplète.

Relier la sauvegarde à l’obligation de sécurité sans inventer une règle

L’article 32 du RGPD demande des mesures techniques et organisationnelles adaptées au risque. Il cite notamment la capacité de rétablir la disponibilité et l’accès aux données personnelles dans des délais appropriés après un incident physique ou technique, ainsi qu’une procédure permettant de tester, d’analyser et d’évaluer régulièrement l’efficacité des mesures de sécurité. Le texte officiel est accessible sur EUR-Lex.

Une obligation proportionnée, pas un calendrier magique

Le RGPD n’impose pas à tout cabinet une copie quotidienne, un test trimestriel ou une conservation de trente jours. Il impose de raisonner à partir de la nature des traitements, du contexte, des conséquences possibles et des moyens disponibles. Les données de santé, les rendez-vous et les documents nécessaires au suivi justifient une attention forte, mais la décision doit être documentée plutôt qu’annoncée comme une règle légale universelle.

La fiche officielle « Sécurité : Sauvegarder » de la CNIL recommande des sauvegardes fréquentes, un site géographiquement distinct, au moins une sauvegarde hors ligne, une protection équivalente à la production, le chiffrement du canal de transmission et des tests réguliers d’intégrité et de restauration. La CNIL présente aussi la règle 3–2–1 comme une pratique conseillée. Ces recommandations constituent une base sérieuse pour traduire l’obligation générale en mesures vérifiables.

Le prestataire n’absorbe pas la responsabilité du cabinet

Un service en ligne peut exécuter la copie, exploiter l’infrastructure et lancer la restauration. Le cabinet reste néanmoins tenu de comprendre les garanties contractuelles, de vérifier qu’elles couvrent les fonctions utilisées et d’organiser son fonctionnement dégradé. Dans sa fiche « Cloud, informatique en nuage », la CNIL rappelle qu’il ne faut pas présumer que l’obligation de sécurité incombe uniquement au fournisseur. Le bon partage des rôles doit être écrit : qui surveille, qui reçoit l’alerte, qui autorise une restauration, qui vérifie le résultat et qui informe en cas d’incident.

Inventorier ce qui doit réellement reprendre

La première cause d’une restauration incomplète est souvent un périmètre incomplet. Sauvegarder « la base » ne suffit pas si la consultation dépend aussi d’un stockage documentaire, d’un service d’authentification, de paramètres ou d’une clé. L’inventaire doit partir de l’activité réelle, pas de la liste commerciale du logiciel.

Cartographier les services et leurs propriétaires

Listez le logiciel de cabinet, les dossiers, les rendez-vous, les pièces jointes, la facturation, la comptabilité, les modèles de documents, les contacts, la messagerie administrative, le site, les agendas externes, les terminaux et les supports papier utiles. Pour chaque élément, indiquez le responsable, l’emplacement, le fournisseur, la fréquence de modification, le volume, la sensibilité et le mode de récupération.

Ne copiez pas automatiquement tout ce qui existe. L’inventaire sert aussi à exclure les doublons inutiles, les téléchargements oubliés et les exports temporaires. Une sauvegarde mieux maîtrisée commence par une production maîtrisée.

Identifier les dépendances invisibles

Pour ouvrir un dossier restauré, il peut être nécessaire de disposer de la même version applicative, d’un dictionnaire de données, d’un certificat, d’un domaine actif, d’un annuaire, d’une clé de chiffrement ou d’un compte d’administration. Pour remettre les rendez-vous en service, il faut parfois rétablir un connecteur et son autorisation. Pour relire une pièce jointe, le lien entre la base et le stockage objet doit être conservé.

Documentez ces dépendances comme une chaîne. Si un seul maillon n’est pas sauvegardé ou récupérable, le volume de fichiers restauré peut être impressionnant et le service rester inutilisable.

Attribuer une criticité compréhensible

Classez les éléments en trois niveaux simples : indispensables à la prochaine journée de consultation, nécessaires au retour complet à la normale, et utiles mais différables. Cette classification aide à décider ce qui doit être restauré en premier. Elle évite de consacrer les premières heures à remettre en ligne une fonction secondaire alors que la liste des rendez-vous ou les éléments nécessaires au suivi restent inaccessibles.

Fixer la perte de données et l’interruption acceptables

La fréquence de sauvegarde découle d’un choix métier : combien d’informations saisies depuis la dernière copie le cabinet peut-il raisonnablement reconstituer ? Le délai de restauration découle d’un autre choix : combien de temps peut-il travailler sans le service ? Le référentiel de mesures MonServiceSécurisé de l’ANSSI demande notamment de formaliser la perte de données maximale admissible et la durée maximale d’interruption admissible. Les termes RPO et RTO sont aussi courants chez les prestataires.

Définir la perte maximale admissible

Si perdre une journée de notes, de rendez-vous et de factures est inacceptable, une sauvegarde nocturne ne répond pas au besoin. Il faut une fréquence plus rapprochée ou un mécanisme complémentaire, en vérifiant que celui-ci produit bien un point récupérable. À l’inverse, sauvegarder toutes les cinq minutes un contenu qui change une fois par mois ajoute de la complexité sans bénéfice évident.

Exprimez l’objectif en durée et en contenu : « au maximum deux heures de saisie sur les dossiers et rendez-vous », plutôt que « sauvegarde fréquente ». Puis vérifiez que le service promet, mesure et permet réellement ce point de reprise.

Définir le délai de reprise utile

Un prestataire peut restaurer un serveur en quatre heures mais mettre deux jours à rendre l’application accessible, puis une journée supplémentaire à reconstruire les pièces jointes. Le délai pertinent va du début de l’indisponibilité au retour d’un service vérifié et utilisable. Il comprend l’escalade, l’autorisation, le transfert, la restauration technique, les contrôles et la réouverture.

Pour chaque fonction critique, notez le délai cible, le mode dégradé possible et la personne qui décide du retour. Ce document alimente le plan de continuité et permet de comparer une promesse commerciale au besoin réel.

Construire une architecture diversifiée

Dans sa fiche consacrée aux sauvegardes, la CNIL conseille la règle 3–2–1 : trois copies des données, sur deux supports différents, dont une hors ligne. Elle recommande également qu’au moins une sauvegarde soit stockée sur un site géographiquement distinct. Le comptage exact importe moins que l’indépendance réelle face aux scénarios retenus : panne, erreur, vol, incendie, compte compromis, rançongiciel ou défaillance du fournisseur.

Diversifier les causes de panne

Deux dossiers sur le même ordinateur ne forment pas deux protections indépendantes. Deux volumes du même compte cloud peuvent partager le même identifiant administrateur. Deux centres de données peuvent dépendre du même fournisseur, de la même console et de la même erreur de configuration. Demandez ce qui est réellement distinct : média, compte, console, zone géographique, opérateur, alimentation et procédure d’accès.

Distinguer hors ligne et immuable

Une copie hors ligne est déconnectée du système courant ; elle ne peut pas être atteinte par le chemin réseau habituel tant qu’elle reste isolée. Une copie immuable ne peut pas être modifiée ou supprimée pendant une durée définie, selon les droits et les garanties du mécanisme. Les deux propriétés peuvent se compléter, mais elles ne sont pas synonymes. Une immuabilité mal configurée ou administrable depuis le compte compromis ne répond pas au même scénario qu’un support réellement déconnecté.

Éloigner sans perdre la maîtrise

La copie distante protège d’un sinistre touchant le cabinet. Son éloignement ne doit pas masquer sa sensibilité : elle peut contenir tout le patrimoine informationnel. Vérifiez la localisation, le chiffrement, le transport, les accès, la journalisation, la rétention et la suppression. Une copie confiée à un tiers doit être couverte par des engagements cohérents avec la production.

Protéger les sauvegardes et leurs accès

La sauvegarde concentre souvent plus de données qu’un écran applicatif et contourne parfois les contrôles usuels. La CNIL demande un niveau de protection équivalent à celui de la production. Dans « Les essentiels — Sauvegarde des systèmes d’information », version 1.1, l’ANSSI considère les opérations de sauvegarde et de restauration comme des opérations sensibles d’administration.

Séparer les identités d’administration

Évitez qu’un seul compte permette d’administrer la production, de désactiver les alertes, de supprimer les sauvegardes et de modifier la rétention. Utilisez des comptes nominatifs, une authentification multifacteur lorsque le service le permet, des droits minimaux et une voie de secours contrôlée. La gestion détaillée doit rester cohérente avec la politique de comptes, droits et habilitations.

Préparez aussi le départ d’un collaborateur et l’indisponibilité du titulaire. Un secret connu d’une seule personne peut bloquer la reprise ; un secret partagé dans un document non protégé augmente le risque d’accès. La procédure de récupération doit être autorisée, tracée et testée.

Chiffrer sans perdre les clés

Chiffrez les sauvegardes au repos lorsque le risque le justifie et le canal lorsqu’elles transitent hors du réseau interne. Identifiez qui contrôle les clés, où se trouve la procédure de récupération et ce qu’il advient après une rotation. Une clé enregistrée uniquement sur le système sinistré rend la copie inutilisable ; une clé stockée sans séparation annule une partie de la protection.

Traiter l’échec comme un incident opérationnel

Une sauvegarde automatique doit produire une information exploitable. Définissez qui reçoit l’alerte, sous quel délai elle est examinée et qui remplace cette personne. Surveillez l’absence de nouvelle copie, l’espace restant, les changements anormaux de volume, l’expiration d’un identifiant, l’échec d’un connecteur et l’altération d’un catalogue.

Une alerte acquittée ne démontre pas que les données attendues sont présentes. Chaque revue doit rapprocher l’historique d’exécution de l’inventaire : les pièces jointes, nouveaux modules et paramètres ajoutés depuis le dernier contrôle sont-ils couverts ?

Contrôler le cloud, le contrat et le périmètre HDS

Dans un service cloud, le mot « sauvegarde » peut désigner une réplication technique interne, un historique accessible au client, une copie d’exploitation ou une prestation de restauration sur ticket. Il faut obtenir une description précise, pas seulement une case cochée dans une brochure.

Les questions à poser au fournisseur

• Quelles données, pièces jointes, configurations et journaux sont inclus ou exclus ?
• À quelle fréquence un point récupérable est-il créé et combien de temps est-il conservé ?
• Une suppression, une corruption ou un chiffrement côté client se réplique-t-il ?
• Quels comptes peuvent supprimer les copies ou réduire leur rétention ?
• Les emplacements sont-ils géographiquement distincts et sous quelle juridiction ?
• Qui détient les clés et comment leur récupération est-elle testée ?
• Quel délai couvre la restauration complète, et quels contrôles sont inclus ?
• Peut-on demander un test, obtenir son compte rendu et corriger un échec ?
• Que devient chaque copie à la fin du contrat ou après une demande de suppression ?

Ces réponses doivent être comparées au protocole de choix du logiciel de cabinet, pas archivées sans essai. Une garantie contractuelle est nécessaire ; un test réussi dans le contexte du cabinet apporte une preuve complémentaire.

Vérifier l’activité HDS mobilisée

Lorsque des données de santé à caractère personnel sont hébergées pour le compte du cabinet et que le service entre dans le champ légal, il faut relier la chaîne technique au certificat HDS. Le référentiel de certification HDS version 2.0 précise que l’activité 6 vise la sauvegarde externalisée ; les sauvegardes intrinsèquement nécessaires aux activités 1 à 5 relèvent du périmètre de ces activités. Il ne suffit donc pas de repérer un logo : il faut vérifier l’entité certifiée, les activités, les sites et les sous-traitants réellement utilisés.

Le guide HDS au cabinet : ce que le certificat prouve et ne prouve pas détaille cette lecture. La certification HDS ne prouve pas, à elle seule, que votre politique de rétention est correcte, que votre export est complet ou que le délai de reprise répond à vos besoins.

Préparer un test de restauration sans exposer la production

Un bon test commence avant le clic sur « restaurer ». Il précise l’objectif, le périmètre, la date cible, les personnes autorisées, l’environnement de destination, les critères de réussite et la marche arrière. Il protège la production et évite que l’exercice crée lui-même un incident.

Choisir un scénario observable

Commencez par un scénario partiel : restaurer à une date précise un jeu fictif comprenant un rendez-vous, un dossier, une pièce jointe, un modèle, une facture et un compte dont les droits sont connus. Notez leurs identifiants et les relations attendues. Le scénario doit permettre de détecter une restauration qui ramène les fichiers mais perd les liens, les métadonnées ou les autorisations.

Ajoutez ensuite un scénario de reprise plus large : indisponibilité du service principal, compte administrateur compromis, perte du poste ou défaillance du fournisseur. Le test complet ne doit être lancé qu’avec un plan validé, les ressources nécessaires et une fenêtre sans impact sur les consultations.

Préparer un environnement isolé

L’environnement de test ne doit pas envoyer de vrais SMS, e-mails, feuilles de soins ou synchronisations. Neutralisez les connecteurs sortants, utilisez des comptes distincts et marquez clairement l’espace comme non productif. Les données fictives sont préférables. Si un échantillon réel est indispensable, limitez-le, documentez la base juridique et appliquez les mêmes mesures de protection que pour la production.

Écrire les critères avant l’exercice

Définissez à l’avance la date de restauration visée, le délai cible, le nombre d’objets attendus, les contrôles d’intégrité, les droits à retrouver, les fonctions à ouvrir et les journaux à examiner. Sans critères préalables, l’équipe risque de déclarer la réussite dès que l’écran d’accueil s’affiche.

Restaurer et vérifier le résultat de bout en bout

Chronométrer la vraie reprise

Démarrez le chronomètre au moment où le cabinet constate l’indisponibilité ou formule la demande prévue par le scénario. Incluez le temps d’identification, d’escalade, d’autorisation, de téléchargement, de déchiffrement, de restauration, de contrôle et de remise à disposition. Notez les temps d’attente et les dépendances humaines : elles comptent autant que la vitesse du stockage.

Vérifier données, liens et formats

Ouvrez les objets du jeu de test et comparez-les aux valeurs attendues. Vérifiez les caractères accentués, les dates, les montants, les pièces jointes, les liens entre dossiers et rendez-vous, les versions de modèles et les métadonnées utiles. Contrôlez quelques objets anciens et récents afin de détecter un problème limité à une période.

Un comptage global est utile mais insuffisant : mille fichiers restaurés peuvent inclure des doublons et omettre la pièce indispensable. Lorsque le système fournit des empreintes, des totaux ou un journal d’intégrité, conservez-les avec le compte rendu et complétez-les par des contrôles fonctionnels.

Vérifier les droits et les journaux

Assurez-vous qu’un compte retiré n’est pas réactivé, qu’un remplaçant ne reçoit pas des droits excessifs et que les rôles restent cohérents. Vérifiez qui a lancé la restauration, qui a consulté l’environnement et si l’opération est tracée. Une reprise qui restitue les données mais ouvre tous les dossiers à tous les comptes crée une nouvelle violation potentielle.

Fermer proprement l’exercice

Après validation, stoppez les connecteurs, exportez les preuves nécessaires, puis supprimez l’environnement de test selon la procédure prévue. Ne laissez pas une copie supplémentaire oubliée dans un espace temporaire. Consignez la suppression, les personnes qui l’ont contrôlée et les exceptions éventuelles.

Transformer le test en preuve exploitable

Le procès-verbal n’a pas besoin d’être volumineux. Il doit permettre à une personne absente le jour de l’exercice de comprendre ce qui a été testé, avec quelle version, selon quels critères et avec quel résultat. Une capture « succès » sans périmètre ni vérification ne permet pas cette lecture.

Le contenu du procès-verbal

Preuve attendue	Utilité
Contexte : date, scénario, système, version et responsables	Rendre le test reproductible
Point choisi : date et heure de la copie restaurée	Mesurer la perte réelle
Périmètre : données, pièces jointes, paramètres et exclusions	Éviter une réussite trompeuse
Durée : début, étapes, attentes et retour utilisable	Comparer au délai cible
Contrôles : comptages, échantillons, liens, droits et journaux	Prouver l’intégrité fonctionnelle
Écarts : gravité, responsable, échéance et nouveau test	Fermer la boucle d’amélioration

Choisir une cadence par le risque

Pour un petit cabinet, un test partiel trimestriel et un exercice plus large annuel peuvent former un point de départ pragmatique, mais ce n’est pas une prescription légale. Une évolution importante, une migration, un changement de prestataire, un échec d’alerte ou un incident justifient un test supplémentaire. Un système critique et très changeant peut exiger davantage ; une donnée stable peut être contrôlée autrement.

Le référentiel de mesures MonServiceSécurisé de l’ANSSI recommande de formaliser, mettre en œuvre et tester les procédures ; sa mesure 0116 mentionne un test a minima annuel. Le cabinet doit néanmoins relier sa propre cadence aux risques et à ses engagements, puis la revoir lorsque son système change.

Traiter un échec sans le maquiller

Un test qui échoue est utile s’il déclenche une correction. Classez l’écart : copie absente, délai dépassé, objet manquant, droit excessif, clé indisponible, procédure incompréhensible ou dépendance oubliée. Désignez un responsable, une échéance et un nouveau test ciblé. Ne remplacez pas le résultat initial ; conservez la chronologie qui montre la détection et la résolution.

Préparer la reprise après panne, perte ou rançongiciel

La restauration technique s’inscrit dans une décision plus large. En cas d’incident, il faut préserver les éléments utiles à l’analyse, isoler ce qui doit l’être, choisir un point de reprise sain et éviter de réintroduire la cause de la compromission. Le plan doit être coordonné avec la procédure perte, vol ou intrusion au cabinet.

Restaurer depuis une source de confiance

L’ANSSI rappelle, dans sa synthèse officielle sur la sauvegarde des systèmes d’information, qu’une sauvegarde peut contenir le vecteur de compromission. Après un rançongiciel, ne restaurez pas mécaniquement la copie la plus récente sur un système non assaini. Reconstituez l’environnement depuis des sources de confiance, vérifiez les configurations et analysez les données avant la reconnexion. Le point choisi peut être plus ancien que prévu si les copies récentes sont suspectes.

Organiser le mode dégradé

Préparez une procédure sobre pour connaître les rendez-vous essentiels, informer sans divulguer de données, noter temporairement le strict nécessaire et sécuriser ces notes. Définissez comment elles seront rapprochées après le retour du logiciel, par qui et avec quel contrôle des doublons. La CNIL recommande, dans sa fiche « Prévoir la continuité et la reprise d’activité », de tester le plan et de prévoir le retour à la normale, sans abaisser la sécurité sans analyse des nouveaux risques.

Évaluer aussi la violation de données

Selon la fiche CNIL « Violations de données personnelles : les règles à suivre », une destruction, une perte ou une altération de données personnelles peut constituer une violation, même sans divulgation. La disponibilité et l’intégrité comptent avec la confidentialité. Une restauration rapide peut réduire les conséquences, mais elle ne dispense pas d’analyser l’incident et, selon le risque, les obligations de documentation, de notification ou d’information. Séparez le rapport de restauration du registre d’incident, puis reliez-les par leurs références.

Gérer la rétention, la purge et le changement de logiciel

La sauvegarde ne crée pas un droit à conserver indéfiniment tout ce qui a été supprimé de la production. Sa rétention doit être définie, proportionnée et techniquement comprise. Pour préparer l’exercice du droit à l’effacement, la CNIL demande de prévoir l’effacement également dans les sauvegardes, ou une autre solution empêchant de restaurer les données effacées. Si le dispositif ne permet pas un effacement sélectif sans compromettre la copie, la procédure de reprise doit donc identifier les données exclues et réappliquer l’effacement avant toute remise en service. Cette organisation doit être documentée et validée selon le contexte et les exceptions légales applicables.

Construire une matrice de rétention

Pour chaque famille de copies, notez la fréquence, la durée, le mode de rotation, l’emplacement, le propriétaire et la procédure de destruction. Distinguez les sauvegardes courtes de reprise, les copies de sécurité isolées, les exports de migration et les archives. Vérifiez que l’augmentation d’une durée ne se fait pas silencieusement à la suite d’un changement d’offre.

Encadrer migration et fin de contrat

Lors d’un changement de logiciel de cabinet, plusieurs copies temporaires apparaissent : export source, fichiers de transformation, import de test et sauvegarde de retour arrière. Attribuez à chacune un emplacement, des accès et une date de suppression. Testez l’export avant la fermeture du service et obtenez les éléments contractuels prévus concernant la restitution et la suppression.

Ne supprimez pas l’ancien accès avant d’avoir rapproché les volumes, les pièces jointes, les historiques et un échantillon fonctionnel. À l’inverse, ne laissez pas indéfiniment l’ancien environnement en ligne « au cas où ». Le procès-verbal de migration doit fixer le moment où le retour arrière n’est plus raisonnable et où commence la purge contrôlée.

Plan d’action sur trente jours pour le cabinet

Semaine 1 : obtenir le périmètre et les engagements

1. Inventorier les systèmes, données, pièces jointes, configurations et dépendances.
2. Récupérer le contrat, la description de sauvegarde, les durées et le dernier compte rendu disponible.
3. Identifier les personnes qui reçoivent les alertes et autorisent une restauration.
4. Formuler la perte et l’interruption maximales acceptables pour les fonctions critiques.

Semaine 2 : confronter le dispositif aux scénarios

1. Dessiner les emplacements, supports, comptes et chemins d’administration.
2. Tester sur le papier une panne locale, une erreur de suppression et un compte compromis.
3. Vérifier la copie hors ligne, le site distant, le chiffrement et la récupération des clés.
4. Contrôler le périmètre HDS lorsque la chaîne entre dans son champ.

Semaine 3 : exécuter un test partiel

1. Créer le jeu fictif et écrire les critères de réussite.
2. Préparer l’environnement isolé et neutraliser les connecteurs sortants.
3. Restaurer un point daté, mesurer la durée et vérifier chaque relation.
4. Consigner les écarts sans effacer les résultats défavorables.

Semaine 4 : corriger et inscrire la routine

1. Traiter d’abord les écarts qui empêchent toute reprise ou exposent les données.
2. Rejouer le test ciblé après correction.
3. Planifier le prochain test, le contrôle mensuel des alertes et l’exercice large.
4. Ranger les preuves dans un espace accessible pendant une indisponibilité du système principal.

Checklist opérationnelle avant de déclarer la sauvegarde maîtrisée

• [ ] Les systèmes, données, pièces jointes, paramètres et dépendances sont inventoriés.
• [ ] Chaque élément critique a un propriétaire et un ordre de reprise.
• [ ] La perte maximale admissible est formulée en durée et en contenu.
• [ ] Le délai de reprise couvre le retour à un service vérifié, pas seulement le serveur.
• [ ] La fréquence et la rétention correspondent à ces objectifs.
• [ ] Les copies ne dépendent pas toutes du même support, lieu ou compte.
• [ ] Au moins une copie est distante du site d’exploitation.
• [ ] Au moins une copie est hors ligne ou isolée selon une mesure équivalente validée.
• [ ] Les différences entre hors ligne, immuable, réplication et historique sont comprises.
• [ ] Les sauvegardes et leurs transferts sont protégés selon le risque.
• [ ] La récupération des clés et secrets est documentée.
• [ ] Les comptes d’administration sont nominatifs, limités et protégés.
• [ ] Les alertes ont un destinataire, un suppléant et un délai de traitement.
• [ ] Le contrat précise inclusions, exclusions, restauration, rétention et fin de service.
• [ ] Le certificat HDS couvre la chaîne réellement utilisée lorsque le régime s’applique.
• [ ] Le scénario de test, la date cible et les critères sont écrits avant l’exercice.
• [ ] Le test utilise un environnement isolé et neutralise les envois externes.
• [ ] Les dossiers, pièces jointes, liens, paramètres et droits sont vérifiés.
• [ ] La durée complète de reprise est chronométrée.
• [ ] Le procès-verbal mentionne aussi les échecs et les exclusions.
• [ ] Chaque écart a un responsable, une échéance et un nouveau test.
• [ ] Le mode dégradé et le retour à la normale sont documentés.
• [ ] Une restauration après compromission prévoit une source propre et des contrôles.
• [ ] Les copies temporaires de migration ont une date de suppression.
• [ ] Les preuves restent accessibles si le logiciel principal est indisponible.

Le meilleur indicateur n’est donc pas le nombre de gigaoctets copiés, mais la capacité démontrée à retrouver les bonnes données, dans le bon état, avec les bons droits et dans le délai décidé. Si cette preuve manque, le prochain geste n’est pas d’acheter davantage de stockage : c’est de définir un scénario, de restaurer dans un espace isolé et de fermer les écarts observés.

Limites et suivi éditorial

Ce guide ne remplace ni une analyse de risques, ni les instructions du prestataire, ni l’intervention d’un professionnel de la sécurité lors d’un incident. Les propositions de cadence sont des points de départ opérationnels et non des obligations universelles. Toute architecture ou procédure de test doit être validée pour le système concerné ; aucune manipulation risquée ne doit être effectuée sur la production.

Sources contrôlées le : 29 août 2026. Prochaine revue prévue : 29 novembre 2026, ou plus tôt en cas d’évolution du guide CNIL, du référentiel HDS ou des recommandations de l’ANSSI.

Sources primaires

• CNIL — Sécurité : sauvegarder, fiche publiée le 14 mars 2024.
• CNIL — Prévoir la continuité et la reprise d’activité.
• CNIL — Cloud, informatique en nuage.
• CNIL — Violations de données personnelles : les règles à suivre.
• CNIL — Préparer l’exercice des droits des personnes.
• Union européenne — Règlement général sur la protection des données, article 32.
• ANSSI — Les essentiels : Sauvegarde des systèmes d’information, version 1.1.
• ANSSI — Référentiel de mesures MonServiceSécurisé.
• Agence du Numérique en Santé — Référentiel de certification HDS, version 2.0.

À lire ensuite

• Préparer la réaction du cabinet face à une perte, un vol ou une intrusion
• Vérifier ce que le certificat HDS couvre réellement
• Changer de logiciel sans perdre les données ni les preuves
• Sécuriser les communications par SMS et e-mail avec les patients