open-trading-api : le dépôt d'exemples de Korea Investment & Securities, entre codes LLM et moteur de backtest
Korea Investment & Securities Open API Github
En bref
- De quoi s’agit-il ?
- Ce dépôt Python rassemble des exemples d'appels à l'Open API de Korea Investment & Securities, une interface de conception de stratégies et un backtester basé sur QuantConnect Lean. La documentation décrit clairement l'intention, mais laisse plusieurs zones d'ombre, notamment sur la licence et sur le contenu réel des fichiers.
- À qui s’adresse-t-il ?
- Ce dépôt convient à un développeur Python déjà titulaire d'un compte chez Korea Investment & Securities et d'une clé Open API, qui veut comprendre la forme des requêtes avant d'écrire son propre client. Il ne convient pas à qui cherche une bibliothèque stable, versionnée et documentée pour la production : la licence n'est pas identifiable dans les éléments fournis et aucun release n'a été récupéré.
- Puis-je l’utiliser commercialement ?
- Pas sans autorisation. GitHub ne trouve aucun fichier de licence dans ce dépôt, et sans licence tous les droits sont réservés par défaut : vous pouvez lire le code, mais pas le réutiliser. Consultez le README ou demandez l’accord des auteurs avant de l’utiliser.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 21 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Un dépôt d'exemples avant d'être une bibliothèque
Le README est explicite sur la nature du projet : il s'agit d'un ensemble de codes d'exemple destinés à illustrer l'intégration de l'Open API de Korea Investment & Securities, et non d'un SDK packagé. La mention en tête de document indique que ces exemples sont fournis à titre de référence pour réduire la charge de développement, qu'ils peuvent être modifiés sans préavis, et que la société n'assume aucune responsabilité pour les pertes causées par un programme construit à partir de ces exemples. Cette dernière phrase n'est pas une clause de style : elle fixe le cadre. Le code est là pour être lu, copié et adapté, pas pour être importé comme dépendance.
Le public visé est nommé sans ambiguïté : développeurs Python qui découvrent l'Open API, utilisateurs existants qui veulent améliorer leur code, et utilisateurs d'agents LLM qui cherchent à construire de la recherche de titres, de l'analyse de cours ou du trading automatique. Le dépôt fournit d'ailleurs un fichier llms.txt pour faciliter la navigation des modèles, ce qui est un choix cohérent avec cette troisième cible.
Le problème résolu est donc concret : l'API KIS existe, mais son usage demande de connaître les points d'entrée, les paramètres et les formats de réponse. Le dépôt sert de carte.
Deux arborescences parallèles pour deux usages distincts
La structure du dépôt sépare deux publics. examples_llm/ organise le code par fonction unique : chaque dossier correspond à un point d'entrée de l'API, avec un fichier d'appel minimal nommé d'après la fonction, par exemple inquire_price.py pour la consultation d'un prix obligataire, et un fichier de vérification préfixé par chk_, comme chk_inquire_price.py. L'objectif déclaré est qu'un LLM puisse localiser et appeler une fonction sans avoir à parcourir un fichier de plusieurs milliers de lignes.
examples_user/ adopte l'organisation inverse : un fichier de fonctions agrégé par catégorie de produit, par exemple domestic_bond_functions.py, accompagné d'un fichier d'exemples d'exécution domestic_bond_examples.py. Les variantes WebSocket suivent le même schéma avec le suffixe _ws. Pour un humain qui veut voir comment enchaîner plusieurs appels, cette forme est plus lisible ; pour un agent qui doit isoler un appel, elle l'est moins. Le dépôt ne tranche pas, il maintient les deux.
Les catégories couvertes sont l'authentification, les actions domestiques, les obligations domestiques, les produits dérivés domestiques, les actions étrangères, les dérivés étrangers, les ELW et les ETF/ETN. Le fichier kis_auth.py, présent dans les deux arborescences, centralise l'émission du jeton d'accès, les fonctions d'appel communes, la bascule entre environnement de simulation et environnement réel, et la configuration WebSocket.
Le pipeline strategy_builder vers backtester
Au-delà des exemples, le dépôt embarque une chaîne outillée. Le README décrit un flux où strategy_builder produit un fichier .kis.yaml, que backtester importe pour valider la stratégie sur des données historiques ; une fois la validation faite, le retour se fait vers le générateur de signaux, qui émet BUY, SELL ou HOLD vers l'Open API. Le diagramme fourni est un graphe mermaid, ce qui signifie que le format .kis.yaml est le point de jonction entre les deux modules.
strategy_builder est présenté comme une interface visuelle de conception de stratégies, avec 80 indicateurs techniques, 10 stratégies prédéfinies et la génération de signaux. backtester repose sur QuantConnect Lean et s'exécute via Docker, avec production d'un rapport HTML. Les 10 stratégies prédéfinies sont communes aux deux modules : croisement de moyennes mobiles, momentum, plus haut sur 52 semaines, séries de hausses ou de baisses consécutives, ratio d'écart à la moyenne, échec de cassure, clôture forte, expansion de volatilité, retour à la moyenne et filtre de tendance.
Un troisième composant, MCP/, est mentionné dans le tableau des répertoires comme passerelle vers des outils d'IA, avec deux éléments nommés KIS Code Assistant et Trading MCP. Le README y renvoie vers MCP/README.MD sans en détailler le fonctionnement. C'est une zone que la documentation ne couvre pas.
Mise en route : uv, Python 3.11 et un fichier YAML à déplacer
Le README fixe Python 3.11 comme minimum et recommande uv comme gestionnaire de paquets. L'installation de uv est donnée sous deux formes : sous Windows en PowerShell avec la commande powershell -c "irm https://astral.sh/uv/install.ps1 | iex", et sous macOS ou Linux avec curl -LsSf https://astral.sh/uv/install.sh | sh. La vérification se fait par uv --version.
Le reste est direct : git clone du dépôt, puis cd open-trading-api, puis uv sync pour installer les dépendances à partir de pyproject.toml et uv.lock.
La partie qui demande de l'attention est la configuration. Le fichier kis_devlp.yaml doit recevoir les identifiants personnels. Le chemin par défaut est ~/KIS/config/kis_devlp.yaml, et le README recommande de créer le dossier, d'y copier le fichier du dépôt, puis de le modifier. Les commandes données sont mkdir -p ~/KIS/config et cp kis_devlp.yaml ~/KIS/config/. Pour changer d'emplacement, il faut modifier la valeur config_root dans kis_auth.py.
En amont, il faut disposer d'un compte chez Korea Investment & Securities relié à un identifiant, avoir souscrit au service Open API, et avoir obtenu une clé d'application et un secret. Le README précise qu'il faut préparer des clés distinctes pour la simulation et pour le compte réel. Le texte fourni s'interrompt au milieu de l'énumération des champs du fichier YAML, donc la liste exacte des clés attendues n'est pas vérifiable ici.
Ce que la documentation ne dit pas
Le point le plus gênant est l'absence de licence identifiable dans les éléments fournis. Pour un dépôt qui contient du code d'exemple destiné à être copié dans des projets, c'est une question qui précède toutes les autres : sans fichier de licence lisible, on ne sait pas sous quelles conditions le code peut être réutilisé, modifié ou redistribué. Le README mentionne une clause de non-responsabilité, ce qui n'est pas la même chose qu'une licence d'utilisation. Je ne peux pas trancher ce point à partir du matériel disponible, et je ne le suppose pas.
Aucun release n'a été récupéré non plus. Le README prévient que les exemples peuvent être mis à jour sans notification. Cela signifie qu'un code qui fonctionne aujourd'hui peut changer de forme demain, sans numéro de version pour s'y accrocher. Pour un projet qui sert de référence à une intégration, c'est une contrainte réelle : il faut prévoir de relire les fichiers après une mise à jour plutôt que de se fier à un état figé.
La documentation ne décrit pas non plus les limites de débit de l'API, les formats d'erreur, ni ce qui se passe quand un jeton expire pendant une session WebSocket. Ces sujets existent forcément dans une API de courtage, mais le README ne les aborde pas.
Le backtester Lean et ce qu'il implique
backtester ne réimplémente pas un moteur de simulation : il s'appuie sur QuantConnect Lean et s'exécute dans Docker. C'est un choix qui a des conséquences pratiques. On hérite d'un moteur éprouvé et d'un format de rapport HTML, mais on ajoute une dépendance à Docker et à l'écosystème Lean dans une chaîne qui, sinon, ne demande que Python et uv. Pour quelqu'un qui veut juste vérifier une moyenne mobile sur trois ans, c'est un coût d'installation disproportionné.
L'alternative la plus évidente est d'écrire soi-même la boucle de backtest sur des données historiques récupérées via l'API. La différence n'est pas dans la qualité du résultat mais dans ce qu'on obtient en plus : Lean apporte la gestion des ordres, des frais et des glissements, ainsi qu'un format de rapport standardisé, que l'on devrait sinon coder. Le dépôt ne fournit pas de benchmark de performance du moteur, et je n'en avance aucun.
Le point d'articulation entre les deux modules, le format .kis.yaml, est décrit comme documenté dans les README respectifs de strategy_builder et backtester. Ces fichiers ne figurent pas dans le matériel fourni, donc la stabilité réelle de ce format entre les deux modules n'est pas vérifiable ici. C'est pourtant le mécanisme central du pipeline : si le format dérive d'un côté, l'import casse.
Coût de maintenance et implications de licence
La maintenance d'un projet construit sur ce dépôt se répartit en deux postes. Le premier est le suivi des mises à jour du dépôt lui-même, puisque le README annonce des changements sans préavis et qu'aucun release n'est publié. Le second est la gestion des identifiants : kis_devlp.yaml contient des clés d'application et des secrets, et le README recommande de le placer hors du dépôt, dans ~/KIS/config/. C'est un bon réflexe, mais cela signifie aussi que la configuration vit en dehors du contrôle de version et doit être sauvegardée et transmise autrement.
Le fichier legacy/ conserve les anciens exemples, ce qui indique que le dépôt a déjà connu une réorganisation. Un lecteur qui tombe sur un exemple ancien doit vérifier s'il se trouve dans legacy/ ou dans l'arborescence active avant de s'en servir.
Sur la licence, je ne peux que constater l'absence d'information exploitable dans le matériel fourni. La mention de non-responsabilité du README limite la responsabilité de l'éditeur, elle ne concède aucun droit. Toute décision de réutilisation doit donc s'appuyer sur la lecture directe du fichier de licence à la racine du dépôt, que je n'ai pas. Je ne donne pas d'avis juridique et je ne comble pas ce vide par une supposition.
Conclusion éditoriale
Ce dépôt convient à un développeur Python déjà titulaire d'un compte chez Korea Investment & Securities et d'une clé Open API, qui veut comprendre la forme des requêtes avant d'écrire son propre client. Il ne convient pas à qui cherche une bibliothèque stable, versionnée et documentée pour la production : la licence n'est pas identifiable dans les éléments fournis et aucun release n'a été récupéré. Avant de s'engager, il faut vérifier le fichier de licence à la racine du dépôt, lire le contenu de kis_devlp.yaml pour savoir quelles clés sont attendues, et confirmer que le module backtester accepte bien le format .kis.yaml exporté par strategy_builder.
Notes de la communauté