Le harnais des agents : les garanties que je donne à un client

Ce que les agents peuvent faire

Lire et modifier le code d'un seul projet, dans une copie de travail isolée (un worktree git) créée pour la tâche et supprimée ensuite.

Exécuter les vérifications propres au projet : build, typage, lint, tests, revue de code et revue de sécurité automatisées.

Ouvrir une pull request vers la branche d'intégration dev, jamais ailleurs.

Ce qu'ils ne peuvent pas faire

Toucher à la branche de production ni déployer. La promotion en production est une pull request manuelle, ouverte et revue par un humain.

Lire ou écrire des secrets. Clés, certificats et fichiers .env sont exclus de git et injectés chiffrés dans la CI par un script qui ne les affiche jamais.

Agir hors du dépôt. Toute action risquée ou tournée vers l'extérieur (envoi, suppression, publication, rotation d'un secret) s'arrête et attend une approbation humaine explicite.

Contourner les règles du projet. Chaque dépôt porte un fichier de politique versionné (exigences à lire d'abord, design gelé, conventions, règles de livraison) que l'agent doit suivre et qu'un humain relit comme du code.

Ce que le client garde

Traçabilité. Chaque modification est un commit sur une branche, une pull request et une revue dans l'historique git du client. Rien ne se passe hors de cet historique.

Réversibilité. Une pull request se rejette, un commit se rétablit, une session s'arrête en une commande.

Coupe-circuit. Une session s'arrête immédiatement sur commande ; un chien de garde relance ou coupe une session qui dérive ; les boucles de revue ont un nombre maximal d'itérations.

Propriété. Le code reste dans les dépôts du client (GitHub ou Azure DevOps) et sur l'infrastructure convenue. Aucune plateforme tierce d'orchestration n'est intercalée : outils de première partie et scripts shell relus seulement. Sur demande, l'usine tourne sur le serveur ou le tenant Azure du client.

Portes humaines. Spécification, design, promotion en production. Aucun code de fonctionnalité avant l'approbation de la spécification.

Ce que le modèle voit

Seulement le contexte nécessaire à la tâche : les fichiers du projet, jamais les secrets ni les données de production.

L'accès au modèle est configuré et documenté pour que le code du client ne serve pas à entraîner les modèles.

Les données personnelles détenues par les produits (patients, employés) ne transitent jamais par les agents de développement. Quand un produit intègre lui-même un modèle (Aria, Pilume), la charge utile est dé-identifiée et la sortie validée par un schéma et par un humain.

Pourquoi un harnais plutôt que la confiance

Un agent efficace est un agent rapide, et la rapidité sans limites est un risque. Le harnais fixe les limites une fois, dans des fichiers relus et versionnés, pour que la cadence des agents ne repose jamais sur leur bonne volonté.