Les pièges de la rapidité

1 Comment

La pression de l’époque fait qu’il faut développer de plus en plus vite des applications, programmes et logiciels. Une telle disposition n’est pas exempte de risques, car la rapidité implique que, souvent, l’impasse est faite sur les tests ou la sécurité.

L’exemple le plus récent est le SAIP (système d’alerte et d’information des populations dont le fonctionnement est précisé ici) que nous allons étudier un peu.

source.

Ainsi, un article du Monde détaille un peu les mésaventures de cette application qui s’est rendue tristement célèbre les 14 et 15 juillet derniers. Le journal nous apprend en effet que, Alors que la tuerie s’est déroulée vers 22 h 30, l’alerte n’a été publiée qu’à 1 h 34 dans la nuit du jeudi 14 au vendredi 15 juillet.
En terme de réactivité, on repassera. D’autant qu’il fallait que l’alerte soit transmise en 15 minutes maximum…

Ceci dit, quelles en sont les raisons ? Selon les informations déjà obtenues par Le Monde de sources concordantes, la défaillance de l’application chargée d’alerter la population en cas d’attentat s’explique par une succession de précipitations, de mauvaise communication et de malchance.

La précipitation

Première cause, puisqu’il a fallu livrer l’application en 2 mois, avant le début de l’euro. Il est vrai que tout le monde a été surpris par la date de début de l’euro, l’UEFA mettant en œuvre le célèbre adage : commander c’est surprendre… Que le travail effectué en un laps de temps aussi court soit digne de louanges est un fait vraisemblable (Ils ont fait un travail remarquable dans un délai très court », reconnaît Romain Pigenel, directeur adjoint en charge du numérique au Service d’information du gouvernement (SIG).), la responsabilité est sûrement ailleurs.

Le même article nous apprend que le cahier des charges très spécifique, les problématiques techniques et surtout le manque de temps ont contraint Deveryware à faire l’économie d’une solution de redondance – qui consiste à dupliquer son dispositif sur plusieurs serveurs pour assurer le fonctionnement de l’application en cas de panne de l’un d’entre eux. C’est certain. Quand on met la pression sur un prestataire, il ne peut pas forcément tout faire dans les règles de l’art.

L’absence de redondance

Comme la mise en place de la redondance était impossible dans le court laps de temps laissé à la société, exit la redondance.
Tout ceci sent déjà bon, si ce n’est l’amateurisme, du moins le réveil tardif. Flûte, flûte, un euro de football. En plus il y aura des supporters hooligans russes et anglais, des matches tendus paisibles comme Turquie Croatie (ils s’aiment d’amour, c’est connu)…

La malchance

Quand ça ne veut pas, ça ne veut pas. Le 13 juillet, un câble de fibre optique est sectionné lors de travaux de génie civil, provoquant la panne de l’hébergeur, et fatalement, celle de l’application. Ou la mise en application de la loi de la tartine beurrée… Allez trouver un réparateur le 13 juillet, ou pire le 14 puisque c’est le matin du 14 juillet, toutefois, que cette indisponibilité a été notifiée au fournisseur de l’application. Pas facile, non ?

La qualité de service

« Ils ont acheté une prestation dont le niveau d’engagement peut se traduire par deux heures d’indisponibilité par mois ». Oui, oui, personne ne plaisante, 2 heures d’indisponibilité par mois pour une application chargée de relayer les alertes attentat. 2 heures par mois, cela fait en moyenne 6 minutes par jour, ce qui est déjà pas mal. Imaginez le bouchon qui pourrait se créer dans une ville comme… Munich en 6 minutes si on ne déviait pas le trafic alors qu’une tuerie est en cours. Continuons les extrapolations. Les attentats en France ont eu lieu en 01/15 (2), 11/15 et 07/16, soit 4 en 20 mois, soit en moyenne un tous les 5 mois. 5 x 2 = 10, on peut arriver à une indisponibilité de 10 heures tous les 5 mois (la fréquence moyenne actuelle des attentats) sans que le prestataire soit inquiété puisqu’il respecte son contrat. Perplexité, non ?

Quelles leçons en tirer ?

  1. ne pas confondre vitesse et précipitation ;
  2. sortir une application rapidement s’effectue souvent au détriment de la sécurité ;
  3. un système critique ne peut suivre des règles de développement purement commerciales ;
  4. Jean de La Fontaine n’avait pas tort lorsqu’il écrivit le lièvre et la tortue : rien ne sert de courir, il faut partir à temps.
Categories: protection Étiquettes : ,

One Reply to “Les pièges de la rapidité”

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

four × = twenty eight