Futures
Accédez à des centaines de contrats perpétuels
CFD
Or
Une plateforme pour les actifs mondiaux
Options
Hot
Tradez des options classiques de style européen
Compte unifié
Maximiser l'efficacité de votre capital
Trading démo
Introduction au trading futures
Préparez-vous à trader des contrats futurs
Événements futures
Participez aux événements et gagnez
Demo Trading
Utiliser des fonds virtuels pour faire l'expérience du trading sans risque
Lancer
CandyDrop
Collecte des candies pour obtenir des airdrops
Launchpool
Staking rapide, Gagnez de potentiels nouveaux jetons
HODLer Airdrop
Conservez des GT et recevez d'énormes airdrops gratuitement
IPO Access
Accédez à l'intégralité des introductions en bourse mondiales
Points Alpha
Tradez on-chain et gagnez des airdrops
Points Futures
Gagnez des points Futures et réclamez vos récompenses d’airdrop.
Investissement
Simple Earn
Gagner des intérêts avec des jetons inutilisés
Investissement automatique
Auto-invest régulier
Double investissement
Profitez de la volatilité du marché
Staking souple
Gagnez des récompenses grâce au staking flexible
Prêt Crypto
0 Fees
Mettre en gage un crypto pour en emprunter une autre
Centre de prêts
Centre de prêts intégré
Promotions
Centre d'activités
Participez et gagnez des récompenses
Parrainage
20 USDT
Invitez des amis et gagnez des récompenses
Programme d'affiliation
Obtenez des commissions exclusives
Gate Booster
Développez votre influence et gagnez des airdrops
Annoncement
Mises à jour en temps réel
Blog Gate
Articles sur le secteur de la crypto
AI
Gate AI
Votre assistant IA polyvalent pour toutes vos conversations
Gate AI Bot
Utilisez Gate AI directement dans votre application sociale
GateClaw
Gate Blue Lobster, prêt à l’emploi
Gate for AI Agent
Infrastructure IA, Gate MCP, Skills et CLI
Gate Skills Hub
+10K compétences
De la bureautique au trading, une bibliothèque de compétences tout-en-un pour exploiter pleinement l’IA
GateRouter
Choisissez intelligemment parmi plus de 40 modèles d’IA, avec 0 % de frais supplémentaires
Pourquoi devez-vous apprendre l'ingénierie de l'harnachement ? Analyse complète de 5 produits, 3 écoles de pensée, 5 principes universels
Système décomposé Harness Engineering 5 produits, 3 écoles (OpenAI / Anthropic / ThoughtWorks), 5 principes universels, et pourquoi « Harness déclin » vous oblige à couper la moitié de la conception tous les 6 mois. Cet article est basé sur un article de @sairahul1, compilé et organisé par Dongqu.
(Précédent : Introduction à Harness Engineering (AI Driving Engineering) : Les normes de programmation les plus récentes d'OpenAI, pour atteindre facilement le niveau 1)
(Complément : Le PDG de YC partage ses secrets AI : L’avenir appartient à ceux qui construisent des systèmes d’intérêt composé d’informations)
Table des matières de cet article
Toggle
En février 2026, une petite équipe d’OpenAI a produit 1 million de lignes de code en production.
Ils n’ont pas écrit une seule ligne à la main.
Ce sont des agents IA qui ont écrit.
Ce que les humains ont conçu, c’est le système qui rend l’agent fiable.
Ce système a maintenant un nom — Harness Engineering.
En quelques semaines, Anthropic a publié 3 articles liés. ThoughtWorks l’a organisé en cadre. Philipp Schmid de Hugging Face le qualifie directement de « la discipline la plus importante de 2026 ».
En 90 jours, une nouvelle discipline d’ingénierie s’est formée. Et en dehors des équipes d’infrastructure IA, presque personne ne la comprenait.
Cet article vise à l’éclaircir. Sans bavardages, sans jargon académique, uniquement le modèle mental dont vous aurez vraiment besoin pour l’utiliser.
1. Définition de Harness
La définition la plus simple donnée par ThoughtWorks :
Harness, c’est tout ce qui est en dehors du modèle.
Enlever le harness → un modèle de langage brut qui devine dans votre codebase.
Ajouter le bon harness → un système capable de produire du code en production.
Ce nom vient du harnachement. Harness, c’est la bride, la selle, la morsure — orienter un animal puissant mais imprévisible dans une direction utile.
Vous ne rendez pas le cheval plus intelligent, vous concevez un équipement pour rendre sa force utile.
2. Métaphore OS
Philipp Schmid donne la meilleure métaphore technique : Imaginez-le comme un ordinateur.
| Rôle | | --- | | Correspondance | | --- | --- | | Modèle | Processeur (puissance brute) | | Fenêtre de contexte | RAM (mémoire de travail limitée et volatile) | | Harness | Système d’exploitation (gère ce que le CPU voit, quand il le voit) | | Agent | Application en cours d’exécution |
Votre modèle est puissant. Mais sans OS pour gérer la mémoire, la planification, les règles d’exécution — il n’est qu’un simple silicium.
La plupart des gens font tourner leurs applications « sans système d’exploitation ». Donc leur agent échoue dès la ligne de production.
3. Qu’est-ce qui a changé en 2026
LangChain utilise le même modèle, et l’a testé deux fois sur Terminal Bench 2.0 :
| Harness | | --- | | Score | | --- | --- | | Ancien harness | 52.8% | | Nouveau harness | 66.5% |
Même modèle. Harness différent. Différence de 13,7 points de pourcentage.
Vercel a inversé la tendance — réduit l’agent de 80% d’outils. Résultat ? Meilleur, pas pire.
La vérité la plus inconfortable de 2026 :
Si 2025 a été l’année où l’agent IA a prouvé qu’il pouvait coder, 2026 est l’année où l’on découvre que « l’environnement » est plus important que « le modèle ».
4. Fichier AGENT.md / CLAUDE.md
Le produit harness le plus universel.
Des fichiers markdown dispersés dans tout le codebase. L’agent lit à chaque session — comme un onboarding pour un nouveau développeur.
Que contient-il ?
OpenAI l’appelle AGENT.md. Anthropic, CLAUDE.md. Cursor utilise .cursorrules.
Différents noms, même principe. Un fichier par module principal. Mise à jour au fil du projet.
Sans cela : chaque session d’agent est une ouverture à l’aveugle. Avec : chaque session est enrichie d’informations.
5. Listes de fonctionnalités JSON (Suivi de progression)
Quand l’agent construit une application sur plusieurs sessions, chaque contexte de session est vide. Comment sait-il ce qui a été fait ?
Un fichier JSON.
Chaque entrée indique :
L’agent lit ce fichier au début — priorise la correction des échecs → implémente → marque comme passé → commit → répète.
Pourquoi JSON et pas Markdown ?
Anthropic a découvert : la probabilité que l’agent écrase accidentellement le JSON est plus faible que pour Markdown.
Les détails sont minimes, mais cruciaux dans un scénario d’autonomie de 6 heures.
6. Routine d'initialisation de session
Chaque session commence de la même manière. À chaque fois.
La procédure en 7 étapes d’Anthropic :
Sans cela : les 20 premières minutes, l’agent essaie de comprendre l’état actuel, et chaque session recommence à zéro. Avec : il part avec toutes les infos en main.
7. Contrats de sprint (Sprint Contracts)
Avant d’écrire une ligne de code — deux agents négocient.
Proposition de l’agent générateur :
Agent évaluateur :
Une fois l’accord obtenu, l’implémentation peut commencer.
C’est une revue de conception. Mais avec deux IA.
Pourquoi c’est important
Dans la même itération, planifier et exécuter avec le même agent donne des résultats peu fiables. La phase de « planification » — même faite par IA — augmente considérablement la qualité du résultat.
8. Modèles de tâches structurés (Structured Task Templates)
Avant d’écrire du code, le harness analyse réellement la codebase.
Il produit une carte d’impact concrète :
Puis l’implémentation commence.
Cela paraît évident. Mais la plupart des équipes sautent cette étape.
L’agent devine la structure des fichiers, invente des API inexistantes, construit quelque chose qui ne correspond pas à la codebase.
Avoir un contexte concret d’abord, puis agir → la qualité du résultat est bien meilleure.
9. La branche d’OpenAI : Priorité à l’environnement
L’équipe Codex d’OpenAI a un problème absurde :
Dans cette échelle, impossible de faire une revue ligne par ligne. Donc ils ne le font pas.
À la place — ils conçoivent l’environnement de façon si rigoureuse que l’agent produit dès le départ des résultats « auditable ».
Leur approche
Philosophie : concevoir l’environnement. Ensuite, laisser l’agent fonctionner.
Les preuves
L’application Sora Android. 4 développeurs. 28 jours. Play Store #1. 99.9% sans crash.
Codex traite 70% des PR internes chaque semaine.
10. La branche d’Anthropic : Séparer « faire » et « juger »
Anthropic fait face à un autre problème :
Quand ils demandent à l’agent d’évaluer ses propres résultats, il se félicite lui-même — même si la qualité est médiocre aux yeux d’un observateur humain.
L’auto-évaluation ne fonctionne pas. L’agent est à la fois étudiant et professeur, et se donne un A+.
Leur solution : 3 agents spécialisés
| Agent | | --- | | Travail | | --- | --- | | Planner | Transforme un prompt de 2 phrases en spécification complète du produit | | Generator | Implémente un sprint à la fois | | Evaluator | Test automatisé via navigateur, comme un utilisateur réel |
Insight : rendre « l’évaluateur indépendant » plus exigeant est beaucoup plus facile que de faire en sorte que le générateur soit critique envers son propre travail.
Résultats (tests A/B)
| Configuration | | --- | Coût | Temps | Résultat | | --- | --- | --- | --- | | Agent unique (sans harness) | $9 | 20 min | Application défectueuse | | Harness complet | $200 | 6 heures | Logiciel fonctionnel + UI soignée |
11. La branche de ThoughtWorks : Cadre 2×2
ThoughtWorks aborde sous différents angles — ils ne créent pas un produit, mais analysent 50+ équipes qui échouent dans les mêmes conditions.
Leur insight : classer chaque contrôle harness selon deux axes
Axe 1 : Quand ça fonctionne ?
Axe 2 : Comment ça fonctionne ?
Matrice 2×2
| | | --- | | Feedforward (directive) | | Feedback (capteur) | | --- | --- | --- | | Computational | système de types, linter, règles d’architecture | suite de tests, couverture, tests mutation | | Inférentiel | fichier de spécifications, contraintes descriptives | LLM pour revue de code, vérificateur de comportement |
Feedforward et feedback, utilisés séparément, ne suffisent pas. Il faut les deux.
12. Principe 1 : Le contexte prime sur l’instruction
Différentes équipes, même constat :
Ancrer dans les fichiers réels → adapter le code à la base. Partir d’une description vague → API inventée et chemins illusoires.
Avant que l’agent ne tape, assurez-vous qu’il sait où il est.
13. Principe 2 : La planification et l’exécution doivent être séparées
Chaque camp découvre que : faire planifier et exécuter dans la même itération donne des résultats peu fiables.
La planification — pas forcément par un humain — doit être une étape séparée, et ses résultats doivent être validés avant de commencer.
14. Principe 3 : La boucle de rétroaction est non négociable
Trois écoles, même principe, trois approches :
| École | | --- | | Source de feedback | | --- | --- | | OpenAI | Tests automatisés + CI | | Anthropic | Un autre LLM | | ThoughtWorks | Utilisation combinée des deux |
Ils divergent sur « qui fournit le feedback ». Mais pas sur « si le feedback est nécessaire ».
15. Principe 4 : Faire une seule chose à la fois
Vouloir faire trop d’agents en même temps :
La routine d’Anthropic : lire la progression → choisir UNE feature → implémenter → commit → répéter.
Le « principe de progression graduelle » est la clé du succès de tout harness.
16. Principe 5 : La base de code est un document
Personne ne va maintenir une autre base de connaissances pour l’agent. Le repo est la seule vérité.
Si une règle, une contrainte ou une décision d’architecture n’est pas dans la codebase → l’agent ne la saura pas.
Implications pratiques
17. Le déclin de Harness (Harness Decay) est réel
Quand Anthropic passe de Opus 4.5 à Opus 4.6 — la décomposition du sprint (initialement indispensable) devient un fardeau.
Les capacités de planification du modèle ont progressé, rendant cette étape superflue.
Les composants harness qui supportaient encore en mars, en avril deviennent une surcharge.
Puis, avec Opus 4.7 — le modèle commence à vérifier ses propres sorties, et la responsabilité de l’évaluateur diminue à nouveau.
Voilà ce qu’est le déclin de Harness
| Version du modèle | | --- | | État du harness | | --- | --- | | Opus 4.5 | Décomposition du sprint + évaluation à chaque sprint | | Opus 4.6 | Pas de décomposition + évaluation unique (économise 38%) | | Opus 4.7 | Auto-vérification du modèle → rôle de l’évaluateur réduit |
18. Construire pour supprimer (Build to Delete)
Philipp Schmid recommande : « Build to delete. »
Concevoir chaque composant harness dès le départ pour qu’il puisse être retiré.
Tester régulièrement chaque composant — le désactiver, voir si la qualité de sortie en souffre.
Pas de différence ? Supprimer.
| Équipe | | --- | | Refactorings tous les 6 mois | | --- | --- | | Manus | 5 refactorings de harness | | LangChain | 3 refactorings en 1 an | | Vercel | Supprimer 80% des outils → meilleure performance |
Ce n’est pas un signe de mauvais génie. C’est la conséquence naturelle de « superposer » sur des modèles en rapide évolution.
19. La réalité des coûts
Les chiffres honnêtes de l’A/B test d’Anthropic :
| Configuration | | --- | | Coût | | --- | --- | --- | --- | | Agent seul (sans harness) | $9 | 20 min | UI modifié, core cassé | | Harness complet (Opus 4.5) | $200 | 6 heures | Logiciel fonctionnel + UI soignée, physique correcte |
22 fois plus cher — pour un vrai produit capable de tourner, pas une simple démo « captures d’écran ».
Est-ce que ça vaut le coup ? Tout dépend du coût pour votre équipe si la version échoue.
Mais cette partie, personne ne la mentionne ici
Le combo Harness + modèle est en évolution constante.
$200 de harness, après mise à jour du modèle, coûte 124$.
| Tendance | | --- | | Meilleur modèle = harness plus simple = coût moindre par exécution = sortie plus rapide |