FR3090930A1 - Procédé et structure de signalement d’incident - Google Patents

Abstract

L’invention concerne un procédé de signalement d’incident mis en œuvre par des moyens informatiques. Le procédé comprend :- générer, au niveau d’une structure de traitement (9), une information de signalement d’un incident (INF) en fonction de données de signalement d’incident (SIGN) relatives à l’incident et générées au niveau d’un ou plusieurs terminaux utilisateur (7) et comprenant au moins des données de géolocalisation de l’incident,- sélectionner un ou plusieurs destinataires (3) des données de signalement d’incident reçues en fonction desdites données de signalement d’incident, ledit ou lesdits destinataires étant sélectionnés au sein d’une base de données de destinataires (29) de la structure de traitement, et- transmettre l’information de signalement d’incident audit ou auxdits destinataires sélectionnés.

Description

Titre de l'invention : Procédé et structure de signalement d’incident

[0001] Le domaine de l’invention se rapporte aux procédés et structures de traitement de données de signalement d’incident dans le but d’assurer l’acheminement les informations relatives à l’incident signalé aux personnes compétentes et en mesure d’assurer la résolution de l’incident signalé.

[0002] Aujourd’hui, la multiplication des moyens de communication et la démocratisation des smartphones permettent dans chaque ville la constitution d’un vaste réseau auquel participent les citoyens. La prise de conscience du dynamisme et de l’étendue de ce réseau a conduit au développement de « villes intelligentes » (connu aussi sous le terme anglophone Smart City). Ce concept récent désigne les villes utilisant les technologies de l’information et de la communication pour améliorer la qualité des services urbains ou réduire ses coûts.

[0003] La ville intelligente contribue plus généralement à la mise en œuvre du « Citizen Sourcing » qui s’appuie sur la contribution active des citoyens pour développer de nouveaux services dans lesquels le rôle des citoyens est prépondérant. Parmi les nombreuses applications, le « Citizen Sourcing » permet par exemple de collecter les idées et les suggestions des citoyens ou encore la surveillance accrue des réseaux sociaux pour trouver des solutions collectives à des problèmes occasionnés par des catastrophes naturelles.

[0004] Le signalement et l’enregistrement des incidents de façon collaborative présentent donc un enjeu majeur pour les villes intelligentes. Par ailleurs, la résolution d’un incident nécessite que les données relatives à l’incident en question collectées par des citoyens soient acheminées à un destinataire apte à résoudre ce type d’incident. En effet, à l’échelle d’une ville par exemple, les différentes administrations et les différents services ont souvent des domaines d’intervention clairement délimités et sont donc assignés à la résolution de certaines tâches bien spécifiques. La collecte des données ne peut donc pas être efficace sans un traitement des données destiné à établir la nature exacte d’un incident et, donc, le destinataire approprié des données relatives à l’incident signalé.

[0005] La présente invention vient améliorer la situation.

[0006] A cet effet, il est proposé un procédé de traitement de données de signalement d’incident mis en œuvre par des moyens informatiques. Le procédé visé comprend : - générer, au niveau d’une structure de traitement, une information de signalement d’un incident en fonction de données de signalement d’incident relatives à incident, les données de signalement d’incident étant générées au niveau d’un ou plusieurs terminaux utilisateur et comprenant au moins des données de géolocalisation de l’incident en question,

- sélectionner, en fonction de l’information de signalement d’incident, un ou plusieurs destinataires de l’information de signalement d’incident au sein d’une base de données de destinataires de la structure de traitement, et

- transmettre l’information de signalement d’incident au ou aux destinataires sélectionnés.

[0007] Selon un aspect de l’invention, une partie au moins des données de signalement d’incident sont générées via une application exécutée sur le terminal utilisateur.

[0008] Selon un autre aspect de l’invention, les données de signalement d’incident comprennent en outre des données saisies par un utilisateur du terminal utilisateur via l’application.

[0009] Selon un autre aspect de l’invention, les données de signalement d’incident comprennent des données relatives à un contenu multimédia généré à l’aide du terminal utilisateur.

[0010] Avantageusement, selon un autre aspect de l’invention, le contenu multimédia est analysé au niveau de la structure de traitement à l’aide d’un logiciel de reconnaissance d’objets, des données générées par ledit logiciel de reconnaissance d’objets étant adjointes aux données de signalement d’incident.

[0011] Selon un autre aspect de l’invention, les données de géolocalisation de l’incident sont déterminées automatiquement et correspondent à une position courante du terminal utilisateur.

[0012] Selon un autre aspect de l’invention, la structure de traitement comprend une base de données d’incidents au sein de laquelle sont stockés le ou les incidents signalés ainsi que les données de signalement d’incident respectivement associées, les données de signalement d’incident reçues étant analysées pour déterminer, par comparaison avec les données de signalement d’incident précédemment stockées dans la base de données d’incidents, si les données de signalement d’incident sont relatives à un incident déjà stocké dans la base de données d’incidents de sorte que :

- si les données de signalement d’incident reçues sont relatives à un incident stocké dans la base de données d’incidents, les données de signalement d’incident en question sont associées au sein de la base de données d’incidents à l’incident correspondant ;

- sinon, un nouvel incident associé aux données de signalement d’incident reçues est stocké dans la base de données d’incidents.

[0013] Selon un autre aspect de l’invention, dans le cas où une partie au moins des données de signalement d’incident sont générées via une application exécutée sur le terminal utilisateur, un utilisateur accède à l’application en se connectant à un compte utilisateur qui lui est propre, et les données de signalement d’incident comprennent un identifiant de compte utilisateur émetteur des données de signalement d’incident, cet identifiant étant associé au sein d’une base de données d’utilisateurs de la structure de traitement avec un indice de confiance, et dans lequel un coefficient de fiabilité est calculé par la structure de traitement pour chaque incident signalé en fonction de l’indice de confiance du ou des comptes utilisateur émetteurs des données de signalement d’incident relative à l’incident, le coefficient de fiabilité d’un incident étant mis à jour à chaque réception de données de signalement d’incident relative à l’incident signalé.

[0014] Selon un autre aspect de l’invention, la génération de l’information de signalement d’incident et la sélection du ou des destinataires de l’information de signalement d’incident relative à un incident sont mises en œuvre si et seulement si le coefficient de fiabilité de l’incident est supérieur ou égal à un seuil prédéterminé.

[0015] Selon un autre aspect de l’invention, un incident et les données de signalement d’incident associées à cet incident sont supprimés de la base de données d’incidents si le coefficient de fiabilité dudit incident est inférieur au seuil prédéterminé à l’issue d’une période de temps prédéterminée.

