Le chiffre de « 30 fois » doit en revanche être manié avec prudence. Les sources officielles de GitHub confirment bien une pression sur la capacité, la concurrence et le modèle de facturation. Mais elles ne confirment pas directement un plan public d’extension à 30×. Ce chiffre vient d’un média externe affirmant que GitHub devrait concevoir ses systèmes pour une échelle 30 fois supérieure à celle d’aujourd’hui . Il vaut donc mieux le lire comme une indication d’ordre de grandeur rapportée, et non comme un objectif officiel annoncé par GitHub.
Les premiers assistants de code fonctionnaient surtout sur un mode interactif : une complétion, une question, une explication, un petit bloc de code. Pour l’infrastructure, cela ressemblait à une succession de requêtes relativement courtes.
L’agentic coding change cette logique. Dans ses notes de version pour Copilot dans Visual Studio Code, GitHub mentionne Autopilot for fully autonomous agent sessions, en public preview, ainsi que des contrôles sur la manière dont les agents s’exécutent . Autrement dit, une intention de développeur peut se transformer en session autonome, et non plus en simple réponse instantanée.
C’est précisément ce que GitHub décrit lorsqu’il parle d’agents et de subagents : des workflows longs, parallélisés, capables de traiter des problèmes plus complexes . Pour la plateforme, la charge ne se mesure donc plus seulement en nombre de requêtes. Elle combine durée d’exécution, parallélisme, volume de contexte lu, appels aux outils, génération de modifications et consommation d’autres ressources GitHub.
Une complétion de code classique est brève. Un agent chargé d’un problème de développement peut, lui, fonctionner en plusieurs étapes : analyser le dépôt, planifier une correction, modifier des fichiers, vérifier le résultat, puis recommencer si nécessaire.
GitHub reconnaît que ces workflows d’agents et subagents peuvent remettre en cause son infrastructure et sa tarification, jusqu’à rendre certaines requêtes plus coûteuses que le prix du forfait . Le problème n’est donc pas seulement le nombre d’utilisateurs. Un seul développeur lançant plusieurs tâches intensives peut consommer beaucoup plus qu’un grand nombre de petites complétions.
Dans un logiciel SaaS classique, on évalue souvent la capacité en regardant combien de personnes utilisent le service en même temps. Avec des agents de code, ce raisonnement devient insuffisant : une seule personne peut déclencher plusieurs workflows automatisés, et chacun peut durer.
GitHub indique avoir observé, avec la croissance de Copilot, des schémas d’usage à forte concurrence et forte intensité, qui créent une pression significative sur l’infrastructure partagée . La bonne question n’est donc plus seulement : combien de développeurs sont en ligne ? Elle devient : combien de tâches automatisées ces développeurs font-ils tourner simultanément ?
Copilot ne se limite plus à la fenêtre de chat ou à l’éditeur de code. Le cas de Copilot code review est révélateur. GitHub indique que son usage a été multiplié par 10 depuis avril de l’année précédente et représente désormais plus d’une revue de code sur cinq sur GitHub. L’entreprise précise aussi être passée à une architecture agentique, capable de récupérer le contexte du dépôt et de raisonner à travers les changements .
Ce type de fonction est plus lourd qu’une simple réponse textuelle. Il s’insère dans le processus de revue, lit le contexte du dépôt et intervient dans une chaîne collaborative. Le fait que Copilot code review consomme des GitHub Actions minutes à partir du 1er juin 2026 montre que ces usages d’IA sont désormais rattachés à des ressources de plateforme plus larges .
Un abonnement mensuel fixe fonctionne bien lorsque l’usage reste relativement prévisible et rythmé par l’humain. Les agents de code, eux, peuvent travailler en continu, en parallèle, et multiplier les appels aux modèles et aux outils.
C’est pourquoi le basculement vers la facturation à l’usage est central. GitHub annonce que tous les forfaits Copilot passeront aux GitHub AI Credits le 1er juin 2026 . Le produit évolue ainsi d’un modèle où l’on achète surtout un siège utilisateur vers un modèle où l’on mesure davantage la quantité réelle de travail IA consommée.
Les changements annoncés forment un ensemble cohérent : limiter les abus, protéger la qualité de service, mieux répartir les coûts et préparer une tarification plus proportionnelle à l’usage.
Pris séparément, chaque changement peut ressembler à une mesure de gestion. Pris ensemble, ils racontent autre chose : GitHub redéfinit la manière dont Copilot consomme, mesure et facture la capacité.
Même si l’ordre de grandeur de 30× rapporté par un média externe devait être exact, il ne faudrait pas l’interpréter comme une simple multiplication par 30 du nombre d’utilisateurs . La pression peut venir d’un effet multiplicateur : davantage de développeurs utilisent l’agentic coding ; chaque développeur peut lancer plusieurs agents ; chaque agent peut durer plus longtemps ; les fonctions comme la revue de code récupèrent du contexte de dépôt et consomment d’autres ressources de plateforme
.
Le point solide, au vu des sources publiques, est donc le suivant : GitHub adapte Copilot parce que les charges de travail agentiques ne ressemblent plus aux usages qui avaient servi de base au modèle d’abonnement initial . Le « 30× » reste une narration externe de l’ampleur possible du problème, pas un indicateur officiel confirmé.
Traiter les agents IA comme de vraies charges de production. Il ne suffit plus de budgéter Copilot par nombre de développeurs. Les équipes doivent regarder combien d’agents sont lancés, combien de temps ils tournent, combien de tâches parallèles ils déclenchent, et quels usages entrent dans les GitHub AI Credits ou les GitHub Actions minutes .
Mettre en place un suivi d’usage au niveau de l’organisation. L’ajout de l’activité Copilot CLI par utilisateur dans les rapports d’organisation va dans ce sens . Pour une équipe qui déploie Copilot CLI, les modes agentiques ou la revue de code automatisée, ces métriques deviennent utiles à la fois pour l’ingénierie et pour le budget.
Encadrer l’autonomie. GitHub teste déjà des sessions d’agent entièrement autonomes dans Visual Studio Code et met en avant des contrôles sur la manière dont les agents s’exécutent . Les organisations qui expérimentent ces fonctions ont intérêt à définir des limites de concurrence, des délais d’expiration, des règles de relance et des points de validation humaine.
Revoir le modèle de coût avant le 1er juin 2026. Le passage aux GitHub AI Credits pour Copilot et la consommation de GitHub Actions minutes par Copilot code review rendront les coûts plus sensibles à l’intensité réelle d’usage . Pour les directions techniques, le sujet n’est plus seulement l’achat de licences, mais la gouvernance d’une capacité IA partagée.
La limitation de GitHub Copilot n’est pas seulement le symptôme d’un produit populaire. Elle révèle un changement de régime : le développement assisté par IA passe d’interactions courtes, calées sur le rythme humain, à des workflows autonomes, parallèles et gourmands en contexte.
GitHub a déjà reconnu que les agents et subagents défient son infrastructure et sa tarification, puis a répondu par des restrictions d’inscription, des limites d’usage, des ajustements de modèles, une facturation aux AI Credits et l’intégration de Copilot code review dans les GitHub Actions minutes .
La conclusion la plus prudente est donc simple : les agents de code sont en train de remodeler le modèle de capacité et le modèle économique de Copilot. Quant au chiffre de 30×, il doit rester présenté comme une affirmation externe non confirmée directement par GitHub .
Comments
0 comments