Ton fichier de configuration d'agent IA gaspille des tokens — voilà quoi faire à la place

J'avais un fichier CLAUDE.md de 1 247 lignes. J'en étais fier. Chaque convention de code, chaque préférence architecturale, chaque cas limite que j'avais jamais rencontré — documenté, organisé et chargé dans le contexte à chaque message envoyé à Claude Code.

Puis j'ai fait les calculs.

À environ 3 tokens par ligne, ce fichier me coûtait ~3 700 tokens par tour. Pas par session — par tour. Dans une session typique de 40 tours, ça représente 148 000 tokens consommés par des instructions que le modèle n'utilisait même pas 90 % du temps. Je payais une taxe de contexte plus élevée que la conversation entière de la plupart des gens, et la qualité de la sortie de mon agent devenait en fait pire à mesure que le fichier grossissait.

Ross Mike a exposé la solution dans une discussion récente qui a totalement recadré ma façon de penser la productivité des agents IA. Son argument est simple, étayé par des données et — une fois que tu l'entends — douloureusement évident : la qualité de la sortie de ton agent IA dépend bien plus de la manière dont tu gères le contexte que du modèle que tu utilises. Opus 4.6, GPT 5.4, Gemini 3 — ils sont tous remarquablement performants. Le goulot d'étranglement, ce n'est pas l'intelligence. C'est le régime d'informations que tu leur sers.

J'ai passé les deux dernières semaines à reconstruire tout mon workflow d'agents autour de ce principe. Les résultats ont été assez frappants pour que j'écrive ce billet au lieu de m'attaquer aux trois autres choses sur ma liste du jour. Voici ce qui a changé, ce qui a cassé et ce que je dirais à quiconque entretient encore un fichier de configuration de 500 lignes.

La vérité inconfortable sur ton fichier agent.md

La plupart des développeurs à qui je parle ont une variante du même setup. Un gros fichier markdown — CLAUDE.md, .cursorrules, agents.md, quel que soit le nom que l'outil lui donne — bourré d'instructions sur leur stack, leurs préférences, leurs conventions. Le fichier grossit au fil des mois. Chaque interaction frustrante ajoute une ligne de plus : "Utilise toujours des named exports." "Préfère Tailwind aux CSS modules." "Ne suggère jamais de class components."

Ross appelle ça l'approche "context dump", et sa critique m'a touché là où ça fait mal : ces fichiers donnent l'impression d'être productifs parce que les écrire ressemble à du travail. Tu codifies des connaissances ! Tu entraînes ton agent ! Sauf que non. Tu crées un bloc de texte statique qui est injecté dans chaque interaction peu importe sa pertinence — et le modèle traite tout son contenu comme aussi important.

Voilà ce que des recherches récentes d'InfoQ montrent réellement au sujet de ces fichiers : les fichiers de contexte générés par LLM dégradent les performances, réduisant les taux de réussite des tâches de 3 % en moyenne par rapport à l'absence totale de fichier de contexte. Ils augmentent aussi systématiquement le nombre d'étapes que l'agent effectue, faisant grimper les coûts d'inférence de plus de 20 %. Même les fichiers écrits par des humains n'ont apporté qu'une amélioration marginale de 4 % du taux de réussite — tout en augmentant simultanément le nombre d'étapes et les coûts jusqu'à 19 %.

Relis ça. Le fichier sur lequel tu as passé des heures à peaufiner rend peut-être ton agent plus lent et plus cher tout en améliorant à peine sa précision.

Le mécanisme devient clair dès qu'on comprend comment ces modèles fonctionnent. Ils ne "comprennent" pas ton fichier de configuration comme un développeur humain lirait et intérioriserait un style guide. Ils prédisent des tokens en se basant sur des motifs dans le context window. Quand tu inondes cette fenêtre de 1 200 lignes d'instructions, tu ne donnes pas au modèle un manuel de référence — tu dilues le rapport signal/bruit de chaque prompt que tu envoies. Le modèle dépense de la capacité d'attention à traiter tes préférences TypeScript alors que tu lui demandes de déboguer un layout CSS.

Cela ne veut pas dire que les fichiers de contexte sont inutiles. Ça veut dire que l'approche par défaut — un gros fichier, chargé partout, qui grandit sans fin — est presque certainement mauvaise.

