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.

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.

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.

	Anciens plafonds	Nouveaux plafonds
Faible	2000 $	250 $
Moyenne	10 000 $	2000 $
Élevée	20 000 $	5000 $
Critique	30 000 $	10 000 $

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.

Niveau de sévérité	Exemples de vulnérabilités
Critique	– Exécution de commandes arbitraires sur un serveur de prod – Exécution de requêtes SQL arbitraires sur une base de données de prod – Accès à des systèmes de production internes – Accès aux données d’un autre utilisateur dans GitHub Actions
Élevée	– Contournement de la logique d’autorisation pour dépasser les droits d’accès d’un collaborateur – Découverte de données sensibles d’un utilisateur ou de GitHub dans une ressource publiquement accessible – Suppression d’un dépôt ou d’un paquet qui devrait être inaccessible – Transmission d’authentifiants depuis une application cliente vers un serveur inattendu
Moyenne	– Divulguer les intitulés d’issues dans des dépôts privés – Compromettre l’intégrité d’un package – Injecter du contenu sur GitHub.com sans contourner la Content Security Policy ni exploiter la session d’un autre utilisateur
Faible	– Déclencher des exceptions qui pourraient affecter beaucoup d’utilisateurs – Exfiltrer des authentifiants dans des logs – Activer une fonctionnalité en accès anticipé pour un utilisateur sans son consentement

* 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.

Bonne nouvelle pour tous ceux qui balancent du code sur PyPI. L'index officiel des paquets Python refuse désormais tout nouveau fichier ajouté à une release qui a plus de 14 jours. Le correctif vient de Seth Larson, développeur sécurité en résidence à la Python Software Foundation, et il colmate un trou que personne n'avait encore exploité sur PyPI... mais qui traînait là, grand ouvert.

Jusqu'ici, un mainteneur pouvait ajouter un fichier à n'importe quelle release, même sortie il y a 3 ans. Pratique pour livrer une nouvelle wheel, dangereux si un token de publication se fait voler. Un attaquant avec vos clés pouvait glisser un binaire vérolé dans une version stable que tout le monde télécharge depuis des lustres, sans déclencher la moindre alerte. Larson le dit sans détour : si ça n'a pas encore été abusé, c'est juste que les pirates n'avaient pas réalisé que c'était possible.

Le déclencheur, c'est l'affaire LiteLLM et Telnyx, deux paquets populaires compromis en mars dernier via une "référence mutable" dans leur usage de la GitHub Action Trivy. Encore une compromission de la chaîne d'appro, dans la lignée de Shai-Hulud sur npm dont je vous ai déjà parlé avec son scanner dédié , même si le mécanisme n'est pas le même. Le sujet mijotait depuis janvier 2024 dans les discussions autour de PEP 740, sauf qu'il coinçait sur un cas d'usage bien réel. En effet, certains projets ajoutent le support d'une nouvelle version de Python, genre les wheels cp314 pour Python 3.14, à d'anciennes releases longtemps après leur sortie.

Sauf que les chiffres ont tranché. En interrogeant la base PyPI sur les 15 000 paquets les plus populaires, seuls 56 avaient publié une wheel compatible 3.14 plus de 14 jours après une release. 56 sur 15 000, autant dire une poignée. Mike Fiedler, l'ingénieur sécurité de PyPI, a donc porté le débat au Packaging Summit de la PyCon US 2026, et le consensus est tombé. Il est maintenant demandé à ces projets de bumper vers une nouvelle version.

Après ne prenez pas cette nouvelle mesure de sécurité comme une garantie. Il n'existe aucune API pour vérifier qu'une release est "fermée", et les vraies règles du jeu ne seront gravées dans le marbre qu'avec l'API Upload 2.0 et les Staged Previews prévus par PEP 694. Donc pour l'instant, c'est un verrou qui protège, mais pas un vrai contrat de confiance sur lequel bâtir (De quoi Darty ??).

N'empêche que le bénéfice est immédiat car ça fait moins de ménage pour les admins PyPI quand un projet se fait trouer, et s'en est fini de l'état schizophrène où une release est à moitié compromise, à moitié saine, avec quelques fichiers vérolés planqués au milieu. Une vieille release devient un bloc figé, et voilà !

