Ma méthode de travail avec les agents IA

J'utilise le même montage dans chaque projet où un agent fait un vrai travail. Je m'en suis servi sur trois bases de code très différentes : un produit grand public, un pipeline de développement commercial et un suivi de données personnel. Des domaines différents, le même squelette. L'ensemble tient autour de deux répertoires, skills/ et resources/, et d'une décision : l'agent a tous les droits dans le dépôt.

L'idée centrale

Un agent ne vaut que ce qu'il peut voir et ce qu'il a le droit de faire. La plupart des montages échouent sur l'un des deux. Soit ils laissent le savoir métier dans la tête d'une personne, soit ils enrobent chaque action d'une demande de confirmation jusqu'à ce que l'agent ne vaille plus la peine d'être utilisé. Cette méthode traite les deux : écrire le savoir là où l'agent le lit, puis lui laisser le champ libre.

`skills/`

Un dossier par tâche que l'agent effectue. Chaque dossier a un SKILL.md et, quand le travail a un cœur déterministe, un dossier scripts/.

SKILL.md s'ouvre sur un en-tête YAML portant un name et une description. La description est une liste de déclencheurs en langage naturel, les phrases que je tape réellement : « enregistre mon déjeuner », « trouve des prospects pour cette campagne », « montre ce que j'ai mangé cette semaine ». L'agent fait la correspondance sur ces phrases et charge la compétence de lui-même. Je n'appelle jamais une compétence par son nom.

Le corps est une procédure courte : rassembler les entrées, faire la chose, rendre compte. Le jugement reste en prose. Tout ce qui est mécanique (une insertion en base, un appel d'API, un scrape de données sur des centaines de lignes) va dans un script que l'agent exécute, pour que cela se déroule pareil à chaque fois et ne déverse jamais de données brutes dans la fenêtre de contexte.

Les compétences viennent en couches, et chacune indique où elle se situe. Une compétence de couche écriture enregistre quelque chose ; une compétence de lecture ou de diagnostic la relit et l'interprète. Là où un projet a une séquence naturelle, les couches forment un pipeline fixe que l'agent suit dans l'ordre, et chaque compétence note sa position dans ce pipeline.

`resources/`

Une référence partagée qui n'est liée à aucune compétence en particulier. Markdown uniquement. Une compétence lit le fichier pertinent comme contexte avant d'agir. Contenu typique :

Schéma — la forme des données que les compétences lisent et écrivent.
Profil — mes objectifs, mes points de référence et mes contraintes, pour que l'agent juge les résultats par rapport à la bonne cible plutôt qu'à une cible générique.
Vocabulaire — les noms canoniques des choses, pour que les entrées restent cohérentes d'une exécution à l'autre.
Modèle du domaine et plans d'action — comment le système sous-jacent fonctionne, et la marche à suivre pas à pas pour les phases du travail.

La séparation est le point clé. Les compétences sont des verbes, les ressources sont des noms. Une compétence dit à l'agent comment faire quelque chose ; une ressource lui dit ce qui est vrai. Une base de code plus grande peut garder ce même savoir dans un document d'orientation de haut niveau et un jeu de fichiers de référence plutôt que dans un dossier resources/, mais le rôle est identique.

Le reste du squelette

Un document d'orientation. Quelque chose qui permet à l'agent de raisonner sur le système sans lire chaque fichier. Pour une grande base de code, c'est une longue carte des pièces mobiles et de leurs liens. Pour une petite, c'est l'ordre du pipeline et un tableau pointant vers les compétences, plus les phrases déclencheuses dans chaque SKILL.md, ce qui garde le dépôt auto-descriptif.
Une configuration d'agent versionnée. Les listes d'autorisations, les plugins activés et les serveurs MCP vivent dans le dépôt, pas dans le montage local de quelqu'un.
Un état que l'agent possède directement. Un fichier de base de données local, des répertoires de données simples, des dossiers de sortie de scripts. Aucune couche de service entre l'agent et les données.
Un frontal de type bot quand j'en veux un. Un chatbot ou un webhook qui invoque les mêmes compétences que la CLI, pour qu'il y ait une seule implémentation, pas deux.
Des dossiers d'évaluation et d'itération. Là où je teste et affine le prompt d'une compétence face à des cas enregistrés avant de lui faire confiance.

Connexions optionnelles

Les plugins et les serveurs MCP ne font pas partie du squelette de base, mais ils élargissent ce que l'agent peut atteindre sans que j'écrive un script pour chaque intégration. Ils sont déclarés dans la configuration versionnée pour qu'un clone neuf les récupère. Ceux sur lesquels je m'appuie :

Plugin Vercel — déploiements, variables d'environnement et état de déploiement, pour que l'agent puisse livrer un changement et confirmer sa mise en ligne.
Plugin GitHub — pull requests, tickets et revues depuis la session au lieu de passer par git et le navigateur.
Passerelle MCP Docker — un point d'accès unique devant un ensemble d'outils conteneurisés (automatisation de navigateur, recherche, veille), pour que l'agent dispose d'une large panoplie sans installation séparée pour chacun.

La règle est la même que pour les compétences : une connexion ne mérite sa place que si elle supprime une friction réelle. Tout le reste est écarté pour que la liste d'outils reste lisible.

Tous les droits

L'agent, presque toujours un modèle Claude, s'exécute sans restriction à l'intérieur du dépôt. Il lit, écrit, exécute des scripts et valide sans demander à chaque fois.

C'est un compromis délibéré, et il fonctionne grâce à l'endroit où les garde-fous se trouvent réellement :

Le dépôt est le rayon d'action. Chaque projet est cantonné à un domaine. Un agent dans un projet ne peut pas atteindre les données d'un autre projet.
Git est le bouton d'annulation. Chaque changement est un diff que je peux lire et annuler.
Les sauvegardes tournent sur minuteur. Tout ce qui n'est pas du code source, comme une base de données locale, se copie selon un calendrier et garde un historique glissant.
« Aucune confirmation nécessaire » est écrit par compétence, pas présumé. Une compétence d'enregistrement dit de l'écrire directement. Une compétence qui envoie des e-mails ou dépense de l'argent dit l'inverse. La posture par défaut est rapide ; les exceptions sont explicites.

Les demandes de confirmation à chaque action ne font que vous entraîner à cliquer sans lire. Je préfère rendre l'environnement sûr pour aller vite et consacrer mon attention à lire les diffs.

Pourquoi c'est portable

Les domaines sur lesquels je l'ai utilisé n'ont rien en commun. La méthode passe quand même de l'un à l'autre parce qu'elle ne porte pas sur le domaine. C'est une façon de découper un système en ce que l'agent fait (skills/), ce que l'agent a besoin de savoir (resources/ et le document d'orientation), ce qu'il a le droit de toucher (la configuration versionnée) et là où vivent les données (des fichiers qu'il possède). Démarrer un nouveau projet, créer ces quatre éléments, et l'agent est productif dès le premier jour.