FR 3001823 A1 20140808 FR 1350896 A 20130201 Titre Système de gestion d'ordres de transactions à contreparties limites Domaine de l'invention La présente invention concerne un système destiné à être mis en oeuvre dans un environnement informatique pour faciliter la définition, l'enregistrement et l'exécution d'ordres d'achat à prix maximum pour des produits ou services. Etat de la technique Dans les procédés de vente les plus couramment utilisés, en particulier sur l'Internet, des vendeurs définissent les prix de biens à vendre (des produits ou des services), et des acheteurs doivent prendre en compte la diversité des offres et les évaluer en fonction de leurs critères. L'analyse de l'offre est ainsi fastidieuse et complexe. Pour des produits ou services dont les prix varient significativement au cours d'une période de mise en vente, il existe des procédés permettant à un acheteur de suivre le prix et d'être informé de ses changements. Notamment, un acheteur peut être informé lorsque le prix a atteint une valeur cible que l'acheteur a définie. Dans ce cas, l'acheteur ne s'est pas engagé à acheter le produit ou service, mais s'il souhaite le faire, il doit réagir rapidement pour effectuer l'achat au moment où le prix correspond à son attente. Un autre système consiste à rassembler des offres conditionnelles d'achat dans un système piloté par les acheteurs. Dans un tel système, le 25 produit ou le service est automatiquement vendu à l'acheteur si un prix maximum défini dans l'offre conditionnelle d'achat est satisfait. Par exemple, dans les marchés boursiers, un ordre d'achat à cours limité est bien connu et largement utilisé sur les plateformes de transactions. Selon un autre exemple, dans le domaine des voyages, certaines 30 plateformes de vente ont déjà implémenté un système piloté par les acheteurs en rassemblant des offres d'achat conditionnelles pour acheter des billets d'avion, des nuits d'hôtel, des locations de voitures, etc. En particulier, la société Priceline a élaboré de tels systèmes. Cependant, les systèmes à offre d'achat conditionnelle existants ne fournissent que très peu d'informations pour aider les acheteurs à fixer leur prix plafond, ce qui rend l'utilisation d'un tel système difficile pour les acheteurs n'ayant pas suffisamment d'expérience ou de connaissance préalable d'un marché pour fixer un prix plafond approprié. En outre, la description du produit ou du service à vendre est souvent imprécise, ce qui rend la fixation d'un prix plafond difficile. Ainsi, face à un manque d'information et d'assistance, de nombreux acheteurs fixent un prix maximum insuffisant, conduisant à un échec de leur offre. La présente invention vise à pallier tout ou partie des limitations de 15 l'état de la technique. Résumé de l'invention La présente invention vise notamment à proposer un système offrant au moins l'une des fonctionnalités suivantes : 20 - le calcul et la présentation en temps réel ou quasi-réel d'un indicateur de probabilité de succès permettant de guider des acheteurs dans la fixation d'un prix maximum pour un ordre d'achat de produit ou de service ; - l'exécution d'ordres d'achats parmi une liste en fonction de priorités définies dans le système ; 25 - la fourniture d'une liste d'ordres d'achat à des vendeurs afin de faciliter l'exécution des transactions. On propose ainsi selon l'invention un système informatique de gestion d'ordres de transactions avec valeur de contrepartie limite, notamment un prix d'achat plafond, pour des produits ou services, caractérisé en ce qu'il 30 comprend : - une source d'informations répertoriant les produits ou services disponibles et des variables explicatives pour ces produits ou services, ainsi que des informations de contrepartie proposée variables en fonction du temps pour ces produits ou services, - un moteur de classification automatique apte à regrouper des produits ou services par classes d'évolution de leur contrepartie, à partir d'historiques de contreparties, et à affecter à chaque classe des gammes de variables explicatives et des valeurs d'évolution, - des moyens d'interface client pour saisir des ordres sur des produits 10 et services données en fixant une contrepartie limite, - un moteur d'affectation d'un ordre saisi à une classe d'évolution en fonction des variables explicatives de l'ordre au regard des gammes de variables explicatives des différentes classes, et - un moteur de calcul d'un indicateur d'une probabilité de succès d'un 15 ordre saisi, en combinant la valeur de la contrepartie limite de cet ordre avec les valeurs d'évolution de la classe à laquelle il a été attribué. - et un moteur de confrontation des offres et des contreparties offertes pour convertir des offres en transactions lorsque des contreparties proposées atteignent des contreparties limites. 20 L'invention est avantageusement mais facultativement complétée par les caractéristiques suivantes, prises en toutes combinaisons techniquement compatibles : * les classes d'évolution comprennent une des classes de tendance et des classes de volatilité. 25 * le moteur de calcul de l'indicateur est apte à recalculer un indicateur de façon périodique pendant la période de validité de l'offre. * pour les calculs périodiques, le moteur de calcul de l'indicateur est apte à mettre en oeuvre une pondération de la probabilité par rapport à une classe identifiée a priori à l'aide des variables explicatives et par rapport à 30 une classe identifiée par l'évolution réelle observée des contreparties pour l'ordre considéré dans la période de validité de l'ordre. * la pondération prend en compte la quantité d'informations de l'évolution réelle observée. * la pondération est basée sur la date courante par rapport à la date de début et la fin de l'ordre considéré. * les moyens d'interface client sont aptes à recevoir une nouvelle valeur de contrepartie limite pendant la période de validité de l'offre, le moteur de calcul de l'indicateur répondant à cette nouvelle valeur reçue en recalculant la valeur dudit indicateur en temps quasi-réel. * le système comprend en outre un dispositif de gestion de la priorité 10 des ordres. * le dispositif de gestion de priorité comprend des moyens d'ordonnancement des ordres selon au moins deux critères parmi des informations de fidélité des entités saisissant des ordres, des informations de quantité de produits ou services demandés dans les ordres, et des 15 informations de contrepartie limite. * chaque nouvel ordre donne lieu à une confrontation par le moteur de confrontation sur la base d'une requête vers la source d'informations en vue d'obtenir une contrepartie proposée, et le système comprend également une mémoire cache de contreparties proposées en vue d'éviter de multiplier les 20 requêtes pour une série d'offres sur le même produit ou service à des contreparties identique ou inférieures. * le système comprend des moyens pour envoyer de nouvelles requêtes pour des contreparties proposées, en vue de confronter d'autres ordres sur un produit ou service donné, lorsqu'une offre a été convertie en 25 transaction sur ledit produit ou service. * le système comprend des moyens réducteurs (MapReduce) pour engendrer la source d'informations à partir d'informations brutes. * le système comprend en outre un moteur d'agrégation d'ordres actifs sur un produit ou service donné, et des moyens de communication entre le 30 moteur d'agrégation et la plateforme d'un offreur du produit ou service donné lui permettre d'accéder à ces ordres agrégés. * le système comprend en outre des moyens d'ajustement de la contrepartie proposée pour le produit ou service donné en fonction des valeurs de contreparties limites contenues dans les ordres agrégés. Brève description des dessins D'autres aspects, buts et avantages de la présente invention apparaîtront mieux à la lecture de la description détaillée suivante d'une forme de réalisation préférée de celle-ci, donnée à titre d'exemple non 10 limitatif et faite en référence aux dessins annexés, sur lesquels : La Figure 1 est un schéma de l'architecture générale du système de l'invention, La Figure 2 illustre un processus de classification automatique de tendances utilisé dans la présente invention, 15 La Figure 3 illustre un ensemble de n classes obtenues par regroupement par k-moyennes, La Figure 4 illustre l'ensemble des n classes, avec l'illustration des densités différentes d'une variable explicative dans deux classes par des hachures de densités différentes, 20 La Figure 5 illustre l'ensemble des n classes, avec l'illustration des densités différentes de deux variables explicatives dans deux classes par des hachures d'orientations et de densités différentes, La Figure 6 représente un graphique illustrant la pondération au cours du temps pour le calcul d'un indicateur de probabilité de succès, 25 La Figure 7 illustre un extrait d'une base de données contenant des caractéristiques pour plusieurs vols possibles sur un trajet en avion donné, La Figure 8 représente cinq observations de prix pour ces vols, en fonction du temps, La Figure 9 représente un exemple de tendance obtenue (classe) 30 correspondant aux cinq observations de prix pour ces vols, La Figure 10 illustre les gammes de variables explicatives associées à une classe, La Figure 11 illustre les variables explicatives d'un vol donné, permettant de l'associer à la classe de la Figure 6, La Figure 12 illustre une observation des prix constatés sur une période donnée pour un vol donné, La Figure 13 illustre une tendance déduite de l'observation de prix de la Figure 12, La Figure 14 illustre un extrait d'une base de données de chambres 10 d'hôtel, avec des variables explicatives, La Figure 15 représente un exemple d'observations de prix pour trois items de l'extrait de la Figure 14, La Figure 16 illustre les tendances de deux classes de tendances déduites de ces observations, 15 La Figure 17 représente des extraits de la base de données de classes, avec un certain nombre d'items (type de chambre et nom de l'hôtel) par classe, le tout pour une ville donnée, La Figure 18 illustre les variables explicatives fixées par un acheteur pour un ordre d'achat donné pour un hôtel, 20 La Figure 19 illustre une observation de prix récente Y1 pour l'objet de cet ordre, et La Figure 20 illustre la tendance de l'observation de prix récente Y1 de la Figure 19, permettant d'identifier la classe Si. 25 Description détaillée d'une forme de réalisation préférée 1. Introduction L'invention est mise en oeuvre au niveau d'une plateforme informatique destinée à assurer la définition, la mémorisation et l'exécution 30 d'ordres de transaction à valeur de contrepartie limite, en particulier d'ordres d'achat de biens ou de services à prix limités, ainsi que la définition de priorités entre différents ordres d'achat à exécuter. Dans le système de l'invention, un indicateur de probabilité de succès d'un ordre sur un prix maximum donné est engendré et présenté à l'acheteur 5 en vue de faciliter sa prise de décision. Un autre aspect de l'invention comprend la présentation à des tiers, en particulier à des vendeurs, de la liste des ordres d'achats en cours pour des produits ou services, de manière à faciliter l'exécution d'une transaction sur un produit ou service donné par ajustement du prix de vente. 10 Dans la description qui suit, à titre d'exemple permettant de bien comprendre l'invention, on va décrire un système particulièrement bien adapté à l'achat et la vente de billets d'avion. L'invention peut toutefois s'appliquer à d'autres biens ou services susceptibles d'offrir une variabilité de prix dans le temps. 15 2. Plateforme En référence tout d'abord à la Figure 1, la plateforme est subdivisée en trois domaines, à savoir un domaine client ou « front-end » en terminologie anglo-saxonne, un domaine de gestion ou « back-end » en 20 terminologie anglo-saxonne, et un domaine serveur. 2.1. Domaine client Le domaine client désigné par Front End sur la Figure 1 est celui qui récupère l'ensemble des informations à partir de la plateforme, l'organise et 25 génère son affichage à destination de l'acheteur. En utilisant une interface client IC, typiquement une interface web et des dispositifs d'entrée (clavier, souris, etc.), l'acheteur peut activer des ordres d'achat de produits ou de services sur une plateforme de vente par la mise en oeuvre des étapes suivantes : * recherche de produits ou de services à partir d'un ensemble de critères, et fourniture d'informations caractéristiques des produits ou services satisfaisant ces critères à l'acheteur ; * sélection par l'acheteur des produits ou services qu'il/elle souhaite 5 acheter ; * fixation par l'acheteur, en fonction d'un indicateur de probabilité de succès (voir plus bas dans la description), d'un prix maximum pour la transaction, cet indicateur étant fourni par la plateforme et ajusté en temps réel ou quasi-réel en fonction du prix maximum fixé par l'acheteur ; 10 * processus d'autorisation de paiement pour le site vendeur dans le cas où l'ordre d'achat sera dénoué avec succès. Dans le système de l'invention, un acheteur a la possibilité d'activer une pluralité d'ordres d'achat et de les lier entre eux. Grâce à ces liens, si un ordre d'achat est dénoué avec succès, les autres ordres liés sont 15 automatiquement annulés. En outre, l'acheteur peut modifier ou annuler manuellement un ordre d'achat à tout moment, aussi longtemps qu'il ne s'est pas dénoué avec succès. Ainsi un ordre d'achat est valable dès qu'il est activé par l'acheteur, et jusqu'à ce qu'il soit annulé, manuellement ou automatiquement, ou encore 20 jusqu'à l'expiration de la période de vente du produit ou service concerné. 2.2. Domaine de gestion Ce domaine désigné par Back End sur la Figure 1 exécute toutes les opérations de synthèse permettant de transformer les données de prix brutes 25 pour un bien ou service considéré en des données utilisables par le serveur, en vue de leur présentation à l'acheteur. Comme on l'a indiqué, on se concentrera ici sur l'exemple des tarifs de billets d'avion. Le domaine de gestion comprend deux modules qui utilisent avantageusement l'environnement logiciel MapReduce® (MR) (voir 30 notamment sous le lien http://en.wikipedia.org/wiki/MapReduce), à savoir : - Un module de collecte des données de vols FDC contenant l'ensemble des données brutes pour un vol donné (horaire, compagnie, aéroport de départ, aéroport d'arrivée, tarifs, etc.). Ce module est directement interfacé à une source tierce de données brutes, cette source de données pouvant être une centrale de fournisseurs (ou GDS « Global Distribution Systems » en terminologie anglo-saxonne), ou tout autre tiers proposant ces données. Ce module gère les requêtes à ce tiers à travers une interface de programmation d'application (API pour « Application Programming Interface » en terminologie anglo-saxonne) si elle existe, ou selon les modalités proposées par ce tiers. L'ensemble des données brutes peuvent être stockées sous forme de fichiers ou de base de données. Enfin, le module FDC est interfacé avec un cache d'un moteur d'options OE tel qu'on le décrira plus loin, qui est géré au niveau du domaine serveur. Grâce à ces données, le module peut fournir au module FDT (décrit dans ce qui suit) les données de prix récents constatés qui seront utilisés par ce dernier pour calculer et mettre à jour des indicateurs, et en particulier un indicateur de probabilité de succès IPS. Ce module est en charge du mappage au sens de l'environnement MapReduce ; et - Un module de traitement de données de vols FDT qui a plusieurs rôles. Le premier est la « réduction » des données collectées par le FDC au sens de MapReduce. Cette réduction permet un calcul efficace par le module FDT des indicateurs qui sont directement utiles au système pour le calcul de l'indicateur de probabilité de succès IPS qui sera détaillé dans la suite. Ces indicateurs sont par exemple le prix minimum sur un segment donné et pour une compagnie donnée, le prix moyen, médian, etc. Le second rôle du module FDT est de réaliser une classification (par exemple en utilisant l'algorithme des k-moyennes comme on le décrira plus loin), afin d'attribuer une classe de tendance et une classe de volatilité à chaque série temporelle de prix constatés pour un vol donné. Le troisième rôle du module FDT est de réaliser la correspondance entre les classes de tendance et les classes de volatilité obtenues en utilisant les prix des vols et des variables explicatives de ces vols (ces variables étant décrites dans la suite). Ces indicateurs calculés (ou encore « réduits ») par l'environnement MapReduce ainsi que les informations de classe issues du module FDT sont stockés dans une base de données de vols F-DB qui est gérée au niveau du domaine de serveur. Ces données sont destinées à être utilisées pour calculer l'indicateur de probabilité de succès IPS pour un ordre d'achat donné. Leur disponibilité permet de garantir un calcul de l'indicateur en quasi- temps réel. 2.3. Domaine serveur Ce domaine désigné par Server sur la Figure 1 a pour fonctions de récupérer les données à partir du domaine de gestion et d'envoyer toutes les informations d'interface utilisateur vers le poste client de l'acheteur, d'enregistrer toutes les données d'utilisateur nécessaires, notamment les données saisies pour réaliser un ordre d'achat, et de réaliser l'interface avec les fournisseurs (à savoir les GDS pour « Global Distribution Systems » en terminologie anglo-saxonne) et les serveurs de paiement Banque et d'assurance Assurance. Il comprend les éléments suivants : - La base de données de vols précitée F-DB, qui réalise l'interface avec le domaine de gestion et est utilisée pour mémoriser des classes de tendances tenues à jour pour chaque itinéraire, des classes de volatilité, ainsi que des indicateurs calculés par le module FDT. Cette base de données est interfacée avec un serveur de vols F-Server et éventuellement avec le serveur S-Server. Cette base de données contient en particulier les indicateurs permettant de calculer rapidement l'indicateur de probabilité de succès, à partir de la classe de tendance et de la classe de volatilité d'un vol donné. - Le serveur de vols F-Server précité, qui est un serveur de type machine à états qui joue plusieurs rôles. Tout d'abord, il reçoit des requêtes, par exemple au format AJAX, à partir du domaine client, et répond à ces requêtes en adressant à son tour des requêtes à une base de données de clients ou acheteurs C-DB, décrite dans la suite. Ce serveur de vols F-Server s'interface ainsi avec cette base de données pour stocker l'ensemble des données de clients utilisées pour définir les options prises et pour traiter les paiements. - La base de données de clients C-DB précitée, utilisée pour stocker toutes les informations relatives aux clients et leurs ordres d'achat. Elle contient également des informations relatives au paiement. La base de données C-DB s'interface avec le serveur de vols F-Server, avec un serveur interne I-Server décrit dans la suite, et avec le module de moteur d'options OE également décrit dans la suite. Le système accède également à cette base de données C-DB pour extraire des informations d'ordres à présenter aux vendeurs et revendeurs comme on le verra dans la suite ; selon une caractéristique particulière de l'invention, la base de données C-DB est ordonnée selon des règles de priorité définies dans la plateforme. La notion d'ordonnancement prioritaire dans la base de données permette de mettre en oeuvre la fonctionnalité suivante : lorsque le moteur d'options OE compare les prix proposés par les vendeurs aux ordres présents, un ordre positionné en début de la liste d'ordres a plus de chance d'être exécuté étant donné que le nombre de places vendues à un prix donné peut être réduit. Les paramètres susceptibles d'influer sur l'ordonnancement de la liste peuvent être, par exemple, des privilèges donnés à des utilisateurs fréquents de la plateforme (système de points de fidélité), ou le montant global de l'ordre, les ordres unitaires étant valables (un ordre comprenant un montant total supérieur pour l'achat de produits ou de services peut être prioritaire). Par exemple, supposons qu'il existe des ordres d'achat sur un billet d'avion comme suit : Ordre 1 : 4 sièges à 220 E, donc pour un montant total de 880 E Ordre 2 : 6 sièges à 200 E, donc pour un montant total de 1200 E et que le tarif public passe brusquement de 240 E à 200 E. Dans ce cas, il peut être décidé par la plateforme de servir en premier l'ordre 2 dont le montant total est supérieur à celui de l'ordre 1 (1200> 880). - Le moteur d'options OE précité, dont la fonction est d'engendrer les requêtes à destination des fournisseurs (en particulier les systèmes de 5 distribution globaux GDS ou tout autre revendeur de billets d'avion, dans le présent exemple) et à destination des serveurs de paiement. Le moteur d'options OE explore la base de données de clients C-DB pour lire séquentiellement l'ensemble des ordres d'achat qu'elle contient, et examine si un ordre donné peut être exécuté, dans le cas où le prix réel d'un vol est 10 tombé au niveau du prix plafond de cet ordre. Lorsque l'ordre est exécuté (transaction d'achat du billet validée), le moteur d'options OE génère une information (par exemple un courrier électronique) à destination de l'acheteur, à l'aide d'un lien vers un serveur de messagerie SMTP désigné par MSG. 15 Ce moteur d'options OE est un élément essentiel de l'invention en ce qu'il gère les listes d'ordres d'achat et leur exécution dans le cas où les conditions d'achat sont remplies. Dans la pratique le moteur d'options lance des requêtes sur une base périodique (par exemple trois fois par jour pour une application aux billets d'avion) à destination des serveurs des 20 fournisseurs ou vendeurs afin de récupérer les prix courants des produits ou services présents dans la liste des ordres d'achat. Dans le cas où un prix courant pour un produit ou service est égal ou inférieur à un prix plafond d'un ordre pour ce même produit ou service, la transaction est automatiquement effectuée, et le compte financier de l'acheteur est automatiquement débité. 25 Dans un mode avantageux de réalisation de l'invention, le moteur d'options OE utilise un cache permettant de limiter le nombre de requêtes effectuées vers une centrale de fournisseurs (par exemple un GDS). En effet, si le prix de vente retourné lors d'une requête pour satisfaire un ordre est supérieur à d'autres ordres présents dans la liste, il est inutile de renouveler 30 cette requête pour ces autres ordres. En revanche, si un ordre rencontre un prix permettant son exécution, il est intéressant de tenter de réaliser les ordres équivalents à la suite, de manière à profiter le plus rapidement possible d'une éventuelle baisse de prix. Avantageusement, le système ordonnance donc les ordres concernant un même ensemble de vols pour une même destination à la suite les uns des autres dans la base C-DB. Le cache du moteur d'options OE est interfacé au module de traitement de données de vols FDT, via le moteur d'options lui-même, de manière à ce que les indicateurs calculés par le module FDT puissent être mis à jour en fonction des prix constatés. - Le serveur interne I-Server précité, dont la fonction est d'extraire de 10 la base de données de clients C-DB toutes les informations nécessaires pour le service après-vente, la supervision, le reporting et enfin l'administration et la comptabilité. - Le serveur statique S-Server précité, utilisé pour engendrer toutes les informations statiques à envoyer du domaine du client. 15 Avantageusement, ce serveur est physiquement séparé du serveur de vols F-Server pour des raisons de performance. Ce serveur est également destiné à produire un service d'information minimum en cas d'arrêt du service du système. 20 3. Indicateur de probabilité de succès IPS L'indicateur IPS est calculé et affiché en temps quasi-réel lorsqu'un acheteur configure son ordre d'achat. Cet indicateur est également disponible pour l'acheteur pendant toute la durée de validité de l'ordre d'achat, et ses variations peuvent être automatiquement transmises à 25 l'acheteur. On peut également prévoir que, lorsque la valeur de l'indicateur IPS devient trop petite, la plateforme recommande automatiquement à l'acheteur d'acheter le produit ou service le plus tôt possible, ou de modifier les critères de son ordre, et ce de manière à éviter de générer auprès de systèmes de 30 distribution globaux GDS des requêtes (qui peuvent être payantes) n'ayant quasiment aucune chance d'être couronnées de succès. On se rend compte ici de l'intérêt de l'IPS : même s'il n'était pas rendu disponible pour le client, l'IPS est nécessaire pour la plateforme de manière à éviter de gérer des ordres n'ayant aucune (ou trop peu) de chances d'aboutir. L'indicateur IPS est calculé pour chaque sélection par l'acheteur en 5 temps quasi-réel (le caractère « quasi-réel » s'expliquant par le fait qu'il est nécessaire d'adresser une requête à la base de données de vols F-DB et de réaliser un calcul sur le serveur de vols, et que même si la durée de calcul est très courte, la présentation à l'utilisateur n'est pas immédiate du fait des durées de transmission de la requête et de la réponse ; ces durées peuvent 10 néanmoins être extrêmement brèves). Ainsi, dès qu'un utilisateur modifie les critères de son ordre d'achat pendant la configuration de cet ordre, la valeur de l'indicateur est bien entendu mise à jour. Le calcul de l'indicateur de probabilité de succès IPS est réalisé sur la base des informations suivantes : 15 1) l'information amont sur le produit ou service : les caractéristiques principales du produit ou du service sélectionné par l'utilisateur sont clairement connues ; par exemple, dans le cas spécifique de billets d'avion, ces caractéristiques principales comprennent le nom du transporteur, les dates et les horaires du vol considéré, le numéro de vol, et la précocité de 20 l'ordre, à savoir l'écart entre la date de l'ordre et la date du vol ; 2) le prix proposé par le vendeur pour acheter le bien ou service : ce prix peut être celui effectivement saisi par le vendeur, ou un prix suggéré par la plateforme de vente ; 3) la connaissance de l'évolution des prix passée pour un produit ou 25 service équivalent : l'historique des prix sur une longue période (en mois ou années) est connu, de même que peuvent être connues des données statistiques telles que le prix moyen, le prix médian, le prix minimum ; cette connaissance du passé est importante pour le calcul d'un bon indicateur de probabilité de succès, comme on va l'expliquer dans la suite ; 30 4) la tendance du prix du produit ou service dans le passé immédiat : l'évolution récente du prix du produit ou service, comme par exemple l'évolution du prix sur le mois écoulé pour un vol spécifique, est également prise en compte ; cette information permet, dans une première étape, de calibrer un algorithme de calcul de probabilité et, dans une seconde étape, de raffiner le calcul pendant la période de validité de l'ordre d'achat ; bien qu'elle ne soit pas indispensable au calcul de l'indicateur, cette information est prise en compte lorsqu'elle est disponible. L'indicateur est calculé à l'aide d'un algorithme apte à combiner ces données de manière à prédire d'une façon aussi fiable que possible la probabilité pour un ordre d'achat donné de réussir. On va maintenant décrire cet algorithme. Tout d'abord, du fait de la complexité du problème à traiter, liée au grand nombre de variables (transporteurs, destinations, dates, etc.) et de la quantité considérable de données, il est nécessaire de simplifier le problème. Ceci est réalisé en groupant les variables ensemble d'une manière 15 pertinente. Cette simplification est réalisée hors-ligne, c'est-à-dire d'une manière systématique et avant d'être nécessaire pour un acheteur donné, par le domaine de gestion Back End de la plateforme, ceci afin d'assurer que l'indicateur soit présenté à l'acheteur en temps quasi-réel. Ainsi, selon une première étape de l'invention, on crée dans le 20 système des classes d'évolution de prix. Dans une seconde étape, toutes les évolutions de prix sont affectées à une classe donnée parmi les différentes classes. Les classes sont basées sur la connaissance préalable d'une évolution typique des prix, et sont définies par l'expérience. Par exemple, on 25 peut créer une classe de prix purement croissants en fonction du temps, une classe de prix croissants puis décroissants en fonction du temps, etc. Dans un mode préféré de l'invention, on applique un filtrage passe-bas sur les données (par exemple en réalisant une moyenne glissante d'une largeur temporelle de quelques jours). Le vecteur de données de prix Pi (en 30 fonction du temps) peut alors être décomposé en : Pi = Xi + Vi Où Xi est la tendance d'évolution du prix (à savoir le résultat du filtrage passe-bas) et Vi est la volatilité du prix. La volatilité du prix est composée elle-même de la gamme dans laquelle les prix fluctuent et de la fréquence des variations pour chaque 5 courte période (typiquement de quelques jours). Le traitement qui sera fait ce cette volatilité Vi est décrit dans la suite. L'attribution (étiquetage) d'une certaine classe à une nouvelle instance de tendance prix, c'est-à-dire la catégorisation des nouvelles tendances de prix de vols en différentes classes (tendance croissante, tendance 10 décroissante, tendance croissante puis décroissante, etc.) est bien connue en soi dans le domaine de la classification en apprentissage automatique. On notera ici que fréquemment, l'information de prix est manquante dans des données de vols. Il est donc important que la classification utilisée selon l'invention soit robuste vis-à-vis des données manquantes. 15 Ainsi, dans une implémentation préférée de l'invention décrite dans la suite, on propose d'utiliser un algorithme de regroupement par k-moyennes (« k-means clustering » en terminologie anglo-saxonne), étant toutefois observé que d'autres algorithmes de classification automatique connus de l'homme du métier peuvent être utilisés. Par exemple, les algorithmes de 20 type « Support Vector Machine (SVM) » ou de « Latent Class Model » sont également particulièrement bien adaptés. En outre, une mise en oeuvre en logique floue (« fuzzy logic ») de ces algorithmes, selon laquelle un élément est classé dans un cluster avec une probabilité donnée, la somme des probabilités sur les clusters étant égale à 1, peut être utilisée. 25 En référence à la Figure 2, l'algorithme peut être décomposé en plusieurs étapes, comme suit : a) à partir d'un ensemble de m observations connues (X1, X2, Xm) ayant fait l'objet d'un filtrage passe-bas, où chaque observation se présente sous la forme d'un vecteur réel de prix, le regroupement automatique, ici par 30 k-moyennes, permet, de façon connue en soi, de classer les m observations en n ensembles, ou classes, (avec n m), de manière à minimiser la somme des distances entre vecteurs au sein d'un groupe. Cette première étape partitionne ainsi l'espace S des observations comme suit : S = {S1, S2, , Sn} Ce regroupement est effectué pour l'ensemble des m vecteurs de prix 5 du passé (données d'apprentissage). Ces classes correspondent aux motifs les plus vraisemblables d'évolution des prix en fonction du temps (à savoir des tendances) que l'on note Ck, avec 1 k n. La Figure 3 illustre un ensemble de n classes. On notera ici qu'il est nécessaire pour le bon fonctionnement de la 10 classification de normaliser les informations de tendance, en fonction des informations sur les prix connues pour un vol donné (prix minimum, prix moyen et prix médian par exemple). En outre, une quelconque observation de prix Pi est liée à une série de variables explicatives. Pour des billets d'avion par exemple, ces variables 15 explicatives comprennent le nom de la compagnie aérienne, des caractéristiques de dates (par exemple fin de semaine, vacances, milieu de semaine, etc.), la durée du vol, la ville de départ, la ville d'arrivée, etc.). Le nombre et la description des variables explicatives sont prédéfinis à la conception du système, selon l'application, et peuvent bien entendu 20 largement varier. Grâce au regroupement sur les données de prix, les variables explicatives sont également regroupées. Par exemple, un vol donné d'une compagnie donnée, à une date donnée, va être affecté à un groupe donné. Les variables explicatives qui ne jouent pas de rôle dans la différentiation des 25 classes ne sont pas exploitées ici, car elles n'apportent pas d'information utile dans le processus. Les autres sont bien entendu exploitées. De la même manière qu'une classification a été réalisée sur l'information de tendance (filtrée) Xi, une classification est mise en oeuvre sur la volatilité Xi. Dans une réalisation préférée de l'invention, un algorithme de 30 regroupement par k-moyennes est à nouveau utilisé, étant toutefois observé qu'ici encore d'autres algorithmes de classification automatique connus de l'homme du métier peuvent être utilisés. Cette classification ne peut cependant pas être effectuée directement sur le signal Xi pour lequel une classification selon les moindres carrés n'aurait pas de sens. Pour cela, le signal Xi est décomposé en plusieurs périodes (typiquement une dizaine de jours) et la variance de Xi est calculée sur chaque période. On associe donc à Xi une série {Di,1, Di,p} où p est le nombre de périodes, et Di,p la variance de volatilité sur la période p. La classification est donc réalisée sur ces séries de variances. De la même manière que pour les tendances, les variables 10 explicatives sont regroupées (ce regroupement est le plus souvent différent du regroupement réalisé pour les tendances). b) si l'on s'intéresse maintenant à une nouvelle observation, cette nouvelle observation est par nature partielle, car le système ne connaît pas l'ensemble des prix en fonction du temps (étant rappelé que l'on cherche 15 précisément à prévoir le comportement futur des prix). A partir des variables explicatives des tendances, l'observation peut être affectée à un ensemble de classes de tendances. De même, l'observation peut être affectée à un ensemble de classes de volatilité. Et à partir des caractéristiques de ces classes, il est possible de calculer la probabilité que le prix franchisse vers le 20 bas la valeur seuil (prix plafond) définie par l'acheteur. On note Pi,k la probabilité d'appartenance à la classe k d'un élément correspondant à la variable explicative i. Pi,k est calculée de la manière suivante : Nbre d'éléments de la variable explicativ e i E Sk 25 avec 1Pi k '1 k On s'intéresse maintenant à la manière dont l'indicateur IPS peut être calculé. Dans un souci de simplicité, nous ne prendrons pas en compte la volatilité dans un premier temps. Supposons que l'on considère une variable explicative i (par exemple 30 une compagnie donnée), et qu'un prix limite a été donné, 7C, valide entre les Pi,k Nbre total d'éléments de la variable explicativ e i dates di et df, On désigne par /die (Ck c)la fonction indicative telle que di ,df k 7)= 1 si Ck passe par une valeur inférieure à 7C sur la plage de dates di à df, et I ,df k 7r)= 0 dans le cas contraire. L'indicateur IPS, pour le prix 7C , sachant la variable explicative i, s'écrit alors : I PS(rli) I di ,df k Cette formule peut aisément être généralisée au cas d'un plus grand nombre de variables explicatives. Les Figures 4 et 5 illustrent l'identification des classes par les variables explicatives et leurs pondérations en fonction 10 de la densité des variables explicatives. La volatilité est prise en compte en utilisant de la même manière la correspondance avec les variables explicatives. Selon la probabilité d'appartenir à une classe de volatilité, la variance de la volatilité peut être calculée sur chaque période. On considère alors qu'une variable aléatoire 15 gaussienne centrée et de variance égale à la variance calculée est ajoutée aux valeurs de Ck : l'indicateur IPS est alors calculé comme la probabilité que cette somme soit inférieure à 7C . . Cette prise en compte séparée de l'information de tendance et de volatilité est un élément particulier de l'invention. Elle traduit le fait que, selon les observations qui ont pu être 20 effectuées, la tendance de prix est un choix stratégique a priori de la compagnie, tandis que la volatilité caractérise une réponse à un taux d'occupation. Cette réponse n'étant pas liée à la tendance, il est pertinent de la considérer séparément. Jusqu'à ce stade, l'indicateur de probabilité de succès est calculé a 25 priori, c'est-à-dire sans utiliser aucune donnée de l'observation de prix courante (seules les variables explicatives étant utilisées). C) supposons maintenant que le système connaît une partie de l'évolution des prix, ou doit mettre à jour le calcul de l'indicateur pendant la période de validité d'ordre d'achat correspondant à l'observation (dans la 30 présente architecture, cette observation provient du cache du moteur d'options 0E). Cette observation même partiellement connue, peut être affectée à un certain groupe en calculant une distance entre l'observation et les différents motifs d'évolution les plus probables Ck (les tendances). En fonction de la part connue d'information, le système combine une attribution a priori (par les variables explicatives) et une attribution par les distances, de préférence de façon pondérée. La pondération tient compte de la quantité d'informations connue, elle-même représentée par position de la date courante par rapport aux dates de début et de fin de l'ordre. Soient les hypothèses suivantes : - dt est la date courante, di est la date initiale de l'ordre et df est la date finale de l'ordre, avec di Chaque vendeur ou revendeur dispose de son propre domaine dédié, et ne peut vérifier que les ordres d'achat correspondant à ses propres produits ou services, et pas à ceux des concurrents. Par exemple, un gestionnaire des ventes d'une compagnie aérienne A peut consulter seulement les ordres d'achat sur les vols de sa propre 30 compagnie aérienne, et pas les ordres d'achat sur les vols des compagnies concurrentes B ou C. 4.2 Présentation en push vers les vendeurs ou revendeurs La plateforme de vente peut automatiquement fournir les détails des ordres d'achat aux différents vendeurs ou revendeurs. Un rapport des ordres est par exemple produit quotidiennement pour chaque vendeur, avec la liste et le détail des ordres actifs pour les produits ou services du vendeur considéré. 4.3 Modification du prix par les vendeurs ou revendeurs Une fois que les vendeurs ont accès aux détails des ordres d'achat, ils peuvent réaliser des transactions sur leurs produits ou services invendus ou difficiles à vendre, ceci en diminuant leur prix de vente selon deux mécanismes différents : a) modification du prix « public » Après avoir vérifié les prix des ordres d'achat pour les produits ou services qu'il propose, un site marchand peut diminuer le prix « public » ou « officiel » pour certains produits ou services mal vendus. Du fait que la plateforme de vente vérifie régulièrement les prix « publics » des vendeurs ou revendeurs, les produits ou services considérés seront vendus dès lors que prix de vente a diminué jusqu'au prix des ordres d'achat. Par exemple, supposons qu'une compagnie aérienne A a des difficultés à vendre certains sièges à 550 E sur un vol spécifique. Après avoir déterminé qu'un ordre d'achat existe sur un prix plafond de 500 E, la compagnie A peut diminuer (de façon manuelle ou assistée par un moteur de décision) son prix public à 500 E. La plateforme va alors automatiquement acheter le billet à ce prix, puisque les prix publics sont vérifiés de façon régulière. b) modification du prix « privé » Certains vendeurs ou revendeurs peuvent rencontrer des difficultés à 30 baisser leur prix public, dans la mesure où tous les acheteurs peuvent observer la baisse du prix public, et où les concurrents peuvent également décider de baisser leurs prix, le système aboutissant alors à une guerre des prix économiquement néfaste. Certains vendeurs peuvent ainsi préférer vendre leurs produits ou services à un prix abaissé dans différents circuits de distribution, appliquant 5 un prix « privé » qui est un prix négocié entre le vendeur et son distributeur. Après avoir vérifié le prix des ordres d'achat de ses produits ou services, un vendeur peut ainsi diminuer le prix « privé » de certains produits ou services invendus sur la plateforme de vente. Si cette diminution atteint le prix plafond de l'ordre d'achat, le vendeur s'assure ainsi que la vente soit 10 réalisée de façon immédiate et automatique sur la plateforme. Dans l'exemple précédent, la compagnie aérienne A accepte de diminuer le prix « privé » à 500 E sur la plateforme de vente, alors que son prix « public » reste à 550 E. La vente à 500 E est néanmoins réalisée immédiatement et automatiquement. 15 On notera ici que la fourniture de listes d'ordres d'achat à des vendeurs peut être fournie moyennant une contrepartie, dans la mesure où elle est susceptible d'accroître la profitabilité des opérations du vendeur. 5. Avantages 20 Les avantages principaux du système de l'invention sont les suivants : a) le système opère de manière automatique et immédiate : dès que le vendeur marque son accord sur le prix d'un ordre d'achat, la transaction est effectuée automatiquement et immédiatement sur la plateforme marchande ; b) l'accord du vendeur sur le prix d'un ordre d'achat n'est pas public, 25 et le prix est considéré comme un prix « privé »; de la sorte, le prix « public » ou « officiel » du produit ou du service n'est pas modifié ; c) le système est profitable aux vendeurs ; en effet, dans la mesure où les vendeurs peuvent connaître à quel prix ils seraient susceptibles de commercialiser leurs invendus ou leurs produits ou services difficiles à 30 vendre, ils peuvent minimiser la baisse de leur prix pour simplement satisfaire les ordres d'achat existants. 6. Exemple d'application du système pour l'achat de billets d'avion Dans le cas particulier des billets d'avion, l'acheteur peut sélectionner avec précision, outre les aéroports de départ et d'arrivée et des créneaux de dates et un prix maximum, un nombre de maximal de vols à inclure dans son ordre. L'indicateur de probabilité de succès est calculé et envoyé au poste client en temps quasi-réel pour informer l'acheteur de la probabilité d'obtenir l'un des vols au prix maximum fixé. 6.1 Définition des classes Pour implémenter l'indicateur de probabilité de succès IPS, la première étape du procédé consiste à déterminer les différentes classes pour chaque itinéraire (à savoir un trajet aérien entre deux villes), sur la base de l'observation des historiques de prix des vols dans le passé. Les observations de prix sont rassemblées dans une base de données spécifique et sont liées aux variables explicatives (le transporteur, les dates de départ et d'arrivée, l'horaire), comme illustré à titre d'exemple sur la Figure 7 pour cinq observations xl , x2, x3, x4, x5 avec les variables explicatives associées. Chaque observation de prix est mémorisée dans la base de données 20 et mène pour les cinq observations xl , x2, x3, x4 et x5 à des courbes de prix telles qu'illustrées à titre d'exemple sur la Figure 8. Sur la base de l'équation du vecteur de données de prix Pi = Xi + Vi, l'algorithme traite chaque observation de prix pour déterminer les éléments suivants : 25 - la tendance du prix (x), qui est définie par un filtrage passe-bas ; on peut utiliser par exemple une moyenne mobile des prix sur 3 à 5 jours ; - la volatilité du prix (y), qui peut être définie par plusieurs valeurs statistiques (en particulier gamme mini-maxi de fluctuation, pourcentage d'augmentation et de baisse, augmentation et baisse maximales, etc.) sur de 30 courtes périodes, par exemple sur 5 jours. Le processus algorithmique délivre donc pour chaque classe une tendance liée à une volatilité, le tout pour un ensemble de variables explicatives propres à la classe considérée. Pour continuer sur l'exemple précédent, les observations de prix x1, 5 x2, x3, x4 et x5 mènent à la détermination d'une classe correspondante Si dont la tendance est illustrée sur la Figure 9. Les variables explicatives attachées à cette classe Si rassemblent les caractéristiques signifiantes pour cette classe, comme illustré à titre d'exemple sur la Figure 10. 10 6.2 Attribution d'un vol à une classe de tendance Lorsqu'un acheteur sélectionne des vols et les inclut dans un ordre d'achat, chaque vol est automatiquement identifié par ses variables explicatives principales. Par exemple, un vol Paris-Madrid est défini comme 15 illustré sur la Figure 11. Au sein de la base de données des classes par trajet, un programme recherche les classes de tendance les plus proches des variables explicatives. On rappelle ici que plusieurs classes peuvent être ici trouvées, on pondère alors selon la densité de la variable explicative dans chaque 20 classe trouvée. Au sein de la base de données des observations historiques de prix, les prix du passé récent pour le trajet considéré sont alors extraits. Si les données sont suffisamment abondantes, cette observation des prix passés peut être exploitée. Par exemple, l'observation des prix récents peut avoir 25 l'allure illustrée sur la Figure 12. Cette observation est alors traitée pour obtenir la tendance et la volatilité comme décrit plus haut. La tendance est illustrée sur la Figure 13. Dans le présent exemple, c'est la classe Si qui est identifiée par les variables explicatives et par les tendances et la volatilité de l'observation des 30 prix récents. L'évolution du prix pour le trajet considéré peut ainsi être prédite, et l'indicateur de probabilité de succès IPS peut être calculé. Dans le présent exemple, à J-42 (42 jours) avant le départ, le prix courant est de 270 E. La prévision donnée par la classe Si est une tendance horizontale associée à une volatilité importante dans une gamme de prix comprise entre 230 E et 270 E. L'indicateur de probabilité de succès est donc élevé pour un ordre d'achat avec un prix plafond supérieur à 230 E, et faible pour un ordre d'achat avec un prix plafond inférieur à 230 E. 7. Exemple d'application du système pour l'achat de nuitées d'hôtel Dans le cas particulier des hôtels, un acheteur peut sélectionner les hôtels précis à inclure dans l'ordre d'achat, les dates, et bien entendu un prix plafond. L'indicateur de probabilité de succès est calculé et transmis au poste client pour affichage en temps quasi-réel pour informer l'acheteur des chances d'obtenir une chambre dans l'un des hôtels sélectionnés à ce prix. 7.1 Définition des classes Pour implémenter l'indicateur de probabilité de succès IPS, la première étape consiste à déterminer les différentes classes pour chaque ville, sur la base des observations des prix historisés dans le passé. Ces observations de prix sont rassemblées dans une base de données spécifique et liées aux variables explicatives (la référence de l'hôtel, les dates d'arrivée et de départ, le type de chambre, etc.) comme illustré à titre d'exemple sur la Figure 14. Chaque observation de prix est mémorisée dans la base de données et permet d'établir une courbe de prix, comme illustré à titre d'exemple sur la Figure 15. Le processus algorithmique délivre en sortie des classes qui sont déterminées par la combinaison d'une tendance spécifique en liaison avec 30 une volatilité de prix et les variables explicatives. En relation avec l'exemple ci-dessus, les observations de prix x1, x2, x3 mènent à la détermination de classes Si et S2, dont les tendances sont illustrées sur la Figure 16. Les variables explicatives attachées à ces classes Si et S2 5 rassemblent les caractéristiques signifiantes, comme illustré sur la Figure 17. 7.2 Affectation d'un ordre d'achat à une classe Lorsqu'un acheteur sélectionne les hôtels et les inclut dans un ordre d'achat, chaque hôtel est automatiquement identifié par ses variables 10 explicatives principales. Par exemple, un hôtel est défini comme illustré sur la Figure 18. Au sein de la base de données de classes par ville, une routine recherche les classes les plus proches correspondant aux variables explicatives. Cette routine peut identifier plusieurs classes, qui sont alors 15 triées par priorité (la classe la plus proche en premier). Dans cet exemple, la classe S2 est identifiée par les variables explicatives. Dans la base de données des observations de l'historique des prix, les prix passés récents de l'hôtel sont extraits. Si les données sont suffisamment abondantes, l'observation de prix peut être utilisée et analysée. Par exemple, 20 l'observation des prix récents peut être comme illustré sur la Figure 19. Cette observation conduit à une tendance illustrée sur la Figure 20 et reconnue comme étant la classe Si. Dans cet exemple, l'observation des prix récents conduit à une classe différente (Si) de celle identifiée par les variables explicatives a priori (S2). 25 L'indicateur de probabilité IPS peut alors être calculé en utilisant la formule suivante pour prendre en compte une pondération entre la classe identifiée par les prix récents et celle identifiée par les variables explicatives : . dt -di df IPS(rli3Obs(ch,d0)= df di I dt' df J± I dt,df kLik - df -di Ainsi l'évolution du prix peut faire l'objet d'une prévision, et l'indicateur 30 de probabilité de succès peut être calculé. Dans le présent exemple, à J-45 avant le départ, le prix courant est de 300 E. La prévision donnée par la classe Si est une tendance C1 horizontale avec une fluctuation des prix entre 250E et 350E, et S2 est une tendance C2 horizontale associée à une volatilité importante avec une gamme de prix comprise entre 175 et 225 E. L'indicateur IPS se calcule donc de la façon suivante, en considérant une observation des prix de 15 jours (sur 60 jours avant le départ), soit di=0, dt=15 et df=60 : \\ 45 , IPS(7r1i3Obs(di,dt»=dt df /es c )± - 60 I dt' df irs 2 60 ' Or pour 7C 250, ledf(C1 7r) = 1 Pour 7C 175 / dt,df (C 2 7r) - Donc pour 7C 250, IPS = 100% Bien entendu, la présente invention n'est nullement limitée aux formes de réalisation décrites et représentées, mais l'homme du métier saura y apporter de nombreuses variantes et modifications. En particulier : - le système peut s'appliquer non seulement à des ordres d'achat de produits ou services à prix plafond, mais également à des ordres de vente de 25 produits ou services à prix plancher ; - l'architecture générale du système peut être différente de celle décrite. REVENDICATIONS1. Système informatique de gestion d'ordres de transactions avec valeur de contrepartie limite, notamment un prix d'achat plafond, pour des produits 5 ou services, caractérisé en ce qu'il comprend : - une source d'informations répertoriant les produits ou services disponibles et des variables explicatives pour ces produits ou services, ainsi que des informations de contrepartie proposée variables en fonction du temps pour ces produits ou services, 10 - un moteur de classification automatique apte à regrouper des produits ou services par classes d'évolution de leur contrepartie, à partir d'historiques de contreparties, et à affecter à chaque classe des gammes de variables explicatives et des valeurs d'évolution, - des moyens d'interface client pour saisir des ordres sur des produits 15 et services données en fixant une contrepartie limite, - un moteur d'affectation d'un ordre saisi à une classe d'évolution en fonction des variables explicatives de l'ordre au regard des gammes de variables explicatives des différentes classes, et - un moteur de calcul d'un indicateur d'une probabilité de succès d'un 20 ordre saisi, en combinant la valeur de la contrepartie limite de cet ordre avec les valeurs d'évolution de la classe à laquelle il a été attribué. - et un moteur de confrontation des offres et des contreparties offertes pour convertir des offres en transactions lorsque des contreparties proposées atteignent des contreparties limites. 25 2. Système selon la revendication 1, dans lequel les classes d'évolution comprennent une des classes de tendance et des classes de volatilité. 3. Système selon la revendication 1 ou 2, dans lequel le moteur de calcul 30 de l'indicateur est apte à recalculer un indicateur de façon périodique pendant la période de validité de l'offre. 4. Système selon la revendication 3, dans lequel pour les calculs périodiques, le moteur de calcul de l'indicateur est apte à mettre en oeuvre une pondération de la probabilité par rapport à une classe identifiée a priori à l'aide des variables explicatives et par rapport à une classe identifiée par l'évolution réelle observée des contreparties pour l'ordre considéré dans la période de validité de l'ordre. 5. Système selon la revendication 4, dans lequel la pondération prend en 10 compte la quantité d'informations de l'évolution réelle observée. 6. Système selon la revendication 5, dans lequel la pondération est basée sur la date courante par rapport à la date de début et la fin de l'ordre considéré. 15 7. Système selon la revendication 6, dans lequel les moyens d'interface client sont aptes à recevoir une nouvelle valeur de contrepartie limite pendant la période de validité de l'offre, le moteur de calcul de l'indicateur répondant à cette nouvelle valeur reçue en recalculant la valeur dudit 20 indicateur en temps quasi-réel. 8. Système selon l'une des revendications 1 à 7, comprenant en outre un dispositif de gestion de la priorité des ordres. 25 9. Système selon la revendication 8, dans lequel le dispositif de gestion de priorité comprend des moyens d'ordonnancement des ordres selon au moins deux critères parmi des informations de fidélité des entités saisissant des ordres, des informations de quantité de produits ou services demandés dans les ordres, et des informations de contrepartie limite. 30 10. Système selon l'une des revendications 1 à 9, dans lequel chaque nouvel ordre donne lieu à une confrontation par le moteur de confrontation sur la base d'une requête vers la source d'informations en vue d'obtenir une contrepartie proposée, et comprenant également une mémoire cache de contreparties proposées en vue d'éviter de multiplier les requêtes pour une série d'offres sur le même produit ou service à des contreparties identique ou inférieures. 11. Système selon la revendication 10, lequel comprend des moyens pour 10 envoyer de nouvelles requêtes pour des contreparties proposées, en vue de confronter d'autres ordres sur un produit ou service donné, lorsqu'une offre a été convertie en transaction sur ledit produit ou service. 12. Système selon l'une des revendications 1 à 11, lequel comprend des 15 moyens réducteurs (MapReduce) pour engendrer la source d'informations à partir d'informations brutes. 13. Système selon l'une des revendications 1 à 12, lequel comprend en outre un moteur d'agrégation d'ordres actifs sur un produit ou service donné, 20 et des moyens de communication entre le moteur d'agrégation et la plateforme d'un offreur du produit ou service donné lui permettre d'accéder à ces ordres agrégés. 14. Système selon la revendication 13, lequel comprend en outre des 25 moyens d'ajustement de la contrepartie proposée pour le produit ou service donné en fonction des valeurs de contreparties limites contenues dans les ordres agrégés.