Note de la rédaction : Alors que des « modèles plus puissants » semblent être la réponse par défaut de l'industrie, cet article propose un point de vue différent : ce qui crée un écart de productivité de 10, 100, voire 1000 fois, ce n'est pas le modèle lui-même, mais plutôt la conception d'un système complet construit autour du modèle.

L'auteur de cet article, Garry Tan, est actuellement président et CEO de Y Combinator et est un expert de longue date de l'IA et de l'écosystème des startups en phase initiale. Il propose le cadre « fat skills + thin harness », décompose les applications d'IA en composants clés tels que les compétences, le cadre d'exécution, le routage contextuel, la répartition des tâches et la compression des connaissances.

Dans ce système, le modèle n'est plus la source unique des capacités, mais simplement une unité d'exécution au sein du système ; ce qui détermine réellement la qualité de la sortie, c'est la façon dont vous organisez le contexte, capitalisez sur les processus et tracez la frontière entre le « jugement » et le « calcul ».

Plus important encore, cette méthode n'est pas seulement conceptuelle ; elle a été validée dans des scénarios réels : face à la tâche de traitement et d'appariement des données de milliers d'entrepreneurs, le système a atteint une capacité proche de celle d'un analyste humain grâce à une boucle « lecture - organisation - jugement - réécriture », et s'optimise continuellement sans avoir à réécrire du code. Ce type de « système qui apprend » transforme l'IA d'un outil ponctuel en une infrastructure dotée d'un effet cumulatif (compound interest).

Ainsi, le rappel 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 les personnes utilisant des agents de programmation IA sont « 10 à 100 fois plus efficaces que les ingénieurs qui écrivent du code uniquement avec Cursor et des outils de chat, et environ 1000 fois plus efficaces que les ingénieurs de Google en 2005. »

Ce n'est pas une exagération. Je l'ai vu de mes propres yeux, et je l'ai vécu moi-même. Mais quand les gens entendent un tel écart, ils ont tendance à l'attribuer à la mauvaise chose : des modèles plus forts, un Claude plus intelligent, plus de paramètres.

En réalité, la personne qui améliore son efficacité par 2 et celle qui l'améliore par 100 utilisent le même modèle. La différence n'est pas dans « l'intelligence », mais dans « l'architecture », et cette architecture est si simple qu'elle peut être écrite sur une carte.

