Gouvernance de GitHub Copilot : la gestion des modèles bascule sur une politique centralisée

L'évolution de Copilot vers un outil multi-modèles et multi-plateformes

Ces dernières semaines, l'écosystème GitHub Copilot a connu des évolutions structurantes pour la gestion du code en équipe. Le 14 août 2026, l'arrivée de Grok 4.6 a confirmé la trajectoire de Copilot comme routeur de modèles, laissant le choix de l'IA selon la tâche. Le 19 août 2026, GitHub renforçait le contrôle d'entreprise sur les environnements JetBrains pour imposer des règles centralisées sur la télémétrie, les extensions et les serveurs MCP (Model Context Protocol, un standard qui connecte l'IA à des outils et bases de données externes). Enfin, le 22 août 2026, l'usage s'est étendu au travail collaboratif avec l'exécution d'agents de code au sein de Microsoft Teams.

Le basculement du 26 août 2026 : une politique par défaut

Pour éviter aux administrateurs de valider manuellement chaque nouveauté, GitHub a modifié sa gouvernance le 26 août 2026. Pour les abonnements Copilot Business et Copilot Enterprise, la règle « Default availability for released models » (disponibilité par défaut des modèles publiés) détermine si les modèles non configurés sont activés ou non. Désormais, lorsqu'un modèle passe en GA (Generally Available, c'est-à-dire disponible officiellement en version finale), il hérite automatiquement de la décision globale de l'entreprise ou de l'organisation. Dans l'interface d'administration, ces modèles portent la mention « Delegate to Default Policy » (déléguer à la politique par défaut).

Sécurité et conformité : les exceptions exclues de l'automatisation

Cette activation globale ne s'applique pas à tous les modèles sans distinction. Plusieurs catégories restent désactivées par défaut et nécessitent une action explicite :

• Les modèles en version pré-GA (en phase de test avant publication officielle).
• Les modèles dits open weight (modèles dont la structure et les poids numériques sont téléchargeables librement), tels que DeepSeek, Kimi K2.7 Code et Kimi K3.
• Les modèles exclus des accords de rétention de données de GitHub, à l'image de Claude Fable 5.
• Les modèles non conformes aux politiques strictes de résidence des données ou à la norme FedRAMP (Federal Risk and Authorization Management Program, la norme de sécurité imposée par le gouvernement américain).

Administrer les accès au niveau de l'équipe

Les équipes travaillant sous des contraintes réglementaires fortes peuvent désactiver complètement cette règle globale d'activation au niveau de l'entreprise ou de l'organisation. Même lorsque la politique reste active, il demeure possible d'outrepasser la règle par défaut pour couper un modèle précis.

{
  "policy_name": "default_availability_for_released_models",
  "status": "enabled",
  "scope": "enterprise",
  "exceptions": [
    {
      "model": "claude-fable-5",
      "status": "disabled_by_data_agreement"
    },
    {
      "model": "deepseek",
      "status": "disabled_by_open_weight_policy"
    }
  ]
}

Grâce à ces ajustements, les responsables techniques doivent traiter la disponibilité des modèles d'IA comme un paramètre système global, évitant la gestion au cas par cas au fil des annonces du journal de modifications.