Entre le 26 août et le 2 septembre 2026, GitHub a fait évoluer plusieurs mécanismes de gouvernance de Copilot : politique globale de disponibilité des modèles, retrait de modèles sélectionnés, prise en compte des exclusions de contenu dans l’application et la CLI, puis définition d’un modèle par défaut au niveau de l’entreprise ou de l’équipe. Pris séparément, ces changements ressemblent à des réglages d’administration. Ensemble, ils montrent que le choix d’un modèle devient un sujet de portefeuille, de données et de continuité opérationnelle.
À retenir : autoriser « Copilot » ne suffit plus. Une organisation doit décider quels modèles sont disponibles, pour quelles équipes, sur quelles données, avec quelles garanties et jusqu’à quelle date. Les valeurs héritées par défaut doivent être distinguées des décisions explicites, et chaque retrait de modèle doit déclencher des tests de non-régression.
1. Pourquoi le multi-modèles change la gouvernance
Un assistant de code était initialement perçu comme un produit relativement homogène : une interface, un fournisseur et une politique centrale. Les plateformes proposent désormais plusieurs modèles, parfois issus d’éditeurs différents, avec des caractéristiques de coût, de performance, de licence et de traitement des données distinctes.
Le modèle intervient dans des contextes variés : complétion locale, conversation, édition multi-fichiers, agent autonome, revue de code ou CLI. Une autorisation adaptée à la rédaction d’un test ne l’est pas nécessairement pour un agent qui explore un dépôt, exécute des commandes et propose une pull request.
Cette diversité apporte de la souplesse. Une équipe peut utiliser un modèle rapide pour les interactions courantes et un modèle plus avancé pour une migration complexe. Mais elle crée aussi des décisions implicites. Un nouveau modèle peut devenir accessible parce qu’il hérite d’une politique globale ; un modèle favori peut disparaître ; un réglage de confidentialité peut être appliqué dans l’IDE mais pas encore dans une autre surface.
La gouvernance doit donc porter sur la combinaison modèle + fonctionnalité + données + équipe + version, et non sur le nom du produit seul.
2. Comprendre les quatre états de politique GitHub
GitHub a annoncé le 26 août la disponibilité générale de sa politique globale pour les modèles Copilot, avec un déploiement progressif jusqu’au 1er septembre. Les modèles généralement disponibles qui n’avaient pas été configurés explicitement peuvent suivre l’état de cette politique.
L’administration distingue quatre situations : activé explicitement, désactivé explicitement, délégué à une équipe ou organisation, et délégué à la politique par défaut. Cette dernière valeur est dynamique : si la politique globale change, tous les modèles qui la suivent changent avec elle.
La nuance est essentielle pour l’audit. Deux modèles visibles comme disponibles peuvent provenir de décisions très différentes. Le premier a été évalué et activé ; le second est apparu par héritage. Il faut donc enregistrer l’origine de la décision et ne pas considérer l’état effectif comme une preuve d’approbation.
GitHub précise que les choix explicites sont préservés. Il indique aussi que les modèles à poids ouverts et ceux qui ne sont pas couverts par son accord de conservation des données sont désactivés par défaut dans ce mécanisme. Cette protection constitue un point de départ, pas une politique complète : l’organisation doit toujours vérifier les conditions applicables, les régions, les fonctionnalités et ses propres engagements clients.
Une bonne pratique consiste à désactiver l’activation automatique dans les périmètres sensibles et à exiger une décision explicite pour chaque nouveau modèle. Dans les environnements moins critiques, l’héritage peut rester autorisé avec une revue automatique et une notification aux propriétaires.
3. Traiter la confidentialité au niveau du contenu
Le 2 septembre, GitHub a annoncé que l’application Copilot et Copilot CLI respectaient désormais les politiques d’exclusion de contenu configurées aux niveaux entreprise, organisation et dépôt pour les offres Business et Enterprise. Les fichiers exclus ne doivent pas être utilisés comme contexte dans ces workflows.
Cette fonction permet de protéger des secrets, du code sous contrainte contractuelle, des données propriétaires ou des répertoires dont l’utilisation par un assistant n’est pas autorisée. Elle ne remplace toutefois pas les contrôles d’accès. Un développeur ou un agent qui peut lire un fichier demeure susceptible de le copier dans une autre surface, de le résumer manuellement ou de l’exposer à un outil externe.
L’exclusion doit donc s’inscrire dans une stratégie plus large : classification des dépôts, séparation des secrets, règles DLP, permissions minimales et journalisation. Elle doit aussi être testée sur chaque interface. Une politique annoncée pour l’application et la CLI ne doit pas être supposée identique dans toutes les extensions, intégrations ou API.
Documentez ce que signifie « exclu ». La question n’est pas seulement de savoir si le contenu entre dans le prompt. Vérifiez les suggestions, index, caches, journaux, traces d’évaluation et éventuelles fonctions de mémoire. Les contrats et documentations éditeur restent la source de vérité.
Notre article sur le Zero Data Retention et le Private Safety Processing détaille cette distinction entre conservation, entraînement, journalisation et contrôles de sécurité.
4. Préparer les dépréciations comme des migrations
Le 31 août, GitHub a annoncé la dépréciation de plusieurs modèles à compter du 1er septembre dans la plupart des expériences Copilot. La liste concernait notamment des versions Gemini, Claude et Raptor Mini, avec des alternatives suggérées.
Le délai très court montre qu’un nom de modèle ne doit pas être codé en dur sans stratégie de remplacement. Une équipe qui utilise un modèle dans des instructions, automatisations, évaluations ou paramètres d’entreprise peut subir une rupture ou un changement silencieux de comportement.
Traitez chaque retrait comme une migration applicative. Inventoriez les usages, choisissez un candidat, rejouez les évaluations, mesurez la qualité et vérifiez les coûts. Les prompts peuvent dépendre d’un style de raisonnement, d’une fenêtre de contexte ou d’un format de sortie. Remplacer un modèle par « le plus proche » ne garantit pas l’équivalence.
Ajoutez une couche logique entre le cas d’usage et le nom commercial. Par exemple, le profil code-review-standard pointe vers un modèle approuvé avec une configuration donnée. Le changement de fournisseur ou de version est réalisé dans le registre, sans modifier tous les workflows.
Surveillez les calendriers, mais préparez aussi le remplacement non planifié. Un modèle peut être retiré pour des raisons de sécurité, de licence ou de disponibilité. Chaque usage critique doit posséder une solution de repli testée et un mode dégradé explicite.
5. Définir des modèles par équipe sans fragmenter l’organisation
Le 2 septembre, GitHub a annoncé la possibilité de définir un modèle par défaut dans les paramètres gérés par l’entreprise, avec des valeurs différentes selon les équipes, pour l’application Copilot, la CLI et Visual Studio Code sur les offres Business et Enterprise.
Cette granularité est utile. Une équipe PHP peut privilégier un modèle performant sur ses dépôts et ses tâches ; une équipe de support peut rechercher vitesse et coût ; une équipe sécurité peut exiger un modèle et une politique plus restrictifs.
Le risque est la fragmentation. Si chaque équipe choisit sans cadre, l’entreprise ne sait plus quels modèles traitent ses données, les évaluations se multiplient et les incidents deviennent difficiles à reproduire.
Définissez un catalogue court. Deux ou trois profils couvrent généralement la majorité des besoins : interaction rapide, raisonnement complexe et contexte sensible. Les équipes demandent une exception lorsqu’elles démontrent un besoin mesurable. L’exception possède un propriétaire, une date d’expiration et un jeu d’évaluation.
Le modèle par défaut n’est pas nécessairement le seul autorisé. Il représente le choix recommandé. La possibilité de le remplacer par l’utilisateur dépend du niveau de risque. Sur un dépôt public, la liberté peut être large ; sur un produit réglementé, le modèle et la surface peuvent être imposés.
6. Construire un registre de modèles et de cas d’usage
Le registre constitue la source de vérité. Pour chaque modèle, conservez le fournisseur, la version, le statut GitHub, les surfaces disponibles, la politique de données, les régions, le coût, la date d’introduction, la date de révision et le propriétaire interne.
Reliez ensuite les cas d’usage : complétion, chat, agent, CLI, revue, génération de tests ou migration. Ajoutez la classification des données, le niveau d’autonomie, les outils accessibles, le modèle par défaut et le modèle de repli.
Une ligne de registre pourrait indiquer : « revue automatique de dépôts internes non réglementés ; modèle A ; suggestions uniquement ; contenu secret exclu ; approbation humaine obligatoire ; évaluation mensuelle ; repli vers modèle B ».
Ce registre doit être versionné. Un fichier lisible par machine permet de générer les paramètres gérés, les tableaux d’audit et les alertes de dépréciation. Les changements passent par une pull request approuvée par les responsables plateforme, sécurité et métier lorsque nécessaire.
Évitez néanmoins de faire du registre un catalogue théorique. Chaque entrée active doit correspondre à un usage observé. Les modèles non utilisés augmentent la surface de gouvernance sans créer de valeur.
7. Tester la qualité, le coût et le risque avant activation
Un benchmark général ne suffit pas pour choisir un modèle de développement. Construisez un jeu d’évaluation à partir de tâches réelles et anonymisées : correction ciblée, compréhension d’un module, génération de test, migration, revue de sécurité et respect des conventions.
Mesurez le taux de réussite, les défauts introduits, la qualité de l’explication, les appels d’outils, le coût et la latence. Vérifiez le comportement face à une instruction présente dans le dépôt, un fichier exclu, un secret factice et une demande hors périmètre.
Pour les agents, ajoutez des critères d’action : respecte-t-il la branche, les fichiers autorisés, les commandes et les limites ? Le meilleur modèle en génération de code n’est pas nécessairement le plus contrôlable dans un workflow autonome.
Rejouez le jeu à chaque nouvelle version ou changement de surface. Une mise à jour GitHub peut modifier l’orchestration autour du modèle, même lorsque le modèle reste identique. Conservez les résultats et les configurations afin d’expliquer une évolution de qualité.
L’activation suit un déploiement progressif : équipe pilote, dépôts sélectionnés, observation, puis généralisation. Les incidents et retours utilisateurs alimentent le registre et peuvent entraîner un retour au modèle précédent.
8. Mettre en place un cycle de gouvernance trimestriel
Chaque trimestre, examinez la liste des modèles disponibles, les décisions héritées, les exclusions, les usages réels, les coûts et les dates de retrait annoncées. Désactivez les modèles non utilisés et renouvelez uniquement les exceptions justifiées.
Chaque mois, surveillez les changelogs des fournisseurs et de GitHub. Un changement matériel déclenche une analyse sans attendre la revue trimestrielle. L’automatisation peut ouvrir un ticket lorsqu’un nom du registre apparaît dans une annonce de dépréciation.
Avant chaque activation, exigez une fiche courte : besoin, données, surfaces, évaluation, coût, repli et propriétaire. Après activation, vérifiez que les paramètres effectifs correspondent au registre. L’écart entre politique déclarée et configuration réelle est un indicateur prioritaire.
Enfin, communiquez aux développeurs. Expliquez pourquoi certains modèles sont disponibles, comment signaler un problème et quelle information ne doit jamais être fournie à l’assistant. Une gouvernance compréhensible obtient davantage d’adhésion qu’une liste de restrictions sans contexte.
Conclusion
La multiplication des modèles dans GitHub Copilot apporte une capacité d’adaptation utile, mais elle transforme un réglage de productivité en système à gouverner. Les politiques globales, exclusions de contenu, valeurs par équipe et dépréciations doivent être traitées ensemble.
Une organisation robuste conserve un registre versionné, explicite l’origine des décisions, évalue les modèles sur ses tâches, prépare les remplacements et vérifie les protections de données sur chaque surface. Partitech accompagne la conception de cette gouvernance, l’automatisation des contrôles et l’intégration de Copilot dans une démarche DevSecOps mesurable.
Références vérifiées le 3 septembre 2026
- GitHub — « Global model policy generally available », 26 août 2026 : https://github.blog/changelog/2026-08-26-global-model-policy-generally-available/
- GitHub — « Selected GitHub Copilot models deprecated », 31 août 2026 : https://github.blog/changelog/2026-08-31-selected-github-copilot-models-deprecated/
- GitHub — « Content exclusions generally available in Copilot app and CLI », 2 septembre 2026 : https://github.blog/changelog/2026-09-02-content-exclusions-generally-available-in-copilot-app-and-cli/
- GitHub — « Enterprise-managed settings support any default model », 2 septembre 2026 : https://github.blog/changelog/2026-09-02-enterprise-managed-settings-support-any-default-model/