PACT : Un Cadre de Gouvernance Programmatique pour le Code Claude Après les Modèles de Défaillance des Agents

Après trois mois de développement d'une application mobile avec Claude Code (plus de 350 fichiers, plus de 70 tables de base de données, BLE peer-to-peer, base de données locale chiffrée, synchronisation cloud), un développeur a identifié des schémas d'échec récurrents qui ne pouvaient pas être corrigés avec les règles CLAUDE.md. L'agent a répété les mêmes catégories d'erreurs à travers les sessions, notamment en ajoutant trois fois des bibliothèques de base de données interdites après avoir été averti, en divulguant des métadonnées de chiffrement au serveur (ce qui a cassé la connexion pour tous les utilisateurs), en passant plus de 4 heures à déboguer Bluetooth en devinant l'API au lieu de lire la documentation, et en appliquant des correctifs de sécurité qui ont cassé la restauration des sauvegardes en ne considérant pas le cycle de vie complet.

Le problème avec les règles

CLAUDE.md a atteint plus de 50 règles mais est devenu performatif - Claude les récitait au début de la session puis les violait facilement. Quand on lui a demandé pourquoi les règles étaient ignorées, Claude a répondu : "Je dois être honnête avec vous. Je peux ignorer les règles en les traitant davantage comme des suggestions. Elles ne peuvent pas toujours empêcher le comportement..."

La solution : le framework PACT

Le développeur a demandé à Claude : "Si je vous donnais la permission de redessiner ce système vous-même, que construiriez-vous ?" Cela a conduit à la création de PACT (Programmatic Agent Constraint Toolkit) avec l'idée centrale, selon les propres mots de Claude : "Les règles sont des suggestions. L'infrastructure est la loi."

Les quatre piliers de PACT

• Application mécanique : Des hooks PreToolUse qui bloquent les schémas interdits avant que les modifications ne soient appliquées. Exemples : import hive ? Bloqué. print() au lieu du logger ? Bloqué. Modifier un fichier que vous n'avez pas lu ? Bloqué.
• Remplacement du contexte : Une carte d'architecture YAML (SYSTEM_MAP.yaml) décrit chaque flux de données : table de base de données → service → gestion d'état → écran UI → comportement en cascade. L'agent lit cela au lieu de passer 15-20 minutes à relire les fichiers sources à chaque session.
• Raisonnement auto-évolutif : Au lieu de règles ("toujours vérifier les dépendances"), des redirections cognitives qui sont des questions : "Qu'est-ce qui dépend de cela, et de quoi cela dépend-il ?" Les questions engagent le raisonnement d'une manière que les règles ne font pas. L'agent peut ajouter de nouvelles redirections quand il se surprend à faire des suppositions.
• Séparation structure/comportement : Les cartes d'architecture (quels fichiers existent) restent séparées des flux de cycle de vie (ce qui se passe à travers les états de l'application). Empêche les deux échecs documentaires les plus courants : les cartes qui deviennent des essais que personne ne lit, et les flux qui dupliquent la structure qui devient obsolète.

Exemples pratiques d'implémentation

Redirections cognitives en pratique : "Quand vous êtes sur le point de supprimer du code : Pourquoi ce code existe-t-il ?" a été ajouté après que Claude ait supprimé un contournement pour un bug du framework alors que le commentaire juste au-dessus expliquait pourquoi il était là. "Quand vous trouvez une objection à votre propre solution : Cette objection est-elle réelle, ou est-ce que je me replie ?" a été ajouté après que Claude ait proposé le correctif approprié, s'en soit dissuadé pendant la revue, et que le développeur ait dû sauver sa propre idée.

Suivi de bugs avec base de connaissances des solutions : Une session a passé 3 heures à résoudre un problème BLE spécifique à Samsung. La session suivante a rencontré le même bug sans aucun souvenir. Maintenant, chaque investigation est enregistrée en temps réel — symptômes, tentatives échouées, cause racine, correctif. La première action de l'agent sur tout bug est de vérifier si une session précédente l'a déjà résolu.

Fichiers de connaissances des packages : Le cauchemar de débogage Bluetooth de 4 heures est arrivé parce que Claude devinait comment le package fonctionnait à partir de données d'entraînement obsolètes. Maintenant, il y a une exigence obligatoire de consulter les fichiers de connaissances des packages.