Administrer Copilot : approbations, exclusions, modèle et Fable 5.1

Commencer par séparer les quatre réglages

Les annonces GitHub du 1er et du 2 septembre 2026 regroupent quatre décisions qui ne se pilotent ni au même niveau, ni avec les mêmes plans, ni sur les mêmes surfaces. Avant de modifier une politique, notez l’organisation, le dépôt, le plan, le client utilisé et l’état affiché dans l’interface. Une disponibilité annoncée ne prouve pas qu’elle est déjà déployée dans votre compte.

Réglage	État vérifié au 23 septembre 2026	Périmètre principal	Preuve à conserver
Approbations de pull requests	Public preview, désactivées par défaut	Plans payants ; entreprise, organisation et dépôt	Politique active, chemins autorisés et règle de merge
Exclusions de contenu	Généralement disponibles dans l’app et la CLI ; preview sur le site et mobile	Business et Enterprise ; app, CLI, IDE et code review selon la surface	Règle d’exclusion et test sur un dépôt non sensible
Modèle par défaut géré	Généralement disponible	Business et Enterprise ; app, CLI et VS Code	Réglage `model`, mapping d’équipe et modèle réellement affiché
Claude Fable 5.1	Généralement disponible, déploiement progressif	Pro+, Max, Business et Enterprise ; nombreuses surfaces, selon le rollout	Politique activée, plan, surface et condition de rétention

Cette matrice est une aide de cadrage, pas une garantie de couverture. La page des modèles pris en charge peut afficher un modèle alors qu’une version du client, une politique d’organisation ou le déploiement progressif ne le rend pas encore utilisable. Gardez donc la date et la surface dans chaque relevé.

Approvals de code review : une délégation bornée

Chaque revue Copilot comprend désormais une évaluation d’approbation dans son commentaire de synthèse. Cette évaluation indique que Copilot considère la pull request prête à être approuvée, mais elle ne satisfait pas à elle seule une exigence de merge. Il faut distinguer ce signal de l’approbation effectivement soumise par Copilot.

Les approbations sont en public preview, disponibles pour les plans Copilot Pro, Pro+, Max, Business et Enterprise, et désactivées par défaut. L’activation peut être encadrée à trois niveaux : l’entreprise peut laisser les organisations décider ou maintenir le réglage désactivé ; l’organisation peut l’activer partout, pour certains dépôts ou laisser les administrateurs de dépôt choisir ; le dépôt peut enfin autoriser ou refuser l’approbation et limiter les chemins concernés.

Le filtre de chemins doit rester explicite. La configuration documentée permet d’indiquer jusqu’à quinze globs ; pour qu’une approbation compte dans les exigences de merge, tous les fichiers modifiés doivent correspondre à l’un des chemins autorisés. Ce filtre ne remplace pas une règle de protection de branche : il réduit la portée de la délégation, mais ne vérifie pas la pertinence de la correction.

Commencez par un dépôt de test ou une pull request sans donnée sensible. Vérifiez séparément que l’évaluation apparaît, que Copilot ne soumet pas d’approbation lorsque la politique est désactivée, puis que l’approbation soumise est bien traitée comme telle uniquement lorsque l’option correspondante est activée. Ajoutez ensuite un commit : GitHub indique que l’approbation est alors retirée comme celle d’un relecteur humain et qu’une nouvelle revue doit être demandée.

Conservez une revue humaine, les tests du dépôt et les protections de branche, même lorsque Copilot peut compter dans le nombre d’approbations requis. Pour un dépôt contenant des migrations, des règles d’accès ou des changements de production, laissez la protection humaine en place et utilisez l’approbation automatique seulement sur une portée que votre équipe sait relire.

Exclusions de contenu : réduire le contexte sans promettre l’impossible

Les exclusions de contenu sont disponibles pour les organisations sous Copilot Business et Copilot Enterprise. Les administrateurs de dépôt, propriétaires d’organisation et propriétaires d’entreprise peuvent configurer les fichiers concernés. Selon la documentation GitHub, un fichier exclu ne fournit pas de contexte aux réponses Copilot, ne nourrit pas les suggestions inline et n’est pas relu par Copilot code review.

