> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Appariement

> Le carnet d’ordres, la façon dont la priorité prix-temps est représentée, et la manière dont la durée de validité et la prévention de l’auto-exécution s’y résolvent.

L’appariement est une étape à l’intérieur de l’[exécution du noyau](/fr/protocol/architecture/kernel), non un service auquel la chaîne s’adresse. Il prend les ordres du bloc dans leur séquence entérinée, les confronte au carnet et produit des exécutions. Il ne déplace le solde de personne — c’est le travail de la [chambre de compensation](/fr/protocol/architecture/clearinghouse), et cela se produit une fois l’appariement terminé.

C’est en tenant ces deux choses séparées que le moteur devient testable. L’appariement répond à *quoi s’est échangé contre quoi*. La chambre de compensation répond à *ce que cela coûte et qui doit désormais quoi à qui*.

<h2 id="the-book">
  Le carnet
</h2>

Chaque instrument a son propre carnet, tenu en mémoire sous la forme de trois structures coopérantes :

<div className="dg" data-dg="matching-book">
  <div className="dg-c" style={{aspectRatio:"720 / 302"}}>
    <svg className="dg-w" viewBox="0 0 720 302" aria-hidden="true">
      <path className="dg-wire dg-soft" d="M 348.60 82.00 L 352.60 82.00" />

      <path className="dg-wire dg-soft" d="M 438.20 82.00 L 442.20 82.00" />

      <path className="dg-wire dg-soft" d="M 527.80 82.00 L 531.80 82.00" />

      <path className="dg-wire dg-soft" d="M 617.40 82.00 L 621.40 82.00" />

      <path className="dg-wire dg--blue" d="M 205.00 68.00 L 238.60 68.00" />

      <path className="dg-head dg--blue" d="M 245.00 68.00 L 238.60 72.40 L 238.60 63.60 Z" />

      <path className="dg-wire dg--sky" d="M 205.00 162.00 L 238.60 162.00" />

      <path className="dg-head dg--sky" d="M 245.00 162.00 L 238.60 166.40 L 238.60 157.60 Z" />
    </svg>

    <div className="dg-band" style={{left:"34.7222%",top:"9.9338%",width:"65.2778%",height:"56.2914%"}}><span className="dg-cap">Slab arena — une région préallouée d’emplacements</span></div>
    <div className="dg-b dg--blue" style={{left:"0.0000%",top:"9.9338%",width:"27.7778%",height:"25.1656%"}}><span className="dg-t">Niveaux de prix</span><span className="dg-s">table ordonnée, prix → niveau</span><span className="dg-n">la meilleure limite se trouve à l’extrémité, sans balayage</span></div>
    <div className="dg-b dg--sky" style={{left:"0.0000%",top:"41.0596%",width:"27.7778%",height:"25.1656%"}}><span className="dg-t">Index des ordres</span><span className="dg-s">id ordre → emplacement</span><span className="dg-n">annuler et modifier en temps constant</span></div>
    <div className="dg-b dg--yellow" style={{left:"36.9444%",top:"19.5364%",width:"11.0556%",height:"15.2318%"}}><span className="dg-t">ordre</span></div>
    <div className="dg-b dg--yellow" style={{left:"49.3889%",top:"19.5364%",width:"11.0556%",height:"15.2318%"}}><span className="dg-t">ordre</span></div>
    <div className="dg-b dg--yellow" style={{left:"61.8333%",top:"19.5364%",width:"11.0556%",height:"15.2318%"}}><span className="dg-t">ordre</span></div>
    <div className="dg-b dg--yellow" style={{left:"74.2778%",top:"19.5364%",width:"11.0556%",height:"15.2318%"}}><span className="dg-t">ordre</span></div>
    <div className="dg-b dg--yellow" style={{left:"86.7222%",top:"19.5364%",width:"11.0556%",height:"15.2318%"}}><span className="dg-t">ordre</span></div>
    <div className="dg-b dg-plain dg-left" style={{left:"36.9444%",top:"41.3907%",width:"60.8333%",height:"15.2318%"}}><span className="dg-s">Chaîne doublement liée dans la séquence d’arrivée : la priorité dans un niveau est positionnelle, non calculée.</span></div>
    <div className="dg-b dg-dashed dg-left" style={{left:"0.0000%",top:"74.8344%",width:"100.0000%",height:"20.5298%"}}><span className="dg-t">Pourquoi la séquence est fixe</span><span className="dg-s">Les emplacements libérés sont réutilisés dans une séquence fixe, avec une graine d’index fixe. Pas un choix de performance : deux validateurs qui feraient autrement forkeraient.</span></div>
    <div className="dg-lbl" style={{left:"31.2500%",top:"17.8808%",width:"15.2778%",whiteSpace:"normal"}}>tête de chaque niveau</div>
    <div className="dg-lbl" style={{left:"31.2500%",top:"62.9139%",width:"15.2778%",whiteSpace:"normal"}}>accès direct</div>
  </div>
