Numérisk, concevoir une téléalerte simple à utiliser en situation de crise

Numérisk développe un logiciel de gestion de crise destiné aux collectivités.

Les appels d'offres demandaient régulièrement un module de téléalerte, que le logiciel ne proposait pas encore.

L'ajouter devait permettre à Numérisk de répondre à plus d'appels d'offres et de gagner des parts de marché.

Il devait aussi limiter les ruptures lors de la gestion d'une crise.

Le brief initial était de proposer une solution plus simple que celles déjà disponibles sur le marché.

Pendant le cadrage, l'équipe voulait pourtant un module très complet, et avait du mal à prioriser.

La problématique : Comment pouvons-nous simplifier et fiabiliser l'envoi de campagnes de téléalerte à la population ?

Pour concevoir une alternative pertinente, il fallait comprendre les difficultés rencontrées avec les outils existants et les pratiques des personnes chargées d'alerter la population.

Du cadrage aux entretiens

1. 01Atelier avec les parties prenantes : 1 h avec le cofondateur et CTO de Numérisk, pour poser les grandes lignes du projet et ce que Numérisk attendait du module.
2. 02Atelier avec les experts métier : 1 h avec 2 experts métier qui accompagnent les collectivités. Nous avons listé les fonctionnalités régulièrement demandées dans les appels d'offres, ce qui a fixé ce que j'allais comparer pendant le benchmark.
3. 03Benchmark de 2 solutions : Les 2 acteurs majeurs, les plus utilisés par les collectivités, identifiés grâce à la connaissance du marché de l'équipe de Numérisk. L'analyse du benchmark m'a permis de formuler les hypothèses à vérifier en entretien.
4. 044 entretiens : Avec des agents et des élus de 4 collectivités, pour vérifier ces hypothèses sur le terrain.

La grille du benchmark

Les critères reprennent les fonctionnalités demandées dans les appels d'offres, listées avec les experts métier, par exemple :

• l'envoi par SMS, message vocal ou mail ;
• le ciblage par zone géographique ;
• les modèles de messages ;
• le test avant envoi ;
• le coût visible avant l'envoi.

Les résultats restent confidentiels, mais la grille vide est disponible gratuitement.

2 hypothèses à vérifier sur le terrain

1. H1

   Un outil utilisé 1 ou 2 fois par an doit pouvoir être pris en main sans réapprentissage, même en situation de crise.

   Signal à observer : Les utilisateurs, même familiers de la plateforme, hésitent, commettent des erreurs ou contournent l'outil en privilégiant des appels ou des SMS manuels.

2. H2

   L'incertitude sur le contenu et la bonne diffusion d'une alerte peut freiner son envoi.

   Signal à observer : L'agent relit plusieurs fois son message avant l'envoi, cherche à vérifier ce que recevront les habitants ou s'assure que l'alerte a bien été diffusée.

Des utilisateurs difficiles à mobiliser

Les agents territoriaux et les élus sont des publics particulièrement sollicités.

Le recrutement a nécessité en moyenne 5 relances par participant.

Pour faciliter les échanges, j'ai profité de réunions techniques déjà programmées avec Numérisk, en réservant leurs 30 dernières minutes aux entretiens.

Cette organisation m'a permis de rencontrer 4 personnes issues de 4 collectivités, toutes ayant déjà participé à l'envoi d'une alerte réelle.

L'échantillon reste limité, mais les échanges ont permis d'identifier plusieurs difficultés à prendre en compte dans la conception.

Difficulté 1 Des annuaires à maintenir séparément

Les outils de téléalerte concurrents nécessitent de gérer un annuaire de contacts distinct des données déjà renseignées dans le Plan communal de sauvegarde (PCS).

Le PCS est le document qui organise la réponse de la commune en cas de crise, sous l'autorité du maire.

Il contient notamment l'annuaire de crise, la liste des personnes à joindre pendant une crise : élus, agents de la commune, secours, gendarmerie, gestionnaires de réseaux.

Pour les collectivités, ce second annuaire représente une charge de maintenance supplémentaire : les mêmes informations doivent être tenues à jour à plusieurs endroits.

Or, Numérisk dispose déjà de ces données dans son logiciel.

L'opportunité : Utiliser les données du PCS pour alimenter directement l'annuaire de téléalerte.

