GitHub Copilot se muscle pour les entreprises : les agents de code passent sous contrôle IT

Copilot n’est plus seulement là pour suggérer la prochaine ligne

GitHub Copilot poursuit sa transformation. À l’origine principalement connu pour compléter du code dans l’éditeur, l’outil évolue désormais vers des agents capables d’explorer un projet, de modifier des fichiers, d’utiliser des outils et d’exécuter des commandes. Cette autonomie change cependant la nature du risque : laisser une IA proposer quelques lignes de code n’est pas équivalent à lui permettre d’interagir avec le système de fichiers, le réseau ou le terminal d’un développeur. Les mises à jour publiées par GitHub entre le 8 et le 10 septembre 2026 montrent donc un changement de priorité : parallèlement aux nouvelles capacités de Copilot, l’entreprise renforce fortement les mécanismes permettant aux organisations de définir ce que leurs agents ont réellement le droit de faire.¹ ²

La sandbox devient administrable à l’échelle de l’entreprise

GitHub permet désormais aux administrateurs de configurer de manière centralisée le comportement de la sandbox de Copilot dans les IDE JetBrains, une fonctionnalité proposée en public preview.¹ Les politiques peuvent notamment contrôler l’activation de la sandbox, l’accès au système de fichiers et au réseau, les paramètres proxy, l’utilisation des outils de développement ou encore l’accès au trousseau macOS. Surtout, les restrictions définies par l’organisation prennent le dessus sur les réglages individuels : un développeur ne peut donc pas simplement modifier localement une option pour contourner une politique imposée par son entreprise. GitHub transforme ainsi la sandbox d’un mécanisme de protection individuel en véritable composant de gouvernance du poste de développement.

GitHub contrôle aussi ce que l’agent peut faire, action par action

Cette logique va plus loin avec les nouvelles enterprise managed permissions annoncées le 9 septembre. Les administrateurs de GitHub Copilot Business et Enterprise peuvent déterminer quelles opérations des agents sont bloquées, soumises à une approbation humaine ou autorisées sans confirmation.² Ces règles concernent notamment les commandes shell, la lecture et la modification de fichiers ainsi que l’accès à des domaines réseau. Les restrictions administrées ne peuvent pas être affaiblies par les paramètres utilisateur, les réglages du workspace, une fonction d’auto-approbation ou des autorisations précédemment enregistrées. GitHub permet également d’appliquer des politiques différentes selon les équipes, ce qui offre un niveau de granularité utile lorsqu’un développeur backend, une équipe sécurité et un groupe travaillant sur un environnement sensible n’ont pas les mêmes besoins.

Donner un terminal à l’IA oblige aussi à lui fixer des limites

Cette évolution touche directement la Programmation et Gestion Web. Un agent ayant accès au terminal peut potentiellement installer des dépendances, lancer des scripts, modifier des fichiers, appeler des services réseau ou utiliser les ressources accessibles depuis la machine. GitHub rappelle d’ailleurs que, sans sandbox locale activée, les commandes lancées par Copilot CLI s’exécutent avec les droits du compte utilisateur et peuvent donc accéder aux ressources auxquelles ce dernier a lui-même accès.³ La sandbox permet précisément de limiter l’accès au système de fichiers, au réseau et aux capacités système. Pour les équipes de développement, apprendre à travailler avec un agent ne consiste donc plus uniquement à rédiger de bons prompts : il faut aussi comprendre dans quel environnement l’agent s’exécute, quels privilèges il possède et quelles frontières techniques l’empêchent de dépasser son périmètre.

Le chat peut désormais comprendre un contexte projet plus large

GitHub améliore parallèlement la compréhension du projet par Copilot dans JetBrains. Les développeurs peuvent désormais ajouter des fichiers et dossiers globaux au contexte du chat, afin de fournir automatiquement des informations utiles à plusieurs demandes sans devoir les rattacher manuellement à chaque conversation.¹ Cette fonction devient particulièrement pertinente lorsque les modifications concernent plusieurs parties d’une application : conventions internes, documentation, fichiers de configuration ou éléments d’architecture peuvent rester disponibles comme contexte transversal. GitHub ajoute également des déplacements de curseur entre fichiers dans ses next edit suggestions, permettant de suivre plus facilement une série de modifications coordonnées à travers différentes zones du projet. Plus Copilot comprend l’ensemble d’une codebase, plus il peut proposer des interventions cohérentes, mais plus les entreprises doivent aussi contrôler les informations qu’elles autorisent à entrer dans ce contexte.

Le terminal et l’IDE commencent à fonctionner comme un même espace agentique

