File Engineering : Le Guide d'Anthropic qui change tout pour les Vibe Coders

TL;DR : Anthropic (l'entreprise derrière Claude Code, Opus et Sonnet) vient de publier un document technique qui valide ce que les meilleurs Vibe Coders pratiquent depuis des mois : le prompt ne suffit plus. La vraie compétence, c'est de structurer des fichiers .md qui donnent à l'IA le bon contexte au bon moment. C'est la fin du Prompt Engineering et le début du File Engineering.

---

Le constat : le prompt est un cul-de-sac

Si tu as lu mon Build in Public #10, tu sais que j'ai atteint les limites du "chat" avec l'IA : perte de contexte, hallucinations, coûts qui explosent. Ma solution : externaliser la mémoire du projet dans des fichiers Markdown et connecter Cursor à Notion via MCP.

Ce que je ne savais pas, c'est qu'Anthropic allait publier un document officiel qui valide exactement cette approche et va encore plus loin.

Leur guide s'appelle "Skill Authoring Best Practices". Derrière ce titre technique se cache une philosophie applicable à tous les modèles d'IA, pas seulement Claude. Et elle se résume en une phrase :

Arrête de perfectionner tes prompts. Perfectionne tes fichiers.

Le prompt est éphémère — il disparaît à la fin de la conversation. Un fichier .md bien structuré, lui, reste. Il s'améliore. Il devient ton avantage compétitif.

---

1. L'économie de contexte : chaque token est une ressource rare

Le concept de "bien public"

Anthropic utilise une formulation frappante : "La fenêtre de contexte est un bien public." Ton texte partage cet espace avec le prompt système, l'historique de conversation, les métadonnées des autres compétences et ta demande.

C'est comme un bureau de travail. Si tu empiles des dossiers partout, tu ne trouves plus rien. L'IA, c'est pareil : trop d'informations = moins de pertinence.

La règle d'or : "Claude est déjà intelligent"

C'est leur conseil le plus contre-intuitif. Anthropic demande de partir du principe que l'IA sait déjà la plupart des choses. Avant d'écrire un paragraphe de contexte, pose-toi trois questions :

1. "Est-ce que l'IA a vraiment besoin de cette explication ?"
2. "Puis-je supposer qu'elle sait ça ?"
3. "Ce paragraphe justifie-t-il son coût en tokens ?"

C'est exactement ce que j'ai constaté sur ResumeRank. Quand j'ai réduit mon fichier tech_stack.md de 120 lignes à 35, en virant toutes les explications que Claude connaissait déjà, la qualité du code généré a augmenté. Moins de bruit, plus de signal.

Avant / Après : la différence en pratique

La version concise est 3 fois plus légère et donne exactement le même résultat. L'IA sait ce qu'est un PDF. Pas besoin de le lui expliquer.

Concrètement : si tes fichiers de contexte (tech_stack.md, rules.md) contiennent des explications que l'IA connaît déjà, tu gaspilles des tokens et tu pollues sa mémoire. Sois chirurgical.

---

2. La Progressive Disclosure : le sommaire plutôt que l'encyclopédie

Le problème du fichier géant

L'erreur du débutant, c'est de créer un seul fichier énorme avec toute la documentation du projet et de le coller dans le chat. Résultat : l'IA est submergée. C'est comme donner un livre de 500 pages à un stagiaire en lui demandant de trouver une info précise — il va mettre des heures.

La solution d'Anthropic : l'arborescence intelligente

Le concept de Progressive Disclosure (divulgation progressive) est le cœur du document. L'idée : créer un fichier principal (SKILL.md) qui fonctionne comme un sommaire. L'IA ne charge les chapitres détaillés que quand elle en a besoin.

Le mécanisme :

1. Au démarrage, l'IA ne voit que le nom et la description de chaque Skill.
2. Quand le Skill devient pertinent, elle lit le fichier SKILL.md (le sommaire).
3. Si elle a besoin de plus de détails, elle suit les liens vers les fichiers spécifiques.

Le résultat : les fichiers non utilisés consomment zéro token. C'est l'exact opposé du copier-coller massif dans le chat.

C'est ce que j'ai mis en place sur Sam Tennis avec mon Notion connecté via MCP : l'IA ne charge les specs de l'Epic "Gamification" que quand je lui demande de travailler dessus. Tout le reste (Onboarding, Stripe, etc.) reste "dormant" et ne pollue pas le contexte.

Règle critique : pas de nesting profond

Anthropic met en garde : garde les références à un seul niveau de profondeur. Si SKILL.md pointe vers advanced.md qui pointe vers details.md, l'IA va probablement survoler details.md au lieu de le lire en entier.

❌ SKILL.md → advanced.md → details.md (trop profond)
✅ SKILL.md → advanced.md + reference.md + examples.md (un seul niveau)

---

3. Les degrés de liberté : quand cadrer, quand lâcher

C'est peut-être le concept le plus subtil du document, et celui que la plupart des gens ignorent.

L'analogie du pont et du champ

Anthropic utilise une métaphore que j'adore :

• Le pont étroit avec des falaises des deux côtés : il n'y a qu'un seul chemin sûr. Il faut des garde-fous stricts et des instructions exactes. → Exemple : une migration de base de données.
• Le champ ouvert sans danger : beaucoup de chemins mènent au succès. Donne la direction générale et fais confiance à l'IA. → Exemple : une revue de code.

Les 3 niveaux en pratique

L'erreur la plus courante : mettre une liberté basse sur tout. Ça transforme l'IA en exécutant robotique qui ne peut plus s'adapter. L'inverse est tout aussi dangereux : une liberté haute sur une migration de base de données peut détruire tes données.

Sur ResumeRank, j'ai appris ça à mes dépens. Quand j'ai laissé l'IA en liberté haute sur la migration Supabase, elle a changé des noms de colonnes que d'autres services utilisaient. Depuis, toutes mes instructions de migration sont en liberté basse : "Exécute exactement ce script, ne modifie rien."

---

4. Le pattern Plan → Validate → Execute

Anthropic insiste sur une boucle qu'ils appellent le feedback loop. C'est la version formalisée de ce que j'expliquais dans mon article sur le workflow Cursor :

1. Plan : l'IA crée un fichier intermédiaire (ex : changes.json) qui décrit ce qu'elle va faire
2. Validate : un script vérifie que le plan est cohérent avant d'exécuter
3. Execute : l'IA applique les changements uniquement si la validation passe

Pourquoi c'est critique : imagine que tu demandes à l'IA de mettre à jour 50 champs dans un formulaire PDF. Sans validation, elle pourrait référencer des champs qui n'existent pas, créer des valeurs conflictuelles, ou oublier des champs obligatoires. Avec la boucle, chaque erreur est attrapée avant qu'elle ne cause des dégâts.

---

5. Le développement itératif : "Claude A" et "Claude B"

C'est la partie la plus contre-intuitive du document. Anthropic recommande d'utiliser deux instances de Claude pour créer et tester tes fichiers de contexte :

• Claude A (l'architecte) : il t'aide à concevoir et rédiger les fichiers .md
• Claude B (le testeur) : une instance fraîche qui utilise les fichiers pour effectuer de vraies tâches

Le cycle :

1. Tu travailles avec Claude A pour créer un Skill
2. Tu testes avec Claude B sur un cas réel
3. Tu observes où Claude B galère
4. Tu reviens vers Claude A pour améliorer

C'est exactement la "revue par les pairs artificielle" dont je parlais dans le guide Cursor. Sauf qu'ici, Anthropic formalise le processus et le rend systématique.

---

6. Ce que ça change pour toi, concrètement

Ce document n'est pas réservé aux développeurs d'Anthropic. Chaque concept est applicable immédiatement dans Cursor, Lovable (via Custom Knowledge), ou même ChatGPT.

Le File Engineering en 4 actions (ce soir)

Action 1 : Crée ton arborescence de fichiers .md

Si tu n'as pas encore de fichiers de contexte dans tes projets, commence ce soir avec ces 3 fichiers minimum :

• tech_stack.md : tes technologies (et rien d'autre)
• rules.md : les règles que l'IA doit suivre
• tasks.md : les tâches en cours

Action 2 : Applique la Progressive Disclosure

Si un fichier dépasse 100 lignes, découpe-le. Crée un fichier principal qui pointe vers des fichiers de détail. L'IA ne chargera que ce dont elle a besoin.

Action 3 : Calibre tes degrés de liberté

Pour chaque instruction, demande-toi : "Est-ce un pont étroit ou un champ ouvert ?" Cadre strictement les opérations fragiles (BDD, déploiement), laisse de la liberté sur le créatif (design, rédaction).

Action 4 : Installe la boucle feedback

Après chaque bug résolu, demande à l'IA : "Comment aurais-je dû formuler ma demande pour éviter ce problème ?". Ajoute la réponse dans ton fichier rules.md. Ton système s'améliore à chaque erreur.

---

Le mot de la fin : du Prompt Engineer au File Engineer

Le Prompt Engineering, c'était l'art de formuler la bonne question. C'était utile quand l'IA était un chatbot.

Le File Engineering, c'est l'art de construire le bon environnement. C'est ce qu'il faut quand l'IA devient un agent qui travaille sur tes projets.

La différence fondamentale : un prompt disparaît, un fichier reste. Et un fichier qui s'améliore à chaque itération devient un avantage compétitif que personne ne peut copier — parce qu'il encode ton expérience, tes erreurs, tes préférences.

Ce document d'Anthropic confirme une tendance de fond : la barrière à l'entrée n'est plus technique, elle est organisationnelle. Celui qui sait structurer le contexte pour l'IA construira plus vite et mieux que celui qui sait écrire les meilleurs prompts.

Et ça, c'est une bonne nouvelle pour les Solo Builders.

---

Questions fréquentes

C'est quoi le File Engineering exactement ?

Le File Engineering, c'est l'art de structurer des fichiers de contexte (.md, .txt) pour donner à l'IA les bonnes informations au bon moment. Au lieu de perfectionner tes prompts (Prompt Engineering), tu perfectionnes tes fichiers. L'avantage : un prompt disparaît à la fin de la conversation, un fichier reste et s'améliore avec le temps.

Est-ce que ça marche uniquement avec Claude et Cursor ?

Non. Les principes — concision, Progressive Disclosure, degrés de liberté, boucle de feedback — s'appliquent à tous les modèles (GPT, Gemini, Mistral) et tous les outils (Cursor, Lovable, ChatGPT, Windsurf). Anthropic a formalisé ces bonnes pratiques, mais elles fonctionnent universellement parce que tous les LLM partagent la même contrainte : une fenêtre de contexte limitée.

Je n'ai aucun fichier de contexte, par où je commence ?

3 fichiers à la racine de ton projet : tech_stack.md (tes technologies), rules.md (les règles pour l'IA), et tasks.md (les tâches en cours). Puis, à chaque bug résolu, mets à jour rules.md avec la leçon apprise. En quelques semaines, tu auras un système qui connaît toutes les subtilités de ton projet. J'en parle en détail dans le Build in Public #10.

Progressive Disclosure, ça veut dire quoi concrètement ?

C'est le principe de ne pas tout donner à l'IA d'un coup. Tu crées un fichier "sommaire" qui pointe vers des fichiers de détail. L'IA ne charge un fichier que quand elle en a besoin. Résultat : moins de tokens consommés, moins de pollution de contexte, et une IA plus pertinente. C'est comme un sommaire de livre : tu ne lis que le chapitre qui t'intéresse.

---

À très vite, Guillaume 👋