Meilleur et pire mille dollars de juin 2026

Quel a été le meilleur trade d'options de juin 2026 — et qu'en serait-il d'un investissement de mille dollars ? La réponse honnête se décline en quatre points : le jackpot ; l'anomalie de l'exécution à un centime sur deux contrats qui constitue le titre ; les neuf mille pertes quasi totales qui l'entourent ; et le trade miroir — la VENTE de ce que le gagnant a acheté — où mille dollars de primes collectées se sont transformés en une perte à six chiffres. Tout est calculé après coup à partir de l'historique des transactions ; un trade optimal a posteriori mesure ce que le mois a contenu, et non une stratégie qu'un opérateur aurait pu exécuter. Chaque chiffre est le résultat d'une requête stockée ; développez n'importe quel panneau pour obtenir la requête SQL exacte.

Quel a été le niveau de volatilité en juin 2026 ?

Un gain de cent fois sur les options nécessite-t-il un mois de marché historique ? Juin démontre le contraire. Le panel recalcule chaque mois de 2026 de la même manière — de l'ouverture à la clôture en séance régulière, plus l'amplitude entre le plus haut et le plus bas en pourcentage de l'ouverture — pour le SPY et NVDA, les actifs à la base du ticket gagnant. Juin a compté 21 sessions.

SELECT toString(toStartOfMonth(toDate(toTimeZone(window_start, 'America/New_York')))) AS period_start,
    round((argMaxIf(toFloat64(close), window_start, ticker = 'SPY' AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60 + toMinute(toTimeZone(window_start, 'America/New_York'))) BETWEEN 570 AND 959) / argMinIf(toFloat64(open), window_start, ticker = 'SPY' AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60 + toMinute(toTimeZone(window_start, 'America/New_York'))) BETWEEN 570 AND 959) - 1) * 100, 1) AS spy_month_pct,
    round((maxIf(toFloat64(high), ticker = 'SPY' AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60 + toMinute(toTimeZone(window_start, 'America/New_York'))) BETWEEN 570 AND 959) - minIf(toFloat64(low), ticker = 'SPY' AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60 + toMinute(toTimeZone(window_start, 'America/New_York'))) BETWEEN 570 AND 959)) / argMinIf(toFloat64(open), window_start, ticker = 'SPY' AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60 + toMinute(toTimeZone(window_start, 'America/New_York'))) BETWEEN 570 AND 959) * 100, 1) AS spy_range_pct,
    round((argMaxIf(toFloat64(close), window_start, ticker = 'NVDA' AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60 + toMinute(toTimeZone(window_start, 'America/New_York'))) BETWEEN 570 AND 959) / argMinIf(toFloat64(open), window_start, ticker = 'NVDA' AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60 + toMinute(toTimeZone(window_start, 'America/New_York'))) BETWEEN 570 AND 959) - 1) * 100, 1) AS nvda_month_pct,
    round((maxIf(toFloat64(high), ticker = 'NVDA' AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60 + toMinute(toTimeZone(window_start, 'America/New_York'))) BETWEEN 570 AND 959) - minIf(toFloat64(low), ticker = 'NVDA' AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60 + toMinute(toTimeZone(window_start, 'America/New_York'))) BETWEEN 570 AND 959)) / argMinIf(toFloat64(open), window_start, ticker = 'NVDA' AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60 + toMinute(toTimeZone(window_start, 'America/New_York'))) BETWEEN 570 AND 959) * 100, 1) AS nvda_range_pct,
    uniqExactIf(toDate(toTimeZone(window_start, 'America/New_York')), ticker = 'SPY') AS trading_days
FROM global_markets.delayed_stocks_minute_aggs
WHERE ticker IN ('SPY', 'NVDA')
  AND window_start >= toDateTime('2026-01-01 05:00:00') AND window_start < toDateTime('2026-07-01 04:00:00')
GROUP BY period_start
HAVING uniqExactIf(toDate(toTimeZone(window_start, 'America/New_York')), ticker = 'SPY') >= 17
ORDER BY period_start ASC

Le SPY a terminé le mois de juin à -1.2% de son ouverture dans une fourchette de 5.8% — une amplitude plus étroite qu'en mars (8.7%) ou en avril (11.4%). La volatilité s'est manifestée sur un autre actif : NVDA a clôturé à -7.4% de son ouverture de juin après avoir évolué dans une fourchette de 19.7% (le récapitulatif du marché de juin 2026 présente la situation globale du marché). Un ticket multiplié par cent n'a pas eu besoin d'un krach boursier — la chute brutale d'un seul titre sur deux semaines a suffi.

