Anthropic fait don d'Agent Skills, le standard ouvert qui fournit aux agents IA des connaissances et des workflows spécialisés, à la Agentic AI Foundation (AAIF). Depuis la publication du standard en décembre 2025, plus de 70 plateformes d'agents l'ont intégré, dont ChatGPT, Cursor, GitHub Copilot et VS Code.

L'AAIF, hébergée par la Linux Foundation, a été cofondée par Anthropic avec Block et OpenAI. Anthropic lui avait déjà cédé le Model Context Protocol (MCP). Le transfert couvre le nom et le logo Agent Skills, l'organisation GitHub et le domaine agentskills.io.

Les détails

Ce qu'est un skill

Un skill est un dossier qui contient un fichier SKILL.md. Ce fichier apprend à un agent une tâche ou un domaine précis, avec les scripts et les documents de référence nécessaires. Anthropic a développé le concept en travaillant sur Claude Code. L'outil traitait correctement le travail de connaissance général mais manquait souvent des connaissances procédurales dont les tâches métier réelles ont besoin.

L'adoption

Quelques semaines après le lancement en octobre 2025, des développeurs ont publié des milliers de skills sur GitHub et écrit des chargeurs pour Codex, Cursor et OpenCode. Anthropic a ensuite publié Agent Skills comme standard ouvert, avec sa propre organisation GitHub et son propre domaine. À ce jour, 1 million de skills ont été publiés et près de 280 millions ont été installés.

La gouvernance

Anthropic affirme vouloir garder Agent Skills ouvert, porté par la communauté et indépendant des fournisseurs. L'AAIF doit offrir un foyer neutre où la communauté aura son mot à dire sur l'évolution du standard. On peut continuer à l'utiliser ou à y contribuer sans rejoindre l'AAIF.

Des ingénieurs d'Anthropic, de Google, d'OpenAI et d'autres entreprises maintiendront le standard à titre individuel. David Soria Parra et Mahesh Murag en sont les Lead Maintainers.

La suite

Anthropic propose de commencer par une feuille de route couvrant des versions numérotées, un processus formel de proposition et des recommandations de sécurité pour ceux qui écrivent et installent des skills. Comme pour MCP, le projet veut donner la priorité aux retours de la communauté et à des décisions transparentes. Un Discord permet de commenter les changements de spécification proposés.

Pourquoi c'est important

Pour un développeur qui construit des agents, le signal est double. Le format SKILL.md devient un standard dont la gouvernance ne dépend plus d'un seul éditeur, ce qui limite le risque de voir le format évoluer au gré des intérêts commerciaux d'Anthropic. Et l'écosystème est déjà large, avec 70 plateformes et un volume d'installations qui donne au format un poids difficile à ignorer.

Le parallèle avec MCP est instructif. Anthropic a suivi la même trajectoire, d'un projet interne à un standard cédé à une fondation neutre. Cela suggère que l'entreprise mise sur l'adoption large de ses formats plutôt que sur leur contrôle. Mon hypothèse est que cette stratégie sert ses intérêts autant qu'elle rassure la communauté, car un standard répandu attire les intégrations vers les produits d'Anthropic.

Reste la question de la sécurité, que la feuille de route annonce sans détailler. Un skill contient des scripts que l'agent exécute. Avec 280 millions d'installations, la surface d'attaque est réelle et les recommandations annoncées méritent d'être suivies de près. Pour une équipe qui évalue l'écriture de ses propres skills, la spécification sur agentskills.io et le processus de proposition à venir seront les deux points d'entrée à surveiller.

Source

• Donating Agent Skills to the Agentic AI Foundation · Anthropic
• Donating Agent Skills to the Agentic AI Foundation · Simon Willison

• 1Password a présenté le 22 octobre un système où l'agent IA s'authentifie avec une clé numérique propre, le gestionnaire remplit le formulaire et retire l'identifiant dès la connexion validée.
• Microsoft attribue à Storm-0940 l'usage du framework ARTEX, un outil agentique basé sur Go, pour tenter plus de 2 250 connexions sur 2 900 tentatives par minute lors de la compromission de ConnectWise Cloud Backup.
• OpenShell, un runtime publié sous licence Apache 2.0, applique les politiques d'accès au niveau du noyau et vérifie formellement chaque changement de politique avant application.
• Yelp, Delta Air Lines, JPMorgan Chase et Charles Schwab bloquent les agents IA, et Amazon a poursuivi Perplexity en justice pour son agent d'achat.

Point d'inflexion

Les agents IA ne sont plus des démonstrations. Ils se connectent à des comptes réels, manipulent des identifiants et déclenchent des actions chez des tiers. La question de leur sécurité a donc changé de nature. Elle ne porte plus sur le contenu de leurs réponses mais sur les droits qu'on leur concède et sur la manière de les révoquer.

Trois sources décrivent trois réponses techniques à ce même problème. 1Password traite l'identité de l'agent comme une identité déléguée distincte de celle de l'utilisateur. OpenShell traite l'exécution de l'agent comme un environnement à confiner au niveau du noyau. Microsoft documente ce qui arrive quand un adversaire retourne ces mêmes mécanismes contre des victimes. Le quatrième texte, sur le blocage des agents par les sites web, montre que la couche applicative refuse déjà de coopérer.

Mon hypothèse est que la sécurisation des agents va se jouer sur la durée de vie des accès plus que sur leur portée. Un jeton qui expire en quelques secondes pose moins de risque qu'un jeton permanent même très restreint. Les quatre textes convergent vers cette idée sans la formuler explicitement.

État de l'art et tendances majeures

Identités déléguées et secrets éphémères

Le mécanisme décrit par 1Password repose sur une séparation nette entre l'agent et le coffre. L'agent s'identifie auprès du gestionnaire avec une clé numérique qui lui est propre. L'utilisateur voit quel identifiant est demandé et dans quel but puis accepte ou refuse sur un appareil autorisé. Si l'accord est donné, 1Password remplit lui-même le formulaire et retire l'identifiant dès que le site valide la connexion. La société affirme que l'agent ne peut ni lire le secret ni le réutiliser, et que le reste du coffre demeure chiffré de bout en bout.

La limite est explicite dans la foire aux questions de l'entreprise. Une fois connecté au compte de la compagnie aérienne ou du site marchand, l'agent peut consulter des informations et agir dessus. 1Password recommande de vérifier la tâche et le compte avant d'approuver. Le risque se déplace donc du gestionnaire vers le périmètre du compte cible.

OpenShell applique une logique voisine sur un autre plan. Les agents ne voient jamais les vrais identifiants. Le runtime les ajoute uniquement aux requêtes destinées à des points de terminaison approuvés. Le secret n'est plus détenu par l'agent mais injecté par l'infrastructure au dernier moment.

Confinement d'exécution et vérification formelle

OpenShell instrumente le noyau pour appliquer la politique à chaque accès fichier, appel système et connexion réseau. Chaque agent tourne dans un bac à sable isolé et toute connexion sortante passe un contrôle de politique avant de quitter cet espace. Le runtime ajoute une seconde couche avec la vérification formelle. Avant qu'un changement de politique soit approuvé, le système signale les nouveaux accès risqués qu'il accorderait, comme joindre un nouvel hôte avec des identifiants ou appeler une nouvelle méthode d'API. Ces changements attendent une revue humaine.

Cette combinaison répond à un angle mort classique des politiques d'agents. Une politique écrite à la main dérive avec le temps et personne ne sait plus ce qu'elle autorise réellement. La vérification formelle rend cet effet de bord visible avant application. Cela reste à surveiller sur un point : la vérification porte sur la politique, pas sur le comportement de l'agent. Un agent qui respecte sa politique peut toujours nuire dans les limites qu'elle fixe.

