Observatoire IAThe Easy Company
Rubriques et méthode

GitHub · Copilot · Fait du 9 septembre 2026

Copilot : décider ce que l’assistant peut faire dans votre équipe

Contre-vérification à compléter : La contre-vérification de cette version n’est pas établie. Lire la méthode

Un assistant de programmation peut agir sur des fichiers et lancer des commandes. GitHub permet aux administrateurs concernés de bloquer certaines actions ou d’exiger une validation. Un défaut connu et encore ouvert peut cependant geler une session dans un état où chaque action redemande une validation.

Pour qui ? Les équipes qui utilisent GitHub Copilot Business ou Enterprise pour développer des logiciels, et les responsables qui doivent en fixer les limites.

Documenté, pas testé par l’Observatoire. Sources lues le 12 septembre 2026. Réexamen prévu au plus tard le 11 octobre 2026. Une documentation décrit une possibilité ; elle ne prouve pas le résultat chez vous.

Ce qui change

L’annonce du 9 septembre décrit des permissions gérées au niveau de l’entreprise. Elles concernent les commandes, la lecture et la modification de fichiers ainsi que les domaines réseau. GitHub indique leur disponibilité générale dans son application Copilot, son outil en ligne de commande et les sessions VS Code utilisant Agent Host.

Preuves : GitHub · annonce du 9 septembre

Trois décisions faciles à comprendre

Une règle peut interdire une opération, demander une approbation humaine ou l’autoriser sans question. Si plusieurs règles se recouvrent, l’interdiction prime, puis la demande d’approbation. Une règle gérée « ask » demande un accord à chaque nouvelle opération concernée, même si une approbation précédente avait été mémorisée.

Preuves : GitHub · référence des permissions

Une limite concrète, encore ouverte

Le dépôt GitHub de Visual Studio Code documente un défaut réel : une session Agent Host peut entrer dans un état de permissions gérées figé même en l’absence de toute politique d’entreprise ou d’appareil réellement configurée. Chaque outil redemande alors une validation, chaque accord n’est traité qu’une seule fois, et le bouton « Tout autoriser » reste sans effet. Un correctif du comportement au démarrage est rapporté dans une version ultérieure à celle où le défaut a été observé. Ce défaut ne remet pas en cause le principe des permissions gérées, mais il justifie un test avant de s’y fier pour bloquer une action réellement sensible.

Preuves : microsoft/vscode · issue #328879

Les mots de cette fiche

Agent
Ici, un assistant qui peut utiliser des outils pour agir, au-delà d’une réponse écrite.
Agent Host
Le mode d’exécution des sessions VS Code auquel GitHub rattache ces règles fines de permission.

Un exemple pour comprendre

EXEMPLE FICTIF · SANS COMPTE NI INSTALLATION

Dans une équipe fictive, l’assistant peut lire le code du projet. L’envoi de modifications vers le dépôt partagé exige un accord ; l’accès à un dossier confidentiel est interdit.

Une personne avait déjà accepté un envoi hier. Cela suffit-il pour une nouvelle opération soumise à « ask » aujourd’hui ?

Voir une réponse expliquée

Selon la règle documentée, une nouvelle approbation est nécessaire. Et un accord ponctuel ne permet pas de contourner une interdiction gérée. L’équipe doit encore vérifier que sa session utilise bien un client compatible et que sa configuration est effectivement chargée.

Votre prochain pas

Demandez à votre responsable technique d’identifier les clients et modes réellement utilisés, puis de vérifier une action autorisée et une action refusée dans un projet d’essai sans données sensibles. Vérifiez aussi qu’un bouton « Tout autoriser » répond bien avant de considérer la session comme fiable.

Conditions précises et sources

Référence de configuration : managed-settings.json, permissions.deny / ask / allow. La priorité est deny > ask > allow. Les contrôles de permissions ne constituent pas à eux seuls une garantie de sécurité de l’ensemble du poste, du réseau ou du projet. Aucun déploiement de ces règles n’a été testé dans ce pilote. Un défaut ouvert (microsoft/vscode#328879) montre qu’un état interne mal réinitialisé peut imiter une politique gérée qui n’existe pas : vérifiez la version du client avant de vous y fier.

Sources primaires : elles décrivent leur propre dispositif. Plusieurs pages du même éditeur ne constituent pas plusieurs confirmations indépendantes.

  • GitHub · annonce du 9 septembre

    Périmètre de disponibilité déclaré, comptes concernés et opérations.

    Document daté du 9 septembre 2026 · consulté le 11 septembre 2026
  • GitHub · référence des permissions

    Priorité des règles, nouvelle approbation et restriction Agent Host.

    Date de publication non établie · consulté le 11 septembre 2026
  • microsoft/vscode · issue #328879

    Défaut réel et encore ouvert : état de permissions gérées figé, « Tout autoriser » sans effet, correctif runtime rapporté dans une version ultérieure.

    Document daté du 4 août 2026 · consulté le 12 septembre 2026