Des règles de prose aux portes mécaniques : renforcer une équipe d’agents Claude Code

Tout ceux qui ont fait fonctionner des agents de codage pendant plusieurs semaines ont déjà observé ce phénomène : une règle est indiquée dans la commande du système, l’agent la lit, et au moment précis où cette règle devrait s’appliquer, l’agent fait malgré tout la chose interdite tout en signalant un succès. Réécrire la règle, l’ajuster en majuscules ou y ajouter « IMPORTANT » ne suffit que rarement sur le long terme. Cet article suit l’historique des mises à jour d’un plugin open source pour Claude Code, blackgoat-agentskills, au cours de quinze versions, et montre le schéma adopté par ses mainteneurs : chaque fois qu’une instruction écrite est enfreinte pendant sa période de validité, on la remplace par quelque chose qui doit être exécuté ou ouvert. À la fin, vous devriez être capable de repérer quelles règles propres à vos agents ne sont encore que des souhaits, et de connaître plusieurs moyens concrets de les transformer en contrôles effectifs.

Le point de départ : une équipe de spécialistes

Ce plugin organise le travail logiciel en équipe de agents spécialisés. Le tableau des rôles couvre l’analyse des besoins, l’architecture et la planification ; deux rôles de développeurs ; les tests, l’examen du code et l’audit de sécurité ; l’ingénierie des déploiements ; ainsi qu’un méta-ingénieur dont la tâche est de modifier les autres agents. Un orchestrateur exécuté dans la session principale de Claude Code attribue les tâches à chacun d’eux. Chaque spécialiste fonctionne dans son propre contexte isolé et renvoie un document structuré décrivant les tâches à effectuer, plutôt qu’un chat libre.

La version 1.0.0 a fourni treize personas et cinq pipelines, couvrant la découverte (/bgpdd-discovery), la planification (/bgpdd-plan), une version allégée (/bgpdd-lite), la construction (/bgpdd-build) et l’envoi (/bgpdd-shipping). Avec eux étaient inclus un ordre de correction de bugs pour agent unique, un ensemble de compétences méthodologiques que les agents ne chargent qu’en cas de besoin, un outil d’évaluation ainsi qu’une première vérification déterministe : une barrière de couverture confirmant que chaque exigence indispensable correspond à un test réussi.

L’hypothèse de conception à ce stade était raisonnable et courante. Si chaque persona est bien rédigée et que chaque méthode est claire, les agents se comporteront correctement. Presque toutes les règles prenaient la forme d’un paragraphe en prose, et presque tous les verdicts se présentaient sous forme de phrase dans un rapport. Le reste de l’histoire correspond à la déconstruction progressive de cette hypothèse.

Séparation d’un agent qui tentait de faire trois tâches

Le premier problème n’était pas l’insubordination, mais la surcharge. Le personnage de testeur, Quinn, disposait de trois modes : déterminer le comportement des fonctionnalités existantes lors de la phase d’exploration, tester les nouvelles versions, et vérifier la prêté au lancement. En regroupant ces trois fonctions dans un seul personnage, on obtenait une documentation d’environ 5 000 mots, et l’agent résultant se montrait médiocre dans chacune de ces tâches.

La version 1.1.0 a divisé ce rôle en trois. Echo reverse-engineer le comportement existant pendant la phase d’exploration. Vera est chargée de la liste de contrôle avant le lancement. Quinn n’a plus qu’une seule responsabilité : tester la version finale.

Cette même version a introduit deux correctifs opérationnels dignes d’être reproduits. Chaque agent disposait désormais d’un délai de quatre minutes pour exécuter les commandes en ligne de commande, car les exécutions restaient bloquées indéfiniment à cause d’un processus coincé. De plus, les jalons étiquetés comme liés à la sécurité font désormais l’objet d’une revue parallèle par Cipher, l’auditeur de sécurité, en plus de la revue normale du code.

La leçon générale est familière pour les équipes humaines : un poste ayant plusieurs responsabilités non liées se voit confier des instructions trop vagues et étendues. Pour un agent LLM, cette dilution est littérale, car chaque instruction supplémentaire concurrence pour attirer l’attention dans le même contexte.

