Ce qui est confirmé
GitHub déploie progressivement l’application de sa politique globale de modèles pour GitHub Copilot Business et GitHub Copilot Enterprise. L’annonce du 26 août 2026 précise que ce déploiement se poursuit jusqu’au 1er septembre. Pour une équipe qui utilise Copilot, le sujet n’est pas le choix d’un nouveau modèle. C’est la manière dont les modèles non configurés héritent désormais d’une décision d’administration centrale. Source GitHub
Ce qui change dans la politique globale de GitHub Copilot
Fait confirmé. GitHub indique avoir annoncé en juillet une politique de modèle par défaut pour les modèles Copilot disponibles de manière générale, sur les offres Copilot Business et Copilot Enterprise. Le changelog publié le 26 août annonce le déploiement progressif de son application jusqu’au 1er septembre. L’instant exact où la règle devient effective dépend donc de chaque entreprise. GitHub
Le mécanisme concerne les modèles qui n’avaient pas encore reçu de réglage individuel. Après l’entrée en vigueur de la politique pour l’organisation ou l’entreprise, ces modèles passent à l’état « Delegate to default policy ». Ils suivent alors le réglage global. Si ce réglage est activé, GitHub précise que les modèles concernés deviennent disponibles pour les utilisateurs. GitHub
Analyse. Cette évolution déplace une partie de la gouvernance. Avant de parler de productivité ou d’agent IA, il faut savoir quel réglage s’applique réellement à un modèle. Un modèle qui suivait une configuration implicite peut désormais suivre une politique globale vivante. C’est un détail d’interface, mais aussi un sujet de pilotage pour une stack de développement.
Tu peux garder un œil sur les actualités du site si tu suis les changements qui touchent les outils IA et les équipes techniques. Pour le contexte sur les modèles dans Copilot, ce dossier sur Gemini 3.7 Flash dans GitHub Copilot peut aussi compléter ta veille. Il ne remplace pas la vérification de tes réglages d’administration.
Les quatre états à comprendre avant de toucher aux réglages
Fait confirmé. GitHub présente quatre états possibles pour un modèle dans les réglages après le déploiement. Un modèle peut être activé explicitement. Il peut être désactivé explicitement. Il peut déléguer sa décision à une équipe, une application ou une organisation. Il peut enfin déléguer à la politique par défaut. GitHub
L’état « Delegate to default policy » est décrit comme dynamique. Il suit en continu la politique globale. GitHub précise qu’un changement de politique se répercute sur tous les modèles concernés. À l’inverse, un choix explicite déjà posé pour un modèle est conservé. GitHub ne modifie pas un modèle qui a été volontairement activé ou désactivé. GitHub
Concrètement. Je te conseille de ne pas lire ces quatre états comme de simples libellés. Ils répondent à quatre questions différentes : qui a décidé, à quel niveau, avec quel degré de permanence, et que se passera-t-il lors du prochain changement global. Cette lecture évite de confondre un modèle disponible avec un modèle explicitement validé par l’entreprise.
Voici une grille simple pour relire tes paramètres :
- « Enabled » signifie que le modèle a été activé de façon explicite.
- « Disabled » signifie que le modèle a été désactivé de façon explicite.
- Un état de délégation vers une équipe, une application ou une organisation signifie que la décision est héritée de ce niveau.
- « Delegate to default policy » signifie que le modèle suit la politique globale par défaut.
Ces définitions reprennent les états listés par GitHub. GitHub
Je ferais surtout la différence entre disponibilité et validation. La disponibilité découle du réglage applicable. La validation interne relève de ton processus. La source ne décrit pas ce processus pour ton entreprise. Elle ne dit pas non plus quels modèles tu utilises aujourd’hui, ni quels réglages existent dans ton compte. Il faut donc les contrôler dans l’administration GitHub, plutôt que supposer un état.
Les modèles exclus de l’activation par défaut
Fait confirmé. GitHub exclut de l’activation par défaut les modèles open-weight, avec DeepSeek et Kimi K2 comme exemples. GitHub exclut aussi les modèles qui ne sont pas couverts par son accord de rétention des données, avec Fable 5 comme exemple. Ces exclusions s’appliquent indépendamment de l’activation de la politique globale. GitHub
Cette précision mérite d’être lue sans raccourci. La source parle de modèles open-weight et de modèles non couverts par l’accord de rétention des données. Elle ne fournit pas une liste exhaustive dans l’extrait disponible. Elle ne détaille pas non plus le contenu de cet accord. Je ne peux donc pas en déduire les conditions techniques, juridiques ou tarifaires applicables à chaque modèle.
Pourquoi c’est important
Analyse. Dans une équipe, cette distinction invite à séparer deux décisions. La première porte sur la politique générale appliquée aux modèles disponibles de manière générale. La seconde porte sur les exceptions et les modèles qui sortent du cadre d’activation par défaut. Les traiter dans le même tableau de revue évite d’oublier qu’une règle globale ne couvre pas nécessairement tous les cas.
Si tu construis des automatisations autour de l’IA, le guide automatiser son business donne un point de départ côté workflow. Pour un sujet plus proche des contrôles d’entreprise, tu peux aussi consulter cet article sur les réglages GitHub Copilot dans JetBrains. Ces ressources sont complémentaires. Elles ne constituent pas une confirmation de configuration pour ton organisation.
Ce qui est confirmé, et ce qui reste inconnu
Fait confirmé. Le déploiement annoncé par GitHub est progressif et doit se poursuivre jusqu’au 1er septembre. GitHub indique que les nouveaux modèles disponibles de manière générale et les modèles précédemment non configurés héritent de l’état de la politique globale. L’entreprise peut modifier cette politique à tout moment. GitHub
Inconnu dans la source. Le changelog ne communique pas la date précise d’activation pour une entreprise donnée. Il ne fournit pas non plus de liste exhaustive des modèles concernés, de calendrier par pays, de détail de prix, ni de procédure de validation interne. Il ne permet donc pas d’affirmer qu’un modèle précis est accessible dans ton environnement à une heure donnée.
Analyse. C’est une annonce de gouvernance, pas une promesse de résultat métier. Elle peut réduire l’ambiguïté si tes équipes savent qui pilote la politique par défaut. Elle ne mesure ni la qualité des réponses, ni le temps gagné, ni le retour sur investissement. Pour ces critères, il faut définir tes propres indicateurs et regarder l’usage réel après le changement.
Je ferais aussi attention à la formulation « par défaut ». Un défaut peut être utile pour standardiser un parc. Il peut devenir opaque si personne ne documente son intention. GitHub indique d’ailleurs évaluer la possibilité de rendre l’état de politique globale explicite et de supprimer l’état « Delegate to default policy ». À ce stade, il s’agit d’une piste évaluée, pas d’un changement annoncé comme acquis. GitHub
Ce que ça change pour toi
Pour un responsable d’équipe, la conséquence pratique est de faire une revue courte des modèles dont l’état est délégué. Commence par identifier les réglages qui relèvent de la politique globale. Distingue-les des modèles activés ou désactivés explicitement. Cette vérification répond directement au changement décrit par GitHub, sans inventer de règle supplémentaire.
Ensuite, note les modèles qui nécessitent une décision spécifique. Les modèles open-weight et ceux non couverts par l’accord de rétention des données ne sont pas activés par défaut selon GitHub. Leur présence éventuelle dans ton stack demande donc une lecture distincte de la politique générale. GitHub
Tu peux transformer cette revue en un workflow simple : un propriétaire pour la politique globale, une liste des exceptions explicites et une date de relecture. C’est une recommandation d’organisation, pas une obligation annoncée par GitHub. Son intérêt est de pouvoir expliquer une décision lorsque les utilisateurs constatent qu’un modèle est disponible, indisponible ou hérité.
Côté marketing et produit, évite de présenter Copilot comme un bloc unique. La source montre que l’accès dépend de la politique et de l’état du modèle. Si tu documentes un onboarding interne, précise donc le périmètre de ton environnement au moment où tu écris. Ne promets pas qu’un modèle est actif pour tous les lecteurs.
Cette prudence rejoint ma manière de regarder les agents IA. Dans cet article sur les plugins d’agents GitHub, le point important reste le cadrage du workflow. Un agent, un plugin ou un modèle n’améliore pas seul un processus. Le résultat dépend aussi des règles, des accès et du contrôle humain.
Une méthode de vérification sans surinterpréter l’annonce
Je procéderais en trois temps. D’abord, ouvre les réglages de ton organisation ou de ton entreprise et relève l’état affiché pour chaque modèle. La source confirme les quatre états, mais elle ne donne pas accès à tes réglages. Cette étape est donc indispensable pour passer de l’annonce à ta situation réelle.
Ensuite, compare les modèles délégués avec la politique globale en vigueur. Le point à vérifier n’est pas seulement l’activation. C’est aussi le niveau auquel la décision est prise. Un modèle explicitement configuré ne suit pas forcément une modification de la politique par défaut, puisque GitHub indique préserver les choix explicites. GitHub
Enfin, documente les exceptions. Je ne parle pas d’ajouter une bureaucratie lourde. Une note courte peut suffire : modèle, état, niveau de décision, personne responsable et raison de l’exception. C’est une opinion de méthode. Elle te donne surtout une base pour répondre à une question simple de tes équipes : pourquoi ce modèle est-il proposé ou non ?
Ce que cela change
Pour relier cette gouvernance à tes autres outils, tu peux parcourir nos guides et ce contenu sur le choix d’un outil d’email marketing. Les sujets diffèrent, mais le réflexe reste le même : vérifier le périmètre réel d’un outil avant de le déployer dans un workflow.
Mon avis
À mon avis, cette politique globale va dans le bon sens si elle rend les décisions visibles et réversibles. Le vrai risque n’est pas l’existence d’un défaut. C’est de croire qu’un défaut remplace une décision de gouvernance. Je privilégierais une politique simple, des exceptions explicites et une revue régulière. Je ne tirerais aucune conclusion sur la performance, la conformité ou le coût d’un modèle à partir de cette seule annonce.
FAQ
Quand la politique globale de modèles Copilot est-elle appliquée ?
GitHub annonce un déploiement progressif de l’application de la politique jusqu’au 1er septembre. Le moment où elle prend effet peut différer selon les entreprises. GitHub
Que devient un modèle GitHub Copilot qui n’était pas configuré ?
Selon GitHub, les modèles auparavant non configurés passent à l’état « Delegate to default policy » lorsque la politique prend effet. Ils suivent alors le réglage global applicable. GitHub
Un réglage explicite sur un modèle est-il remplacé par la politique globale ?
Non. GitHub indique conserver les choix explicites d’activation ou de désactivation réalisés pour un modèle. GitHub
Les modèles open-weight sont-ils activés par défaut dans GitHub Copilot ?
Non. GitHub indique que les modèles open-weight sont exclus de l’activation par défaut, et cite DeepSeek et Kimi K2 comme exemples. GitHub
Comment vérifier les modèles réellement disponibles dans mon organisation ?
Consulte les réglages d’administration de ton organisation ou de ton entreprise. Le changelog décrit les états possibles, mais ne permet pas de connaître la configuration propre à ton environnement.
Information & avertissement
Cet article analyse une annonce officielle de GitHub datée du 26 août 2026. Il ne remplace pas la vérification des réglages de ton organisation, ni un avis juridique, sécurité ou conformité. Aucun lien affilié ni aucune offre commerciale ne sont intégrés à cet article.
Sources et méthode
Les informations ont été vérifiées à partir des sources ci-dessous.
Les faits confirmés sont distingués des analyses et des limites encore ouvertes.
