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

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)