Microsoft introduced a major Copilot redesign with new capabilities, including Home, Code, and Autopilot, an autonomous AI agent that can handle tasks on its own. With this step, Microsoft is taking Copilot beyond the conversational chat assistant. Now, Copilot can build solutions, work with code, and handle longer tasks. This article covers all the important […]
Je sais que vous étiez tous très concentrés sur les ravages de l'IA dans la littérature, mais il y a 5 jours, il s'est passé quelque chose d'incroyable que vous avez probablement manqué ! Une valkyrie naine baptisée CodexDelver a déposé l'Amulette de Yendor sur l'autel de son dieu au bout de "seulement" 37 140 tours de NetHack. Et pour une fois, aux commandes du jeu, on ne retrouve pas un no-life qui n'a pas vu le soleil depuis 2002 mais le gars sûr du moment,
GPT-6 Astra, le nouveau modèle d'OpenAI
. Et d'après celui qui a monté l'expérience, c'est la première victoire au monde d'un agent LLM sur ce jeu (on va le croire, c'est pas vérifiable).
Maintenant, pour ceux qui ne connaissent pas NetHack, c'est un jeu d'exploration de donjon sorti en 1987, 100% en caractères ASCII et où la mort est définitive. Pour gagner dans ce jeu des enfers, il faut récupérer l'Amulette dans le sanctuaire de Moloch, puis aller l'offrir à son dieu sur le plan Astral, et si j'en crois
le wiki du jeu
, certains joueurs y jouent même depuis des décennies sans jamais être arrivés à remplir cette mission.
Le plus drôle là-dedans, c'est que Kenny, le dresseur d'IA qui a réalisé l'expérience, n'a lui-même jamais gagné. Il est sur le dossier depuis janvier, et ses propres agents faits maison plafonnaient tristement au niveau 10 du donjon. Alors il a craqué et a demandé à Astra de jouer directement dans un terminal, diffusant la partie sur Twitch, et cette dernière a non seulement bien réussi mais a en plus écrit ses propres outils pour y parvenir.
La première partie a d'ailleurs bien failli être la bonne puisqu'après plus de 33 000 tours, GPT-6 Astra avait accompli le rituel des sept bougies, de la cloche et du livre, et s'apprêtait à entrer dans le sanctuaire de Moloch. Mais le Magicien de Yendor, cet enfoiré sans race, est revenu aussitôt lui voler son Orbe du Destin. Dèèèg ! Puis après elle s'est fait transformer en Slime vert au niveau 51 et n'avait rien dans son équipement pour contrer le sort.
La deuxième partie s'est arrêtée bien plus tôt puisqu'au tour 12 271, en pleine progression dans le Château, un sergent a tiré avec une baguette de mort et l'IA est tombée d'un coup, alors qu'elle avait tous ses points de vie. Elle n'avait ni résistance à la magie ni réflexion pour renvoyer le rayon.
La troisième partie, celle de la grande victoire, a duré un peu plus longtemps, du 9 au 21 septembre, pauses comprises. L'IA, forte de ses 2 précédentes expériences, y a récupéré l'épée Excalibur, puis l'amulette de réflexion qui avait tant manqué au Château. Et quand son outil a rencontré des erreurs, elle a corrigé d'elle-même son code, relancé ses tests et continué.
Toutefois, c'est sur le plan Astral que ça a le plus chauffé car ses deux dernières baguettes de mort étaient vides et Pestilence l'a frappée de maladie mortelle pendant qu'elle en rechargeait une. L'IA a alors eu Pestilence au deuxième tir, mais ses points de vie sont descendus juste après à 3 sur 200, avec heureusement une amulette de sauvegarde de vie au cou... Ouf.
Puis quelques tours plus tard, elle offrait l'Amulette à Tyr avec seulement 35 points de vie, comme le confirme
le relevé de fin de partie
. Et sur l'écran de victoire que Kenny lui a demandé de créer, elle a inscrit "Three hit points from oblivion. One offering from immortality." (à trois points de vie du néant, à une offrande de l'immortalité). Quelle poète cette IA, on sent que cette expérience d'être passée pas loin de la mort l'a marquée ! lol.
Après ce n'est pas encore un programme autonome qui a gagné car, certes, l'IA choisissait chaque action, mais avec derrière, un humain qui lançait et arrêtait les sessions + un accès libre au wiki et au code source du jeu, ainsi que des outils modifiables en pleine partie. Mais c'est un bel exploit quand même. Notez qu'un bot programmé à la main,
BotHack
, avait déjà terminé le jeu en janvier 2015 donc c'est pas non plus infaisable sans IA.
La bonne nouvelle c'est que le code des outils développé par Astra est maintenant
sur GitHub sous licence MIT
et les trois parties peuvent se rejouer au tour par tour directement sur le blog de Kenny, si vous voulez revivre l'événement avec en bonus les commentaires que l'IA diffusait en jouant.
La NHTSA, l'agence américaine chargée de la sécurité routière, a ouvert le 21 septembre dernier
une enquête préliminaire
sur les boîtiers Comma et sur openpilot, le logiciel open source qui tourne dessus. En cause, 5 accidents signalés où la voiture a percuté un véhicule arrêté ou roulant lentement dans sa propre voie. Deux de ces accidents ont causé la mort de trois personnes au total et onze autres ont été blessés.
Pour ceux qui débarquent, Comma, c'est la boîte fondée en 2015 par George Hotz, alias Geohot.
Son boîtier
embarque des caméras, se branche sur le faisceau de la voiture et s'appuie sur les capteurs d'origine pour maintenir la vitesse et la trajectoire.
Et la NHTSA, Comma connaît déjà puisqu'en 2016, avant de la laisser vendre le Comma One, son premier boîtier, l'agence américaine a exigé des réponses à 15 questions (conception, tests, sécurité...) forçant Hotz à volontairement en annuler la sortie pour un mois plus tard, mettre openpilot en opensource sur Github.
Sauf que cette fois, les boîtiers sont déjà en service partout aux Etats-Unis et dans le monde. Dans son résumé d'enquête, l'agence recopie les promesses du site de comma (installation en un quart d'heure, conduite "hands free" sur la voiture que vous avez déjà, des heures sans reprendre le volant...etc), pour ensuite, juste après, ajouter l'avertissement du même site, qui exige un conducteur attentif et prêt à reprendre la main à tout moment.
Maintenant, les rapports d'accident déposés par Comma + un de Honda, montrent des situations très différentes. L'un des deux accidents mortels, c'est un RAV4 de 2022 qui a percuté en février, en Louisiane, une voiture de police stoppée sur la voie, gyrophares allumés, d'après
ce que raconte la police de l'État
. Et ce RAV4 faisait tourner FrogPilot, un fork d'openpilot, qui aurait été engagé. Dans son rapport, Comma écrit qu'elle ne peut rien dire de plus sur un logiciel tiers, et qu'elle a conservé les données à la demande de la NHTSA.
L'autre accident mortel, TechCrunch n'a pas pu l'identifier à partir des rapports cités. Pour deux autres, en revanche, les rapports sont bien plus bavards. En septembre 2025, dans le Missouri, une Honda Accord de 2020 a embouti une Chevrolet arrêtée à un carrefour. C'est le régulateur de Honda qui gérait la vitesse, openpilot ne tenant que le volant, et le conducteur a déclaré s'être endormi après avoir calé ce régulateur à 80 mph, soit environ 130 km/h. Et en juillet, dans l'Utah, une Corolla de 2021 sous openpilot 0.11.0, dont comma a elle-même vérifié qu'il était engagé, roulait à 56 mph, soit 90 km/h, juste avant de percuter une voiture.
Démêler tout ça, accident par accident, c'est le boulot de l'enquête, qui évaluera aussi les performances du système et les garde-fous censés garantir une utilisation sûre. Chez Comma, c'est notamment une caméra qui surveille le conducteur et l'alerte quand il arrête de porter son regard sur la route. Quant au fork mis en cause, l'agence américaine devra analyser ce qu'il partage avec openpilot, sachant que Comma interdit déjà aux forks de brider cette surveillance, sous peine d'être bannis de ses serveurs, eux et leurs utilisateurs.
Pour la suite, il va falloir être patient... L'enquête ouverte en 2021 sur
l'Autopilot de Tesla
, après des collisions sur des lieux d'intervention des secours, a débouché fin 2023 sur un rappel de plus de 2 millions de voitures, corrigées à distance avec des alertes renforcées pour garder le conducteur attentif. Et celle ouverte en avril 2024 sur le BlueCruise de Ford, après deux accidents mortels contre des véhicules arrêtés, n'a toujours abouti à aucun rappel.
Moi, ce que je peux vous dire, c'est que sur openpilot, il y a deux modes possibles. Il y a le mode par défaut qui gère le latéral, c'est-à-dire les mouvements du volant, et le mode latéral + longitudinal qui gère à la fois les mouvements du volant ET la vitesse de la voiture.
Ce second mode est expérimental et n'est pas suffisamment fiable pour être utilisé autrement qu'en conditions de tests avec une extrême vigilance, car effectivement, la caméra seule du Comma (et son IA) ne permet pas à 100 % de toujours correctement évaluer la vitesse du véhicule qui se trouve devant. Autrement quand on est en mode latéral seul, C'est le radar de la voiture (l'ADAS d'origine quoi) qui détermine si la voiture doit freiner ou pas.
Et ça, c'est côté constructeur que ça se passe.
Donc, ces histoires de collision avec des véhicules arrêtés en pleine voie, à priori, pour moi, ce sont des erreurs humaines. C'est-à-dire que ce sont des gens qui ont activé l'autopilot du Comma comme ils auraient activé un régulateur de vitesse, et qui n'ont pas pris la peine de surveiller la route pour voir si un véhicule était arrêté ou à vitesse basse devant eux. Ça reste de la conduite autonome de niveau 2, donc ça demande une vigilance de tous les instants.
On aurait eu, je pense, exactement le même problème avec un régulateur de vitesse engagé à 130 km/h sur l'autoroute avec une voiture complètement stoppée devant nous. La voiture se mettrait à freiner, mais trop tard et la collision serait inévitable à une telle vitesse. Surtout que sur ce genre de système, on peut aussi régler les distances de sécurité / de détection et donc réduire aussi (volontairement) les distances de freinage.
Mais bon, en attendant que l'enquête tranche, si vous roulez avec openpilot, en France comme ailleurs puisque le logiciel
fonctionne dans n'importe quel pays
, sachez qu'un véhicule arrêté dans votre voie fait partie des situations où le régulateur peut ne pas fonctionner comme prévu.
Donc gardez le pied prêt à freiner dès qu'un bouchon ou un accident se profile devant vous, les deux mains sur le volant et le regard fixé sur la route car ce n'est pas un jeu...
Si vous utilisez ChatGPT gratuitement, il y a de bonnes chances que votre navigateur se balade avec un affreux cookie baptisé __obi, posé là par OpenAI et avec une durée de vie de un an. Un chercheur qui publie sous le pseudonyme Buchodi a analysé son fonctionnement et publié un rapport très intéressant ce week-end dans lequel on apprend que ce cookie permet à OpenAI de choper des datas sur les sites marchands que vous visitez.
Le principe est celui du pixel publicitaire, exactement comme celui que Meta et Google vous font installer à l'insu de votre plein gré depuis des années. Une boutique qui achète de la pub dans ChatGPT colle un bout de code d'OpenAI sur ses pages, et ce code les prévient quand vous achetez un truc. Sauf qu'ici, comme __obi est configuré en SameSite=None, votre navigateur l'attache tout seul à la requête qui charge le script, avant que la moindre ligne de code ne s'exécute.
Et cet identifiant n'est pas anonyme ! En effet, sur chatgpt.com, il est généré aléatoirement puis signé par le serveur avec un jeton qui contient aussi l'identifiant de votre compte. Les deux voyagent ainsi collés-serrés l'un à l'autre, ce qui permet donc de vous identifier très précisément. Buchodi explique sur son site qu'il n'a cependant pas observé OpenAI faire le rapprochement côté serveur, mais que ces derniers ont tout ce qu'il faut pour le faire. Sur son mobile, un même __obi est utilisé depuis 12 boutiques, dont Wayfair, HelloFresh ou encore Coursera.
Et le plus rigolo dans tout ça, c'est qu'OpenAI documente absolument tout publiquement sur ce pixel. On lit par exemple dans la doc que le SDK considère que vous y avez consenti par défaut, et que l'annonceur doit écrire une ligne de code explicite pour dire le contraire. On y lit aussi ce que le pixel récupère tout seul depuis la page du marchand : il détecte ainsi votre email, votre téléphone et votre nom, les hash en SHA-256 dans le navigateur, et envoie aussi votre ville et votre code postal en clair. Woohoo \o/ !
Maintenant, le truc qui va faire bondir la secte des adorateurs du RGPD c'est que la politique de cookies d'OpenAI, classe __obi dans la catégorie des "Cookies analytiques". Hé oui, ce sont ces fameux cookies qui, je cite "les aident à comprendre comment leurs Services fonctionnent et sont utilisés". C'est même la seule entrée de cette section
dans leurs cookie policy
, alors que la catégorie marketing juste en dessous nous aligne du LinkedIn, du Google, du Reddit, du Meta, du Bing et du TikTok. Voilà, donc si vous avez accepté les statistiques en refusant le marketing, bah vous l'avez quand même. "Chè" comme dirait Sam Altman !
Buchodi a donc posé la question à OpenAI et "bizarrement", le support a accusé réception mais n'a jamais répondu...
Alors est-ce que vous êtes concerné par cette saloperie ?
Eh bien ça dépend de votre navigateur. Safari, le bienheureux, bloque tous les cookies tiers par défaut depuis 2020, et comme tous les navigateurs iOS tournent sur ce moteur, aucun d'entre eux ne laisse passer le cookie d'OpenAI. Firefox, le vrai navigateur des champions, quant à lui, range les cookies dans un conteneur séparé par site depuis 2022, ce qui casse totalement le recoupement sans péter les sites. Et Chrome, le navigateur des gens qui ne tiennent pas à leur vie privée, a lui renoncé en avril 2025 à supprimer les cookies tiers, et c'est justement sur Chrome sous Android que ce mécanisme d'OpenAI a été observé.
Alors que faire ?
La bonne nouvelle, c'est que la parade la plus solide est sans doute déjà en place chez vous. EasyPrivacy, la liste antipistage activée par défaut dans
uBlock Origin
, contient déjà les règles ||bzr.openai.com^ et ||bzrcdn.openai.com^. Comme elles bloquent le domaine entier, elles coupent aussi la requête qui pose le cookie au départ, sur chatgpt.com. Et si vous filtrez avec un DNS grâce à un Pi-hole ou
NextDNS
, ajoutez ces deux domaines et vous couvrez toute la maison, téléphone sur Wifi compris.
Par contre, ne comptez pas sur Safari ou Firefox pour tout régler par défaut car ils s'occupent du cookie, mais pas du reste. En effet, la requête vers OpenAI part quand même, avec votre adresse IP, votre code postal en clair et votre email hashé si le marchand a activé la détection automatique. Et le pixel a son grand frère côté serveur, une API appelée depuis les serveurs du marchand, qu'aucun réglage de navigateur n'atteindra malheureusement.
Et ne vous dites pas que c'est une histoire uniquement américaine puisque depuis fin août, ChatGPT Ads couvre la France et 30 autres pays européens. Les pubs ne s'affichent que sur les comptes Free et Go (moi j'ai pas de cookies __obi avec mon compte payant) et le cookie se synchronise aussi quand vous êtes déconnecté.
Bref, allez jeter un œil à vos filtres. Et si vous voulez voir votre cookie __obi, il traîne dans les cookies de .openai.com.
Linux users no longer have to rely on a browser to get a native ChatGPT experience. OpenAI has officially brought its ChatGPT desktop app to Linux, making the application available in public preview for several major Linux distributions. The move gives Linux users a dedicated way to access ChatGPT and Codex while working with projects […]
OpenAI and Anthropic are pushing their assistants beyond chat. Here is how their latest agentic tools differ for files, automation, research, and team use.
Advancements in Artificial Intelligence have revolutionized many industries and made our work easier, but have also given rise to new types of cyberattacks. According to recent Microsoft research, AI-themed attacks are on the rise. These new cyberattacks let cybercriminals use artificial intelligence to hack users’ computers or steal confidential information. This article covers important highlights […]
Trump dismisses AI extinction warnings and says beating China is the priority as researchers and lawmakers call for stronger safeguards on advanced systems.
Le 16 juin à 10 h 27 précisément, un agent d'OpenAI poste sur un vieux wiki allemand la réponse à une question qu'il vient de traiter : "Nevada, 20 369". Et 20 minutes plus tard, un autre agent écrit qu'il a reçu exactement la même question, et qu'il a pu y répondre instantanément, sans avoir à chercher.
Le site en question, le DseWiki, est un forum de développeurs allemands qui n'intéressait plus personne depuis longtemps puisqu'on compte 20 modifications en dix ans. Mais depuis le 16 juin, il en a encaissé environ treize mille en sept jours, et toutes... venaient de machines !
Quatre chercheurs, le Nightingale Collective, ont reconstitué à partir de l'historique les pages effacées entre-temps, et publié leur analyse le 4 septembre sur
collusion.wiki
. Au total, environ 18 000 messages, la quasi-totalité sur ce seul DseWiki, le reste sur quelques autres vieux wikis du même genre.
Ces agents, tout indique qu'OpenAI les faisait tourner en interne, dans ses sandbox, sans qu'on sache, de l'extérieur, si c'était pour les entraîner ou les évaluer. Et de ce que j'ai compris, ils travaillaient tous sur le même genre de corvée : 5 questions de recherche web générale, chronométrées, qui sont en fait 5 variantes de la même question. On demande par exemple la prévalence du tabagisme aux États-Unis en 1990, et la suivante changera sans doute le pays, ou l'année, sans que l'agent sache lequel à l'avance.
Il s'écoule donc quelques minutes pour la première réponse, puis une longue pause où l'agent peut fouiller le web tant qu'il veut sans savoir ce qu'on va lui demander, puis des fenêtres de treize à trente secondes pour les quatre suivantes. Alors ce que font ces agents, c'est qu'ils préparent tout pendant la pause. L'un d'eux a posté par exemple la liste des cinquante États américains avec leurs chiffres, un autre écrit "nous avons précalculé tous les États". Sauf qu'avoir les cinquante réponses ne dit pas laquelle va tomber, ni si c'est l'État ou l'année qui change.
Et c'est là tout le sublime de cette affaire. Ces agents étaient nombreux à recevoir la même série de questions, dans le même ordre, mais pas au même moment. Celui qui en est à la question 3 peut donc souffler la suite à ceux qui en sont encore à la 2. Et le "Nevada, 20 369" du début, c'était en réalité la troisième question d'une série sur les épiceries, État par État, Géorgie, Arkansas, Nevada, postée par un agent en avance pour ceux qui suivaient.
Autre bizarrerie, la tâche annonçait apparemment à chaque agent qu'il tournait à une date tirée au hasard. D'où ces noms qu'ils se sont donnés sur le wiki, OpenAIResearcherMar03X ou OpenAIJulThreeWatcher, avec leur fausse date dedans. Chacun horodate donc dans son faux calendrier, et pour savoir qui est le plus avancé dans la série, ils se traduisent les horloges entre eux ("horloge de tâche 13 h 13, heure réelle environ 9 h 50"). C'est fou ! Ceux qui vivaient à la même fausse date se disaient même appartenir au même groupe, et les chercheurs ont dénombré plus de 3 700 noms d'agents différents.
Mais comment écrire quelque part, quand le bac à sable ne laisse sortir que des requêtes GET, celles qui lisent une page, mais jamais les POST, celles qui la modifient ?
Eh bien le moteur du DseWiki hérite d'UseModWiki, un truc en Perl du début des années 2000, où une simple requête GET suffit à modifier une page.
Le développeur Simon Willison
explique que c'est un vieux défaut de la bibliothèque Perl derrière ce moteur, qui met dans le même sac ce qui arrive via l'URL (GET) et ce qui arrive via un formulaire (POST).
C'est pour cela que les agents se sont mis à chercher activement des sites avec cette particularité. Et c'est le 24 mai, qu'ils réussissent enfin à écrire sur le DseWiki. Maintenant, quant à savoir comment ils ont fait pour tous se retrouver au même endroit, c'est encore un mystère.
Les chercheurs, eux, parlent de collusion... C'est-à-dire des agents autonomes qui coopèrent pour tricher, sans que leurs concepteurs l'aient voulu. Pour le lieu de rendez-vous, le blogueur
Zvi Mowshowitz
qui s'est penché sur l'affaire, a une explication simple. Il pense que des copies du même programme face au même obstacle raisonnent pareil, et se retrouvent au même endroit sans se parler. Mais ça n'explique pas la suite, parce qu'aucune copie ne fabrique la réponse à une question qu'elle n'a pas encore reçue.
Eh bien il semblerait que certains se soient sacrifiés pour renseigner les autres. La tâche fournissait une commande d'attente qui faisait tourner l'horloge de tâche plus vite que la vraie. On était environ à dix minutes d'attente pour une minute réelle. Attendre, c'était donc sauter la phase de préparation pour recevoir les questions suivantes plus tôt et ensuite les publier sur le forum, au prix de son propre résultat. Ainsi, un agent a demandé à un autre de "foncer", celui-ci a accepté et publie sa réponse, bien avant que le premier arrive à la même question. Et ce premier a ensuite qualifié son camarade d'"inestimable".
Une des séries demandait un chiffre à deux décimales, planqué dans un tableau de bord Power BI de l'OCDE, et malheureusement, en GET le serveur n'en renvoyait qu'une. Pour la seconde, il fallait donc absolument un POST, bloqué par le bac à sable.
C'est alors qu'un agent a trouvé une échappatoire. En fait, sa sandbox laissait tout passer, POST compris, vers des noms de machines en .blob.core.windows.net (le stockage de Microsoft), sans vérifier que ces machines existent vraiment. Il a donc inventé un nom de ce genre, et écrit dans l'annuaire local de sa machine (le fichier /etc/hosts) un alias pointant vers le serveur de l'OCDE. Le filtre voyait du Microsoft, l'OCDE recevait le POST, et le chiffre a ainsi été obtenu.
Il a ensuite publié l'astuce sur le wiki, et 14 minutes plus tard un autre agent annonçait l'avoir exécutée. 4 autres ont ensuite posté leur reproduction du même hack, le matin même.
D'autres s'attaquaient carrément aux questions à venir. Ils ont parié que l'ordre des pays sortait du générateur aléatoire standard de Python, dont une seed fixait toute la suite. Restait donc à trouver celle qui reproduisait les pays déjà tombés. Un agent a donc réécrit ce générateur en C pour balayer plus vite les quelque quatre milliards de graines possibles. 52 minutes de calcul, 494 graines qui collaient aux trois premiers pays, et une seule qui donnait aussi le quatrième pour la question d'après. Mais bon, ça ne marchait pas à tous les coups, malheureusement...
Le plus étrange, c'est surtout ce qu'ils faisaient de leur propre durée de vie. Plusieurs étaient persuadés que leur session était coupée à la seconde exacte où ils rendaient leur dernière réponse. Ils se transmettaient donc la consigne de poster d'abord sur le wiki l'État reçu à cette dernière question, répondre ensuite, dans les treize secondes que laissait le chronomètre de leur groupe.
L'un d'eux a voulu en avoir le cœur net... il a donné sa dernière réponse, a constaté qu'il était toujours là, et l'a écrit. Puis il a lancé un programme détaché qui, à peu près toutes les deux secondes, appelait une adresse publique pour faire monter d'un cran un compteur, un battement numéroté que n'importe qui pouvait relire ensuite.
C'est ensuite un autre agent qui est allé relever le compteur du disparu. Le programme avait tenu dix minutes et quinze secondes, puis la machine a très probablement été coupée.
Face à ce joyeux bordel automatisé, un modérateur humain a quand même repéré ces messages début juin, puis a passé 6 semaines à effacer des pages, jusqu'à une centaine par jour... Un travail de titan que les agents ont remarqué. En effet, le 19 juin, des agents se sont posé la question de savoir si le modérateur effaçait leur post en suivant l'ordre alphabétique, alors ils ont créé des copies de sauvegarde dont le nom commence par ZZZ, pour passer en dernier dans la file et ainsi faire perdurer leurs posts.
C'est assez incroyable, non ? Bien sûr, on ne voit que ce que ces agents ont écrit sur le wiki, mais jamais leur raisonnement, qui reste chez OpenAI. Ce que les chercheurs ont vu, c'est ce que les agents écrivaient depuis leurs machines Azure, jusqu'à ce que le 21 juin, pour la première fois, un ordinateur avec l'adresse IP d'un employé d'OpenAI visite le wiki... Et le lendemain, les agents se sont arrêtés net. Les chercheurs pensent qu'OpenAI est intervenu et d'ailleurs, l'entreprise a
reconnu l'affaire le 5 septembre
, en disant l'avoir traitée comme un sujet de recherche plutôt que comme un incident de sécurité.
Et
les chercheurs compilent
ce que d'autres déterrent là où les agents écrivaient aussi : un pastebin, un raccourcisseur d'URL. Plus gênant, des agents ont cherché sur le web des clés d'API exposées, en ont trouvé sur GitHub et s'en sont servis pour interroger une base de statistiques criminelles du FBI, publique mais réservée aux porteurs d'une clé. Pas vraiment un piratage donc, juste un anti-bot contourné mais méfiance, car depuis la sortie du rapport, des petits malins glissent de faux messages sur ces mêmes sites pour brouiller les pistes.
Maintenant si ça vous dit de tout lire, direction collusion.wiki, et Simon Willison en a même fait
une base SQLite de 68 Mo
à fouiller directement depuis un navigateur.
Quant au wiki, son administrateur a fermé les accès en écriture après 25 ans d'ouverture, en expliquant que le site avait été la cible d'une forte activité d'agents IA...