Surveillance des prix e-commerce : la couche navigateur

Un navigateur de surveillance des prix e-commerce est une étape d’une chaîne de traitement, pas la chaîne elle-même. Un prix enregistré peut différer de l’exécution précédente parce que la page s’est rendue dans une autre devise, parce que la lecture a eu lieu avant que l’élément de prix ne se stabilise, parce que la route est sortie par une autre région, ou parce que le marchand a réellement changé le nombre. Seul le quatrième cas est un fait sur les données ; les trois autres sont des défauts de mesure que la couche navigateur empêche ou introduit silencieusement, y compris lorsque la route sort par une région que l’opérateur ne visait pas. BotBrowser fournit un environnement Chromium configurable qui démarre à partir d’une configuration fournie par l’opérateur et renvoie la page rendue, ce qui permet de figer l’étape navigateur pendant que les autres étapes sont mesurées. Il ne peut pas planifier les tâches, ne conserve pas l’historique, ne calcule pas les écarts, ne décide pas si un marchand autorise la collecte et ne garantit pas le prix qu’une page affiche. La procédure suppose un banc d’essai possédé ou une cible explicitement autorisée, et ne donne aucune méthode pour contourner les protections d’un marchand.

TL;DR

• Écrivez la chaîne comme quatre étapes ayant chacune un responsable : planification, rendu navigateur, extraction et détection de changement. Un écart de prix n’est attribuable que si les frontières d’étape sont enregistrées pour chaque observation.
• Fixez trois entrées visibles par le navigateur avant toute comparaison, et effacez ou figez aussi l’état des cookies et des préférences dès la première observation, car une préférence stockée peut primer sur les trois : Accept-Language avec navigator.languages, la devise utilisée pour le formatage et la région de sortie. La modification d’une seule produit un nombre différent sur le même produit.
• Remplacez « attendre le prix » par une condition de disponibilité nommée, par exemple un nœud de prix non vide dont le texte s’analyse comme un nombre et dont le bloc d’offre environnant est complet. Une pause fixe n’est pas une condition de disponibilité.
• Stockez la monnaie en unités mineures entières avec le code ISO 4217 à côté. 19.99 en flottant perd la frontière du centime dont dépend un écart, et ¥1,980 n’est pas la même quantité que $19.80.
• Classez chaque observation parmi : prix observé, prix absent, requête refusée, page non stabilisée. Fusionner ces quatre cas en « pas de prix » est le défaut qui fait paraître exacte une chaîne de surveillance qui ne l’est pas.

Sommaire

• Décomposer la charge en quatre étapes
• Fixer les variables côté navigateur
• Définir le moment de rendu et les lectures périmées
• Séparer l’erreur du navigateur de l’erreur des données
• Conclusion pratique

Décomposer la charge en quatre étapes

Une tâche de surveillance des prix répond à une question par produit et par exécution : quel nombre cette page a-t-elle affiché à cet instant, pour cette devise, depuis cette région ? Tout le reste de la chaîne existe pour rendre cette réponse comparable à la précédente. Découper le travail en étapes est ce qui rend un écart explicable, parce que chaque étape peut échouer d’une manière que les autres ne peuvent pas produire.

Étape	Responsable de	Peut produire cette défaillance	Ne peut pas corriger
Planification	Quel produit, à quelle fréquence, quel créneau, budget de reprise	Créneau manqué, exécutions qui se chevauchent, observations en double	Une lecture fausse ou périmée
Rendu navigateur	Langue, devise, région de sortie, condition de disponibilité	Lecture dans la mauvaise devise, prix d’une autre région, lecture périmée	Un prix qui a changé
Extraction	Quel nœud, quel analyseur, quel repli	Erreur d’analyse, erreur d’unité, mauvais champ	Une page qui ne s’est jamais stabilisée
Détection de changement	Référence, tolérance, règle d’alerte	Fausse alerte, alerte manquée, dérive	Une observation erronée

Le tableau est un instrument de diagnostic, pas un organigramme. Quand un écart apparaît, la première question est de savoir quelle étape a produit les deux observations, car un écart calculé à partir de deux configurations de navigateur différentes n’est pas un changement de prix. Une chaîne de surveillance qui annonce « le prix a changé » sans enregistrer la devise, la région et la condition de disponibilité des deux observations a produit une affirmation invérifiable.

Pourquoi la frontière d’étape doit être enregistrée par observation

