Cursor a fait son choix : exit Spokes, place à Continuity.

Le premier est un système de stockage distribué fondé sur le consensus. Né au début des années 2010, il est devenu le substrat de nombreux services d’hébergement Git.

Le second est une tentative d’en pallier les limites – tant en matière de scalabilité que de maintien de la cohérence. Son architecture est centrée sur un concept propre à S3 : les journaux d’écriture anticipée (WAL, Write-Ahead Logs). Lesquels consistent, dans les grands lignes, à stocker plusieurs objets dans un même fichier de manière séquentielle.

Sur cette base, Cursor a développé une forge qu’il a appelée Origin. Mi-août, il a commencé à y donner accès, en bêta, pour les abonnés à ses forfaits payants.

En façade, il n’y a pour le moment pas de spécificités fonctionnelles par rapport à la concurrence. Il y a surtout beaucoup moins d’intégrations : le catalogue se limite à Vercel, Depot et Buildkite.

Cursor a soigné les passerelles avec GitHub, mais tout n’est pas encore synchronisé (issues et workflows CI, par exemple). Il promet notamment, sur le court terme, des jonctions avec ses agents.

Pannes répétées pour GitHub, victime de « surcharge agentique »

L’annonce d’Origin est tombée le jour même où GitHub a connu sa dernière panne majeure en date. Au pic, les taux d’erreur web et API ont avoisiné 20 % (50 % sur l’archivage et le téléchargement de fichiers). En cause, une saturation réseau sur des load balancers aux États-Unis. Le problème découlait d’une politique d’autoscaling mal configurée, en conséquence de quoi un pod Istio avait atteint ses limites de concurrence.

GitHub a connu d’autres pannes importantes ces dernières semaines. En particulier sur le CI. Le 9 juillet, la dégradation d’un service de provisionnement d’exécuteurs hébergés a empêché certains workloads d’en acquérir. Dix jours plus tard, une expiration de certificat SSL a entraîné une perte de connectivité pour certains runners. Début août, à la suite d’un déploiement de routnie vers un service interne de traitement d’événements et de création de jobs, jusqu’à 70 % des flux CI ont échoué. Une autre perturbation est survenue à la fin du mois, due à une saturation des écritures vers une base de données exploitée par les déclencheurs.

Ces derniers mois, la plate-forme a plus globalement souffert d’un net accroissement de la charge dans le contexte du développement agentique. Le problème n’est toutefois pas tant lié à GitHub qu’à Git. Ainsi Cursor n’a-t-il pas seulement conçu Origin, mais aussi Continuity.

Remédier aux limites de scalabilité de Spokes

Git s’accommode mal de la cohérence éventuelle. Il est préférable de la maintenir en continu. Pour cela, Spokes accepte un coût de complexité très élevé.

À son lancement, trois répliques par dépôt représentaient le compromis idéal, d’après Cursor. Aujourd’hui, les choses ont changé : les repos se sont massifiés.

Dès lors qu’on commence à ajouter des répliques apparaît un problème de la longue traîne, la latence de chaque étape étant déterminée par le serveur le plus lent du cluster. Cette contrainte de scalabilité vaut aussi dans l’autre sens. Lorsque des agents travaillent sur un monorepo, ils opèrent souvent en dehors, créant un grand nombre de petits dépôts. Soit autant de répliques à maintenir pour garantir entièrement la cohérence.

Cursor souligne un autre défaut de Spokes : puisque les dépôts sur disque constituent toujours la source de vérité pour le consensus, chaque copie est importante. Il faut donc savoir exactement où se trouve chaque dépôt. Ce qui ajoute une dépendance envers une table de routage externe.

Pas de consensus ni d’état

Pour garantir une scalabilité horizontale entièrement cohérente, le composant central de Continuity est donc le journal d’écriture anticipée. Chaque push y est stocké sous la forme d’un objet distinct. Le packfile (format de sérialisation binaire de Git) est à la fois envoyé sur disque et téléversé sur S3. Un push ne devient cependant visible qu’après préparation de la transaction de référence sur une copie locale du dépôt et enregistrement d’un pointeur vers l’entrée WAL dans le fichier d’index. L’ensemble garantit que tous les pushs sont linéarisables, explique Cursor.

Comme il suffit de synchroniser la transaction de référence avec un seul dépôt local plutôt qu’avec un quorum de répliques, le système peut ingérer les pushs aussi vite que le permet le disque.

