Suivi des prix Cyber Monday 2026 : méthode et coûts

Ce que les horaires 2025 changent pour le suivi

Les calendriers publiés par les enseignes en 2025 montrent pourquoi il est utile d'anticiper. Walmart a donné un accès anticipé à ses membres dès 19 heures (heure de la côte Est) le dimanche 30 novembre. Target a organisé un événement en ligne du 30 novembre au 1er décembre. Amazon, lui, a étendu sa période Black Friday jusqu'au 1er décembre : pour certains produits, le tarif « Cyber Monday » n'était donc pas forcément une nouvelle baisse.

Adobe Analytics a aussi observé un pic de dépenses entre 20 et 22 heures (heure de l'Est), avec environ 16 millions de dollars dépensés par minute. Un pic de demande peut augmenter le risque de rupture de stock. Ça ne prouve pas à lui seul que les prix baissent à ce moment-là : ça indique surtout que, si vous ne releviez qu'une fois par jour, vous pourriez rater des changements rapides.

Pour un acheteur français qui suit des sites américains, il faut convertir les horaires avant de programmer les contrôles. À cette période de l'année, l'heure de Paris a généralement six heures d'avance sur New York : 19 heures à New York correspond à 1 heure du matin à Paris le lendemain. Pour les enseignes françaises et européennes, utilisez leur fuseau horaire réel et leurs annonces, plutôt que de « transposer » automatiquement le calendrier américain.

Les limites à intégrer dès le départ

Premier point souvent négligé : les offres réservées aux membres. Un outil qui consulte une page sans session authentifiée peut voir uniquement le prix public, pas une offre Prime, Walmart+ ou une réduction liée à un compte.

Deuxième point : ne confondez pas « prix affiché », « disponibilité » et « conditions de livraison ». Un tarif bas sans stock, ou conditionné à une adhésion, n'a pas le même impact qu'une offre réellement accessible à tous.

À retenir : les horaires 2025 servent de repères, pas de calendrier officiel pour 2026. Les enseignes doivent encore publier leurs dates et leurs accès anticipés. Dès que ces infos tombent, ajustez la fenêtre de suivi.

Choisir la fréquence selon l'usage

Le relevé horaire est utile si vous voulez repérer vite une baisse ou une rupture de stock sur une liste ciblée. Mais il est plus coûteux, et il ne garantit pas que vous verrez un changement exactement au moment où il apparaît : un prix peut varier entre deux relevés, puis revenir à son niveau précédent.

Un relevé toutes les trois heures est souvent un bon compromis si vous faites une veille moins urgente, surtout avec une liste longue. Vous réduisez les exécutions des deux tiers, mais vous acceptez qu'une baisse temporaire très courte puisse passer inaperçue.

Une approche intermédiaire consiste à augmenter la fréquence au moment où les offres démarrent et pendant les heures les plus chargées, puis à espacer la nuit. C'est généralement plus rationnel que de garder la fréquence la plus élevée tout du long. Tenez aussi compte du temps d'exécution : si un relevé dépasse une heure, une planification « horaire » peut se chevaucher et rendre les comparaisons incohérentes.

Exemple de planification

Pour une tâche planifiée dans le fuseau America/New_York, les expressions suivantes couvrent la fenêtre décrite. Elles sont séparées en trois entrées pour gérer le dimanche, le lundi et le début du mardi.

Ces expressions sont adaptées à ce fuseau et à ces dates. Elles ne sont pas « universelles » : selon les planificateurs, une expression valide dans un outil peut ne pas correspondre à votre fuseau ou à votre tâche. Ajoutez ces exécutions à votre contrôle quotidien, sans viser forcément le même instant à chaque fois. Si l'outil propose un mode qui n'écrit que les changements, activez-le pour limiter les écritures inutiles.

Calcul pour une liste de 150 produits

Pour les sites accessibles sans proxy résidentiel ni navigateur distant - par exemple certains sites américains de vente au détail ou des boutiques Shopify - le barème utilisé dans l'exemple est :

Pour 150 produits, une exécution coûte donc entre deux cas : aucun changement, ou changement de tous les produits.

• Offre gratuite : 0,005 $ + 150 × 0,0012 $ = 0,185 $ si rien ne change ; jusqu'à 0,005 $ + 150 × 0,0048 $ = 0,725 $ si tout change.
• Offre Gold : 0,005 $ + 150 × 0,0002 $ = 0,035 $ si rien ne change ; jusqu'à 0,005 $ + 150 × 0,0008 $ = 0,125 $ si tout change.

En multipliant par le nombre d'exécutions sur toute la fenêtre, on obtient :

L'hypothèse de 10 % de changements est un exemple, pas une observation. Elle correspond à 15 produits modifiés à 0,0008 $, 135 produits inchangés à 0,0002 $ et 0,005 $ de démarrage, soit 0,044 $ par exécution Gold. Les montants sont en dollars car le barème d'origine est dans cette devise ; d'éventuels frais de conversion ou taxes ne sont pas inclus.

Les coûts que le tableau ne couvre pas

Certains sites demandent des proxys résidentiels ou un navigateur. Des sites comme Amazon Royaume-Uni ou Wayfair peuvent alors facturer plus cher selon le volume de données ou le rendu. Le coût réel dépend de votre configuration et du comportement du site : vérifiez le tarif applicable à votre cible avant d'enchaîner plusieurs dizaines de contrôles.

Il y a aussi deux limites opérationnelles faciles à sous-estimer. D'abord, une exécution doit finir avant la suivante. Sinon, deux tâches peuvent comparer leurs résultats à la même référence, ou se chevaucher. Sur de petits échantillons, un relevé peut prendre moins d'une minute ; à titre indicatif, le guide tarifaire utilisé estime qu'une tâche Shopify traite environ 30 à 40 produits par minute avec 1 Go de mémoire. Pour une liste de 1 000 produits, comptez environ une demi-heure.

Ensuite, si votre outil le permet, mettez un plafond de dépenses par exécution. Un incident, une boucle de relance, ou un volume inattendu ne devrait pas transformer une veille courte en facture imprévue. Avant de lancer la campagne complète, testez sur quelques produits et vérifiez à la fois la durée et le coût observés.

Comparer deux exécutions par URL produit

Le script Python ci-dessous associe les lignes à partir de l'URL. Il signale un changement de devise au lieu de calculer une différence trompeuse, puis affiche combien d'articles ne sont présents que dans un seul des deux relevés.

import os
import sys
from apify_client import ApifyClient
client = ApifyClient(os.environ['APIFY_TOKEN'])
def prix_par_url(run_id):
"""Associe l'URL au prix, à la devise et à la date de relevé."""
dataset = client.run(run_id).dataset()
return {
ligne['url']: (ligne['price'], ligne['currency'], ligne['scrapedAt'])
for ligne in dataset.iterate_items()
if ligne.get('recordType') == 'product' and ligne.get('price')
}
black_friday = prix_par_url(sys.argv[1])
cyber_monday = prix_par_url(sys.argv[2])
communs = black_friday.keys() & cyber_monday.keys()
for url in sorted(communs):
prix_bf, devise_bf, date_bf = black_friday[url]
prix_cm, devise_cm, date_cm = cyber_monday[url]
if devise_bf != devise_cm:
print('{} : devise différente, {} puis {}, comparaison ignorée'.format(
url, devise_bf, devise_cm))
continue
ecart = prix_cm - prix_bf
moins_cher = ('Cyber Monday' if ecart < 0 else
'Black Friday' if ecart > 0 else 'identique')
print('{:>8.2f} ({})  {:>8.2f} ({})  {:+7.2f} {}  moins cher : {:<12} {}'.format(
prix_bf, date_bf[:10], prix_cm, date_cm[:10], ecart,
devise_bf, moins_cher, url))
print('{} produits présents dans les deux relevés ; {} uniquement dans le premier, '
'{} uniquement dans le second'.format(
len(communs), len(black_friday.keys() - cyber_monday.keys()),
len(cyber_monday.keys() - black_friday.keys())))

Lancement : python comparaison.py <identifiant-releve-black-friday> <identifiant-releve-cyber-monday>. Les identifiants correspondent aux exécutions à comparer. Si les deux listes sont identiques, les compteurs d'articles absents d'un relevé doivent être à zéro. Sinon, vérifiez la watchlist, les variantes de produit et les URLs avant de conclure.

Une différence de prix ne suffit pas toujours. Cette comparaison ne prend pas en compte les frais de livraison, les avantages réservés aux membres, ni les différences de configuration entre les deux relevés. Vérifiez ces points séparément, en particulier pour l'électronique où un nom commercial peut cacher plusieurs capacités ou générations.

Reconstituer les changements heure par heure

Pour savoir à quel moment le tarif a évolué, partez d'un export d'historique qui contient les lignes de changement, par exemple price_history.csv. Le champ scrapedAt est enregistré en UTC : il faut le convertir dans le fuseau utilisé pour lire le calendrier. Le script suivant limite l'analyse à la fenêtre en heure de New York et ignore les lignes « nouvelles » ou « inchangées ».

import csv
import sys
from datetime import datetime
from zoneinfo import ZoneInfo
fuseau = ZoneInfo('America/New_York')
debut = datetime(2026, 11, 29, 18, tzinfo=fuseau)
fin = datetime(2026, 12, 2, 6, tzinfo=fuseau)
with open(sys.argv[1], encoding='utf-8') as fichier:
lignes = sorted(csv.DictReader(fichier), key=lambda ligne: ligne['scrapedAt'])
for ligne in lignes:
date_utc = datetime.fromisoformat(ligne['scrapedAt'].replace('Z', '+00:00'))
date_locale = date_utc.astimezone(fuseau)
if not (debut <= date_locale < fin):
continue
if ligne['changeType'] in ('new', 'unchanged'):
continue
precedent = ligne.get('previousPrice') or ''
prix = ligne.get('price') or ''
nom = ligne.get('name') or ''
stock = ligne.get('inStock') or ''
print('{}  {:<14} {} -> {}  stock : {:<6} {}'.format(
date_locale.strftime('%a %H:%M ET'), ligne['changeType'],
precedent, prix, stock, nom))

Sous Windows, l'installation du paquet tzdata peut être nécessaire pour que Python reconnaisse les fuseaux horaires. Le type de changement mérite aussi une lecture attentive : si un produit change à la fois de prix et de disponibilité, le système peut privilégier l'événement « stock ». Dans ce cas, comparez previousPrice et price, ou regardez le tableau changes[] de l'export brut, plutôt que de déduire que le tarif est resté identique.

Une vérification de fin de campagne

À la fin de la semaine, contrôlez :

• le prix le plus bas observé et la date correspondante ;
• l'écart entre les prix affichés et les produits réellement disponibles ;
• les changements de devise, de variante ou de conditions d'accès ;
• les articles présents dans les deux relevés de comparaison ;
• la durée et le coût réels des exécutions, par rapport à l'estimation initiale.

Ce qui compte, ce n'est pas seulement d'avoir une liste de prix. Il faut un historique suffisamment fiable pour comprendre pourquoi un tarif est considéré comme une bonne affaire, à quel moment il a été disponible, et si l'article était réellement en stock. Pour une veille récurrente, gardez les mêmes règles d'une campagne à l'autre : changer de méthode au milieu rend les comparaisons moins solides.