Stocker la configuration une fois par tâche ne suffit pas. Une tâche qui change sa devise au milieu d’un lot, ou qui bascule sur une route d’une autre région après une erreur de proxy, produit des observations non comparables entre elles alors même que l’identifiant de tâche est identique. Enregistrez la configuration effective à côté de chaque observation, pas à côté de l’exécution.

Les champs utiles par observation sont peu nombreux et stables : l’identifiant de version du navigateur, l’identifiant de profil, la valeur effective de Accept-Language, le code de devise utilisé pour l’extraction, la région de sortie telle que la route la rapporte, le nom de la condition de disponibilité, l’horodatage de la lecture et le statut HTTP de la réponse du document. Avec ces huit champs, deux observations peuvent être comparées ou explicitement déclarées incomparables. Sans eux, un écart est une opinion.

Ce que l’étape navigateur peut et ne peut pas rapporter

Le navigateur peut rapporter ce qu’il a rendu : le contenu textuel d’un nœud, les attributs qui y figurent, le statut HTTP du document, les en-têtes de réponse envoyés par le serveur et le moment où la condition de disponibilité choisie est devenue vraie. Il peut aussi rapporter le minutage des requêtes pour le document et ses sous-ressources.

Le navigateur ne peut pas rapporter pourquoi un nombre vaut ce qu’il vaut. Il ne peut pas dire si 1,299 signifie 1 299 unités de la devise affichée ou un prix régional arrondi, si le marchand a appliqué une remise membre à un autre compte, ni si une promotion s’est terminée entre deux exécutions. Il ne peut pas non plus indiquer si une page qu’il n’a jamais reçue aurait affiché un autre prix. Ce sont des questions d’extraction et de métier, et les attribuer à l’étape navigateur produit la mauvaise correction : une équipe qui traite chaque écart de prix comme un problème de navigateur peut finir par changer de profil alors que la cause réelle était une devise par défaut.

Un produit, une unité de comparaison

Avant tout code de chaîne, décidez ce qui compte comme le même produit d’une exécution à l’autre. Les identifiants produit d’un marchand ne sont pas stables d’une région à l’autre : le même article peut porter des identifiants différents par vitrine, et un catalogue régional peut lister une variante absente du catalogue global. Utilisez une clé stable côté opérateur comme unité de comparaison, et stockez l’identifiant du marchand à côté, comme attribut.

Si la clé côté opérateur est construite à partir de l’URL, normalisez-la d’abord : retirez les paramètres de suivi, normalisez la casse dans le chemin là où la vitrine le fait, et supprimez les fragments de session. Deux URL qui ne diffèrent que par un paramètre de campagne désignent le même produit, et les traiter comme deux produits double le nombre d’observations sans apporter d’information.

Fixer les variables côté navigateur

Quatre surfaces sur le trajet de la requête changent le nombre qu’une page affiche sans aucun changement chez le marchand. Trois se fixent dans le navigateur : la langue négociée par la page, la devise sélectionnée par la vitrine, et l’état de préférence ou de cookie qui persiste entre deux requêtes. La quatrième est la région de sortie de la route, qui appartient à la couche de routage et ne s’observe que depuis la route, pas depuis la page. Chacune est indépendante, et chacune a un mode de défaillance différent.

La négociation de langue et sa chaîne de résolution

Une vitrine choisit généralement une langue à partir de Accept-Language sur la requête du document, d’un segment de chemin ou de sous-domaine, d’un cookie ou d’une préférence stockée, ou de la région de sortie, dans un ordre qu’elle décide. À l’intérieur de la page, navigator.language et navigator.languages décrivent ce que le navigateur rapporte, et le formatage Intl se résout sur une étiquette de langue.

Ce sont quatre surfaces distinctes et elles peuvent diverger. Une requête qui envoie Accept-Language: de-DE alors que navigator.languages rapporte en-US peut produire une page allemande dont le formatage côté client rend encore un nombre au format anglais. Le résultat observable est une page qui semble localisée mais formate la monnaie dans l’autre convention, exactement l’état mixte qui produit un écart de prix fantôme.

Surface	Définie par	Observable depuis	Défaut typique en cas de dérive
En-tête de requête Accept-Language	Les options de contexte de la bibliothèque d’automatisation	Les en-têtes de requête capturés	Le serveur choisit une autre langue de vitrine
navigator.language / navigator.languages	Le profil du navigateur	page.evaluate sur la page	La sortie Intl côté client change
Chemin ou sous-domaine d’URL	L’adresse demandée	L’URL finale	Les requêtes atteignent une tout autre vitrine
Préférence stockée ou cookie	Une navigation antérieure ou un parcours de consentement	Cookies du document, stockage	La première requête et les suivantes divergent

