SYSTEME D'ECHANGE D'INFORMATIONS ENTRE DIFFERENTS

UTILISATEURS ET DIFFERENTES AUTORITES

DESCRIPTION

DOMAINE TECHNIQUE

[0001] L'invention se rapporte à un système d'échange d'informations entre différents utilisateurs et différentes autorités.

[0002] Le domaine d'application de l'invention concerne l'échange d'informations entre des utilisateurs et différentes autorités, par exemple entre des Citoyens et des collectivités territoriales permettant aux Citoyens, de signaler des Evénements survenus dans leurs collectivités (« un Evénement »), et aux collectivités d'émettre des alertes à l'attention de Citoyens présents dans une zone géographique pertinente, liée aux

Evénements signalés ou totalement indépendantes de ceux-ci (« une Alerte »).

[0003] Cet échange entre Citoyens et collectivités est bénéfique pour fluidifier, sécuriser et faciliter le bien-être des utilisateurs au sein de ces collectivités en les impliquant en outre dans le fonctionnement de la collectivité considérée.

[0004] L'échange d'informations entre utilisateurs et autorités s'effectue via une application préalablement téléchargée sur un téléphone intelligent, ou Smartphone, ou via une interface d'un site internet dédié, ces informations étant ainsi rendues accessibles aux utilisateurs du système, sédentaires ou en déplacement.

ÉTAT DE LA TECHNIQUE [0005] Il est connu du document US 7 301 450, un système de communication d'Alertes émises par un centre de communication aux Citoyens, rattaché par exemple à une municipalité, à destination de Citoyens adhérents au système et ayant choisi de recevoir ce type d'Alerte. Dans ce système, le centre de communication recueille sur internet, par le biais de sites gouvernementaux ou d'autres bases de données, des Alertes à l'attention de la population, telles que des Alertes météorologiques, et les transmet, par SMS, courriel ou via un site internet dédié, aux utilisateurs s'étant préalablement déclarés désireux de recevoir ce type d'information. Ce système d'échange d'informations est adapté aux Alertes de grande ampleur mais s'avère inopérant pour des Alertes relatives à des faits plus localisés, dont aucun rapport ne sera établi sur un site gouvernemental. En outre, bien que les sources fournissant en informations les centres de communications soient relativement fiables, celles-ci ne s'avèrent cependant pas suffisamment réactives lors de la survenue d'un fait soudain, isolé, et localisé, tel que la survenue d'un dégât des eaux ou la chute de grêlons dans une ville.

[0006] Par ailleurs, dans un tout autre domaine d'application, les systèmes d'aide à la conduite permettent à des utilisateurs de déclarer des Evénements, tels que la survenue d'un accident de circulation ou d'un ralentissement, via un dispositif de navigation ou une application téléchargée sur leur Smartphone, afin que cet Evénement soit signalé à des utilisateurs présents dans la zone où l'Evénement est survenu. Tel est le cas du système décrit dans le document FR 2 982 986. Toutefois, si ce système permet effectivement la déclaration de l'Evénement gênant ou d'un problème, il n'en permet pas la résolution, les Evénements déclarés par des utilisateurs demeurant à la seule connaissance de ces utilisateurs qui ne sont pourtant pas en mesure d'apporter une solution à la gêne occasionnée par l'Evénement. EXPOSÉ DE L'INVENTION

[0007] L'invention vise à résoudre les problèmes évoqués ci-dessus en permettant un échange bilatéral d'informations entre d'une part différents utilisateurs du système et d'autre part différentes autorités, qui coopéreront pour fournir pratiquement en temps réel des informations sur un fait particulier, et permettre un traitement de ce fait par les autorités compétentes, soit en résolvant le problème occasionné par ce fait soit en diffusant au plus grand nombre d'utilisateurs des informations sur ce fait.

[0008] Plus particulièrement, l'invention concerne une solution technique et logicielle de signalement d'un événement au moyen de terminaux mobiles ou fixes, traitement de ces événements au moyens de portails métiers par des autorités et diffusion d'alertes depuis ces portails métiers auprès de ces terminaux mobiles ou fixes à l'échelle d'un territoire allant d'un site propre (site industriel, bâtiment) au territoire national d'un pays ou état.

[0009] Plus précisément, la présente invention a pour objet un système d'échange d'informations entre différents utilisateurs inscrits au système et différentes autorités associées à des zones géographiques telles que des collectivités territoriales, comprenant :

- une plateforme commune de stockage de données

- des terminaux des différents utilisateurs, comprenant chacun • un moyen de géolocalisation courant du terminal,