Les plus gros multiples du mois

L'univers : chaque contrat sur six racines liquides avec au moins cinquante transactions en juin — 30951 contrats — évalués du premier print au dernier, sur les deux marchés : ce que l'achat au premier print a rapporté par rapport au dernier, et ce que la vente de mille dollars de prime a finalement coûté.

SELECT ticker AS contract,
    substring(ticker, -9, 1) = 'P' AS is_put,
    round(first_px, 2) AS first_price,
    round(last_px, 2) AS last_price,
    round(last_px / first_px, 1) AS multiple,
    toUInt32(floor(1000 / (first_px * 100))) AS contracts_for_a_thousand,
    round(floor(1000 / (first_px * 100)) * last_px * 100, 0) AS bought_end_value_usd,
    round(1000 * (last_px / first_px) - 1000, 0) AS sold_net_loss_usd,
    trades
FROM (
    SELECT ticker,
        toFloat64(argMin(price, (sip_timestamp, price))) AS first_px,
        toFloat64(argMax(price, (sip_timestamp, price))) AS last_px,
        count() AS trades
    FROM global_markets.options_trades
    WHERE ((startsWith(ticker, 'O:MU') AND length(ticker) = 19) OR (startsWith(ticker, 'O:NVDA') AND length(ticker) = 21) OR (startsWith(ticker, 'O:TSLA') AND length(ticker) = 21) OR (startsWith(ticker, 'O:SPY') AND length(ticker) = 20) OR (startsWith(ticker, 'O:QQQ') AND length(ticker) = 20) OR (startsWith(ticker, 'O:AAPL') AND length(ticker) = 21))
      AND sip_timestamp >= toDateTime64('2026-06-01 00:00:00', 9) AND sip_timestamp < toDateTime64('2026-07-01 00:00:00', 9)
    GROUP BY ticker
    HAVING count() >= 50 AND argMin(price, (sip_timestamp, price)) > 0
)
ORDER BY multiple DESC, contract ASC
LIMIT 5

Le gagnant était un put : O:NVDA260629P00200000, premier print à $0.01 et dernier print à $4.95 — un multiple de 495x. Analyse du symbole : un put NVDA avec un strike de 200 $ expirant le 29 juin. Mille dollars au premier print permettaient d'acheter 1000 contrats ; au dernier print, la position était marquée à $495000. Le titre NVDA a chuté durant la seconde moitié du mois de juin — sa chute détaille la baisse, séance par séance — et ce contrat représentait cette chute, avec effet de levier. Anticiper ce mouvement est la seule chose qu'aucun tableau ne peut vous vendre ; le premier print fait l'objet d'une analyse détaillée ci-dessous.

Les autres acteurs du classement

Les cinq contrats sont des puts — la colonne is_put en est la preuve — et même le plus petit multiple a dépassé dix fois sa mise initiale. La deuxième ligne, un put AAPL à 240 $ expirant le 24 juillet, est passée de $0.01 à $0.34 pour un multiple de 34x et était encore actif à la fin du mois (une expiration en juillet fait de ce dernier prix une valorisation, et non un règlement). La troisième ligne, un put MU à 100 $ expirant le 10 juillet, a affiché un multiple de 20x et s'est également prolongée en juillet. Les quatrième et cinquième lignes, un put TSLA à 397,50 $ et un put QQQ à 707 $, ont réalisé respectivement 12.5x et 11.7x lors de la chute survenue en début de mois. Cinq contrats, cinq paris sur une baisse.

La vente : comment mille dollars deviennent une perte de cinq cent mille

L'achat du titre gagnant impliquait un risque de précisément mille dollars. La VENTE — percevoir ces mêmes mille dollars sous forme de prime — exposait au mouvement du cours. La colonne sold_net_loss_usd présente chaque ligne du point de vue du vendeur, sans tenir compte de la marge, de l'assignation ou des rachats forcés. La vente de 1000 contrats à 0.01 $ a permis de collecter mille dollars ; la dernière cotation évaluait la position à 495000 $ pour le vendeur — soit une perte nette de 494,000 $. Le pire scénario pour l'acheteur est le prix du titre ; le pire scénario pour le vendeur est le mouvement du cours, et le plus grand mouvement de juin a atteint cinq cents tickets de profondeur.

