Forfaits GitHub Copilot : guide complet des fonctionnalités et de l’administration selon les paliers

Aperçu des forfaits GitHub Copilot

GitHub propose plusieurs paliers distincts dans son écosystème. Notamment, la plateforme finalise la bascule vers une facturation à l’usage, remplaçant l’ancien cadre « Premium Request Unit » (PRU) par les GitHub AI Credits en juin 2026.

Dans le nouveau système, les complétions de code de base et les suggestions « Next Edit » restent illimitées et ne consomment pas de crédits. 

En revanche, les opérations avancées comme le chat multi-fichiers, les workflows agents, les sessions de codage longues et les revues de code approfondies consomment des AI Credits selon les jetons utilisés (entrée, sortie et tokens en cache) au regard des tarifs API publiés pour chaque modèle. 

Les prix d’abonnement mensuels de base restent inchangés, mais ce changement modifie la façon dont les administrateurs budgètent les dépassements et surveillent l’usage effectif.

Offres individuelles : Free, Student, Pro et Pro+

Les paliers individuels se distinguent par l’accès aux modèles, les limites d’usage et les fonctionnalités expérimentales. Par exemple, si le palier Free convient pour découvrir l’outil, Pro+ donne accès à GitHub Spark, un environnement conçu pour créer des applications assistées par l’IA.

Actuellement, les nouvelles inscriptions aux comptes payants individuels de GitHub, comme Pro, Pro+ et Student, sont en pause. Les comptes existants peuvent passer de Pro à Pro+, mais les nouveaux comptes ne peuvent pas s’abonner avant la fin de la transition vers la facturation à l’usage par AI Credits.

Business et Enterprise

Avec Business et Enterprise, les forfaits GitHub Copilot passent d’une simple extension IDE à un actif d’infrastructure d’entreprise entièrement auditable.

GitHub Copilot Business introduit des capacités de gestion essentielles :

• Attribution et révocation centralisées des licences.
• Politiques de référence à l’échelle de l’organisation.
• Journaux d’audit structurés et suivi des événements de conformité.
• Exclusions de contenu et de fichiers de dépôts.
• Indemnisation commerciale en propriété intellectuelle.

GitHub Copilot Enterprise va encore plus loin en termes de contrôle et de capacités :

• Copilot Spaces : un espace de connaissance permettant d’interroger Copilot sur la documentation interne, les wikis et les référentiels de standards de code.
• Intégration renforcée à GitHub.com Chat.
• Héritage hiérarchique des politiques entre organisations filles.

GitHub Copilot Enterprise requiert un abonnement actif à GitHub Enterprise Cloud. GitHub Enterprise Cloud coûte 21 $ par utilisateur et par mois et la licence Copilot Enterprise 39 $ par utilisateur et par mois : le coût minimal réel est donc de 60 $ par utilisateur et par mois pour Enterprise. Cela ne s’applique pas à GitHub Copilot Business, que les organisations peuvent acheter directement si elles utilisent GitHub Free ou GitHub Team.

Les organisations n’auront pas les avantages Enterprise comme l’héritage des politiques, mais bénéficieront tout de même de l’indemnité PI, de l’audit, des exclusions de fichiers et de la gestion des politiques : une bonne alternative pour des équipes de développement de taille moyenne.

Si vous envisagez un abonnement Enterprise, notre guide GitHub Copilot Enterprise vous montrera comment exploiter ses fonctionnalités, comme Copilot Spaces et la nouvelle Usage Metrics API.

Ce qui distingue les offres individuelles des offres Business

La gestion des données, l’indemnité PI et la facturation sont les principaux domaines où les offres individuelles et Business diffèrent fortement. Les fonctionnalités supplémentaires pour les utilisateurs sont appréciables, mais comprendre ces écarts est clé pour choisir entre gérer un empilement de licences Pro personnelles et un abonnement Business.

Gestion des données et valeurs par défaut d’entraînement

Pour les équipes qui manipulent des systèmes propriétaires, la confidentialité des données est généralement le facteur décisif entre des offres personnelles et un abonnement Business.

En avril 2026, GitHub a modifié la collecte des données d’interaction pour les offres individuelles de Copilot. Pour les utilisateurs Free, Pro et Pro+, les données d’interaction peuvent désormais être utilisées par défaut pour entraîner les modèles, sauf si l’utilisateur se désactive explicitement.

Faisons bien la différence entre le code au repos et les données d’interaction, afin de savoir ce qui est utilisé pour l’entraînement :

• Code au repos : le code brut présent dans votre dépôt privé n’est ni lu ni intégré dans des jeux d’entraînement publics.
• Données d’interaction : incluent les invites, requêtes de chat, contexte du curseur, blocs de code environnants envoyés via l’API de l’IDE pendant l’édition, les taux d’acceptation des suggestions et les journaux de feedback.