La règle pratique est de fixer les quatre surfaces sur un même jeu de valeurs et de vérifier leur accord sur la première observation d’une exécution. Playwright expose des options de contexte pour la langue et le fuseau horaire, ce qui permet d’aligner l’en-tête et les valeurs de navigator dans le même lancement, et page.evaluate peut relire ce que la page voit réellement avant toute extraction.

Choix de devise et formatage

La devise est une source fréquente d’erreurs silencieuses dans une chaîne de surveillance, parce qu’un élément de prix contient généralement une chaîne formatée plutôt qu’un nombre lisible par machine. $1,299, 1.299 €, ¥1,299 et 1 299,00 € peuvent tous représenter des quantités différentes ou la même quantité rendue selon des conventions différentes. Séparer le symbole des chiffres ne suffit pas : le même glyphe sert à plusieurs devises.

Utilisez les codes ISO 4217, jamais les symboles, dans les enregistrements stockés. USD, EUR, GBP, JPY et CNY sont sans ambiguïté ; $ ne l’est pas, et ¥ sert à la fois au JPY et au CNY. Quand la page expose une devise lisible par machine, préférez-la : Offer de schema.org porte priceCurrency et price, et un bloc JSON-LD est plus fiable à analyser qu’une étiquette rendue.

Les unités mineures comptent pour la même raison. La plupart des devises utilisent deux décimales, mais le JPY et le KRW en utilisent zéro, et des devises comme le KWD et le BHD en utilisent trois. Une chaîne qui multiplie chaque prix analysé par 100 pour obtenir une valeur entière en centimes décalera une devise sans décimale de deux ordres de grandeur. Stockez le code ISO 4217, l’exposant d’unité mineure de ce code et le montant entier, puis formatez l’affichage à partir de ces trois champs.

Enregistrez aussi le comportement d’arrondi. Intl.NumberFormat avec un style monétaire arrondit aux décimales par défaut de la devise sauf indication contraire, donc une page qui affiche 1.995 formaté en 2.00 a déjà perdu de l’information avant que l’extraction ne la voie. Si la comparaison a besoin de la troisième décimale, l’extraction doit lire la valeur non formatée ou accepter que la chaîne compare des prix arrondis.

La région vient de la route, pas du navigateur

La région est l’entrée que les équipes supposent le plus souvent contrôler alors que ce n’est pas le cas. Le navigateur peut rapporter un fuseau horaire et un ensemble d’étiquettes de langue, et un profil peut déclarer une géolocalisation, mais la vitrine décide de son catalogue régional à partir de ce qu’elle peut observer de la requête, ce que domine l’adresse de sortie. Un profil qui revendique une région alors que la route sort d’une autre produit une page dont le catalogue régional et le formatage côté client divergent.

Alignez-les délibérément. Si la charge a besoin de la vitrine allemande, la route doit sortir par une adresse allemande, Accept-Language doit porter l’allemand, la langue du contexte doit être une étiquette allemande et le fuseau horaire doit être celui que verrait un visiteur allemand. Cet alignement est une propriété de configuration de l’exécution, et il est vérifiable : l’URL finale, l’en-tête Content-Language du document lorsqu’il est présent et la devise rendue indiquent ensemble quelle vitrine a répondu.

Vérification	Ce qu’elle prouve	Où la lire
URL finale après redirections	Quel chemin de vitrine a répondu	page.url()
En-tête de réponse Content-Language	Quelle langue le serveur a choisie	La réponse de document capturée
Code de devise rendu	De quel catalogue la page provient	Offer.priceCurrency ou le nœud de prix
Intl.DateTimeFormat().resolvedOptions().timeZone	Quel fuseau horaire la page voit	page.evaluate
Région de sortie de la route	De quelle région la requête est partie	Le rapport de la route, pas la page

La dernière ligne est celle qui ne peut pas être lue depuis la page, ce qui explique qu’elle doive être enregistrée par la couche qui possède la route. Une page peut se rendre parfaitement alors que la route sort par un endroit que l’opérateur ne visait pas, et rien dans le DOM ne le révèle. Le relevé dont un prix a besoin à côté de lui, et le découpage en un contexte par détaillant et par région, sont traités dans protection des empreintes pour la surveillance e-commerce ; le figement de la région, de la langue et de la route pour une fenêtre de comparaison est traité dans profils de navigateur pour la surveillance SEO.