[0016] Selon un autre aspect de l’invention, un coefficient de complétude est calculé par la structure de traitement pour chaque incident signalé en fonction d’un critère de précision concernant les données de signalement relatives audit incident, le coefficient de complétude étant une variable binaire prenant la valeur 0 lorsque le critère de précision n’est pas satisfait et prenant la valeur 1 lorsque le critère de précision est satisfait, la génération de l’information de signalement d’incident et la sélection du ou des destinataires de ladite information de signalement d’incident relative à un incident sont mises en œuvre si et seulement si le coefficient de complétude dudit incident est égal à 1.

[0017] Selon un autre aspect de l’invention, l’information de signalement d’incident est mise à disposition du ou des destinataires sélectionnés via un portail web au contenu personnalisé et adapté à chaque destinataire.

[0018] Selon un autre aspect de l’invention, l’information de signalement comprend des données relatives à un type de l’incident sélectionné dans une liste préétablie de types d’incident, chaque destinataire stocké dans la base de données de destinataires étant associé à un ou plusieurs types d’incident de la liste préétablie de types d’incident.

[0019] L’invention concerne en outre un programme informatique comportant des instructions pour la mise en œuvre du procédé décrit précédemment, lorsque les instructions sont mises en œuvre par au moins un processeur.

[0020] Enfin, l’invention vise une structure de traitement de données de signalement d’incident agencée pour générer une information de signalement d’un incident en fonction de données de signalement d’incident relatives à cet incident, les données de signalement d’incident étant générées par un ou plusieurs terminaux utilisateur et comprenant au moins des données de géolocalisation de l’incident. Par ailleurs, la structure de traitement est agencée en outre pour sélectionner, en fonction de l’information de signalement d’incident, un ou plusieurs destinataires de l’information de signalement d’incident, la structure de traitement comprenant une base de données de destinataires au sein de laquelle le ou les destinataires sont sélectionnés. Enfin, la structure de traitement est agencée en outre pour transmettre l’information de signalement d’incident au ou aux destinataires sélectionnés.

[0021] D’autres caractéristiques, détails et avantages de l’invention apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels :

[0022] [fig.l] illustre un système de traitement de données de signalement d’incident selon l’invention; et

[0023] [fig.2] illustre un procédé de traitement de données de signalement d’incident selon l’invention.

[0024] La [Fig. 1] illustre un système de traitement de données de signalement d’incident, ci-après système 1 et un système d’information 3. Dans l’exemple illustré, un portail web 5 permet d’accéder à des informations relatives à un ou plusieurs incidents signalés.

[0025] Le système 1 est agencé pour générer et traiter des données de signalement d’incident. Le système 1 est agencé en outre pour assurer l’acheminement d’informations relatives aux incidents signalés à un ou plusieurs destinataires, par exemple le système d’information 3, de manière à faciliter la résolution des incidents signalés en s’assurant que les informations relatives à un incident donné sont transmises aux destinataires appropriés.

[0026] Le système 1 comprend un ou plusieurs terminaux utilisateur, ici un terminal utilisateur 7, et une structure de traitement de données de signalement d’incident, ci-après structure de traitement 9.

[0027] Le terminal utilisateur 7 est adapté pour signaler un incident à la structure de traitement 9. Plus exactement, le terminal utilisateur 7 permet à un utilisateur en sa possession de signaler un incident en générant et en transmettant des données de signalement de l’incident à la structure de traitement 9. Les données de signalement d’incident comprennent au moins des données de géolocalisation de l’incident.

[0028] Dans un ou plusieurs modes de réalisation, le terminal utilisateur 7 est adapté pour déterminer automatiquement les données de géolocalisation de l’incident. La géolocalisation de l’incident correspond alors à une position courante du terminal utilisateur 7. La position courante du terminal utilisateur 7 est par exemple déterminée automatiquement par un serveur connecté à un réseau auquel le terminal utilisateur 7 est connecté. Alternativement, le terminal utilisateur 7 comprend un module de géoloca5 lisation, par exemple de type GPS (acronyme anglophone pour « Global Positioning System ») ou de type Galileo.

[0029] De manière générale, un incident est un accident de voiture, un incendie, une dégradation de la chaussée ou tout autre évènement localisé et pouvant faire l’objet d’un signalement. Un incident peut également concerner un dysfonctionnement, par exemple des retards, d’un prestataire de service de transport public ou privé.

[0030] Comme illustré en [Fig. 1], le terminal utilisateur 7 comprend une interface Homme/ Machine 11, une unité de capture d’images 13, une unité de traitement 15 et un module de communication 17.

[0031] L’interface Homme/Machine 11 est adaptée pour permettre à l’utilisateur en possession du terminal utilisateur 7 de générer des données relatives à l’incident qu’il souhaite signaler à la structure de traitement 9.

[0032] Par exemple, une partie au moins des données de signalement d’incident sont générées via une application exécutée sur le terminal utilisateur 7. L’utilisateur peut accéder à cette application en se connectant à un compte utilisateur. On comprend ici que dans un ou plusieurs modes de réalisation, un utilisateur souhaitant participer au signalement d’incidents peut le faire en exécutant une application client sur le terminal utilisateur 7 (par exemple application native ou web exécutée sur un smartphone ou une tablette, ou web-application exécutée par le biais d’un navigateur Web sur un ordinateur personnel (de type PC, pour « Personal Computer »)), et en utilisant un compte utilisateur qui lui est propre pour se connecter à une application serveur. Ce compte utilisateur peut se présenter par exemple sous la forme d’un ensemble de données comprenant des données d’identification ainsi que, selon les cas, des données d’authentification de l’utilisateur.

[0033] En fonction du mode de réalisation, une application client exécutée sur un terminal tel que le terminal utilisateur 7 peut nécessiter une inscription de l’utilisateur et le renseignement de données telles qu’un numéro de mobile, un mot de passe ou des données personnelles telles que son adresse de domicile.

[0034] Chaque compte utilisateur est associé à un identifiant qui lui est propre. Un tel identifiant permet, comme expliqué dans la suite, de déterminer à partir de quel compte utilisateur ont été générées les données de signalement. Une autre manière de voir les choses est de considérer que, avantageusement, l’identifiant du compte utilisateur à partir duquel l’utilisateur a signalé un incident et renseigné des informations sur cet incident fait partie des données de signalement d’incident et générées.

[0035] A l’aide de cette application, l’utilisateur peut, par exemple, saisir ou renseignement une partie au moins des données de signalement d’incident. Autrement dit, l’interface Homme/Machine 11 et l’application exécutée sur le terminal utilisateur 7 permettent à l’utilisateur en possession du terminal utilisateur 7 de générer lui-même une partie au moins des données de signalement d’incident.

