---
url: https://docs.ogmabox.com/fr/app/ws-replay.md
description: >-
  Se reconnecter aux points de terminaison WebSocket, modifier les trames et
  renvoyer les messages capturés dans Ogma.
---

# Rejeu WebSocket {#websocket-replay}

L’outil Rejeu WebSocket crée des sessions réutilisables pour tester les points de terminaison WebSocket. Utilisez-le pour vous reconnecter avec les détails de négociation capturés, modifier des messages, envoyer de nouvelles trames et observer les réponses du serveur.

## Créer une session {#creating-a-session}

Vous pouvez créer une session Rejeu WebSocket de deux façons :

* Faites un clic droit sur un message WebSocket capturé dans **Historique WS / SSE** et choisissez **Envoyer au rejeu WebSocket**.
* Ouvrez **Rejeu WebSocket** et créez une session manuellement avec une URL `ws://` ou `wss://`.

Les sessions manuelles peuvent inclure des en-têtes personnalisés pour les cookies, les jetons d'autorisation, la négociation du protocole ou les valeurs de négociation propres à l'application.

## Configurer une session {#session-setup}

| Champ | Description |
| --- | --- |
| Nom | Libellé de session lisible. |
| URL | Point de terminaison WebSocket. L'URL doit commencer par `ws://` ou `wss://`. |
| En-têtes | En-têtes de négociation facultatifs, envoyés lors de la connexion. |

Si vous modifiez l'URL ou les en-têtes, Ogma enregistre la session avant d'ouvrir la connexion suivante.

## Se connecter {#connecting}

Sélectionnez une session et cliquez sur **Connecter**. L'état de la connexion indique si le socket est déconnecté, en cours de connexion, ouvert, en cours de fermeture ou fermé.

Utilisez **Déconnecter** avant de changer de cible ou de modifier les détails de négociation. Reconnectez-vous après avoir modifié l'URL ou les en-têtes pour tester un nouveau chemin serveur ou un nouveau contexte authentifié.

La connexion ne fait qu'effectuer la négociation WebSocket. De nombreuses applications exigent ensuite une trame d'authentification ou d'initialisation avant d'accepter des messages métier. Utilisez le premier message client capturé comme référence, attendez son accusé de réception, puis envoyez votre message modifié. Les cookies, les URL signées et les jetons capturés peuvent avoir expiré.

## Envoyer des messages {#sending-messages}

Utilisez l'éditeur de messages pour modifier une charge utile et l'envoyer via la session sélectionnée. Les charges utiles textuelles sont envoyées sous forme de trames WebSocket de texte.

Passez en mode binaire pour saisir des octets hexadécimaux. **Rejouer le premier message WebSocket capturé** permet de renvoyer le message d'initialisation, et **Rejouer la séquence sortante capturée** envoie les messages client capturés dans l'ordre. Vérifiez les réponses dans la chronologie plutôt que de supposer que l'envoi d'une séquence a recréé l'état de l'application.

L'éditeur de protocole prend en charge les modes WebSocket brut et GraphQL gérés (`graphql-transport-ws` et l'ancien `graphql-ws`). Choisissez le protocole utilisé par la cible et fournissez ses paramètres de connexion. Conservez l'en-tête de sous-protocole d'origine lorsque c'est nécessaire ; demander un protocole incorrect peut faire échouer le passage à WebSocket.

**Actualiser les horodatages** est désactivé par défaut. Activez-le uniquement pour les requêtes non signées qui nécessitent des horodatages récents : modifier une URL ou une charge utile signée peut invalider sa signature. **Reconnexion automatique** tente une nouvelle connexion après une déconnexion, mais celle-ci peut encore nécessiter une authentification au niveau applicatif.

Les messages capturés envoyés depuis l'historique conservent leur charge utile d'origine comme point de départ, ce qui permet de modifier un seul champ à la fois et de comparer les comportements.

## Chronologie des messages {#message-timeline}

La chronologie enregistre les trames envoyées et reçues pour la session sélectionnée.

| Colonne | Description |
| --- | --- |
| Sens | Indique si la trame a été envoyée par le client ou reçue du serveur. |
| Code d’opération | Type de trame, comme text, binary, ping, pong ou close. |
| Taille | Taille de la charge utile. |
| Horodatage (Time) | Moment auquel Ogma a observé la trame. |

Sélectionnez un message pour examiner sa charge utile. Les charges utiles JSON sont mises en forme lorsque c'est possible ; le contenu brut reste disponible pour un examen exact.

## Procédure de test {#testing-workflow}

1. Capturez un échange WebSocket normal dans **Historique WS / SSE**.
2. Envoyez un message client intéressant à **Rejeu WebSocket**.
3. Reconnectez-vous et renvoyez le message d'origine pour confirmer le comportement de référence.
4. Modifiez un seul champ, jeton, identifiant ou commande à la fois.
5. Consignez les comportements confirmés dans **Constats** ou gardez des notes dans **Notes**.

## Dépannage {#troubleshooting}

| Symptôme | Points à vérifier |
| --- | --- |
| Passage à WebSocket rejeté ou interdit | URL, Origin, cookies, autorisation et valeurs signées expirées dans la chaîne de requête. |
| Sous-protocole invalide ou non demandé | Comparez En-têtes de négociation avec la négociation capturée et le mode de protocole sélectionné. |
| Connexion établie, puis fermée | Examinez le message système ou de fermeture et envoyez la trame d'initialisation ou d'authentification requise. |
| Message envoyé sans réponse utile | Vérifiez les identifiants d'abonnement, les messages précédents, l'authentification et l'état de l'application ; le transport WebSocket ne recrée pas automatiquement une session de navigateur. |

Avec MCP, utilisez les outils dédiés à la lecture et à la liste des messages Rejeu WebSocket, ainsi qu'à la déconnexion. Les outils d'historique capturé lisent une autre transcription ; consultez [la référence des outils MCP](../reference/mcp-tools.md#websocket-and-sse).

## Pages connexes {#related-pages}

* [Historique WebSocket et SSE](./ws-sse-history.md)
* [Rejeu](./replay.md)
* [Constats](./findings.md)