GitHub Copilot en pratique : forfaits, crédits et bonnes pratiques pour en tirer le maximum

Je suis déjà revenu sur la double nature agentique de GitHub Copilot dans un premier article : l’Agent Mode synchrone dans l’éditeur, le Coding Agent asynchrone dans le cloud. Cette fois, je descends d’un cran : comment choisir son forfait, comprendre ce que consomment vraiment les crédits, et surtout comment configurer et piloter l’outil pour qu’il rende vraiment service, plutôt que de rester au niveau de l’autocomplétion.

Les surfaces de Copilot, en un coup d’œil

Avant de parler argent, un point de repère. Copilot en 2026, c’est plusieurs interfaces qui partagent le même compte et le même compteur de crédits¹ :

• Complétion de code et Next Edit Suggestions : la suggestion en ligne, gratuite et illimitée sur tout forfait payant.
• Copilot Chat : la conversation classique dans l’éditeur ou sur github.com.
• Agent Mode : l’agent synchrone dans l’IDE (VS Code, Visual Studio, JetBrains, Eclipse, Xcode).
• Coding Agent : l’agent asynchrone dans le cloud, qui part d’une issue GitHub et revient avec une pull request.
• Code review : la relecture automatique de tes pull requests, avec ses propres instructions personnalisées.
• Copilot CLI : l’agent en ligne de commande, avec mode plan, mode autopilot et exécution parallèle via /fleet.
• Copilot Spaces : un espace de contexte durable (dépôts, docs, standards) que tu peux réutiliser d’une session à l’autre.
• GitHub Spark : un générateur d’applications en langage naturel, réservé à Pro+ et Enterprise.

Retiens surtout ceci : la complétion de code reste gratuite et illimitée sur tout forfait payant. Tout le reste (chat, agents, CLI, code review, Spaces, Spark) tire sur ton enveloppe de crédits¹.

Les forfaits en juillet 2026

Le tableau des forfaits individuels a pris sa forme actuelle avec l’arrivée du palier Max :

Forfait	Prix	Crédits inclus	Points clés
Free	0 $	Usage chat/agent très limité, non chiffré	2 000 complétions/mois, modèles en sélection automatique uniquement, CLI et Agent Mode disponibles
Pro	10 $/mois	15 $ (10 $ de base + 5 $ flex)	Complétions illimitées, Cloud/Coding Agent, code review, sélection manuelle du modèle
Pro+	39 $/mois	70 $ (39 $ de base + 31 $ flex)	Accès aux modèles premium, GitHub Spark, journaux d’audit, environ 4x le volume de Pro
Max	100 $/mois	200 $ (100 $ de base + 100 $ flex)	Accès prioritaire aux nouveaux modèles, environ 2,9x le volume de Pro+, pensé pour l’usage agentique intensif
Business	19 $/utilisateur/mois	19 $ par utilisateur, mutualisables dans l’organisation	Gestion centralisée, politiques d’accès, pool de crédits d’équipe
Enterprise	39 $/utilisateur/mois	Pool plus large que Business	Indexation du code de l’organisation, sécurité renforcée, intégration native à github.com

Le prix affiché de chaque forfait correspond exactement au montant de crédits de base inclus : Pro coûte 10 $ et inclut 10 $ de crédits de base, Pro+ coûte 39 $ pour 39 $, et ainsi de suite. Par-dessus s’ajoute une enveloppe « flex » variable, qui explique pourquoi le total de crédits dépasse toujours le prix affiché¹.

Une remarque pratique si tu tentes de souscrire aujourd’hui : GitHub ouvre les inscriptions à Pro, Pro+ et Max « progressivement », donc il est possible que le bouton d’inscription ne soit pas immédiatement disponible selon ta zone ou ton compte¹. Ce n’est pas une panne, c’est un rythme de déploiement contrôlé.

Le système de crédits : ce qu’il faut vraiment comprendre

Jusqu’au 1er juin 2026, Copilot facturait en « requêtes premium », un compteur simple mais grossier. Depuis cette date, tous les forfaits sont passés à la facturation à l’usage : un « crédit GitHub AI » vaut 0,01 $, et chaque interaction consomme un montant de crédits calculé sur la consommation réelle de tokens (entrée, sortie, cache) au tarif de l’API du modèle choisi².

Ce qui ne consomme jamais de crédits : la complétion de code et les Next Edit Suggestions, qui restent illimitées sur tout forfait payant¹.