Les contrats Business et Enterprise garantissent strictement que les données d’interaction ne sont jamais utilisées à des fins d’entraînement, en toutes circonstances. Aucune action manuelle de l’utilisateur n’est requise.

Pour approfondir l’usage des données et savoir comment résoudre les problèmes dans Copilot, consultez notre guide GitHub Copilot Privacy and Troubleshooting.

Indemnité PI

GitHub Copilot Business et Enterprise incluent une indemnité en propriété intellectuelle (PI) pour le code généré. Les offres individuelles n’en proposent pas.

Concrètement, l’indemnité signifie que GitHub s’engage contractuellement à fournir une protection juridique dans des circonstances précises si le code généré crée des litiges de propriété intellectuelle. Cela n’élimine pas tout risque juridique, mais change la discussion sur la responsabilité pour les équipes logicielles commerciales.

Les indépendants qui livrent du code à des clients doivent y prêter attention. La différence entre « outil de productivité personnel » et « plateforme de développement soutenue par une organisation » devient très concrète dès qu’il y a des contrats et des livraisons commerciales.

Facturation, licences et passage aux AI Credits

La facturation individuelle est en libre-service et liée directement aux comptes personnels. Les offres Business centralisent la facturation avec des licences attribuées par les administrateurs. De plus, au lieu que chaque utilisateur consomme un lot de crédits indépendant, l’organisation mutualise ses AI Credits mensuels selon le nombre d’utilisateurs.

Les offres Enterprise vont plus finement avec des limites budgétaires granulaires, des regroupements par centres de coûts et des allocations par département afin qu’une équipe unique, gourmande en workflows agents, n’épuise pas tout le crédit mensuel de l’entreprise.

SKUs et considérations de confidentialité

Comprendre les différentes protections de confidentialité des données et les SKUs est important. Les frontières architecturales qui régissent les flux de données, les protections juridiques et le suivi selon les paliers sont résumées ci-dessous :

Changements de politique d’entraînement en avril 2026

Le passage d’un modèle en opt-in à un modèle en opt-out pour les offres individuelles met en évidence un vecteur majeur de fuite de conformité. La charge utile de données d’interaction capturée automatiquement lors d’une session IDE active inclut :

• Historique de chat détaillé et contexte des invites.
• Suggestions de code multi-lignes et taux d’acceptation locaux.
• Contexte du curseur dans l’éditeur, qui récupère fréquemment le contexte de fichiers adjacents, les imports et déclarations de variables des onglets ouverts.

Imaginez qu’un développeur utilise un compte Copilot Pro personnel tout en travaillant dans un dépôt de l’entreprise. Si l’entraînement reste activé, les données d’interaction liées à cette session peuvent entrer dans l’écosystème d’entraînement de GitHub. C’est une raison fréquente d’adopter les offres Business.

Choisir le bon SKU selon vos exigences de confidentialité

Selon la nature des travaux, vous pouvez avoir besoin de SKUs différents. 

• Développeur solo/projets personnels : les paliers Free ou Pro offrent une flexibilité maximale. Désactivez simplement l’option dans vos paramètres de confidentialité si vous travaillez sur du code propriétaire.
• Freelances/contractuels : le forfait Business offre une protection défensive. Les contrats clients interdisent souvent explicitement l’envoi de données à des fournisseurs de LLM externes ; une licence dédiée au sein de l’organisation protège vos engagements.
• Équipes d’entreprise avec obligations de conformité : le palier Business constitue la base, garantissant l’isolement des flux de données et la gouvernance administrative.
• Secteurs réglementés (finance, santé) : le palier Enterprise est généralement requis, avec intégration à des configurations de sécurité spécifiques, résidences de données strictes et couches d’ajustement fin localisées.

Exclure des fichiers spécifiques de Copilot

La mise en place de règles d’exclusion de fichiers dans GitHub Copilot est l’un des moyens les plus efficaces de sécuriser un environnement de manière défensive. L’exclusion de contenu empêche l’agent IDE local de traiter certains fichiers, qui deviennent invisibles pour les complétions inline, les chats et les opérations agents en arrière-plan. 

Notez que GitHub Copilot CLI, l’agent cloud Copilot et le mode Agent dans Copilot Chat dans les IDE ne prennent pas en charge l’exclusion de contenu.

Configurer des règles d’exclusion

Les équipes d’administration peuvent appliquer des exclusions soit dans les paramètres globaux de l’organisation, soit au niveau d’un dépôt donné. Il suffit d’ouvrir les paramètres du dépôt ou de l’organisation via le bouton Settings en haut à droite.

Dans la barre latérale, sous Copilot, choisissez « Code and automation ». Renseignez ensuite vos exclusions dans la zone « Paths to exclude in this repository » comme suit :

