À l’échelle agentique, un système où chaque nœud héberge une copie complète et autonome de l’historique Git n’est plus viable.

Anthropic, Cursor, GitHub et OpenAI s’accordent sur ce point. Chacun a entrepris de faire évoluer son système de gestion de versions en abandonnant le modèle purement décentralisé.

Anthropic abandonne Git pour un système propriétaire

Sur son monorepo interne, Anthropic est passé d’environ 2500 merges par jour en mai 2026 à plus de 30 000 en septembre. Avec un historique principal avoisinant 100 Go et près de 25 millions d’extractions quotidiennes pour le CI, l’utilisation classique de Git aurait exigé de transférer plus de 600 Po de données par jour. Le palliatif consistant à exécuter des centaines de miroirs et de snapshots de dépôts sur stockage objet était devenu ingérable.

Anthropic a opté pour une rupture avec Git. Il l’a remplacé par un système maison baptisé Scion et développé en 5 mois.

Exit, donc, le modèle décentralisé. Le serveur gère les opérations lourdes (merges, rebases, création des commits…) tandis que le client local se résume à une couche légère gérant un cache borné et la matérialisation à la demande des fichiers sur le disque.

Contrairement à un commit Git pointant vers un arbre complet d’objets, le changeset de Scion ne stocke que la liste des fichiers modifiés par rapport au premier parent. Cette liste est associée à des pointeurs adressés par contenu vers des blobs compressés.

Une approche asymétrique par changesets et caches hiérarchiques

De Git, Scion supprime aussi les packfiles. Il n’utilise, en parallèle, aucune copie totalement matérialisée du dépôt. La création d’un changeset s’effectue en temps proportionnel à la taille de la modification – et non à la taille du dépôt. Les références globales (branches, tags) sont strictement découragées hors de la branche principale ou des versions. Leur mise à jour se fait par CAS (compare-and-swap) sur une ligne de base Spanner.

Pour calculer rapidement le blame ou les graphes de commits, Scion génère des « données dérivées » (skip lists, index de chemins) définies récursivement et calculables à la demande. Le système expose ces primitives par API. CI et outils internes peuvent ainsi effecteur des requêtes sans cloner en local.

Le client communique via un socket avec un démon de nœud qui interroge des caches mémoire régionaux. Ces derniers s’alimentent auprès de serveurs d’autorité adossés à Spanner et au stockage objet. Un hiérarchie qui isole les pannes et supprime les protocoles de négociation de Git.

Anthropic affirme que cette infra consomme 200 fois moins de ressources calcul et mémoire que son ancienne flotte Git. Il ajoute que la CI a gagné 25 % de capacité CPU, avec des checkouts qui s’effectuent désormais en quelques secondes.

Cursor emploie un WAL S3 comme source de vérité unique

Cursor a conservé le format de stockage et les outils natifs de Git sur disques NVMe locaux. Pour surmonter les limites de Spokes (architecture historique de réplication de GitHub), il a conçu un moteur alternatif nommé Continuity. Il l’a appliqué à son monorepo et à une flotte de micro-dépôts.

Son architecture est centrée sur un concept propre à S3 : les journaux d’écriture anticipée (WAL, Write-Ahead Logs). Lesquels consistent, dans les grandes lignes, à stocker plusieurs objets dans un même fichier de manière séquentielle. Ici, chaque push prend la forme d’une entrée de WAL distincte. Aucun push n’est acquitté tant qu’il n’est pas persisté sur S3. Un fichier d’index de WAL mis à jour par CAS linéarise chaque transaction.

Les répliques sur disques NVMe locaux ne sont que des caches qu’on réhydrate depuis le WAL. La localisation des dépôts ne dépend pas d’une base relationnelle centrale. Si un nœud tombe ou qu’un dépôt n’est pas présent localement, il est matérialisé depuis le WAL.

N’importe quel nœud peut recevoir une écriture et agir comme primaire. L’atomicité du CAS sur S3 garantit l’intégrité. La propagation des lectures se fait via un commérage UDP, chaque réplique vérifiant son état contre la source de vérité.

Continuity monte à 120 pushs par seconde sur S3 Standard ; à plus de 300 avec S3 Express One Zone. On atteint ensuite la limite intrinsèque de vitesse de compaction Git sur disque. En lecture, le système a démontré une montée en charge linéaire jusqu’à 100 répliques sans impacter les écritures.

