Méthode agents IA

Le contexte

Cette page ne présente pas un produit, elle présente une façon de travailler. Depuis juillet 2026, je développe et je fais mes recherches avec Claude Code et des agents spécialisés. Profilia a été construit entièrement de cette façon : conception, code, traductions en cinq langues, relecture scientifique, suivi de la production.

Les dépôts concernés restent privés, donc il n’y a pas de code ici. Ce qui suit décrit l’organisation, les règles et ce qu’elles ont permis d’éviter. Précision utile : il n’y a pas d’IA dans les produits eux-mêmes. Les agents servent à fabriquer et à vérifier, pas à répondre aux utilisateurs.

Le défi

Un agent IA produit vite du travail plausible. Le difficile est ailleurs :

• Il se trompe avec assurance. Un chiffre repris de mémoire, une citation attribuée au mauvais auteur, une recommandation qui a l’air sourcée. Rien ne signale l’erreur.
• Les leçons ne survivent pas d’une session à l’autre. Une erreur corrigée un mardi revient le jeudi dans un autre dépôt, parce que la correction vivait dans une conversation.
• Une règle écrite n’est pas une règle appliquée. Une consigne formulée en « quand c’est important » laisse le déclenchement au jugement de celui qui est en train de se tromper.
• Le coût est réel et mal attribué. Tout ce qui est chargé dans le contexte est relu à chaque tour. Sans mesure, on optimise ce qu’on voit travailler, pas ce qui coûte.

Ce que j’ai fait

Une doctrine écrite une seule fois

• Un dépôt central de recherche, le QG, porte la méthode. Les autres dépôts la lisent par lien symbolique, posé par un script qui tourne sur macOS, Linux et Windows et qui refuse de travailler s’il ne peut pas créer de vrais liens. Une leçon générique se corrige à un seul endroit.
• Deux fichiers séparés : les règles, courtes et chargées dans chaque session, et les cas, c’est-à-dire ce qui s’est passé, ce qui a été cru puis démenti, avec les dates et les chiffres. Les cas ne sont jamais chargés automatiquement : on les ouvre pour contester une règle ou vérifier qu’une situation y ressemble.
• Chaque règle a un déclencheur observable, pas une intention. Par exemple : « une ligne qui associe un nom de produit et un prix est une recommandation d’achat, et passe par le vérificateur ». Le critère se repère sans jugement.

31 agents, chacun avec un mandat

• Au QG, sept agents : un éclaireur pour cartographier un sujet, un lecteur profond, un comparateur, un vérificateur dont le seul rôle est de réfuter, deux spécialistes de domaine et un forgeron qui crée, corrige et supprime les autres agents. Un agent inutilisé après plusieurs recherches est fusionné ou supprimé, et chaque changement est journalisé.
• Sur Profilia, dix agents métier : traduction et validation des cinq langues, relecture scientifique des contenus contre une base de sources fichées, revue de diff avant mise en production, diagnostic de l’intégration continue, lecture de Sentry, de l’indexation Google et Bing, et des chiffres de production en lecture seule.
• Quatorze autres agents répartis sur des dépôts de recherche personnels, chacun limité à son domaine.
• Le modèle est choisi par agent, et déclaré : un modèle léger pour une validation déterministe, un modèle intermédiaire pour la recherche et la relecture, le plus capable réservé à quelques agents, comme l’enquête sur la production. Un agent sans modèle déclaré hérite du plus cher ; un hook refuse donc tout agent qui n’en déclare pas.
• Les outils avant les agents : seize scripts au QG, dont un lecteur de pages qui résistent, un transcripteur de vidéos, des « canaris » qui vérifient qu’un accès mesuré hier fonctionne encore aujourd’hui, et un audit du coût en tokens par cause.

Des hooks qui bloquent

Les hooks sont des scripts que Claude Code exécute avant ou après une action. Je ne les utilise pas pour rappeler une règle, mais pour refuser l’action quand une règle déjà enfreinte une fois est sur le point de l’être à nouveau : agent sans modèle, doctrine au-dessus de son plafond ou prix sans marqueur de vérification. Chaque garde est testé sur deux cas : celui qui doit déclencher, et le cas ressemblant qui ne doit pas.

Une recherche livrée, pas racontée

Une recherche suit le même protocole à chaque fois : cadrage, lecture de la mémoire du dépôt avant toute recherche web, nombre d’agents proportionné à la question, vérification adversariale des conclusions, rapport daté qui commence par la réponse. Depuis le 3 juillet, 49 recherches ont été menées et archivées ainsi.

