NinjaTrader 8 lent ou avec les bougies gelées : pourquoi ça arrive, ce que ça vous coûte et comment le résoudre
Si votre NinjaTrader 8 est devenu lent, que les bougies cessent de se mettre à jour en plein marché ou que la plateforme se ferme toute seule, le problème ne vient très probablement ni de votre connexion ni de votre ordinateur : il est dans la base de données interne de NinjaTrader. Et ce n'est pas une gêne technique — c'est un risque financier mesurable.
Dans ce guide, nous expliquons, avec la documentation officielle et des études évaluées par des pairs, pourquoi cela arrive, ce que cela vous coûte vraiment, ce que vous pouvez faire vous-même et comment éviter que cela se reproduise.
Qu'est-ce que la base de données de NinjaTrader et pourquoi elle se dégrade
NinjaTrader 8 enregistre vos ordres, exécutions, positions et historique de prix dans une base de données SQLite locale (dossier Documents\NinjaTrader 8\db). SQLite est fiable sur des milliards de déploiements, mais sa propre documentation énumère les conditions exactes qui la corrompent[1] — et plusieurs sont habituelles dans un environnement de trading intensif.
Pourquoi NinjaTrader 8 est particulièrement vulnérable
| Condition (SQLite officiel) | Présente dans le trading réel |
|---|---|
| Verrouillage de fichier défectueux / accès concurrent | Plusieurs instances ou comptes partagent les mêmes fichiers en même temps |
Échec de fsync (le disque « ment » sur l'écriture) | Volume d'ordres élevé : des milliers d'écritures par session |
| Arrêt ou plantage au milieu d'une transaction | Chutes de flux, reconnexions, fermetures forcées |
| Sauvegarde pendant une transaction active | Outils qui copient le dossier avec NinjaTrader ouvert |
fsync() est grande — précisément le profil d'un copieur multi-compte qui émet des milliers d'ordres par jour.Symptômes : comment savoir si c'est votre base de données
- Les bougies restent immobiles alors que le prix dans le DOM bouge bien.
- Ouvrir un graphique ou changer d'instrument prend bien plus de temps qu'avant.
- NinjaTrader consomme de plus en plus de mémoire et avance « par à-coups ».
- Fermetures inattendues, surtout au démarrage ou au chargement des données.
La chaîne causale : du fichier à la perte
Le dommage suit une séquence mécanique et reproductible :
| # | Maillon | Ce qui se passe |
|---|---|---|
| 1 | BD corrompue ou énorme | Erreurs de données (ID dupliqués) ou fichier endommagé ; lectures lentes |
| 2 | La plateforme recharge la BD sur le thread de l'écran | À la reconnexion du flux, le graphique tente de recharger les exécutions depuis la BD |
| 3 | Blocage | Le thread de l'écran se bloque ; les bougies s'arrêtent, l'opérationnel continue sur un autre thread |
| 4 | Exécution endommagée | Ordres tardifs, dupliqués ou impossibles ; position non gérée |
| 5 | Perte financière | Slippage, position piégée, risque sans stop |
Ce n'est pas une gêne technique : c'est un risque financier mesurable
Un blocage, c'est au fond une latence extrême. Et la latence a un coût quantifié par la littérature académique.
Si 500 ms représentent déjà un coût substantiel, un blocage de secondes ou de minutes transforme ce coût en une perte de premier ordre. Et cela arrive justement quand le marché est le plus volatil — c'est-à-dire quand le flux tombe et que la BD est sous tension.
Une étude du Journal of Financial Economics (2022) sur les pannes de courtiers documente en outre que, quand votre plateforme vous bloque, vous perdez le contrôle de votre risque au pire moment ; ce n'est pas une anecdote, c'est un effet mesuré à l'échelle du marché[3].
Comment cela se traduit dans votre P&L
| Dommage | Effet sur votre compte |
|---|---|
| Slippage dû au blocage | Pire prix d'entrée/sortie sur chaque opération concernée |
| Position piégée | Perte du côté adverse tant que vous ne pouvez pas fermer |
| Ordres dupliqués / fantômes | Exposition non souhaitée, position inversée |
| Données historiques corrompues | Backtests et statistiques mal calculés → décisions erronées |
| Enregistrements erronés | Litiges avec les prop firms, erreurs fiscales/comptables |
Solutions manuelles (et pourquoi elles ne suffisent pas)
- Réduire l'historique que vous conservez (moins de jours de données à la main).
- Sauvegarder votre dossier NinjaTrader avant de toucher à quoi que ce soit.
- Compacter ou reconstruire la base de données en suivant la documentation officielle[5].
Le problème, c'est que cela est manuel, occasionnel et risqué : il faut y penser, choisir le moment (marché fermé) et une mauvaise manœuvre peut vous laisser sans historique. La plupart ne réagissent que lorsque quelque chose est déjà cassé.
La façon d'éviter que cela se reproduise : automatiser la maintenance
Plutôt que d'éteindre des incendies, la solution durable est que la maintenance se fasse toute seule, en arrière-plan et au bon moment. C'est pour cela que nous avons créé TSD DB Guardian, un programme externe à NinjaTrader qui s'occupe de la santé de sa base de données sans que vous ayez rien à faire :
- Détecte la corruption et la croissance excessive en continu.
- Sauvegarde avec une copie vérifiée avant d'agir.
- Répare quand il le faut et attend le marché fermé pour ne pas gêner votre opérationnel.
- Laisse un rapport d'audit signé de chaque intervention.
Il fonctionne de façon programmable (hebdomadaire, tous les 15 ou tous les 30 jours) et comprend un bouton d'urgence pour lancer la maintenance instantanément. C'est un logiciel Windows qui coexiste avec NinjaTrader 8 ; ce n'est pas un module qui se charge à l'intérieur de la plateforme.
Arrêtez de vous battre avec la base de données de NinjaTrader
Essayez TSD DB Guardian 14 jours gratuits, avec toutes les fonctions et sans carte.
Voir TSD DB Guardian Essayer gratuitement 14 jours
Questions fréquentes
Vais-je perdre mon historique de données en réparant la base ?
Non, si c'est fait avec une sauvegarde préalable. DB Guardian sauvegarde toujours avant d'agir ; si vous le faites manuellement, faites la copie vous-même d'abord.
Dois-je arrêter de trader pour faire la maintenance ?
Non. DB Guardian attend le marché fermé et travaille en arrière-plan. La maintenance manuelle, elle, vaut mieux la faire avec la plateforme fermée.
Est-ce un indicateur NinjaTrader ?
Non. C'est un programme Windows indépendant qui coexiste avec NinjaTrader 8 et s'occupe de sa base de données depuis l'extérieur.
Pourquoi se fige-t-il justement dans les moments de plus grand mouvement ?
Parce que la volatilité amène plus d'ordres, plus d'écritures et plus de reconnexions de flux — les conditions exactes qui stressent la base de données SQLite et déclenchent le rechargement sur le thread de l'écran.
Références
- SQLite. How To Corrupt An SQLite Database File. sqlite.org/howtocorrupt.html
- Moallemi, C. C., & Saglam, M. (2013). The Cost of Latency in High-Frequency Trading. Operations Research, 61(5).
- Retail trader sophistication and stock market quality: Evidence from brokerage outages. Journal of Financial Economics (2022).
- NinjaTrader Support Forum. Issue with Order Flow Market Depth Map Freezing Platform — significant loss incurred.
- NinjaTrader Help Guide. Operations > Database Operations (Reset DB / Repair DB).