Prix des vols : fixer quatre entrées

Collecter des prix de vols ne produit une série exploitable que si l’environnement derrière chaque requête reste constant. Un tarif est coté pour une devise, des paramètres régionaux, un point de vente et un appareil, et changer l’un d’eux peut changer le montant sans que rien ne change sur le marché. BotBrowser documente des entrées de paramètres régionaux, de fuseau horaire et de langues issues du profil, avec une sortie alignée géographiquement, de sorte qu’une capture peut déclarer l’environnement qu’elle représente. Il ne fournit pas de tarifs, ne réserve pas, ne contrôle pas la logique tarifaire d’une compagnie et ne garantit pas qu’un prix coté sera de nouveau renvoyé. Là où un flux tarifaire sous licence ou une API d’agence existe, c’est la voie à utiliser.

Résumé

• Un tarif est coté pour une devise, des paramètres régionaux, un point de vente et un appareil précis. Fixez les quatre, sinon l’écart mesuré est en partie un écart d’environnement.
• La devise est un réglage de requête ou de compte, pas une valeur du profil du navigateur. Les paramètres régionaux et les langues viennent du profil. Le point de vente est un paramètre du site qui doit concorder avec la région de sortie et le compte.
• Consignez les quatre entrées auprès de chaque tarif coté, pas une fois par exécution.
• Classez un écart selon les entrées qui ont changé. Un changement de devise n’est pas un mouvement tarifaire, quelle que soit l’ampleur du montant.
• Préférez un flux tarifaire sous licence ou une API d’agence lorsqu’ils existent. Une exécution de navigateur ne crée pas d’autorisation de suivi et ne peut pas réserver.

Sommaire

• Quatre entrées qui déplacent un tarif
• Lesquelles un profil retient réellement
• Consigner les quatre entrées par capture
• Lire un écart selon l’entrée qui a changé
• Quand un flux tarifaire sous licence est la réponse
• Conclusion pratique

Quatre entrées qui déplacent un tarif

Une recherche de vol transporte plus qu’une origine, une destination et une date. Elle transporte une devise, une préférence de langue, un marché pour lequel l’itinéraire est coté et une classe d’appareil qui peut sélectionner un autre ensemble d’offres. Ces quatre ne sont pas interchangeables, et une série de suivi qui les fait varier mesure sa propre configuration autant que les tarifs.

Entrée	Où elle se règle	Ce qu’elle peut changer
Devise	Paramètre de requête ou réglage de compte	Le montant coté et son arrondi
Paramètres régionaux	Paramètres régionaux et langues du profil	Langue de la page, format, parfois l’offre
Point de vente	Paramètre du site, région de sortie et compte	Le marché dont les règles et l’inventaire s’appliquent
Appareil	Fenêtre d’affichage et valeurs d’appareil du profil	Mise en page et parfois une offre mobile seule

Le type Offer de schema.org donne ici une forme utile au vocabulaire. Il définit price et recommande de l’accompagner de priceCurrency avec un code ISO 4217 plutôt qu’un symbole ambigu, et il déconseille l’usage de séparateurs dans la valeur numérique. Cette consigne concerne la publication d’une offre et s’applique directement au problème de capture : un tarif consigné comme $412 n’est pas un fait, alors que 412 USD est une observation comparable.

Les deuxième et troisième entrées sont celles que l’on confond. Des paramètres régionaux sont ce que le navigateur déclare. Un point de vente est le marché pour lequel le site fixe le prix, et il est souvent dérivé de la combinaison d’un paramètre du site, de la région apparente de la requête et du réglage du compte. Faire déclarer l’allemand au navigateur ne transforme pas à soi seul le tarif en tarif allemand, et sortir depuis une adresse allemande ne fixe pas à soi seul la devise.

La devise mérite son propre paragraphe car c’est l’entrée la plus souvent laissée implicite. Un site peut accepter un paramètre de devise explicite, la dériver du point de vente ou la lire dans une préférence de compte, et ces trois chemins peuvent diverger. Quand ils divergent, la page affiche souvent une devise et le paiement une autre, ou la même devise avec un autre taux appliqué. Consignez la devise affichée par la page, non celle demandée par la requête, et consignez le point de vente à côté, car c’est ce couple qui rend le montant reproductible.

L’arrondi est une source de bruit plus discrète mais persistante. Un tarif converti d’une devise à une autre est arrondi selon une précision propre à la devise, et certaines arrondissent à l’unité entière tandis que d’autres gardent deux décimales. Deux captures du même tarif dans la même devise devraient donc coïncider exactement ; si elles diffèrent d’une fraction d’unité, l’écart vient généralement d’une conversion et non d’un changement tarifaire, et l’enregistrement doit le dire au lieu de traiter la fraction comme un mouvement.