Continuity élimine aussi le besoin de suivre l’emplacement de chaque dépôt sur chaque serveur. La source de vérité reste le journal d’écriture anticipée. Le système est sans état et ne nécessite ni tables de routage, ni base de données relationnelle. Si un dépôt est absent du disque local lors d’un accès sur un hôte, on le matérialise à partir du WAL.
Il n’y a pas non plus de consensus : n’importe quel serveur peut être le principal. La synchronisation du WAL se fait par une opération atomique de comparaison et d’échange sur S3. Il est donc toujours sûr que n’importe quelle instance d’un dépôt reçoive un push, prétend Cursor.

Jusqu’à 300 pushs par seconde

Continuity effectue une réplication optimiste en envoyant des paquets UDP de gossip dans le cluster. Chaque réplique connaît l’ETag (entity tag) de la dernière version de l’index WAL qu’elle a rattrapée. Les opérations de lecture sur une réplique consistent en des requêtes GET conditionnelles avec l’ETag attendu. Avoir S3 comme source de vérité évite les problèmes quand le paquet UDP se perd ou arrive sur le mauvais serveur. Le système passant à l’échelle dans les deux directions, chaque dépôt dispose du bon nombre de répliques, selon Cursor. Et le débit des opérations Git en lecture seule (clone, fetch…) augmente linéairement.

Continuity amortit par ailleurs le coût du compactage. Seul le nœud principal l’effectue. Le résultat s’applique à la fois au dépôt sur disque et au WAL. Comme toutes les répliques suivent le WAL, elles suivent aussi les événements de compactage.

Le débit des pushs d’un cluster dépend de la latence de mise à jour du WAL. Avec S3 Standard, Cursor parvient à maintenir 120 pushs par seconde. Avec Express One Zone, il atteint 300 pushs/s. Le facteur limitant est la vitesse à laquelle Git peut compacter les données sur disque. Cursor dit travailler sur des méthodes d’organisation de ces données afin de réduire l’impact du compactage.

Illustration générée par IA

The post Cursor s’appuie sur S3 pour repenser Git… et concurrencer GitHub appeared first on Silicon.fr.

Malgré l’aide précieuse qu’apporte l’IA, merci de ne pas confondre vitesse et précipitation.

Mi-mai, GitHub avait fait passer le message aux participants à son bug bounty public. En toile de fond, la saturation de ce programme par des soumissions de faible qualité. Essentiellement à deux titres. D’une part, parce que hors périmètre. De l’autre, par l’absence de preuve d’impact réel.

Dans ce contexte, GitHub avait affirmé qu’il évaluerait plus strictement la présence de PoC fonctionnels. Il avait plus globalement rappelé qu’IA ou pas, il convenait de valider toute trouvaille avant de la soumettre. Tout en s’assurant que les rapports soient concis et structurés (résumé du problème, étapes pour le reproduire, déclaration d’impact).

Ce rappel s’était accompagné d’un autre, relatif à la notion de responsabilité partagée. GitHub était notamment revenu sur les attaques impliquant un « engagement explicite » de l’utilisateur. Il avait cité, entre autres, le clonage de dépôt malveillant et l’usage d’une IA pour analyser du code non sécurisé. Dans les grandes lignes : ces scénarios ne sont généralement pas assimilables à un contournement de ses contrôles de sécurité.

GitHub avait aussi annoncé la fin des récompenses financières pour les rapports qui ne démontrent pas d’impact significatif mais qui permettent une correction de code ou de documentation. Leurs auteurs peuvent ne peuvent désormais prétendre qu’à des goodies.

Des seuils de récompense globalement maintenus… pour les VIP

Une nouvelle étape dans la restructuration du bug bounty vient d’être franchie. Elle comprend une refonte du programme VIP sur invitation*. Critère d’éligibilité : le nombre de rapports validés. Au choix, au moins :

• 1 pour une vulnérabilité critique
• 2 pour des vulnérabilités importantes
• 4 pour des vulnérabilités de sévérité moyenne
• 7 pour des vulnérabilités de faible sévérité

Au-delà d’une promesse de relation « plus étroite » avec les équipes sécurité de GitHub, les VIP pourront espérer des récompense plus élevées. Les plafonds sont fixés à :