Quand l'adversaire utilise les mêmes outils

Microsoft documente le revers de la médaille. Storm-0940 a utilisé ARTEX pour automatiser reconnaissance, pulvérisation de mots de passe et abus d'applications OAuth chez des victimes en aval. Entre le 10 et le 14 octobre 2026, l'infrastructure de l'attaquant a ciblé 327 comptes dans huit organisations et Microsoft a capté plus de 151 000 échecs de connexion, avec un pic à 2 900 échecs par minute le 11 octobre. Aucune authentification réussie n'a été détectée sur cette période.

La situation change le 15 octobre 2026 quand les agents obtiennent l'accès aux identités de plusieurs applications cloud de ConnectWise. Ils s'en servent pour s'authentifier auprès des environnements clients en réutilisant la confiance déjà établie par ces applications dans chaque locataire. Microsoft note que certaines attaques ont abouti à un accès privilégié en moins de trois heures. La modification des identifiants d'application peut survivre à la remédiation de l'application compromise et servir de porte dérobée.

Zscaler ThreatLabz a analysé un déploiement ARTEX configuré avec un modèle DeepSeek derrière une passerelle compatible OpenAI, avec d'autres configurations citant DeepSeek, GLM et Grok. Les invites demandaient aux modèles de se répartir les tâches d'investigation et de relire mutuellement leurs résultats. Wiz a observé des sessions de 24 à 30 heures et de nouvelles adresses IP quelques minutes après un blocage.

Architectures et outils

Le tableau met en évidence une asymétrie. Les deux outils défensifs limitent la portée ou la durée d'un accès. L'outil offensif exploite des accès déjà accordés et ne demande jamais de nouvelle autorisation. La leçon pour un architecte est que la surface d'attaque se trouve dans les intégrations existantes, pas dans les nouvelles.

Impact concret sur le workflow professionnel

Pour un développeur qui construit un agent, la première conséquence est qu'il faut traiter l'agent comme un principal d'identité à part entière. Cela implique des identifiants distincts, une journalisation par agent et une procédure de révocation qui ne passe pas par le compte de l'utilisateur. Le modèle de 1Password montre qu'un gestionnaire peut jouer ce rôle d'intermédiaire sans exposer le secret à l'agent.

La deuxième conséquence concerne l'environnement d'exécution. OpenShell impose Docker, Podman ou la virtualisation hôte, et un CNI qui applique NetworkPolicy pour un déploiement Kubernetes. Ce sont des contraintes d'infrastructure réelles, pas des options. Une équipe qui déploie des flottes d'agents doit prévoir cette couche dès le départ.

La troisième conséquence touche les intégrations côté fournisseur. Les sites bloquent déjà les agents. Yelp réserve l'accès aux agents qui paient son programme de licence de données, Delta Air Lines empêche la réservation de billets, JPMorgan Chase et Charles Schwab bloquent l'accès aux comptes pour raisons de sécurité. Meta a répondu en s'appuyant sur des partenariats avec Walmart, Gap, Sephora et Best Buy, et Shopify a ouvert son réseau de boutiques aux agents. Un agent qui échoue sur un site sans accord préalable n'est pas un bug à corriger, c'est un refus commercial.

La quatrième conséquence est défensive. Les modifications d'identifiants d'application observées par Microsoft peuvent persister après la remédiation. Une équipe qui répond à un incident doit auditer les identifiants d'application et les rôles privilégiés, pas seulement réinitialiser les mots de passe. Le lien entre confinement d'exécution et incidents d'agents est d'ailleurs documenté ailleurs sur ce blog, dans Incidents d'agents IA : des experts pointent des échecs de confinement, pas de la « misalignment ».

Conclusion et perspectives

Les quatre textes décrivent un même déplacement du problème. La sécurité des agents ne se joue plus dans le modèle mais dans les identités qu'on lui prête et dans l'environnement qui l'exécute. 1Password et OpenShell proposent deux réponses complémentaires, l'une sur le secret, l'autre sur le bac à sable. Microsoft montre que ces mécanismes peuvent être retournés et que la fenêtre de détection se compte en heures. Les sites web ajoutent une couche de refus que les agents ne peuvent pas contourner techniquement. Mon hypothèse est que les équipes qui gagneront du temps seront celles qui traiteront la révocation comme une fonctionnalité de premier plan, pas comme une procédure d'urgence.

• Donner à chaque agent une identité distincte et journaliser ses actions séparément de celles de l'utilisateur.
• Faire transiter les secrets par un intermédiaire qui les injecte par requête plutôt que de les stocker dans l'agent.
• Auditer les identifiants d'application et les rôles privilégiés après tout incident, car ces modifications peuvent survivre à la remédiation.
• Vérifier qu'un site cible accepte les agents avant de construire un parcours qui en dépend.

Questions fréquentes

Un agent peut-il lire les mots de passe de mon coffre avec le système de 1Password ?

Non selon l'entreprise. L'agent s'authentifie avec sa propre clé numérique et 1Password remplit le formulaire à sa place. Le gestionnaire retire l'identifiant dès que le site valide la connexion, et le reste du coffre demeure chiffré de bout en bout.

OpenShell empêche-t-il un agent de faire une erreur de jugement ?

Non. Le runtime applique une politique sur les fichiers, les appels système et le réseau. Un agent qui reste dans les limites de sa politique peut toujours prendre une mauvaise décision dans ce périmètre. La vérification formelle signale les nouveaux accès risqués avant application mais ne juge pas l'intention.

Pourquoi les sites web bloquent-ils les agents IA ?

Les raisons diffèrent selon les acteurs. Yelp réserve l'accès aux agents qui paient son programme de licence de données, Delta Air Lines refuse la réservation de billets et JPMorgan Chase comme Charles Schwab invoquent la sécurité des comptes. Amazon a poursuivi Perplexity en justice pour son agent d'achat et soutient que ces accès violent ses règles.

Les agents peuvent-ils contourner les protections anti-robots ?

Ils les déclenchent souvent sans les contourner. Chris Canal, dirigeant d'EquiStamp, explique que les protections mises en place contre les programmes malveillants réagissent de la même manière aux agents IA. Des utilisateurs ont signalé des blocages de comptes Google liés à l'usage de Muse pour activité suspecte.

Ressources complémentaires

• 1Password a un plan pour laisser les agents IA accéder à vos comptes, sans exposer vos mots de passe · Numerama
• Agents IA : 1Password encadre l'utilisation des identifiants · Le Monde Informatique
• China-Linked Hackers Use ARTEX AI Agents in ConnectWise Supply Chain Attack · The Hacker News
• Microsoft Links Storm-0940 to ConnectWise Supply Chain Attack · Dark Reading
• OpenShell – A safe, private runtime for fleets of autonomous AI agents · Hacker News
• Websites are closing their doors to AI agents · The Verge

DeepSeek a mis en ligne DeepInfer, le framework d'inférence haute performance qui alimente ses services de production à grande échelle. La publication est open source sous licence Apache 2.0 et couvre l'inférence hors ligne avec les fonctions nécessaires pour servir un modèle en production.

Un seul modèle est pris en charge pour l'instant : DeepSeek-V4.1-Flash. Le framework tourne sur les GPU NVIDIA SM100 et sur les NPU Huawei Ascend 950.

Les détails

Ce que contient la publication

