---
title: "Carnet d’ordres de cryptoactifs"
description: "Un carnet d’ordres est une vue propre à une plateforme des ordres d’achat et de vente au repos ; son utilisation sûre exige une reconstruction cohérente des données de marché, des règles d’appariement exactes, un calcul d’exécution tenant compte de la profondeur et un rapprochement des exécutions et du règlement."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Carnet d’ordres de cryptoactifs

> À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

<a id="answer"></a>

## 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é.

<a id="mechanism"></a>

## Fonctionnement

1. 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.
2. 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.
3. 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é.
4. 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`, `IOC` ou `FOK`, les indicateurs post-only ou reduce-only, les bandes de protection et le pire prix acceptable.
5. 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.
6. 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.
7. 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.

<a id="example"></a>

## Exemples chiffrés

- **Spread et identité de la cotation.** Le meilleur bid est `99.90` et le meilleur ask `100.10` ; ainsi `midpoint = (99.90 + 100.10) / 2 = 100.00`, le spread absolu vaut `0.20` et le spread rapporté au milieu vaut `0.20 / 100.00 = 0.20% = 20 bps`. Une dernière transaction à `99.70` ne modifie pas à elle seule ces cotations actuellement exécutables.
- **Balayage de la profondeur et frais.** Les asks sont `2 @ 100.00`, `3 @ 100.20` et `5 @ 100.50`. Un achat au marché de `8` coûte `200.00 + 300.60 + 301.50 = 802.10`, soit `VWAP = 802.10 / 8 = 100.2625`. Le slippage par rapport au meilleur ask est `0.2625% = 26.25 bps`. Avec des frais taker de `20 bps`, les frais sont de `1.6042`, la sortie de trésorerie totale de `803.7042` et le coût unitaire tout compris de `100.463025`.
- **Reliquat d’un ordre limite négociable.** Un ordre d’achat limité de `8 @ 100.20` face aux mêmes asks exécute `2 @ 100.00` et `3 @ 100.20`, pour un coût de `500.60` et un VWAP de `100.12`, avec `3` non exécutés. Sous `IOC`, le reliquat est annulé ; sous `GTC`, il peut rester au carnet à `100.20`. Des frais taker de `20 bps` sur le notionnel exécuté valent `1.0012`, de sorte que la sortie de trésorerie courante est `501.6012` avant toute exécution maker ultérieure.
- **Séquences et concurrence des annulations.** Un snapshot local à `sequence = 100` affiche `4 @ 100.10`. L’événement `101` ramène la quantité à `1`, mais l’événement reçu ensuite est `103` ; l’absence de `102` rend le carnet inconnu, de sorte que `103` ne peut pas le réparer de manière sûre et qu’un nouveau snapshot est requis. Par ailleurs, un ordre de vente de `10` reçoit des exécutions de `2` et `1` avant l’accusé d’annulation : la quantité finale exécutée est `3` et le reliquat annulé `7`, et non zéro exécuté.

<a id="risks"></a>

## 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`, `IOC` ou `FOK` mal 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.

<a id="misconceptions"></a>

## 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.

<a id="related"></a>

## Sujets connexes

- [Plateforme d’échange centralisée](/fr/crypto/cex/)
- [Ordre à cours limité](/fr/crypto/limit-order-crypto/)
- [Ordre au marché](/fr/crypto/market-order-crypto/)

<a id="sources"></a>

## Sources

- [Recommended Practices for Book Management](https://www.fixtrading.org/wp-content/uploads/download-manager-files/MDOWG_Book_Mgt-v20.pdf) - FIX Trading Community (consulté le 2026-08-13)
- [Exchange Matching Engine](https://docs.cdp.coinbase.com/exchange/concepts/matching-engine) - Coinbase Developer Documentation (consulté le 2026-08-13)
- [Exchange WebSocket Channels](https://docs.cdp.coinbase.com/exchange/websocket-feed/channels) - Coinbase Developer Documentation (consulté le 2026-08-13)
- [Create a new order](https://docs.cdp.coinbase.com/api-reference/exchange-api/rest-api/orders/create-new-order) - Coinbase Developer Documentation (consulté le 2026-08-13)
- [Get all fills](https://docs.cdp.coinbase.com/api-reference/exchange-api/rest-api/orders/get-all-fills) - Coinbase Developer Documentation (consulté le 2026-08-13)
- [Get fees](https://docs.cdp.coinbase.com/api-reference/exchange-api/rest-api/fees/get-fee) - Coinbase Developer Documentation (consulté le 2026-08-13)
- [Order Types](https://docs.cdp.coinbase.com/prime/concepts/trading/order-types) - Coinbase Developer Documentation (consulté le 2026-08-13)
- [Order book](https://hyperliquid.gitbook.io/hyperliquid-docs/hypercore/order-book) - Hyperliquid Docs (consulté le 2026-08-13)

Source: https://wiki.fcontext.com/fr/crypto/order-book-crypto/index.mdx