La surface compte toutefois. L’annonce du 2 septembre confirme le respect des exclusions par l’app Copilot et Copilot CLI. La documentation précise aussi que les exclusions s’appliquent à code review sur le site GitHub, tandis que le site et GitHub Mobile restent indiqués en public preview. Les modes Edit et Agent de Copilot Chat dans VS Code et d’autres éditeurs ne sont pas encore couverts par les exclusions. Une règle configurée dans l’organisation ne doit donc pas être décrite comme un filtre identique sur tous les clients.

Testez la règle avec un dépôt de démonstration et un marqueur inoffensif, jamais avec un secret réel. Relevez le dépôt, le chemin, l’organisation, le client, le mode et le résultat observé. Vérifiez que le fichier exclu n’est pas proposé comme contexte, puis contrôlez séparément le comportement de code review. Les liens symboliques et les dépôts situés sur des systèmes de fichiers distants font partie des limites documentées : leur présence doit être traitée comme une question à résoudre, pas comme une couverture implicite.

Une exclusion limite l’utilisation documentée du fichier dans certaines surfaces ; elle ne constitue ni un coffre-fort, ni une preuve de non-transmission par tous les chemins possibles, ni une politique universelle de confidentialité. Pour une donnée réellement sensible, la décision doit aussi préciser où elle est stockée, qui peut l’ouvrir et quelles surfaces Copilot sont autorisées.

Modèle par défaut géré : fixer un point de départ, pas un verrou universel

Les réglages gérés d’entreprise peuvent définir le modèle par défaut des nouvelles conversations pour Copilot Business et Copilot Enterprise. Le changelog du 2 septembre vise explicitement l’app Copilot, Copilot CLI et Visual Studio Code. Il ne transforme pas ce réglage en politique générale pour les comptes individuels, ni en choix imposé sur toutes les surfaces GitHub Copilot.

La clé documentée est model au niveau supérieur de managed-settings.json. Lorsqu’elle est marquée comme remplaçable, un mapping d’équipe peut fournir une spécialisation via team-mappings.json. Les autres utilisateurs héritent alors du défaut d’entreprise, tandis que l’équipe concernée peut recevoir son modèle prévu. Un réglage par défaut laisse par ailleurs la possibilité de sélectionner un autre modèle dans une conversation lorsque la politique le permet.

Avant de publier ce changement, consignez le modèle, sa version si elle est exposée, la surface, le plan et la règle d’équipe qui s’applique. Ne déduisez pas le modèle réellement utilisé du seul nom du réglage : vérifiez le sélecteur ou le relevé disponible dans le client. La page des modèles pris en charge distingue les modèles GA, les préversions et les surfaces ; elle doit être relue lorsque le client ou la politique change.

Fable 5.1 : la rétention est une condition d’accès

GitHub annonce Claude Fable 5.1 pour les utilisateurs Copilot Pro+, Max, Business et Enterprise, avec un déploiement progressif. L’annonce liste Visual Studio Code, Visual Studio, Copilot CLI, Copilot coding agent, l’app Copilot, github.com, GitHub Mobile, JetBrains, Xcode et Eclipse, mais précise que le modèle peut ne pas être visible immédiatement. Ne généralisez donc pas une présence observée dans un client à toute l’organisation.

Pour Copilot Business et Enterprise, un administrateur doit activer la politique Fable 5.1 ; elle est désactivée par défaut. GitHub indique que l’utilisation du modèle exige par défaut la conservation des prompts et des sorties par Anthropic afin d’exécuter ses classifieurs de sécurité. GitHub précise également que ces données conservées ne servent pas à entraîner les modèles Anthropic. Ce sont des conditions de service à relire, pas une promesse de confidentialité ni un avis juridique.

La page Anthropic sur les modèles couverts indique une conservation de trente jours des prompts et des sorties pour le travail de sécurité. Cette durée vient de la politique Anthropic générale ; l’administrateur doit vérifier qu’elle correspond bien au chemin GitHub et à l’accord applicable à son organisation avant de la présenter comme une durée contractuelle locale.