DeepInfer embarque des noyaux optimisés (FlashMLA, DeepGEMM, DeepEP, TileKernels, DeepSelect et des noyaux TileLang sur mesure) ainsi que le runtime du modèle et de l'échantillonneur. Côté parallélisme, la source cite l'attention DP avec CP équilibré et le MoE EP avec EPLB.

Le décodage s'appuie sur DSpark et une vérification planifiée par la confiance : des jetons brouillon accélèrent la génération et des estimations de confiance décident quand vérifier. La variable DEEPINFER_ENABLE_MTP_VARLEN=1 active ce mécanisme et DEEPINFER_USE_NEXTN_DECODE fixe la longueur maximale des brouillons (5 par défaut).

Le rejeu borné du décodeur SWA réduit le travail de prefill en ne rejouant qu'un suffixe limité. Pour les réglages V4.1 par défaut, la source indique DEEPINFER_YOCO_PREFILL_TRUNCATION_MODE=compact et DEEPINFER_YOCO_PREFILL_KEEP_TOKENS=140, avec un suffixe conservé qui doit couvrir la fenêtre SWA plus la longueur maximale de retour arrière.

L'ordonnancement asynchrone, activé par défaut, fait chevaucher la planification des lots sur CPU et l'exécution sur l'accélérateur. L'inférence invariante au lot garde des résultats identiques quelles que soient les compositions de lots, via DEEPINFER_BATCH_INVARIANT=1 (NVIDIA uniquement). L'échantillonnage déterministe produit les mêmes sorties pour les mêmes jetons d'entrée et les mêmes paramètres, en combinant DEEPINFER_BATCH_INVARIANT=1 et DEEPINFER_ENABLE_MTP_VARLEN=0 avec une graine fixe passée à SamplingParams (NVIDIA uniquement). Les sorties structurées contraignent la génération à une expression régulière, un schéma JSON ou une grammaire EBNF, via so_args dans SamplingParams.

Ce qui manque encore

La publication ne suffit pas à monter un service complet. Il faut y ajouter un système de cache KV, la désagrégation VE/Prefill/Decode (dont l'essentiel du moteur est déjà implémenté selon la source), et l'équilibrage de charge entre réplicas data-parallel pour le prefill comme pour le decode.

Prérequis et mise en route

L'environnement doit être sous Linux, avec GCC 13.0 ou plus, Python 3.12, CUDA 13 côté NVIDIA et CANN 9.2 côté Ascend. La compilation se lance avec ./build.sh après avoir exporté DEEPINFER_ACCELERATOR=nvidia (ou ascend). Le point de contrôle par défaut, deepseek-ai/DeepSeek-V4.1-Flash-1017, se télécharge dans le cache Hugging Face au premier lancement. Pour partir d'une copie locale, la source mentionne la variable DEEPINFER_HF_MODEL_DIR pointant vers le répertoire du modèle. Un exemple d'inférence hors ligne est fourni dans examples/offline_inference.py.

Les mesures citées portent sur 4 GPU SM100 pour le prefill et 64 pour le decode, chaque ensemble restant dans un même domaine de mise à l'échelle. Le script run_sweep.sh permet de reproduire les benchmarks.

DeepInfer a d'abord été construit principalement sur vLLM, avec des emprunts à SGLang et TensorRT-LLM, que la source remercie.

Pourquoi c'est important

DeepSeek ne se contente plus de publier des poids de modèles : il ouvre le moteur qui les sert en production. Pour une équipe qui veut faire tourner DeepSeek-V4.1-Flash sur ses propres machines, cela donne accès aux mêmes optimisations que le fournisseur, sans avoir à réécrire un serveur d'inférence. Les noyaux et les mécanismes de décodage spéculatif sont exactement ceux qui font la différence de débit à grande échelle.

Le point à surveiller est le périmètre volontairement partiel. Cache KV, désagrégation et équilibrage de charge restent à la charge de l'exploitant. Mon hypothèse est que DeepSeek garde ces briques pour son infrastructure interne et laisse la communauté assembler le reste. Cela suggère aussi que la prise en charge d'Ascend 950 n'est pas anecdotique : le framework est pensé pour tourner sur du matériel non NVIDIA, ce qui compte pour les équipes soumises à des contraintes d'approvisionnement.

Les options d'invariance au lot et d'échantillonnage déterministe méritent une lecture attentive. Elles répondent à un problème concret des pipelines de test et d'évaluation, où deux exécutions du même prompt doivent donner le même résultat. Le fait que ces modes soient réservés à NVIDIA limite toutefois leur intérêt sur Ascend.

Source

• DeepInfer: High-performance inference framework for DeepSeek models · github.com (via Hacker News)

Le Nasdaq 100 a perdu 5,5 % la semaine dernière, ce qui a relancé les questions sur la solidité de l'investissement dans l'IA, estimé à 1 000 milliards de dollars cette année. Le mouvement semble parti de l'échec de Firmus, une société australienne de centres de données, à s'introduire sur l'ASX. Son introduction en Bourse, valorisée à plusieurs milliards de dollars, devait un temps dépasser la capitalisation de Telstra avant même que l'entreprise n'ait produit les bénéfices promis.

Les marchés américains ont rebondi lundi soir. Le Nasdaq 100 vaut encore près de trois fois plus qu'au début de 2023.

Les détails

Des valorisations très concentrées

Sur le S&P 500, Alphabet, Amazon, Apple, Meta, Microsoft, Nvidia et Tesla représentent désormais 35 % de l'indice, contre 12 % il y a dix ans. La capitalisation totale de ces sept entreprises a progressé de plus de 50 % en deux ans.

Gerard Minack, de Minack Advisors, estime que les investisseurs surestiment fondamentalement les rendements que les fournisseurs d'IA pourront dégager. Il se dit de plus en plus convaincu que ces rendements décevront, tout en reconnaissant être incapable de désigner le sommet exact du marché.

Raisah Rasid, stratège marchés chez JP Morgan Asset Management à Singapour, voit dans la récente correction « a valuation reset, rather than the market questioning the efficacy of AI itself ». Elle considère qu'il s'agit d'une transformation structurelle de long terme, très différente de la bulle internet.

Deux menaces plus sérieuses

Rasid identifie deux risques qui lui paraissent plus significatifs. Le premier est qu'un modèle d'IA open source, éventuellement chinois, vienne fragiliser l'économie du secteur et les centaines de milliards de dollars déjà investis. Minack partage cette inquiétude. Le second est qu'une opposition populaire atteigne une masse critique, que ce soit contre les projets de centres de données ou parce que l'IA ferait plus de mal que de bien aux travailleurs et à la société.

Le poids de la dette

Amazon, Microsoft, Google et Apple ont beaucoup emprunté pour financer leurs centres de données et l'infrastructure d'IA associée. Minack chiffre les dépenses d'investissement liées à l'IA de ces hyperscalers américains à 425 milliards de dollars en 2025, avec une trajectoire vers 800 milliards cette année et plus de 1 100 milliards ensuite. Selon le Fonds monétaire international, les obligations émises par ces entreprises représentent près de 10 % du marché mondial du crédit investment grade, contre 0,5 % fin 2024.

Le FMI a placé l'éclatement d'une bulle d'investissement dans l'IA en tête de trois risques menaçant l'économie mondiale, avec la hausse rapide des coûts d'emprunt et la menace d'une cyberattaque majeure.

Sally Auld, cheffe économiste de NAB, souligne un autre point de vigilance, la circularité croissante des financements entre entreprises. Un fabricant de puces peut par exemple financer la construction d'un centre de données en échange de l'achat de ses processeurs. Ces montages ne valent que ce que vaut leur maillon le plus faible. Si la demande d'IA n'est pas là, le centre ne se construit pas et les puces n'ont pas besoin d'être fabriquées.

Le cas australien

Les économistes de CBA estiment que l'Australie investira 150 milliards de dollars dans les centres de données d'ici 2030, et 260 milliards au milieu des années 2030. Auld juge cet investissement significatif mais pas majeur pour l'économie du pays, qui ne serait pas à l'épicentre d'un éventuel krach de l'IA.

Pourquoi c'est important

Pour une équipe qui construit sur des API de modèles ou qui loue du calcul, ces signaux financiers finissent par se traduire en conditions commerciales. La question de la circularité des financements mérite une attention particulière. Si un fournisseur de puces finance un centre de données pour écouler sa production, la demande observée n'est pas entièrement indépendante de l'offre. Mon hypothèse est que cette dépendance rend les prix et les capacités plus volatils qu'ils n'y paraissent.

Le risque open source cité par Rasid et Minack concerne directement les développeurs. Un modèle ouvert performant, où qu'il soit publié, pèse sur les tarifs des API propriétaires et change le calcul coût-bénéfice d'un projet. Cela reste à surveiller de près dans les prochains mois.

La saison des résultats trimestriels aux États-Unis donnera un premier verdict sur les valorisations. Auld rappelle que chaque grande technologie, des chemins de fer à internet, a connu une surcapacité. Elle en tire une question simple sur l'IA. Rien ne garantit que celle-ci échappe à la règle.

Source

• Is this the beginning of the end of the AI stock market boom? · The Guardian

La provenance des graines utilisées pour définir les courbes elliptiques standard du NIST n'avait jamais été expliquée depuis leur publication en 2000 dans le FIPS 186-2. La NSA les avait fournies sans justification, ce qui alimentait depuis des années les soupçons d'une possible porte dérobée. Un employé d'Anthropic a posé la question à un modèle de recherche interne en octobre 2026 et Claude a retrouvé l'origine des graines de P-192, P-224, P-256, P-384 et P-521 en moins d'une demi-heure.

Le résultat est prosaïque. Les graines ne sortent d'aucune fonction de hachage, contrairement à une rumeur tenace. Elles proviennent du générateur pseudo-aléatoire lrand48 des bibliothèques C, amorcé par un horodatage Unix.

Les détails

Comment Claude a procédé

Les recherches menées à partir de la rumeur d'une phrase humoristique hachée n'avaient rien donné. Claude a changé d'angle en raisonnant sur le logiciel qui avait dû produire les courbes. Il a supposé l'usage d'un générateur pseudo-aléatoire livré avec les bibliothèques C des années 1990, assez faible pour que sa sortie soit reconnaissable.

Claude a écrit un scanner qui parcourt chaque graine publiée bit par bit et teste si des blocs adjacents sont des sorties consécutives d'un générateur de cette époque. Le balayage a couvert 34 combinaisons de générateur et de découpe. Un motif est alors apparu sur les bits de poids fort de certaines graines, tous à zéro. Écrites en cinq mots de 32 bits, quatre des dix graines ont un 0 en tête pour leurs 20 mots, ce qui n'arriverait par hasard qu'avec une probabilité de 1/5810. C'est la signature de lrand48, qui ne renvoie que les 31 bits de poids fort d'un état de 48 bits.

Pour retrouver l'état, Claude a essayé les 2¹⁷ valeurs possibles des 17 bits cachés du premier mot et vérifié que les quatre suivants suivaient. La méthode a fonctionné pour les quatre graines concernées. Les graines des courbes premières venaient du même générateur mais conservaient moins de bits par sortie. Claude a ramené le problème à une réduction de base par l'algorithme Lenstra–Lenstra–Lovász (LLL), en testant toutes les fenêtres de bits possibles. Les cinq graines NIST et cinq autres issues du standard ANSI X9.62 présentaient le même motif, lrand48() >> 23.

Le générateur se remonte aussi facilement qu'il descend. Claude a reculé chaque état jusqu'à la forme produite par srand48, avec les 16 bits de poids faible à 0x330E. Pour les dix graines de courbes premières, chaque initialisation correspondait à un horodatage Unix entre mai 1997 et avril 1998. Les quatre initialisations des courbes binaires lues comme des dates donnaient février 1984. En doublant ces horodatages, on retombe sur le 17 avril 1998, deux semaines après le calcul de P-224. Le programme a peut-être divisé l'horloge par deux.

Les points de base

Claude a aussi retrouvé l'origine de certains points de base G. Ceux des six courbes générées en mai 1997 (P-192 et les cinq courbes d'exemple ANSI X9.62 prime192v2, prime192v3 et prime239v1 à v3) viennent du générateur de FreeLIP, la bibliothèque d'arithmétique sur grands entiers d'Arjen Lenstra. Les premières versions de la bibliothèque NTL de Victor Shoup embarquent le même code. Les graines du générateur sont 20000 pour P-192, 20420, 20507 et 20509 pour prime239v1 à v3, et 20512 et 20517 pour prime192v2 et v3.