OpenAI opte pour la cohérence causale…

En deux ans, le volume de commits atterrissant sur la branche master du monorepo d’OpenAI a été multipliée par 25 environ. La fiabilité du contrôle de version était passée sous les 90 %. En 10 semaines, l’entreprise a développé Pando.

Ce back-end rejette l’idée qu’un serveur doit fournir un état cohérent de l’ensemble des branches à un instant T lors d’un clone ou d’un fetch. Les mises à jour de chaque branche sont indépendantes et sérialisables individuellement, mais Pando remplace le snapshot global par un modèle de cohérence causale. Un client qui récupère une branche respecte l’historique de l’auteur qui l’a créée, sans que le système impose d’ordre d’interclassement global avec les branches non liées. Deux clients qui lisent différentes branches au même moment peuvent donc voir des versions décalées dans le temps.

Traditionnellement, chaque fetch oblige le serveur à calculer dynamiquement la différence entre les objets que détient le client et ceux demandés. Puis à compresser un packfile sur mesure. Pando réutilise des packfiles immuables préexistants. Les serveurs n’ont par conséquent plus à recalculer de deltas à la volée.

Lors d’un push, le packfile qu’envoie le client est validé en une seule passe et streamé directement vers le stockage objet, sans déballage local. Une transaction enregistre une « version de référence » dans le magasin de métadonnées et bascule le pointeur de la branche de façon atomique. Lors de la phase de négociation du push, Pando n’annonce pas l’intégralité de ses branches. Cela évite de créer des packs trop interdépendants ou trop fragmentés.

… et pour des packfiles réutilisables

Pour transférer les données, Pando utilise packfile-url, directive Git qu’OpenAI a perfectionnée en amont dans le projet open source. Lors d’un fetch, la réponse HTTP principale renvoie un packfile vide accompagné d’une liste d’URI pointant vers les packfiles requis. Les clients téléchargent ces packs depuis Express, un service de cache régional distribué. Cela permet de maximiser l’usage de la bande passante réseau sans solliciter le CPU sur le serveur.

Chaque push génère un pack de niveau L0. Des processus en tâche de fond regroupent géométriquement l’ensemble des packs en couches supérieures (L1 à L4) pour améliorer la compression et accélérer les extractions.

OpenAI explique que Pando a réduit la latence médiane des pushs de près de 80 %. Et qu’il permet de délivrer près de 1 Po de données Git par jour avec « une poignée » de cœurs CPU.

GitHub modernise Spokes grâce aux quorums par référence

En un an, le volume de commits qu’a enregistrés GitHub a plus que quintuplé : 7,38 milliards en septembre 2026, pour 3,35 milliards de pushs.

L’architecture qu’il a commencé à déployer en production minimise la coordination. Le quorum et le protocole 3PC (verrouillage des commits en 3 étapes) ne portent plus sur l’ensemble du dépôt. Ils sont isolés au niveau de chaque référence (branche) individuelle. Les agents qui travaillent en parallèle sur des branches distinctes ne subissent plus de contention mutuelle. Les étapes lourdes (écriture des objets, validation de connectivité, analyse des secrets) se déroulent hors du chemin critique. L’étape de coordination se réduit donc au déplacement du pointeur de référence. Les tests internes ont démontré un débit d’écriture 3 à 4 fois plus élevé sur les dépôts concurrents.

Comme ses pairs, GitHub a découplé le stockage du calcul. Il a confié les données d’autorité au stockage objet Azure. Un nœud de calcul éphémère intègre le quorum de vote comme passerelle. Il streame les écritures, agrège les transactions de branches disjointes en un nombre réduit d’E/S, puis s’occupe de la compaction. D’autres nœuds temporaires sont instanciés à la demande pour absorber les pics de lecture. Ils réconcilient leur cache en arrière-plan avec Azure Blob Storage. Des workers indépendants gèrent le décompactage, le repacking et le nettoyage des objets orphelins.

Dans son architecture cible, GitHub annonce un gain potentiel de débit d’écriture allant jusqu’à un facteur 35. Tout en assurant une montée en charge autonome de la couche de lecture.

Illustration générée par IA