Autre évolution importante : une session GitHub Copilot CLI ouverte dans le terminal peut désormais être connectée à l’IDE JetBrains grâce à la commande /ide, en public preview.¹ La session terminal obtient alors accès au contexte de l’IDE, notamment aux sélections, diagnostics et références de fichiers. Le développeur peut donc commencer une tâche dans son environnement graphique puis poursuivre avec un agent dans le terminal sans perdre totalement le contexte du projet. Cette convergence montre comment GitHub cherche à dépasser la séparation historique entre éditeur, terminal et assistant IA : l’agent devient progressivement une couche capable de circuler entre les différents outils du workflow de développement.

Les administrateurs peuvent enfin comprendre pourquoi Copilot est bloqué

À mesure que les politiques se multiplient, un nouveau problème apparaît : lorsqu’une fonctionnalité de Copilot ne fonctionne pas, est-ce un bug, un mauvais paramétrage local ou une règle imposée par l’entreprise ? GitHub ajoute des diagnostics de politiques d’entreprise dans JetBrains afin d’aider les développeurs et administrateurs à identifier les règles appliquées à leur environnement.¹ Ce type de visibilité peut sembler secondaire, mais il devient essentiel dans les grandes organisations où plusieurs couches de politiques peuvent s’appliquer simultanément. Une gouvernance efficace ne consiste pas seulement à bloquer une action : les équipes doivent aussi pouvoir comprendre quelle règle s’applique et pourquoi afin d’éviter que les contrôles de sécurité ne deviennent eux-mêmes un obstacle difficile à diagnostiquer.

Le code sensible peut aussi être exclu du contexte de l’IA

Le renforcement des contrôles ne se limite pas aux actions exécutées par l’agent. Depuis début septembre, l’application GitHub Copilot et Copilot CLI respectent également les content exclusion policies configurées au niveau de l’entreprise, de l’organisation ou du repository.⁴ Les fichiers exclus ne doivent pas être utilisés comme contexte par Copilot, ce qui permet aux entreprises de protéger certaines parties sensibles de leurs codebases dans les workflows agentiques. Cette séparation entre ce qu’un agent peut voir et ce qu’il peut faire devient fondamentale : la gouvernance du développement IA doit désormais contrôler à la fois l’accès au contexte, l’exécution des commandes, les modifications de fichiers et les communications réseau.

L’autonomie des agents oblige GitHub à professionnaliser leur gouvernance

Ces nouveautés s’inscrivent dans une évolution plus profonde de Copilot. GitHub avait déjà introduit en juin des sandboxes locales et cloud pour fournir aux agents des environnements isolés dans lesquels ils peuvent utiliser des outils, exécuter des commandes et modifier du code.³ En septembre, l’entreprise ajoute progressivement la couche organisationnelle nécessaire pour utiliser ces capacités à grande échelle : politiques globales sur les modèles, exclusions de contenu, permissions d’agent, sandbox administrée et contrôles centralisés. GitHub prévoit également de rapprocher Copilot Chat sur github.com, l’expérience mobile et son cloud agent autour d’une expérience et d’une politique communes à partir de fin septembre.⁵ Le développement assisté par IA entre donc dans une phase où l’administration de l’agent devient presque aussi importante que ses performances de génération.

L’entreprise ne choisit plus seulement un assistant, elle définit son périmètre d’action

La transformation est importante pour les DSI et les équipes DevOps. Pendant la première génération d’outils de programmation IA, les principales questions portaient sur la qualité du code généré ou les gains de productivité. Avec les agents, une nouvelle série de questions apparaît : quels fichiers peuvent-ils consulter, quelles commandes peuvent-ils exécuter, quels domaines peuvent-ils contacter, quelles actions exigent une validation humaine et quelles règles doivent être identiques pour toute l’organisation ? GitHub apporte progressivement des réponses techniques à ces questions. Le passage du copilote à l’agent de développement ne signifie donc pas seulement davantage d’autonomie : il entraîne la création d’une véritable politique de sécurité et de gouvernance autour du code produit avec l’IA.

L’Actu IT à 360° — décrypter la technologie pour comprendre les métiers de demain.

Pour aller plus loin

Cette montée en puissance des contrôles devient particulièrement importante à mesure que les agents sont capables de travailler sur des projets de plus en plus vastes. Découvrez notre article CCCLX « Qwen3.8-Max aurait codé seul pendant 16 jours sans intervention humaine », qui analyse jusqu’où peut aller l’autonomie d’un agent de développement lorsqu’il est capable d’enchaîner des centaines d’actions sur un projet logiciel.

Références