Le Harness (cadre d'exécution) est le produit lui-même.

Le 31 mars 2026, Anthropic a accidentellement publié le code source complet de Claude Code sur npm — 512 000 lignes au total. Je l'ai lu en entier. Cela a validé ce que je n'arrête de dire chez YC (Y Combinator) : le vrai secret n'est pas dans le modèle, mais dans « la couche qui enveloppe le modèle ».

Le contexte du dépôt de code en temps réel, la mise en cache des prompts, les outils conçus pour des tâches spécifiques, la compression maximale du contexte redondant, la mémoire de session structurée, les sous-agents fonctionnant en parallèle — tout cela ne rend pas le modèle plus intelligent. Mais cela permet de donner au modèle le « bon contexte » au « bon moment », tout en évitant d'être submergé par des informations non pertinentes.

Cette couche « d'enveloppement » s'appelle le harness (cadre d'exécution). Et la question que tous les constructeurs d'IA devraient vraiment se poser est : qu'est-ce qui devrait aller dans le harness, et qu'est-ce qui devrait rester dehors ?

Cette question a en fait une réponse très spécifique — je l'appelle : harness mince (thin harness), compétences épaisses (fat skills).

Cinq définitions

Le goulot d'étranglement n'a jamais été l'intelligence du modèle. Les modèles savent en fait déjà raisonner, synthétiser des informations, é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 ci-dessous sont précisément conçues pour résoudre ce problème.

1. Fichier de compétence (Skill file)

Un fichier de compétence est un document markdown réutilisable qui apprend au modèle « comment faire quelque chose ». Attention, pas lui dire « quoi faire » — cette partie est fournie par l'utilisateur. Le fichier de compétence fournit le processus.

Le point clé que la plupart des gens négligent est : un fichier de compétence est en fait comme un appel de méthode. Il peut recevoir des paramètres. Vous pouvez l'appeler avec différents paramètres. Le même processus, avec des paramètres d'entrée différents, peut montrer des capacités radicalement différentes.

Par exemple, il existe une compétence appelée /investigate. Elle contient sept étapes : délimiter la portée des données, construire une chronologie, diariser chaque document, synthétiser, argumenter des deux côtés, citer les sources. Elle reçoit trois paramètres : CIBLE, QUESTION et JEU_DE_DONNÉES.

Si vous le pointez vers un scientifique de la sécurité et 2,1 millions d'e-mails de forensic, il deviendra un analyste de recherche médicale, pour déterminer si un lanceur d'alerte a été réprimé.

Si vous le pointez vers une société écran et les déclarations de la FEC (Federal Election Commission), il deviendra un enquêteur médico-légal, traquant des dons politiques coordonnés.

Même compétence. Mêmes sept étapes. Même fichier markdown. Une compétence décrit un processus de jugement, et ce qui l'ancre dans le monde réel, ce sont les paramètres passés lors de l'appel.

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

2. Harness (Cadre d'exécution)

Le Harness, c'est le programme 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 et exécuter les contraintes de sécurité.

C'est tout. C'est ça le « thin » (mince).

L'anti-modèle est : harness épais, compétences minces.

Vous avez forcément vu ce genre de chose : 40+ définitions d'outils, la moitié de la fenêtre de contexte mangée par les descriptions ; un God-tool tout-en-un, qui prend 2 à 5 secondes pour un aller-retour MCP ; ou encore, emballer chaque endpoint d'API REST dans un outil séparé. Le résultat : l'utilisation de tokens triple, la latence triple, le taux d'échec triple.

L'approche idéale est vraiment d'utiliser des outils rapides, à fonction étroite, conçus pour un but.

Par exemple, un CLI Playwright, où chaque opération navigateur prend 100 ms ; et non pas un Chrome MCP, où une séquence screenshot → find → click → wait → read prend 15 secondes. Le premier est 75 fois plus rapide.

Les logiciels d'aujourd'hui n'ont plus besoin d'être « finement ciselés jusqu'à l'obésité ». Vous devriez : ne construire que ce dont vous avez vraiment besoin, et rien de plus.

3. Resolver (Résolveur)

Un resolver, essentiellement, est une table de routage contextuelle. Quand une tâche de type X apparaît, chargez prioritairement le document Y. Les skills disent au modèle « comment faire » ; les resolvers disent au modèle « quand charger quoi ».

Par exemple, un développeur modifie une prompt. Sans resolver, il pourrait la modifier et la déployer directement. Avec un resolver, le modèle va d'abord lire docs/EVALS.md. Et ce document dit : d'abord exécuter la suite d'évaluation, comparer les scores avant/après ; si la précision baisse de plus de 2%, revenir en arrière et investiguer. Ce développeur ne savait même pas qu'une suite d'évaluation existait. C'est le resolver qui, au bon moment, a chargé le bon contexte.

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

Soyons francs : mon ancien CLAUDE.md faisait 20 000 lignes. Toutes les excentricités, tous les patterns, toutes les leçons apprises, tout était fourré dedans. Absurdité totale. La qualité de l'attention du modèle a clairement chuté. Claude Code m'a même directement dit de le couper.

La solution de correction finale faisait environ 200 lignes — ne gardant que quelques pointeurs vers des documents. Quand un document est vraiment nécessaire, le resolver le charge au moment crucial. Ainsi, les 20 000 lignes de connaissances restent disponibles à la demande, sans polluer la fenêtre de contexte.

4. Latent et deterministic (Espace latent et Déterministe)

Dans votre système, chaque étape appartient soit à cette catégorie, soit à l'autre. Et confondre ces deux-là est l'erreur la plus courante dans la conception des agents.

· L'espace latent (Latent space), est là où réside l'intelligence. Le modèle y lit, comprend, juge, décide. On y traite : jugement, synthèse, reconnaissance de patterns.

· Le Déterministe (Deterministic), est là où réside la fiabilité. Même entrée, toujours même sortie. Les requêtes SQL, le code compilé, les opérations arithmétiques appartiennent à ce côté.

Un LLM peut vous aider à placer 8 personnes à une table de dîner, en considérant leur personnalité et leurs relations sociales. Mais demandez-lui de placer 800 personnes, il inventera de manière plausible une disposition de table « qui semble raisonnable mais est complètement fausse ». Parce que ce n'est plus un problème pour l'espace latent, c'est un problème déterministe — un problème d'optimisation combinatoire — qui a été faussement placé dans l'espace latent.

Les pires systèmes placent toujours le travail du mauvais côté de cette ligne de démarcation. Les meilleurs systèmes tracent cette frontière de manière très froide.

5. Diarization (Organisation des documents / Profilage thématique)

L'étape de diarization est ce qui apporte vraiment de la valeur à l'IA pour le travail intellectuel réel.

Cela signifie : le modèle lit tous les documents relatifs à un sujet, puis écrit un profil structuré. Sur une page, il condense les jugements provenant de dizaines, voire de centaines de documents.

Ce n'est pas quelque chose qu'une requête SQL peut produire. Ce n'est pas quelque chose qu'un pipeline RAG peut produire. Le modèle doit vraiment lire, garder en tête les informations contradictoires, remarquer ce qui a changé, quand cela a changé, 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 briefing d'analyste.

Cette architecture

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

· La couche supérieure est celle des compétences épaisses (fat skills) : des processus écrits en markdown, portant jugement, méthodologie et connaissances métier. 90% de la valeur est dans cette couche.
· Au milieu, une fine couche CLI harness : environ 200 lignes de code, entrée JSON, sortie texte, lecture seule par défaut.
· Au fond, votre système applicatif : QueryDB, ReadDoc, Search, Timeline — ce sont les infrastructures déterministes.

Le principe central est directionnel : pousser « l'intelligence » autant que possible vers les skills ; enfoncer « l'exécution » autant que possible vers les outils déterministes ; garder le harness mince.

Le résultat est : chaque fois que les capacités du modèle s'améliorent, toutes les compétences deviennent automatiquement plus fortes ; et le système déterministe sous-jacent reste toujours stable et fiable.

Un système qui apprend

Je vais utiliser un système réel que nous construisons actuellement chez YC pour montrer comment ces cinq définitions fonctionnent ensemble.

Juillet 2026, Chase Center. Startup School compte 6000 fondateurs participants. Chacun a des documents de candidature structurés, des réponses à un questionnaire, des transcriptions de conversations 1:1 avec des mentors, et des signaux publics : posts sur X, commits GitHub, historique d'utilisation de Claude Code (qui indique leur vitesse de développement).

L'approche traditionnelle est : une équipe projet de 15 personnes lit les candidatures une par une, juge à l'instinct, puis met à jour un tableau.

Cette méthode fonctionnait à l'échelle de 200 personnes, mais échoue totalement à 6000. Aucun humain ne peut garder autant de profils en tête simultanément et réaliser que : les trois meilleurs candidats dans la direction de l'infrastructure d'agents IA sont un fondateur d'outils dev à Lagos, un entrepreneur en compliance à Singapour, et un développeur d'outils CLI à Brooklyn — et qu'ils ont décrit la même difficulté avec des formulations complètement différentes lors de différentes conversations 1:1.

Le modèle peut le faire. Voici comment :

Enrichissement (Enrichment)

Il existe une compétence appelée /enrich-founder, qui récupère toutes les sources de données, fait de l'enrichissement, de la diarization, et marque les différences entre « ce que le fondateur dit » et « ce qu'il fait réellement ».

Le système déterministe sous-jacent est responsable : requêtes SQL, données GitHub, tests navigateur des URL de démo, scraping des signaux sociaux, requêtes CrustData, etc. Une tâche planifiée tourne une fois par jour. Les 6000 profils de fondateurs sont toujours à jour.

La sortie de la diarization capture des informations qu'une recherche par mots-clé ne pourrait jamais découvrir :

Ce type de différence entre « déclaration et comportement réel » nécessite de lire simultanément l'historique des commits GitHub, les documents de candidature et les transcripts de conversation, et de les intégrer mentalement. Aucune recherche par similarité d'embedding ne peut faire cela, pas plus qu'un filtrage par mots-clés. Le modèle doit lire en entier, puis porter un jugement. (C'est exactement le type de tâche qui doit aller dans l'espace latent !)

Appariement (Matching)

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

La même compétence d'appariement, appelée trois fois, peut produire des stratégies complètement différentes :

/match-breakout : traite 1200 personnes, les clusterise par domaine, 30 personnes par groupe (embedding + allocation déterministe)

/match-lunch : traite 600 personnes, « matching accidentel » cross-domain, 8 personnes par table sans répétition — généré d'abord par le LLM par thème, puis placement assis par algorithme déterministe

/match-live : traite les participants en temps réel sur site, basé sur l'embedding des plus proches voisins, matching 1 pour 1 en moins de 200ms, en excluant les personnes déjà rencontrées

Et le modèle peut faire des jugements que les algorithmes de clustering traditionnels ne peuvent pas faire :

« Santos et Oram sont tous deux dans l'infrastructure IA, mais ne sont pas en concurrence — Santos fait de l'attribution des coûts, Oram fait de l'orchestration. Devraient être dans le même groupe. »
« Kim a écrit outils pour développeurs dans sa candidature, mais la conversation 1:1 montre qu'il fait de l'automatisation de conformité SOC2. Doit être reclassé dans FinTech / RegTech. »

Ce reclassement n'est pas du tout capturé par les embeddings. Le modèle doit lire le profil entier.

Boucle d'apprentissage (learning loop)

Après l'événement, une compétence /improve lit les résultats de l'enquête NPS, fait une diarization des retours « passables » — pas les mauvais, mais ceux « presque bons » — et en extrait des patterns.

Ensuite, elle propose de nouvelles règles, et les réécrit dans la compétence de matching :

Quand un participant dit « AI infrastructure », mais que son code est à 80%+ des modules de facturation :
→ Classer en FinTech, pas AI Infra

Quand deux personnes dans un groupe se connaissent déjà :
→ Réduire le poids de matching
→ Donner la priorité à de nouvelles relations

Ces règles sont réécrites dans le fichier de skill. Elles sont actives automatiquement au prochain run. La compétence « se réécrit elle-même ». En juillet, les notes « passables » représentaient 12% ; à l'événement suivant, c'est tombé à 4%.

Le fichier de skill a appris ce que « passable » signifie, et le système s'est amélioré sans que personne ne réécrive de code.

Ce pattern peut être migré vers n'importe quel domaine :

Récupération → Lecture → Diarization → Comptage → Synthèse

Puis : Investigation → Enquête → Diarization → Réécriture de la skill

Si vous demandez quelle est la boucle la plus valuable en 2026, c'est celle-ci. Elle peut s'appliquer à presque tous les scénarios de travail intellectuel.

Les compétences sont des mises à niveau permanentes

J'ai récemment posté une instruction pour OpenClaw sur X, l'écho a été plus important que prévu :

Ce contenu a obtenu des milliers de likes et plus de deux mille sauvegardes. Beaucoup ont cru que c'était une astuce de prompt engineering.

En fait non, c'est l'architecture décrite précédemment. Chaque skill que vous écrivez est une mise à niveau permanente du système. Elle ne régresse pas, n'oublie pas. Elle s'exécute automatiquement à 3h du matin. Et quand la prochaine génération de modèles sortira, toutes les skills deviendront instantanément plus fortes — la partie latente du jugement s'améliore, tandis que la partie déterministe reste stable et fiable.

C'est la source de l'efficacité multipliée par 100 dont parle Yegge.

Pas des modèles plus intelligents, mais : des compétences épaisses, un cadre mince (Thin Harness, Fat Skills), et la discipline de solidifier le tout en capacités.

Le système croît à intérêts composés. Construisez une fois, exécutez longtemps.