Options Mon compte Next INpact
Affichage
Modifications sauvegardées
  • Smileys
  • Images
  • Commentaires par actu
  • Commentaires sous les news
  • Désactiver la version mobile
  • Taille de police
Close

Vous consultez la version mobile de ce contenu.

Cliquez ici pour être redirigé vers la version complète, ou attendez 5 secondes. Fermez ce pop-up pour continuer sur la version mobile.

5
secondes
L'application SAIP torpillée au Sénat, de sa conception à son utilisation
Applications Crédits : Ministère de l'Intérieur

L'application SAIP torpillée au Sénat, de sa conception à son utilisation

Saipés comme jamais
9 min

Le sénateur Jean Pierre Vogel (LR) descend en flammes l'application SAIP dans un rapport au vitriol. Il s'agit pour lui d'une « application imparfaite », à évaluer d'ici 2019 « afin de déterminer sa pertinence » et, si besoin, de réorienter le système vers du cell broadcast.

Juin 2016, quelques jours avant le coup d'envoi de l'Euro 2016 de football, le gouvernement lançait officiellement son application SAIP sur smartphones (Android et iOS seulement). Quelques semaines plus tard (le 14 juillet 2016), Nice subissait un attentat causant des dizaines de morts. À l'époque, le ministère de l'Intérieur avait rapidement déclenché le plan ORSEC et Facebook son Safety Check, mais la notification SAIP était arrivée bien plus tard dans la nuit.

Dans un rapport publié aujourd'hui et examiné fin juin en commission des finances, le sénateur Jean Pierre Vogel (Les Républicains) revient sur le dispositif qui englobe le Système d’alerte et d’information des populations (SAIP) : le Réseau national d’alerte (qui utilise également les sirènes). Il n'est pas tendre avec ce dernier, jugé « obsolète ». Le développement de l'application a été confié à la société Deveryware, pour un budget de 300 000 euros

Le parlementaire recommande de développer « fortement le volet "téléphonie mobile" plutôt que le volet "sirènes" » qui concentrerait près de 80 % des crédits prévus (44,7 millions d'euros pour la première phase jusqu'en 2018, 36,8 millions d'euros à partir de 2020, soit un total de 81,5 millions d'euros). De son côté, le volet téléphonie mobile ne récupère que 11 % des crédits consommés ou prévus pour ce projet.

Un choix « contestable » pour le sénateur, d'autant que les sirènes ne sont aujourd’hui « quasiment jamais utilisées dans d’autres contextes que ceux des essais hebdomadaires ». De plus, elles ne donnent pas de détails sur la marche à suivre en cas d'incident : seule une infime minorité de Français saurait comment réagir si les sirènes devaient se déclencher. Il est par contre possible d'afficher des informations détaillées sur les terminaux mobiles. C'est justement le rôle que devait jouer l'application SAIP, mais elle n'a pas vraiment eu le succès escompté jusqu'à présent, notamment à cause de « failles techniques ».

SAIP : « application imparfaite », « dysfonctionnement technique », « bugs »...

Premier fait marquant, le 14 juillet : « alors que le dispositif est utilisé pour la première fois en conditions réelles, un dysfonctionnement technique retarde de plus de deux heures l’envoi de l’alerte » explique le rapport. Des changements sont apportés et un audit technique conclut que les corrections apportées sont suffisantes pour éviter que le problème se reproduise.

Pour rappel, l'application SAIP a été activée une seconde fois depuis son lancement, en septembre 2016 dans le quartier des Halles à Paris... mais pour une fausse alerte. Deux couacs en deux utilisations, cela fait beaucoup pour un service censé prévenir une personne présente dans une zone à risque.

Le rapport ne s'arrête pas en si bon chemin. Il note aussi que « des « bugs » résiduels, laissant une impression de manque de maîtrise de la part du ministère de l’Intérieur et de Deveryware, subsistent toutefois (cas de réception d’alerte bien que l’utilisateur ne se trouve pas dans une zone de danger, message de fin d’alerte à Nice renvoyé plus d’un mois après l’événement, à la suite du redémarrage des serveurs du back-office) ».