Difficulté 2 Trop d'options pour des usages occasionnels

Les solutions étudiées proposent de nombreux réglages et fonctionnalités avancées.

Ces possibilités peuvent répondre à des usages experts, mais elles complexifient les tâches essentielles pour des agents et des élus qui ne sont pas spécialistes de l'informatique.

Certains n'utilisent un outil de téléalerte qu'une ou deux fois par an.

L'enjeu était donc de rendre les fonctions essentielles immédiatement accessibles : rédiger un message, sélectionner ses destinataires et l'envoyer.

L'opportunité : Rendre l'outil utilisable sans réapprentissage, même après des mois sans l'ouvrir.

Difficulté 3 Une appréhension au moment de déclencher l'alerte

Pendant les entretiens, 3 participants sur 4 expliquaient relire plusieurs fois leur message avant l'envoi.

Au-delà des erreurs de manipulation, ils s'interrogeaient sur la manière dont le message serait reçu et compris par les habitants.

Cette appréhension était particulièrement importante dans un contexte où une alerte peut concerner une grande partie de la population.

L'opportunité : Permettre aux utilisateurs de recevoir eux-mêmes un message de test avant de déclencher la campagne.

Difficulté 4 Des coûts difficiles à anticiper

Les solutions concurrentes manquaient également de transparence sur les crédits consommés.

Les collectivités devaient calculer elles-mêmes le coût de leurs campagnes, avec parfois de mauvaises surprises lors de la facturation trimestrielle.

L'opportunité : Afficher les crédits restants et le nombre de crédits nécessaires avant le lancement d'une campagne.

J'ai testé un premier prototype avec 3 participants, puis j'ai itéré sur un seul point : le nombre d'étapes.

Un premier prototype avec le moins d'étapes possible

Ces actions tenaient sur la même page :

• la sélection des destinataires ;
• la rédaction du message ;
• les paramètres d'envoi.

Il contenait déjà toutes les fonctionnalités de la version finale.

Un écran pour chaque phase de l'alerte

Après les tests, le second prototype consacrait un écran à chaque phase de l'alerte, en 5 étapes.

1. 01Création de la campagne : Nom de la campagne et type d'envoi : SMS ou message vocal.
2. 02Choix des destinataires : Annuaire ou liste de diffusion, avec la possibilité d'ajouter des destinataires à la main.
3. 03Rédaction du message : Avec la possibilité de partir d'un modèle.
4. 04Synthèse et test : Toutes les informations de la campagne, avec la possibilité de tester avant l'envoi.
5. 05Résultats : Statut des envois et suivi des réponses.

Les participants consultaient l'étape en cours sans faire défiler la page, puis passaient à la suivante.

La décision : Privilégier un écran par phase plutôt qu'un parcours réduit au moins d'étapes possible, qui obligeait à faire défiler la page.

Les enseignements du benchmark, des entretiens et des tests ont guidé la conception du module.

Choix 1 Réutiliser les contacts du PCS

L'annuaire de téléalerte s'appuie sur les données déjà renseignées dans le logiciel Numérisk.

Les collectivités évitent ainsi de maintenir 2 bases de contacts distinctes.

Choix 2 Se concentrer sur les fonctions essentielles

L'interface donne la priorité à la préparation du message, au choix des destinataires et à la diffusion.

L'idée était proche de celle d'une télécommande : permettre aux utilisateurs d'accéder directement aux fonctions dont ils se servent, sans devoir maîtriser de nombreuses options expertes.

Choix 3 Vérifier le message avant sa diffusion

Un envoi de test permet à l'agent de recevoir le SMS ou le message vocal comme le recevraient les habitants.

Il peut vérifier le contenu et sa présentation avant de lancer la campagne.

Aucune des 2 solutions concurrentes étudiées ne proposait ce test.

Une alerte peut pourtant partir vers plus de 500 numéros, et bien davantage selon la taille de la commune.

Vérifier que tout est bon avant l'envoi rassure.

Cette fonctionnalité répond directement à l'appréhension exprimée pendant les entretiens.

Choix 4 Afficher les crédits avant l'envoi

Le nombre de crédits restants et le nombre de crédits nécessaires à la campagne sont visibles avant la confirmation.

Les collectivités peuvent ainsi anticiper leur consommation sans avoir à effectuer elles-mêmes les calculs.