Foire aux questions

Puis-je utiliser Takuto librement ?

Oui. Auto-héberger Takuto Core pour votre propre usage — sur votre machine ou au sein de votre entreprise — est gratuit : aucun frais reversé au projet, aucune limite de sièges, aucun plafond d’usage qu’il vous impose. Le moteur est sous AGPL-3.0 et le Takuto CLI sous MIT : vous êtes donc libre de le faire tourner, de le modifier et de le déployer sur votre propre infrastructure. Aucune télémétrie, rien qui ne « téléphone à la maison ».

La seule obligation de l’AGPL à connaître : si vous proposez Takuto Core comme service à des tiers (un produit hébergé), vous devez publier l’intégralité de la pile correspondante en open source. Le faire tourner en interne pour votre propre équipe ne déclenche pas cette obligation. Si ces termes ne correspondent pas à vos besoins, écrivez-moi.

Combien ça coûte à faire tourner ?

Takuto Core en lui-même ne vous facture rien — c’est votre fournisseur d’IA qui facture. L’agent fait tourner Claude Code, Cursor Agent, Codex ou un modèle auto-hébergé sur votre compte, et chaque ticket consomme des tokens proportionnels à la taille du code, au contexte du prompt et au nombre d’étapes de votre workflow.

Ce que cela coûte dépend entièrement du fournisseur et du modèle que vous choisissez — vérifiez leurs tarifs actuels, et surveillez vos premières exécutions pour cerner votre propre charge.

Leviers d’économie :

  • Utilisez des étapes de commande pour le travail déterministe (lint, test) — elles ne consomment aucun token IA.
  • Plafonnez le contexte avec [jira] ticket_context_max_description_bytes.
  • Répétez à blanc avec [general] dry_mode = true avant de pointer sur un vrai backlog.
  • Un modèle auto-hébergé via OpenCode supprime entièrement la facturation au token (vous ne payez que le matériel) — voir Modèles auto-hébergés.

Est-ce prêt pour la production ?

Takuto Core est en bêta. Il est utilisable aujourd’hui, et des gens font tourner de vrais workflows avec — mais attendez-vous à des rugosités, et tous les retours sont les bienvenus. Le statut bêta est aussi pourquoi la communication sur tout ce site penche vers « essayez-le, dites-nous ce qui casse » plutôt que « prêt pour l’entreprise ». Chaque rapport aide à orienter l’évolution du projet.

Puis-je contribuer ? Pourquoi les pull requests ne sont-elles pas acceptées ?

Takuto Core est open source, mais l’auteur n’accepte pas les pull requests pour l’instant. C’est une position délibérée et temporaire, pour des raisons légales : le projet a besoin de temps pour être observé et structuré correctement — licence des contributeurs, gouvernance et marques doivent toutes être en place avant que du code externe puisse être mergé de façon responsable.

Cela ne veut pas dire que les retours sont mal venus — bien au contraire. Les rapports de bugs, les demandes de fonctionnalités et les retours en général sont très souhaités. Ouvrez une issue ou écrivez à morphet.contact@gmail.com. La restriction porte spécifiquement sur le merge de code externe, pas sur la conversation autour du projet.

Quelles sont les licences ?

Deux composants, deux licences :

  • Takuto Core (le moteur que vous auto-hébergez) est sous licence AGPL-3.0. L’auto-hébergement est gratuit. Si vous proposez Takuto Core comme service à des tiers, l’AGPL vous oblige à publier l’intégralité de votre pile en open source. Si ces termes ne correspondent pas à vos besoins, écrivez à morphet.contact@gmail.com — avec plaisir pour en discuter.
  • Le Takuto CLI (l’outil de setup compagnon) est sous licence MIT.

Les sources de Takuto Core sont sur https://github.com/takuto-team/takuto-core ; le CLI est sur https://github.com/takuto-team/takuto-cli.

Collectez-vous des données ou de la télémétrie ?

Non. Takuto Core ne collecte ni ne transmet aucune télémétrie — aucune analyse d’usage, aucun rapport de crash, aucun phone-home. Vous pouvez le vérifier vous-même dans les sources.

Tout le trafic sortant passe par une allowlist : votre site Jira/Atlassian et GitHub, les hôtes d’API des fournisseurs d’IA que vous activez (Claude, Codex/OpenAI et Cursor sont autorisés d’emblée ; OpenCode étant auto-hébergé, c’est plutôt son base_url qui est autorisé), les registres de paquets (npm — ainsi que votre .npmrc — crates.io, nodejs.org), quelques sites de documentation pour développeurs (docs Rust, MDN, Stack Overflow), et AWS STS/SSO pour les exécutions authentifiées sur AWS. Les hôtes des fournisseurs suivent [agent].available_providers — réduisez cette liste pour resserrer le firewall — et vous pouvez ajouter vos propres hôtes avec [network] extra_egress_hosts. Un firewall d’egress (mis en place au démarrage du container) bloque tout le reste par défaut. Le contenu de vos tickets, votre code source et vos prompts ne sont envoyés qu’au fournisseur d’IA que vous avez choisi — Takuto Core lui-même ne les voit jamais. Et comme il tourne en local ou sur votre propre serveur, vous pouvez le faire tourner entièrement auto-hébergé (ou même le pointer sur un modèle auto-hébergé) pour que rien ne quitte du tout votre infrastructure.

Comment est-il isolé ? Est-il sûr de faire tourner des agents en autonomie ?

L’isolation est un objectif de conception central :

  • Chaque agent tourne dans son propre container, donc le rayon d’impact d’une attaque par prompt injection est limité à ce container.
  • L’allowlist du firewall d’egress restreint ce que n’importe quel agent peut atteindre sur le réseau.
  • La protection de branche est requise — les agents poussent des branches et ouvrent des PR, ne commitent jamais sur main. Combiné à des tokens à portée limitée (un PAT GitHub fine-grained, un compte de service Jira limité), cela borne ce qu’une session détournée peut réellement faire.

Takuto Core ajoute un encadrement explicite du contenu non fiable autour du texte des tickets et des plafonds d’octets optionnels, ce qui réduit le risque de prompt injection sans l’éliminer — la revue de code humaine sur les PR reste votre filet de sécurité.

Quels agents IA sont pris en charge ?

  • Claude Code
  • Cursor Agent
  • Codex
  • OpenCode (pour les modèles auto-hébergés uniquement)

Vous choisissez le fournisseur dans Configuration → AI Settings ; chacun a ses propres réglages [agent.providers.<name>]. Voir la référence de configuration.

De quel matériel ai-je besoin ?

Ces chiffres sont des estimations approximatives, pas des exigences strictes — vos besoins réels dépendent du projet, de votre fournisseur et de votre niveau de concurrence. À titre de repère, l’auteur développe et fait tourner Takuto Core sur un Apple M1 Pro avec 16 Gio de RAM.

  • RAM : ≥ 8 Gio pour un seul workflow ; ≥ 12 Gio sur macOS avec Podman (la VM a besoin de sa propre part). Adaptez avec [general] max_concurrent_workflows.
  • Disque : ≥ 30 Gio libres — les worktrees, les caches npm/cargo, les toolchains mise et la couche Docker-in-Docker optionnelle vivent tous dans des volumes Docker.
  • OS : un hôte Linux est recommandé pour les déploiements serveur ; macOS convient bien pour un usage local.
  • Les modèles auto-hébergés demandent considérablement plus — dimensionnez le GPU/VRAM au modèle que vous comptez servir.

Où aller ensuite ?