FR3072487A1 - Procede et systeme de traitement de donnees relatives a un incident - Google Patents

Abstract

Un procédé de traitement de données d'incident mis en œuvre par une unité de traitement est proposé. Le procédé comprend : sur réception de données de signalement d'incident, stocker dans une premiÚre base de données des données d'incident comprenant des données représentatives d'une géolocalisation de l'incident et d'un état de l'incident, sélectionner un ou plusieurs utilisateurs en fonction de données de profil utilisateur correspondant respectivement à des utilisateurs et des données d'incident, émettre une requête de retour sur incident à destination d'au moins un utilisateur sélectionné, et mettre à jour dans la premiÚre base de données l'état de l'incident en fonction de données de suivi d'incident reçues en provenance au moins d'utilisateurs sélectionnés.

Description

Procédé et système de traitement de données relatives à un incident

Le domaine de l’invention se rapporte aux procédés et systèmes de traitement de données relatives à un incident dans le but d’assurer la vérification, le suivi et la résolution de l’incident signalé.

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.

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.

Le signalement et l’enregistrement des incidents de façon collaborative présentent donc un enjeu majeur pour les villes intelligentes. Les différentes plateformes crées pour permettre aux citoyens de faire remonter des informations en cas d’incident rencontrent aujourd’hui des problèmes liés à la vérification ou au suivi du statut d’un signalement. De plus, la résolution de ces incidents se heurte à l’incapacité de ces plateformes à solliciter sélectivement les citoyens aptes à apporter une solution aux incidents signalés.

La présente invention vient améliorer la situation.

A cet effet, il est proposé un procédé de traitement de données d’incident mis en œuvre par une unité de traitement, le procédé comprenant:

a) sur réception de données de signalement d’incident comprenant des données de présence d’un incident et des données de géolocalisation de l’incident, stocker dans une première base de données des données d’incident relatives à l’incident, les données d’incident comprenant des données représentatives d’une géolocalisation de l’incident et d'un état de l'incident sélectionné parmi un ensemble prédéfini d’états, les données d’incident étant fonction des données reçues. Un incident signalé est archivé dans la première base de données afin d’assurer sa vérification, son suivi et sa résolution. Un tel archivage permet aussi de conserver un historique des incidents passés et en cours. Les données représentatives d’une géolocalisation d’un incident stockées dans la première base de données sont déterminées en fonction des données de signalement d’incident, et plus précisément des données de géolocalisation de l’incident. Ces données peuvent par exemple être transcodées et/ou formatées pour produire les données représentatives d’une géolocalisation d’un incident qui sont stockées dans la première base de données,

b) sélectionner un ou plusieurs utilisateurs en fonction de données de profil utilisateur correspondant respectivement à des utilisateurs, et en fonction des données d’incident, les données de profil utilisateur étant stockées dans une deuxième base de données,

c) émettre une requête de retour sur incident à destination d’au moins un utilisateur sélectionné, la requête de retour sur incident comprenant une partie au moins des données d’incident, et

d) mettre à jour dans la première base de données l’état de l’incident en fonction de données de suivi d’incident reçues en provenance au moins d’utilisateurs sélectionnés.

Dans un ou plusieurs modes de réalisation, l’ensemble prédéfini d’états comprend au moins un état « incident non résolu », un état « incident résolu » et un état « incident erroné ». Cet ensemble d’état permet un suivi, potentiellement en temps réel ou proche du temps réel, de l’incident signalé. Plus précisément, l’état « incident non résolu » indique que l’incident signalé n’a pas été résolu ou est en cours de résolution. L’état « incident résolu » indique que l’incident signalé a été résolu et ne nécessite donc plus l’intervention de nouveaux utilisateurs. Enfin, l’état « incident erroné » indique par exemple que l’incident a été signalé par erreur, ou que l’incident a déjà été résolu ou tout autre état ne pouvant être assimilé à l’état « incident non résolu » ou l’état « incident résolu ».

Dans ce mode de réalisation, l’émission de requête de retour sur incident et la mise à jour de l’état de l’incident sont avantageusement répétées selon un processus itératif tant que l’état de l’incident après mise à jour ne correspond pas à un état prédéfini d’arrêt du processus itératif, par exemple l’état « incident résolu ». Les données de suivi d’incident envoyées par des utilisateurs, sélectionnés ou non, connectés à leurs comptes utilisateur respectifs via leurs terminaux utilisateurs respectifs permettent de mettre à jour l’état de l’incident dans la première base de données. Dans un ou plusieurs modes de réalisation, tant que l’état de l’incident n’est pas l’état « incident résolu », des requêtes de retour sur incident sont envoyées en boucle, optimisant ainsi les chances de résolution de l’incident.

Dans les modes de réalisation utilisant le processus itératif décrit ci-dessus, le processus itératif peut être avantageusement interrompu si le nombre de cycles de répétition de l’émission de requête de retour sur incident et de la mise à jour de l’état de l’incident atteint un nombre prédéterminé. Comme expliqué précédemment, des cycles d’envoi de requêtes de retour sur incident permettent d’augmenter les chances de résolution de l’incident signalé. Néanmoins, dans le cas où l’incident a été signalé par erreur, une telle fonctionnalité d’interruption des cycles permet d’éviter de solliciter inutilement les utilisateurs.

Dans un ou plusieurs modes de réalisation, les données de profil utilisateur correspondant à un utilisateur sont représentatives d’une localisation géographique d’un terminal utilisateur de l’utilisateur. Un utilisateur est caractérisé au sein de la deuxième base de données par des données de profil utilisateur. Ces données de profil utilisateur peuvent comprendre des données de terminal comprenant des données représentatives d’une ou plusieurs localisations géographiques respectives d’un ou de plusieurs terminaux utilisateur de l’utilisateur. De telles données permettent une sélection plus fine et optimisée des utilisateurs pour le suivi, la vérification et la résolution des incidents signalés. Il est en particulier avantageux de sélectionner des utilisateurs dont une position courante ou habituelle est proche de l’incident signalé.

Dans un ou plusieurs modes de réalisation, les données de profil utilisateur correspondant à un utilisateur comprennent des données représentatives d’un indice de confiance de l’utilisateur. Comme expliqué précédemment, la sélection des utilisateurs peut dépendre des données de profil utilisateur. Les données de profil utilisateur peuvent notamment comprendre des données d’indice de confiance. Il est particulièrement avantageux d’attribuer un indice de confiance à un utilisateur pour estimer la pertinence des données de suivi d’incident qu’il serait susceptible d’envoyer depuis son compte utilisateur via un terminal utilisateur. En particulier, une telle fonctionnalité permet d’attribuer plus de crédibilité et d’importance aux données de suivi d’incident envoyées par un utilisateur jugé très fiable qu’aux données envoyées par un utilisateur jugé non fiable.

Dans ce mode de réalisation, un coefficient de fiabilité peut être calculé pour chaque état de l’ensemble d’états consécutivement à la réception des données de suivi d’incident, le coefficient de fiabilité d’un état étant fonction du nombre d’utilisateurs ayant transmis des données de suivi d’incident représentatives dudit état et de l’indice de confiance respectif des utilisateurs. Les indices de confiance attribués aux utilisateurs permettent d’estimer la pertinence des données de suivi d’incident qu’ils sont susceptibles d’envoyer. Les données de suivi d’incident sont avantageusement représentatives respectivement d’un état de l’incident. On comprend ici qu’un utilisateur peut, via un terminal utilisateur, envoyer des données de suivi d’incident pour signaler qu’un incident est résolu, non résolu ou erroné. En fonction des indices de confiance de chacun on peut estimer la fiabilité de chaque état, c'est-à-dire la probabilité que l’incident soit dans tel ou tel état.

Dans ce mode de réalisation, le coefficient de fiabilité d’un état E, est par exemple défini par :

N, Ci = ^ic(j) 1=1 où :

• Ci est le coefficient de fiabilité de l’état Ej, • Ni est le nombre d’utilisateurs ayant envoyé des données de suivi d’incident qui comprennent des données de suivi représentatives de l’état Ej, et • IC(j) est l’indice de confiance du j-ième utilisateur ayant envoyé des données de suivi d’incident représentatives de l’état Ej.

Dans ce mode de réalisation, l’ensemble prédéfini d’états comprend au moins un état « incident non résolu », un état « incident résolu » et un état « incident erroné » et, en l’absence de réception de données de suivi d’incident associées à un utilisateur sélectionné à l’issue d’une période de temps prédéterminée, le coefficient de fiabilité de l’état « incident erroné » est avantageusement augmenté de l’indice de confiance dudit utilisateur. Il est tout à fait possible qu’un utilisateur reçoive sur son compte utilisateur une requête de retour sur incident mais ne réponde pas à cette requête. Dans un tel cas, on peut considérer que l’absence de réaction de la part de l’utilisateur est significative d’un état erroné de l’incident signalé.

Dans ce mode de réalisation, la mise à jour de l’état de l’incident est par exemple réalisée en fonction des coefficients de fiabilité respectifs de chaque état de l’ensemble d’états. Après un cycle d’émission de requêtes de retour sur incident, de traitement des données de suivi d’incident reçues, l’état de l’incident dans la première base de données peut être éventuellement mis à jour en fonction des données de suivi d’incident reçues.

