Un système disponible répond quand on l’utilise. Un système fiable continue de fonctionner malgré un incident, ou retrouve vite un état normal après coup.

Surveiller la disponibilité d’un système ne dit rien de sa fiabilité : tant qu’il n’a pas été testé, on ne sait pas s’il repartira le jour où un incident survient pour de vrai.

Selon le rapport The True Cost of Downtime 2024 publié par Siemens, une heure d’arrêt non planifié peut coûter de plusieurs dizaines de milliers de dollars à plus de deux millions de dollars selon le secteur industriel.

Quelques heures d’arrêt suffisent donc à justifier une à deux journées d’investigation préventive.

Le scénario classique

La fameuse phrase :

« On n’a pas de problème, tout fonctionne. »

En général, elle est prononcée quelques semaines ou quelques mois avant qu’un incident ne révèle un dysfonctionnement.

Un mercredi, 14 h 17, le serveur principal cesse de répondre. La production ralentit, puis s’arrête. L’équipe informatique intervient tout de suite : les sauvegardes existent, enfin c’est ce que dit le logiciel. Le fichier sauvegardé s’avère inexploitable.

La restauration échoue. On tente une sauvegarde plus ancienne, même résultat.

Quelqu’un demande alors qui connaît la procédure de redémarrage.

Silence : Bernard, l’administrateur qui a installé le serveur, est parti à la retraite deux ans plus tôt. Les mots de passe ne sont documentés nulle part, les scripts sont stockés dans son ancien profil utilisateur, les licences sont introuvables.

Quelques heures plus tôt, tout fonctionnait. Le problème n’est pas la panne elle-même. Le problème, c’est que personne n’avait remarqué que le système était devenu impossible à reprendre.

Pourquoi un tableau de bord vert ne suffit pas

Imaginez une voiture qui démarre tous les matins, dont le moteur tourne et dont les freins répondent. Tout semble normal.

Pourtant, aucun contrôle des freins ni remplacement de courroie n’a eu lieu depuis cinq ans. Diriez-vous qu’elle est fiable ? Non.

Ce que le tableau de bord ne montre pas

Le serveur démarre, le MES (le logiciel qui pilote et trace la production, Manufacturing Execution System) répond, les tableaux de bord sont verts, les sauvegardes affichent « succès ».

Le constat immédiat est que le service tourne.

Non : ça fonctionne aujourd’hui. Ce n’est pas la même chose.

On surveille le CPU, la mémoire, les disques, les services Windows et l’exécution des sauvegardes. On vérifie plus rarement :

  • qu’une sauvegarde peut réellement être restaurée ;
  • qu’une autre personne que l’administrateur habituel peut reconstruire le système ;
  • que la documentation correspond à la réalité du terrain ;
  • que la reprise après incident a déjà été testée en conditions réelles.

Un tableau de bord entièrement vert ne garantit donc rien sur la capacité à repartir après un vrai incident.

Des défaillances silencieuses

Ce qui rend le problème difficile à voir venir, c’est que les défaillances sérieuses sont silencieuses. Une sauvegarde inutilisable ne fait aucun bruit.

Un certificat qui expire dans quinze jours ne déclenche aucune alarme. Une dépendance oubliée continue de fonctionner.

Jusqu’au jour où plusieurs événements coïncident : le serveur redémarre, le certificat expire, le contrôleur de domaine devient indisponible. C’est à ce moment précis qu’un système qui semblait robuste révèle toutes ses fragilités d’un coup, en paralysant l’activité au passage.

Le trio de choc

Les mêmes problèmes ressortent quasi systématiquement, sous trois formes.

1. Les sauvegardes jamais restaurées

Le logiciel indique « sauvegarde réussie ». Pourtant, aucune restauration complète à blanc n’a été testée depuis le déploiement.

Le jour où le disque tombe en panne, on découvre que certaines bases n’ont jamais été sauvegardées, que les snapshots sont incohérents, ou que les fichiers sont corrompus et donc inutilisables.

Une sauvegarde n’a qu’un seul objectif : pouvoir être restaurée. Tout le reste, y compris le message « succès » affiché par le logiciel, n’est qu’un indicateur indirect.

2. Le système tient grâce à une seule personne

Ce n’est presque jamais volontaire. Au fil des années, une personne accumule les connaissances : elle connaît les mots de passe, sait dans quel ordre redémarrer les services, comprend les exceptions du système.

Puis elle quitte l’entreprise. À cet instant, le système devient un risque silencieux, non pas parce qu’il est mauvais, mais parce qu’il dépend désormais d’une mémoire humaine qui vient de partir.

