Harness maigre, Skill gros : la véritable source d'une productivité AI 100 fois supérieure

Titre original : Thin Harness, Fat Skills
Auteur original : Garry Tan
Traduction : Peggy, BlockBeats

Auteur original : BlockBeats

Source originale :

Reproduction : Mars Finance

Note de l’éditeur : Lorsque « un modèle plus puissant » devient la réponse par défaut dans l’industrie, cet article propose un jugement différent : ce qui permet réellement d’atteindre un écart de productivité de 10, 100, voire 1000 fois, ce n’est pas le modèle lui-même, mais l’ensemble du système conçu autour du modèle.

L’auteur de cet article, Garry Tan, actuellement président et CEO de Y Combinator, s’est longtemps consacré à l’écosystème de l’IA et des startups précoces. Il propose le cadre « fat skills + thin harness », décomposant l’application de l’IA en compétences, cadre opérationnel, routage contextuel, division des tâches et compression des connaissances.

Dans ce système, le modèle n’est plus l’intégralité de la capacité, mais simplement une unité d’exécution ; ce qui détermine réellement la qualité de la sortie, c’est la façon dont vous organisez le contexte, consolidez les processus, et délimitez la frontière entre « jugement » et « calcul ».

Plus important encore, cette méthode ne reste pas au niveau conceptuel, mais est validée dans des scénarios réels : face à des milliers d’entrepreneurs traitant des données et des tâches de correspondance, le système, via une boucle « lecture — consolidation — jugement — écriture », atteint une capacité proche de celle d’un analyste humain, tout en s’auto-améliorant en continu sans réécrire de code. Ce « système qui apprend » transforme l’outil unique en une infrastructure à effet composé.

De là, le message central de l’article devient clair : à l’ère de l’IA, l’écart d’efficacité ne dépend plus de l’utilisation du modèle le plus avancé, mais de la construction d’un système capable d’accumuler continuellement des capacités et d’évoluer automatiquement.

Voici le texte original :

Steve Yegge dit que, pour ceux qui utilisent des agents de programmation IA, « l’efficacité est de 10 à 100 fois celle des ingénieurs qui écrivent du code uniquement avec Cursor et outils de chat, soit environ 1000 fois celle des ingénieurs de Google en 2005. »

Ce n’est pas une exagération. Je l’ai vu de mes propres yeux, je l’ai vécu personnellement. Mais quand les gens entendent cette différence, ils ont tendance à l’attribuer à une mauvaise direction : modèles plus puissants, Claude plus intelligent, plus de paramètres.

En réalité, une personne doublant sa productivité avec un modèle et une autre multipliant par 100, utilisent le même modèle. La différence ne réside pas dans « l’intelligence », mais dans « l’architecture », et cette architecture est si simple qu’on peut la résumer sur une seule carte.

Harness (cadre opérationnel) est le vrai produit.

Le 31 mars 2026, Anthropic a accidentellement publié le code source complet de Claude Code sur npm — 512 000 lignes. Je l’ai parcouru en entier. Cela confirme ce que je dis depuis longtemps chez YC (Y Combinator) : le vrai secret ne réside pas dans le modèle, mais dans « la couche qui enveloppe le modèle ».

Le contexte en temps réel du dépôt de code, le cache de prompts, les outils conçus pour des tâches spécifiques, la compression des redondances contextuelles, la mémoire structurée des conversations, les sous-agents parallèles — tout cela ne rend pas le modèle plus intelligent. Mais cela permet de fournir au modèle « le bon contexte au bon moment », tout en évitant qu’il ne soit noyé par des informations non pertinentes.

Cette couche « d’enveloppement » s’appelle le harness (cadre opérationnel). La question que tout constructeur d’IA devrait se poser est : qu’est-ce qui doit entrer dans le harness, et qu’est-ce qui doit rester à l’extérieur ?

Il existe une réponse très concrète à cette question — que je nomme : thin harness (cadre fin), fat skills (compétences épaisses).

Cinq définitions

Le goulot d’étranglement n’a jamais été l’intelligence du modèle. En réalité, les modèles savent déjà comment raisonner, synthétiser l’information, écrire du code.

Ils échouent parce qu’ils ne comprennent pas vos données — votre schéma, vos conventions, la forme spécifique de votre problème. Et ces cinq définitions visent justement à résoudre ce problème.

1. Skill file (fichier de compétences)

