Claude et Qwen : planification coûteuse, implémentation moins chère

Un modèle puissant conçoit, un modèle moins cher code

Je répartirais le travail ainsi : Claude ou Codex analyse les exigences, construit un plan et vérifie le résultat, tandis que Qwen effectue l’essentiel des modifications. Il ne s’agit pas d’un remplacement universel d’un modèle coûteux, mais d’un routage des tâches selon leur complexité.

Le projet public claude-qwen-hybrid décrit un pipeline presque identique. Claude Code produit un plan JSON structuré, puis un modèle local exécute les étapes, travaille avec le dépôt et lance les vérifications.

L’économie ne vient pas du fait que le modèle le plus puissant cesse de voir le contexte. Elle provient de la réduction de ses coûteux tokens de sortie et de ses cycles avec outils. Dans l’exemple publié, le planificateur a utilisé 540 tokens de sortie et 10 666 tokens d’entrée mis en cache, pour un coût estimé à $0.0113 au moment du rapport. C’est un cas précis, pas une promesse de prix pour tous les dépôts.

L’artefact essentiel n’est ni le prompt ni un long historique de conversation, mais le contrat de transmission de la tâche. Il doit préciser le périmètre des changements, les interfaces, les invariants, les critères d’acceptation, les commandes de validation et les conditions de retour à la planification.

• Claude ou Codex : architecture, découpage, risques et revue finale.
• Qwen : modifications limitées, tests, changements répétitifs et corrections suivant des remarques précises.
• Passerelle automatisée : formatage, typage, tests, contrôles de sécurité et suivi des fichiers modifiés.

Les benchmarks n’apportent qu’un soutien indirect à ce schéma. Sur la page officielle de Qwen3.7, l’équipe Qwen indiquait 80,4 % pour Qwen3.7-Max sur SWE-Verified, contre 80,8 % pour Opus 4.6 Max cité sur cette page. Ce sont des données du fournisseur et elles ne mesurent pas l’intégrité architecturale d’un grand projet.

La qualité de transmission du contexte détermine l’économie

L’approche hybride est efficace pour les tâches modulaires avec de bons tests, mais s’effondre vite lorsque des décisions architecturales doivent être prises à chaque étape. La panne la plus dangereuse semble anodine : l’exécutant satisfait des critères locaux tout en éloignant le code de la conception globale.

Je suivrais d’abord le nombre de revues répétées, la part des changements acceptés et les défauts après fusion, plutôt que le coût des tokens. Si Claude ou Codex réécrit régulièrement l’implémentation de Qwen, l’économie n’existe que dans un tableur.

Il existe aussi un coût opérationnel : isolation des correctifs, commandes autorisées, délais d’expiration, filtrage des secrets et retour arrière après un contrôle échoué. Sans ces garde-fous, un exécutant local n’est moins cher que jusqu’au premier incident coûteux.

Ce pipeline ressemble moins à une compétition entre modèles qu’à un compilateur avec un frontend coûteux et une exécution économique. Une question demeure : jusqu’où peut-on compacter le plan avant de perdre le contexte même qui justifiait l’appel au modèle puissant ?

Nous avons déjà expliqué comment des agents Claude Code parallèles peuvent examiner des pull requests et détecter des conditions de course dans les processus d’ingénierie. Cette approche complète une configuration LLM hybride en montrant où Claude peut apporter une supervision structurée du travail d’implémentation.