---
title: "Gardez vos dépôts agnostiques de l'environnement"
description: "J'utilise quatre outils de codage IA différents au cours d'une semaine normale. Voici trois pratiques pour que mes dépôts fonctionnent avec tous, et un problème que je n'ai toujours pas résolu."
date: 2026-08-12
language: fr
canonical: https://gduv.club/fr/articles/harness-agnostic-workspaces
source: gduv.club
---
J'utilise quatre interfaces d'IA au cours d'une semaine normale. Un IDE avec une navigation rapide entre les fichiers quand j'explore, un CLI pour mes projets personnels, une application de bureau pour le travail, et occasionnellement une quatrième quand je veux un second avis sur le même repo.

Ce n'est pas une recommandation, c'est juste ma situation. Et cela a une conséquence : tout ce que je configure dans l'une d'elles est invisible pour les trois autres. Une mémoire de session sauvegardée, une compétence au format d'une plateforme, un fichier de config propre à l'outil. Tout disparaît dès que j'ouvre le même dossier ailleurs.

Ma règle est donc simple. **Seuls les vrais fichiers du repo sont partagés entre les interfaces.** Tout le reste est un confort que je loue.

Trois points en découlent.

## 1. Les compétences sont en Markdown simple, pas dans un format propriétaire

Une compétence ici est simplement une procédure : comment importer un export bancaire, comment publier un article, comment lancer une traduction. Chaque interface sérieuse a désormais son propre format pour cela, et ils sont tous différents.

Les écrire dans le format d'un fournisseur permet l'autocomplétion, mais fait perdre la portabilité. J'utilise donc une version plus basique : un fichier Markdown par procédure, dans un dossier `skills/` au sein du repo.

```
skills/
  transaction_import_skill.md
  linkedin_post_skill.md
  video_editing_skill.md
```

Je les liste ensuite dans le fichier d'instructions avec un chemin et une ligne expliquant quand les utiliser :

| Compétence | Utiliser quand |
| :--- | :--- |
| `skills/transaction_import_skill.md` | intégration d'un export bancaire dans le grand livre |
| `skills/linkedin_post_skill.md` | transformation d'une idée ou d'une source en un post publiable |

N'importe quel agent, dans n'importe quel outil, peut lire ce tableau, ouvrir le fichier dont il a besoin et le suivre. Il n'y a pas de runtime et rien à enregistrer. Lorsqu'une nouvelle interface apparaît, elle est opérationnelle dès le premier jour.

## 2. Un seul fichier d'instructions, via lien symbolique

`AGENTS.md` devient 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 :

```bash
ln -s AGENTS.md CLAUDE.md
```

Il n'y a plus qu'un seul fichier, quatre lecteurs, et une règle écrite en haut : **seul `AGENTS.md` doit être édité**. Le lien symbolique suit automatiquement.

Ce que cela évite n'est pas spectaculaire, et c'est précisément pour cela que c'est utile. Deux fichiers d'instructions divergent sur quelques semaines, et vous vous retrouvez avec deux agents suivant avec assurance deux conventions différentes dans le même repo.

## 3. Partir du principe qu'aucune mémoire ne survit à la session

Chaque interface a une forme de mémoire persistante et aucune ne la partage. Ainsi, tout ce qui est important, je l'écris dans un fichier : les décisions dans un log, les conventions dans les instructions, les procédures dans une compétence.

Cela ressemble à du travail supplémentaire. En pratique, c'est le même travail effectué une seule fois au lieu de quatre, et cela a eu un effet secondaire inattendu. Les notes écrites pour qu'un agent puisse les lire sont finalement des notes que je peux relire six mois plus tard. Mes propres notes se sont améliorées car j'ai commencé à les écrire pour un lecteur n'ayant aucun contexte.

## Ce que je n'ai pas encore résolu : les serveurs MCP

Chaque interface nécessite que les connexions MCP soient configurées séparément. Mêmes serveurs, mêmes identifiants, quatre configurations, et elles finissent par diverger.

C'est aussi un gaspillage qui se ressent sur la facture. Un serveur d'analyse que j'utilise expose 275 outils. Chacune de ces définitions, avec sa description et son schéma, occupe du contexte à chaque requête, alors que j'en appelle peut-être quatre.

Mon hypothèse pour la suite : un serveur MCP unique que l'on connecte une seule fois dans chaque interface, lequel gère ensuite quels sous-serveurs et quel sous-ensemble d'outils sont exposés par projet. Un système comme le code mode de Cloudflare aiderait ici, en remplaçant un flux de définitions d'outils par une petite interface que le modèle appelle par programmation. Cela réglerait aussi un second désagrément : le fait de lancer le même serveur avec différents comptes selon le projet.

Si quelqu'un a déjà résolu cela, j'aimerais le savoir. C'est la dernière pièce de ma configuration qui a encore une forme d'outil plutôt qu'une forme de fichier.