À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.
Réponse directe
Un carnet d’ordres est un état ou une vue de données de marché, propre à une plateforme et à un produit, des ordres d’achat et de vente au repos ou des niveaux de prix agrégés. Le cours acheteur affiché le plus élevé et le cours vendeur affiché le plus bas forment le meilleur bid et le meilleur ask ; leur différence est le spread. Cet état visible représente un intérêt exécutable à un instant donné, non une prévision, un engagement à rester en place ni une carte complète de la liquidité cachée, iceberg, RFQ, OTC ou disponible sur d’autres plateformes.
Le niveau des données de marché est déterminant. Le niveau 1 montre le sommet du carnet, le niveau 2 agrège les quantités par prix et le niveau 3 peut exposer les ordres individuels et leur rang dans la file lorsque la plateforme le fournit. Une quantité de niveau 2 peut regrouper plusieurs ordres et ne révèle pas le rang d’un compte dans la file. Un carnet local fiable doit combiner un snapshot cohérent avec des événements incrémentaux continus et correctement ordonnés, puis cesser d’être considéré comme valide si la continuité des séquences ou du checksum échoue.
Les règles d’appariement sont propres à chaque plateforme. Certains carnets continus appliquent la priorité prix-temps ; d’autres produits peuvent employer une allocation au prorata, des enchères, des règles relatives aux ordres cachés, la prévention de l’auto-exécution ou un ordonnancement propre à la blockchain. Les ordres au marché s’exécutent aux prix disponibles, et non à un dernier cours garanti. Les ordres à cours limité peuvent prendre immédiatement de la liquidité et laisser un reliquat au repos. Une demande d’annulation reste en concurrence avec les exécutions jusqu’à sa confirmation ; exécutions, frais, quantité restante, soldes et règlement doivent donc être rapprochés à partir d’événements faisant autorité.
- Glissement moyen
- 0,09%
- Quantité non remplie
- 0
Les résultats sont des approximations pédagogiques. Ils excluent les règles du site, les taxes, la latence, le comportement d'Oracle et d'autres paramètres spécifiques au protocole, sauf indication contraire.
Fonctionnement
- Fixer la plateforme et l’entité juridique, le produit et la séance, le sens base/cotation, le marché au comptant ou le contrat dérivé, le pas de cotation, la taille de lot, le notionnel minimal, le barème de frais, le niveau du carnet, le modèle de conservation ou de règlement et l’horloge.
- Construire une vue locale cohérente : s’abonner aux événements et les mettre en mémoire tampon, obtenir le snapshot documenté, n’appliquer que les mises à jour compatibles et ordonnées, distinguer une taille absolue d’une variation, valider la séquence ou le checksum et reprendre un snapshot à la moindre lacune.
- Lire les règles exactes d’appariement concernant la priorité, les enchères, la prévention de l’auto-exécution, les modifications, les annulations, les ordres cachés ou iceberg et l’ordonnancement on-chain ou intra-bloc. Ne pas déduire le rang dans la file d’un niveau agrégé.
- Définir le sens, la quantité de l’actif de base ou le budget dans la devise de cotation, le comportement à cours limité ou au marché, le déclencheur stop, la durée de validité telle que
GTC,IOCouFOK, les indicateurs post-only ou reduce-only, les bandes de protection et le pire prix acceptable. - Balayer le côté exécutable niveau par niveau afin d’estimer la quantité exécutée, le notionnel, le VWAP, le spread et le slippage par rapport à une référence nommée. Ajouter les frais maker ou taker par exécution et soumettre à un stress la latence, la profondeur qui disparaît ou reste cachée et l’exécution partielle.
- Soumettre avec un identifiant client idempotent et traiter les accusés de réception, rejets et exécutions privés. Considérer modification, annulation et remplacement comme des demandes en concurrence tant que le moteur ou la blockchain ne les a pas confirmés ; rapprocher la quantité restante, l’inventaire, la trésorerie et les frais réellement constatés.
- Comparer le carnet public, l’état privé des ordres, les exécutions et le registre de règlement. Pour une plateforme centralisée, séparer l’appariement de la conservation et du retrait ; pour les carnets on-chain ou hybrides, distinguer soumission, ordonnancement, exécution, règlement, réorganisation et finalité, puis suspendre et resynchroniser si l’état devient incohérent.
Maker et taker décrivent le rôle de liquidité de chaque exécution, et non une étiquette permanente du compte ou de l’ordre. Un ordre à cours limité négociable peut prendre plusieurs niveaux puis laisser un reliquat maker au repos. Les ordres stop sont généralement absents du carnet visible jusqu’à ce qu’un déclencheur défini par la plateforme crée un autre ordre, et le prix de déclenchement ne garantit pas le prix d’exécution. La durée de validité, le post-only, la protection des ordres au marché et le comportement des modifications doivent être vérifiés pour la plateforme et le produit précis.
Exemples chiffrés
- Spread et identité de la cotation. Le meilleur bid est
99.90et le meilleur ask100.10; ainsimidpoint = (99.90 + 100.10) / 2 = 100.00, le spread absolu vaut0.20et le spread rapporté au milieu vaut0.20 / 100.00 = 0.20% = 20 bps. Une dernière transaction à99.70ne modifie pas à elle seule ces cotations actuellement exécutables. - Balayage de la profondeur et frais. Les asks sont
2 @ 100.00,3 @ 100.20et5 @ 100.50. Un achat au marché de8coûte200.00 + 300.60 + 301.50 = 802.10, soitVWAP = 802.10 / 8 = 100.2625. Le slippage par rapport au meilleur ask est0.2625% = 26.25 bps. Avec des frais taker de20 bps, les frais sont de1.6042, la sortie de trésorerie totale de803.7042et le coût unitaire tout compris de100.463025. - Reliquat d’un ordre limite négociable. Un ordre d’achat limité de
8 @ 100.20face aux mêmes asks exécute2 @ 100.00et3 @ 100.20, pour un coût de500.60et un VWAP de100.12, avec3non exécutés. SousIOC, le reliquat est annulé ; sousGTC, il peut rester au carnet à100.20. Des frais taker de20 bpssur le notionnel exécuté valent1.0012, de sorte que la sortie de trésorerie courante est501.6012avant toute exécution maker ultérieure. - Séquences et concurrence des annulations. Un snapshot local à
sequence = 100affiche4 @ 100.10. L’événement101ramène la quantité à1, mais l’événement reçu ensuite est103; l’absence de102rend le carnet inconnu, de sorte que103ne peut pas le réparer de manière sûre et qu’un nouveau snapshot est requis. Par ailleurs, un ordre de vente de10reçoit des exécutions de2et1avant l’accusé d’annulation : la quantité finale exécutée est3et le reliquat annulé7, et non zéro exécuté.
Risques
- Plateforme, entité juridique, produit, contrat, séance ou environnement erroné.
- Sens base/cotation inversé ou unités de quantité et de notionnel incohérentes.
- Pas de cotation, taille de lot, notionnel minimal, décimales ou règle de bande de prix erronés.
- Snapshot périmé, incomplet, issu de la mauvaise séance ou incompatible avec les événements en mémoire tampon.
- Lacune de séquence, doublon, événement désordonné ou échec du checksum ignoré.
- Taille de remplacement absolue traitée comme une variation, ou suppression par taille nulle mal gérée.
- Agrégation de niveau 2 confondue avec l’identité d’un ordre de niveau 3 ou son rang dans la file.
- Liquidité cachée, iceberg, RFQ, opaque, OTC, internalisée ou disponible sur d’autres plateformes omise.
- Priorité prix-temps, prorata, enchère, prévention de l’auto-exécution, modification ou reconstitution supposés à tort.
- Sémantique des ordres au marché, à cours limité, stop, avec bande de protection, post-only, reduce-only,
GTC,IOCouFOKmal comprise. - Ordre au marché partiellement exécuté, rejeté ou exécuté loin du dernier cours, du milieu ou du meilleur prix.
- Annulation, modification ou remplacement en concurrence avec les exécutions, créant un reliquat ou une surexécution involontaire.
- Soumission en double, accusé perdu, collision d’identifiant client ou discordance d’identifiant d’ordre rompant l’idempotence.
- Rôle maker/taker, palier, remise, frais par exécution, financement ou frais de règlement mal comptabilisés.
- Spread ou profondeur affichés disparaissant pendant la latence réseau, de traitement, de file ou de bloc.
- Murs acheteurs ou vendeurs annulés, manipulés, stratifiés, reconstitués ou mal interprétés entre plateformes fragmentées.
- Référence de slippage, sens, spread, VWAP, frais, conversion de change ou coût tout compris mal calculés.
- Suspension, enchère, mode limit-only, maintenance, panne, limite de débit ou changement d’état du marché modifiant le comportement.
- Défaillance de la conservation, du registre, de la ségrégation des actifs, du retrait, de la solvabilité ou de l’intégrité de l’API d’une plateforme centralisée, indépendamment de l’appariement.
- Flux on-chain ou hybride ajoutant des risques d’autorisation, nonce, gas, séquenceur, MEV, contrat, réorganisation, finalité et indexeur, avec échec du rapprochement final.
Idées reçues
- « Un grand mur acheteur garantit une hausse du prix. » Les ordres affichés peuvent être légitimes, annulés, déplacés, masqués par d’autres flux ou destinés à induire en erreur.
- « Un ordre au marché s’exécute au dernier cours, au milieu ou au meilleur prix. » Il consomme la liquidité opposée disponible et peut n’être exécuté qu’en partie ou traverser plusieurs niveaux.
- « Un ordre à cours limité est toujours maker et ne coûte rien. » Une partie négociable peut être taker, le reliquat peut attendre ou ne jamais être exécuté, et les frais, le coût d’opportunité et la fuite d’information subsistent.
- « Un volume historique élevé garantit une liquidité exécutable profonde pour toute taille. » Le volume mesure la rotation passée ; la profondeur actuelle, la latence, les flux cachés et l’impact de marché déterminent l’exécution.
- « Un carnet d’ordres on-chain est entièrement visible, instantanément final et sans tiers de confiance. » L’ordonnancement, les ordres signés hors chaîne, les séquenceurs, contrats, indexeurs, le règlement et la finalité peuvent rester des dépendances distinctes.
Sujets connexes
Sources
- Recommended Practices for Book Management - FIX Trading Community (consulté le 2026-08-13)
- Exchange Matching Engine - Coinbase Developer Documentation (consulté le 2026-08-13)
- Exchange WebSocket Channels - Coinbase Developer Documentation (consulté le 2026-08-13)
- Create a new order - Coinbase Developer Documentation (consulté le 2026-08-13)
- Get all fills - Coinbase Developer Documentation (consulté le 2026-08-13)
- Get fees - Coinbase Developer Documentation (consulté le 2026-08-13)
- Order Types - Coinbase Developer Documentation (consulté le 2026-08-13)
- Order book - Hyperliquid Docs (consulté le 2026-08-13)