Gardez vos dépôts indépendants des environnements d’exécution

J’utilise quatre environnements d’exécution IA au cours d’une semaine normale. Un IDE avec une navigation rapide entre les fichiers quand j’explore, une CLI pour mes projets personnels, une application de bureau pour le travail, et parfois un quatrième outil quand je veux un deuxième avis sur le même dépôt.

Ce n’est pas une recommandation, c’est simplement ma situation. Et elle a une conséquence : tout ce que je configure dans l’un de ces outils reste invisible aux trois autres. Une mémoire de session enregistrée, une compétence dans le format d’une plateforme, un fichier de configuration propre à un outil. Tout disparaît dès que j’ouvre le même dossier ailleurs.

La règle que je suis est donc simple. Seuls les vrais fichiers du dépôt sont partagés entre les environnements d’exécution. Tout le reste est un service que je loue pour me faciliter la vie.

Trois choses en découlent.

1. Des compétences en Markdown brut, pas dans le format d’une plateforme

Ici, une compétence n’est qu’une procédure : comment importer un relevé bancaire, publier un article ou lancer une traduction. Tous les environnements d’exécution sérieux ont désormais leur propre format pour ces procédures, et ils sont tous différents.

Les rédiger dans le format d’un fournisseur vous donne la complétion automatique, mais vous fait perdre en portabilité. J’utilise donc une version plus simple : un fichier Markdown par procédure, dans un dossier skills/ du dépôt.

skills/
  transaction_import_skill.md
  linkedin_post_skill.md
  video_editing_skill.md

Ensuite, je les répertorie dans le fichier d’instructions, avec un chemin et une ligne indiquant quand les utiliser :

N’importe quel agent, dans n’importe quel outil, peut lire ce tableau, ouvrir le fichier dont il a besoin et le suivre. Pas de moteur d’exécution ni d’inscription à effectuer. Quand un nouveau framework apparaît, il fonctionne dès le premier jour.

2. Un seul fichier d’instructions, avec un lien symbolique

AGENTS.md est en train de devenir la convention, et plusieurs outils le lisent directement. L’un des outils que j’utilise cherche plutôt CLAUDE.md.

Un simple ln -s suffit à régler le problème :

ln -s AGENTS.md CLAUDE.md

On a maintenant un seul fichier, quatre lecteurs et une règle inscrite en haut : seul AGENTS.md doit être modifié. Le lien symbolique se met à jour tout seul.

Ce n’est pas un problème spectaculaire, et c’est justement pour cela que ça vaut la peine de s’en occuper. Au bout de quelques semaines, deux fichiers d’instructions divergent, et deux agents finissent par appliquer avec assurance des conventions différentes dans le même dépôt.

3. Partir du principe que rien ne survit à la session

Chaque environnement d’exécution dispose d’une forme de mémoire persistante, mais aucun ne la partage avec les autres. Alors, je consigne dans des fichiers tout ce qui compte : les décisions dans un journal, les conventions dans les instructions et les procédures dans une compétence.

Ça peut sembler être du travail en plus. En pratique, c’est le même travail fait une seule fois au lieu de quatre, avec un effet secondaire auquel je ne m’attendais pas. Ce que j’écris pour qu’un agent le lise s’avère aussi utile à relire pour moi six mois plus tard. Mes propres notes se sont améliorées parce que j’ai commencé à les rédiger pour quelqu’un qui n’a aucun contexte.

Le problème que je n’ai pas résolu : les serveurs MCP

Chaque environnement d’exécution nécessite une configuration distincte pour ses connexions MCP. Les mêmes serveurs, les mêmes identifiants, quatre configurations qui finissent par diverger.

C’est aussi du gaspillage, et ça se voit sur la facture. Un serveur d’analytique que j’utilise expose 275 outils. La définition de chacun, avec sa description et son schéma, occupe de la fenêtre de contexte à chaque requête, alors que je n’en appelle peut-être que quatre.

À mon avis, la solution serait un serveur MCP unique, auquel on se connecte une fois dans chaque environnement d’exécution. Il gérerait ensuite les sous-serveurs et les outils qu’ils exposent pour chaque projet. Le mode code de Cloudflare pourrait être utile : au lieu d’inonder le contexte de définitions d’outils, il fournirait une petite interface que le modèle appelle par programmation. Cela réglerait aussi un autre problème : utiliser le même serveur avec des comptes différents selon le projet.

Si quelqu’un a déjà résolu ce problème, j’aimerais le savoir. C’est le dernier élément de ma configuration qui repose sur des outils plutôt que sur des fichiers.

Sources

• Claude Code 2.1.277 ajoute une solution de repli pour AGENTS.md
• La spécification AGENTS.md