The post Anthropic, Cursor, GitHub, OpenAI : 4 approches pour passer Git à l’échelle agentique appeared first on Silicon.fr.

On y est : sur GitHub Copilot, routage et orchestration convergent.

Par « routage », il faut entendre le mode Auto. Introduit en début d’année. Il a connu deux incarnations. La v1 utilisait un encodeur ModernBERT pour aiguiller les requêtes en fonction de la disponibilité des modèles et de leurs capacités. La v2, appelée HyDRA (Hybrid Dynamic Routing Architecture), exploite le même type de classifieur, mais entraîné pour évaluer les besoins, sur 4 dimensions : raisonnement, génération de code, débogage et utilisation d’outils. Elle intègre par ailleurs des contraintes d’exploitation comme la continuité de session et le filtrage dynamique des pannes.

La partie orchestration est plus récente. GitHub avait commencé à l’expérimenter début septembre, sous le nom HydraFusion. Promesse : pour chaque prompt, choisir non pas le modèle optimal, mais le workflow optimal, entre trois options :

• Réalisation de la tâche par un modèle unique
• Intervention d’un LLM juge qui peut valider ou décider de confier la tâche à un autre modèle
• Boucle d’itération avec un modèle critique n’intervenant qu’en lecture

Les modèles locaux restent en preview

De la convergence des deux briques naît le mode Fusion. ll peut fonctionner à quatre niveaux d’effort : Standard, High, Max et Fast, ce dernier n’étant pas réglable par l’utilisateur (il est réservé au chat inline de VS Code).

Le niveau Standard est accessible sur tous les forfaits Copilot. Les niveaux High et Max ne sont disponibles que sur les abonnements Pro+, Max, Business et Enterprise. Tandis que le mode Auto octroyait 10 % de réduction sur le prix des modèles, GitHub propose 30 %… mais pour une durée limitée (jusqu’à fin nonvembre).

Côté admin, on peut choisir d’activer Fusion par défaut dans le sélecteur. Et contrôler le pool de modèles, ainsi que le niveau d’effort par défaut pour les nouvelles conversations.

L’intégration des modèles locaux reste en preview. Elle en concerne pour le moment deux :

• MAI Code 1.1 Flash, utilisable sur Windows via le CLI et l’application GitHub Copilot ou VS Code
• Qwen3.8 Flash, utilisable sur Windows, Mac et Linux via le CLI

Premiers résultats mitigés chez Michelin

Les quelques semaines de test ont fait ressortir, entre autres points de frustration, le manque de feed-back pendant l’exécution des tâches. GitHub a notamment pris le parti de ne pas afficher les résultats des étapes intermédiaires. Motif : éviter qu’on les perçoive comme du travail fini…

On a aussi suggéré à GitHub d’exposer, plutôt que la chaîne de pensée, de la télémétrie structurée. Par exemple, la stratégie d’exécution choisie, les familles de modèles utilisées ou les motifs de rejet de résultats.

Michelin a fait partie des entreprises qui ont essayé HydraFusion. Il en a témoigné mi-septembre. Son bilan était mitigé. De son avis, cet orchestrateur n’était pas un substitut au mode Auto, mais un « mécanisme de qualité »… au prix nettement plus élevé.

Nombre de retours utilisateurs lui ont fait écho. Dans les grandes lignes : HydraFusion a tendance à choisir des modèles trop performants. Et à ne pas exploiter de sous-agents « économiques » à moins qu’on le demande explicitement.

Illustration générée par IA

The post GitHub Copilot fusionne finalement routeur et orchestrateur appeared first on Silicon.fr.

GitHub n’a jamais hébergé autant d’activité. Au cours des douze derniers mois, les développeurs ont poussé du code sur la plateforme à 17,9 milliards de reprises, davantage qu’en 2024 et 2025 réunies. Le nombre de commits a atteint 34,3 milliards, tandis que les pull requests fusionnées ont dépassé 1,3 milliard. Dans le même temps, les agents d’intelligence artificielle s’installent dans les habitudes de développement. C’est dans ce contexte que GitHub entend faire évoluer son offre.

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.

Début août, Anthropic annonçait que les textes générés par Claude porteraient bientôt une marque invisible, censée permettre de repérer un contenu écrit généré par IA. Une annonce accueillie froidement et qui voit naître son lot d’outils pour contrecarrer la mesure.