Dans un ou plusieurs modes de réalisation, les données de profil utilisateur correspondant à un utilisateur sont représentatives d’une localisation géographique d’un terminal utilisateur de l’utilisateur et la sélection d’un ou de plusieurs utilisateur comprend :

bl) déterminer un ensemble d’utilisateurs, chaque utilisateur étant associé à un terminal utilisateur dont la localisation géographique est à une distance de la géolocalisation de l’incident inférieure ou égale à un seuil prédéterminé, b2) déterminer si l’ensemble d’utilisateurs vérifie un critère d’indice de confiance, la détermination d’un ensemble d’utilisateur étant répétée pour un nouveau seuil supérieur au précédent si le critère d’indice de confiance n’est pas vérifié, b3) sélectionner les utilisateurs parmi l’ensemble d’utilisateurs si le critère d’indice de confiance est vérifié.

Comme expliqué précédemment, les utilisateurs peuvent être sélectionnés à la fois en fonction de données de profil utilisateur (comprenant des données représentatives d’une localisation géographique d’un terminal utilisateur de l’utilisateur et des données représentatives d’un indice de confiance de l’utilisateur) et de données d’incident. Ainsi, la sélection des utilisateurs peut être effectuée en déterminant d’abord un ensemble d’utilisateurs proches de l’incident (ou ceux dont une position habituelle est proche), puis en choisissant au sein de cet ensemble des utilisateurs en fonction des indices de confiance respectifs.

Dans ce mode de réalisation, le critère d’indice de confiance est par exemple défini par :

N_p > N_P;mi_n pour tout entier naturel p compris entre 1 et n où :

• n est un entier naturel non nul prédéterminé • N_p est le nombre d’utilisateurs de l’ensemble d’utilisateurs dont l’indice de confiance est supérieur ou égal à l’indice de confiance prédéterminé IC_P et strictement inférieur à l’indice de confiance prédéterminé ICp+i, avec IC_p<IC_p+i pour tout entier naturel p compris entre 1 et n, • N_Pjmin est un entier naturel prédéterminé, pour tout entier naturel p compris entre 1 et n, les utilisateurs sélectionnés vérifiant la condition suivante :

N_p,_min < N’p où N’_p est le nombre d’utilisateurs sélectionnés dont l’indice de confiance est supérieur ou égal à l’indice de confiance prédéterminés IC_P et strictement inférieur à l’indice de confiance prédéterminé IC_p+i.

Un tel critère d’indice de confiance permet de contrôler l’hétérogénéité des utilisateurs sélectionnés pour l’envoi d’une requête de retour sur incident. Il est en effet avantageux d’avoir des utilisateurs fiables ou très fiables pour assurer un suivi optimal de l’état de l’incident signalé. Mais il est aussi avantageux de pouvoir sélectionner des utilisateurs non fiables ou peu fiables pour réévaluer leurs indices de confiance respectifs. Une telle fonctionnalité assure un dynamisme dans la mise à jour des données de profil utilisateur dans la deuxième base de données via un apprentissage intelligent.

Dans un ou plusieurs modes de réalisation, l’indice de confiance d’au moins un utilisateur à l’origine de données de suivi d’incident est mis à jour en fonction de l’état de l’incident dont les données de suivi d’incident sont représentatives et de l’état de l’incident mis à jour. Comme expliqué précédemment, l’état de l’incident est éventuellement mis à jour après traitement des données de suivi d’incident reçues. Il est ainsi possible de comparer l’état de l’incident après mise à jour et l’état de l’incident tel que renseigné par les utilisateurs. Ainsi, si l’état de l’incident est l’état « incident résolu » après mise à jour mais qu’un utilisateur a signalé l’incident comme étant non résolu, l’indice de confiance de cet utilisateur peut être diminué et l’utilisateur peut passer, par exemple, de fiable à peu fiable. À l’inverse, si l’état de l’incident est, par exemple, l’état « incident erroné » après mise à jour et qu’un utilisateur a effectivement signalé l’incident comme étant erroné, l’indice de confiance de cet utilisateur peut être augmenté et l’utilisateur peut passer, par exemple, de peu fiable à fiable.

Dans un ou plusieurs modes de réalisation, les données de profil utilisateur correspondant à un utilisateur sont représentatives d’un mode actif, dans lequel l’utilisateur est systématiquement sélectionné, ou d’un mode passif, dans lequel l’utilisateur n’est pas systématiquement sélectionné. Il est possible pour un utilisateur d’être sélectionné même lorsque sa localisation géographique ou son indice de confiance ne justifient pas qu’il soit sélectionné. Ainsi un utilisateur dont les données de profil utilisateur sont représentatives du mode actif est systématiquement sélectionné.

Il est proposé en outre un programme informatique caractérisé en ce qu’il comporte des instructions pour la mise en œuvre du procédé de traitement de données d’incident selon l’un des modes de réalisations proposé dans les présentes, lorsque ce programme est exécuté par au moins un processeur.

Il est proposé enfin un système de traitement de données d’incident pour la mise en œuvre du procédé, le système comprenant : un module de communication adapté pour recevoir des données de signalement d’incident, une première base de données adaptée pour stocker des données d’incident relatives à l’incident, une deuxième base de données adaptée pour stocker des données de profil utilisateur correspondant respectivement à des utilisateurs, et une unité de traitement comprenant un processeur, couplée de manière opérationnelle au module de communication et aux première et deuxième bases de données, dans lequel le module de communication, les première et deuxième bases de données et l’unité de traitement sont en outre adaptés pour mettre en œuvre un procédé de traitement de données d’incident selon l’un des modes de réalisation proposé dans les présentes.

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 :

la Figure 1 illustre un ensemble comprenant au moins un terminal utilisateur à l’origine de données relatives à un incident, un système et une pluralité de terminaux utilisateur sélectionnés pour la vérification, le suivi et la résolution de l’incident;

la Figure 2 illustre un procédé de traitement de données relatives à l’incident dans un ou plusieurs modes de réalisation ; et la Figure 3 illustre une sélection d’un ou plusieurs terminaux utilisateur du procédé illustré en Figure 2.

La Figure 1 illustre un ensemble 1. L’ensemble 1 comprend au moins un terminal utilisateur 3, un système 5 et des terminaux utilisateur 7, 9.

Le terminal utilisateur 3 est adapté pour signaler un incident au système 5. Plus exactement, le terminal utilisateur 3 permet à un utilisateur en sa possession de signaler un incident et des informations relatives à l’incident au système 5. Par exemple, 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.

Le terminal utilisateur 3 comprend une interface Homme/Machine 11, un module de traitement 13 et un module de communication 15.

L’interface Homme/Machine 11 est adaptée pour permettre à l’utilisateur de préciser la géolocalisation de l’incident qu’il souhaite signaler au système 5. Alternativement, la géolocalisation de l’incident est associée à une position courante du terminal utilisateur 3. La position courante du terminal utilisateur 3 est par exemple déterminée automatiquement par un serveur connecté à un réseau auquel le terminal utilisateur 3 est connecté. Alternativement, le terminal utilisateur 3 comprend un module de géolocalisation, par exemple de type GPS (acronyme anglophone pour « Global Positioning System ») ou de type Galileo.

Avantageusement, l’interface Homme/Machine 11 est 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.

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.