Le problème des penny prints

D'où proviennent les 495x ? Le relevé ci-dessous condense l'intégralité des transactions du gagnant pour le mois de juin en une seule ligne d'analyse : sa première transaction, sa deuxième, et le décompte de chaque penny print de son historique.

SELECT
    toString(toDate(min(sip_timestamp))) AS first_print_date,
    formatDateTime(toTimeZone(min(sip_timestamp), 'America/New_York'), '%H:%i:%S') AS first_print_et,
    round(anyIf(price, rn = 1), 2) AS first_price,
    toUInt64(anyIf(size, rn = 1)) AS first_print_contracts,
    countIf(price <= 0.011) AS penny_prints_in_june,
    toUInt64(sumIf(size, price <= 0.011)) AS penny_contracts_in_june,
    round(anyIf(price, rn = 2), 2) AS second_price,
    toUInt32(dateDiff('second', min(sip_timestamp), anyIf(sip_timestamp, rn = 2))) AS seconds_to_second_print,
    round(argMax(price, (sip_timestamp, price)), 2) AS month_last_price,
    round(argMax(price, (sip_timestamp, price)) / anyIf(price, rn = 2), 1) AS second_print_multiple_to_last,
    round(floor(1000 / (anyIf(price, rn = 2) * 100)) * argMax(price, (sip_timestamp, price)) * 100, 0) AS thousand_at_second_print_end_usd
FROM (
    SELECT sip_timestamp, toFloat64(price) AS price, size,
        row_number() OVER (ORDER BY sip_timestamp, price) AS rn
    FROM global_markets.options_trades
    WHERE ticker = 'O:NVDA260629P00200000'
      AND sip_timestamp >= toDateTime64('2026-06-01 00:00:00', 9) AND sip_timestamp < toDateTime64('2026-07-01 00:00:00', 9)
)

Le contrat n'apparaissait pas sur le tape de juin avant 2026-06-15. Sa première transaction, à 09:49:30 ET, portait sur 2 contrats à $0.01 — soit environ deux dollars de prime. La transaction suivante, 101 secondes plus tard, était de $2.44, et le penny n'a plus jamais été exécuté (1 penny print, 2 contrats, sur tout le mois). La position de mille contrats supposée par le titre est cinq cents fois supérieure au volume jamais échangé à ce prix. Si l'on entre sur la deuxième transaction, mille dollars atteignent $1980 lors de la dernière transaction du mois — soit un multiplicateur de 2x, et non de 495x. La progression depuis la deuxième transaction — un doublement en deux semaines via une trajectoire violente — était réelle et tradable. Le jackpot, tel qu'il est affiché, ne l'était pas.

Le parcours : dix sessions de l'inscription à l'expiration

Considérez l'exécution comme certaine et maintenez la position jusqu'au terme : chaque session affiche le volume échangé, le dernier prix et la valorisation de la position.

WITH (
    SELECT (ticker, first_px)
    FROM (
    SELECT ticker,
        toFloat64(argMin(price, (sip_timestamp, price))) AS first_px,
        toFloat64(argMax(price, (sip_timestamp, price))) AS last_px,
        count() AS trades
    FROM global_markets.options_trades
    WHERE ((startsWith(ticker, 'O:MU') AND length(ticker) = 19) OR (startsWith(ticker, 'O:NVDA') AND length(ticker) = 21) OR (startsWith(ticker, 'O:TSLA') AND length(ticker) = 21) OR (startsWith(ticker, 'O:SPY') AND length(ticker) = 20) OR (startsWith(ticker, 'O:QQQ') AND length(ticker) = 20) OR (startsWith(ticker, 'O:AAPL') AND length(ticker) = 21))
      AND sip_timestamp >= toDateTime64('2026-06-01 00:00:00', 9) AND sip_timestamp < toDateTime64('2026-07-01 00:00:00', 9)
    GROUP BY ticker
    HAVING count() >= 50 AND argMin(price, (sip_timestamp, price)) > 0
    )
    ORDER BY last_px / first_px DESC, ticker ASC
    LIMIT 1
) AS winner
SELECT toDate(sip_timestamp) AS date,
    toUInt64(sum(size)) AS contracts_traded,
    round(sum(toFloat64(price) * toFloat64(size)) * 100 / 1e6, 2) AS day_premium_usd_m,
    round(toFloat64(argMax(price, (sip_timestamp, price))), 2) AS day_last_price,
    round(floor(1000 / (winner.2 * 100)) * toFloat64(argMax(price, (sip_timestamp, price))) * 100, 0) AS position_value_usd,
    round(100 * toFloat64(argMax(price, (sip_timestamp, price))) / max(toFloat64(argMax(price, (sip_timestamp, price)))) OVER (), 1) AS pct_of_peak
