Ce qu’il faut préparer avant de lancer un projet de robot de trading sur mesure

Avant de discuter des langages ou de l’infrastructure, déterminez qui utilisera le système, ce qu’il est autorisé à faire et le niveau de supervision nécessaire.

Certains projets exigent seulement une stratégie et une plateforme. D’autres nécessitent un tableau de bord, plusieurs environnements ou un processus de transfert plus formel.

Les autorisations d’API, l’environnement d’essai et le modèle d’ordres appropriés peuvent modifier la forme du projet. Ce détail ne doit pas être reporté.

Si l’intégration demeure incertaine, l’étape la plus prudente consiste à examiner les exigences de la plateforme et à les intégrer à la portée.

Même lorsque les règles de la stratégie sont claires, le flux doit être vérifié dans un environnement d’essai avant l’utilisation en réel. La simulation ou les essais en bac à sable peuvent révéler des erreurs d’acheminement, de synchronisation, de configuration et de notification; ils ne valident ni la stratégie ni les résultats financiers.

Omettre cette validation logicielle entraîne généralement davantage de retards par la suite.

Un robot sur mesure demeure un logiciel qui exige de la documentation, des limites de soutien et une gestion des changements. La simple remise du code source ne constitue pas un transfert complet.

Les acheteurs doivent demander ce qui est inclus par défaut, ce qui nécessite un forfait de soutien et qui sera responsable du déploiement et de la surveillance après le lancement.

Décrivez les signaux, instruments permis, séances, entrées, seuils et exceptions afin qu’une autre personne puisse tester le comportement prévu. Une équipe d’ingénierie peut mettre en œuvre les règles définies par le client; elle ne doit pas déduire des décisions de placement.

Convenez des vérifications en démo ou en simulation, des journaux, des destinataires des alertes, des accès de déploiement, de la propriété du code source, de la documentation et du processus de modification avant le début du développement.

Un bon énoncé décrit ce que le logiciel doit faire dans une situation précise : un signal arrive, le système le valide, soumet la demande permise, consigne la réponse et alerte un opérateur lorsqu’une mise à jour attendue manque. Chacun dispose ainsi d’un comportement concret à examiner.

Incluez les exceptions autant que le parcours normal. Des identifiants absents, une demande rejetée, un signal en double, une plateforme indisponible et une pause manuelle font tous partie de la définition d’un système exploitable. Le but est de rendre le comportement du logiciel testable, et non de prédire les marchés.