[0036] Par exemple, l’interface Homme/Machine 11 est alors adaptée pour permettre à l’utilisateur de spécifier un niveau d’urgence de l’incident. Par exemple, l’interface Homme/Machine 11 permet de sélectionner le niveau d’urgence de l’incident sur une échelle préétablie. Le niveau d’urgence est par exemple caractérisé par un chiffre ou une lettre.

[0037] Avantageusement, l’interface Homme/Machine 11 est adaptée pour permettre à l’utilisateur de spécifier un type de l’incident. Par exemple, l’interface Homme/ Machine 11 permet de sélectionner le type de l’incident parmi une liste préétablie d’incidents potentiels. Cette fonctionnalité peut se présenter sous la forme d’un menu déroulant accessible à l’utilisateur via l’interface Homme/Machine 11. Alternativement, l’interface Homme/Machine 11 permet de spécifier un type d’incident ne faisant pas partie de la liste préétablie via une option de texte libre accessible à l’utilisateur.

[0038] Ainsi, le niveau d’urgence de l’incident ou encore le type de l’incident sont des exemples possibles de données inclues dans les données de signalement d’incident et générées par le terminal utilisateur 7. Ces données peuvent être en particulier saisies et renseignées par l’utilisateur en possession du terminal utilisateur 7 en exécutant une application.

[0039] Par ailleurs, comme expliqué précédemment, les données de signalement comprennent des données de géolocalisation de l’incident déterminées automatiquement par le terminal utilisateur 7 et correspondant à une position courante du terminal utilisateur 7. Néanmoins, alternativement, le terminal utilisateur 7 est adapté pour permettre à l’utilisateur de renseigner, par exemple via l’application exécutée sur le terminal utilisateur 7, la géolocalisation de l’incident.

[0040] L’unité de capture d’images 13 est adaptée pour générer un contenu multimédia tel qu’un contenu vidéo ou une photographie. Dans un ou plusieurs modes de réalisation, les données de signalement d’incident comprennent des données relatives à un contenu multimédia généré à l’aide du terminal utilisateur 7, et plus exactement donc à l’aide de l’unité de capture d’images 13. Par exemple, une fonctionnalité de l’application exécutée sur le terminal utilisateur 7 permet à l’utilisateur d’adjoindre aux données saisies un contenu multimédia, donc un contenu vidéo et/ou une ou plusieurs photographies.

[0041] L’unité de traitement 15 est adaptée pour générer des données de signalement d’incident SIGN.

[0042] Comme expliqué précédemment, les données de signalement d’incident SIGN comprennent au moins des données de géolocalisation de l’incident.

[0043] Par ailleurs, en référence aux modes de réalisation évoqués précédemment, les données de signalement d’incident SIGN peuvent comprendre en outre des données relatives au niveau d’urgence de l’incident et/ou des données relatives au type de l’incident et/ou un contenu multimédia. De manière générale, les données de signalement d’incident SIGN peuvent comprendre tout type de données concernant la nature de l’incident et pouvant être utile à la résolution de ce dernier.

[0044] Avantageusement, les données de signalement d’incident SIGN comprennent en outre un identifiant du compte utilisateur à partir duquel l’utilisateur du terminal utilisateur 7 a signalé, via l’application exécutée sur le terminal utilisateur 7, l’incident.

[0045] Comme illustré en [Fig. 1], l’unité de traitement 13 comprend une mémoire 19 et un processeur 21.

[0046] La mémoire 19 est configurée pour stocker des instructions d’un programme informatique dont l’exécution par le processeur 21 se traduit par le fonctionnement de l’unité de traitement 15 pour la mise en œuvre du procédé de traitement de données de signalement d’incident proposé, et plus spécifiquement la génération des données de signalement d’incident SIGN.

[0047] Avantageusement, la mémoire 19 est en outre configurée pour stocker une adresse de la structure de traitement 9 pour l’acheminement des données de signalement d’incident SIGN à destination de la structure de traitement 9 correspondante. Par ailleurs, la mémoire 19 peut en outre être configurée pour stocker un identifiant du compte utilisateur auquel se connecte habituellement l’utilisateur du terminal utilisateur 7. Bien entendu, l’identifiant du compte utilisateur peut aussi être extrait de celui-ci, ponctuellement, lorsqu’un utilisateur se connecte à son compte utilisateur via le terminal utilisateur 7. Ainsi, dans le cas où un nouvel utilisateur utilise le terminal utilisateur 7 pour se connecter à un compte utilisateur différent du compte utilisateur auquel se connecte l’utilisateur régulier du terminal utilisateur 7, l’identifiant de ce nouveau compte utilisateur peut être extrait, éventuellement stocké dans la mémoire 19, et intégré aux données de signalement d’incident SIGN.

[0048] Le module de communication 17 est adapté pour émettre les données de signalement d’incident SIGN à destination de la structure de traitement 9. Les données de signalement d’incident SIGN sont par exemple émises à destination de la structure de traitement 9 via un réseau (non représenté sur la [Fig. 1]). Un tel réseau est par exemple un réseau de type MAN (acronyme anglophone pour « Metropolitan Area Network »).

[0049] L'homme du métier peut se rendre compte qu'il existe de nombreux types différents de réseaux de communication de données, par exemple des réseaux de radiocommunication, cellulaires ou non cellulaires, et qu’en fonction du mode de réalisation, le module de communication 17 pourra intégrer un ou plusieurs modules de commu nication, par exemple de communication radiofréquence et être configuré pour l’émission et la réception de signaux radiofréquences, selon une ou plusieurs technologies, telles que TDMA, FDMA, OFDMA, CDMA, ou un ou plusieurs standards de radiocommunication, tels que GSM, EDGE, CDMA, UMTS, HSPA, LTE, LTE-A, WiFi (IEEE 802.11) et WiMAX (IEEE 802.16), ou leurs variantes ou évolutions, actuellement connus ou développés ultérieurement.

[0050] La structure de traitement 9 est agencée pour générer une information de signalement d’un incident en fonction des données de signalement d’incident SIGN relatives à l’incident en question. Par ailleurs, la structure de traitement 9 est agencée en outre pour sélectionner, en fonction de l’information de signalement d’incident, un ou plusieurs destinataires de l’information de signalement d’incident. En d’autres termes, la structure de traitement 9 est agencée pour analyser les données de signalement d’incident SIGN reçues en provenance du ou des terminaux utilisateur, tels que le terminal utilisateur 7, et pour appliquer un traitement aux données de signalement d’incident SIGN en vue d’acheminer le signalement de l’incident aux destinataires appropriés, sous la forme de l’information de signalement, afin de faciliter la résolution de l’incident.