Taxes et frais relèvent de la même famille de problèmes. Un montant affiché peut les inclure, les exclure ou n’en inclure qu’un sous-ensemble dépendant du point de vente, et un changement de l’ensemble inclus ressemble exactement à un changement de prix. Consignez ce que le montant affiché inclut lorsque la page l’indique, et gardez ce champ auprès du montant. Une série qui passe d’un affichage taxes incluses à un affichage taxes exclues montrera un saut sans rapport avec le tarif.

Lesquelles un profil retient réellement

La documentation BotBrowser sur fuseau horaire, paramètres régionaux et langues décrit une dérivation automatique depuis l’IP de sortie du proxy lorsqu’un proxy est configuré, ainsi que des remplacements manuels de fuseau horaire, de paramètres régionaux et de langues, ces remplacements étant soumis à une licence ENT Tier1. La documentation GeoIP décrit la traduction de l’adresse de sortie en valeurs géographiques et énonce clairement la limite de précision : la correspondance au niveau du pays est généralement solide, celle au niveau de la ville peut désigner une ville ou une région voisine.

Cela couvre la moitié « paramètres régionaux » du tableau et une partie du point de vente. Cela ne couvre pas la devise, et ne couvre pas complètement le point de vente non plus, car un site peut accepter un paramètre de devise indépendamment de la langue qu’il sert, un comportement du site et non une entrée navigateur documentée. Un dispositif de suivi qui suppose que le profil gère tout retiendra deux des quatre entrées et croira en retenir quatre.

Entrée	Retenue par le profil	Nécessite une vérification explicite
Devise	Non	Le paramètre de requête ou le réglage de compte
Paramètres régionaux	Oui, si configurés	La liste déclarée que la page rapporte réellement
Point de vente	En partie	L’indication du site sur le marché
Appareil	Oui, si configuré	La fenêtre d’affichage et les valeurs rapportées

La conséquence pratique est que la vérification doit être par capture et non par configuration. Une exécution correctement configurée au départ dérivera dès qu’un paramètre de requête est modifié, qu’un remplacement est ajouté ou qu’un proxy est changé pour une région. Consigner les quatre entrées au moment de la cotation est le seul moyen de savoir lesquelles s’appliquaient.

La classe d’appareil est l’entrée qui se cache le mieux. Une fenêtre d’affichage bureau et une fenêtre mobile peuvent renvoyer des ensembles d’offres différents, et certaines compagnies exposent un tarif réservé au mobile qui n’existe tout simplement pas sur le chemin bureau. Ce n’est pas un changement de prix entre deux observations de la même offre, c’est une autre offre. Consignez la fenêtre d’affichage à côté de la classe d’appareil pour qu’un lecteur ultérieur puisse voir si les deux captures ont utilisé la même, et traitez un changement d’ensemble d’offres comme un effet d’appareil plutôt que comme un mouvement tarifaire.

Il existe aussi une dimension temporelle à l’intérieur de l’environnement lui-même. Une capture prise pendant une période de promotion et une autre prise une heure plus tard peuvent différer parce que la promotion a pris fin : c’est un changement côté source que les quatre entrées signalent correctement comme inchangées. C’est le bon résultat : l’enregistrement fait son travail en écartant la capture comme explication. L’erreur à éviter est l’inverse, accuser la source d’un écart qu’un changement de devise explique.

Une dernière habitude mérite d’être citée pour son faible coût. Capturez les quatre entrées avant le chargement de la page tarifaire plutôt qu’après, et conservez les valeurs d’avant chargement. Une page peut changer des paramètres régionaux ou une devise pendant sa propre initialisation côté client, si bien qu’une valeur lue après la cotation peut décrire l’état final plutôt que celui porté par la requête. Consigner les deux, lorsqu’ils diffèrent, transforme un écart déroutant en transition documentée.

Consigner les quatre entrées par capture

Un enregistrement de capture pour le suivi tarifaire est petit. Il lui faut l’itinéraire, le montant coté avec sa devise, les quatre entrées et l’heure d’observation. Le reste est un détail de soutien.