Un skill file est un document markdown réutilisable, destiné à enseigner au modèle « comment faire une tâche ». Attention, il ne s’agit pas de lui dire « quoi faire » — cette partie est fournie par l’utilisateur. Le skill file fournit la procédure.

La clé que beaucoup négligent est que : le skill file ressemble à un appel de méthode. Il peut recevoir des paramètres. Vous pouvez l’appeler avec différents paramètres. La même procédure, avec des paramètres différents, peut révéler des capacités très différentes.

Par exemple, il y a une compétence appelée /investigate. Elle comprend sept étapes : délimiter la portée des données, construire une chronologie, diariser chaque document, synthétiser, argumenter en positif et négatif, citer les sources. Elle prend trois paramètres : TARGET, QUESTION et DATASET.

Si vous la dirigez vers un scientifique en sécurité et 2,1 millions de courriels de preuve, elle devient un analyste en recherche médicale, pour déterminer si un lanceur d’alerte a été réprimé.

Si vous la dirigez vers une société écran et des déclarations à la FEC (Commission électorale fédérale américaine), elle devient un enquêteur judiciaire, pour traquer des dons politiques coordonnés.

C’est toujours la même compétence. Toujours les mêmes sept étapes. Toujours le même fichier markdown. La compétence décrit une procédure de jugement, mais ce qui la concrétise dans le monde réel, ce sont les paramètres passés lors de l’appel.

Ce n’est pas du prompt engineering, mais de la conception logicielle : sauf qu’ici, on utilise markdown comme langage de programmation, et le jugement humain comme environnement d’exécution. En fait, le markdown est même plus adapté que du code rigide pour encapsuler des capacités, car il décrit un processus, un jugement, un contexte — et ce sont précisément ces langages que le modèle « comprend » le mieux.

2. Harness (cadre opérationnel)

Le harness, c’est la couche qui pilote l’exécution du LLM. Il ne fait que quatre choses : faire tourner le modèle en boucle, lire/écrire vos fichiers, gérer le contexte, appliquer des contraintes de sécurité.

C’est tout. Voilà ce qu’on appelle « thin » (fin).

Le contre-exemple serait : un harness lourd, des compétences faibles.

Vous avez sûrement vu ce genre de choses : plus de 40 outils définis, dont la documentation occupe la moitié de la fenêtre du contexte ; un outil « Dieu » tout-en-un, qui prend 2 à 5 secondes pour faire un aller-retour MCP ; ou encore, chaque endpoint REST API encapsulé dans un outil séparé. Résultat : la consommation de tokens triple, la latence triple, le taux d’échec triple.

La meilleure approche consiste à utiliser des outils conçus pour un objectif précis, rapides et avec des fonctionnalités limitées.

Par exemple, une CLI Playwright, où chaque opération de navigateur ne prend que 100 ms ; plutôt qu’un MCP Chrome, qui prend 15 secondes pour faire une capture d’écran, rechercher, cliquer, attendre, lire. La première est 75 fois plus rapide.

Les logiciels modernes n’ont plus besoin d’être « surdimensionnés ». Il faut simplement construire ce dont vous avez réellement besoin, et rien de plus.

3. Resolver (résolveur)

Le resolver est essentiellement une table de routage contextuel. Lorsqu’un type de tâche X apparaît, il charge en priorité le document Y. Les skills indiquent « comment faire » ; les resolvers indiquent « quand charger quoi ».

Par exemple, un développeur modifie une invite. Sans resolver, il peut simplement déployer après modification. Avec un resolver, le modèle va d’abord lire docs/EVALS.md. Ce document indique : d’abord exécuter le test d’évaluation, comparer les scores ; si la précision chute de plus de 2 %, faire un rollback et investiguer. Ce développeur ne savait même pas qu’un tel test existait. C’est le resolver qui, au bon moment, charge le bon contexte.

Claude Code intègre un resolver. Chaque skill a un champ description, et le modèle associe automatiquement l’intention de l’utilisateur à la description du skill. Vous n’avez même pas besoin de vous souvenir si /ship existe — la description elle-même est un resolver.

Honnêtement, mon fichier CLAUDE.md faisait 20 000 lignes. Toutes mes bizarreries, tous mes patterns, toutes mes leçons apprises, y étaient. C’était absurde. La qualité de l’attention du modèle en pâtissait. Claude Code m’a même poussé à le supprimer.

