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 en source ouverte (source-available) sous FSL-1.1-ALv2 et le Takuto CLI sous MIT : vous êtes donc libre de le faire tourner, de le modifier et de l’auto-héberger pour tout usage non concurrent. Aucune télémétrie, rien qui ne « téléphone à la maison ».

La seule limite à connaître : la FSL interdit l’usage concurrent — vous ne pouvez pas vous servir de Takuto Core pour proposer un produit ou un service hébergé concurrent. L’usage interne, l’évaluation et le travail pour des clients via des services professionnels sont tout à fait permis, et chaque version bascule sous Apache-2.0 deux ans après sa sortie. 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 en source ouverte (source-available), 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 en source ouverte (source-available) sous la Functional Source License 1.1 (FSL-1.1-ALv2) : libre pour tout usage non concurrent, et chaque version bascule sous Apache-2.0 deux ans après sa sortie. Vous ne pouvez pas vous en servir pour proposer un produit ou un service hébergé concurrent. 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 un firewall d’egress qui bloque tout par défaut et n’ouvre que ce dont une exécution a besoin — votre/vos fournisseur(s) d’IA, GitHub/Jira et les registres de paquets (ajoutez-en avec [network] extra_egress_hosts). 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 avec un modèle auto-hébergé, rien ne quitte 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.
  • Le firewall d’egress limite ce que n’importe quel agent peut atteindre sur le réseau. L’allowlist par défaut bloque tout sauf les hôtes nécessaires à une exécution — le réglage le plus strict, mais énumérer chaque hôte devient vite pénible avec des services derrière un CDN comme GitHub. Quand c’est impraticable, [network] allow_all_https autorise tout le HTTPS sortant à la place ; combiné à l’isolation par container ci-dessus, cela reste une posture saine.
  • 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.

Pourquoi ma connexion à la base de données échoue-t-elle quand j’utilise localhost ?

Takuto tourne dans un container : une chaîne de connexion vers localhost pointe donc vers Takuto lui-même, pas vers votre base de données. Utilisez le nom de service du container de base de données et son port interne sur un réseau Docker partagé (par ex. postgres://…@postgres:5432/…) — et non localhost ni le port publié sur l’hôte. Avec le CLI, choisissez « une base de données dans un container sur cette machine » dans takuto setup et il câble tout cela pour vous. Voir Base de données externe.

L’enregistrement de mon PAT GitHub ou de ma clé d’IA échoue avec une erreur de connexion — mon token est-il erroné ?

En général, non. Valider un token n’atteint qu’un seul endpoint du fournisseur : un échec pointe donc presque toujours vers un problème de réseau/egress plutôt que vers un identifiant invalide — souvent un hôte derrière un CDN comme api.github.com dont les IP changent. Vérifiez que l’allowlist d’egress résout les hôtes actuels du fournisseur, et ajoutez ceux qui manquent avec [network] extra_egress_hosts. Voir Configuration → network.

Mon modèle auto-hébergé renvoie « Model not found » ou des erreurs de contexte.

Deux causes courantes : (1) chargez le modèle sur votre serveur avec la largeur de contexte attendue par Takuto — réglez [agent.providers.opencode] context_limit pour qu’il corresponde à ce que votre serveur sert réellement (LM Studio, par exemple, utilise par défaut 4096, et non 32768) ; et (2) l’identifiant du modèle doit correspondre exactement à l’identifiant d’API du fournisseur. Voir Modèles auto-hébergés.

Mes clés d’API enregistrées ont cessé de fonctionner après avoir réinitialisé un volume Docker.

Les identifiants sont chiffrés avec une clé maîtresse (secret.key) stockée sur le volume takuto-data. Si vous supprimez ou recréez ce volume, les clés scellées avec l’ancienne clé maîtresse ne peuvent plus être déchiffrées — le symptôme est une erreur déroutante d’« authentification » ou de « not found » plutôt qu’une panne cryptographique évidente. Rouvrez les réglages du fournisseur et ressaisissez chaque clé. Pour garder la clé maîtresse stable entre les réinitialisations, provisionnez TAKUTO_SECRET_KEY vous-même au lieu de vous reposer sur la génération automatique.

L’installation du CLI d’agent échoue ou casse au démarrage — que puis-je faire ?

Les CLI d’agent (claude / codex / opencode / cursor) ne sont pas intégrés à l’image — Takuto les installe dans le volume d’outils partagé au premier démarrage d’un container et les rafraîchit vers la dernière version à chaque démarrage. Une version de CLI fraîchement publiée peut donc casser une configuration qui fonctionnait : échecs d’installation, un CLI qui ne se lance plus, ou des changements de comportement à l’exécution.

Si cela vous arrive, épinglez le CLI sur une version connue comme stable via version dans la sous-table de ce fournisseur, pour qu’il cesse de suivre la dernière version :

[agent.providers.claude]
version = "2.1.178"

Cela fonctionne pour les quatre fournisseurs (claude, codex, opencode, cursor). Redémarrez pour que la version épinglée s’installe, puis relevez l’épinglage de façon délibérée une fois une version plus récente vérifiée. Voir Configuration → installation des CLI d’agent & épinglage de version.

À qui les commits et les PR sont-ils attribués — à moi ou à un bot ?

L’attribution suit vos identifiants, de la même façon pour les commits et les pull requests : avec un PAT GitHub, les deux sont attribués à vous ; avec une GitHub App seule (sans PAT), les deux sont attribués au bot. Il n’y a pas de bascule par exécution. Voir GitHub App.

Pourquoi « Marquer comme terminé » ne fait-il pas avancer mon ticket Jira ?

Marquer comme terminé fait passer le ticket à votre [jira] done_status. Cela échoue lorsque le workflow de votre projet Jira n’a aucune transition du statut actuel du ticket vers ce statut, ou lorsque votre token n’a pas la permission de transition. Réglez done_status sur un statut réellement atteignable dans le workflow de votre tableau. (Le nom du statut lui-même est reconnu indépendamment de la langue, donc des noms localisés comme « Terminé(e) » correspondent toujours à « Done ».)

Puis-je héberger Takuto derrière un domaine public ?

Oui. Placez-le derrière un reverse proxy avec TLS (voir Installer Takuto Core) et reposez-vous sur l’authentification multi-utilisateurs intégrée. Comme cette connexion est le point d’entrée et que Takuto ne prend pas encore en charge la 2FA/OTP ni les clés de sécurité (passkeys/WebAuthn), utilisez un mot de passe fort et unique pour chaque compte. Des protections intégrées aident — hachage de mot de passe argon2, verrouillage de compte après plusieurs échecs répétés, et limitation de débit par IP sur la connexion — mais le mot de passe reste votre principale ligne de défense pour l’instant. Gardez la protection de branche et les tokens à portée limitée comme filet de sécurité.

Où aller ensuite ?