Déboires de Voyages-sncf.com : encore un joli flou artistique

Régulations

Ce jeudi, le site n’était pas encore opérationnel à 100%. Tentatives d’explications

Les trois ingrédients habituels du genre sont là : l’utilisateur est perdu ; la communication de la SNCF ne traite pas vraiment le problème sur le fond et les journalistes extrapolent à tout va.

Essayons de ne pas tomber dans le même travers en regardant ces trois points !

-L’usager perdu : visiblement le panneau affiché sur le site était inadapté ; il est vrai qu’afficher un message du genre “nous sommes en panne et ne savons pas quand cela ira bien” n’est pas chose facile. Toutefois, les usagers de GoogleMail connaissent ces messages “nous vivons actuellement des problèmes de débit et ne pouvons pas garantir l’acheminement de vos messages” (ou équivalent) qui s’affichent en orange sur l’écran dès que quelque chose ne va pas. Il y a probablement côté SNCF un effort à faire pour adapter le message à l’incident et surtout pour mettre en garde l’usager sur l’impossibilité d’acheter son billet. La SNCF doit apprendre à se mettre à la place de l’usager ! Cela n’est pas nouveau.

-Deuxième ingrédient obligatoire du genre: le flou artistique sur les causes. On nous a dit : “une défaillance matérielle a empêché le démarrage d’un serveur” ou encore : “c’est une panne rare, mais cela arrive” (SNCF 8/08, grand classique déjà dit lors de la panne Bouygues). Entendu aussi sur France Info : “c’est une panne d’un type particulier, due à l’architecture ; on n’y peut rien”. Il est surprenant que dans une société d’ingénieurs comme la SNCF, on ne considère pas les défaillances possibles, les relations de cause à effets, qu’on ne trace pas des arbres de défaillance aboutissant à un calcul de fiabilité.

Car enfin, une panne qui peut arriver n’est pas rare ! On peut conclure aussi que l’architecture n’a pas été étudiée pour être fiable…pourquoi pas ? mais alors il faut se donner les moyens de réparer vite pour être disponible ! Enfin, l’architecture semble “subie”, ce qui en informatique est toujours un signe que les équipes Etudes sont plus fortes que les équipes de Production et négligent les contraintes opérationnelles. Attention ! Un bon “time to market” ne veut pas dire “quick & dirty”. Il faut probablement analyser les risques de panne à iso-architecture (si vraiment on ne peut pas la changer) et prévoir un plan de reprise rapide face aux pannes possibles.

-Troisième aspect : les hésitations de journalistes qui ont tendance à tout mélanger. Un hebdomadaire satyrique s’est fait l’écho d’une étude des risques liés à ce site de vente sur Internet. Et de se gausser de risque de fuite de données en laissant supposer qu’il y aurait peut-être à aller voir de ce côté là. Ne mélangeons pas tout ! analyser les risques et une démarche saine et courageuse !

Confondre risque et certitude c’est prêcher une forme d’obscurantisme de mauvais aloi au XXIème siècle. Mélanger risque de panne et risque de fuite de données c’est “du grand n’importe quoi”. Oui, il faut analyser les risques, tous les risques. La bonne question à se poser est de savoir si les risques opérationnels de l’informatique ont été étudiés ; il semble dans le cas actuel que si c’est le cas, les dispositifs de reprise sont défaillants.

On attend donc encore le jour ou face à une panne majeure, un prestataire pourra avertir correctement ses usagers dans un délai raisonnable, expliquer à peu près bien ce qui se passe (quitte à dire ‘on regarde’ au début) et avoir des journalistes conscients des enjeux face à lui.

_________

(*) E.Besluau : Duquesne Research

auteur de “management de la continuité d’activité” (éditions Eyrolles)


Lire la biographie de l´auteur  Masquer la biographie de l´auteur