Les agents au service d'un projet

Vous savez ce qu’est un agent et comment il boucle. Mais tant qu’on en reste à « il m’a écrit une fonction », on passe à côté de l’essentiel. Le vrai déclic, c’est le jour où vous arrêtez de voir l’agent comme un autocomplete++ et où vous commencez à le voir comme un coéquipier que vous pointez sur une tâche bornée. Là, ce n’est plus un gadget : ça change votre façon de bosser. Et toute la valeur tient dans quelques patterns : des manières de vous en servir qu’on va dérouler une par une.

Quatre façons de vous en servir au quotidien

Un agent n’est pas une chose. C’est un rôle que vous lui assignez. Selon ce que vous lui demandez, le même outil devient quatre coéquipiers différents.

L’exécutant

Le pain quotidien. Vous décrivez une fonctionnalité en français, « ajoute un endpoint qui renvoie les 10 derniers articles, avec pagination et un test », et l’agent l’implémente : il lit le code existant pour s’aligner sur vos conventions, écrit la fonction, écrit le test, le lance, corrige si ça casse. Vous, vous relisez le diff. Vous êtes passé de « celui qui tape » à « celui qui valide ». C’est 80 % de votre usage, et c’est déjà énorme.

Le relecteur

Celui-là, on l’oublie trop souvent. Au lieu de demander à l’agent d’écrire, vous lui demandez de relire : il prend votre diff et le passe au peigne fin, bugs logiques, secret oublié dans un commit, régression silencieuse, cas limite pas géré. C’est un second regard infatigable, qui ne se lasse jamais à 18 h un vendredi. Claude Code le fournit d’origine, sans rien installer : /review (un alias de /code-review) relit le diff en cours à la recherche de bugs, et /security-review passe les changements de votre branche au crible des failles de sécurité, injections, authentification, fuite de données. On détaille la méthode dans Relire, auditer, sécuriser. Un relecteur dédié attrape ce que votre œil, fatigué d’avoir écrit le code, ne voit plus.

Le chercheur

« Où est gérée l’authentification dans ce projet ? » « Comment cette lib fait son cache, en vrai ? » Plutôt que d’ouvrir 40 fichiers à la main, vous envoyez un agent fouiller, votre codebase, la doc, le web, et il vous ramène la réponse, débarrassée de la pile de fichiers. C’est un explorateur qui lit vite, retient l’essentiel, et vous le résume. Vous gardez votre concentration pour décider, lui fait le travail de fourmi.

Le metteur au propre

Renommer une variable dans 60 fichiers. Migrer d’une vieille API vers la nouvelle partout. Mettre à jour les dépendances et réparer ce qui casse. Ces tâches sont répétitives, mécaniques, assommantes pour un humain, et parfaites pour un agent qui ne se lasse pas et ne saute pas une ligne par distraction. Vous décrivez la transformation une fois, il l’applique partout, méthodiquement.

Le multi-agent : découper pour mieux régner

Pour un petit boulot, un seul agent suffit largement. Mais sur un gros chantier, auditer toute une codebase, mener une migration de fond, un seul agent finit par s’étouffer : son contexte se remplit de mille détails, il perd le fil, il confond les fichiers. La parade, c’est l’orchestration. Un agent chef de file découpe le travail, délègue des bouts à plusieurs sous-agents qui bossent en parallèle, chacun avec son propre contexte propre, puis il rassemble leurs retours et fait la synthèse.

Chef de file Agent orchestrateur découpe la tâche, répartit, synthétise

délègue en parallèle

• Sous-agent 1 · son propre contexte Recherche lit la doc, le web
• Sous-agent 2 · son propre contexte Code écrit la fonctionnalité
• Sous-agent 3 · son propre contexte Relecture cherche les bugs

Chacun a son propre contexte : plus de travail abattu sans saturer une seule fenêtre.

Pourquoi c’est mieux qu’un seul gros agent ? Trois raisons concrètes :

• Contexte propre par tâche. Le sous-agent qui cherche où est l’auth n’a pas besoin de savoir comment se fait le rendu. Chacun garde une tête claire, focalisée sur son bout. Pas de pollution, pas de confusion.
• Parallélisme. Trois sous-agents qui fouillent trois coins du code en même temps, c’est trois fois plus rapide qu’un seul qui fait la queue. Sur un audit, ça compte.
• Croisement de regards. Un sous-agent qui vérifie le travail d’un autre, c’est moins d’erreurs. Le code passe par une tête, la relecture par une autre, exactement comme une vraie équipe où personne ne valide son propre boulot.

C’est précisément comme ça qu’un workflow (ou une « flotte ») d’agents attaque un audit de sécurité ou une grosse migration : un orchestrateur, des spécialistes, une synthèse. Claude Code en fournit un patron tout fait : /batch suivi d’une consigne étudie la codebase, découpe le changement en unités indépendantes, vous présente le plan, puis lance un sous-agent par unité, chacun dans sa propre copie de travail git (un worktree).

Les agents qui tournent tout seuls

Jusqu’ici, vous lancez l’agent et vous attendez. Mais un agent peut aussi tourner en tâche de fond ou sur un planning, sans que vous soyez devant. Une revue automatique des PR chaque matin avant que vous arriviez. Une veille techno qui vous résume les nouveautés du jour. Un monitoring qui surveille un service et vous ping si ça déraille. C’est là que la mini-machine prend tout son sens : un petit PC qui ne dort jamais, avec un agent qui bosse pendant que vous, vous vivez votre vie. On creuse tout ça dans la fiche suivante, pour l’instant, retenez juste que c’est possible.

Comment bien s’en servir

Les patterns, c’est le quoi. Voici le comment, cinq réflexes qui font la différence entre un agent qui vous aide et un agent qui vous fait perdre votre temps.