Alexandre Chaimbault
Mode automatique selon l’appareil.

Rechercher

Nouveautés

Retrouve ici les dernières publications. L’abonnement aux notifications sera proposé après validation du canal.

Recevoir la newsletter Flux RSS

Articles de blog

GitHub Copilot : la politique globale de modèles devient disponible

GitHub déploie une politique globale de modèles pour Copilot Business et Enterprise. Voici ce qui change, ce qui est confirmé et les vérifications utiles.

Illustration éditoriale d’une politique centrale reliée à des cartes de modèles, avec application globale et héritage visuels.

Ce qui est confirmé

GitHub déploie progressivement une politique globale de modèles pour GitHub Copilot Business et GitHub Copilot Enterprise. L’annonce, publiée le 26 août 2026, précise que l’application commencée ce jour-là se poursuit jusqu’au 1er septembre. Le changement compte surtout pour les administrateurs qui n’ont pas encore configuré chaque modèle individuellement.

Le point important est simple : GitHub Copilot ne traite plus chaque nouveau modèle disponible comme un réglage isolé. Selon le changelog GitHub, les modèles généralement disponibles qui ne sont pas déjà configurés héritent désormais de l’état de la politique globale. GitHub parle d’un déploiement graduel, donc deux entreprises peuvent observer le changement à des moments différents.

Ce qui change dans la politique globale de GitHub Copilot

Fait : GitHub avait annoncé en juillet une politique de modèles par défaut pour les modèles GitHub Copilot généralement disponibles, sur les offres Business et Enterprise. Le changelog du 26 août indique que son application est déployée progressivement jusqu’au 1er septembre. Il ne s’agit donc pas d’une nouvelle famille de modèles annoncée aujourd’hui. Il s’agit d’une règle de gouvernance sur leur disponibilité.

Quand la politique prend effet pour une organisation ou une entreprise, les modèles qui n’avaient pas été configurés auparavant passent à l’état « Delegate to default policy ». Cet état suit la politique globale. Si cette politique est activée, ce qui est présenté comme le réglage par défaut, les modèles concernés deviennent disponibles pour les utilisateurs.

Le mot « déléguer » mérite attention. Il ne décrit pas une décision prise une fois pour toutes. GitHub précise que cet état est dynamique. Si l’administrateur modifie ensuite la politique globale, les modèles applicables suivent ce changement. Cette logique limite les réglages répétés modèle par modèle, mais elle augmente aussi l’importance du réglage central.

Fait : une décision explicite au niveau d’un modèle est conservée. Un modèle qu’un administrateur a volontairement activé ou désactivé ne doit pas être modifié par cette bascule. Avant toute modification, il faut donc séparer ce qui relève d’une préférence documentée et ce qui relève de l’absence de choix.

Les modèles qui ne suivent pas l’activation par défaut

La politique n’active pas tous les modèles sans distinction. GitHub exclut de l’activation par défaut les modèles à poids ouverts, avec comme exemples DeepSeek et Kimi K2. Le changelog exclut aussi les modèles qui ne sont pas couverts par l’accord de conservation des données de GitHub, dont Fable 5 est donné comme exemple.

Fait : ces exclusions s’appliquent même si la politique globale est activée. Ce détail évite une lecture trop rapide de la règle. Une politique activée ne signifie pas que chaque option visible ou future est disponible pour l’ensemble des collaborateurs.

Concrètement, un administrateur ne peut pas déduire la disponibilité d’un modèle à partir du seul statut général de Copilot. Il doit regarder le statut attribué au modèle concerné et le cadre de données qui lui est associé. La source ne détaille pas la configuration contractuelle de chaque organisation. Elle ne donne pas non plus une liste exhaustive de tous les modèles concernés.

Pour suivre les changements autour de Copilot, tu peux consulter mes actualités et mon suivi de Copilot, modèles, plugins et agents en août 2026. Ces liens servent de contexte éditorial. Ils ne remplacent pas la vérification de tes propres réglages dans GitHub.

Les quatre états à connaître après le déploiement