# Ignore the /src/some-dir/kernel.rs file in this repository.
- "/src/some-dir/kernel.rs"

# Ignore files called secrets.json anywhere in this repository.
- "secrets.json"

# Ignore all files whose names begin with secret anywhere in this repository.
- "secret*"

# Ignore files whose names end with .cfg anywhere in this repository.
- "*.cfg"

# Ignore all files in or below the /scripts directory of this repository.
- "/scripts/**"

Le niveau organisation + dépôts est similaire, sauf que le réglage se trouve sous « Repositories and Paths to exclude » en utilisant le format suivant :

REPOSITORY-REFERENCE:
  - "/PATH/TO/DIRECTORY/OR/FILE"
  - "/PATH/TO/DIRECTORY/OR/FILE"
  - …

Conserver la clé REPOSITORY-REFERENCE est important. Les bases de configuration à privilégier portent sur les identifiants sensibles, les profils d’orchestration de production, les modules algorithmiques propriétaires sensibles ou les dossiers à forte exigence réglementaire.

Application des exclusions dans Copilot

Lorsqu’une exclusion correspond, l’isolation des données est absolue dans tous les sous-systèmes de Copilot :

• Complétions inline : impossibilité de générer du contexte dans le fichier ou d’y puiser du contexte pour renseigner des fichiers adjacents.
• Copilot chat/agents : le système renvoie un message indiquant que le fichier ne peut pas être analysé pour des raisons de politique organisationnelle.

Les moteurs IDE locaux standard fonctionnent normalement. Les outils de confort comme l’analyse de texte, la coloration syntaxique et l’IntelliSense locale compilent comme d’habitude, car la couche d’exclusion de fichiers s’applique explicitement aux flux de télémétrie externes de Copilot. 

Les administrateurs doivent tester minutieusement les motifs de chemin dans des dépôts de préproduction ; des jokers mal formés peuvent échouer en ouverture et exposer des données que vous souhaitiez isoler.

Gestion des politiques à l’échelle de l’organisation

L’application de politiques GitHub Copilot au niveau de l’organisation garantit que la sécurité d’entreprise est définie par l’équipe d’administration et non par les préférences individuelles des développeurs.

Paramètres de politique disponibles

Les organisations peuvent contrôler plusieurs réglages pour les développeurs :

• Activation de fonctionnalités : activer ou bloquer globalement Copilot Chat dans les environnements de développement, les interfaces en ligne de commande (via Copilot CLI) ou les systèmes avancés de revue de code par agents.
• Filtre de code public : contrôle légal qui empêche Copilot de proposer des suggestions trop proches de dépôts open source publics sur GitHub, réduisant les risques liés aux licences open source.
• Restrictions de choix de modèle : limiter les modèles (par ex., variantes GPT ou Claude) que les développeurs peuvent sélectionner pour maîtriser latence, consommation de crédits et performances. Pour un aperçu des modèles disponibles sur la plateforme de GitHub, consultez ce guide pratique sur les GitHub Models.
• Instructions personnalisées d’organisation : injecter des fichiers markdown standard qui ajoutent à chaque invite les patterns de code, cadres de sécurité et paradigmes architecturaux de l’entreprise.

Si votre équipe est moins familière avec le modèle d’organisation et d’autorisations de GitHub, le cours Intermediate GitHub Concepts fournit un bon contexte. Pour les équipes qui déploient des outils en ligne de commande, consultez notre GitHub Copilot CLI Tutorial.

Héritage des politiques au niveau Enterprise

Dans les grands environnements, le moteur de politiques suit une cascade d’héritage stricte : politique Enterprise > politique d’organisation > préférences utilisateur

Les administrateurs Enterprise peuvent verrouiller des politiques globalement pour tous les unités métier, autoriser des dérogations sélectives par organisation ou déléguer totalement le contrôle. Par exemple, l’Enterprise peut imposer des réglages globaux sur l’usage de certains modèles.

Au niveau équipe, on peut restreindre la division services financiers avec des filtres de code public stricts tout en laissant à une division R&D interne plus de latitude pour expérimenter.

Journaux d’audit

Lorsque les auditeurs de conformité exigent des preuves sur votre chaîne d’approvisionnement logicielle, ou quand les équipes sécurité traquent une fuite de données, GitHub Copilot journalise les modifications de la plateforme.

Événements Copilot dans le journal d’audit

Le système enregistre un registre complet des opérations d’administration, notamment :

• Attributions, révocations de licences et changements de groupes de facturation.
• Modifications du filtre de duplication de code public.
• Évolutions des motifs d’exclusion de fichiers et répertoires.
• États d’activation des fonctionnalités (ex. activation des modes de revue de code par agents).