Ce que Ross saisit bien sur le fonctionnement réel des modèles

Il y a une idée fausse sur laquelle la plupart des constructeurs d'agents IA trébuchent, et Ross l'a abordée directement : ces modèles ne pensent pas. Ils ne comprennent pas. Ils prédisent le prochain token à partir de motifs présents dans leurs données d'entraînement et dans le contexte que tu fournis.

Ca sonne comme une limitation. C'est en réalité une contrainte de conception qui te dit exactement comment obtenir de meilleures sorties.

Si le modèle est un moteur de correspondance de motifs, alors les motifs à l'intérieur de ton context window sont le plus grand levier que tu as sur la qualité de la sortie. Nourris-le avec un contexte encombré d'instructions non pertinentes, et la correspondance de motifs devient bruitée. Nourris-le avec un contexte ciblé contenant exactement l'information nécessaire à la tâche en cours, et la correspondance de motifs devient nette.

Ross a utilisé une analogie qui m'est restée : imagine que tu briefes un nouvel employé avant chaque tâche. Si tu lui tends un manuel de 50 pages couvrant tous les scénarios jamais rencontrés par l'entreprise, il sera submergé et lent. Si tu lui donnes une fiche d'une page ciblée spécifiquement sur la tâche en question, il performera bien tout de suite. Les modèles fonctionnent de la même manière — non pas parce qu'ils "comprennent" le briefing, mais parce qu'un contexte ciblé produit des motifs de prédiction de tokens plus propres.

Cela a une implication pratique que la plupart des gens ratent. Le context window n'est pas juste un seau que tu remplis d'informations utiles. C'est plutôt un projecteur — il a une zone d'éclairage limitée, et tout ce qui se trouve dans cette zone se dispute l'attention du modèle. Les recherches le confirment : garder le context window entre frais et environ 70 % de capacité produit la sortie la plus fiable. Au-delà, on commence à voir des performances dégradées — instructions manquées, suggestions répétées, motifs de code incohérents.

Je l'ai testé moi-même. Même prompt, même modèle (Opus 4.6), même tâche : construire un flow d'authentification utilisateur avec JWT tokens et refresh rotation. Avec mon CLAUDE.md complet de 1 247 lignes chargé, l'agent a pris 14 tours et produit du code avec deux bugs. Après avoir réduit le CLAUDE.md à 47 lignes de conventions vraiment essentielles, la même tâche s'est terminée en 8 tours avec zéro bug. Moins d'instructions, meilleure sortie. La version épurée a permis au modèle de se concentrer sur l'essentiel.

Mais c'est ici que ça devient intéressant — parce que la réponse n'est pas juste "réduis ton fichier de configuration". Ça, c'est traiter le symptôme. La vraie intuition de Ross porte sur l'architecture de la manière dont le contexte doit circuler.

Progressive disclosure : le pattern qui change tout

Le concept qui a transformé mon workflow n'est pas nouveau — il vient du design UX. Progressive disclosure, c'est montrer aux utilisateurs uniquement les informations dont ils ont besoin à chaque étape, en révélant la complexité progressivement à mesure qu'ils creusent. Le framework agent-skills de Microsoft l'a formalisé comme une architecture de chargement à trois niveaux pour les agents IA, et c'est aujourd'hui la base du fonctionnement des skills dans Claude Code, Cursor et d'autres outils majeurs.

Voici la différence concrète entre l'ancienne et la nouvelle approche :

L'ancienne manière (agent.md / CLAUDE.md) : Chaque interaction charge ton fichier de configuration entier. Si tu as 1 000 tokens d'instructions, ce sont 1 000 tokens ajoutés à chaque message — que l'agent en ait besoin ou non.

La nouvelle manière (skills avec progressive disclosure) : Au démarrage, l'agent ne charge que les noms et descriptions des skills — environ 50 tokens par skill. Ce n'est que quand une tâche correspond à la description d'une skill que l'ensemble complet d'instructions est chargé dans le contexte. Quand la tâche est terminée, les instructions détaillées de la skill ne persistent pas dans la tâche suivante.

