FR 3072487 A1 20190419 FR 1759635 A 20171013 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 oeuvre 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 oeuvre 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 2 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 5 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 10 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 15 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 20 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. 25 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 30 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 3 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 5 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 10 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 15 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 20 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 25 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 30 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. 4 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 5 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 10 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 Ei est par exemple défini par : Ni Ci = ICW j=1 où : - Ci est le coefficient de fiabilité de l'état Ei, 15 - 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 Ei, 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 Ei. Dans ce mode de réalisation, l'ensemble prédéfini d'états comprend au moins un état 20 « 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 25 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 5 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 à 5 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 : b 1) 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é, 10 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é. 15 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 20 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 : Np > Np,inin pour tout entier naturel p compris entre 1 et n où : 25 - n est un entier naturel non nul prédéterminé - Np 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é ICp et strictement inférieur à l'indice de confiance prédéterminé ICp+i, avec ICp Np,min , pour tout entier naturel p compris entre 1 et n OÙ Np,min 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 ICp 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 10 utilisateur plutôt fiables, 8Z utilisateurs neutres et 16Z utilisateurs non fiables, Z étant un entier naturel. En d'autres termes : N1, min =1Z N2, min = 8*Z N3, min = 4*Z 15 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) 20 un nouveau seuil D2 strictement supérieur à D1. 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. 25 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 : 23 Np,/,,in Score maximal/2 20 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 29 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 5 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 10 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 15 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 20 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é (S10) dans la première base de données 23. La boucle étant terminée, l'émission des 25 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 (S11). 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 30 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 30 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 5 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 à 10 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. 15 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 à 20 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. 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 oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, les termes « module » et « unité » peuvent correspondre dans ce document 30 aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de 31 composants matériels et/ou logiciels, aptes à mettre en oeuvre 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 5 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.). 10 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 15 « System On Chip »), une carte à puce, une carte électronique pour l'exécution d'un micro-logiciel (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 20 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 « Graphics Processing Unit ») ou un MPPA (acronyme 25 anglophone pour « Multi-Purpose Processor Array »). Le procédé proposé peut en outre être mis en oeuvre 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 Gate Array »). Les FPGA sont des circuits 30 électroniques reconfigurables par l'utilisateur. 32 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 oeuvre 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 oeuvre 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 REVENDICATIONS: 1. Procédé de traitement de données d'incident mis en oeuvre 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. 34 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 5 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 Ei est 10 défini par : N, Ci = iC(j) j=1 où : - Ci est le coefficient de fiabilité de l'état Ei, - 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 Ei, et 15 - 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 Ei. 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 20 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 oeuvre du procédé selon l'une des revendications 1 à 9, lorsque ce programme est exécuté par au moins un processeur. 25 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 à 35 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 oeuvre un procédé selon l'une 5 quelconque des revendications 1 à 9.