[0051] Comme illustré en [Fig. 1], la structure de traitement 9 comprend un module de communication 23, une base de données d’incidents 25, une base de données d’utilisateurs 27, une base de données de destinataires 29 et une unité de traitement 31.

[0052] Le module de communication 23 est adapté pour recevoir des données de signalement d’incident SIGN émises par le terminal utilisateur 7, et plus précisément par le module de communication 17 du terminal utilisateur 7. Avantageusement, le module de communication 23 est adapté pour recevoir des données de signalement d’incident SIGN émises par plusieurs terminaux utilisateur tels que le terminal utilisateur 7.

[0053] Le module de communication 23 est en outre adapté pour communiquer avec plusieurs destinataires. Le module de communication 23 communique par exemple avec le système d’information 3 via un réseau (non représenté sur la figure). En particulier, le module de communication 23 est adapté pour émettre l’information de signalement d’incident INF générée par la structure de traitement de données 9 à destination d’un ou plusieurs destinataires. Un tel réseau est par exemple un réseau de type MAN.

[0054] Par ailleurs, comme expliqué dans la suite de la description, le module de communication 23 peut être agencé en outre pour transmettre l’information de signalement d’incident INF à un ou plusieurs destinataires par l’intermédiaire du portail web 5.

[0055] L'homme du métier peut se rendre compte qu'il existe de nombreux types différents de réseaux de communication de données, par exemple des réseaux de radiocommunication, cellulaires ou non cellulaires, et qu’en fonction du mode de réalisation, le module de communication 23 pourra intégrer un ou plusieurs modules de communication, par exemple de communication radiofréquence et être configuré pour l’émission et la réception de signaux radiofréquences, selon une ou plusieurs technologies, telles que TDMA, FDMA, OFDMA, CDMA, ou un ou plusieurs standards de radiocommunication, tels que GSM, EDGE, CDMA, UMTS, HSPA, LTE, LTE-A, WiFi (IEEE 802.11) et WiMAX (IEEE 802.16), ou leurs variantes ou évolutions, actuellement connus ou développés ultérieurement.

[0056] La base de données d’incidents 25 est adaptée pour stocker le ou les incidents signalés ainsi que les données de signalement d’incident SIGN associées aux incidents signalés et stockés. On comprend ici que la base de données d’incidents 25 est configurée de sorte que les données de signalement d’incidents SIGN reçues en provenance de terminaux utilisateurs tels que le terminal utilisateur 7 sont regroupées par incident de sorte que chaque incident signalé est répertorié dans la base de données d’incidents 25 en association avec les données de signalement d’incidents SIGN qui lui sont relatives.

[0057] On comprend que la base de données d’incidents 25 est configurée pour être mise à jour en fonction des données de signalement d’incident SIGN reçues. Par ailleurs, et comme développé dans la suite de la description, un incident et les données de signalement d’incident SIGN qui lui sont associées peuvent être supprimés de la base de données d’incidents 25 sous certaines conditions, notamment lorsque les données de signalement d’incident SIGN reçues et relatives à un incident ne sont pas suffisamment fiables, la fiabilité étant estimé par la structure de traitement 9 sur la base d’un indice de confiance de chaque compte utilisateur signalant l’incident. On comprend que, dans ce mode de réalisation, chaque incident répertorié dans la base de données d’incidents 25 est associé à un coefficient de fiabilité susceptible d’être mis à jour.

[0058] Par ailleurs, avantageusement, un incident et les données de signalement d’incident SIGN qui lui sont associées peuvent être supprimés de la base de données d’incidents 25 lorsque l’incident est résolu.

[0059] Par ailleurs, dans un mode de réalisation, un incident signalé peut être associée à un coefficient de complétude caractérisant la suffisance ou l’insuffisance des informations remontées concernant l’incident signalé en question. En d’autres termes, un tel coefficient de complétude permet de caractériser le fait que les informations obtenues concernant un incident signalé sont suffisantes ou non pour résoudre cet incident.

[0060] Le coefficient de complétude est calculé par la structure de traitement pour chaque incident signalé en fonction d’un critère de précision concernant les données de signalement relatives à cet incident. Par exemple, le coefficient de complétude est une variable binaire prenant la valeur 0 lorsque le critère de précision n’est pas satisfait et prenant la valeur 1 lorsque le critère de précision est satisfait.

[0061] La base de données d’utilisateurs 27 est adaptée pour stocker l’identifiant d’un ou plusieurs comptes utilisateur tel que le compte utilisateur à partir duquel l’utilisateur du terminal utilisateur 7 a signalé un incident. Avantageusement, la base de données d’utilisateurs 27 est adaptée en outre pour stocker, en association avec chacun des identifiants stockés, un indice de confiance. On comprend donc que, au sein de la base de données d’utilisateurs 27, chaque identifiant d’un compte utilisateur est associé à un indice de confiance.

[0062] La base de données de destinataires 29 est adaptée pour stocker un ou plusieurs destinataires. On comprend ici que la base de données de destinataires 29 comprend un ou plusieurs identifiants, chaque identifiant étant associé à un destinataire potentiel d’une information de signalement d’incident INE générée par la structure de traitement 9.

[0063] Par ailleurs, la base de données de destinataires 29 est adaptée en outre pour stocker, en association avec chaque destinataire stocké dans la base de données de destinataires 29, une adresse du destinataire considéré. Cette adresse permet par la suite au module de communication 23 d’acheminer l’information de signalement d’incident INF générée aux destinataires sélectionnés.

[0064] Dans un ou plusieurs modes de réalisation, la base de données de destinataires 29 est adaptée pour stocker, en association avec chaque destinataire stocké, un ou plusieurs types d’incident. Typiquement, les différents types d’incident associés avec les destinataires au sein de la base de données de destinataires 29 font partie de la liste préétablie de types d’incident proposée à un utilisateur souhaitant signaler un incident à l’aide de son terminal utilisateur.

[0065] Avantageusement, chaque destinataire est associé en outre, au sein de la base de données de destinataires 29, avec une zone géographique. On comprend qu’une telle zone géographique correspond à une zone d’intervention possible du destinataire.

[0066] L’unité de traitement 31 est agencée pour générer une information de signalement d’incident INF en fonction des données de signalement d’incident SIGN relatives à l’incident en question.

[0067] L’information de signalement d’incident INF comprend des données permettant aux destinataires d’avoir à leur disposition les éléments nécessaires à la résolution de l’incident signalé. Par exemple, l’information de signalement d’incident INF comprend une géolocalisation de l’incident. Toujours à titre d’exemple, l’information de signalement d’incident INF peut comprendre en outre le type de l’incident signalé sélectionné dans la liste préétablie de types d’incident.