Trois histoires vérifiables

Vingt sources, une seule phrase

Lors d’une recherche sur l’outillage communautaire d’un jeu vidéo, une affirmation revenait partout : l’éditeur aurait annoncé bannir automatiquement les joueurs utilisant deux chargeurs de modules précis. L’agent de recherche l’a rapportée comme un fait, et je l’ai écrite trois fois dans le rapport.

Le vérificateur, à qui l’on demande de réfuter et non de confirmer, a remonté la chaîne. La phrase exacte venait de la page de présentation d’un projet tiers, celui-là même qui avait intérêt à expliquer son propre arrêt. Aucun canal de l’éditeur ne l’avait jamais dite. Le contrôle de fraîcheur ne pouvait rien voir, la page n’avait pas de date ; le comptage de sources non plus, elles citaient toutes la même phrase.

La règle qui en est sortie tient en une ligne : une annonce attribuée à quelqu’un se remonte à son propre canal, sinon on écrit « affirmé par un tiers, jamais confirmé ». Plus tôt dans l’été, une recommandation d’achat non vérifiée était restée six jours dans une note avant d’être démentie. Depuis, le vérificateur ne se déclenche plus sur une impression d’importance mais sur un critère que l’on peut chercher dans le texte.

Mesurer le coût par sa cause, pas par son dossier

Fin août, j’ai mesuré la consommation de tokens par dépôt sur quatorze jours. Le QG pesait 3 % du total, c’était le dépôt le moins cher par message. Conclusion tentante : il ne coûte rien.

C’était faux, et la correction est venue d’une remarque simple : le QG est appelé par tout. Sa doctrine était importée dans chaque session de la machine, donc son coût apparaissait dans le contexte de tous les autres dépôts, jamais dans le sien. Recalculée par cause, la doctrine représentait 14 à 18 % du contexte de toute la machine.

Après la séparation entre règles et cas, le contexte de départ d’une session Profilia est passé d’environ 110 000 à 48 000 tokens, alors que Profilia ne contient pas la doctrine, il l’importe. Une partie de cette baisse vient d’un autre changement du même jour que je n’ai pas isolé : la direction est certaine, le chiffre exact ne l’est pas. Depuis, tout artefact chargé en permanence se chiffre en tokens par appel multipliés par les appels de la machine, et un hook plafonne la doctrine : elle avait atteint 115 Ko en un mois sans que rien ne l’arrête.

Un garde né d’un incident de production

Sur Profilia, une erreur s’est retrouvée en production sous la forme d’une cascade d’exceptions dans Sentry : un bloc de script placé au mauvais endroit dans un gabarit, invisible à la relecture. Le correctif a été fait, puis la cause a été transformée en garde.

Un hook s’exécute maintenant quand l’agent veut rendre la main. Il refuse de terminer si ce motif réapparaît, si une langue est écrite en dur dans le code, ou si de la logique PHP a été modifiée sans qu’aucun test n’ait tourné dans la session. Il ne vérifie que ce qui a déjà cassé la production, rien de plus, et il ne bloque jamais deux fois de suite pour ne pas enfermer la session dans une boucle.

Même logique pour le coût : la mesure sur trente jours a montré qu’un agent générique, sans mandat écrit, consommait en moyenne trois fois plus par appel qu’un agent métier pour le même service. Un hook ne l’interdit pas, il oblige à justifier le choix au moment de le faire.

Choix de conception

Écrire la règle courte et garder le récit à part. Une règle de quatre lignes relue à chaque tour coûte peu ; son histoire complète, chargée partout, coûtait une part mesurable de toute la machine. Le plafond de taille force l’arbitrage : pour ajouter une règle, il faut souvent en compresser une autre.

Ne jamais supprimer une règle parce qu’elle sert rarement. Les règles les moins citées sont les pièges rares, exactement ceux qu’une doctrine existe pour retenir.

Séparer celui qui produit de celui qui valide. L’agent qui relève une information n’a pas le droit de la marquer comme vérifiée. C’est ce qui rend la règle difficile à contourner, y compris pour moi.

Vérifier ce que l’amont propose avant d’écrire du code maison. Sur Profilia, un agent dédié vérifie ce que Laravel, PHP ou les paquets déjà installés résolvent avant qu’une solution sur mesure soit écrite. Le risque principal d’un dépôt assisté par IA n’est pas le mauvais code, c’est le code plausible qui refait ce qui existait déjà.

En chiffres

Si vous voulez parler de la façon dont c’est organisé, ou que vous mettez en place quelque chose de comparable dans une équipe, écrivez-moi.