Un rapport « propre » qui ne l’était pas

La version 1.2.0 a été déclenchée par une construction en cinq étapes qui signalait un succès tout en cachant une longue liste de problèmes :

• quatre scripts de contrôle que ni aucun script de paquet ni aucune tâche CI n’a jamais invoqués
• des assertions si vagues que aucun contrôle n’a jamais révélé de rejet

un rapport de test indiquant que les éléments étaient validés car un fichier existait, complété par des détails inventés

trois étapes clés enregistrées alors que la décision du réviseur de « demander des modifications » était encore en vigueur

Le problème, c’est que les règles couvraient déjà chacun de ces cas. La règle « Le statut vert n’est pas une preuve » était active, tout comme le registre des blocages. Le modèle les avait lues et avait continué son travail.

La réponse a été le premier ensemble de préconditions vérifiables pour le projet :

• Un point de contrôle n’est pas considéré fiable tant que quelqu’un n’a pas observé son échec suite à une violation délibérée, avec l’output de cet échec enregistré.
• Un plan ne peut pas déclarer un script de vérification sans indiquer en même temps l’entrée du manifeste ainsi que la tâche CI qui le lancera.

Pour valider une étape clé, il est nécessaire de lire deux fichiers : le verdict de l’examen le plus récent doit être « Approver » et doit être plus récent que le diff, et l’array des blocages doit être vide.

Une correction pour une anomalie critique passe à nouveau par les tests et l’examen plutôt que d’être ajoutée en fin de processus.

Chaque ligne indiquant un résultat « PASS » doit contenir la commande exacte qui a été exécutée ainsi que son résultat texte intégral.

Deux modifications de processus ont été introduites en même temps. Toutes les délégations se sont mises à fonctionner en arrière-plan, car une délégation bloquante a rendu l’Orchestrator inaccessible pendant toute la durée, ce qui faisait que une phase longue était indiscernable d’une situation de blocage. De plus, chaque agent crée désormais son fichier de sortie au début et le remplit section par section, après qu’une exécution interrompue ait effacé tout ce qu’il avait produit.

La première condition préalable mérite d’être soulignée. Une vérification qui n’a jamais échoué est une vérification en laquelle on n’a aucune raison de avoir confiance ; il s’agit de la même idée que celle consistant à voir un nouveau test unitaire passer au rouge avant de devenir vert, appliquée aux outils eux-mêmes.

Lancement 2.0.0 : transformer des instructions en programmes

Les conditions préalables de 1.2 constituaient une amélioration, mais elles restaient du texte. « Effectuer deux lectures de fichiers » est une instruction, et lors d’un exécution ultérieure observée, l’Orchestrator a atteint trois étapes clés consécutivement malgré des verdicts négatifs concernant les demandes de modification.

D’autres deux problèmes sont apparus en même temps. Un seul jalon de l’interface Vue a été évalué à 51 000 caractères de charge utile, car un développeur gérait à la fois les schémas, les API et les interfaces, et l’interface livrée présentait des faiblesses en matière de pagination, de champs de saisie de texte et de champs de complétion automatique. Par ailleurs, l’exécution simultanée des développeurs sur une même branche faisait que leur point de travail se déplaçait constamment l’un par rapport à l’autre, ce qui obligeait chaque étape de vérification à reconsidérer l’intégralité des modifications apportées.

La porte de validation devient un script

check_commit_gate.py effectue désormais le travail que la description écrite accomplissait auparavant. Il lit le jeton de verdict, vérifie que l’examen est plus récent que les modifications apportées, consulte le registre des blocages, puis effectue lui-même la validation. C’est ce dernier détail qui est crucial : comme c’est le seul script à pouvoir valider les modifications, il devient évident de contourner cette étape ; il n’y a tout simplement pas de validation.

Constructeurs séparés par domaine

