Pourquoi un système qui fonctionne n'est pas forcément un système fiable

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.
La plupart des systèmes industriels sont surveillés pour leur disponibilité, jamais testés pour leur fiabilité, ce qui les rend vulnérables au 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 plusieurs jours d'investigation préventive.

Un scénario qui revient souvent

Au fil des interventions sur des systèmes industriels, une phrase revient sans cesse : "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 ce que personne ne voulait regarder.

Un mercredi, 14h17, 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.
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 : le seul administrateur qui savait reconstruire le serveur est parti 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, personne n'a changé les freins, contrôlé les pneus ou remplacé la courroie depuis cinq ans. Diriez-vous qu'elle est fiable ? Non, évidemment.

C'est pourtant ainsi que sont gérés de nombreux systèmes industriels : 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". Alors tout le monde conclut que ça fonctionne.
Non : ça fonctionne aujourd'hui. Ce n'est pas la même chose.

La plupart des entreprises surveillent le CPU, la mémoire, les disques, les services Windows et l'exécution des sauvegardes. Très peu vérifient 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 encore à la réalité du terrain, ou 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.

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.

Les trois fragilités qui reviennent le plus souvent

Au fil des interventions, les mêmes problèmes reviennent systématiquement, sous trois formes.

1. Les sauvegardes jamais restaurées

Le logiciel indique "sauvegarde réussie", tout le monde est rassuré. Pourtant, personne n'a tenté une restauration complète depuis plusieurs années. 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 change de poste ou quitte l'entreprise. À cet instant, le système devient un risque, 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 dix ou quinze ans. 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 personne ne regarde l'ensemble qui en résulte. Petit à petit, le système devient si complexe que plus personne ne comprend réellement son fonctionnement global.

Ce qu'apporte un diagnostic de fiabilité

Un diagnostic 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 diagnostic 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.

À quelle fréquence faut-il réaliser un diagnostic de fiabilité ?

Tous les deux à trois ans dans un contexte stable, ou avant une migration, une évolution importante du système, ou un changement d'équipe technique.

Combien de temps dure un diagnostic de fiabilité ?

La plupart des diagnostics se réalisent en une à deux journées, suivies d'une restitution priorisée 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 réalise des diagnostics de fiabilité sur les systèmes d'information industriels : test réel de restauration, identification des dépendances invisibles, évaluation de la reprenabilité par un tiers, et restitution priorisée des points de rupture. En une à deux journées, sans interrompre la production.

Prenez rendez-vous pour un diagnostic de votre existant : le premier test de restauration révèle presque toujours ce que le tableau de bord ne montre pas.

Sources

• Siemens. The True Cost of Downtime 2024.
• Microsoft Learn - SQL Server Backup and Restore Documentation.
• Les exemples présentés dans cet article sont inspirés de situations réelles rencontrées sur des systèmes industriels. Ils ont été anonymisés et, lorsque nécessaire, adaptés afin de préserver la confidentialité des organisations concernées.