Policies et activation des fonctionnalités

6.4 Policy management

Définition

Une policy Copilot est une règle qui contrôle la disponibilité ou le comportement d’une fonctionnalité Copilot pour des utilisateurs licenciés.

GitHub distingue notamment :

• feature policies : disponibilité d’une fonctionnalité ;
• privacy policies : autorisation ou blocage d’actions potentiellement sensibles ;
• models policies : disponibilité de certains modèles au-delà des modèles de base. (docs.github.com)

Exemple simple

Une organisation peut décider :

Copilot Chat in IDE → Enabled
Copilot CLI → Disabled
Copilot Code Review → Enabled
Selected AI models → Disabled

Ce sont des choix de policy.

Pourquoi les policies existent ?

Pour éviter que chaque développeur utilise Copilot différemment sans contrôle.

Les policies permettent de gérer :

• sécurité ;
• conformité ;
• coûts ;
• cohérence ;
• disponibilité ;
• usages autorisés ;
• limites d’accès ;
• adoption progressive.

Types de policies

1. Feature policy

Contrôle si une fonctionnalité est disponible.

Exemples :

• Copilot Chat ;
• Copilot CLI ;
• Copilot Code Review ;
• les agents (Copilot cloud agent, agents tiers) ;
• les serveurs MCP.

2. Privacy policy

Contrôle des actions liées à la confidentialité.

Exemples conceptuels :

• autoriser ou non certaines interactions sensibles ;
• contrôler l’usage de données ;
• limiter certaines capacités selon le contexte.

3. Models policy

Contrôle l’accès à certains modèles.

Pourquoi c’est important ?

Certains modèles peuvent :

• coûter plus cher ;
• avoir des performances différentes ;
• être soumis à des règles d’utilisation ;
• être réservés à certains plans.

GitHub mentionne explicitement que les models policies contrôlent la disponibilité des modèles au-delà des modèles de base, et que ces modèles peuvent entraîner des coûts additionnels. (docs.github.com)

Policy inheritance

Une policy se configure dans l’onglet AI controls de l’enterprise ou dans les réglages de l’organisation. Au niveau enterprise, un enterprise owner (ou un rôle qui gère les AI controls) choisit en général entre trois états : activée, désactivée, ou « Let organizations decide » (aussi appelé « No policy »).

Enterprise : activée ou désactivée  → l’organisation ne peut pas la modifier.
Enterprise : Let organizations decide → chaque organization owner décide.
Utilisateur : reste soumis aux policies supérieures.

Quand l’enterprise a imposé une valeur, elle apparaît dans l’organisation sans pouvoir y être changée.

Exemple

Enterprise policy :

Copilot CLI = Disabled

Un organization owner veut activer Copilot CLI dans son organisation.

Résultat :

Il ne peut pas : la restriction de l’enterprise s’applique.

Si l’enterprise avait choisi « Let organizations decide », chaque organisation déciderait.

Logique d’examen :

Le niveau supérieur peut imposer une règle au niveau inférieur ; sans règle imposée, le niveau inférieur décide.

Policy management = contrôler quelles fonctionnalités Copilot sont disponibles, pour qui, et dans quelles conditions.

6.5 Activer ou désactiver des features Copilot

Définition

Les admins peuvent activer ou désactiver certaines fonctionnalités Copilot selon le plan et le niveau d’administration.

GitHub explique que les admins peuvent contrôler la disponibilité des features Copilot pour les utilisateurs licenciés via des policies organisation ou enterprise. (docs.github.com)

Exemples de features contrôlables

Selon les plans et les évolutions produit, les policies peuvent concerner des fonctionnalités comme :

• Copilot Chat ;
• Copilot in the IDE ;
• Copilot on GitHub.com ;
• Copilot CLI ;
• Copilot Code Review ;
• Copilot cloud agent et agents tiers ;
• serveurs MCP ;
• accès à certains modèles.

Exemple 1 : Désactiver Copilot CLI

Pourquoi une entreprise pourrait désactiver Copilot CLI ?

Parce que le CLI peut :

• lire des fichiers ;
• modifier des fichiers ;
• exécuter des commandes ;
• être utilisé dans des dossiers sensibles ;
• générer des commandes destructives.

Une équipe sécurité peut décider :

Copilot CLI = Disabled

jusqu’à ce qu’un cadre d’usage soit défini.

Exemple 2 : Activer Copilot Chat dans l’IDE

Une équipe engineering veut améliorer la productivité sans activer les agents autonomes.

Policy possible :

Copilot Chat in IDE = Enabled
Agentic features = Disabled

Cela permet une adoption progressive.

Exemple 3 : Contrôler les modèles

Une organisation veut éviter les coûts imprévus.

Policy possible :

Selected AI models = Disabled

ou :

Selected AI models = Enabled only for selected users

Agents, CLI et Chat : des policies séparées

Plusieurs fonctionnalités voisines ont chacune leur policy :

• Copilot CLI et l’application GitHub Copilot : désactiver l’une ne désactive pas l’autre.
• /delegate dans le CLI : les policies Copilot CLI et Copilot cloud agent doivent toutes deux l’autoriser.
• Agent Mode dans l’IDE : il se contrôle séparément de Copilot Chat dans l’IDE.
• Copilot cloud agent : l’enterprise peut l’activer pour des organisations choisies seulement.
• Agents tiers : ils se gèrent à part ; désactiver le cloud agent ne les désactive pas.
• Serveurs MCP : policy « MCP servers in Copilot », désactivée par défaut, qui ne gouverne que Business et Enterprise (voir 4.7).

Historique : les Copilot Extensions basées sur des GitHub Apps ont été arrêtées le 10 novembre 2025 ; les serveurs MCP les remplacent.

Bonne pratique

Ne pas tout activer d’un coup sans réflexion.

Approche responsable :

1. Activer Copilot pour une équipe pilote.
2. Définir les policies.
3. Former les développeurs.
4. Configurer content exclusions.
5. Activer Code Review si pertinent.
6. Surveiller avec audit logs.
7. Étendre progressivement.

Une policy au niveau organisation ou enterprise.