Si tu travailles déjà avec une IA pour t'aider à écrire des emails ou du code, tu as déjà vu le problème. L'IA démarre très vite et bien, puis perd le fil. Elle invente, oublie une contrainte, ressort un format différent que celui demandé. La cause est presque toujours la même : on lui a parlé sans cadre, sans plan, sans critères de réception. La méthode à quatre fichiers vise précisément ce problème. Voici comment elle fonctionne.
Je suis Johan Iavarone, Product Builder indépendant. Cet article présente la méthode à quatre fichiers que je documente et que j'utilise dans mon propre travail, en m'appuyant sur des références publiques. Tu peux l'appliquer telle quelle ou l'adapter à ton contexte.
Pourquoi une méthode écrite ?
Anthropic a publié fin 2025 et début 2026 une série d'articles sur ce qu'ils appellent les Dynamic Workflows et l'agentic engineering. L'un des exemples documentés sur leur blog est le port de leur outil interne CLI vers Bun, porté par une équipe réduite en quelques jours en s'appuyant sur des sous-agents Claude organisés autour de cadres de travail écrits. Le principe partagé par ces équipes est simple : plus tu écris le contexte, le plan et les critères de réception au début, plus la livraison ressemble à ce que tu voulais. La méthode à quatre fichiers est l'expression la plus minimale de cette discipline.
Elle se compose de quatre documents Markdown. Tu les crées dans un dossier de travail, tu les remplis dans l'ordre, et tu les utilises comme contexte de chaque session avec l'IA.
Fichier 1 : brief.md (le contrat)
Le brief.md contient le contrat. C'est là que tu poses le contexte métier, l'objectif chiffré, les contraintes explicites, et surtout les contre-exemples. Les contre-exemples sont la partie que la plupart des gens oublient. Sans dire « ce n'est pas ça que je veux » au début, l'IA livre le plus probable selon ses données d'entraînement, qui n'est pas toujours ce dont tu as besoin.
Un bon brief.md contient au minimum : l'objectif final en une phrase, le contexte (qui, quoi, quand, pourquoi), les contraintes (longueur, format, ton, technologies imposées), et trois contre-exemples explicites au moins (« le contraire de ce qu'on veut, c'est X, Y, Z »).
Fichier 2 : plan.md (le plan d'attaque)
Le plan.md est produit par l'agent IA à partir du brief.md, pas par toi. C'est important : tu demandes à l'agent de te proposer un plan d'attaque étape par étape, et tu le relis avant de le laisser exécuter. Tu corriges, tu complètes, tu réduis. Cette relecture coupe une grande partie des dérives de session. La règle empirique partagée par plusieurs équipes qui utilisent ce type de méthode est qu'un plan trop confiant, sans nuance, sans alternatives considérées, est presque toujours à réécrire.
Tu signes le plan quand il te convient. À partir de là, l'agent l'utilise comme référence pour ses actions suivantes. S'il s'en écarte, c'est qu'il y a un problème, et c'est plus facile à détecter parce que le plan est écrit.
Fichier 3 : qa-checklist.md (la grille de réception)
La qa-checklist.md est ce qui te permet de dire « oui » ou « non » à la livraison. Pas « j'aime bien » ou « ça a l'air pas mal » : binaire, mesurable, explicite. Si tu n'as pas de checklist, tu n'as pas de moyen objectif de dire que c'est livré, et tu finis par tout accepter par fatigue.
Exemples de critères concrets : « le H1 fait moins de 70 caractères », « l'article contient au moins cinq chiffres datés avec sources citées », « le code passe les tests existants », « la réponse cite au moins une source externe pour chaque affirmation factuelle ». Tout ce qui n'est pas mesurable n'a rien à faire dans la checklist.
Fichier 4 : notes.md (la mémoire)
Le notes.md est la mémoire transversale du projet. Tu y notes ce qui a marché, ce qui a échoué, les patterns répétés, les prompts qui ont donné de bons résultats. Sans ce fichier, chaque session avec l'IA redémarre à zéro et tu refais les mêmes erreurs. Avec, une session unique se transforme en actif réutilisable.
Au début, le fichier est presque vide. Après trois ou quatre projets, il devient ton avantage : tu sais ce qui fonctionne dans ton contexte spécifique, et tu peux le templater pour les missions suivantes.
La règle qui rend la méthode utile
Aucun fichier ne saute l'autre. Pas de plan.md sans brief.md contresigné. Pas d'exécution sans plan.md relu. Pas de clôture sans qa-checklist.md cochée et notes.md mis à jour. C'est une discipline simple, mais c'est elle qui fait la différence entre une session IA productive et une session qui s'éparpille.
Si tu sautes une étape, tu rates en général l'une des deux choses suivantes : soit l'IA part dans la mauvaise direction parce que le cadre n'était pas posé (manque de brief.md), soit tu ne peux pas dire si c'est bon à la fin (manque de qa-checklist.md).
Où cette méthode est utile et où elle ne l'est pas
Elle est utile pour toute tâche qui demande de la précision et plusieurs échanges avec l'IA : rédaction longue, développement logiciel, conception d'un produit, structuration d'une recherche. Elle est en revanche surdimensionnée pour les tâches courtes (un email, une question rapide), où tu peux directement formuler ton besoin en une ou deux phrases sans cadre formel.
Pour les tâches récurrentes, la valeur n'est pas dans la méthode mais dans le notes.md qui capitalise. Après quelques projets, tu obtiens des templates de brief.md, des prompts qui marchent, et la méthode devient un cadre léger qui accélère plutôt qu'il alourdit.
Ressources publiques utiles
Pour aller plus loin sur les fondements de cette approche : le blog d'Anthropic sur les Dynamic Workflows et l'agentic engineering (anthropic.com/news), la documentation de Claude Code et de l'Agent SDK, et les comptes-rendus publics de plusieurs équipes qui ont documenté leur passage à cette discipline pour piloter des sous-agents IA à grande échelle.
Si tu veux qu'on échange sur comment adapter cette méthode à ton contexte (métier, outils, équipe), tu peux m'écrire via la page contact. Premier échange sans engagement.
FAQ : méthode à quatre fichiers
Cette méthode est-elle réservée au code ou utile aussi pour l'éditeur de contenu, le marketing, etc. ?
Elle est utile pour toute tâche structurée où tu travailles avec une IA sur plusieurs échanges : rédaction d'articles longs, conception de produit, recherche, automatisation marketing. Le code est l'exemple le plus documenté publiquement parce qu'il est facile à mesurer, mais la méthode s'applique partout où tu veux un livrable précis.
Faut-il un outil spécifique ?
Non. Quatre fichiers Markdown dans un dossier suffisent. Tu peux les gérer dans VS Code, Cursor, Obsidian, ou n'importe quel éditeur. L'important est la discipline de les remplir et de les utiliser comme contexte de chaque session.
Combien de temps faut-il pour s'y mettre ?
La première fois, compter une heure pour bien remplir le brief.md et obtenir un plan.md propre. Les fois suivantes, c'est plus rapide parce que tu récupères tes templates dans notes.md.
D'où vient l'inspiration de cette méthode ?
Elle synthétise les pratiques documentées publiquement par Anthropic (blog Dynamic Workflows, doc Claude Code), par plusieurs équipes ingénierie qui ont publié leurs comptes-rendus, et par la littérature classique sur la spécification logicielle. Ce n'est pas une invention nouvelle : c'est une formalisation minimale d'un consensus.