Le niveau de granularité dépend de votre abonnement. Les paliers Business couvrent les événements au périmètre de l’organisation, tandis que les comptes Enterprise donnent accès à une télémétrie forensique inter-organisations.

Recherche, filtrage et export

Les flux de journaux d’audit sont consultables nativement via le panneau Organization Settings. Les administrateurs peuvent interroger l’interface avec des qualificatifs d’action spécifiques :

# Filter logs to identify who adjusted Copilot access privileges
action:copilot.cfb_seat_assignment_created

# Identify changes made to systemic exclusions within a date window
action:copilot.content_exclusion_updated created:2026-05-01..2026-05-31

Les comptes Enterprise peuvent diffuser ces événements d’audit vers des SIEM externes (Splunk, Datadog, etc.) pour l’alerte automatisée et une conservation centralisée immuable.

Gérer les licences Copilot avec l’API REST

Affecter manuellement des licences via un tableau de bord fonctionne pour de petites équipes, mais ne tient pas la charge lors d’intégrations massives. Utiliser les endpoints seats de l’API REST de GitHub Copilot permet de traiter l’identité et les droits d’accès entièrement comme du code.

C’est l’une de mes parties préférées de l’administration Copilot : la gestion des licences devient automatisable proprement par les équipes engineering.

Endpoints API clés

Les workflows API courants incluent :

• Lister les attributions de licences
• Attribuer des licences
• Retirer des licences
• Récupérer des mesures d’usage
• Lire les paramètres Copilot de l’organisation

L’authentification requiert généralement :

• Des jetons d’accès personnels à portée fine
• Des permissions d’application GitHub
• Des droits d’administration d’organisation

Pour accéder à ces voies d’administration, vos scripts doivent s’authentifier avec un Personal Access Token (PAT) disposant des portées admin:org élevées, ou s’exécuter via une application GitHub autorisée avec des droits explicites de gestion Copilot au niveau organisation. 

Pour approfondir l’intégration programmatique à la plateforme, je vous recommande de suivre notre GitHub Foundations skill track. 

Modèles d’automatisation courants

Exemples pratiques :

• Onboarding identité automatisé : relier un SIRH (Workday, Okta) à GitHub via webhooks. Quand un ingénieur rejoint une équipe donnée, un script envoie une requête POST pour lui attribuer automatiquement une licence Copilot.

• Récupération des licences inactives : un script Cron planifié interroge l’utilisation des licences via l’API. Si un utilisateur n’a pas utilisé Copilot depuis plus de 30 jours, le script exécute une commande DELETE pour récupérer la licence et préserver le pool de crédits.

• Tableaux de bord financiers : extraire quotidiennement les données d’allocation et de consommation pour les intégrer à des plateformes de BI internes (Tableau, par exemple) et faciliter la refacturation par centre de coûts.

Exemple : attribuer une licence Copilot avec Python

Le script suivant montre comment attribuer par programmation une licence d’organisation à un développeur donné avec Python :

	import requests
	# Identity Configuration
TOKEN = "YOUR_ORGANIZATION_ADMIN_PAT"
ORG = "your-corporate-org"
USERNAME = "target-developer-user"

url = f"https://api.github.com/orgs/{ORG}/copilot/billing/selected_users"

headers = {
    "Authorization": f"Bearer {TOKEN}",
    "Accept": "application/vnd.github+json",
    "X-GitHub-Api-Version": "2022-11-28"
}

payload = {
    "selected_usernames": [USERNAME]
}

response = requests.post(url, json=payload, headers=headers)

if response.status_code == 201:
    print(f"Successfully allocated Copilot seat to {USERNAME}.")
else:
    print(f"Failed allocation. Status: {response.status_code}")
    print(response.json())

En conclusion

La structure des forfaits GitHub Copilot paraît simple depuis la page de tarifs. Dès que vous gérez des équipes, les différences deviennent bien plus substantielles.

Les frontières de confidentialité, les politiques d’entraînement, l’auditabilité et les contrôles de gouvernance comptent souvent plus que l’accès brut aux modèles. C’est pourquoi les discussions Business vs Enterprise autour de GitHub Copilot sont généralement des sujets sécurité et opérations, plus que purement techniques.

Si je devais conseiller une équipe aujourd’hui, je commencerais par les exigences de gouvernance :

• Avez-vous besoin de garanties contractuelles de confidentialité ?
• Avez-vous besoin de journaux d’audit ?
• Avez-vous besoin d’une gestion centralisée des politiques ?

Ensuite, j’optimiserais l’usage et l’accès aux fonctionnalités.

Pour renforcer les compétences techniques de votre équipe et vous préparer aux certifications officielles, explorez ces parcours avancés :

• Software Development with GitHub Copilot Course
• AI for Software Engineering Skills Track
• The GitHub Certification Guide for Data Professionals