FROM global_markets.options_trades
WHERE ticker = winner.1
  AND sip_timestamp >= toDateTime64('2026-06-01 00:00:00', 9) AND sip_timestamp < toDateTime64('2026-07-01 00:00:00', 9)
GROUP BY date
ORDER BY date ASC

Le contrat a été enregistré sur l'ensemble des 10 sessions de sa durée de vie, de 2026-06-15 jusqu'à l'expiration le 2026-06-29. La première journée s'est clôturée à $1.4, avec une perte latente de mille dollars, soit $140000 par rapport au prix d'entrée. Puis la tendance s'est inversée : une valorisation de $287000 en 2026-06-17 a chuté à $106000 en 2026-06-22, soit un drawdown de près des deux tiers. Le sommet, $745000, a été atteint le 2026-06-26, une session avant l'expiration ; le dernier cours enregistré était de $495000 — soit 66.4% du sommet. Même la meilleure transaction du mois s'est achevée un tiers en dessous de son propre plus haut. Volume : le premier jour a enregistré 385 contrats sur la session — soit environ la position estimée sur les trois premières sessions cumulées — tandis que la journée la plus active, le 2026-06-23, a traité 9718 contrats pour $2.86 millions de primes. La liquidité n'est apparue qu'une fois le mouvement amorcé.

L'autre côté du bilan

SELECT
    count() AS contracts_with_50_trades,
    countIf(substring(ticker, -9, 1) = 'P') AS put_contracts,
    countIf(last_px / first_px >= 100) AS up_100x_plus,
    countIf(last_px / first_px >= 10) AS up_10x_plus,
    countIf(last_px / first_px >= 10 AND substring(ticker, -9, 1) = 'P') AS up_10x_puts,
    countIf(last_px / first_px >= 10 AND substring(ticker, -9, 1) = 'C') AS up_10x_calls,
    countIf(last_px / first_px <= 0.1) AS down_90_pct_plus,
    countIf(last_px / first_px <= 0.1 AND substring(ticker, -9, 1) = 'C') AS down_90_calls,
    round(100.0 * countIf(last_px / first_px <= 0.1 AND substring(ticker, -9, 1) = 'C') / countIf(last_px / first_px <= 0.1), 1) AS down_90_call_share_pct,
    countIf(last_px <= 0.02) AS ended_at_two_cents_or_less
FROM (
    SELECT ticker,
        toFloat64(argMin(price, (sip_timestamp, price))) AS first_px,
        toFloat64(argMax(price, (sip_timestamp, price))) AS last_px,
        count() AS trades
    FROM global_markets.options_trades
    WHERE ((startsWith(ticker, 'O:MU') AND length(ticker) = 19) OR (startsWith(ticker, 'O:NVDA') AND length(ticker) = 21) OR (startsWith(ticker, 'O:TSLA') AND length(ticker) = 21) OR (startsWith(ticker, 'O:SPY') AND length(ticker) = 20) OR (startsWith(ticker, 'O:QQQ') AND length(ticker) = 20) OR (startsWith(ticker, 'O:AAPL') AND length(ticker) = 21))
      AND sip_timestamp >= toDateTime64('2026-06-01 00:00:00', 9) AND sip_timestamp < toDateTime64('2026-07-01 00:00:00', 9)
    GROUP BY ticker
    HAVING count() >= 50 AND argMin(price, (sip_timestamp, price)) > 0
)

SELECT ticker AS contract,
    round(first_px, 2) AS first_price,
    round(last_px, 2) AS last_price,
    toUInt32(floor(1000 / (first_px * 100))) AS contracts_a_thousand_bought,
    round(floor(1000 / (first_px * 100)) * last_px * 100, 0) AS ending_value_usd