Les maths des tokens sont spectaculaires. Disons que tu as 20 workflows différents encodés en instructions. Avec l'ancienne approche, ça pourrait représenter 15 000 à 20 000 tokens chargés à chaque tour. Avec la progressive disclosure, tu charges ~1 000 tokens de métadonnées au démarrage, plus peut-être 500 à 800 tokens de la seule skill pertinente quand elle est nécessaire. Selon des benchmarks réels, cela représente à peu près une réduction de 82 % de l'overhead de contexte.

J'ai couvert l'implémentation technique des skills dans mon guide pour construire des agent skills, mais le framework de Ross ajoute quelque chose que la doc technique omet : une philosophie sur quand et comment créer des skills qui fonctionnent vraiment.

Le framework de Ross : comment construire des skills qui ne craignent pas

Le premier réflexe de la plupart des gens qui entendent parler des skills est de s'asseoir et d'en écrire une à partir de zéro. Ouvrir un fichier markdown vierge, penser à un workflow, documenter les étapes, sauvegarder. Terminé.

Ross argumente que c'est exactement à l'envers — et après avoir essayé les deux approches, je suis complètement d'accord.

Son framework comporte cinq étapes, et l'ordre compte plus que n'importe quelle étape individuelle :

Étape 1 : identifie un workflow réel (pas un hypothétique)

Ne construis pas de skills pour des workflows dont tu penses que tu auras besoin. Construis-les pour des workflows que tu as déjà faits manuellement au moins trois fois. Si tu ne l'as pas fait trois fois, tu ne comprends pas suffisamment bien les cas limites pour pouvoir l'enseigner à un agent.

Ce seul filtre m'a évité de créer une douzaine de skills inutiles. J'avais de grands projets pour une skill "déployer en production", une skill "migration de base de données", une skill "écrire des unit tests". Mais quand j'ai appliqué le filtre de Ross — ai-je réellement fait ceci manuellement, du début à la fin, au moins trois fois récemment ? — la liste a rétréci vite. Les workflows que je répétais vraiment étaient plus prosaïques : trier les e-mails entrants, formater les métadonnées des articles de blog, mettre en place le scaffolding de nouveaux projets avec mes conventions spécifiques.

Prosaïque, c'est bien. Prosaïque veut dire répétitif. Répétitif veut dire fort ROI pour l'automatisation.

Étape 2 : apprends à l'agent par la conversation, pas par la configuration

C'est là que l'approche de Ross diverge de ce que je vois faire à la plupart des développeurs. Au lieu d'écrire un fichier de skill en espérant que ça marche, tu enseignes le workflow à l'agent de manière interactive — exactement comme tu formerais un nouvel employé.

Transfère une vraie tâche à l'agent. Guide-le dans ton processus de décision en temps réel. Quand il fait une erreur, corrige-le et explique pourquoi. Quand il fait quelque chose de bien, confirme-le. C'est de l'apprentissage expérientiel, et Ross argumente que c'est la seule manière fiable de faire émerger les cas limites et les connaissances implicites que tu ne penserais jamais à écrire dans un fichier d'instructions statique.

Son exemple était convaincant : il a appris à un agent à filtrer des e-mails de sponsors en lui transférant littéralement de vrais e-mails et en le guidant à travers le processus de recherche. "Vérifie leur présence sur Twitter. Cherche-les sur Trustpilot. Confirme leur statut de financement. Si l'entreprise a été fondée il y a moins de 6 mois, marque-la." Chaque correction affinait la compréhension de l'agent. Après trois ou quatre itérations, l'agent filtrait les e-mails plus vite et plus en profondeur que Ross ne le faisait manuellement.

J'ai essayé ça avec mon workflow de métadonnées d'articles de blog. Au lieu d'écrire une skill à partir de zéro, j'ai fait passer Claude à travers le processus sur un vrai article : "Voilà le titre, voilà ce que je choisirais comme tags, voilà pourquoi je choisis ces mots-clés secondaires plutôt que ceux-là, voilà le pattern de meta description que j'utilise." Puis je l'ai refait avec un autre article. À la troisième fois, Claude générait des métadonnées qui correspondaient presque exactement à mon style — captant des nuances que je n'aurais jamais pensé à documenter, comme ma préférence pour les verbes d'action dans les meta descriptions ou mon habitude de mettre le nom de la marque en dernier dans les listes de tags.

Étape 3 : itère jusqu'à ce que les modes d'échec disparaissent