[0068] Par ailleurs, comme expliqué précédemment, les données de signalement d’incident SIGN peuvent comprendre en outre un contenu multimédia généré par le terminal utilisateur 7 à l’aide de l’unité de capture d’images 13. L’unité de traitement 31 est alors agencée en outre pour analyser, à l’aide d’un logiciel de reconnaissance d’objets, le contenu multimédia émis. L’unité de traitement 31 adjoint alors les données générées par le logiciel de reconnaissance d’objets aux données de signalement d’incident SIGN.

[0069] L’unité de traitement 31 est agencée en outre pour sélectionner, en fonction de l’information de signalement d’incident INL générée, un ou plusieurs destinataires de l’information de signalement d’incident INL au sein de la base de données de destinataires 29 de la structure de traitement 9.

[0070] La sélection des destinataires de l’information de signalement d’incident INL dépend du type de l’incident signalé. Comme expliqué précédemment, chaque destinataire stocké dans la base de données de destinataires 29 est associé à un ou plusieurs types d’incidents. Les types d’incident auquel est associé un destinataire correspond aux types d’incident qu’il est apte à résoudre et qui relèvent de son domaine d’intervention. Par ailleurs, la sélection des destinataires peut dépendre en outre de la géolocalisation de l’incident signalé.

[0071] L’unité de traitement 31 comprend une mémoire 33 et un processeur 35.

[0072] La mémoire 33 est configurée pour stocker des instructions d’un programme informatique dont l’exécution par le processeur 35 se traduit par le fonctionnement de l’unité de traitement 31 pour la mise en œuvre du procédé de traitement de données de signalement d’incident proposé, et plus spécifiquement la génération de l’information de signalement d’incident INL.

[0073] Dans un ou plusieurs modes de réalisation, la mémoire 33 est configurée en outre pour stocker la liste préétablie de types d’incident.

[0074] Le système d’information 3 est agencé pour recevoir l’information de signalement d’incident INL générée et émise par la structure de traitement 9. Typiquement, dans le contexte de la présente invention, le système d’information 3 désigne des ressources informatiques de collecte d’informations, ici l’information de signalement d’incident INL, d’une administration ou d’un prestataire de services, que ce prestataire soit un organisme public ou privé. On comprend ici que l’architecture illustrée en [Fig. 1] permet à cette administration ou à ce prestataire de services de prendre connaissance d’un incident signalé par un ou plusieurs utilisateurs à l’aide de leurs terminaux utilisateur et traité puis acheminé par la structure de traitement 9.

[0075] Par exemple, le système d’information 3 est celui d’un prestataire de service de transport et l’information de signalement d’incident INL permet de signaler un retard et de fournir les éléments nécessaires à la prise en charge et à la résolution de ce retard. Toujours à titre d’exemple, le système d’information 3 est celui d’une caserne de pompiers et l’information de signalement INL permet de signaler un incendie et de fournir les éléments nécessaires à la prise en charge de cet incendie.

[0076] Par ailleurs, dans un ou plusieurs modes de réalisation, l’information de signalement d’incident INF peut également être mise à disposition du ou des destinataires sélectionnés par la structure de traitement 9 via le portail web 5. Le portail web 5 présente un contenu personnalisé et adapté à chaque destinataire.

[0077] On comprend ici que chaque système d’information tel que le système d’information 3 peut accéder à l’information de signalement d’incident en accédant au portail web 5. Par exemple, l’administration ou le prestataire de services auquel est rattaché le système d’information 3 peut accéder au portail web 5 en se connectant via un compte utilisateur. L’accession à ce compte utilisateur peut impliquer l’utilisation d’un identifiant, propre au système d’information 3, et d’un mot de passe. Le portail web 5 est alors personnalisé en ce que les incidents signalés peuvent être différents d’un système d’information à un autre.

[0078] Un procédé de traitement de données de signalement d’incident SIG va maintenant être décrit en référence à la [Fig. 2],

[0079] Dans le contexte de l’invention, un incident se produit par exemple dans une ville. Cet incident peut être un incendie, un accident de voiture, une dégradation de la chaussée ou tout autre type d’incident. Les utilisateurs témoins de cet incident souhaitent que cet incident soit résolu au plus tôt et disposent chacun d’un terminal utilisateur tel que le terminal utilisateur 7.

[0080] Lors d’une étape SI, le terminal utilisateur 7 génère des données de signalement d’incident relatives à l’incident constaté. Par exemple, l’utilisateur en possession du terminal utilisateur 7 exécute une application, par exemple une application native ou une application web, lui permettant de saisir et de renseigner des données relatives à l’incident.

[0081] A l’aide de cette application, l’utilisateur spécifie par exemple le niveau d’urgence de l’incident ainsi que le type de l’incident constaté. Comme expliqué précédemment, l’utilisateur peut sélectionner le type de l’incident à l’aide d’un menu déroulant lui présentant une liste préétablie d’incidents potentiels ou utiliser une option de texte libre pour décrire l’incident qu’il souhaite signaler.

[0082] Toujours au cours de cette étape, l’utilisateur peut utiliser l’unité de capture d’image 13 du terminal utilisateur 7 pour générer un contenu multimédia relatif à l’incident constaté. Ce contenu multimédia correspond par exemple à un contenu vidéo ou à des photographies ou à une combinaison des deux. Le contenu multimédia ainsi obtenu fait alors partie des données de signalement d’incident SIGN.

[0083] Par ailleurs, comme expliqué précédemment, l’utilisateur du terminal utilisateur 7 signale l’incident par exemple en exécutant une application dédiée au signalement d’incident et en se connectant à un compte utilisateur qui lui est propre. Dans un tel cas, donc, les données de signalement d’incident SIGN peuvent comprendre en outre un identifiant du compte utilisateur à partir duquel l’utilisateur du terminal utilisateur 7 a signalé l’incident.

[0084] Lors d’une étape S2, le terminal utilisateur 7 génère automatiquement des données de géolocalisation de l’incident. Ces données de géolocalisation correspondent à une position courante du terminal utilisateur 7. Comme expliqué précédemment, la position courante du terminal utilisateur 7 est par exemple déterminée par un serveur connecté à un réseau auquel le terminal utilisateur 7 est connecté ou par un module de géolocalisation compris dans le terminal utilisateur 7.

[0085] Alternativement, la géolocalisation de l’incident peut être renseignée par l’utilisateur lui-même à l’aide de l’application exécutée sur le terminal utilisateur 7.

[0086] Ces données de géolocalisation de l’incident sont intégrées aux données de signalement d’incident SIGN.

