Démarrage rapide

La voie canonique « essayez-le tout de suite » : installez le Takuto CLI, lancez takuto setup puis takuto start, et terminez dans le dashboard. Comptez quelques minutes.

État des tests par fournisseur (beta). Claude Code a été vérifié pour la dernière fois avant qu’Anthropic ne rende une clé API obligatoire pour son mode headless, et Codex n’a pas encore été testé. Tout devrait fonctionner, mais vous pourriez rencontrer quelques aspérités. Si c’est le cas, faites-nous signe — vos retours sont les bienvenus et nous aident à corriger rapidement le moindre problème.

Configuration recommandée. Quelques choix rendent l’expérience plus fluide et plus proche de la production :

• Authentifiez GitHub avec une GitHub App, plutôt qu’avec un personal access token (PAT). Les PR sont alors ouvertes sous une identité de bot dédiée plutôt que sous votre compte personnel — une paternité plus propre, et un accès qui reste limité à ce que l’app autorise.
• Protégez les branches que l’agent cible. Un agent autonome peut faire tout ce que son token permet : activez donc la branch protection sur main (et toute branche cible) — exigez une PR avant tout merge, exigez une revue approuvée, et interdisez les pushes directs. Couplé à une identité de bot, cela vous donne un garde-fou de revue obligatoire même en travaillant en solo.
• Utilisez une base de données externe (Postgres / MySQL / MariaDB) pour que vos données vivent hors du container et puissent être sauvegardées.

Tout ce qui suit fonctionne sans cela, mais ces réglages valent la peine d’être mis en place tôt.

Vous préférez faire tourner le moteur vous-même sans le CLI ? Voir Installer Takuto Core pour la voie construisez-votre-propre-container.

1. Créer les tokens dont vous aurez besoin

Préparez-les avant de commencer — vous les ajouterez dans le dashboard (étape 6) :

• Un identifiant de fournisseur d’IA — l’un de : une clé API Anthropic pour Claude Code (son mode headless requiert désormais une clé API), une clé API OpenAI pour Codex, une clé API Cursor pour Cursor Agent — ou aucun si vous faites tourner un modèle auto-hébergé via OpenCode.
• Un accès GitHub — un personal access token fine-grained limité aux dépôts sur lesquels Takuto travaillera (Contents et Pull requests : read & write ; Metadata : read ; Issues : read & write si vous interrogez GitHub Issues). Mieux encore, mettez en place une GitHub App pour que les PR proviennent d’une identité de bot à portée limitée plutôt que de votre compte personnel.
• Jira (uniquement si vous interrogez Jira) — votre propre token API Atlassian. Chaque utilisateur ajoute le sien dans le dashboard (Configuration → Ticketing) ; les lectures et écritures agissent alors en votre nom. Un token owner à l’échelle du déploiement n’est qu’un repli pour les utilisateurs qui n’en ont pas ajouté un.

Limitez chaque token au minimum dont il a besoin — ce sont eux qui bornent ce qu’un agent autonome peut atteindre.

2. Installer le CLI

brew install takuto-team/tap/takuto

# Apple Silicon (arm64) — pour Intel, utilisez takuto-darwin-amd64
curl -L -o takuto https://github.com/takuto-team/takuto-cli/releases/latest/download/takuto-darwin-arm64
chmod +x takuto && sudo mv takuto /usr/local/bin/

brew install takuto-team/tap/takuto

# amd64 — pour arm64, utilisez takuto-linux-arm64
curl -L -o takuto https://github.com/takuto-team/takuto-cli/releases/latest/download/takuto-linux-amd64
chmod +x takuto && sudo mv takuto /usr/local/bin/

# Télécharge le dernier binaire Windows
curl.exe -L -o takuto.exe https://github.com/takuto-team/takuto-cli/releases/latest/download/takuto-windows-amd64.exe
# Puis déplacez takuto.exe dans un dossier présent dans votre PATH (par ex. un dossier d’outils)

brew install takuto-team/tap/takuto

# amd64 — pour arm64, utilisez takuto-linux-arm64
curl -L -o takuto https://github.com/takuto-team/takuto-cli/releases/latest/download/takuto-linux-amd64
chmod +x takuto && sudo mv takuto /usr/local/bin/

Pour tous les binaires et sommes de contrôle, voir la page des Releases et la référence du CLI.

3. Prérequis

Tout ce dont vous avez besoin, c’est Docker ou Podman installé — le CLI détecte automatiquement celui dont vous disposez.

• Docker Desktop
• Podman

