Sécurité n’est pas sûreté

L’ambiance paranoïaque de notre monde actuel se reflête bien dans l’obsession sécuritaire et son cortège de solution de cryptage, d’antispam, pare-feux, etc… Mais la sécurité ne suffit pas et les pannes gérantes récentes en sont l’illustration.
Que s’est-il passé ? tout simplement un petit problème local qui devient le grain de sable qui fait s’effondrer le système par effet de dominos.
Chez France Télécom, c’est un système local, à Reims, qui sous le coup d’un “défaut logiciel” a fait tomber la moitié du réseau fixe.
Dans le cas de Bouygues, deux serveurs ont planté simultanément alors qu’ils étaient redondant pour supporter un pic de charge ou se relayer en cas d’incidence de l’un. Architecture hyper-classique s’il en est. Ce n’est qu’une hypothèse, mais si le premier serveur tombe à cause d’une requête pernicieuse, d’une corruption lambda ou d’un processus défaillant et que l’autre serveur reprenne le relais, il y a de bonne chance que les mêmes causes produisent les mêmes effets puisque ce sont deux clones. Total : l’ensemble s’écroule.
La mise en place de systèmes d’informations, ou même d’un simple “site” est un facteur très fort de dynamisme et de performance, mais on ne mesure pas assez la dépendance que cela entraîne. Comme toujours, on fait trop confiance et on ne s’assure pas assez. Ce n’est que quand le crash se produit que l’on regrette ne pas avoir pris les options… Il suffit qu’il y ait un blocage de quelques heures pour que ce soit la panique. L’info ne circule plus et avec un modèle de fonctionnement qui est maintenant en flux tendu, l’angoisse s’installe parce qu’évidemment les moyens de traçabilité et de supervision sont négligés. Et ne parlons même pas des sauvegardes !

Internet qui est une architecture non centralisée est peu sujet aux effets dominos, son problème c’est plus la surcharge. Il faut se méfier des systèmes centralisés, qui plus est quand ils gèrent des flux et il faut savoir se poser au départ quelques bonnes questions au départ. Un projet ne se limite pas à son développement, loin s’en faut. Tout cela a un coût mais prendrez-vous le risque ?

 avoir quelqu’un qui s’occupe (vraiment) des TIC, qui a mis en place des procédures, qui sait où se trouvent les choses, sur qui s’appuyer et quoi faire

 sauvegarder c’est essentiel, mais il faut aussi se soucier d’avoir procédé à une simulation pour être tranquille et savoir faire. C’est comme le plan d’évacuation incendie.

 redonder les machines c’est bien, mais cela ne suffit pas. Il faut se donner les moyens de la traçabilité, de la supervision pour gagner du temps dans le diagnostic et réagir.

 réagir, c’est aussi avoir les compétences sous la main. Avoir des ressources de maintenance c’est important et la régie ne concerne pas que les gros.

 accessoirement, ce type de risque s’assure et il y a des assureurs pour cela. La perte d’activité engendrée par un crash, ça compte !

Mais avant cela, il y a un point clé : s’investir dans son projet et investir ce qu’il faut dans la recette, dans des tests de montée en charge et de mise en situation critiques.
Quand vous budgetez un projet, pensez à tout cela et ne vous contentez pas de simplement acheter la réalisation. Faites-vous conseiller. Anticiper tout cela fait partie de l’assistance à maîtrise d’ouvrage. Réfléchissez-y.