Un enregistrement de configuration figée

Placez les valeurs figées dans un seul enregistrement que l’étape d’extraction et l’étape de détection de changement peuvent toutes deux lire. Une forme exploitable est un petit objet contenant les étiquettes de langue, le code de devise et l’exposant d’unité mineure, la région, le fuseau horaire, le nom de la condition de disponibilité, ainsi que les identifiants du navigateur et du profil. L’enregistrement voyage avec l’observation.

Deux contraintes s’appliquent. Premièrement, l’enregistrement décrit la configuration effective, pas celle demandée ; une requête pour de-DE que le site a redirigée vers une vitrine anglaise doit enregistrer ce qui a réellement répondu. Deuxièmement, un changement de configuration est un événement de chaîne, pas une modification de routine : si le réglage de devise change, les observations de part et d’autre ne sont pas comparables, et l’étape de détection de changement doit le savoir plutôt que de recevoir un écart.

Définir le moment de rendu et les lectures périmées

Les nœuds de prix sont fréquemment présents avant d’être corrects. Un texte de remplacement rendu par le serveur, un élément squelette, une étape d’hydratation côté client et une bannière promotionnelle qui réécrit le nombre affiché peuvent tous apparaître en séquence dans le même chargement de page. Lire au mauvais moment produit un nombre qui était réellement sur la page et n’a jamais été le prix.

Une condition de disponibilité au lieu d’une pause

Écrivez la condition de disponibilité comme un prédicat sur la page, pas comme un temps écoulé. Un prédicat utile comporte trois parties : le nœud de prix existe, son texte s’analyse comme un nombre selon les règles de devise déclarées, et un témoin structurel confirme que le bloc d’offre environnant est complet, par exemple une valeur priceCurrency, un marqueur de stock ou de disponibilité, ou un contrôle d’ajout au panier activé.

La troisième partie est ce qui sépare une lecture réelle d’une lecture chanceuse. Une page peut exposer un nœud de prix contenant une chaîne numérique bien avant que le bloc d’offre ne soit assemblé, et un prédicat qui ne vérifie que le nœud passera sur un rendu partiel. Attendre l’ensemble des témoins coûte un peu de latence et supprime toute une classe de lectures périmées.

Playwright fournit directement les primitives : page.waitForFunction peut évaluer le prédicat dans la page, page.waitForSelector peut conditionner sur la présence du nœud, et page.waitForResponse peut conditionner sur une réponse d’API précise quand le prix arrive par le réseau plutôt que dans le document. Choisir entre elles est une décision sur l’origine du prix, et ce choix appartient à l’enregistrement d’exécution parce qu’il change ce que « disponible » signifie.

Source du prix	Primitive de disponibilité	Ce qu’elle prouve	Risque résiduel
Document rendu par le serveur	waitForSelector sur le nœud de prix plus le témoin	Le document contenait l’offre	Un script ultérieur réécrit le nombre
Nœud hydraté côté client	waitForFunction sur le prédicat complet	Le client a fini d’assembler l’offre	Un script promotionnel ultérieur le modifie
Prix livré par un appel d’API	waitForResponse correspondant au point d’entrée	La réponse de prix est arrivée	Le DOM n’a pas encore été mis à jour
Prix derrière une interaction	Une interaction scriptée puis le prédicat	L’interaction s’est terminée	L’interaction n’était pas la bonne

La quatrième ligne est celle où une chaîne de surveillance peut franchir silencieusement sa propre frontière : une interaction qui révèle un prix membre ou un prix régional est un état authentifié ou personnalisé, et une charge autorisée uniquement pour des pages publiques doit classer cette observation hors périmètre plutôt que de l’extraire.

Lectures périmées, prix manquants et requêtes refusées

Ces trois issues se ressemblent pour une chaîne qui ne stocke qu’un nombre ou une valeur nulle, et elles exigent des réponses différentes. Une lecture périmée signifie que la condition de disponibilité était fausse et que l’observation doit être écartée, pas stockée. Un prix manquant signifie que la page s’est entièrement rendue et que le bloc d’offre ne contenait pas de prix, ce qui est un constat réel sur le produit. Une requête refusée signifie que le navigateur n’a jamais reçu la page, ce qui est une question d’accès et pas du tout une question de données.