</div>

| Structure             | Rôle                                                                                                                                                                      |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Niveaux de prix**   | Une table ordonnée du prix vers le niveau, de sorte que le meilleur cours acheteur et le meilleur cours vendeur se trouvent en allant à l’extrémité plutôt qu’en balayant |
| **Chaîne des ordres** | Une liste doublement chaînée qui enfile les ordres dans leur séquence d’arrivée, de sorte que la priorité à l’intérieur d’un niveau est positionnelle plutôt que calculée |
| **Index des ordres**  | Une table directe de l’identifiant d’ordre vers son emplacement, de sorte que l’annulation et la modification se font en temps constant plutôt que par recherche          |

Les ordres vivent dans un **slab arena** — une région préallouée dont l’allocation et la libération se font en temps constant. Les opérations sur le carnet n’allouent donc pas sur le chemin critique, et les emplacements libérés sont réutilisés selon une séquence fixe, et non là où l’allocateur se trouve les placer. Ce dernier détail n’est pas un choix de performance : si deux validateurs réutilisaient les emplacements dans des séquences différentes, tout ce qui observe la disposition des emplacements divergerait.

La même discipline s’applique à l’index des ordres, dont la graine est fixe et non aléatoire. Une table de hachage avec une graine par processus est une défense classique contre les attaques par collision ; sur un chemin d’exécution soumis au consensus, c’est un fork.

Les prix sont des entiers de bout en bout — des unités de subtick, pas des décimaux. Voir [Précision](/fr/trading/precision) pour la correspondance avec ce que vous soumettez.

<h2 id="priority">
  La priorité
</h2>

La priorité, c’est le prix d’abord, puis la position dans la chaîne à ce prix. Le « temps » est la position canonique de l’ordre dans la séquence entérinée du bloc, non le moment où il est arrivé sur un nœud.

C’est ce qui supprime la course à la latence intra-bloc. Deux ordres d’un même bloc ont une préséance définie que chaque validateur calcule à l’identique, et aucune proximité avec un nœud donné n’y change quoi que ce soit. D’un bloc à l’autre, l’arrivée compte encore — mais l’unité de compétition est le bloc, pas la microseconde.

L’enchaînement des étapes du noyau renforce cela : les annulations s’exécutent avant les placements agressifs à l’intérieur d’un bloc, de sorte qu’une cotation en carnet ne peut pas être prise par un ordre arrivé dans le même bloc que son annulation.

<h2 id="matching-an-order">
  Apparier un ordre
</h2>

<div className="dg" data-dg="matching-walk">
  <div className="dg-c" style={{aspectRatio:"720 / 334"}}>
    <svg className="dg-w" viewBox="0 0 720 334" aria-hidden="true">
      <path className="dg-wire dg--blue" d="M 134.00 144.00 L 155.60 144.00" />

      <path className="dg-head dg--blue" d="M 162.00 144.00 L 155.60 148.40 L 155.60 139.60 Z" />

      <path className="dg-wire dg--sky" d="M 320.00 144.00 L 345.60 144.00" />

      <path className="dg-head dg--sky" d="M 352.00 144.00 L 345.60 148.40 L 345.60 139.60 Z" />

      <path className="dg-wire dg--green" d="M 510.00 144.00 L 535.60 144.00" />

      <path className="dg-head dg--green" d="M 542.00 144.00 L 535.60 148.40 L 535.60 139.60 Z" />

      <path className="dg-wire dg--sky" d="M 633.00 114.00 L 633.00 80.00 L 241.00 80.00 L 241.00 103.60" />

      <path className="dg-head dg--sky" d="M 241.00 110.00 L 236.60 103.60 L 245.40 103.60 Z" />

      <path className="dg-wire dg--green" d="M 633.00 174.00 L 633.00 213.60" />

      <path className="dg-head dg--green" d="M 633.00 220.00 L 628.60 213.60 L 637.40 213.60 Z" />

      <path className="dg-wire dg--sky" d="M 241.00 178.00 L 241.00 213.60" />

      <path className="dg-head dg--sky" d="M 241.00 220.00 L 236.60 213.60 L 245.40 213.60 Z" />
    </svg>

    <div className="dg-b dg--blue" style={{left:"0.0000%",top:"35.3293%",width:"18.0556%",height:"15.5689%"}}><span className="dg-t">Ordre entrant</span></div>
    <div className="dg-b dg--yellow dg-round" style={{left:"23.0556%",top:"34.1317%",width:"20.8333%",height:"17.9641%"}}><span className="dg-t">Croise le carnet ?</span></div>
    <div className="dg-b dg--sky" style={{left:"49.4444%",top:"35.3293%",width:"20.8333%",height:"15.5689%"}}><span className="dg-t">Consommer meilleur niveau opposé</span></div>
    <div className="dg-b dg--green" style={{left:"75.8333%",top:"35.3293%",width:"24.1667%",height:"15.5689%"}}><span className="dg-t">Émettre exécution</span></div>
    <div className="dg-b dg--green" style={{left:"75.8333%",top:"67.0659%",width:"24.1667%",height:"25.7485%"}}><span className="dg-t">Terminé</span></div>
    <div className="dg-b dg--sky dg-left" style={{left:"10.5556%",top:"67.0659%",width:"45.8333%",height:"25.7485%"}}><span className="dg-t">Reposer ou rejeter, selon la durée de validité</span><span className="dg-s">GTC repose · IOC annule · FOK n’exécute rien sauf en totalité · post-only est rejeté plutôt que de croiser</span></div>
    <div className="dg-lbl" style={{left:"60.6944%",top:"23.9521%",width:"27.7778%",whiteSpace:"normal"}}>reliquat — niveau suivant</div>
    <div className="dg-lbl" style={{left:"87.9167%",top:"58.9820%"}}>plus rien</div>
  </div>
