Télécharger keel

Installer depuis le terminal — une seule commande

Rassembler les wheels à la main n'est pas la seule porte d'entrée. Un script publié sur la branche par défaut de keel fait tout le travail. Il lit la dernière version parue sur GitHub, télécharge les cinq wheels de production et le config.yaml par défaut, puis les installe dans un environnement Python privé, sous votre dossier personnel.

Une wheel est un paquet Python déjà construit. Un venv est un dossier qui contient le Python d'un seul projet et ses bibliothèques, tenu à l'écart du reste du système ; celui-ci est créé dans ~/.keel/.venv.

Il vous faut macOS ou Linux, un terminal, curl et Python 3.14 ou plus. Le script refuse toute autre plateforme : les lecteurs sous Windows restent sur le parcours des wheels ci-dessus. Sous Linux, ce seuil mord dès aujourd'hui : la plupart des distributions s'en tiennent encore par défaut à un Python plus ancien, et le test de fumée de keel sur Linux échoue précisément à cette vérification, quand macOS la franchit avec un Python de Homebrew. Attendez-vous à installer 3.14 vous-même d'abord. Depuis la v0.12.0, les wheels publiées exigent le même 3.14 : tous les chemins vers keel partagent désormais un seul seuil.

L'installation en une ligne

curl -fsSL https://raw.githubusercontent.com/CodeGateSoftware/keel/main/scripts/install.sh | bash

Ou bien lisez-le d'abord, puis exécutez ce que vous avez lu

keel est un programme auquel vous confierez peut-être les clés d'API d'une plateforme d'échange : diriger un script venu d'internet droit dans bash ne doit donc pas être la seule option proposée. Téléchargez-le, lisez-le, puis exécutez votre propre copie.

curl -fsSL https://raw.githubusercontent.com/CodeGateSoftware/keel/main/scripts/install.sh -o install.sh
# chaque étape annonce ce qu'elle va faire, et pourquoi, avant de le faire
less install.sh
bash install.sh

Le script est servi depuis main, la branche par défaut de keel. Il n'a jamais fait partie d'une version publiée, il n'y a donc aucun numéro à citer, et il change quand main change : c'est ainsi que le seuil Python ci-dessus est passé de 3.11 à 3.14. Lisez la copie que vous téléchargez, plutôt que de supposer que cette description a suivi.

Ce que fait le script

• Il télécharge exactement cinq wheels, chacune par son nom exact, dans la dernière version parue. Il n'utilise jamais de motif *.whl : une version publiée embarque aussi des wheels qu'un déploiement ne doit pas recevoir.
• Il installe par chemin de fichier exact, jamais par nom de paquet. Sur PyPI, le nom keel appartient à un projet sans rapport, et installer par chemin rend cette erreur impossible.
• Il construit le venv avec uv seulement quand un uv fonctionnel répond à uv --version ; un substitut incapable de s'exécuter est considéré comme absent. Sinon, il utilise le Python qu'il a trouvé, avec pip.
• Il affiche le sha256 de chaque wheel, calculé sur votre propre machine. C'est une trace d'audit, pas une vérification — aucune empreinte de wheel n'est publiée nulle part, il n'y a donc rien à quoi comparer.
• Il n'exécute aucune commande privilégiée. Les téléchargements atterrissent dans un dossier temporaire supprimé à la sortie du script, et l'installation elle-même ne vit que sous votre dossier personnel.
• Il n'écrase jamais un ~/.keel/config.yaml ni une base de données existante. Relancer le script met le code à jour sur place.
• Le config.yaml qu'il dépose est la configuration de production de la version publiée, en auto_trade.mode: confirm — le profil réel derrière un verrou, pas le profil papier. keel prévisualise chaque entrée dictée par une règle et demande avant de la passer, à une invite y/N dont la réponse par défaut est non. Le stop de protection et la prise de bénéfice qui suivent une position déjà approuvée, eux, partent sans seconde question. Notez que le message de succès du script appelle cela le profil papier : cette ligne est fausse, vérifiez auto_trade.mode dans le fichier plutôt que de vous y fier.
• Un déploiement neuf ne négocie rien pour autant. Le coupe-circuit échoue en position fermée : chaque cycle passe son tour tant que vous n'avez pas lancé keel resume, et les règles semées démarrent comme candidates, sans rien négocier avant que vous ne les promouviez. Pour une configuration incapable de passer le moindre ordre réel, lancez ./.venv/bin/keel init-config --force depuis ~/.keel : sans --live, c'est le modèle mode: paper qui est écrit.
• Il termine en lançant keel versions, et échoue bruyamment si le résultat n'est pas net.