Champ	Contenu	Pourquoi il figure dans l’enregistrement
itinerary_key	Trajet, dates et classe demandés	Définit ce qui est comparé
amount	Valeur numérique avec point décimal	Comparable seulement avec une devise
currency	Code ISO 4217	Empêche qu’un symbole soit lu comme un montant
accept_language	Liste de langues déclarée à la capture	Montre quels paramètres régionaux s’appliquaient
point_of_sale	Marché indiqué par le site	Sépare le marché de la langue
device_class	Bureau ou mobile, avec fenêtre d’affichage	Sépare la mise en page du tarif
observed_at	Heure de capture en UTC	Ordonne les observations et révèle les changements de calendrier
alignment	aligned ou l’entrée qui a différé	Maintient hors série une ligne incomparable

Deux entrées de ce tableau sont faciles à mal consigner. amount doit être un nombre à point décimal et non une chaîne formatée, car une chaîne porte la convention de séparateurs des paramètres régionaux et devient ambiguë dès que la série couvre deux paramètres régionaux. point_of_sale doit être ce que le site a indiqué, non ce que l’opérateur voulait : une intention que le site n’a pas honorée est exactement le cas qui mérite d’être détecté.

Le constructeur d’enregistrements ci-dessous compare deux captures du même itinéraire et indique quelles entrées ont tenu. Le cas est construit.

// Constructed fixture: two captures of one itinerary, one input changed.
const captureA = {
  itineraryKey: 'YYZ-LHR 2026-12-10 Y',
  amount: 812.4,
  currency: 'CAD',
  acceptLanguage: 'en-CA,en',
  pointOfSale: 'CA',
  deviceClass: 'desktop',
  observedAt: '2026-11-10T09:00:00Z',
};
const captureB = {
  itineraryKey: 'YYZ-LHR 2026-12-10 Y',
  amount: 512.1,
  currency: 'EUR',
  acceptLanguage: 'en-CA,en',
  pointOfSale: 'CA',
  deviceClass: 'desktop',
  observedAt: '2026-11-10T09:00:30Z',
};

const FIELDS = ['currency', 'acceptLanguage', 'pointOfSale', 'deviceClass'];
const changed = FIELDS.filter(f => captureA[f] !== captureB[f]);
const alignment = changed.length === 0 ? 'aligned' : `input_changed:${changed.join(',')}`;

const lines = [
  `itinerary=${captureA.itineraryKey}`,
  `a=${captureA.amount} ${captureA.currency} b=${captureB.amount} ${captureB.currency}`,
  `currency=${captureA.currency}->${captureB.currency} locale=${captureA.acceptLanguage}`,
  `pos=${captureA.pointOfSale} device=${captureA.deviceClass}`,
  `changed=${changed.join(',') || 'none'} alignment=${alignment}`,
  `observed_at=${captureA.observedAt}->${captureB.observedAt}`,
];
console.log(lines.join('\n'));

La sortie construite ci-dessous est l’objectif de l’exercice. Le montant a chuté d’environ 37 pour cent, et la classification indique que cette baisse n’est pas du tout un mouvement tarifaire.

itinerary=YYZ-LHR 2026-12-10 Y
a=812.4 CAD b=512.1 EUR
currency=CAD->EUR locale=en-CA,en
pos=CA device=desktop
changed=currency alignment=input_changed:currency
observed_at=2026-11-10T09:00:00Z->2026-11-10T09:00:30Z

Lire un écart selon l’entrée qui a changé

L’ampleur d’un écart ne dit rien de sa cause. La question utile est quelles entrées ont été maintenues, car cela détermine ce que le couple de captures peut soutenir.

Entrées maintenues	Observation	Ce que l’écart soutient
Les quatre identiques	Le montant diffère	Un changement de prix comparable dans cet environnement
Devise changée, reste fixe	Le montant diffère	Une conversion ou une nouvelle tarification, pas un mouvement
Point de vente changé	Le montant diffère	Deux marchés observés ; aucun n’est la base de l’autre
Classe d’appareil changée	Le montant ou l’offre changent	Une offre dépendante de l’appareil, pas un tarif

La première ligne est la seule qui soutienne une série tarifaire. La deuxième est l’erreur la plus fréquente en pratique, car un changement de devise modifie le montant par un facteur important et le graphique obtenu ressemble à un mouvement spectaculaire. La troisième ligne est une comparaison de marchés qui doit être construite comme deux séries et non une. La quatrième est celle où une offre mobile seule peut se faire passer pour un changement de prix.