[0087] Lors d’une étape S3, le module de communication 17 du terminal utilisateur 7 émet les données de signalement d’incident SIGN à destination de la structure de traitement 9. Les données de signalement d’incident SIGN sont émises à destination de la structure de traitement 9 à l’aide de l’adresse de la structure de traitement 9 stockée dans la mémoire 19 de l’unité de traitement 15 du terminal utilisateur 7. Les données de signalement d’incident SIGN sont par exemple émises à destination de la structure de traitement 9 via un réseau de type MAN.

[0088] Lors d’une étape S4, dans le cas où les données de signalement d’incident SIGN comprennent un contenu multimédia, l’unité de traitement 31 de la structure de traitement 9 analyse le contenu multimédia à l’aide d’un logiciel de reconnaissance d’objets. L’utilisation d’un logiciel de reconnaissance d’objets permet un marquage (plus connu sous le terme anglophone « tagging ») des différents objets ou éléments présents sur les images du contenu multimédia, qu’il s’agisse d’un contenu vidéo ou de photographies. Le marquage permet ainsi de déterminer automatiquement des zones d’intérêt dans une image et, par comparaison avec une banque d’objet, stockée par exemple dans la mémoire 33, de générer des données supplémentaires relatives à l’incident signalé. De telles données permettent par exemple, d’augmenter la précision de la géolocalisation de l’incident, d’estimer l’ampleur de l’incident, son niveau d’urgence ou toute autre information utile pour déterminer le type de l’incident et pour sa résolution.

[0089] Lors de cette étape, les données générées par le logiciel de reconnaissance d’objets sont adjointes aux données de signalement d’incident SIGN, ces dernières se trouvant ainsi enrichies.

[0090] Lors d’une étape S5, la structure de traitement 9 analyse les données de signalement d’incident SIGN reçues, et potentiellement enrichies lors de l’étape S4 à l’aide du logiciel de reconnaissance d’objets,, pour déterminer, par comparaison avec les données de signalement d’incident précédemment stockées dans la base de données d’incidents 25 si les données de signalement d’incident SIGN reçues sont relatives à un incident déjà stocké dans la base de données d’incidents 25.

[0091] Cette comparaison peut être mise en œuvre de plusieurs manières. Tout d’abord, la structure de traitement 9, et plus particulièrement l’unité de traitement 31, peut comparer les données de géolocalisation comprises dans les données de signalement d’incident SIGN reçues avec les données de géolocalisation comprises dans les données de signalement d’incident déjà stocké. Ainsi, il est possible d’écarter les incidents dont les données de géolocalisation ne coïncident pas avec celles des données de signalement d’incident SIGN analysées.

[0092] Par ailleurs, une fois déterminés les incidents déjà stockés compatibles géographiquement avec les nouvelles données de signalement d’incident SIGN reçues, l’unité de traitement 31 peut comparer le type de l’incident avec le type de chaque d’incident déjà stockés. La comparaison peut en outre s’appuyer sur les données générées par le logiciel de reconnaissance d’objets en cherchant une corrélation entre des objets détectés dans le contenu multimédia des nouvelles données de signalement d’incident SIGN et des objets déjà détectés pour les contenus multimédias des données de signalement d’incident déjà stockées dans la base de données d’incidents 25.

[0093] Lors d’une étape S6A, si les données de signalement d’incident SIGN reçues sont relatives à un incident déjà stocké dans la base de données d’incidents 25, ces données de signalement d’incident SIGN sont associées au sein de la base de données d’incidents 25 à l’incident correspondant.

[0094] Alternativement, lors d’une étape S6B, un nouvel incident associé aux données de signalement d’incident reçues est stocké dans la base de données d’incidents 25.

[0095] Comme expliqué précédemment, dans un ou plusieurs modes de réalisation, les données de signalement d’incident SIGN émises par le terminal utilisateur 7 comprennent un identifiant du compte utilisateur à partir duquel l’utilisateur du terminal utilisateur 7 a signalé l’incident. Par ailleurs, au sein de la base de données d’utilisateurs 27, chaque identifiant de compte utilisateur est associé à un indice de confiance.

[0096] Ainsi, lors d’une étape S7, l’unité de traitement 31 détermine l’indice de confiance associé à l’identifiant du compte utilisateur émetteur des données de signalement d’incident SIGN, c’est-à-dire, dans le cas décrit ici, l’identifiant associé au compte utilisateur auquel s’est connecté l’utilisateur du terminal utilisateur 7 et a, depuis l’application exécutée, signalé l’incident.

[0097] Par ailleurs, comme expliqué précédemment, chaque incident répertorié dans la base de données d’incidents 25 est associé à un coefficient de fiabilité. Un tel coefficient de fiabilité permet de caractériser la fiabilité de l’incident signalé et, ainsi, d’éviter de signaler potentiellement un incident n’existant pas.

[0098] Ainsi, lors de l’étape S8, l’unité de traitement 31 de la structure de traitement 9 met à jour le coefficient de fiabilité de l’incident auxquelles se rapporte les données de signalement d’incident SIGN reçues en fonction de l’indice de confiance associé au compte utilisateur émetteur de ces données de signalement d’incident SIGN. Bien entendu, dans le cas où les données de signalement d’incident SIGN correspondent à un nouvel incident, l’indice de confiance permet d’initialiser le coefficient de fiabilité associé à ce nouvel incident. En d’autres termes, la structure de traitement 9 calcule, pour chaque incident signalé, un coefficient de fiabilité en fonction de l’indice de confiance du ou des comptes utilisateur émetteurs des données de signalement d’incident relative à l’incident considéré.

[0099] Lors d’une étape S9, le coefficient de fiabilité de l’incident signalé est comparé à un seuil prédéterminé. Ce seuil prédéterminé est par exemple stocké dans la mémoire 33 de l’unité de traitement 31.

[0100] Par ailleurs, alternativement ou parallèlement il est également possible de définir d’autres conditions que l’incident signalé doit vérifier lors de cette étape S9. Par exemple, en plus ou à la place de la condition portant sur le coefficient de fiabilité de l’incident, la structure de traitement peut déterminer un coefficient de complétude caractérisant la suffisance ou l’insuffisance des informations remontées concernant l’incident signalé. Par exemple, ce coefficient de complétude est une variable binaire prenant la valeur 0 lorsque les informations remontées par les différents utilisateurs, et plus exactement les différents comptes utilisateur, ne sont pas suffisante pour résoudre l’incident signalé ou la valeur 1 lorsque les informations remontées sont suffisantes pour la résolution de l’incident signalé.

[0101] Par exemple, le coefficient de complétude dépend de la précision de la géolocalisation de l’incident évaluée par comparaison des différentes données de géolocalisation comprises dans les données de signalement d’incident SIGN relatives à l’incident en question.

