Duquesne Group Duquesne Group

English version
Recherche et Analyse

Pour éclairer les décideurs dans le domaine de la Continuité d'Activité et de la Sécurité de l'Information, Duquesne Group propose ses analyses et réflexions issues de ses réalisations concrètes en clientèle. Observation critique du terrain par nos experts, contacts permanents avec les principaux acteurs du domaine et expérience vécue dans nos missions de conseil sont nos principales sources. Contactez-nous pour en savoir +
French version
Research

To support decision makers in the management and optimisation of information systems, Duquesne Group delivers in-depth analyses of information technologies, their implementations and their markets. Our research is based on critical observation of the market by our analysts and their on-going contacts with the vendor community, together with hands-on, practical experience from our consulting work. Contact us to find out more


Pannes Informatiques : loi de Murphy ou effet Tchernobyl ?



Tout le monde garde en mémoire les récents déboires de France Télécom, Bouygues Télécom et de la SNCF avec leurs outils de production. Bref, 2004 restera peut-être comme l’ «annus horribilis » des pannes informatiques. Quelles constatations peut-on en tirer ?




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 !
E.B. Sirius
Dimanche 30 Septembre 2007

Home Home    Mail Mail    Print Print    Zoom + Zoom +    Zoom - Zoom -    Share Share


Dans la même rubrique :
< >

Mercredi 5 Octobre 2016 - 17:48 Attention : un SMCA n'est pas un PCA !


Duquesne Research Newsletter