GitHub annonce des politiques de sandbox administrées pour Copilot dans JetBrains. L’intérêt n’est pas d’ajouter une consigne aux développeurs, mais de vérifier quelles frontières s’imposent réellement à l’agent, sur chaque environnement du parc.
Ce que GitHub annonce dans JetBrains
Une préversion, pas une garantie pour tout le parc
Une sandbox est un environnement d’exécution qui limite les ressources accessibles à un programme. Ici, la question porte sur les restrictions que l’entreprise peut imposer à l’assistant de développement.
Le 8 septembre 2026, GitHub a annoncé en préversion publique des politiques de sandbox administrées pour Copilot dans JetBrains. L'annonce décrit des restrictions décidées par l'entreprise qui priment sur les réglages individuels, avec un périmètre couvrant notamment fichiers, réseau, outils ou services locaux et des éléments de diagnostic de la politique reçue. Ces faits proviennent du changelog GitHub, consulté le 9 septembre. Ils ne prouvent ni une disponibilité universelle ni le comportement d'une installation particulière.
Une préversion se qualifie donc par environnement : édition et version de l'IDE, plugin, système, offre Copilot et politique effectivement reçue. Une règle déclarée dans une console n'est pas encore une frontière démontrée sur le poste où l'agent travaille.
Le piège des documentations voisines
La documentation GitHub sur la configuration du sandbox local donne du contexte sur les contrôles, les outils et les exceptions approuvées. Elle est orientée vers l’interface en ligne de commande (CLI). Elle ne démontre pas que chaque réglage, format ou commande s'applique à JetBrains. Toute configuration proposée à une équipe doit donc être reliée à un client testé, plutôt qu'assemblée à partir d'exemples voisins.
Décrire la frontière attendue avant de configurer
Fichiers, réseau et outils : trois inventaires distincts
Avant un pilote, établissez une matrice de besoins par tâche. Un assistant qui corrige un test n'a pas nécessairement besoin des mêmes fichiers, hôtes ni outils qu'un assistant chargé d'analyser une dépendance. Cette séparation évite de transformer une permission large en solution par défaut.
| Environnement | Version plugin | Politique attendue | Action inoffensive | Résultat constaté | Preuve | Propriétaire |
|---|---|---|---|---|---|---|
| À renseigner | À renseigner | À renseigner | Fichier, hôte ou outil de démonstration | Non mesuré | Non mesuré | À désigner |
Utilisez des chemins de démonstration, des hôtes de test et des secrets factices. Le but est de vérifier une frontière sans faire circuler une donnée client ni modifier une politique d'entreprise réelle.
Qui peut demander ou accepter une exception ?
Cartographiez séparément l'administrateur qui modifie la politique centrale, le développeur qui constate un blocage et le validateur qui accepte une exception. Une demande documentée, une approbation et un contournement autorisé ne sont pas synonymes. Leur existence et leur visibilité restent à confirmer dans le client et l'organisation qui déploie la préversion.
Vérifier la politique effective
Un test positif et un test négatif par frontière
Préparez une paire de tests pour chaque autorisation attendue : un fichier dans et hors espace admis, un point d’accès de démonstration accepté puis refusé, une ressource locale factice accessible puis exclue. Pour chaque essai, conservez l'attendu, le constat, la version et la preuve disponible. Un résultat vide vaut « non mesuré », jamais « sécurisé ».
Diagnostiquer au lieu de conclure sur un échec isolé
Un refus peut révéler une politique ; une panne réseau, une option de préversion désactivée ou une incompatibilité de version peuvent produire le même symptôme. Relevez la politique reçue, les indicateurs d'affichage, les versions et le journal pertinent avant de conclure. La possibilité de diagnostic annoncée par GitHub devient utile lorsqu'elle permet à l'équipe de distinguer une restriction voulue d'un défaut de déploiement.
Déployer sans casser le travail quotidien
Commencez avec un groupe pilote, des tâches connues et un propriétaire pour chaque exception. Définissez avant le déploiement ce qui doit interrompre le pilote : perte de traçabilité, impossibilité de diagnostiquer un blocage ou dérive des exceptions. Ces critères sont des choix internes ; GitHub ne fournit pas ici un seuil universel.
Suivez la friction utile : demandes légitimes bloquées, exceptions devenues durables et tâches sorties du dispositif. Ces observations ne mesurent pas une baisse d'incidents. Elles permettent de voir si la frontière répond au travail réel et si les droits résiduels restent compris.
Ce qu'une politique centrale ne remplace pas
Une politique centrale ne remplace ni la revue de code ni les droits minimaux, et ne rend pas une sortie d'agent correcte par construction. Le cadre présenté dans notre article sur les agents IA zero trust reste complémentaire : les écritures, les identités et les actions sensibles demandent leurs propres preuves et contrôles.
Le livrable d'un pilote peut rester simple : une matrice approuvée, des tests reproductibles et un propriétaire pour chaque exception. C'est ce qui rend les frontières observables. Une politique annoncée devient alors une décision technique défendable, sans la présenter comme une sandbox inviolable.