Un incident affecte plusieurs services critiques de GitHub ce lundi 17 août. La plateforme évoque un taux d'erreur d'environ 20% sur de nombreuses fonctionnalités.

Depuis ce printemps, sachez qu'un git clone ordinaire peut maintenant récupérer un dépôt qui n'existe sur aucun serveur spécifique. En fait, le code est stocké dans Freenet, le réseau pair-à-pair qu'Ian Clarke a relancé en mars. Et comme y'a plus d'hébergeur, bah y'a plus personne pour fermer un compte ou shooter le dépôt.

Car Git est décentralisé depuis toujours et fonctionne très bien comme ça, puisque chaque clone contient l'historique complet, ce qui permet à 2 clones de se synchroniser directement. Ce qui lui manquait par contre, c'était l'hébergement, et c'est là-dessus que les forges que nous connaissons, Github en tête, sont venues capitaliser. Y'a bien des initiatives comme Grasp qui essaie d'en sortir grâce au protocole Nostr mais freenet-git lui range carrément le dépôt dans un contrat que les nœuds recopient, et se publie lui-même à l'adresse freenet::99TmCayXn6Tm/freenet-git.

Cloner ou publier du code exige donc le paquet freenet-git et un nœud qui tourne sur votre machine, ce qui fait qu'on ne supprime pas vraiment le serveur, mais on le ramène juste chez soi.

Charger la vidéo depuis YouTube Ce clic autorise une connexion à Google : adresse IP transmise et traceurs possibles. En savoir plus Voir cette vidéo sur YouTube

Le socle compte plus que l'application dans cette présentation. Les contrats et les delegates forment la couche où une app tourne sans backend, et quatre tournent déjà dessus : River pour le chat de groupe, Delta pour les sites, Atlas pour la recherche, et freenet-git pour le code. Mail, Raven et Harvest existent aussi, à un stade plus jeune.

L'adresse du dépôt sort des 12 premiers caractères de la clé publique de son propriétaire, et à ce stade expérimental, lui seul peut pousser dedans. Y'a pas non plus de pull requests, ni d'issues puisque c'est le modèle du noyau Linux d'avant les forges, où chacun publie son clone et le mainteneur vient y piocher ce qui l'intéresse.

Reste le plus dur maintenant, retrouver un dépôt.

Car sans annuaire, un nœud doit deviner lequel de ses voisins mettra le moins de temps à trouver ce qu'on lui demande. Le réseau traite ça comme un problème d'apprentissage et parie sur le bon voisin à partir des requêtes passées grâce à Renegade, une bibliothèque open source sortie en 2021, capable de faire ce calcul.

Installer freenet-git

Il faut une chaîne Rust, et ~/.cargo/bin doit être dans votre PATH. Les installeurs du nœud sont sur freenet.org/quickstart.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Rust n'entre dans le PATH qu'au shell suivant, donc ouvrez un nouveau terminal avant la commande d'après. Elle dépose deux binaires, freenet-git et le remote helper que Git appellera tout seul.

cargo install freenet-git

Cloner un dépôt qui existe déjà

Aucune identité n'est nécessaire pour lire. La bibliothèque standard de Freenet fait un bon test, elle porte son historique complet et ses tags.

git clone freenet::96rknpy1GYhZ/freenet-stdlib

Publier le vôtre

C'est create qui publie réellement le contrat. Il affiche PUT confirmed by host et l'adresse du dépôt, dont le préfixe se recopie dans le remote. La phrase de passe voyage par une variable d'environnement parce que Git garde la main sur l'entrée standard durant le push.

freenet-git init-identity --name "Votre Nom" --email vous@example.com
cd ~/code/mon-projet
freenet-git create --name mon-projet
# -> URL: freenet:VOTRE_PREFIXE/mon-projet
git remote add freenet freenet::VOTRE_PREFIXE/mon-projet
export FREENET_GIT_PASSPHRASE='votre-phrase-de-passe'
git push freenet main

Et voilà ! Avec ça vous pouvez faire du vrai git décentralisé même si la vraie limite est ailleurs...

