Orchestrez des débats entre IA.

Soumettez une question technique à deux agents IA. Ils débattent, argumentent, se corrigent. Palabre invoque directement les CLIs présents sur votre machine et synthétise consensus, désaccords et actions concrètes.

Démarrer

Voir sur GitHub

npm

$npm install -g palabre

terminal

$ palabre gemini-claude "Faut-il migrer vers TypeScript strict ?" -t 4

┌─ Palabre ───────────────────────────────────────────────

│ Sujet: Faut-il migrer vers TypeScript strict ?

│ Agents: gemini <-> claude

│ Tours: 4 | Synthese: claude

└─────────────────────────────────────────────────────────

◆ gemini · reviewer · tour 1/4

────────────────────────────────────────────────────────────

Oui, quasi-indispensable pour la maintenabilité. strictNullChecks est le gain le plus immédiat : il force à gérer null/undefined explicitement, une classe entière de bugs disparaît. noImplicitAny améliore l'auto-complétion et fait du code une documentation vivante.

Sur le legacy existant : approche flag par flag avec ts-migrate plutôt qu'un Big Bang. Vrai risque : une migration forcée sans formation mène à l'abus de "as any", annulant tous les bénéfices.

Claude, quel est ton avis sur l'équilibre entre rigueur et vélocité lors de la transition ?

◆ claude · reviewer · tour 2/4

────────────────────────────────────────────────────────────

Globalement d'accord avec Gemini. Sur le "dernier kilomètre" du legacy stable : ne pas chercher 100%. @ts-expect-error + ESLint ban-ts-comment sur les nouveaux fichiers bloque la dette future sans réécrire l'existant -- le ratio effort/bénéfice s'effondre sur du code figé.

Sur l'abus de "as any" : c'est un problème de revue de code, pas de stratégie de migration. Si l'équipe contourne, c'est que le pourquoi du strict n'a pas été vendu.

Je préfère strict: true en bloc dès le départ sur les nouveaux modules, séparés dans leur propre tsconfig. Ça évite une config hybride illisible. La valeur du strict dépend aussi du turnover : sur une équipe qui change, c'est de la documentation exécutable.

◆ gemini · reviewer · tour 3/4

────────────────────────────────────────────────────────────

Je te rejoins sur l'isolation par modules -- plus sain que polluer le tsconfig global. TS 5.x satisfies réduit la friction : il valide une contrainte sans perdre l'inférence originale, rendant le mode strict moins punitif.

Deux points à trancher. D'abord : gérer plusieurs tsconfig ou des Project References introduit une friction réelle dans le pipeline CI -- est-ce que le gain justifie ce surcoût ?

Ensuite : avec Copilot/Cursor omniprésents, une partie du ROI du mode strict n'est-elle pas déjà captée par l'IA ? Et l'épuisement cognitif sur des types imbriqués complexes -- où place-t-on le curseur entre sécurité et agilité créative ?

◆ claude · reviewer · tour 4/4

────────────────────────────────────────────────────────────

Sur les Project References : le surcoût est réel mais souvent surestimé. Un tsconfig.new.json hérité avec include restreint, c'est 10 lignes. Un fichier truffé de @ts-expect-error sans convention, lui, grossit sans friction visible -- et c'est exactement ce qu'on rate en revue.

Sur l'IA : Copilot/Cursor opèrent localement dans leur fenêtre de contexte. Le mode strict garantit des invariants à l'échelle du graphe de types entier. Complémentaires, pas substituables -- un typage strict améliore même la qualité des suggestions.

Sur l'épuisement cognitif : c'est le seul point où je concède vraiment. Ma réponse : dossiers experiments/ avec tsconfig permissif, jamais importés en prod. L'agilité créative et la rigueur ne partagent pas le même périmètre.

◆ Synthese · claude · reviewer

────────────────────────────────────────────────────────────

Consensus

- strict: true justifié pour tout code nouveau ou en évolution active.

- Pas de Big Bang sur le legacy stable : @ts-expect-error ciblés + ban-ts-comment en CI.

- Nouveau code = strict: true en bloc, isolé dans son propre tsconfig.

- satisfies (TS 5.x) réduit la friction en préservant l'inférence.

- L'abus de any est un problème de revue, pas un argument contre la migration.

- L'IA est complémentaire : elle opère localement, le typage opère globalement.

Desaccords

Activation des flags

gemini : un par un (noImplicitAny puis strictNullChecks)

claude : strict: true en bloc sur les nouveaux modules dès le départ

Surcoût des Project References

gemini : friction réelle à ne pas sous-estimer dans le pipeline

claude : souvent surestimé, moins visible que la dette @ts-expect-error

Actions proposees

1. Activer strict: true sur tout nouveau module dès maintenant.

2. Créer tsconfig.strict.json + ajouter ban-ts-comment en erreur sur ces périmètres.

3. Legacy : inventorier les fichiers qui bougent encore et les migrer en priorité.

4. Dossier experiments/ avec tsconfig permissif, jamais importé en prod.

5. Définir en équipe la frontière code exploratoire / production (ADR ou README).

Exported → ./2026-05-05-typescript-strict.debate.md

Comment ça fonctionne

De la question à la synthèse, en quelques secondes.

Définissez un sujet

Formulez votre question (choix d'architecture, stratégie de refactoring, comparaison d'approches) et désignez les deux agents qui vont en débattre.

Le débat s'engage

Palabre orchestre les échanges en alternance. Chaque agent argumente, critique et affine sa position sur la base des réponses précédentes.

Récupérez la synthèse

À l'issue des échanges, Palabre produit un résumé consolidé et exporte le transcript complet dans un fichier .debate.md.

Tout ce qu'il faut, rien de plus

Intégration native CLI

Palabre invoque directement les CLIs présents sur votre machine : Claude Code, Codex, Gemini CLI, Ollama. Aucune couche d'abstraction, aucun wrapper.

Aucune configuration d'authentification

Chaque agent utilise son propre mécanisme d'authentification. Si un CLI fonctionne dans votre terminal, il fonctionne avec Palabre.

Rôles configurables

Assignez un rôle à chaque agent (implementer, reviewer, critic, architect) pour orienter la dynamique du débat.

Modèles locaux via Ollama

Combinez un agent cloud avec un modèle local pour des sessions plus économiques. Les agents Ollama participent au même titre que Claude ou Codex.

Injection de contexte

Transmettez votre code source via --files ou --context. Les agents débattent sur la base de votre codebase réelle.

Export Markdown

Chaque session produit un fichier .debate.md structuré, incluant le transcript complet, les métadonnées et la synthèse finale.

Faites débattre vos agents IA.

Installez Palabre et obtenez une synthèse argumentée en quelques secondes.

Démarrer Voir sur GitHub