9 min de lecture - Exclusions Copilot : vérifiez les parcours avant le déploiement

GitHub a annoncé le 2 septembre 2026 que Copilot app et CLI respectent désormais les exclusions de contenu définies par les administrateurs. Cette évolution concerne les clients Copilot Business et Enterprise et étend à ces interfaces les restrictions sur les fichiers utilisés comme contexte. Si votre équipe avait suspendu un essai d’assistance dans le terminal à cause de code sensible, vous pouvez réexaminer ce choix.

La décision demande toutefois de préciser le parcours de travail. Un développeur peut passer de l’éditeur au terminal, puis à une pull request, sans changer de compte. Une autorisation qui indique seulement « Copilot est autorisé » laisse chacun deviner quelles activités la revue de sécurité a couvertes.

Nous recommandons d’évaluer chaque client et chaque mode au regard des fichiers qu’il doit pouvoir utiliser. Consignez les chemins exclus, testez le parcours réel avec des données fictives et attribuez la revue du code que l’assistant doit ignorer. L’exercice proposé ci-dessous constitue une méthode d’acceptation, sans prétendre rapporter des tests de GitHub ou un déploiement chez un client d’Exceev.

Lisez l’annonce à l’échelle de chaque client

La documentation des exclusions de GitHub indique encore des limites pour les modes Edit et Agent des éditeurs, les liens symboliques et les systèmes de fichiers distants. Elle signale aussi que les informations sémantiques fournies par l’IDE peuvent transmettre des détails issus de fichiers exclus. Ces fichiers échappent à la revue de code de Copilot.

Le client et le mode doivent donc figurer dans l’autorisation. Si un développeur peut utiliser un parcours testé, n’étendez pas cette permission à un autre parcours sur la seule base du nom du produit. Notez l’interface ouverte, la manière dont le dépôt arrive dans cet environnement et l’action qui déclenche l’assistance.

Vous pourriez, par exemple, autoriser un client testé sur une copie locale du dépôt, tout en laissant un environnement de développement distant en attente. Cette formulation illustre une décision possible ; elle ne signifie pas que tout parcours local est couvert. Le développeur dispose d’une consigne précise et le responsable de la revue peut reproduire son périmètre.

Conservez une copie datée de la documentation avec cette décision. La couverture du produit peut évoluer ; une ancienne capture d’un réglage activé ne suffit pas à justifier l’usage d’un nouveau mode.

Commencez par les fichiers et le compte

Prenons une équipe fictive qui conserve une application courante, un module de tarification confidentiel et des exports de diagnostic client dans le même répertoire de travail. L’application peut bénéficier de l’assistance, le module impose une autre règle de divulgation et les exports devraient rester hors de l’environnement de l’assistant.

Établissez ces distinctions avant d’écrire les motifs d’exclusion. Pour chaque catégorie, indiquez la raison de la restriction et la personne habilitée à la modifier. Évitez un motif large choisi uniquement parce que son nom semble sensible. Un dossier internal peut contenir des types d’API publics et des règles commerciales confidentielles ; l’équipe doit décider où placer chaque contenu.

Le guide de configuration de GitHub distingue les règles d’entreprise de celles liées aux licences attribuées par une organisation. Vérifiez l’origine de la licence du compte de test, ainsi que le dépôt. Le guide documente des listes de chemins au niveau du dépôt, comme dans cet exemple :

- '/restricted-pricing/**'
- '/customer-debug-exports/**'

Ces noms illustrent la syntaxe et ne constituent pas une politique complète. Demandez à un administrateur du dépôt de saisir les règles applicables dans les paramètres documentés et de vérifier les règles héritées avant le test. La présence d’un fichier de politique dans le dépôt ne prouve pas qu’un administrateur a configuré ces paramètres.

Pour une équipe répartie entre la France et le Maroc, conservez un registre commun des comptes et des parcours autorisés. La géographie ne permet pas, à elle seule, de décider quels fichiers un outil peut recevoir. N’en déduisez aucune permission contractuelle ni hypothèse sur le traitement des données.

Construisez un test sans données sensibles

Utilisez un dépôt jetable qui reprend l’organisation envisagée. Placez un marqueur aléatoire et inoffensif dans un fichier autorisé, puis un autre dans un fichier exclu. Générez ces marqueurs pour le test et ne les inscrivez pas dans les requêtes. Un marqueur unique aide à distinguer un détail retrouvé d’une réponse plausible inventée par le modèle.

Commencez par un contrôle positif : demandez un fait présent uniquement dans le fichier autorisé. Si l’assistant ne répond pas, corrigez l’environnement avant d’interpréter son silence sur le fichier exclu. Un client déconnecté peut donner une fausse impression de restriction.

Posez ensuite une question équivalente dont la réponse existe uniquement dans le fichier exclu. Conservez la réponse et les références ou traces d’outils disponibles. L’absence du marqueur dans la réponse ne prouve pas qu’aucun contenu n’a atteint un service. Rapprochez cette observation de la couverture documentée et des diagnostics disponibles. Ne collez pas de contenu confidentiel réel pour rendre le test plus convaincant.

Un tableau permet de conserver les conditions de chaque résultat. Il s’agit de cas de test proposés, sans résultats mesurés ni procédure de certification GitHub.