Plus loin, il est même question d'une « application imparfaite réalisée dans un calendrier trop contraint ». En effet, l'idée du service est née des attentats du Bataclan, en novembre 2015. La phase d'expression des besoins a commencé en janvier 2016 et la mise en ligne a eu lieu cinq mois plus tard seulement. Entre temps, le marché a été notifié à la société Deveryware le 27 mai 2016 pour une mise en ligne le 8 juin de la même année. Bref, elle a « été conçue dans l’urgence, ce qui a nui à la qualité du produit final ».

Le rapport note tout de même que Deveryware était déjà, comme d’autres sociétés, en relation d’avant-vente avec la DGSCGC (direction générale de la sécurité civile et de la gestion des crises) depuis plus d’un an.

Des défauts à corriger, une doctrine d'emploi à revoir

Ce n'est pas tout. Le rapport pointe des « défauts structurels » de l'application SAIP : la consommation de batterie, la géolocalisation quasi-continue en cas d’alerte et la nécessité de garder le service en tâche de fond sur iOS (ouvert, mais pas forcément au premier plan). Le rapport recommande donc de « corriger en urgence les principales défaillances persistantes de l’application SAIP qui nuisent à sa fiabilité et à son ergonomie ».

Autre recommandation, « modifier la doctrine d’emploi de l’application afin d’y relayer, même lorsqu’ils semblent maîtrisés, l’ensemble des évènements pouvant mettre en cause la sécurité des personnes sur un territoire ». Le déclenchement des alertes est jugé « trop timide », ce qui peut pousser les utilisateurs à aller voir ailleurs (notamment sur les réseaux sociaux).

Par exemple, lors des attentats du mois d'avril à Paris, la préfecture de police de Paris a envoyé des messages vers 21h06, alors que l'application SAIP restait silencieuse. Un tweet sur ce mutisme nous avait d'ailleurs valu une mise en demeure de l'avocat de Deveryware (voir cette actualité). L'entreprise accusait notre rédacteur en chef, Marc Rees, de dénigrement de son produit.

Selon le rapport, le ministère de l'Intérieur se retranche derrière une « cinétique lente ou le fait que la situation ait pu être figée rapidement » pour justifier le non-recours aux alertes via l'application SAIP dans certaines situations. Argument balayé par le sénateur : il « apparaît d’autant plus contestable que le manque de diffusion de l’alerte accroît la charge de travail des forces de l’ordre sanctuarisant le secteur de l’attaque ».

Même dans une situation figée, la fuite d'un assaillant ou la présence d'une autre équipe de terroristes n'est pas à exclure systématiquement. Dans ce cas, « la diffusion de l’alerte apparaît également pertinente » ajoute le rapport. Bref, il faudrait déclencher plus souvent l'alarme via l'application SAIP, sans tomber dans l'excès inverse en lançant de fausses alertes. Bref, une chaine de déclenchement à revoir. 

SAIP

Un manque de collaboration entre applications mobiles

En cas d'incident, les notifications peuvent arriver de plusieurs applications à la fois, certaines bien plus répandues que SAIP. C'est le cas de Facebook (et de son Safety Check) avec 28 millions d'utilisateurs depuis un mobile en France. Twitter est également largement utilisé pour une remontée rapide d'événements, tandis que Google Maps pourrait également servir de relais, pointe le sénateur. Il cite d'ailleurs l'exemple de l'attaque sur les Champs-Elysées le 21 avril 2017. Alors que SAIP ne relatait « aucun incident en cours », l'application de cartographie de Google a « signalé cette avenue comme bloquée très rapidement après l’attaque ».

Problème, « ces dispositifs épars ne font l’objet d’aucune réelle coordination au niveau de l’État », même si des sollicitations ponctuelles ont parfois lieu. Un tel rapprochement serait souhaitable, mais ne remet pas en cause la nécessité pour le gouvernement de disposer de son propre système d'alerte « dont il a la pleine maîtrise ».

Le cell broadcast laissé de côté à cause des opérateurs ?