En effet, les nœuds gardent en cache ce qu'on leur réclame et évacuent le reste, donc un dépôt que personne ne clone finit au bout d'un moment par ne plus être clonable. Et ça c'est dommage... C'est pourquoi une commande (rescue), le remet en circulation depuis une machine qui a encore les données. Le projet ne présente toutefois pas ça comme un bug, mais comme son modèle de durabilité actuel.

Mais autant le savoir avant d'y déposer votre code.

Source

Dark Hours est à l'origine une petite web app qui vous dit ce qu'il y a à voir dans le ciel ce soir et si ça vaut le coup de mettre le museau dehors. Le développeur Terry Godier l'a construite avec l'aide de Claude et lancée début août mais au moment où j'écris ces lignes, elle n'existe plus... En effet, son site darkhours.io redirige maintenant vers DarkHours.app , un autre projet signé Miguel Beher et sous licence MIT.

C'est ce dernier qui a vu le problème, et je vais vous expliquer...

En fait, les 2 apps avaient non seulement le même nom, mais également les mêmes fonctions, et le même nom de domaine (à part le TLD). Quand Beher a signalé le souci à Godier , ce dernier a d'abord proposé de changer de nom et de différencier les fonctionnalités mais une heure plus tard il retirait tout, annulait l'app iOS qu'il préparait, et publiait un mea culpa où il parle de son "usage irresponsable de l'IA".

Et ce qui l'a décidé à tout stopper comme ça, c'est juste un bug. En effet, son application envoyait les gens observer les étoiles au milieu de champs perdus au Mexique, ou dans l'océan Pacifique et Beher avait exactement le même souci de son côté à ce moment-là (il l'a résolu depuis).

Alors se ressembler sur des fonctionnalités, ça arrive et ça ne me choque pas mais se ressembler jusque dans les bugs, là ça pique un peu beaucoup. Les procès en pompage IA, j'en ai déjà parlé , et ils se trompent souvent de coupable, et dans le cas de Godier, celui-ci n'a pas pompé le code du Dark Hours original. Non, il a juste développé son app avec Claude Code, sans se poser trop de question.

Pour lui, il est juste parti d'un code d'éphémérides qu'il a écrit en janvier mais comme Dark Hours est un projet open source, et bien ce qui s'est passé, c'est que son agent IA a récupéré de gros bouts de cette app, jusqu'à son nom pour en faire sa nouvelle app. Hé oui, la vie c'est facile quand on se repose sur le code des autres.

Dark Hours, le vrai

En effet, Claude Code, Codex et les autres sont des outils connectés. Ils lisent des pages, clonent des dépôts, fouillent GitHub quand ça les arrange, du coup, si votre demande ressemble à un truc qui existe déjà, et bien l'agent peut aller le consulter et s'en servir de modèle. Et même sans aller sur le net, comme les modèles ont été entraînés sur tout ce qui traîne publiquement sur le net, dépôts de code compris, il est capable de restituer une structure vue mille fois, sans même aller la chercher sur le net. Un peu comme les modèles de diffusion d'images qui reproduisent le style des artistes.

C'est pour ça que je trouve la mésaventure de Godier et Beher intéressante. Ça nous enseigne qu'il faut faire extrêmement attention quand on code avec l'IA. Pour limiter les risques qu'elle aille se servir dans du code libre, il faut donc indiquer expressément à l'agent de NE PAS récupérer le code source de projets open source, ne pas l'analyser, ne pas pomper du code ni les interfaces. Bref, lui dire qu'on part d'une page blanche...

C'est le même principe que celui de la clean room qui a permis à Compaq de cloner légalement le BIOS d'IBM, comme on peut le voir dans la série Halt and Catch Fire... On implémente les bonnes idées, mais jamais les lignes de code.

Charger la vidéo depuis YouTube Ce clic autorise une connexion à Google : adresse IP transmise et traceurs possibles. En savoir plus Voir cette vidéo sur YouTube

Pour ma part, je fais quasiment que des outils internes et des bidules perso, mais je le précise quand même pour que tout soit clean. Toutefois, ça ne règle pas le problème de l'entraînement qui a été fait en amont pour forger le modèle IA.

