Pannes Informatiques : loi de Murphy ou effet Tchernobyl ?

L'exercice est difficile, étant donné le peu d’informations disponibles. Néanmoins, plusieurs commentaires s’imposent.

D’abord, un fait est frappant : les responsables de ces entreprises ne savent pas parler des pannes et les journalistes ne savent pas poser les bonnes questions ! Visiblement la culture de la production informatique est inexistante en France ! Il existe des gens qui croient encore sérieusement qu’un système à tolérance de panne ne peut jamais être impliqué dans une interruption de service ! Comme si l’on ne pouvait avoir d’accident avec une voiture sous prétexte qu’elle ne tombe pas en panne ! C’est la négation même du métier d’exploitant ! En bref, il suffirait de mettre dans un coin des machines qui marchent, avec des programmes fonctionnellement testés (voire…) et tout irait bien. Il n’y a pas de chauffeur ?

Deuxième remarque : « on ne connaît pas l’origine de la panne » est un leitmotiv inquiétant. Cela peut vouloir dire qu’on a accumulé des systèmes opérants sans système de contrôle. Les éléments en production ne renseignent donc pas sur leur état. Pas de nouvelle, bonne nouvelle ! C’est la négation même de la démarche de la production industrielle qui veut que l’on envisage que tout système peut et doit tomber en panne (Murphy). Il faut donc envisager ce que cela peut produire sur le service rendu. Malheureusement, il semble qu’on ne surveille pas ce qui doit l’être, car on ne sait pas ce qui est important en terme de service rendu. Le chauffeur de la voiture est aveugle !

Troisième point important, mais plus délicat : il semble que les actions d’évolution de systèmes (‘upgrade’), de mise à jour de correctifs, bref d’interventions sensibles sur les éléments de production aient tendance à être menées sans considération profonde des impératifs de service. Il ne semble pas que des notions industrielles comme les évaluations d’impact ou la capacité à mener des « retour-arrière » soient très élaborées. La conservation des capacités à produire serait donc quelquefois mise en danger. La capacité à reconstituer des états propres de données semble trop faible. A quoi sert alors d’avoir des systèmes coûteux à tolérance de panne dans ces conditions ? Le chauffeur n’a pas le permis !

Enfin dernier point, qui ne facilite pas la tâche au producteur et apporte une grosse circonstance atténuante. Nous sommes en présence d’environnements n-tiers complexes, avec de multiples plates-formes en interaction et en partie des automatismes transversaux. Il est très difficile d’avoir un environnement de test qui reproduise la réalité. Dit autrement, par opposition aux systèmes « traditionnels », il faut parfois tester en production, quitte à baisser la garde en terme d’automatisme (effet Tchernobyl). De plus, la pression concurrentielle pousse à mettre en production très vite de nouvelles applications, le risque est donc fort de voir se déclarer des incidents en exploitation.

Conclusion : produire un service, ce n’est pas uniquement avoir une « informatique qui marche » c’est aussi savoir quoi faire quand elle ne marche pas !