Le premier passage aura des erreurs. Le deuxième en aura moins. Au quatrième ou cinquième, tu commences à voir une sortie cohérente et fiable. Ross est explicite là-dessus : ne zappe pas la phase d'itération. L'agent n'est pas en train "d'apprendre" de manière persistante — c'est toi qui apprends de quel contexte il a besoin, et chaque itération révèle des lacunes que tu n'avais pas anticipées.

Cette patience paie des intérêts composés. Chaque cas limite que tu fais émerger et résous pendant l'entraînement est un cas limite qui ne te mordra pas en production. J'ai constaté que la plupart des skills nécessitaient 4 à 6 passes d'entraînement interactif avant d'être suffisamment solides pour être formalisées.

Étape 4 : convertis le workflow affiné en fichier de skill

Ce n'est qu'après que l'entraînement interactif produit des résultats cohérents que tu crées le fichier skill.md. À ce stade, tu n'inventes pas d'instructions — tu documentes ce qui fonctionne déjà. Le fichier de skill devient une codification de patterns éprouvés, pas une supposition spéculative sur ce dont l'agent pourrait avoir besoin.

La structure que Ross recommande est épurée :

# Skill: [Name]

## Description
[One sentence — what this skill does and when to use it]

## Workflow
[Numbered steps, each specific and actionable]

## Known Edge Cases
[Things that went wrong during training and how to handle them]

## Success Criteria
[How to verify the output is correct]

Cette section "Known Edge Cases" est l'endroit où réside la vraie valeur. C'est la connaissance institutionnelle que tu as construite pendant les étapes 2 et 3 — les pièges qu'un auteur de skill partant d'une page blanche n'anticiperait jamais.

Étape 5 : continue à raffiner de manière récursive

Un fichier de skill n'est pas un produit fini. C'est un document vivant. Chaque fois que la skill échoue en production, tu la débogues, tu corriges la cause racine et tu mets à jour le fichier. Ross appelle ça "recursive skill building", et c'est le mécanisme qui fait que les skills composent en valeur au fil du temps.

J'ai mis à jour ma skill de génération de métadonnées sept fois depuis sa création il y a trois semaines. Chaque mise à jour a été déclenchée par un échec réel — un article dont la meta description était trop longue, une combinaison de tags qui ne collait pas à la structure de clusters, un slug qui contenait des stop words. La skill est dramatiquement meilleure aujourd'hui que quand je l'ai écrite pour la première fois, et chaque amélioration a été pilotée par un usage réel, pas par de la spéculation.

Pourquoi tu ne devrais jamais télécharger des skills depuis un marketplace

La position de Ross là-dessus est sans ambiguïté, et j'ai fini par lui donner raison après avoir d'abord résisté.

Les marketplaces de skills — les endroits où tu peux parcourir et installer des skills préconstruites par d'autres développeurs — semblent être une excellente idée en surface. Pourquoi construire une skill de "génération de composants React" à partir de zéro quand quelqu'un d'autre en a déjà fait une ?

Deux raisons.

D'abord, le décalage de contexte. Une skill construite pour le workflow de quelqu'un d'autre encode ses conventions, ses choix de stack, ses cas limites. À moins que son environnement de développement soit identique au tien (il ne l'est pas), la skill produira une sortie qui ne colle pas tout à fait. Tu passeras autant de temps à corriger la sortie que tu en aurais passé à construire la skill toi-même. J'ai écrit sur ce problème dans mon guide de workflow pour agent skills — les skills qui fonctionnent le mieux sont celles construites à partir de ton workflow réel, pas de l'abstraction d'un workflow similaire faite par quelqu'un d'autre.

Ensuite, la sécurité. Un fichier skill.md est essentiellement un ensemble d'instructions que ton agent IA va suivre. Installer une skill depuis une source non fiable, c'est comme exécuter un paquet npm sans lire le code — sauf que la surface d'attaque est tout ton environnement de développement. Une skill malveillante pourrait instruire l'agent d'exfiltrer du code, d'injecter des dépendances ou de modifier des fichiers de manière à créer des vulnérabilités. Le risque n'est pas théorique ; à mesure que les agents gagnent en capacités autonomes, les instructions qu'ils suivent deviennent un vecteur d'attaque de plus en plus attrayant.