Les fonctionnalités décrites précédemment et accessibles à l’utilisateur souhaitant signaler un incident via l’interface Homme/Machine 11 de son terminal utilisateur sont accessibles à l’utilisateur en question par exemple en se connectant à un compte utilisateur. On comprend ici que dans un ou plusieurs modes de réalisation, un utilisateur souhaitant participer au signalement, au suivi, à la vérification et à la résolution d’incidents peut le faire en exécutant une application client sur un terminal utilisateur (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 pour se connecter à une application serveur exécutée sur un système de traitement de données d’incident tel que proposé dans les présentes. 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. En fonction du mode de réalisation, une application client exécutée sur un terminal utilisateur 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 lieu de travail, son adresse de domicile ou tout autre lieu fréquenté régulièrement par l’utilisateur.

Le module de traitement 13 est adapté pour générer des données de signalement SIGN relatives à l’incident. Dans la suite de la description, les données SIGN relatives à l’incident sont appelées données de signalement d’incident SIGN. Les données de signalement d’incident SIGN peuvent en particulier comprendre des données de présence et des données de géolocalisation de l’incident ou des incidents.

Avantageusement, les données de signalement d’incident SIGN comprennent des données d’urgence de l’incident ou de chaque incident auquel il se rapporte. Dans un ou plusieurs modes de réalisation, les données d’urgence d’un incident sont représentatives d’un niveau d’urgence sélectionné par l’utilisateur pour l’incident.

Avantageusement, les données de signalement d’incident SIGN comprennent des données de type de l’incident ou de chaque incident auquel il se rapporte. Dans un ou plusieurs modes de réalisation, les données de type d’un incident sont représentatives d’un type de l’incident tel que sélectionné ou spécifié par l’utilisateur.

Avantageusement, les données de signalement d’incident SIGN comprennent en outre des données d’identifications du terminal utilisateur 3.

Dans un ou plusieurs modes de réalisation, le module de traitement 13 comprend une mémoire 17 et un processeur 19.

La mémoire 17 peut être configurée pour stocker des lignes de code d’un programme informatique dont l’exécution par le processeur 19 se traduit par le fonctionnement du module de traitement 13 pour la mise en œuvre du procédé de traitement d’incident proposé. Avantageusement, la mémoire 17 est en outre configurée pour stocker une adresse du système 5 pour l’acheminement des données de signalement d’incident SIGN à destination du système 5 correspondant.

Le module de communication 15 est adapté pour émettre les données de signalement d’incident SIGN à destination du système 5. Les données de signalement d’incident SIGN sont par exemple émises à destination du système 5 via un réseau (non représenté sur la Figure 1). Un tel réseau est par exemple un réseau de type MAN (acronyme anglophone pour « Metropolitan Area Network »).

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 15 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.

Le système 5 est adapté pour assurer le suivi de l’incident signalé.

Dans le mode de réalisation non limitatif illustré en Figure 1, le système 5 comprend un module de communication 21, une première base de données 23, une deuxième base de données 25 et une unité de traitement 27.

Le module de communication 21 est adapté pour recevoir des données de signalement d’incident SIGN émises par un terminal utilisateur 3. Avantageusement, le module de communication 21 est adapté pour recevoir des données de signalement d’incident SIGN émises par des terminaux utilisateur tel que le terminal utilisateur 3. Le module de communication 21 est en outre adapté pour communiquer avec des terminaux utilisateur. Dans l’exemple illustré en Figure 1, le module de communication 21 est adapté pour communiquer avec la pluralité de terminaux utilisateur 7, 9. Le module de communication 21 communique par exemple avec la pluralité de terminaux 7, 9 via un réseau (non représenté sur la figure). Un tel réseau est par exemple un réseau de type MAN.

Là encore, 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 21 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.

Dans un ou plusieurs modes de réalisation, la première base de données 23 est adaptée pour stocker des données, dites données d’incident, relatives à un incident signalé. Les données d’incident stockées dans la première base de données 23 peuvent comprendre, pour un incident, des données représentatives d’une géolocalisation de l’incident, par exemple reçues avec des données de signalement d’incident SIGN relatives à l’incident et reçues par le système 5. Avantageusement, les données représentatives d’une géolocalisation de l’incident stockées dans la première base de données 23 sont fonction des données de signalement d’incident SIGN reçues.

Dans un ou plusieurs modes de réalisation, les données d’incident stockées dans la première base de données 23 peuvent en outre comprendre, pour un incident, des données représentatives d'un état de l'incident, ou données d’état d’incident, sélectionné parmi un ensemble d’états. Dans un mode de réalisation, l’ensemble d’états peut comprendre au moins un état « incident non-résolu », un état « incident résolu » et un état « incident erroné » ou « erreur sur l’incident ». Les données d’état d’incident dans la première base de données 23 peuvent être définies et structurées pour permettre d’opérer un suivi de l’évolution de l’incident au cours du temps, sur la base des informations d’état de l’incident. Par exemple, au signalement de l’incident, l’état de celui-ci dans la première base de données 23 peut être l’état « incident non-résolu » puisque l’incident n’est a priori pas encore résolu. Dans un ou plusieurs modes de réalisation, cet état « incident non résolu » peut être assigné par défaut à tout incident nouvellement signalé et nouvellement consigné dans la première base de données 23.

Dans un ou plusieurs modes de réalisation, l’état « incident résolu » peut être utilisé pour caractériser un incident résolu. Par exemple, l’état « incident résolu » peut être assigné à un incident consigné dans la première base de données 23, et dont l’état a évolué vers un état dans lequel l’incident est considéré comme résolu.

Dans un ou plusieurs modes de réalisation, l’état « incident erroné » peut être utilisé pour caractériser un incident signalé mais dont la véracité n’est pas établie ou n’a pas pu être établie.

Dans un ou plusieurs modes de réalisation, les données d’incident stockées dans la première base de données 23 peuvent en outre comprendre, pour un incident, des données d’urgence de l’incident.

Dans un ou plusieurs modes de réalisation, les données d’incident stockées dans la première base de données 23 peuvent en outre comprendre, pour un incident, des données représentatives de l’information de type de l’incident.

Avantageusement, la première base de données 23 conserve l’ensemble des incidents signalés par des terminaux utilisateur tels que le terminal utilisateur 3. La conservation dans la première base de données 23 des incidents signalés permet d’établir un historique. L’historique en question peut comporter d’autres données sur les incidents signalés comme des données vidéo ou des images relatives aux incidents.

Dans un ou plusieurs modes de réalisation, la deuxième base de données 25 est adaptée pour stocker des données, dites données de profil utilisateur, respectivement relatives à des utilisateurs. Comme indiqué précédemment, les données de profil utilisateur peuvent être associées à un compte utilisateur de l’utilisateur. La deuxième base de données 25 pourra par exemple comprendre une liste d’utilisateurs, et à chaque utilisateur de la liste pourront correspondre des données de profil utilisateur stockées dans la deuxième base de données 25.

Dans un ou plusieurs modes de réalisation, les données de profil utilisateur stockées dans la deuxième base de données 25 peuvent comprendre, pour un utilisateur, des données représentatives d’une localisation géographique d’un terminal utilisateur de l’utilisateur, ou données de terminal. La localisation géographique d’un terminal utilisateur est par exemple une position courante du terminal utilisateur. Alternativement, la localisation géographique pourra être une position régulière ou habituelle du terminal utilisateur, ou bien une combinaison d’une position courante et d’une position régulière ou habituelle du terminal. Les données de localisation géographique d’un terminal utilisateur stockée dans la deuxième base de données 25 peuvent correspondre, selon le mode de réalisation choisi, à différents niveaux d’échelle géographique, et peuvent par exemple désigner un domicile, un lieu de travail de l’utilisateur en possession du terminal utilisateur ou tout autre lieu fréquenté occasionnellement par l’utilisateur. Dans un ou plusieurs modes de réalisation, les données de profil utilisateur stockées dans la deuxième base de données 25 peuvent comprendre, pour un utilisateur, des données représentatives d’une pluralité de localisations géographiques, chaque donnée de localisation géographique de la pluralité de localisations géographiques étant associée à une donnée de probabilité que le terminal utilisateur soit présent à cette localisation géographique. On comprend ici qu’une ou plusieurs localisations géographiques peuvent être associées à un terminal utilisateur correspondant à l’utilisateur dans la deuxième base de données 25.

Dans un ou plusieurs modes de réalisation, les données de profil utilisateur stockées dans la deuxième base de données 25 peuvent comprendre, pour un utilisateur, des données représentatives d’un indice de confiance IC, ou données d’indice de confiance. L’indice de confiance IC d’un utilisateur est représentatif de la contribution passée de l’utilisateur à la vérification, au suivi et à la résolution d’incidents passés. Selon le mode de réalisation choisi, l’indice de confiance IC peut prendre des valeurs continues, ou des valeurs discrètes. A titre d’exemple, le système 5 peut être configuré pour utiliser des valeurs discrètes d’indices de confiance, par exemple l’ensemble de valeurs {0; 0.25; 0.5; 1; 2}, et un utilisateur jugé non fiable peut être associé dans la deuxième base de données 25 à une valeur d’indice de confiance égale à 0, un utilisateur jugé neutre peut être associé dans la deuxième base de données 25 à une valeur d’indice de confiance égale à 0.25, un utilisateur jugé plutôt fiable peut être associé dans la deuxième base de données 25 à une valeur d’indice de confiance égale à 0.5, un utilisateur jugé fiable peut être associé dans la deuxième base de données 25 à une valeur d’indice de confiance égale à 1, et un utilisateur jugé très fiable peut être associé dans la deuxième base de données 25 à une valeur d’indice de confiance égale à 2.

Dans un ou plusieurs modes de réalisation, l’unité de traitement 27 est adaptée pour sélectionner un ou plusieurs utilisateurs dans la deuxième base de données 25 en fonction de données de profil utilisateur et de données d’incident. La sélection des utilisateurs sera détaillée dans la suite. Dans l’exemple non limitatif illustré en Figure 1, les terminaux utilisateur 7, 9 sont associés respectivement à des utilisateurs sélectionnés par l’unité de traitement 27. Comme précisé précédemment, l’unité de traitement 27 peut ne sélectionner qu’un seul utilisateur.

Dans un ou plusieurs modes de réalisation, l’unité de traitement 27 peut en outre être adaptée pour générer une requête de retour sur incident REQ destinée à être émise à destination d’un ou plusieurs utilisateurs sélectionnés. Comme expliqué précédemment, tout utilisateur souhaitant participer au signalement, au suivi, à la vérification et à la résolution d’incident doit disposer d’un compte utilisateur. On comprend ici que la requête de retour sur incident REQ est transmise au compte utilisateur de chaque utilisateur sélectionné. Un utilisateur sélectionné peut donc accéder à la requête de retour sur incident REQ en se connectant à son compte utilisateur via un terminal utilisateur. La requête de retour sur incident REQ peut comprendre une partie au moins des données d’incident. La requête de retour sur incident REQ peut par exemple comprendre des données relatives à la géolocalisation de l’incident. En fonction du mode de réalisation, la requête de retour sur incident REQ peut en outre comprendre un niveau d’urgence de l’incident, un type de l’incident et/ou un état de l’incident. La requête de retour sur incident REQ permet aux utilisateurs sélectionnés de prendre connaissance de l’incident et des éléments nécessaires comme le niveau d’urgence de l’incident ou sa géolocalisation.

La requête de retour sur incident REQ peut être émise par le module de communication 21 à destination des terminaux sélectionnés.

Dans un ou plusieurs modes de réalisation, l’unité de traitement 27 peut en outre être adaptée pour mettre à jour les données d’état d’incident dans la deuxième base de données 25 en fonction de données de suivi d’incident reçues en provenance au moins d’ utilisateurs sélectionnés. On comprend ici qu’un utilisateur sélectionné pour recevoir une requête de retour sur incident REQ peut ne pas répondre à la requête de retour sur incident REQ. On comprend également qu’un utilisateur souhaitant transmettre des données de suivi d’incident à l’unité de traitement 27 peut émettre ces données via un terminal utilisateur en sa possession après s’être connecté sur son compte utilisateur.

Dans un ou plusieurs modes de réalisation, les données de profil utilisateur d’un utilisateur comprennent des données représentatives d’un mode actif, dans lequel l’utilisateur est systématiquement sélectionné pour recevoir une requête de retour sur incident REQ, ou d’un mode passif, dans lequel l’utilisateur n’est pas systématiquement sélectionné pour recevoir une requête de retour sur incident REQ. On comprend ici que les utilisateurs dont les données de profil utilisateur comprennent des données représentatives d’un mode actif font partie des utilisateurs sélectionnés, c'est-à-dire les utilisateurs à destination desquels une requête de retour sur incident REQ est émise via leurs comptes utilisateur respectifs.

Dans un ou plusieurs modes de réalisation, l’unité de traitement 27 comprend une mémoire 29 et un processeur 31.

La mémoire 29 peut être configurée pour stocker des lignes de code d’un programme informatique dont l’exécution par le processeur 31 se traduit par le fonctionnement de l’unité de traitement 27 pour la mise en œuvre du procédé de traitement d’incident proposé. Avantageusement, la mémoire 29 est en outre configurée pour stocker des adresses respectives de comptes utilisateur pour l’acheminement d’une requête de retour sur incident REQ à destination de chaque utilisateur sélectionné auquel il est prévu d’envoyer une requête de retour sur incident REQ.

Dans un ou plusieurs modes de réalisation, chaque compte utilisateur associé à un utilisateur sélectionné peut être adapté pour, sur réception d’une requête de retour sur incident REQ, ou indépendamment de la réception ou non d’une requête de retour sur incident, recueillir des informations concernant un incident signalé. Les comptes utilisateur respectifs des utilisateurs sélectionnés peuvent ainsi être configurés pour coopérer avec le système 5 pour permettre à ce dernier un suivi de l’incident signalé.

Dans l’exemple illustré en Figure 1 et comme expliqué précédemment, les utilisateurs sélectionnés ont accès à la requête de retour sur incident REQ émise par le système 5 respectivement via les terminaux utilisateur 7, 9. En d’autres termes, deux utilisateurs ont été sélectionnés dans l’exemple illustré en Figure 1. Chaque utilisateur sélectionné accède à la requête de retour sur incident REQ en ouvrant son compte utilisateur sur un terminal utilisateur, ici un premier terminal utilisateur 7 et un deuxième terminal utilisateur 9. Idéalement, plusieurs dizaines d’utilisateur sont sélectionnés par le système 5 pour l’envoi d’une requête de retour sur incident REQ.

Chaque terminal utilisateur 7, 9 est adapté pour permettre à un utilisateur d’accéder à son compte utilisateur. Par exemple, le terminal utilisateur 7, 9 est adapté pour se connecter à un réseau de type Internet et permettre ainsi à l’utilisateur d’accéder à son compte utilisateur.

Dans un ou plusieurs modes de réalisation, chaque terminal utilisateur 7, 9 comprend un module de communication 33, une interface Homme/Machine 35 et un module de traitement 37.

Le module de communication 33 est adapté pour communiquer avec le système 5. Plus particulièrement, le module de communication 33 est adapté pour recevoir une requête de retour sur incident REQ émise par le système 5.

Le module de communication 15 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.

Dans un ou plusieurs modes de réalisation, l’interface Homme/Machine 35 est adaptée pour afficher des informations caractéristiques de l’incident, et les rendre accessibles à l’utilisateur. Ces informations sont destinées à faciliter la vérification et la résolution de l’incident par l’utilisateur. L’interface Homme/Machine 35 est par exemple adaptée pour afficher la géolocalisation de l’incident.

Par exemple, l’interface Homme/Machine 35 est avantageusement adaptée pour afficher le niveau d’urgence de l’incident, le type de l’incident et/ou l’état de l’incident.

Dans un ou plusieurs modes de réalisation, l’interface Homme/Machine 35 est en outre adaptée pour permettre à l’utilisateur de sélectionner un état de l’incident parmi un ensemble d’états d’incident pour indiquer au système 5 un état courant de l’incident tel qu’il le constate. Cet ensemble d’états d’incident comprend préférentiellement l’ensemble d’états d’incident utilisé dans la première base de donnés 23. En cas de résolution de l’incident, l’utilisateur peut par exemple sélectionner l’état « incident résolu » ou un état équivalent parmi l’ensemble d’états pour indiquer que l’incident est résolu. En cas de non résolution de l’incident, l’utilisateur peut par exemple sélectionner l’état « incident non résolu » ou un état équivalent parmi l’ensemble d’états pour indiquer que l’incident n’est toujours pas résolu En cas d’absence d’incident, l’utilisateur peut par exemple sélectionner l’état « incident erroné » ou un état équivalent parmi l’ensemble d’états pour indiquer qu’il ne constate aucun incident, éventuellement correspondant au type d’incident qui lui est indiqué, à l’endroit correspondant à la géolocalisation de l’incident.

Plus spécifiquement, les informations et données concernant l’incident ainsi que les fonctionnalités permettant à l’utilisateur de participer à la vérification, le suivi et la résolution de l’incident sont accessibles via l’interface Homme/Machine 35 lorsque l’utilisateur est connecté à son compte utilisateur via son terminal utilisateur 7, 9.

Dans un ou plusieurs modes de réalisation, l’unité de traitement 37 peut être adaptée pour générer des données de suivi d’incident destinées à être émises à destination du système 5. Dans l’exemple décrit ici, le terminal utilisateur 7 envoie un message ANS7 contenant des données de suivi d’incident à destination du système 5, et le terminal utilisateur 9 envoie un message ANS9 contenant des données de suivi d’incident à destination du système 5. Les données de suivi d’incident comprises respectivement dans les messages ANS 7, ANS 9 comprennent des données relatives à un état de l’incident tel que sélectionné par l’utilisateur. Dans un ou plusieurs modes de réalisation, les messages ANS 7, ANS 9 peuvent en outre avantageusement comprendre des données d’identification du terminal utilisateur émetteur des données, telles que, par exemple, un identifiant de terminal du type numéro MSISDN (de l’anglais Mobile Station - Integrated Services Digital Network), du type IMSI (de l’anglais « International Mobile Subscriber Identity »), ou du type IMEI (de l’anglais « International Mobile Equipment Identity »).

Dans un ou plusieurs modes de réalisation, l’unité de traitement 37 comprend une mémoire 39 et un processeur 41.

La mémoire 39 peut être configurée pour stocker des lignes de code d’un programme informatique dont l’exécution par le processeur 41 se traduit par le fonctionnement de l’imité de traitement 37 pour la mise en œuvre du procédé de traitement d’incident proposé. Avantageusement, la mémoire 39 est en outre configurée pour stocker une adresse du système 5 pour l’acheminement du message comprenant des données de suivi d’incident à destination du système 5.

Dans l’exemple décrit ici, les utilisateurs sélectionnés transmettent, via un terminal utilisateur, des données de suivi d’incident à destination du système 5 en réponse à la réception de la requête de retour sur incident REQ. Comme expliqué précédemment, la deuxième base de données 25 peut être adaptée de sorte que les données de profil utilisateur peuvent correspondre à plusieurs terminaux utilisateur d’un même utilisateur. Par exemple, les terminaux utilisateur d’un même utilisateur sont caractérisés par les mêmes données d’identification. Les différents terminaux utilisateur appartenant à un même utilisateur, au sein de la deuxième base de données 25, permettent de déterminer plusieurs localisations géographiques possibles de cet utilisateur. Néanmoins, comme expliqué précédemment, un utilisateur accède à une requête de retour sur incident REQ en se connectant sur son compte utilisateur. Ainsi, un utilisateur peut tout à fait se connecter sur son compte utilisateur via un terminal utilisateur non référencé, au sein de la deuxième base de données 25, comme appartenant à l’utilisateur en question, et envoyer des données de suivi d’incident au système 5 via ce terminal utilisateur.

Un procédé de traitement d’incident tel que proposé est maintenant décrit dans un ou plusieurs modes de réalisation en référence notamment aux Figures 2 et 3.

En référence à la Figure 2, le système 5 reçoit (SI) des données de signalement d’incident SIGN en provenance d’un terminal utilisateur. Dans l’exemple décrit ici, les données de signalement d’incident SIGN proviennent du terminal utilisateur 3 et sont émises par le module de communication 15. En outre, les données de signalement d’incident SIGN comprennent des données de géolocalisation de l’incident. Dans un ou plusieurs modes de réalisation, les données de signalement d’incident SIGN comprennent en outre des données représentatives d’un niveau d’urgence de l’incident et/ou des données représentatives du type d’incident.

Sur réception des données de signalement d’incident SIGN, des données d’incident relatives à l’incident est stocké (S2) dans la première base de données 23. Les données d’incident comprennent au moins des données représentatives d’une géolocalisation de l’incident et d’un état de l’incident parmi un ensemble d’états. Comme expliqué précédemment, les données d’incident sont fonction des données de signalement d’incident SIGN reçues. Avantageusement, les données représentatives d’une géolocalisation de l’incident stockées dans la première base de données 23 sont déterminées en fonction des données de géolocalisation de l’incident comprises dans les données de signalement d’incident SIGN. Par exemple, l’état de l’incident qui vient d’être signalé par le terminal utilisateur 3 est l’état « incident non-résolu » ou un état équivalent.

Un ou plusieurs utilisateurs sont sélectionnés (S3) par l’unité de traitement 27 du système 5. Dans un ou plusieurs modes de réalisation, la sélection des utilisateurs est effectuée en fonction des données de profil utilisateur stockées dans la deuxième base de données 25, et en fonction des données d’incident. Dans un mode de réalisation, la sélection d’utilisateurs est effectuée sur la base de données de profil utilisateur comprises dans la deuxième base de données 25, sans tenir compte des données d’incident, et cette sélection peut alors être effectuée indépendamment de la réception des données de signalement d’incident SIGN. Dans une autre variante, la sélection d’utilisateurs est préconfigurée dans le système 5, indépendamment de données de profil utilisateur ou de données d’incident. L’homme du métier peut se rendre compte que les différents modes de sélection de terminaux utilisateur peuvent être utilisés isolément, ou en combinaison, en fonction du mode de réalisation choisi, et que le procédé proposé n’est pas limité à un schéma de sélection particulier.

Comme indiqué ci-dessus, les données de profil utilisateur correspondant à un utilisateur peuvent comprendre, dans un ou plusieurs modes de réalisation, des données représentatives d’une localisation géographique d’un terminal utilisateur de l’utilisateur. Les données de profil utilisateur peuvent comprendre en outre des données représentatives d’un indice de confiance IC de l’utilisateur auquel elles correspondent. Les données de profil utilisateur peuvent en outre comprendre, dans un ou plusieurs modes de réalisation, des données représentatives d’une pluralité de localisations géographiques telles qu’une position courante et une position habituelle du terminal utilisateur. La sélection d’utilisateurs (référence S3 sur la Figure 2) va maintenant être décrite dans un ou plusieurs modes de réalisation en référence à la Figure 3.

La Figure 3 illustre différentes opérations dont la mise en œuvre correspond à la réalisation, par l’unité de traitement 27, de la sélection d’utilisateurs. Plus particulièrement, ces opérations concernent le mode de sélection des utilisateurs.

En référence à la Figure 3, l’unité de traitement 27 détermine (Tl) une distance prédéterminée Di, ci-après seuil prédéterminé Di. Ce seuil prédéterminé Di permet de délimiter une zone géographique autour de la géolocalisation l’incident. Les utilisateurs dont le ou les terminaux utilisateur respectifs sont localisés dans cette zone géographique peuvent alors être sélectionnés pour être sollicités pour assurer la vérification de l’état de l’incident, par exemple par le biais de l’envoi d’une requête de retour sur incident REQ du type décrit cidessus. Comme expliqué précédemment, une localisation géographique d’un terminal utilisateur d’un utilisateur peut correspondre en outre à une position courante du terminal utilisateur. Alternativement, la localisation géographique pourra être une position régulière ou habituelle du terminal utilisateur, ou bien une combinaison d’une position courante et d’une position régulière ou habituelle du terminal.

Pour ce faire, l’unité de traitement 27 peut, dans un ou plusieurs modes de réalisation, déterminer (T2) un ensemble de terminaux utilisateur dont la localisation géographique est à une distance de la géolocalisation de l’incident inférieure ou égale au seuil prédéterminé Di.

Dans un ou plusieurs modes de réalisation, par exemple lorsque l’incident signalé est considéré comme urgent sur la base de l’information d’urgence représentative du niveau d’urgence comprise dans les données de signalement d’incident SIGN, la localisation géographique considérée pour déterminer l’ensemble de terminaux utilisateur sélectionnés est la position courante respective des terminaux utilisateur. Dans le cas d’un niveau d’urgence plus faible, la localisation géographique considérée peut être une position habituelle ou régulière de chaque terminal utilisateur.

Dans un ou plusieurs modes de réalisation, l’unité de traitement 27 détermine (T3) si l’ensemble de terminaux utilisateur déterminé lors de la précédente opération T2 vérifie un critère d’indice de confiance. Le critère d’indice de confiance sera détaillé dans la suite de la description.

L’unité de traitement 27 détermine des valeurs d’indice de confiance {IC_P}, p étant un entier naturel compris entre 1 et n+1, n étant un entier naturel non nul. Les indices de confiances IC_P sont par exemple ordonnés par ordre croissant :

ICi<...<ICp<.. .<IC_n+i

Comme expliqué précédemment, plusieurs seuils d’indice de confiance peuvent être prédéfinis pour associer respectivement des intervalles d’indice de confiance correspondants à des niveaux de fiabilité des utilisateurs. Par exemple, le système 5 peut être configuré pour déterminer qu’un utilisateur sera jugé non fiable lorsqu’il est associé à un indice de confiance égal à 0, qu’un utilisateur sera jugé neutre lorsqu’il est associé à un indice de confiance égal à 0,25, qu’un utilisateur sera jugé plutôt fiable lorsqu’il est associé à un indice de confiance égal à 0,5, qu’un utilisateur sera jugé fiable lorsqu’il est associé à un indice de confiance égal à 1, et qu’un utilisateur sera jugé très fiable lorsqu’il est associé à un indice de confiance égal à 2.

On peut supposer par exemple que l’unité de traitement 27 a déterminé des valeurs d’indices de confiance IC_P suivants:

ICi = 0

IC₂ = 0,25

IC₃ = 0,5

IC₄= 1

IC5 = 2

IC₆ = 3

A partir des valeurs d’indice de confiance {ICp}, l’ensemble des terminaux utilisateur peut être partitionné ainsi :

N = Ni + -+ Ν_ρ + ··· + Ν_η où :

• N est le nombre d’utilisateurs de l’ensemble d’utilisateurs, et • N_p est le nombre d’utilisateur de l’ensemble d’utilisateurs dont l’indice de confiance IC est supérieur ou égal à l’indice de confiance prédéterminé à IC_P et strictement inférieur à l’indice de confiance prédéterminé à IC_p+i· En d’autres termes :

IC_P < IC < IC_p+i

Ici, l’indice de confiance IC peut prendre des valeurs continues ou des valeurs discrètes.

Dans l’exemple décrit précédemment où 6 valeurs d’indice de confiance IC_P sont prédéterminées, l’ensemble des terminaux utilisateur peut être partitionné comme suit :

N = Ni+N₂ + N₃ + N₄ + N₅ où :

• Ni est le nombre d’utilisateurs de l’ensemble d’utilisateurs dont l’indice de confiance est supérieur ou égal à ICi=0 et strictement inférieur à IC2=0,25, • N2 est le nombre d’utilisateurs de l’ensemble d’utilisateurs dont l’indice de confiance est supérieur ou égal à ICi=0,25 et strictement inférieur à IC2=0,5, • N₃ est le nombre d’utilisateurs de l’ensemble d’utilisateurs dont l’indice de confiance est supérieur ou égal à IC2=0,5 et strictement inférieur à IC3=1, • N₄ est le nombre d’utilisateurs de l’ensemble d’utilisateurs dont l’indice de confiance est supérieur ou égal à IC3=1 et strictement inférieur à IC₄=2, • N₅ est le nombre d’utilisateurs de l’ensemble d’utilisateurs dont l’indice de confiance est supérieur ou égal à IC4=2 et strictement inférieur à IC2=3,

Dans un ou plusieurs modes de réalisation, il est déterminé que le critère d’indice de confiance est vérifié si :

N_p > Np_;min , pour tout entier naturel p compris entre 1 et n où Νρ,πύη est un entier naturel prédéterminé par l’unité de traitement 27.

Toujours en référence à l’exemple décrit précédemment où 6 valeurs d’indice de confiance IC_P sont prédéterminées , le critère d’indice de confiance est par exemple vérifié si l’ensemble d’utilisateurs comprend au moins Z utilisateurs très fiables, 2Z utilisateurs fiables, 4Z utilisateur plutôt fiables, 8Z utilisateurs neutres et 16Z utilisateurs non fiables, Z étant un entier naturel. En d’autres termes :

Ni_>min=16*Z

N2,min⁼ 8*Z

N_3;min=4*Z

N4,min=2*Z

N5_;min= Z

Typiquement, les utilisateurs non fiables sont sélectionnés afin de réévaluer leurs indices de confiance comme expliqué ci-après.

Si le critère d’indice de confiance n’est pas vérifié, l’unité de traitement 27 sélectionne (T4) un nouveau seuil D2 strictement supérieur à Di. Les opérations T2 et T3 sont ensuite répétées jusqu’à ce qu’un ensemble d’utilisateur vérifiant le critère d’indice de confiance soit trouvé. On comprend ici que la zone autour de l’incident dans laquelle seront sélectionnés les utilisateurs est élargie tant que l’ensemble d’utilisateurs à l’intérieur de cette zone ne vérifie pas le critère d’indice de confiance.

Lorsqu’un ensemble d’utilisateurs vérifiant le critère d’indice de confiance a été déterminé, l’unité de traitement 27 sélectionne (T5) un ou plusieurs utilisateurs parmi l’ensemble d’utilisateurs. Les utilisateurs sélectionnés sont ceux qui vérifient par exemple la condition suivante :

N · <N’ où N’p est le nombre d’utilisateurs sélectionnés dont l’indice de confiance IC est supérieur ou égal à l’indice de confiance prédéterminé IC_P et strictement inférieur à l’indice de confiance prédéterminé IC_p+i. Le nombre d’utilisateurs sélectionnés est alors N’ avec :

n' = n; + ···+ n^ + - + n;

Dans un ou plusieurs modes de réalisation, les utilisateurs sélectionnés parmi l’ensemble d’utilisateurs vérifient :

N’ = N

P ^ρ,ΠΊΐη

Toujours en référence à l’exemple décrit précédemment, les utilisateurs sélectionnés vérifient par exemple :

N’i = 16*Z

N’₂ = 8*Z

N’₃ = 4*Z

N’₄ = 2*Z

N’₅ = Z

A l’issue de cette sélection (T5) de un ou plusieurs utilisateurs parmi l’ensemble d’utilisateurs, l’unité de traitement 27 a sélectionné (S3) un ou plusieurs utilisateurs, dont les indices de confiance respectifs présentent une hétérogénéité dans le mode de réalisation décrit en référence à la figure 3.

Les opérations précédentes décrites en référence à la Figure 3 permettent de sélectionner des utilisateurs en fonction de la ou les localisations géographiques du ou des terminaux utilisateur associés aux utilisateurs dans la deuxième base de données 25 et d’un critère d’indice de confiance. Alternativement ou parallèlement, d’autres utilisateurs peuvent être sélectionnés à la place ou en plus des utilisateurs sélectionnés à l’issue de l’opération T5. En effet, comme expliqué précédemment, les données de profil utilisateur d’un utilisateur comprennent, dans un ou plusieurs modes de réalisation, des données représentatives d’un mode actif, dans lequel l’utilisateur est systématiquement sélectionné pour recevoir la requête de retour sur incident REQ, ou d’un mode passif, dans lequel l’utilisateur n’est pas systématiquement sélectionné pour recevoir une requête de retour sur incident REQ. Dans un ou plusieurs modes de réalisations, les utilisateurs sélectionnés par l’unité de traitement 27 peuvent donc être les utilisateurs sélectionnés via les opérations Tl, T2, T3, T4 et T5 ainsi que les utilisateurs dont les données de profil utilisateur sont représentatives d’un mode actif.

Dans l’exemple illustré sur la Figure 1, un premier utilisateur en possession d’un premier terminal utilisateur 7 et un deuxième utilisateur en possession d’un deuxième terminal utilisateur 9 sont sélectionnés pour l’envoi d’une requête de retour sur incident REQ.

De préférence, le système 5 sera configuré et paramétré de sorte que plusieurs dizaines d’utilisateurs sont sélectionnés. Pour ce faire, le système 5 pourra être prévu pour atteindre un seuil minimum de nombre d’utilisateur par apprentissage et paramétrage dynamique.

Une boucle de traitement dont une itération opère un envoi de requêtes et de traitement de données de suivi d’incident reçues peut être mise en œuvre dans un ou plusieurs modes de réalisation du procédé proposé. Le procédé proposé illustré sur la Figure 2 effectue ainsi une boucle itérative, chaque itération de la boucle opérant l’envoi de requêtes de retour sur incident REQ vers les terminaux utilisateur sélectionnés. Dans l’exemple illustré sur la Figure 2, la boucle parcourt un ensemble de cycles d’émission de requêtes par le biais d’un indice k de boucle qui est incrémenté (S9) à chaque itération de boucle, k étant initialisé à la valeur 0 (S4) et la boucle se terminant (S8) lorsque k atteint la valeur M, valeur déterminée par l’unité de traitement 27 et correspondant à un nombre maximum de cycles d’envoi de requête de retour sur incident REQ.

A chaque itération de la boucle, une requête de retour sur incident REQ est émise (S5) par le module de communication 21 à destination des terminaux utilisateur sélectionnés. Comme indiqué ci-dessus, la requête de retour sur incident REQ peut, dans un ou plusieurs modes de réalisation, comprendre une partie au moins des données d’incident, telle que, par exemple, des données représentatives d’géolocalisation de l’incident. La requête de retour sur incident REQ peut en outre comprendre un niveau d’urgence de l’incident, un type de l’incident et/ou un état de l’incident.

Suite à l’envoi des requêtes de retour sur incident, le système 5 reçoit des données de suivi d’incident (S6) en provenance au moins d’utilisateurs sélectionnés pour recevoir une requête de retour sur incident REQ. Comme expliqué précédemment, dans un ou plusieurs modes de réalisation, des données de suivi d’incident peuvent en outre être reçues par le système 5 en provenance d’utilisateur non sélectionnés. Il est également possible que des utilisateurs sélectionnés, bien qu’ayant reçu la requête en retour sur incident, ne répondent pas à la requête de retour sur incident REQ reçue sur leur compte utilisateur. Autrement dit, il est possible que le système ne reçoive pas de données de suivi d’incident en provenance d’un terminal utilisateur connecté au compte utilisateur d’un utilisateur sélectionné.. Sur réception des données de suivi d’incident, l’unité de traitement 27 calcule un coefficient de fiabilité pour chaque état de l’ensemble prédéterminé d’états possibles pour l’incident (comprenant par exemple un état « incident non résolu » ou un état équivalent, un état « incident résolu » ou un état équivalent, et un état « incident erroné » ou un état équivalent comme décrit ci-dessus).

Dans un ou plusieurs modes de réalisation, les données de suivi d’incident émises par un terminal utilisateur comprennent typiquement des données indiquant un état courant de l’incident tel qu’entré par l’utilisateur du terminal par le biais d’une interface Homme/Machine du terminal.

Dans un ou plusieurs modes de réalisation, un coefficient de fiabilité d’un état pour l’incident est calculé en fonction du nombre d’utilisateurs ayant envoyé des données de suivi d’incident comprenant des données indiquant cet état, et éventuellement en fonction de l’indice de confiance IC respectif des utilisateurs ayant envoyé des données de suivi d’incident. Le coefficient de fiabilité d’un état permet avantageusement à l’unité de traitement 27 de déterminer par exemple une probabilité que cet état soit effectivement l’état de l’incident, par exemple l’état « incident résolu », « incident non résolu » ou « incident erroné ».

Dans un ou plusieurs modes de réalisation, le coefficient de fiabilité C, d’un état E, dans un ensemble d’états [Εί], peut être déterminé comme suit :

1=1

ou :

• Ci est le coefficient de fiabilité de l’état E_i5 • Ni est le nombre d’utilisateurs ayant envoyé des données de suivi d’incident qui comprennent des données de suivi représentatives de l’état E_i5 et • IC(j) est l’indice de confiance du j-ième utilisateur ayant envoyé des données de suivi d’incident représentatives de l’état Ej.

Dans le cas de figure non limitatif où l’ensemble d’états {Ei}_{i=1 3} comprend trois états, par exemple un état « incident résolu » ou équivalent, un état « incident non résolu » ou équivalent, et un état « incident erroné » ou équivalent, l’unité de traitement 27 mesure trois coefficients de fiabilité correspondants respectivement aux états: un premier coefficient de fiabilité pour l’état « incident résolu », un deuxième coefficient de fiabilité pour l’état « incident non résolu », et un troisième coefficient de fiabilité pour l’état « incident erroné ».

En référence au cas particulier décrit précédemment dans lequel un utilisateur sera jugé non fiable lorsqu’il est associé à un indice de confiance égal à 0, un utilisateur sera jugé neutre lorsqu’il est associé à un indice de confiance égal à 0,25, un utilisateur sera jugé plutôt fiable lorsqu’il est associé à un indice de confiance égal à 0,5, un utilisateur sera jugé fiable lorsqu’il est associé à un indice de confiance égal à 1, et un utilisateur sera jugé très fiable lorsqu’il est associé à un indice de confiance égal à 2, pour illustrer les opérations de la Figure 3, chaque coefficient Ci peut être par exemple déterminé comme suit :

Cj 0 * Νί _ηοη finies + 0,25 * Nj,neutres d * Njpiufôtfiables d” 1 * Nj fi_abi_es + 2 * N^très fiables où :

• Ni, _non fiables est le nombre d’utilisateurs associés à un indice de confiance correspondant au niveau de confiance « non fiable » confirmant l’état E_i5 • N;, neutres est le nombre d’utilisateurs associés à un indice de confiance correspondant au niveau de confiance « neutre » confirmant l’état Ej, • N;, plutôt fiables est le nombre d’utilisateurs associés à un indice de confiance correspondant au niveau de confiance « plutôt fiable » confirmant l’état E_i5 • Ni, gables est le nombre d’utilisateurs associés à un indice de confiance correspondant au niveau de confiance « fiable » confirmant l’état Ej, • Ni, très fiables est le nombre d’utilisateurs associés à un indice de confiance correspondant au niveau de confiance « très fiable » confirmant l’état Ej.

Ainsi, dans l’exemple décrit ici, la contribution des utilisateurs non fiables n’est pas prise en compte dans le calcul des coefficients de fiabilité puisque l’indice de confiance IC correspondant est nul. L’homme du métier comprendra toutefois que d’autres valeurs que celles présentées ici sont possibles pour les utilisateurs non fiables, et que le procédé proposé n’est pas limité à des valeurs particulières d’indice de confiance associées à des niveaux de confiance. Il pourra donc être envisagé de mettre en œuvre le procédé proposé, dans un autre mode de réalisation, en prenant en compte la contribution des utilisateurs non fiables dans le calcul des coefficients de fiabilité.

Dans un mode de réalisation dans lequel l’ensemble des états possibles d’un incident comprend un état « incident erroné » ou équivalent, en l’absence de de réception de données de suivi d’incident en provenance d’un utilisateur sélectionné à l’issue d’une période de temps prédéterminée, le coefficient de fiabilité de l’état « incident erroné » pourra être augmenté de l’indice de confiance IC de l’utilisateur en question. Ainsi, si un utilisateur sélectionné n’a pas émis, via un terminal utilisateur, de données de suivi d’incident au bout d’une période de temps prédéterminée, ou si les données de suivi d’incident n’ont pas été reçues par le système 5, les coefficients de fiabilité seront calculés comme si l’utilisateur avait émis, via un terminal utilisateur, des données de suivi d’incident comprenant des données indiquant l’état « incident erroné ». Dans d’autres modes de réalisation, un utilisateur sélectionné dont les données de suivi d’incident n’ont pas été reçues par le système 5 pourra ne pas être pris en compte, en particulier dans le calcul du coefficient de fiabilité de l’état « incident erroné ».

Dans un ou plusieurs modes de réalisation, le coefficient de fiabilité de l’état « incident erroné » pourra être augmenté de l’indice de confiance d’un utilisateur n’ayant pas émis, via un terminal utilisateur, de données de suivi d’incident (ou non reçues par le système 5) lorsque l’utilisateur a été sélectionné par l’unité de traitement 27 en fonction des données d’incident, par exemple en fonction de la géolocalisation de l’incident. Dans un tel mode de réalisation, le coefficient de fiabilité de l’état « incident erroné » n’est pas augmenté de l’indice de confiance d’un utilisateur dont les données de suivi d’incident n’ont pas été reçues par le système 5 dans le cas où l’utilisateur a été sélectionné uniquement parce que les données de terminal de cet utilisateur sont représentatives d’un mode actif.

Dans un ou plusieurs modes de réalisation, la période de temps prédéterminée est fonction du niveau d’urgence de l’incident. Alternativement ou parallèlement, la période de temps prédéterminée est fonction d’une distance moyenne entre les localisations géographiques respectives des terminaux utilisateur respectifs des utilisateurs sélectionnés et la géolocalisation de l’incident signalé.

A titre d’exemple, la période de temps prédéterminée pour un incident considéré comme urgent est de l’ordre de quelques heures. A titre d’exemple, la période de temps prédéterminée pour un incident considéré comme non urgent est de quelques jours.

A nouveau en référence à la Figure 1, l’unité de traitement 27 met à jour (S7) l’état de l’incident dans la première base de données 23. La mise à jour (S7) de l’état de l’incident permet avantageusement, en fonction du mode de réalisation, par exemple en fonction de la fréquence des envois de requêtes de retour sur incident REQ, un suivi de l’incident, éventuellement en temps réel. Dans un ou plusieurs modes de réalisation, la mise à jour de l’état de l’incident tient compte d’un ou de plusieurs des coefficients de fiabilité respectifs déterminés pour chaque état de l’ensemble d’états.

Dans un ou plusieurs modes de réalisation, l’unité de traitement 27 peut utiliser pour cette mise à jour un score maximal déterminé comme suit :

Score maximal = ^réponses

Σ ^ic®

1=1 où :

• Réponses est le nombre d’utilisateur émetteurs, via un terminal utilisateur, de données de suivi d’incident, et • IC(j) est l’indice de confiance du j-ième utilisateur émetteur, via un terminal utilisateur, de données de suivi d’incident.

L’état de l’incident au sein de la première base de données 23 est mis à jour avec l’état E, si le coefficient de fiabilité de l’état Ej est supérieur à une valeur prédéterminée fonction du score maximal. Par exemple, l’état de l’incident consigné dans la première base de données 23 est mis à jour avec l’état Ej si le coefficient de fiabilité Ci de l’état Ej vérifie :

> Score maximal/

Par exemple, en référence au cas particulier développé précédemment pour illustrer les opérations de la Figure 3 et dans un cas de figure dans lequel tous les terminaux utilisateur sélectionnés, et seuls les terminaux utilisateur sélectionnés, émettent une réponse à destination du système 5, le score maximal peut être calculé comme suit :

Score maximal = 16Z * 0 + 8Z * 0,25 + 4Z * 0,5 + 2Z * 1 + Z * 2 = 8Z

Dans le cas où aucun coefficient de fiabilité déterminé ne dépasse la valeur prédéterminée, l’état de l’incident peut ne pas être mis à jour.

En fin d’itération de la boucle d’envoi des requêtes, l’unité de traitement 27 détermine (S8) si l’état de l’incident, éventuellement mis à jour, correspond à un ou plusieurs états prédéterminés (par exemple un état « incident résolu » ou équivalent), dits « états de sortie de boucle », et détermine si le nombre de cycles d’émission de requêtes de retour sur incident REQ est supérieur ou égal au nombre maximum M de cycles.

Si l’état de l’incident n’est pas un état de sortie de boucle (par exemple si l’état de l’incident n’est pas, après mise à jour, l’état « incident résolu »), et si le nombre de cycles d’émission de requêtes de retour sur incident REQ est strictement inférieur au nombre maximum M de cycles, une nouvelle itération de la boucle d’émission de requêtes de retour sur incident REQ est entreprise, avec un indice k d’itération de boucle incrémenté (S9), itération qui comprend l’envoi (S5) des requêtes de retour sur incident, la réception (S6) des données de suivi d’incident, et éventuellement une mise à jour (S7) de l’état de l’incident dans la première base de données 23. Lorsque l’état de l’incident, après mise à jour, est un état de sortie de boucle, ou lorsque l’indice k de l’itération de boucle est égal au nombre maximum M de cycles d’émission de requêtes de retour sur incident REQ, la boucle se termine.

Dans un ou plusieurs modes de réalisation, si l’état de l’incident n’est pas un état de sortie de boucle et si le nombre de cycle d’émission de requêtes de retour sur incident REQ est strictement inférieur au nombre maximum M de cycles, le procédé peut reboucler non pas sur une nouvelle itération de la boucle, mais sur une nouvelle sélection (S3) d’utilisateurs et une initialisation (S4) d’une nouvelle boucle d’envoi de requêtes de retour sur incident REQ.

Dans un ou plusieurs modes de réalisation, lorsque la boucle est terminée l’incident est archivé (S 10) dans la première base de données 23. La boucle étant terminée, l’émission des requêtes de retour sur incident REQ concernant cet incident est donc stoppée.

Dans un ou plusieurs modes de réalisation, lorsque la boucle est terminée pour un incident, l’indice de confiance IC d’au moins un utilisateur émetteur, via un terminal utilisateur, de données de suivi d’incident est mis à jour (Sll). Cette mise à jour peut tenir compte des données indiquant un état de l’incident qui ont été remontées par l’utilisateur dans les données de suivi d’incident, et de l’état de l’incident archivé. Ainsi, l’indice de confiance IC d’un utilisateur peut être mis à jour en fonction de sa contribution à la vérification, au suivi et à la résolution de l’incident. Par exemple, si un utilisateur a émis des données de suivi d’incident comprenant des données indiquant un état « incident erroné » ou qui ont été traitée comme correspondant à un état « incident erroné » ou équivalent, alors que l’incident est archivé avec un autre état (comme par exemple l’état « incident résolu »), l’indice de confiance IC de l’utilisateur pourra être diminué. A l’inverse, si un utilisateur a émis, via un terminal utilisateur, des données de suivi d’incident comprenant des données indiquant un état « incident résolu » ou équivalent, et que l’incident est archivé avec le même état, l’indice de confiance IC de l’utilisateur pourra être augmenté.

Dans un ou plusieurs modes de réalisation, l’indice de confiance IC de l’utilisateur 3 à l’origine des données de signalement d’incident est également mis à jour.

Dans d’autres modes de réalisation, l’indice de confiance IC d’un utilisateur est mis à jour à chaque mise à jour de l’état de l’incident en fonction des données désignant un état d’incident comprises dans les données de suivi d’incident du terminal utilisateur et du coefficient de fiabilité calculé pour cet état.

Le procédé proposé présente plusieurs avantages.

Tout d’abord, la sélection des terminaux utilisateur en fonction de la localisation géographique des terminaux et de la géolocalisation de l’incident permet d’optimiser les chances de vérification et de résolution d’un incident. Cette optimisation dans la sélection des terminaux utilisateur permet en outre des économies sur la bande-passante en ne mettant à contribution que les terminaux utilisateur susceptibles d’être pertinents, évitant ainsi l’afflux de réponses de terminaux utilisateur non-pertinents.

En outre, la réévaluation des indices de confiance des terminaux utilisateur qui ont contribué au suivi de l’incident permet au système 5 un apprentissage intelligent par un perfectionnement constant de la deuxième base de données 25.

Enfin, l’archivage des incidents dans une autre base de données, la première base de données 23, permet d’éviter un encombrement des bases de données et d’avoir un historique fiable concernant les différents incidents traités.

Le procédé proposé peut être mis en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, les termes « module » et « unité » peuvent correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et/ou logiciels, aptes à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit pour le module ou l’unité concerné.

Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur exécutable par un processeur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel. Un tel composant logiciel est stocké en mémoire puis chargé et exécuté par un processeur de données d'une entité physique (passerelle multimédia, équipement utilisateur, terminal, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.).

De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware). Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré comme un circuit intégré pour application spécifique ASIC (acronyme anglophone pour « ApplicationSpecific Integrated Circuit »), un système sur puce SOC (acronyme anglophone pour « System On Chip »), une carte à puce, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc.