• 1000 $ pour une vulnérabilité de faible sévérité
• 7500 $ en sévérité moyenne
• 20 000 $ en sévérité élevée
• 30 000 $ pour les critiques

Ces plafonds restent indicatifs. GitHub se réserve le droit de moduler les récompenses en fonction des découvertes. Même chose pour les « non-VIP »… qui, sur le papier, perdent au change.

GitHub ne le cache pas : il rogne sur les récompenses du bug bounty public pour pouvoir en octroyer de plus élevées aux VIP.

GitHub utilisera désormais l’indice de réputation HackerOne

Autre nouveauté : l’enclenchement du signal HackerOne. Cet indice de réputation, s’il n’est pas atteint, limite le nombre de soumissions autorisées : 4 par programme pour les nouveaux membres (moins de 5 rapports résolus), 8 pour les anciens (plus de 5 rapports). L’exigence s’appliquera au 27 juillet 2026.

* Il existait déjà un programme VIP sur invitation. Il donnait accès à un canal Slack dédié, à des goodies exclusifs et à des fonctionnalités en accès anticipé. Mais pas à des récompenses plus élevées. Pour y être admissible, il fallait avoir gagné au moins 20 000 $ sur le bug bounty et avoir soumis au moins 2 rapports sur les 2 dernières années.

Illustration générée par IA

The post Dépassé par la « bouillie IA », GitHub restructure son bug bounty appeared first on Silicon.fr.

Limitez les permissions de vos agents au strict nécessaire, a fortiori s’ils ont accès à plusieurs dépôts.

Là n’est pas le seul conseil que Noma Security donne aux utilisateurs des workflows agentiques GitHub. Mais c’est probablement celui qui se justifie après la démonstration de l’entreprise israélienne. Elle a, en l’occurrence, mis en lumière une vulnérabilité d’injection de prompt.

Un fichier d’un dépôt privé exfiltré via une issue publique

Les workflows agentiques sont en bêta publique depuis quelques semaines.On les place dans le même dossier que les automatisations déterministes, mais sous forme de fichiers Markdown. On les accompagne d’une configuration YAML (conditions de déclenchement, permissions et opérations autorisées). Une commande CLI convertit l’ensemble en actions exécutables par GitHub Copilot, Claude, Codex ou Gemini.

La vulnérabilité en question repose sur des instructions localisées dans une issue créée au sein d’un dépôt public de l’organisation cible. Son auteur, soi-disant directeur commercial, revient d’une réunion client et demande plusieurs choses :

• Modifier les couleurs d’une page de login
• Lui rappeler le contenu du README dans un dépôt public de l’organisation
• « En plus », lui rappeler le contenu de de même fichier dans un dépôt privé de l’organisation

Le workflow se déclenche après assignation de l’issue. L’agent récupère le contenu desdits fichiers… et les poste dans le fil de discussion, en public.

De grandes permissions impliquent un grand risque

GitHub a des protections contre ce type de scénario. Mais l’ajout de l’expression « en plus » a permis de les déjouer, explique Noma Security.

Telle que présentée, l’attaque peut toucher toute organisation utilisant les workflows agentiques. D’autant plus qu’elle n’exige pas d’authentification (créer une issue dans un dépôt public suffit). Elle aurait cependant échoué si l’IA n’avait pas eu la permission d’accéder au dépôt privé. Difficile, en ce sens, que le problème vient de GitHub, sauf une de ses applications a accordé cette permission.

GitHub lui-même rappelle, dans la documentation de ses workflows agentiques, la nécessité de d’appliquer le principe du moindre privilège. Et de limiter les opérations autorisées. Il précise, à ce sujet, que toute écriture – y compris l’ajout de commentaires – doit être permise explicitement dans la configuration des workflows.

Illustration générée par IA

The post GitHub Actions devient un canal d’injection de prompts appeared first on Silicon.fr.

Ajoutez les clés de passe si vous voulez, mais ne supprimez pas le TOTP.

Cette demande est emblématique de la friction que GitHub a engendrée avec son dernier train de mesures de sécurité pour npm.

Il avait annoncé la couleur fin septembre 2025, dans la lignée d’une attaque d’ampleur sur le gestionnaire de paquets. Dans un horizon de quelques semaines, les tokens « classiques » (legacy) seraient supprimés. Quant aux tokens granulaires avec des permissions en écriture, ils ne pourraient plus avoir une durée de vie illimitée. Mi-octobre, celle-ci passerait à 90 jours maximum… et à 7 jours par défaut (contre 30 auparavant).

