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

# Préconfirmations : Le Signal de Transaction le Plus Précoce sur Solana

> Diffusez les transactions Solana avant qu'elles ne soient fragmentées — préconfirmations Helius avec statut d'exécution, plus Jito BAM, dans un abonnement WebSocket unique.

<Tip>
  **Utilisez [Sender Max](/docs/fr/sending-transactions/sender-max) (pourboire min : 0,001 SOL) pour
  agir sur les préconfirmations.** Une préconfirmation ne rapporte que si vous réalisez votre
  transaction
  en premier — Sender Max est le moyen le plus rapide de le faire. Construisez sur Sender Max dès le
  début pour tirer pleinement parti des préconfirmations.
</Tip>

## Vue d'ensemble

Les préconfirmations diffusent les transactions dès le point le plus précoce où elles peuvent être observées — **avant** qu'elles ne soient collectées en entrées et converties en fragments. C’est le signal de transaction à la latence la plus faible que Helius propose — plus tôt que [Shred Delivery](/docs/fr/shred-delivery/raw-shreds) et que les flux d'engagement traités.

Vous vous abonnez via un WebSocket avec la méthode `preconfSubscribe` et recevez chaque transaction au fur et à mesure qu’elle se produit. Le flux combine deux sources, toutes deux incluses par défaut, qui émettent à différents points du pipeline :

