Audit de harnais IA : pourquoi le harnais compte plus que le modèle

Cela fait des mois que je martèle la même idée, avec mes clients et pour moi-même : le modèle n’est pas le problème. Vous passez d’Opus à Sonnet, de Sonnet à un autre, et cette sensation de « ça marche une fois sur deux » reste là. Ce n’est pas un meilleur modèle qui casse la loterie. C’est le harnais : l’ensemble de fichiers, de règles, de scripts et de sous-agents qui vivent dans votre dépôt et forcent le modèle à aller dans la bonne direction.

J’ai récemment audité mon propre harnais avec une méthode que j’appelle harness-audit. Ce que j’y ai trouvé a changé ma façon de travailler — et, très concrètement, a fait baisser ma facture de tokens. Voici l’essentiel pour un entrepreneur : ce qu’est un harnais, pourquoi il compte plus que le modèle, et comment mesurer le vôtre.

Le point de départ Le modèle est le cheval, le harnais ce sont les rênes

Un LLM seul est un cheval puissant mais imprévisible : il génère des milliers de lignes, prend des décisions erratiques, finit là où vous ne vouliez pas. Le harnais, ce sont les rênes. Sans harnais, chaque session est une loterie ; avec harnais, c’est un processus reproductible.

Cela a une conséquence commerciale que presque personne ne nomme :

Le modèle est une commodité qui change tous les trois mois. Le harnais que vous construisez par-dessus vous appartient et reste.

— le principe qui structure tout andrami

Quand le prochain modèle arrive, vous changez le cerveau de votre système en une après-midi. Vos processus, vos règles, votre piste d’audit restent intacts. C’est pourquoi, dans l’approche d’andrami, la question n’est jamais « quelle IA choisir ? », mais « quelle infrastructure bâtir pour ne dépendre d’aucune ? ».

Pourquoi les prompts ne suffisent pas Le contexte se dégrade bien avant d’être plein

L’intuition courante : « avec un million de tokens de contexte, on est tranquilles ». Faux. La qualité commence à se dégrader vers 20 % d’utilisation du contexte et devient critique entre 40 et 48 %. Remplir la fenêtre ne vous rend pas plus intelligent : cela vous rend plus cher et plus erratique.

Autre piège, celui du « plus, c’est mieux ». Quand Vercel a repensé son agent D0, ils ont retiré des outils au lieu d’en ajouter : de 16 outils à essentiellement Bash + le système de fichiers. Résultat : 3× plus rapide, 47 % de tokens en moins, et un taux de réussite passé de 80 % à 100 %.

La méthode Les quatre piliers d’un harnais sain

harness-audit évalue quatre choses. Ce n’est pas de la théorie : chacune se traduit par des fichiers concrets dans le dépôt.

1. Le harnais dans le code. Un point d’entrée portable (AGENTS.md, ≤ 200 lignes), un script de preflight qui valide avant chaque commit, des conventions de mémoire. Si votre savoir vit dans la tête d’une personne et non dans le dépôt, vous n’avez pas de harnais.
2. La séparation des rôles (multi-agents). Un implémenteur qui écrit et un relecteur qui audite — et qui est indépendant : il reçoit le résultat, jamais le raisonnement de celui qui l’a écrit. Cette indépendance est la clé du chiffre suivant.
3. La vérification automatique. Lint, types, tests qui échouent quand le code casse (pas des tests de façade). L’agent ne termine pas parce qu’il dit avoir terminé ; il termine quand le harnais a pu valider qu’il a terminé.
4. Le loop design. Une grille d’évaluation exécutable, des conditions d’arrêt explicites et une mémoire qui mûrit. C’est le pilier le plus récent et celui qui rapporte le plus.

Le chiffre qui justifie le relecteur indépendant

Quand un modèle se relit lui-même, il a juste à 62 % — et 28 % de ses validations de « code correct » sont en réalité fausses. Presque 1 sur 3. Quand la relecture est faite par un sous-agent indépendant, la justesse monte à 89 % et les faux positifs tombent à 7 %.