La solution finale ne fait qu’environ 200 lignes — ne conservant que quelques pointeurs vers des documents. Le resolver charge la bonne documentation au moment critique, selon le besoin. Ainsi, 20 000 lignes de connaissances restent accessibles à tout moment, sans polluer la fenêtre de contexte.

4. Latent et deterministic (espace latent et déterminisme)

Dans votre système, chaque étape appartient à l’un ou l’autre de ces deux types. Confondre ces deux notions est l’erreur la plus courante dans la conception d’agents.

·L’espace latent (latent space) est le lieu de l’intelligence. Le modèle y lit, comprend, juge, décide. C’est là que se traitent : jugement, synthèse, reconnaissance de motifs.

·Le déterminisme (deterministic) est la fiabilité. Avec la même entrée, on obtient toujours la même sortie. Les requêtes SQL, le code compilé, les opérations arithmétiques, relèvent de cette catégorie.

Un LLM peut vous aider à organiser un dîner pour 8 personnes en tenant compte de leur personnalité et relations sociales. Mais si vous lui demandez d’organiser pour 800 personnes, il va produire une « liste de sièges » qui paraît raisonnable, mais qui est totalement fausse. Parce que ce n’est plus une tâche à traiter dans l’espace latent, mais un problème d’optimisation combinatoire, qui doit relever du domaine du déterminisme.

Les systèmes les plus mauvais mélangent ces deux domaines de façon incorrecte. Les meilleurs, eux, délimitent très strictement ces frontières.

5. Diarization (organisation / profilage thématique)

La diarization est la véritable clé pour que l’IA apporte une valeur concrète dans le travail de connaissance.

Elle consiste à faire lire à l’IA tout le matériel lié à un thème, puis à produire un profil structuré. En une page, condenser les jugements issus de dizaines ou centaines de documents.

Ce n’est pas quelque chose qu’un SQL peut produire. Ce n’est pas non plus une sortie d’un pipeline RAG. Le modèle doit vraiment lire, intégrer des informations contradictoires, repérer ce qui change, quand cela change, puis synthétiser tout cela en une intelligence structurée.

C’est la différence entre une requête en base de données et un rapport d’analyste.

Ce cadre

Ces cinq concepts peuvent être combinés en une architecture très simple à trois couches.

·La couche supérieure : les fat skills — processus écrits en markdown, portant jugement, méthodologie et connaissances du domaine. 90 % de la valeur.
·La couche intermédiaire : un thin CLI harness — environ 200 lignes de code, prenant JSON en entrée, produisant du texte en sortie, en lecture seule par défaut.
·La couche inférieure : votre système applicatif : QueryDB, ReadDoc, Search, Timeline — ces infrastructures déterministes.

Le principe central est directionnel : pousser « l’intelligence » vers le haut dans les skills ; faire descendre « l’exécution » dans des outils déterministes ; garder le harness léger.

Ce qui en résulte : chaque fois que le modèle s’améliore, toutes les compétences s’améliorent automatiquement ; et l’infrastructure déterministe reste stable et fiable.

Un système qui apprend

Je vais illustrer ces cinq définitions avec un système réel que nous construisons chez YC.

Juillet 2026, Chase Center. Startup School rassemble 6000 fondateurs. Chacun dispose de matériaux structurés, de réponses à des questionnaires, de transcriptions de 1:1 avec des mentors, et de signaux publics : posts sur X, commits GitHub, utilisation de Claude Code (pour voir leur vitesse de développement).

La méthode traditionnelle : une équipe de 15 personnes lit chaque dossier, juge par intuition, puis met à jour un tableau.

Ce système fonctionne encore à 200 personnes, mais à 6000, il échoue totalement. Personne ne peut gérer mentalement autant de profils, et réaliser que : les trois meilleurs candidats pour l’infrastructure IA sont respectivement le fondateur d’outils de développement à Lagos, un entrepreneur en conformité à Singapour, et un développeur d’outils CLI à Brooklyn — et qu’ils décrivent le même problème avec des formulations totalement différentes dans leurs 1:1.

Le modèle peut faire cela. La méthode :

Enrichment (enrichissement d’informations)

Une compétence appelée /enrich-founder récupère toutes les sources de données, fait de l’enrichissement, de la diarisation, et met en évidence les différences entre « ce que dit le fondateur » et « ce qu’il fait réellement ».

