Copilot CLI respecte les exclusions, mais seulement sur deux offres
Depuis le 2 septembre 2026, GitHub Copilot CLI et l’application GitHub Copilot respectent les exclusions de contenu configurées par les administrateurs d’entreprise, d’organisation ou de dépôt. Dans son annonce du 2 septembre, GitHub indique que les fichiers exclus ne sont plus utilisés comme contexte et que cette disponibilité générale concerne Copilot Business et Copilot Enterprise.
Depuis cette annonce du 2 septembre, les organisations abonnées à l’une de ces deux offres peuvent donc appliquer leurs règles au CLI et à l’application Copilot. Cette disponibilité générale porte sur le comportement des produits : l’API REST qui permet de gérer les règles d’une organisation conserve, elle, le statut d’aperçu public.
La règle administrative atteint désormais le terminal
Le changement étend au CLI et à l’application Copilot une politique définie en amont par les administrateurs. Lorsqu’un chemin correspond à une exclusion applicable, le contenu direct du fichier concerné ne doit pas entrer dans le contexte utilisé par Copilot pour produire sa réponse.
La portée peut être définie au niveau de l’entreprise, de l’organisation ou du dépôt. Ces niveaux ne sont pas interchangeables : une règle de dépôt concerne ce dépôt, tandis qu’une règle d’organisation ou d’entreprise dépend du périmètre administratif et de l’attribution du siège Copilot à l’utilisateur.
L’exclusion est un filtre de contexte, pas un contrôle général des accès. Elle ne retire pas les permissions du compte sur le fichier, ne remplace pas les droits du système d’exploitation et ne dispense pas de conserver les véritables secrets hors du dépôt. Un contenu copié directement dans une invite ou exposé par un autre mécanisme ne devient pas protégé du seul fait qu’un chemin figure dans la règle.
Business et Enterprise sont les deux offres éligibles
La prise en charge annoncée est réservée à Copilot Business et Copilot Enterprise. Disposer du CLI avec une offre individuelle ne suffit donc pas à bénéficier d’une politique d’exclusion administrée au niveau de l’organisation ou de l’entreprise.
Avant d’autoriser une session sur un dépôt sensible, il faut distinguer trois vérifications : l’offre associée au compte, le siège Copilot effectivement attribué et la règle applicable au dépôt utilisé. La simple présence d’une exclusion dans des paramètres GitHub ne démontre pas qu’elle couvre l’utilisateur, le dépôt et la session CLI concernés.
Cette précision empêche aussi d’étendre le résultat à toutes les surfaces Copilot. La nouveauté confirmée porte sur l’application Copilot et Copilot CLI ; une validation obtenue dans le terminal ne prouve pas le même comportement dans un autre client ou mode.
L’API d’organisation n’a pas encore le même statut
La disponibilité générale du contrôle dans les deux produits ne stabilise pas automatiquement son interface d’administration. La documentation REST de GitHub classe toujours les points d’accès de gestion des exclusions d’organisation en aperçu public et prévient qu’ils peuvent changer.
Deux opérations sont documentées sous /orgs/{org}/copilot/content_exclusion : GET consulte les règles et PUT les remplace. Elles sont réservées aux propriétaires de l’organisation. Avec un jeton à permissions fines, la consultation exige la permission d’organisation « Copilot content exclusion » en lecture, et la modification la même permission en écriture.
Pour les jetons OAuth et les jetons personnels classiques, GET accepte les portées « copilot » ou « read:org », tandis que PUT exige « copilot ». L’API ne prend pas en charge les commentaires : GET ne les renvoie pas et PUT supprime ceux qui existent. Elle ne conserve pas non plus plusieurs occurrences d’une même clé, seule la dernière étant renvoyée ou enregistrée.
Une automatisation doit par conséquent relire l’état après chaque écriture et comparer la configuration obtenue avec celle attendue. Ce contrôle répond aux limites actuelles de l’API ; il ne remet pas en cause la disponibilité générale des exclusions dans le CLI et l’application.
Un test négatif et un témoin avant l’ouverture du dépôt
Une équipe ne devrait pas tester cette frontière avec un véritable secret. Le protocole proposé par BaristaLabs repose sur deux fichiers synthétiques : un fichier exclu contenant un marqueur inoffensif et unique, puis un fichier autorisé contenant un autre marqueur.
- Confirmer l’offre Business ou Enterprise, le compte connecté, le siège attribué, le dépôt actif, le niveau administratif de la règle et le motif de chemin attendu.
- Demander au CLI de résumer le fichier synthétique exclu en indiquant seulement son chemin. Son contenu ne doit pas être utilisé comme contexte.
- Demander ensuite le marqueur du fichier exclu sans le copier dans l’invite. Sa restitution à partir de ce fichier constitue un résultat à investiguer.
- Interroger le fichier témoin autorisé. Son marqueur doit rester disponible, faute de quoi le premier résultat pourrait simplement provenir d’une absence générale de contexte du dépôt.
- Poser une question de code dépendant uniquement d’un répertoire autorisé afin de repérer une règle trop large.
- Rejouer ces contrôles après une modification des exclusions, une mise à jour du CLI, un changement de dépôt, de compte ou de licence.
Le relevé doit identifier la version du CLI, le système, le compte, le dépôt, le motif d’exclusion, les invites synthétiques et les résultats observés. Un test concluant atteste uniquement cette combinaison et le traitement direct des chemins vérifiés ; il ne certifie ni toutes les voies d’accès possibles, ni une autre surface Copilot.
L’état confirmé au 7 septembre 2026 est donc délimité : Copilot CLI et l’application Copilot appliquent les exclusions pour les clients Business et Enterprise, mais les routes REST d’organisation restent en aperçu public. La prochaine évolution déterminante sera la stabilisation de cette API ou la modification de ses limites documentées sur les commentaires et les clés dupliquées.
À lire aussi:
Abonnez-vous à notre newsletter
Recevez directement les dernières actualités sur le Web3, l’IA et les cryptomonnaies.