Sur le fond, Jean Pierre Vogel regrette le choix d'une application pour smartphone – « moins efficace et développée hâtivement, nécessitant encore d'importantes améliorations » – plutôt que la technologie de cell broadcast (diffusion cellulaire) permettant d'envoyer un message à toutes les personnes se trouvant dans une zone géographique, en passant par les opérateurs mobiles.

Selon le sénateur, des négociations avaient été engagées dès 2011 avec ces derniers. Elles n’avaient néanmoins pu aboutir « pour des raisons de volonté des opérateurs ou de coûts non soutenables et non compatibles avec les enveloppes budgétaires existantes ».

Le cell broadcast a deux inconvénients. D'une part, ce système n'est pas compatible avec tous les smartphones et réseaux 4G. D'autre part, elle demanderait « un fort investissement » des opérateurs pour rendre leurs réseaux compatibles. Cela ne l'empêche pas d'être déjà utilisée dans plusieurs pays, comme les Pays-Bas, le Japon et la Corée.

Une autre solution aurait pu être de passer par des SMS géolocalisés, mais cette technologie « souffre également de plusieurs lacunes jugées, à juste titre, rédhibitoires par le ministère de l’Intérieur ». La vitesse d'acheminement dans un contexte de crise et le fait que le SMS d'alerte ne soit pas différent des autres SMS (alors que le cell broadcast est prioritaire avec une mise en avant spécifique). Enfin, le SMS géolocalisé soulève la question de vie privée : l'opérateur agrège les numéros de téléphone présents dans une zone d'alerte.

Le choix d'une application « contestable » à plus d'un titre

Si le cell broadcast et le SMS géolocalisé ne sont pas parfaits, passer par une application pour smartphone « présente plusieurs inconvénients qui conduisent à douter de sa pertinence » note le rapport. Pêle-mêle il est question d'un téléchargement préalable obligatoire de la part de l'utilisateur, la nécessité de disposer d'une connexion à Internet (réseau vulnérable en cas de crise) et une concurrence avec d'autres applications mobiles (également capables d'envoyer des notifications push).

Bref, « le cell broadcast aurait sans doute mérité de plus amples réflexions avant d’être abandonné si promptement » pour le sénateur. Il balaye au passage la réticence des opérateurs qui « aurait aisément pu être surmontée par l’introduction d’une disposition législative ». Il ajoute que les 81,5 millions d’euros programmés pour SAIP auraient pu être plus utile s'ils avaient été utilisés afin de « poursuivre les études préparatoires relatives au volet « mobile » et à financer une éventuelle mise en place du cell broadcast comme vecteur de l’alerte ».

Des spécialistes militent également pour la mise en place du cell broadcast. C'est notamment le cas de Ludovic Lux, président de l'association VISOV (Volontaires internationaux en soutien opérationnel virtuel) que nous avions interviewé en juillet 2016, suite à l'attentat de Nice. C'est aussi ce que demande un député depuis plusieurs mois.

Une évaluation de SAIP d'ici 2019 pour décider de la suite 

S'il est difficile de faire machine arrière, étant donné les sommes déjà investies, le sénateur souligne l'importance d'une évaluation indépendante d'ici fin 2019. Le cas échéant, les travaux sur le cell broadcast pourraient reprendre et l'application SAIP être laissée de côté.

Dans cette situation, il dévoile une ébauche de calendrier : la technologie cell broadcast devra être mis en service en 2020 ou 2021. Au contraire, si l'application est entérinée, elle devra être fiabilisée. Une mise en avant importante devra être menée auprès des utilisateurs afin d'atteindre une « masse critique » de téléchargements. Objectif : cinq millions d'ici fin 2020, alors qu'il ne serait question que de 900 000 téléchargements mi-2017 et 500 000 utilisateurs selon le document... Il reste donc du travail.

Lors de son passage devant la commission le 28 juin, le sénateur fait part de son souhait d'affecter davantage de crédit au volet mobile au lieu de déployer encore plus de 2 000 sirènes. Il reste pour rappel 36,8 millions d'euros à répartir. 

Publiée le 08 août 2017 à 09:03


Chargement des commentaires