Le markdown comme assurance : pourquoi votre méthode agentique doit survivre au modèle

C'est la question qui revient le plus souvent quand je discute avec des personnes qui commencent à investir sérieusement dans une méthode agentique : "et si demain Claude ne marche plus, ou que l'abonnement explose, ou qu'un nouveau modèle sort et rend tout mon travail obsolète, je fais comment ?"

C'est une inquiétude légitime et elle mérite une réponse honnête plutôt que rassurante. Parce qu'il y a deux versions de cette réponse qui circulent et elles ne sont pas équivalentes.

La première version, celle qu'on lit souvent dans les contenus promotionnels, dit que le markdown est portable, donc votre travail l'est aussi, donc vous pouvez changer de modèle sans réapprentissage. C'est trop simple pour être vrai.

La deuxième version, plus nuancée, dit que le markdown préserve la méthode mais pas nécessairement la tactique. Ce qui survit à un changement de modèle, c'est la structure, la taxonomie des rôles, les règles de fond et l'expérience que vous avez accumulée sur comment organiser votre travail. Ce qui ne survit pas tel quel, c'est la formulation précise des prompts, les tournures qui marchent mieux sur un modèle que sur un autre et certains outils ou conventions spécifiques à un système.

C'est cette deuxième version que je veux défendre ici, parce qu'elle est plus juste et aussi parce qu'elle reste très positive pour qui travaille sérieusement en agentique. La portée de ce qui est portable est largement suffisante pour que l'investissement en vaille la peine, à condition qu'on comprenne bien ce qu'on gagne.

Ce qui est vraiment portable

Quand votre méthode est écrite en markdown dans des fichiers sur votre disque dur, vous possédez plusieurs choses qui sont indépendantes du modèle qui les exécute.

