Une entreprise peut posséder un plan de reprise soigneusement documenté, effectuer des sauvegardes quotidiennes et rester pourtant très vulnérable à une panne majeure ou à une cyberattaque. Entre ce qui existe sur le papier et ce qui fonctionne réellement sous pression, l’écart est parfois considérable. La résilience d’un système d’information se vérifie donc sur le terrain. Elle dépend autant des solutions techniques que des délais de reprise, des personnes disponibles et des dépendances oubliées. Plusieurs contrôles permettent d’obtenir une vision beaucoup plus réaliste de cette capacité à encaisser un incident.
Ne pas confondre PCA, PRA et politique de sauvegarde
Le plan de continuité d’activité, ou PCA, vise à maintenir les fonctions essentielles lorsque les conditions habituelles ne sont plus réunies. Une équipe peut, par exemple, continuer certaines opérations avec des outils réduits ou des procédures temporaires. Le PRA intervient davantage sur le retour à un fonctionnement informatique acceptable après l’incident. Les deux dispositifs se complètent : l’un aide l’entreprise à tenir pendant la perturbation, l’autre organise la remise en service des ressources nécessaires.
Les sauvegardes jouent un autre rôle. Elles fournissent des copies de données, de configurations ou de systèmes qui pourront servir lors de la restauration, mais elles ne constituent pas à elles seules un PRA. Disposer de plusieurs téraoctets sauvegardés ne dit rien sur le temps nécessaire pour reconstruire un serveur, rétablir les accès ou relancer une application métier. Pour juger la résilience réelle, il faut donc regarder l’ensemble de la chaîne, depuis l’activité à préserver jusqu’au retour effectif du service.
Partir des activités que l’entreprise ne peut pas laisser à l’arrêt
Toutes les applications ne méritent pas le même niveau de protection. Une plateforme utilisée pour traiter les commandes peut devenir critique après quelques minutes d’interruption, alors qu’un outil d’archivage interne peut supporter une indisponibilité bien plus longue. L’analyse commence donc côté métier. Il faut déterminer quelles activités doivent continuer, lesquelles peuvent fonctionner temporairement de façon dégradée et combien de temps l’organisation peut raisonnablement supporter leur arrêt.
Ce travail permet ensuite de remonter vers les applications, les données et les équipements dont chaque activité dépend. Une priorité affichée comme « critique » sans justification opérationnelle apporte finalement peu d’informations. La question utile reste beaucoup plus concrète : que se passe-t-il si ce service disparaît pendant deux heures, une journée ou trois jours ? Les conséquences financières comptent, mais aussi les engagements clients, les obligations contractuelles, la sécurité des personnes, la réputation ou encore l’impossibilité pour les salariés de travailler.
Vérifier si les objectifs RTO et RPO correspondent vraiment au terrain
Deux indicateurs reviennent souvent dans les plans de reprise. Le RTO correspond au délai visé pour remettre un service en fonctionnement après son interruption. Le RPO indique, en temps, la quantité de données que l’entreprise accepte éventuellement de perdre. Un RPO de quatre heures suppose ainsi que revenir à un état des données vieux de quatre heures reste supportable. Ces objectifs doivent provenir des besoins réels de l’activité, et non des seules performances annoncées par les outils informatiques.
Le problème apparaît lorsque les délais inscrits dans le PRA n’ont jamais été confrontés à une restauration complète. Une entreprise peut viser quatre heures de reprise alors que le téléchargement des données, leur contrôle puis le redémarrage des applications en réclament douze. Pour obtenir un regard extérieur sur ces écarts, contacter une entreprise de conseil informatique à Paris peut notamment permettre d’auditer l’architecture, les procédures et les engagements de reprise. L’essentiel reste cependant de mesurer des délais observés et non de conserver des objectifs purement théoriques.
Examiner ce que les sauvegardes protègent réellement
Un tableau de supervision rempli de voyants verts peut donner une fausse impression de sécurité. La première vérification concerne le périmètre : les bases de données sont-elles toutes sauvegardées ? Qu’en est-il des configurations réseau, des machines virtuelles, des données hébergées dans des services cloud ou des paramètres nécessaires aux applications ? Oublier une petite composante technique suffit parfois à rendre une restauration beaucoup plus longue, voire à empêcher temporairement le redémarrage d’un service pourtant correctement sauvegardé.
La protection des copies mérite le même examen. Si un compte administrateur compromis permet de supprimer à la fois les données de production et leurs sauvegardes, la stratégie montre une faiblesse évidente. Une partie des copies doit pouvoir résister à ce scénario grâce à une séparation suffisante, par exemple avec un stockage hors ligne ou des sauvegardes rendues non modifiables pendant une période définie. Leur chiffrement et le contrôle des accès réduisent également le risque qu’une copie destinée au secours devienne elle-même une source de fuite.
Tester la restauration plutôt que la simple création des copies
Une sauvegarde réussie signifie essentiellement que l’outil a enregistré quelque chose sans signaler d’erreur majeure. Cela ne prouve pas que les fichiers seront exploitables le jour où l’entreprise en aura besoin. Un test de restauration doit aller plus loin : récupérer les données, vérifier leur intégrité, reconstruire l’environnement nécessaire et confirmer que l’application fonctionne correctement. Sur les services les plus sensibles, le test doit aussi permettre de chronométrer les différentes étapes.
Les conditions retenues doivent rester proches d’un véritable incident. Restaurer quelques fichiers sur le serveur habituel apporte une information limitée si le scénario redouté suppose justement que ce serveur soit indisponible. Il peut être préférable de reconstruire le service dans un environnement distinct, avec des personnes qui ne connaissent pas chaque procédure par cœur. Les défauts deviennent alors visibles : identifiants introuvables, documentation dépassée, volume de données trop important, logiciel manquant ou séquence de redémarrage mal maîtrisée.
Rechercher les dépendances qui peuvent bloquer toute la reprise
Un service informatique fonctionne rarement seul. Une application peut dépendre d’un annuaire d’utilisateurs, d’un serveur DNS qui traduit les noms en adresses réseau, d’un accès internet, de certificats numériques ou d’une base de données hébergée ailleurs. Restaurer l’application sans ces composants ne suffit donc pas. Cette réalité explique pourquoi une cartographie des dépendances apporte souvent davantage qu’un simple inventaire des serveurs. Elle montre surtout dans quel ordre les éléments doivent revenir.
Certaines dépendances sont moins visibles parce qu’elles se trouvent chez des prestataires. Une solution cloud peut être disponible alors que la connexion permettant d’y accéder est coupée. Un fournisseur peut restaurer ses infrastructures sans garantir immédiatement toutes les fonctions utilisées par votre entreprise. Les contrats, licences, systèmes d’authentification, télécommunications et moyens de contact doivent alors entrer dans l’analyse. Le véritable point faible n’est pas toujours l’équipement le plus complexe : c’est parfois un service secondaire dont tout le reste dépend sans que personne ne l’ait clairement identifié.
S’assurer que le mode dégradé est réellement utilisable
Le PCA prend toute sa valeur lorsque l’informatique habituelle devient inaccessible. Certaines tâches peuvent continuer avec une procédure simplifiée, un autre outil ou même un traitement manuel temporaire. Encore faut-il que cette solution soit praticable. Prévoir que les équipes prendront les commandes par téléphone n’aide guère si les numéros des clients ne sont accessibles que dans l’application indisponible. Le fonctionnement dégradé doit donc être testé avec les mêmes contraintes que celles envisagées pendant la crise.
Les personnes représentent ici une composante essentielle de la résilience. Une procédure connue d’un seul administrateur crée une dépendance aussi sérieuse qu’un serveur sans solution de remplacement. Les responsabilités et contacts d’urgence doivent rester accessibles même lorsque la messagerie ou l’annuaire interne sont indisponibles. Des exercices courts permettent de voir très vite où les équipes hésitent, quels documents leur manquent et quelles décisions remontent inutilement trop haut dans l’organisation.
Confronter le dispositif à un véritable scénario de cyberattaque
Une panne matérielle classique et une attaque informatique ne posent pas exactement les mêmes difficultés. Après un incendie ou une défaillance technique, restaurer le système aussi vite que possible constitue généralement l’objectif naturel. Face à un rançongiciel ou à une intrusion profonde, redémarrer trop rapidement peut au contraire remettre en ligne un environnement encore compromis. Il faut d’abord déterminer ce qui a été touché, isoler certaines ressources et rechercher un état suffisamment sain pour reconstruire les services.
Ce scénario change aussi la façon de tester les sauvegardes. Une copie techniquement exploitable peut contenir des fichiers malveillants ou une configuration déjà compromise si l’attaque a commencé bien avant sa détection. Le PRA doit donc pouvoir s’articuler avec les procédures de gestion d’incident et de crise. La reprise ne consiste plus seulement à retrouver des données : elle doit rétablir un système suffisamment fiable pour éviter une nouvelle compromission quelques heures après sa remise en service.
Mesurer la résilience à partir de preuves, puis corriger les écarts
La meilleure évaluation repose sur ce qui a réellement été démontré. Le délai obtenu lors du dernier exercice apporte plus d’informations qu’un RTO jamais testé. Le nombre de services critiques effectivement restaurés, l’âge de la dernière copie vérifiée ou les incidents rencontrés pendant un exercice donnent également une vision concrète. La résilience devient alors observable. Elle ne dépend plus seulement de documents déclarant que l’organisation dispose d’un PRA, d’un PCA et d’une solution de sauvegarde.
Cette démarche doit rester régulière, car le système d’information évolue sans cesse. Une migration vers le cloud, un nouvel outil métier ou un changement de prestataire peuvent créer une dépendance inconnue quelques mois auparavant. Après chaque exercice ou incident réel, les écarts méritent donc d’être intégrés aux plans puis corrigés. L’objectif n’est pas d’obtenir un dispositif figé et supposé parfait, mais de conserver une capacité de reprise cohérente avec l’activité telle qu’elle fonctionne réellement.