Vous n’avez pas à récupérer l’image Takuto Core vous-même : takuto start la récupère au premier lancement (avec repli sur une copie en cache si vous êtes hors ligne). Elle est publiée publiquement, donc aucune authentification au registre n’est nécessaire — même si vous pouvez la pré-récupérer manuellement avec docker pull ghcr.io/takuto-team/takuto-core:latest si vous préférez.

4. Générer votre config

takuto setup

L’assistant est court : maintenant que le dashboard gère la majeure partie de la configuration, il ne vous demande que le port du dashboard et — si vous utilisez une base de données externe (Postgres / MySQL / MariaDB) — ses détails de connexion (sinon il bascule par défaut sur le SQLite intégré). Tout le reste — système de ticketing, fournisseur d’IA et modèles, polling, workflows — se configure ensuite dans le dashboard. Il génère takuto.yml ainsi qu’un dossier .takuto/ contenant config.toml, les secrets (takuto.env) et un dossier workflows/ de définitions de pipeline de départ :

takuto.yml                  # Docker Compose orchestration
.takuto/
  config.toml                # bootstrap configuration
  takuto.env                # secrets and API tokens
  workflows/                 # pipeline step definitions
    implement_ticket.toml
    merge_base.toml
    address_pr_comments.toml

Le dossier .takuto/ est créé là où vous lancez la commande — il n’a pas à être un répertoire de projet. Lancez takuto setup/takuto start depuis différents dossiers pour garder côte à côte plusieurs instances Takuto isolées : chacune avec sa propre config, son authentification, ses espaces de travail et sa base de données, sans configuration supplémentaire.

Vous pointez sur une base de données externe — surtout une qui tourne dans un container ? Réussir la chaîne de connexion est la seule partie délicate : voir Base de données externe.

5. Démarrer Takuto

takuto start

Ouvrez ensuite le dashboard dans votre navigateur — http://localhost:8080 par défaut, ou le port que vous avez choisi lors du takuto setup. takuto start récupère l’image (au premier lancement) et démarre la stack. Au premier démarrage, le dashboard vous invite à créer le compte admin initial.

6. Terminer dans le dashboard

Au premier démarrage, le dashboard vous guide à travers un court assistant de configuration, dans l’ordre :

1. GitHub — votre PAT, ou une GitHub App pour des commits et PR attribués à un bot.
2. Repositories — clonez le ou les dépôts sur lesquels vous voulez que Takuto travaille.
3. AI provider — votre clé de fournisseur (ANTHROPIC_API_KEY, CURSOR_API_KEY, OPENAI_API_KEY…), ou un endpoint auto-hébergé.
4. Ticketing — Jira ou GitHub Issues, plus le polling par dépôt (clés de projet, types d’éléments, filtres) réglé pour chaque dépôt. Chaque utilisateur ajoute ici son propre token Jira.
5. Workflows — passez en revue les pipelines TOML pré-amorcés.

Les valeurs existantes pré-remplissent leurs champs (les secrets affichent un placeholder ••••••) ; vous pouvez aussi placer les secrets dans .takuto/takuto.env avant le démarrage (voir Configuration). Une fois un dépôt et le ticketing configurés, le polling démarre automatiquement et récupère les tickets « To Do » — ou cliquez sur + pour coller une description et lancer un workflow manuellement.

Optionnel — takuto auth (non recommandé). takuto auth déroule des connexions OAuth interactives (GitHub + votre fournisseur d’IA) depuis le CLI. L’OAuth accorde un accès large au compte ; nous recommandons donc plutôt des clés API / tokens à portée limitée (ci-dessus). N’utilisez takuto auth que si vous avez spécifiquement besoin du flux de connexion interactif.

Ce qui se passe ensuite

Chaque workflow crée un git worktree à partir de votre branche de base, lance vos commandes d’initialisation de worktree (par ex. npm ci), puis exécute les étapes d’agent de votre définition de workflow TOML. Suivez la sortie terminal en direct sur chaque carte de workflow, et ouvrez un éditeur VS Code dans le navigateur sur n’importe quel worktree avec Open editor.

Voir Comment ça marche pour le cycle de vie complet d’un workflow, et la référence du CLI pour stop, restart et l’isolation multi-projets.

Arrêter et redémarrer

takuto stop       # arrête les services Takuto
takuto restart    # redémarre les services Takuto

Tout l’état d’authentification, les snapshots de workflow et les caches vivent dans des volumes Docker nommés : les workflows survivent donc à un redémarrage — les exécutions en pause ou en cours reprennent automatiquement.