Deux mises en garde supplémentaires relèvent de la lecture et non de l’enregistrement. D’abord, une cotation n’est pas un prix réservable : taxes, frais et disponibilité peuvent changer entre la cotation et la page de paiement. Ensuite, une capture répétée dans un environnement inchangé peut malgré tout différer parce que l’inventaire ou les règles tarifaires de la compagnie ont changé, ce qui est une observation réelle et doit être étiquetée comme changement côté source et non comme erreur de capture.

L’architecture de suivi des prix couvre la planification et la détection de changement d’une série générale. Ce que le voyage ajoute, c’est que les quatre entrées sont plus indépendantes les unes des autres qu’en commerce de détail, où une seule page produit implique généralement une devise et des paramètres régionaux. Un dossier de cohérence profil-route est le complément approprié pour la moitié « sortie » du point de vente. Un calendrier de disponibilité a besoin d’une clé par date plutôt que par produit, et le modèle de disponibilité explique comment garder ce calendrier comparable entre captures.

Quand un flux tarifaire sous licence est la réponse

La plupart des compagnies et des grandes agences proposent une voie sous licence : un flux de distribution tarifaire, une API d’agence ou un export de données convenu. Ces voies donnent les mêmes itinéraires avec un schéma défini, une cadence de mise à jour déclarée et une licence qui précise l’usage autorisé des données. Quand elle existe, une exécution de navigateur est généralement le mauvais instrument, car elle produit une série moins stable avec plus d’exposition juridique pour une source qui offrait déjà un chemin pris en charge.

Là où aucune voie n’existe, la question honnête est ce qui autorise l’observation. Une session de navigateur qui fonctionne n’est pas cette réponse. Les conditions applicables de la compagnie ou de l’agence décident, et elles restreignent souvent l’accès automatisé, la revente de données tarifaires et l’affichage de prix mis en cache. Consignez la base de l’exécution auprès des captures pour que le lecteur suivant hérite de la réponse et non de la supposition.

Le type FlightReservation de schema.org rappelle la même frontière depuis l’autre côté. Il définit un vocabulaire pour une réservation, avec bookingTime, des champs passager et reservationFor pointant vers le vol. Il décrit comment une réservation peut être représentée ; il ne dit rien de la possibilité de suivre un tarif, ni du prix qui sera coté au paiement.

Le vocabulaire reste utile pour nommer ce qu’une capture garde séparé. Une réservation n’est pas une offre, et une offre n’est pas une règle tarifaire. Quand un enregistrement mélange les trois, une comparaison ultérieure ne peut pas dire si la compagnie a changé un prix, l’itinéraire ou les conditions associées. Gardez la clé d’itinéraire décrivant ce qui a été demandé, le montant et la devise décrivant ce qui a été coté, et les quatre entrées d’environnement décrivant comment la cotation a été obtenue.

Questions fréquentes

Un changement de devise est-il un changement de prix ?

Non. Il change l’unité du montant, et généralement l’arrondi. Une série qui change de devise en cours de route mesure ce changement ; gardez donc une devise par série ou convertissez avec un taux déclaré et consignez la conversion.

Un profil de navigateur peut-il retenir le point de vente ?

En partie seulement. Le profil contrôle les paramètres régionaux, les langues et, via le proxy, la région apparente. Le point de vente d’un site est souvent un paramètre ou un réglage de compte distinct ; vérifiez donc ce que le site a indiqué plutôt que ce que l’opérateur voulait.

Le même itinéraire renvoie-t-il toujours le même prix ?

Non. L’inventaire et les règles tarifaires changent, et la cotation n’est pas le total au paiement. Une capture répétée dans un environnement inchangé peut malgré tout différer, et cet écart appartient à la source.

BotBrowser fournit-il des tarifs ou réserve-t-il des vols ?

Non. Il fournit des entrées de navigateur documentées pour qu’une capture déclare son environnement. Il ne fournit pas de données tarifaires, ne réserve pas et ne garantit pas un prix coté.

Sources

• schema.org FlightReservation
• schema.org Offer
• MDN Accept-Language
• Fuseau horaire, paramètres régionaux et langues dans BotBrowser
• Base GeoIP de BotBrowser

Conclusion pratique

Décidez quelle devise, quels paramètres régionaux, quel point de vente et quel appareil la série représente avant la première capture. Vérifiez les quatre à chaque capture, car un profil en retient deux entièrement et une seulement en partie, et consignez-les auprès du montant coté et de l’heure d’observation. Classez chaque écart selon l’entrée qui a changé et traitez un changement de devise comme un changement d’environnement plutôt qu’un mouvement tarifaire. Là où un flux tarifaire sous licence ou une API d’agence existe, utilisez-le et gardez l’exécution de navigateur hors de la conception.