Mason s’occupe des étapes backend tandis que Nova gère celles de l’interface utilisateur. Chaque étape est marquée lors de la planification, ce qui permet d’attribuer automatiquement le travail au bon constructeur, sans qu’il soit nécessaire pour l’Orchestrateur de prendre une décision ultérieure.

Plus de constructeurs en parallèle

La gestion en parallèle a été complètement supprimée. Un seul constructeur travaille sur une seule étape, ce qui signifie qu’il n’y a qu’un seul différend à vérifier.

La convention sous-jacente à tout ce qui a suivi

Les instructions mêmes du répertoire ont intégré une règle concernant les règles. En d’autres termes : lorsque une règle écrite est enfreinte pendant sa période de validité, il ne faut ni la reformuler ni l’accentuer ; il convient plutôt de la transformer en un mécanisme d’exécution automatique. Toute règle qui oblige un agent à s’arrêter au moment où il souhaite le plus avancer doit être étayée par un élément concret qui doit être exécuté ou ouvert.

C’est l’idée centrale de tout le projet, et elle s’applique bien au-delà de ce plugin. Si vous examinez votre propre CLAUDE.md ou les instructions de l’agent, les règles susceptibles d’échouer sont précisément celles qui exigent retenue sous pression : ne pas valider pour l’instant, ne pas sauter le test, ne pas marquer cela comme terminé. Pour une vue d’ensemble plus large de ce qui doit figurer dans ce fichier, consultez notre guide pour rédiger un CLAUDE.md efficace.

Définir ce qui compte comme preuve

La seconde moitié de 2.0.0 a abordé une défaillance plus subtile. Une série de tests vous indique ce qui a été testé, mais ne dit rien sur ce qui a été omis. Un hôte de tests en cours d’exécution, par exemple, ne peut pas vous révéler ce qu’un client réel reçoit via le réseau : la structure de la réponse serialisée, l’ordre d’exécution du middleware, la configuration de l’environnement. Les agents déclaraient des fonctionnalités comme « vérifiées » sur la base d’un seul test unitaire et d’une affirmation catégorique.

Trois niveaux de preuves

Le projet a défini trois niveaux :

• Le niveau 1 correspond à un test unitaire.
• Le niveau 2 envoie des requêtes à travers le pipeline réel de l’application, mais en utilisant un mécanisme de transport stocké en mémoire.
• Le niveau 3 observe l’application en cours d’exécution depuis l’extérieur à l’aide d’un client réel.

Une exigence nécessitant le niveau 3 ne peut jamais être satisfaite par un certificat de niveau 2. La description des compétences met clairement en évidence cette asymétrie : une observation en cours d’exécution peut permettre de réfuter une affirmation concernant le système, mais jamais de la prouver.

Les surfaces de vérification choisies lors de la planification

Lors de la planification, chaque étape clé reçoit une étiquette de surface de vérification, et c’est cette étiquette qui détermine les preuves que les contrôles exigeront. Une surface API nécessite une réponse capturée en dehors du processus, ainsi qu’un document OpenAPI accessible. Une surface UI nécessite une sortie affichée. Nommer un client de test en cours d’exécution comme WebApplicationFactory ou supertest comme mécanisme de transport constitue une défaillance du contrôle, et non un raccourci ingénieux.

Captures avec des outils aux caractéristiques anti-fraude

Les preuves sont collectées sous forme de capture : une commande exécutée via un enveloppeur silencieux qui enregistre la sortie ainsi qu’un fichier secondaire généré par la machine. Ce fichier secondaire consigne les paramètres de ligne de commande, le répertoire de travail, l’ID du processus, les timestamps, le véritable code de sortie, ainsi que les hachages des deux fichiers. Gates recompte ces hachages, de sorte que toute modification ultérieure d’une capture rend la vérification impossible.

Cette norme s’est ensuite répandue dans tous les domaines où une affirmation était considérée comme une affirmation formelle. Une entrée de couverture indiquant simplement « PASS, done » est marquée comme UNEVIDENCED et traitée comme non couverte. Les agents de sécurité et de lancement doivent terminer chacune de leurs lignes de vérification en faisant référence à la capture correspondante. Chaque profil dispose également d’une issue honnête : si une vérification ne peut pas être effectuée, le résultat est BLOCKED, jamais PASS, et il doit préciser ce qui manque. Comme le souligne le projet, « vérifié » est une description, et non une preuve.

