GitHub Copilot ajoute un bac à sable local : les agents de code gagnent des garde-fous

ParKelvin Carretero-Corrales

Les agents de programmation savent désormais faire bien plus que proposer quelques lignes de code. Ils peuvent parcourir un projet, modifier plusieurs fichiers, lancer des commandes, installer des dépendances et parfois utiliser des identifiants. C’est pratique, mais plus l’outil agit, plus une mauvaise commande peut coûter cher.

Le 23 septembre 2026, GitHub a annoncé la disponibilité en aperçu public d’un bac à sable local dans l’application GitHub Copilot. Le récapitulatif publié le 25 septembre confirme cette évolution parmi les nouveautés de la semaine. L’objectif n’est pas de rendre un agent infaillible, mais de limiter ce qu’il peut atteindre sur la machine.

Un bac à sable, concrètement, c’est quoi ?

Un bac à sable, ou sandbox, est une zone d’exécution contrôlée. Au lieu de donner à l’agent les mêmes accès que l’utilisateur connecté, on définit un périmètre : certains dossiers sont autorisés, d’autres sont seulement lisibles ou totalement interdits, et l’accès au réseau peut être restreint.

Dans l’application GitHub Copilot, ces réglages sont définis projet par projet pour les sessions locales associées à un dépôt et à son espace de travail. GitHub permet notamment de contrôler :

  • les dossiers supplémentaires accessibles en lecture et écriture ;
  • les dossiers accessibles uniquement en lecture ;
  • les emplacements explicitement interdits ;
  • l’accès à Internet et au réseau local ;
  • l’utilisation des identifiants Git et de l’outil GitHub CLI.

Point important : si le système d’exploitation ne sait pas appliquer la politique demandée, le shell protégé doit échouer au lieu de démarrer sans isolation. C’est un comportement sain : en sécurité, un mécanisme qui ne peut pas tenir sa promesse doit s’arrêter clairement.

Ce qui change vraiment pour un développeur

Sans restriction, une commande mal comprise pourrait lire un fichier sensible situé en dehors du projet, contacter un service du réseau local ou utiliser des identifiants disponibles dans la session. Le bac à sable réduit la surface accessible avant même que la commande soit exécutée.

Prenons un exemple simple : l’agent doit corriger une petite application web. Il a besoin du dossier du projet, du gestionnaire de paquets et éventuellement d’Internet pour consulter ou télécharger une dépendance. Il n’a aucune raison d’accéder aux documents personnels, aux sauvegardes, aux clés SSH d’autres projets ou à l’ensemble du réseau de l’entreprise. Une politique bien réglée traduit cette réalité technique en autorisations explicites.

GitHub précise toutefois que la fonction est désactivée par défaut et qu’elle ne s’applique qu’aux nouvelles sessions du projet, sauf activation manuelle dans une session locale en cours avec /sandbox on. Les sessions dans un bac à sable cloud et celles exécutées sur une machine distante ne sont pas couvertes par ce réglage local. La configuration de l’application Copilot et celle de Copilot CLI restent également séparées.

Un garde-fou n’est pas une garantie absolue

Le mot « sandbox » peut donner une fausse impression de sécurité totale. Ce n’est pas le cas. L’agent peut toujours faire des dégâts à l’intérieur de la zone autorisée : supprimer un fichier du projet, introduire une régression, modifier une configuration ou exécuter une dépendance compromise.

Le bon raisonnement est donc de cumuler les protections :

  1. travailler dans une branche Git dédiée, jamais directement sur la version utilisée en production ;
  2. n’autoriser que les dossiers, réseaux et identifiants indispensables à la tâche ;
  3. retirer les secrets des fichiers du projet et utiliser un mécanisme adapté pour les injecter ;
  4. relire les changements avec git diff avant de les valider ;
  5. lancer les tests et vérifier le comportement réel de l’application ;
  6. prévoir une sauvegarde ou un retour arrière testé avant tout déploiement.

Autrement dit, le bac à sable limite le rayon d’action. Il ne remplace ni la revue humaine, ni les tests, ni une stratégie de sauvegarde.

GitHub ajoute aussi de la traçabilité avec OpenTelemetry

Une autre annonce, datée du 22 septembre 2026, complète cette approche. L’application GitHub Copilot peut désormais exporter des données d’activité via OpenTelemetry dans le cadre de réglages administrés par l’entreprise.

OpenTelemetry est un cadre ouvert d’observation des applications. Ici, il permet de suivre le déroulement d’une session d’agent, les appels aux modèles et les outils utilisés, puis d’envoyer ces traces vers un système de supervision compatible. Cela aide à comprendre un comportement inattendu au lieu de découvrir uniquement son résultat final.

GitHub indique que le contenu des demandes et des réponses est exclu par défaut. Ce point doit rester surveillé : activer davantage de journalisation peut faciliter le diagnostic, mais aussi collecter des informations sensibles. Avant de conserver des traces détaillées, il faut décider quelles données sont réellement nécessaires, qui peut les consulter et combien de temps elles restent stockées.

Le lien concret avec une petite entreprise

Une TPE n’utilisera pas forcément GitHub Copilot ni OpenTelemetry. Le principe derrière ces nouveautés la concerne pourtant directement : une automatisation ne devrait jamais disposer de plus de droits que nécessaire, et son activité importante doit pouvoir être comprise après coup.

Pour un formulaire qui crée des dossiers, une synchronisation entre deux outils ou un petit logiciel métier, les bonnes questions restent les mêmes :

  • quelles données le processus peut-il lire ou modifier ?
  • que se passe-t-il si une étape échoue ?
  • qui reçoit l’alerte et peut reprendre la main ?
  • peut-on tester sans toucher aux vraies données ?
  • dispose-t-on d’un historique assez clair pour diagnostiquer le problème ?

C’est précisément le lien avec les prestations FuretLabs de diagnostic de processus, automatisation n8n et création de petits outils métier : le travail ne consiste pas seulement à faire fonctionner un enchaînement. Il faut aussi prévoir ses limites, ses erreurs, ses alertes et une intervention humaine possible.

Ce qu’il faut retenir

Les annonces de GitHub des 22, 23 et 25 septembre 2026 montrent une évolution utile des agents de code : ils gagnent en autonomie, mais aussi en isolation et en observabilité. C’est la bonne direction, à condition de ne pas confondre garde-fou et pilote automatique.

Avant de confier une tâche à un agent, posez une règle simple : accès minimal, environnement séparé, changements vérifiables et validation humaine avant la production. L’IA peut accélérer le travail. La responsabilité de définir son terrain de jeu, elle, reste bien humaine.

Sources

Publications similaires