Brevet FR3070777A1 — publié le 20190308

Procédé de gestion de perturbations de service, plateforme mettant en oeuvre ledit procédé et système associé L'invention concerne le domaine des plateformes de gestion d'incidents ou de perturbations de services offerts à des usagers. L'essor des technologies du numérique a conduit à 5 démultiplier les services innovants offerts au grand public ou à des acteurs privés. La diversification des moyens de communication, ou plus généralement des interfaces de restitution ou de sortie de contenus graphiques et/ou sonores mis à la disposition de chacun 10 d'entre nous, tels que les téléphones ou les tablettes intelligents, a en outre suscité une exigence croissante quant à la quantité mais aussi à la pertinence des informations en lien avec un service offert à des usagers. 15 Pour les prestataires de service, satisfaire le besoin de ses clients ou des usagers devient chaque jour davantage complexe. En effet, avec le développement et l'essor des services proposés, les attentes et exigences des clients ou usagers sont de plus en plus élevées. 20 A titre d'exemples non limitatifs, lesdits usagers souhaitent, voire même exigent : de la réactivité dans la diffusion d'une information directement compréhensible par lesdits usagers, 25 notamment dans le cadre d'une situation de perturbation d'un service ; 2 - une évolutivité d'une telle information pour que celle-ci soit en adéquation avec l'évolution des incidents ou perturbations ; - une teneur ou plus généralement le contenu de message d'information adaptée, en adéquation avec une disparité croissante de media d'affichage ou plus généralement de media de sortie d'informations selon un mode graphique et/ou sonore; - une cohérence de l'information diffusée via différents moyens de communication, quelle que soit la localisation d'un usager ; - une information pertinente dans la description des impacts sur la prestation de service découlant d'un incident ; - une proposition d'une ou plusieurs alternatives pour surmonter ou atténuer les conséquences d'un incident de service. De telles attentes ne sont généralement pas 20 satisfaites ou ne le sont que très partiellement selon le service concerné. Par exemple, dans le cadre d'une application en lien avec le transport de passagers, une telle gestion d'incidents du réseau de transport demeure essentiellement 25 humaine. Généralement, quelques écrans ou haut-parleurs, dont la restitution est directement pilotée par un opérateur, se bornent à relater aux usagers un retard ou un incident à proximité des lieux d'attente de véhicules, par exemple sur un quai d'une gare ferroviaire ou routière. 30 Les usagers doivent généralement se rapprocher de personnels de la société de transport concernée par l'incident, en espérant que ceux-ci soient disponibles ou 3 accessibles et informés pour connaître la nature de l'incident et surtout les conséquences concrètes sur la continuité ou la discontinuité du service, voire pour identifier des solutions de repli. Il en résulte une grande 5 frustration, voire un mécontentement des usagers susceptible de détourner ces derniers du service. En outre, un usager ne peut généralement pas anticiper et trouver une solution alternative pour rallier une destination à une heure prévue, voire prévenir d'un retard d'une durée 10 maitrisée. Le personnel ou l'acteur d'un service peut par ailleurs se trouver parfois en première ligne et démuni face à de telles requêtes légitimes d'usagers. A titre d'exemple d'application préféré mais non 15 limitatif, l'invention sera décrite au travers d'un exemple d'application relatif au service de transport de passagers en milieu urbain. L'invention pourra toutefois s'appliquer à tout autre domaine d'application, nécessitant une analyse complexe d'incidents et une production d'informations à des humains via différentes modalités de restitution graphiques et/ou sonores. L'invention permet de répondre à tout ou partie des inconvénients soulevés par les solutions connues. En offrant une solution améliorant la qualité et la pertinence de l'information communiquée à des usagers lors d'une occurrence d'une perturbation de service, l'invention offre à un prestataire de service des moyens : - pour identifier les perturbations du service susceptibles d'intéresser directement les usagers ; - pour produire et diffuser, avec une grande réactivité, une information pertinente, c'est-à- 4 dire répondant à un éventuel questionnement des usagers face à l'occurrence d'un incident de service via des supports ou media de diffusion appropriés et à des moments opportuns. 5 A cet effet, l'invention concerne un procédé de gestion d'incidents d'un service, ledit procédé étant mis en oeuvre par une unité de traitement d'une plateforme de gestion d'incidents de service comportant outre ladite unité de 10 traitement, une mémoire de données, des moyens de communication avec le monde extérieur, ladite mémoire de données et lesdits moyens de communication coopérant avec ladite unité de traitement. Selon l'invention, les moyens de communication de 15 ladite plateforme assurent une première liaison avec un générateur de données d'incidents ou d'exploitation du service et une deuxième liaison avec un moyen de sortie d'un message d'information. En outre, un tel procédé de gestion d'incidents d'un service comporte : 20 - une étape pour collecter une donnée d'incident ou d'exploitation du service émise par le générateur de données d'incidents ou d'exploitation du service ; - une étape pour estimer une ou plusieurs conséquences 25 d'un aléa d'exploitation du service et produire un ou plusieurs messages d'information unitaires associées à ces dernières une étape pour produire un message d'information à partir desdits un ou plusieurs messages d'information unitaires ; 30 - une étape pour provoquer une sortie dudit message d'information par le moyen de sortie de sorte qu'un 5 usager dudit service perçoive la teneur dudit message d'information. Selon un deuxième objet, l'invention concerne un 5 produit programme d'ordinateur comportant des instructions de programme qui, lorsqu'elles sont exécutées ou interprétées par un ordinateur, provoquent la mise en oeuvre d'un tel procédé de gestion d'incidents d'un service conforme à l'invention. 10 Selon un troisième objet, l'invention concerne une plateforme de gestion d'incidents de service comportant une unité de traitement, une mémoire de données, une mémoire de programmes, des moyens de communication avec le 15 monde extérieur, lesdites mémoires de données et de programmes et lesdits moyens de communication coopérant avec ladite unité de traitement, ladite mémoire de programmes comportant les instructions d'un produit programme d'ordinateur conforme à l'invention. 20 Enfin, l'invention concerne un système de gestion d'incidents d'un service comportant un ou plusieurs générateurs de données d'incidents ou d'exploitation dudit service, un ou plusieurs moyens de sortie d'un message 25 d'information, lesdits générateurs et moyens de sortie coopérant avec une plateforme de gestion d'incidents de service conforme à l'invention. D'autres caractéristiques et avantages apparaîtront 30 plus clairement à la lecture de la description qui suit, se rapportant à un exemple de réalisation donné à titre 6 indicatif et non limitatif, et à l'examen des figures qui l'accompagnent parmi lesquelles : - la figure 1 illustre un exemple de réalisation non limitatif d'une architecture fonctionnelle d'une 5 plateforme de gestion d'incidents de service conforme à l'invention ; - la figure 2 présente un exemple de réalisation non limitatif d'un procédé de gestion d'incidents d'un service mis en oeuvre par une telle plateforme selon 10 l'invention - la figure 3 décrit un exemple de modélisation de données associées à un événement pour lequel un ou plusieurs messages peuvent respectivement être associés et formatés à un ou plusieurs conséquences 15 pour les usagers d'un service ; - les figures 4A à 4D décrivent un exemple de production de messages d'informations destinées aux usagers durant les étapes d'apparition, du suivi et de fin d'occurrence d'un incident de service. 20 L'invention concerne un procédé et une plateforme mettant en oeuvre ledit procédé, pour gérer un ou plusieurs incidents de service et pour traduire ces derniers en un ou plusieurs aléas d'exploitation, puis en une ou plusieurs 25 conséquences pour les usagers et in fine en un ou plusieurs messages d'information pour ces derniers, suivis de la ou des meilleures modalités de restitution ou de sortie, de sorte que lesdits usagers perçoivent la teneur desdits messages d'information et pâtissent ainsi le moins 30 possible d'un tel incident de service. Comme l'indique à titre d'exemple de réalisation préféré mais non limitatif la figure 1, une plateforme de 7 gestion d'incidents de service conforme à l'invention consiste à collecter et décoder des données d'incidents d'exploitation d'un service DIS1, DISi, ..., DISn émanant respectivement de différents générateurs ou sources IG1, 5 IGi, ..., IGn, parmi une pluralité 20 de sources disponibles, telles que des capteurs disposés sur un réseau de transport de passagers par exemple, ou encore des systèmes d'aide à l'exploitation dudit service, voire directement par un opérateur via une interface homme-machine d'entrée ou de 10 saisie, générant ainsi lesdites données d'incidents d'exploitation. De telles données peuvent être horodatées pour suivre l'évolution d'un incident et véhiculées par des messages de données transmis à une plateforme 10 de gestion d'incidents de service conforme à l'invention, via 15 un premier réseau de communication ou liaison Ni. Un tel réseau Ni peut être simple ou pluriel et mettre en oeuvre une ou plusieurs technologies et/ou protocoles de communication filaires ou sans fil, tels que, de manière non exhaustive, Internet, Sigfox, LoRa, ou plus 20 généralement tout vecteur de communication permettant à deux objets électroniques d'échanger une information de nature technique. Pour parvenir à traiter ces différentes données d'incident, l'invention s'appuie sur la mise en oeuvre d'un 25 ensemble PI de procédés de traitement de données d'exploitation et/ou d'incident du service, lesdites données d'exploitation et/ou d'incident DIS1, DISi, DISn étant exploitées par une unité de traitement 11 d'une plateforme 10, par exemple sous la forme d'un ordinateur 30 ou plus généralement d'un serveur informatique. Une telle unité de traitement 11 consiste en un ou plusieurs microprocesseurs et coopère via un ou plusieurs bus de 8 communication, symbolisés par des flèches doubles en figure 1, avec une mémoire de données 12, consistant en une ou plusieurs entités physiques et/ou logiques, dont certaines peuvent être physiquement distantes de ladite 5 unité de traitement 11. La mémoire de données 12 permet de sauvegarder par exemple toutes données de travail, des éventuels paramètres de fonctionnement de la plateforme, voire in finie le contenu d'un message d'information destiné aux usagers. L'unité de traitement 11 coopère en 10 outre avec une mémoire de programmes 14, agencée pour stocker les instructions d'un programme d'ordinateur PG, dont l'exécution ou l'interprétation, par ladite unité de traitement 11, provoque la mise en oeuvre d'un procédé PI de gestion des incidents de service conforme à l'invention. 15 Pour collecter et décoder les données d'incidents DIS1, DISi, ... DISn respectivement véhiculées par des messages émis par les générateurs de données 20, IG1, IGi, ..., IGn, une plateforme 10 selon l'invention comporte en outre des moyens de communication 13 adaptés pour interagir avec 20 lesdits générateurs ou sources de données d'incidents IG1, IGi, ..., IGn, via le premier réseau de communication ou liaison Ni. Les fonctions principales d'une telle plateforme 10, 25 correspondant aux principales étapes fonctionnelles d'un procédé PI de gestion d'incidents d'un service conforme à l'invention, consistent notamment en : - un premier bloc d'étapes 10-1 pour filtrer et regrouper des données d'incidents de service DIS1 30 à DISn afin de ne conserver qu'un corpus ou une sélection desdites données de service DIS susceptibles d'impacter les usagers du service, 9 et traduire ledit corpus en un ou plusieurs impacts AE sur l'exploitation dudit service ; un deuxième bloc d'étapes 10-2 pour traduire le ou lesdits impacts d'exploitation AE 5 préalablement estimé en conséquences CU pour les usager, de sorte à élaborer, à partir de messages unitaires associés auxdites conséquences, puis formater un ou plusieurs messages MU à destination des usagers, selon un ou 10 plusieurs moyens ou media de communication 0D1, ODj, 0Dm, appropriés pour diffuser de tels messages ; un troisième bloc d'étapes 10-3 pour organiser et provoquer la restitution graphique et/ou sonore 15 dudit ou desdits messages MU, en un ou plusieurs messages d'information MUl, MUj, MUm adaptés auxdits différents media OD1, ODj, 0Dm. De tels media de communication OD1, ODj, ...0Dm, parmi 20 une pluralité 30 de media disponibles, peuvent consister un écran d'ordinateur, un panneau d'affichage public, un serveur de mise à disposition d'information via Internet, une borne d'informations de voyageurs (également connue sous l'abréviation BIV), un ordinateur personnel, un 25 téléphone ou une tablette intelligente, etc. Une telle plateforme de gestion d'incidents de service 10 conforme à l'invention coopère avec de tels media 30 via un deuxième réseau de communication ou liaison N2, éventuellement similaire au premier réseau de communication Ni, 30 précédemment évoqué pour véhiculer les données d'incident de service DIS1 à DISn. En variante, lesdits premier et 10 deuxième réseaux de communication Ni et N2 peuvent ne constituer qu'un seul et même réseau de communication. A titre d'exemple préféré mais non limitatif, 5 l'invention va être décrite au travers d'un exemple d'application de transport de passagers. Elle pourrait s'appliquer à tout autre type de service dont un usager attend une aide concrète pour faire face ou contourner un incident de service. 10 Un exemple de réalisation détaillé d'un procédé PI de gestion d'incidents d'un service conforme à l'invention, mis en oeuvre par une plateforme telle qu'illustrée par la figure 1, est à présent décrit en lien avec la figure 2. 15 Une telle plateforme 10 peut être décrite comme comportant trois modules fonctionnels principaux, correspondant respectivement aux trois principaux blocs d'étapes 10-1, 10-2 et 10-3 dudit procédé PI de gestion 20 d'incidents d'un service, mis en oeuvre par l'unité de traitement 11 de ladite plateforme 10. Ainsi, un premier module fonctionnel ou un premier bloc d'étapes 10-1 est chargé de l'acquisition ou de la collecte et du traitement de données d'exploitation ou de 25 service DIS1, DISi, DISn, ainsi que de la détermination d'un référentiel d'un service, un tel premier module étant ci-après nommé « Operation monitoring services » selon une terminologie anglo-saxonne. Un deuxième module ou un deuxième bloc d'étapes 10-2 est chargé, quant à lui, de la 30 création des événements usagers et de la mise en forme de messages prêts à être diffusés, respectivement liés aux conséquences (routage, attente, etc.) pour les usagers du 11 service, ledit deuxième module étant ci-après dénommé « User information creation services » selon une terminologie anglo-saxonne. Un troisième module ou un troisième bloc d'étapes 10-3 est chargé de la diffusion 5 desdits messages à destination de supports de diffusion, ou de moyens de sortie 0D1, ODj, ..., 0Dm adaptés ou de moyens de communication idoines, ledit troisième module étant dénommé « User information broadcasting services » selon une terminologie anglo-saxonne. 10 Selon ladite figure 2, un tel procédé PI de gestion d'incidents d'un service comporte principalement : un bloc d'étapes 10-1 pour collecter des données DIS1, DISi, DISn, d'exploitation ou d'incident du 15 service considéré, lesdites données DIS1, DISi, DISn, étant produites par tout système 20 adapté coopérant avec ladite plateforme 10, ledit bloc d'étapes 10-1 consistant en outre à traduire, selon une ou plusieurs règles prédéterminées, 20 d'une ou plusieurs desdites données d'exploitation ou d'incident du service en un aléa AE, ce dernier étant créé ou mis à jour, si celui-ci est d'actualité ; un bloc d'étapes 10-2 pour déterminer, selon un 25 scénario prédéterminé, une ou plusieurs conséquences CU dans la délivrance du service auxdits usagers, à partir dudit aléa AE produit ou mis à jour au bloc d'étapes 10-1 et pour produire à partir de telles conséquences, un 30 événement E selon un ou plusieurs scénarii prédéterminés, un tel événement E se traduisant par une sélection d'un ou plusieurs moyens de 12 diffusion de messages, assortie d'une production d'un ou plusieurs messages d'information MU, formatés de manière prédéterminée selon le type de moyen de diffusion sélectionné ; 5 un bloc d'étapes 10-3 pour provoquer la diffusion du ou des messages d'information MU produits par, ou sur, ledit ou lesdits moyens de diffusion ou de sortie 0D1, ODj, ..., 0Dm sélectionnés pour restituer de manière sonore ou graphique des 10 messages MUl, MUj, ..., MUm aux usagers. Un tel bloc d'étapes 10-3 (ou plus précisément l'étape 600 en lien avec la figure 2) pour provoquer la diffusion peut avantageusement être adapté pour que ladite diffusion soit « orchestrée » selon un 15 protocole prédéterminé. Comme l'indique, de manière avantageuse, l'exemple d'un procédé PI selon l'invention illustrée par la figure 2, une étape 100, du premier bloc d'étapes 10-1, de 20 collecte 100 de données d'incident ou d'exploitation de service DIS1, DISi, DISn peut faire l'objet d'une procédure d'enregistrement desdites données dans la mémoire de données 12 de la plateforme 10. Une telle opération d'enregistrement peut notamment comporter un horodatage de 25 ladite collecte des données d'incidents ou d'exploitation du service. Un historique des opérations peut ainsi être constitué et consulté sur demande. En outre, lesdites données peuvent être respectivement associées à des périodes de validité données. Dans le cadre d'une 30 application de transport de passagers, une telle étape 100 peut par exemple consister à enregistrer des données 13 d'exploitation décrivant un tracé d'une ligne et/ou des points d'arrêt sur une telle ligne. Ladite étape 100 consiste, préalablement à une phase d'enregistrement de telles données d'incident ou 5 d'exploitation en mémoire de données, à décoder lesdites données d'incidents ou d'exploitation collectées et à les « normaliser » afin que celles-ci puissent être conjointement examinées ou traitées plus tard. Une telle étape de normalisation ou de formatage se traduit par une 10 fonction appelée couramment « connecteur » dans le jargon informatique. Ainsi, une plateforme selon l'invention dispose, par programmation, d'un modèle prédéterminé de toute donnée d'exploitation ou d'incident au regard d'un référentiel prédéterminé pour un service concerné. 15 Avantageusement, une telle plateforme 10 peut être agencée pour s'adapter à tout type de flux de données et/ou de technologies répondant à des modèles de communication de types requête/réponse, abonnement/notification ou traitement par lots (« batch » selon une terminologie 20 anglo-saxonne) comme par exemple, un « web service », une importation de fichier, une trame selon le protocole TCP (« Transmission Control Protocol » selon une terminologie anglo-saxonne, ou littéralement en français « protocole de contrôle de transmissions ») tel que décrit dans le 25 document RFC7931 de l'IETF (Internet Engineering Task Force » selon une terminologie anglo-saxonne). Une telle étape 100 peut avantageusement exploiter des normes de communication du domaine métier visé, par exemple dans le domaine du transport, SIRI (« Service Interface for Real 30 time Information », selon une terminologie anglo-saxonne, définissant un protocole d'échange d'informations en temps réel), NeTEx (Network Exchange selon une terminologie 14 anglo-saxonne, pour échanger des informations en lien avec le Transport selon un format de document de type XML - « Extensible Màrkup Language », selon une terminologie anglo-saxonne), GTFS (« General Transit Feed 5 Specification » selon une terminologie anglo-saxonne, spécifiant les flux relatifs aux transports en commun), pour faciliter une intégration avec des systèmes 20 fournisseurs de données DIS. Un tel bloc d'étapes 10-1 peut en outre comporter une 10 étape 200 de filtrage, c'est-à-dire de sélection desdites données DIS1, DISi, DISn, pour ne conserver qu'un sous- ensemble de données d'intérêt, voire encore pour regrouper et « prioriser » certaines données d'exploitation et/ou d'incident acquises. Une telle sélection peut être 15 paramétrée, voire personnalisée selon le service considéré, par exemple selon le réseau de transport urbain d'une ville particulière, par le chargement d'instructions de programme idoine venant enrichir le programme PG enregistré dans la mémoire de programmes 14. De la même 20 manière, l'étape 300, du premier bloc d'étapes 10-1, consiste à déterminer les impacts sur les usagers, induits par lesdites données sélectionnées DIS, sous la forme d'un aléa d'exploitation AE, éventuellement assorti d'une donnée caractérisant un niveau d'urgence ou de criticité. 25 Cette destination résulte de la mise en oeuvre d'instructions de programme d'ordinateur ou de règles, permettant de modéliser et de générer ledit aléa d'exploitation AE, si possible automatiquement à réception d'une donnée d'incident ou d'exploitation particulière 30 DIS. Le programme PG, et donc le procédé PI, peuvent donc éventuellement être enrichis ou modifiés selon le service concerné. 15 Par exemple, dans le domaine d'application préféré du transport de passagers, une stratégie d'aléa peut définir que si plusieurs actes de régulation « Courses supprimées » sont reçus d'un système d'aide à l'exploitation (en 5 l'espèce un type particulier de générateur de données d'exploitation du service) impactant un même itinéraire de ligne, sur une plage glissante de cinq minutes, alors il est possible de regrouper les aléas induits par lesdits actes de régulation sous la forme d'un seul aléa « Courses 10 supprimées » associé à une priorité faible. Selon l'exemple du procédé PI de gestion d'incidents d'un service conforme à l'invention, décrit notamment en lien avec la figure 2, celui-ci comporte un deuxième bloc 15 d'étapes 10-2 pour produire des messages MU à destination des usagers à partir du ou desdits aléas d'exploitation AE produits en 10-1. Ledit deuxième bloc d'étapes 10-2 consiste ainsi en une première étape 500 pour produire un ou plusieurs 20 évènements usagers E sous la forme de messages MU, élaborés selon un exemple décrit ultérieurement avec la figure 3, et prêts à être diffusés. Préalablement à l'étape 500, le procédé PI comporte une étape 400 pour, à partir d'alea(s) d'exploitation AE et à partir de scénarios d'événements 25 prédéterminés ou d'aléas types, éventuellement paramétrables et/ou personnalisables via des règles, sous la forme par exemple d'instructions de programme ou de scripts, mémorisées en mémoire de programmes 14, une ou plusieurs conséquences CU sont créées, chacune étant 30 associée à un message unitaire MUU constituant une partie ou une zone d'un tel message usager MU constitué à l'étape 500, lesdits messages MUU et MU étant éventuellement 16 formatés pour mettre en exergue telle ou telle chaîne de caractères, par exemple. L'invention prévoit en effet, que l'étape 500 s'appuie sur un ou plusieurs modèles de message, généralement 5 mémorisés soit en mémoire de données 12, soit en mémoire de programmes 14. Une sélection de modèles de message peut être mise en oeuvre à l'étape 500 selon la nature de l'événement E généré à l'étape 400. Ainsi, à titre d'exemple non limitatif, l'étape 500 peut générer un ou 10 plusieurs messages MU à partir d'un modèle de message prédéterminé contenant un texte, par exemple sous la forme de chaîne(s) de caractères alphanumériques, une mise en forme éventuelle, précisant une ou plusieurs couleurs desdits caractères, la ou les polices desdits caractères, 15 des accentuations de caractères, etc., une ou plusieurs conditions et/ou une ou plusieurs variables contextuelles, de telles conditions ou variables contextuelles consistant non limitativement en : un type de contenu pris en charge, selon un 20 langage de balisage par exemple tel que le langage HTML (« HyperText Markup Language », selon une terminologie anglo-saxonne), un simple texte, un contenu sonore et/ou visuels, etc. par un ou plusieurs moyens de diffusion ou de sortie 30 ; 25 une ou plusieurs langues prises en charge ; un nombre de lignes d'affichage sur un support ; un nombre maximal de caractères autorisés par ligne d'affichage ; une liste ou un type de caractères autorisés ou 30 interdits ; 17 - des caractéristiques déterminant un défilement éventuel dudit message MU lors de sa future diffusion ; - une prise en charge ou non de fichiers multimédias 5 éventuellement associés (formats vidéo, image, etc.). De manière avantageuse, l'invention prévoit qu'une plateforme 10 de gestion d'incidents de service, puisse comporter un composant ou une fonction de pré-affichage 10 pour qu'un opérateur de ladite plateforme 10 puisse effectuer des simulations d'affichage et/ou d'écoute de messages sur un ou plusieurs supports de diffusion ou de sortie 30, avant la diffusion réelle sur sites, de futurs messages MU survenant après un réel incident de service. 15 Le bloc étape 10-2 d'un procédé PI conforme à l'invention peut en outre être adapté (notamment l'étape 400), de sorte que la plateforme 10 présente alors, par la mise en oeuvre dudit procédé PI, un module fonctionnel que nous pourrions nommer « Situation policy engine » selon 20 une terminologie anglo-saxonne. Une telle adaptation permet à ladite plateforme 10, plus précisément à son unité de traitement 11, de sélectionner automatiquement, parmi une pluralité de scenarii possibles, un scénario d'événements le plus pertinent, selon le ou les aléas 25 d'exploitation AE produits précédemment. Ainsi, il devient possible de grouper plusieurs événements autour d'une même cause, en l'espèce un aléa d'exploitation pour les usagers, et de déterminer si une diffusion de messages d'information MU automatique est requise ou non. De la même manière, une 30 telle étape 400 peut être agencée pour déterminer une ou plusieurs conséquences usager CU, corollaires aux impacts 18 directement induits par un aléa d'exploitation AE produit par le premier bloc d'étapes 10-1. Également, l'invention prévoit en outre que l'étape 500 du deuxième bloc d'étapes 10-2 puisse déterminer un ou 5 plusieurs moyensn supports ou media de diffusion ou de sortie OD1, 0Dm, parmi la pluralité de media 30 disponibles, et/ou un ou plusieurs lieux ou périmètres géographiques de diffusion de messages MU selon l'aléa ou le type d'aléa d'exploitation AE produit en 10-1. Ainsi, 10 les messages MU associés à un événement E peuvent être formatés en conséquence, comme nous l'étudierons ultérieurement en lien avec un exemple de modélisation de message illustré par la figure 3. Lorsqu'une pluralité de messages est affectée à un 15 événement E ou qu'une pluralité d'événements sont produits à l'étape 400, cette dernière, voire l'étape 500, peut comporter une phase d'analyse de la validité des messages prêts à être diffusés en termes de format et de fonds au regard de messages usager MU, d'ores et déjà en cours de 20 diffusion et de restitutions sonore et/ou graphique. Le troisième module fonctionnel offert par une plateforme 10 conforme à l'invention, par la mise en oeuvre du bloc d'étapes 10-3, en l'espèce l'étape 600, du procédé 25 PI illustré à titre d'exemple non limitatif par la figure 2, est chargé de maîtriser la diffusion et la restitution ou sortie sonore et/ou graphique de messages MU produits par le bloc d'étapes 10-2 précédemment décrit, par les moyens ou media de restitution ou de sortie OD1, ODj, ..., 30 0Dm parmi la pluralité des moyens de sortie 30 disponibles. Cette fonction se traduit tout d'abord par une orchestration de la restitution ou sortie sonore et/ou 19 graphique des messages MU - on entend par « orchestration » une synchronisation, un séquençage, une ou plusieurs durées de restitution, un bouclage, etc. desdits messages MU. Une telle restitution ou sortie de messages MU sous- 5 entend également une fonction de type « connecteur », miroir de celle offerte par l'étape 100 permettant de « connecter » la plateforme 10 aux générateurs de données d'exploitation et d'incidents 20. Cette deuxième fonction « connecteur » permet de lier ladite plateforme 10 aux 10 moyens ou media de diffusion 30. Ainsi, l'étape 600 consiste en outre à encoder les messages MU pour adapter ces dernier automatiquement à tout type de flux ou à toute technologie, répondant par exemple aux modèles de communication de types requête/réponse, 15 abonnement/notification ou « batch », dotant ainsi une plateforme 10 de gestion d'incidents de service conforme à l'invention d'un connecteur fonctionnel conforme aux normes de communication du domaine métier visé, par exemple dans le domaine du transport de passagers, SIRI ou GTFS. 20 Selon ledit exemple d'application préféré en lien avec le transport de passagers, la figure 3 décrit un exemple de structure de données produites à l'étape 400 et associées à une événement E conduisant au formatage 25 prédéterminé d'un message MU selon l'invention. Ladite figure 3 illustre qu'un événement E est associé à une ou plusieurs conséquences CUR, CUI, CU2, CU3, CUL, ces dernières pouvant se dérouler en une ou plusieurs phases PHx, parmi lesquelles une phase initiale, une phase 30 courante lors de l'occurrence dudit événement, et une phase de clôture ou de fin d'occurrence lors du terme dudit événement E. 20 Chaque phase PHx est associée à une sélection d'un ou plusieurs moyens 30 de diffusion ou de sortie de message, un périmètre d'impact, d'un ou plusieurs messages unitaires, préalablement formatés selon le ou les type(s) 5 de moyens de diffusion sélectionnés. Un message MU peut, à l'instar de la description de l'exemple illustré par la figure 3, être associé à la conséquence récapitulative CUR et comporter un texte, mais également une ou plusieurs conditions et autres variables contextuelles. Il peut en 10 outre, tel un message « enveloppe », comporter une ou plusieurs zones de texte, en l'espèce sur la figure 3, les zones Z1 à Zw, chaque zone pouvant comporter une ou plusieurs plages de texte TXT et/ou un ou plusieurs messages unitaires MUU-CU1, MUU-CU2, MUU-CU3, MUU-CUz 15 respectivement associés aux conséquences CUI, CU2, CU3, Cliz de l'événement E. Pour illustrer la mise en oeuvre d'une plateforme de gestion d'incidents de service, telle que la plateforme 10 20 décrite en lien avec la figure 1 et mettant en oeuvre un procédé de gestion des incidents d'un service conforme à l'invention, tel que le procédé PI illustré par la figure 2, étudions un exemple d'application en lien avec le transport de passagers dans la ville de Marseille, France, 25 en liaison avec les figures 4A à 4D. Un tel exemple découlant de la mise en oeuvre par une plateforme 10 d'un procédé PI conformes à l'invention et respectivement illustrés par les figures 1 et 2, vise à diffuser, par un medium de restitution ou de sortie 30 graphique du type navigateur de page Internet, disponible sur tout ordinateur personnel connecté à Internet, un message MU destiné aux usagers des transports publics de 21 la ville de Marseille, lié à un événement E découlant d'un incident de personne survenu sur le Boulevard Chave. Ledit exemple illustre le fait que le contenu du message MU évolue au gré de l'évolution de la situation ou 5 configuration du réseau de transport concerné. Les figures 4A à 4D décrivent ainsi respectivement quatre moments ou phases distincts et successifs, durant lesquels une information destinée aux usagers est produite, et dont la diffusion par Internet a été provoquée par la mise en oeuvre 10 dudit procédé PI par une plateforme 10, lesdits plateforme 10 et procédé PI étant conformes à la présente invention. En liaison avec la figure 4A, un incident dit « boulevard Chave » se produit. Un service partiel sur la 15 ligne de tramway Tl est saisi par l'exploitant délivrant une donnée d'incident ou d'exploitation DIS1. Une première étape génère un événement E découlant dudit incident et dont la structure est telle que celle décrite par la figure 3 à titre d'exemple non limitatif. Ledit événement E et la 20 teneur d'un message MU automatiquement produit, dès l'apparition dudit événement E, par ledit procédé sont décrits en lien avec la figure 4A. Un premier message récapitulatif MU, associée à la phase courante, référencée PH1 en figure 4A, de la conséquence récapitulative CUR va 25 être élaboré puis diffusé et restitué graphiquement sur tout ordinateur connecté à Internet, voire sur des bornes d'informations voyageurs éventuellement connectées à Internet. Ledit message récapitulatif MU destiné aux usagers est constitué par trois zones Zl, Z2 et Z3. La 30 première zone Zl comporte une zone de texte 1X11, sous la forme d'une chaîne de caractères alphanumériques, mentionnant « Aujourd'hui, ligne Tl : accident de personne 22 - Boulevard Chave. Cet incident nous oblige à modifier l'itinéraire de la ligne comme suit : ». Une deuxième zone Z2 dudit message récapitulatif MU consiste en le message unitaire MUU-CUl associée à la phase en cours, PH1 en 5 figure 4A, de la conséquence CUI. Ledit message unitaire MUU-CUl comporte une zone de texte mentionnant « Interruption entre les stations Noailles et Eugène Pierre. Trois stations desservies : Camas, George, Jean Martin ». Enfin, une troisième zone Z3 composant le message 10 récapitulatif MU consiste en une zone de texte TXT3 précisant : « Veuillez nous excuser pour la gêne occasionnée ». La teneur globale d'un message MU prêt à être restitué à tout usager est donc : 15 « Aujourd'hui, ligne Tl : accident de personne - Boulevard Chave. Cet incident nous oblige à modifier l'itinéraire de la ligne comme suit : Interruption entre les stations Noailles et Eugène Pierre. Trois stations desservies : Camas, George, 20 Jean Martin. Veuillez nous excuser pour la gêne occasionnée ». Quelques minutes plus tard, une opportunité de contournement, illustrée en lien avec la figure 4B, est 25 identifiée par l'exploitant du réseau de transport de passagers de la ville de Marseille. En effet, une déviation sur la ligne de bus 72 est saisie par l'exploitant et génère une nouvelle donnée d'exploitation du service DIS2. Une nouvelle conséquence CU2 est alors produite en lien 30 avec ladite ligne de bus 72 en complément de la première conséquence CUI associée à la ligne de tramway Tl, à l'instar de la situation décrite par la figure 4A. 23 La plateforme 10 selon l'invention prend en considération cette alternative et génère automatiquement la situation illustrée par la figure 4B. Ainsi, un tel événement E se décline en deux 5 conséquences distinctes CUI et CU2 sur des éléments du réseau de transport différents. Lesdites conséquences peuvent être associées à une conséquence récapitulative CUR. Les trois conséquences CUR, CUI et CU2 peuvent ainsi générer trois messages, respectivement un message 10 récapitulatif MU pour la conséquence CUR et des messages unitaires MUU-CUl et MUU-CU2, pour les deux autres. Un tel message récapitulatif MU est formaté pour être restitué graphiquement par un navigateur internet. Comme l'indique la figure 4B, ledit message récapitulatif MU, associée à 15 la phase courante PH1 de la conséquence récapitulative CUR, est constitué de quatre zones Zl à Z4. Lesdites zones Zl et Z4 du message récapitulatif selon la figure 4B sont identiques respectivement aux zones Zl et Z3 du message MU en lien avec la figure 4A. La deuxième zone Z2 du message 20 récapitulatif selon la figure 4B consiste en le message unitaire MUU-CUl associé à la phase en cours PH1 de la conséquence CUI. Ledit message unitaire MUU-CUl précise un texte identique à celui-ci exprimé en lien avec les message unitaire MUU-CUl de la figure 4A. En revanche, ledit 25 message récapitulatif comporte une zone supplémentaire, la zone Z3, pour mentionner la teneur du message unitaire MUU-CU2 associé à la phase en-cours PH1 de la conséquence CU2 en lien avec la ligne de bus 72. Ledit message unitaire MUU-CU2 précise alors « Bus 72 : Déviation en direction du 30 terminus Métro Rond Point du Prado par rue George. Arrêt non desservi : Sakakini Chave ». 24 Ledit message récapitulatif MU selon la figure 4B mentionne donc une information destinée aux usagers telle que : « Aujourd'hui, ligne Tl : accident de personne - 5 Boulevard Chave. Cet incident nous oblige à modifier l'itinéraire de la ligne comme suit : Interruption entre les stations Noailles et Eugène Pierre. Trois stations desservies : Camas, George, Jean Martin. 10 Bus 72 : Déviation en direction du terminus Métro Rond Point du Prado par rue George. Arrêt non desservi : Sakakini Chave. Veuillez nous excuser pour la gêne occasionnée ». 15 Quelques minutes plus tard, la perturbation évolue, comme illustré par la figure 4C. Un retour progressif à un niveau de service normal s'amorce. La déviation sur la ligne de bus 72 est terminée. La conséquence CU2 est alors concernée par la phase de fin PH2. De nouvelles données 20 d'exploitation DIS3 ont été collectées et une nouvelle itération dudit procédé PI permet de générer un nouveau message récapitulatif MU. Ce nouveau message MU informe les usagers qu'une modification des itinéraires des lignes est possible. 25 Lesdits usagers ont alors une parfaite connaissance des conséquences et peuvent ainsi réagir à la perturbation courante. Nous pouvons constater, en lien avec la figure 4C, que l'une des deux conséquences CU2 découlant de l'incident, c'est-à-dire en l'espèce, l'impact sur la 30 ligne de bus 72 est en passe de se résorber. Une information en lien avec le retour à la normale de ladite ligne 72 peut ainsi être propagée. Un message unitaire 25 MUU-CU2 associé à la phase de fin PH2 de ladite conséquence CU2 est à présent intégré dans le message récapitulatif MU en lieu et place du message unitaire MUU-CU2 associé à la phase courante illustrée par la figure 4B. 5 Quelques minutes plus tard, la perturbation évolue davantage. La ligne de tramway Tl recouvre elle-aussi un fonctionnement normal. Globalement, le réseau de transport recouvre donc un service normal. Un message récapitulatif 10 MU associé à la phase de fin PH2 de la conséquence récapitulative CUR est alors produit, puis diffusé, comme l'indique la figure 4D. Un tel message MU ne comporte qu'une zone Zl comportant un champ de texte TXT mentionnant « Aujourd'hui, lignes Tl et 72 : accident de personne 15 Boulevard Chave - fin de perturbation ». Grâce à l'invention, les usagers ont pu suivre l'évolution de la perturbation du service de transport. Informés en temps réel des impacts sur le réseau de 20 transport, des opportunités de contournement d'une perturbation de service, puis de la fin de ladite perturbation, les usagers peuvent s'organiser REVENDICATIONS1. Procédé (PI) de gestion d'incidents d'un service, ledit procédé (PI) étant mis en oeuvre par une unité de traitement (11) d'une plateforme de gestion d'incidents de service (10) comportant outre ladite unité de traitement (11), une mémoire de données (12), des moyens de communication (13,15) avec le monde extérieur, ladite mémoire de données (12) et lesdits moyens de communication (13,15) coopérant avec ladite unité de traitement (11), ledit procédé (PI) étant caractérisé en ce que : - les moyens de communication (13) de ladite plateforme (10) assurent une première liaison (Ni) avec un générateur (20, IG1, IGi, IGn) de données d'incidents ou d'exploitation du service (DIS1, DISi, DISn) et une deuxième liaison (N2) avec un moyen de sortie (30, OD1, ODj, 0Dm) d'un message d'information (MU, MUl, MUj, MUm) ; - ledit procédé (PI) comporte : - une étape (100, 10-1) pour collecter une donnée d'incident ou d'exploitation du service (DIS1, DISi, DISn) émise par le générateur de données d'incidents ou d'exploitation du service (20, IG1, IGi, IGn) ; - une étape (300, 400, 10-2) pour estimer une ou plusieurs conséquences (CUI, CUz) d'un aléa d'exploitation (AE) du service et 27 produire un ou plusieurs messages d'information unitaires (MUU-CU1, MUUCUz) associées à ces dernières ; - une étape (500, 10-2) pour produire un 5 message d'information (MU) à partir desdits un ou plusieurs messages d'information unitaires (MUU-CU1, MUU-CUz) ; - une étape (600, 10-3) pour provoquer une sortie dudit message d'information (MU) par 10 le moyen de sortie (30, 0D1, ODj, 0Dm) de sorte qu'un usager dudit service perçoive la teneur dudit message d'information (MU, MUl, MUj, MUm). 15 2. Produit programme d'ordinateur (PG) comportant des instructions de programme qui, lorsqu'elles sont exécutées ou interprétées par un ordinateur (10), provoquent la mise en oeuvre d'un procédé (PI) de gestion d'incidents d'un service selon la 20 revendication précédente. 3. Plateforme (10) de gestion d'incidents de service comportant une unité de traitement (11), une mémoire de données (12), une mémoire de programmes 25 (14), des moyens de communication (13, 15) avec le monde extérieur, lesdites mémoires de données et de programmes (12, 14) et lesdits moyens de communication (13, 15) coopérant avec ladite unité de traitement (11), ladite plateforme de gestion d'incidents d'un service (10) étant caractérisée en 28 ce qu'elle comporte dans la mémoire de programmes (14), les instructions d'un produit programme d'ordinateur (PG) selon la revendication précédente. 5 4 Système de gestion d'incidents d'un service comportant un ou plusieurs générateurs (20, IG1, IGi, IGn) de données d'incidents ou d'exploitation dudit service (DIS1, DISi, DISn), un ou plusieurs 10 moyens de sortie (30, 0D1, ODj, 0Dm) d'un message d'information (MU, MUl, MUj, MUm), lesdits générateurs et moyens de sortie coopérant (Ni, N2) avec une plateforme (10) de gestion d'incidents de service conforme à la revendication précédente.