Sur petit modèle local, le harnais léger gagne

L'article Harness Design for Long-Running Agentic Applications d'Anthropic pose un principe fort : à mesure que les modèles s'améliorent, on retire du harnais, pas l'inverse. J'ai voulu vérifier ce principe sur l'autre bout du spectre. Pas sur Opus, sur un modèle open-weight local, sur une RTX 2060 à 300 €. La leçon est plus dure encore : sur un petit modèle, un harnais dirigiste ne rate pas seulement la cible : il l'éloigne.

Le banc, en trois lignes

Hardware : NVIDIA RTX 2060, 6 Go de VRAM, 64 Go de RAM, 6 cœurs physiques / 12 threads. Système : Windows 11, 100 % offline, llama.cpp + llama-swap. Tâche-étalon : « crée un démineur jouable dans le navigateur » : succès visible immédiatement, échec impossible à maquiller.

Modèles servis pendant la campagne (banc historique) : un petit modèle dense de 4B (Gemma 4 E4B, Q4, ~5 Go, tout en VRAM), et un MoE 26B à 4B actifs (Gemma 4 26B-A4B, Q4, ~16 Go, experts en RAM via --cpu-moe). Aujourd'hui notre banc tourne majoritairement sur ornith et aganta1 (35B Q8), mais la démonstration ci-dessous porte sur les modèles les plus contraints : c'est là que le harnais fait la différence de manière la plus visible.

Run 1 : harnais dirigiste, échec propre

Premier essai avec un harnais qui décompose la tâche, impose des phases, ajoute des « portes de preuve » entre chaque étape. Le réflexe intuitif : encadrons bien le petit modèle, sinon il va se perdre. Bilan brut :

• 5 643 lignes de log de session ;
• ≈ 356 appels d'outils passés par le modèle ;
• résultat : boucle infinie, zéro démineur produit.

En lisant les traces, le mécanisme d'échec est net : le harnais a poussé le modèle à se générer un critère de validation impossible (chercher une classe CSS .revealed sur une page qui n'en a pas), puis la porte de vérification a rejeté la sortie encore et encore. 356 décisions, le même raisonnement répété cinq fois, jamais terminé. Un run précédent d'esprit similaire : 291 décisions du modèle en ≈ 20 minutes, sans jamais aboutir.

Run 2 : harnais léger, réussite tranquille

Deuxième essai avec un harnais réduit à sa forme la plus dénudée : une boucle tool-use pure : écrire, exécuter, vérifier, et le modèle décide de la séquence. Aucune phase imposée, aucune porte de preuve, aucun rail. Bilan :

• 699 lignes de log ;
• ≈ 30 appels d'outils ;
• résultat : démineur HTML fonctionnel : 100 cases, flood-fill sur un clic (43 cases révélées d'un coup dans un test), clic droit pour drapeau, zéro erreur console.

Le modèle a même repéré et corrigé lui-même une erreur (document is not defined quand la vérif tentait de tourner sous Node) : il a pivoté vers une vérif navigateur, tout seul, sans que le harnais ne l'y pousse.

La math d'erreur composée

Pourquoi le harnais dirigiste dessert-il un petit modèle ? Une arithmétique très simple. Découper une tâche en 8 sous-étapes suppose que le modèle sait décomposer ET exécuter chaque atome. Or les erreurs par étape se composent multiplicativement :

• modèle fiable à 99 % par étape → 0,99⁸ ≈ 92 % → découper aide ;
• modèle fiable à 85 % par étape → 0,85⁸ ≈ 27 % → découper empire.

Le résultat est symétrique de ce qu'Anthropic constate côté modèles frontier : la complexité utile du harnais dépend du plancher de fiabilité du modèle. Au-dessus d'un seuil, découper fait converger. En-dessous, découper multiplie les endroits où échouer.

Cette symétrie a une conséquence pratique : la meilleure façon de fiabiliser un petit modèle, ce n'est pas de lui imposer un rail. C'est de lui donner de bons outils (find_files, read_file, run_shell, check_interactive) et un oracle pas cher qui lui rend une erreur utile quand il se trompe. Le harnais outille, il ne pilote pas.

Le 12 juin, ou pourquoi ce n'est pas qu'une question technique

Cette histoire de harnais léger, on pourrait la lire comme une note technique. Elle est aussi une note de résilience. Le 12 juin 2026, le gouvernement américain a suspendu à 17 h 21 (heure de l'Est) l'accès aux modèles Fable 5 et Mythos 5 d'Anthropic : au motif d'un « jailbreak » que Anthropic elle-même a décrit comme narrow, non-universal. Le prompt du jailbreak ? Demander au modèle de lire un codebase et corriger les failles. Autrement dit : un usage normal de développeur.

Le sens de cet incident, indépendamment de qui a raison sur le fond, est simple : quand tu dépends exclusivement d'un fournisseur central, tu peux te retrouver coupé de ton outil en une décision administrative que tu n'as pas vu venir. Anthropic est un « bon élève » : américain, aligné, transparent, safety-first, et ça n'a pas suffi à protéger la disponibilité de ses propres modèles cinq heures.

Le retournement, c'est ce qui rend l'argument fort : le seul outil qui a fonctionné pour Anthropic dans cet épisode, c'est la transparence publique (statement immédiat, mobilisation, discussion ouverte). Concentrer le pouvoir de déploiement dans quelques acteurs les rend fragiles à l'arbitraire ; distribuer via des poids ouverts et un audit par pairs, c'est précisément la résilience.

Open-weight comme assurance, pas comme religion

On ne fait pas de l'open-weight contre Claude. On utilise Claude en production sur plusieurs déploiements clients, et on continuera. On fait de l'open-weight en complément : sur notre banc R&D Loom, aujourd'hui public sous licence MIT sur github.com/Tough-Respawn/loom : parce que trois choses valent d'être vérifiées par la pratique, pas par le discours :

• que le harnais peut tenir seul, sans dépendance à un fournisseur unique ;
• que la qualité open-weight (GLM 5.2, Kimi K3, Qwen, Gemma, DeepSeek) est réelle, pas hypothétique ;
• que la souveraineté du code : faire tourner l'agent sur ta machine, tes données, tes règles : n'est pas un caprice mais une exigence tenable.

Ces trois vérifications ne remplacent pas Claude ; elles font que Claude reste un choix, pas une nécessité. C'est la différence entre un fournisseur et une dépendance.

Ce qu'on retient

Deux règles, une posture.

• Règle 1 : sur un modèle sous son seuil de fiabilité, un harnais léger bat un harnais dirigiste. Décomposer ne fiabilise pas : décomposer transforme un modèle imparfait en cascade de points de rupture.
• Règle 2 : la complexité utile du harnais est inversement proportionnelle à la capacité du modèle. Plus le modèle progresse, plus on retire. Plus le modèle est modeste, plus il faut outiller : pas orchestrer.
• Posture : la meilleure gouvernance de l'IA est celle qui est libre et partagée. Merci à GLM, Kimi, Gemma, Qwen, DeepSeek. Sans eux, le marché frontier serait un monopole, et « on vous protège » deviendrait sans contre-pouvoir.

Pour la suite : nous avons commencé à contribuer en amont à llama.cpp, avec une première PR ouverte sur le repo ggml-org/llama.cpp. C'est le sujet de la prochaine note.