Anatomie d’un agent harness
pourquoi les modèles ont besoin d’un harnais

Le problème : un modèle n’est pas encore un opérateur

Dans une démonstration, le modèle répond à une question. Dans une équipe produit, on lui demande plutôt de modifier du code, de comparer deux approches, de lancer des tests, de lire les erreurs et de rendre un diff que quelqu’un peut relire. Cette différence paraît subtile, mais elle change tout : sans harnais, le modèle travaille dans une conversation ; avec un harnais, il travaille dans un environnement.

• Contexte instable : le modèle oublie facilement les règles locales, les fichiers déjà lus ou les contraintes du dépôt si le harness ne les recharge pas au bon moment.
• Actions sans preuve : une réponse peut sembler exacte, alors qu’un test, un linter ou un journal d’exécution montrerait une rupture très concrète.
• Risque opérationnel : accès au shell, secrets, fichiers temporaires et commandes longues exigent des permissions explicites, pas une confiance implicite.

Matrice : modèle seul, agent scripté ou véritable harness

La bonne question n’est pas « quel modèle est le plus intelligent ? », mais « quelle surface d’exécution lui permet d’être fiable ? ». Une architecture élégante sépare la décision, l’action et la vérification, afin que chaque résultat puisse être repris, annulé ou audité.

Six étapes pour construire un harnais utile

Un harness n’a pas besoin d’être spectaculaire ; il doit surtout être lisible. Dans les équipes qui livrent vraiment, la sobriété gagne souvent : peu d’outils, mais bien nommés ; peu de mémoire, mais pertinente ; peu de droits, mais suffisants pour terminer la tâche.

• 1. Écrire le contrat : définir l’objectif, les fichiers autorisés, les critères de réussite et les situations où l’agent doit demander confirmation.
• 2. Préparer l’environnement : lancer le travail dans un worktree, un conteneur ou un Mac dédié, afin que les essais restent isolés du poste personnel.
• 3. Brancher les outils : exposer lecture, édition, recherche, tests et commandes longues avec des timeouts et des sorties conservées.
• 4. Ajouter la mémoire courte : résumer les fichiers lus, les décisions prises et les erreurs rencontrées pour éviter les boucles coûteuses.
• 5. Vérifier avant de conclure : demander au harness de fournir diff, commandes exécutées, statut des tests et limites restantes.
• 6. Industrialiser : déplacer les tâches longues vers une machine disponible, proche des dépendances, plutôt que vers un laptop qui dort ou change de réseau.

Pourquoi l’infrastructure compte autant que le modèle

Le harness devient particulièrement intéressant lorsqu’il exécute du travail réel : builds Xcode, tests Node, indexation de dépôt, benchmarks d’inférence locale ou génération d’artefacts. Dans ces cas, la machine n’est plus un détail. Elle doit rester allumée, garder les caches, supporter SSH et VNC, et produire des journaux que l’équipe peut relire le lendemain.

Un Mac mini M4 dédié est bien adapté à ce rôle lorsque l’agent touche à l’écosystème Apple, aux tests iOS ou à des workflows hybrides mêlant interface graphique et shell. Le même nœud peut recevoir les tâches en SSH, afficher Xcode ou un navigateur en VNC, puis servir de banc d’essai pour mesurer ce que le modèle a réellement accompli.

Conclusion : acheter du raisonnement ne suffit pas, il faut louer une capacité d’action

Le modèle apporte l’intuition ; le harness apporte la discipline. Ensemble, ils produisent un agent capable de travailler, pas seulement de parler du travail. Pour une équipe qui veut passer des prompts aux livraisons, la priorité est donc claire : choisir un modèle compétent, puis lui donner un environnement stable, observable et réversible.