Après le déploiement, GitHub indique qu’un modèle affiche l’un de quatre états dans les réglages. Les connaître aide à lire la configuration sans supposer qu’un modèle est actif ou bloqué.

  • « Enabled » signifie que le modèle a été activé explicitement.
  • « Disabled » signifie que le modèle a été désactivé explicitement.
  • « Delegate to enterprise teams/apps or organizations » signifie que le modèle suit un réglage hérité d’une équipe, d’une application ou d’une organisation de l’entreprise.
  • « Delegate to default policy » signifie que le modèle suit la politique d’activation par défaut.

Fait : GitHub présente ces quatre états comme les statuts visibles après le déploiement. L’état affiché est donc une information de gouvernance. Il permet de savoir si la disponibilité provient d’un choix direct, d’un héritage organisationnel ou de la politique globale.

Analyse : la différence entre « explicitement activé » et « suit la politique par défaut » est utile au moment d’un audit. Deux modèles peuvent être disponibles au même instant, tout en ayant une logique de gouvernance différente. Le premier demandera un changement local pour être retiré. Le second suivra le prochain changement de politique globale, si aucune exception explicite n’est créée.

Pourquoi c’est important

Si tu travailles avec JetBrains, tu peux rapprocher ce sujet de mon article sur les réglages GitHub Copilot gérés en entreprise dans JetBrains. Pour une vision plus large des environnements encadrés, j’ai aussi publié un point sur GitHub Enterprise Server 3.22, Copilot CLI et les environnements isolés. Ce sont des pistes de lecture internes, pas une confirmation supplémentaire de l’annonce du 26 août.

Ce qui est confirmé et ce qui reste inconnu

Fait confirmé : l’application de la politique globale commence le 26 août et le déploiement est annoncé jusqu’au 1er septembre. Fait confirmé : les modèles non configurés et généralement disponibles héritent de la politique globale. Fait confirmé : les choix explicites existants sont préservés.

Fait confirmé : les modèles à poids ouverts et ceux qui exigent une conservation des données ne sont pas activés par défaut dans ce mécanisme. GitHub cite DeepSeek, Kimi K2 et Fable 5 pour illustrer ces catégories. La source ne dit pas que ces modèles sont retirés de GitHub Copilot. Elle dit qu’ils sont exclus de l’activation par défaut.

Reste inconnu dans cette annonce : la date exacte à laquelle chaque entreprise verra le changement. GitHub indique seulement que le déploiement est graduel. Reste également inconnu, à partir de cette seule source, le nombre de modèles touchés dans une organisation donnée, leur utilisation réelle ou leur effet sur les coûts, la productivité ou la qualité du code.

Cette distinction compte. Je ne confonds pas une règle de disponibilité avec une mesure d’usage. L’annonce ne fournit ni volume d’utilisateurs, ni métrique d’adoption, ni résultat opérationnel. Si ton équipe utilise Copilot pour développer, tu ne peux pas attribuer une évolution de livraison à cette politique sans mesures internes, prises avant et après le changement.

Ce que ça change pour toi

Analyse : si tu administres GitHub Copilot Business ou Enterprise, le premier réflexe utile est de relire la politique globale avant le 1er septembre, puis de vérifier les modèles qui doivent rester explicitement activés ou désactivés. Le changement de GitHub rend l’absence de réglage active dans la gouvernance. Une configuration laissée en attente peut désormais suivre le choix global.

En pratique, je te conseille de traiter cette étape comme un contrôle de périmètre, pas comme une migration technique lourde. Commence par identifier les modèles avec un choix explicite. Distingue-les de ceux qui délèguent à une équipe, une organisation ou la politique par défaut. Vérifie ensuite les exceptions liées aux modèles à poids ouverts et à la conservation des données.

Ce n’est pas une instruction officielle de GitHub. C’est mon analyse de la mécanique décrite dans le changelog. Elle vise à rendre visible ce qui est automatique et ce qui dépend encore d’une décision humaine. Si tu n’as pas les droits d’administration, demande à la personne responsable quel état est appliqué, plutôt que de conclure à partir de ce que tu vois dans ton interface.