GitHub avait déjà dégainé la même idée avec ses releases immuables , qui rendent vos versions intouchables même par le mainteneur du projet.

Bref, une porte de moins pour les attaquants supply chain. Sympa non ?

Source (repéré chez Simon Willison)

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.

Injection de prompt et injection SQL, même concept ?

En SQL, la frontière est claire entre instructions (ce que le moteur de base de données « fait ») et données (ce qui est « stocké » ou « utilisé » dans une requête). Pour empêcher les injections, il faut garantir cette séparation. La solution réside dans les requêtes paramétrées : peu importe les entrées, la base de données ne les interprète jamais comme des instructions.Avec les LLM, faute de distinction « native » entre données et code, il paraît beaucoup plus difficile d’empêcher les injections de prompts. Des techniques émergent néanmoins. Par exemple, expliquer à un modèle la notion de « data ». Ou l’entraîner à prioriser les « instructions » par rapport aux « données » qui y ressemblent.

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 :

Forfait	Prix mensuel	Crédits
Pro	10 $	1000
Pro+	39 $	3900
Business	19 $/utilisateur	1900
Enterprise	39 $/utilisateur	3900

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).

Modèle	Multiplicateur actuel	Nouveau multiplicateur
Claude Haiku 4.5	0,33	0,33
Claude Opus 4.5	3	15
Claude Opus 4.6	3	27
Claude Opus 4.7	7,5	27
Claude Sonnet 4	1	1
Claude Sonnet 4.5	1	6
Claude Sonnet 4.6	1	9

 

Modèle	Multiplicateur actuel	Nouveau multiplicateur
Gemini 2.5 Pro	1	1
Gemini 3 Flash	0,33	0,33
Gemini 3 Pro	1	6
Gemini 3.1 Pro	1	6

 

Modèle	Multiplicateur actuel	Nouveau multiplicateur
GPT-4o	0	0,33
GPT-4o mini	0	0,33
GPT-4.1	0	1
GPT-5.1	1	3
GPT-5.1-Codex	1	3
GPT-5.1-Codex-Mini	0,33	0,33
GPT-5.1-Codex-Max	1	3
GPT-5.2	1	3
GPT-5.2-Codex	1	3
GPT-5.3-Codex	1	6
GPT-5.4	1	6
GPT-5.4 mini	0,33	6
GPT-5 mini	0	0,33

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

Modèle	Input	Input en cache	Output
GPT-4.1	2 $	0,5 $	8 $
GPT-5 mini	0,25 $	0,025 $	2 $
GPT-5.2	1,75 $	0,175 $	14 $
GPT-5.2-Codex	1,75 $	0,175 $	14 $
GPT-5.3-Codex	1,75 $	0,175 $	14 $
GPT-5.4	2,5 $	0,25 $	15 $
GPT-5.4 mini	0,75 $	0,075 $	4,5 $
GPT-5.4 nano	0,2 $	0,02 $	1,25 $
GPT-5.5	5 $	0,5 $	30 $

Pour les modèles Claude

Modèle	Input	Input en cache	Écriture cache	Output
Claude Haiku 4.5	1 $	0,1 $	1,25 $	5 $
Claude Sonnet 4	3 $	0,3 $	3,75 $	15 $
Claude Sonnet 4.5	3 $	0,3 $	3,75 $	15 $
Claude Sonnet 4.6	3 $	0,3 $	3,75 $	15 $
Claude Opus 4.5	5 $	0,5 $	6,25 $	25 $
Claude Opus 4.6	5 $	0,5 $	6,25 $	25 $
Claude Opus 4.7	5 $	0,5 $	6,25 $	25 $

Pour les modèles Gemini

Modèle	Input	Input en cache	Output
Gemini 2.5 Pro	1,25 $	0,125 $	10 $
Gemini 3 Flash	0,5 $	0,05 $	3 $
Gemini 3.1 Pro	2 $	0,2 $	12 $

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.