Une semaine après l’attentat de Nice, les circonstances du dysfonctionnement de l’app SAIP “Alerte attentat” commencent à être mieux connues. Cette app commandée par le gouvernement auprès d’une société tierce avait envoyé son premier message d’alerte à 1h34, dans la nuit du 14 au 15. Deux heures et demi après la fin de cet événement meurtrier.
Il avait été rapidement évoqué une « faille technique » et Le Monde apporte plus de détails aujourd’hui, une communication semble être également prévue à terme de la part du ministère de l’Intérieur.
Premier constat, le projet n’a pas été initié suffisamment en amont dans le temps. Le prestataire chargé de développer cette app — Deveryware — connaît son sujet mais il n’a eu que deux mois pour réaliser le logiciel (budget : 400 000 euros), celui-ci devant être prêt 48h avant l’ouverture de l’Euro 2016.
Un peu plus de 15 ingénieurs ont été affectés à sa création et plusieurs tests furent conduits en France sans rencontrer d’écueils.
Cependant, les conditions d’exécution de ce projet, ont poussé Deveryware à n’utiliser qu’un seul serveur pour faire fonctionner son service. Au lieu de prévoir des solutions de repli en cas de panne du système principal. C’est une filiale de SFR, Numergy, qui a assuré cet hébergement, sous le contrôle technique du ministère.
À ce premier faux pas s’est ajouté une combinaison de mauvaise communication et de malchance. Ce n’est que la veille de l’Euro que Numergy a été informé par Deveryware de la nature du service informatique qu’il hébergeait et de sa sensibilité. Le prestataire explique qu’il a insisté auprès de Deveryware pour qu’une redondance de cet hébergement soit prévue, chez lui ou chez un autre. Ce qui n’a pas été fait.
Le 13 juillet, veille de l’attentat, la section accidentelle d’un câble de fibre optique durant un chantier met en panne l’hébergeur et donc le système SAIP. Le 14 juillet, le service de Numergy est de retour en ligne mais c’est à ce moment seulement que Deveryware est prévenu. Il redémarre ses systèmes à son tour, cependant ce cas de figure n’avait pas été testé précédemment. Une notification sur un outil de monitoring prévient que tout est revenu à la normale. En fait il n’en est rien.
Ce dysfonctionnement n’apparaît qu’au moment de l’attaque. Lorsque la Préfecture des Alpes-Maritimes envoie une alerte à Deveryware, rien ne se passe, aucune notification n’est distribuée vers les apps installées sur les téléphones. Un nouveau redémarrage est réalisé immédiatement et les notifications partent, mais il était déjà trop tard. Elle se seront reçues au mieux deux heures plus tard et jusqu’au lendemain.
S’en suit une analyse de la chaine des responsabilités :
Deveryware ne semble pas pouvoir se retourner contre Numergy. « Ils ont acheté une prestation dont le niveau d’engagement peut se traduire par deux heures d’indisponibilité par mois », explique-t-on chez SFR. « Le diagnostic est assez clair : il y a eu un problème dans la relation entre l’hébergeur et Deveryware. Les personnes avec qui ils travaillent, c’est leur problème à eux, c’est leur responsabilité entière », souligne, de son côté, Romain Pigenel, directeur adjoint en charge du numérique au Service d’information du gouvernement.
Un nouveau plan de fonctionnement a été décidé, qui devrait prendre en compte cette nécessité de multiplier les serveurs en cas de panne du système principal, conclut Le Monde.
Source :