Les SOC sont des systèmes embarqués qui intègrent tous les composants d’un système électronique dans une puce unique. Un ASIC est un circuit électronique spécialisé qui regroupe des fonctionnalités sur mesure pour une application donnée. Les ASIC sont généralement configurés lors de leur fabrication et ne peuvent être que simulés par l’utilisateur.

Un procédé de traitement de données tel que proposé peut également utiliser des architectures hybrides, comme par exemple des architectures basées sur un CPU+FPGA, un GPU (acronyme anglophone pour « Graphies Processing Unit ») ou un MPPA (acronyme anglophone pour « Multi-Purpose Processor Array »).

Le procédé proposé peut en outre être mis en œuvre sous forme d’une combinaison d’éléments logiciels et matériels, comme par exemple un programme logiciel destiné à être chargé et exécuté sur un composant de type circuits logiques programmables FPGA (acronyme anglophone pour « Field Programmable Gâte Array »). Les FPGA sont des circuits électroniques reconfigurables par l’utilisateur.

En fonction du mode de réalisation choisi, certains actes, actions, évènements ou fonctions de chacune des méthodes décrites dans le présent document peuvent être effectués ou se produire selon un ordre différent de celui dans lequel ils ont été décrits, ou peuvent être ajoutés, fusionnés ou bien ne pas être effectués ou ne pas se produire, selon le cas. En outre, dans 5 certains modes de réalisation, certains actes, actions ou évènements sont effectués ou se produisent concurremment et non pas successivement.

