Le plan de reprise que personne n’a jamais exécuté

La question la plus utile à poser à une DSI ne porte pas sur ses sauvegardes. Elle porte sur la dernière fois qu’une restauration complète d’un applicatif métier a été exécutée de bout en bout, chronomètre en main. La réponse est le plus souvent : jamais, ou il y a plusieurs années, sur un périmètre qui n’existe plus.

Les cinq écarts les plus fréquents

• Les copies restent accessibles depuis le domaine d’administration qu’elles sont censées protéger. Une compromission de l’annuaire emporte alors les sauvegardes avec le reste.
• Le périmètre sauvegardé a divergé du périmètre réel : des serveurs ajoutés au fil des projets n’appartiennent à aucune politique.
• La restauration dépend de procédures détenues par l’éditeur et non documentées en interne.
• Les délais de reprise sont déclarés mais jamais mesurés. L’écart entre l’objectif affiché et la durée constatée se compte souvent en jours.
• Le plan suppose des ressources — matériel, réseau, licences, personnes disponibles — qui ne sont réservées nulle part.

Ce qui rend une reprise crédible

L’isolement des copies

Immuabilité, comptes dédiés, séparation d’administration, copie hors ligne ou hors site. La règle des trois copies sur deux supports dont une hors site reste valable. Il faut lui ajouter une condition devenue décisive : une copie que l’administrateur du système sauvegardé ne peut pas supprimer.

Le test complet, pas le test de fichier

Restaurer un fichier prouve que la chaîne fonctionne. Restaurer un applicatif métier complet, avec sa base, ses dépendances et son authentification, prouve que la reprise est possible. Seul le second exercice révèle les procédures manquantes, et il en révèle à chaque fois.

Des délais définis par les métiers

Un délai de reprise global n’a pas de sens : les services n’ont pas la même tolérance. Le travail utile consiste à établir, service par service, ce qui doit redémarrer en premier et ce qui peut attendre. Cette discussion appartient aux métiers ; la DSI en est le rapporteur, pas l’arbitre.

Un exercice à faible coût

Une journée de test par an, sur un applicatif significatif, en environnement isolé, avec un chronomètre et un compte rendu écrit. C’est l’investissement le plus rentable de toute la démarche de continuité, et il produit systématiquement une liste d’écarts que ni l’audit documentaire ni les rapports de sauvegarde n’avaient révélés.

Le résultat attendu de ce test n’est pas de réussir, mais de savoir avant l’incident ce qui aurait échoué.