[0102] Toujours à titre d’exemple, le coefficient de complétude peut dépendre de la précision concernant le type de l’incident signalé. En effet, comme expliqué précédemment, l’application exécutée par un utilisateur peut laisser la possibilité à ce dernier de renseigner, via une option de texte libre, le type de l’incident auquel cas une incertitude peut exister sur le type de l’incident, la qualification du type de l’incident pouvant varier d’un utilisateur à l’autre.

[0103] Lors d’une étape S10, mise en œuvre dans le cas où le coefficient de fiabilité de l’incident est supérieur ou égal au seuil prédéterminé, l’unité de traitement 31 génère une information de signalement d’incident INE relative à l’incident considéré.

[0104] Par ailleurs, comme expliqué précédemment, un coefficient de complétude peut également être déterminé par la structure de traitement 9 de sorte que, dans ce mode de réalisation, l’étape S10 n’est mise en œuvre que si, en plus à la place de la condition sur la valeur du coefficient de fiabilité, la valeur du coefficient de complétude est satisfaisante.

[0105] Ainsi, dans le cas où le coefficient de complétude est une variable binaire, la génération de l’information de signalement d’incident est mise en œuvre si et seulement si le coefficient de complétude de l’incident est égal à 1.

[0106] Comme expliqué précédemment, l’information de signalement d’incident INF comprend les éléments nécessaires à la résolution de l’incident signalé. Ainsi, l’information de signalement d’incident INF comprend la géolocalisation de l’incident ainsi que le type de l’incident sélectionné dans la liste préétablie d’incidents potentiels. Bien entendu, d’autres éléments comme le niveau d’urgence de l’incident peuvent être compris dans l’information de signalement d’incident.

[0107] Lors d’une étape SI 1, consécutive à l’étape S10, la structure de traitement 9 et plus précisément l’unité de traitement 31, sélectionne un ou plusieurs destinataires de l’information de signalement d’incidents INF au sein de la base de données de destinataires 29 en fonction de l’information de signalement d’incident INF générée.

[0108] Comme expliqué précédemment, chaque destinataire est associé, au sein de la base de données de destinataires 29, à un ou plusieurs types d’incident. Ainsi, par exemple, les destinataires sélectionnés sont les destinataires associés au moins au type de l’incident signalé. Par ailleurs, chaque destinataire peut être associé en outre à une zone géographique au sein de la base de données de destinataires 29 de sorte qu’un critère supplémentaire peut consister à ne sélectionner que les destinataires dont la zone géographique comprend la géolocalisation de l’incident signalé.

[0109] Bien entendu, d’autres modes de réalisation sont possibles. Ainsi, un destinataire peut être sélectionné par la structure de traitement 9 même si la géolocalisation de l’incident n’est pas dans sa zone géographique si le niveau d’urgence de l’incident est faible.

[0110] Lors d’une étape S12, le module de communication 23 de la structure de traitement 9 émet l’information de signalement d’incident SIGN à destination du ou des destinataires sélectionnés. Par ailleurs, il convient de noter que l’adresse de chaque destinataire est également stockée dans la base de données de destinataires 29, ce qui permet par la suite l’acheminement de l’information de signalement d’incident SIGN. L’information de signalement d’incident INF sont par exemple émises à destination de la structure de traitement 9 via un réseau de type MAN.

[0111] Comme expliqué précédemment, l’information de signalement d’incident INF peut être transmise directement au destinataire. Dans l’exemple illustré en [Fig. 1], le destinataire de l’information de signalement d’incident INF est le système d’information

3. Le système d’information 3 est typiquement le système d’information d’une administration ou d’un prestataire de services en charge de la résolution d’incidents tels que l’incident signalé via l’information de signalement d’incident SIGN.

[0112] Par ailleurs, l’information de signalement d’incident peut être également utilisée pour mettre à jour le portail web 5, et plus exactement le contenu personnalisé du portail web 5 réservé à l’administration ou au prestataire de service auquel se rattache le système d’information 3. Ainsi, en accédant à son compte utilisateur, un salarié habilité de l’administration ou du prestataire de services a accès aux informations relatives à un incident signalé et relevant de son domaine d’intervention.

[0113] Les étapes S10, SI 1 et S12 décrites précédemment sont mises en œuvre lorsque le coefficient de fiabilité de l’incident signalé est supérieur ou égal au seuil prédéterminé. Néanmoins, dans le cas où le coefficient de fiabilité est inférieur au coefficient de fiabilité, les étapes décrites ci-après sont mises en œuvre par la structure de traitement 9.

[0114] Dans un ou plusieurs modes de réalisation, le stockage d’un nouvel incident dans la base de données d’incidents 25 déclenche une période de temps prédéterminée. Ainsi, si à l’issue de cette période de temps prédéterminée, le coefficient de fiabilité de l’incident signalé n’est pas supérieur au seuil prédéterminé, l’incident et les données de signalement d’incident qui lui sont associées sont supprimés de la base de données d’incident 25.

[0115] L’unité de traitement 31 est par exemple munie d’une horloge (non représentée sur la

[Fig. 1]).

[0116] Ainsi, lors d’une étape S13, dans le cas où le coefficient de fiabilité est inférieur au seuil prédéterminé, il est déterminé si la période de temps prédéterminée associée à l’incident est écoulée ou non.

[0117] Lors d’une étape S14, si la période de temps prédéterminée est écoulée, l’incident et les données de signalement d’incident qui lui sont associées sont supprimés de la base de données d’incident 25.

[0118] En revanche, si la période de temps prédéterminée n’est toujours pas écoulée, la structure de traitement 9 reste dans l’attente de la réception de nouvelles données de signalement d’incident SIGN susceptibles de modifier le coefficient de fiabilité de l’incident.

[0119] L’homme du métier comprend bien entendu ici que cette contrainte liée à la période de temps prédéterminée déclenchée au moment du stockage de l’incident dans la base de données d’incidents 25 est appliquée en permanence. Ainsi, la structure de traitement 9 n’attend pas la réception de nouvelles données de signalement d’incident SIGN et le calcul d’un nouveau coefficient de fiabilité pour supprimer l’incident si la période de temps prédéterminée qui lui est associée est révolue.

[0120] La présente invention présente plusieurs avantages.

[0121] Tout d’abord, la structure de données permet un traitement et un acheminement efficaces permettant ainsi un signalement intelligent de l’incident auprès des destinataires concernés par l’incident signalé, en évitant ainsi de solliciter un destinataire dont le domaine d’intervention est distinct de l’incident.