Les points de base de P-224, P-256, P-384 et P-521 ne suivent pas cette recette et restent inexpliqués, tout comme ceux des courbes binaires du NIST. La graine de B-163 résiste aussi à toutes les tentatives.

Ce qui reste ouvert

Certains candidats viables ont été écartés lors de la génération. Pour P-256, la graine publiée est le candidat 1842, mais le candidat 876 de la même exécution donne aussi une courbe d'ordre premier de la bonne taille. Le calcul de P-224 a sauté trois courbes de ce type et les deux exécutions derrière les courbes ANSI X9.62 en ont sauté sept de plus. Les auteurs ne savent pas quels critères ont été appliqués, ni s'il s'agit d'un artefact involontaire.

La prime de 36 864 dollars pour la découverte des graines sera versée à l'Internet Security Research Group. Les travaux ont été menés chez Anthropic par John Wood, Henry de Valence, Ava Howell, Zack Voase, Lucy Sweet, Amir Omidi, Paul Crowley, Iain McGinniss, Nicholas Carlini et Steve Weis.

Pourquoi c'est important

Il ne s'agit ni d'une attaque ni d'une faiblesse des courbes ECDSA. Les auteurs estiment au contraire que ces résultats renforcent la confiance dans les paramètres, puisqu'une génération aussi simple laisse peu de place à une subversion délibérée. Mon hypothèse est que le précédent le plus intéressant n'est pas cryptographique mais méthodologique : un modèle a résolu en trente minutes un problème ouvert depuis vingt-cinq ans en raisonnant sur le logiciel de l'époque plutôt qu'en cherchant la bonne phrase. Cela suggère que les modèles peuvent être utiles pour l'archéologie logicielle, quand les archives ont disparu et que seuls les artefacts subsistent. Le fait que les points de base de plusieurs courbes restent inexpliqués montre aussi que le travail n'est pas terminé.

Source

• Claude reveals ECDSA curve origins · anthropic.com (via Hacker News)

Un chercheur en interprétabilité mécaniste affirme que les réseaux de neurones sont bien plus lisibles que son domaine ne le pensait. L'argument central en faveur de la « superposition », l'idée qu'un réseau empile des concepts sans rapport faute de place, reposait selon lui sur une lecture erronée. Ce qui ressemblait à un empilement arbitraire relève surtout d'un motif qu'il nomme « généralisation récursive » et qui pose bien moins de problèmes. On pourrait donc étudier les réseaux directement sans devoir d'abord les « dénouer ».

