Diagnostic de connexion
Un diagnostic de connexion est un contrôle par étapes qui éprouve une connexion de données de marché une étape à la fois — passerelle, nom de système, login, souscription et premier tick — et rapporte ce que chacune a mesuré. Il sépare une route refusée d'identifiants refusés, et les deux d'un flux accepté mais simplement silencieux.
Senzoukria · Glossaire · Mis à jour en septembre 2026
Les étapes
| Étape | Question | Ce qu'un succès prouve |
|---|---|---|
| Passerelle joignable | L'URL de la passerelle a-t-elle répondu ? | Le chemin réseau existe ; aucun pare-feu, VPN ou proxy ne l'a bloqué |
| Système reconnu | Cette passerelle dessert-elle le système nommé ? | Le nom de système figure sur la liste en direct de la passerelle |
| Passerelle et système cohérents | La route est-elle correcte ? | Un refus plus bas ne vient pas d'une erreur de route |
| Authentification | Le broker a-t-il accepté le login ? | Les identifiants et le droit d'accès à ce système |
| Souscription aux données | La souscription au symbole a-t-elle été acceptée ? | Le droit aux données de marché pour ce symbole |
| Premier tick reçu | Un tick est-il arrivé dans le délai d'attente ? | La donnée circule maintenant ; un marché calme peut malgré tout échouer ici |
Pourquoi un contrôle par étapes vaut mieux qu'une erreur unique
Des refus identiques à l'écran ont eu des causes différentes : une mauvaise passerelle, un nom de système qui a changé de place, un mot de passe expiré, un droit aux données absent, un contrat échu qui accepte encore les souscriptions. Un diagnostic qui s'arrête à la première étape en échec et nomme ce qu'il a mesuré transforme un vague « login refusé » en un fait exploitable par le support ou le fournisseur. Le guide Rithmic liste à part les points à confirmer côté compte : nom de système, applications tierces autorisées, disponibilité de la profondeur et de l'historique, limites de session et permissions de routage.
Dans Senzoukria
L'écran des connexions comporte un « Diagnostic de connexion » avec un bouton « Lancer le diagnostic », un bouton « Relancer » et « Copier le résultat ». Chaque étape rapporte l'un des trois états — réussie, échouée, ou « Non exécuté » avec sa raison, par exemple « Non exécuté — aucun mot de passe enregistré sur cette connexion ». Sa note énonce la méthode : il rapporte ce qu'il a mesuré et liste les causes possibles par fréquence ; il n'en désigne jamais une comme certaine.
Quand toutes les étapes passent mais qu'aucun tick n'arrive, le diagnostic affiche « Tout a été accepté, aucune donnée n'arrive » et liste les causes, les plus fréquentes d'abord : le marché est fermé pour ce contrat, le symbole n'est plus l'échéance de référence, et d'autres encore. La copie du résultat est faite pour être collée dans une demande au support, avec l'intervalle demandé.
Erreurs fréquentes
- Changer d'indicateurs ou réinstaller l'application avant d'avoir lancé le diagnostic.
- Lire une souscription acceptée comme une preuve de couverture historique : l'historique est un droit distinct.
- Lancer le contrôle un week-end et conclure que le compte est cassé parce qu'aucun tick n'est arrivé.
- N'envoyer au support que le verdict final plutôt que le résultat copié étape par étape.
Voir aussi
- État du flux
- Stockage des identifiants dans le trousseau
- Logiciel footprint pour Rithmic
- Bridge orderflow Quantower
Cette page dans d’autres langues
Questions fréquentes
- Le diagnostic passe toutes les étapes mais le graphique reste vide. Pourquoi ?
- Une souscription acceptée prouve une permission, pas une activité. Le contrat peut être hors séance, ou le symbole peut être une échéance expirée qui accepte encore les souscriptions sans rien traiter. Vérifiez d'abord l'horaire de séance et l'échéance de référence ; le diagnostic liste ces causes par fréquence sans en affirmer aucune.
- Le diagnostic s'applique-t-il à une connexion par bridge ?
- Les contrôles de passerelle, de système et de login concernent les connexions directes. Un bridge NinjaTrader ou Quantower se contrôle autrement : l'indicateur du bridge doit tourner sur un graphique, le port local doit être libre, et l'historique annoncé par le bridge doit correspondre à celui reçu. Le guide Quantower donne la commande PowerShell qui confirme l'écoute du port.