Rejouez les cas concernés après un déplacement de dossier ou une mise à jour du client qui modifie le parcours. Gardez un dépôt de test assez petit pour qu’un développeur puisse expliquer le rôle de chaque fichier. Un dépôt réaliste mais volumineux, avec des dépendances mal identifiées, complique l’analyse d’une réponse inattendue.

Prévoyez la revue du code exclu

La décision d’exclusion a une conséquence sur la livraison. Si l’équipe restreint son module de tarification, quelqu’un doit encore examiner ses modifications et celles du code qui en dépend. Prévoyez ce travail lors de l’approbation de la restriction.

Imaginons une modification du paiement qui change l’arrondi dans l’application courante, tandis qu’un module exclu calcule les remises. La personne chargée de la revue doit vérifier la relation entre les deux. Une revue de l’assistant sans anomalie sur le code visible ne permet pas de clore cette question.

Demandez au responsable de revue d’examiner le diff exclu et les tests d’intégration qui exercent son comportement public. Utilisez des exemples fictifs à cette interface lorsque l’assistant peut travailler sur les tests sans recevoir l’implémentation confidentielle. Si l’interface elle-même est confidentielle, gardez aussi ce parcours de test dans l’environnement autorisé.

Suivez la couverture de la revue séparément de ses conclusions. « Aucun problème détecté » décrit un résultat dans le périmètre examiné ; cette mention n’indique pas quels fichiers ont été vérifiés. Une courte note qui relie les chemins exclus à leur responsable de revue lève cette ambiguïté sans recopier de code confidentiel dans la discussion de la pull request.

Notre guide de choix entre développement et achat d’un assistant de code aide à cadrer l’achat. La décision d’exclusion appartient au registre opérationnel, plus précis, du produit et du dépôt retenus.

Examinez séparément les permissions des outils

Les recommandations d’OWASP sur l’autonomie excessive des agents préconisent des permissions minimales et des contrôles d’autorisation dans les systèmes appelés. Cette source indépendante justifie une revue distincte des accès ; elle ne prouve aucune défaillance des exclusions d’une version de Copilot.

Pour le pilote, inventoriez les outils connectés et les identités qu’ils utilisent. Si un connecteur interroge un espace documentaire, déterminez les documents dont son identité a besoin. Si un shell s’exécute avec le compte d’un développeur, examinez ce que cet environnement peut atteindre. N’attribuez pas à un réglage de contexte la réponse à ces questions.

Si votre exigence interdit tout accès du processus de l’assistant à un jeu de données, concevez l’environnement en conséquence. Une copie du dépôt limitée au nécessaire et des identifiants aux droits restreints sont des options à évaluer. Testez la solution retenue avec le compte réel ; l’instruction « ne pas lire » dans une requête ne prouve pas qu’un contrôle de permission existe.

Rendez la décision de déploiement reproductible

À la fin de l’exercice, conservez un relevé court avec la version de la politique, le client et son mode, l’identité de test, la révision du dépôt fictif et les résultats observés. Ajoutez les questions ouvertes. Attribuez chaque parcours non résolu à un responsable au lieu de l’inclure dans une autorisation générale.

GitHub documente l’événement d’audit copilot.content_exclusion_changed pour les changements au niveau des dépôts et des organisations, avec les chemins exclus enregistrés. Reliez ces éléments au relevé de test. Ils montrent ce que les administrateurs ont modifié, sans prouver le déroulement de chaque interaction avec l’assistant.

Fixez la condition d’acceptation avant de consulter les résultats. Vous pouvez autoriser le parcours testé lorsque l’assistance courante fonctionne, que les exclusions correspondent au périmètre documenté et qu’un responsable prend en charge le code omis. Si une observation contredit la restriction attendue, suspendez ce parcours et analysez le problème avec le dépôt fictif. Gardez la dernière configuration acceptée pour pouvoir la restaurer sans reconstruire les règles de mémoire.

Le résultat utile est une permission qu’un développeur peut appliquer : ce compte peut utiliser ce client et ce mode sur cette organisation du dépôt, avec ces chemins exclus et cette répartition de la revue. Élargissez-la lorsque de nouveaux éléments justifient un changement précis.

Sources et limites

Nous avons ouvert et vérifié toutes les sources ci-dessous le 3 septembre 2026.

• L’annonce GitHub du 2 septembre établit l’évolution pour app et CLI ainsi que les offres concernées.
• La couverture et les limites de GitHub précisent le périmètre du produit retenu ici.
• Le guide de configuration GitHub étaye la distinction entre comptes et l’exemple de chemins.
• Le guide d’audit GitHub documente les traces des changements de politique.
• OWASP LLM06:2025 apporte des recommandations établies sur les permissions, indépendamment de GitHub.

GitHub constitue la source primaire sur le comportement de son produit. OWASP ne confirme pas l’annonce et ne certifie pas son implémentation. Nous n’avons ni testé ces clients Copilot, ni mesuré des taux de fuite, ni évalué les exigences contractuelles d’un client. Les exemples et l’exercice d’acceptation relèvent d’une analyse d’ingénierie proposée. Vérifiez la documentation et vos clients installés avant de les appliquer.