🛠️Mettre en place vos agents

Vous savez maintenant ce qu’est un agent : un modèle, des outils, et une boucle qui le fait recommencer jusqu’au but. Avec Claude Code ou OpenCode fraîchement installés, vous avez déjà un agent parfaitement fonctionnel, système de fichiers, terminal, git, recherche. Mais c’est l’agent par défaut, celui de tout le monde. Cette fiche, c’est le passage à votre agent : on enrichit ses outils, on le branche à vos données, et on borde son comportement pour qu’il bosse comme vous voulez.

Donner plus d’outils via MCP

Le levier le plus puissant s’appelle MCP : Model Context Protocol. C’est un standard ouvert, devenu en deux ans la prise universelle entre un agent et le reste du monde. L’idée : au lieu de coder une intégration sur mesure pour chaque service, vous ajoutez un petit programme, un serveur MCP : et l’agent gagne d’un coup une poignée de nouvelles actions.

Le concept est plus parlant en exemples. Connectez votre agent à Postgres, et il peut interroger votre base directement : « combien de commandes hier ? », il écrit la requête et vous répond. Connectez-le à GitHub, et il gère vos issues et vos pull requests sans quitter le terminal. Branchez un serveur de recherche web, un accès à votre système de fichiers, votre outil de tickets, votre propre service maison : chaque serveur MCP, c’est une rallonge de bras pour l’agent.

Claude Code et OpenCode supportent tous les deux MCP. Concrètement, vous déclarez un serveur dans la config de votre agent (un nom, une commande à lancer, parfois une clé d’API), vous redémarrez, et les nouveaux outils apparaissent. Les serveurs courants, filesystem, GitHub, Postgres, Slack, sont déjà tout faits ; vous n’écrivez rien, vous pointez vers eux.

Les sous-agents : déléguer pour rester propre

Un agent peut faire appel à des sous-agents : des agents auxiliaires qu’il lance lui-même, chacun avec son propre contexte tout neuf et une mission précise. Un sous-agent qui part fouiller la codebase pendant que le principal continue. Un sous-agent « relecteur » dédié à la revue de code. Un sous-agent qui teste une hypothèse en parallèle.

Pourquoi ça compte ? Pour deux raisons très concrètes. D’abord, ça garde le contexte principal propre : la recherche tous azimuts dans cinquante fichiers se fait dans la tête du sous-agent, qui ne vous remonte que la conclusion. Le fil principal ne se noie pas sous les détails. Ensuite, ça parallélise : trois sous-agents qui bossent en même temps sur trois bouts indépendants, c’est trois fois plus rapide.

Claude Code formalise ça avec des sous-agents et des types d’agents personnalisés (un agent « explorateur », un agent « architecte »…), chacun avec ses propres outils et ses propres consignes. On verra les patrons concrets, quand déléguer, comment cadrer un sous-agent, dans la fiche suivante. Pour l’instant, retenez juste que la capacité existe : votre agent n’est pas seul, il peut monter une petite équipe.

Border les permissions

C’est le réglage le plus important de tous, et celui qu’on néglige le plus. Un agent agit, il peut donc casser. Border ses permissions, c’est décider quels outils et quelles commandes il a le droit de lancer librement, et lesquels exigent votre feu vert. C’est ici, très concrètement, que vous réglez le curseur d’autonomie dont on parlait dans la fiche précédente.

Les briques sont partout les mêmes :

• L’allowlist (liste blanche). Vous autorisez d’avance les gestes sans danger et réversibles : lire des fichiers, lancer les tests, faire un git status. L’agent les enchaîne sans vous interrompre.
• La règle « demande avant X ». Pour tout ce qui modifie ou détruit, supprimer, pousser sur une branche distante, toucher au réseau, installer un paquet, l’agent s’arrête et demande. C’est le réglage de tous les jours : fluide sur l’inoffensif, prudent sur le reste.
• Jamais root à l’aveugle. Ne laissez jamais un agent enchaîner des sudo sans relecture. Une commande privilégiée mal formée ne casse pas un projet, elle casse la machine.
• Cantonnez le répertoire de travail. L’agent bosse dans le dossier de votre projet, pas dans tout le système de fichiers. Un agent qui ne peut écrire que sous ~/projets/mon-app ne peut pas, même en se trompant, toucher ailleurs.

La config et la mémoire

Au démarrage, votre agent lit sa configuration et ses fichiers mémoire. C’est là que vivent les instructions permanentes : « ce projet utilise pnpm, pas npm », « écris les messages de commit en français », « ne touche jamais au dossier legacy/ ». Vous l’écrivez une fois, l’agent s’en souvient à chaque session, sans que vous ayez à le répéter. C’est ce qui transforme un agent générique en agent qui connaît votre projet et vos habitudes.

On ne détaille pas ici, la mémoire a sa propre fiche, complète, dans Fichiers mémoire. Retenez le rôle : la config définit ce que l’agent peut faire et avec quels outils, la mémoire définit ce qu’il sait en permanence sur votre monde.

Claude Code et OpenCode, côte à côte

Les deux agents partagent la même philosophie, mais pas le même écosystème.

La marche à suivre

Voici la check-list pour passer de l’agent par défaut à un agent taillé pour vous.

Vous avez maintenant un agent qui vous ressemble : les bons outils, les bonnes données, les bonnes limites. Reste à apprendre à le faire vivre dans un vrai projet : où poser les fichiers, comment l’équipe partage la config, quels patrons de sous-agents fonctionnent au quotidien.