Vous envoyez un ordre portant sur 10 000 unités et le carnet d’ordres n’en tient que 1 000 à votre prix. Qu’advient-il des 9 000 autres ? Chaque ordre porte déjà une réponse à cette question avant même d’être envoyé. Fill or kill, immediate or cancel et all or none sont trois façons d’y répondre, et ce ne sont pas trois variantes d’un même réglage.
Ce que décide vraiment un time-in-force
Un time-in-force est une instruction attachée à un ordre, et il tranche exactement une question : ce qu’il advient de la part qui ne peut pas être exécutée tout de suite. Soit cette part attend dans le carnet, soit elle est écartée au moment de l’appariement.
C’est là tout l’axe. Un ordre good-till-cancelled prend la première branche et attend jusqu’à son exécution ou jusqu’à ce que vous le retiriez. Un ordre good-till-date attend de la même façon mais s’arrête à une échéance que vous fixez. Immediate or cancel et fill or kill prennent la seconde branche, celle où rien du tout ne reste en attente.
Le protocole FIX, une spécification sectorielle de longue date pour le traitement des ordres, définit ce champ comme précisant combien de temps l’ordre reste en vigueur, et sa propre valeur par défaut est un réglage à la journée de trading, hérité de places qui ferment. Kraken retient good-till-cancelled comme valeur par défaut sur sa propre interface d’ordres. Écrits en toutes lettres à leur première apparition, les trois réglages sont abrégés à partir d’ici en IOC, FOK et AON.
Immediate or cancel : prendre ce qui est là, laisser le reste
Un ordre immediate-or-cancel traite tout ce qu’il peut contre le carnet à cet instant et écarte le reste. Il autorise une exécution partielle : si 1 000 de vos 10 000 peuvent se traiter à votre prix, 1 000 se traitent et les 9 000 autres cessent simplement d’exister.
Kraken décrit ce réglage comme celui qui annule aussitôt toute quantité qui ne peut pas être exécutée à l’arrivée. Coinbase formule le même comportement comme l’annulation de toute quantité restante. Deux plateformes, un même mécanisme.
Ici, immediate renvoie au moment de l’appariement, pas à la vitesse. Quand le carnet est assez profond pour absorber l’ordre entier, un IOC et un ordre à cours limité ordinaire au même prix suivent le même trajet et finissent au même endroit. La différence n’apparaît qu’à l’instant où il reste quelque chose.
Fill or kill : tout, tout de suite, ou rien
Un ordre fill-or-kill ajoute une condition à cette même immédiateté : la quantité entière, ou rien. C’est un IOC plus une exigence d’intégralité, et les deux conditions doivent tenir ensemble. Si 9 000 de vos 10 000 pouvaient se traiter, un IOC traite les 9 000 et un FOK ne traite rien.
Ce qu’un FOK garantit, c’est la quantité, pas le prix. Il peut se compléter intégralement à une moyenne bien pire que le prix que vous regardiez, parce qu’il consomme toute la profondeur nécessaire pour finir le travail. La maîtrise du prix est un instrument distinct, un prix limite ou une tolérance au slippage, et se tourner vers fill or kill pour éviter un mauvais prix, c’est lui demander ce qu’il ne fournit pas.
Kraken consigne une restriction supplémentaire qu’il vaut mieux connaître avant de chercher le réglage : son option fill-or-kill n’est disponible que pour les ordres à cours limité.
All or none est un autre réglage, pas une troisième échéance
All or none a l’air d’un frère de fill or kill, et il ne l’est pas. Dans FIX, le time-in-force vit dans un champ unique à huit valeurs, et all or none n’en fait pas partie. Il vit dans un champ distinct, celui des instructions de traitement des ordres, sous le code G, décrit là comme all or none.
La conséquence est pratique, pas administrative. Comme AON siège sur un autre champ, il peut se combiner à une échéance : un ordre all-or-none qui est aussi good-till-cancelled se pose dans le carnet et attend, mais ne se traitera jamais qu’en un seul bloc complet. Fill or kill rassemble immédiateté et intégralité dans une seule valeur de time-in-force, si bien qu’il ne peut attendre quoi que ce soit.
| Le reste peut-il rester dans le carnet | Exécution partielle autorisée | Exécution partielle interdite |
|---|---|---|
| Oui, il attend | Good-till-cancelled | All or none, posé |
| Non, il est écarté | Immediate or cancel | Fill or kill |
Ce que dit le statut quand rien ne s’exécute
Un ordre qui n’a jamais été traité n’est pas automatiquement un ordre échoué ou expiré. Sous FIX, un ordre fill-or-kill ou immediate-or-cancel non exécuté finit annulé, et la spécification cite ces deux-là comme les exceptions explicites à l’état expiré.
Cela se lit étrangement au regard du sens ordinaire d’annulé, qui suppose que quelque chose a reposé dans le carnet puis en a été retiré. La réconciliation tient en ceci : l’ordre est bien devenu actif, il n’a simplement jamais reposé dans le carnet. Coinbase dit la même chose dans l’autre sens : un ordre fill-or-kill n’est publié dans le carnet que s’il devait être exécuté immédiatement et intégralement.
La séquence officielle détaillée rend l’arithmétique visible. Un ordre fill-or-kill portant sur 10 000 qui ne peut pas être complété finit sans rien de traité : la quantité exécutée est 0 et la quantité restante est 0. Un ordre immediate-or-cancel portant sur les mêmes 10 000 qui trouve 1 000 disponibles finit avec 1 000 traités et 9 000 annulés. Ces mêmes tableaux portent aussi une branche rejetée, et la spécification note séparément qu’un ordre peut passer du statut nouveau au statut rejeté même après avoir été acquitté. Rejeté et annulé sont deux issues distinctes : lisez le statut que rapporte votre plateforme plutôt que de supposer lequel s’applique.
Les réglages côte à côte
| Réglage | Le reste | Exécution partielle | Champ sur lequel il vit |
|---|---|---|---|
| Good-till-cancelled | Reste jusqu’à l’exécution ou au retrait | Autorisée | Time-in-force |
| Good-till-date | Reste jusqu’à votre échéance | Autorisée | Time-in-force |
| Immediate or cancel | Écarté aussitôt | Autorisée | Time-in-force |
| Fill or kill | Écarté aussitôt | Interdite | Time-in-force |
| All or none | Dépend de l’échéance à laquelle il est associé | Interdite | Instruction de traitement des ordres |
Quand chacun est le bon choix
Tournez-vous vers fill or kill quand une position partielle vaut moins que pas de position du tout. Une jambe d’arbitrage ou une jambe de couverture qui ne fonctionne qu’en taille pleine est le cas net : la moitié n’en vaut pas la moitié, c’est une exposition nouvelle et non voulue. Le prix que vous acceptez pour cette certitude, c’est qu’un échec de peu ne rapporte rien du tout.
Tournez-vous vers immediate or cancel quand vous voulez consommer la liquidité qui se trouve devant vous sans laisser derrière vous un ordre visible. Il traverse le carnet posé à peu près comme le fait un ordre au marché, à ceci près qu’un ordre au marché consiste à prendre les meilleurs prix disponibles plutôt qu’à décider quoi faire d’un reste.
Tournez-vous vers un réglage qui laisse l’ordre posé quand l’attente est justement le but. Si votre prix n’est pas encore dans le carnet et que vous acceptez de patienter jusqu’à ce qu’il arrive, écarter l’ordre au moment de l’appariement va à l’encontre de l’objectif.
En résumé
Un time-in-force répond à une question et à une seule : ce que devient la quantité qui ne peut pas se traiter tout de suite. Immediate or cancel écarte le reste et garde ce qu’il a obtenu. Fill or kill refuse entièrement le résultat partiel, si bien qu’il se complète ou ne vous laisse rien. All or none n’est pas du tout une échéance mais une règle d’intégralité posée sur un autre champ, et c’est pourquoi il peut attendre dans le carnet là où fill or kill ne le peut pas.
Avant d’en utiliser un, vérifiez à laquelle des deux questions vous répondez vraiment : combien de temps l’ordre doit vivre, ou si un résultat incomplet est acceptable. C’est en confondant les deux qu’on transforme fill or kill en une protection de prix attendue, ce qu’il n’a jamais été. Pour continuer à apprendre les fondamentaux, retrouvez d’autres articles de Bitbase Academy.
Articles associés
Autres articles Bitbase sur ce sujet :
- Déséquilibre du carnet d'ordres, CVD et impact sur le marché
- Murs d'achat, murs de vente et profondeur du carnet d'ordres
- Frais maker et taker en crypto : quelle différence ?
- Protection des ordres au marché et limites fat-finger
Avertissement : Cet article est un contenu pédagogique de Bitbase Academy, fourni à titre d'information uniquement. Il ne constitue pas un conseil en investissement, en trading, en fiscalité ou en finance. Les cryptoactifs sont volatils ; évaluez votre propre risque. Rédigé en septembre 2026 ; référez-vous aux informations officielles les plus récentes.
Sources
[1] FIX Trading Community, FIX Application Layer: Order State Changes (FIX Latest, mis à jour jusqu’à EP284, novembre 2023) fixtrading.org
[2] Onix Solutions, dictionnaire FIX 4.4, TimeInForce(59) onixs.biz
[3] Onix Solutions, dictionnaire FIX 4.4, ExecInst(18) onixs.biz
[4] Documentation de l’API Kraken, WebSocket v2, Add Order (champ time_in_force) docs.kraken.com
[5] Documentation développeur de Coinbase, Advanced Trade API, Create Order docs.cdp.coinbase.com
