FR 2831691 A1 20030502 FR 0113924 A 20011026 "Système et procédé de gestion de flux de données événementielles" La présente invention est relative à un système et un procédé de gestion de flux de données en vue d'élaborer un ensemble d'actions prédéterminées pour le suivi d'une prestation en cours. Elle trouve une application particulièrement intéressante dans le domaine logistique de transport et de livraison d'objets. Mais l'invention est d'un cadre plus large puisqu'elle peut s'appliquer aux entreprises de tout secteur d'activité et de toutes tailles qui traitent des opérations complexes générant des flux de données et nécessitant des actions de suivi actif ou passif. On peut notamment citer les domaines de réalisation de prestations de service, du suivi d'actions en marketing de masse, du crédit/recouvrement, de gestion des impayés, etc. Les entreprises disposent de plus en plus de moyens pour communiquer en interne et avec leurs partenaires, clients, fournisseurs, tiers. Cependant, dans le flot d'informations, de plus en plus volumineux, reçues et émises par une entité il est difficile de traiter les données de manière qualitative, en fonction de la nature du message qu'elles transportent. De plus, l'action d'acheminer de manière pertinente une information qualifiée à un décideur ou à un exécutant à même de l'exploiter est souvent mal maîtrisée. La présente invention a pour but de proposer un nouvel outil apte à fournir à tout utilisateur les moyens d'opérer une analyse systématique, automatique et personnalisée de flux d'information. L'invention a aussi pour but d'extraire de l'information pertinente afin d'en déduire et générer des actions de communication vers des destinataires prédéterminés au moyen de divers média de communication. On atteint les objectifs précités avec un système de gestion de flux de données en vue d'élaborer un ensemble d'actions prédéterminées pour le suivi d'une prestation. Selon l'invention, ce système comprend au moins : un serveur de communication pour recevoir et formater des données d'exploitation en provenance d'au moins une source de données, et pour diffuser les actions prédéterminées vers des destinataires donnés, - un serveur de base de données pour stocker des données de configuration et les données d'exploitation, et pour exécuter un moteur de décision qui interprète les données d'exploitation, vérifie si ces données d'exploitation remplissent des conditions comprises dans les données de configuration et élabore les actions prédéterminées le cas échéant, et un serveur d'administration pour gérer les données de configuration, la communication entre le serveur d'administration et le serveur de base de données étant une communication client-serveur. Le serveur de base de données peut exécuter un système de gestion de bases de données relationnelles (SGBD/R). Le serveur d'administration peut être un serveur d'applications web. Par prestation, on entend l'objet du suivi réalisé par le système selon l'invention. La prestation est initiée, c'est-àdire créée dans un état initial, puis les différents états représentant les étapes de sa réalisation sont acquis par le système selon l'invention. Une prestation est caractérisée par des moyens d'identification et de qualification comprenant : des informations d'identification, telles un code ou une clé permettant de faire référence de manière univoque à la prestation ; pour une livraison par exemple : le numéro de pistage (tracking) transporteur ou le numéro de bon de livraison, et des informations de qualification constituées par l'ensemble des informations permettant de décrire la prestation ; pour une livraison par exemple : le nom du destinataire, le poids du colis, la date d'expédition, etc. Un statut représente un état de la prestation au cours du temps. Les statuts sont transmis par l'auteur de la prestation. Le serveur de communication a donc un premier rôle d'acquisition des données d'exploitation. Ces données d'exploitation sont l'ensemble des informations fournies par l'auteur de la prestation, c'est-à-dire tout ou partie des moyens d'identification et de qualification de la prestation, ainsi que le statut de cette prestation. Le serveur de communication assure l'intégration des données de statuts au fur et à mesure de leur arrivée. Les principales fonctions du serveur de communication, dans son mode d'acquisition, sont donc les suivantes : - acquisition des données d'exploitation selon différents modes de communication (ftp ("File Transfer Protocol"), web, EDI ("Electronic Data Interchange"), e-mail,...) - traduction des données reçues sous une forme standard et prédéfinie qui constitue l'interface du moteur de décision, - mise des données reçues à disposition du moteur de décision, et - déclenchement dans le moteur de décision d'un processus d'intégration de données. Le serveur de gestion comprend des moyens logiciels intégrant plusieurs normes d'acquisition pour pouvoir interpréter des statuts exprimés selon différentes normes. Une norme d'acquisition représente le formalisme utilisé pour lire les statuts en provenance de l'auteur de la prestation. On peut principalement citer les normes EDI ou les standards XML ("Extensible Markup Language") décrits par des définitions de types de documents (DTD) standards ou spécifiques. D'une façon générale, le moteur de décision, actif dans le serveur de base de données, contient une logique métier d'interprétation des données reçues. Selon un mode de mise en oeuvre avantageux de l'invention, ce moteur de décision comprend des moyens pour : - répertorier l'ensemble des états possibles liés à une prestation, - regrouper ces états possibles en plusieurs sous-groupes selon une fonction subjective, chaque sous-groupe symbolisant un événement. De préférence, ce regroupement en événements est défini en fonction de critères transmis par l'auteur de la prestation. Avec un tel système selon l'invention, pour une prestation donnée, on a partitionné l'ensemble des états possibles. Chaque état est contenu dans une partition donnée. Par conséquent, le système est configuré de façon à exprimer la vision de l'auteur de la prestation. Les états peuvent donc être regroupés selon la volonté de l'auteur. Chaque donnée d'exploitation peut comprendre au moins une information sur un état possible de la prestation, c'est-à-dire son statut, et sur des moyens d'identification et de qualification de la prestation (information d'identification et information de qualification). Le moteur de décision a notamment pour rôle d'extraire des données d'exploitation le statut de la prestation en cours, normaliser ce statut en l'identifiant à un statut interne prédéfini, et déterminer à quel sous-groupe ou événement prédéfini par la partition ce statut appartient. Une fois l'événement identifié, on considère les règles susceptibles de s'appliquer sur cet évènement, puis on vérifie si les conditions de chaque règle considérée sont respectées. L'invention est remarquable par le fait que la disposition en plusieurs événements facilite l'application des règles sur ces événements. En effet le moteur de décision n'est pas obligé d'explorer l'ensemble des états possibles pour vérifier les règles, il est aiguillé vers des sous-groupes prédéfinis correspondant à des critères spécifiques à chaque auteur de prestation, ceci représentant un gain de clarté pour l'utilisateur. Le regroupement en événement représente la vision de l'auteur sur la gestion de la prestation. Les statuts internes sont un ensemble de statuts compréhensibles par l'ensemble des normes gérées par le moteur de décision. Afin d'être manipulés et gérés de manière uniforme, les statuts reçus en fonction d'une norme sont traduits en statuts internes. A chaque statut dans une norme, correspond un statut interne. Des statuts appartenant à des normes différentes peuvent être associés à un même statut interne, si la situation qu'ils représentent est similaire. Le moteur de décision comprend un gestionnaire de règles qui peut fonctionner selon un formalisme de type ECA ("Event Condition Action", en langue anglaise) défini pour des serveurs de données actifs. Au sens de ce formalisme, que l'on peut notamment retrouver dans Active Database Systems : Triggers and Rules for Advanced Database Processing > > , de Jennifer Widom et Stefano Ceri, Edition Morgan Kaufmann 1996, ISBN 1-55860-304- 2, dans le cas du système selon l'invention, tous les événements sont abstraits et les modes de couplage immédiats. L'implémentation de règles est semi-procédurale. Les règles portent sur des conditions appliquées aux moyens d'identification et de qualification de la prestation et aux événements. Les conditions peuvent être de formes diverses, en fonction de la typologie des données. Des conditions portant sur des données distinctes peuvent être combinées au moyen d'opérateurs logiques"ET"et OU". Une règle peut être qualifiée de niveau : - "zéro" lorsqu'elle porte sur les moyens d'identification et de qualification de la prestation et sur l'absence d'information sur un état possible (ou statut) de la prestation ; les règles de niveau "zéro" permettent d'interpréter l'absence d'information comme étant un élément de décision ; -"un" lorsqu'elle porte sur les moyens d'identification et de qualification de la prestation et sur un événement donné (notamment le dernier activé) regroupant un ensemble d'états possibles de la prestation ; -"deux" lorsqu'elle porte sur les moyens d'identification et de qualification de la prestation et sur l'ensemble d'événements associés à la prestation ; -"trois" lorsqu'elle porte les moyens d'identification et de qualification d'une pluralité de prestations et sur l'ensemble d'événements de la pluralité de prestations. Une règle peut être activée selon plusieurs modes : - inactive : pas d'examen des conditions ; - active : examen des conditions, enregistrement d'un historique de la règle, création des actions et diffusion des messages associés ; - veille (ou sommeil) : examen des conditions, enregistrement d'un historique, mais pas de création des actions ni diffusion de messages. Ce mode est utile pour des tests et à des fins statistiques. Pour chaque règle, les prestations ayant vérifié les conditions sont conservées. L'historique d'invocation des règles permet d'effectuer des analyses globales ou statistiques sur la qualité de la prestation Les actions associées aux règles sont des actions de diffusion d'information, vers un destinataire et selon un média déterminé dans la règle. Le message envoyé est un message type qui peut être enrichi de données provenant des données d'exploitation ou générées par le moteur de décision. En d'autres termes, une action consiste en la création d'un message décrivant la situation pour permettre au destinataire de l'interpréter et d'agir en conséquence. Le message envoyé est une phrase-type à laquelle peuvent s'ajouter des données contextuelles, provenant de la prestation et du statut à l'origine de l'événement ayant déclenché l'application de la règle. Les données contextuelles sont référencées dans le message par la description des champs de données à extraire pour construire le message, c'est-à-dire lorsque la prestation est la livraison d'un colis par exemple, le message peut être une phrase type dans laquelle l'heure de livraison est une donnée contextuelle non prédéterminée. Il est de plus possible d'associer une pièce jointe à un message, par exemple un fichier électronique pour un envoi de message par e-mail. Pour éviter la redondance de messages, on peut avantageusement hiérarchiser les règles pour un ensemble de prestations. Une redondance de message peut par exemple subvenir lorsque plusieurs règles sont invoquées et vérifiées pour la même prestation et le même événement. Le moteur de décision se comporte comme un module autonome à qui on présente les données d'entrée (fichiers de statuts), et qui délivre en sortie un fichier des actions à exécuter. Le format du fichier d'entrée doit correspondre à une norme gérée par le système. Le format du fichier de sortie comprend le type d'action, le canal à utiliser, les coordonnées destinataire sur le canal en question, le texte du message à envoyer, et un lien sur une éventuelle pièce jointe. En fonction de ce fichier, un module de diffusion crée les messages et les envoie. Ce module de diffusion peut être intégré dans le serveur de communication. Selon une caractéristique de l'invention, le module de diffusion gère au moins les modes de communication suivants : - e-mail : envoi d'un message à l'adresse de messagerie électronique fournie par le paramétrage de la règle. Le contenu est construit en fonction des données correspondant à la prestation et à l'événement constaté. SMS : envoi du message sur un téléphone mobile, au numéro fourni par le paramétrage de la règle, selon le protocole SMS (Short Message Service). - transfert de fichier : envoi d'un fichier sur une ressource identifiée par son URL. La ressource peut être locale (LAN), distante (ftp) ou accessible par EDI. Dans ce dernier cas, le message est posté dans une boîte aux lettres d'envoi de station EDI. - synthèse vocale : une communication téléphonique est établie avec le numéro fourni par le paramétrage de la règle, et le message est lu au destinataire par un utilitaire de synthèse vocale. L'ensemble du système selon l'invention est gérable au moyen du serveur d'administration qui comprend des moyens de paramétrage d'un utilisateur, de la nature et format des données traitées, des règles et conditions, et des actions associées. Ce serveur d'administration comprend également des moyens de suivi des statistiques sur les actions générées, des rapports, et de la visualisation des données. On peut ainsi par exemple effectuer des requêtes multicritères sur la base de données. Ce serveur d'administration présente un ensemble d'interfaces telles que par exemple une interface permettant de réaliser des requêtes multicritères sur la base de données. L'utilisateur spécifie des conditions de recherche, les données à extraire et le mode de transmission des résultats (affichage à l'écran ou enregistrement dans un fichier). Les requêtes peuvent être enregistrées pour une utilisation ultérieure. Les requêtes enregistrées peuvent utiliser des paramètres dynamiques ou résultats de fonctions exécutées lors du lancement de la requête. Suivant un autre aspect de l'invention, il est proposé un procédé de gestion de flux de données en vue d'élaborer un ensemble d'actions prédéterminées pour le suivi d'une prestation en cours. Selon l'invention, ce procédé comprend les étapes suivantes : - acquisition de données d'exploitation en provenance d'au moins une source donnée, - interprétation des données d'exploitations reçues, - application d'un ensemble de règles sur lesdites données d'exploitations, - élaboration d'un message lorsqu'une règle est respectée, et - transmission du message vers un destinataire. De préférence, l'étape d'acquisition fait intervenir les étapes suivantes : - acquisition de données d'exploitation selon différents modes de communication, et - conversion desdites données d'exploitation sous un format standard prédéterminé. A titre d'exemple, l'étape d'interprétation peut faire intervenir les étapes suivantes : - identification de la source et du format des données d'exploitation, - transfert dans une table de base de données adaptée au format identifié, - détermination de nouvelles prestations devant être initialisées en fonction desdites données d'exploitation, en fait il s'agit de distinguer, parmi les données reçues, celles qui concernent des prestations déjà connues du système de celles qui concernent de nouvelles prestations, - détermination des prestations déjà existantes pour lesquelles les données reçues constituent un nouvel état, - détermination au sein des données d'exploitation d'un état possible relatif à ladite prestation, - traduction dudit état possible en un état possible prédéfini, - identification de l'état possible ainsi traduit au sein d'un événement, un événement étant un sous-groupe composé de plusieurs états possibles et obtenu à la suite d'une partition de l'ensemble des états possibles prédéfinis, cette partition étant définie en fonction de critères transmis par l'auteur de ladite prestation. Selon un mode de mise en oeuvre préféré de l'invention, les étapes d'application des règles et d'élaboration de message font intervenir les étapes suivantes : sélection des règles à examiner en fonction de leur état d'activité et de la source des données d'exploitation ; extraction, à partir des données d'exploitation, d'informations supplémentaires relatives à ladite prestation et de l'événement comprenant l'état identifié en fonction d'un ensemble de conditions composant les règles ; création de messages en fonction de phrases-types et de données contextuelles ; enregistrement de l'historique des règles invoquées, extraction des modes de diffusion pour les destinataires des messages ; et - constitution d'un fichier de messages. D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après. Aux dessins annexés donnés à titre d'exemples non limitatifs : La figure 1 est une vue synoptique de la disposition des éléments du système selon l'invention. La figure 2 illustre un ensemble de données comprises dans un fichier transmises vers le module d'acquisition du système selon l'invention. La figure 3 est une vue schématique illustrant deux regroupements différents en profil métier à partir d'un ensemble d'états possibles. La figure 4 est une vue d'une fenêtre d'interfaçage illustrant la définition d'une règle. Bien que l'invention n'y soit pas limitée, on va maintenant décrire un système de gestion de flux de données selon l'invention appliqué à une prestation de livraison. En référence à la figure 1, on distingue un serveur 1 d'administration, un serveur de communication 2 et un serveur de base de données 5. Ce serveur d'administration est le point d'entrée pour un utilisateur gérant le système selon l'invention. Il présente deux fonctions principales : - paramétrage du système selon l'invention : paramétrages des autorisations pour plusieurs utilisateurs, natures et formats des données traitées, définitions des règles (conditions et actions) et paramétrage des profils métier ; - suivi : statistiques sur les actions générées, rapports, consultations des données de la base. Le serveur de communications 2 comprend principalement deux modules. Un premier module d'acquisition 3 capable de réceptionner des messages ou fichiers provenant de diverses sources 9,10 et 11, de les formater de façon à être convenablement transmis vers le serveur de base de données et acceptés par ce dernier. Ce module d'acquisition 3 permet d'acquérir des données selon différents modes de communication tels que : FTP, WEB, EDI, E-MAIL, ou autres moyens d'échanges d'informations, en mode tiré ou poussé. Les données traitées par le module d'acquisition 3 sont ensuite recueillies par le moteur de décision 6 du serveur de base de données 5. L'ensemble des données ainsi recueillies est ensuite stocké dans une base de données 7, elle constitue alors les données opérationnelles. Le serveur de base de données 5 comprend également des données pour le paramétrage des règles et des événements. Les règles et les événements sont des données permettant au moteur de décision 6 d'intégrer et d'interpréter les données opérationnelles 7. Le traitement effectué par le moteur de décision 6 sur les données opérationnelles 7 et les données de paramétrage 8 résulte en un fichier transmis vers un module de diffusion 4 présent dans le serveur de communication 2. Ce module de diffusion 4 est chargé de l'acheminement des messages d'informations vers des destinataires 13,14 et 15, selon différents modes de communication tels que par exemple : messages électroniques, mini-messages de téléphonie mobile, transferts de fichiers par réseau local étendu ou Internet (FTP), ou EDI, synthèse vocale (lecture du message après établissement d'une communication téléphonique). Dans le cas d'espèce, le transporteur 9, chargé de livrer un colis à un destinataire, transmet de façon événementielle des informations sur le statut ou l'état en cours d'une prestation de livraison qu'il est en train de réaliser. Le système selon l'invention réceptionne ces informations via le module d'acquisition 3 qui les traduit dans un format interne. Le moteur de décision 6 réceptionne à son tour ces informations formatées, extrait le statut de la prestation afin de l'identifier au sein d'un événement prédéterminé. Sur la figure 2 est représenté un ensemble 16 des informations transmises vers le module d'acquisition 3. Cet ensemble 16 comprend deux parties. Une première partie 17 intitulée"en-tête", comprend des informations sur le type de la prestation réalisée c'est à dire une livraison. L'en-tête 17 comprend également des informations d'identification telles un "code expéditeur"correspondant à un numéro de livraison dans le système de gestion de l'expéditeur, un"code transporteur" correspondant à un numéro de colis dans le système de traçabilité du transporteur 9 et un"code destinataire" correspondant à un numéro de commande dans le système de gestion du destinataire. L'en-tête 17 comprend encore des informations qualifiantes décrivant la prestation réalisée. Ces informations qualifiantes comprennent la date d'expédition du colis, les coordonnées du destinataire, le niveau de service souhaité par exemple prioritaire, le poids du colis transporté. La principale information transmise par le transporteur 9 est le statut 18. Ce statut représente l'état en cours de la livraison et elle comprend l'information "dévoyé", c'est-à-dire que le colis est égaré. Le fichier 16, après être correctement formaté par le module d'acquisition 13, et réceptionné par le moteur de décision 6. Ce moteur va alors identifier ce statut à un statut interne prédéterminé et classé dans un événement. La figure 3 permet de définir ce que sont les événements. On distingue en 19 l'ensemble des états possibles pour cette prestation de livraison. Ces états sont préalablement introduits dans la base de données 8 en concertation avec le transporteur 9. Avantageusement, le système selon l'invention peut également faire intervenir non seulement le transporteur 9 mais également l'expéditeur du colis ainsi que le destinataire. Ces acteurs peuvent intervenir aussi bien au niveau de la source pour transmettre des informations qu'au niveau destinataire vers qui des messages élaborés par le système selon l'invention sont transmis. L'invention est remarquable par le fait qu'à partir de l'ensemble des états possibles de la prestation, on élabore en fonction des critères établis en concertation avec l'expéditeur du colis et le transporteur, un profil métier 20 représentant une partition de cet ensemble des états possibles 19. Pour le transporteur 9, son profil métier 20 comprend quatre événements : "en cours","livré","sinistre", et"problème". Ces états possibles sont en fait des statuts internes prédéfinis. Chaque état possible est rangé dans un événement. Il ne peut y avoir deux événements d'un même profil métier comportant un même état possible. Ainsi l'événement cours"comprend les états suivants : collecté ; entrée agence ; trié ; et mise à jour. L'événement "livré" comporte uniquement l'état possible : livré. L'événement"sinistre"comprend les états possibles suivants : avarie ; dévoyé. L'événement"problème"comporte les états possibles suivants : erreur adresse ; et destinataire absent. Ce découpage est spécifiquement réalisé pour le transporteur 9. A titre d'exemple, un autre profil métier peut être tel que celui représenté en 21. Ce profil métier comprend 3 événements. Un événement"remboursement"comportant les états suivants : avarie, et dévoyé. Un événement"correction"comportant les états suivants : erreur adresse, et destinataire absent. Un événement "normal"comportant les états suivants : collecté, entrée agence, trié, mise à jour, et livré. Profil métier du transporteur 9 : remboursement (avarie, dévoyé), correction (erreur adresse, destinataire absent), normal (collecté, entrée agence, trié, livré). Un autre profil métier possible : sinistre (avarie, dévoyé), problème (erreur adresse, destinataire absent), livré (livré), en cours (collecté, trié, entrée agence). Ces deux profils traduisent deux manières différentes de suivre la prestation réalisée par le transporteur 9, mais ils appartiennent tous deux au même client. Chaque profil est considéré comme spécifique à un transporteur donné car l'ensemble de départ (les statuts) de la fonction de regroupement est défini par les données fournies par le transporteur. En d'autres termes, un autre transporteur fournira a priori un ensemble de statuts différents. Ainsi, la base de données 8 renferme le profil métier 20 représenté sur la figure 3 pour le transporteur 9. Lorsque le fichier 16 arrive dans le serveur de base de données 5, le moteur de décision 6 trie l'ensemble des données, extrait le statut"dévoyé", identifie ce statut à un statut interne prédéfini dans l'ensemble 19 et détecte dans le profil métier 20 l'événement comportant ce statut, c'est à dire l'événement "sinistre". Par ailleurs, lorsque le statut reçu par le serveur de base de données 5 a été identifié, le moteur de décision 6 lance un gestionnaire de règles qui a pour rôle d'appliquer un ensemble de règles prédéterminées sur les événements du profil métier. Une règle est un ensemble de conditions prédéfinies susceptibles d'être appliquées à un ou plusieurs événements de façon à générer une action prédéterminée. Une règle comprend donc les conditions à appliquer sur l'ensemble des informations relatives à la prestation et aux événements correspondants, l'action associée si les conditions sont vérifiées, ainsi que le destinataire de l'action. La figure 4 illustre une telle règle définissant les conditions à appliquer et les actions à mener lorsqu'un colis est perdu. Cette règle est donc intitulée colis perdu. La fenêtre d'interfaçage 22 est une fenêtre qui peut être visualisée par un moyen d'affichage associé au serveur d'administration 1. Cette fenêtre 22 comprend une première sousfenêtre 23 décrivant le type de règle et son mode de fonctionnement. La règle "colis perdu" est dans un mode de fonctionnement actif. La sous-fenêtre 24 correspond à l'action à effectuer, c'est à dire l'envoi d'un message. Ce message est une phrase type à laquelle seront ajoutées des données contextuelles telles que le numéro de code transporteur, la date d'expédition, le nom et pays du destinataire, provenant de la prestation, de l'événement ou d'un calcul de fonction lors de l'examen de la règle. La sous-fenêtre 25 comprend la combinaison des conditions à appliquer. Ainsi le message décrit dans la sous-fenêtre 24 sera envoyé si à l'examen de la règle"colis perdu", le profil métier de la prestation concernée comprend un événement sinistre actif ou un événement livré non actif combiné à un délai supérieur à 15 jours. Un événement est actif lorsqu'il comporte un statut venant d'être reçu. La sous-fenêtre 26 indique l'ensemble des destinataires du message. Par conséquent, lorsque le moteur de décision 6 détecte à la réception d'un fichier transmis par le transporteur 9 pour la prestation de livraison, un statut"dévoyé", ce moteur de décision 6 active l'événement"sinistre"compris dans le profil métier 20 du transporteur 9, et lance également l'examen de la règle "colis perdu". L'examen de la règle"colis perdu"montre que la première condition est vérifiée, c'est à dire que l'événement"sinistre"est actif. Le moteur de décision 6 insère alors dans un fichier le message décrit dans la sous-fenêtre 24 ainsi que les destinataires et les moyens de communication spécifiés dans la sous-fenêtre 26. Ces informations sont alors transmises vers le module de diffusion 24 qui prépare un message 12 à transmettre vers les destinataires spécifiés dans la sousfenêtre 26. D'une façon générale, le destinataire des messages est l'expéditeur, mais d'autres entités peuvent être désignées comme destinataire. Pratiquement, le système selon l'invention peut être soit directement implanté sur le site d'un utilisateur auteur de la prestation, soit disposé sur un site distant géré par un utilisateur tiers. L'installation sur site concerne particulièrement des entreprises désirant utiliser le système selon l'invention en maîtrisant les ressources techniques du système. L'architecture de ce type d'installation comprend trois éléments principaux : un serveur de base de données, un serveur d'administration et un serveur de communication. Le serveur de base de données assure la gestion physique des deux ensembles de données : données de paramétrage (paramétrage des messages, utilisateurs, règles, profils, etc.) et données opérationnelles (contenu des enregistrements de prestations et statuts). Le serveur de base de données est de plus en charge de l'exécution des fonctions du moteur de décision. Il peut alors être concrétisé par une machine exécutant un système de gestion de bases de données relationnelles. Le serveur d'administration héberge un site web d'une application d'administration du système selon l'invention. Le site web communique avec le serveur de base de données selon un modèle client-serveur. L'application web pourra être installée sur un serveur Intranet de l'entreprise ou sur un autre serveur réseau équipé d'un serveur d'applications Web. Le serveur de communication assure d'une part la réception des messages de statuts entrants, et d'autre part la diffusion des actions vers des destinataires prédéfinis. Le module chargé de la réception possède de préférence un accès à Internet, à un réseau à valeur ajouté (VAN"Value added network"en langue anglaise) par exemple de type Atlas 400 pour l'EDI ("Electronic Data Interchange") et à un serveur ftp ("File Transfer Protocol"). Le module chargé de la diffusion supporte de préférence le protocole ftp et MAPI ("Message Application Programming Interface"), et l'accès à des outils d'interfaçage téléphonique TAPI ("Telephony Application Programming Interface"). L'installation hors site de l'utilisateur auteur de la prestation, consiste à implanter les éléments techniques ainsi décrits chez un tiers. Le système constitue alors une application hébergée auquel les utilisateurs peuvent avoir accès via Internet. Bien sûr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l'invention. REVENDICATIONS 1. Système de gestion de flux de données en vue d'élaborer un ensemble d'actions prédéterminées pour le suivi d'une prestation, comprenant au moins : - un serveur de communication pour recevoir et formater des données d'exploitation en provenance d'au moins une source donnée, et pour diffuser les actions prédéterminées vers des destinataires donnés, un serveur de base de données pour stocker des données de configuration et les données d'exploitation, et pour exécuter un moteur de décision qui interprète les données d'exploitation, vérifie si ces données d'exploitation remplissent des conditions comprises dans les données de configuration et élabore les actions prédéterminées le cas échéant, et un serveur d'administration pour gérer les données de configuration, la communication entre le serveur d'administration et le serveur de base de données étant une communication client-serveur. 2. Système selon la revendication 1, caractérisé en ce que pour chaque prestation, le moteur de décision comprend des moyens pour : - répertorier l'ensemble des états possibles liés à une prestation, - regrouper ces états possibles en plusieurs sous-groupes selon une fonction surjective, chaque sous-groupe symbolisant un événement, et en ce que ce regroupement en événements est défini en fonction de critères transmis par l'auteur de ladite prestation. 3. Système selon l'une des revendications 1 ou 2, caractérisé en ce que chaque donnée d'exploitation comprend au moins une information sur un état possible de la prestation et des moyens d'identification et de qualification de la prestation, ces moyens d'identification contenant un identifiant sous forme de code d'identification de la prestation, et une description de la prestation. 4. Système selon la revendication 3, caractérisé en ce que les conditions comprises dans les données de configuration sont combinées sous forme de règles applicables sur les moyens d'identification et de qualification de la prestation et sur l'absence d'information sur un état possible de la prestation 5. Système selon la revendication 3, caractérisé en ce que les conditions comprises dans les données de configuration sont combinées sous forme de règles applicables sur les moyens d'identification et de qualification de la prestation et sur un événement donné regroupant un ensemble d'états possibles de la prestation 6. Système selon la revendication 3, caractérisé en ce que les conditions comprises dans les données de configuration sont combinées sous forme de règles applicables sur les moyens d'identification et de qualification de la prestation et sur l'ensemble d'événements associés à ladite prestation. 7. Système selon la revendication 3, caractérisé en ce que les conditions comprises dans les données de configuration sont combinées sous forme de règles applicables sur les moyens d'identification et de qualification d'une pluralité de prestations et sur l'ensemble d'événements de la pluralité de prestations. 8. Système selon l'une quelconque des revendications 4 à 7, caractérisé en ce que les règles comprennent des moyens pour déterminer une action en fonction desdites conditions et de spécifier un canal de diffusion d'un message vers un destinataire donné. 9. Système selon la revendication 8, caractérisé en ce que le canal de diffusion comprend un mini message via un téléphone portable. 10. Système selon la revendication 8 ou 9, caractérisé en ce que le canal de diffusion comprend un message électronique via un réseau de communication de type Internet. 11. Système selon l'une quelconque des revendications 8 à 10, caractérisé en ce que le canal de diffusion comprend un message vocal. 12. Système selon l'une quelconque des revendications 4 à 11, caractérisé en ce qu'il comprend des moyens pour rendre une règle active, inactive ou la mettre en veille. 13. Procédé de gestion de flux de données en vue d'élaborer un ensemble d'actions prédéterminées pour le suivi d'une prestation en cours, comprenant les étapes suivantes : - acquisition de données d'exploitation en provenance d'au moins une source de données, via un mode de communication, - interprétation des données d'exploitations reçues, - application d'un ensemble de règles sur lesdites données d'exploitations, - élaboration d'un message lorsqu'une règle est respectée, et transmission du message vers un destinataire notamment par voie électronique ou téléphonique. 14. Procédé selon la revendication 13, caractérisé en ce que l'étape d'acquisition fait intervenir les étapes suivantes : - acquisition de données d'exploitation selon différents modes de communication, et - conversion desdites données d'exploitation sous un format standard prédéterminé. 15. Procédé selon l'une des revendications 13 ou 14, caractérisé en ce que l'étape d'interprétation fait intervenir les étapes suivantes : - identification de la source et du format des données d'exploitation, - transfert dans une table de base de données adaptée au format identifié, - détermination de nouvelles prestations devant être initialisées en fonction desdites données d'exploitation, détermination des prestations déjà existantes pour lesquelles les données reçues constituent un nouvel état, détermination au sein des données d'exploitation d'un état possible relatif à ladite prestation, traduction dudit état possible en un état possible prédéfini, identification de l'état possible ainsi traduit au sein d'un événement, un événement étant un sous-groupe composé de plusieurs états possibles et obtenu à la suite d'une partition de l'ensemble des états possibles prédéfinis, cette partition étant définie en fonction de critères transmis par l'auteur de ladite prestation. 16. Procédé selon la revendication 15, caractérisé en ce que les étapes d'application des règles et d'élaboration de message font intervenir les étapes suivantes : sélection des règles à examiner en fonction de leur état d'activité et de la source des données d'exploitation ; extraction, à partir des données d'exploitation, d'informations supplémentaires relatives à ladite prestation et de l'événement comprenant l'état identifié en fonction d'un ensemble de conditions composant les règles ; - création de messages en fonction de phrases-types et de données contextuelles ; enregistrement de l'historique des règles invoquées, - extraction des modes de diffusion pour les destinataires des messages ; et constitution d'un fichier de messages.