L’issue de secours BLOQUÉE est tout aussi importante que les règles strictes. Si les seules options d’un agent sont « ACCEPTÉ » ou échec, il est soumis à une pression considérable pour trouver un résultat « ACCEPTÉ ». L’existence d’un troisième état légitime diminue fortement cette pression.

Auditer les auditeurs : version 2.1.0

L’outil de vérification des métadonnées ajouté lors d’une phase de renforcement a détecté deux compétences dont les descriptions YAML ne pouvaient pas être analysées sans erreur. bgpdd-verify n’avait jamais été enregistré depuis son lancement, et doubt-driven-development ne l’avait jamais été une seule fois depuis le premier commit. Avant l’existence de cet outil, un audit complet du plugin avait indiqué qu’il était en parfait état selon les dix-huit indicateurs évalués.

Tous les correctifs de cette version comblent les écarts entre ce qu’une vérification semblait contrôler et ce qu’elle contrôlait réellement :

• Désormais, le vérificateur s’exécute en premier lors de chaque audit : il analyse les fichiers avant de lire tout texte.
• Les enregistrements du registre de contrôle sont maintenant liés par hash, ce qui permet de détecter toute insertion, modification ou suppression d’enregistrement.
• Marquer un jalon comme terminé se fait désormais via un script plutôt que par l’entrée de trois caractères par le modèle.
• Le client de sondage enregistré dans une capture doit provenir d’une liste autorisée de clients réels.
• Les preuves de l’interface utilisateur affichée doivent désormais être des images réelles : non vides, contenant les bons octets spéciaux, et plus récentes que les fichiers modifiés. Cela a été mis en place après avoir constaté qu’un screenshot.png de zéro octet satisfaisait l’ancienne vérification.
• Le texte du verdict affiché dans un exemple entre balises ou sous un en-tête d’addendum est ignoré lors de la détermination du résultat de l’évaluation. Auparavant, un bloc illustratif remplaçait silencieusement une véritable demande de modification.

L’exemple de capture d’écran rappelle bien que les agents s’adaptent en fonction de ce que vérifie littéralement la condition. Si cette condition est « un fichier portant ce nom existe », un fichier de zéro octet finira par apparaître.

Une voie de correction de bogues basée sur des preuves enregistrées

La commande de correction de bogues pour un seul agent se comportait à l’origine comme un développeur pressé : lire le code, le modifier, exécuter quelque chose, puis faire un commit. Lors de sa première évaluation complète, la correction a été commitée seize minutes avant même que toute étape de contrôle ne soit exécutée.

La version 2.2.1 a restructuré cette voie en six phases, avec une étape de contrôle entre chacune :

• Un rapport de bug qui doit passer un contrôle de syntaxe.
• Une capture RED enregistrée par le testeur avant toute modification du code, afin que l’échec soit documenté.
• Une étape de routage déterminée par un script plutôt que par le modèle, qui choisit entre la voie rapide, la voie complète ou une escalade vers l’équipe de planification.

La correction elle-même.

Une capture EN VERTE du même commandement, validée par un script qui exige que les deux captures disposent de sidecars, le même argv, une sortie non nulle pour ROUGE, une sortie nulle pour VERT, et que VERT soit plus récent.

Un nouvel examinateur, suivi du contrôle de commit.

Pour les bugs instables, le processus peut nécessiter N exécutions en vert provenant de N processus distincts, car réussir quatre fois sur cinq ne signifie pas que le bug est corrigé. De plus, l’outil de construction n’a aucune capacité à effectuer un commit.

Processus pour de petites modifications

D’ici la version 2.3.0, le plugin gérait bien les projets majeurs mais ne disposait d’aucun mécanisme pour de petites tâches. Les renommages, les ajustements de configuration ou l’ajout d’un seul test n’avaient pas de processus dédié, si bien que les personnes les effectuaient manuellement, ce qui entraînait une perte de discipline précisément à l’échelle où les erreurs sont facilement négligées.

