Pourquoi un système qui fonctionne n'est pas forcément un système fiable
Pourquoi un système qui fonctionne n'est pas forcément un système fiable
Un système peut fonctionner pendant dix ans... et être incapable de redémarrer demain matin.
C'est la différence entre la disponibilité et la fiabilité.
Et cette différence peut représenter un coût considérable lorsqu'un incident survient.
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.
Au fil de mes interventions sur des systèmes industriels, une même phrase revient inlassablement :
On n'a pas de problème, tout fonctionne.
En général, cette phrase est prononcée quelques semaines ou quelques mois avant qu'un incident ne révèle ce que personne ne voulait regarder.
Quelle que soit l'activité, une chose est constante : quelques heures d'arrêt suffisent à justifier plusieurs jours d'investigation préventive.
Le piège du ça marche
Imaginez une voiture.
Elle démarre tous les matins.
Le moteur tourne.
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 ?
Évidemment non.
Pourtant, c'est exactement ainsi que sont gérés de nombreux systèmes industriels.
Le serveur démarre.
Le MES répond.
Les tableaux de bord sont verts.
Les sauvegardes affichent Succès.
Alors tout le monde conclut :
Ça fonctionne.
Non.
Ça fonctionne aujourd'hui.
Ce n'est pas la même chose.
Le jour où tout change
Mercredi.
14 h 17.
Le serveur principal cesse de répondre.
La production ralentit.
Puis s'arrête.
L'équipe informatique intervient immédiatement.
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 pas documentés.
Les scripts sont stockés dans son profil utilisateur.
Les licences sont introuvables.
Quelques heures plus tôt, tout fonctionnait.
Quelques heures plus tard, plus personne ne maîtrise le système.
Le problème n'est pas la panne.
Le problème est que personne n'avait réalisé que le système était devenu impossible à reprendre.
Disponibilité ≠ Fiabilité
Un système disponible répond lorsqu'on l'utilise.
Un système fiable continue à fonctionner malgré un incident ou retrouve rapidement un état nominal après celui-ci.
Cette différence paraît subtile.
Elle ne l'est pas.
Beaucoup d'entreprises surveillent :
- le CPU ;
- la mémoire ;
- les disques ;
- les services Windows ;
- les sauvegardes.
Très peu vérifient :
- qu'une sauvegarde peut réellement être restaurée ;
- qu'une autre personne peut reconstruire le système ;
- que la documentation correspond encore à la réalité ;
- que les dépendances sont connues ;
- que la reprise a déjà été testée.
Un tableau de bord entièrement vert ne garantit absolument rien.
Les trois fragilités que je retrouve le plus souvent
Au fil de mes interventions, les mêmes problèmes reviennent systématiquement.
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 ;
- les snapshots sont incohérents ;
- les fichiers sont corrompus ;
- les sauvegardes sont inutilisables.
Une sauvegarde n'a qu'un seul objectif :
Pouvoir être restaurée.
Tout le reste n'est qu'un indicateur.
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.
Elle sait dans quel ordre redémarrer les services.
Elle comprend les exceptions.
Puis elle change de poste.
Ou quitte l'entreprise.
À cet instant, le système devient un risque.
Non parce qu'il est mauvais.
Parce qu'il dépend désormais d'une mémoire humaine.
3. Une dette technique devenue invisible
Les systèmes industriels vivent longtemps.
Très longtemps.
Pendant dix ou quinze ans, on ajoute :
- une interface ;
- un automate ;
- une nouvelle base SQL ;
- une passerelle MQTT ;
- quelques scripts.
Chaque ajout est justifié.
Mais personne ne regarde l'ensemble.
Petit à petit, le système devient si complexe que plus personne ne comprend réellement son fonctionnement.
Pourquoi personne ne voit venir le problème
Les défaillances sérieuses sont silencieuses.
Une sauvegarde inutilisable ne fait pas de bruit.
Un certificat expirant dans quinze jours ne déclenche pas d'alarme.
Une dépendance oubliée continue de fonctionner.
Tout paraît normal.
Jusqu'au jour où plusieurs événements surviennent simultanément.
Le serveur redémarre.
Le certificat expire.
Le contrôleur de domaine devient indisponible.
Et soudain, un système qui semblait robuste révèle toutes ses fragilités.
Ce qu'apporte un diagnostic de fiabilité
Un diagnostic ne consiste pas à chercher des bugs.
Il répond à des questions essentielles.
- Combien de temps faut-il pour reconstruire un serveur critique ?
- Les sauvegardes ont-elles déjà été restaurées ?
- Quelles sont les dépendances invisibles ?
- Qui détient les connaissances critiques ?
- Quels sont les véritables points de rupture ?
Le résultat n'est pas un rapport de cent pages.
C'est une vision claire des risques.
Vous savez :
- où agir ;
- dans quel ordre ;
- et pourquoi.
Vous cessez de piloter votre système à l'intuition.
Le coût du déni
Un diagnostic représente une ou deux journées.
Un incident peut immobiliser une production pendant plusieurs jours.
Le coût du diagnostic est connu.
Celui de l'incident ne l'est jamais.
Et c'est précisément ce qui le rend dangereux.
Ce que je vérifierais si j'arrivais chez vous demain
Avant même de parler d'évolution ou de modernisation, je chercherais à répondre à cinq questions.
✅ Les sauvegardes ont-elles déjà été restaurées avec succès ?
✅ Existe-t-il une procédure documentée de reprise après incident ?
✅ Les dépendances critiques sont-elles connues ?
✅ Une autre personne peut-elle reprendre le système sans aide ?
✅ Les comptes techniques et les services sont-ils maîtrisés ?
Si une seule réponse est je ne sais pas, il existe probablement un risque qui mérite d'être évalué.
Questions fréquentes
Une sauvegarde réussie garantit-elle une restauration ?
Non. Seule une restauration complète permet de valider qu'une sauvegarde est réellement exploitable.
À quelle fréquence réaliser un diagnostic ?
Tous les deux à trois ans, ou avant une migration, une évolution importante ou un changement d'équipe.
Combien de temps dure un diagnostic ?
La plupart des diagnostics de fiabilité peuvent être réalisés en une à deux journées, suivies d'une restitution priorisée.
En conclusion
On n'attend pas qu'un pont s'effondre pour l'inspecter.
On n'attend pas qu'une chaudière explose pour la contrôler.
On ne devrait pas attendre qu'un serveur critique tombe pour découvrir comment il fonctionne.
La vraie question n'est pas :
Est-ce que mon système fonctionne ?
La vraie question 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, alors votre système fonctionne peut-être… mais vous ne savez pas encore s'il est réellement fiable.
Nous reviendrons dans un prochain article sur une erreur fréquente : confondre une sauvegarde réussie avec une restauration réellement possible.
À retenir
- Un système disponible n'est pas forcément fiable.
- Une sauvegarde n'est utile que si elle peut être restaurée.
- La connaissance tacite est un risque technique.
- La dette technique devient dangereuse lorsqu'elle est invisible.
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.