Il s'appuie sur plusieurs cas concrets, dont InceptionV1 et des modèles de langue récents. Sa thèse : la polysémanticité canonique venait en grande partie d'outils d'analyse insuffisants et de défauts d'architecture.

Les détails

Le cas InceptionV1

La dernière couche d'InceptionV1 semblait pleine de mélanges arbitraires et presque aucun neurone n'y était facilement interprétable. L'auteur l'explique par des défauts d'architecture qui saturaient les dernières couches et par des outils d'interprétabilité trop grossiers pour le voir. Des corrections d'architecture ordinaires suffisent à rendre 99 à 100 % des neurones de cette couche faciles à interpréter. Ni la taille du modèle ni les données d'entraînement ne changent. Il dit avoir entraîné des versions dont la taille varie d'un facteur 300 et toutes restent largement lisibles.

Le circuit « chien/voiture »

En 2019 il avait présenté avec Chris Olah un circuit où une caractéristique « voiture » semblait se répandre dans des neurones « chien » sans rapport. Il estime aujourd'hui qu'aucune partie du réseau n'exploite cette combinaison en aval. Il s'agissait de généralisation et de composition ordinaires. À sa connaissance personne n'a publié depuis un second circuit de cette forme.

Les modèles de langue

Le texte cite deux travaux de 2023. « Towards Monosemanticity » d'Anthropic étudiait un petit modèle à une couche où le neurone médian obtenait 0 sur une échelle de 14. Un projet d'interprétabilité automatisée lancé chez OpenAI trouvait environ 1,7 % de neurones interprétables. Avec de meilleurs outils et des modèles actuels le tableau change. Des audits préliminaires de Qwen3-32B attribuent une tâche principale à environ 90 % des pôles de neurones. Environ 7 % en ont deux liées et seulement 2 à 4 % restent incompris. L'auteur rapporte des résultats comparables sur des modèles de plusieurs milliers de milliards de paramètres comme Kimi K3 et annonce un second article pour les détailler.

La généralisation récursive

Le motif est simple. Un neurone qui détecte « iy » se met à détecter « diy » puis « do it yourself » qui ne contient plus « iy ». L'idée figurait déjà dans une sous-section passée inaperçue d'un article de 2021 sur les neurones multimodaux. L'auteur prévient que les pourcentages dépendent des seuils choisis et qu'il ne faut pas les traiter comme un score précis à optimiser.

Pourquoi c'est important

Pour une équipe d'interprétabilité la thèse change l'ordre du travail. Au lieu d'entraîner un second modèle comme un autoencodeur parcimonieux pour approcher le réseau « déplié » on inspecterait directement neurones et circuits en suivant leur croissance pendant l'entraînement. Les boucles d'expérimentation seraient plus simples et moins chères.

Mon hypothèse est que l'effet le plus concret portera sur les outils. L'auteur cite un neurone « Titanic » mal jugé parce que l'outil ne regardait que le contexte précédent. Si l'essentiel de la polysémanticité apparente vient de là alors améliorer les métriques compte plus que changer de méthode d'analyse. Deux points à surveiller : la reproduction de ces chiffres sur d'autres modèles et la façon de fixer les seuils puisque l'auteur lui-même prévient que le résultat en dépend fortement.

Source

• Neural networks are clean · already-clean.goodfire.com (via Hacker News)

Google déploie Gemini 4 Argon à l'échelle mondiale. Le modèle est accessible aux développeurs, aux entreprises et aux consommateurs via l'API dans AI Studio et la plateforme Gemini. Les abonnés Google AI Ultra peuvent l'utiliser dans Google Antigravity, tandis que les abonnés AI Ultra et Pro y accèdent via l'application Gemini et le mode IA de Google Search.

Argon remplace la classe Gemini Pro et devient la nouvelle série frontier de Google. Les utilisateurs gratuits et les abonnés Plus sont désormais limités aux modèles Flash, moins performants, dans le cadre d'une nouvelle structure de niveaux. Google indique que d'autres modèles Gemini 4 suivront, ce qui suggère des variantes Flash mises à jour qui finiraient par être proposées aux utilisateurs gratuits et Plus. En interne, Google testerait déjà un successeur potentiel nommé « Carbon », censé surpasser Argon en codage.

Les détails

Tarifs et classements

Le tarif reste celui annoncé précédemment : 2 dollars par million de tokens en entrée et 10 dollars par million en sortie au tarif d'introduction, avec une réduction de 95 % sur les entrées mises en cache. Argon occupe la première place du Vals Index, mais reste derrière Claude Opus 5.5 d'Anthropic dans les classements globaux indépendants. Google ayant attendu environ deux semaines pour livrer, le modèle se situe aussi derrière Muse Wonder Full de Meta, lancé la veille.

Gains internes revendiqués

Google partage des chiffres internes auto-déclarés. Les ingénieurs logiciels utilisant Argon auraient augmenté de plus de 35 % les soumissions de code pilotées par agent, tandis que les rollbacks de code auraient chuté de près d'un tiers. Dans le projet Chromium, Argon a aidé l'équipe Chrome à mener un refactoring architectural sur des centaines de fichiers dans une base de code de 40 millions de lignes : un travail qui aurait pris des mois a été achevé en quelques semaines. Pour les utilisateurs, les pages web peuvent se déplacer entre onglets, barres latérales et fenêtres flottantes sans rechargement.

Avec l'Agent Development Kit open source de Google, Argon a tourné en autonomie pendant la nuit et trouvé des optimisations réduisant de 40 % le temps de préparation de session et accélérant de 21 % les imports à froid. La vitesse d'inférence des modèles ouverts Gemma sur un A100 via vLLM est passée d'environ 37 900 à plus de 108 000 tokens par seconde, soit un facteur de 2,85. Les changements sont visibles dans des pull requests upstream.

Argon peut aussi générer des modèles 3D complexes, des jeux et des animations en code pur exécutés directement dans le navigateur. Une démo présente un moteur de raytracing écrit entièrement en Python sans bibliothèque externe ; Google a publié le code source. Dans une autre démo, Argon part d'une seule image dans Antigravity et pilote Blender via MCP dans une boucle autonome, modélisant une architecture gothique et configurant un éclairage réactif à l'audio.

Accès chercheurs et sécurité

Google offre à 10 000 chercheurs le plus haut niveau d'utilisation de Google Antigravity gratuitement pendant six mois, les places étant attribuées au fil de l'eau selon l'éligibilité, la capacité et la sélection. Les défenseurs en cybersécurité peuvent candidater séparément au programme Fairwind, qui donne accès à Argon sans garde-fous cyber ; Google prévoit d'étendre ce programme à des centaines de partenaires supplémentaires.

Côté sécurité, Google qualifie l'architecture d'Argon de plus robuste à ce jour. Le red teaming externe en biologie aurait contourné moins de 1 % des contrôles testés, et sur un ensemble adversarial, les violations auraient chuté de près de moitié par rapport aux modèles Gemini antérieurs. Les tentatives de raccourcis non autorisés par l'agent tombent à 2 %, avec un moniteur de désalignement automatisé analysant en temps réel le raisonnement et les actions. Argon obtient aussi le plus faible taux d'attaque sur le benchmark Gray Swan d'injection indirecte de prompt, avec 0,7 % de réussite sur 15 tentatives adaptatives, contre 8,5 % pour GPT-6 Astra et 4,8 % pour Claude Opus 5 lors du test précédent — la source note que Google ne précise pas si les tests étaient identiques.

Pourquoi c'est important