* **Préconfirmations Helius** de validateurs qui transmettent à Helius. Émis à l'instant où le leader **exécute** la transaction, avec son statut d'exécution — le premier moment où le résultat existe quelque part.
* **[Préconfirmations BAM](#préconfirmations-bam)** de validateurs exécutant le client Block Assembly Marketplace (BAM) de Jito. Émis lorsque le validateur **s'engage à exécuter** la transaction, avant qu'elle ne soit exécutée — ils ne contiennent donc pas de statut d'exécution.

<Note>
  Les préconfirmations sont servies depuis le point de terminaison Helius [Gatekeeper](/docs/fr/gatekeeper/overview)
  `wss://beta.helius-rpc.com`. Le nom d'hôte `beta` fait référence au
  déploiement de Gatekeeper, pas à la maturité des préconfirmations — il deviendra le
  point de terminaison standard à mesure que le trafic migre vers Gatekeeper.
</Note>

<CardGroup cols={2}>
  <Card title="Latence la Plus Basse" icon="bolt">
    Les transactions sont livrées avant les fragments et les flux d’engagement traités
  </Card>

  <Card title="Streaming WebSocket" icon="tower-broadcast">
    Abonnez-vous une fois avec `preconfSubscribe` et recevez Helius et BAM
    préconfirmations dans un flux unique
  </Card>

  <Card title="Tarification Basée sur le Crédit" icon="coins">
    Plan professionnel ou supérieur ; 10 crédits par message (chaque transaction diffusée)
  </Card>

  <Card title="Conçu pour les Traders" icon="chart-line">
    Réagissez à l'activité onchain avant qu'elle n'atterrisse, pour propAMMs, snipers, copy
    traders et bots de liquidation
  </Card>
</CardGroup>

## Positionnement des Préconfirmations dans le Pipeline

Une transaction passe par plusieurs étapes à l'intérieur d'un validateur avant qu'elle ne soit enregistrée sur la chaîne. La latence augmente de gauche à droite — plus vous observez loin à droite, plus vous apprenez tardivement la transaction.

<Frame caption="Les préconfirmations livrent les transactions avant les fragments et les flux d’engagement traités.">
  <img src="https://mintcdn.com/helius/8YmEB-0rF0Db0-AR/images/pre-confirmations-latency.png?fit=max&auto=format&n=8YmEB-0rF0Db0-AR&q=85&s=40a2de7b866c2e5f65f1009914b64bc1" alt="Flux de latence des transactions à l'intérieur d'un validateur : User Tx à TPU à Scheduler à Preconf (transaction planifiée) à Shreds, avec une latence croissante de gauche à droite." width="1024" height="244" data-path="images/pre-confirmations-latency.png" />
</Frame>

Les préconfirmations Helius sont émises depuis l'étape **d'exécution** — au moment où le leader exécute la transaction et son statut est connu, mais avant que le résultat ne soit enregistré dans une entrée et transformé en fragments. C'est le premier point du cycle de vie où le résultat d'une transaction existe et peut être rapporté.

Les préconfirmations BAM sont émises une étape plus tôt, lorsque le validateur s'engage à exécuter la transaction mais avant qu'elle n'ait été exécutée. Les deux arrivent avant que la transaction ne soit fragmentée, ce qui les rend strictement de latence inférieure à la livraison basée sur les fragments pour la même transaction.

## Préconfirmations BAM

[BAM (Block Assembly Marketplace)](https://bam.dev/docs/bam/bam-overview/) est le système de construction de blocs de Jito pour Solana. Les validateurs exécutant des clients compatibles BAM émettent une préconfirmation dès qu'ils s'engagent à exécuter une transaction. Helius les ingère des points de terminaison régionaux BAM de Jito et les délivre par le même abonnement `preconfSubscribe` et charge utile binaire que les préconfirmations Helius. Au lancement, BAM a ajouté une couverture de validateurs représentant plus de 34 % des mises en réseau.

Les préconfirmations BAM suivent le même format de charge utile mais diffèrent par quelques champs :

* **`status` est toujours `2` (inconnu).** BAM ne rapporte pas le statut d'exécution, donc seules les préconfirmations Helius vous indiquent si une transaction a réussi ou échoué. Si votre stratégie dépend du statut d'exécution, définissez `includeBam: false` ou vérifiez le statut vous-même.
* `tx_index` est toujours `0`. BAM ordonne les transactions par ID de séquence et position de paquet plutôt que par index de créneau ; aucun ne correspond au champ Helius, et aucun n'est transmis sur le flux. Voir [Différencier les deux sources](/docs/fr/pre-confirmations/preconf-subscribe#distinguer-les-deux-sources).
* `regionInclude` correspond au point de terminaison BAM régional qui a émis la préconfirmation, pas à la région Helius qui l'a ingérée.
* Une petite part des transactions parviennent à Helius par les deux sources, donc la même signature peut arriver deux fois. Voir [Notifications en double](/docs/fr/pre-confirmations/preconf-subscribe#notifications-en-double).

Pour recevoir uniquement les préconfirmations Helius, passez `includeBam: false` dans le [filtre d'abonnement](/docs/fr/pre-confirmations/preconf-subscribe#filtrage).

## Quand utiliser les Préconfirmations

<CardGroup cols={2}>
  <Card title="Bonne adéquation" icon="circle-check">
    propAMMs, snipers, copy traders et bots de liquidation — toute stratégie qui
    doit réagir à une transaction aussi tôt que physiquement possible.
  </Card>

  <Card title="Envisager des alternatives" icon="circle-info">
    Pour des données historiques complètes ou confirmées, utilisez [LaserStream](/docs/fr/laserstream) ou
    [WebSockets améliorés](/docs/fr/rpc/websocket/transaction-subscribe). Pour les données brutes du réseau,
    voir [Shred Delivery](/docs/fr/shred-delivery/raw-shreds).
  </Card>
</CardGroup>

<Warning>
  Une préconfirmation est un signal précoce, pas une garantie. La transaction n’a pas
  encore atterri sur la chaîne et pourrait encore être abandonnée — et le statut d'exécution d'une préconfirmation Helius reflète le résultat local du leader, qui n'est pas définitif tant que le bloc n'est pas confirmé. Confirmez l'atterrissage via des contrôles d'engagement standards
  avant de le considérer comme final.
</Warning>

## Tarification

Les préconfirmations nécessitent un **plan professionnel ou supérieur** et coûtent **10 crédits par message** — un message par transaction diffusée — facturé à partir de votre plan. Voir [Crédits](/docs/fr/billing/credits) pour plus de détails.

<Note>
  Les préconfirmations sont un nouveau produit et les prix peuvent changer.
</Note>

## Couverture

Les préconfirmations ne sont disponibles que pour les transactions planifiées par des validateurs qui transmettent leur flux à Helius ou exécutent un client compatible BAM. La couverture évolue avec la part des mises en réseau couvertes par ces deux sources, donc le flux n'est **pas continu**. Le réglage `includeBam: false` limite la couverture aux validateurs qui transmettent directement vers Helius.

<Warning>
  Attendez-vous à des lacunes. Pendant les créneaux dont le leader n'est couvert par aucune source, vous ne recevrez aucun message de préconfirmation pour ce créneau. Concevez votre intégration pour tolérer ces lacunes — ne supposez pas un flux ininterrompu et recourir à d'autres signaux tels que [LaserStream](/docs/fr/laserstream) ou [Shred
  Delivery](/docs/fr/shred-delivery/raw-shreds) lorsque vous avez besoin d'une couverture continue.
</Warning>

La couverture augmente à mesure que davantage de validateurs transmettent à Helius. Si vous exploitez un validateur, vous pouvez [aider à combler ces lacunes et générer des revenus](/docs/fr/pre-confirmations/for-validators).

## Pour les validateurs

Exploitez-vous un validateur ? Vous pouvez générer des revenus en transmettant votre flux de préconfirmation à Helius — et améliorer la couverture pour tous ceux qui consomment des préconfirmations.

<Card title="Validateurs : gagnez en envoyant des préconfirmations" icon="server" href="/docs/fr/pre-confirmations/for-validators">
  Découvrez comment commencer à transmettre des préconfirmations et générer des revenus.
</Card>

## Étapes suivantes

<CardGroup cols={2}>
  <Card title="Référence preconfSubscribe" icon="code" href="/docs/fr/pre-confirmations/preconf-subscribe">
    Abonnement, format de message et exemple complet de WebSocket.
  </Card>

  <Card title="Helius Sender" icon="rocket" href="/docs/fr/sending-transactions/sender">
    Associez les préconfirmations à Sender pour agir sur ce que vous voyez avec l'atterrissage le plus rapide.
  </Card>
</CardGroup>
