À partir du 26 août 2026, GitHub Copilot Business et Enterprise changeront la manière dont les modèles généralement disponibles mais non configurés sont proposés. Ils prendront automatiquement la valeur d’une nouvelle politique globale, activée par défaut. Une organisation qui ne modifie rien pourra donc voir apparaître de nouveaux modèles sans validation manuelle à chaque lancement.

GitHub cherche à réduire le délai entre la disponibilité d’un modèle et son adoption. Pour une petite équipe, c’est pratique. Pour une entreprise soumise à des règles de localisation, de conservation, de coût ou de propriété intellectuelle, l’absence de décision devient cependant une décision technique.

La réponse rapide

QuestionRéponse
Quand la politique prend-elle effet ?Le 26 août 2026.
Quels modèles sont concernés ?Les modèles GA laissés non configurés et éligibles à l’activation automatique.
Les choix explicites sont-ils écrasés ?Non, un modèle explicitement activé ou désactivé conserve son état.
Les modèles ouverts sont-ils activés automatiquement ?Non, GitHub exclut notamment les modèles open weight de ce mécanisme.
Que doit faire un administrateur prudent ?Choisir un défaut global puis expliciter les exceptions avant le 26 août.

« Inherits default » remplace l’absence de décision

Jusqu’ici, un nouveau modèle pouvait rester dans un état non configuré jusqu’à l’intervention d’un administrateur. Avec la nouvelle règle, cet état devient inherits default. Si la politique globale est activée, le modèle devient accessible ; si elle est désactivée, il reste bloqué.

L’intérêt est la cohérence. Une organisation favorable à l’innovation n’a plus à ouvrir chaque modèle manuellement. Une entité réglementée peut placer le défaut sur désactivé et constituer une liste positive. Dans les deux cas, il faut comprendre que le paramètre s’appliquera aussi aux futurs modèles éligibles.

Les décisions explicites restent prioritaires. Désactiver individuellement un modèle empêche son activation par héritage, même si le défaut global est permissif. Cette hiérarchie permet un socle simple avec quelques exceptions documentées.

Tous les modèles ne suivent pas la règle

GitHub exclut les modèles en préversion, les modèles à poids ouverts et ceux qui ne sont pas couverts par son accord de conservation des données. Les environnements restreints aux modèles résidents ou conformes FedRAMP conservent également leurs contraintes.

Ces exclusions évitent qu’un réglage générique contourne des limites contractuelles majeures. Elles ne dispensent pas d’un examen. Un modèle couvert par un accord peut quand même présenter un coût, une qualité, une fenêtre de contexte ou un comportement différents de celui validé par l’entreprise.

Le vrai sujet est la gouvernance du changement

L’accès à plusieurs modèles permet aux développeurs de choisir entre vitesse, raisonnement et contexte. Il rend aussi les résultats moins homogènes. Deux personnes peuvent obtenir des propositions différentes sur le même dépôt, et un changement de modèle peut modifier la consommation de crédits ou la façon dont du code est envoyé au fournisseur.

Une politique robuste doit répondre à quatre questions : quels fournisseurs sont approuvés, quelles données peuvent quitter le poste, quels budgets sont acceptables et comment mesurer la qualité. La liste des modèles n’est que l’implémentation de ces choix.

GitHub recommande une approche plutôt permissive avec blocage des exceptions critiques. Une entreprise peut légitimement choisir l’inverse. Le bon réglage dépend du niveau de contrôle requis, pas d’une préférence universelle.

Une vérification en cinq étapes avant le 26 août

Commencez par ouvrir les paramètres Copilot de l’entreprise et des organisations. Identifiez ensuite les modèles explicitement activés, désactivés et optionnels. Choisissez la valeur de Default availability for released models, puis documentez les exceptions.

Vérifiez les accords de traitement des données et les exigences de résidence avec les équipes juridique et sécurité. Associez enfin cette politique aux budgets de crédits IA : ouvrir davantage de modèles sans limite de dépense peut créer une surprise financière même si la conformité est correcte.

Après l’entrée en vigueur, exportez ou contrôlez la liste effective depuis un compte utilisateur représentatif. Les héritages entre entreprise et organisation peuvent produire une configuration différente de celle imaginée à un seul niveau.

Ne pas oublier les usages locaux et les clés personnalisées

Les entreprises qui autorisent des modèles apportés par l’utilisateur ou une clé fournisseur personnalisée doivent traiter ce canal séparément. La politique des modèles hébergés par GitHub ne résout pas automatiquement la gouvernance d’un modèle local, d’une extension IDE ou d’un serveur MCP.

Le poste de développement cumule désormais plusieurs plans de contrôle : compte GitHub, configuration de l’éditeur, extensions, outils en ligne de commande et connexions externes. L’inventaire doit couvrir l’ensemble, sinon une règle stricte dans Copilot laissera une voie parallèle non surveillée.

Le changement du 26 août n’est pas une faille, mais un nouveau défaut opérationnel. Les équipes qui configurent clairement leur politique y gagnent en simplicité. Celles qui laissent l’état implicite risquent de découvrir après coup qu’un modèle est devenu accessible parce que personne n’avait choisi de le refuser.