FR 3071340 A1 20190322 FR 1758607 A 20170918 PROCEDE ET DISPOSITIF DE TRAITEMENT DE REQUETE, DE MISE A JOUR ET DE FOURNITURE DE DONNEES EXTRAITES D'UNE MEMOIRE CACHE Domaine de l'invention L'invention concerne de manière générale les architectures client/serveur et en particulier un procédé et dispositif de traitement de requête, de mise a jour et de fourniture de données extraites d'une mémoire cache. Etat de la technique Dans un dispositif serveur fournisseur de produits, basé sur une architecture client/serveur, un utilisateur peut soumettre une requête depuis un dispositif client (dispositif utilisateur) à un dispositif serveur via un réseau de communication pour obtenir un produit. La requête comprend un ensemble de paramètres de requêtes pouvant être obligatoires ou optionnels. Le dispositif serveur traite alors la requête pour déterminer un ensemble de produits candidats satisfaisant au mieux au moins certains des paramètres de la requête, chaque produit candidat ayant une valeur numérique représentant le prix du produit. Certains systèmes fournisseurs de produits délivrent des produits associés à une date de produit, comme par exemple un système fournisseur de voyage délivrant des produits de voyage tels que des billets d'avion, la valeur du produit étant alors la valeur du billet à l'instant de traitement de la requête par le dispositif serveur. Une requête de voyage reçue par un tel système fournisseur de voyage comprend généralement une origine, une destination et une date de voyage. Dans un exemple d'application à l'industrie du voyage, le dispositif serveur fournisseur de produits peut être un système de type GDS (« Global Distribution System », ou Système de Distribution Global) permettant aux 2 utilisateurs de réserver et d'acheter des produits de voyage tels que des billets d'avion, de train ou encore des nuitées d'hôtel, en ayant accès directement aux données fournies par le fournisseur de voyage (qui peut être par exemple, une compagnie aérienne dans le cas d'une réservation de billet 5 d'avion). Les systèmes informatiques fournisseurs de produits peuvent utiliser des algorithmes d'optimisation en fonction de différentes données (les algorithmes d'optimisation sont encore appelés algorithmes de Gestion des Recette ou « Revenue Management » en langue anglo-saxonne). Par suite, le 10 prix du billet peut varier dans le temps, c'est-à-dire augmenter ou diminuer entre la date de traitement de la requête et la date de voyage effective. L'utilisateur sait généralement que pour une origine et une destination données, le prix du billet peut être différent selon la date de voyage. 15 L'utilisateur, qui a identifié un produit de voyage suite à une première requête, peut, pour différentes raisons, vouloir attendre le plus possible avant d'acheter un billet d'avion à un prix donné, ou savoir plus généralement quand acheter un billet au meilleur prix. Ainsi, à la suite d'une première requête lui proposant un produit de voyage satisfaisant sa requête, l'utilisateur ne sait pas si le prix 20 affiché restera le même, s'il va augmenter ou baisser prochainement, et de combien. Par exemple, si l'utilisateur souhaite acheter un billet Paris CDG - New-York JFK pour un départ le 15 août 2017 et un retour le 30 août 2017, l'utilisateur peut constater que le billet est à un prix de 400 euros le 1er mars, qu'il passe ensuite à un prix de 500 euros le 1er avril, puis augmente fortement 25 pour arriver à un prix de 650 euros à partir du 1er août. Pour optimiser le prix d'achat de son billet, l'utilisateur peut tenter de consulter des données statistiques ou utiliser sa propre expérience d'achats précédents. De la sorte, l'utilisateur peut par exemple se rendre compte, avant d'acheter son billet, qu'il risque de payer son billet plus cher s'il part en été, début octobre ou fin décembre, plutôt que le reste de l'année. En revanche, l'utilisateur ne dispose pas d'informations relatives à la stabilité d'un prix 3 annoncé, pour une origine, une destination et une date données, et pour une même compagnie. Il ne dispose également pas d'informations sur le(s) moment(s) de l'année où le prix du billet est le plus bas. Le prix peut varier en effet au cours du temps, selon la politique de « revenue management » (ou 5 « gestion des recettes ») qu'applique la compagnie aérienne. Le plus souvent, l'utilisateur est donc amené à vérifier régulièrement l'évolution du prix du billet avant de finaliser son achat. Ainsi, il arrive souvent que les utilisateurs, depuis leurs dispositifs clients, consultent à de très nombreuses reprises le prix du billet qui les intéresse, en émettant à chaque fois une nouvelle requête 10 utilisateur au dispositif serveur (système fournisseur de voyage), la fréquence d'émission de telles requêtes par l'utilisateur pouvant augmenter fortement à certaines périodes, notamment lorsque l'utilisateur a une date cible pour finaliser son achat. L'utilisateur peut ainsi effectuer la même requête à plusieurs dates plus ou moins rapprochées, voire plusieurs fois par jour, pour 15 vérifier que le billet n'a pas augmenté depuis la dernière requête. Ce sont autant de nouvelles requêtes qui impliquent des milliers de transactions additionnelles par rapport à la requête initiale qui a déjà été effectuée, à une date précédente. De telles requêtes consomment énormément de ressources du côté du dispositif serveur (système fournisseur de voyage), l'exécution de 20 chaque requête par le dispositif serveur ayant en soi un coût computationnel très élevé, notamment en raison des calculs de combinaisons tarifaires et des interactions avec les différents systèmes inventaires des compagnies aériennes. 25 Des solutions ont été proposées pour tenter de limiter l'utilisation de ressources informatiques du système de réservation, comme par exemple le procédé de la demande US2015/0012469 Al. Dans le procédé proposé dans la demande US2015/0012469 A1, la pertinence des informations de vols enregistrées est régulièrement évaluée, selon différents critères de 30 cohérence, tels que le nombre d'escales, la compagnie aérienne proposée, la classe de réservation. Toutefois, une telle solution ne permet pas à l'utilisateur d'avoir accès à une estimation de l'évolution du prix d'un billet. 4 Il existe donc un besoin pour un procédé et un dispositif amélioré de traitement des requêtes capable d'optimiser les ressources du dispositif serveur. 5 Définition générale L'invention se rapporte pour cela à un dispositif de traitement de requête, implémenté dans un dispositif serveur, la requête identifiant des 10 paramètres de requêtes et étant reçue depuis un dispositif client connecté audit dispositif serveur, la requête étant traitée par le dispositif serveur à une date donnée dite date de requête. Le dispositif comprend une unité de traitement configurée pour déterminer un ensemble des produits candidats satisfaisant au moins certains des paramètres de ladite requête, chaque 15 produit candidat étant associé à une valeur numérique courante représentant la valeur courante du produit candidat à la date de requête, chaque produit étant en outre associé à une date de produit, postérieure à ladite date de requête. Le dispositif comprend en outre : - Un comparateur configuré pour comparer la valeur courante de 20 chaque produit candidat avec une valeur de référence mémorisée dans une mémoire cache, connectée audit dispositif serveur, la valeur de référence étant une valeur dudit produit déterminée par le dispositif serveur à une date antérieure à ladite date de requête, dite « date de référence », la date de référence ayant le même quantième et le même mois que ladite date de 25 requête, et - Une unité de mise à jour configurée pour mettre à jour la valeur de référence mémorisée dans ladite mémoire cache en lui affectant la valeur courante du produit, si la valeur courante est différente de la valeur de référence, ou s'il n'y a pas de valeur de référence dans ladite mémoire cache. 30 Selon un autre aspect de l'invention, le dispositif est configuré pour retourner une réponse au dispositif client comprenant l'ensemble des produits 5 candidats déterminés, et pour chaque produit candidat la valeur courante du produit et des données extraites de la mémoire cache associées au produit. Avantageusement, le dispositif peut être configuré pour prédire la 5 stabilité temporelle de la valeur courante du produit candidat à la date de requête, déterminée à partir de la date de requête et de la date à laquelle la valeur de référence varie par rapport à la valeur courante, si la valeur courante du produit candidat est égale à la valeur de référence. 10 Dans un mode de réalisation, les données extraites de la mémoire cache associées au produit peuvent comprendre au moins une date dite de prédiction, sélectionnée parmi l'ensemble des dates associées respectivement à l'ensemble valeurs de référence et situées entre la date de requête et la date de produit, la date de prédiction correspondant à la date à 15 laquelle la valeur de référence est minimale. Avantageusement, les données extraites de la mémoire cache associées au produit peuvent comprendre en outre une estimation temporelle du délai entre la date de prédiction et la date à laquelle la valeur de référence 20 associée à la date de prédiction varie. Dans un mode de réalisation, les données extraites de la mémoire cache associées au produit peuvent comprendre la valeur de référence associée à la date de prédiction. 25 Dans certains modes de réalisation, le dispositif serveur peut être configuré pour contrôler l'affichage des données extraites de la mémoire cache associées au produit sur une interface graphique d'un site Internet. 30 En particulier, les paramètres de la requête peuvent comprendre au moins un aéroport d'origine et un aéroport de destination. 6 L'invention propose également à un procédé de traitement de requête, dans un dispositif serveur, la requête identifiant des paramètres de requêtes et étant reçue depuis un dispositif client connecté audit dispositif serveur, la requête étant traitée par le dispositif serveur à une date donnée 5 dite date de requête, le procédé comprenant les étapes consistant à: - déterminer un ensemble des produits candidats satisfaisant au moins certains des paramètres de ladite requête, chaque produit candidat étant associé à une valeur numérique courante représentant la valeur courante du produit candidat à la date de requête, chaque produit étant en 10 outre associé à une date de produit, postérieure à ladite date de requête, le procédé comprenant en outre, pour chaque produit candidat, une étape consistant à: - comparer la valeur courante du produit candidat avec une valeur de référence mémorisée dans une mémoire cache, connectée audit dispositif 15 serveur, la valeur de référence étant une valeur dudit produit déterminée par le dispositif serveur à une date antérieure à la dite date de requête, dite « date de référence », la date de référence ayant le même quantième et le même mois que ladite date de requête, et à - mettre à jour la valeur de référence mémorisée dans la mémoire 20 cache en lui affectant la valeur courante du produit, si la valeur courante est différente de la valeur de référence, ou s'il n'y a pas de valeur de référence dans ladite mémoire cache. Le procédé comprend en outre une étape consistant à retourner une réponse au dispositif client comprenant l'ensemble des produits candidats 25 déterminés, et pour chaque produit candidat la valeur courante du produit et des données extraites de la mémoire cache associées au produit. Avantageusement, si la valeur courante du produit candidat est égale à la valeur de référence, les données extraites de la mémoire cache 30 associées au produit peuvent comprendre une prédiction de la stabilité temporelle de la valeur courante du produit candidat à la date de requête, 7 déterminée à partir de la date de requête et de la date à laquelle la valeur de référence varie par rapport à la valeur courante. Avantageusement, les données extraites de la mémoire cache 5 associées au produit peuvent comprendre au moins une date dite de prédiction, sélectionnée parmi l'ensemble des dates associées respectivement à l'ensemble valeurs de référence et situées entre la date de requête et la date de produit, la date de prédiction correspondant à la date à laquelle la valeur de référence est minimale. 10 Avantageusement, les données extraites de la mémoire cache associées au produit peuvent comprendre en outre une estimation temporelle du délai entre la date de prédiction et la date à laquelle la valeur de référence associée à la date de prédiction varie. 15 Dans un mode de réalisation, les données extraites de la mémoire cache associées au produit peuvent comprendre la valeur de référence associée à la date de prédiction. 20 Dans un mode de réalisation, un affichage des données extraites de la mémoire cache associées au produit peut être généré sur une interface graphique d'un site Internet. En particulier, les paramètres de la requête peuvent comprendre au 25 moins un aéroport d'origine et un aéroport de destination. L'invention propose en outre un produit-programme d'ordinateur pour le traitement d'une requête, le produit-programme d'ordinateur comprenant un support durable de stockage de données lisibles par ordinateur et un code de 30 programme enregistré sur le support durable de stockage lisible par ordinateur qui, lorsqu'il est exécuté par un ou plusieurs processeurs, amène le ou plusieurs processeurs à exécuter les étapes du procédé précité. 8 Description des figures D'autres caractéristiques, détails et avantages de l'invention 5 ressortiront à la lecture de la description faite en référence aux dessins annexés donnés à titre d'exemple et qui représentent, respectivement : la figure 1 illustre schématiquement les interactions entre un dispositif client et le dispositif serveur mettant en oeuvre l'invention ; - la figure 2 illustre schématiquement la composition du dispositif 10 client et du dispositif serveur ; - la figure 3 illustre schématiquement l'architecture du dispositif serveur selon l'invention ; la figure 4 illustre schématiquement l'architecture de la mémoire cache ; 15 - la figure 5 illustre schématiquement les différentes étapes de création et de mise à jour de chaque cellule de stockage de la mémoire cache; - la figure 6 illustre en détail les différentes étapes de mise à jour des cellules de stockage de la mémoire cache ; 20 - la figure 7 illustre une interface graphique du côté du dispositif client, pour un premier cas d'usage ; - la figure 8 illustre un exemple d'histogramme correspondant au premier cas d'usage ; - la figure 9 illustre une interface graphique du côté du dispositif 25 client, pour un deuxième cas d'usage ; et la figure 10 illustre un exemple d'histogramme correspondant au deuxième cas d'usage. Description détaillée 30 La figure 1 représente schématiquement un exemple d'environnement dans lequel l'invention peut être mise en oeuvre, selon certains modes de 9 réalisation. L'environnement comprend au moins un dispositif client 100 et un dispositif serveur 90 connectés via un réseau de communication. Sur la figure 1, un seul dispositif client 100 est représenté. Toutefois, en variante, et de façon connue, l'environnement peut comprendre une pluralité de dispositifs 5 clients 100. Le dispositif client 100 peut être associé à une pluralité de systèmes d'agences de voyages émettant des requêtes de services via des interfaces clientes respectives. Chaque système de gestion de voyages peut en outre être connecté à différents types de dispositifs clients soumettant différents types de demandes (ou requêtes) selon une approche 10 client/serveur, tels que des dispositifs utilisateurs (ou voyageurs) via des interfaces utilisateurs respectives. Chaque système de gestion de voyages peut également être connecté à un ou plusieurs systèmes de fournisseurs de voyages. Dans une application préférée de l'invention à l'industrie du voyage, lorsqu'un utilisateur souhaite réserver un billet d'avion par exemple, il peut 15 soumettre une requête 80, depuis un dispositif utilisateur (par exemple un ordinateur, une tablette ou un téléphone) muni d'un terminal de saisie et d'un dispositif affichage 100 via une interface graphique dédiée, en spécifiant une origine, une destination, et une date de départ. La requête 80 est alors transmise au dispositif serveur 90 via un réseau de communications 25. Le 20 réseau 25 peut inclure des portions d'un ou de plusieurs réseaux privés ou publics (par ex., Internet, un réseau virtuel privé, un réseau local, un réseau étendu, un réseau de téléphone cellulaire, etc.) fournissant une interconnexion et facilitant l'échange de données contenant des informations. En réponse à la requête, le dispositif serveur 90 calcule alors une liste de 25 produits de voyages 70, comprenant les différentes options de voyage disponibles satisfaisant la requête, chaque option étant associée à un prix représentant le prix de l'option de voyage. Le dispositif serveur 90 retourne ensuite les options de voyage à l'utilisateur via l'interface utilisateur dédiée. Ainsi, le dispositif serveur 90 est capable de retourner la liste 70 des options 30 de voyage calculées quelque temps après la saisie de la requête 80, via le réseau de communications 25. Dans les systèmes actuels de fourniture de voyage basés sur des architectures client/serveur, il est souhaitable que le 10 délai entre la saisie de la requête et le retour des résultats soit plus bref possible pour optimiser l'expérience utilisateur. Le dispositif serveur 90 et/ou les dispositifs client 100 peuvent être 5 implémentés sur un ou plusieurs ordinateurs, tels que l'ordinateur 30, comme représenté sur la figure 2. L'ordinateur 30 peut comporter un processeur 32, une mémoire 34, un dispositif de mémoire de stockage de masse 36, une interface d'entrée/sortie (I/O) 38 et une Interface Homme-Machine (IHM) 40. L'ordinateur 30 peut également être couplé de manière fonctionnelle à une ou 10 plusieurs ressources externes 42 via le réseau 25 et/ou une interface I/O 38. Des ressources externes peuvent inclure, mais sans y être limitées, des serveurs, des bases de données, des dispositifs de stockage de masse, des dispositifs périphériques, des services de réseau à base de nuage, ou toute autre ressource informatique appropriée qui peut être utilisée par l'ordinateur 15 30. Le processeur 32 peut inclure un ou plusieurs dispositifs sélectionnés parmi les microprocesseurs, les microcontrôleurs, les processeurs de signaux numériques, les micro-ordinateurs, les unités centrales de traitement, les réseaux prédiffusés programmables par l'utilisateur, les dispositifs logiques programmables, les machines d'état, les circuits logiques, les circuits 20 analogiques, les circuits numériques, ou d'autres dispositifs qui manipulent des signaux (analogiques ou numériques) en fonction d'instructions d'opérations qui sont stockées dans la mémoire 34. La mémoire 34 peut inclure un seul dispositif mémoire ou une pluralité de dispositifs mémoire incluant, mais sans y être limités, une mémoire morte (ROM), une mémoire 25 vive (RAM), une mémoire volatile, une mémoire non volatile, une mémoire à accès aléatoire statique (SRAM), une mémoire à accès aléatoire dynamique (DRAM), une mémoire flash, une mémoire cache, ou tout autre dispositif capable de stocker des informations. Le dispositif de mémoire de stockage de masse 36 peut inclure des dispositifs de stockage de données tels qu'un 30 disque dur, un disque optique, un lecteur de cassette, un dispositif à semiconducteurs non volatile, ou tout autre dispositif capable de stocker des informations. Une base de données 44 peut résider sur le dispositif de 11 mémoire de stockage de masse 36, et peut être utilisée pour collecter et organiser des données utilisées par les différents systèmes et modules décrits ici. Le processeur 32 peut fonctionner sous la commande d'un système d'exploitation 46 qui réside dans la mémoire 34. Le système d'exploitation 46 5 peut gérer des ressources informatiques de telle sorte qu'un code de programme informatique intégré sous la forme d'une ou plusieurs applications logicielles, telles qu'une application 48 résidant dans la mémoire 34, peuvent avoir des instructions exécutées par le processeur 32. Dans une autre forme de réalisation, le processeur 32 peut exécuter l'application 48 directement, 10 auquel cas le système de fonctionnement 46 peut être omis. Une ou plusieurs structures de données 50 peuvent également résider dans la mémoire 34, et peuvent être utilisées par le processeur 32, le système d'exploitation 46 et/ou l'application 48 pour le stockage ou la manipulation de données. L'interface I/O 38 peut fournir une interface machine qui couple fonctionnellement le 15 processeur 32 à d'autres dispositifs et systèmes, tels que le réseau 22 et/ou une ressource externe 42. L'application 48 peut ainsi travailler en coopération avec le réseau 22 et/ou une ressource externe 42 en communiquant via l'interface I/O 38 pour fournir les différentes particularités, fonctions, applications, processus et/ou modules comprenant des formes de réalisation 20 de l'invention. L'application 48 peut également avoir un code programme qui est exécuté par une ou plusieurs ressources externes 42, ou autrement s'appuyer sur des fonctions et/ou signaux fournis par d'autres composants système ou réseau externes à l'ordinateur 30. En effet, étant donné la presque infinité de configurations matérielles et logicielles possibles, l'homme 25 du métier comprendra que les formes de réalisation de l'invention peuvent inclure des applications qui sont situées à l'extérieur de l'ordinateur 30, distribuées sur plusieurs ordinateurs ou d'autres ressources externes 42, ou fournies par des ressources informatiques (matérielles ou logicielles), sous la forme d'un service sur le réseau 22, tel qu'un service informatique en nuage. 30 L'interface IHM 40 peut être couplée de manière fonctionnelle au processeur 32 de l'ordinateur 30 d'une manière connue, pour permettre à un utilisateur de l'ordinateur 30 d'interagir directement avec l'ordinateur 30. L'interface IHM 40 12 peut inclure des écrans vidéo et/ou alphanumériques, un écran tactile, un haut-parleur, et tout autre indicateur audio et visuel approprié capable de fournir des informations à l'utilisateur. L'interface IHM 40 peut également inclure des dispositifs de saisie et des commandes tels qu'un clavier 5 alphanumérique, un dispositif de pointage, des pavés numériques, des boutons poussoirs, des boutons de commande, des microphones, etc., capables de recevoir des commandes et données d'entrée en provenance de l'utilisateur et de transmettre les entrées introduites dans le processeur 32. 10 La figure 3 illustre une vue détaillée et schématique du dispositif serveur 90, dans un exemple d'application de l'invention au domaine de l'industrie du voyage, selon certains modes de réalisation. Le dispositif serveur 90 peut par exemple être un système de type GDS. La requête 80 peut être transmise par le dispositif client 100 via le réseau 25 au dispositif 15 serveur 90. Le dispositif serveur 90 peut comprendre un moteur de recherche 110 (encore appelé « serveur de trajet » ou « planificateur de voyage »). Le moteur de recherche 110 est configuré pour déterminer des produits de voyage satisfaisant les paramètres de la requêtes, comprenant la date, l'origine et la destination spécifiées par l'utilisateur. Pour déterminer les 20 options de voyages, le moteur de recherche 110 peut procéder en deux étapes. Dans une première étape, le moteur de recherche 110 peut déterminer des routes, ou itinéraires géographiques satisfaisant les paramètres de la requête. Le moteur de recherche 110 détermine généralement un nombre important de routes, en prenant en considération 25 l'ensemble des connexions possibles entre l'origine et la destination, parmi les milliers de stations possibles (par exemple, aéroports commerciaux) dans la zone géographique considérée. Le moteur de recherche 110 peut en outre trier et filtrer un tel ensemble de connexions tout au long du processus, en fonction d'une liste de critères. Le moteur de recherche 110 peut également 30 appliquer un coefficient multiplicateur à la distance séparant les stations d'origine et de destination, et écarter toutes les routes (avec escale) qui font parcourir une distance supérieure au produit de la distance séparant les 13 stations d'origine et de destination par le coefficient multiplicateur. Dans une deuxième étape, le moteur de recherche 110 peut utiliser les routes sélectionnées comme étant les plus pertinentes pour créer les produits de voyages correspondant à ces routes. Le moteur de recherche peut 5 notamment importer une table d'horaires 105, qui peut être utilisée de façon centralisée par plusieurs systèmes informatiques et mise à jour à une fréquence donnée (par exemple une fois par semaine, ou une fois par jour). La table d'horaire 105 peut comprendre les heures de départ et d'arrivée ainsi que les stations correspondantes (e.g. aéroport de la majorité des 10 compagnies aériennes commerciales). A partir de ces données, le moteur de recherche 110 peut explorer les itinéraires d'origine à destination, triés et sélectionnés à partir d'une liste de critères sur ces segments d'itinéraires (par exemple un temps suffisant pour faire une escale). Le moteur de recherche 110 peut alors déterminer les différentes produits de voyages possibles sous 15 la forme d'une liste restreinte de produits de voyage. Les produits de voyage ainsi obtenus peuvent être transmis à une plateforme de détermination de prix 120. Le nombre de produits de voyage transmis à la plateforme de détermination de prix 120 peut être paramétré, et être fixé à un nombre prédéterminé (tel que par exemple sept cent cinquante). 20 La plateforme de détermination de prix 120 peut être configurée pour déterminer un prix pour chacune des produits de voyage transmises par le moteur de recherche 110. Le dispositif serveur 90 peut comprendre une base de données des tarifs 140, qui importe des tarifs depuis une table de tarifs 115 fournie de façon centralisée à un ou plusieurs différents systèmes 25 informatiques existants. Pour un trajet donné défini par une origine et une destination, il peut exister différents tarifs applicables, chaque tarif étant associé à une des classes de réservation disponibles au sein d'un même vol. Telle qu'utilisée ici, l'expression « classe de réservation » fait référence à un identifiant associé à un type de service associé à un vol tel qu'un service 30 disponible à bord d'un vol, ou des conditions de modification de billet. Les classes de réservation peuvent être regroupés par groupes de classes de réservation, visibles par l'utilisateur par exemple par les libellés « première 14 classe », « classe affaire », « classe économie » ou encore « classe économie premium ». Seul le prix correspondant à la classe la moins chère de groupe de classes peut être transmis à l'utilisateur. 5 Une liste comprenant un nombre de produits de voyage (généralement environ cent cinquante produits de voyages) et correspondant aux prix les plus bas déterminés peut être ensuite transmise à un serveur de disponibilité 130. Le serveur de disponibilité peut être configuré pour vérifier les disponibilités des produits de voyages qui lui sont transmises. Le serveur 10 de disponibilité 130 peut être en outre configuré pour vérifier, pour chaque produit de voyage retenues dans les différentes classes de réservation, et fournies par la plateforme de détermination de prix 120, si des sièges sont encore disponibles. Le serveur de disponibilité 130 peut vérifier la disponibilité auprès des systèmes inventaires 160 des compagnies aériennes comp1, 15 comp2, comp3, comp4 etc. de différentes manières. Pour certaines compagnies, le serveur de disponibilité 130 peut être adapté pour interroger de façon dynamique le système inventaire 160 de la compagnie aérienne sur la disponibilité des places sur un vol pour une classe donnée (option dite « polling » ou « interrogation » en français, également appelée « Seamless 20 availability » ou « disponibilité transparente »). D'autres systèmes inventaires 160 de compagnies peuvent envoyer des informations de statut (option dite « AVS », acronyme pour « Availibility Status » ou « Statut de Disponibilité » en français), lorsque le système inventaire 160 l'estime nécessaire, par exemple à chaque fois que la disponibilité change. Le système inventaire 160 25 propre à chaque compagnie peut être un système informatisé qui stocke des unités ou articles périssables d'un inventaire. Dans une application préférée de l'invention à l'industrie du voyage, le système inventaire peut stocker des unités ou articles représentant des sièges pour de multiples combinaisons de vols-dates d'un réseau aérien, ainsi que des cabines et/ou classes de 30 réservation pour chacun de ces vols-dates. Pour faciliter la description de certains modes de réalisation, la description qui suit de certains modes de réalisation de l'invention sera faite en référence à une telle application de 15 l'invention au secteur du voyage dans laquelle le système inventaire 160 est configuré pour stocker des sièges, à titre d'exemple non limitatif. La liste 70 de produits de voyages est finalement fournie à l'utilisateur, 5 via le terminal de saisie et d'affichage 100. Ainsi, pour chaque requête effectuée par un utilisateur, ce sont classiquement des milliers de transaction qui sont effectuées par le dispositif serveur 90. Le moteur de recherche 110 reçoit un volume de trafic très élevé, et doit répondre rapidement et de manière optimisée. Un tel moteur de recherche est généralement soumis à de 10 très fortes contraintes en termes de performances et de temps de réponse. Par ailleurs, la plateforme de détermination de prix 120 est classiquement très consommatrice en ternies de ressources informatiques, et notamment de ressources CPU. Une telle consommation est notamment due aux calculs de combinaisons tarifaires effectués en fonction des pays de voyage, du nombre 15 d'escales pour chaque billet proposé, et plus généralement de la complexité de l'itinéraire. L'invention vient améliorer la situation en proposant un dispositif serveur 90 capable de traiter les requêtes émises par les dispositifs clients en 20 optimisant les ressources. Selon un aspect de l'invention, le dispositif serveur 90 est équipé d'une mémoire cache 150. La mémoire cache 150 est configurée pour fournir de façon transparente des données qui ont été précédemment chargées. La mémoire cache 150 constitue donc une mémoire intermédiaire dans laquelle 25 sont stockées les informations qui sont susceptibles d'être demandées par la plateforme de détermination de prix 120. Comme ces informations sont immédiatement disponibles, le temps de traitement est sensiblement diminué, ce qui accroit les performances du dispositif serveur 90. 30 La figure 4 illustre schématiquement l'architecture de la mémoire cache 150. La mémoire cache 150 associe à chaque requête une cellule de stockage (CS1, C52, ...) apte à stocker une pluralité d'informations liées à la 16 requête. Une unité de gestion 170 est intégrée à la mémoire cache 150. L'unité de gestion 170 est configurée pour gérer des cellules de stockage (lecture/écriture). L'unité de gestion 170 peut comprendre un module d'interface 200 configuré pour faire l'interface avec la plateforme de 5 détermination de prix 120, et recevoir les différentes valeurs courantes de la plateforme de détermination de prix 120. L'unité de gestion 170 peut également comprendre un comparateur 300 configuré pour comparer la valeur courante fournie par l'unité de traitement 200 et la valeur de référence se trouvant dans la cellule de stockage correspondant au même produit de 10 voyage. L'unité de gestion 170 peut comprendre aussi une unité de mise à jour 400, configurée pour mettre à jour les valeurs de référence dans les cellules de stockage, ainsi que, les cas échéant, les dates d'apparition et de disparition de la valeur de référence. L'unité de gestion 170 peut comprendre enfin une unité de renvoi 500 configurée pour retourner au dispositif client 15 l'information extraite de la cellule de stockage. Le procédé selon l'invention peut comprendre, pour chaque cellule de stockage composant la mémoire cache, deux étapes principales, illustrées par la figure 5 : une étape 2000 de remplissage de la cellule de stockage, et une 20 étape 3000 de mise à jour de la cellule de stockage. L'étape de remplissage des cellules de stockage peut être réalisée à partir de valeurs enregistrées préalablement dans le dispositif serveur 90. La figure 6 est un schéma illustrant les différentes étapes de mise à 25 jour des valeurs de référence, des dates d'apparition et des dates de disparition dans chacune des cellules de stockage. Le procédé est initialisé à l'étape 1000. Cette étape peut comprendre par exemple l'importation de données de valeurs d'une année précédente, afin de remplir certaines cellules de stockage de la mémoire cache 150. 30 A l'étape 1001 une valeur courante (val_cour) correspondant à une requête utilisateur est reçue, à un jour J. A l'étape 1002, la mémoire cache 17 150 identifie les paramètres du produit de voyage. Les paramètres peuvent comprendre un paramètre représentant l'origine, un paramètre représentant la destination, un paramètre représentant la date de départ et un paramètre représentant la date d'arrivée (chaque date est définie par un quantième, un 5 mois). Les paramètres peuvent en outre comprendre un paramètre représentant le groupe de classe de réservation. La mémoire cache 150 peut ainsi déterminer à l'étape 1003 si une cellule de stockage existe déjà. Si ce n'est pas le cas (i.e. aucune cellule de stockage n'existe), à l'étape 1006, la cellule de stockage peut être créée en lui assignant pour valeur de référence 10 (val_ref) la valeur courante, comme date d'apparition (date_app) la date du jour (quantième et mois), et comme date de disparition (date_disp) la valeur « Null » (ou un équivalent signifiant une donnée inconnue). S'il est déterminé qu'une cellule de stockage existe, à l'étape 1005, la valeur courante peut être comparée à la valeur de référence. Si elles sont différentes, à l'étape 1008, la 15 valeur courante peut être enregistrée en tant que valeur de référence, avec comme date d'apparition la date du jour (quantième et mois), comme date de disparition le champ « Null » (ou un équivalent signifiant une donnée inconnue). La valeur de référence qui était associée auparavant au jour J a alors une nouvelle date de disparition, à savoir J-1. Si la valeur courante et la 20 valeur de référence sont égales, ou sensiblement égales, dans un mode de réalisation, les dates d'apparition et de disparition ne sont pas modifiées. A l'étape 1009, la valeur de référence peut être transmise à l'utilisateur. Selon un mode de réalisation, les données extraites de la mémoire cache associées au produit peuvent être générées sur une interface graphique d'un site 25 Internet, en vue d'afficher ces données à l'utilisateur de façon ergonomique, et sans que cela ne perturbe la navigation sur le site Internet du côté du dispositif client 100. Le procédé retourne ensuite à l'étape 1001, de réception des valeurs courantes. 30 La table ci-dessous illustre schématiquement la structure détaillée d'une cellule de stockage, pour un exemple de produit de voyage. Cette cellule de stockage peut être identifiée dans la mémoire cache par des 18 références propres à la requête, identifiées dans la première ligne de la table, par exemple cdg_jfk_15aug_15aug_eco pour la cellule de stockage représentée schématiquement ci-dessous : CDG (11) JFK (12) 15 AUG (13) 15 AUG (14) ECO (15) Prix de vente (16) Devise (16') Date Date de d'apparition (17) disparition (18) 250 EUR 16 AUG 31 DEC 400 EUR 01 JAN 31 MAR 500 EUR 01 APR 31 JUL 650 EUR 01 AUG 15 AUG 5 Chaque cellule de stockage de la mémoire cache peut être propre aux paramètres du produit de voyage, tels que l'origine 11, la destination 12, le jour de départ 13, le jour d'arrivée 14 et le groupe de classe de réservation 15. Tel qu'utilisé ici, le terme « groupe de classes de réservation » fait référence à 10 un regroupement d'un certain nombre de classes de réservation. Par exemple, sur un vol donné, le groupe de réservation « business » peut correspondre aux classes A, F et Z. Les valeurs de référence correspondent aux prix des billets sur le même vol, sur une année précédente, pour chacun de groupes de réservation. 15 La cellule de stockage peut comprendre également : - une valeur de référence, qui correspond, dans une application de l'invention au domaine du voyage, au prix de vente 16 du billet à la même période l'année dernière, et/ou 20 - la devise 16', et/ou - le jour où le prix est apparu 17, et/ou - le dernier jour 18 de validité de ce prix. Dans une cellule de stockage, il peut donc y avoir autant de lignes que de prix différents sur une année passée. Par exemple, sur la table ci- 19 dessus, le vol Paris CDG - New-York JFK du 15 août en « Eco » a eu quatre prix de vente différents l'année dernière : 250 euros du 16 août au 31 décembre, 400 euros du 1er janvier au 31 mars, 500 euros du 1er avril au 31 juillet, et 650 euros du ler au 15 août. 5 Selon un mode de réalisation, pour un même trajet, les différents groupes de classes de réservation, propre à chaque cellule de stockage, peuvent être regroupées dans une cellule de stockage supplémentaire, comprenant, pour chaque jour, la valeur de référence la plus basse, à savoir la valeur de référence la plus basse de tous les groupes de classes de 10 réservation. Selon un premier cas de figure, pour l'exemple considéré, si, au 1er janvier 2017, la valeur courante (300 euros) est différente de la valeur de référence (400 euros), alors le jour du 1er janvier est stocké en tant que date 15 d'apparition 17 de la valeur courante 300 euros. La case de date de début correspondant à cette valeur est alors modifiée, et prend comme date le jour suivant, à savoir le 2 janvier. Une nouvelle ligne peut alors être créée, et dans ce cas la case de « date de disparition » n'est pas renseignée. La table ci-dessous illustre la modification des lignes de la cellule de stockage : 20 CDG (11) JFK (12) 15 AUG (13) 15 AUG (14) ECO (15) Prix de vente (16) Devise (16') Date Date de d'apparition (17) disparition (18) 250 EUR 16 AUG 31 DEC 400 EUR 02 JAN 31 MAR 500 EUR 01 APR 31 JUL 650 EUR 01 AUG 15 AUG 300 EUR 01 JAN NULL Un tri par date d'apparition de la valeur de référence peut ensuite être réalisé, selon différentes techniques de tri. 20 Selon un deuxième cas de figure, si, à la date de la requête (le 1er janvier), la valeur courante est égale à la valeur de référence (400 euros), les cellules de stockage ne sont pas modifiées. Les informations peuvent ainsi 5 être collectées de façon glissante et d'un jour à l'autre, le glissement étant réalisé sur un cycle complet d'une année. Pour un même jour, c'est la valeur courante la plus basse qui est retenue comme nouvelle valeur de référence, si elle est différente de l'ancienne valeur de référence. Ainsi, dans l'éventualité où une valeur courante est supérieure à une autre valeur courante le même 10 jour, c'est la valeur courante la plus faible qui est retenue comme valeur de référence. A la suite du premier cas de figure, si la valeur courante est toujours de 300 euros au 2 janvier mais repasse à 400 euros le 3 janvier, le 3 janvier 15 est indiqué comme date d'apparition de la valeur courante (case 17). La table ci-dessous représente ce cas de figure. CDG (11) JFK (12) 15 AUG (13) 15 AUG (14) ECO (15) Prix de vente (16) Devise (16') Date Date de d'apparition (17) disparition (18) 250 EUR 16 AUG 31 DEC 400 EUR 03 JAN 31 MAR 500 EUR 01 APR 31 JUL 650 EUR 01 AUG 15 AUG 300 EUR 01 JAN 02 JAN 20 Si, par contre, la valeur courante est de 400 euros au 2 janvier, la case 18 de date de disparition peut être remplie avec la date du 1er janvier, comme illustré par la table ci-dessous : 21 CDG (11) JFK (12) 15 AUG (13) 15 AUG (14) ECO (15) Prix de vente (16) Devise (16') Date Date de d'apparition (17) disparition (18) 250 EUR 16 AUG 31 DEC 400 EUR 02 JAN 31 MAR 500 EUR 01 APR 31 JUL 650 EUR 01 AUG 15 AUG 300 EUR 01 JAN 01 JAN Les cellules de stockage peuvent ainsi être quotidiennement alimentées et mises à jour, les cellules de stockage étant de préférence mises 5 à jour par glissement tout au long d'une année. De façon avantageuse, la mémoire cache 150 peut effectuer un glissement jour après jour sur l'année écoulée et sur l'année à venir, les données issues de l'année écoulée pouvant être transmises à l'utilisateur. Les données issues de la mémoire cache 150 peuvent être exploitées pour fournir notamment à l'utilisateur des informations 10 additionnelles et contextuelles relatives à la valeur courante et/ou à la valeur de référence. Selon un premier cas d'usage, le dispositif serveur 90 peut transmettre à l'utilisateur, en même temps que la valeur courante, une 15 estimation de la durée durant laquelle la valeur courante est constante. Selon une variante, le dispositif serveur 90 peut transmettre à l'utilisateur, en même temps que la valeur courante, la durée durant laquelle la valeur courante est sensiblement constante, par exemple à plus ou moins 5%. La figure 8 illustre une interface graphique d'utilisateur, reprenant ce cas d'usage. L'utilisateur 20 effectue la requête conformément aux exemples précédents, à la date du 15 juillet. Le dispositif serveur 90 lui renvoie la valeur courante, à savoir 500 euros, et également un message Message_cas1 comprenant les informations extraites de la cellule de stockage correspondant à cette requête, et plus 22 précisément la date de disparition de la valeur de référence l'année dernière (31 juillet). Le message Message_cas1 peut être du type : « L'an dernier, ce prix était valable jusqu'au 31 juillet ! ». L'histogramme de la figure 8 illustre différentes valeurs enregistrées dans la mémoire cache, et indique au moyen 5 d'un élément visuel particulier la date de la requête (par exemple une flèche pointant sur la date de la requête), ainsi que le message (Message_cas1) comprenant des informations extraites de la cellule de stockage. L'histogramme peut être affiché à l'utilisateur, à la demande de l'utilisateur ou systématiquement. En alternative, il peut être masqué. 10 Selon un deuxième cas d'usage, également appliqué au domaine du voyage, l'utilisateur peut être informé du moment de l'année où la valeur de référence est la plus faible pour un produit donné. Cette valeur peut en effet 15 ne pas augmenter continûment jusqu'au jour du voyage. Il peut y avoir dans les cellules de stockage de l'année précédente des périodes où la valeur de référence baisse sur une période donnée. Ainsi, il peut être pertinent de transmettre à l'utilisateur, en plus de la valeur courante, la valeur de référence la plus basse ayant un quantième et un mois antérieur à la date du voyage, 20 avec la date d'apparition et de disparition correspondantes. Cette valeur ajoutée permettrait à l'utilisateur de reporter l'achat du produit. La figure 9 illustre une interface graphique d'utilisateur, reprenant ce cas d'usage. L'utilisateur effectue la requête conformément aux exemples précédents, à la date du 1er mai. Le dispositif serveur 90 lui renvoie la valeur courante, à savoir 25 500 euros, et également un message Message_cas2 comprenant les informations extraites de la cellule de stockage correspondant à cette requête, et plus précisément la valeur de référence la plus basse ayant un quantième et un mois antérieur à la date du voyage, avec la date d'apparition et de disparition correspondantes. Le message Message_cas2 peut être du type : 30 « L'an dernier, vous pouviez voyager au tarif le moins cher (à partir de 350 E) en prenant votre billet le 1 er juin, pendant 2 mois ! ». Le message Message_cas_2 peut comprendre la valeur de référence la plus basse pour 23 chacun des groupes de classe de réservation, ou en alternative sans distinction des groupes de classe de réservation. Dans ce cas, les informations peuvent être extraites de la cellule de stockage supplémentaire, qui comprend les valeurs de références les plus basses pour chaque jour, 5 indépendamment du groupe de classe de réservation. L'histogramme de la figure 10 illustre les différentes valeurs enregistrées dans la mémoire cache, et indique par un élément visuel particulier la date de la requête (par exemple une flèche pointant sur la date de la requête), ainsi que le message (Message_cas2) comprenant des informations extraites de la cellule de 10 stockage. L'histogramme peut être affiché pour une interaction avec l'utilisateur, à la demande de l'utilisateur ou systématiquement. En variante, il peut être masqué. En variante, le moment de l'année (défini par exemple sous forme 15 d'intervalle par une date d'apparition et par une date de disparition) où la valeur de référence est la plus faible pour un produit donné, ainsi que la valeur de référence correspondante, peuvent être transmises à l'utilisateur avant qu'il ne valide sa requête 80, à savoir avant que l'utilisateur n'appuie sur un bouton de validation qui peut apparaître dans l'interface homme-machine 20 du dispositif client 100. Selon cette variante, dès que l'utilisateur a saisi une origine, une destination et une date de départ, et avant qu'il ne valide sa requête pour obtenir les disponibilités et les prix des produits répondant à ses critères, la requête 80 est tout de même traitée par le moteur de recherche 110 qui détermine à son tour les produits de voyage les plus pertinents, de 25 façon transparente pour l'utilisateur. Ces produits de voyage ne sont alors pas transmis à la plateforme de détermination de prix 120. L'unité de renvoi 500 de la mémoire cache 150 renvoie au dispositif client l'information extraite de la cellule de stockage correspondant aux critères définis de la requête. Cette variante permet donc de contextualiser la recherche effectuée par l'utilisateur, 30 et peut constituer une aide à la décision pour l'utilisateur. En effet, il peut avoir connaissance de la date où le billet satisfaisant les critères de sa requête a été mis en vente au prix le plus bas l'année passée, sans qu'il n'ait besoin de 24 valider sa requête, économisant ainsi un éventuel traitement de la requête devant passer notamment par la plateforme de détermination de prix 120, consommatrice en ressources informatiques. 5 Selon un mode de réalisation, le premier cas d'usage et le deuxième cas d'usage peuvent être combinés. L'utilisateur aurait alors deux niveaux d'informations, à savoir un premier relatif à la durée à laquelle son produit reste à cette valeur, et un deuxième relatif au moment où il y aura une valeur plus basse. 10 Le dispositif et le procédé objets de l'invention permettent ainsi d'éviter une surcharge des dispositifs serveurs, en limitant le nombre de requêtes identiques par un même utilisateur. La réutilisation des données immédiatement disponibles dans la mémoire cache permet ainsi de réduire 15 sensiblement le délai de réponses des dispositifs serveurs, et d'augmenter les performances du dispositif serveur. L'homme du métier comprendra que les procédés selon les modes de réalisation peut être mis en oeuvre de diverses manières par matériel 20 (« hardware »), logiciel, ou une combinaison de matériel et de logiciels, notamment sous la forme de code de programme pouvant être distribué sous la forme d'un produit de programme, sous diverses formes. En particulier, le code de programme peut être distribué à l'aide de supports lisibles par ordinateur, qui peuvent inclure des supports de stockage lisibles par 25 ordinateur et des supports de communication. Les procédés décrits dans la présente description peuvent être notamment implémentés sous la forme d'instructions de programme d'ordinateur exécutables par un ou plusieurs processeurs dans un dispositif informatique d'ordinateur. Ces instructions de programme d'ordinateur REVENDICATIONS1. Dispositif de traitement de requête, implémenté dans un dispositif serveur (90), la requête identifiant des paramètres de requêtes et étant reçue depuis un dispositif client connecté (100) audit dispositif serveur (90), la requête étant traitée par le dispositif serveur (90) à une date donnée dite date de requête, le dispositif comprenant : - Une unité de traitement (200) configurée pour déterminer un ensemble des produits candidats satisfaisant au moins certains des paramètres de ladite requête, chaque produit candidat étant associé à une valeur numérique courante représentant la valeur courante du produit candidat à la date de requête, chaque produit étant en outre associé à une date de produit, postérieure à ladite date de requête, caractérisé en ce que le dispositif comprend en outre : - Un comparateur (300) configuré pour comparer la valeur courante de chaque produit candidat avec une valeur de référence mémorisée dans une mémoire cache (150), connectée audit dispositif serveur, la valeur de référence étant une valeur dudit produit déterminée par le dispositif serveur à une date antérieure à ladite date de requête, dite « date de référence », la date de référence ayant le même quantième et le même mois que ladite date de requête, et - Une unité de mise à jour (400) configurée pour mettre à jour la valeur de référence mémorisée dans ladite mémoire cache (150) en lui affectant la valeur courante du produit, si la valeur courante est différente de la valeur de référence, ou s'il n'y a pas de valeur de référence dans ladite mémoire cache (150), le dispositif étant en outre configuré pour retourner une réponse au dispositif client comprenant l'ensemble des produits candidats déterminés, et pour chaque produit candidat la valeur courante du produit et des données 30 extraites de la mémoire cache associées audit produit. 26 2. Dispositif selon la revendication 1, dans lequel ledit dispositif est configuré pour prédire la stabilité temporelle de la valeur courante du produit candidat à la date de requête, déterminée à partir de la date de requête et de la date à laquelle la valeur de référence varie par rapport à la valeur courante, 5 si la valeur courante du produit candidat est égale à la valeur de référence. 3. Dispositif selon l'une des revendications précédentes, dans lequel les données extraites de la mémoire cache associées au produit comprennent au moins une date dite de prédiction, sélectionnée parmi l'ensemble des 10 dates associées respectivement à l'ensemble valeurs de référence et situées entre la date de requête et la date de produit, la date de prédiction correspondant à la date à laquelle la valeur de référence est minimale. 4. Dispositif selon la revendication 3, dans lequel les données 15 extraites de la mémoire cache associées au produit comprennent en outre une estimation temporelle du délai entre la date de prédiction et la date à laquelle la valeur de référence associée à la date de prédiction varie. 5. Dispositif selon l'une des revendications 3 ou 4, dans lequel les 20 données extraites de la mémoire cache associées au produit comprennent la valeur de référence associée à la date de prédiction. 6. Dispositif selon l'une des revendications précédentes, dans lequel le dispositif serveur (90) est configuré pour contrôler l'affichage des données 25 extraites de la mémoire cache associées au produit sur une interface graphique d'un site Internet. 7. Dispositif selon l'une des revendications précédentes, dans lequel les paramètres de la requête comprennent au moins un aéroport d'origine et 30 un aéroport de destination. 27 8. Procédé de traitement de requête (80), dans un dispositif serveur (90), la requête identifiant des paramètres de requêtes et étant reçue depuis un dispositif client (100) connecté audit dispositif serveur (90), la requête étant traitée par le dispositif serveur (90) à une date donnée dite date 5 de requête, le procédé comprenant les étapes consistant à: - déterminer (1002) un ensemble des produits candidats satisfaisant au moins certains des paramètres de ladite requête, chaque produit candidat étant associé à une valeur numérique courante représentant la valeur courante du produit candidat à la date de requête, chaque produit 10 étant en outre associé à une date de produit, postérieure à ladite date de requête, caractérisé en ce que le procédé comprend en outre, pour chaque produit candidat, une étape consistant à : comparer (1005) la valeur courante du produit candidat avec une 15 valeur de référence mémorisée dans une mémoire cache (150), connectée audit dispositif serveur, la valeur de référence étant une valeur dudit produit déterminée par le dispositif serveur à une date antérieure à la dite date de requête, dite « date de référence », la date de référence ayant le même quantième et le même mois que ladite date de requête, et à 20 - mettre à jour (1006, 1008) la valeur de référence mémorisée dans ladite mémoire cache (150) en lui affectant la valeur courante du produit, si la valeur courante est différente de la valeur de référence, ou s'il n'y a pas de valeur de référence dans ladite mémoire cache (140), et en ce que le procédé comprend une étape consistant à retourner 25 (1009) une réponse (70) au dispositif client comprenant l'ensemble des produits candidats déterminés, et pour chaque produit candidat la valeur courante du produit et des données extraites de la mémoire cache associées audit produit. 9. Procédé selon la revendication 8, dans lequel, si la valeur courante du produit candidat est égale à la valeur de référence, les données extraites de la mémoire cache associées audit produit comprennent une 28 prédiction de la stabilité temporelle de la valeur courante du produit candidat à la date de requête, déterminée à partir de la date de requête et de la date à laquelle la valeur de référence varie par rapport à la valeur courante. 5 10. Procédé selon l'une des revendications 8 ou 9, dans lequel les données extraites de la mémoire cache associées au produit comprennent au moins une date dite de prédiction, sélectionnée parmi l'ensemble des dates associées respectivement à l'ensemble valeurs de référence et situées entre la date de requête et la date de produit, la date de prédiction correspondant à 10 la date à laquelle la valeur de référence est minimale. 11. Procédé selon la revendication 10, dans lequel les données extraites de la mémoire cache associées au produit comprennent en outre une estimation temporelle du délai entre la date de prédiction et la date à 15 laquelle la valeur de référence associée à la date de prédiction varie. 12. Procédé selon l'une des revendications 10 ou 11, dans lequel les données extraites de la mémoire cache associées au produit comprennent la valeur de référence associée à la date de prédiction. 20 13. Procédé selon l'une des revendications 8 à 12, dans lequel un affichage des données extraites de la mémoire cache associées au produit est généré sur une interface graphique d'un site Internet. 25 14. Procédé selon l'une des revendications 8 à 13, les paramètres de la requête comprenant au moins un aéroport d'origine et un aéroport de destination. 15. Produit-programme d'ordinateur pour le traitement d'une 30 requête, le produit-programme d'ordinateur comprenant un support durable de stockage de données lisibles par ordinateur et un code de programme enregistré sur le support durable de stockage lisible par ordinateur qui, lorsqu'il est exécuté par un ou plusieurs processeurs, amène le ou plusieurs 29 processeurs à exécuter les étapes du procédé selon l'une des revendications 8 à 14.