FROM (
    SELECT ticker,
        toFloat64(argMin(price, (sip_timestamp, price))) AS first_px,
        toFloat64(argMax(price, (sip_timestamp, price))) AS last_px,
        count() AS trades
    FROM global_markets.options_trades
    WHERE ((startsWith(ticker, 'O:MU') AND length(ticker) = 19) OR (startsWith(ticker, 'O:NVDA') AND length(ticker) = 21) OR (startsWith(ticker, 'O:TSLA') AND length(ticker) = 21) OR (startsWith(ticker, 'O:SPY') AND length(ticker) = 20) OR (startsWith(ticker, 'O:QQQ') AND length(ticker) = 20) OR (startsWith(ticker, 'O:AAPL') AND length(ticker) = 21))
      AND sip_timestamp >= toDateTime64('2026-06-01 00:00:00', 9) AND sip_timestamp < toDateTime64('2026-07-01 00:00:00', 9)
    GROUP BY ticker
    HAVING count() >= 50 AND argMin(price, (sip_timestamp, price)) > 0
)
WHERE last_px <= 0.02 AND floor(1000 / (first_px * 100)) >= 1
ORDER BY first_px DESC, contract ASC
LIMIT 1

Le chiffre qui accompagne le jackpot : sur 30951 contrats liquides, exactement 1 ont fait un multiplicateur de cent — et 9385 ont perdu quatre-vingt-dix pour cent ou plus, 8949 contrats sur l'ensemble de l'univers ayant clôturé à deux cents ou moins. En tirant au hasard dans ce jeu, la pile des pertes de quatre-vingt-dix pour cent est apparue des milliers de fois pour chaque jackpot. La perte la plus coûteuse : O:MU260612C01350000, un call MU avec un strike de 1 350 $ expirant le 12 juin, ouvert en juin à 10 et clôturé à 0.01, transformant mille dollars en 1.

Calls ou puts : quel côté a gagné ?

Les deux extrémités ne correspondent pas. Le côté gagnant était exclusivement composé de puts : chacun des 14 ten-baggers était un put (14 puts, 0 calls) dans un univers contenant 14994 puts parmi 30951 contrats. Le côté perdant était presque équilibré : sur les 9385 pertes quasi totales, 4403 — 46.9% — étaient des calls, les puts étant légèrement majoritaires. La direction a permis de choisir chaque grand gagnant, mais n'a sauvé personne à elle seule : des milliers de puts ont également fini dans la pile des pertes, à cause d'un mauvais strike, d'une mauvaise semaine, ou des deux.

Où les pertes se sont accumulées

Quel sous-jacent a alimenté le cimetière ? Pas le nom du krach.

SELECT
    multiIf(startsWith(ticker, 'O:NVDA'), 'NVDA', startsWith(ticker, 'O:TSLA'), 'TSLA', startsWith(ticker, 'O:AAPL'), 'AAPL', startsWith(ticker, 'O:SPY'), 'SPY', startsWith(ticker, 'O:QQQ'), 'QQQ', 'MU') AS root,
    count() AS contracts,
    countIf(last_px / first_px <= 0.1) AS down_90_pct_plus,
    round(100.0 * countIf(last_px / first_px <= 0.1) / count(), 1) AS pct_of_root_wiped,
    round(100.0 * countIf(last_px / first_px <= 0.1) / sum(countIf(last_px / first_px <= 0.1)) OVER (), 1) AS share_of_all_down_90_pct,
    countIf(last_px / first_px >= 10) AS up_10x_plus
FROM (
    SELECT ticker,
        toFloat64(argMin(price, (sip_timestamp, price))) AS first_px,
        toFloat64(argMax(price, (sip_timestamp, price))) AS last_px,
        count() AS trades
    FROM global_markets.options_trades
    WHERE ((startsWith(ticker, 'O:MU') AND length(ticker) = 19) OR (startsWith(ticker, 'O:NVDA') AND length(ticker) = 21) OR (startsWith(ticker, 'O:TSLA') AND length(ticker) = 21) OR (startsWith(ticker, 'O:SPY') AND length(ticker) = 20) OR (startsWith(ticker, 'O:QQQ') AND length(ticker) = 20) OR (startsWith(ticker, 'O:AAPL') AND length(ticker) = 21))
      AND sip_timestamp >= toDateTime64('2026-06-01 00:00:00', 9) AND sip_timestamp < toDateTime64('2026-07-01 00:00:00', 9)
    GROUP BY ticker
    HAVING count() >= 50 AND argMin(price, (sip_timestamp, price)) > 0
)
GROUP BY root
ORDER BY down_90_pct_plus DESC, root ASC