• une interface « signalisation » permettant à l'utilisateur de signaler un Evénement géolocalisé et de préférence horodaté au sein d'une ou plusieurs autorités (selon qualification de l'Evénement),

• des moyens de transmission à la plateforme qui les stocke, du lieu courant de géolocalisation du terminal et de l'Evénement signalé,

- des terminaux des différentes autorités, comprenant chacun

• des moyens de transmission à la plateforme qui les stocke, d'Alertes émises par l'autorité considérée,

Le système comprenant en outre :

- des moyens de transmission des événements stockés dans la plateforme aux autorités associées respectivement aux zones géographiques où chaque Evénement a été géolocalisé, et

- des moyens de transmission des Alertes stockées dans la plateforme, aux utilisateurs inscrits au système et dont les terminaux sont géolocalisés dans une zone de diffusion de l'Alerte définie par l'autorité considérée.

[0010]Selon des modes de mise en œuvre avantageux :

- les moyens de géolocalisation des terminaux des utilisateurs sont formés de points GPS fournis par un équipement interne au terminal ou par des points GPS fournis par triangulation d'antennes cellulaires (BTS), ou sont déterminés par rattachement à un code préalablement déployé et paramétré en une zone spatiale particulière et enregistré par l'utilisateur sur son terminal lors d'un besoin de géolocalisation (« tags » en zone non couverte, à l'intérieur de bâtiments ou d'environnements enterrés), ou sont définis par sélection par l'utilisateur d'un point sur une carte affichée dans l'interface de signalisation de son terminal,

- le système comprend des moyens de déclenchement automatique de la transmission à la plateforme du lieu courant de géolocalisation du terminal d'un utilisateur,

- le déclenchement automatique de la transmission à la plateforme du lieu courant de géolocalisation du terminal d'un utilisateur s'effectue périodiquement avec une période correspondant à un temps de remontée d'information prédéfini

- le temps de remontée d'information est adapté en fonction d'un niveau de charge du terminal de l'utilisateur, le temps de remontée étant d'autant plus important que la charge est basse,

- l'interface du terminal d'un utilisateur comprend une liste de types d'Evénements susceptibles d'être signalés en fonction du lieu courant de géolocalisation du terminal (selon la capacité de traitement de l'autorité couvrant le territoire et ses propositions),

- la plateforme comprend des moyens d'identification d'un Evénement secondaire signalé par un utilisateur c'est-à-dire un Evénement identifié comme similaire à un Evénement déjà signalé et stocké dans la plateforme,

- l'identification d'un Evénement secondaire s'effectue par comparaison de paramètres propres à un Evénement déjà signalé et stocké et incluant la géolocalisation et l'heure de l'Evénement, à des paramètres définis par une autorité et incluant un périmètre autour d'un Evénement, une période de temps autour de la survenue d'un Evénement et une indication sur une orientation spatiale relative entre le terminal de l'utilisateur et l'Evénement, un nouvel Evénement étant identifié comme secondaire vis-à- vis d'un Evénement déjà signalé et stocké, s'il intervient dans le périmètre, la période de temps et l'orientation définis par l'autorité

- la plateforme est capable de rattacher, selon les différentes règles suscitées, un Evénement à un autre et de réaliser ainsi un dé-doublonnage de l'ensemble des Evénements reçus.

- lorsque l'interface du terminal comprend une capture d'image ou de vidéo à associer à la signalisation d'un Evénement, l'indication sur l'orientation spatiale relative entre le terminal de l'utilisateur et l'Evénement prend la forme d'une boussole apparaissant sur l'image ou la vidéo de manière explicite (marquage) ou implicite (données internes),

- la plateforme comprend des moyens pour ignorer un Evénement secondaire en ne le stockant pas

- selon une alternative, le système comprend des moyens pour demander à un utilisateur ayant signalé un Evénement, ou à tout utilisateur se retrouvant dans une zone géographique prédéfinie autour de l'Evénement signalé, des renseignements complémentaires sur l'Evénement, tels que des images ou une confirmation que l'Evénement perdure,

- les moyens pour demander des renseignements complémentaires sur un Evénement signalé sont gérés par les terminaux des autorités

- selon une variante de réalisation, le système comprend des moyens pour transmettre le signalement d'un Evénement généré par un utilisateur, à d'autres utilisateurs se trouvant dans une zone géographique prédéfinie autour de l'Evénement signalé

- les moyens pour transmettre le signalement d'un Evénement généré par un utilisateur, à d'autres utilisateurs sont gérés par les terminaux des autorités

- le signalement d'un Evénement par un usager, peut être réalisé suite à une action volontaire de l'usager ou automatiquement c'est à dire sans action de sa part. Ce dernier cas concerne des faits, tels qu'un choc subi par un usager dans son véhicule, susceptibles de générer des informations interprétables par la plateforme, en l'occurrence dans l'exemple considéré, une discontinuité dans les données fournies par un accéléromètre contenu dans le terminal de l'usager disposé dans le véhicule. La transmission automatique d'un tel événement peut être paramétrée au préalable par l'usager qui choisira le type de fait pouvant être automatiquement signalé comme un Evénement à la plateforme, sans donc aucune action spécifique de sa part,

- selon un mode de réalisation, les terminaux des utilisateurs sont des terminaux mobiles ou fixes.

[0011] L'invention concerne également un procédé d'échange d'informations entre différents utilisateurs inscrits à un système d'échange d'informations et différentes autorités associées à des zones géographiques telles que des collectivités territoriales, comprenant :

- des étapes de stockage de données au sein d'une plateforme de stockage commune aux différents utilisateurs et aux différentes autorités,

- une étape d'identification du lieu de géolocalisation des terminaux des différents utilisateurs inscrits au système, chaque terminal comprenant un moyen de géolocalisation courant du terminal, une interface « signalisation » permettant à l'utilisateur de signaler un événement géolocalisé au sein d'une autorité, et des moyens de transmission à la plateforme qui les stocke, du lieu courant de géolocalisation du terminal et de l'événement signalé,

- une étape de transmission à la plateforme qui les stocke, d'alertes émises par des terminaux des différentes autorités

Le procédé comprenant en outre :

- une étape de transmission des Evénements stockés dans la plateforme à chaque autorité associée à la zone géographique où l'événement a été géolocalisé, et

- une étape de transmission des Alertes stockées dans la plateforme, à chaque utilisateur inscrit au système et dont le terminal est géolocalisé dans une zone de diffusion de l'Alerte définie par l'autorité considérée.

De préférence, le procédé comprend en outre une étape de transmission des Evénements stockés dans la plateforme à chaque service d'une autorité ou chaque usager ayant choisi, par adhésion explicite de recevoir automatiquement des informations sur certains Evénements selon leur nature. PRÉSENTATION DES FIGURES

[0012] D'autres données, caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description non limitée qui suit, en référence aux figures annexées qui représentent, respectivement :

la figure 1 , représente de façon schématique le fonctionnement du système selon l'invention pour le traitement d'Evénements signalés par un utilisateur ;

la figure 2, représente de façon schématique le fonctionnement du système selon l'invention pour la communication d'Alertes émises par une autorité, à l'attention d'utilisateurs abonnés à cette autorité

la figure 3 illustre de façon schématique l'ensemble du procédé d'échange d'informations,

les figures 4 à 6 représentent schématiquement le processus d'identification d'un Evénement primaire et d'un Evénement secondaire,

les figures 7 à 9 illustrent schématiquement l'identification de citoyens présents dans une zone de diffusion d'une Alerte,

les figures 10 et 1 1 montrent un schéma illustrant l'affichage de la cartographie des Evénements sur l'espace Grand Public du site Web du système selon l'invention.

DESCRIPTION DÉTAILLÉE

[0013] Le système selon l'invention sera décrit dans ce qui suit en référence à un mode de réalisation selon lequel les « autorités » sont des collectivités territoriales repérées par « Ci » sur la figure 3, telles que des villes, et les utilisateurs désignés par « Ui » sur cette même figure, des

Citoyens susceptibles d'être situés dans une ville rattachée au système ou de se déplacer entre villes.

[0014]Ce système permet de fournir principalement deux types d'échange d'information, qui peuvent interagir l'un l'autre :

- le signalement d'Evénements par le Citoyen sur action volontaire de sa part, ou de façon automatique, à destination des villes et plus largement de collectivités et

- l'émission d'Alertes par une collectivité (et plus généralement une autorité) à destination du Citoyen

[0015] Il s'agit d'un service unique accessible sur tout le territoire d'un

Etat avec un unique site (portail en accès direct type WEB ou indirect via application mobile) connu du grand public (les utilisateurs déclarés) et des collectivités (les différentes villes abonnées au système agissant via des Opérateurs), et une unique plateforme de stockage P des événements signalés par les différents utilisateurs, et des Alertes émises par les différentes villes. Un Opérateur administrateur par ville gère ses propres usagers, ses types d'Evénements et ses critères de dé-doublonnage. Un Administrateur global gère le système.

[0016] Les utilisateurs accèdent au procédé d'échange d'informations selon l'invention soit via une application gratuite préalablement téléchargée sur leur téléphone mobile intelligent, soit via une application web de type portail, les collectivités territoriales via un site web et l'Administrateur global également via un site web.

[0017] Les interfaces des applications ou sites web dédiés aux Citoyens, aux collectivités et aux Administrateurs seront explicitées en fin de description.

[0018] Identification des différents intervenants :

On distingue quatre types d'intervenants : On va donc distinguer quatre catégories de personnes :

• Les utilisateurs inscrits, nommés « les Citoyens » et pouvant déclarer des Evénements et recevoir des Alertes.

• Les utilisateurs non inscrits, c'est-à-dire les internautes qui accéderont aux pages « Grand public » du site web ou les détenteurs de téléphones mobiles n'ayant pas téléchargé l'application, nommés le Grand Public.

• Les Opérateurs d'une collectivité, en charge de la gestion du service public pour une collectivité.

· Les Administrateurs du service : « l'Administrateur » représentés par des personnes en charge de la gestion du Système d'échange d'informations entre les différents utilisateurs et les différentes autorités objet de l'invention.

[0019] Les utilisateurs devront être inscrits dans le système et donc authentifiés pour accéder aux fonctionnalités. Cette inscription peut s'effectuer avec comme identifiant pour l'intervenant, son email, ou son numéro de téléphone authentifié par procédure.

[0020]Authentification des équipements : terminaux mobiles ou fixes des Citoyens.

[0021] Un équipement correspond à un terminal mobile sur lequel est installée l'application ou un terminal fixe ayant accès au site web dédié à cette application. L'équipement sera identifié en tant que tel et lié à un Citoyen. Le Citoyen pourra associer autant d'équipements qu'il le souhaite.

[0022] Localisation d'un événement [0023] La géolocalisation est une donnée essentielle du système selon l'invention.

Celle-ci est une propriété intrinsèque d'un Evénement et d'une

Alerte.

L'Evénement est obligatoirement géolocalisé :

1 . Lors de la création d'un Evénement à partir d'un équipement mobile par un Citoyen au travers de l'application téléchargée sur son téléphone, l'Evénement est automatiquement géolocalisé par l'un et/ou l'autre des procédés suivants :

• Point GPS (coordonnées (X, Y) fourni par l'équipement lui- même

• Point GPS fourni par la triangulation des cellules BTS.

• Rattachement à un « tag » type « QRCode » préalablement déployé et paramétré, (principe de géolocalisation sur des sites de types « Indoor » : bâtiments, sites industriels, etc.). Le « QRCode » est une étiquette supportant un TAG connu du système selon l'invention : A chaque « QRCode» correspond une position géographique (Point réel cartographique ou une position sur un plan par exemple). Le « QRCode » est préalablement déployé et paramétré. (Principe de géolocalisation sur des sites de types « Indoor » : bâtiments, sites industriels, etc.). Le « QRCode » est une étiquette supportant un TAG connu du service Alert-Phone : A chaque « QRCode» correspond une position géographique (Point réel cartographique ou une position sur un plan par exemple).

2. Lors de la création d'un Evénement à partir du site Web dans la partie privative du Citoyen, le Citoyen devra définir sur une carte (par un simple « click » sur cette carte) la géolocalisation de l'Evénement.

La localisation est donc définie par le couple de valeurs :

Type de localisation :

o GPS EQUIPEMENT

o GPS_BTS

o GPS_CARTO

o QRCODE

Valeur de localisation

o Coordonnées (X, Y)

o Valeur du « QRCode » [0024] Un Evénement créé par le Citoyen suit un processus précis, dont le but est le traitement de l'Evénement par la collectivité.

[0025] Le diagramme illustré sur la figure 1 présente globalement les changements d'états associés à un Evénement.

L'OBJET EVENEMENT ET SES PROPRIETES

Il s'agit de l'objet créé par le citoyen au travers de l'application Smartphone, ou d'un formulaire sur le site web.

L'objet Evénement possède de nombreuses propriétés :

1 . Il est rattaché à un niveau de la nomenclature des événements.

2. Une description (commentaire ou informations supplémentaires)

3. Un taux de gravité (de 1 à 5)

4. Une localisation

5. Des photos (3 pour l'instant)

6. Des vidéos (x pour l'instant)

7. Un type (Primaire / Secondaire)

8. Un statut

9. Un nombre de points

LES PROPRIETES DIRECTES DE L'EVENEMENT

Catégorie et type de l'événement

L'objet événement est rattaché à un niveau de l'arborescence.

Il possède donc :

Une catégorie (niveau 1 de la nomenclature).

Un type d'événement et sous type (fonction du nombre de niveau).

Description

Cette information de type texte, saisie par le citoyen est optionnelle.

On se limitera à 255 caractères.

Taux de gravité

Information subjective renseigné par le citoyen de type entier Des photos

Le citoyen peut associer par exemple de 0 à 3 photos.

Celles-ci sont stockées dans un répertoire spécifique.

Taille des images : pour ne pas pénaliser le temps de chargement des fichiers (d'équipement mobile vers le serveur), la taille des fichiers doit être modifiée avant envoi.

La résolution choisie est de : 800*450 avec un poids entre 50 et 100 Ko.

Chacune des photos associées possède une propriété :

· L'orientation. Les valeurs possibles sont :

o NULL : aucune information associée. (Par exemple, si l'utilisateur sélectionne des photos existantes, ou utilise le formulaire du site web).

o De 0 à 359 : valeur de l'orientation par rapport au Nord.

Cette information est disponible et sera affichée à l'opérateur de l'autorité dans l'onglet qui présente les photos de l'événement.

Exemple :

2 photos sont associées à l'événement

Photo 1 , Orientation = 310

Photo 2, Orientation = 325

Des vidéos

Le citoyen pourra associer de 0 à 3 vidéos.

Celles-ci sont stockées dans un répertoire spécifique.

A Spécifier : Re-nommage + mode de stockage.

Règles sur le poids de la vidéo ?

La gestion des vidéos ne sera pas implémenter pour la version typée Q1 . La spécification fonctionnelle associée, sera produite ultérieurement. Le statut de l'Evénement apparaissant sur le terminal de l'Autorité, et modifié par l'opérateur de l'autorité :

De la création de l'événement à sa clôture, celui-ci va suivre différents statuts. Les différents statuts sont les suivants :

OUVERT C'est le statut par défaut : l'événement est créé dans le système, mais l'algorithme de dé-doublonnage n'a pas spécifié le type de l'événement.

A TRAITER Le type de l'événement est spécifié (Primaire ou Secondaire). L'élément est donc présenté à l'utilisateur de l'autorité qui doit le traiter.

PRIS EN COMPTE L'utilisateur de l'autorité indique que l'événement est pris en compte, et donc en cours de traitement.

NON PRIS EN COMPTE L'utilisateur de l'autorité indique que l'événement ne sera pas pris en compte, il ne s'agit pas d'un événement pertinent à traiter.

TRAITE L'événement est traité, l'utilisateur de l'autorité indique le changement d'état.

CLOTURE Ce statut permet de sortir l'événement de la liste des événements en cours. Cela correspond à un archivage de l'événement.

REJETE Suite au statut « NON PRIS EN COMPTE », un événement pourra être « REJETE » si s'agit d'une « fausse » déclaration.

Pour chacun de ces états, est associée une date (date de changement d'état), ainsi qu'un lien vers l'utilisateur à l'origine de la modification.

On conserve l'historique des changements de statut. Cet historique se présentera insi :

OUVERT 12Î52/2814 - 1:1 H22 5 - :Préf!Gm| ■

A T AIT SYSTEM ■

PRIS m CO MPTE 12¾2ί28·Μ - TLiSTAEUR • U - Ρεέαοπξ ■

TRAITER UStEZOU - iiTLISTÀEliR l HOU - Préi nî II

CLOTURER 1&¾2/2:S1:4 - 1:8H ^' 3S ÛTLiSTÂEUR : - FïériOîriî ■ [0026] Principe du « dé-doublonnage d'un événement » ou du « regroupement d'Evénements secondaires avec un Evénement primaire »

Le but de cette fonction est de ne pas surcharger l'Opérateur lors du traitement des Evénements, par le stockage multiple d'informations similaires ou identiques relatives à un seul et même événement.

Prenons l'exemple d'un lampadaire public qui ne fonctionne plus.

Si plusieurs Citoyens déclarent cet Evénement : « Dysfonctionnement LAMPADAIRE », alors l'Opérateur devra traiter un grand nombre d'Evénements qui sont tous identiques. Si on ajoute à cela une période de temps assez longue pour la réparation (par exemple quelques jours), alors l'Opérateur sera submergé par un Evénement au détriment d'autres Evénements.

Pour éviter cela, un traitement spécifique (Algorithme de dé- doublonnage) sera appliquer à chaque Evénement et qui permettra de classer les Evénements en deux catégories :

• Evénement primaire

• Evénement secondaire

L'Evénement primaire correspond à la première déclaration par un Citoyen d'un Evénement pour un type donné. Celui-ci devra donc être traité par l'Opérateur et suivra un processus de changement de statut tel qu'indiqué sur le diagramme de la figure 1 .

L'Evénement secondaire correspond au même Evénement (même type) que le primaire, mais il a été déclaré par la suite. Dans ce cas, cet Evénement est rattaché à l'Evénement primaire et ne sera pas traité par l'Opérateur. Cet Evénement secondaire suivra le statut de l'Evénement primaire. L'Opérateur pourra accéder aux informations des Evénements secondaires à sa demande afin d'obtenir, par exemple, des informations complémentaires sur l'Evénement.

L'Evénement primaire aura d'autant plus d'importance qu'il y aura d'Evénements secondaires qui s'y rapporteront.

La classification est automatiquement réalisée par le système selon l'invention en fonction des paramètres suivants pour chacun desquels seront définies des plages de valeurs associées :

(A) Périmètre géographique (rayon d'action),

· (B) Période de temps

(C) Orientation (lors de la prise de la photo ou vidéo). L'Opérateur administrateur peut modifier implicitement et simplement les valeurs (A) et (B) par type d'Evénement. Les données (C) sont exploitées par le système pour départager les ambiguïtés résiduelles. D'autres données pourront intervenir pour départager ces dernières tel qu'un degré d'urgence fourni par le Citoyen.

En reprenant l'exemple ci-dessus, l'Opérateur pourra donc définir les plages de valeurs pour les règles de dé-doublonnage du type d'Evénement « Dysfonctionnement LAMPADAIRE » :

• (A) Périmètre géographique : 0-25 m

(B) Période : 0-72 heures

Concrètement, conformément à la figure 4, si un événement de type « Dysfonctionnement LAMPADAIRE » est créé, et que le service ne trouve aucun Evénement de même type créé dans les 72 heures dans un rayon de 25 mètres, alors celui-ci est de classe « Primaire ».

Dans le cas contraire (le service trouve déjà un Evénement existant dans les 72 heures ET dans un rayon de 25 mètres), l'Evénement est de classe « Secondaire » et sera rattaché à l'Evénement primaire.

Conformément aux figures 5 et 6, l'orientation, lors d'une prise de photo ou de vidéo, permettra dans certains cas, de détecter si des Evénements secondaires sont bien des doublons de l'Evénement primaire, ou si un doute subsiste. Dans ce cas, l'Evénement pourra être présenté comme primaire. Ces critères serviront à traiter automatiquement les ambiguïtés résiduelles.

Dans le cas de la figure 5, le 2 ^eme Evénement (point proche du contour du cercle) sera bien défini comme « Secondaire », car l'orientation enregistrée lors de la prise de vue est compatible avec celle de l'Evénement primaire.

Dans le cas de la figure 6, le 2 ^eme Evénement à priori défini comme « Secondaire » (Périmètre géographique et période sont respectés) se verra classé « Primaire » car l'orientation de prise de vue ne correspond pas à celle du précédent Evénement.

Le système selon l'invention fournit donc à l'Opérateur les moyens pour paramétrer la fonction de dé-doublonnage. Algorithme de regroupement

Le système comprend en outre un algorithme permettant de regrouper des Evénements survenant après d'un Evénement primaire et en dehors des plages de valeurs de paramètres prévus pour qualifier un Evénement de secondaire, et de les attribuer à l'Evénement primaire.

Plus précisément, cet algorithme utilise en plus des paramètres initiaux définis pour qualifier un Evénement secondaire (périmètre géographique A et période B selon l'exemple précédent), une pondération pour chacun de ces paramètres, par exemple comprise entre 1 et 10 et permettant d'attribuer une note permettant d'apprécier pour le paramètre considéré la probabilité qu'il soit réellement secondaire (la note « 1 » représentant une probabilité très faible, par exemple, un Evénement intervenant à plus de 100 m d'un Evénement du même type, et la note « 10 », une probabilité très importante, cette note de 10 pouvant être réservée aux Evénements intervenant dans la tolérance prévue pour qualifier un Evénement de secondaire).

Par exemple, si un Evénement est signalé :

dans la même catégorie qu'un Evénement précédent en date, « Dysfonctionnement LAMPADAIRE » pour reprendre l'exemple précédent,

à un emplacement situé à 26 m de l'Evénement précédent (c'est à dire en dehors du périmètre de 25 m autour dudit Evénement précédent défini dans l'exemple précédent pour identifier un Evénement comme secondaire, mais à un mètre près), et

dans les 73 heures suivant la survenue de cet Evénement précédent (c'est à dire une heure trop tard par rapport à la durée de 72 heures définie pour identifier un Evénement comme secondaire dans l'exemple précédent),

la note attribuée au paramètre géographique A sera relativement élevée (par exemple 9/10) et celle attribuée au paramètre temps B, également élevée (par exemple 9/10 également) tant les probabilités sont grandes que cet Evénement situé certes en dehors du périmètre et de la période définis pour être identifié comme secondaire, soit en réalité un Evénement secondaire de l'Evénement précédemment signalé.

Un algorithme mathématique pourra être prévu pour attribuer une pondération à chaque paramètre permettant de qualifier un Evénement secondaire en fonction de l'écart observé pour un Evénement de la même catégorie qu'un Evénement précédent, entre le paramètre relevé pour l'Evénement considéré, et la plage de valeurs définie pour ce paramètre pour qualifier un Evénement de secondaire. L'on pourra éventuellement prévoir de calculer une moyenne des notes attribuées pour l'ensemble des paramètres de qualification d'un Evénement secondaire. Un exemple de l'algorithme de calcul d'une telle note de regroupement est donné ci-après :

La méthode va s'appuyer sur le calcul de deux notes :

^• Le taux de fiabilité explicite.

· Le taux de fiabilité implicite.

Chacune de ces notes sera ensuite pondérée pour calculer une note finale entre 0 et 100.

Etape 1 : on recherche s'il existe des événements « Primaires » potentiels :

^• Si aucun événement primaire ne correspond, alors il n'y a pas de calcul de la note finale.

• Sinon, on doit calculer une note finale pour choisir le rattachement ou non à cet événement.

Plus la note finale est proche des 100, et plus le système est confiant sur l'affectation du nouvel événement en « Secondaire » : un précédent événement « Primaire » est clairement identifié.

Inversement, si la note finale est proche de la valeur 0, cela indique que la relation vers un événement « Primaire » n'est pas identifiée.

Entre ces deux valeurs (0 et 100), on pourra définir des seuils pour lesquels le système choisira automatiquement ou non un type d'événement.

L'Administrateur de l'autorité pourra définir ses propres seuils, et ainsi choisir son mode de gestion pour son autorité :

^• Affectation automatique des événements en Primaire ou Secondaire

L'affectation d'un type secondaire est automatique si la note finale est supérieure ou égale à une valeur de seuil (par exemple 70/100)

^• Intervalle de valeur pour lequel l'affectation n'est pas automatique et le système demande une validation de la part de l'opérateur en charge.

Si la note est inférieure à une première valeur de seuil (par exemple 65/100), l'Evénement est automatiquement identifié comme primaire, supérieure à une deuxième valeur de seuil (par exemple 70/100), il est automatiquement identifié comme secondaire, et lorsqu'elle est comprise dans l'intervalle défini par ces deux valeurs de seuil (en l'occurrence entre 65/100 et 70/100), une validation est demandée à l'opérateur de l'Autorité qui identifie par son appréciation l'événement comme primaire ou secondaire en cliquant sur une zone active correspondante de l'écran de son terminal,

a) Calcul du taux de fiabilité explicite Le calcul de ce taux s'applique sur les 2 valeurs : Période et Distance.

Le principe : plus la valeur calculée est proche de 100, plus le taux de fiabilité explicite augmente.

On doit calculer 2 notes :

· Une note pour la Période

• Une note pour le Rayon

Le taux de fiabilité explicite correspond donc à la moyenne des 2 notes précédemment décrite :

N&ietPsrioûe + Not»R3 on

Taux de fiabilité explicite =

b) Calcul du taux de fiabilité implicite

Le calcul de ce taux s'applique sur 2 valeurs.

Le principe : plus la valeur calculée est proche de 100, plus le taux de fiabilité implicite augmente.

On doit calculer 2 notes :

• Une note sur l'orientation des prises de vues (photos).

· Une note sur la fiabilité de la géolocalisation.

Le taux de fiabilité implicite correspond donc à la moyenne des 2 notes précédemment décrites :

ftfote Qàeat. Photo + Hot* type <fe Géofoc.

Taux de fiabtiité implicite ^■

c) Calcul de la note finale

A partir des 2 notes : taux Explicite et taux Implicite, on calcule la note finale.

L'Administrateur de l'autorité défini des coefficients pour chacun de ses 2 taux. Puis on calcule la note finale en fonction de ces 2 valeurs :

Coeff :E ^* TFE ^■ ÷ Caefi * TF!

Note finale =

Coeff.E + CoefcJ

Lien vers les événements Secondaires

Un événement primaire peut donc être lié à 0 ou plusieurs événements secondaires.

Pour un événement « Primaire », on accède donc à la liste des événements « Secondaires » au travers d'un tableau.

On aura donc dans ce tableau, les propriétés directes et on accédera aux propriétés indirectes par la méthode des actions « Formulaire qui s'intègre dans les lignes du tableau.

Une action particulière (suite à une action volontaire d'un opérateur) permettra de modifier un événement « Secondaire » en « Primaire » :

o À partir de ce moment, l'événement devenant « Primaire », il perd sa relation avec le précédent événement « Primaire ».

o II quitte le tableau et devient un élément « Primaire » avec une note finale = 0. o Quel que soit son précédent statut, il prend le statut : « A TRAITER ».

o On garde l'information sur le fait qu'un opérateur à modifier le type de cet événement.

Demande d'informations complémentaires

Cette fonctionnalité permet pour un événement particulier, d'envoyer sur des équipements identifiés (terminaux des utilisateurs par exemple) une demande d'informations complémentaire.

L'Administrateur définit un rayon pour lequel il désire atteindre les équipements.

En fonction de la valeur du rayon, le système lui indique le nombre d'équipements qui sont potentiellement dans la zone.

Lorsque la demande est envoyée, elle contient les informations suivantes :

Date et heure de la demande d'informations complémentaires

Type de l'événement primaire

Coordonnées de l'événement « Primaire »

Texte explicatif saisi par l'opérateur.

Ces informations permettront de pré-remplir le formulaire dans les équipements adéquats ; chacun des citoyens recevant cette demande, pourront donc ajouter de l'information :

o Plus de description

o Photos

Automatiquement, ces événements déclarés par le citoyen sont de type « Secondaire » et associés à l'événement primaire initial.

On détaille dans ce qui suit l'algorithme de regroupement et la méthode de calcul des notes :

ETAPE 1 : ON RECHERCHE S'IL EXISTE DES EVENEMENTS « PRIMAIRES POTENTIELS Pour une déclaration d'événement, on recherche dans la base de données s'il existe une liste d'événements de type « Primaire » possédant comme caractéristiques :

• Le même type (catégorie, type, sous- type, etc ..)

· Possédant une date telle que :

[NOW] - [Date du statut « A TRAITER »] < [valeur de la période]

• Possédant une Géolocalisation telle que :

[Le calcul de la distance] < [Valeur du rayon]

Le résultat de cette recherche sera interprété de cette manière

Résultat de la requête est vide : Résultat de la requête non vide :

Aucun événement primaire ne Un événement primaire correspond correspond. aux critères.

Le nouvel événement est donc On ne peut pas définir le type automatiquement typé « PRIMAIRE » immédiatement, le calcul de la note est indispensable.

Attention : si un résultat existe, celui- ci doit être unique. Dans le cas contraire, c'est qu'il existe une incohérence dans les données : l'Administrateur doit en être informé immédiatement (email).

Pas de calcul de note finale. Calcul de la note finale nécessaire.

Celle-ci est automatiquement égale à 0

Les notes explicites sont déterminées par la formule :

Note explicite = 100 - 100 ^* période ou rayon de survenue de l'Evénement / période ou rayon défini

Note explicite Période ou Rayon

Période ou Rayon de survenue de V Evénement

= 100 - 100 x _n , . j ^ 7 -.

Période ou Rayon définie

ex : a. Prenons un exemple d'une Période définie sur 48 heures. Si l'événement est déclaré 30 heures après l'événement « Primaire », alors, la note est calculée comme suit :

30

Note explicite Période = 100 - 100 x— = 37%

48

b. Prenons un exemple d'une Période définie sur 48 heures. Si l'événement est déclaré 5 heures après l'événement « Primaire », alors, la note est calculée comme suit :

5

Note explicite Période = 100 - 100 x— = 90%

48

c. Prenons un exemple d'un Rayon défini à 25 mètres. Si l'événement est déclaré à 20 mètres de la géolocalisation de l'événement « Primaire », alors, la note est calculée comme suit :

20

Note explicite Rayon = 100 - 100 x— = 20% d. Prenons un exemple d'un Rayon défini à 25 mètres. Si l'événement est déclaré à 7 mètres de la géolocalisation de l'événement « Primaire », alors, la note est calculée comme suit :

7

Note explicite Rayon = 100 - 100 x— = 72%

Le taux de fiabilité explicite correspond à la moyenne des 2 notes « Rayon » et « Période » précédemment décrite :

NotePériû îe + Hoteftsycm

Taux, de fiabilité explicite =

Exemple, en prenant les exemples ci-dessus, en combinant les différents résultats, on aurait les valeurs suivantes :

CALCUL DU TAUX DE FIABILITE IMPLICITE

Le calcul de ce taux s'applique sur 2 valeurs.

Le principe : plus la valeur calculée est proche de 100, plus le taux de fiabilité implicite augmente.

On doit calculer au moins une note : • Une note sur la fiabilité de la géolocalisation.

Il existe 4 types de géolocalisation :

o GPS EQUIPEMENT

o GPS_BTS

o GPS_CARTO

o QRCODE

Pour chacun de ces types, l'Administrateur de l'autorité indiquera des valeurs permettant de définir la fiabilité de la Géolocalisation en fonction du type.

On aura donc par exemple des valeurs définies de cette manière :

Si la géolocalisation est effectuée par un type GPS_EQUIPEMENT, alors la note sera fixée à 90,

Si la géolocalisation est effectuée par un type GPS_BTS, alors la note sera fixée à 40,

Si la géolocalisation est effectuée par un type GPS_CARTO, alors la note sera fixée à 60,

Si la géolocalisation est effectuée par un type GPS_QRCODE, alors la note sera fixée à 100. · et éventuellement, une note sur l'orientation des prises de vues (photos).

Cette note sera calculée uniquement si des valeurs existent :

L'événement Primaire doit posséder des photos et des valeurs concernant l'orientation de ces photos.

L'événement à classifier doit lui aussi posséder des photos et les valeurs associés sur l'orientation.

Si aucune de ces conditions n'est respectées, le calcul de la note ne peut pas avoir lieu, et de fait, cela ne rentre pas en compte dans le calcul de la note implicite (et donc globale) Le taux de fiabilité implicite correspond donc à la moyenne des 2 notes précédemment décrites : tilote Orient. Photo + ''foie type de Geoksc

Tau* de fiabilité implicite =

Exemple, en prenant les exemples ci-dessus, en combinant les différents résultats, on aurait les valeurs suivantes :

CALCUL DE LA NOTE FINALE

A partir des 2 notes : taux Explicite et taux Implicite, on calcule la note finale.

L'Administrateur de l'autorité défini des coefficients pour chacun de ses 2 taux : Puis on calcule la note finale en fonction de ces 2 valeurs :

C∞ff.£ '' TFE ÷ Caef.i * TFÎ

Note finale =

Coeff.E ÷ Ceeff.î

Exemple, en prenant les exemples ci-dessus, en combinant les différents résultats, on aurait les valeurs suivantes :

Période de résolution

Elle correspond au temps imparti à l'autorité pour traiter l'événement. Ce délai est défini pour chaque type d'événement. Il correspond à la valeur « Période » utilisée par l'algorithme de regroupement.

Le délai démarre à partir du moment où l'événement est dans le statut : « A TRAITER » ou « PRIS EN COMPTE »

Pour un événement, en fonction de son statut, celui-ci pourra être répertorié:

o Dans le délai,

o Hors délai

On affichera sur le terminal de l'Autorité, une représentation de ce délai avec le temps qu'il reste, ou inversement, le temps passé après le délai.

Sévérité - Priorité d'un Evénement signalé

En fonction du type d'Evénement signalé (dangereux pour la population ou non), du nombre de signalements d'Evénements secondaires pour un Evénement primaire, ou encore de l'identité de l'utilisateur ou de l'entité ayant signalé cet Evénement, l'on pourra déterminer un degré de sévérité pour l'Evénement considéré (par exemple compris entre 1 et 10) et un affichage d'alerte pour l'Evénement en question sur le terminal de l'Autorité au sein de laquelle il a été signalé.

Par exemple, cet Evénement pourra apparaître avec une couleur dépendant de la sévérité qui lui aura été attribuée, avec un signal visuel (affichage clignotant de l'Evénement) ou sonore (alarme).

Les Evénements avec un degré de sévérité important pourront apparaître de façon prioritaire sur la liste des Evénement s'affichant sur le terminal de l'Autorité. L'application de ce degré de sévérité pourra s'effectuer par l'opérateur dédié à la gestion du terminal de l'Autorité, ou de façon automatique grâce à un algorithme prévu à cet effet. Fonction urgence

Un objet informatique permettra de déclarer un Evénement à un service de sécurité national type police national, Samu, pompier, ou de la ville type commissariat municipal. Citoyen à l'origine de la déclaration

Un lien entre l'objet « Evénement » et l'objet « Citoyen » est conservé.

On peut donc à tout instant connaître le citoyen à l'origine de l'événement.

A partir d'un événement, on pourra afficher les informations du citoyen :

• Nom

· Prénom

• Email • Photo

Equipement à l'origine de la déclaration

Il existe un lien entre l'équipement (l'équipement mobile : IPhone, Android, Wphone) et le citoyen.

Un citoyen peut utiliser plusieurs équipements.

Un événement est créé par un citoyen, à partir :

• d'un équipement mobile ou

• depuis le formulaire du site Web.

A partir d'un événement, on pourra afficher les informations de l'équipement :

• ID

• Type d'équipement (IPhone, Android, Wphone)

Degré de confiance, de crédibilité - Récompense

Un historique des Evénements signalés par chaque utilisateur permet de connaître pour chacun son ancienneté, le nombre de signalement d'Evénements qui ont été confirmés par d'autres utilisateurs, la nature des Evénements signalés (dangerosité)...

En fonction de ces données, un utilisateur se voit attribué un degré de confiance, ou des points de crédibilité par exemple calculé par un algorithme, et noté de 1 à 10.

Les points

Les points associés à la déclaration d'un événement de type primaire seront affectés à l'événement.

Un paramétrage global par autorité permettra de définir le nombre de points pour un événement déclaré de type Primaire et de type Secondaire.

On aura donc 2 paramètres

• NBPOINTS_PRIMAIRE (de 0 à 10).

• NBPOINTS SECONDAIRE (de 0 à 10).

Un autre paramètre permettra de définir si l'autorité utilise ou pas le système d'attribution des points :

• SERVICE_POINTS : OUI/NON.

Règles d'attribution des points :

1 .A chaque déclaration d'un événement, le nombre de points définis par les paramètres est ajouté à cet événement.

2. Il n'y a pas besoin de validation de la part d'un utilisateur de l'autorité. Les points sont automatiquement associés à l'équipement.

3. En revanche, l'utilisateur de l'entité peut au cas par cas, ajouter ou supprimer des points à l'événement.

4. Si un événement typé Primaire devient Secondaire (ou inversement) par action de l'utilisateur, alors les points sont réattribués. Par exemple :

Pour une collectivité, les valeurs pour les paramètres sont :

· NBPOINTS PRIMAIRE = 10

• NBPOINTS SECONDAIRE = 2

Un citoyen déclare un événement de type : « Défaut de signalisation routière / Feux tricolores ».

Si après traitement, l'événement est :

· De type Primaire, celui-ci se voit attribuer 10 points.

• De type Secondaire, celui-ci se voit attribuer 2 points.

Mais l'utilisateur en charge du traitement de l'événement possède le droit de modifier cette attribution de points. Il devra donc saisir une nouvelle valeur dans la fiche associée à l'événement puis « Valider ».

Ce degré de confiance pourra être pris en compte dans le calcul de la sévérité d'un Evénement signalé (voir ci-dessus) et ainsi pour évaluer la priorité de l'Evénement signalé.

Ce degré de confiance, ou ces points de crédibilité pourra permettre la délivrance de récompenses, telles que des chèques cadeaux, en lien avec l'Autorité à laquelle l'Utilisateur est abonné (par exemple, une réduction sur le montant de l'abonnement annuel à la piscine municipale).

Idéalement, dans le but d'éviter une utilisation abusive de l'application selon l'invention, par un utilisateur désirant artificiellement augmenter son degré de confiance, la récompense pourra prendre la forme d'un avantage attribué à un tiers (par exemple un chèque à l'attention d'une association de la municipalité) et non à l'utilisateur lui-même.

Egalement, toujours dans le but d'éviter à des utilisateurs vénaux de déclarer des Evénements en nombre pour augmenter leurs chances d'obtenir une récompense, en créant une multitude de comptes d'utilisateur afin de confirmer en nombre un Evénement déclaré à partir d'un compte principal, il est prévu de pouvoir vérifier si plusieurs comptes d'Utilisateur crées correspondent bien à des terminaux différents, par exemple grâce à un identifiant du terminal de l'utilisateur qui sera enregistré en lien avec le premier compte d'utilisateur crée à partir de ce terminal. En fonction de l'identité de l'Utilisateur, le degré de confiance ou les points de crédibilité accordés pourront être plus importants. C'est notamment le cas lorsque l'Utilisateur est reconnu comme un Agent de confiance (un agent technique de la ville par exemple) ou comme un Utilisateur au degré de confiance élevé. Si au contraire, un Utilisateur s'avérait nuisible pour le bon fonctionnement du service, d'après par exemple le caractère farfelu des Evénements ou la teneur des messages qu'il associe à ces Evénements (à caractère raciste, pornographique, contraires à l'ordre public .) un message pourra être émis par une Autorité pour l'inviter à améliorer la qualité de ses signalements. A défaut, cet Utilisateur pourra être banni de la communauté.

L'enregistrement d'un identifiant pour le terminal de l'Utilisateur banni permettra d'éviter qu'il crée un autre compte sur le même terminal après avoir été banni. Par ailleurs, un outil informatique de reconnaissance pourra être prévu pour analyser les captures d'image ou les vidéos accompagnant le signalement d'un Evénement et supprimer celles représentant un individu d'une façon permettant son identification. Un message pourra être adressé à l'utilisateur lui rappelant qu'aucune donnée de ce type n'est acceptée par le service. Une alternative sera l'utilisation d'un outil informatique permettant de brouiller tout visage identifié sur une capture d'image ou une vidéo.

Synchronisation - problèmes de réseau:

Chaque Evénement est enregistré localement sur le terminal de l'Utilisateur, et lorsque ce dernier est en mesure de communiquer avec le serveur, également sur ce serveur.

Ainsi, en cas d'absence de réseau, la création d'un Evénement reste possible et celui-ci est stocké sur le terminal pour être communiqué au serveur ultérieurement.

La synchronisation des Evénements à signaler et stockés sur le terminal de l'utilisateur, et des Alertes stockées sur le serveur et à transmettre au terminal de l'utilisateur s'effectue dès que le terminal est connecté à un réseau.

L'application téléchargée sur le terminal pourra permettre l'envoi d'une notification lorsqu'une absence de réseau est détectée avec la géolocalisation de la perte du réseau, afin d'avertir une Autorité de la présence dans son périmètre d'une zone d'absence de réseau, ou de la survenue d'un problème de réseau, problème pouvant être transmis au service compétent de l'Autorité, ou à un service externe à celle-ci tel que le service d'un fournisseur national de réseau.

Gestion par les Autorités

Au niveau du terminal d'une Autorité, les événements signalés sont regroupés par sous groupe en fonction des services de l'Autorité et communiqués de façon automatique au service considéré.

Le terminal d'un Utilisateur communique à une fréquence donnée sa géolocalisation au serveur (par exemple toutes les 15 mn) et reçoit les Alertes émanant de l'Autorité considérée, tant que la dernière position de géolocalisation est située dans le périmètre de l'Autorité considérée.

Lorsque la géolocalisation du terminal de l'Utilisateur le positionne en dehors du périmètre géographique d'une Autorité qu'il vient de quitter, il en est averti par une Notification (« Vous venez de quitter Le Perreux sur Marne, Bienvenue à Neuilly sur Marne ») et peut se voir proposer :

- de continuer à recevoir les Alertes de l'Autorité qu'il vient de quitter,

- de commencer à recevoir les Alertes de l'Autorité qu'il vient de rejoindre, si celle-ci adhère au service, et dans la négative, d'envoyer un message à cette

Autorité pour l'inciter à adhérer au service

Un historique des Evénements signalés dans le périmètre d'une Autorité permettra de proposer à un Utilisateur désirant signaler un nouvel Evénement dans l'Autorité concernée, de se voir proposé, dans l'interface de saisie d'un nouvel Evénement, une liste des différents Evénement déjà signalés.

REGLES DE SUPPRESSION D'UN EVENEMENT PAR LE CITOYEN

Le citoyen à l'origine de la création d'un événement reste le « propriétaire » de cet événement.

II peut donc à tout instant décider de le supprimer entièrement ou en partie.

SUPPRESSION OU MODIFICATION PARTIELLE

Le citoyen peut modifier ou supprimer certaines informations associées à l'événement.

II peut donc modifier les informations suivantes :

• Le taux de gravite

• La description

Les autres propriétés de l'événement (son type, sa géolocalisation, etc.) ne sont pas modifiables par le Citoyen.

En ce qui concerne les photos, le Citoyen peut :

• Les supprimer : il s'agit vraiment d'une suppression physique : le fichier est supprimé du serveur

• En ajouter, si les 3 emplacements photos disponibles ne sont pas utilisés.

SUPPRESSION TOTALE

La suppression totale implique pour le citoyen que cet événement n'existe plus. Il ne pourra donc plus apparaître dans sa liste « Mes événements ».

Mais cet événement reste disponible pour l'Autorité qui en a la charge, avec les modifications suivantes :

• Le lien vers le Citoyen qui en est à l'origine n'existe.

• Et donc le lien vers l'équipement n'existe plus.

• Les photos sont physiquement supprimés (car pour le citoyen, il a vraiment supprimé l'événement et donc les photos associées).

Pour un utilisateur de l'Autorité, cet événement apparaîtra toujours dans le tableau des événements, mais il sera représenté avec une particularité (couleur spécifique de la ligne par exemple) pour que l'utilisateur identifie immédiatement que le Citoyen à supprimer cet événement.

L'utilisateur de l'autorité aura le choix de traiter cet événement ou de le clôturer si celui-ci n'est plus pertinent.

Gestion des Autorités par l'Administrateur global

L'Administrateur global est dédié à la gestion des différentes Autorités et des différents utilisateurs. Il possède un terminal doté d'une interface de gestion de ces Autorités.

Cette interface permet d'accéder à l'interface de chaque Autorité et d'y intervenir comme l'Autorité elle-même, et de créer un nouveau compte pour une nouvelle Autorité.

Cette interface permet également la visualisation de différentes cartographies de différentes Autorités sur lesquelles les Evénements signalés sont repérés par signe, cliquable afin de connaître le détail de l'Evénement considéré.

Cette interface est reliée à une source d'information sur les cadastres des différentes villes ou cantons d'un territoire, mise à jour régulièrement, et permet, lorsqu'une nouvelle Autorité veut s'abonner au service, de délimiter automatiquement à partir du code postal de la ville ou canton, d'un périmètre sur une carte.

Si une ville veut s'abonner, elle renseigne les différents Evénements qu'elle autorise un Utilisateur à déclarer, renseigne des identifiants pour les différents services susceptibles de traiter ces Evénements, et des adresses emails ou des liens vers ceux ci permettant de leur pousser les Evénements signalés, ainsi que les différents paramètres du systèmes (paramètres de regroupements, degré de confiance).

Cette interface permet non seulement l'introduction d'une nouvelle Autorité dans le système mais aussi celle d'un système d'information extérieur, tel qu'un système d'information gouvernemental (par exemple : Police national pour les Alertes enlèvement).

En effet, à chaque Autorité, l'Administrateur global pourra proposer les Alertes d'un système d'information extérieur. [0027] Localisation d'une Alerte

[0028] L'Alerte est obligatoirement associée à un périmètre géographique et diffusée aux Citoyens présents dans ce périmètre.

La notion de géolocalisation pour une Alerte est donc double :

1 . Il faut tout d'abord définir le périmètre géographique associé à la diffusion de cette Alerte : Par défaut, il s'agira du périmètre sur lequel s'étend le pouvoir d'une autorité (Par exemple pour une commune, il s'agira du périmètre du territoire communal).

L'Opérateur aura aussi la capacité de modifier ce périmètre :

a. Digitaliser spécifiquement un périmètre (pour une Alerte qui serait uniquement diffusée dans le centre-ville par exemple)

b. Sélectionner des territoires adjacents (pour une Alerte diffusée sur une commune, et les communes environnantes).

Le périmètre géographique de diffusion de l'alerte est indépendant du lieu courant de localisation du terminal de l'Autorité par lequel sont émises des Alertes.

2. L'Alerte est diffusée uniquement aux Citoyens présents dans le périmètre défini pour l'Alerte.

Cela implique donc que le système et le procédé selon l'invention connaissent à tout instant où se trouve réellement les Citoyens déclarés dans le système.

Autrement dit, la liste des Citoyens (et donc de leurs équipements) impactés par la diffusion d'une Alerte sera calculée par le système au travers d'une requête de type Géo-Spatiale qui en superposant les deux informations géographiques (périmètre de l'alerte et positions des différents équipements) en déduira le groupe de Citoyens à atteindre.

Par exemple, prenons une Alerte dont le périmètre de diffusion correspond à un cercle sur un territoire donné :

Conformément à la figure 7, on connaît à chaque instant la position de tous les Citoyens (équipements) déclarés dans le Service Alert-Phone (étoiles blanches à contour noir).

Une Alerte est créée. Le périmètre de diffusion de cette Alerte correspond à un cercle tel que représenté sur la figure 8 (Choix de l'Opérateur). Conformément à la figure 9, le système, au travers d'une requête Géo-Spatiale définit la cible des Citoyens (équipements) pour lesquels l'Alerte sera diffusée (étoiles noires).

Les autres Citoyens n'étant pas dans le périmètre de l'Alerte ne seront pas notifiés de celle-ci.

[0029] En plus de la réception d'Alertes sur une zone géolocalisée, le Citoyen pourra choisir de s'abonner aux alertes d'une ou de plusieurs Collectivités. Il recevra ainsi les Alertes correspondantes même si ce dernier n'est pas localisé dans la zone de diffusion de l'Alerte.

[0030] Récompense du Citoyen

[0031] Un système d'obtentions de points sera mis en place pour rendre attractif le service et récompenser le Citoyen actif.

[0032] Le principe de base est que pour tout nouvel Evénement déclaré, l'utilisateur reçoit des points.

[0033] La validation de l'acquisition des points sera réalisée par l'Opérateur en charge du traitement de l'Evénement.

[0034] Pour un Evénement de type « Primaire », le Citoyen reçoit des points

[0035] Pour un Evénement de type « Secondaire », aucun point ne sera octroyé, sauf si l'Opérateur trouve pertinent les informations associées (meilleure description de l'Evénement, ou photos et vidéos pertinentes).

[0036] Si les informations recueillies au sein des différents Evénements sont jugées insuffisantes par l'Opérateur pour traiter l'Evénement, ce dernier aura la possibilité d'émettre une demande d'information complémentaire à tous les usagers ayant signalés l'Evénement. La demande d'information complémentaire s'appuiera sur la fonction d'émission d'Alerte par sélection des Citoyens ayant transmis l'Evénement (primaire ou secondaires).

La fourniture d'information complémentaire pourra être assujettie au gain de points.

[0037] Les points gagnés par les Citoyens seront exploitables par la Collectivité par différents moyens (présentation des citoyens les plus actifs, récompenses officielles, échange des points contre des services de la Collectivité...). Selon l'usage de ses points, un traitement de la valeur des points acquis sera possible par usager par la Collectivité. GESTION DES EVENEMENTS PAR SERVICE

La notion de service correspond à un cloisonnement nécessaire à la gestion des événements créés.

L'Administrateur de l'Autorité possède la capacité de déclarer des services.

Puis de définir les relations entre la nomenclature des événements et les services.

Règles de liaisons

1 . Une Autorité possède au moins un Service. Il faudra donc créer un Service par défaut lorsque l'Administrateur INEO créera une Autorité : il s'agira du Service « Administration Autorité » qui contiendra au moins un utilisateur : l'Administrateur de l'autorité.

2. Un utilisateur de l'autorité appartient à un ou plusieurs services.

3. Un type d'événement est associé à un ou plusieurs services. De ce fait, un utilisateur verra dans les différentes fonctionnalités (tableau de gestion, sur la carte, etc.) tous les événements dont les types sont associés aux services auxquels il appartient.

[0038] Gestion de l'historique

Au titre de l'invention, il est prévu une gestion globale de l'historique des actions réalisées par les intervenants dans le système.

Cela veut dire que toutes les actions réalisées par les différents acteurs (Citoyens, Opérateurs, Administrateurs) sont identifiées et sauvegardées.

En fonction de la gestion des droits associés à chacun, l'affichage de cet historique des actions sera filtré et présenté aux différents types d'acteurs.

[0039] Architecture technique envisagée

Le système et procédé d'échange d'informations Alert-Phone est une solution logicielle en mode SaaS (Software As A Service) qui regroupe les applications suivantes :

ALERT-PHONE-SMART : Application cliente gratuite dédiées aux Smartphones (pour le Citoyen).

ALERT-PHONE : Application WEB de type portail destinée aux utilisateurs de tout type. ALERT-PHONE-COLLECTIVITE : Application WEB à destination des collectivités (configuration, gestion, traitement de l'information et des services associés).

ALERT-PHONE-ADMIN : Application WEB d'Administration globale à destination des Administrateurs du service (personnels du déposant).

ALERT-PHONE-WEBSERVICE : Méthodes Web Service d'interopérabilités qui seront consommées par des applications externes.

Conformément à la figure 1 1 , le service Alert-Phone est composé au niveau FrontOffice des interfaces suivantes :

Application pour Smartphone : ALERT-PHONE-SMART

• Site Web grand Public : ALERT-PHONE qui sera lui-même décomposé en espace privatif :

o L'espace privatif pour le Citoyen

o Les espaces privatifs pour les collectivités : ALERT-PHONE- COLLECTIVITE

• Un site Web privé (qui ne sera pas forcément accessible depuis internet) pour l'Administrateur global.

Le backoffice est composé de serveurs Web Applicatifs qui prendront en charge les composants suivants :

• Une couche d'interopérabilité (WebServices) qui sera utilisée par le FrontOffice du Service Alert-Phone. Cette même couche de WebServices pourra être utilisée par des applications externes.

Un ou plusieurs serveurs d'applications Web qui seront parallélisés en fonction de la charge globale (sollicitation du système).

Un système de gestion de base de données et de stockage de fichiers (Photos, vidéos).

DETAILS DES INTERFACES

[0040JCOTE UTILISATEUR : APPLICATION POUR TELEPHONE MOBILE

[0041] L'application pour terminal mobile, permettra au Citoyen de s'identifier en créant un profil, de s'abonner au service, de sélectionner des villes dont il souhaite recevoir des Alertes, de sélectionner le type d'Alertes qui l'intéresse (Alerte météorologiques, accident de circulation, fermeture d'une école...), de déclarer les Evénements et de recevoir des Alertes.

[0042] A travers l'application pour téléphone mobile, le Citoyen pourra déclarer un Evénement et ses données associées : Choix du type d'Evénement

Géolocalisation de l'Evénement

Commentaires ou informations supplémentaires

Photos

Vidéos

Degré d'urgence (note subjective du Citoyen)

[0043]Toutes ces informations associées à l'Evénement créé par le Citoyen sont la propriété du Citoyen déclarant. Il possède donc un droit de modification et de suppression à tout instant sur cet Evénement.

[0044] Il peut associer au signalement d'un Evénement, différents médias tels qu'une photo ou une vidéo. Dans ce cas, une option permettant le masquage dynamique des visages pourra être prévue.

[0045] Les fonctions associées à ce masquage seront établies suivant les cas suivants :

- L'Opérateur, c'est-à-dire la collectivité recueillant le signalement, peut activer ou non le masquage lorsqu'il visualise les médias associés (ou en fonction de droits associés à l'Opérateur)

- Le Citoyen aura la capacité de rendre le masquage soit dynamique soit permanent

[0046] Le Citoyen peut en outre supprimer :

- Les documents attachés à son Evénement : Photos et vidéos. Ces documents seront réellement supprimés de la plateforme où ils sont stockés. Personne (Administrateur, Opérateur) ne peut les consulter après cette opération de suppression.

- Un Evénement : dans ce cas, cet Evénement disparait des listes du Citoyen, mais celui-ci reste présent dans le système (dans la plateforme) pour traitement (si besoin). Tous liens entre l'Evénement et le Citoyen sont alors supprimés, il sera impossible de faire un lien entre l'Evénement et le Citoyen l'ayant initialement déclaré.

Il sera typé « Supprimé », pour que l'Opérateur soit conscient de cet état. Il ne pourra donc plus communiquer expressément sur cet Evénement (avec le Citoyen déclarant ou d'autres Citoyens). Impossible donc de demander plus d'informations sur cet Evénement.

[0047]Cette application pour Smartphone devra être développée notamment pour les OS suivants :

• IOS : iPhone®

ANDROID®

• Windows® Phone (W8) [0048]Chaque application (la partie FRONT et utilisation des API du téléphone) sera développée en utilisant les technologies propres à chaque environnement, mais utilisera des WS identiques qui seront eux développés coté Serveur : Java J2EE. Dans la mesure du possible, du code JavaScript commun aux 3 environnements sera utilisé.

[0049] En pratique, le Citoyen désireux de mettre en œuvre le système selon l'invention doit installer l'application sur son Smartphone. L'utilisation de cette application nécessite forcément une authentification :

• Le Citoyen doit être déclaré comme utilisateur du service · Le Citoyen doit s'authentifier et déclarer son équipement pour accéder aux fonctionnalités de l'application.

• Seule la fonctionnalité de notification d'Alertes (Réception d'une Alerte) est active sans authentification.

[0050] Formulaire d'inscription de l'utilisateur

Puisque l'authentification est obligatoire, un nouvel utilisateur peut se déclarer auprès du service à partir de cette application.

Ce formulaire peut potentiellement être relativement court (en tous cas plus court que celui du portail web ALERT-PHONE détaillé par la suite). L'utilisateur pourra ultérieurement ajouter d'autres informations sur son compte.

Le processus d'inscription demande à l'utilisateur de saisir un code reçu par SMS, cela afin de valider la création et l'activation du compte.

[0051] Formulaire de déclaration d'un terminal mobile

[0052] Un Citoyen peut posséder plusieurs téléphones ou tablettes. Dans ce cas, un formulaire lui permet de déclarer plusieurs équipements. Il sera donc reconnu comme Citoyen unique quel que soit le terminal mobile utilisé.

[0053] Formulaire de connexion/déconnexion

[0054] La connexion est obligatoire pour accéder aux fonctionnalités du service après avoir rempli le formulaire de connexion. La déconnexion de l'utilisateur se fait au travers du formulaire déconnexion qui, une fois validé, ne permettra plus à celui-ci d'accéder aux fonctionnalités.

[0055] Page « Accueil », personnalisation de l'application

[0056]Au lancement de l'application, un contrôle est réalisé entre les collectivités auxquelles adhèrent le Citoyen, et la position géographique ou il se trouve réellement (Géolocalisation). [0057] Les cas suivants seront gérés :

• Si le Citoyen se trouve réellement dans une collectivité supportant le Service, l'application est personnalisée (Logo, nom de la collectivité, charte graphique, etc.).

• Si le Citoyen se trouve dans une collectivité ou zone géographique non adhérente au service Alert-Phone, alors l'application le notifie de cette situation, et la page d'accueil sera une page par défaut. Dans ce cas, il pourra être prévu un bouton d'action qui proposera au Citoyen d'envoyer un message à la commune : « Voulez-vous signifier à la commune l'existence du service Alert-Phone ? »

[0058] Gestion de la géolocalisation

[0059]On propose au Citoyen de gérer lui-même la période avec laquelle l'application ALERT-PHONE-SMART remontera au service la position (géolocalisation) de son équipement.

[0060]A titre d'exemple, la remontée de cette information sera comprise entre 1 minute et 1 heure. Le traitement local (fonction de l'application ALERT-PHONE-SMART) est consommatrice d'énergie. Cela ne doit pas être réalisé au dépend de l'utilisation de l'équipement lui-même par le Citoyen.

[0061]A partir d'un certain seuil du niveau de la batterie, l'application ALERT-PHONE-SMART adaptera automatiquement la période d'envoi de la position de l'équipement pour ne pas solliciter la batterie dans ce contexte.

[0062] Lorsque le terminal est connecté au secteur et ne fonctionne plus sur batterie, la remontée de l'information de position (géolocalisation) s'active automatiquement sur un cycle court (toutes les 5 minutes par exemple).

[0063] Déclarer un Evénement

[0064] La principale fonction est bien que l'utilisateur remonte des Evénements. Toute une nomenclature d'Evénements (en fonction des services disponibles et paramétrés par la collectivité) sera présentée.

Un Evénement aura les propriétés suivantes :

• Information géographique (géolocalisation)

Informations alpha (texte, type, date, etc.).

• Photos associées (et orientations lors de la prise de vue)

Vidéos associées • Curseur qualitatif : l'utilisateur peut donner une note (de 1 à 5 par exemple), pour signifier la gravité du fait.

A l'issue de la déclaration de l'Evénement, l'utilisateur sera notifié :

• Evénement « primaire » avec potentiellement l'attribution de points.

• Evénements « secondaire » (Evénement déjà déclaré).

• Le cas échéant, les points acquis grâce à cet Evénement.

[0065] Demande d'informations supplémentaires

Dans le cas d'un Evénement secondaire, c'est-à-dire d'un Evénement préalablement déclaré, la collectivité peut demander aux utilisateurs des informations complémentaires.

Un utilisateur à l'initiative d'un Evénement « secondaire » pourra par ailleurs se voir attribuer des points si les informations remontées (photo, vidéo) sont pertinentes.

[0066] Souscrire aux abonnements (Souscrire aux collectivités)

Le Citoyen peut « s'abonner » pour recevoir les Alertes et adresser des Evénement d'une ou plusieurs collectivité(s) adhérente(s) au service de l'invention.

· Un formulaire dans lequel l'utilisateur sélectionne les collectivités.

• Une demande d'abonnement dynamique lorsque l'utilisateur suite à ses déplacements, arrive dans une collectivité qui possède ce type de service.

Le fait de s'abonner à une collectivité, permettra au Citoyen de :

• Déclarer des Evénements pour cette collectivité.

• Recevoir les Alertes émises par cette collectivité pour lesquelles le Citoyen s'est abonné. [0067] Recevoir les Alertes

[0068]Cette fonctionnalité est transparente pour le Citoyen, dans le sens où il recevra les Alertes du Service Alert-Phone générées par la collectivité dans laquelle il se trouve actuellement.

Le Citoyen recevra donc uniquement les Alertes qui répondent aux critères suivants :

• Le Citoyen se trouve dans le périmètre de diffusion de l'Alerte • De façon non obligatoire, le Citoyen a validé dans ses préférences, la volonté de recevoir des Alertes de ce type.

A noter que la réception d'Alertes n'est pas soumise à authentification. Le Citoyen peut être notifié d'une Alerte sans avoir renseigné le formulaire d'authentification. En revanche, pour consulter le contenu de cette Alerte, il devra s'authentifier dans l'application.

[0069] Consulter les Alertes

[0070] Le Citoyen consulte les Alertes actives dans la zone où il se trouve.

[0071] Média vidéo

Des fonctionnalités avancées seront associées à ce média :

- Enregistrer une vidéo, puis l'attacher à un Evénement et le déclarer.

- Réaliser une vidéo et en même temps envoyer ce flux sur les serveurs du service ALERT-PHONE. Cela permettra à des Opérateurs de la collectivité d'accéder en direct au flux vidéo.

[0072] Fonction « URGENCE » ou « SOS »

[0073] Fonction qui permet au Citoyen de créer un Evénement de type « SOS » par simple clic. La finalité est de fournir au Citoyen en situation d'urgence ou de stress, un moyen d'émettre le plus rapidement possible un Evénement pour alerter les services compétents (Pompier, Samu, Police, Gendarmerie, Police municipale, etc.). Lors de l'envoi d'un « SOS », un compte à rebours apparaît sur le terminal avant l'envoi effectif (10 secondes par exemple) afin de permettre au Citoyen d'annuler son « SOS » s'il s'agit d'une erreur.

[0074]Cet Evénement envoie la géolocalisation de la personne pour une identification plus précise de la situation.

[0075] Le choix du service compétent apte à traiter ces Evénements de type « SOS » sera bien sûr paramétrable par la collectivité par l'Opérateur administrateur.

[0076] Fonction « PIETON / VEHICULE »

[0077] Fonction qui permet au Citoyen d'activer explicitement dans l'application son mode de déplacement :

- PIETON : mode par défaut.

- VEHICULE : mode permettant au Citoyen d'activer la remontée automatique de SOS si un choc est identifié par le terminal. Dans ce mode, le Citoyen participe à la génération de données de trafic. [0078] En mode « VEHICULE », l'émission de « SOS » peut être déclenchée automatiquement sans action du Citoyen par exemple en cas de choc d'un usager en véhicule. La finalité est d'émettre le plus rapidement possible un Evénement pour alerter les services compétents (Pompier,

Samu, Police, Gendarmerie, Police municipale, etc.) lorsqu'un choc se produit. Pour cela cette fonction exploite les données d'accéléromètre fournies par un équipement interne au terminal afin d'émettre l'Evénement. Grâce au compte à rebours disponible lors de l'émission d'un « SOS », le Citoyen peut annuler une fausse alerte avant son émission effective.

[0079] Lorsque le terminal se déplace à une vitesse supérieure à un seuil (30 km/h par exemple), le terminal s'identifie automatiquement en mode « VEHICULE » afin de consolider les données de trafic. Lorsque la plateforme identifie des terminaux sur des zones autoroutière prédéfinies (autoroutes par exemple), les terminaux sont implicitement basculé en mode « VEHICULE ».

[0080] La vitesse de déplacement d'un Citoyen est déterminée par un équipement interne au terminal ou par calcul depuis la plateforme selon les points de géolocalisation, l'horodatage de ces points et la topologie urbaine du lieu.

[0081] Les données de trafic et les avaries ainsi récoltées sur les voies routières peuvent être utilisées par la Collectivité et/ou les services compétents pour remédier à des situations et pour informer les Citoyens.

[0082] COTE UTILISATEUR : APPLICATION SUR SITE WEB

[0083] L'application disponible sur le site web comprendra les fonctionnalités ci-dessus décrites pour l'application pour téléphone portable, et présentera de manière globale le procédé. La page d'accueil est donc globale (il n'y a pas à ce stade de différenciation des collectivités locales qui adhèrent au service, et le grand public).

[0084] Ce site web (plusieurs pages selon le contenu) devra informer le public sur le service, les collectivités qui y adhèrent, etc .. La première page pourra contenir par exemple :

• Un lien vers des pages descriptives : « Je suis un Citoyen »

• Un lien vers des pages descriptives : « Je suis une collectivité »

[0085] Ensuite des liens permettront d'afficher des pages spécifiques (en termes de présentation et de contenu informatif) vers chaque collectivité et les services associés. [0086] Les pages associées aux collectivités pourront être présentées selon un:

• Mode par défaut : Inscrire leur contenu de présentation dans un cadre déjà « formaté » du portail ALERT-PHONE avec une personnalisation en termes de charte graphique et de données présentées.

• Mode Optionnel : Créer un site spécifique de présentation si volonté de la collectivité.

[0087] Déclarer un Evénement

[0088] Il s'agit de la même fonctionnalité que celle détaillée dans l'application ALERT-PHONE-SMART. A la différence, que la déclaration se fait depuis un poste fixe ; les médias (photos, vidéos) seront donc « uploader » à partir d'une sélection de fichiers. Idem pour la géolocalisation, l'utilisateur (s'il le désire) aura la possibilité de géolocaliser l'Evénement en sélectionnant sur une carte l'emplacement adéquat.

[0089] Mes Alertes

[0090]Cette fonction regroupe l'ensemble des Alertes émises par les collectivités auxquelles l'utilisateur adhère. L'utilisateur peut accéder à l'ensemble des Alertes émises. A ce stade, une « collectivité » pourrait être de type national et donc diffuser les Alertes qui impactent le territoire national. Ou une collectivité qui diffuse une Alerte sur son territoire, pourrait aussi diffuser sur des territoires adjacents si le risque sort de son propre territoire initial. Dans ce cas, même si l'utilisateur n'a pas adhéré explicitement à la collectivité, il reçoit tout de même l'Alerte.

[0091] Mes adhésions aux collectivités

[0092]Cette fonction permet à l'utilisateur de sélectionner les collectivités adhérentes au Service, pour lesquelles il souhaite recevoir les Alertes ou émettre des Evénements. Le choix ne pourra se faire que parmi les collectivités qui adhérent au Service Alert-Phone. Dans le cas d'une adhésion dynamique depuis son Smartphone, la collectivité retrouvera donc la liste des adhésions.

[0093] Cartographie des Evénements

[0094] L'utilisateur visualise sur la carte ses propres Evénements. Il pourra donc y accéder par sélection directe sur la carte.

[0095] Dans des pages « Grands Public », figurera une synthèse globale des Evénements reportés. Il ne sera pas possible à partir de ces informations de « remonter » vers un Evénement unique contenant les informations personnelles du déclarant. [0096] C'est une présentation anonyme de la base des Evénements dans le but de montrer le dynamisme du service.

[0097JSITE WEB ESPACE GRAND PUBLIC

[0098]C'est le site Grand Public qui présente le service (aux futurs utilisateurs, mais aussi aux futures collectivités). A partir de ce site, on accède :

• Aux pages globales de présentation du Service Alert-Phone (« Je suis un Citoyen », « Je suis une collectivité »).

• Aux pages globales de présentation des Evénements.

• Aux pages de présentation des collectivités adhérentes au service.

[0099]Aux synthèses de la base des Evénements (synthèse globales, par collectivité, par type d'Evénements, etc.).

[00100] Le site doit mettre en valeur le côté dynamique et acquisition en temps réel du service (nombre d'Evénements déclarés par jour, par semaines ; Nombre d'Evénements traités par les collectivités, indice de satisfaction, etc.) et l'importance de la communauté adhérente (utilisateurs et collectivistes). Il propose pour cela des indicateurs dédiés au Grand Public et aux Opérateurs.

[00101] Formulaire d'adhésion du Citoyen utilisateur

[00102] Ce formulaire permet au Citoyen de s'inscrire au Service Alert-Phone. On traitera dans cette fonction : « Mot de passe oublié, redéfinir un nouveau mot de passe »

[00103] Formulaire d'adhésion d'une collectivité

[00104] Ce formulaire permet à une collectivité d'adhérer au Service Alert-Phone. Dans un premier temps, ce formulaire pourrait ne pas exister, mais permettrait à la collectivité de prendre contact avec l'Administrateur pour mettre au point la partie contractuelle. L'ajout d'une nouvelle collectivité et son paramétrage sera réalisé dans l'application ALERT-PHONE-ADMIN.

[00105] Formulaire de connexion du Citoyen utilisateur

[00106] Permet au Citoyen d'accéder aux fonctions du service, et à la gestion de ses Evénements : partie privative du Citoyen.

[00107] Cartographie des Evénements

[00108] Conformément aux figures 10 et 1 1 , on affiche sur une carte, la localisation des Evénements, avec une précision dépendante du nombre d'Evénements en fonction du niveau de zoom. [00109] On associe à cette représentation des filtres, l'affichage des Evénements en :

• Fonction de la période (jour-mois-année)

• Fonction du type d'Evénement

· Fonction de l'état (traité, non traité, en cours, etc.)

[00110] COTE COLLECTIVITES : SITE WEB

[00111] Les collectivités quant à elles accèdent au système selon l'invention via une application web permettant la configuration, la gestion, le traitement de l'information et des services associés.

[00112] Le site web du système selon l'invention, possède donc des pages « privées » accessibles uniquement aux Citoyens déclarés, ainsi qu'aux utilisateurs des collectivités et de deux types différents :

[00113] · Espace privé pour le Citoyen

[00114] · Espace privé pour les Opérateurs d'une collectivité : C'est dans ces espaces privés, que les fonctionnalités de gestion du service Alert-Phone seront positionnées.

[00115] L'application « collectivité » a deux buts principaux :

• Permettre à la collectivité de paramétrer son service

• Permettre à la collectivité de gérer les Evénements remontés par les Citoyens.

[00116] Il est important de noter qu'en réalité, chaque collectivité aura son propre espace privé, pour gérer les spécificités de Service qu'elle désire mettre en œuvre dans son périmètre (type d'Evénements pouvant être signalés par exemple : « accident de circulation », « dégât des eaux » mais pas « voirie » lorsque la municipalité considérée n'en est pas pourvue.

[00117] Le système selon l'invention propose par défaut une bibliothèque de type d'Evénements à la collectivité, et l'Opérateur (par simple paramétrage) sélectionnera parmi ces types d'Evénements, ceux dont il souhaite recueillir un signalement, et qui apparaîtront dans la liste disponible sur le téléphone mobile du Citoyen ou l'interface Citoyen du site web. La collectivité en charge de cet Evénement accède à toutes les informations de cet Evénement déclaré par l'utilisateur. L'Opérateur aura en outre la capacité d'enrichir cette bibliothèque avec ses propres types d'Alerte. Tous ces types d'Alertes seront donc proposés à la collectivité, et l'Opérateur pourra créer une Alerte (diffusion de l'Alerte vers le Citoyen) à partir de cette bibliothèque.

[00118] A travers l'application sur téléphone mobile et le site web dédié, le Citoyen sera notifié de la présence d'une Alerte émise conformément au diagramme illustré sur la figure 2.

[00119] Cette Alerte aura donc les propriétés suivantes : 1. Type de l'Alerte (nomenclature de la bibliothèque)

2. Libellé et description de l'Alerte (prise en compte du multilingues).

3. Période d'activation (date de début, date de fin). La date de fin est optionnelle, ce qui veut dire que l'Alerte est Active sans limite de temps. Dans ce cas l'Opérateur devra donc « manuellement » désactiver l'Alerte lorsque celle- ci sera terminée.

4. Territoires et/ou collectivités concernées (gestion du cas ou l'Alerte peut sortir du périmètre de la collectivité).

[00120] Dans un premier temps, la zone concernée par l'Alerte correspondra à la surface de la collectivité concernée. Puis l'Opérateur, s'il le souhaite pourra définir (digitaliser) lui-même une zone géographique plus précise qui correspondrait à la zone réelle de l'Alerte (la zone d'impact).

[00121] Une autre fonctionnalité « Gestion de l'escalade » lui permettra de diffuser cette Alerte sur des territoires adjacents à son propre territoire. Dans ce cas un workflow permettra à chaque Opérateur des territoires concernés de valider la diffusion de cette Alerte. On pourra également prévoir un lien vers un ou plusieurs fichiers, comme par exemple un fichier PDF, qui seront affichés par les capacités propre du Smartphone.

[00122] Lorsque l'Alerte n'est plus active : Date de fin dépassée ou l'Opérateur désactive l'Alerte ; celle-ci disparait automatiquement de la liste des « Alertes émises » présentée dans le Smartphone du Citoyen ou dans son interface sur le site web dédié.

[00123] GESTION

Il s'agit des fonctionnalités permettant à la collectivité de gérer le système Alert-Phone.

Il existe 3 grandes catégories de fonctions :

• Les fonctions d'administration des Evénements liés à la collectivité.

• Les fonctions associées aux Alertes (définition et diffusion).

• Les fonctions de restitution des informations, rapports, indicateurs.

•

Gestion du Périmètre géographique

Cette fonction permet à une collectivité de définir géographiquement le périmètre dans lequel :

Les Evénements crées par le Citoyen seront géolocalisés. Les Alertes générées par la collectivité seront diffusées. Par défaut, pour une collectivité de type communal, ce périmètre géographique correspondra au territoire de la commune.

Ce découpage en communes, départements, régions sera déjà présent dans le Service Alert-Phone. La collectivité pourra ainsi directement sélectionner la surface adéquate.

En option, des outils de digitalisation permettront à d'autres types de collectivités ou d'autorités de définir graphiquement leur propre périmètre géographique dans lequel leur Service Alert-Phone sera opérationnel.

Gérer les services (notion de portail par service)

Permet de déclarer les services internes (Equipement, Voirie, Travaux, etc.) de la collectivité qui entre-autre, auront la charge de prendre en compte les Evénements déclarés.

• Déclarer un service (présentation, rayon d'actions, etc.)

• Gérer les utilisateurs de ce service : utilisateurs, profils, droits.

Gérer les options

Différentes options pourront être activées ou non

Options de présentation : Charte graphique, logo, nom, etc. Options sur la gestion des points

• Options sur le niveau de détail ou de présentation des résultats aux Citoyens, aux Grand Public.

Etc.

GESTION DES EVENEMENTS Gérer la base des Evénements

A partir de la bibliothèque globale des Evénements (Bibliothèque définie par l'Administrateur global du Service), l'Opérateur sélectionne les types d'Evénements qu'il désire proposer aux Citoyens de sa collectivité.

Pour chaque type d'Evénement sélectionné, l'Opérateur définie les paramètres suivants :

• Paramétrage de la fonction de dé-doublonnage :

o Définition du périmètre géographique (en mètre)

o Définition de la période (en heure)

• Modification du libellé et de la description de l'Evénement • Affectation du service qui sera en charge de traiter l'Evénement (service et/ou Opérateur).

Gérer des Workflow

Définition de Workflow dans la gestion de la prise en compte d'un fait : définition des états et des acteurs associés pour chacun des états.

Gérer les Evénements créés

L'Opérateur acquittera les Evénements qui lui sont destinés et les traitera. Cette opération d'acquittement est importante car elle sera remontée auprès du Citoyen qui a déclaré l'Evénement.

Une prise en compte rapide, et une clôture rapide (Evénement traité ou sans suite) permettra de créer un sentiment de satisfaction pour l'utilisateur (si un utilisateur s'aperçoit qu'il n'y pas de prise en compte, il n'aura plus la volonté de déclarer des Evénements).

GESTION DES ALERTES Gérer des types d'Alerte

Outre la bibliothèque globale des Alertes définies par l'Administrateur du Service (outil ALERT-PHONE-ADMIN), l'Opérateur a la capacité de définir ses propres types d'Alerte pré formatée. Par exemple, pour un type spécifique d'Alerte, la liste des consignes seraient déjà définie.

Définir une Alerte (créer une Alerte)

A partir de la bibliothèque globale des Alertes (Bibliothèque définie par l'Administrateur global du Service et bibliothèque spécifique de la collectivité), l'Opérateur sélectionne l'Alerte qu'il désire envoyer aux Citoyens de sa collectivité.

Interopérabilité avec des systèmes externes

Le système d'Alertes de l'application permet l'interopérabilité avec des systèmes externes tels qu'un service d'état centralisé, ou un service privé (par exemple un service d'informations météorologiques sur l'ensemble d'un territoire, qui pourra fournir à une Autorité des informations météorologiques concernant son périmètre.

Une Alerte émise depuis une source externe, sera déclaré dans le système par l'intermédiaire de WebServices mis à disposition par la solution. Cette Alerte pourra donc ensuite être diffusée par notification auprès de tous les citoyens possédant l'application.

Pour cela, l'opérateur visualise dans l'application Backoffice les Alertes Externes, puis, il valide le cas échéant les Alertes qui devront être répercutées dans la solution selon l'invention par l'intermédiaire de la plateforme.

L'alerte sera automatiquement associée à une autorité, elle est donc émise pour le périmètre de l'autorité (dans notre exemple, cela correspond au contour de la commune).

Donc tout terminal qui se trouve ou entre dans ce périmètre sera automatiquement notifié de l'Alerte en cours.

Formulaire de déclaration d'une Alerte

Le formulaire de déclaration d'une Alerte permet de saisir ou modifier toutes les informations relatives à une Alerte.

1 . Choix du type de l'Alerte

2. Modifier le libellé et description de l'Alerte.

3. Choix d'une période d'activation (date de début, date de fin, gestion manuelle)

4. Territoires et/ou collectivités concernées (gestion du cas où l'Alerte peut sortir du périmètre de la collectivité)

5. Définition de consignes

6. Etc ..

TYPE DE LOCALISATION D'UNE ALERTE

L'opérateur pourra lui-même définir une zone spécifique pour l'alerte, qu'elle soit émise par l'Autorité dont il dépend, ou par un service externe.

Ces zones sont donc de différents types :

Il existe toujours le périmètre de l'autorité

Cela correspond à la fonctionnalité déjà disponible en V1 , pas de changement fonctionnel.

Une zone digitalisée sur la carte : rectangle, cercle, polygone.

L'opérateur peut donc définir des zones temporaires ou qui seront sauvegardées dans le système. Ces zones auront au moins un nom, ce qui permettra de la sélectionner lorsque l'opérateur créera l'Alerte. On pourra « ranger » ou classer ces noms de zones dans une arborescence fonctionnelle.

La sélection d'une entité graphique appartenant à une couche de la cartographie : District, quartier, etc.

Définition de zones d'alertes

Une fonction permettra de créer une zone d'alerte :

Nom, Description

Entité géographique associée :

o Entité graphique existante : district, quartier

o Entité graphique dessinée par l'opérateur

Le choix de l'entité géographique permettra de d'associer automatiquement la surface en m2 à cette zone d'alerte.

Gérer les Alertes

Présentation de formulaires permettant de :

• Visualiser l'historique des Alertes émises.

• Visualiser et gérer les Alertes en cours.

• Reconduire une Alerte.

• Arrêter une Alerte.

Affichage des zones d'alertes dans un tableau ; actions pour modifier, supprimer.

En fonctions de l'entité géographique, les actions seront différentes :

Entité graphique existante : district, quartier

o Suppression impossible.

o Modification des propriétés alphanumériques (nom).

Entité graphique dessinée par l'opérateur :

o Suppression : OK (si aucune alerte en cours)

o Modification des propriétés alphanumériques et/ou graphiques

: OK

RESTITUTION DE L'INFORMATION Les Citoyens adhérents

Accès à la liste des Citoyens qui adhèrent au Service Alert-Phone de la collectivité. Pour chaque Citoyen, on peut comptabiliser le nombre de d'Evénements (avec une répartition en fonction de l'état)

La cartographie des Evénements

On affiche sur une carte, la localisation des Evénements attachés à la collectivité.

On pourra filtrer selon :

• Période.

• Etat de l'Evénement (A traiter, traiter, etc.).

• Affectation au service en charge du traitement de l'Evénement (Voirie, Equipement, etc.).

• Autres selon réflexion.

La base des Evénements

Cette base permettra la création et l'affichage de rapports, d'indicateurs sur l'utilisation du Service Alert-Phone.

Ces rapports pourront rester confidentiels, c'est-à-dire que la collectivité ne les diffuse pas auprès de ses Citoyens.

Ces rapports permettront à un gestionnaire de vérifier le bon fonctionnement du Service à l'intérieur d'une collectivité :

• Taux de déclaration des Evénements

Taux de prise en compte, de résolution, etc.

D'autres rapport ou indicateurs pourront être diffusé par l'intermédiaire de l'espace public du site ALERT-PHONE-COLLECTIVITE auprès du Citoyen.

Tableau de bord et Statistiques

Des rapports mettant en évidence le taux de prise en compte et de résolution pourront être mis en place pour chaque service de la collectivité.

Génération d'un rapport hebdomadaire, mensuel, annuel sur la performance du Service Alert-Phone de la collectivité.