Le timing pour supprimer TOTP était (beaucoup) trop court

GitHub prévoyait aussi qu’à échéance de « quelques mois », l’authentification forte par code TOTP ne soit plus disponible. Il le justifiait essentiellement par la vulnérabilité du protocole au phishing et aux attaques par relais. Risques auxquels, expliquait-il, les clés de passe ne sont pas exposées, même si le générateur lui-même est compromis.

Dans la communauté npm, on lui a fait remarquer que l’approche passkey n’était pas idéale pour les systèmes automatisés. Et que finalement, il était bien pratique de pouvoir publier depuis le terminal sans avoir à s’authentifier dans un navigateur. Certains furent plus offensifs, invoquant un verrouillage (« Les clés de passe ne sont pas si portables »…).

Au bout du compte, GitHub a maintenu le cap… mais a remis les choses à bien plus tard. En février, il expliquait encore ne pas avoir l’intention de supprimer le TOTP avant que le reste de ses mesures de sécurité aient été largement adoptées.

Des tokens finalement un peu moins éphémères

La suppression des tokens classiques fut elle aussi repoussée à plusieurs reprises. Elle est finalement intervenue début décembre. S’y sont substitués, pour la publication locale, des tokens éphémères, initialement valables 2 heures. Interpellé sur les contraintes que cela représentait, GitHub a fini par élargir la fenêtre à 12 heures. Non sans recommander de limiter ces tokens à la publication et d’utiliser des tokens granulaires en lecture seule pour l’accès continu aux paquets privés.

Parallèlement au plafonnement de la durée de vie des tokens granulaires avec droits en écriture, le paramétrage standard des paquets a évolué.  À leur création, le 2FA s’active par défaut, conditionnant toute publication.

GitHub serre la vis sur les scripts install

La dernière mesure annoncée s’appliquera à partir de npm v12, attendu pour juillet (elle émet pour le moment des alertes). Elle désactive, par défaut, l’exécution des scripts preinstall, install et postinstall depuis des dépendances. Cela inclut les builds node-gyp natifs (qui exécutent un node-gyp rebuild implicite). Attention donc à des paquets comme bcrypt, canvas, sharp et les pilotes de bases de données. Ainsi qu’à Cypress, Playwright et Pupeteer, mais pour une autre raison : ils téléchargent des binaires via postinstall.

Un autre comportement disparaîtra par défaut : la résolution des dépendances depuis des URL distantes (–allow-remote), y compris les tarballs https. La même chose s’applique depuis février à la résolution de dépendances Git directes ou transitives (–allow-git). Elle bloque un vecteur d’exécution de code (le .npmrc d’une dépendance Git pouvant passer outre l’exécutable, même avec –ignore-scripts).

Pour le moment, GitHub n’annonce pas de changement de comportement pour les drapeaux –allow-file et –allow-directory.

Le trusted publishing, en manque de fournisseurs CI/CD

La suppression de TOTP dépendra probablement aussi de la diffusion du trusted publishing. Cette fonctionnalité implémente un standard défini par l’OpenSSF. Elle utilise l’authentification OIDC pour créer une relation de confiance entre npm et des fournisseurs CI/CD. PyPi fut le premier gestionnaire de paquets à l’adopter, en 2023. Sur npm, elle est disponible depuis juillet 2025, mais ne gère encore que trois services :

• GitHub Actions (exécuteurs managés)
• GitLab CI/CD (exécuteurs partagés)
• CircleCI (version cloud)

L’édition par lots des configurations trusted publishing est relativement récente (février 2026). La détection des malwares dans les dépendances avec Dependabot l’est encore plus (mars)… en tout cas dans sa nouvelle incarnation. GitHub avait suspendu la précédente en 2022, en raison du volume de faux positifs dus officiellement à des conflits de nommage entre des paquets publics et privés.

Illustration générée par IA

The post La sécurité de npm, un jeu d’équilibriste pour GitHub appeared first on Silicon.fr.

Construire avec GitHub, contextualiser avec Microsoft IQ, exécuter dans Foundry, gouverner avec Agent 365.

Ces quatre briques forment le cœur de la « plate-forme agentique » de Microsoft ; en tout cas telle qu’il l’a présentée à la Build 2026.

