> ## 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. # Transactions Prétraitées : Données Solana Pré-exécution Sans Déchiquetage > Diffusez des transactions Solana pré-exécution avant qu'elles n'atteignent l'engagement traité. Helius gère le décodage des shreds — vous recevez des transactions signées via WebSocket. ## Vue d'ensemble Les transactions prétraitées sont des transactions Solana pré-exécution livrées **avant qu'elles n'atteignent le niveau d'engagement `processed`**. Helius agrège plusieurs sources de pré-exécution — principalement des shreds décodés directement à leur arrivée au validateur, complétés par des signaux de [préconfirmation](/docs/fr/pre-confirmations/overview) — et les livre sous la forme d'un flux unique dédupliqué, sans paquets de shreds bruts à recevoir ni infrastructure de déchiquetage à opérer de votre côté. Les transactions provenant de signaux de préconfirmation arrivent plus tard sur ce flux que sur le produit dédié aux [préconfirmations](/docs/fr/pre-confirmations/overview), qui reste le premier accès à celles-ci. La méthode pour consommer des transactions prétraitées est la méthode [`preprocessedSubscribe` WebSocket](/docs/fr/preprocessed-transactions/preprocessed-subscribe) (Bêta Publique) — disponible sur **tous les plans payants** à **0,1 crédit par message**. La façon recommandée de diffuser des transactions prétraitées : filtrage par compte, charges utiles binaires compactes, tous les plans payants. ## Où se situent les transactions prétraitées dans le cycle de vie Dans l'architecture de Solana, les transactions passent par plusieurs étapes avant d'être entièrement traitées : 1. **Réception des shreds** → Le validateur reçoit des shreds de transaction (fragments de données). ← **[Shreds bruts (UDP)](/docs/fr/shred-delivery/raw-shreds)** sont livrés ici. 2. **Décodage des shreds** → Les shreds sont décodés en transactions brutes. ← **Les transactions prétraitées sont principalement livrées ici.** 3. **Exécution de la transaction** → La transaction est exécutée par le runtime. 4. **Génération de métadonnées** → Pré/post soldes, journaux, et informations d'erreur sont calculés. 5. **Engagement** → La transaction atteint un état traité/confirmé/finalisé. ← **[LaserStream gRPC](/docs/fr/laserstream)** et **[LaserStream WebSocket](/docs/fr/rpc/websocket)** livrent ici. Les abonnements post-exécution livrent des données à l'étape 5 — après l'exécution complète et la génération de métadonnées. Les transactions prétraitées sont livrées au moment de l'étape 2 — après le décodage des shreds, avant que l'exécution ne soit terminée. Pour un signal encore plus précoce, les [préconfirmations](/docs/fr/pre-confirmations/overview) diffusent des transactions avant qu'elles ne deviennent des shreds. **Le compromis :** vous recevez les données de transaction plus tôt, mais sans métadonnées d'exécution comme les changements de solde, les journaux ou les informations d'erreur. **Ceci est un flux de transactions uniquement.** Les mises à jour de l'état des comptes et des programmes n'existent pas tant que le runtime n'exécute pas la transaction. Si vous avez besoin de mises à jour en temps réel des comptes ou des programmes — soldes de jeton, état de la courbe de liaison, comptes de programme — utilisez plutôt **[LaserStream gRPC](/docs/fr/laserstream) à l'engagement `processed`**. ## Quelles données sont disponibles ? Les transactions prétraitées incluent la transaction signée complète, mais n'ont pas de métadonnées d'exécution : ### Données disponibles * ✅ **Signature de la transaction** - Identifiant unique de la transaction * ✅ **Clés de compte** - Tous les comptes référencés par la transaction * ✅ **Instructions** - Données d'instruction complètes et appels de programmes * ✅ **Bloc récent** - Référence d'expiration de la transaction * ✅ **Signatures** - Toutes les signatures de la transaction * ✅ **Numéro de slot** - Dans quel slot la transaction a été observée ### Données manquantes * ❌ **Métadonnées de la transaction** - Changements de solde de jeton, pré/post soldes, statut de la transaction * ❌ **Erreurs de la transaction** - Nous ne pouvons pas déterminer si la transaction a échoué * ❌ **Instructions internes** - Les invocations inter-programmes (CPI) ne sont pas incluses * ❌ **Messages de journal** - Les journaux de programme sont générés pendant l'exécution * ❌ **Unités de calcul consommées** - Métriques d'exécution indisponibles Pensez aux transactions prétraitées comme la réception de la "proposition" sans le "résultat." Vous voyez ce que l'expéditeur a essayé de faire, mais pas ce qui s'est réellement produit. ## Garanties de livraison La livraison est une meilleure pratique, non garantie, et il n'y a pas de relecture historique. Une transaction diffusée est un signal pré-exécution, pas un niveau d'engagement — elle peut échouer, être abandonnée, ou atterrir sur une branche différente. Dédupliquez par signature et conciliez avec un flux traité ou confirmé lorsque les résultats d'exécution comptent. Pour les applications critiques nécessitant une livraison garantie et des données complètes, utilisez plutôt [LaserStream gRPC](/docs/fr/laserstream). ## Quand utiliser les transactions prétraitées Applications sensibles à la latence qui veulent des transactions décodées, pré-exécution sans opérer un décodeur de shreds : * propAMMs * Snipers * Traders mimétiques * Bots de liquidation * Arbitrage Si chaque microseconde compte et que vous pouvez déchiqueter à vitesse de ligne, utilisez [shreds bruts (UDP)](/docs/fr/shred-delivery/raw-shreds). Si vous avez besoin du signal le plus précoce possible, utilisez les [préconfirmations](/docs/fr/pre-confirmations/overview). ## Tarification [`preprocessedSubscribe`](/docs/fr/preprocessed-transactions/preprocessed-subscribe) est disponible sur **tous les plans payants** et mesuré à **0,1 crédit par message** — un message par transaction livrée. Voir [Crédits](/docs/fr/billing/credits) pour plus de détails. ## FAQs Non, le filtre est fixé par l'initialisation `preprocessedSubscribe`. Pour éviter un écart, nous recommandons d'ouvrir une seconde connexion avec le nouveau filtre, d'attendre la confirmation de l'abonnement, puis de transférer votre service vers le nouveau filtre. La limite de 10 connexions simultanées est appliquée par clé API. Chaque clé API dans un projet bénéficie de sa propre limite de 10 connexions. ## Prochaines étapes Point de terminaison, filtrage de compte, disposition de la charge utile binaire, et exemples de code. Transactions diffusées avant qu'elles ne deviennent des shreds — le signal de transaction le plus précoce. Paquets de shreds non traités via UDP. Vous implémentez le déchiquetage. Agissez sur ce que vous voyez avec l'atterrissage de transaction le plus rapide.