Ce qui consomme des crédits, et à un rythme très variable : le chat, l’Agent Mode, le Coding Agent, le code review, Copilot CLI, Spaces et Spark. Une question courte à un modèle léger coûte une fraction de crédit. Une session d’agent longue sur un modèle frontière, qui touche de nombreux fichiers, peut en coûter beaucoup plus¹. C’est le vrai piège du passage à l’usage : deux développeurs sur le même forfait Pro peuvent avoir des factures très différentes selon qu’ils utilisent surtout l’autocomplétion ou qu’ils lancent des sessions d’agent à répétition.

Quand l’enveloppe incluse est épuisée, tu as trois options : attendre le renouvellement mensuel, fixer un budget de dépassement (les crédits supplémentaires se décomptent toujours à 0,01 $ l’unité, donc 10 $ de budget couvrent 1 000 crédits de plus), ou basculer sur un modèle moins gourmand pour faire durer ce qu’il te reste¹. Sur Business et Enterprise, ce sont les administrateurs qui fixent ces règles au niveau de l’entreprise, du centre de coûts ou de l’utilisateur, avec des alertes automatiques à 75 %, 90 % et 100 % du budget configuré¹². Si tu pilotes une équipe, c’est le premier réglage à vérifier avant de généraliser l’usage agentique : un stagiaire qui laisse tourner l’Autopilot toute la nuit sur un modèle premium peut faire beaucoup de dégâts budgétaires en une seule session.

Un autre réflexe pèse tout autant sur la facture, et il ne dépend d’aucun réglage GitHub : ne pas tout traiter dans le même chat. Une conversation qu’on prolonge de sujet en sujet accumule un contexte de plus en plus lourd, et ce contexte est renvoyé (et refacturé) à chaque nouvel échange, même la part devenue inutile au sujet du moment. Le mécanisme, pourquoi la qualité des réponses se dégrade bien avant la limite technique, et les bons réflexes pour garder une fenêtre de contexte propre, je les détaille dans mon article sur la fenêtre de contexte : le principe vaut pour Claude comme pour Copilot. Ouvrir une nouvelle session par tâche indépendante coûte quelques secondes et évite de payer, encore et encore, pour du contexte que le modèle n’utilise même plus vraiment.

Bien choisir son modèle

Le catalogue de modèles disponibles dans Copilot est large et couvre les trois grandes familles : Claude d’Anthropic (de Haiku à Opus), GPT d’OpenAI (y compris les variantes Codex spécialisées code) et Gemini de Google¹. La règle qui structure tout le reste : le coût en crédits dépend du modèle choisi, pas seulement de la tâche. Un modèle de raisonnement haut de gamme peut consommer plusieurs fois plus de crédits qu’un modèle standard pour un travail équivalent³.

En pratique, une stratégie simple fonctionne bien : un modèle léger et rapide pour les tâches répétitives (docstrings, tests unitaires basiques, petits correctifs), un modèle de raisonnement plus lourd réservé aux refactors complexes, à l’investigation de bugs subtils ou à la conception d’architecture, et le mode « auto » quand tu n’as pas d’avis tranché, puisqu’il choisit en fonction de la charge du système et de la complexité perçue de la tâche³.

Il y a un levier presque aussi déterminant que le choix du modèle, et qu’on oublie trop souvent : l’effort de raisonnement (« thinking effort » ou « reasoning effort »). Sur les modèles qui le permettent, le sélecteur de modèle de l’éditeur (VS Code depuis la version 1.113, entre autres) affiche un niveau d’effort réglable indépendamment du modèle, typiquement de Low à x-High¹². Le même modèle, disons Claude Sonnet 4.6, produit un raisonnement minimal et une réponse quasi instantanée en effort bas, et alloue nettement plus de tokens de réflexion en effort élevé, avec un résultat souvent bien plus solide sur un bug retors ou une décision d’architecture. Seuls les modèles de raisonnement affichent ce réglage : les modèles non-raisonnants comme GPT-4.1 ou GPT-4o n’ont pas ce sous-menu¹². Le réflexe à prendre : si un résultat te semble insuffisant, monte d’abord l’effort avant de changer de modèle, l’écart de qualité est souvent plus net qu’en changeant de modèle à effort égal. Contrepartie logique : plus l’effort grimpe, plus la consommation de crédits grimpe aussi, donc réserve le x-High aux tâches qui le justifient vraiment (audit de sécurité, migration complexe, bug qui a déjà résisté à une première tentative), et laisse le réglage par défaut pour le chat courant et les petites retouches.

Le terminal comme nouvelle interface : Copilot CLI