Construis les tiennes. Ça prend plus de temps au départ. Le retour composé en vaut la peine.

Le principe "un agent, plusieurs skills"

C'est ici que le framework de Ross rejoint une décision architecturale plus large sur laquelle je vois constamment des développeurs se tromper.

La tentation, une fois qu'on comprend les agents et les skills, c'est de construire une flotte. Un agent de coding. Un agent de research. Un agent de writing. Un agent de deployment. Chacun avec son propre system prompt, sa propre configuration d'outils, sa propre personnalité. Ça a l'air impressionnant. Ça fait sophistiqué. Et pour la plupart des cas d'usage, c'est un overkill massif.

La recommandation de Ross : commence avec un seul agent. Construis-lui 10 skills. Fais en sorte que ces skills fonctionnent de façon fiable. Ensuite seulement, demande-toi si un deuxième agent améliorerait vraiment ta productivité — et uniquement si tu peux articuler exactement ce que le second agent ferait que le premier ne peut pas.

Le raisonnement est pragmatique. Plusieurs agents introduisent de l'overhead de coordination — ils doivent communiquer, partager du contexte, se passer des tâches et résoudre des conflits. Cet overhead ne se justifie que quand les agents effectuent un travail réellement parallèle qui ne peut pas être sérialisé. Pour un développeur solo ou une petite équipe, un agent bien doté en skills gère la plupart des workflows plus efficacement que trois agents spécialisés qui ont besoin d'orchestration.

J'ai restructuré mon propre setup autour de ce principe le mois dernier. Je suis passé de trois agents configurés (un pour le coding, un pour le contenu, un pour DevOps) à un seul agent avec une bibliothèque de 14 skills couvrant les trois domaines. Le setup à agent unique est plus rapide à maintenir, plus prévisible dans son comportement et — contre-intuitivement — produit une meilleure sortie parce que le contexte complet de mon projet est toujours disponible, pas fragmenté entre des agents qui ne peuvent pas voir le travail des autres.

Si tu préfères que quelqu'un mette en place ce genre d'architecture d'agent à partir de zéro, je prends des missions de workflow et d'automatisation IA. Tu peux voir ce que j'ai construit sur fiverr.com/s/EgxYmWD.

L'exception à la règle de l'agent unique, c'est le parallélisme authentique — des tâches qui sont vraiment indépendantes et suffisamment sensibles au temps pour justifier une exécution simultanée. Déployer en staging pendant qu'une suite de tests tourne et que de la documentation se génère en parallèle ? Ce sont trois tâches indépendantes. Trois agents ont du sens. Mais écrire du code, le relire, puis le déployer ? C'est un workflow sériel. Un agent, trois skills.

Migration pratique : d'une configuration gonflée à des skills épurées

Si tu es assis sur un gros CLAUDE.md ou agents.md en ce moment, voici comment j'ai migré le mien sans perdre les connaissances accumulées :

1. Audite ton fichier de configuration pour identifier les vrais usages.

