Fraîcheur des prix et stocks : définir un délai de confiance

Un prix ou un stock n'est fiable que si vous savez quand il a été produit, quand il a été collecté et si la collecte était complète. Définissez des délais de confiance séparés par fournisseur, type de champ et usage : achat automatique, alerte manuelle ou simple analyse historique. Il n'existe pas de durée universelle. Le stock peut changer plus vite que les caractéristiques produit, et un prix ancien peut rester valable contractuellement. Au-delà du délai choisi, ne remplacez pas la valeur par zéro : marquez-la « à confirmer » ou « périmée », empêchez les actions incompatibles avec ce niveau de preuve et demandez une observation récente avant commande.

Trois horodatages au lieu d'une vague « dernière mise à jour »

La fraîcheur est souvent réduite à la date d'exécution du script. C'est insuffisant. Une collecte réussie à 10 h peut télécharger un fichier produit la veille, lui-même fondé sur un système commercial mis à jour à une cadence inconnue. Conservez autant que possible trois temps distincts :

• source_generated_at : date déclarée par le fournisseur pour la donnée ou le fichier ;
• observed_at : moment où votre système a reçu la réponse ;
• validated_at : moment où le contenu a passé les contrôles et a été rendu exploitable.

Si le premier horodatage n'existe pas, ne le remplacez pas par l'heure de téléchargement. Notez explicitement source_generated_at=inconnu. Les validateurs HTTP ETag et Last-Modified, décrits par la RFC 9110, peuvent aider à savoir si une représentation a changé lorsque le serveur les fournit correctement. Ils ne prouvent cependant pas à eux seuls quand le prix ou le stock métier a été actualisé.

Traiter séparément chaque famille de donnée

Une fiche produit rassemble des éléments dont la vitesse de changement n'est pas la même. La marque, le titre ou le GTIN sont généralement utilisés comme données d'identité ; le prix, la disponibilité, le délai et la remise sont des données d'offre. Une seule date globale masque ces différences.

Le statut InStock mérite une attention particulière. Schema.org le définit comme une indication que l'article est en stock, mais cette convention ne fournit ni quantité ni horodatage. L'âge de l'observation reste donc essentiel. La distinction entre stock booléen et quantité exacte doit être conservée en plus de la fraîcheur.

Construire une politique de confiance sans inventer de standard

Commencez par le risque de l'action. Une page de recherche consultée par un humain peut afficher une donnée ancienne avec un avertissement clair. Une commande déclenchée sans vérification exige une preuve plus récente et des garanties contractuelles plus fortes. Définissez ensuite un délai interne pour chaque combinaison source × champ × usage, puis documentez qui l'a approuvé.

Voici un exemple entièrement hypothétique destiné à montrer la structure, et non des durées recommandées. Une équipe pourrait décider qu'un stock observé depuis moins de deux heures est « récent » pour une alerte, qu'entre deux et huit heures il est « à confirmer », et qu'au-delà il est « périmé ». Pour un prix contractuel mensuel, elle pourrait appliquer une règle différente. Ces nombres ne viennent d'aucune norme : ils doivent être remplacés par des seuils issus de votre cadence observée, de votre contrat et de votre tolérance au risque.

La procédure de calibration est plus importante que le chiffre initial :

1. Enregistrer chaque collecte réussie, incomplète ou échouée. 2. Mesurer les intervalles entre changements réellement observés, champ par champ. 3. Relever les commandes refusées, écarts de prix et ruptures après observation. 4. Choisir un seuil initial prudent et explicite pour l'usage étudié. 5. Afficher la date et le statut à l'utilisateur, pas seulement un score. 6. Réviser le seuil à partir des incidents et de nouvelles preuves.

Une politique ne doit jamais déclarer une valeur fraîche uniquement parce que le job a démarré. Elle dépend d'une réponse valide, complète et attribuable à la bonne source.

Gérer les collectes partielles et les silences

Un fichier plus petit que d'habitude peut être une vraie réduction du catalogue ou une exportation interrompue. Une API peut répondre 200 OK tout en renvoyant une page vide à cause d'un curseur mal géré. La fraîcheur doit donc intégrer un contrôle de complétude : volume attendu sous forme de plage observée, nombre de pages, présence des champs critiques et stabilité des identifiants.

Si le contrôle échoue, gardez la dernière valeur validée avec son ancien horodatage. N'associez pas l'heure de l'échec à la donnée conservée. Enregistrez séparément last_attempt_at, last_success_at et le motif exact. C'est ce qui permet de différencier une source silencieuse d'un produit réellement en rupture.

Le choix du format de flux CSV, XML, API ou FTP influence la stratégie de reprise, mais pas la règle fondamentale : on n'avance l'horodatage d'une donnée que lorsqu'une observation pertinente et validée le justifie.

Présenter l'incertitude sans score trompeur

Un score global peut aider à trier, à condition de rester explicable. Affichez l'âge réel, l'horodatage disponible, le type de stock et les derniers incidents à côté de toute couleur. Une jauge verte sans détail transforme un choix interne en promesse implicite.

Préférez trois états opérationnels : utilisable_pour_analyse, confirmation_requise et bloque_pour_action. Les règles qui mènent à ces états doivent être lisibles. Le score de fiabilité d'un fournisseur peut intégrer la fraîcheur, mais ne doit jamais effacer un échec critique ou un champ absent.

Checklist de fraîcheur

• ☐ Les dates source, observation et validation sont séparées.
• ☐ Prix et stock possèdent leurs propres statuts.
• ☐ Une absence d'horodatage est marquée inconnue.
• ☐ Un ETag n'est pas présenté comme date métier.
• ☐ Les seuils sont internes, approuvés et révisables.
• ☐ La complétude est contrôlée avant de déclarer la collecte réussie.
• ☐ Une erreur ne rafraîchit pas la dernière valeur valide.
• ☐ L'âge réel reste visible à côté du score.
• ☐ Une confirmation récente est demandée avant commande.
• ☐ Les incidents alimentent la révision de la politique.

Ce qu'ArbitragePro+ peut automatiser / ce que le vendeur doit vérifier

La spécification proposée score-fraicheur pourrait calculer l'âge des observations, appliquer des seuils configurés, signaler les collectes partielles et bloquer l'usage d'une valeur périmée. Elle devrait toujours exposer les horodatages et la règle ayant produit le statut.

Le vendeur doit définir les délais adaptés à son contrat et à son risque, confirmer prix et disponibilité avant achat, puis arbitrer les cas où la source n'offre pas d'horodatage métier.

Surveiller l'état des sources

Consulter la santé des sources pour examiner les informations de collecte et les alertes actuellement disponibles.

Sources officielles

• IETF, RFC 9110, « HTTP Semantics », https://www.rfc-editor.org/rfc/rfc9110.html — consulté le 2026-08-17.
• Schema.org, « ItemAvailability », https://schema.org/ItemAvailability — consulté le 2026-08-17.
• Schema.org, « InStock », https://schema.org/InStock — consulté le 2026-08-17.