Pour les créateurs, freelances et petites équipes, le signal est plus large. Les outils d’IA intégrés au développement ont besoin de règles compréhensibles lorsque les modèles changent. La productivité ne vient pas seulement de l’accès à une option. Elle dépend aussi de savoir qui l’active, sur quel périmètre, et selon quelles contraintes de données.

Tu peux prolonger cette réflexion avec mon article sur l’IA pour les entrepreneurs et créateurs ou mon retour sur l’automatisation d’un business en ligne. L’objectif est de garder une IA utile dans un processus clair, et non d’ajouter un outil sans responsabilité identifiée.

Une vérification simple avant de changer un réglage

Fait : GitHub indique que les modèles non configurés passent vers un état qui délègue à la politique par défaut. Fait : les décisions explicites sont préservées. À partir de là, la vérification la plus prudente consiste à documenter l’état actuel de chaque modèle avant toute décision.

Je procéderais ainsi : relever l’état affiché, noter le niveau dont il dépend, puis décider si cet héritage est souhaité. Pour un modèle « Enabled » ou « Disabled », il faut savoir qu’il correspond à un choix explicite. Pour un modèle en délégation, il faut identifier la politique dont il dépend. Cette méthode ne remplace pas les procédures de sécurité de ton entreprise. Elle évite simplement de confondre une disponibilité héritée avec une autorisation choisie modèle par modèle.

Analyse : cette annonce peut aussi servir de rappel pour clarifier qui détient la responsabilité de Copilot. Sans propriétaire de politique, le réglage global risque de devenir une décision implicite. À l’inverse, une politique globale documentée peut réduire les incohérences entre équipes, à condition que les exceptions soient elles aussi suivies.

Ce que cela change

Mon avis

À mon avis, le changement est utile parce qu’il rend la logique d’héritage plus lisible. Je préfère une règle centrale que l’on peut examiner à une accumulation de réglages oubliés. Je resterais prudent sur l’idée que cette annonce améliore automatiquement la productivité ou la sécurité. La source confirme un mécanisme de politique, pas ses résultats dans ton entreprise.

Je suivrai aussi le point soulevé par GitHub : l’entreprise évalue la possibilité de rendre la politique globale explicite et de supprimer l’état « Delegate to default policy ». À ce stade, ce n’est pas un changement annoncé comme acquis. GitHub invite les utilisateurs à donner leur avis dans une discussion communautaire.

FAQ

Quand la politique globale de modèles GitHub Copilot entre-t-elle en vigueur ?

GitHub a annoncé le 26 août 2026 le début d’un déploiement graduel de l’application de la politique. Selon le changelog officiel, il se poursuit jusqu’au 1er septembre et peut donc arriver à des moments différents selon les entreprises.

Quels modèles GitHub Copilot suivent la politique globale ?

Les modèles généralement disponibles que l’organisation n’a pas déjà configurés suivent la politique globale. GitHub précise qu’ils passent à l’état « Delegate to default policy » lorsque le mécanisme prend effet.

Un modèle désactivé manuellement peut-il être réactivé par la politique globale ?

Non, d’après l’annonce. GitHub indique qu’un choix explicite d’activation ou de désactivation pour un modèle est préservé. La politique globale concerne les modèles qui n’étaient pas configurés individuellement.

Les modèles à poids ouverts sont-ils activés automatiquement dans GitHub Copilot ?

Non. GitHub indique que les modèles à poids ouverts, avec DeepSeek et Kimi K2 comme exemples, sont exclus de l’activation par défaut. Cela ne permet pas de conclure, à partir de cette seule annonce, à leur disponibilité dans chaque organisation.

Fable 5 suit-il la politique globale de GitHub Copilot ?

GitHub cite Fable 5 comme exemple de modèle non couvert par son accord de conservation des données. Ces modèles sont exclus de l’activation par défaut, même lorsque la politique globale est activée.

Information & avertissement

Cet article résume une annonce officielle de GitHub publiée le 26 août 2026. Il ne remplace ni la documentation GitHub, ni les règles de sécurité, de conformité ou de gestion des données de ton organisation. Avant de modifier une politique Copilot, vérifie les réglages et les droits applicables dans ton environnement.

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.

Sources

  1. github.blog