La structure de votre arborescence. Le fait d'avoir un manifeste d'agents, des rôles bien séparés, une distinction claire entre index et contenu détaillé, une hygiène de sources uniques (dont j'ai parlé dans le deuxième article de cette série). Cette structure est le fruit d'un travail de conception qui vaut pour n'importe quel modèle qui sait lire du markdown, c'est-à-dire essentiellement tous.

La taxonomie de vos rôles. La liste des agents que vous avez identifiés, ce qu'ils font, comment ils se coordonnent. Cette connaissance de votre propre domaine est ce que vous avez de plus précieux, et elle est gravée dans vos fichiers, pas dans les tripes d'un modèle.

Les règles de fond. Les principes métier, les conventions, les interdits, les exemples canoniques. Ces règles sont ce qui définit votre expertise. Un modèle peut les lire et les appliquer plus ou moins bien, mais les règles existent indépendamment de lui.

Votre historique de décisions. Les notes sur pourquoi vous avez choisi telle convention, pourquoi vous avez abandonné tel pattern, ce qui a marché et ce qui n'a pas marché. Cet historique est littéralement votre expérience accumulée, et si vous le gardez en markdown, vous pouvez le relire, le montrer à un collègue, ou le donner à un nouveau modèle qui en tirera ce qu'il peut.

Votre travail lui-même. Les documents produits, les itérations, les versions successives. Tout est sur votre disque, lisible par n'importe quel éditeur de texte, y compris celui de votre système sans la moindre installation.

Cet ensemble représente la plus grande partie de la valeur que vous avez construite. Et il est entièrement portable, au sens strict : un changement de modèle ne le touche pas.

Ce qui demande une adaptation

Le reste, qui est une minorité, n'est pas perdu mais demande du travail quand vous changez de modèle. Et il vaut mieux en être conscient pour ne pas avoir de mauvaise surprise.

Les formulations qui exploitent un modèle particulier. Chaque famille de modèles a ses habitudes. Claude réagit bien à certaines formulations, Qwen préfère d'autres tournures, Mistral a son propre style d'interprétation. Un prompt très soigneusement travaillé pour Claude Opus ne donnera pas exactement le même résultat avec Qwen3-32B en local, même si le fond est identique. Vous gardez le fond, vous adaptez la forme.

Les instructions sur le comportement méta. Des choses comme "sois concis", "n'utilise pas d'emojis", "vérifie toujours avant d'écrire". Ces instructions marchent sur tous les modèles raisonnables, mais leur efficacité varie. Certains modèles ont besoin qu'on les leur répète à chaque tour, d'autres les intègrent durablement. Là encore, le fond est portable, le dosage est à calibrer.

Les outils spécifiques. Si vous vous appuyez sur des outils propres à un système (les sous-agents de Claude Code, des MCP spécifiques, des hooks particuliers), ces outils ne seront pas disponibles tels quels ailleurs. La logique que vous aviez implémentée avec eux reste valable, mais il faudra la réimplémenter avec les outils disponibles dans votre nouvelle stack.

Les conventions de fichiers spéciaux. CLAUDE.md est une convention Claude. AGENTS.md en est une autre, utilisée par d'autres systèmes. Le contenu reste pertinent, mais le nom du fichier et la place qu'il occupe dans l'exploration automatique peuvent changer. C'est une migration mécanique, pas un réapprentissage, mais c'est du travail.

Le travail d'adaptation, quand il se présente, dure généralement quelques heures pour quelqu'un qui maîtrise sa méthode et quelques jours pour quelqu'un qui la redécouvre en même temps qu'il migre. C'est incomparablement moins coûteux que de tout reprendre à zéro, mais ce n'est pas nul, et c'est important de le dire.

Pourquoi c'est structurellement mieux que l'alternative

Pour mesurer la valeur de cette approche, il faut la comparer à ce qu'elle remplace. Et ce qu'elle remplace, c'est l'usage "conversationnel" d'un modèle IA, où tout se passe dans des conversations qui disparaissent dès que vous fermez l'onglet.

Dans ce mode, votre expertise n'est nulle part, ou plutôt elle est dans votre tête et dans le fil de conversations dispersées que vous ne pouvez pas exploiter systématiquement. Vous reconstruisez le contexte à chaque session. Vous réexpliquez à chaque fois qui vous êtes, ce que vous faites, ce que vous attendez. Vous obtenez des réponses qui ne s'accumulent pas, qui ne se structurent pas, qui ne vous font pas progresser durablement.

Le jour où le modèle change, dans ce mode, vous repartez de zéro. La raison n'est pas qu'un contenu a été perdu : il n'y avait simplement rien de durable à conserver.

Dans le mode markdown structuré, votre expertise est dans le dossier. Chaque session enrichit le dossier. Chaque règle que vous découvrez est ajoutée au bon fichier. Chaque erreur que vous corrigez est documentée pour que le modèle ne la refasse pas. Le dossier grossit, se précise, devient de plus en plus juste. La valeur que vous accumulez dans le dossier ne dépend ni du modèle du moment ni du nombre de tokens que vous avez consommés.

Et le jour où le modèle change, vous ne repartez pas de zéro. Vous repartez du même point, avec la plus grande partie qui est portable, et vous faites le travail d'adaptation pour la minorité restante. C'est une autre économie du travail avec l'IA : celle où le dossier est un actif qui se bonifie au lieu d'un coût récurrent.

La différence avec "utiliser une IA"

C'est là qu'apparaît la vraie distinction, qui n'est pas "ancien modèle versus nouveau modèle" mais "utilisateur versus praticien".

Utiliser une IA, c'est avoir un outil qui répond à vos questions quand vous lui en posez. C'est utile, c'est souvent impressionnant, mais rien de ce qui se passe dans ces conversations ne s'accumule quelque part où vous pourriez le retrouver plus tard. L'outil assiste la tâche du moment, il ne construit rien de persistant.

Travailler en agentique avec un dossier markdown structuré, c'est construire un système qui capture votre expertise à mesure que vous travaillez. Les décisions prises en conversation deviennent des règles, les règles deviennent des fichiers et ces fichiers conditionnent la qualité des conversations suivantes. Chaque session rend la suivante un peu plus efficace. Ce qui a de la valeur, à terme, c'est le système que vous avez construit, indépendamment du modèle qui l'exécute aujourd'hui.

Cette distinction n'a rien de technique au sens strict. C'est un changement de posture. On passe du rapport "je consomme l'IA" au rapport "je construis avec l'IA, et ce que je construis est à moi". Et ce changement de posture est précisément ce qui rend votre travail durable.

Ce que le leak de Claude Code confirme

Ce que je viens de décrire n'est pas une idée à moi. Le leak de Claude Code montre que l'équipe d'Anthropic a conçu son propre système de mémoire exactement selon ce principe. MEMORY.md est un fichier markdown. Les topic files sont des fichiers markdown. Les transcripts sont du JSONL lisible. Tout est sur disque, tout est inspectable, tout est modifiable avec un éditeur de texte.

Andrej Karpathy l'a formulé dans un thread que je citais déjà dans l'article parent : quatre principes dont "file over app" (des fichiers plutôt qu'une application), "data under user control" (les données sous le contrôle de l'utilisateur), et "BYOAI" (bring your own AI, c'est-à-dire modèle interchangeable).

Cette convergence n'est pas un hasard. Anthropic, qui a pourtant tout intérêt à verrouiller les utilisateurs dans son écosystème, choisit d'exposer la mémoire en markdown plutôt que de la cacher dans une base propriétaire. Karpathy, qui vient du monde de la recherche, arrive indépendamment à la même conclusion. Des praticiens individuels qui n'ont jamais vu le code de Claude Code construisent des systèmes similaires. Quand le même pattern émerge partout, ce n'est plus un choix de produit, c'est un principe d'ingénierie.

Et le principe est celui-ci : la vraie propriété de votre travail en IA se trouve dans le dossier qui reste sur votre disque après la fin de la conversation.

Conclusion de la série

Cette série a exploré trois conséquences pratiques des principes que j'avais extraits du leak de Claude Code. Une source de vérité par rôle pour éviter les comportements erratiques. Un contexte optimisé pour rester efficace et économique. Du markdown comme assurance pour que la méthode survive à l'outil.

Les trois se rejoignent dans une même idée : un système agentique se construit, comme on construirait n'importe quel autre système d'ingénierie. Discipline des sources, discipline du contexte, discipline de la portabilité. Rien de plus, rien de moins.

Si vous appliquez ces trois principes, vous êtes beaucoup mieux armé que la plupart des utilisateurs d'IA actuels, non pas parce que vous utilisez un meilleur modèle, mais parce que vous avez un meilleur scaffold. Et, comme le disait le premier article de cette série, le modèle est nécessaire, le scaffold est suffisant.

L'inférence locale, c'est le sujet connexe sur lequel je travaille avec herbert-rs. Une fois que votre méthode est portable, le choix du modèle devient une décision tactique. Et parmi les décisions tactiques possibles, faire tourner votre méthode sur un modèle open-source en local est une option qui mérite d'être considérée sérieusement. C'est le sujet du panorama LLM 2026 et c'est une des raisons pour lesquelles je construis un moteur d'inférence : la portabilité ultime de votre méthode, c'est de pouvoir l'exécuter chez vous, sur votre matériel, avec un modèle dont vous avez les poids.

Des questions sur cet article ou votre propre projet ? Réserver une consultation