Pourquoi l’application « alerte attentat » n’a pas fonctionné le soir de la tuerie de Nice

Elle était censée prévenir ses utilisateurs de toute attaque terroriste en quinze minutes maximum. Au final, il aura fallu presque trois heures à l’application SAIP (pour Système d’alerte et d’information des populations) du gouvernement pour signaler les événements dramatiques survenus à Nice le 14 juillet. 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.

Au lendemain de l’attaque meurtrière, le ministère de l’intérieur avait invité le prestataire de l’application, une société parisienne de géolocalisation d’environ quatre-vingts employés, Deveryware, à « rendre compte des dysfonctionnements constatés ».

« L’information relative à l’attentat qui a frappé la ville de Nice le 14 juillet a été relayée beaucoup trop tardivement […]. A la demande du ministère de l’intérieur, les responsables de l’application SAIP, acteurs reconnus des usages de sécurité du Web, ont été invités lors d’une réunion de crise qui s’est tenue ce jour [vendredi 15] à 15 heures, à rendre compte des dysfonctionnements constatés », avait indiqué le ministère.

Depuis cette date, la direction de Deveryware a refusé de s’exprimer publiquement les raisons de ce raté, considérant qu’il revenait à son client, l’Etat, de communiquer. Une nouvelle réunion avec le gouvernement doit avoir lieu jeudi 21 juillet. Elle pourrait aboutir à la publication des détails du dysfonctionnement du dispositif.

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.

Une application développée en deux mois

Précipitation, d’abord, car le projet s’est dessiné tard. Moyennant environ 400 000 euros, l’application a dû être réalisée en deux mois, avec une date butoir ferme pour sa mise en place : celle du 8 juin, deux jours avant le début de l’Euro 2016 de football.

Le gouvernement cherchait une société capable de faire une application dans l’urgence tout en assurant la préservation de l’anonymat. La technique était inédite, mais certaines sociétés spécialisées dans la géolocalisation en avaient l’expertise, a estimé l’Etat. C’est le cas de Deveryware, qui a développé l’application Taxiloc.

Une quinzaine d’ingénieurs ont été mis sur le projet. Plusieurs tests grandeur nature ont été réalisés avant lancement, dans différentes villes de France. L’application a alors fonctionné correctement. « 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).

Mais 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.

La mise en place d’une redondance multiserveurs en deux mois a été jugée irréaliste : la solution d’un serveur simple chez un hébergeur externe, validée avec les spécialistes en sécurité au ministère de l’intérieur, avait été choisie en amont. L’hébergeur retenu était Numergy, une société appartenant à SFR.

Panne chez le prestataire

C’est là où le problème de communication intervient : Numergy a vendu sa prestation sans connaître le client final de l’application, l’Etat, ni la raison d’être de l’utilisation de ses serveurs. « C’est lorsque Deveryware a contacté notre assistance technique à la veille de l’Euro que nous avons appris la nature de leurs services ; nous les avons alors alertés immédiatement sur la nécessité de prévoir une solution de redondance chez Numergy ou ailleurs pour des services aussi sensibles », explique le service de communication de SFR.

Dès lors, faute de recours technique, le bon fonctionnement de SAIP reposait presque entièrement sur celui des serveurs de Numergy. Et c’est là que la malchance intervient. 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. Personne, alors, ne peut se douter qu’un attentat se prépare pour le lendemain.

Personne, non plus, n’assume la faute. « L’indisponibilité de la plateforme d’hébergement concernée date du 13 juillet. Elle fonctionnait parfaitement le 14 juillet. Il n’y a donc aucun lien avec les dysfonctionnements de l’application SAIP », assure-t-on du côté de SFR.

C’est le matin du 14 juillet, toutefois, que cette indisponibilité a été notifiée au fournisseur de l’application. « Dès que le problème a été repéré, une cellule de crise a été constituée, tous les ingénieurs et les responsables ont été dépêchés sur place et la panne a été trouvée. Il n’y a pas eu négligence », relate une source proche de Deveryware.

Indicateurs erronés

Une fois la panne de son hébergeur réglée, le fournisseur de l’application a dû relancer ses propres systèmes. Un tel redémarrage en situation de crise n’a encore jamais été expérimenté. Or, à ce moment-là, une erreur d’affichage d’un logiciel tiers de monitoring indique à l’entreprise que l’application est à nouveau opérationnelle, affirme une source proche du dossier.

C’est lorsque la préfecture des Alpes-Maritimes transmet l’information concernant l’attentat que les ingénieurs découvrent que ce n’est pas le cas. Un nouveau redémarrage du système est opéré en urgence absolue. Finalement, l’application parvient à envoyer une alerte, mais avec plus de deux heures de retard au lieu des quinze minutes prévues.

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, du SIG.

Le dysfonctionnement ne se répétera pas, jurent désormais les différents acteurs. « Un plan d’action a été demandé dans un délai très bref pour qu’un tel incident ne puisse pas se reproduire, indique-t-on au ministère de l’intérieur. Le gestionnaire de l’application s’est engagé à présenter des mesures correctives dès lundi 18 juillet pour assurer une parfaite fiabilité des modalités de déclenchement de l’alerte des populations via SAIP. » L’application devrait désormais s’appuyer sur plusieurs serveurs redondants au lieu d’un seul.