[0122] Ensuite, la possibilité d’intégrer un contenu multimédia aux données de signalement d’incident et le marquage de ce contenu multimédia à l’aide d’un logiciel de reconnaissance de caractères permet une collecte de données plus objective que les données saisies ou renseignées par un utilisateur à l’aide du terminal utilisateur. L’analyse du contenu multimédia permet en outre de recueillir des informations précises et utiles pour la résolution de l’incident.

[0123] Enfin, l’utilisation d’un portail web au contenu personnalisé et mis à jour permet aux destinataires, typiquement des administrations ou des prestataires de services, de pouvoir fonctionner selon un mode dans lequel ils peuvent décider quand accéder aux signalements d’incident et lesquels ils souhaitent résoudre en priorité.

Claims (1)

1. Revendications [Revendication 1] Procédé de traitement de données de signalement d’incident mis en œuvre par des moyens informatiques, le procédé comprenant : - générer (S 10), au niveau d’une structure de traitement (9), une information de signalement d’un incident (INF) en fonction de données de signalement d’incident (SIGN) relatives audit incident et générées au niveau d’un ou plusieurs terminaux utilisateur (7) et comprenant au moins des données de géolocalisation dudit incident, - sélectionner (SI 1), en fonction de ladite information de signalement d’incident, un ou plusieurs destinataires (3) de l’information de signalement d’incident au sein d’une base de données de destinataires (29) de la structure de traitement, et - transmettre (S 12) l’information de signalement d’incident audit ou auxdits destinataires sélectionnés. [Revendication 2] Procédé selon la revendication 1, dans lequel une partie au moins des données de signalement d’incident sont générées via une application exécutée sur le terminal utilisateur. [Revendication 3] Procédé selon la revendication 2, dans lequel les données de signalement d’incident comprennent en outre des données saisies par un utilisateur du terminal utilisateur via l’application. [Revendication 4] Procédé selon l’une des revendications précédentes, dans lequel les données de signalement d’incident comprennent des données relatives à un contenu multimédia généré à l’aide du terminal utilisateur. [Revendication 5] Procédé selon la revendication 4, dans lequel le contenu multimédia est analysé (S4) au niveau de la structure de traitement à l’aide d’un logiciel de reconnaissance d’objets, des données générées par ledit logiciel de reconnaissance d’objets étant adjointes aux données de signalement d’incident. [Revendication 6] Procédé selon l’une des revendications précédentes, dans lequel les données de géolocalisation de l’incident sont déterminées automatiquement et correspondent à une position courante du terminal utilisateur. [Revendication 7] Procédé selon l’une des revendications précédentes, dans lequel la structure de traitement comprend une base de données d’incidents (25) au sein de laquelle sont stockés le ou les incidents signalés ainsi que les données de signalement d’incident respectivement associées, les données de signalement d’incident reçues étant analysées pour dé-

   terminer (S5), par comparaison avec les données de signalement d’incident précédemment stockées dans la base de données d’incidents, si lesdites données de signalement d’incident sont relatives à un incident déjà stocké dans la base de données d’incidents de sorte que : - si les données de signalement d’incident reçues sont relatives à un incident stocké dans la base de données d’incidents, lesdites données de signalement d’incident sont associées (S6A) au sein de la base de données d’incidents à l’incident correspondant ; - sinon, un nouvel incident associé aux données de signalement d’incident reçues est stocké (S6B) dans la base de données d’incidents. [Revendication 8] Procédé selon la revendication 7 prise en combinaison avec la revendication 2, dans lequel un utilisateur accède à l’application en se connectant à un compte utilisateur qui lui est propre, dans lequel les données de signalement d’incident comprennent un identifiant de compte utilisateur émetteur des données de signalement d’incident, ledit identifiant étant associé au sein d’une base de données d’utilisateurs (27) de la structure de traitement avec un indice de confiance, et dans lequel un coefficient de fiabilité est calculé par la structure de traitement pour chaque incident signalé en fonction de l’indice de confiance du ou des comptes utilisateur émetteurs des données de signalement d’incident relative audit incident, le coefficient de fiabilité d’un incident étant mis à jour (S8) à chaque réception de données de signalement d’incident relative audit incident. [Revendication 9] Procédé selon la revendication 8, dans lequel la génération de l’information de signalement d’incident et la sélection du ou des destinataires de ladite information de signalement d’incident relative à un incident sont mises en œuvre si et seulement si le coefficient de fiabilité dudit incident est supérieur ou égal à un seuil prédéterminé. [Revendication 10] Procédé selon la revendication 9, dans lequel un incident et les données de signalement d’incident associées audit incident sont supprimés (S 14) de la base de données d’incidents si le coefficient de fiabilité dudit incident est inférieur au seuil prédéterminé à l’issue d’une période de temps prédéterminée. [Revendication 11] Procédé selon l’une des revendications précédentes, dans lequel un coefficient de complétude est calculé par la structure de traitement pour chaque incident signalé en fonction d’un critère de précision concernant les données de signalement relatives audit incident, ledit coefficient de complétude étant une variable binaire prenant la valeur 0 lorsque le

   critère de précision n’est pas satisfait et prenant la valeur 1 lorsque le critère de précision est satisfait, la génération de l’information de signalement d’incident et la sélection du ou des destinataires de ladite information de signalement d’incident relative à un incident sont mises en œuvre si et seulement si le coefficient de complétude dudit incident est égal à 1. [Revendication 12] Procédé selon l’une des revendications précédentes, dans lequel l’information de signalement d’incident est mise à disposition du ou des destinataires sélectionnés via un portail web (5) au contenu personnalisé et adapté à chaque destinataire. [Revendication 13] Procédé selon l’une des revendications précédentes, dans lequel l’information de signalement comprend des données relatives à un type de l’incident sélectionné dans une liste préétablie de types d’incident, chaque destinataire stocké dans la base de données de destinataires étant associé à un ou plusieurs types d’incident de ladite liste préétablie de types d’incident. [Revendication 14] Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications précédentes, lorsque lesdites instructions sont mises en œuvre par au moins un processeur. [Revendication 15] Structure de traitement (9) de données de signalement d’incident agencée pour générer une information de signalement d’un incident (INF) en fonction de données de signalement d’incident (SIGN) relatives audit incident et générées par un ou plusieurs terminaux utilisateur (7) et comprenant au moins des données de géolocalisation dudit incident, ladite structure de traitement étant agencée en outre pour sélectionner, en fonction de ladite information de signalement d’incident, un ou plusieurs destinataires (3) de l’information de signalement d’incident, ladite structure de traitement comprenant une base de données de destinataires (29) au sein de laquelle ledit ou lesdits destinataires sont sélectionnés, ladite structure de traitement étant agencée en outre pour transmettre l’information de signalement d’incident audit ou auxdits destinataires sélectionnés.

   1/2