Tester les Automations de VS Code sans laisser l’agent écrire librement

Commencer par le statut réel

Dans les notes de VS Code 1.137, publiées le 16 septembre 2026, Automations est une fonctionnalité en Preview, diffusée progressivement. Le réglage chat.automations.enabled doit être activé pour l’essayer ; la documentation précise que le réglage est désactivé par défaut dans Stable et activé par défaut dans Insiders. Une équipe peut donc ne pas voir la même interface, même avec une version proche.

Ce statut impose une expérience datée. Ne présentez pas une automation comme une capacité disponible sur tous les postes et ne remplacez pas une CI, une revue humaine ou une procédure de sauvegarde par une fonction en préversion.

Préparer un bac d’essai

Choisissez un dépôt non critique, sans secret et sans accès de production. Préparez quelques changements déjà connus ou un petit état de travail que l’équipe peut restaurer. L’objectif du premier run est d’observer, pas de produire une modification utile.

Écrivez un prompt borné qui demande une lecture, un rapport dans la sortie de session et une liste des incertitudes. Ajoutez explicitement : ne pas modifier les fichiers, ne pas créer de branche, ne pas installer de dépendance, ne pas envoyer de données vers un service externe et ne pas exécuter de commande destructive. Ces phrases orientent l’agent, mais ne constituent pas une permission technique ; la configuration de session reste la barrière à vérifier.

Créer une automation manuelle

Dans la fenêtre Agents, ouvrez Automations puis Create Automation. Pour ce premier passage :

donnez un nom qui indique le dépôt et le but du test ;
choisissez le workspace de test, ou No workspace si aucun fichier n’est nécessaire ;
sélectionnez l’agent et le modèle disponibles, puis relisez toute la configuration de session ;
examinez les permissions et l’isolation proposées ; si un nouveau worktree est supporté, vérifiez sa branche de base ;
gardez le planning sur Manual et créez l’automation sans l’activer pour une récurrence.

La documentation officielle recommande ce passage manuel avant toute planification. Elle rappelle aussi qu’une automation peut lire des fichiers, exécuter des commandes et faire des changements selon les permissions de l’agent. Le fait d’enregistrer une automation ne supprime ni les politiques de l’organisation ni les demandes d’approbation futures.

Observer le premier run

Utilisez Run now, puis ouvrez l’exécution dans History. Relisez la réponse, les éventuelles demandes d’approbation et la liste des changements avant de prendre le rapport pour acquis. Contrôlez au minimum :

le dépôt réellement ciblé et la branche utilisée ;
les fichiers lus et les chemins mentionnés dans la sortie ;
les commandes exécutées et celles refusées ;
l’existence d’une écriture, même si le prompt l’interdisait ;
le rapport produit, ses preuves et ses incertitudes ;
les appels externes visibles dans le contexte de votre environnement.

Un résultat vide ou un refus n’est pas un échec de sécurité : c’est une observation à classer. À l’inverse, un rapport convaincant ne prouve pas que les futures exécutions auront le même contexte, le même modèle ou les mêmes permissions.

Planifier seulement après contrôle

Après un premier run relu, vous pouvez choisir Manual, Hourly, Daily ou Weekly. Les horaires quotidien et hebdomadaire utilisent le fuseau local. La machine qui exécute l’automation doit rester éveillée et l’Agent Host ou la fenêtre VS Code requis doit rester disponible ; fermer l’application n’est pas une garantie d’exécution en arrière-plan. Après une interruption, une exécution de rattrapage peut avoir lieu, mais la documentation ne garantit pas que chaque occurrence manquée sera rejouée.

Commencez par la fréquence la plus facile à observer. Comparez deux exécutions sur le même état de test et notez les différences de contexte, de durée, de demandes d’approbation et de sortie. Une automation n’exécute pas deux occurrences parallèles de la même définition ; cela simplifie l’observation, sans garantir une sortie identique.

Comprendre Agent Host sans lui attribuer un rôle de sécurité

L’Agent Host Protocol présente une session d’agent comme une ressource synchronisée à laquelle plusieurs clients peuvent se connecter. Il facilite donc la continuité d’une session entre une interface, un web client, une CLI ou une automation selon l’implémentation retenue. Il ne prouve ni que les permissions sont réduites, ni que les sorties sont exactes, ni qu’un client partage exactement le même niveau de confiance.

Dans votre relevé, séparez « état synchronisé » de « configuration de session ». Pour chaque client, vérifiez qui peut voir la session, quelles approbations sont en attente et si l’agent dispose de capacités d’écriture. La synchronisation est une propriété de transport et d’état ; ce n’est pas une validation du travail produit.

Arrêter et décider

Désactivez les futures exécutions depuis la carte de l’automation et arrêtez un run actif depuis History si nécessaire. La désactivation ne stoppe pas une exécution déjà en cours. Conservez le prompt, la configuration, le résultat et la date de l’essai pour pouvoir expliquer la décision.

Gardez l’automation seulement si son périmètre est lisible, ses permissions sont compatibles avec le risque et ses sorties restent vérifiables sur plusieurs runs. Sinon, revenez au lancement manuel ou à une revue humaine. Le tutoriel sur le contrat de sortie multi-agent peut servir à formaliser le propriétaire, les preuves et la condition d’arrêt ; la grille de versionnement des prompts et du contexte aide à garder la comparaison reproductible.

Sources et limites

Sources officielles consultées le 23 septembre 2026 : notes de version VS Code 1.137 ; documentation Automations, mise à jour le 16 septembre 2026 ; Agent Host Protocol. Automations reste en Preview et son déploiement est progressif. Les réglages, les agents disponibles et les politiques d’organisation peuvent changer ; ce protocole décrit un essai contrôlé, pas une garantie de disponibilité, de sécurité ou de qualité.