Classez explicitement. Stockez un code d’issue avec chaque observation : observed, absent, refused ou unsettled. En aval, seules les observations observed alimentent un écart de prix, absent alimente un signal de changement de catalogue, refused alimente un journal d’accès et unsettled alimente un compteur de défauts de condition de disponibilité. Une chaîne qui traite les quatre comme « pas de prix » signalera un catalogue stable alors qu’elle échoue systématiquement à le lire.

Requêtes conditionnelles et ce que signifie un 304

Quand la charge relit une page déjà vue, le serveur peut répondre 304 Not Modified à une requête conditionnelle portant If-None-Match avec l’ETag précédent, ou If-Modified-Since avec le Last-Modified précédent. Un 304 n’est pas un échec et n’est pas une observation fraîche : il signifie que la représentation que le serveur aurait envoyée est inchangée par rapport à celle que décrit le validateur.

Pour la surveillance des prix, un 304 est à la fois une preuve utile et un piège. Il est utile parce qu’il confirme que le document n’a pas changé depuis l’émission du validateur. C’est un piège parce que le validateur décrit le document, pas le prix : un prix récupéré par un appel d’API séparé et injecté côté client peut changer alors que l’ETag du document reste identique. Si le prix arrive par le réseau, le validateur sur lequel conditionner est celui de cette réponse, pas celui du document.

Vary complique la même question. Une réponse portant Vary: Accept-Language signifie que la représentation mise en cache est indexée sur cet en-tête, donc une exécution qui change son réglage de langue ne relit pas la même entrée de cache. Enregistrer l’en-tête Vary à côté de l’observation évite qu’une analyse ultérieure suppose que deux observations partageaient une clé de cache alors que ce n’était pas le cas.

Horloge, horodatage et ordre

Stockez l’heure d’observation depuis une seule horloge, et stockez à côté le signal temporel du serveur lorsque la réponse en fournit un, par exemple un en-tête Date. Le Date.now() de la page et l’horloge de l’hôte peuvent différer, et une chaîne qui les mélange produit des observations dont l’ordre n’est pas fiable.

L’ordre compte plus que la précision ici. Si deux observations du même produit sont stockées avec des heures qui inversent leur ordre réel, l’étape de détection de changement signalera un changement de prix dans la mauvaise direction et pourra alerter dessus. Enregistrer un numéro de séquence strictement croissant par exécution, en plus de l’heure murale, rend l’ordre récupérable même quand deux horodatages entrent en collision.

Séparer l’erreur du navigateur de l’erreur des données

L’intérêt du découpage en quatre étapes est de transformer « le prix semble faux » en une affirmation précise et vérifiable. Utilisez les frontières d’étape comme première étape de classification, puis les codes d’issue d’observation comme seconde.

Matrice d’attribution des défaillances

Symptôme	Étape la plus probable	Première vérification	À ne pas faire
Tous les produits d’une région affichent une autre devise	Rendu navigateur	Devise effective et région de sortie dans l’enregistrement d’exécution	Changer de profil
Le prix d’un produit bouge puis revient	Détection de changement	Tolérance et règle d’alerte	Réécrire l’extracteur
Les prix sont absents sur une partie des produits	Extraction	Si le bloc d’offre contient un prix du tout	Réessayer avec un nouveau profil
Une exécution présente des trous à intervalles réguliers	Planification	Chevauchement de créneaux et budget de reprise	Augmenter la concurrence
Les prix sont systématiquement en retard d’un cran	Rendu navigateur	Condition de disponibilité et compteur de lectures périmées	Accuser le marchand
Un prix est décalé d’un facteur 100	Extraction	Exposant d’unité mineure du code de devise	Ajuster la règle d’alerte

La colonne « à ne pas faire » est le point opérationnel. Chacun de ces symptômes a une correction tentante qui vise une autre étape, et l’appliquer transforme un défaut diagnosticable en décalage permanent et inexpliqué.

Un enregistrement d’exécution qui permet la classification

L’enregistrement doit être assez petit pour être réellement écrit et assez complet pour que la matrice ci-dessus s’applique sans rien réexécuter. Une forme exploitable par observation porte la clé produit, l’heure d’observation et le numéro de séquence, le code d’issue, le texte de prix brut, le montant entier analysé, le code ISO 4217 et l’exposant d’unité mineure, la langue et la région effectives, le nom de la condition de disponibilité, le statut HTTP du document et l’URL finale.