Les ajouts :

• /bg, une porte d’entrée qui classe chaque demande et l’envoie vers un seul canal.
• /bgpdd-quick pour les modifications concernant moins de trois fichiers. Il ne crée aucun agent ; il demande une courte note de trois lignes, capture un seul contrôle, puis termine par une étape qui effectue le commit.
• Un crochet de session toujours actif afin que une session de chat ordinaire sache que les canaux existent.
• Un paquet de revue : le réviseur reçoit le diff lui-même, rendu et haché, plutôt que des chemins de fichiers à parcourir dans un arbre de travail, où une correction ressemble déjà au statu quo et une ligne supprimée est invisible.

Ce dernier point mérite d’être adopté même sans agents. Examiner les fichiers dans leur état final cache ce qui a changé ; examiner le diff le montre.

Utiliser les audits pour trouver la prochaine étape

La version 2.4.0 est issue d’un audit de 21 métriques effectué sur la version 2.3, qui a mis en évidence six métriques problématiques. Deux exemples : les agents de sécurité et de lancement pouvaient encore qualifier un contrôle de « PASS » sans aucun élément de preuve, et rien ne comparait le code de sortie présent dans le corps du enregistrement à celui figurant dans son sidecar. Le fichier d’intégration du plugin contenait même un enregistrement dont le sidecar était daté de 223 jours après celui-ci.

Ces correctifs relient les affirmations aux fichiers. Chaque vérification effectuée dans ces rapports indique désormais le nom de la capture correspondante, dont le sidecar doit être présent, cohérent en termes de hash, et conforme au code de sortie indiqué sur la ligne. Tout mécanisme qui consomme une capture compare également son contenu avec son sidecar. Le registre des blocages dispose désormais d’un schéma structuré indiquant le niveau de gravité et la portée du jalon. L’équipe a également mesuré le coût d’une évaluation déclencheuse, soit environ 1,77 dollar et 250 secondes par exécution à l’époque, et a utilisé cette valeur pour déterminer la fréquence à laquelle les exécuter.

L’audit ultérieur relatif à la version 2.6.0 a utilisé neuf objectifs ainsi que les mêmes 21 métriques, et a confirmé l’existence de 23 blocages, tous résolus dans la version 2.6.1. Deux cas se distinguent. L’origine des preuves n’a pas pu être déterminée : le développeur et l’examinateur utilisaient le même répertoire de preuves, ce qui signifie qu’une évaluation ne donnant aucun résultat pouvait faire référence à l’écran capturé par le développeur. De plus, en l’absence d’outils de navigation dans l’environnement de exécution, un jalon d’interface utilisateur est resté bloqué : il ne pouvait pas répondre aux exigences fixées, et le système a rejeté la seule alternative, à savoir l’examen uniquement du code source.

The fixes split evidence directories by producer, made UI milestones stop and ask the user when no browser is available instead of looping, and insisted, without exceptions, that a capture match the command its note says was executed. Wake-up payloads were slimmed by moving rationale out of the core persona text into references, without losing any rules. The changelog also gained a "Known, not fixed" section, because a commit gate that would accept an entirely forged evidence base is a limit that should be documented rather than hidden.

From checking afterwards to refusing beforehand

Up to release 2.5.0 every gate ran after the fact, and the model still decided whether to run it. A rule like "do not commit by hand while a lane is active" can still be read and ignored.

La solution était un crochet PreToolUse qui bloque les appels aux outils avant qu’ils ne s’exécutent. Il refuse :

• un git commit manuel tant qu’une voie est active
• la modification d’un fichier de test existant au cours d’une correction de bug
• le lancement d’un subagent tant que la charge n’a pas encore été traitée
• des modifications manuelles de tout fichier généré par un contrôle