Bien que décrits à travers un certain nombre d’exemples de réalisation détaillés, le procédé d’encodage proposé et l’équipement pour la mise en œuvre du procédé comprennent différentes variantes, modifications et perfectionnements qui apparaîtront de façon évidente à 10 l’homme de l’art, étant entendu que ces différentes variantes, modifications et perfectionnements font partie de la portée de l’invention, telle que définie par les revendications qui suivent. De plus, différents aspects et caractéristiques décrits ci-dessus peuvent être mis en œuvre ensemble, ou séparément, ou bien substitués les uns aux autres, et l’ensemble des différentes combinaisons et sous combinaisons des aspects et caractéristiques 15 font partie de la portée de l’invention. En outre, il se peut que certains systèmes et équipements décrits ci-dessus n’incorporent pas la totalité des modules et fonctions décrits pour les modes de réalisation préférés.

Claims (11)

1. Procédé de traitement de données d’incident mis en œuvre par une unité de traitement, le procédé comprenant:

a) sur réception de données de signalement d’incident comprenant des données de présence d’un incident et des données de géolocalisation de l’incident, stocker dans une première base de données des données d’incident relatives à l’incident, les données d’incident comprenant des données représentatives d’une géolocalisation de l’incident et d'un état de l'incident sélectionné parmi un ensemble prédéfini d’états, les données d’incident étant fonction des données de signalement d’incident reçues,