Deux champs dérivés rendent la matrice utilisable à l’échelle : un compteur de lectures périmées par exécution et un compteur de défaillances par étape. Le premier est le nombre d’observations dont le prédicat a réussi mais dont l’ensemble de témoins était incomplet, qui devrait être nul après réglage. Le second regroupe les codes d’issue par étape, de sorte qu’un compteur refused qui monte est visiblement un problème d’accès et qu’un compteur unsettled qui monte est visiblement un problème de disponibilité.

Liste de vérification avant exécution

• L’unité de comparaison est une clé produit côté opérateur, avec l’identifiant du marchand stocké comme attribut.
• Les surfaces de langue s’accordent : en-tête de requête, navigator.languages, chemin d’URL et toute préférence stockée.
• La devise est stockée comme code ISO 4217 avec son exposant d’unité mineure, jamais comme symbole.
• La région de sortie est enregistrée par la couche de route et correspond à la vitrine visée.
• La condition de disponibilité est un prédicat nommé avec un ensemble de témoins, pas une pause fixe.
• Chaque observation porte un code d’issue parmi observed, absent, refused, unsettled.
• Les validateurs de requête conditionnelle sont attachés à la réponse qui porte réellement le prix.
• La tolérance de détection de changement est déclarée avant la première alerte, pas après la première fausse.
• Un changement de configuration est enregistré comme un événement qui découpe les fenêtres d’observation comparables.

FAQ

Le navigateur décide-t-il du prix qu’une page affiche ?

Non. La vitrine décide du prix à partir de son propre catalogue, de ses promotions, de l’état du compte et de ses règles régionales. La couche navigateur contrôle ce que la vitrine peut observer de la requête, et cette observation peut influencer le catalogue ou la devise servis, mais le nombre lui-même vient des systèmes du marchand. Traiter le navigateur comme la cause d’un écart de prix conduit à une agitation de configuration qui ne traite jamais la variable réelle.

Une attente plus longue est-elle une correction fiable des lectures périmées ?

Elle réduit le symptôme sans le corriger. Une pause fixe plus longue abaisse la probabilité de lire un rendu partiel, abaisse aussi le débit et échoue encore chaque fois que la page est plus lente que le délai choisi. Un prédicat de disponibilité qui nomme le nœud de prix et son ensemble de témoins échoue de manière visible et spécifique, ce dont une chaîne de surveillance a besoin : une observation qui dit « non stabilisée » est utilisable, tandis qu’une observation qui a silencieusement capturé un texte de remplacement ne l’est pas.

Les prix doivent-ils être stockés en flottants ou en entiers ?

En entiers en unités mineures, avec le code ISO 4217 et son exposant stockés à côté du montant. La virgule flottante binaire ne peut pas représenter exactement la plupart des fractions décimales, donc un 19.99 stocké n’est pas exactement dix-neuf et quatre-vingt-dix-neuf centièmes, et l’arithmétique répétée sur de telles valeurs accumule l’erreur. Les unités mineures entières rendent l’égalité et la différence exactes, et l’exposant empêche une devise sans décimale d’être mise à l’échelle comme si elle avait des centimes.

Conclusion pratique

Commencez par la frontière d’étape plutôt que par la configuration du navigateur. Écrivez les quatre étapes, nommez le responsable de chacune et enregistrez la configuration effective côté navigateur à côté de chaque observation plutôt qu’à côté de chaque tâche. Remplacez ensuite la pause par un prédicat de disponibilité qui nomme à la fois le nœud de prix et un témoin structurel, et classez chaque observation dans l’un des quatre codes d’issue : observed, absent, refused, unsettled.

L’action suivante est réduite : prenez un produit sur une page autorisée, enregistrez son prix deux fois sous une configuration figée, et confirmez que les deux observations portent le même code de devise, la même région, la même condition de disponibilité et le même code d’issue. Si c’est le cas, la chaîne peut attribuer un écart futur. Sinon, l’écart est déjà là et la couche navigateur est le premier endroit à examiner.

Sources

• Playwright : BrowserType.launch
• Playwright : Réseau
• Playwright : Contextes de navigateur
• RFC 9110 : Sémantique HTTP
• RFC 9111 : Mise en cache HTTP
• Schema.org : Offer
• Codes de devise ISO 4217
• ECMA-402 : Intl.NumberFormat
• BotBrowser : Démarrage avec Playwright
• BotBrowser : Alignement proxy et géolocalisation
• BotBrowser : Fuseau horaire, langue et localisation