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, Codex 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 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, Codex et OpenCode supportent tous les trois 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.

Ce qu’on branche vraiment

La liste des serveurs disponibles s’allonge chaque mois. Les plus utiles au quotidien :

Le serveur Meta est un bon cas d’école, parce qu’il montre l’intérêt et le danger dans le même geste. Un agent qui le consulte repère en trois secondes qu’une campagne est en pause depuis deux jours, ce qu’un humain ne voit qu’en ouvrant le gestionnaire de publicités et en cherchant au bon endroit. Le même agent peut relancer cette campagne, donc dépenser votre argent.

Claude Design : quand la sortie n’est pas du texte

Un agent produit du code, des fichiers, des messages. Il sait aussi produire du visuel.

Claude Design est l’outil de maquette d’Anthropic, en bêta sur les offres Pro, Max, Team et Enterprise. Il vit sur claude.ai/design, et Claude Code y accède directement : la commande /design suivie d’une consigne (« /design un écran de réglages pour une appli bancaire ») fait dessiner l’agent sur un canevas, plusieurs planches posées côte à côte. Vous ouvrez le résultat dans un navigateur, vous sélectionnez un élément, vous le modifiez, et vos retouches s’enregistrent toutes seules. Chaque planche s’exporte en PNG ou en PDF.

L’intérêt tient dans ce basculement. Corriger un détail visuel produit par un agent voulait dire reformuler la demande et espérer que le reste ne bouge pas. Là, vous ajustez directement ce qui vous dérange. Le chemin marche aussi dans l’autre sens : une maquette finie dans Claude Design s’envoie à Claude Code pour être développée, et /design-sync téléverse le système de composants React de votre dépôt pour que les maquettes utilisent vos vrais composants.

C’est utile pour des maquettes d’interface, des enchaînements d’écrans, une page d’accueil, des visuels de réseaux sociaux, une affiche. Gardez en tête que c’est une bêta : l’outil évolue vite, et /design demande une version récente de Claude Code.

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, rangés dans .claude/agents/ (projet) ou ~/.claude/agents/ (global). Le plus simple pour en créer un : le décrire à Claude, qui écrit le fichier. Codex a le même principe : il lance des sous-agents (la commande /agent permet de passer de l’un à l’autre), et vos agents personnalisés sont de petits fichiers TOML rangés dans .codex/agents/ (projet) ou ~/.codex/agents/ (global). 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 et nulle part ailleurs. 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, Codex et OpenCode, côte à côte

Les trois agents partagent la même philosophie, avec chacun son écosystème. Et ils ne proposent pas les mêmes modèles : la page Outils de code de Quelle IA recense quels modèles on trouve dans quel outil (Claude Code, Codex, OpenCode, Cursor…), avec le score de chacun.

codex mcp add context7 -- npx -y @upstash/context7-mcp   # un serveur MCP lancé en local
codex mcp list                                           # ce qui est déclaré

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.