Face à un résultat incorrect produit par une IA, le réflexe quasi universel est le même : réécrire le prompt, changer de modèle, puis basculer sur une fenêtre de contexte plus large.
Pourtant, le problème persiste. Le modèle continue d'oublier des instructions, d'appeler les mauvais outils, de sauter les étapes de vérification ou de valider avec assurance un travail dysfonctionnel.
Pourquoi ? Parce que le problème ne réside pas dans les poids du modèle (weights). Le problème réside dans son environnement d'exécution.
Cet environnement, c'est le Harness (le "harnais" ou le cadre d'exécution). L'art de le concevoir et de l'optimiser s'appelle le Harness Engineering.
Comme le soulignait Dario Amodei lors du lancement de Claude Code :
« Évidemment, vous avez besoin d'une interface, vous avez besoin d'un harnais pour les utiliser. »
Le modèle agit comme un moteur de raisonnement : il prédit la prochaine étape logique, mais il est incapable de bâtir un système d'exploitation stable par lui-même. C'est le harnais qui pilote ce que le modèle lit, les outils qu'il peut déclencher, les données qui survivent aux réinitialisations de contexte et le moment précis où l'exécution doit s'arrêter.
- Le Prompt Engineering ajuste la formulation de la requête.
- Le Harness Engineering construit l'infrastructure dans laquelle cette requête s'exécute.
Placez un modèle de pointe (frontier model) dans une interface de chat vide : vous obtiendrez de la prose fluide mais superficielle. Placez ce même modèle dans un dépôt de code doté d'un accès terminal, de suites de tests automatisées, d'une cartographie du projet et d'espaces de travail isolés : il livrera un logiciel fonctionnel et prêt pour la production. Les poids du modèle n'ont pas changé. Le harnais a tout changé.
Les 3 couches d'un système IA fiable
On oppose souvent les chaînes de prompts (prompt chains), les boucles d'agents (agent loops) et les graphes multi-agents (multi-agent graphs). En réalité, il s'agit des trois couches complémentaires d'un même système.
+-------------------------------------------------------+ | 3. Graph Layer (Allocation du travail & Rôles) | +-------------------------------------------------------+ | 2. Loop Layer (Validation mécanique & Capteurs) | +-------------------------------------------------------+ | 1. Harness Layer (Environnement, Mémoire & RAM/CPU) | +-------------------------------------------------------+
1. La couche Harness (Environnement et Mémoire)
Le harnais englobe tout ce qui existe en dehors du modèle. Il gère l'accès au système de fichiers, les variables d'environnement, les jetons d'authentification et les fichiers persistants.
Andrej Karpathy en a résumé le modèle mental :
- Le modèle est le CPU.
- La fenêtre de contexte est la RAM.
Un CPU brut sans stockage ni système d'exploitation plante instantanément. Lorsque vous injectez vingt pages de contexte dans un seul prompt, vous saturez la RAM, et le modèle perd l'attention sur les règles critiques. Un harnais propre conserve la connaissance du projet dans des fichiers Markdown externes et ne charge en RAM que l'extrait exact nécessaire à l'étape en cours.
2. La couche Loop (Preuve et Convergence)
Demander à un modèle "Es-tu sûr que ce code est correct ?" crée une boucle d'hallucination circulaire. Le modèle évalue sa propre prédiction probabiliste et confirme son biais initial.
La couche Loop introduit des capteurs objectifs :
- Exécuteurs de tests (
pytest,vitest,cargo test) - Validateurs de format (validateurs de schémas JSON, linters)
- Budgets d'exécution (limite fixée à 4 tentatives maximum avant escalade humaine)
Le modèle propose une correction, le harnais exécute le test et réinjecte la sortie brute du terminal. L'exécution ne se poursuit que si une preuve mécanique valide le correctif.
3. La couche Graph (Allocation du travail)
Les tâches complexes s'effondrent lorsqu'elles sont forcées dans un fil de discussion unique. La couche Graph distribue le travail à travers des contextes d'exécution isolés :
- Agent A (Analyste) : Analyse la tâche et rédige le plan d'implémentation.
- Agent B (Développeur) : Écrit le code dans une branche/dossier isolé.
- Agent C (Relecteur) : Inspecte le diff face aux exigences initiales.
Le contexte reste propre : aucun prompt unique ne porte le poids de tout le cycle de vie du projet.
Les 5 piliers d'un Harness IA efficace
Il n'est pas nécessaire de déployer une plateforme d'entreprise complexe pour appliquer ces principes. Un harnais personnel s'appuie sur 5 règles mécaniques au quotidien :
1. Transformer chaque requête en un contrat délimité
Sans cadre strict, un modèle confronté à une ambiguïté redéfinit silencieusement le succès pour résoudre un problème plus simple et déclarer victoire. Un contrat d'exécution impose des limites fermes avant le début de la génération :
- Livrables : Nom de fichier et format exacts.
- Contraintes : Dépendances autorisées, standards de style, budget de tokens.
- Périmètre exclu (Non-Goals) : Liste explicite des éléments auxquels le modèle ne doit pas toucher.
- Critères d'acceptation : Conditions matérielles requises pour clôturer la tâche.
2. Fournir une carte, pas une encyclopédie
Injecter l'intégralité d'une documentation dans le chat dilue l'attention et consomme des tokens inutilement. La bonne approche consiste à fournir une carte racine compacte indiquant l'emplacement des documentations, schémas et fichiers sources. Le modèle consulte la carte, identifie le fichier pertinent et lit uniquement celui-ci.
3. Externaliser la mémoire dans des fichiers durables
Le fil de discussion est une zone de travail temporaire, pas une base de données. Conservez les décisions d'architecture, les préférences et les bugs non résolus dans des fichiers dédiés au niveau du projet (comme un fichier CLAUDE.md ou .cursorrules). À l'ouverture d'une nouvelle session, le modèle lit le fichier et reprend immédiatement le travail sans perte de contexte.
4. Placer des capteurs avant de donner de l'autonomie
Dire à un modèle "Écris du code sans bug" ne produit aucun effet garanti. Lui fournir une commande qui renvoie un code de sortie 0 ou une trace d'erreur (stack trace) lui donne une réalité tangible. Les linter, compilateurs et tests automatisés créent la preuve objective sur laquelle le harnais s'appuie pour valider ou rejeter le résultat.
5. Appliquer la règle du double encodage (Dual-Encoding)
Rédiger une règle en langage naturel laisse une marge d'erreur probabiliste. Le double encodage résout ce problème en deux temps :
- Instruction textuelle : Expliquer la règle dans le prompt pour orienter l'intention du modèle.
- Barrière mécanique : Configurer une restriction système (ex: restreindre les permissions du terminal pour qu'un
rm -rflève une erreur système).
Micro-Harnais prêt à l'emploi : HARNESS.md
Voici une structure de harnais prête à être copiée à la racine de vos dépôts, projets Claude ou espaces Cursor dans un fichier HARNESS.md :
# Contrat d'Exécution du Projet ## Limites Opérationnelles - Périmètre autorisé : Modifier uniquement les fichiers explicitement assignés à la tâche en cours. - Actions interdites : Ne jamais supprimer de tests existants, ne jamais ajouter de dépendances non vérifiées. ## Cartographie du Projet - /src : Code source de l'application - /tests : Suites de tests de validation - /docs/decisions.md : Journal des choix d'architecture validés ## Protocole de Vérification Avant de marquer une tâche comme terminée, exécuter ces vérifications dans l'ordre : 1. Linter local : `npm run lint` 2. Suite de tests : `npm test` 3. Validation de format : Vérifier que la sortie respecte le schéma demandé. ## Escalade en Cas d'Échec Si un test échoue deux fois sur la même erreur : - Interrompre l'édition autonome. - Afficher le journal d'erreur exact. - Expliquer le correctif proposé et attendre la confirmation de l'utilisateur.
Le Workflow à deux passes (Two-Pass Prompting)
Pour les tâches de raisonnement complexes, séparez la phase de création de la phase de critique :
- Passe 1 : L'Exécution
"Rédige la spécification technique de [Fonctionnalité X] en respectant les contraintes de
HARNESS.md. N'évalue pas ton propre résultat pour l'instant. Fournis le brouillon brut et liste toutes les hypothèses prises." - Passe 2 : La Relecture Adversariale
"Examine le brouillon ci-dessus comme un relecteur sénior critique. Vérifie les points de défaillance suivants : 1) Les cas limites sont-ils traités ? 2) La logique introduit-elle des dépendances superflues ? 3) La solution viole-t-elle une contrainte de
HARNESS.md? Rédige la version révisée en corrigeant ces écarts."
Pourquoi l'ingénierie de harnais s'amortit dans le temps
Les modèles d'IA évoluent tous les quelques mois, rendant les prompts complexes rapidement obsolètes. En revanche, le Harness Engineering pérennise vos investissements techniques.
Lorsque les fournisseurs publient une nouvelle génération de modèles, vos suites de tests, vos cartes de projet, vos limites de permissions et vos fichiers d'état restent parfaitement valides. Le modèle fournit la puissance de calcul cognitif brut ; le harnais fournit les rails qui créent une exécution fiable et déterministe.
Par Aghilas AZZOUG