3. Une dette technique devenue invisible

Les systèmes industriels vivent longtemps, souvent plus d’une dizaine d’années. Pendant cette durée, on ajoute une interface ici, un automate là, une nouvelle base SQL, une passerelle MQTT, quelques scripts pour combler un manque ponctuel.

Chaque ajout est justifié sur le moment, mais la cohérence d’ensemble n’est plus maintenue. Petit à petit, le système se complexifie et perd toute lisibilité d’architecture.

Ce qu’apporte un cadrage technique de fiabilité

Un état des lieux de fiabilité ne consiste pas à chercher des bugs.

Il répond à des questions concrètes : combien de temps faut-il pour reconstruire un serveur critique, les sauvegardes ont-elles déjà été restaurées avec succès, quelles sont les dépendances invisibles du système ?

Qui détient les connaissances critiques, et quels sont les véritables points de rupture ?

Le résultat n’est pas un rapport de cent pages, mais une vision claire des risques réels, priorisée par gravité et par facilité de correction. Le coût d’un cadrage technique est connu à l’avance : une ou deux journées.

Le coût d’un incident ne l’est jamais, et il peut immobiliser une production pendant plusieurs jours. C’est précisément cette asymétrie qui rend le déni dangereux : on connaît le prix de la prévention, jamais celui de l’attente.

La vraie question n’est pas « est-ce que mon système fonctionne aujourd’hui ? » C’est : « si tout s’arrête dans une heure, serai-je capable de repartir demain matin ? »

Si la réponse n’est pas immédiate, documentée et démontrable, le système fonctionne peut-être, mais sa fiabilité reste à prouver.

Ce que je vérifierais si j’arrivais chez vous demain

Avant même de parler d’évolution ou de modernisation, voici les questions auxquelles je chercherais à répondre en premier :

  • Les sauvegardes ont-elles déjà été restaurées avec succès, en conditions réelles ?
  • Existe-t-il une procédure documentée de reprise après incident ?
  • Les dépendances critiques du système sont-elles toutes connues et listées ?
  • Une autre personne que l’administrateur habituel peut-elle reprendre le système sans aide ?
  • Les comptes techniques et les services associés sont-ils identifiés et maîtrisés ?

Si une seule réponse est « je ne sais pas », il existe probablement un risque qui mérite d’être évalué sérieusement.

Questions fréquentes

Une sauvegarde réussie garantit-elle une restauration possible ?

Non. Seule une restauration complète, testée en conditions réelles, permet de valider qu’une sauvegarde est réellement exploitable le jour où on en a besoin.

Faut-il arrêter la production pour réaliser cet état des lieux ?

Non. Le cadrage technique s’appuie sur l’analyse de l’existant (configurations, procédures, historiques de sauvegarde, entretiens avec les équipes) sans modifier ni perturber les environnements de production en cours, ainsi qu’un test de restauration sur un environnement isolé, jamais sur la production.

Qu’est-ce qui différencie ce cadrage d’un audit de cybersécurité ?

La cybersécurité cherche à savoir si le système est vulnérable face aux attaques extérieures. L’analyse de fiabilité cherche à savoir si le système est capable de survivre à un incident interne (panne matérielle, perte de compétences, corruption de données) et de repartir rapidement.

Les deux sont complémentaires, mais répondent à des risques différents.

Combien de temps dure ce cadrage technique ?

Le cadrage technique se réalise en une à deux journées, suivies de la restitution d’une cartographie et des risques identifiés.

À retenir

  • Un système disponible n’est pas forcément fiable : la disponibilité mesure le présent, la fiabilité mesure la capacité à encaisser un incident.
  • Une sauvegarde n’a de valeur que si sa restauration a été testée, pas seulement affichée comme réussie.
  • La connaissance tacite, portée par une seule personne, est un risque technique au même titre qu’une panne matérielle.
  • La dette technique devient dangereuse le jour où elle devient invisible, faute d’une vue d’ensemble régulière du système.

C’PRAG commence par un cadrage technique : l’état des lieux de la fiabilité réelle de votre système.

L’approche pragmatique

  • Test réel de restauration.
  • Identification des dépendances invisibles.
  • Évaluation de la reprenabilité par un tiers.
  • Restitution priorisée des points de rupture.

En une à deux journées, sans interrompre la production.

Réservez un échange préalable de 15 minutes pour en parler : le premier test de restauration révèle presque toujours ce que le tableau de bord ne montre pas.

Sources