Donc avant de coder, deux réflexes à avoir : 1/ Chercher le nom de votre app (ou de votre nouvelle entreprise) pour de vrai, ce qui vous évitera de vous lancer dans un move de contrefaçon sans le savoir. Et 2/ Installer tout ce qui existe dans le même genre pour être sûr de ne pas vous faire berner par l'IA... Sachez que rien que cette année, j'ai été victime moi-même 2 fois, de gens qui n'ont pas pris ces précautions et qui se sont attribués les noms de mes projets pour leurs propres trucs en se reposant, je le suppose, uniquement sur l'IA sans se poser la moindre question. Pour l'un des projets, VoxDrop, j'ai changé le nom en Kassis pour pas me prendre le chou car c'était un projet jeune. Mais pour l'autre problème, c'est plus épineux et je ne peux pas vous en parler encore mais rassurez-vous, dès que je le pourrais, vous ferai un article qui détaillera tout en détail pour vous raconter cette histoire hallucinante qui m'arrive.

Après, ce que je vous conseille de faire aussi c'est qu'une fois que votre projet est fini, pensez à lancer une phase de contrôle. Ça personne ne le fait, mais c'est pas mal de récupérer le code des projets qui vous ont inspiré ou projet concurrents, de le poser à côté du vôtre et faire vous-même ou demander à un agent IA une comparaison, un peu comme la passe sécurité que vous faites en fin de projet.

Reprendre une fonctionnalité qu'on trouve bien ailleurs et la réimplémenter dans son projet, c'est normal et c'est ce que tout le monde fait d'ailleurs. Mais reprendre le nom, le look de l'interface et le code, qui plus est, sans mentionner la licence, c'est vraiment moche. Et c'est exactement ce que peut faire votre agent IA dans votre dos, alors soyez vigilant parce qu'après, vous pourrez dire que vous ne le saviez pas, tout le monde vous traitera de voleur. La frontière est là, et il n'y a qu'une comparaison explicite du code et de l'interface qui vous dira de quel côté vous êtes tombé...

Source

JFrog, une société spécialisée dans la sécurité de la chaîne logicielle, a passé au crible les 55 vulnérabilités déposées par un seul compte GitHub. Cinquante-quatre étaient entièrement fabriquées, une seule décrivait un vrai bug.

Six d'entre elles visaient SQLite, la petite base de données embarquée qu'on retrouve dans à peu près tous les téléphones et navigateurs de la planète, avec des scores de gravité affichés jusqu'à 9,8 sur 10. Les quarante-neuf autres s'en prenaient à libraw, une bibliothèque de traitement d'images, et à un module audio pour cartes ESP32.

Les rapports ne résistent pas à une vérification. L'un s'appuie sur une fonction qui n'existe pas dans la version de SQLite qu'il prétend attaquer. Un autre cite les lignes 3555 et 3575 d'un fichier qui n'en compte que 2706.

Ces failles n'ont été bloquées à aucune étape. Elles ont atterri dans le NVD, la base de référence américaine des vulnérabilités, avec un enrichissement fourni par la CISA, l'agence fédérale de cybersécurité, qui a validé les scores critiques au passage. Red Hat a dû redescendre l'une d'elles de 10 sur 10 à 7,6.

Le formulaire public par lequel on déclare une faille ne vérifie pas sérieusement l'identité du déclarant. Aucune étape du processus n'exige de preuve de concept ni la moindre reproduction du bug. Un texte plausible suffit.

Le reste est automatique. La fiche descend dans les bases dérivées, puis dans les scanners que les entreprises font tourner sur leur propre code, et une équipe finit par chercher un correctif à un problème qui n'a jamais existé. MITRE, l'organisme qui attribue ces identifiants, a rejeté le lot le 1er août.

Le NIST, chargé d'analyser ces fiches, avait déjà plus de 27 000 vulnérabilités en attente fin 2025, et un rapport officiel de mai dernier lui reprochait un manque de planification et de décision.

Les mainteneurs de logiciels libres décrochent. Le projet curl a fermé son programme de primes début 2026, après sept ans, son taux de rapports confirmés étant passé de 15 % à moins de 5 % sous le déluge de textes générés par IA.

Daniel Stenberg, qui le maintient, a ensuite fermé le guichet aux signalements du 1er juillet au 3 août. Bref, ce qui faisait tenir le système, c'est que fabriquer un faux rapport crédible demandait du temps à quelqu'un.

