A chaque territoire ou organisme son application mobile d’alerte : l’impasse du modèle actuel.
Le monde de la communication de crise s’achemine de plus en plus rapidement vers un modèle d’applications mobiles d’alerte face aux catastrophes qui pourrait devenir, dans un proche avenir, complètement ingérable, aussi bien par la population que par les responsables d’alerte. En effet, la tendance actuelle dans ce domaine est que de plus en plus d’autorités, d’entreprises ou d’associations développent des applications mobiles différentes afin d’alerter, le plus rapidement possible, les populations des risques de catastrophe pouvant survenir sur leur territoire. Cependant, circonscrites à un territoire, hermétiques et propriétaires, ces applications mobiles engendrent différents effets contre productifs en matière de communication de crise qui seront analysés ci-après. De plus, l’impact financier du développement et de la maintenance d’une application mobile multiplateforme sur le long terme peut coûter très cher, surtout si on multiplie ce coût par autant de territoires et d’organismes que le monde peut en compter. Enfin l’efficacité ne sera pas au rendez-vous pour tout le monde et chacun réussira avec plus ou moins de succès cette entreprise, entre bugs techniques et insuffisance de téléchargement de leur application. S’il ne viendrait rarement à l’esprit d’une autorité quelconque de développer une application mobile pour lire des vidéos ou écouter des musiques, pourquoi tout se passe comme si chaque fournisseur de service d’alerte cherchait à créer son propre programme de diffusion ?
Exemples des limites de ce modèle dans la diffusion des messages d’alerte
Prenons un premier exemple (sans nom pour ne viser personne en particulier). La commune X, aux intentions louables, décide de créer son application mobile pour alerter ces administrés sur son territoire. L’administré doit donc télécharger ce logiciel, si celui-ci existe pour son mobile. Une fois téléchargée, cette application ne lui transmettra des alertes que sur le territoire qui le concerne. Si l’utilisateur est en déplacement dans un autre territoire (travail, vacances, transports), il ne sera ainsi plus sous sa couverture. Pour parfaire son dispositif d’alerte par mobile, il devra donc télécharger toutes les applications d’alerte existantes sur les territoires et sujets qui le concernent, ce qui rend ce procédé fastidieux et incertain. Et pourtant, un des retours d’expérience récurrent en matière de catastrophe nous enseigne que beaucoup de décès sont liés à la méconnaissance des territoires de personnes extérieures comme en témoigne récemment les derniers incendies en Catalogne espagnole où périrent plusieurs français.
Prenons un deuxième exemple : Une organisation nationale Y décide de créer un système d’information centralisant les données d’alerte dont elles disposent et dont l’application mobile informe instantanément le citoyen quel que soit l’endroit où il se trouve dans le pays. Outre les problèmes des visiteurs étrangers n’ayant pas téléchargé cette application, il se pose d’autres problèmes d’ordre organisationnels et techniques. Quels modèles d’échange de données entre les différents organismes générateurs d’alerte seront utilisés ? Un service se chargeant de collecter et d’entrer manuellement chaque alerte pour la normaliser à son système d’information sera pénalisé par une perte de temps conséquente alors qu’avec un système d’échange normalisé et synchrone, le service en question n’aurait plus à relayer manuellement l’alerte (mode automatique pour les alertes météo ou crue par exemple), ou juste à la valider simplement pour la diffuser (une fonction d’ajout d’informations propres à son territoire est possible lors de cette phase).
Prenons un troisième exemple : Un territoire Z n’a pas les moyens de créer une application mobile d’alerte, ce qui est la très grande majorité des cas. Une organisation internationale publique ou privée pourrait mettre à la disposition de tous les services territoriaux d’alerte une interface d’administration dans laquelle les gestionnaires d’alerte pourraient y paramétrer leur zone de couverture et entrer les alertes spécifiques à leur territoire tout en bénéficiant des alertes d’échelons supérieurs. Cette application permettrait également l’échange de données avec les organismes internationaux dont on peut imaginer les multiples usages comme par exemple d’informer toutes les personnes possédant l’application mobile d’alerte universelle et présentes sur ce territoire Z.
Les points forts de cette application
Les avantages d’une application mobile d’alerte universelle et open source :
– Des frais de développement concentrés sur un projet international, collaboratif et ouvert
– Une application qui contient les dernières avancées technologiques de transmission d’alerte
– La possibilité pour les gestionnaires de crise du monde entier de proposer, sans aucun frais de développement et de maintenance informatique, une application mobile d’alerte
– L’utilisateur ayant téléchargé l’application universelle a alors la possibilité de recevoir des alertes quel que soit l’endroit où il se trouve sur la planète si peu qu’un gestionnaire de crise administre les flux d’alerte sur le territoire qui le concerne
– La possibilité pour les gestionnaires de crise de recevoir beaucoup plus d’informations de crise (photos, vidéos, textes localisés) grâce à un nombre d’utilisateurs significativement plus élevé.
– La possibilité d’échanger et d’historiser les informations d’alerte entre organismes de gestion de crise et ainsi de bénéficier (entre autres) de données à analyser pour comprendre les dynamiques de crise et pour élaborer des retours d’expériences.
– La garantie de l’anonymat des utilisateurs par la licence open-source de l’application (type GNU) et la mise en ligne de son code-source.
Conclusion
La création d’une application mobile d’alerte universelle peut jouer un rôle important dans le dispositif de communication de crise multi-canal des autorités, notamment grâce aux possibilités étendues des smartphones offrant à la population plus qu’un simple signal ou qu’un court texte. Cependant, celle-ci devra rester ergonomique et simple à utiliser, dès la première prise en main. Comme pour tout système d’alerte, elle devra être accompagnée, en amont de son utilisation, d’un volet éducatif conséquent, afin que l’information d’alerte à court ou moyen terme qu’elle délivre soit comprise rapidement et efficacement.
Malheureusement, plus le temps passe et plus le vide laissé par cette absence d’application universelle et open-source sera comblé par des applications propriétaires aux efficacités et buts divers. Il pourrait même en émerger une application propriétaire fortement dominante, pesant de tout son poids sur le contrôle de cette information. Cette situation passive de la société civile et des Etats (concentrés sur la technologie du Cell Broadcast*) engendre donc un risque conséquent : celui d’une gestion de l’alerte par application mobile qui ne serait pas sous le contrôle des citoyens.
Pour aller plus loin
Plateforme pour la promotion d l’alerte précoce
http://www.unisdr.org/2006/ppew/
OASIS (Advancing open standard for the information society) : CAP (Common alerting protocol)
http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html
AFP : Google invite les Etats à mieux partagé leurs informations
http://fr.canoe.ca/techno/internet/archives/2012/07/20120702-104052.html
* Wikipédia : Cell Broadcast ou diffusion cellulaire
http://fr.wikipedia.org/wiki/Cell_Broadcast
Application mobile propriétaire « Alertes citoyens » (ndlr : en attendant mieux)
http://www.proximamobile.fr/article/alertes-citoyens
Quelques aspects techniques sur la réalisation de cette application mobile
Beaucoup d’application d’alerte se focalisent sur une, voir deux plateformes mobiles, ne couvrant pas l’ensemble du parc de smartphone en circulation. Des technologies existent pourtant pour porter facilement ces applications mobiles d’un environnement à l’autre mais il faut qu’elles soient comprises et définies à l’avance. La plupart des smartphones intègre maintenant les technologies de l’HTML5 qui, combinées avec des langages JS (et donc AJAX pour des requêtes sur serveurs distants) et CSS permettent de porter facilement une application d’un OS à l’autre, sans forcément en passer par un développement natif sur chaque plateforme mobile.
Enfin, la plupart des ces applications transmettent de manière asynchrone l’information (requêtes Ajax de l’application à tout les intervalles de temps t) alors même que des technologies de transmission synchrone existent (websocket par exemple). Il convient également de citer des protocoles de transmission (P2P par exemple) qui pourraient être plus rapides que l’Ajax dans certains cas d’alerte massive.
Il faut également se pencher fortement sur la façon dont les alertes seront signifiées sur le smartphone de l’utilisateur. L’avenir n’est plus de mettre simplement des cartes d’alerte sur n’importe quelle plateforme web ou mobile en se disant que l’utilisateur viendra s’enquérir par lui-même des informations qu’elle contient. Il faut maintenant lui délivrer, le plus rapidement et efficacement possible, l’information qui le concerne au moment où il en a besoin. Plusieurs types de signifiants visuels, tactiles ou sonores sont disponibles : notification dans la barre d’état du smartphone, beep, vibration ou sonnerie particulière. Le contenu particulier de chaque alerte est alors disponible sous forme textuelle (consignes de sécurité, description aléa), cartographique ou sonore. Une prise en charge multilingue automatique est aussi nécessaire, surtout en ce qui concerne l’information de base de l’alerte.
En ce qui concerne l’échange de données entre différents organismes, un modèle normalisé et ouvert d’échange de données existe déjà mais est très rarement utilisé surtout pour les applications d’alertes conçues aux niveaux infranationaux. Il est possible de regarder du côté du protocole standard d’alerte CAP rédigé en 2006 par OASIS. L’UNISDR et de grandes entreprises comme Google prônent, avec raison, l’échange ouvert de données sur les alertes et les catastrophes et regrettent que beaucoup d’organismes nationaux y soient encore hermétiques.
Enfin, le développement open-source permet de mutualiser les compétences et les bonnes volontés disponibles sur ce projet collectif, tout en rassurant les utilisateurs sur l’utilisation anonyme des données que le système d’information collectera et échangera.