Nous reprenons ici cette trame, en nous arrêtant sur quelques fonctionnalités récemment passées en phase commerciale ou lancées en phase expérimentale.

Une application de bureau pour GitHub Copilot

Depuis quelques semaines, l’app GitHub Copilot est en préversion technique. Elle est disponible pour Windows, Mac et Linux (x64, Arm). Il y a une liste d’attente pour les utilisateurs de la version gratuite de GitHub Copilot. Pas pour les abonnés Pro, Pro+, Max, Business et Enterprise.

GA mi-juin pour Work IQ, la couche de context engineering

Sous la marque Work IQ, Microsoft revendique une couche de contexte unifiée, des données aux outils.

Au-delà de l’accès aux données de ses logiciels (suite Office, ainsi que Dynamics 365 et PowerApps via Dataverse) et de systèmes externes via les connecteurs Copilot, Microsoft promet de dépasser la notion d’ancrage, en « comprenant comment les organisations travaillent » (profils de compétences, projets importants, habitudes de communication…).

Les endpoints (A2A, MCP et REST) passeront en phase commerciale le 16 juin. La facturation se fera à la consommation, indépendamment des licences Microsoft 365 Copilot – nécessaires néanmoins pour certaines fonctionnalités. Il y aura plus précisément des frais variables pour les usages de type requêtes (récupération, raisonnement) et fixes pour l’invocation d’actions et d’outils. Microsoft donne trois exemples, de complexité graduelle :

• Identifier les tâches ou actions assignées par un manager et en faire une check-list : 0,20 à 0,40 $
• Analyser les derniers e-mails de clients pour identifier les principaux thèmes et l’impact sur la roadmap, puis recommander 3 actions : 0,30 à 0,75 $
• Produire des résumés niveau 1 et 2 de la plus récente revue de roadmap, en exploitant les réunions et les documents prioritaires pour le CMO : 0,50 à 1,50 $

Web IQ, une « version premium » de l’ancrage avec Bing

En complément à Work IQ, il y a Web IQ. Cette suite d’API, disponible en preview (liste d’attente), est une forme de « version premium » de l’ancrage avec Bing. Elle s’appuie aussi sur l’index du moteur de recherche (additionné de données sous licence), mais a sa propre architecture de vectorisation, de classement, d’extraction et de routage.

Microsoft a intégré, dans ce pipeline, quelques-unes de ses technologies. Par exemple, son modèle d’embedding Harrier et son algorithme de recherche de plus proche voisin DiskANN. Il annonce une latence de 164 ms au 95^e percentile.

Frontier Tuning, un environnement managé d’apprentissage par renforcement

Autre fonctionnalité en preview, dans le cadre de l’initiative Forward Deployed Engineers lancée avec EY : Frontier Tuning. Elle donne accès à un environnement managé d’apprentissage par renforcement. Microsoft prévoit de l’intégrer dans Copilot Studio et dans Foundry.

Une demi-douzaine de LLM maison, dont un flagship à 1T

Il y a aussi des nouveautés dans le catalogue de LLM Microsoft. Le flagship s’appelle MAI-Thinking-1. Il s’agit d’un MoE (35 milliards de paramètres actifs sur environ 1000 milliards), avec 256k de fenêtre de contexte. Microsoft compare ses performances à celles de Claude Opus 4.6 sur SWE-Bench Pro (codage). Il l’oppose aussi à Claude Sonnet 4.6 sur la préférence utilisateur (1276 tâches non spécifiées).

Dans la catégorie codage, il y a un modèle spécialisé : MAI-Code-1-Flash. Microsoft le compare notamment à Claude Haiku 4.5. Il l’a déployé dans GitHub Copilot au sein de VS Code.

Sur PowerPoint et OneDrive, on peut désormais utiliser MAI-Image-2.5 et sa variante Flash. Microsoft les compare essentiellement à Nano Banana 2 sur le leaderboard Image Edit d’Arena.

MAI-Transcribe-1.5 est en cours d’intégration dans Copilot, Teams, GitHub et Dynamics 365 Contact Centre. Microsoft affirme que ce modèle speech-to-text est « jusqu’à 5 fois plus rapide » que Gemini 3.1, Scribe v2 et GPT-4o-Transcribe sur « de longs fichiers audio ». Il l’a combiné à MAI-Image-2.5 ainsi qu’à MAI-Voice-2 (text-to-speech) dans le cadre d’une expérience appelée Duo AI et accessible dans son AI Playground.