27 points de précision ne viennent pas d’un modèle plus gros. Ils viennent du fait de séparer celui qui écrit de celui qui vérifie.

Le changement de paradigme D’écrire des prompts à concevoir des loops

L’ancien flux : un humain écrit un prompt détaillé → le modèle répond → l’humain évalue → on recommence. Le nouveau est différent :

Vous concevez un objectif, une grille, un vérificateur et une mémoire. Le modèle tourne seul. L’environnement lui renvoie un feedback (tests, commandes, métriques). Le modèle se corrige. On recommence jusqu’à ce que la grille converge ou qu’une condition d’arrêt se déclenche.

La compétence n’est plus d’écrire le prompt parfait. C’est de concevoir le loop. Et il y a un risque qu’il vaut mieux dire tout haut : une mauvaise grille avec un excellent modèle produit un loop sûr de lui et faux. La grille fait plus de travail que le modèle.

La mémoire, elle aussi, mûrit par étapes : de noter « j’ai essayé X et ça n’a pas marché », à expliquer pourquoi ça a échoué, à marquer des faits comme vérifiés, à les distiller en règles générales, et enfin à les consulter avant d’agir. Dans les tests, les agents qui atteignent cette dernière étape — consulter leur propre mémoire — passent de 60 % à 91 % de réussite entre les premières et les dernières sessions. Ceux qui en restent à « noter les échecs » ne progressent jamais.

Ce qui me fait économiser Comment le harnais réduit la facture de tokens

Voici la partie qui intéresse vraiment un entrepreneur. Un harnais bien conçu économise de trois façons, et je les ai mesurées sur mon propre travail :

• Un modèle par rôle, pas un modèle pour tout. Je répartis le travail en 10/80/10 : le premium —son cerveau, aujourd’hui Fable 5— planifie et relit les extrémités où une décision change tout ; le workhorse, rapide et bon marché (Opus 4.8), avale les 80% d’exécution ; et un modèle minimal (Haiku) fait tourner les vérifications mécaniques, le preflight. Je ne paie pas un cerveau cher pour taper du boilerplate. Quand les modèles changent, je change la répartition ; le harnais, lui, reste.

• Moins de tours à vide. Chaque session-loterie qui finit en « presque, mais non » se paie en tokens. La vérification automatique coupe ces tours : le loop n’avance pas avec du code cassé, donc je ne brûle pas de contexte à courir après un bug qu’un test aurait attrapé gratuitement.
• Un contexte discipliné. Des sessions courtes et une mémoire consultable plutôt que de traîner 200k tokens dégradés. Moins de remplissage, moins de coût, meilleure qualité.

Quoi en faire Votre code IA : harnais ou loterie ?

Si votre équipe utilise déjà Claude Code, Cursor ou équivalent en production et que la sensation est l’inconsistance — parfois brillant, parfois désastre — le problème n’est presque jamais le modèle. C’est qu’il n’y a pas de harnais, ou que celui qui existe est gonflé et sans vérification.

La bonne nouvelle : c’est mesurable. Vous pouvez auditer le vôtre — AGENTS.md (ou son absence), séparation des rôles, ce qui est réellement vérifié, si la mémoire est consultée — et repartir avec un plan de remédiation concret. C’est exactement ce que je fais dans une Radiographie de code IA, et le premier diagnostic prend quelques minutes.

Les modèles continueront de tourner tous les trois mois. Le harnais que vous bâtissez, lui, reste. Commençons par savoir où en est le vôtre.

Prenez-le Le skill harness-audit, en open source

La méthode de cet article vit sous la forme d’un skill Claude Code que vous pouvez lancer dans votre propre dépôt : il audite votre harnais selon les quatre piliers et vous renvoie une grille exécutable avec un plan de remédiation. Je l’ai ouvert sur GitHub — dites-moi où vous l’envoyer et je vous montre le lien pour le consulter et le cloner.