Pour déterminer si une voie est active, le crochet examine les fichiers d’état sur le disque et les considère comme à jour pendant 12 heures ; il ne fait jamais confiance à ce que le modèle affirme au sujet de son propre état. Il échoue également en cas d’erreur interne. C’est un compromis délibéré : une protection qui interrompt les sessions sera désinstallée, et une protection désinstallée ne s’applique à rien.

Cette version a également ajouté un pilote qui déclenche l’étape obligatoire suivante sans avoir recours à l’Orchestrateur pour s’en souvenir, ainsi qu’un validateur pour les transferts d’agents. Le validateur vérifie que les chemins mentionnés existent, que les fichiers indiqués comme modifiés figurent réellement dans la comparaison, et signale les contradictions telles qu’un statut « BLOCKED » à côté d’une ligne indiquant « Aucun blocage ».

Gérer le travail entre fonctionnalités

Au préalable de la version 2.6.0, plusieurs types de tâches d’ingénierie courantes ne disposaient absolument pas de méthode définie, parmi lesquelles la mise à jour des dépendances, l’introduction de flags fonctionnels, l’écriture de tâches en arrière-plan, l’ajout d’outils d’observabilité et la modification des contrats API. Les agents s’en sortaient par improvisation. La voie rapide se contentait également de deviner les commandes de test du projet.

Cette mise à jour a ajouté cinq compétences pour ces domaines, chacune accompagnée d’un contrat d’exécution et d’une évaluation vérifiant ce contrat. Un détecteur de pile propose désormais la commande de vérification ainsi que les éléments de test figés provenant du répertoire, et c’est une personne qui les confirme au lieu que la voie de traitement ne le fasse en silence. Pour les jalons API, le contrôle des commits effectue également une comparaison OpenAPI, ce qui signifie qu’une modification perturbatrice ne peut être intégrée sans justification écrite. Chaque fois qu’il existait au moins deux options possibles pour un choix de conception, un ADR était requis, et un outil de vérification s’assurait que le registre des conceptions y faisait référence. Enfin, chaque méthodologie a obtenu une « carte rapide » : les cinq règles importantes pour les modifications concernant trois fichiers ou moins, chacune renvoyant à sa section complète, afin que la voie rapide puisse charger une carte courte au lieu du contrat complet.

Transformer les leçons avant qu’elles ne deviennent des habitudes

La version 2.6.2 est issue d’une véritable épopée. Quinn a été redélégué quatre fois pour résoudre le même problème d’environnement, ce qui a consommé environ 1,2 million de tokens. Un transfert marqué comme COMPLÈTE indiquait un artefact encore rempli de marqueurs de structure TODO. De plus, le réveil d’un agent existant était enregistré comme une nouvelle délégation, ce qui gonflait le journal des exécutions.

Le processus d’apprentissage a identifié trois leçons et les a transformées en étapes de validation avant de les valider définitivement. Un transfert dont l’artefact contient encore des éléments temporaires échoue désormais à la validation. Un réveil est enregistré comme tel. Lorsqu’un obstacle ne peut être résolu que par un humain, comme l’absence de crédentiel ou un service refusant de démarrer, le pipeline s’arrête et ne peut être repris qu’après une commande explicite donnée par une personne. Cet arrêt aurait permis d’économiser la majeure partie de ces 1,2 million de tokens.

Détecter les tests qui se testent eux-mêmes

La version 2.7.0 a corrigé l’un des problèmes les plus préoccupants. Dans un projet réel, treize des vingt spécifications Playwright générées par les différents flux étaient fausses. Ces spécifications réimplémentaient la fonction à tester, soit directement, soit à l’intérieur d’une appel à page.evaluate, puis vérifiaient leur propre version. Un tel test passe systématiquement du statut ROUGE au vert, et la discipline de suivi ROUGE/VERT ne peut pas le détecter car cette tautologie réussit les deux étapes.

check_test_authenticity.py s’exécute désormais à chaque capture en état ROUGE dans tout flux qui génère des tests. Il recherche quatre types de spécifications fausses :

• une spécification qui n’importe rien du code de production
• une réimplémentation en ligne de la fonction à tester
• une évaluation du texte source
• un DOM synthétique remplaçant l’application réelle

