Brevet FR3096163A1 — publié le 20201120

Description Titre de l'invention : GESTION DE VERSIONS PARALLÈLES ET ESSAIS À VARIANTES MULTIPLES [0001] La présente invention concerne de façon générale un environnement informatique distribué, sans qu'il y soit limité. Plus spécifiquement, la présente invention concerne des systèmes, des procédés et des supports de stockage lisibles par ordinateurs pour tester des versions parallèles de contenu dans un environnement distribué. [0002] Des expériences contrôlées telles que les tests AIB, permettent les mises à jour de contenu actuel ou de contenu nouveau devant être évalué objectivement tout en minimisant les risques associés avec un déploiement complet. Avec les tests AIB, par exemple, une mise à jour d'une version actuelle de contenu ou de nouveau contenu faisant l'objet de tests (ci-après « version B») peut être évaluée objectivement par rapport à une version actuelle (ci-après «version A »). Les utilisateurs interagissant avec le contenu en cours dc test peuvent être cloisonnés de sorte que la version A est présentée à un premier sous-ensemble d'utilisateurs alors que la version B est présentée à un deuxième sous-ensemble d'utilisateurs. Les métriques d'évaluation peuvent être déterminées pour chaque version en utilisant des données collectées concernant des réponses ou des comportements d'utilisateurs dans le premier et le deuxième sous-ensemble. Ces métriques d'évaluation facilitent l'évaluation de façon objective de la version B par rapport à la version A. [0003] Diverses épreuves existent pour les fournisseurs de contenus qui implémentent ces essais contrôlés dans des environnements informatiques distribués. Une épreuve implique de corréler des cloisonnements dc tests avec des réponses ou des résultats subséquents pour obtenir des données afin dc générer des métriques d'évaluation. Par exemple, une requête de contenu en cours de test et une transaction concernant cc contenu peuvent être reçues par un serveur qui fournit cc contenu via des canaux différents même si la requête et la transaction sont émises in fine par le même utilisateur. Cette instance survient généralement dans des environnements informatiques distribués impliquant des dispositifs intermédiaires (p. ex., des serveurs d'applications, des sites Web de recherche, des serveurs de terminal, et autres) à travers lesquelles les utilisateurs peuvent accéder au contenu qui est testé. [0004] Une autre épreuve survient lorsqu'un fournisseur de contenu tente de tester de multiples versions de contenu parallèlement. Par exemple, au lieu de tester les versions A et B. le fournisseur de contenu peut essayer de tester la version C. En réponse aux métriques d'évaluation reçues, le fournisseur de contenu peut identifier des aspects particuliers des versions B et C qui représentent des améliorations par rapport à la 2 version A et des aspects particuliers des versions B et C dont les performances sont pires que des aspects correspondants de la version A. La fusion sélective des aspects particuliers des versions B et C qui représentent des améliorations par rapport à la version A pour des tests ultérieurs tout en rejetant des aspects particuliers des versions B et C dont les performances sont pires que ceux de la version A, peut s'avérer ne pas être possible avec les techniques existantes. En outre, le retour en arrière, après que des changements quelconques sont introduits dans les diverses versions durant les tests, est généralement difficile. [0005] Des modes de réalisation de la présente invention fournissent des systèmes, des procédés et des supports de stockage lisibles par ordinateur pour tester et faire évoluer indépendamment des versions de contenu parallèles dans un environnement informatique distribué. Dans un mode de réalisation de la présente invention, un procédé inclut la réception d'une interrogation de recherche incluant une pluralité de paramètres de recherche provenant d'un dispositif client. Un résultat de recherche qui satisfait la pluralité des paramètres de recherche est identifié. Un identifiant unique associé à la requête de recherche est déterminé. Sur la base de l'identifiant unique, une version de contenu parmi la pluralité de versions de contenu est accédée. Chaque version de résultat de recherche parmi la pluralité des versions de contenu est distincte des autres versions en vertu d'une variante. Chaque variante est stockée dans un fichier enfant correspondant. Chaque fichier enfant a un fichier parent correspondant représentant une version particulière de l'ensemble de tarifs avant une modification par une variante respective. Les données de contenu sont récupérées à partir de la version de contenu accédée. Un résultat de recherche qui satisfait la pluralité des paramètres de recherche est enrichi avec des informations pertinentes en utilisant les données de contenu récupérées, et transmises au dispositif client en réponse à l'interrogation de recherche. [0006] Selon un aspect, la pluralité des versions de l'ensemble de tarifs inclut un premier ensemble de tarifs modifié et un deuxième ensemble de tarifs modifié qui sont distincts des autres versions de l'ensemble de tarifs en vertu d'une première variante, le premier ensemble de tarifs modifié inclut une première version de la première variante et le deuxième ensemble de tarifs modifié inclut une deuxième version de la première variante. [0007] Un autre aspect comprend de déterminer une première métrique d'évaluation pour le premier ensemble de tarifs modifié ; et de déterminer une deuxième métrique d'évaluation pour le deuxième ensemble de tarifs modifié. [0008] Un autre aspect comprend la fusion d'une de la première version et de la deuxième version de la première variante en une version de base de l'ensemble de tarifs sur la base d'une comparaison entre la première métrique d'évaluation et la deuxième 3 métrique d'évaluation. [0009] Un autre aspect comprend le rejet d'un du premier ensemble de tarifs modifié et du deuxième ensemble de tarifs modifié sur la hase d'une comparaison entre la première métrique d'évaluation et la deuxième métrique d'évaluation. [0010] Selon un autre aspect, la première métrique d'évaluation et la deuxième métrique d'évaluation sont des taux de conversion indicatifs d'un pourcentage de réservations d'itinéraires de voyage associés respectivement à la première version et à la deuxième version de la première variante. [0011] Selon un autre aspect, la pluralité des versions de l'ensemble de tarifs inclut par ailleurs un troisième ensemble de tarifs modifié qui est distinct des autres versions de l'ensemble de tarifs en vertu d'une deuxième variante, et le troisième ensemble de tarifs modifié correspondant à un sous-ensemble du premier ensemble de tarifs modifié. [0012] Un autre aspect comprend la mise en oeuvre d'une opération ensembliste sur le premier ensemble de tarifs modifié et le troisième ensemble de tarifs modifié pour générer un quatrième ensemble de tarifs modifié. [0013] Selon un autre aspect, l'opération ensembliste inclut une opération ensembliste d'union, une opération ensembliste d'intersection, une opération ensembliste de différence, ou une combinaison de celles-ci. [0014] Selon un autre aspect, l'identifiant unique est déterminé sur la hase de la pluralité des paramètres de recherche, des authentifications de connexion de l'utilisateur, d'un identifiant de compte, d'un identifiant de machine du dispositif client, d'une adresse réseau du dispositif client, d'une localisation géographique du dispositif client ou d'une combinaison de ces éléments. [0015] Un autre aspect comprend la mise en cache de données liées à la recherche qui associent l'identifiant unique, l'interrogation de recherche, la version de l'ensemble de tarifs accédée, la réponse à l'interrogation, ou une combinaison de ces éléments dans un dispositif de stockage associé au système de réservation. [0016] Selon un autre aspect, l'interrogation de recherche est une sollicitation d'une interface de programme d'application (API) adressée à une API d'un système de réservation. [0017] Dans un autre mode de réalisation un système inclut un dispositif informatique et un support de stockage lisible par ordinateur comprenant un premier ensemble d'instructions qui lors de l'exécution par dispositif informatique amène le système à effectuer des opérations. Les opérations incluent la réception, provenant d'un dispositif client, d'une interrogation de recherche incluant une pluralité de paramètres de recherche. Un identifiant unique correspondant à la requête de recherche est déterminé. Sur la base de l'identifiant unique, une version de contenu parmi une pluralité de versions de continu est accédée. Chaque version de contenu parmi la pluralité des versions de contenu est distincte des autres versions en vertu d'une variante. Chaque variante est stockée dans un fichier enfant correspondant. Chaque fichier enfant a un fichier parent correspondant représentant une version particulière de l'ensemble de tarifs avant une modification par une variante respective. Les données de contenu sont récupérées à partir de la version de contenu accédée. Un résultat de recherche qui satisfait la pluralité des paramètres de recherche est enrichi avec des informations pertinentes en utilisant les données de contenu récupérées, et transmises au dispositif client en réponse à l'interrogation de recherche. [0018] D'autres aspects du système incluent un quelconque des aspects du procédé mentionnés ci-dessus. [0019] Dans un autre mode de réalisation, un support de stockage lisible par ordinateur inclut des instructions lisibles par ordinateur qui lors de l'exécution par un dispositif informatique amènent le dispositif informatique à mettre en oeuvre des opérations. Les opérations incluent la réception, provenant d'un dispositif client, d'une interrogation de recherche incluant une pluralité de paramètres de recherche. Un identifiant unique correspondant à la requête de recherche est identifié. Sur la base de l'identifiant unique, une version de contenu parmi une pluralité de versions de continu est accédée. Chaque version de résultat de recherche parmi la pluralité des versions de contenu est distincte des autres versions en vertu d'une variante. Chaque variante est stockée dans un fichier enfant correspondant. Chaque fichier enfant a un fichier parent correspondant représentant une version particulière de l'ensemble de tarifs avant une modification par une variante respective. Les données de contenu sont récupérées à partir de la version de contenu accédée. Un résultat de recherche qui satisfait la pluralité des paramètres de recherche est enrichi avec des informations pertinentes en utilisant les données de contenu récupérées, et transmises au dispositif client en réponse à l'interrogation de recherche. [0020] D'autres aspects du support de stockage lisible pal- ordinateur incluent un quelconque des aspects du procédé mentionnés ci-dessus. [0021] Dans un autre mode de réalisation un produit programme d'ordinateur comprend des instructions de code de programme stockées sur un support lisible par ordinateur pour exécuter les aspects du procédé mentionnés ci-dessus lorsque ledit programme fonctionne sur un ordinateur. Le résumé ci-dessus peut présenter une vue d'ensemble simplifiée de certains des modes de réalisation de l'invention afin de fournir une compréhension basique de certains aspects de l'invention discutés dans les présentes. Le résumé ne prétend pas apporter une vue d'ensemble exhaustive de l'invention et n'est pas non plus destiné à identifier des éléments clés ou critiques quelconques ou à limiter la portée de l'invention. Le seul but du résumé est simplement de présenter quelques concepts sous une forme simplifiée en guise de préambule à la description détaillée présentée ci-dessous. [0022] Les dessins en annexe illustrent divers modes de réalisation de la présente invention et, avec la description générale de l'invention ci-dessus et la description détaillée des modes de réalisation donnée ci-dessous, servent à expliquer les modes de réalisation de l'invention. Dans les dessins, des références à des chiffres similaires sont utilisées pour indiquer des éléments similaires dans les diverses visualisations. [0023] La [FIG. 1] est un diagramme bloc d'un exemple d'environnement informatique distribué qui est adapté à l'implémentation des aspects de la présente invention. [0024] La [FIG. 2] est un diagramme bloc d'un exemple de système de réservation adapté à l'implémentation des modes de réalisation de la présente invention. [0025] La [Fig. 3] est une illustration de haut niveau de gestion de versions parallèles de contenu conformément à un mode de réalisation de la présente invention. [0026] La [Fig. 4] est une illustration de haut niveau d'une structure de donnée adaptée à l'implémentation de gestion de versions parallèles de contenu conformément à un mode de réalisation de la présente invention. [0027] La [Fig. 5] illustre un exemple de relations entre un ensemble de tarifs de base et des variantes de l'ensemble de tarifs de base conformément un mode de réalisation de la présente invention. [0028] La [Fig. 6] décrit un diagramme de Venn pour illustrer la performance des opérations ensemblistes sur les versions parallèles de contenu conformément à un mode de réalisation de la présente invention. [0029] La [Fig. 7] est un diagramme séquentiel illustrant un exemple du procédé pour tester simultanément des versions parallèles de contenu dans un environnement informatique distribué. [0030] La [Fig. 8] est un diagramme bloc d'un exemple d'environnement informatique adapté à l'implémentation des modes de réalisation de l'invention. [0031] De nombreux détails sont fournis afin d'apporter une compréhension approfondie des implémentations exemplaires montrées dans les dessins. Cependant, les dessins ne montrent que quelques aspects exemplaires de la présente divulgation et ne doivent donc pas être interprétés comme étant restrictifs. Les hommes de métier comprendront que d'autres aspects effectifs et/ou variantes n'incluent pas tous les détails spécifiques décrits dans les présentes. En outre, des systèmes, procédés, composants, dispositifs et circuits bien connus n'ont pas été décrits de façon exhaustive afin de ne pas obscurcir des aspects pertinents des implémentations exemplaires décrites dans les présentes. [0032] Faisant référence à la FIG. 1, un environnement d'exploitation exemplaire 100 pour implémenter les aspects de l'invention présente est illustré et désigné de façon générale sous le numéro 100. En général l'environnement d'exploitation 100 représente les 6 divers systèmes et canaux de distribution par lesquels les utilisateurs accèdent au contenu fourni par un fournisseur de contenu. Le système d'exploitation 100 inclut un dispositif utilisateur 110, un serveur d'applications 120, un site Web de recherche 130, un serveur de terminal 140 et un serveur de contenu 150. Ainsi que décrit dans la FIG.1, les divers systèmes communiquent les uns avec les autres via le réseau 160 qui peut inclure un ou plusieurs réseaux publics et/ou privés. Des exemples de réseaux qui sont appropriés pour l'implémentation du réseau 160 incluent : des réseaux de zone locale (LANs), des réseaux de zone étendue (WANs), un réseau cellulaire, l'internet et autres de ce genre. [0033] Dans le fonctionnement, un utilisateur interagit avec un dispositif utilisateur 110 pour accéder à du contenu fourni par un serveur de contenu 150 via le réseau 160. Comme on le voit dans la FIG. 1, de nombreux canaux de distribution existent à l'inférieur de l'environnement d'exploitation 100 par lesquels l'utilisateur peut accéder à du contenu fourni par un serveur de contenu 150. Par exemple, un dispositif utilisateur 110 peut accéder directement au contenu en communiquant une demande pour le contenu directement au serveur de contenu 150 via le réseau 160. Le dispositif utilisateur 110 peut aussi accéder indirectement au contenu en communiquant d'abord une demande pour le contenu à un dispositif intermédiaire. Le dispositif intermédiaire peut être un serveur d'applications 120, un site Web de recherche 130 et/ou un serveur de terminal 140. Lors de la réception de cette requête, le dispositif intermédiaire peut communiquer une requête pour le contenu au serveur de contenu 150. En réponse, le serveur de contenu 150 renvoie le contenu demandé au dispositif intermédiaire qui transmet le contenu demandé au dispositif utilisateur 110. Autrement, lors de la réception de la requête pour le contenu du dispositif utilisateur 110, le dispositif intermédiaire peut renvoyer une version en cache du contenu demandé au dispositif utilisateur 110. Dans ce cas, le dispositif intermédiaire peut avoir récupéré le contenu demandé à partir du serveur de contenu 150 avant de recevoir la requête du dispositif utilisateur 110 et avoir stocké ce contenu dans un stockage en cache local pour réduire les temps de réponse. [0034] Lorsque le dispositif utilisateur 110 reçoit le contenu demandé, l'utilisateur peut exécuter une transaction concernant le contenu demandé. Par exemple, l'utilisateur peut initier une transaction pour obtenir du contenu relatif au contenu demandé ou initier une transaction pour acheter le contenu demandé. À nouveau, il existe beaucoup de canaux de distribution dans l'environnement d'exploitation 100 à travers lesquels l'utilisateur peut exécuter une transaction concernant le contenu demandé. Le dispositif utilisateur 110 peut exécuter directement la transaction avec le serveur de contenu 150 via le réseau 160. Si un dispositif intermédiaire a fourni le contenu demandé au dispositif utilisateur 110, le dispositif utilisateur 110 peut indirectement exécuter une 7 première transaction concernant le contenu demandé avec le dispositif intermédiaire. Le dispositif intermédiaire peut ensuite exécuter directement une deuxième transaction concernant le contenu demandé avec le serveur de contenu 150. Autrement, le dispositif intermédiaire peut avoir fourni des instructions au dispositif utilisateur 110 pour établir une session de communication avec le serveur de contenu 150 afin d'exécuter une transaction lors de la fourniture du contenu demandé. Dans ce cas, le dispositif l'utilisateur 110 peut directement exécuter la transaction concernant le contenu demandé avec le serveur de contenu 150 sur la hase de ces instructions. [0035] L'homme de métier reconnaîtra qu'en accédant au contenu fourni par le serveur de contenu 150 ou en initiant une transaction concernant ce contenu, un client particulier initie une session de communication avec un composant particulier d'un réseau informatique distribué. En bref, une « session de communication » dans les modes de réalisation exemplaires de la présente divulgation fait référence à un flux d'échange d'informations entre un noeud serveur et un noeud client dans une architecture serveur-client. Le flux d'échange d'informations implique typiquement le noeud client qui envoie au noeud serveur une demande qui est traitée par le noeud serveur lequel renvoie une réponse satisfaisant la demande au noeud client. Dans un mode de réalisation, une session de communication peut être implémentée comme session basée sur le protocole de transfert hypertexte (« HTTP ») sur une connexion de protocole de contrôle de transmission (TCP). [0036] De la perspective du serveur 150, chacune des demandes de contenu et des tran- sactions dans les exemples ci-dessus peuvent provenir des divers noeuds clients. Dans l'exemple où le dispositif utilisateur 110 accède directement au contenu, le dispositif utilisateur 110 est le noeud client de cette session de communication. Dans l'exemple où le dispositif utilisateur 110 accède indirectement au contenu en communiquant d'abord une demande pour le contenu à un dispositif intermédiaire, le dispositif intermédiaire (p. ex., le serveur d'applications 120, le site Web de recherche 130, et/ou le serveur de terminal 140) est le noeud client de cette session de communication puisque le dispositif intermédiaire communique une demande pour le contenu au serveur de contenu 150. Dans l'exemple où le dispositif utilisateur 110 accède indirectement au contenu via le dispositif intermédiaire et, par la suite, exécute directement la transaction avec le serveur de contenu 150, la demande et la transaction proviennent de divers noeuds clients (c.-à-d., le dispositif intermédiaire et le dispositif utilisateur 110, respectivement), même si la requête et la transaction proviennent toutes deux in fine du dispositif utilisateur 110. [0037] Chacun des systèmes montrés dans la FIG. 1 peut être implémenté via tout type de système informatique tel que le système informatique 800 décrit de façon plus détaillée ci-dessous en référence à la FIG. 8, par exemple. Chaque système montré dans la 8 FIG.1 peut comprendre un seul dispositif ou de multiples dispositifs qui collaborent dans un environnement distribué. Par exemple, le serveur de contenu 150 peut être fourni via de multiples dispositifs arrangés dans un environnement distribué qui fournissent collectivement la fonctionnalité décrite dans les présentes. De plus, d'autres composants non représentés peuvent aussi être inclus dans l'environnement distribué. [0038] La FIG. 2 est un diagramme bloc d'un système de réservation exemplaire 200 qui est adapté à l'implémentation de la présente invention. Dans un mode de réalisation, le système de réservation 200 est implémenté dans le serveur de contenu 150 de la FIG. 1. Comme décrit dans la FIG. 2, le système de réservation 200 inclut des systèmes frontaux 285 et des systèmes dorsaux 295 qui échangent des données via un réseau 270 composé de réseaux publics et privés, tels qu'Internet et un système de réservation intranet. Les systèmes frontaux 285, tels qu'un moteur de recherche 220, interagissent directement avec les dispositifs clients (p. ex., le dispositif utilisateur 110, le serveur d'applications 120, le site Web de recherche 130 et/ou le serveur de terminal 140 de la FIG. 1) durant le processus de réservation de voyage. [0039] Par contraste, les dispositifs clients ne sont pas exposés aux systèmes dorsaux 295 qui stockent des données relatives à des services de voyages («données relatives au voyage ») et mettent en oeuvre des services liés à la réservation de services de voyages (« services liés au voyage»). Dans la FIG. 2, les services liés au voyage dans le système de réservation 200 incluent des services liés au voyage fournis par un système de gestion d'inventaire 230, un système de gestion de réservations 240, un système de gestion de billets 250 et un système de gestion d'ensembles de tarifs de base 260. Des exemples de données relatives au voyage incluent les données d'inventaire, les données tarifaires, les données de routes, les données de planning, les données d'enregistrement, les données d'embarquement et ainsi de suite. Des exemples de services liés au voyage incluent les services de réservation de voyage qui définissent un itinéraire, l'émission de billets pour les services de voyage réservés qui définissent un itinéraire et ainsi de suite. Pour les besoins de la présente divulgation, un «itinéraire » fait référence à un trajet de voyage structuré entre un lieu d'origine et un lieu de destination. Dans un mode de réalisation, les données relatives au voyage correspondent au contenu fourni par le serveur de contenu 150 dans la FIG. 1. [0040] Le moteur analytique 210 est configuré pour faciliter les tests et la gestion de versions parallèles de contenu dans un environnement informatique distribué. Le moteur analytique 210 inclut un service Web 211, un gestionnaire de routage 213, un gestionnaire de versions 215, un gestionnaire d'ensembles de tarifs 217 et un gestionnaire d'évaluation 219. Le service Web 211 est configuré pour faciliter les communications en réseau entre les systèmes frontaux 285 du système de réservation 200 (p. 9 ex. le moteur de recherche 120) et les clients du système de réservation 200. Par exemple, pendant une phase de recherche du processus de réservation de voyage, une interrogation de recherche soumise par un dispositif client est adressée au moteur de recherche 220 via le service Web 210. [0041] Le gestionnaire de routage 213 est configure pour déterminer un identifiant unique correspondant à chaque interrogation de recherche soumise par un dispositif client au service Web 211 conformément à des règles de cloisonnement prédéfinies. Selon un aspect, un identifiant unique, correspondant à une interrogation de recherche reçue d'un dispositif client, est déterminé sur la hase de la pluralité des paramètres de recherche inclus dans l'interrogation de recherche, des authentifications de connexion de l'utilisateur, d'un identifiant de compte, d'un identifiant de machine du dispositif client, d'une adresse réseau du dispositif client, d'une localisation géographique du dispositif client ou d'une combinaison de ces éléments. Le gestionnaire de routage 213 est par ailleurs configuré pour interagir avec le moteur de recherche 220 pour identifier un ou plusieurs résultats de recherche comprenant un itinéraire de voyage qui satisfait la pluralité des paramètres de recherche. [0042] Lorsque ledit un plusieurs résultats de recherche sont identifiés, le gestionnaire de routage 213 interagit avec le gestionnaire d'ensembles de tarifs 217 pour obtenir des informations tarifaires pour des itinéraires de voyage inclus dans ledit un ou plusieurs résultats de recherche. Sur la hase d'une évaluation de l'identifiant unique avec les règles de cloisonnement, le gestionnaire de routage 213 dérive une valeur correspondant à une version particulière d'un ensemble de tarifs que le gestionnaire d'ensembles de tarifs 217 doit accéder afin d'obtenir les informations de prix. Le gestionnaire de routage 213 transmet la valeur au gestionnaire d'ensembles de tarifs 217 et, en réponse, reçoit les informations de prix. Dans un mode de réalisation, le gestionnaire de routage 213 met an cache les données relatives à la recherche qui associent l'identifiant unique, l'interrogation de recherche, la version d'ensemble de tarifs accédée, la réponse à l'interrogation, ou une combinaison de ces éléments dans un dispositif de stockage associé au système de réservation 200. [0043] Le gestionnaire de versions 215 est configuré pour gérer des ensembles de tarifs modifié afin d'assister la gestion de versions parallèles de contenu, comme cela sera décrit de façon plus détaillée ci-dessous. Le compilateur d'ensembles de tarifs 217 est configuré pour récupérer des informations de prix pour des itinéraires de voyage inclus dans lesdits un ou plusieurs résultats de recherche identifiés par le moteur de recherche 220 en utilisant une valeur reçue du gestionnaire de routage 213 qui correspond à une version particulière d'un ensemble de tarifs que le gestionnaire d'ensembles de tarifs 217 doit accéder pour obtenir les informations de prix. Dans un mode de réalisation, le gestionnaire d'ensembles de tarifs 217 accède à la base de données d'ensembles de tarifs de hase via le système de gestion d'ensembles de tarifs de hase 260 pour obtenir des informations de prix lorsque la version particulière de l'ensemble de tarifs est un ensemble de tarifs de hase. Dans un mode de réalisation, le gestionnaire d'ensembles de tarifs 217 transmet la valeur au gestionnaire de versions 215 pour obtenir les informations tarifaires lorsque la valeur correspond à une version modifiée de l'ensemble de tarifs. Lors de l'obtention des informations de prix pour les itinéraires de voyage, le gestionnaire d'ensembles de tarifs 217 transmet ces informations au gestionnaire de routage 213 pour un traitement ultérieur. [0044] Le gestionnaire d'évaluation 219 est configuré pour corréler des enregistrements de réservations avec des versions d'un ensemble de tarifs qui a été accédé afin d'enrichir des résultats de recherche avec des informations de prix. En faisant cette corrélation, le gestionnaire d'évaluation 219 peut compiler des données d'évaluation. Sur la base des données d'évaluation, le gestionnaire d'évaluation 219 détermine une métrique d'évaluation, telle qu'un taux de conversion pour chaque version d'ensemble de tarifs parmi la pluralité des versions d'ensemble de tarifs. De cette façon, chaque version de l'ensemble de tarifs parmi la pluralité des versions de l'ensemble de tarifs peut être évaluée objectivement en utilisant des métriques d'évaluation déterminées pour chaque version en utilisant les données d'évaluation compilées. Sur la base de cette évaluation objective, une détermination peut être faite que des clients répondent plus positivement à une première version d'un ensemble de tarifs qu'à une deuxième version de l'ensemble de tarifs. [0045] Le moteur de recherche 220 est configuré pour identifier des résultats de recherche ayant au moins un itinéraire qui satisfait les paramètres de recherche inclus dans chaque interrogation de recherche. Des exemples de ces paramètres de recherche incluent : un lieu d'origine, un lieu de destination, une date de départ, une date de retour, un nombre de passagers associé à une demande de voyage (« un nombre dans un groupe»), une classe de réservation, un nombre d'escales, un numéro de segment ferroviaire, un identifiant de fournisseur de voyage, une classe de cabine (p. ex. première classe ou économie), une famille de tarifs, une fourchette d'horaires de départ, et ainsi de suite. Le moteur de recherche 220 est par ailleurs configuré pour communiquer les résultats de recherche identifiés aux dispositifs clients via le service Web 210. [0046] Les données relatives à l'inventaire pour un ou plusieurs fournisseurs de services de voyage sont stockées dans une base de données d'inventaire 235 sous le contrôle d'un système de gestion d'inventaire 230. Dans un mode de réalisation, les données relatives à l'inventaire incluent des informations de disponibilité qui définissent des services d'inventaire de voyage non réservés. Tel qu'utilisé dans les présentes, «les services d'inventaire de voyage non réservés » concernent les portions d'un inventaire 11 de services de voyage qui ne sont pas associées à un quelconque des enregistrements de réservation stockés dans la hase de données de réservations 245. Par contraste, « l'inventaire de services de voyage réservés » concerne des portions de l'inventaire de services de voyage qui sont associés avec un ou plusieurs enregistrements de réservation stockés dans une hase de données de réservation 245. [0047] Les enregistrements de réservation pour un ou plusieurs fournisseurs de services de voyage sont stockés dans une hase de données de réservation 245 sous le contrôle d'un système de gestion de réservations 240. Le système de gestion de réservations 240 est configuré pour interagir avec le moteur de recherche 220 afin de traiter les demandes de réservation reçues au cours d'une phase de réservation du processus de traitement d'une réservation de voyage. En réponse à la réception d'une demande de réservation incluant un itinéraire de voyage, le système de gestion des réservations 240 génère un enregistrement de réservation dans la hase de données de réservations 245. Dans un mode de réalisation, l'enregistrement de réservation est un enregistrement de nom de passager («PNR »). L'enregistrement de réservation inclut des données d'itinéraire et un localisateur d'enregistrement qui identifie de façon unique l'enregistrement de réservation dans la hase de données de réservations 245. Dans un mode de réalisation, l'enregistrement de réservation inclut un horaire limite pour l'émission des billets. Lc localisateur d'enregistrement peut aussi être désigné comme numéro de confirmation, numéro de réservation, code de confirmation, références de réservation, numéro de PNR, et ainsi de suite. [0048] Les données d'itinéraire incluent généralement des informations de voyage dé- finissant divers services de voyage inclus dans un itinéraire et les informations relatives à un ou plusieurs passagers associés à l'enregistrement de réservation. Des exemples d'information de voyage incluent : un lieu d'origine, un lieu de destination, une date de départ, une date de retour, un nombre dans un groupe, une classe de réservation, un nombre d'escales, un numéro de vol, un identifiant de fournisseur de voyage, une cabine, et ainsi de suite. Des exemples d'informations de passager, pour chaque passager parmi ledit un ou plusieurs passagers associés à un enregistrement de réservation incluent : le nom, le genre, la date de naissance, la nationalité, l'adresse du domicile, l'adresse professionnelle, les informations du passeport, une adresse courriel, un numéro de téléphone, une demande de service spécial (« SSR»), et ainsi de suite. [0049] Les enregistrements de billets pour un ou plusieurs fournisseurs de services de voyage sont stockés dans la base de données billettiques 255 sous le contrôle du système de gestion billettique 250. Le système de gestion billettique 250 est configuré pour interagir avec le moteur de recherche 220, le système de gestion d'inventaire 230, et le système de gestion de réservations 240 afin de traiter les demandes d'émission de billets reçues au cours d'une phase d'émission de billets d'un processus de réservation 12 de voyage. Au cours du traitement des demandes d'émission de billets, le système de gestion billettique 250 génère des enregistrements de hillets dans la hase de données hillettiques 255 pour chaque segment de services de voyage (« segment ») et chaque passager associé à l'itinéraire de voyage réservé en utilisant les informations de voyage et les informations de passager dans l'enregistrement de réservation. [0050] Par exemple, un enregistrement de réservation peut inclure des informations de passager relatives à deux passagers. L'enregistrement de réservation peut par ailleurs inclure des informations définissant deux segments ferroviaires pour voyager d'un lieu d'origine à un lieu de destination, via un lieu d'escale et un segment ferroviaire pour voyager du lieu de destination au lieu d'origine. Dans cet exemple, l'information de voyage définit au total trois segments ferroviaires pour deux passagers. En réponse à la réception d'une demande d'émission de hillets associée à l'enregistrement de réservation dans cet exemple, le système de gestion billettique 250 générerait six enregistrements de billets dans la hase de données hillettiques 255. Le système de gestion billettique 250 soumettrait une demande au système de gestion des réservations 240 pour mettre à jour l'enregistrement de réservation stocké dans la hase de données de réservations 245 afin d'inclure six numéros de billets identifiant chaque enregistrement de billet généré. C'est-à-dire que dans cet exemple, un simple enregistrement de réservation stocké dans la hase de données de réservation 245 inclurait six numéros de billet identifiant six enregistrements de billet stockés dans la hase de données billettique 255. [0051] Les ensembles de tarifs non modifiés sont stockés dans une base de données d'ensemble de tarifs de base 265 sous le contrôle du système de gestion d'ensembles de tarifs de base 260. Le système de gestion d'ensembles de tarifs de base 260 est configuré pour interagir avec les systèmes de fournisseurs de voyages via un réseau (p. ex. le réseau 160 de la FIG. 1) pour assurer que les données tarifaires stockées dans la base de données d'ensemble de tarifs 265 sont synchronisées avec les données tarifaires hébergées dans les systèmes de fournisseurs de voyages. Dans un mode de réalisation, les systèmes de fournisseurs de voyages poussent les mises à jour de données tarifaires vers la base de données d'ensembles de tarifs de base 265 via le système de gestion d'ensembles de tarifs de base 260. Dans un mode de réalisation, le système de gestion d'ensembles de tarifs de base 260 interroge périodiquement les structures de donnée qui résident sur les systèmes de fournisseurs de voyages pour s'assurer que les données tarifaires stockées dans la base de données d'ensembles de tarifs de base 265 sont synchronisées avec les données tarifaires hébergées sur les systèmes de fournisseurs de voyages. [0052] La Fig. 3 est une illustration de haut niveau de gestion de versions parallèles de contenu à divers moments dans le temps conformément à un mode de réalisation de la 13 présente invention. Dans un mode de réalisation, la technique de gestion de versions parallèles de contenu décrite dans la FIG. 3 peut être effectuée par le gestionnaire de versions 213 de la FIG. 2. Chaque ligne décrite dans la FIG. 3 représente un ensemble indépendant de tarifs qui est actuellement accessible à un serveur de contenu (p. ex., le serveur de contenu 150 de la FIG. 1 et le système de réservation 200 de la FIG. 2) et l'occurrence une opération de ramification est désignée par un cercle. [0053] Comme illustré, la gestion de versions parallèles de contenu survient par rapport à une source de contenu d'origine stockant des données de contenu d'origine (c.-à-d. non modifiées). Dans cet exemple, la source de contenu d'origine est une hase de données d'ensembles de tarifs de hase 300 stockant des données d'ensembles de tarifs de hase. L'homme de métier reconnaîtra que la présente invention est également applicable à des sources de contenu d'origine stockant d'autres types de données de contenu d'origine. Des exemples de ces autres types de données de contenu d'origine incluent des données d'image, des données audios, des données vidéo, des données de texte et autres de ce genre. [0054] Au moment « tl », seule une version d'un ensemble de tarifs (c.-à-d., l'ensemble de tarifs de hase) est actuellement accessible au serveur de contenu. Par la suite au moment «tl », une opération de ramification 310 survient et un premier ensemble de tarifs modifié qui inclut une première variante est créé. Comme conséquence de l'opération de ramification 310, deux versions de l'ensemble de tarifs sont simultanément accessibles au serveur de contenu, au moment «t2 ». Suivant le moment «t2 », une opération de ramification 320 survient et un deuxième ensemble de tarifs modifié qui inclut une deuxième version de la première variante est créé. Comme conséquence de l'opération de ramification 320, deux versions de l'ensemble de tarifs sont simultanément accessibles au serveur de contenu, au moment «t3 ». [0055] Chaque version parallèle de l'ensemble de tarifs peut évoluer indépendamment dans le temps comme illustré par l'opération de ramification 330, l'opération de ramification 340 et l'opération de ramification 350. Cette évolution indépendante peut impliquer de modifier l'ensemble de tarifs de base avec des variantes différentes, comme illustré par les opérations de ramification 330 et 350 dans lesquelles l'ensemble de tarifs de base est modifié par une troisième variante et une quatrième variante respectivement. Cette évolution indépendante peut aussi impliquer par ailleurs de modifier les ensembles de tarifs modifiés avec des variantes supplémentaires ainsi que l'illustre l'opération de ramification 340 dans laquelle le premier ensemble de tarifs modifié est par ailleurs modifié avec une deuxième variante. Quelle que soit l'occurrence de cette évolution indépendante, des résultats similaires s'ensuivent - des versions supplémentaires de l'ensemble de tarifs sont simultanément disponibles au serveur de contenu. Par exemple, quatre versions de l'ensemble de tarifs sont simul- 14 tanément accessibles au serveur de contenu au moment «t4 », cinq versions de l'ensemble de tarifs sont simultanément accessihles au moment «t5 » et six versions de l'ensemble de tarifs sont simultanément accessihles au moment «t6 » à la suite des opérations de ramification 330, 340 et 350 respectivement. [0056] La Fig. 4 décrit une illustration de haut niveau d'une structure de donnée 400 adaptée à r implémentation du de la gestion de versions parallèles de contenu conformément à un mode de réalisation de la présente invention. Comme détaillé ci-dessus par rapport à la FIG. 2, des versions parallèles d'un ensemble de tarifs peuvent être traitées comme des ensembles de tarifs indépendants en créant un fichier enfant lorsqu'une opération de ramification survient. Pour faciliter ce traitement indépendant, la structure de données 400 est composée une pluralité d'éléments de données discrets, d'objets, ou de fichiers («fichiers ») (c.-à-d., les fichiers 410, 420, 422, 424, 430 et 440). En d'autres termes, chaque fichier parmi la pluralité des fichiers inclus dans la structure de données 400 est traité comme donnée d'unité atomique. [0057] Généralement, chaque fichier parmi la pluralité des fichiers composant la structure de donnée 400 représente soit un état actuel d'un ensemble de tarifs relatif à un état d'un ensemble parent de tarifs lorsque l'ensemble de tarifs modifié a été créé, ou un état actuel d'un ensemble de tarifs de hase. Par exemple, le fichier 420 représente un état actuel d'un premier ensemble de tarifs modifié alors que le fichier 410 représente un état actuel d'un ensemble de tarifs de hase. Si le premier ensemble de tarifs modifié est distinct d'autres versions de l'ensemble de tarifs en vertu d'une première variante, le fichier 420 stocke des données correspondant à la première variante. Faisant référence à la FIG. 3, le fichier 420 est créé par un gestionnaire de versions (p. ex., le gestionnaire de versions 213 de la FIG. 2) concomitamment à l'opération de ramification 310. [0058] Comme autre exemple, les fichiers 430 et 440 représentent un état actuel d'un quatrième ensemble de tarifs et un cinquième ensemble de tarifs, respectivement. Si le quatrième ensemble de tarifs modifié est distinct d'autres versions de l'ensemble de tarifs en vertu d'une troisième variante et que le cinquième ensemble de tarifs modifié est distinct d'autres versions de l'ensemble de tarifs en vertu d'une quatrième variante, les fichiers 430 et 440 qui stockent des données correspondant à la troisième et à la quatrième variante respectivement. Faisant référence à la FIG. 3, les fichiers 430 et 440 sont créés par le gestionnaire de versions concomitamment aux opérations de ramification 330 et 350 respectivement. [0059] Comme illustré par la FIG. 4, un ensemble de tarifs modifié peut avoir un autre ensemble de tarifs modifié comme ensemble parent de tarifs qui permet les modifications ultérieures des modifications d'un ensemble de tarifs de base. Par exemple, les fichiers 422 et 424 représentent un état actuel d'un deuxième ensemble de tarifs modifié et d'un troisième ensemble de tarifs modifié respectivement, avec chaque ensemble de tarifs modifié ayant un autre ensemble de tarifs modifié (c.-à-d., le premier ensemble de tarifs modifié) comme ensemble parent de tarifs. Ces autres modifications facilitent l'évolution indépendante des ensembles de tarifs modifiés. Cette évolution indépendante peut inclure l'instanciation de versions différentes d'une modification d'un ensemble de tarifs de hase. Dans le mode de réalisation de la FIG. 4, ceci est illustré par le fichier 422 qui stocke des données correspondant à une deuxième version de la première variante. Cette évolution indépendante peut aussi inclure divers aspects différents de l'ensemble de tarifs de hase. Dans le mode de réalisation de la FIG. 4, ceci est illustré par les fichiers 430 et 440 qui stockent des données correspondant à la troisième et à la quatrième variante respectivement. [0060] Dans un mode de réalisation, le gestionnaire de versions crée concomitamment une image d'un fichier représentant un état d'un ensemble parent de tarifs lorsqu'un ensemble de tarifs modifié est créé. Par exemple, le gestionnaire de versions peut créer concomitamment une image du fichier 410 pour capturer un état actuel de l'ensemble de tarifs de hase lorsque le fichier 420 est créé. Comme autre exemple, le gestionnaire de versions peut créer concomitamment une image du fichier 420 pour capturer un état actuel de l'ensemble de tarifs de base lorsque le fichier 422 est créé. Dans un mode de réalisation, le gestionnaire de versions crée concomitamment une copie à lecture seule d'un fichier représentant un état d'un ensemble parent de tarifs lorsqu'un ensemble de tarifs modifié est créé. Par exemple, le gestionnaire de versions peut créer concomitamment une image du fichier 410 pour capturer un état actuel de l'ensemble de tarifs de base lorsque le fichier 430 est créé. Comme autre exemple, le gestionnaire de versions peut créer concomitamment une image du fichier 420 pour capturer un état actuel du premier ensemble de tarifs modifié lorsque le fichier 424 est créé. Dans un mode de réalisation, le gestionnaire de versions crée concomitamment une copie à lecture seule d'un fichier pour un ensemble parent de tarifs lorsqu'un ensemble de tarifs modifié est créé afin de capturer une quelconque modification subséquente à l'ensemble parent de tarifs. [0061] Lors de la création d'un fichier qui représente un état actuel d'un ensemble de tarifs modifié, le gestionnaire de versions enrichit le fichier avec des métadonnées. Ces métadonnées peuvent inclure des informations concernant l'ensemble de tarifs modifié ou son ensemble parent de tarifs. Par exemple, les métadonnées peuvent inclure une identité de l'ensemble parent de tarifs, une information de localisation pour un fichier associé à l'ensemble parent de tarifs, une quelconque information de de la gestion de versions ( p. ex., un numéro de version de l'ensemble parent de tarifs), un horodatage associé à une opération de ramification qui a donné lieu à l'ensemble de tarifs modifié, des données descriptives concernant une variante de l'ensemble de tarifs modifié et 16 ainsi de suite. [0062] Dans un mode de réalisation, le gestionnaire de versions compile un ensemble de tarifs modifié en réponse à la réception d'une valeur provenant d'un gestionnaire de données tarifaires (p. ex., le gestionnaire de données tarifaires 217 de la FIG. 2) correspondant à l'ensemble de tarifs modifié. Dans un mode de réalisation, la valeur inclut les informations de localisation pour un fichier représentant un état actuel de l'ensemble de tarifs modifié. Dans un mode de réalisation, la valeur d'un gestionnaire de données tarifaires (p. ex., le gestionnaire de données tarifaires 217 de la FIG. 2) est basée sur un identifiant unique associé à une interrogation de recherche. En utilisant les métadonnées récupérées du fichier représentant l'état actuel de l'ensemble de tarifs modifié, le gestionnaire de versions localise un fichier associé à son ensemble parent de tarifs. Si cet ensemble parent de tarifs n'est pas un ensemble de tarifs de hase, le gestionnaire de versions localise un fichier associé à un ensemble parent de tarifs de cet ensemble de tarifs en utilisant les métadonnées récupérées à partir de son fichier associé jusqu'à ce qu'un fichier associé à l'ensemble de tarifs de base soit localisé. Lors de la localisation du fichier associé à l'ensemble de tarifs de base, le gestionnaire de versions analyse les données récupérées de cette chaîne de fichiers pour compiler l'ensemble de tarifs modifié. [0063] Par exemple, lors de la compilation du deuxième ensemble de tarifs modifié, le ges- tionnaire de versions peut recevoir une valeur qui décrit une localisation du fichier 422. En utilisant les métadonnées récupérées du fichier 422, le gestionnaire de versions peut localiser le fichier 420 (ou une image/copie à lecture seule du fichier 420 créé concomitamment à l'opération de ramification 320 de la FIG. 3). Puisque le fichier 420 correspond au premier ensemble de tarifs modifié et non pas à l'ensemble de tarifs de base, le gestionnaire de versions localise le fichier 410 (ou une image/copie à lecture seule du fichier 410 créée concomitamment à l'opération de ramification 310 de la FIG. 3) correspondant à l'ensemble de tarifs de base. Le gestionnaire de versions peut ensuite analyser les données récupérées du fichier 422 ainsi que les données récupérées des fichiers 420 et 410 (ou les images/copies à lecture seule correspondantes) pour compiler le deuxième ensemble de tarifs modifié. [0064] Dans un mode de réalisation, les données tarifaires sont récupérées d'un fichier re- présentant un état actuel d'un ensemble de tarifs modifié sans compiler l'ensemble de tarifs modifié en utilisant les métadonnées du fichier. C'est-à-dire, que les données tarifaires peuvent être récupérées directement à partir du fichier sans que le gestionnaire de versions crée une version complète de l'ensemble de tarifs modifié. Dans ce mode de réalisation, les données tarifaires sont récupérées en analysant les métadonnées pour déterminer si le fichier inclut des informations de prix pour un itinéraire de voyage qui satisfait les paramètres de recherche reçus d'un client soumettant une interrogation de 17 recherche. Si l'analyse des métadonnécs détermine que ces informations de prix sont incluses dans le fichier, les données tarifaires sont directement récupérées à partir du fichier. Si l'analyse des métadonnécs détermine que ces informations de ne sont pas incluses dans le fichier, un fichier parent associé à l'ensemble parent de tarifs de l'ensemble de tarifs modifié est localisé en utilisant les métadonnécs. Ce processus continue jusqu'à ce qu'une analyse des métadonnécs d'un fichier parent indique que ces informations de prix sont incluses dans le fichier parent. [0065] La Fig. 5 illustre un exemple de relations entre un ensemble de données de tarifs de hase 510 et des variantes des données de l'ensemble de tarifs de base 510 conformément un mode de réalisation de la présente invention. Dans la FIG. 5, les données d'ensembles de tarifs de hase 510 représentent des données stockées dans une hase de données d'ensembles de tarifs de hase (p. ex., la hase de données d'ensembles de tarifs de hase 265 et/ou 300 des FIGS. 2 et 3 respectivement). En outre, chaque donnée de variante dans la FIG. 5 représente des données stockées dans un fichier associé à un ensemble de tarifs modifié. C'est-à-dire, en faisant référence à la FIG. 4, que la première donnée de variante 520 représente des données stockées dans le fichier 420, la deuxième donnée de variante 522 représente des données stockées dans le fichier 424, la troisième donnée de variante 530 représente des données stockées dans le fichier 430 et la quatrième donnée de variante 540 représente des données stockées dans le fichier 440. [0066] Comme illustré, la donnée de variante stockée dans un fichier associé à un ensemble particulier de tarifs modifié correspond à un sous-ensemble de données de tarifs de base 510. Ceci facilite l'introduction de changements étroitement définis qui modifient des aspects particuliers des données de l'ensemble des tarifs de base 510. Par exemple, si les données d'ensemble de tarifs de base 510 correspondent à des données tarifaires pour des trajets desservis par un transporteur ferroviaire en Europe, la première donnée de variante 520 peut définir des changements effectués aux données tarifaires pour un trajet Paris Nice. Dans ce cas, les données tarifaires pour un trajet Paris Lille desservi par le transporteur ferroviaire resteraient inchangées par la première donnée de variante 520. Les changements effectués au trajet Paris Lille peuvent être définis par la troisième donnée de variante 530. [0067] En plus de définir des changements effectués aux données tarifaires pour des trajets particuliers, la donnée de variante peut aussi définir des changements effectués aux données tarifaires pour d'autres aspects des données d'ensembles de tarifs de base 510. Les autres aspects peuvent inclure : les régions de voyage (p. ex., des trajets en Allemagne), une fourchette d'horaires de voyage (p. ex., des itinéraires de voyage impliquant un hébergement de nuit), des classes de tarifs (p. ex., la classe économique), des sous-ensembles de passagers (p. ex., passagers seniors ou enfants) et ainsi de suite. 18 En continuant avec l'exemple précédent, la quatrième donnée de variante 540 peut définir des changements effectués aux données tarifaires pour les passagers seniors. [0068] En plus d'introduire des changements qui modifient directement des aspects par- ticuliers des données d'ensembles de tarifs de hase 510, la donnée de variante peut aussi introduire des changements qui modifient indirectement les données d'ensembles de tarifs de hase 510. Ces changements peuvent être implémentés par une donnée de variante définissant des changements qui modifient des aspects particuliers d'un autre ensemble de tarifs modifié. En utilisant l'exemple précédent, la deuxième donnée de variante 522 peut définir des changements effectués aux données tarifaires pour des passagers seniors sur le trajet Paris Nice. Ceci réduit encore plus la granularité des changements effectués par la donnée de variante aux données d'ensembles de tarifs de hase 510. [0069] La donnée de variante peut aussi définir des versions différentes de ces changements. En faisant référence à la FIG. 4, le fichier 422 stocke des données correspondant à une deuxième version de la première variante. Dans ce cas, si la première donnée de variante 520 représente des données stockées dans le fichier 420, les données stockées dans le fichier 422 coïncideraient avec la première donnée de variante 520 dans la FIG. 5. En continuant avec l'exemple précédent, la première donnée de variante 520 peut définir une première version d'une réduction de données tarifaires pour un trajet Paris Nice telle qu'un rabais de 50 %. Les données stockées dans le fichier 422 peuvent définir une deuxième version de la réduction de donnée tarifaire pour le trajet Paris Nice, telle que pour un billet acheté/un billet offert. Avec l'offre un billet acheté/ un billet offert, un client pourrait acheter un premier billet pour le trajet Paris Nice et recevoir un deuxième billet gratuit pour ce trajet. [0070] Dans la FIG. 5, les données de variantes correspondant aux variantes de données d'ensembles de tarifs de base 510 (p. ex., la première variante 520, la deuxième variante 522, la troisième variante 530 et la quatrième variante 540) sont illustrées comme étant désunies dans le but de simplifier l'illustration. Dans certains modes de réalisation, des données de variantes correspondant à une variante de données d'ensemble de tarifs de base 510 peuvent intersecter avec deux ou plusieurs autres variantes conformément à des aspects de la présente invention. Par exemple, conformément un mode de réalisation de la présente invention, la deuxième variante 522 peut intersecter avec, à la fois, la première variante 520 et la troisième variante 530. Dans cet exemple, la deuxième variante 522 peut par ailleurs modifier des aspects particuliers, à la fois, de la première variante 520 et de la troisième variante 530. [0071] La Fig. 6 décrit un diagramme de Venn 600 pour illustrer la performance des opérations ensemblistes sur les versions parallèles de contenu, conformément à un 19 mode de réalisation de la présente invention. Ainsi que cela a été détaillé ci-dessus, par rapport à la FIG. 2, chacune des versions parallèles d'un ensemble de tarifs peut être évaluée objectivement en utilisant des métriques d'évaluation déterminées pour chaque version en utilisant les données d'évaluation compilées. Sur la hase de cette évaluation objective, une détermination peut être faite que des clients répondent plus positivement à une première version d'un ensemble de tarifs qu'à une deuxième version de l'ensemble de tarifs. En faisant cette détermination, il peut être souhaitable d'incorporer complètement ou partiellement (c.-à-d., de fusionner) des changements définis par une donnée de variante associée à cette première version dans un ensemble de tarifs de base (ou une autre version de l'ensemble de tarifs). [0072] Autrement, cette évaluation objective peut déterminer que des clients répondent plus positivement à la deuxième version de l'ensemble de tarifs qu'à la première version de l'ensemble de tarifs. Dans ce cas, il est souhaitable d'effectuer un retour en arrière complet ou partiel des changements définis par une donnée de variante associée à cette première version de l'ensemble de tarifs lorsque cette donnée de variante a été incorporée dans l'ensemble de tarifs de hase (ou une autre version de l'ensemble de tarifs). [0073] Une telle fusion ou opération de retour en arrière implique typiquement des com- paraisons, élément par élément, entre chaque ensemble de tarifs faisant l'objet d'une fusion. Par contraste, des modes de réalisation de la présente invention fournissent ces opérations de fusion ou de retour en an-ière en utilisant des opérations ensemblistes effectuées sur des fichiers enfants (p. ex. ; les fichiers 420, 422, 424, 430 et 440 de la FIG. 4). Vu que les fichiers enfants stockent des données correspondant à des variantes qui définissent des changements réalisés sur des ensembles parents de tarifs, ces changements peuvent être identifiés et fusionnés ou ramenés à un état antérieur comme il convient. En outre, dans la mesure où chaque fichier enfant a un fichier parent correspondant représentant une version particulière de l'ensemble de tarifs avant modification par une variante respective stockée dans ce fichier enfant, les relations résultantes parent-enfant peuvent améliorer l'intégrité lorsque des changements supplémentaires sont introduits. [0074] Dans la FIG. 6, chacun des fichiers 610 et 620 stocke des données correspondant à une version d'un ensemble de tarifs parmi une pluralité de versions de l'ensemble de tarifs. Par exemple, les fichiers 610 et 620 peuvent correspondre aux fichiers 420 et 424 de la FIG. 4 respectivement. Si une opération d'union est effectuée sur les fichiers 610 et 620 pour agréger les données dans les deux fichiers, un fichier résultant stockerait des données représentées par les régions 630, 640 et 650. Si une opération de différence est effectuée sur les fichiers 610 et 620 pour identifier des différences entre ces fichiers, un fichier résultant stockerait les données représentées par les régions 630 et 650. Si une opération d'intersection est effectuée sur le fichier 610 et 620 pour identifier des données communes stockées dans les deux fichiers, un fichier résultant stockerait les données représentées par la région 640. L'homme de métier reconnaîtra que d'autres opérations ensemblistes au-delà de des opérations ensemblistes divulguées dans les présentes peuvent être effectuées sur les fichiers 610 et 620 sans s'éloigner de l'esprit de la présente invention. Dans un mode de réalisation, les opérations ensemblistes techniques décrites par rapport à la FIG. 6 peuvent être mises en oeuvre par le gestionnaire de versions 215 de la FIG. 2. [0075] La FIG. 7 décrit un mode de réalisation d'un procédé 700 pour des tests dépendants de canaux de versions parallèles de contenu dans un environnement informatique distribué. Dans un mode de réalisation, le procédé 700 peut être mis en oeuvre par le système de réservation 200 de la FIG. 2 au moment où il génère un identifiant unique pour une interrogation de recherche reçue. Au bloc 702, une interrogation de recherche incluant une pluralité de paramètres de recherche est reçue d'un dispositif client. Dans un mode de réalisation, le bloc 702 peut être mis en oeuvre par le service Web 211 de la FIG. 2. Dans un mode de réalisation, la demande de recherche est une sollicitation d'API adressée à une API d'un système de réservation. Dans un mode de réalisation, le dispositif client est un dispositif utilisateur. Dans un mode de réalisation, le dispositif client est un client sur le Web (p. ex., un serveur d'application, un site Web de recherche et/ou un serveur de terminal) associé à un dispositif utilisateur. Dans un mode de réalisation, la pluralité des paramètres de recherche correspond à une demande de voyage pour un client. Dans un mode de réalisation, la pluralité des paramètres de recherche inclut un numéro de segment fen-oviaire, une date de départ, une date d'arrivée, un point d'origine, une destination, un nombre d'arrêts, une classe de réservation, un point de vente, un nombre dans un groupe, une RFSIC ou une combinaison de ceux-ci. [0076] Au bloc 704, un identifiant unique associé à la requête de recherche est déterminé. Dans un mode de réalisation, le bloc 704 peut être mis en oeuvre par le gestionnaire de routage 213 de la FIG. 2. Dans un mode de réalisation, l'identifiant unique est déterminé en utilisant la pluralité des paramètres de recherche. Dans un mode de réalisation, l'identifiant unique est déterminé en utilisant un témoin stocké sur le dispositif client. Dans un mode de réalisation, l'identifiant unique est déterminé en utilisant une adresse réseau associée au dispositif client, une adresse machine d'un composant inclus dans le dispositif client, un ID d'un utilisateur associé au dispositif client, un ID d'une entité commerciale associée au dispositif client, des authentifiants de connexion fournis en établissant une session de communication entre le système de réservation et le dispositif client, des informations fournies par un plugiciel fonctionnant dans un déploiement d'application associée au dispositif client, ou une combinaison de ceux-ci. 21 [0077] Au bloc 706, une version d'un ensemble de tarifs parmi une pluralité de versions de l'ensemble de tarifs est accédée sur la hase de l'identifiant unique. Chaque version de l'ensemble de tarifs parmi la pluralité des versions de l'ensemble de tarifs est distincte des autres versions en vertu d'une variante. Dans un mode de réalisation, la variante définit des changements effectués aux données tarifaires pour un sous-ensemble de donnée d'ensemble de tarifs de hase. Dans un mode de réalisation, le sous-ensemble de données d'ensembles de tarifs de hase correspond à une route particulière desservie par un fournisseur de voyage associé aux données d'ensembles de tarifs de hase, une région de voyage desservie par le fournisseur de voyages, une fourchette d'horaires de voyage, une place de cabine proposée par le fournisseur de voyage, un sous-ensemble de passager, et ainsi de suite. Dans un mode de réalisation, la variante définit une version différente d'une autre variante. Dans un mode de réalisation, la version accédée de l'ensemble de tarifs est un ensemble de tarifs modifié. Dans un mode de réalisation, la version accédée de l'ensemble de tarifs est un ensemble de tarifs de hase. Dans un mode de réalisation, les données sont en cache dans un dispositif de stockage associé au système de réservation qui associe l'identifiant unique à la version accédée d'un ensemble de tarifs. Dans un mode de réalisation, les données en cache incluent des informations d'horodatage indiquant une heure de réception de l'interrogation de recherche, une heure d'accès à la version accédée de l'ensemble de tarifs, une heure de mise en cache des données, ou une combinaison de ces éléments. Dans un mode de réalisation, le bloc 706 est mis en oeuvre par le gestionnaire de versions 215 de la FIG. 2. Dans un mode de réalisation, le bloc 706 est mis en oeuvre par le gestionnaire de versions 217 de la FIG. 2. [0078] Au bloc 708, les données tarifaires sont récupérées à partir de la version accédée de l'ensemble de tarifs. Dans un mode de réalisation, les données tarifaires sont récupérées dans un ensemble de tarifs modifié compilé par un gestionnaire de versions avant que l'interrogation de recherche soit reçue du dispositif client. Dans un mode de réalisation, les données tarifaires sont directement récupérées dans un fichier enfant stockant des données correspondant à une variante d'un ensemble de tarifs modifié en examinant les métadonnées associées au fichier enfant. Dans un mode de réalisation, les données tarifaires sont récupérées directement à partir d'une image parente stockant des données qui représentent un état d'un ensemble parent de tarifs lorsque l'ensemble de tarifs modifié a été ramifié à partir de l'ensemble parent de tarifs en examinant les métadonnées associées à l'image parente. Dans un mode de réalisation, le bloc 708 est mis en oeuvre par le gestionnaire de versions 217 de la FIG. 2. Au bloc 710, un résultat de recherche est enrichi avec les informations de prix pour un itinéraire de voyage qui satisfait la pluralité des paramètres de recherche en utilisant les données tarifaires récupérées. Dans un mode de réalisation, le bloc 710 peut être mis en oeuvre par le ges- tionnaire de routage 213 de la FIG. 2. Au bloc 712, le résultat est transmis au dispositif client en réponse à l'interrogation de recherche. Dans un mode de réalisation, le service Web 211 met en oeuvre le bloc 712. [0079] Après avoir décrit divers modes de réalisation de l'invention, un environnement in- formatique exemplaire adapté à l'implémentation des modes de réalisation de l'invention va maintenant être décrit. En faisant référence à la FIG. 8, un diagramme bloc d'un dispositif informatique exemplaire est fourni et est désigné de façon générale comme le système informatique 800. Le dispositif utilisateur 110, le serveur d'applications 120, le site Web de recherche 130, le serveur de terminal 140, le serveur de contenu 150, le système de réservation 200, et un quelconque composant du système de réservation 200 peuvent être implémentés sur un ou plusieurs dispositifs ou systèmes informatiques, tels que le système informatique exemplaire 200. Le système informatique 200 peut inclure un processeur 826, une mémoire 828, un dispositif de mémoire de masse 830, une interface entrée/sortie (I/0) 832, et une interface homme-machine (HMI) 834. Le système informatique 800 peut aussi être couplé de façon fonctionnelle à une ou plusieurs ressources externes 836 via le réseau 823, ou une interface I/0 832. Les ressources externes peuvent inclure, niais de façon non exhaustive, des serveurs, des hases de données, des dispositifs de stockage de masse, des dispositifs périphériques, des services de réseau en nuage basé sur le cloud, ou toute autre ressource informatique adaptée qui peut être utilisée avec l'ordinateur 800. [0080] Le processeur 826 peut inclure un ou plusieurs dispositifs sélectionnés : micropro- cesseurs, microcontrôleurs, processeurs de signaux numériques, micro-ordinateurs, unités centrales de traitement, réseaux de portes programmables, dispositifs logiques programmables, machines à état défini, circuits logiques, circuits analogiques, circuits numériques, ou tout autre dispositif servant à manipuler des signaux (analogues ou numériques) basé sur des instructions de fonctionnement qui sont stockées dans la mémoire 828. La mémoire 828 peut inclure un seul dispositif de mémoire ou une pluralité de dispositifs de mémoire comprenant, de façon non exhaustive, la mémoire à lecture seule (ROM), la mémoire à accès aléatoire (RAM), la mémoire volatile, la mémoire non volatile, la mémoire vive statique (SRAM), la mémoire dynamique à accès aléatoire (DRAM), la mémoire flash, la mémoire cache, ou tout autre dispositif capable de stocker des informations. Le dispositif de mémoire de masse 830 peut inclure des dispositifs de stockage de données tels qu'un disque dur, un disque optique, un dérouleur de bande magnétique, un circuit à l'état solide non volatile, ou tout autre dispositif capable de stocker des informations. [0081] Le processeur 826 peut fonctionner sous le contrôle d'un système d'exploitation 838 qui réside dans la mémoire 828. Le système d'exploitation 838 peut gérer les ressources de l'ordinateur de sorte que le code de programme de l'ordinateur, intégré 23 sous forme d'un ou plusieurs logiciels d'application, tels que l'application 840 qui réside dans la mémoire 828, puisse disposer d'instructions exécutées par le processeur 826. Dans un autre mode de réalisation, le processeur 826 peut exécuter l'application 840 directement et dans ce cas, le système d'exploitation 838 peut être omis. Une ou plusieurs structures de donnée 842 peuvent également résider dans la mémoire 828, et peuvent être utilisées par le processeur 826, le système d'exploitation 838, ou l'application 840 pour stocker ou manipuler des données. [0082] L'interface 1/0 832 peut fournir une interface de machine qui couple de façon fonc- tionnelle le processeur 826 à d'autres dispositifs et systèmes, tels que le réseau 823 ou une ou plusieurs ressources externes 836. L'application 840 peut ainsi collaborer avec le réseau 823 et/ou les ressources externes 836 en communiquant via l'interface 0 832 pour fournir les divers éléments, fonctions, applications, processus, ou modules composant les modes de réalisation de l'invention. Le serveur d'application 840 peut aussi avoir un code de programme qui est exécuté par ladite une ou plusieurs ressources externes 836 ou, autrement, repose sur les fonctions ou signaux fournis par d'autres systèmes ou composants de réseau externes au système informatique 824. En effet, au vu des configurations presque infinies de matériel informatique et de logiciels possibles, les hommes de métier comprendront que les modes de réalisation de l'invention peuvent inclure des applications localisées à l'extérieur de l'ordinateur 824, distribuées à des ordinateurs multiples et à d'autres ressources externes 836, ou apportées par des ressources informatiques (matérielles et logicielles) qui sont fournies comme services sur le réseau 823, par exemple un service d'informatique en nuage. [0083] Le HMI 834 peut être couplé de façon opérationnelle au processeur 826 du système informatique 824 d'une façon connue pour permettre à un utilisateur d'interagir directement avec le système informatique 824. Le HMI 834 peut inclure des affichages vidéo ou alphanumériques, un écran tactile, un haut-parleur et tous autres indicateurs audio et visuels adaptés capables de fournir des données à l'utilisateur. Le HMI 834 peut aussi inclure des dispositifs de saisie et des contrôles tels qu'un clavier alphanumérique, un dispositif de pointage, des boutons poussoirs, des boutons de contrôle, des microphones, etc. capables d'accepter des commandes ou des saisies de l'utilisateur et de transmettre les saisies entrées au processeur 826. [0084] Une base de données 844 peut résider sur le dispositif de mémoire de masse 830, et peut être utilisée pour collecter et organiser les données utilisées par les différents systèmes et modules décrits dans les présentes. La base de données 844 peut inclure des données ainsi que les structures de donnée qui les accommodent pour stocker et organiser les données. En particulier, la base de données 844 peut-être arrangée selon toute organisation ou structure de base de données incluant, mais de façon non exhaustive, une base de données relationnelle, une base de données hiérarchique, une 24 hase de données en réseau, ou des combinaisons de celles-ci. Un système de gestion de hase de données sous forme de logiciel informatique d'application qui s'exécute sous la forme d'instructions sur le processeur 826 peut être utilisé pour accéder à l'information ou aux données stockées dans des fichiers de la hase de données 844 en réponse à une interrogation, lorsqu'une interrogation peut être déterminée de façon dynamique et exécutée par le système d'exploitation 838, les autres applications 840, ou un ou plusieurs modules. [0085] En général les routines exécutées pour mettre en oeuvre les modes de réalisation de l'invention, qu'elles soient implémentées dans le cadre d'un système d'exploitation ou d'une application spécifique, d'un composant, d'un programme, d'un objet, d'un module ou d'une séquence d'instructions, ou même un sous-ensemble de ceux-ci, peuvent être désignées dans les présentes comme «code de programme informatique » ou simplement « code de programme». Le code de programme comprend typiquement des instructions lisibles par ordinateur qui résident à divers moments dans divers dispositifs de mémoire et de stockage dans un ordinateur, et qui lorsqu'il est lu et exécuté par un ou plusieurs processeurs dans un ordinateur, amène cet ordinateur à mettre en oeuvre les opérations et/ou les éléments propres aux aspects variés des modes de réalisation de l'invention. Les instructions d'un programme informatique lisible par ordinateur pour accomplir les opérations des modes de réalisation de l'invention peuvent être, par exemple, le langage d'assemblage ou, un code source ou un code objet, écrits en combinaison avec un ou plusieurs langages de programmation. [0086] Le code de programme mis en oeuvre dans toute application/module décrit(e) dans les présentes peut être distribué individuellement ou collectivement comme un produit programme d'ordinateur, sous une variété de formes. En particulier, le code de programme peut être distribué en utilisant un support de stockage lisible par ordinateur ayant des instructions de programme lisibles par ordinateur pour amener un processeur à mettre en oeuvre des aspects des modes de réalisation de l'invention. [0087] Les supports de stockage de données lisibles pal- ordinateur qui sont intrinsèquement non transitoires, peuvent inclure des médias tangibles, volatiles et non volatiles, amovibles et non amovibles, implémentés dans tout procédé ou technologie de stockage de données, tels que des instructions de programme lisibles par ordinateur, des structures de donnée, des modules de programme, ou autres données. Les supports de stockage lisibles par ordinateur peuvent aussi comprendre des mémoires : une mémoire à accès aléatoire (RAM), une mémoire à lecture seule (ROM), une mémoire à lecture seule programmable et effaçable (EPROM), une mémoire à lecture seule programmable et effaçable électriquement (EEPROM), une mémoire flash, ou autre technologie de support solide de mémoire, un disque compact portable doté d'une mémoire à lecture seule (CD-ROM), ou autre stockage optique, une bande d'enregistrement magnétique, ou tout autre support pouvant être utilisé pour stocker l'information désirée et apte à être lu par un ordinateur. Le support de stockage lisihle par ordinateur ne peut être interprété en soi comme des signaux transitoires (p. ex. des ondes radio ou d'autres ondes électromagnétiques propagées via des supports de transmission tels qu'un guide d'ondes, ou des signaux électriques transmis par un câble). Les instructions de programme lisibles par ordinateur peuvent être téléchargées sur un ordinateur, un autre type d'appareil de traitement de données programmable ou sur tout autre dispositif de support de stockage lisible par machine, ou vers un ordinateur externe ou vers un dispositif de stockage externe par un réseau. [0088] Les instructions de programme lisibles par ordinateur, stockées sur un support lisihle par ordinateur, peuvent être utilisées pour instruire un ordinateur, d'autres types d'appareils programmables de traitement ou d'autres dispositifs pour fonctionner d'une façon particulière, de sorte que les instructions stockées sur un support lisible par ordinateur produisent un article de fabrication comprenant les instructions qui implémentent les fonctions/actions spécifiées dans les organigrammes, diagrammes de séquence, et/ou diagrammes blocs. Les instructions de programme informatiques peuvent être fournies à un ou plusieurs processeurs d'un ordinateur à usage général, un ordinateur dédié ou un autre appareil programmable de traitement de données pour produire une machine, de sorte que les instructions, lorsqu'elles sont exécutées via ledit un ou plusieurs processeurs, accomplissent une série de calculs pour mettre en oeuvre les fonctions, actions, et/ou les actions spécifiées dans les organigrammes, diagrammes séquentiels et/ou diagrammes blocs. [0089] Dans certains autres modes de réalisation, les fonctions et/ou les actions spécifiées dans les organigrammes, diagrammes séquentiels, et/ou des diagrammes blocs peuvent être commandées à nouveau, traitées en série et/ou traitées en même temps sans s'éloigner du champ d'application des modes de réalisation de l'invention. De plus, un quelconque des organigrammes, diagrammes séquentiels, et/ou diagrammes bloc peut inclure plus ou moins de blocs que ceux qui sont illustrés, conformément à des modes de réalisation de l'invention. [0090] La terminologie utilisée dans les présentes a pour but de décrire uniquement des modes de réalisation particuliers et n'est pas destinée à limiter les modes de réalisation de l'invention. On comprendra par ailleurs que les termes « comprennent », et/ou « comprenant » lorsqu'ils sont utilisés dans cette spécification, précisent la présence de caractéristiques énoncées, de nombres entiers, d'étapes, d'opérations, d'éléments, et/ou de composants, mais n'excluent pas la présence ou l'ajout d'une ou de plusieurs caractéristiques, nombres entiers, étapes, éléments, composants et/ou groupes en cela. De plus, dans la mesure où les termes «inclut», « ayant », «a », « avec » ou leurs variantes, sont utilisés dans la description détaillée des revendications, ces termes sont censés 26 être inclusifs de façon similaire au terme «comprendre». [0091] Bien que l'invention ait été illustrée par une description de modes de réalisation divers et bien que ces modes de réalisation aient été décrits de façon considérablement détaillée, il n'y a pas d'intention de la part du demandeur de restreindre ou de limiter en aucune façon le champ d'application des revendications annexées à ces détails. Des avantages supplémentaires et des modifications possibles apparaîtront aisément aux hommes de métier. L'invention sous ses aspects plus larges n'est donc pas limitée aux détails spécifiques, aux appareils représentatifs et aux procédés, ainsi qu'aux exemples illustratifs montrés et décrits. Par conséquent, il est possible de s'éloigner de ces détails sans s'éloigner de la portée du concept inventif général des demandeurs. 27 [Revendication I] [Revendication 2] [Revendication 3] [Revendication 4] REVENDICATIONSUn procédé pour traiter des versions parallèles de contenu, comprenant : la réception, d'un dispositif client, d'une interrogation de recherche incluant une pluralité de paramètres de recherche ; l'identification d'un résultat de recherche qui satisfait la pluralité des paramètres de recherche, le résultat de recherche comprenant un itinéraire de voyage ; la détermination d'un identifiant unique associé à la requête de recherche ; l'accès à une version d'un ensemble de tarifs parmi une pluralité de versions de l'ensemble de tarifs sur la base de l'identifiant unique, chaque version de l'ensemble de tarifs parmi la pluralité des versions de l'ensemble de tarifs étant distincte des autres versions en vertu d'une variante, chaque variante éttnt stockée dans un fichier enfant correspondant, chaque fichier enfant ayant un fichier parent correspondant représentant une version particulière de l'ensemble de tarifs préalablement à une modification de la variante respective ; la récupération des données tarifaires à partir de la version accédée de l'ensemble de tarifs ; l'enrichissement du résultat de recherche avec les informations tarifaires pour l'itinéraire de voyage en utilisant les données tarifaires récupérées ; et la transmission du résultat de recherche au dispositif client en réponse à l'interrogation de recherche. Le procédé de la revendication 1, dans lequel la pluralité des versions de l'ensemble de tarifs inclut un premier ensemble de tarifs modifié et un deuxième ensemble de tarifs modifié qui sont distincts des autres versions de l'ensemble de tarifs en vertu d'une première variante, le premier ensemble de tarifs modifié inclut une première version de la première variante et le deuxième ensemble de tarifs modifié inclut une deuxième version de la première variante. Le procédé de la revendication 2, comprenant par ailleurs : la détermination d'une première métrique d'évaluation pour le premier ensemble de tarifs modifié ; et la détermination d'une deuxième métrique d'évaluation pour le deuxième ensemble de tarifs modifié. Le procédé de la revendication 3, comprenant par ailleurs : 28 la fusion d'une de la première version et de la deuxième version de la première variante pour obtenir une version de base de l'ensemble de tarifs sur la base d'une comparaison entre la première métrique d'évaluation et la deuxième métrique d'évaluation. [Revendication 5] Le procédé de la revendication 3, comprenant par ailleurs : le rejet d'un du premier ensemble de tarifs modifié et du deuxième ensemble de tarifs modifié sur la base d'une comparaison entre la première métrique d'évaluation et la deuxième métrique d'évaluation. [Revendication 6] Le procédé de l'une quelconque des revendications 3 à 5, dans lequel la première métrique d'évaluation et la deuxième métrique d'évaluation sont des taux de conversion indicatifs d'un pourcentage de réservations d'itinéraires de voyage associés respectivement à la première version et à la deuxième version de la première variante. [Revendication 7] Le procédé de l'une quelconque des revendications 2 à 6, dans lequel la pluralité des versions de l'ensemble de tarifs inclut par ailleurs un troisième ensemble de tarifs modifié qui est distinct des autres versions de l'ensemble de tarifs en vertu d'une deuxième variante, et le troisième ensemble de tarifs modifié correspondant à un sous-ensemble du premier ensemble de tarifs modifié. [Revendication 8] Le procédé de la revendication 7, comprenant par ailleurs : la mise en oeuvre d'une opération ensembliste sur le premier ensemble de tarifs modifié et le troisième ensemble de tarifs modifié pour générer un quatrième ensemble de tarifs modifié. [Revendication 9] Le procédé de la revendication 8, dans lequel l'opération ensembliste inclut une opération ensembliste d'union, une opération ensembliste d'intersection, une opération ensembliste de différence, ou une combinaison de celles-ci. [Revendication 10] Le procédé de l'une quelconque des revendications 1 à 9, dans lequel l'identifiant unique est déterminé sur la base de la pluralité des paramètres de recherche, des authentifications de connexion de l'utilisateur, d'un identifiant de compte, d'un identifiant de machine du dispositif client, d'une adresse de réseau du dispositif client, d'une localisation géographique du dispositif client ou d'une combinaison de ces éléments. [Revendication 11] Le procédé de l'une quelconque des revendications 1 à 10, comprenant par ailleurs : La mise en cache de données liées à la recherche qui associent l'identifiant unique, l'interrogation de recherche, la version de 29 [Revendication 12] [Revendication 13] [Revendication 14] [Revendication 15] l'ensemble de tarifs accédée, la réponse à l'interrogation, ou une combinaison de ces éléments dans un dispositif de stockage associé au système de réservation. Le procédé de l'une quelconque des revendications 1 à 11, dans lequel la requête de recherche est une sollicitation d'une interface de programme d'application (API) adressée à une API d'un système de réservation. Un système pour traiter des versions parallèles de contenu, comprenant : un dispositif informatique; et un support de stockage lisible par ordinateur comprenant des instructions qui, lors de l'exécution par le dispositif informatique, amènent le système à : recevoir, d'un dispositif client, une interrogation de recherche incluant une pluralité de paramètres de recherche ; déterminer un identifiant unique associé à l'interrogation de recherche ; accéder à une version d'un ensemble de tarifs parmi une pluralité de versions de l'ensemble de tarifs sur la hase de l'identifiant unique, chaque version de l'ensemble de tarifs, parmi la pluralité des versions de l'ensemble de tarifs, étant distincte des autres opérations en vertu d'une variante, chaque variante étant stockée dans un fichier enfant correspondant, chaque fichier enfant ayant un fichier parent correspondant représentant une version particulière de l'ensemble de tarifs avant une modification de la variante respective ; récupérer des données tarifaires à partir de la version de l'ensemble de tarifs accédée ; enrichir un résultat de recherche avec les informations tarifaires pour un itinéraire de voyage qui satisfait la pluralité des paramètres de recherche en utilisant les données tarifaires récupérées ; et transmettre le résultat de recherche au dispositif client en réponse à l'interrogation de recherche. Le système de la revendication 13, le support de stockage lisible par ordinateur comprend par ailleurs des instructions qui, lors de l'exécution par le dispositif informatique, amènent par ailleurs le système à mettre en oeuvre le procédé de l'une quelconque des revendications 2 à 12. Un produit programme d'ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur pour mettre en oeuvre les étapes du procédé selon les revendications 1 à 12 lorsque ledit programme fonctionne sur un ordinateur.