Foundry, en connexion avec Fireworks AI

Autres modèles ajoutés au catalogue : ceux de Fireworks AI, dans Foundry. Au menu, du DeepSeek, du Google, du Meta, du Mistral AI, du Moonshot AI, du Qwen et du Zhipu AI.

L’intégration vient de passer en GA. Elle permet aussi l’inférence sur des modèles personnalisés. Bases possibles : Kimi (K2, 2.5 et 2.6), GLM (4.7 et 4.8), OpenAI (gpt-OSS-120b), Qwen (3.5-9B, 35B-A3B, 112B-A10B et 397B).

MDASH, une réponse à Claude Mythos

Autre GA : celle de l’intégration entre Defender et GitHub Code Security (composante de la suite GitHub Advanced Security). Nécessitant d’activer Defender CSPM, elle enrichit les vulnérabilités détectées dans le code en y apportant du contexte d’exécution.

MDASH, lui, est encore en preview. (accessible aux membres du programme Security Advisors). Il constitue la réponse de Microsoft à Claude Mythos : un « système de sécurité agentique » qui orchestre « plus de 100 agents spécialisés » pour détecter les vulnérabilités. Il a permis d’en trouver 16 – dont 4 RCE – sur la pile réseau/authentification de Windows (Microsoft les a corrigées dans son dernier Patch Tuesday). Une cinquantaine de partenaires se sont associés à l’initiative. Dont, en France, Atos, Capgemini et Genetec.

MXC, la perspective d’une sandbox « composable » pour exécuter les agents

Autre preview sur la partie sécurité : MXC (Microsoft eXecution Container). Le principe : fournir une sandbox « composable ». Capable en l’occurrence d’exploiter, sur Windows, Mac et Linux, plusieurs back-ends d’isolation, derrière un schéma de configuration unifié et un SDK TypeScript.

MXC est censé renforcer le « plan de contrôle agentique » Agent 365. Microsoft l’a intégré dans le CLI GitHub. NVIDIA l’exploite pour porter OpenShell sur Windows. OpenClaw l’utilise aussi, pour exécuter nœud et passerelle.

Illustration principale générée par IA

The post Build 2026 : ce que Microsoft met dans sa « plate-forme agentique » appeared first on Silicon.fr.

C’était pressenti, c’est acté : GitHub Copilot change de modèle économique.

Le 1^er juin 2026, des quotas de crédits remplaceront les quotas de requêtes premium actuellement intégrés dans les abonnements payants.

Un crédit équivaudra à 0,01 $. Ce qui donnera les quotas suivants :

Cette enveloppe de base pourra être élargie au besoin, dans des conditions que GitHub ne détaille pas en l’état.

Les forfaits annuels iront à terme avec un quota de requêtes… mais un usage restreint

Par défaut, les forfaits individuels souscrits sur base annuelle conserveront, jusqu’à échéance, des quotas de requêtes premium. Mais une bonne partie des modèles en consommeront davantage. Voici un aperçu des multiplicateurs qui s’appliqueront au 1^er juin pour les trois principales familles (Claude, Gemini, GPT).

Des pools de crédits sur les offres entreprise

Les titulaires de forfaits individuels contractés sur base annuelle pourront aussi les résilier et obtenir un remboursement au prorata. S’ils attendent l’échéance, le renouvellement ne sera pas automatique (passage sur le forfait gratuit).

Sur les forfaits GitHub Copilot pour les entreprises, les quotas de tous les utilisateurs seront regroupés en un pool au niveau de l’entité facturée. Ajouter des licences augmentera immédiatement la capacité de ce pool. En supprimer ne la réduira qu’au démarrage du cycle de facturation suivant.

Pour accompagner la transition, GitHub accordera, sur juin, juillet et août, 3000 crédits par mois pour chaque utilisateur sur le forfait Business et 7000 sur le forfait Enterprise. Début mai, il mettra à disposition des admins des projections de coûts, sur la base de l’usage du moins d’avril. Des budgets pourront être définis à quatre niveaux : entreprise, organisation GitHub, centre de coût et utilisateur.

Prévoir les coûts de la revue de code sera difficile

Saisie semi-automatique et suggestions d’édition ne consommeront pas de crédits, tout comme elles ne consomment actuellement pas de requête premium.

