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

# Identifiant client d’ordre

> Attacher votre propre identifiant à un ordre, pour l’annuler et le rapprocher au moyen d’une valeur que vous avez choisie plutôt que d’une valeur attribuée par la chaîne.

Lorsque vous soumettez un ordre, la chaîne lui attribue un identifiant d’ordre. Cet identifiant fait autorité, mais vous ne le connaissez qu’*après* l’acceptation de l’ordre — ce qui pose problème quand ce que vous avez à faire, précisément, c’est annuler un ordre dont vous n’avez jamais vu l’acceptation.

L’identifiant client d’ordre résout cela. Vous générez l’identifiant vous-même, vous l’attachez à la soumission, et vous pouvez agir sur l’ordre par cet identifiant dès l’instant où vous l’envoyez.

<h2 id="why-this-matters-more-than-it-sounds">
  Pourquoi cela compte plus qu’il n’y paraît
</h2>

Prenez une soumission dont le délai d’attente expire. A-t-elle atteint la chaîne ? Vous n’en savez rien. Sans identifiant client d’ordre, vos options sont d’interroger les ordres récents et de deviner d’après le marché, le sens, le prix et la quantité, ou de ne rien faire et d’espérer.

Avec un identifiant, l’ambiguïté disparaît. Vous annulez par l’identifiant que vous avez généré. Si l’ordre existait, il est annulé. S’il n’est jamais arrivé, l’annulation ne trouve rien. Dans les deux cas vous terminez dans un état connu, ce dont un système qui tourne sans humain devant l’écran a réellement besoin.

C’est aussi ce qui rend le rapprochement praticable. Vos propres enregistrements sont indexés sur un identifiant que vous avez attribué : confronter votre vue à celle de la chaîne devient une recherche, et non une heuristique.

## Format

L’identifiant est une **valeur de 16 octets**, soumise sous forme de chaîne hexadécimale en minuscules de 32 caractères, préfixée par `0x`.

```
0xa1b2c3d4e5f6789012345678901234ab
```

Trois règles imposées par le protocole :

* **Minuscules uniquement.** L’hexadécimal en majuscules est rejeté, et non normalisé.
* **Longueur exacte.** Les valeurs plus courtes ou plus longues sont rejetées.
* **La valeur entièrement nulle est réservée.** `0x00000000...0000` est la sentinelle qui signifie *absent* et ne peut pas servir d’identifiant.

Le champ est facultatif. Un ordre qui n’en porte pas se comporte normalement à tous égards — il ne peut simplement pas être annulé par identifiant client d’ordre, seulement par l’identifiant d’ordre attribué par la chaîne.

<h2 id="uniqueness">
  Unicité
</h2>

L’unicité a pour portée le **sous-compte** : la combinaison de l’adresse signataire et du sous-compte qui en dépend.

Deux conséquences en découlent. Des sous-comptes différents sous une même adresse peuvent utiliser le même identifiant sans conflit — pratique lorsque vous faites tourner des stratégies indépendantes qui génèrent chacune leurs identifiants. Et à l’intérieur d’un même sous-compte, réutiliser un identifiant attaché à un ordre encore actif est une erreur, pas un remplacement.

<Note>
  Générez les identifiants aléatoirement plutôt que séquentiellement. Un compteur est tentant parce qu’il rend la séquence lisible, mais un redémarrage qui perd le compteur produit des collisions avec des ordres encore actifs, alors que 16 octets aléatoires n’entrent jamais en collision en pratique.
</Note>

<h2 id="what-you-can-do-with-it">
  Ce que vous pouvez en faire
</h2>

| Opération                                     | Comportement                                                                                              |
| --------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| **Annuler par identifiant client d’ordre**    | Annule l’ordre actif qui porte cet identifiant, sans avoir besoin de l’identifiant attribué par la chaîne |
| **Rechercher par identifiant client d’ordre** | Récupère l’état courant et l’historique de l’ordre                                                        |
| **Rapprocher**                                | Confronter vos propres enregistrements à ceux de la chaîne par un identifiant que vous avez attribué      |

<h2 id="lifetime">
  Durée de vie
</h2>

L’identifiant appartient à l’ordre, pas à votre session. Il reste interrogeable après l’exécution ou l’annulation de l’ordre, et c’est ce qui le rend utile pour le rapprochement a posteriori.

Il redevient réutilisable dès que l’ordre qu’il désignait n’est plus actif. En pratique, il y a peu de raisons de le réutiliser — une nouvelle valeur aléatoire ne coûte rien et supprime toute question sur l’ordre auquel se rapporte un enregistrement historique.

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

<CardGroup cols={2}>
  <Card title="Modifier un ordre" href="/fr/trading/modify-orders">
    Modifier un ordre actif, et ce qu’il advient de ses identifiants.
  </Card>

  <Card title="Types d’ordres" href="/fr/trading/order-types">
    Ce à quoi vous pouvez attacher un identifiant.
  </Card>

  <Card title="Développeurs" href="/fr/developers/overview">
    Soumettre des ordres et traiter les réponses ambiguës dans le code.
  </Card>

  <Card title="Séquencement des transactions" href="/fr/trading/tx-sequencing">
    Pourquoi une annulation soumise dans le même bloc s’exécute avant un ordre agressif.
  </Card>
</CardGroup>
