Quand un modèle dit « lance npm test », aucun test ne démarre pour autant. Ce qui l’exécute vraiment, c’est le logiciel qui entoure le modèle : le harness, ou plan de contrôle. Imaginons un harness qui traite cette demande ainsi. Il vérifie d’abord que npm test figure dans sa liste de commandes autorisées, puis le lance dans un sous-processus limité à cinq minutes. À la fin, il renvoie au modèle le code de sortie et les 200 dernières lignes de sortie, et inscrit le même enregistrement dans son journal. Si le processus plante en cours de route, la tentative suivante repart de cette entrée du journal.
Dans cette seule étape, le modèle n’a fait que proposer le prochain mouvement ; le harness l’a rendu exécutable, l’a maintenu dans ses limites, en a gardé une trace consultable et l’a rendu récupérable après une erreur. Un harness est donc plus qu’une fenêtre de dialogue : il relie modèle, dépôt, terminal, permissions et vérifications.
Le tableau suivant applique les huit responsabilités à la même demande npm test.
Couche
Responsabilité
Ce qu’elle fait pour npm test
Boucle
Alterner tours du modèle, appels d’outils, résultats et arrêt
Renvoyer le résultat des tests pour que le modèle choisisse la suite ; s’arrêter quand les tests passent ou que le budget d’étapes est épuisé
Contexte
Choisir instructions, historique, fichiers et preuves
Ne mettre dans le contexte que les 200 dernières lignes, pas tout le journal
Outils
Valider les arguments, exécuter et structurer les résultats
Vérifier la commande et le répertoire de travail, renvoyer code de sortie et sortie ; un sous-processus hérite des variables d’environnement et des ressources ouvertes de son parent (voir Processus, espaces d’adressage et mémoire), il faut donc décider d’abord ce qu’il peut emporter
Politique
Imposer portée, permissions, approbations, budgets et sécurité
Consulter la liste autorisée : npm test peut tourner directement, une commande qui supprime un répertoire ou pousse du code doit s’arrêter et demander à une personne
État
Conserver progression, artefacts et checkpoints récupérables
Noter que cette étape a lancé les tests et avec quel résultat, pour reprendre ici après un plantage
Fiabilité
Gérer timeouts, reprises, idempotence, annulation et erreurs
Arrêter le processus au bout de cinq minutes ; relancer les tests ne modifie rien, la reprise est donc sans risque
Observabilité
Conserver traces, logs, tokens, coûts et preuves d’outils
Journaliser commande, durée et code de sortie, pour savoir ensuite ce qui a tourné et quand
Évaluation
Tester le résultat sur des tâches représentatives, pas seulement le discours
Vérifier que les tests passent réellement, pas que le modèle a l’air d’avoir fini
Un « tous les tests passent » du modèle ne compte pas : un harness fiable lit lui-même le code de sortie de npm test, puis décide d’arrêter ou non. La façon de brancher ce type de validation externe dans la boucle est décrite dans Boucles d’agent bornées.
Définir le résultat et un contrôle externe de réussite, par exemple « npm test se termine avec le code 0 ».
Exposer le plus petit ensemble d’outils utile. Un petit modèle local dépend encore plus de cette étape : tours courts, outils peu nombreux, sorties plafonnées.
Séparer lectures, écritures et actions irréversibles.
Conserver artefacts et preuves hors de la conversation.
Fixer des limites de temps, tokens, reprises et concurrence ; les conditions d’arrêt et le coupe-circuit sont détaillés dans Boucles d’agent bornées.
Tracer tours et appels d’outils tout en protégeant les données sensibles.
Rejouer des tâches représentatives avant de changer de modèle, de harness ou d’effort de raisonnement.
Les contrôles qui décident si un résultat peut être livré, comme les tests, les permissions et la recette de bout en bout, appartiennent au harness et au workflow ; le modèle reste remplaçable. Les modèles et tarifs changeants appartiennent au Radar des modèles et API, et les résultats publics et pièges propres aux outils vont dans Choisir un agent de programmation IA. Un meilleur modèle peut réduire les reprises, mais ne dispense ni des preuves, ni des permissions, ni des contrôles de bout en bout.
Où se trouvent ces contrôles dans Claude Code, Codex et Pi
Un agent de code installé tel quel implémente déjà l’essentiel de ces responsabilités ; ce que vous réglez, ce sont ses interrupteurs. Le tableau suit la documentation officielle au 2026-10-29, et Pi 1.4.0.
Contrôle
Claude Code
Codex
Pi
Instructions du projet
CLAUDE.md ; il sait aussi lire le AGENTS.md du dépôt
AGENTS.md : d’abord ~/.codex/AGENTS.md, puis chaque niveau depuis la racine du dépôt
AGENTS.md et CLAUDE.md se chargent toujours, quelle que soit la confiance accordée au projet (doc de sécurité)
Permissions et approbation
/permissions, ou permissions.allow / ask / deny dans settings.json, évaluées refus → demande → autorisation
approval_policy (par exemple on-request ou never) et /permissions ; approvals_reviewer = "auto_review" confie les approbations à un agent relecteur
Aucune demande avant les appels d’outils ; --approve / --no-approve décident seulement si les réglages et extensions du projet se chargent
Bac à sable
Désactivé par défaut ; on l’active avec /sandbox ou sandbox.enabled ; il n’enveloppe que les commandes shell
sandbox_mode : read-only, workspace-write, danger-full-access ; workspace-write n’a pas de réseau par défaut
Pas de bac à sable intégré ; exécuter tout Pi dans un conteneur ou une machine virtuelle
pi -c reprend la plus récente ; pi -r ouvre la liste des sessions
Le même mot « bac à sable » ne couvre pas le même terrain chez les trois ; celui de Claude Code, par exemple, peut encore lire ~/.ssh une fois activé. Avant de toucher à quoi que ce soit, lisez la comparaison et la configuration de départ dans Sécurité des agents.