Carnet d’ordres ou pool de liquidité : comment un prix de transaction se forme

Un prix affiché n’est pas une promesse d’exécution

Une interface peut montrer le dernier échange, le meilleur prix demandé par un vendeur ou une estimation interne. Ces informations ne sont pas équivalentes. Pour savoir ce qu’une transaction pourrait produire, il faut identifier le mécanisme utilisé et les quantités réellement disponibles.

Cet article explique deux modèles techniques : le carnet d’ordres et le pool automatisé. Leur présentation ne signifie pas qu’un token immobilier particulier puisse légalement ou techniquement circuler sur l’un d’eux. Restrictions de transfert, qualification de l’instrument et règles de la plateforme restent déterminantes.

Le carnet rapproche des intentions d’achat et de vente

Dans un carnet, les acheteurs proposent des prix et des quantités ; les vendeurs font de même. Le meilleur prix acheteur est le plus élevé actuellement proposé à l’achat. Le meilleur prix vendeur est le plus bas demandé à la vente. Leur différence est l’écart achat-vente, souvent appelé spread.

Si le meilleur acheteur propose 98 € et le meilleur vendeur demande 102 €, l’écart est de 4 €. Cela ne signifie pas qu’une transaction aura lieu à 100 €. Ce milieu est un repère arithmétique ; personne n’est nécessairement disposé à échanger à ce prix.

Un ordre limité fixe une condition de prix, mais peut rester inexécuté. Un ordre au marché cherche les contreparties disponibles sans garantir le prix final. Investor.gov expose cette distinction pour les marchés de titres ; son application pratique dépend ensuite des fonctionnalités et règles du lieu d’échange considéré.

La profondeur compte plus que la première ligne

La quantité disponible au meilleur prix peut être minime. Vendre davantage oblige alors à rencontrer des ordres moins favorables, si le mécanisme et les limites de l’ordre le permettent. La profondeur désigne cette disponibilité à plusieurs niveaux de prix.

Des ordres peuvent être modifiés ou retirés avant l’exécution. Une capture du carnet est donc une photographie à un instant donné. Elle ne prouve pas que le même montant sera échangeable demain ni qu’un volume affiché sera réellement exécuté.

Exemple fictif : vendre plus que la meilleure quantité

Un carnet comporte trois offres d’achat : 20 tokens à 100 €, 30 à 98 € et 50 à 95 €. Un vendeur cède 70 tokens en rencontrant ces ordres, sans frais ni autre changement.

Il reçoit 2 000 € pour les vingt premiers, 2 940 € pour les trente suivants et 1 900 € pour les vingt derniers. Total : 6 840 €, soit environ 97,71 € par token. Le meilleur prix initial était pourtant 100 €.

Un ordre de vente limité à 99 € n’aurait rencontré, dans cette photographie, que les vingt tokens proposés à 100 €. Le reste serait resté en attente ou aurait été annulé selon les modalités de l’ordre. Le prix protégé et l’exécution intégrale sont deux objectifs différents.

Un pool utilise des réserves et une formule

Un pool automatisé détient deux actifs et détermine les conditions d’échange par un algorithme. Dans le modèle pédagogique à produit constant, le produit des deux réserves reste constant avant prise en compte des frais. L’achat d’un actif réduit sa réserve et augmente celle de l’autre, ce qui modifie le prix marginal.

La documentation Uniswap explique ce principe ainsi que les mécanismes de liquidité concentrée de versions plus récentes. Il serait donc incorrect de supposer que tous les pools fonctionnent comme le modèle élémentaire présenté ici. Cette documentation est celle d’un fournisseur de protocole : elle décrit son mécanisme, pas une garantie de sécurité.

Exemple fictif : la taille de l’achat modifie son prix

Un pool simplifié contient 1 000 tokens et 100 000 unités monétaires. Son produit est 100 000 000 et le rapport initial des réserves vaut 100 unités par token. Un acheteur ajoute 10 000 unités monétaires, sans frais.

La réserve monétaire atteint 110 000. Pour conserver le produit, la réserve de tokens devient environ 909,09. L’acheteur reçoit donc environ 90,91 tokens : son prix moyen est 110 unités par token, et non le rapport initial de 100.

Cet exercice abstrait ne décrit aucune offre immobilière accessible. Il montre simplement pourquoi une opération importante par rapport aux réserves déplace le prix. Un pool ne crée pas gratuitement une capacité de sortie illimitée.

Sépare impact de prix, frais et variation en cours d’exécution

L’impact de prix vient de l’effet de ton échange sur les disponibilités. Les frais rémunèrent ou financent différents intervenants selon le système. Une variation entre le devis et l’exécution peut encore s’ajouter si le marché évolue ou si d’autres transactions passent avant la tienne.

Une tolérance de glissement limite certaines conditions d’exécution dans certains outils. Elle ne supprime ni le risque économique ni les restrictions du token. Les procédures de règlement, les interruptions et les contrôles d’identité peuvent également empêcher une opération pourtant imaginable dans un calcul.

À retenir

• Identifie ce que mesure le prix affiché.
• Compare la quantité souhaitée à la profondeur ou aux réserves.
• Un ordre limité peut protéger un prix sans garantir une exécution.
• Un pool automatise une formule ; il ne garantit pas la liquidité d’un actif immobilier.
• Vérifie séparément droits de transfert, lieu d’échange, frais et règlement.

Information générale

Exemples fictifs destinés à expliquer la microstructure. Aucune recommandation d’utiliser une plateforme ou un protocole. L’accès et la négociabilité d’un instrument doivent être vérifiés dans son cadre juridique et contractuel.

Tout investissement comporte un risque de perte en capital.

Sources

• Investor.gov — Types of Orders : ordres au marché et à cours limité.
• Uniswap Developers — How Uniswap Works : réserves, invariant et liquidité concentrée.
• Uniswap Labs — What is price impact? : effet de la taille de l’échange sur le prix.

Sources consultées le 28 octobre 2026.