Pour une équipe qui construit sur des API, la segmentation par niveaux change la donne : les modèles frontier deviennent un produit payant, et les utilisateurs gratuits ou Plus basculent sur des Flash. Cela suggère de vérifier dès maintenant quels modèles vos intégrations ciblent réellement, et de prévoir une stratégie de repli si un modèle change de palier.

Les chiffres internes sur Chromium et l'Agent Development Kit sont auto-déclarés, donc à prendre avec prudence, mais ils pointent une tendance : les agents autonomes qui tournent la nuit sur du refactoring et de l'optimisation deviennent un usage de production, pas une démo. Le taux de 0,7 % sur Gray Swan est à surveiller pour les équipes qui exposent des agents à des entrées non fiables, même si la comparabilité des tests reste incertaine. Enfin, le programme Fairwind — accès sans garde-fous cyber — mérite une lecture attentive : c'est un outil de recherche défensive, mais il élargit volontairement la surface d'usage.

Source

• Gemini 4 Argon is now available worldwide as Google's most capable frontier model · The Decoder
• Google finally releases Gemini 4 Argon · The Verge
• Gemini 4 Argon begins rolling out in Gemini app and Antigravity, but only if you pay · Ars Technica
• Gemini 4 Argon: Built to solve your hardest problems · Google AI

Un billet partagé sur Hacker News décrit un écart croissant dans la compréhension des capacités des grands modèles de langage (LLM). L'auteur estime que la population se répartit en plusieurs cercles très inégaux : environ 6 milliards de personnes (75 % de la population) n'ont presque pas eu de contact avec les LLM ; 1 à 2 milliards (20 %) les utilisent occasionnellement via des versions gratuites de produits type ChatGPT ; environ 20 millions (0,2 %) en font un usage professionnel de pointe, notamment en mathématiques et en programmation ; et environ 5 000 personnes (0,00006 %) ont accès en interne à des systèmes de frontière.

Cette répartition ne relève pas seulement d'une différence d'opinion : elle dépend de l'ambition des problèmes traités, du caractère vérifiable des domaines, et du niveau d'accès. L'auteur souligne que ces situations coexistent au même moment, ce qui rend le débat public difficile.

Les détails

Quatre niveaux d'exposition

L'auteur distingue quatre groupes. Le premier, le plus nombreux, n'a quasiment pas utilisé de LLM. Le deuxième, environ 1 à 2 milliards de personnes, se sert de versions gratuites et perçoit des chatbots approximatifs, utiles comme moteur de recherche amélioré ou aide à la rédaction. Même des professionnels hors mathématiques et code s'y trouvent : des dirigeants, par exemple, passent beaucoup de temps à parler à d'autres personnes et gardent une compréhension abstraite de ces outils.

Le troisième groupe, environ 20 millions de personnes, utilise des LLM de qualité frontière en mathématiques et en programmation. L'auteur y voit des projets complexes, qui prenaient des semaines ou des mois, réalisés par des agents sur simple invite : construire des applications, les copier, les traduire, les décompiler à partir de binaires. Il rappelle qu'il y a moins d'un an, il écrivait encore son code manuellement, caractère par caractère, avec parfois la touche Tab pour compléter un fragment.

Le quatrième groupe, environ 5 000 personnes, a accès en interne à des systèmes de frontière. L'auteur évoque des essaims de milliers d'agents collaborant sur des semaines pour des mégaprojets logiciels : découverte de failles zero day, attaques et défenses informatiques à la vitesse de la machine, nouvelles découvertes scientifiques, avancées en mathématiques. Des travaux qui auraient pris des années à des professionnels de premier plan. Il note que la relecture et la compréhension humaines commencent à prendre du retard, citant l'« archéologie » de l'incident OpenAI-HF de plusieurs mois auparavant, ou les 722 manuscrits de mathématiques de frontière que les mathématiciens pourraient mettre du temps à examiner.

Trois facteurs qui expliquent l'entonnoir

L'auteur avance trois causes. D'abord, l'impact croît avec l'ambition, la taille du problème et l'horizon : une question dont la réponse tient en un paragraphe sollicite peu le système ; il faut un réservoir de problèmes difficiles qui comptent vraiment. Ensuite, la « jaggedness » du système : les capacités culminent dans les domaines numériques, vérifiables et économiquement précieux, car elles émergent d'un apprentissage par renforcement sur des récompenses vérifiables, dans un mélange d'environnements guidé par le potentiel de revenus. Enfin, l'accès : gratuit, payant, interne.

Pourquoi c'est important

Pour un développeur ou une équipe, ce constat suggère que l'écart de perception ne se réduit pas à une question d'opinion. Il dépend du niveau d'accès et du type de problèmes traités. Une équipe qui n'utilise que la version gratuite d'un chatbot risque de sous-estimer ce que permettent les systèmes de pointe sur du code ou des mathématiques, tandis qu'une équipe qui travaille sur des projets longs et vérifiables peut au contraire surestimer la facilité de généralisation à d'autres domaines.

Mon hypothèse est que les équipes qui sauront calibrer leurs attentes par domaine, plutôt que par impression générale, tireront mieux parti de ces outils que celles qui se fient à un seul essai sur la version gratuite.

Source

• The gap in shared understanding of LLM capability is widening · twitter.com (via Hacker News)

OpenAI a publié un ensemble de 722 manuscrits présentant des résultats mathématiques générés par un modèle de frontière non diffusé, couvrant 372 familles de résultats qui regroupent des articles liés. Selon AGMAI, le groupe consultatif indépendant formé pour communiquer ces résultats de manière responsable, cette publication inclut des solutions à des « centaines » de questions ouvertes. Le volume est tel qu'OpenAI a jugé nécessaire de publier des conseils pour naviguer dans le dépôt GitHub associé.

Cette annonce prolonge une série de percées qui ont impressionné et déstabilisé une partie de la communauté mathématique, tout en soulevant des questions sur l'éthique de la recherche et la conduite académique. Les résultats étaient attendus depuis des semaines : en septembre, OpenAI avait déclaré que son modèle avait « résolu plus de 100 problèmes ouverts de longue date dans la plupart des domaines des mathématiques ». La publication inclut également des résumés du raisonnement du modèle, des estimations du calcul utilisé et des statistiques sur le nombre de problèmes tentés. OpenAI affirme que le « résultat moyen » a utilisé l'équivalent de trois heures de réflexion de ChatGPT Pro.

Ce qui vient de changer, c'est l'échelle et la nature de la production mathématique assistée par IA. Il ne s'agit plus de démonstrations anecdotiques ou de benchmarks contrôlés, mais d'un flux massif de manuscrits couvrant la combinatoire, plusieurs branches de la géométrie, la théorie des nombres, l'informatique théorique, l'algèbre, la topologie, les probabilités et la mécanique statistique, ainsi que la physique mathématique. Pour les développeurs et data scientists, cela signale un changement de régime : les modèles de frontière ne se contentent plus de résoudre des problèmes bien posés, ils produisent des artefacts de recherche qui nécessitent une infrastructure de vérification, de traçabilité et de gestion de la qualité.

État de l'art et tendances majeures

La vérification formelle comme goulot d'étranglement

L'un des points saillants de cette publication est l'utilisation de Lean, un langage de programmation et assistant de preuve qui permet de vérifier les résultats par calcul. Ces formalisations ont joué un rôle déterminant dans l'évaluation de certaines des précédentes affirmations mathématiques d'OpenAI, donnant aux chercheurs la confiance qu'une affirmation est logiquement correcte même s'ils ne comprennent pas pleinement l'argument sous-jacent.