Le maintenir à jour

Relancer l'installeur amène le déploiement à la dernière version parue, sur place. keel sait aussi se mettre à jour depuis le dossier où il habite : keel update --check annonce ce que ferait la mise à jour sans rien modifier, et keel update l'applique après une confirmation tapée à la main. Une réserve mérite d'être connue avant de s'y fier : keel update installe via uv, et s'arrête sur une erreur explicite quand uv est absent. Un déploiement que le script a construit sans uv réclame l'ajout de uv avant qu'une mise à jour puisse s'appliquer. keel update refuse de toucher à une copie des sources.

cd ~/.keel
./.venv/bin/keel update --check
./.venv/bin/keel update

Tous les fichiers de la version

• config.yaml
• keel_broker_alpaca-0.21.0-py3-none-any.whl
• keel_broker_alpaca-0.21.0.tar.gz
• keel_broker_api-0.21.0-py3-none-any.whl
• keel_broker_api-0.21.0.tar.gz
• keel_broker_coinbase-0.21.0-py3-none-any.whl
• keel_broker_coinbase-0.21.0.tar.gz
• keel_broker_fake-0.21.0-py3-none-any.whl
• keel_broker_fake-0.21.0.tar.gz
• keel_broker_kraken-0.21.0-py3-none-any.whl
• keel_broker_kraken-0.21.0.tar.gz
• keel_broker_robinhood-0.21.0-py3-none-any.whl
• keel_broker_robinhood-0.21.0.tar.gz
• keel_core-0.21.0-py3-none-any.whl
• keel_core-0.21.0.tar.gz
• keel_trader-0.21.0-py3-none-any.whl
• keel_trader-0.21.0.tar.gz

Les téléchargements pointent directement vers les fichiers hébergés par GitHub. Ce site n'héberge aucun binaire. Données de version récupérées depuis GitHub au moment du build, le 2026-10-18.

Depuis les sources — essayez keel en cinq minutes

Tout ce parcours est en lecture seule et côté papier : aucun fonds, et rien ici ne peut passer d'ordre. Il vous faut uv et une clé d'API Coinbase Developer Platform (CDP) gratuite, en lecture seule — l'historique des bougies passe par le client authentifié, si bien que keel fetch sans clé échoue sur une AuthenticationError. Autant le dire tout de suite, pour que l'étape 4 ne surprenne personne.

• uv (le gestionnaire de paquets Python)
• Python 3.14 ou plus — le seuil qu'exigent aussi les wheels publiées depuis la v0.12.0
• Une clé CDP gratuite en lecture seule — données de marché uniquement

git clone https://github.com/CodeGateSoftware/keel.git && cd keel
uv sync --all-extras --dev        # Python 3.14+ — the repo's floor moved up in #546
cp .env.example .env              # put the read-only CDP key/secret in it — market data only
uv run keel rules seed            # register the rule families as candidates
uv run keel fetch                 # pull candle history for the default allowlist
uv run keel simulate --years 1 --skip-within-cap

À quoi vous attendre

keel simulate rejoue les vraies règles, de façon déterministe, sur l'historique récupéré, les compare à la référence DCA et rédige un rapport GO-LIVE / TRAIN-MORE. Sur les règles par défaut, il vous répondra très probablement TRAIN-MORE en nommant les verrous qui bloquent : c'est le moteur qui fonctionne, pas une panne — l'honnêteté est la fonctionnalité.

Les étapes suivantes — faire franchir le verrou à une règle, lancer l'agent papier, passer un premier ordre réel sous supervision — figurent dans le runbook de mise en production. →