Le système déterministe sous-jacent gère : requêtes SQL, données GitHub, tests de navigateurs via URL de démo, collecte de signaux sociaux, requêtes CrustData, etc. Une tâche planifiée tourne chaque jour. Les profils des 6000 fondateurs sont toujours à jour.

Les sorties de diarisation captent des informations impossibles à détecter par une recherche par mots-clés :

Ce genre de « différence entre discours et action » nécessite de lire intégralement l’historique des commits GitHub, les matériaux de candidature, et les transcriptions, puis de les intégrer dans l’esprit. Aucune recherche par embedding ou filtrage par mots-clés ne peut faire cela. Le modèle doit tout lire, puis juger. (C’est précisément une tâche à traiter dans l’espace latent !)

Matching (correspondance)

C’est là que la « compétence = appel de méthode » montre toute sa puissance.

Une même compétence de correspondance, appelée trois fois, peut produire des stratégies totalement différentes :

/match-breakout : traiter 1200 personnes, par clustering par domaine, groupes de 30 (embedding + attribution déterministe)
/match-lunch : traiter 600 personnes, « matching » aléatoire inter-domaine, 8 par table, sans répétition — le LLM génère d’abord un thème, puis un algorithme déterministe organise les sièges
/match-live : traiter des participants en temps réel, basé sur le plus proche voisin d’embedding, en 200 ms, pour faire des correspondances 1:1, en évitant ceux déjà rencontrés

Et le modèle peut faire des jugements qu’un algorithme de clustering traditionnel ne peut pas :

« Santos et Oram appartiennent tous deux à l’infrastructure IA, mais ne sont pas en concurrence — Santos fait de la causalité de coûts, Oram de l’orchestration. Ils doivent être dans le même groupe. »
« Kim a postulé comme développeur d’outils, mais en 1:1, il montre qu’il travaille sur l’automatisation de la conformité SOC2. Il faut le reclassifier en FinTech / RegTech. »

Ce type de reclassification, totalement hors de portée des embeddings, nécessite que le modèle lise tout le profil.

Boucle d’apprentissage (learning loop)

Après l’événement, une compétence /improve lit les résultats NPS, diarise les retours « moyens » — pas les mauvais, mais ceux qui « auraient pu être meilleurs » — et en extrait des modèles.

Elle propose de nouvelles règles, qui sont intégrées dans la compétence de correspondance :

Quand un participant parle d’« infrastructure IA », mais que 80 % de son code concerne la facturation : → classer en FinTech, pas IA Infra
Quand deux personnes du même groupe se connaissent déjà : → réduire le poids de la correspondance, favoriser l’introduction de nouvelles relations

Ces règles sont écrites dans le fichier skill. Lors de la prochaine exécution, elles s’appliquent automatiquement. La compétence s’auto-modifie. En juillet, le score « moyen » était de 12 % ; lors de la prochaine session, il tombe à 4 %.

Le fichier skill apprend ce que signifie « moyen » et le système s’améliore sans que personne ne réécrive de code.

Ce modèle peut s’appliquer à tout domaine :

Recherche → lecture → diariser → compter → synthétiser

Puis : enquête → sondage → diariser → réécrire le skill

Si vous demandez quel sera le cycle le plus précieux en 2026, c’est cette architecture. Elle peut s’appliquer à presque toutes les tâches de connaissance.

Les compétences sont une mise à niveau permanente

J’ai récemment publié sur X une instruction pour OpenClaw, qui a reçu plus d’un millier de likes et plus de deux mille sauvegardes :

Beaucoup ont pensé qu’il s’agissait d’une technique de prompt engineering.

Ce n’est pas le cas, c’est cette architecture dont je parle. Chaque skill que vous écrivez constitue une mise à niveau permanente du système. Elle ne se dégrade pas, ne s’oublie pas. Elle tourne automatiquement à 3 heures du matin. Et lorsque la prochaine génération de modèles sera disponible, tous les skills seront instantanément renforcés — la capacité de jugement dans la partie latent s’améliore, la partie déterministe reste stable et fiable.

C’est la source de l’efficacité 100x que Yegge évoque.

Ce n’est pas un modèle plus intelligent, mais : des compétences épaisses, un cadre fin (Thin Harness), et une discipline pour tout transformer en capacité.

Le système croît par effet composé. Une seule mise en place, pour une utilisation à long terme.