Cependant, le degré de vérification varie énormément. Sur GitHub, OpenAI reconnaît que les résultats sont « à différents stades de vérification » et que « beaucoup, mais pas tous, des manuscrits ont été formalisés ». Au moment de la rédaction, moins de la moitié des manuscrits de la collection semblent avoir été décrits formellement. OpenAI indique que seulement 300 résultats de premier plan sur 719 manuscrits ont été formalisés, soit environ 42 %, et que le dépôt « sera mis à jour avec davantage de formalisations au fur et à mesure que nous les obtiendrons ».

Plusieurs mathématiciens se sont plaints du manque de formalisation, en particulier compte tenu du nombre de résultats. Même lorsqu'un code Lean accompagne un résultat, l'évaluation n'est pas instantanée : les chercheurs doivent vérifier que la formalisation prouve réellement ce que le résultat prétend, un processus chronophage. Plusieurs personnes ayant examiné les articles ont déclaré que même lorsque des preuves vérifiables par ordinateur étaient fournies, la qualité était incohérente et les énoncés vérifiés ne correspondaient pas toujours parfaitement aux affirmations des manuscrits accompagnants.

Kevin Buzzard, professeur de mathématiques à l'Imperial College London, a identifié de nombreux théorèmes dans son domaine — la théorie algébrique des nombres — dont seulement environ six se sont immédiatement « démarqués ». Peu, voire aucun, ne semblaient formellement vérifiés dans Lean. « Par conséquent, soit je dois lire du slop potentiellement incorrect, soit attendre que d'autres le fassent, soit attendre que quelqu'un les formalise avant de pouvoir dire avec certitude que les résultats sont même corrects. »

Le « slop » et la crise de la reproductibilité

Le terme « slop » désigne du matériel généré par IA de faible qualité, souvent erroné, qui prolifère en ligne et dans le monde réel, y compris dans les articles académiques. Comme dans d'autres domaines, les mathématiciens ont constaté une forte augmentation de ce type de matériel produit avec des outils comme ChatGPT et Claude ces dernières années. Une grande partie est confuse, difficile à lire et démontre peu de compréhension du sujet ; elle est particulièrement défaillante en matière de créditation des autres chercheurs.

Les précédentes publications mathématiques d'OpenAI ont été largement critiquées par les experts pour leur nature bâclée, en particulier leur attribution médiocre ou inexistante. Avant la publication, plusieurs chercheurs avaient pris l'habitude d'appeler le flot imminent d'articles la « slopocalypse » ou des variantes similaires. Savoir si cette « slopocalypse » redoutée s'est matérialisée est difficile à dire, en grande partie à cause du volume déroutant de matériel publié.

Les premières indications suggèrent qu'OpenAI a pris davantage de soin avec les articles cette fois-ci, ou du moins avec certains d'entre eux. Plusieurs mathématiciens ont déclaré que leurs premières impressions étaient bien meilleures que prévu, même si, de leur propre aveu, la barre n'était pas très haute compte tenu des précédentes publications bâclées de l'entreprise. Mais mieux ne signifie pas nécessairement bon, encore moins conforme aux normes habituellement attendues pour des travaux académiques de cette ampleur.

Nalini Joshi, professeure de mathématiques à l'Université de Sydney, a noté que certains des articles qu'elle a examinés « ont des bibliographies courtes ». Compte tenu des critiques précédentes sur les pratiques de créditation d'OpenAI, elle se dit « méfiante quant au fait que l'attribution dans les articles puisse manquer l'histoire complète ». Brendan Hassett, professeur de mathématiques à Brown, a déclaré : « La rédaction du problème que je connais le mieux n'avait guère de sens après une lecture rapide. Si cela avait été écrit par une personne, je n'aurais pas passé plus de temps à essayer de comprendre. Bien sûr, cela laisse 721 autres préprints ! »

L'impact sur les carrières et l'écosystème académique

Au-delà des questions techniques, la publication soulève des inquiétudes profondes sur l'avenir des carrières académiques. Plus de trois douzaines de mathématiciens ont décrit la publication comme « stupéfiante », « accablante », « sans précédent », « surréaliste » ou « pure folie ». Certains craignent que des carrières soient bouleversées du jour au lendemain et que les universitaires doivent séparer les solutions du slop pendant qu'OpenAI passe à autre chose.

Un chercheur a résumé la situation : « Si les IA disparaissaient maintenant, comme si des extraterrestres étaient venus sur Terre puis repartis, nous étudierions cela pendant les 10 prochaines années, en essayant de tout comprendre. » Un autre a averti : « C'est un grand gâchis. Cela peut causer un effondrement massif de la culture académique et simplement tuer la plupart des facultés. C'est un problème social et il semble que les laboratoires d'IA ignorent complètement cette question. »

AGMAI a publié ses premières recommandations fin septembre, exhortant les laboratoires d'IA à publier les résultats mathématiques rapidement et par les canaux académiques établis lorsque c'est possible, tout en divulguant des détails tels que le nom du modèle utilisé, les invites et les coûts de calcul. Le groupe a également imploré les entreprises d'IA de « s'abstenir de traiter la publication de résultats mathématiques comme des véhicules marketing pour promouvoir leurs modèles », une pratique qui, selon eux, cause un préjudice important à la communauté mathématique.

Architectures et outils

Impact concret sur le workflow professionnel

Pour les développeurs et data scientists, cette publication a des implications directes sur plusieurs plans. D'abord, la vérification formelle devient une compétence différenciante. Lean n'est plus un outil de niche pour théoriciens : il devient un maillon critique dans la chaîne de validation des résultats générés par IA. Les équipes qui intègrent des assistants de preuve dans leurs pipelines de recherche pourront filtrer plus efficacement le bruit et le slop.

Ensuite, la gestion de la qualité des sorties de modèles génératifs prend une nouvelle dimension. Les problèmes observés — bibliographies courtes, attribution manquante, incohérence entre les énoncés formels et les affirmations textuelles — sont des symptômes classiques de systèmes génératifs non supervisés. Les data scientists travaillant sur des pipelines de génération de contenu technique devront mettre en place des mécanismes de vérification croisée, des contrôles de cohérence et des métriques de qualité automatisées.

La question de l'échelle est également centrale. OpenAI affirme que le « résultat moyen » a utilisé l'équivalent de trois heures de réflexion de ChatGPT Pro. Pour les équipes qui cherchent à reproduire ou à s'appuyer sur ces résultats, cela signifie des coûts de calcul non négligeables et une planification rigoureuse des ressources. La publication inclut des estimations de calcul, ce qui permet de calibrer les attentes.

Enfin, l'aspect éthique et social ne peut plus être ignoré. La crainte d'un « effondrement massif de la culture académique » et la nécessité de créditer correctement les travaux humains sous-jacents sont des enjeux qui touchent directement les pratiques de développement. Les équipes qui construisent des produits sur des modèles de frontière doivent anticiper les questions de conformité, de traçabilité et de responsabilité.

Conclusion et perspectives

La publication par OpenAI de 722 manuscrits mathématiques générés par un modèle non diffusé marque un point d'inflexion dans la manière dont les IA interagissent avec la recherche fondamentale. Si les résultats incluent des travaux jugés de très haut calibre — certains auraient mérité une publication dans des revues de premier rang et auraient pu suffire à asseoir une carrière académique, voire à faire d'un mathématicien un sérieux candidat pour une médaille Fields —, le manque de formalisation, les problèmes d'attribution et le volume écrasant créent une situation inédite. Les chercheurs estiment qu'il faudra des années pour comprendre pleinement ce qui a été publié. Mon hypothèse est que cette dynamique va s'accélérer avec les laboratoires concurrents comme Anthropic, et que la communauté devra développer des infrastructures de vérification à la hauteur.