Passé en disponibilité générale en février 2026, Copilot CLI s’installe en une commande (npm install -g @github/copilot) et fonctionne sur tous les forfaits, y compris Free⁴. Trois mécanismes le distinguent nettement de l’Agent Mode dans l’éditeur :

Le mode plan (bascule avec Maj+Tab) te fait d’abord relire un plan d’implémentation avant que Copilot ne touche à un seul fichier, ce qui évite les mauvaises surprises sur une tâche mal cadrée.

Le mode autopilot laisse l’agent enchaîner les étapes sans repasser par toi à chaque action, utile pour une tâche longue que tu ne veux pas superviser en direct, mais à encadrer avec une limite explicite sur le nombre d’itérations autorisées⁵.

La commande /fleet est la plus intéressante si tu réfléchis déjà à l’orchestration de plusieurs agents en parallèle : elle prend un plan d’implémentation, le découpe en sous-tâches indépendantes, et distribue chacune à un sous-agent qui dispose de son propre contexte, avant de faire converger le tout⁶⁷. Concrètement :

/fleet Ajoute la validation des entrées sur tous les endpoints de l'API,
mets à jour les tests unitaires de chaque endpoint, et complète la
documentation JSDoc des routes concernées.

flowchart TD
  A["Prompt /fleet + plan d'implémentation"] --> B["Orchestrateur : découpe en sous-tâches indépendantes"]
  B --> C1["Sous-agent 1<br/>fichier ou module A"]
  B --> C2["Sous-agent 2<br/>fichier ou module B"]
  B --> C3["Sous-agent 3<br/>fichier ou module C"]
  C1 --> D["Convergence des résultats"]
  C2 --> D
  C3 --> D
  D --> E["Relecture humaine avant fusion"]

/fleet paie surtout quand une tâche se découpe naturellement par fichier ou par module (API, UI, tests, docs), avec des lots qui ne se marchent pas dessus. Si deux sous-agents doivent modifier le même fichier, ou si chaque étape dépend strictement de la précédente, la parallélisation n’apporte rien et complique inutilement la relecture⁶. Point de vigilance budgétaire : quatre sous-agents en parallèle consomment environ quatre fois les crédits d’un agent séquentiel unique, donc réserve /fleet aux tâches suffisamment vastes pour justifier le coût, et garde toujours une étape de relecture humaine avant de fusionner.

Ce découpage en sous-tâches parallèles fait de Copilot CLI un candidat sérieux à intégrer dans une réflexion sur la supervision de plusieurs agents de code en simultané, à la manière de ce que permettent déjà des outils comme Claude Squad côté Claude Code. GitHub a d’ailleurs formalisé cette ambition sous le nom d’Agent HQ : une couche d’orchestration où Copilot ne se contente plus d’exécuter ses propres agents, mais peut aussi déléguer des tâches à des agents tiers (Claude Code d’Anthropic, Codex d’OpenAI) depuis une interface et une facturation communes, une fonctionnalité actuellement réservée aux forfaits Pro+ et Max⁸.

Donner du contexte durable : instructions personnalisées et Spaces

La plus grosse différence entre un Copilot qui produit du code générique et un Copilot qui respecte tes conventions, c’est un fichier .github/copilot-instructions.md à la racine du dépôt. Il est lu à chaque requête de chat, d’agent ou de code review sur ce dépôt⁹. Les recommandations qui reviennent le plus souvent chez GitHub et dans la communauté :

• Reste concis. Au-delà d’environ 1 000 lignes, la qualité des réponses se dégrade ; viser quelques centaines de lignes bien structurées vaut mieux qu’un document exhaustif¹⁰.
• Structure avec des titres et des listes, pas des paragraphes narratifs. Copilot, comme n’importe quel humain qui découvre ton repo, parcourt mieux un document scannable¹⁰.
• Sois explicite plutôt que général : « utilise des exports nommés » vaut mieux que « respecte de bonnes pratiques d’export ».
• Pour des règles propres à un type de fichier, crée des fichiers .instructions.md séparés dans .github/instructions/, avec un motif applyTo en en-tête YAML (par exemple applyTo: "**/*.py"), plutôt que de tout empiler dans le fichier racine⁹.
• Itère plutôt que de viser la perfection du premier coup. Un fichier imparfait vaut largement mieux que l’absence de fichier, et tu peux même demander à Copilot de générer une première version à partir de l’inventaire de ton repo⁹.

Sur les priorités de dépôts multiples ou d’organisation : les instructions personnelles priment, puis les instructions de dépôt, puis les instructions d’organisation, mais toutes s’additionnent, elles ne s’excluent pas entre elles⁹.