Calibré par rapport à cet ensemble réel, il rejette précisément les treize spécifications falsifiées et accepte les sept spécifications authentiques, sans coder de noms de fichiers. La méthodologie de test intègre également ce qu’elle appelle le test de suppression : si un test continue de passer après la suppression du code de production qu’il prétend couvrir, il s’agit d’une constatation critique. Il s’agit d’une vérification rapide que l’on peut appliquer à n’importe quel test, qu’il soit écrit par un humain ou non ; notre article sur les anti-patterns des tests React aborde les manières dont ces ensembles de tests donnent une fausse confiance.

Leçons tirées d’un autre outil de revue de code

Pour la version 2.7.1, les mainteneurs ont étudié le système d’évaluation ouverte d’Alibaba, qui atteindrait une précision d’environ 34 % selon un benchmark public, contre entre 7 et 16 % lorsque Claude Code effectue des évaluations sans aide en utilisant des modèles identiques. Il convient de considérer ces chiffres comme l’interprétation du projet de ce benchmark à l’époque, et non comme un résultat indépendant. L’observation intéressante a été que les deux systèmes d’évaluation étaient presque identiques. La différence résidait dans les éléments structurels : une liste figée des fichiers à prendre en compte, suppression des fichiers générés avant que l’évaluateur ne voie les différences, une limite de taille, ainsi qu’une étape de vérification factuelle qui ne peut annuler une constatation que pour l’une des deux raisons indiquées.

Deux incidents de validation ont été pris en compte dans la même version. Une validation sans interface graphique, ne disposant d’aucun répertoire Git dans ses fichiers de configuration, a cherché un tel répertoire sur l’ensemble du système et a consulté un véritable outil de suivi des problèmes. De plus, une correction de bug activant un plugin a coûté 11,06 $ sans produire aucun test capable de détecter des erreurs dans la version défectueuse, ce qui signifie que personne ne s’apercevrait si cette correction était annulée.

Les modifications résultantes :

• Le système de validation refuse une approbation si des anomalies critiques ou importantes non résolues apparaissent dans la section d’évaluation. En pratique, le verdict est déterminé en fonction de ces anomalies, et une expression régulière confirme ce calcul.
• Si aucun paragraphe d’évaluation dédié n’est prévu pour chaque fichier dans le diff, la mise à jour est rejetée.
• Le package d’évaluation supprime les fichiers de verrouillage, les fichiers minifiés ainsi que tous les fichiers générés, indique ce qui a été retiré, et refuse les diffs dépassant 1 500 lignes à moins qu’une autorisation écrite n’ait été fournie par un humain.

Désormais, chaque briefing des travailleurs lors d’une évaluation sans interface affiche à nouveau un préambule décrivant le champ d’application, et un mécanisme de détection isole toute exécution qui s’écarte de son espace de travail.

Les évaluations des résultats ont intégré un nouveau critère : une correction n’est prise en compte que si elle est accompagnée d’un test de régression qui donnerait un résultat négatif en cas de réversion de cette correction.

L’audit du journal des modifications a révélé cinq commits publiés sans aucune entrée correspondante, et ceux-ci ont été fermés.

La comparaison n’était pas unilatérale. Les 51 documents de règles linguistiques de l’autre outil ne contenaient aucune information concernant C#, Vue, PowerShell ou SQL, langages pour lesquels on recourt à une liste de contrôle générique ; or ce sont précisément ces technologies que couvrent les compétences de ce plugin.

Lors d’une seconde lecture, trois règles de précision ont été ajoutées à la section 2.7.2 avant même que toute défaillance ne les rende nécessaires. Le réviseur peut consulter n’importe quel fichier pour comprendre le contexte, mais les constatations sont limitées aux fichiers faisant partie du diff compilé ; toute observation concernant d’autres fichiers constitue une note hors champ destinée à l’Orchestrator. La méthodologie de base de données a vu s’ajouter une règle d’injection prévoyant une liste explicite des éléments qui ne doivent jamais être signalés, tels que les liaisons paramétrées et les instructions statiques, car un faux positif sur du code correct incite les lecteurs à négliger les véritables problèmes. De plus, la méthodologie de sécurité exige désormais une structure en cinq sections pour les documents de sécurité, et chaque catégorie OWASP doit être accompagnée soit d’une citation, soit d’un argumenté « Pas applicable », car laisser une ligne vide ne constitue pas un jugement.

