Système d'alerte et notification de crise pour les collectivités — Cas d'usage Nehos
Un tableau de bord unique, pilotable sur mobile, pour alerter la population par SMS, push, email et sirènes. Méthode Nehos appliquée de l'audit ORSEC à la mise en production opérationnelle.
Nos clients types
Les collectivités territoriales françaises (communes, intercommunalités, syndicats mixtes) se retrouvent régulièrement face à une réalité difficile : en situation de crise, leurs dispositifs d'alerte traditionnels ne couvrent pas toute la population en temps utile. Les sirènes du Réseau National d'Alerte, héritées d'une autre époque, n'atteignent pas tous les habitants, en particulier ceux qui ne sont pas à leur domicile ou ne les entendent pas. Une commune qui se repose uniquement sur ce canal laisse une partie de ses administrés sans alerte directe lors d'un événement grave. Le premier facteur est la fragmentation des canaux. La plupart des collectivités disposent séparément de comptes sur les réseaux sociaux, d'une liste de diffusion email parfois incomplète, d'un site internet, de quelques sirènes, et d'une capacité d'astreinte téléphonique manuelle. Aucun de ces canaux n'est piloté depuis une interface unifiée. En situation de crise, les agents d'astreinte perdent un temps précieux à passer d'un outil à l'autre, à copier-coller des messages et à gérer des listes de contacts disparates. Le deuxième facteur est l'absence de ciblage géographique fin. Lors d'une inondation localisée sur deux quartiers, envoyer un SMS à l'ensemble de la population crée de la saturation et de la méfiance vis-à-vis des alertes suivantes (effet « cri au loup »). Un zonage précis, à l'IRIS ou à la rue, est la réponse. Le troisième facteur est la résilience en situation dégradée. Lorsqu'une crue inonde les locaux techniques ou qu'une coupure électrique interrompt le réseau local, l'interface d'administration du système d'alerte doit rester accessible depuis un smartphone en 4G/5G, en dehors du réseau interne de la collectivité. Beaucoup de solutions anciennes ne fonctionnent que sur le réseau local sécurisé de la mairie. Le quatrième facteur est la conformité. Le Plan Communal de Sauvegarde est obligatoire dans les communes dotées d'un plan de prévention des risques naturels approuvé ou comprises dans le périmètre d'un plan particulier d'intervention. Il doit décrire les procédures d'alerte. Un dispositif sérieux exige une traçabilité complète (horodatage, accusés de réception, journaux d'envoi) que les outils artisanaux, comme une liste de diffusion dans une messagerie, ne peuvent pas fournir. Enfin, la charge opérationnelle sur les agents d'astreinte est souvent sous-estimée. Un agent de permanence réveillé en pleine nuit doit pouvoir déclencher l'alerte depuis son smartphone, rapidement, sans formation récurrente. L'ergonomie mobile de l'interface est donc un critère opérationnel direct. Les systèmes qui exigent un VPN, un navigateur spécifique ou un poste de la mairie sont des freins en situation réelle.
La solution Nehos pour la gestion d'alertes et de notifications de crise en collectivité repose sur une architecture multicanale pilotée depuis un tableau de bord unique, pensé d'abord pour le mobile, résilient en situation dégradée, et cohérent avec les exigences réglementaires (ORSEC, PCS, RGPD). Architecture technique : les canaux orchestrés Le premier canal est la notification push sur une application citoyenne (iOS et Android), développée ou intégrée, qui reçoit des notifications géociblées. La géolocalisation est volontaire (opt-in) et limitée aux périodes d'alerte déclarées. Le deuxième canal est le SMS de masse géociblé, via une passerelle opérateur française, avec segmentation par code postal ou par zone géographique importée depuis le SIG communal. Chaque SMS peut contenir un lien court vers une page de consignes mise à jour en temps réel. Les accusés de réception sont horodatés et conservés pour la traçabilité. Le troisième canal est l'email groupé, pour les personnes moins mobiles et pour les communications de suivi (consignes détaillées, réouverture de services). Les listes sont alimentées par l'inscription volontaire, avec consentement explicite et désinscription en un clic. Le quatrième canal est l'intégration au dispositif national d'alerte lorsque la collectivité y est éligible via la préfecture. Un seul déclenchement peut alors activer à la fois le réseau national et les notifications numériques, sans double saisie. Le cinquième canal est le pilotage des sirènes IP locales, pour les communes qui en sont équipées et dont les équipements exposent une interface de commande. Le séquençage est paramétrable (par exemple, sirènes quelques secondes avant les SMS). Le sixième canal est la publication automatisée sur les réseaux sociaux de la collectivité, à partir de modèles de messages préparés par type d'événement (inondation, incendie, accident industriel, coupure d'eau, alerte météo). Tableau de bord opérationnel : conçu pour l'urgence L'interface doit être utilisable par un élu ou un agent d'astreinte sans formation récente, sur smartphone, de nuit, sous stress. La navigation se réduit à trois actions : choisir le type d'alerte dans une bibliothèque de scénarios, sélectionner la zone concernée sur une carte, et confirmer l'envoi. Le message est composé automatiquement selon le scénario, et modifiable si besoin. Le tableau de bord affiche en temps réel le taux de délivrance par canal, le nombre d'accusés de réception, la couverture géographique effective et le journal chronologique des actions, exportable en PDF pour le retour d'expérience après l'événement. Infrastructure : souveraineté et résilience Le système peut être hébergé chez un hébergeur français, sans dépendance à une infrastructure physique de la collectivité. En cas de coupure réseau ou d'inondation des locaux techniques, il reste utilisable depuis le cloud. L'interface mobile fonctionne sur n'importe quel réseau 4G/5G. La base des habitants inscrits (SMS, email, push) est chiffrée, avec un accès limité aux agents habilités par le DPO de la collectivité. Les données ne sont pas transmises à des tiers. La durée de conservation des journaux d'alerte est définie avec le DPO. Le backend est conçu pour monter en charge lors d'un envoi massif, ce que nous vérifions par des tests de charge pendant le pilote. Conformité ORSEC, PCS et réglementation Chaque déploiement s'accompagne d'un dossier comprenant : la cartographie des canaux activés, la procédure d'alerte documentée et intégrable au PCS, le registre des traitements RGPD à soumettre au DPO, les tests de déclenchement documentés avant la mise en service, et le rapport de couverture par canal. L'intégration avec les outils existants de la collectivité (gestion des astreintes, SIG, site web, application mobile citoyenne éventuelle) est cartographiée pendant l'audit, avant toute décision de déploiement.
Un seul geste
Déclencher une alerte multicanale en trois actions depuis un smartphone : scénario, zone, confirmation
Traçabilité
Journal horodaté des envois et des accusés de réception, exportable pour le retour d'expérience
Pilote
Délai de diffusion, taux de délivrance par canal et couverture effective mesurés pendant une simulation de crise avant la mise en service
#Le problème : pourquoi un système d'alerte et de notification de crise est un enjeu critique pour les collectivités
Les collectivités territoriales françaises (communes, intercommunalités, syndicats mixtes) se retrouvent régulièrement face à une réalité difficile : en situation de crise, leurs dispositifs d'alerte traditionnels ne couvrent pas toute la population en temps utile. Les sirènes du Réseau National d'Alerte, héritées d'une autre époque, n'atteignent pas tous les habitants, en particulier ceux qui ne sont pas à leur domicile ou ne les entendent pas.
Une commune qui se repose uniquement sur ce canal laisse une partie de ses administrés sans alerte directe lors d'un événement grave.
Le premier facteur est la fragmentation des canaux. La plupart des collectivités disposent séparément de comptes sur les réseaux sociaux, d'une liste de diffusion email parfois incomplète, d'un site internet, de quelques sirènes, et d'une capacité d'astreinte téléphonique manuelle.
Aucun de ces canaux n'est piloté depuis une interface unifiée. En situation de crise, les agents d'astreinte perdent un temps précieux à passer d'un outil à l'autre, à copier-coller des messages et à gérer des listes de contacts disparates.
Le deuxième facteur est l'absence de ciblage géographique fin. Lors d'une inondation localisée sur deux quartiers, envoyer un SMS à l'ensemble de la population crée de la saturation et de la méfiance vis-à-vis des alertes suivantes (effet « cri au loup »). Un zonage précis, à l'IRIS ou à la rue, est la réponse.
Le troisième facteur est la résilience en situation dégradée. Lorsqu'une crue inonde les locaux techniques ou qu'une coupure électrique interrompt le réseau local, l'interface d'administration du système d'alerte doit rester accessible depuis un smartphone en 4G/5G, en dehors du réseau interne de la collectivité. Beaucoup de solutions anciennes ne fonctionnent que sur le réseau local sécurisé de la mairie.
Le quatrième facteur est la conformité. Le Plan Communal de Sauvegarde est obligatoire dans les communes dotées d'un plan de prévention des risques naturels approuvé ou comprises dans le périmètre d'un plan particulier d'intervention. Il doit décrire les procédures d'alerte. Un dispositif sérieux exige une traçabilité complète (horodatage, accusés de réception, journaux d'envoi) que les outils artisanaux, comme une liste de diffusion dans une messagerie, ne peuvent pas fournir.
Enfin, la charge opérationnelle sur les agents d'astreinte est souvent sous-estimée. Un agent de permanence réveillé en pleine nuit doit pouvoir déclencher l'alerte depuis son smartphone, rapidement, sans formation récurrente. L'ergonomie mobile de l'interface est donc un critère opérationnel direct. Les systèmes qui exigent un VPN, un navigateur spécifique ou un poste de la mairie sont des freins en situation réelle.
#Notre approche en 4 phases
#Phase 1 : Audit ORSEC et cartographie des risques
Analyser le DDRM local, les plans ORSEC en vigueur, les canaux d'alerte existants (sirènes, réseaux sociaux, téléphone), les fichiers de population disponibles et les contraintes RGPD. L'intégration avec les outils existants de la collectivité (gestion des astreintes, SIG, site web, application mobile citoyenne éventuelle) est cartographiée pendant l'audit, avant toute décision de déploiement.
Voir notre expertise : service Applications Mobiles Nehos.
#Phase 2 : Architecture multicanale et choix des intégrations
Définir la stack : passerelle SMS opérateur français, push Firebase/APNs, intégration au dispositif national si la collectivité est éligible, sirènes IP si elles en sont équipées, email groupé, réseaux sociaux. Cartographier les zones de diffusion géographique. Le système peut être hébergé chez un hébergeur français, sans dépendance à l'infrastructure physique de la collectivité, avec une base d'habitants chiffrée et un accès limité aux agents habilités par le DPO.
Voir notre expertise : service Développement Web Nehos.
#Phase 3 : Pilote avec crise simulée et tests de charge
Déployer le système sur un périmètre restreint (commune pilote ou quartier), simuler plusieurs types de crise (inondation, accident industriel, coupure réseau), mesurer les délais de diffusion et les taux d'accusé de réception.
Voir notre expertise : Méthode Stack Souveraine Nehos™.
#Phase 4 : Déploiement généralisé, formation de l'astreinte et plan de continuité
Mettre en production sur l'ensemble du territoire, former les élus et agents d'astreinte (interface mobile simplifiée), documenter le plan de continuité d'activité, intégrer le dispositif au PCS (Plan Communal de Sauvegarde).
Voir notre expertise : cas d'usage portail citoyen services en ligne.
#Ce que nous mesurons
Nous ne promettons pas de résultat chiffré à l'avance. Pendant le pilote, nous mesurons le délai de diffusion de la première vague d'alerte, le taux de délivrance par canal, le nombre d'accusés de réception et la couverture géographique effective. Ces relevés, comparés à la situation de départ (exercice précédent, procédure manuelle), servent à décider du déploiement généralisé.
#Exemple de situation : une communauté de communes exposée aux crues
Exemple de situation, pas un client réel. Une communauté de communes dont plusieurs communes sont en zone inondable dispose de sirènes du réseau national, d'un compte Facebook et d'une liste email de volontaires peu fournie. Un exercice ORSEC a montré que l'alerte atteignait mal la population.
Nous proposerions : un audit ORSEC (sirènes existantes, zones mal couvertes, entretiens avec les agents d'astreinte), une architecture combinant application citoyenne, SMS géociblé, intégration au dispositif national si la préfecture l'autorise et publication automatique sur les réseaux sociaux, une formation des agents d'astreinte en conditions réelles, puis une crise simulée sur des communes pilotes pour mesurer les délais et les taux de délivrance. Le budget se chiffre après l'audit.
#Pourquoi Nehos pour un système d'alerte de crise
Nehos Groupe n'est pas un intégrateur généraliste qui adapte une solution standard à votre contexte. On conçoit des architectures sur mesure, calibrées sur vos contraintes métier, réglementaires et techniques. Chaque projet démarre par un audit de faisabilité qui pose les limites avant les promesses.
Notre méthode ROI-First impose un cadrage chiffré dès la phase d'audit : coût actuel documenté, gains attendus avec hypothèses prudentes, critères de go/no-go factuels. Nos expertises connexes : Méthode Stack Souveraine Nehos™, cas d'usage portail citoyen services en ligne, application mobile ville multiservice.
Stack technique souverain : hébergement possible chez un hébergeur français, code intégralement détenu par la collectivité à la livraison. Pas de dépendance à un fournisseur cloud américain pour vos données critiques.
#Pour aller plus loin
Cas d'usage connexes :
Questions & réponses
Questions fréquentes sur les systèmes d'alerte et notification de crise pour collectivités
Le Plan Communal de Sauvegarde (PCS) est obligatoire pour les communes dotées d'un plan de prévention des risques naturels prévisibles approuvé ou comprises dans le périmètre d'un plan particulier d'intervention (article L. 731-3 du Code de la sécurité intérieure). Il doit organiser notamment l'alerte et l'information de la population. Les intercommunalités peuvent porter un plan intercommunal de sauvegarde pour les compétences qu'elles exercent. En dehors des obligations formelles, toute collectivité exposée à un risque majeur documenté dans le DDRM (Document Départemental des Risques Majeurs) a intérêt à se doter d'un dispositif robuste, car la responsabilité administrative du maire ou du président peut être engagée en cas de carence dans l'alerte. Pour les cas particuliers de votre commune, rapprochez-vous de la préfecture.
Trois modes de collecte, par ordre de robustesse juridique. (1) Inscription volontaire via le portail citoyen ou l'application mobile : formulaire avec consentement explicite, finalité limitée à l'alerte de crise, désinscription en un clic, mention du DPO de la collectivité. (2) Base existante (abonnés à la newsletter municipale) : le consentement doit être requalifié, par exemple par un email de confirmation d'inscription à l'alerte, et ceux qui ne répondent pas sont écartés. (3) Diffusion cellulaire par les opérateurs (Cell Broadcast, via le dispositif FR-Alert) : aucune base de données n'est nécessaire, l'alerte est diffusée à tous les téléphones compatibles dans la zone couverte par les antennes relais. Ce dispositif est déclenché par l'État. La base de données gérée dans le système est hébergée en France et chiffrée, avec traçabilité des inscriptions et des désinscriptions. Le registre des traitements est fourni comme livrable pour le DPO de la collectivité.
Non. FR-Alert est un canal complémentaire puissant, avec des limites que les collectivités doivent connaître. Il est déclenché par l'État (les préfets), pas directement par les maires. Pour une inondation localisée dans deux quartiers, le maire ne peut pas le déclencher de son propre chef. Il ne permet pas de personnaliser le message ni de cibler finement à l'IRIS, ni d'obtenir des accusés de réception individuels, et il suppose un téléphone compatible. Un système multicanal conserve les canaux SMS, push, email et sirènes sous le contrôle direct de la collectivité, pour les situations où elle doit agir dans les premières minutes sans attendre la préfecture, et peut s'articuler avec FR-Alert lorsque la préfecture le déclenche.
Le coût dépend du périmètre : nombre d'habitants, canaux activés (push, SMS, email, sirènes IP si la commune en est équipée, réseaux sociaux), développement d'une application citoyenne ou réutilisation d'une application existante, niveau d'intégration avec le dispositif national, formation. À cela s'ajoutent des coûts récurrents : maintenance, hébergement et envoi des SMS. Nous établissons un devis sur mesure, chiffré en 48 h après un premier échange. Selon le projet, des financements peuvent exister (par exemple la Dotation de Soutien à l'Investissement Local ou les prêts de la Banque des Territoires), à vérifier avec votre préfecture et votre trésorier.
Le PCS est le document de gouvernance, le système en est l'outil opérationnel. L'intégration se fait sur trois points. (1) Procédures documentées : chaque scénario d'alerte du PCS (inondation, incendie, accident industriel…) est traduit en modèle d'alerte préconfiguré, avec message pré-rédigé, zone associée et canaux activés. L'agent d'astreinte sélectionne le scénario et confirme. (2) Annuaire de crise : les contacts du PCS (sapeurs-pompiers, gendarmerie, direction générale, astreinte technique, élus référents) sont intégrés au module de notification interne, afin qu'ils reçoivent l'information au déclenchement d'une alerte publique. (3) Traçabilité : le journal horodaté (qui a déclenché, quand, quel message, quels canaux, quel taux de délivrance) est exportable en PDF pour alimenter le retour d'expérience après l'événement.
C'est un principe de conception non négociable. Le système est hébergé chez un hébergeur, sans dépendance physique aux serveurs de la collectivité. L'interface d'administration est accessible depuis un navigateur mobile sur réseau 4G/5G, sans VPN ni accès au réseau local. En cas de coupure de l'infrastructure de la collectivité (locaux inondés, coupure électrique, attaque sur les serveurs municipaux), le système d'alerte reste utilisable. Les tests de déclenchement en conditions dégradées (smartphone 4G, hors wifi, batterie faible) font partie des livrables du pilote avant la mise en production.
La durée dépend du nombre d'agents d'astreinte et de leur aisance avec les outils numériques. L'interface est conçue pour limiter le nombre d'actions : quelques gestes suffisent pour déclencher une alerte standard. Nous proposons en général une première séance de prise en main (navigation dans le tableau de bord, scénarios préconfigurés, simulation d'un déclenchement sans envoi réel), puis un exercice complet avec envoi réel d'une alerte test à un petit groupe de testeurs volontaires, avec mesure des délais et lecture des rapports de délivrance. Les agents les moins à l'aise avec le numérique, souvent des élus en permanence, sont les premiers testés. Si l'interface est trop complexe pour eux, nous la simplifions avant la mise en production, pas après.