QQQ a fourni la plus grosse pile : 2923 pertes quasi totales — 31.1% de la pile totale — avec 35.7% de ses contrats liquides anéantis. Ajoutez les 24.7% de SPY et les indices racines détiennent plus de la moitié du cimetière. Les deux taux d'effacement les plus faibles appartiennent à NVDA et AAPL (21.8% et 21.8%) — le premier étant NVDA, la racine sous le plus grand gagnant du mois. La pile a grossi là où la prime est restée stable. L'autre côté, même tableau : QQQ a produit 9 des 14 ten-baggers du mois ; SPY, avec 2319 contrats dans la pile, en a produit 0.

Ce que ce tableau enseigne (et ses limites)

Quatre leçons. La convexité est réelle : une option out-of-the-money peu coûteuse voit sa valeur multipliée de manière absurde lors d'un mouvement rapide de l'actif sous-jacent — c'est précisément pourquoi les tickets de loterie s'échangent pour quelques centimes. Les multiples affichés nécessitent une analyse approfondie : le multiple de 495x de juin repose sur une seule transaction de deux lots ; la performance tradable était de deux. La distribution est le prix de la convexité : 14 ten-baggers côtoient 9385 quasi-pertes totales (le guide sur les market makers explique qui vend ces tickets). Enfin, le rétroviseur n'est pas tradable : le ticket gagnant n'existait pas le 1er juin — il n'est apparu que le 15 juin — et l'acheter impliquait de connaître, ce matin-là, la direction et le timing des deux semaines suivantes. Cette page mesure le contenu de juin. Elle ne prédit pas celui de juillet.

FAQ

Quel a été le meilleur trade d'options de juin 2026 ?

Mesuré de la première transaction à la dernière sur six actifs liquides, un put NVDA avec un strike à 200 $ expirant le 29 juin 2026 : de $0.01 à $4.95, soit un multiple de 495x — basé sur une première transaction de deux lots à un centime (la transaction suivante était de $2.44).

Peut-on perdre plus que son investissement initial en trading d'options ?

En achetant des options, non : un acheteur peut perdre au maximum la prime payée. En vendant des options, oui — les données de juin montrent un vendeur ayant collecté mille dollars de prime et finissant avec un drawdown de $494,000 à la dernière transaction.

Pourquoi la plupart des options peu chères expirent-elles sans valeur ?

Une option peu chère valorise un scénario que le marché juge improbable : un mouvement important avant une échéance proche. La plupart des mois ne présentent que peu de mouvements de ce type, et la plupart des tickets subissent l'effet de l'érosion temporelle. En juin 2026, 9385 de 30951 de contrats activement échangés ont perdu au moins quatre-vingt-dix pour cent de leur valeur initiale ; 8949 ont terminé leur dernière transaction à deux cents de dollars ou moins.

Un trader réel aurait-il pu capturer le multiple de 495x ?

Presque certainement pas avec la taille affichée : seuls 2 contrats ont été échangés au prix d'entrée de $0.01, et le prix atteignait $2.44 en moins de 101 secondes. Mille dollars à la deuxième transaction valaient environ $1980 à la dernière transaction — un trade performant, mais un multiple transformateur uniquement avec le recul.

Notes sur les données

Méthodologie

• Période : du 1er au 30 juin 2026 ; les horodatages sont stockés en UTC et filtrés selon les limites UTC brutes. Le panel de calibration sert de bloc de référence et analyse délibérément l'année 2026, avec un calcul identique.
• Par contrat : le premier prix correspond à la transaction la plus précoce du SIP en juin, le dernier à la plus tardive ; les ex æquo sont départagés de manière déterministe par le prix. Les multiples sont calculés via la dernière transaction plutôt que la première, directement dans la requête.
• Le panel de trajectoire quotidienne redérive le gagnant à partir du même scan classé à chaque génération ; le reçu d'entrée le fixe par symbole, avec des limites qui maintiennent le poste si les deux divergent.
• La génération s'effectue uniquement par lots via le chemin de lecture restreint ; la page n'interroge jamais les données en direct. État de l'entrepôt au 12 juillet 2026.

Chaque panel est un objet stocké unique — graphique, tableau et SQL. Interrogez vous-même le grand livre sur le terminal Strasmore.