Source et visuel : The Register et JFROG

Le 23 juillet à 23h16 précisément, GitHub reçoit une notice du ministère de l'Intérieur indien avec un compte à rebours de seulement 3 heures. Ce qu'exige cette notice c'est de faire disparaître 3 dépôts de code, et pas n'importe lesquels. Ceux de bitchat , la messagerie Bluetooth de Jack Dorsey qui fonctionne sans le moindre réseau.

Trois jours plus tôt, le 20 juillet, des étudiants du Cockroach Janata Party manifestent à Jantar Mantar, en plein centre de Delhi, et réclament la démission du ministre de l'Éducation.

La police disperse leur marche à la matraque et au gaz lacrymogène, ferme des stations de métro et coupe l'internet mobile autour du site. Alors au bout de 2 jours de coupure, les manifestants basculent sur des applis qui n'en ont pas besoin.

Bitchat, sorti l'été dernier, fait exactement ça. Chaque téléphone discute en Bluetooth Low Energy avec ceux qui sont à sa portée, soit une trentaine de mètres, et relaie les messages de proche en proche. Dans une foule dense, la chaîne de relais pousse alors la portée à 300 mètres et plus.

Aucun compte à créer et aucun numéro de téléphone à fournir. Il n'y a pas non plus de serveur central, et les messages privés passent par du chiffrement Noise Protocol. Puis quand le réseau revient, l'application bascule sur le protocole Nostr pour la portée mondiale.

Le code iOS de Bitchat est dans le domaine public, tout comme la version Android en GPL-3.0. Dorsey avait d'ailleurs ressorti la même boîte à outils il y a quelques jours avec Buzz, son chat d'équipe .

L'application, dit la notice de l'Indian Cybercrime Coordination Centre, "permet la communication même pendant des restrictions réseau" et crée "un risque substantiel d'utilisation abusive par des éléments antinationaux, des organisations terroristes, des groupes criminels organisés". Plus loin, on lui reproche une architecture qui entrave "l'interception légale, l'attribution et l'enquête". En clair, le reproche c'est de continuer à marcher quand l'État a coupé le net.

Côté droit, l'ordre s'appuie sur la Section 79(3)(b) de l'IT Act et la Rule 3(1)(d) des IT Rules, c'est-à-dire les articles en Inde qui protègent les hébergeurs de la responsabilité des contenus publiés par leurs utilisateurs.

Les infractions listées, elles, vont de l'accès non autorisé à un système informatique à la complicité, plus trois articles du nouveau code pénal indien sur le complot criminel et l'atteinte à l'unité nationale. Oui, oui, pour un dépôt de code... Bien sûr, l'Internet Freedom Foundation qualifie la manœuvre d'"inconstitutionnelle et autoritaire" et lui reproche de court-circuiter la procédure de blocage officielle. Certes, la Section 79 conditionne une immunité, mais elle n'ouvre absolument pas un droit de censure, puis surtout, cette notice ne désigne aucun message ni aucun fichier illicite précis mais vise le projet entier. Bref, c'est trop vague !

Et même si les rêves les plus humides du gouvernement indien se réalisaient, retirer un dépôt ne retire pas grand-chose. Si vous avez déjà l'app sur votre téléphone, elle y reste, et un maillage qui ne dépend d'aucun serveur continue de faire circuler les messages quoi qu'il arrive à la page GitHub.

MediaNama écrit que GitHub a obtempéré et retiré les liens de sa plateforme. Comme j'y ai encore accès, je pense que ça ne concerne que l'Inde et que Github a fait ça en mode géoblocage. Mais bon, peu importe, ça + l'effet Streisand, dans les heures qui ont suivi la notice, le code était de toute façon recopié sur d'autres sites. Il est sous licence libre, donc il peut être forké dans tous les sens.

En tout cas, ce n'est pas la première fois que cette messagerie sert de plan B à la population puisqu'au Népal, en septembre 2025, elle a été téléchargée près de 49 000 fois en une seule journée durant les manifestations Gen Z, soit près de 40 % de son adoption mondiale sur ce seul pays. Couper le réseau pour calmer une foule, l'Égypte avait déjà essayé en janvier 2011 , la Syrie quelques mois plus tard et on le sait, ça ne fonctionne pas.

Source

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.