Une idée de trading peut sembler parfaitement claire devant un graphique. Vous savez quelle configuration rechercher, quand entrer et quelle opération éviter. Puis vous l'expliquez à un développeur, et quelques petites questions changent la discussion : quelle bougie fait foi, le système peut-il entrer à nouveau, et que se passe-t-il si une autre stratégie utilise déjà le même compte ?
C'est avec ces questions que commence une grande partie du travail. Chez POLARIS, développer un système de trading consiste à rendre votre idée assez précise pour la construire, la tester et l'utiliser en confiance. La qualité du code compte. S'assurer qu'il respecte réellement votre intention compte tout autant.
Nos archives publiées regroupent 170 fiches : 169 travaux de développement et une recherche interne. Elles couvrent des systèmes nouveaux, des modifications d'outils existants, des intégrations et des réparations. Cette diversité constitue le contexte des enseignements qui suivent. Les trois exemples ont été conçus pour cet article : ils rendent le raisonnement concret sans dévoiler de projets clients.
1. Une petite question peut changer chaque opération
Imaginez demander un système qui achète lorsque l'indicateur devient positif. L'instruction semble complète. Mais voulez-vous dire « acheter une fois au franchissement de zéro » ou « acheter chaque fois que la valeur est supérieure à zéro » ?
Cinq observations suffisent à voir la différence. Supposons qu'aucune autre règle ne bloque l'entrée. Chaque ligne correspond à une nouvelle lecture de l'indicateur ; avant la première, sa valeur était de −0,2.
| Lecture | Valeur de l’indicateur | Acheter si la valeur est positive | Acheter au franchissement seulement |
|---|---|---|---|
| 1 | 0,3 | Demande d’achat | Demande d’achat |
| 2 | 0,4 | Demande d’achat | Pas de nouvel achat |
| 3 | 0,1 | Demande d’achat | Pas de nouvel achat |
| 4 | −0,1 | Pas de nouvel achat | Pas de nouvel achat |
| 5 | 0,2 | Demande d’achat | Demande d’achat |
La règle qui regarde seulement si la valeur est positive produit quatre demandes d'achat. Celle du franchissement produit deux nouveaux signaux. Aucune n'est automatiquement la bonne : les entrées répétées peuvent être votre intention. Le problème est de laisser ce choix à la personne qui écrit le programme.
Imaginons maintenant que la première position se ferme alors que l'indicateur reste positif. Faut-il entrer à nouveau ? Le réglage « une position à la fois » ne répond pas à cette question. Il peut masquer l'ambiguïté jusqu'à la première sortie.
Ce que nous conviendrions avant de développer : pour cet exemple, utiliser des bougies clôturées et ne créer un signal que si la valeur précédente était nulle ou négative et la nouvelle strictement positive. Attribuer une référence unique au signal empêche la même bougie de provoquer un second ordre après un redémarrage. Si l'entrée n'est pas autorisée, le signal expire à la bougie suivante. Sans données d'indicateur, aucune entrée.
Comment le vérifier : rejouer les cinq observations doit produire deux références de signal. Répéter la première lecture, puis redémarrer le système, ne doit pas créer d'ordre supplémentaire pour ce même signal. Ce sont les résultats attendus selon nos règles d'exemple, pas les résultats rapportés d'un test client. Un système qui intervient pendant la formation d'une bougie demande d'autres règles, tout aussi explicites.
2. Deux opérations raisonnables peuvent dépasser la capacité d'un compte
Les réglages de risque peuvent être rassurants lorsque l'on examine chaque stratégie séparément. La question plus délicate est ce qui arrive quand plusieurs stratégies veulent intervenir ensemble.
Prenons un compte de 10 000 $. Dans cet exemple, chaque opération peut prévoir jusqu'à 100 $ de perte au stop, tandis que le total prévu sur le compte doit rester sous 150 $. Deux systèmes demandent chacun une opération avec 90 $ de risque prévu. Chacun respecte sa limite. Ensemble, ils ont besoin de 180 $.
Le moment de la vérification est décisif. Si les deux systèmes consultent le compte avant qu'une opération apparaisse, chacun peut croire que les 150 $ sont encore disponibles. Le calcul du pourcentage peut être juste alors que la décision à l'échelle du compte est mauvaise.
Un contrôle commun du risque résout cet exemple en réservant immédiatement 90 $ au premier ordre accepté pour envoi. Il reste 60 $ : la deuxième demande de 90 $ est donc refusée. Nous gardons ici une taille fixe ; réduire la seconde opération serait une autre règle à convenir.
Cette réservation ne doit pas disparaître simplement parce qu'une réponse tarde. Si le courtier confirme le rejet, le montant peut être libéré. Si le résultat reste inconnu, le système doit examiner les ordres et positions réels avant de considérer cette capacité comme disponible. MetaQuotes explique pourquoi une demande de trading peut donner lieu à plusieurs mises à jour distinctes.
Comment le vérifier : envoyer les deux demandes ensemble, retarder une réponse et recommencer après un redémarrage. Le risque prévu, utilisé ou réservé, ne doit jamais dépasser 150 $. Il s'agit d'une limite de conception, pas d'une garantie de perte maximale : les sauts de cours, le glissement et les sorties qui échouent peuvent entraîner une perte plus importante.
3. Un graphique peut sembler plus clair après coup
Un signal apparaît à 10:05 sur un graphique de cinq minutes, et vous souhaitez le confirmer par la tendance horaire. Quelle bougie horaire le système doit-il lire ?
À 10:05, la bougie de cinq minutes allant de 10:00 à 10:05 est clôturée. La bougie horaire de 10:00 à 11:00 a encore 55 minutes devant elle. Sa valeur finale est inconnue. Si la règle repose sur des bougies clôturées, la bougie horaire disponible est celle de 09:00 à 10:00.
Devant le graphique terminé, cette différence s'oublie facilement. Utiliser la valeur finale de 11:00 pour évaluer une décision prise à 10:05 donne au système une information qu'il ne pouvait pas posséder. Employer volontairement la bougie horaire encore en formation est possible, mais c'est une autre règle, à tester comme telle.
Ce que nous conviendrions : la bougie dont provient chaque donnée, le moment où elle devient utilisable et le comportement en cas de retard. Dans notre exemple, un historique manquant entraîne une attente ou une entrée ignorée selon la règle convenue, jamais le remplacement discret par une bougie inachevée.
Comment le vérifier : le journal de la décision de 10:05 doit citer la bougie horaire clôturée à 10:00 et celle de cinq minutes clôturée à 10:05. Retarder l'une des données doit provoquer l'attente ou l'abandon prévu. Ces horaires supposent des données continues dans un fuseau serveur défini ; autour des fermetures de marché, il faut vérifier les horodatages réels des bougies.
4. Un programme correct et une stratégie utile demandent des vérifications différentes
Les exemples précédents vérifient si le logiciel fait ce qui a été convenu. Un système peut réussir tous ces contrôles et perdre de l'argent. C'est pourquoi une bonne discussion sur la livraison porte aussi sur l'évaluation de l'idée de trading elle-même.
Un backtest montre comment les règles se sont comportées sur des cours passés, dans les conditions de test choisies. C'est utile, mais le résultat dépend aussi des coûts, de la qualité des données et de la simulation des opérations. Si une faible hausse du spread efface l'avantage apparent, mieux vaut le découvrir avant de s'appuyer sur le système.
Une démarche pratique consiste à développer l'idée sur une période, puis à la tester sur une autre qui n'a pas servi à ces décisions. Vient ensuite une observation en temps réel, dans des conditions définies. Si la période séparée sert régulièrement à retoucher la stratégie, elle ne constitue plus un contrôle neuf. Chaque étape apporte des informations ; aucune ne garantit la suivante.
Le développeur et le client doivent définir ce que signifie réussir chaque test. « Le système a ouvert exactement les deux opérations prévues » est un résultat logiciel. « La stratégie est restée utile après coûts sur des données inédites » exige ses propres éléments de preuve.
5. Vous devez pouvoir comprendre ce que fait votre système
Un système doit rester utilisable après le premier test réussi. Lorsqu'il reste hors du marché, vous devez pouvoir savoir s'il n'y avait pas de signal, si la limite de risque était atteinte ou si des prix manquaient.
Un message comme « opération échouée » laisse trop de questions ouvertes. « Entrée ignorée : 60 $ disponibles, 90 $ nécessaires » indique ce qui s'est passé et où regarder. La version du logiciel, l'heure de décision et la réponse du courtier aident à distinguer une règle modifiée d'un environnement de trading qui a changé.
Le redémarrage mérite la même attention. Le système reconnaîtra-t-il une position existante ? Peut-il répéter un ordre déjà envoyé ? Une livraison utile comprend des réglages clairs, un guide d'utilisation succinct et des contrôles de ces situations. Ce sont des pratiques que nous recommandons ; les archives ne prouvent pas que chaque travail historique les comprenait.
Ce que cela signifie pour votre projet
L'expérience aide à poser les bonnes questions assez tôt, quand il est encore facile de faire évoluer les réponses. Une stratégie nouvelle, la conversion d'un indicateur et une réparation ne demandent pas le même plan. Elles demandent toutefois une compréhension commune de ce que le système terminé doit faire.
Pour un premier échange avec POLARIS, trois éléments sont particulièrement utiles : un exemple d'opération souhaitée, un exemple à éviter et les limites que le système doit respecter. Vous n'avez pas besoin d'arriver avec un cahier des charges technique. Ces exemples nous donnent un point de départ concret pour le construire avec vous.
- Avant le développement : convenir des signaux, du calendrier des décisions, des limites de position et du comportement lorsque des informations manquent.
- Avant l'acceptation : tester une situation normale, un cas limite et une défaillance, avec le résultat attendu écrit à l'avance.
- Avant de s'y fier : examiner les résultats de trading, les instructions d'utilisation et le comportement après incident.
Notre objectif est que vous retrouviez votre propre idée dans le système terminé et compreniez comment son comportement a été vérifié. C'est une confiance que le soin apporté au développement peut mériter.
Parlez de votre idée de trading avec POLARIS · Découvrez nos compétences en développement
Les archives de plus près
Les archives illustrent la diversité des travaux derrière cette discussion. Elles ne mesurent pas la rentabilité ni la fréquence d'une erreur particulière. Les détails suivants permettent de vérifier les chiffres sans interrompre les enseignements pratiques.
Ce que comprennent les 170 fiches et comment lire les chiffres
Les chiffres proviennent du jeu de données publié des archives. Une ligne représente un travail enregistré, pas nécessairement un client distinct ou une stratégie différente.
| Type de travail | Fiches |
|---|---|
| Nouveau développement | 117 |
| Modification et amélioration | 34 |
| Conversion et intégration | 12 |
| Débogage et réparation | 6 |
| Recherche interne | 1 |
Les 169 fiches de développement portent des dates allant de novembre 2020 à février 2024. La recherche interne n'a ni date ni durée publiées. Il s'agit d'un instantané des archives, pas d'un total actuel de tous les travaux POLARIS. Il ne contient ni comptes rendus d'acceptation client, ni rendements de comptes, ni liste commune de critères d'acceptation.
Plateformes : les libellés totalisent 81 fiches MT5, 71 MT4 et 18 MT4/MT5. Parmi elles, 108 sont explicitement marquées comme déduites : 52 MT5 et 56 MT4. Les 62 autres comprennent 29 MT5, 15 MT4 et 18 mixtes ; l'absence de cette marque ne vaut pas vérification indépendante. Les dates déduites pour MT4 vont de novembre 2020 à décembre 2021, et celles de MT5 de janvier 2022 à janvier 2024. Il ne faut pas les présenter comme une expérience confirmée sur ces plateformes.
Catégories : chaque ligne possède un sujet principal et peut recevoir plusieurs étiquettes de fonctionnalités. La fiche 1, par exemple, a pour sujet la gestion du risque et des opérations, avec des étiquettes de dimensionnement des positions et de gestion des stops. Elle reste une seule fiche. Une étiquette absente signifie « non enregistré ici », pas nécessairement « non développé ». Les dates et durées inconnues restent inconnues.
Les décomptes exacts par fonctionnalité comprennent 45 fiches de dimensionnement des positions, 7 sur plusieurs unités de temps et 6 d'intégration d'indicateurs. Six lignes sont aussi classées spécifiquement comme réparations. Ces chiffres décrivent les archives ; ils ne comptent pas les défauts et ne prouvent pas que les protections des exemples ont été livrées dans chaque cas.
Certaines pages anciennes emploient des regroupements thématiques plus larges. Le tableau distingue ces synthèses publiées des nombres que l'on peut recalculer directement à partir des lignes.
| Sujet | Ancien total thématique | Sélection de l’article | Décompte dans les données |
|---|---|---|---|
| Intégration d’indicateurs | 11 | 10 | 6 — étiquette de fonctionnalité |
| Grid et couverture | 38 | 33 | 33 — sujet principal |
| Action et structure des prix | 26 | 22 | 22 — sujet principal |
| Données, statistiques et apprentissage automatique | 9 | 3 | 3 — sujet principal |
| Tableaux de bord et scanners | 22 | 14 | 11 — étiquette de fonctionnalité |
Les listes reliant les anciens groupes et les sélections d'articles aux lignes individuelles ne sont pas publiques ; les écarts ne peuvent donc pas être entièrement expliqués. Pour reproduire les décomptes, compter chaque sujet principal une fois par ligne, ou la présence de la fonctionnalité indiquée une fois par ligne. Plusieurs fonctionnalités peuvent se recouper.
Les archives reflètent les travaux conservés et la demande des clients, pas un échantillon représentatif du secteur. Elles ne recensent pas les travaux abandonnés, la fréquence des erreurs ou l'accord entre évaluateurs indépendants. Des affirmations plus fortes exigeraient ces informations. Les futures fiches seraient plus faciles à vérifier en indiquant la version acceptée, la liste de contrôle, la date de décision, l'évaluateur et l'emplacement des preuves.
| Enseignement | Décompte | Ce qui illustre la leçon | Quand la règle peut différer |
|---|---|---|---|
| Définir le déclenchement | 6 étiquettes d’intégration d’indicateurs | L’exemple 1 montre quatre demandes contre deux signaux ; le décompte ne mesure pas les erreurs. | Les entrées répétées peuvent être voulues. |
| Coordonner le risque du compte | 45 étiquettes de dimensionnement | L’exemple 2 demande 180 $ pour 150 $ disponibles ; le décompte ne prouve pas un contrôle partagé. | Des comptes séparés et isolés ne partagent pas cette capacité. |
| Convenir de la bougie utilisée | 7 étiquettes multi-unités de temps | L’exemple 3 distingue l’information disponible d’une valeur finale ultérieure ; ce n’est pas un taux d’erreur. | Une bougie en formation peut être utilisée si cela est prévu et testé. |
| Rendre les problèmes compréhensibles | 6 fiches de réparation | L’exemple de journal montre l’utilité d’un message précis ; les réparations ne comptent pas tous les défauts. | Une réparation peut aussi faire partie d’un développement ou d’une modification. |
Quelques questions que vous pourriez vous poser
170 fiches signifient-elles 170 systèmes clients rentables ?
Non. Les archives contiennent 169 fiches de développement et une recherche interne. Elles couvrent plusieurs types de travaux et n’établissent pas le nombre de clients distincts ou de stratégies rentables.
Les exemples proviennent-ils de projets clients individuels ?
Non. Nous les avons conçus pour rendre les choix techniques faciles à suivre. Les archives apportent le contexte, mais les exemples ne sont ni des récits de projets clients ni leurs résultats mesurés.
Faut-il un cahier des charges technique avant de contacter POLARIS ?
Non. Commencez par le comportement de trading souhaité, un exemple que vous refuseriez et vos limites d’utilisation. Ces éléments peuvent servir de base à un cahier des charges convenu ensemble.
Puis-je vérifier les chiffres des archives ?
Oui. Le jeu de données lié permet de compter les types de travaux, les sujets principaux et les étiquettes exactes. Certains totaux plus larges sur d’anciennes pages ne sont pas entièrement reproductibles, car leurs listes de fiches incluses ne sont pas publiques.
Réécrit le 6 septembre 2026. Les chiffres renvoient à l'instantané publié de 170 fiches. Les identités des clients, spécifications privées et codes sources ne sont pas divulgués.