Pour un contexte encore plus durable que le fichier d’instructions, Copilot Spaces te permet de rassembler dépôts, documents et standards dans un espace persistant que tu réutilises d’une session à l’autre, plutôt que de recoller le contexte à chaque nouvelle conversation.

Bonnes pratiques pour vraiment gagner en productivité

Quelques réflexes qui font la différence entre un Copilot qui traîne des pieds et un Copilot qui accélère vraiment le travail :

• Écris des prompts riches en contexte : noms de fonctions explicites, fichiers pertinents ouverts ou épinglés, intention clarifiée en commentaire avant de demander la génération.
• Découpe en petites étapes vérifiables plutôt que de demander une fonctionnalité entière d’un coup. Un agent qui livre un diff de 40 lignes se relit ; un agent qui livre un diff de 800 lignes se subit.
• Traite chaque suggestion comme le brouillon d’un développeur junior : à lire, tester et éventuellement corriger, jamais à fusionner les yeux fermés.
• Ouvre une session par tâche indépendante, plutôt que d’enchaîner des sujets sans rapport dans le même chat ou la même session d’agent (voir la section sur la fenêtre de contexte plus haut).
• Réserve le Coding Agent aux tickets bien cadrés (bug reproductible, ajout de tests, dépendance à mettre à jour, refactor limité à un périmètre précis) plutôt qu’à un objectif ouvert du type « améliore les performances », qui le fera tourner jusqu’à épuiser ses instructions ou ses crédits¹¹⁹.
• Encadre systématiquement /fleet et l’autopilot par une frontière de fichiers explicite dans le prompt et une relecture humaine finale, jamais une fusion automatique.
• Surveille ta consommation de crédits régulièrement, pas seulement en fin de mois : le tableau de bord de facturation et la barre de statut Copilot dans VS Code donnent une vision en temps réel.
• Écris ton copilot-instructions.md dès le premier jour d’un projet, pas après trois mois de suggestions à côté de la plaque à corriger à la main.

Copilot face à Claude Code : deux philosophies

Si tu es déjà familier de Claude Code, la comparaison est utile pour savoir quand sortir quel outil. Copilot mise sur la largeur : intégration native à tout l’écosystème GitHub (issues, pull requests, Actions), une seule authentification et une seule facturation pour la complétion, le chat, les agents et le CLI, et un prix d’entrée plus bas. Claude Code mise sur la profondeur : une autonomie plus poussée sur les chaînes de tâches longues et ouvertes, une gestion de contexte pensée dès le départ pour le terminal, et une architecture de sous-agents native. Pour un objectif bien cadré dans un dépôt GitHub classique, Copilot tient largement la route et coûte moins cher. Pour un refactor ambitieux et peu balisé, une longueur d’avance reste du côté de l’outil pensé spécifiquement pour ça, et c’est justement ce que couvre mon article sur Claude Code. Les deux ne s’excluent d’ailleurs plus vraiment : avec Agent HQ, Copilot peut désormais déléguer certaines tâches à Claude Code lui-même depuis une même interface.

Par où commencer aujourd’hui

Si tu démarres ou si tu veux remettre à plat ton usage :

1. Choisis ton forfait selon ton usage réel, pas selon la liste de fonctionnalités. Un usage majoritairement complétion + chat occasionnel tient très bien sur Pro ; un usage agentique quotidien pousse vite vers Pro+ ou Max.
2. Installe Copilot CLI et teste le mode plan sur une tâche que tu connais déjà, pour calibrer ta confiance avant de lâcher l’autopilot.
3. Écris un copilot-instructions.md minimal (stack, conventions, commandes de build et de test) avant de multiplier les sessions d’agent.
4. Teste /fleet sur une tâche volontairement découpable, comme ajouter des tests sur trois fichiers indépendants, pour voir la mécanique à l’œuvre.
5. Fixe une alerte de budget dès le premier jour d’usage agentique intensif, tu ajusteras ensuite en connaissance de cause.

L’essentiel à retenir

Le forfait fixe ton enveloppe de crédits de base, mais ta vraie facture dépend de la manière dont tu travailles : la complétion ne coûte rien, l’usage agentique coûte proportionnellement à ce que tu lui demandes, au modèle que tu choisis, à l’effort de raisonnement que tu lui accordes, et à la taille du contexte que tu traînes d’un sujet à l’autre. Le vrai levier de productivité n’est pas le forfait le plus cher, c’est un copilot-instructions.md bien pensé, des tâches bien découpées dans des sessions propres, un effort de raisonnement ajusté à l’enjeu, et une relecture humaine systématique avant chaque fusion.