Sauriez-vous reconstruire votre informatique après un sinistre ?

Restaurer des données ne suffit pas. Sans les configurations et sans la documentation, la remise en route se compte en jours plutôt qu'en heures.

Restaurer les données ne suffit pas à redémarrer une entreprise. Il faut aussi remonter les serveurs, reconfigurer le pare-feu, retrouver les paramètres des applications métier et rebrancher les liaisons avec les machines de production.

C'est ce travail-là qui transforme une reprise annoncée en quelques heures en une remise en route de plusieurs jours. Les données sont revenues, mais rien ne sait plus les utiliser.

Ce qu'il faut conserver en plus des données

Les configurations des équipements réseau et du pare-feu arrivent en premier. Un pare-feu reconstruit de mémoire prend une journée et laisse des trous, alors qu'une configuration exportée se réinjecte en quelques minutes.

Les paramètres des applications métier ensuite, qui vivent souvent en dehors de la base de données. Ce sont eux qui portent les circuits de validation, les formats de documents et les interconnexions.

Les certificats et les clés de licence, dont l'absence bloque le redémarrage d'un logiciel pourtant correctement restauré.

Les scripts et les tâches automatiques enfin, ces petits programmes écrits il y a des années qui transfèrent un fichier chaque nuit et dont plus personne ne connaît l'existence tant qu'ils fonctionnent.

La documentation qui sert réellement

Une documentation exhaustive et périmée est inutile. Une documentation courte et à jour vaut beaucoup.

Quatre éléments suffisent dans une PME. Un schéma du réseau, même dessiné à la main, montrant ce qui est relié à quoi. La liste des serveurs et de ce qu'ils font. Les coordonnées des contacts, éditeurs, prestataires, opérateur, avec les numéros de contrat. Et l'ordre de redémarrage des systèmes.

Ce dernier point est celui qu'on oublie et qui coûte le plus. Redémarrer une application avant sa base de données, ou la supervision avant le réseau, produit des erreurs difficiles à diagnostiquer quand tout le monde attend.

Le stockage de cette documentation

Une documentation conservée uniquement sur le serveur de fichiers de l'entreprise disparaît en même temps que lui. C'est un cas rencontré régulièrement après un rançongiciel.

Elle doit exister ailleurs, hors ligne ou dans un service indépendant de votre infrastructure, et elle doit être accessible sans les identifiants qui viennent d'être compromis.

Une copie imprimée des informations essentielles, rangée dans un endroit sûr, n'est pas ridicule. C'est parfois la seule chose qui reste consultable pendant les premières heures d'un incident majeur.

La configuration de référence

Une PME accumule des postes et des serveurs configurés chacun un peu différemment, selon qui les a installés et à quelle époque. Cette diversité rend chaque intervention plus longue et chaque diagnostic plus incertain.

Définir une configuration de référence, même sommaire, apporte deux choses. Une réinstallation devient rapide et prévisible. Et un écart devient visible, ce qui est le point de départ de la détection d'une anomalie.

Il n'est pas nécessaire d'outiller cela dans une PME. Une image de référence tenue à jour deux fois par an et une courte liste de ce qui doit être configuré suffisent.

Ce qui dérive et pourquoi

Les configurations s'écartent de la référence pour de bonnes raisons, un dépannage, une exception accordée à un utilisateur, un test qui n'a jamais été défait.

Ces écarts ne sont pas graves individuellement. Ils le deviennent par accumulation, parce que plus personne ne sait ce qui est volontaire et ce qui est accidentel, et parce qu'ils incluent presque toujours des règles ouvertes en urgence et jamais refermées.

C'est le lien direct avec le registre des changements, qui permet de savoir si un écart constaté correspond à une décision ou à un oubli.

Le test qui valide tout le reste

La seule preuve qu'une reconstruction est possible est de l'avoir faite. Restaurer un serveur complet dans un environnement séparé, une fois par an, révèle les manques bien mieux que toute revue documentaire.

L'exercice découvre systématiquement des dépendances non documentées, une licence liée à une adresse matérielle, un mot de passe que seul l'ancien prestataire connaissait, un service tiers qui n'accepte les connexions que depuis une adresse précise.

Ce test se prépare, il mobilise une demi-journée, et il vaut tous les audits.

Ce qui suffit dans une petite structure

Une revue annuelle convient, à condition d'être réellement conduite. Elle vérifie que les configurations des équipements sont exportées et conservées hors ligne, que la documentation courte est à jour, et que l'ordre de redémarrage est écrit.

L'exercice de reconstruction annuel complète le dispositif. Ensemble, ils font la différence entre une reprise maîtrisée et une improvisation sous pression.

Questions fréquentes

Sauvegarder les données ne suffit-il pas ?

Non, car les données seules ne redémarrent rien. Il faut également les configurations des équipements réseau et du pare-feu, les paramètres des applications, les certificats et les licences, ainsi que les tâches automatiques. Sans ces éléments, une restauration réussie aboutit à des données présentes que plus aucun système ne sait exploiter.

Où conserver la documentation technique ?

Ailleurs que sur l'infrastructure qu'elle décrit, ce qui exclut le serveur de fichiers de l'entreprise. Elle doit rester accessible sans les identifiants susceptibles d'être compromis. Une copie hors ligne, voire imprimée pour les informations essentielles, est souvent la seule chose consultable durant les premières heures d'un incident majeur.

Faut-il un outil de gestion de configuration en PME ?

Rarement. Une image de référence tenue à jour deux fois par an, une courte liste de ce qui doit être configuré et l'export régulier des configurations d'équipements couvrent l'essentiel. Les outils d'automatisation deviennent utiles quand le nombre de serveurs rend le travail manuel disproportionné.

Quel est l'élément le plus souvent oublié ?

L'ordre de redémarrage des systèmes. Relancer une application avant sa base de données, ou la supervision avant le réseau, produit des erreurs difficiles à diagnostiquer au moment précis où tout le monde attend. Cet ordre s'écrit en quelques lignes et fait gagner des heures.

Un sujet qui vous concerne ?

Un échange sans engagement, pour parler de vos enjeux et repérer ce qui mérite d'être traité en premier.

Nous contacter