Parcours chaque instruction de ton fichier et demande-toi : "Quand cette instruction a-t-elle changé pour la dernière fois la sortie de l'agent ?" Sois honnête. J'ai découvert qu'environ 60 % de mes instructions étaient soit redondantes (le modèle le fait déjà par défaut), obsolètes (faisant référence à des patterns que je n'utilise plus), soit si rares qu'elles n'avaient été déclenchées que deux fois peut-être en des mois d'utilisation.

2. Sépare l'universel du spécifique à la tâche.

Certaines instructions appartiennent vraiment à chaque interaction : "Utilise TypeScript, pas JavaScript." "Suis la structure de projet existante." "Lance les tests avant de proposer un PR." Celles-ci restent dans ton CLAUDE.md épuré. Tout le reste — patterns d'API spécifiques, procédures de deployment, règles de formatage du contenu — devient un candidat pour une skill.

3. Pour chaque candidat à une skill, applique le test des "trois fois".

As-tu vraiment effectué ce workflow manuellement au moins trois fois ? Si oui, ça vaut la peine de construire une skill. Sinon, soit tu le fais encore quelques fois manuellement pour comprendre les cas limites, soit tu passes à autre chose.

4. Construis les skills par la conversation, pas par la configuration.

Pour chaque skill que tu crées, fais passer l'agent à travers le workflow de manière interactive 3 à 5 fois avant d'écrire le fichier de skill. Cela fait émerger des cas limites que tu raterais en écrivant depuis une page blanche.

5. Garde ton CLAUDE.md sous la barre des 200 lignes.

C'est le seuil que current best practices recommandent pour maintenir l'équilibre coût-bénéfice. Au-delà de 200 lignes, le coût persistant des tokens d'entrée commence à dépasser l'amélioration de la qualité de sortie. Le mien est actuellement à 47 lignes, et la qualité de la sortie est la meilleure qu'elle ait jamais été.

Après cette migration, mon utilisation de tokens par session a chuté d'environ 60 %. J'accomplis le même travail — souvent plus — tout en consommant dramatiquement moins de tokens. Les sessions se sentent différentes aussi. L'agent répond plus vite, reste plus concentré et produit moins de suggestions à côté de la plaque. J'ai écrit en détail sur le versant optimisation des tokens dans mon guide d'optimisation des tokens Claude Code, mais c'est la migration de la configuration monolithique vers les skills qui a apporté la plus grande amélioration individuelle.

Le vrai changement de paradigme : le contexte, c'est le produit

Ross a dit quelque chose vers la fin de la discussion que je retourne dans ma tête depuis : les modèles sont une commodité. Opus 4.6, GPT 5.4, tout ce qui sortira au prochain trimestre — ils convergent tous vers des niveaux de capacité similaires. L'avantage compétitif, ce n'est pas quel modèle tu utilises. C'est à quel point tu construis bien le contexte, les workflows et les skills autour du modèle que tu choisis.

Cela recadre ce que ça signifie d'être productif avec l'IA en 2026. Les développeurs qui prospéreront ne seront pas ceux qui courent après chaque nouvelle sortie de modèle ou qui accumulent les fichiers de configuration les plus longs. Ce seront ceux qui ont construit une bibliothèque personnelle de skills éprouvées au combat — chacune affinée par un usage réel, chacune encodant des connaissances de workflow qu'un agent neuf ne pourrait pas répliquer sans des semaines d'entraînement.

Vois ça comme la construction d'un fossé de connaissances. Chaque skill que tu crées, chaque cas limite que tu documentes, chaque workflow que tu affines — c'est de l'expertise qui se compose et rend ton setup IA plus précieux et plus efficient au fil du temps. Quelqu'un qui démarre de zéro demain ne peut pas raccourcir ce processus. Il peut utiliser le même modèle. Il ne peut pas utiliser tes skills.

Ross prévient — et je pense qu'il a raison — que l'écart entre les gens qui comprennent ça et ceux qui ne le comprennent pas va se creuser vite. Les modèles vont continuer à s'améliorer. Les gens qui savent comment les guider via un contexte bien construit vont extraire dramatiquement plus de valeur de chaque amélioration. Les gens qui traitent les agents IA comme des boîtes magiques censées "juste marcher" vont continuer à se cogner aux mêmes murs, en blâmant le modèle pour des échecs qui sont en réalité des échecs de contexte.

Ce que j'ai changé cette semaine et ce qui s'est passé

Je veux être précis sur les résultats parce que les affirmations vagues ne valent rien.

Après avoir reconstruit mon workflow autour du framework de Ross, voici à quoi a ressemblé mon lundi comparé au lundi précédent :

Lundi précédent (CLAUDE.md monolithique, sans skills) :

• Limite de tokens atteinte deux fois pendant une session de travail de 5 heures
• Environ 25 minutes passées à ré-expliquer le contexte après chaque /clear
• 3 composants finis produits, dont 2 ont nécessité des corrections manuelles
• Consommation de tokens estimée : ~850 000 tokens

Ce lundi (CLAUDE.md de 47 lignes, 14 skills actives) :

• Limite de tokens atteinte zéro fois pendant la même fenêtre de 5 heures
• Le rétablissement du contexte après /clear a pris moins de 2 minutes (la skill a chargé automatiquement le contexte pertinent)
• 5 composants finis produits, 1 a nécessité un petit ajustement
• Consommation de tokens estimée : ~340 000 tokens

Même développeur. Même modèle. Même projet. La seule variable, c'était la manière dont le contexte était structuré.

L'amélioration la plus surprenante, ce n'était pas les économies de tokens — c'était la régularité de la qualité. Avec la configuration monolithique, la qualité de la sortie se dégradait nettement à mesure que la session avançait et que le context window se remplissait. Avec les skills, chaque tâche démarre avec un contexte relativement frais plus uniquement les instructions de la skill pertinente. La cinquième tâche de la journée bénéficie de la même qualité que la première.

La version de cinq minutes

Si tu ne retiens rien d'autre de ce texte, voici le framework distillé :

Arrête de laisser grossir ton fichier de configuration. Plafonne-le à 200 lignes maximum. Réduis-le aux seules instructions qui doivent réellement s'appliquer à chaque interaction.

Construis les skills par itération, pas par imagination. Fais passer l'agent à travers de vraies tâches 3 à 5 fois avant d'écrire un fichier de skill. Les cas limites que tu découvres pendant l'entraînement sont la partie la plus précieuse de la skill.

Un agent, plusieurs skills. Résiste à l'envie de construire une flotte d'agents spécialisés. Un agent bien doté en skills surpasse trois agents mal coordonnés pour la plupart des workflows.

N'installe jamais les skills de quelqu'un d'autre. Construis les tiennes. Le décalage de contexte et les risques de sécurité ne valent pas le gain de temps.

Traite le contexte comme un budget, pas comme un conteneur. Chaque token dans le context window se dispute l'attention du modèle. Dépense les tokens délibérément pour l'information dont la tâche actuelle a besoin. Affame tout le reste.

Ross présente ça comme un changement de paradigme, et je ne pense pas que ce soit exagéré. Les développeurs qui maîtriseront l'ingénierie de contexte — qui traiteront le régime d'informations de leurs agents IA comme une préoccupation d'ingénierie de premier ordre — vont surpasser ceux qui continuent à tout déverser dans un fichier de configuration en espérant que le modèle s'en sortira.

Les modèles sont assez intelligents. La question, c'est de savoir si nous sommes assez intelligents pour bien les nourrir.

Foire aux questions

Ai-je vraiment besoin d'un fichier CLAUDE.md ou agents.md ?

Uniquement si tu as des conventions universelles qui s'appliquent réellement à chaque interaction — préférences de langage, règles de structure de projet ou patterns propriétaires que le modèle ne connaîtrait pas. Garde-le sous les 200 lignes. Pour la plupart des développeurs solo, 50 à 100 lignes est le sweet spot où tu obtiens des conventions cohérentes sans payer un overhead excessif en tokens.

Combien de skills devrais-je construire avant de voir de vrais gains de productivité ?

La plupart des développeurs voient une amélioration significative après 3 à 5 skills bien conçues qui couvrent leurs workflows les plus répétés. Ne vise pas une grosse bibliothèque dès le début — concentre-toi sur les tâches que tu fais au quotidien et construis à partir de là. J'ai atteint un point d'inflexion notable à 8 skills.

Puis-je convertir mon CLAUDE.md existant en skills ?

Oui, et tu devrais. Regroupe les instructions liées en clusters spécifiques à un workflow, applique le test des "trois fois" à chaque cluster, puis construis des skills pour ceux qui passent le test. Les instructions qui n'entrent dans aucun workflow spécifique restent dans ton fichier de configuration épuré.

Quelle est la différence entre les skills et les MCP tools ?

Les skills sont des paquets de connaissances — elles disent à l'agent comment aborder une tâche. Les MCP tools sont des capacités — elles permettent à l'agent d'effectuer des actions comme lire des fichiers, exécuter des commandes ou appeler des APIs. Les skills dirigent le raisonnement de l'agent ; les tools étendent ce qu'il peut faire. Elles sont complémentaires, pas concurrentes.

Comment savoir si mon context window est trop plein ?

Surveille trois signaux : l'agent commence à répéter des suggestions qu'il a déjà faites, les temps de réponse ralentissent sensiblement, ou l'agent rate des instructions que tu as clairement fournies. Ces signes indiquent que le contexte est saturé et que le modèle perd le focus. Utilise /compact ou /clear pour récupérer de l'espace.

Travaillons ensemble

Tu veux construire des systèmes IA, automatiser des workflows ou scaler ton infrastructure tech ? Je serais ravi de t'aider.

• Fiverr (développements et intégrations sur mesure) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design et branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io