Un agent IA avec Claude : comment je m'y prends

« On a pris Claude, et franchement on n'a pas vu la différence. » Je l'entends régulièrement, et c'est souvent exact. Brancher un agent sur un dépôt et lui demander de travailler produit un résultat tiède, parfois pire que ce qu'un développeur aurait écrit seul. Ce qui déplace vraiment l'aiguille n'est pas l'outil, c'est ce qu'on installe autour.

Monter un agent IA avec Claude qui tient sur la durée relève moins de la configuration que de la préparation : l'agent ne vaut que ce que votre projet a écrit de lui-même. Sur mes propres projets, je fais tourner une petite équipe de sous-agents spécialisés, chacun avec son contexte versionné dans le dépôt à côté du code, et c'est cette mémoire écrite qui décide de la qualité du résultat, pas le modèle qu'on a choisi.

La mémoire vit dans le dépôt, pas dans l'agent

Un agent qui démarre sans mémoire repart de zéro à chaque fois. Il repose les questions auxquelles vous avez répondu la semaine dernière, repropose la technologie que vous aviez écartée pour de bonnes raisons, réinvente une convention tranchée six mois plus tôt. Ce n'est pas un défaut qu'on corrige avec de meilleures instructions : c'est un défaut de dispositif. La parade que j'applique est simple à décrire et longue à installer : ce que le projet sait de lui-même est écrit dans le dépôt, en markdown, à côté du code, et relu comme du code. Les décisions d'architecture et leurs raisons, les choix écartés, les conventions, les pièges rencontrés en production, le vocabulaire métier. Versionné, daté, attribué.

Le point qui surprend les dirigeants à qui j'explique ça, c'est que le bénéfice principal n'est pas pour l'agent. Un document qui dit pourquoi vous avez retenu telle base de données et renoncé à telle autre sert d'abord à la personne qui arrive dans l'équipe. L'agent se contente de le lire systématiquement, sans jamais oublier de le faire, ce qui est déjà plus que ce qu'on obtient d'un humain pressé. J'ai détaillé cette mécanique dans le monorepo-mémoire. Si rien n'est écrit aujourd'hui chez vous, c'est là que commence le chantier, bien avant de choisir un outil.

Cinq agents étroits valent mieux qu'un agent qui sait tout

Le réflexe naturel consiste à donner à un seul agent toutes les instructions, toutes les conventions et tous les critères de qualité. Ça fonctionne mal, pour une raison assez humaine : plus on charge un contexte, plus les consignes se diluent et plus l'agent risque d'en ignorer une partie. Un agent à qui on demande d'écrire du code, de vérifier la sécurité, de soigner le référencement et de relire la cohérence produit fera les quatre moyennement. J'ai basculé vers une autre organisation : un agent principal qui reçoit la demande, découpe, distribue et rassemble, derrière lui des sous-agents étroits qui ne font qu'une chose. Chacun a son fichier de contexte versionné, qui décrit ce qu'il cherche, ce qu'il ignore et sous quelle forme il rend son verdict.

La spécialisation a un effet secondaire que je n'avais pas anticipé : elle rend les désaccords visibles. Quand le relecteur sécurité bloque quelque chose que le relecteur produit juge indispensable, l'arbitrage me remonte explicitement au lieu de se résoudre en silence dans un compromis moyen. C'est devenu une des sources d'information les plus utiles sur l'état réel d'un projet. Pour la définition propre de ce qu'est un agent et de ce qui le distingue d'un chatbot, j'ai écrit un article séparé.

Le temps s'est déplacé vers l'amont, et ça déstabilise

Le changement le plus difficile à faire accepter dans une équipe n'est pas technique : il porte sur la répartition du temps. Dans le fonctionnement classique, on cadre vite et on code longtemps, parce que le code est l'opération coûteuse. Avec un agent bien outillé, l'opération coûteuse change de place : l'exécution devient rapide et c'est le cadrage qui détermine presque tout. Une demande floue produit un résultat flou, livré très vite et très proprement, soit le pire des cas puisque le défaut se repère tard. J'ai vu des équipes conclure que l'approche ne marchait pas alors qu'elles avaient gardé l'ancien ratio entre réflexion et exécution.

Le plus déroutant, c'est de passer la matinée à écrire ce qu'on attend, et l'après-midi à relire quelque chose qui est déjà fini. J'ai eu l'impression de ne plus faire mon métier avant de comprendre que c'était devenu mon métier.

Concrètement, le travail consiste à décrire le contexte technique, les contraintes métier, les cas limites et le résultat attendu, puis à laisser l'agent contester ce cadrage avant qu'il n'écrive quoi que ce soit. Cette phase de contestation est souvent la plus rentable : elle fait apparaître des questions que l'équipe n'avait pas posées, parce qu'un agent n'a aucune gêne à demander ce qui paraît évident. Pour un responsable, c'est le moment où l'on découvre ce qui n'avait jamais été formalisé. J'ai raconté deux cas concrets de ce basculement.

Ce que ça change pour une équipe, pas seulement pour un développeur

Du point de vue d'un dirigeant, l'erreur serait de voir là un outil de productivité individuelle qu'on distribue et dont on mesure l'effet par personne. Ce qui se joue est une redistribution du travail : moins de temps passé à produire, beaucoup plus à spécifier, à arbitrer et à vérifier. Les profils qui prennent de la valeur sont ceux qui savent transformer une intention en énoncé précis et juger un résultat sans l'avoir écrit. Cette bascule ne se décrète pas, surtout dans une équipe qui n'a pas l'habitude d'écrire.

Reste une question de responsabilité, qu'il vaut mieux trancher tôt. Un agent n'a pas de jugement sur ce qui compte pour votre entreprise, pas de mémoire de vos engagements s'il ne les a pas reçus, et il ne viendra pas vous dire qu'il s'est trompé. Il faut donc décider ce qu'il a le droit de faire seul, ce qui passe obligatoirement par un humain, et où sont les traces quand ça se passe mal. Ces garde-fous sont la partie la moins spectaculaire du sujet et de loin la plus structurante : c'est le cœur de mon guide sur l'IA agentique.

Ce qui ne marche pas, et pourquoi je le dis

Je me méfie des comparatifs qui tranchent entre les modèles du moment : ils se périment vite et masquent ce qui sépare vraiment deux équipes équipées à l'identique, à savoir que l'une a écrit ce que son produit sait de lui-même et l'autre non. J'utilise Claude parce que j'y ai construit mes automatismes, pas parce que je saurais démontrer qu'il bat ses concurrents sur votre cas. Ce qui ne fonctionne pas, je l'ai assez vu : lâcher un agent sans conventions écrites, lui confier une tâche dont personne ne sait formuler le critère de réussite, ou mesurer le succès au volume de code produit. Les trois mènent à un enthousiasme bref suivi d'un rejet durable, souvent porté par les développeurs les plus expérimentés, et leurs raisons sont bonnes. La formation sert d'abord à poser ce socle.

Je n'ai pas la conviction que ma façon de travailler aujourd'hui sera encore la bonne dans six mois : les environnements d'agents bougent vite et une partie de mes réglages deviendra caduque. Ce qui ne bougera pas, à mon avis, c'est que la qualité du résultat dépend de ce que l'organisation a pris la peine d'écrire. Cette partie-là n'est pas un sujet d'outillage mais de discipline, et c'est pour ça qu'elle résiste : elle demande du temps à des gens qui n'en ont pas. Si vous envisagez d'accompagner ce déploiement chez vous, c'est par cette conversation que je commence, jamais par une démonstration.