Il y aura, en revanche, une zone d’ombre sur la fonctionnalité de revue de code. La non-divulgation du modèle utilisé rend impossible de prévoir exactement les coûts. Ceux-ci se répercutent sur deux plans. D’un côté, les crédits. De l’autre, les minutes GitHub Actions que consomme l’infrastructure agentique (hors exécuteurs autohébergés).

Le passage aux crédits éliminera la possibilité actuelle de repli vers un modèle « low cost » en cas d’épuisement du quota de requêtes. Il faudra acheter des crédits supplémentaires. Chose que, d’ailleurs, qu’on ne devrait pas pouvoir faire si on a souscrit à GitHub Copilot via l’app mobile.

Tarifs applicables au 1^er juin pour les modèles GPT

Pour les modèles Claude

Pour les modèles Gemini

Illustration générée par IA

The post GitHub Copilot passe (essentiellement) à la facturation à l’usage appeared first on Silicon.fr.

La facturation au token, issue inévitable pour GitHub Copilot ?

Avec l’agentisation des workflows, le modèle économique à la requête n’apparaît pas tenable. GitHub en parle de plus en plus ouvertement. Et il prend des mesures. Officiellement, pour « protéger l’expérience des clients existants ».

Parmi ces mesures, il y a l’impossibilité temporaire de souscrire de nouveaux abonnements Pro, Pro+ et Étudiant. Il y a aussi un « resserrement des limites d’utilisation ». GitHub ne le chiffre pas, se contentant de rappeler que le forfait Pro+ inclut 5 fois plus de quota que le forfait Pro. Il a également décidé d’ajuster la disponibilité de certaines modèles. En tête de liste, Claude Opus, qui disparaît du forfait Pro.

Le fonctionnement en mode agent entraîne des sessions longues et des traitements parallélisés. De plus en plus d’utilisateurs dépassent les limites conçues pour maintenir la disponibilité du service, nous explique-t-on. Non sans reconnaître que l’utilisation engendre fréquemment des coûts supérieurs au prix des forfaits…

Ces limites sont de deux ordres. D’une part, un volume hebdomadaire de tokens, introduit récemment face à la massification des requêtes agentiques. De l’autre, un nombre de sessions sur une fenêtre temporelle non communiquée. L’une et l’autre évoluent au fil du temps.
La limite de tokens n’empêche pas d’utiliser les « requêtes premium » auxquelles chaque abonnement donne droit. En version gratuite, c’est 50 par mois en version gratuite. Sur les abonnements Pro et Pro+, c’est respectivement 300 et 1500, la requête supplémentaire coûtant 0,04 $.

Pour minimiser la consommation de tokens, GitHub recommande d’utiliser le mode plan, qui génère des plans d’implémentation structurés avant l’écriture d’un code. Il conseille par ailleurs de limiter l’usage de la commande /fleet, qui permet à GitHub Copilot de créer des sous-agents.

GitHub avait déjà mis un terme aux périodes d’essai

Il y a quelques semaines, GitHub était revenu sur ses problèmes de disponibilité, qui devenaient récurrents. Soulignant la « croissance extrême » de l’usage de sa plate-forme, il avait reconnu les « limites d’élasticité » d’une partie de son infrastructure.

L’entreprise avait notamment promis de revoir son système de cache et de « casser le monolithe » pour mieux isoler les dépendances-clés. Elle avait rappelé être en cours de migration vers Azure, avec l’objectif que la moitié de son trafic passe par la région US Central.

Début avril, GitHub avait déjà suspendu en partie l’accès au service : il avait mis un terme à toutes les périodes d’essai – y compris celles en cours – de son forfait Pro. Motif : une hausse des usages abusifs.

Récemment, l’approche a aussi changé sur la télémétrie. Désormais, sur les abonnements individuels, GitHub collecte par défaut les données d’interaction (inputs, outputs, commentaires, documentation…) pour entraîner ses modèles. Jusque-là, il s’en tenait aux interactions des employés de sa maison mère Microsoft.
La collecte par défaut s’étend au CLI GitHub Copilot. Avec là aussi une possibilité d’opt-out. Soit via une variable d’environnement (export GH_TELEMETRY=false ou export DO_NOT_TRACK=true), soit via une option de configuration (gh config set telemetry disabled).

Illustration générée par IA

The post Avec l’agentique, GitHub Copilot arrive au bout de son modèle économique appeared first on Silicon.fr.