Agents de code : l’autonomie utile commence par des garde-fous

Séparer objectif, plan et permissions

Une demande décrit un objectif, pas une autorisation universelle. L’agent transforme cet objectif en plan explicite, puis chaque étape en action autorisée. Lire un fichier, lancer un test et publier une version sont des capacités différentes qui ne doivent pas être regroupées dans un accès unique.

Le moindre privilège consiste à fournir seulement les répertoires, commandes et connexions nécessaires. Les opérations irréversibles ou externes restent soumises à validation. Cette séparation rend le comportement compréhensible et limite les conséquences d’une mauvaise interprétation.

Créer une zone de travail jetable

L’agent ne devrait pas expérimenter directement dans la copie principale. Un conteneur, une machine isolée ou un Git worktree fournit une zone distincte où modifications et tests sont observés avant intégration. Git permet plusieurs arbres de travail attachés au même dépôt tout en séparant les fichiers et l’index.

L’isolation du dossier ne suffit pas. Il faut contrôler le réseau, les variables d’environnement, les secrets et les volumes montés. Un processus qui peut lire une clé de production ou envoyer du contenu vers Internet n’est pas réellement enfermé.

• Créer un espace neuf pour chaque tâche.
• Monter les secrets uniquement lorsqu’ils sont indispensables.
• Détruire l’espace après conservation du rapport utile.

Remplacer la confiance par des preuves

Une phrase comme « les tests passent » n’est pas une preuve. Le rapport indique les commandes exécutées, leurs codes de sortie, les fichiers modifiés et les validations impossibles. La sortie brute peut être conservée séparément tandis qu’un résumé structuré facilite la revue.

Parseur, compilation, lint, tests, schéma ou règle métier éliminent une partie des erreurs avant la revue humaine. L’agent doit pouvoir déclarer un blocage plutôt que d’optimiser son récit de réussite.

Borner les boucles et traiter les entrées hostiles

Une correction après un test échoué est utile, mais une boucle sans limite peut dépenser du temps et des tokens sans progresser. On fixe nombre de tours, durée, budget et quantité maximale de modifications. Chaque itération répond à un échec identifié.

Un dépôt peut contenir des instructions dans un README ou un commentaire. Ces contenus ne modifient jamais les permissions de l’agent. Les politiques, les instructions utilisateur et les données observées restent séparées.

Garder l’intégration comme décision explicite

Le résultat le plus sûr est souvent un diff accompagné d’un rapport, pas un commit fusionné automatiquement. Un réviseur contrôle portée, dépendances, tests et migrations. Pour des tâches répétitives bien couvertes, l’intégration peut ensuite être automatisée progressivement.

L’autonomie devient utile lorsque l’agent absorbe le travail mécanique tout en augmentant la visibilité. Si l’équipe comprend moins bien ce qui change, l’automatisation a déplacé le risque au lieu de le réduire.

Construire une politique de capacités

Une politique lisible associe chaque outil à une portée et à une condition. La lecture du dépôt peut être automatique ; l’installation d’une dépendance demande une liste d’origines autorisées ; l’accès réseau se limite aux domaines nécessaires ; une publication externe exige une validation. Cette politique vit dans le système d’exécution, pas seulement dans le prompt.

Les capacités temporaires expirent à la fin de la tâche. Un secret n’est injecté que dans le processus qui l’utilise et ne doit apparaître ni dans les logs ni dans le rapport. Les refus d’autorisation sont des résultats normaux : l’agent explique la limite et propose une étape vérifiable plutôt que de chercher un contournement.

Auditer l’agent comme un service de production

Les métriques utiles ne se limitent pas au nombre de tâches terminées. On suit les retours arrière, les modifications hors périmètre, les validations humaines, les échecs répétés et le coût par résultat intégré. Un taux de réussite élevé peut masquer des diffs trop larges ou une revue devenue plus longue.

Un échantillon de tâches est rejoué après chaque changement de modèle, d’outil ou de politique. Les scénarios incluent instruction ambiguë, fichier hostile, dépendance indisponible et test trompeur. L’équipe peut alors augmenter l’autonomie uniquement sur les familles de tâches dont les preuves sont solides.

• Tracer objectif, outils, sorties et décisions.
• Conserver un diff réversible.
• Séparer validation automatique et approbation humaine.
• Réduire les permissions après chaque incident.