DevAgentConfig

Le point de départ

À mesure que j’utilisais plusieurs agents et plusieurs machines, la configuration de développement commençait à se fragmenter : mêmes méthodes copiées à plusieurs endroits, règles différentes selon l’outil et risque de recréer du contexte dans chaque repository applicatif.

DevAgentConfig est né pour faire l’inverse : garder une source de vérité unique pour la manière de travailler avec les agents, puis laisser chaque projet ne posséder que son contexte propre.

Les contraintes

Claude Code et Codex n’utilisent pas les mêmes emplacements de configuration, et Windows natif, WSL ou une machine distante n’ont pas le même filesystem ni les mêmes contraintes d’exécution. Le système doit donc rester portable sans imposer de dupliquer les repositories applicatifs.

Il doit aussi rester discret dans les projets : les skills globaux ne sont pas copiés localement, les contextes professionnels privés restent séparés, et l’agent doit commencer par comprendre où il s’exécute avant de proposer des commandes, une preview ou un nouveau checkout.

Les choix qui ont compté

Le repository sépare les méthodes génériques des overlays privés. Des installateurs Linux/macOS/WSL et Windows exposent les skills via symlinks ou junctions, synchronisent les politiques globales et installent des hooks qui rejouent cette synchronisation après les mises à jour Git.

Plusieurs règles sont devenues de vrais contrats de travail : réutiliser le checkout existant avant de créer un clone, ranger les worktrees dans un espace dédié, initialiser les nouveaux projets avec un socle documentaire minimal, et préférer une live preview pilotée par l’humain pendant les itérations visuelles plutôt qu’un navigateur agent utilisé en permanence.

Où le projet en est

La configuration est aujourd’hui utilisée sur plusieurs environnements et alimente à la fois Claude Code et Codex. Les skills, politiques et garde-fous sont centralisés ; le chantier courant porte surtout sur la qualité des handoffs entre l’agent et l’utilisateur selon la topologie réelle — Windows, WSL ou devbox distante.

Le repository reste privé parce qu’il contient aussi des overlays de travail qui n’ont pas vocation à être publiés. La méthode générique, elle, est progressivement extraite en principes réutilisables dans mes autres projets et dans Brand OS.

Ce que j’en retiens

La portabilité d’un environnement agent ne se résume pas à partager un prompt. Il faut partager les règles, les points d’entrée et les garde-fous, tout en laissant le runtime s’adapter à la machine réellement utilisée.

Autre apprentissage : pour les tâches visuelles, automatiser davantage n’est pas toujours plus efficace. Quand l’utilisateur possède déjà le bon navigateur, la bonne session et le bon contexte, l’agent gagne souvent à modifier le code pendant que l’humain observe le résultat, puis à réserver l’automatisation navigateur à la validation ciblée.