Recommandations actionnables :

1. Intégrer Lean ou un assistant de preuve équivalent dans vos pipelines de validation dès que vous manipulez des résultats mathématiques générés par IA, et ne considérez un résultat comme fiable que lorsque sa formalisation a été vérifiée indépendamment.

2. Mettre en place des contrôles automatisés de qualité sur les sorties de modèles génératifs : détection de bibliographies courtes ou manquantes, vérification de la cohérence entre énoncés formels et textes, et alertes sur les attributions suspectes.

3. Documenter systématiquement les coûts de calcul, les invites et les versions de modèles utilisés dans vos expérimentations, en vous alignant sur les recommandations d'AGMAI, afin de faciliter la reproductibilité et l'audit par les pairs.

4. Anticiper les implications éthiques et sociales en formant vos équipes aux risques de « slop » et en établissant des politiques claires de créditation des travaux humains sous-jacents.

Ressources complémentaires

• ‘Pure insanity’: Mathematicians will need years to make sense of OpenAI’s latest drop · The Verge
• OpenAI drops another batch of mathematical breakthroughs · The Verge

OpenAI a publié cette semaine près de 400 résultats mathématiques générés par IA, répartis sur plus de 700 manuscrits couvrant la combinatoire, plusieurs branches de la géométrie, la théorie des nombres, l'informatique théorique, l'algèbre, la topologie, les probabilités, la mécanique statistique et la physique mathématique. Le volume est tel qu'OpenAI a jugé nécessaire de publier un guide pour naviguer dans le dépôt GitHub qui héberge l'ensemble.

Plus de trois douzaines de mathématiciens interrogés par The Verge ont employé des mots comme « stupéfiant », « accablant », « sans précédent », « surréaliste » ou « pure folie » pour décrire la livraison. Beaucoup estiment qu'il faudra des années rien que pour comprendre ce qui a été publié, et craignent qu'OpenAI ne passe à autre chose — ou ne publie davantage — bien avant.

Les détails

Vérification partielle et inégale

Parmi les manuscrits figurent des formalisations en Lean, un langage de programmation et assistant de preuve qui permet de vérifier les résultats par calcul. Ces formalisations ont déjà servi à évaluer certaines affirmations mathématiques antérieures d'OpenAI. Mais le degré de vérification varie fortement : sur GitHub, OpenAI reconnaît que les résultats sont « à différents stades de vérification » et que « beaucoup, mais pas tous, des manuscrits ont été formalisés ». L'entreprise indique que seuls 300 résultats principaux sur 719 manuscrits ont été formalisés, soit environ 42 %, et qu'elle « mettra à jour le dépôt avec davantage de formalisations » au fur et à mesure.

Plusieurs mathématiciens déplorent ce manque de formalisation, d'autant que même lorsqu'un code Lean accompagne un résultat, l'évaluation n'est pas instantanée : il faut vérifier que la formalisation prouve bien ce que le résultat prétend. Plusieurs chercheurs ayant épluché les articles rapportent une qualité inégale et des énoncés vérifiés qui ne correspondent pas toujours aux affirmations des manuscrits.

Qualité et attribution en question

Kevin Buzzard, professeur à l'Imperial College London, dit avoir identifié de nombreux théorèmes dans son domaine (théorie algébrique des nombres) dont seulement environ six lui ont immédiatement « sauté aux yeux ». Presque aucun ne semblait formellement vérifié en Lean. « Je dois donc soit lire du slop potentiellement incorrect, soit attendre que d'autres le fassent, soit attendre que quelqu'un les formalise avant de pouvoir dire que les résultats sont même corrects », résume-t-il.

Le terme « slop » désigne du contenu généré par IA de faible qualité et souvent erroné. Les mathématiciens interrogés disent constater une forte hausse de ce type de matériel produit avec des outils comme ChatGPT et Claude, difficile à lire et peu rigoureux sur le crédit aux autres chercheurs. Les précédents écrits mathématiques d'OpenAI avaient été largement critiqués pour leur négligence, notamment leur attribution défaillante. Avant la publication, certains chercheurs parlaient de « slopocalypse ».

Brendan Hassett, professeur à Brown, raconte que « la rédaction du problème que je connais le mieux n'avait guère de sens après une lecture rapide » et qu'il n'aurait pas insisté s'il avait été écrit par un humain. Nalini Joshi, de l'université de Sydney, note que certains articles examinés « ont des bibliographies courtes » et se dit « méfiante quant au fait que l'attribution dans les articles puisse manquer une partie de l'histoire ». D'autres relèvent l'extraordinaire brièveté de travaux qui auraient normalement occupé des centaines de pages.

Des résultats jugés de haut niveau

Malgré ces réserves, le consensus est que la publication contient des travaux genuinely impressionnants. Dans un monde sans IA, beaucoup de ces résultats auraient mérité des revues de premier rang et auraient pu suffire à asseoir une carrière académique. Quelques-uns sont décrits comme le genre de travail qui pourrait faire d'un mathématicien un sérieux candidat à une médaille Fields.

Jared Duker Lichtman, de Stanford, cite « des dizaines » de résultats dans cette catégorie, dont des progrès vers l'hypothèse de Riemann, un cas particulier de la conjecture de Hodge et une solution à la conjecture de Kakeya en dimension quatre. Riemann et Hodge figurent parmi les sept problèmes du prix du millénaire. Scott Armstrong souligne qu'« il ne s'agit pas de problèmes farfelus que personne n'a jamais entendus » et que beaucoup sont « des problèmes très connus que beaucoup de gens ont tenté de résoudre pendant des décennies ».

Un paysage bouleversé

De nombreux chercheurs ont vu des années de travail et des plans de recherche soigneusement établis s'évaporer d'un coup. Tristan Buckmaster, de NYU, dit avoir entendu parler de « trois personnes dont des programmes de recherche entiers ont été anéantis ». Colva Roney-Dougal, de l'université de St Andrews, évoque une ambiance sombre et des collègues dont « les demandes de subvention viennent d'être anéanties ». Francesco Fournier-Facio, de Heriot-Watt, observe que les chercheurs en probabilités, combinatoire et informatique théorique semblent « particulièrement sous le choc », certaines régions de la théorie des groupes ayant été « rasées ».

Pourquoi c'est important

Pour un développeur ou une équipe qui travaille avec des modèles génératifs, cette séquence illustre un problème qui dépasse les mathématiques : produire massivement du contenu plausible est désormais facile, le vérifier ne l'est pas. Le taux de 42 % de formalisation rapporté par OpenAI montre que même l'éditeur ne peut pas garantir la validité de tout ce qu'il publie. Cela suggère que les pipelines de vérification automatique — ici Lean — deviennent un maillon critique dès qu'on automatise la production de résultats techniques.

À surveiller : la manière dont les communautés scientifiques s'organisent face à ce type de livraison. Si les chercheurs doivent trier eux-mêmes le bon grain de l'ivraie, la charge de relecture se déplace vers ceux qui ont le moins de ressources, et l'attribution devient un enjeu de crédibilité. Mon hypothèse est que les outils de vérification formelle et de traçabilité des sources vont devenir aussi importants que les modèles eux-mêmes.

Source

• ‘Pure insanity’: Mathematicians will need years to make sense of OpenAI’s latest drop · The Verge