b) sélectionner un ou plusieurs utilisateurs en fonction de données de profil utilisateur correspondant respectivement à des utilisateurs, et en fonction des données d’incident, les données de profil utilisateur étant stockées dans une deuxième base de données,

c) émettre une requête de retour sur incident à destination d’au moins un utilisateur sélectionné, la requête de retour sur incident comprenant une partie au moins des données d’incident, et

d) mettre à jour dans la première base de données l’état de l’incident en fonction de données de suivi d’incident reçues en provenance au moins d’utilisateurs sélectionnés.

2. Procédé selon la revendication 1, dans lequel l’ensemble prédéfini d’états comprend au moins un état « incident non résolu », un état « incident résolu » et un état « incident erroné ».

3. Procédé selon la revendication 2, dans lequel l’émission de requête de retour sur incident et la mise à jour de l’état de l’incident sont répétées tant que l’état de l’incident après mise à jour n’est pas l’état « incident résolu ».

4. Procédé selon la revendication 3, dans lequel le procédé est interrompu si le nombre de cycles de répétition de l’émission de requête de retour sur incident et de la mise à jour de l’état de l’incident atteint un nombre prédéterminé.

5. Procédé selon l’une des revendications précédentes, dans lequel les données de profil utilisateur correspondant à un utilisateur comprennent des données représentatives d’une localisation géographique d’un terminal utilisateur de l’utilisateur.