Certaines entreprises éligibles peuvent demander un accès temporaire à Fable 5.1 avec zéro rétention jusqu’à la fin de 2026, pendant le déploiement d’Enterprise Frontier Safeguards. L’éligibilité se vérifie auprès de l’équipe de compte GitHub ; l’approbation n’active pas automatiquement le modèle. Après approbation, un administrateur Business ou Enterprise doit encore activer la politique. Si l’organisation ne peut pas accepter la condition de rétention par défaut et ne dispose pas de l’exception approuvée, n’activez pas ce modèle sur cette base.

Valider à faible risque avant de généraliser

Préparez un dépôt de test distinct, sans secret, donnée client, clé d’accès ni branche de production. Écrivez la configuration actuelle avant toute modification, puis changez un seul réglage à la fois.

Approvals : utilisez une pull request volontairement simple, vérifiez l’évaluation puis l’approbation effective, contrôlez les globs et poussez un nouveau commit pour confirmer l’invalidation. Vérifiez que la règle de protection de branche et la revue humaine restent actives.
Exclusions : utilisez un fichier de démonstration sans valeur sensible, comparez une surface couverte et une surface en preview, puis notez les limites de mode ou de système de fichiers. Ne concluez pas à une exclusion universelle à partir d’un seul client.
Modèle géré : relevez le plan Business ou Enterprise, le client, la clé model, le mapping d’équipe et le modèle effectivement sélectionnable. Conservez la date du test et la page des modèles consultée.
Fable 5.1 : vérifiez le plan, le déploiement dans la surface visée, la politique administrateur et la condition de rétention. Si une exception ZDR est invoquée, conservez la preuve d’éligibilité et d’activation séparément.

La preuve utile est une capture ou un export de la politique, accompagnée du plan, de la surface, du dépôt ou de l’équipe et de la date. Elle ne doit pas contenir de secret. La méthode d’évaluation d’un outil IA aide à séparer l’annonce du fournisseur, l’observation locale et la validation humaine ; le guide sur la rétention et les réglages Copilot fournit le contexte distinct des politiques de Chat déjà annoncé ; le protocole d’évaluation de Copilot code review traite séparément l’observation des revues et ne remplace pas cette gouvernance.

Décider, puis prévoir le rollback

Une décision d’activation devrait nommer l’administrateur responsable, le périmètre, la preuve attendue et le signal qui déclenche un retour arrière. Pour les approbations, le rollback le plus lisible consiste à désactiver la capacité au niveau de l’entreprise, de l’organisation ou du dépôt, puis à conserver les exigences de revue humaine et de protection de branche. Pour un modèle géré, restaurez le dernier réglage documenté ou rendez le modèle non géré selon la politique de l’organisation ; ne supprimez pas le mapping d’équipe avant d’avoir conservé sa version précédente.

Pour Fable 5.1, désactivez la politique si la condition de rétention, l’éligibilité ou la surface ne correspond plus à la décision approuvée. Pour une exclusion, réexaminez la règle et son périmètre avant de la retirer : un retour arrière doit être volontaire, daté et testé sur le dépôt de démonstration. Dans tous les cas, un réglage revenu à son état précédent ne répare pas rétroactivement une donnée déjà traitée ; il borne seulement les usages à venir selon la politique que vous avez restaurée.

Sources et limites

Sources officielles consultées le 23 septembre 2026 : approbations de pull requests par Copilot ; documentation de Copilot code review et configuration officielle des revues ; exclusions de contenu et documentation des exclusions ; réglages gérés et clé model et schéma des réglages gérés ; Claude Fable 5.1 dans GitHub Copilot ; modèles Copilot pris en charge ; politique Anthropic de rétention des modèles couverts.

Les plans, surfaces, rollouts, préversions, politiques d’organisation et conditions de rétention peuvent évoluer après cette date. Ce guide propose une méthode d’administration et de validation à faible risque ; il ne constitue ni conseil d’achat, ni avis juridique, ni garantie de confidentialité, de sécurité ou de performance. Les approbations Copilot restent en public preview et ne remplacent pas une revue humaine ni les protections de branche.