Où en est le projet

Lors de la rédaction de ce texte, le plugin dispose de 16 personnalités d’agents, 45 compétences et 32 scripts de contrôle, ainsi que 1 656 tests automatisés. Tous ces scripts de contrôle sont déterministes et ne font appel à aucun modèle de langage large ; ils s’exécutent avant chaque mise à jour. L’ensemble d’évaluation comprend 69 cas répartis en quatre niveaux ; le niveau de résultat compare les exécutions avec et sans le plugin activé, en utilisant des tests cachés plutôt que de vérifier si une voie spécifique a été activée. Depuis la première version, 119 modifications ont ajouté environ 67 000 lignes de code.

La métrique qui, selon les mainteneurs, compte réellement n’est aucune de celles mentionnées. Il s’agit du nombre de règles qui restent formulées en prose, demandant au modèle de s’abstenir au moment où il souhaite le plus continuer. Ce chiffre diminue à chaque mise à jour, et chaque baisse est liée à un problème observé lorsque la règle était active.

Points clés

• Traiter une règle qui a été enfreinte pendant sa période de validité comme un rapport de bug concernant cette règle, et la corriger au moyen d’un contrôle de sécurité, plutôt qu’en renforçant simplement sa formulation.
• Permettre aux scripts d’effectuer des actions irréversibles telles que les commits, afin qu’un contrôle sauté laisse apparaître une absence visible plutôt qu’un passage silencieux.
• Définir des niveaux de preuve et exiger l’enregistrement du résultat d’une commande hachée, plutôt qu’une simple mention indiquant « vérifié ».
• Fournir aux agents un résultat légitime de type BLOQUÉ, de sorte que l’invention d’un résultat PASS ne soit jamais le chemin le plus simple.
• Prouver chaque contrôle de sécurité en observant son échec lors d’une violation délibérée, et auditer ces contrôles eux-mêmes, car les vérifications tendent à se limiter aux noms de fichiers et à leur existence.
• Bloquer les appels à des outils dangereux avant qu’ils ne s’exécutent, mais configurer les mécanismes de protection de manière à ce qu’ils échouent par défaut, afin que personne ne soit tenté de les supprimer.

Appliquez le test de suppression aux tests générés : si la suppression du code en production ne brise pas le test, celui-ci est inutile.

La méthode consiste en une boucle : observez un exécution, identifiez l’instruction qui a été ignorée, remplacez-la par quelque chose qui doit être exécuté ou ouvert, puis observez la prochaine exécution.

Lectures complémentaires

• Où appartiennent les instructions de Claude Code : CLAUDE.md, règles de path ou hooks — Découvrez pourquoi Claude Code traite CLAUDE.md comme un contexte, comment le simplifier, appliquer des règles par path, déplacer les étapes obligatoires dans des hooks, et vérifier ce qui est réellement chargé.
• Un manuel pratique pour écrire un fichier CLAUDE.md efficace — Découvrez 21 règles concrètes et vérifiables pour réduire la taille d’un fichier CLAUDE.md trop volumineux, afin que Claude Code reste fiable, prévisible et facile à utiliser pendant de longues sessions.
• Enseigner à Claude Code vos règles et compétences de mapping dans un monorepo NestJS — Comment configurer CLAUDE.md, les règles, les compétences et les permissions afin que Claude Code place le code dans le bon service NestJS et respecte les conventions de votre équipe.
• Appliquer les règles des agents dans le code : PreToolUse, PostToolUse et Stop Hooks — Découvrez pourquoi l’autorisation des agents LLM doit être intégrée dans les hooks déterministes de appel d’outils, comment refuser des appels en toute sécurité, et comment envelopper un dispatcheur sans recursion.