OHLCV

Jana choisit d’abord une plateforme, une paire et un intervalle. La paire indique ce qui s’échange contre quoi, par exemple du bitcoin contre des dollars. Kraken définit Open comme le prix de la première transaction et Close comme celui de la dernière dans l’intervalle. High et Low sont les prix extrêmes atteints. Jana voit ainsi l’amplitude et la variation entre début et fin sans lire chaque transaction. Aucun de ces prix n’est automatiquement une moyenne ni une offre actuelle du carnet. [1]

Au-delà du mouvement des prix, Jana veut savoir quelle quantité a réellement été échangée. Kraken donne Volume dans l’actif de base de la paire, donc en bitcoins pour BTC/USD. Binance distingue aussi le volume dans l’actif de cotation, ici le dollar, et le nombre de transactions. Quantité de bitcoins, valeur en dollars et nombre d’exécutions sont des données différentes. Un grand nombre sans unité ne révèle pas l’activité du marché ; il faut d’abord savoir ce que compte la source. [1] [2]

Jana trouve ailleurs une bougie quotidienne différente et soupçonne une erreur. Avant de conclure, elle doit aussi comparer les limites temporelles. Binance permet de définir les intervalles par timeZone, un paramètre de fuseau horaire, tandis que startTime et endTime, utilisés pour sélectionner les données, restent interprétés en UTC, la référence horaire mondiale commune. Une journée commençant à un autre moment peut inclure d’autres transactions. Le mot quotidien ne suffit donc pas : marché, période et sens de l’horodatage doivent correspondre. [2]

Sur un graphique en direct, la bougie la plus récente peut changer sous les yeux du lecteur. L’interface REST de Kraken, par laquelle un programme demande des données, inclut toujours l’intervalle en cours, encore inachevé. Son Close désigne alors la dernière transaction connue, pas une clôture définitive ; le volume peut aussi augmenter. Pour comparer des périodes terminées, Jana doit distinguer cette bougie en formation. Sinon, elle compare une histoire achevée à une valeur encore en construction. [3]

Il arrive qu’un intervalle manque. Coinbase avertit que l’historique peut être incomplet et ne publie pas de bougies pour les périodes sans événements de négociation. Jana ne peut donc pas déduire d’un vide une chute du prix à zéro. Elle doit déterminer s’il n’y a eu aucune transaction ou s’il manque des données. Reporter le prix précédent ne crée pas non plus une nouvelle transaction ; si un graphique comble un trou ainsi, cette modification doit être identifiable. [4]

Programmer un graphique présente un autre piège : le sigle OHLCV ne garantit pas l’ordre des champs de réponse. Coinbase indique temps, Low, High, Open, Close et Volume. Kraken distingue aussi le nombre de transactions et VWAP, le prix moyen pondéré par les quantités échangées. Le programme doit lire chaque champ selon la documentation de l’interface utilisée. Inverser des valeurs ne casse pas forcément le graphique de manière visible : cela peut produire une courbe convaincante mais trompeuse. [4] [1]

Les définitions de Kraken permettent aussi de déduire la bonne méthode de regroupement. Si Jana dispose d’intervalles complets, consécutifs et sans chevauchement sur le même marché, elle retient le premier Open et le dernier Close. Pour High, elle prend le maximum le plus élevé ; pour Low, le minimum le plus bas ; elle additionne les Volume comparables. Faire la moyenne des ouvertures donnerait autre chose. Il faut auparavant vérifier l’ordre chronologique, les doublons et les lacunes : une somme ne reconstitue pas les transactions absentes. [1]

Les champs récapitulatifs de Coinbase ne conservent ni la suite complète des transactions ni les offres en attente. Une bougie peut montrer des prix hauts et bas sans dire lequel est venu en premier. Lorsque Jana teste un ordre hypothétique sur le passé, High et Low seuls ne prouvent ni l’ordre de franchissement des seuils ni son exécution réelle. OHLCV est une vue utile du passé, mais ne remplace pas les transactions détaillées ou la confirmation de son propre ordre. [4]