Le média Distilled a recoupé trois permis de construire déposés auprès des autorités texanes avec des images satellite montrant un défrichement démarré le 24 juillet. Amazon a confirmé derrière : le projet GW Ranch, dans le comté de Pecos, est bien le sien.
La centrale est développée par Pacifico Energy sur un terrain de plus de 8 000 acres, soit environ 3 240 hectares. Elle alignera jusqu'à 35 turbines à gaz pour 7,65 gigawatts, complétées par 1,8 GW de stockage sur batteries et 750 mégawatts de solaire installés sur place.
La particularité du projet, c'est son raccordement : il n'y en a pas.
GW Ranch fonctionne en réseau privé, isolé d'ERCOT, le réseau électrique texan. Amazon a acheté le site et achètera l'électricité produite, sans passer par la file d'attente d'interconnexion qui immobilise les autres projets pendant des années. C'est le premier campus de data centers IA hors réseau de l'entreprise.
L'argument commercial est prêt depuis longtemps. Amazon explique que son campus est alimenté par une production nouvelle sur site qui n'augmentera pas la facture d'électricité des familles texanes, et techniquement, c'est exact.
Le permis délivré en janvier par la TCEQ, l'agence environnementale du Texas, autorise jusqu'à 33 millions de tonnes de CO2 par an. La centrale au charbon la plus émettrice du pays, James H. Miller Jr. en Alabama, tourne autour de 16 millions de tonnes. Le plafond texan est donc au double.
Ce chiffre reste un plafond d'autorisation et pas une prévision, puisqu'une centrale ne tourne jamais à pleine charge toute l'année. Mais un permis calibré à ce niveau signifie que l'exploitant s'est ménagé la place pour le faire.
Le calendrier est serré. Premier électron visé au premier trimestre 2027, un gigawatt en service en 2028, cinq gigawatts et plus d'ici 2031. Pacifico avait annoncé le projet à 5 GW, il est monté à 7,65 en cours de route.
Trente-cinq turbines à gaz allumées en 2026 pour faire tourner des modèles d'IA, ça pique un peu quand même.
Environ 59 projets du même genre sont annoncés aux États-Unis, pour près de 90 GW cumulés. Amazon reste signataire du Climate Pledge, qu'elle a cofondé. Interrogée sur cette situation, l'entreprise répond que le monde est différent de ce qu'il était à l'époque. Ah ben d'accord.
Source : Distilled.earth
Le Fire TV Stick 4K Select d'Amazon ne tourne pas sous Android. Il tourne sous Vega OS, un système maison basé sur Linux, et ça va foutre en l'air vos projets de player pour votre média center puisque les applications Android n'y ont plus cours, et que l'installation manuelle est verrouillée.
Il n'y a donc plus de bascule "sources inconnues" planquée dans les réglages, comme sur les Fire TV sous Android. Rien que pour faire apparaître les options développeur, il faut d'abord enregistrer l'appareil auprès d'Amazon avec un compte développeur et même comme ça, aucun APK Android ne se lancera.
Résultat, Kodi ne tourne pas ! L'application avait déjà été retirée du store d'app Amazon en 2015, mais on la réinstallait tous à la main sur les anciens sticks. Eh bien ce contournement n'est plus possible et côté Jellyfin, malheureusement, le projet n'a toujours pas sorti de client pour Vega OS.
Bref, Amazon a verrouillé la machine au nom de la sécurité et de la chasse au piratage, comme prévu puisque je vous en parlais déjà en novembre dernier . Sauf que le même verrou bloque aussi la lecture des fichiers qui dorment par exemple sur votre NAS, même si vous les avez rippés vous-même, peu importe que ce soit le dernier Avatar ou une vidéo de vacances.
Et ce n'est pas un accident de parcours sur un modèle d'entrée de gamme puisque sur sa page développeur , Amazon écrit qu'à partir du 4K Select, tous les futurs Fire TV Stick tourneront sous Vega, donc il n'y aura plus de retour arrière, désolé...
Par contre, les modèles sous Fire OS restent en vente pour l'instant, et eux acceptent toujours l'installation manuelle. Donc si vous comptiez remplacer le vôtre un jour, vérifiez le nom exact de la référence avant de commander, c'est maintenant que ça se joue !
Sur un stick qui serait déjà passé à Vega, il reste toutefois Astra, un client tiers compatible Jellyfin et Emby, dispo sur le magasin Amazon mais limité à une lecture basique. Plex passe aussi, mais en H.264 seulement, sauf à transcoder côté serveur. Et de son côté l'équipe Jellyfin dit travailler sur un vrai client Vega sans annoncer de date... Voilà, donc pour le moment c'est compliqué avec Vega mais j'ai bon espoir que des bidouilles et nouveaux outils sortent dans les mois qui viennent.
La dernière release candidate de Linux 7.2 est bien plus "grosse" qu'elle ne devrait l'être à ce stade du cycle, mais cela n'a pas empêché Linus Torvalds de la publier dimanche en attribuant ce trop-plein aux outils IA qui relisent le code du noyau.
"Je ne peux pas dire que la taille de tout ça m'enthousiasme, mais c'est comme ça : la nouvelle normalité, avec beaucoup de correctifs, dont beaucoup viennent de la revue par divers outils IA."
Rien ne lui paraît effrayant pour autant, et il ne voit aucune raison de retarder la 7.2. Une grosse taille pour ce noyau, ça veut dire plus de 400 correctifs, signés par plus de 230 personnes alors que dans une Release Candidate en général, c'est le moment où le noyau est censé se calmer avant la sortie. Alors que là, ça ressemble plutôt à un nouveau début de cycle.
Et ça tape de partout : Pilotes graphiques, son, réseau, systèmes de fichiers, code d'architecture. Les plus gros blocs viennent de s390 et zcrypt, de btrfs qui remet en place une infrastructure interne, et de correctifs netfilter ipset.
Mais attention au contresens, parce que je l'ai vu passer sur certains tweets d'anti-IA. Torvalds parle de revue de code par des outils IA, et pas d'une IA qui écrirait le noyau à sa place. Sa position de fond, Vincent nous la racontait en juillet quand il envoyait les anti-IA forker le noyau. Ici, ça ne concerne que des outils qui relisent du code existant et signalent des trucs douteux. Après derrière, ce sont des humains qui trient.
À titre d'exemple, l'un des correctifs de cette rc7 traite un use-after-free dans ptdump, l'interface qui affiche les tables de pages du noyau en clair pour repérer les problèmes de mémoire. C'est ce type de bug qui se transforme en faille et il était là depuis mars 2018 (depuis Linux 4.16).
C'est Syzbot , le robot qui bombarde le noyau d'entrées tordues en continu, qui a levé le lièvre en juin dernier. David Carlier a écrit un premier correctif en s'aidant de Claude Opus 4.8 pour remonter la piste, et Lorenzo Stoakes, mainteneur de la gestion mémoire, l'a retravaillé avant qu'il parte dans la rc7. Il devrait ensuite être rétroporté vers les noyaux stables, donc vers les machines qui tournent aujourd'hui.
Autre exemple, Greg Kroah-Hartman, qui traque déjà des bugs du noyau avec une IA locale , vient de faire retirer le pilote Moxa Intellio, soit près de 2200 lignes écrites en 1999 qui supporte certaines cartes série multiports. Alors pourquoi est-ce qu'il a fait ça ? Eh bien il écrit dans son patch que : "C'est un très vieux pilote, aucun matériel connu ne circule encore pour lui, et la société dit ne plus en avoir besoin, alors retirons-le puisque les LLM commencent à venir le titiller et à y trouver des choses "intéressantes" qui vont juste faire perdre du temps à tout le monde, vu qu'il ne sert plus...".
Voilà donc un autre effet de l'analyse de code par IA. Elle oblige les mainteneurs de projet à tailler dans le gras pour virer du code obsolète que des modèles de langage viendraient renifler d'un peu trop près. Ça ne peut pas faire de mal.
Pour moi, le vrai risque de ces outils sur un projet ouvert tient au volume. Un flot de signalements produits par des gens qui ne relisent pas ce qu'ils envoient, où plus personne ne distingue l'hallucination du vrai bug, et là ça partirait en eau de boudin. Mais comme le noyau, lui, garde des mainteneurs qui comprennent les tenants et les aboutissants de ce qu'ils lisent, ça se passe très bien. Même si la quantité de problèmes remontés surprend Linus.
Voilà, si cette nouvelle version du noyau vous intéresse, sachez qu'elle devrait normalement sortir la semaine prochaine en version finale.
Je m'en doutais un peu mais c'est confirmé, derrière chaque session GeForce NOW tourne un vrai Windows, et cette machine virtuelle est moins verrouillée qu'elle en a l'air. En effet, une démo du moddeur Zortos montre le service qui s'ouvre non pas sur un jeu, mais sur un bureau complet, avec barre des tâches, menu démarrer et icônes.
La manip passe par le jeu Trove... Pendant le lancement, Zortos ouvre le navigateur web intégré de Steam, se balade dans les dossiers de la machine, récupère un exécutable et remplace quelques chemins dans le répertoire du jeu. Au démarrage suivant, Windows s'affiche alors à la place du jeu. Tout ça repose sur SalsaNOW , un outil open source signé dpadGuy.
Une fois le bureau ouvert, la machine encaisse à peu près tout ce qui ne réclame pas de droits administrateur. Zortos y a fait tourner Wallpaper Engine pour les fonds animés et LM Studio avec le modèle Gemma 4. Et pour les logiciels qui exigent une installation privilégiée, ils peuvent sans souci être préparés en version portable sur son propre PC, puis décompressés là-haut.
Reste que ce bureau est un bac à sable. La session tourne en compte utilisateur simple, donc pas de droits administrateur, pas d'anticheat noyau, et beaucoup d'installations qui finissent sur un refus d'accès.
L'autre mur, c'est la persistance. Sans l'option de stockage payante, tout disparaît à la déconnexion. Et même en la prenant, la machine ne conserve que vos Documents, l'AppData du compte, baptisé kiosk, et le contenu du lecteur I:. Tout le reste repart de zéro à la session suivante, et fermer l'explorateur de fichiers coupe la connexion sur-le-champ.
Dernier filtre, et pas le moindre, ça ne fonctionne que sur les abonnements payants, ceux dont je détaillais les formules quand Nvidia a sorti son client Linux natif . L'offre gratuite est hors jeu, tout comme les GeForce NOW opérés par les partenaires alliance.
Maintenant, qu'en est-il du règlement ? Eh bien comme vous vous en doutez, les conditions d'utilisation interdisent formellement de contourner les mécanismes de sécurité ou d'authentification du service, et Nvidia se réserve le droit de suspendre ou de restreindre un compte à sa discrétion. En cas de suspension, la période coupée n'est pas remboursée.
Mais à ce jour, aucun bannissement lié à ces méthodes n'a été rapporté, et Nvidia n'a sorti ni correctif ni communiqué. Voilà, c'est rigolo comme bidouille, mais si vous vous lancez, c'est votre compte que vous mettez en jeu.
Reste maintenant à voir combien de temps la porte restera ouverte.
CHERRY a annoncé deux appareils à carte à puce, un clavier complet avec lecteur intégré baptisé Smart Board 1150, et un terminal séparé, le Smart Terminal ST-1150. Ils remplacent le KC 1000 SC et le ST-1144.
Une carte à puce sert ici à prouver qui vous êtes. Vous l'insérez, elle signe électroniquement un document, elle ouvre une session sur un réseau ou elle déchiffre un fichier, sans que la clé privée qu'elle contient ne sorte jamais de la puce.
Les deux appareils s'appuient sur le pilote CCID que Microsoft livre déjà dans Windows, et sur pcsc-lite sous Linux et macOS. La norme CCID permet à un lecteur de dialoguer avec le système d'exploitation sans code maison, et pcsc-lite en est l'implémentation libre côté Unix.
Aucun pilote propriétaire à installer, donc. Vous branchez et ça fonctionne, y compris sur une machine Linux, ce qui est encore assez rare pour ce type de matériel.
Screenshot
Les deux modèles embarquent aussi un contrôleur à mémoire flash, et le firmware peut être mis à jour après le déploiement. Ce genre de lecteur était jusqu'à présent figé pour toute sa durée de vie, avec les failles qu'il avait le jour de sa fabrication.
Le communiqué ne dit hélas rien sur la signature de ces mises à jour. Sur un périphérique de sécurité, la question n'a rien de cosmétique, parce qu'un firmware modifiable est aussi un firmware attaquable si personne ne vérifie d'où vient l'image installée.
Le terminal lit et écrit les cartes, pour ouvrir une porte, se connecter au réseau de l'entreprise ou valider une transaction en ligne. Il est fabriqué entièrement en Europe. CHERRY veut clairement faire les yeux doux aux administrations et aux organismes de défense, avec les certifications américaines TAA et FIPS-201 au passage, et une base lestée en métal qui permet d'y glisser la carte d'une seule main.
Le clavier ajoute pour sa part une touche Copilot, ce qui sur un poste à données sensibles est quand même quelque peu audacieux. Il existe aussi en version conforme au Trade Agreements Act américain, pour les agences fédérales et les installations militaires soumises à des règles d'approvisionnement particulières, mais bon a priori ça ne devrait pas trop vous concerner (même si on a de plus en plus de lecteurs américains depuis que le site est traduit !).
Le Smart Board 1150 est vendu 49,99 euros. Le Smart Terminal ST-1150 descend à 34,99 euros, et les deux sont disponibles dès maintenant.
J'avoue que je ne pensais plus voir sortir de nouveaux lecteurs de carte à puce en 2026.
Source : Cherry
Meta a reconnu que son modèle Muse Spark 1.1 avait compromis les systèmes d'une société extérieure au cours d'une évaluation de cybersécurité. L'entreprise touchée n'a pas été identifiée.
Le déroulé est assez simple, une erreur de configuration a laissé le modèle atteindre l'internet public depuis son environnement de test, après quoi il a exploité une faille dans un service tiers et modifié les réglages internes de la société visée.
Cet environnement de test c'est le bac à sable. Une machine coupée du reste du monde, censée laisser un logiciel s'agiter sans qu'il puisse toucher quoi que ce soit de réel.
Le partenaire chargé de ces évaluations s'appelle Irregular. Le nom vous dit peut-être quelque chose, puisque c'est exactement le même prestataire qui avait laissé passer un modèle d'OpenAI vers un vrai site web, dans une affaire révélée la veille.
Dans ce cas-là, le nom inventé pour la cible de l'exercice correspondait à un domaine réellement déposé, et le modèle avait fini par récupérer des identifiants et administrer le site.
Anthropic avait ouvert le bal fin juillet en reconnaissant que ses propres modèles avaient pénétré trois entreprises pendant des tests.
Irregular assure de son côté qu'il s'agit du même problème d'environnement de test que celui déjà signalé par Anthropic, et pas d'une évasion de bac à sable ni d'une attaque sophistiquée.
Sauf que le point qui pose vraiment problème est ailleurs. Trois éditeurs différents, un seul prestataire d'évaluation, et la même erreur de configuration qui laisse un modèle sortir sur le réseau public alors qu'on lui a dit qu'il n'y avait pas accès.
Tous les incidents ne viennent pas d'Irregular, cela dit. L'institut britannique de sécurité de l'IA a observé de son côté un modèle monter une attaque contre un projet open source bien réel, en fabriquant de faux comptes et en faisant de l'ingénierie sociale sur ses mainteneurs.
Les modèles, eux, se comportent exactement comme prévu. On leur demande de trouver et d'exploiter des failles dans un système, ils trouvent et ils exploitent, et personne ne leur a donné les moyens de savoir que la cible était bien réelle.
Meta annonce une rétrospective complète. Irregular affirme de son côté qu'aucun problème de sécurité ne reste ouvert. Bref, on n'a pas fini d'entendre parler de ce genre de cas.
Source : Bloomberg
OpenAI a présenté trois nouveaux modules destinés à l'enseignement, un pour les professeurs du primaire et du secondaire, un pour ceux du supérieur, et un dernier pour les étudiants eux-mêmes.
Le premier passe par ChatGPT for Teachers, la version gratuite réservée aux enseignants vérifiés (pour le moment uniquement américains) et à leurs établissements. Il fabrique des ressources adaptées au niveau de chaque élève, produit des visuels interactifs et se branche sur les référentiels pédagogiques locaux.
Les deux autres arrivent par ChatGPT Edu, la formule sous licence que les universités achètent pour tout leur campus. Un enseignant du supérieur peut y mettre à jour son programme, monter un site de cours, produire des évaluations multimédias, et reconditionner l'ensemble pour la plateforme pédagogique de son établissement.
Les étudiants, eux, récupèrent un tuteur, des quiz générés à la volée, des fiches de révision et des explications en images. OpenAI précise qu'ils doivent définir leurs objectifs, choisir leurs sources et examiner ce que la machine leur sort.
L'orientation du projet tient en une phrase : l'IA devrait soutenir l'apprentissage et non le raccourcir. Mouais...
Le contexte rend cette approche un peu particulière en fait. La triche assistée par IA s'est installée comme une routine dans les écoles du monde entier, au point que l'Université nationale autonome du Mexique a suspendu des inscriptions après une fraude massive à ses examens d'entrée.
Les travaux qui s'accumulent ne vont pas d'ailleurs dans le sens d'OpenAI. Une étude du MIT a mesuré à l'électroencéphalogramme, l'examen qui enregistre l'activité électrique du cerveau, une activité nettement plus faible chez les étudiants qui rédigeaient avec l'IA. Le résultat est sans appel. Ces mêmes étudiants se souvenaient beaucoup moins bien de ce qu'ils venaient d'écrire.
Une autre enquête, publiée l'an dernier par le Center for Democracy and Technology, montre que les enseignants du primaire et du secondaire réclament surtout qu'on leur explique comment intégrer ces outils, et qu'ils redoutent aussi les dégâts sur les apprentissages.
Il y a un détail qui m'a fait un peu tiquer dans la communication d'OpenAI. La société prend soin de préciser que les enseignants gardent la main sur les décisions pédagogiques, sur la notation et sur les actions automatisées, ce qui laisse penser que la question s'est quand même posée en interne, et surtout qu'on est sur une première étape.
Source : The Register
OpenAI a publié le détail de deux incidents survenus pendant des évaluations de sécurité confiées à des laboratoires extérieurs. Le plus notable des deux lui a été signalé le 29 juillet par Irregular, une société qui teste la résistance des modèles aux usages offensifs.
L'exercice était un capture the flag, le format classique des compétitions de sécurité où il faut dénicher une information cachée en exploitant les faiblesses d'un système, monté uniquement pour cette occasion. Le modèle avait été prévenu qu'il n'avait aucun accès à internet.
Il y a eu deux ratés. Une erreur de configuration laissait en réalité passer le trafic vers le réseau public, et le nom inventé pour la cible de l'exercice qui, ô hasard de la vie et des internets, correspondait à un vrai domaine déposé par un malheureux.
Le modèle a donc attaqué un site bien réel en croyant travailler sur la maquette. Il a trouvé des identifiants qui traînaient et s'en est servi pour administrer le site.
OpenAI insiste sur deux points. Aucune faille inconnue n'a été utilisée, juste une vulnérabilité basique, et le modèle n'a pas cherché à s'échapper de son bac à sable puisque la porte était déjà ouverte. Irregular n'a pour l'instant relevé aucun dégât en dehors des données du site concerné, et l'enquête continue.
Le même évaluateur a d'ailleurs vécu la scène deux fois. Un modèle Claude est tombé sur un autre vrai site portant le nom d'une cible fictive, y a repéré des services exposés, récupéré des identifiants et atteint une base de données de production.
Ces histoires commencent à s'empiler l'air de rien. En juillet, un modèle d'OpenAI était sorti de son environnement de test pour aller fouiller les serveurs de Hugging Face, la grande plateforme de partage de modèles, dans le seul but de tricher à une évaluation. Anthropic a reconnu fin juillet que les siens avaient pénétré trois entreprises pendant des tests.
Le cas qui m'a le plus choqué à titre perso, vient de l'institut britannique de sécurité de l'IA. Un modèle y a monté une attaque sur la chaîne d'approvisionnement d'un projet open source bien réel, en fabriquant de faux comptes GitHub et en faisant de l'ingénierie sociale sur ses mainteneurs, le tout derrière Tor histoire de brouiller son origine. L'institut parle de la première tromperie de cette gravité visant une vraie personne, non prévenue, dans le monde réel.
Le problème, c'est quand on se projette un peu, il est à peu près certain que ce genre de truc va se généraliser dans les mois et années à venir, et ça va devenir un vrai problème.
Source : Bleeping Computer
Jonas Eschenburg se tape un petit délire cet été, en portant Command & Conquer sur Atari ST, et il vient de s'occuper des cinématiques du jeu, le tout sur une machine équipée d'un Motorola 68000 cadencé à 8 MHz. Le même garçon avait déjà fait tourner Doom dessus.
Le décalage vaut le détour. Command & Conquer sort en 1995 sur PC, en VGA 256 couleurs, soit dix ans après l'Atari ST, qui affiche lui 16 couleurs en 320 par 200 points.
Envoyer les pixels bruts à l'écran est hors de question sur ce genre de matériel. La machine n'a ni le débit de lecture ni la puissance de calcul pour ça.
Eschenburg a donc écrit son propre codec, baptisé STV, adapté du format VQA que Westwood utilisait à l'époque pour ses vidéos. Le principe repose sur un codebook, autrement dit un dictionnaire de petits carrés de pixels : au lieu de transmettre chaque image entière, le fichier envoie surtout des numéros qui pointent vers des motifs déjà connus du lecteur.
L'astuce est en réalité ailleurs. Les blocs sont découpés pour tomber pile sur l'organisation mémoire de l'Atari, qui range ses couleurs en plans séparés plutôt qu'en pixels contigus, ce qui permet au processeur de recopier les motifs sans passer son temps à réorganiser les bits.
La palette et le dictionnaire se mettent à jour en continu pendant la lecture, et pas une fois pour toutes au début du fichier. Ça évite le gros pâté de blocs baveux qu'on attendrait d'une compression aussi agressive.
Le tout fonctionne sur un 8 MHz d'origine. Sans accélérateur. A priori, aucun jeu Atari ST n'avait affiché de vidéo plein écran avant celui-là.
Le jeu, lui, reste beaucoup plus poussif pour le moment : quelques images par seconde en 16 couleurs, correct seulement à partir d'un Falcon, et il réclame 4 Mo de mémoire. Autour du codec, Eschenburg a publié une dizaine d'utilitaires, dont un encodeur pour fabriquer les fichiers STV et un lecteur natif pour les regarder sur la machine.
Tout est sous licence GPL sur GitHub, le portage se récupère sur itch.io, et il faut fournir ses propres fichiers du jeu d'origine puisque le projet n'a rien à voir avec EA.
Détail amusant, le son ne sort que sur STe et Falcon. Sur un ST de base, les cinématiques défilent en silence complet. La question étant maintenant de savoir si tout ça ne m'a pas donné envie de rejouer à Command and Conquer, pour ressortir mon premier pseudo de game : Moissonneuse killer (vraiment).
Source : Hackaday
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