GitHub a rendu l’exclusion de contenu généralement disponible le 2 septembre dans l’application GitHub Copilot et dans Copilot CLI. Pour les clients Copilot Business et Copilot Enterprise, ces deux interfaces respectent désormais les règles définies par les administrateurs au niveau de l’entreprise, de l’organisation ou du dépôt, et les fichiers exclus ne sont pas utilisés comme contexte par Copilot.
L’évolution comble une partie importante du dispositif de contrôle, mais elle ne crée pas une frontière universelle autour du code sensible. La documentation de GitHub décrit encore des niveaux de prise en charge différents selon les interfaces, exclut actuellement les modes Edit et Agent de Copilot Chat dans Visual Studio Code et d’autres éditeurs, et signale des limites concernant les liens symboliques, les systèmes de fichiers distants et certaines informations fournies indirectement par l’environnement de développement. Pour une entreprise, le contrôle doit donc être validé par client, par mode d’utilisation et par emplacement du dépôt.
La règle s’étend à l’application Copilot et à la ligne de commande
L’exclusion de contenu permet aux administrateurs d’indiquer les fichiers que Copilot doit ignorer. GitHub précise que les fichiers concernés ne reçoivent pas de suggestions en ligne, que leur contenu ne doit pas alimenter les suggestions dans d’autres fichiers ni les réponses de Copilot, et qu’ils ne sont pas examinés par la revue de code Copilot.
La mise à jour du 2 septembre est notable parce que l’application Copilot et Copilot CLI sont des points d’entrée pour des usages agentiques, et pas seulement pour la complétion de code. GitHub indique que ces deux interfaces appliquent maintenant les règles configurées au niveau de l’entreprise, de l’organisation et du dépôt. Une politique destinée à isoler certaines parties sensibles d’un dépôt peut ainsi suivre une partie des flux de travail dans lesquels un agent explore le code, répond à une demande ou réalise une tâche depuis le terminal.
La fonction est disponible pour Copilot Business et Copilot Enterprise. Les administrateurs de dépôt, les propriétaires d’organisation et les responsables au niveau Enterprise peuvent définir des exclusions dans leur périmètre.
L’application de la règle dépend encore de l’interface
L’expression « exclusion de contenu » peut donner l’impression d’un contrôle uniforme. La matrice de prise en charge publiée par GitHub montre que ce n’est pas encore le cas.
Sur le site GitHub et dans GitHub Mobile, l’exclusion de contenu reste en préversion publique. L’application GitHub Copilot et Copilot CLI bénéficient désormais de la disponibilité générale annoncée le 2 septembre. En revanche, GitHub indique explicitement que les modes Edit et Agent de Copilot Chat dans Visual Studio Code et d’autres éditeurs ne prennent actuellement pas en charge cette fonction.
La différence est importante pour les entreprises qui passent d’une simple assistance à la saisie vers des agents capables de planifier des modifications, de changer plusieurs fichiers, d’exécuter des commandes et d’utiliser des outils. Le fait qu’une règle fonctionne dans une interface Copilot ne garantit pas qu’elle se comporte de la même manière dans une autre.
Des informations dérivées peuvent encore franchir la frontière
GitHub documente également une limite plus subtile. Copilot peut utiliser des informations sémantiques liées à un fichier exclu lorsque l’environnement de développement les fournit indirectement. La documentation cite notamment les informations de type, les définitions affichées au survol des symboles et des propriétés générales du projet telles que la configuration de compilation.
Cela ne signifie pas que Copilot lit directement le fichier exclu. Le problème est que l’IDE peut transformer le contenu du dépôt en métadonnées qui deviennent accessibles par un autre chemin. Une revue de sécurité doit donc examiner non seulement l’accès aux fichiers, mais aussi les informations dérivées que les outils de développement exposent.
GitHub précise en outre que les exclusions ne s’appliquent actuellement ni aux liens symboliques ni aux dépôts placés sur des systèmes de fichiers distants. Cette restriction compte pour les équipes qui utilisent des espaces de travail montés à distance, des systèmes de fichiers réseau, des conteneurs de développement distants ou des dépôts reposant fortement sur des liens symboliques.
La gouvernance exige une matrice de contrôle, pas une seule case à cocher
La conséquence opérationnelle est claire : l’exclusion de contenu doit être considérée comme un contrôle dépendant de l’interface et non comme une garantie générale empêchant tout contenu sensible d’influencer Copilot.
Une matrice de contrôle utile devrait au minimum consigner quatre dimensions : le client Copilot, le mode d’interaction, l’emplacement du dépôt ou du système de fichiers, et la nature des informations susceptibles de franchir la frontière. Un même chemin exclu peut bénéficier d’une protection différente lorsque le développeur passe de la revue de code à la CLI, de la CLI à un mode agent dans l’IDE, ou d’une copie locale à un système de fichiers distant.
Les critères d’autorisation doivent suivre cette réalité. « L’exclusion de contenu est activée » est un critère trop faible pour un dépôt sensible. Une exigence plus solide consiste à vérifier les interfaces Copilot effectivement autorisées pour ce dépôt, tout en documentant les modes non pris en charge et les exceptions liées au système de fichiers.
Ce qu’il faut vérifier avant un déploiement sur du code sensible
Avant d’autoriser des agents Copilot sur des dépôts contenant des secrets, des algorithmes propriétaires, des données réglementées ou du code soumis à des restrictions contractuelles, les équipes plateforme et sécurité doivent tester le comportement dont elles dépendent réellement.
Elles devraient définir les clients et les modes autorisés, tester les fichiers exclus dans l’application et dans la CLI, recenser l’usage des modes Edit et Agent dans les éditeurs, contrôler les dépôts distants et les liens symboliques, puis décider si les informations sémantiques fournies indirectement par l’IDE sont acceptables. La revue de code mérite également un test distinct, puisque GitHub la présente comme une surface prise en charge séparément.
Cette version renforce de façon concrète la couche de contrôle destinée aux entreprises. Sa valeur principale n’est pas de résoudre définitivement la gouvernance du code sensible, mais d’ajouter une interface supplémentaire où la politique peut être appliquée. Les limites restantes rappellent un principe plus général : un contrôle de gouvernance pour les agents doit avoir un périmètre explicite, et ce périmètre doit être vérifié dans l’environnement où l’agent est réellement utilisé.