Chargement de la page…
Une alerte de prix utile doit permettre de reconstruire exactement ce qui a changé, quand, sur quelle source et selon quelle règle. Conservez l'identifiant du produit et de la source, l'ancienne et la nouvelle valeur, la devise, la base de taxe, les deux horodatages, la version de la règle et la preuve de collecte. Déclenchez l'alerte sur un événement validé, pas sur une simple différence brute. Distinguez aussi l'heure déclarée par la source de l'heure d'observation par votre système. Enfin, journalisez la tentative de notification et son résultat. L'automatisation accélère la veille ; elle ne transforme ni une donnée périmée ni une page mal interprétée en prix fiable.
Une alerte est un dossier de preuve miniature
Le message « prix en baisse » ne suffit pas pour décider un achat. Il manque la référence concernée, la valeur de comparaison, la devise, le statut de stock, la date de la mesure et la règle qui a produit la notification. Sans ces éléments, une équipe ne peut ni confirmer l'opportunité ni expliquer après coup pourquoi elle a agi.
La trace doit relier trois objets distincts : l'observation brute, la valeur normalisée et la décision de déclencher. La première conserve ce qui a été reçu. La deuxième documente les transformations, par exemple une conversion d'un texte en nombre. La troisième indique la règle et sa version. Si la normalisation est corrigée plus tard, l'observation d'origine permet de rejouer le contrôle sans réinventer les données.
La fraîcheur des prix et des stocks reste un contrôle séparé. Un prix nouvellement importé peut avoir été publié depuis longtemps par le fournisseur ; inversement, une source momentanément indisponible ne prouve pas que son dernier prix est faux. L'alerte doit exposer cet état au lieu de le masquer.
Les champs minimaux à conserver
| Champ | Rôle dans la trace | Contrôle associé |
|---|---|---|
source_id et URL | identifier l'origine | source autorisée et attendue |
| identifiant produit | retrouver la même offre | clé stable, EAN ou référence documentée |
| valeur brute | préserver la preuve reçue | contenu non réécrit |
| ancienne et nouvelle valeur normalisées | expliquer la variation | même devise et même base de comparaison |
| devise et base de taxe | éviter une comparaison ambiguë | valeurs explicitement connues |
| disponibilité observée | contextualiser le prix | ne pas confondre prix et stock |
| heure de l'événement | dater ce que la source affirme | format et fuseau explicites |
| heure d'observation | dater la collecte | horloge du système collecteur |
| version de règle | expliquer le déclenchement | règle immuable ou historisée |
| identifiant de requête | relier les journaux | corrélation bout en bout |
ETag ou Last-Modified, si fourni | conserver le validateur HTTP | ne pas l'assimiler à une date métier |
| résultat de notification | prouver l'envoi ou l'échec | statut, canal et nouvelle tentative |
RFC 3339 définit une représentation d'horodatage utilisable dans les protocoles Internet, avec décalage par rapport à UTC. Le modèle de journaux OpenTelemetry distingue le Timestamp, heure où l'événement s'est produit à la source, de l'ObservedTimestamp, heure où le système l'a observé. Cette séparation est particulièrement utile quand un flux arrive en retard.
HTTP prévoit aussi des validateurs. Last-Modified représente l'estimation du serveur d'origine sur la date de modification de la représentation ; ETag fournit un identifiant opaque de version. Ils aident à savoir si une représentation a changé, mais ils ne prouvent ni la date commerciale du prix ni sa validité contractuelle.
Procédure reproductible de déclenchement
1. Collecter sans écraser. Stockez la réponse utile et les métadonnées de requête avant toute transformation. 2. Identifier l'offre. Reliez la mesure à une source, un produit et, si nécessaire, une variante précise. 3. Valider le format. Vérifiez que prix, devise, taxe et disponibilité sont présents ou marquez les champs manquants. 4. Normaliser explicitement. Conservez chaque règle appliquée à la valeur brute et sa version. 5. Comparer des bases compatibles. Refusez une variation si devise, unité, conditionnement ou base fiscale ne correspondent pas. 6. Contrôler la fraîcheur. Ajoutez l'heure de l'événement et celle de l'observation ; n'inventez pas la première si la source ne la fournit pas. 7. Évaluer la règle. Calculez le résultat avec une règle nommée et historisée, puis conservez ses entrées. 8. Émettre et journaliser. Enregistrez le message, le canal, le résultat et l'identifiant de corrélation. 9. Prévoir le rejeu. Permettez de réévaluer un événement après correction d'une règle sans modifier la preuve d'origine. 10. Fermer la boucle. Documentez la décision humaine : vérifié, ignoré, expiré ou transformé en analyse.
Le tableau de santé des sources complète cette procédure : il indique si la collecte elle-même fonctionne. Une alerte isolée n'est pas un diagnostic de la source entière.
Exemple chiffré entièrement hypothétique
Supposons un produit fictif dont le prix normalisé passe de 28,00 à 25,00 dans la même devise et sur la même base hors taxe. La différence pédagogique est de 3,00, soit environ 10,7 % de l'ancienne valeur. Ces nombres sont inventés et ne décrivent aucun fournisseur ni seuil recommandé.
La règle hypothétique R-7 pourrait demander une baisse strictement supérieure à 2,00 et une observation datant de moins d'une durée choisie par le vendeur. Si les deux conditions documentées sont satisfaites, l'événement devient candidat à notification. Si la devise de la nouvelle mesure est absente, la variation est placée en anomalie plutôt que notifiée. Si la source déclare un prix par lot alors que l'ancienne mesure était unitaire, la comparaison est également bloquée.
Cet exemple montre pourquoi le pourcentage seul est insuffisant. Le journal doit conserver 28,00, 25,00, la formule, R-7, les horodatages, les bases de prix et le motif de la décision. L'équipe peut alors recalculer le résultat et contester une fausse alerte.
Cette capture est une vue publique expurgée de la route indiquée. Elle ne contient aucune donnée de compte et ne prouve pas l'existence de la fonction authentifiée proposée dans cet article.
Traiter doublons, retards et notifications en échec
Deux collectes identiques ne doivent pas produire deux décisions indépendantes si elles représentent le même événement. Définissez une clé d'idempotence à partir d'identifiants stables et documentés, puis conservez le résultat antérieur. Une nouvelle tentative de notification ne doit pas recréer la variation ; elle doit se rattacher à l'événement existant.
Un événement reçu tardivement exige une autre précaution. Triez l'historique selon l'heure de l'événement quand elle est fiable, mais gardez l'heure d'observation pour expliquer l'arrivée. Si seule l'heure d'observation existe, dites-le. Ne reconstruisez pas une heure source supposée.
Enfin, l'échec d'un canal ne signifie pas que la règle a échoué. Séparez l'état de l'événement, l'état de la décision et l'état de chaque notification. Cette distinction facilite les reprises et les audits sans envoyer plusieurs fois la même information.
Ce qu'ArbitragePro+ peut automatiser / ce que le vendeur doit vérifier
La fonction specification:alertes-prix est une proposition, pas une fonction confirmée de l'application.
| Automatisation proposée pour ArbitragePro+ | Vérification qui reste au vendeur |
|---|---|
| collecter et horodater les observations | confirmer que la source et le champ correspondent au prix attendu |
| conserver anciennes valeurs et règles versionnées | valider devise, taxe, unité et conditionnement |
| détecter les différences compatibles | choisir les règles pertinentes pour son activité |
| dédupliquer les événements et rejouer une règle | examiner les anomalies et les corrections de parsing |
| journaliser les tentatives de notification | décider d'acheter, d'attendre ou d'écarter le signal |
L'automatisation proposée organiserait les preuves et la distribution du signal. Elle ne garantirait ni le stock, ni le maintien du prix, ni la rentabilité finale.
Checklist avant d'activer une règle
- La source, le produit et la variante ont des identifiants stables.
- La valeur brute reste disponible après normalisation.
- Devise, taxe, unité et conditionnement sont comparables.
- Heure de l'événement et heure d'observation sont distinguées.
- La règle possède un nom et une version.
- Les validateurs HTTP ne sont pas présentés comme dates commerciales.
- Les doublons et les nouvelles tentatives sont idempotents.
- Le résultat de notification est séparé du résultat de la règle.
- Une validation humaine précède toute commande.
- L'export des opportunités avec leurs preuves conserve les identifiants utiles.
Sources officielles
Sources consultées le 17 août 2026 :
- IETF — RFC 3339, représentation des dates et heures sur Internet
- IETF — RFC 9110, sémantique HTTP et validateurs
- OpenTelemetry — modèle officiel des journaux