6. Procédé selon l’une des revendications précédentes, dans lequel les données de profil utilisateur correspondant à un utilisateur comprennent des données représentatives d’un indice de confiance dudit utilisateur.

7. Procédé selon la revendication 6, dans lequel un coefficient de fiabilité est calculé pour chaque état de l’ensemble d’états consécutivement à la réception des données de suivi d’incident, le coefficient de fiabilité d’un état étant fonction du nombre d’utilisateurs ayant transmis des données de suivi d’incident représentatives dudit état et de l’indice de confiance respectif desdits utilisateurs.

8. Procédé selon la revendication 7, dans lequel le coefficient de fiabilité d’un état Ej est défini par :

N;

Ci = ^ic(j) j=i où :

• Ci est le coefficient de fiabilité de l’état Ej, • Ni est le nombre d’utilisateurs ayant envoyé des données de suivi d’incident qui comprennent des données de suivi représentatives de l’état E_i5 et • IC(j) est l’indice de confiance du j-ième utilisateur ayant envoyé des données de suivi d’incident représentatives de l’état Ej.

9. Procédé selon la revendication 7 ou 8, dans lequel l’ensemble prédéfini d’états comprend au moins un état « incident non résolu », un état « incident résolu » et un état « incident erroné » et, en l’absence de réception de données de suivi d’incident associées à un utilisateur sélectionné à l’issue d’une période de temps prédéterminée, le coefficient de fiabilité de l’état « incident erroné » est augmenté de l’indice de confiance dudit utilisateur.

10. Programme informatique caractérisé en ce qu’il comporte des instructions pour la mise en œuvre du procédé selon l’une des revendications 1 à 9, lorsque ce programme est exécuté par au moins un processeur.

11. Système de traitement de données d’incident comprenant : un module de communication adapté pour recevoir des données de signalement d’incident, une première base de données adaptée pour stocker des données d’incident relatives à l’incident, une deuxième base de données adaptée pour stocker des données de profil utilisateur correspondant respectivement à des utilisateurs, et une unité de traitement comprenant un processeur, couplée de manière opérationnelle au module de communication et aux première et deuxième bases de données, dans lequel le module de communication, les première et deuxième bases de données et l’unité de traitement sont en outre adaptés pour mettre en œuvre un procédé selon l’une 5 quelconque des revendications 1 à 9.