</div>

Le moteur consomme à répétition la tête du côté opposé, en émettant une exécution pour chaque maker qu’il prend, jusqu’à épuisement de l’ordre entrant ou jusqu’à ce que le carnet ne croise plus. Le sort d’un éventuel reliquat est décidé par la durée de validité :

* **GTC** — le reliquat reste en carnet.
* **IOC** — le reliquat est annulé.
* **FOK** — si l’ordre ne peut pas être exécuté intégralement, rien ne s’exécute du tout.
* **ALO** — post-only (exclusivement maker) : si l’ordre devait prendre de la liquidité, il est rejeté plutôt que de croiser.

Les exécutions portent leur attribution dès leur production. Chaque exécution enregistre sa place dans la suite des exécutions de son instrument, et ces places par instrument sont résolues en un séquencement unique à l’échelle du bloc au moment de l’assemblage de la sortie. C’est ce qui permet, plus tard, de remonter d’un événement à la transaction exacte et au point exact du bloc qui l’a causé.

<h2 id="self-trade-prevention">
  Prévention de l’auto-exécution
</h2>

Quand un ordre entrant s’apparierait avec de la liquidité en carnet appartenant au même propriétaire, l’appariement est supprimé au lieu d’être exécuté. Le côté qui cède est configurable :

| Mode                    | Comportement                                             |
| ----------------------- | -------------------------------------------------------- |
| **Expiration du taker** | L’ordre entrant est annulé                               |
| **Expiration du maker** | L’ordre en carnet est annulé et l’ordre entrant poursuit |
| **Expiration des deux** | Les deux sont annulés                                    |

Les makers annulés de cette façon sont collectés pendant l’appariement et retirés dans le même bloc, de sorte que le carnet ne porte pas un ordre déjà supprimé.

Pour ce contrôle, la propriété se résout au niveau de compte que suit le carnet. Voir [Prévention de l’auto-exécution](/fr/trading/self-trade-prevention) pour la vue côté trading.

<h2 id="what-matching-does-not-do">
  Ce que l’appariement ne fait pas
</h2>

Il ne calcule pas les frais, ne réalise pas de P\&L, n’ajuste pas les positions et ne contrôle pas la marge. Tout cela se produit après l’appariement, dans la [chambre de compensation](/fr/protocol/architecture/clearinghouse), à partir des exécutions que l’appariement a produites.

Il ne décide pas non plus si un ordre avait le droit d’exister. La suffisance de marge, les limites d’ordres ouverts, les contraintes reduce-only et la conversion des ordres au marché en ordres limités sont réglées avant qu’un ordre n’atteigne le carnet. Quand le moteur voit un ordre, la seule question est de savoir où il se place dans le carnet.

<h2 id="where-to-go-next">
  Pour aller plus loin
</h2>

<CardGroup cols={2}>
  <Card title="Chambre de compensation" href="/fr/protocol/architecture/clearinghouse">
    Ce qui arrive aux soldes et aux positions une fois les exécutions produites.
  </Card>

  <Card title="Types d’ordres" href="/fr/trading/order-types">
    La vue côté trading : ce que vous pouvez soumettre et comment chaque type se comporte.
  </Card>

  <Card title="Carnet d’ordres" href="/fr/trading/order-book">
    La profondeur, les niveaux, et la lecture du carnet en tant que trader.
  </Card>

  <Card title="IntentionKernel" href="/fr/protocol/architecture/kernel">
    Où se place l’appariement dans l’exécution du bloc.
  </Card>
</CardGroup>