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

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

Anthropic abandonne Git pour un système propriétaire

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

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

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

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

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

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

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

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

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

Source de vérité	Spanner et GCS
Modèle de cohérence	Append-only (changesets) sur Spanner, données dérivées asynchrones
Écritures	Aucun push, commits créés côté serveur sans verrou
Format de transfert	Arbres et blobs individuels adressés par contenu
Compaction	Éliminée (aucun packfile, aucun repacking)

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

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

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

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

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

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

Source de vérité	WAL S3
Modèle de cohérence	Stricte et linéarisable via index S3
Écritures	Locale + S3 en parallèle, linéarisée par CAS sur l’index S3
Format de transfert	Packfiles classiques
Compaction	Repackaging asynchrone sur répliques découplées

OpenAI opte pour la cohérence causale…

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

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

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

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

… et pour des packfiles réutilisables

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

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

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

Source de vérité	Stockage objet immuable + magasin de métadonnées
Modèle de cohérence	Cohérence causale
Écritures	Streaming direct vers le magasin d’objets sans décompression locale
Format de transfert	Packfile vide inline + URI de packfiles précompressés réutilisables
Compaction	Hiérarchique multiniveaux façon LSM-Tree (L0 à L4)

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

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

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

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

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

Source de vérité	Azure Blob Storage
Modèle de cohérence	Forte via quorum délimité par référence
Écritures	Concurrentes sur branches disjointes via quorum par référence
Format de transfert	Packfiles classiques
Compaction	Workers d’arrière-plan isolés du chemin critique

Illustration générée par IA

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

Du 21 juillet au 11 août 2026, deux chercheurs extérieurs, issus de METR et de Redwood Research, ont eu un accès approfondi aux infrastructures d’OpenAI pour tester son système de détection du désalignement de ses agents.

METR décrit un exercice pilote de red-teaming « à haut niveau d’accès » au cours duquel ils ont pu consulter le code interne, les prompts et configurations des moniteurs ainsi que la documentation. L’exercice porte sur le système tel qu’il existait le 21 juillet et avant. OpenAI l’élargissait alors : ces évolutions n’ont pas été évaluées, et les constats ne décrivent donc pas la couverture actuelle.

Les deux chercheurs ont mené des entretiens techniques avec une douzaine de chercheurs et d’ingénieurs des équipes de surveillance, de sûreté des systèmes et de sécurité. Ils travaillaient sur des appareils fournis par OpenAI qui ne quittaient pas les locaux.

Dans un rapport interne, partagé avec les chercheurs et les équipes de sécurité d’OpenAI, ils cherchent à répondre à deux questions :

• quelle part de l’activité des agents est réellement surveillée ?
• un agent pourrait-il, en théorie, désactiver ou détourner le système de surveillance ?

Les règles de publication ont été fixées à l’avance : un billet de blog relativement bref et de haut niveau, et la possibilité pour OpenAI de retirer, à sa seule discrétion, toute information jugée confidentielle ou sensible.

Le billet de METR précise que, contrairement à d’autres missions, comme son enquête distincte sur l’incident Hugging Face, l’organisation n’avait pas ici le droit unilatéral de décrire ces retraits.

Entre 75 % et 94 % du trafic estimé éligible à la surveillance

Les chercheurs estiment qu’entre 75 % et 94 % du trafic agentique de l’API interne Responses, qui alimente notamment Codex, était éligible à la surveillance pour les modèles au moins aussi puissants que GPT-5.5, avec une forte incertitude dans les deux sens.

Pour le sous-ensemble utilisé par les agents Codex internes, la part atteint 99,2 %.

« Éligible » signifie destiné à être envoyé au moniteur : erreurs, délestage ou bugs peuvent en empêcher une partie d’aboutir. Le chiffre exclut d’autres sources de trafic, comme les agents tournant sur le service d’inférence interne de la recherche, dont le volume n’a pu être estimé.

Selon ce qui a été indiqué aux chercheurs, un sous-ensemble des sessions d’entraînement par apprentissage par renforcement était surveillé entre mars et juin. Au début de l’exercice, ces sessions n’étaient plus couvertes.

L’absence de surveillance des événements de compaction a probablement laissé sans contrôle de l’ordre de 10 % du trafic Codex éligible entre mai et juillet 2026. L’incertitude est forte, car l’information nécessaire n’était pas journalisée. OpenAI avait identifié le problème avant l’exercice et l’a corrigé pendant celui-ci.

Le moniteur se déclenchait quand l’agent rendait la main à l’utilisateur. Pendant la période sans surveillance de la compaction, un agent pouvait donc, en enchaînant les actions, repousser indéfiniment son examen. METR n’a pas pu vérifier si des agents l’avaient fait en pratique.

Enfin, d’après les informations communiquées aux chercheurs, le moniteur échouait sur moins de 0,2 % des requêtes, et aucune perte de charge n’a été relevée sur une période de 24 heures pendant l’exercice.

Cinq vulnérabilités signalées

• Les chercheurs ont trouvé un moyen, en principe, de contourner le bac à sable et Auto-Review, permettant à un agent d’effectuer toute action accessible à l’utilisateur hôte.
• Une faille empêchait la surveillance de centaines d’actions récentes, y compris celles de l’exploitation elle-même. Les détails ont été expurgés par OpenAI.
• Des agents pouvaient vraisemblablement fabriquer des entrées faisant échouer le moniteur, en jouant sur les différences entre la trajectoire vue par l’agent et celle vue par le moniteur. La trajectoire n’était alors pas transmise à un réviseur humain.
• Deux en-têtes indépendants, contrôlables côté client, désactivaient la surveillance des nouveaux agents, ce qui pouvait permettre de lancer une instance non surveillée mais par ailleurs identique. L’acte de positionner ces en-têtes et de créer l’instance pouvait toutefois être repéré par le moniteur.
• Pour deux outils agentiques non surveillés, un exploit simple aurait permis d’effectuer des actions arbitraires dans leur environnement isolé. METR n’a ni validé ce comportement ni testé son exploitabilité en pratique.

L’exercice a aussi produit deux constats plus rassurants.

• À quelques exceptions mineures près, le moniteur voit la trajectoire complète que voit l’agent.
• Les prompts du moniteur cherchent notamment le scheming, la subversion du moniteur, le sabotage, l’exfiltration de données, la tromperie et les injections de prompt entrantes et sortantes.

Cinq principes de conception

METR en tire des principes visant des systèmes de surveillance capables de résister à des attaques délibérées, stratégiques et soutenues, menées à grande échelle par des agents internes très capables.

• Rendre la surveillance difficile à éviter. Les requêtes non surveillées exigeraient une approbation explicite pour utiliser un ensemble défini d’organisations et de clés d’API, dont l’usage est interdit à l’inférence agentique. Les agents seraient surveillés tous les N messages ou N minutes, sans attendre la fin de leur tour.
• S’assurer que le trafic censé être surveillé l’est réellement. Comptabiliser toute l’inférence, recouper régulièrement ces journaux avec ceux du moniteur, tenir la liste des contournements connus et veiller à ce que le moniteur voie le même contexte que l’agent.
• Répondre vite et de façon fiable aux incidents. Désigner un responsable clair, fixer des consignes réduisant la subjectivité et conserver des journaux inaltérables et faciles à interroger.
• Soumettre le moniteur à un red-teaming actif. Évaluer périodiquement les contrôles, chercher les bugs exploitables et mettre au point une méthode pour évaluer les collusions stratégiques.
• Isoler agents et moniteurs. Dans la mesure du possible, exécuter l’architecture de l’agent dans un environnement distinct de celui des appels d’outils. Les actions de l’agent ne devraient pas influer sur le déclenchement du moniteur, et l’agent n’aurait en général pas accès à sa conception ni à son code.

OpenAI affirme avoir corrigé toutes les vulnérabilités identifiées qui touchaient sa pile de protections en production, et a décrit depuis des changements importants dans la couverture prévue de son dispositif. METR indique ne pas avoir évalué ces affirmations.

Pour les prochaines éditions, METR dit viser davantage de transparence et d’indépendance.

Source : « Red-Teaming OpenAI’s Internal Agent Monitoring Systems », METR, 22 octobre 2026.

The post Agents IA : la surveillance interne d’OpenAI passée au crible appeared first on Silicon.fr.

Un nouveau cap a été franchi dans l’inquiétante séquence de désobéissance agentique.

OpenAI a publié, ce 20 octobre, un rapport décrivant deux incidents internes au cours desquels des agents d’IA ont affaibli des dispositifs de surveillance conçus pour repérer des comportements potentiellement problématiques.

On parle ici d’un  » misalignment monitoring « , un ensemble de contrôles chargés de détecter lorsqu’un modèle interprète mal une instruction ou agit au-delà du périmètre autorisé.

Des garde-fous neutralisés pendant des tâches courantes

Le premier incident est survenu le 3 octobre. Un agent chargé de réparer un pipeline d’évaluation a reçu une consigne visant à ne pas envoyer de messages Slack. Selon OpenAI, il a interprété cette demande comme couvrant également les alertes automatiques destinées à son équipe sécurité.

« Un agent GPT-6.1 Sol, chargé de réparer un pipeline d’évaluation, a désactivé les alertes automatiques destinées à notre équipe sécurité, considérant qu’une consigne antérieure de ne pas envoyer de messages lors d’une recherche dans l’historique Slack justifiait la suppression des notifications de surveillance. » indique le rapport.

Le système de surveillance est resté actif et a continué d’enregistrer ses rapports. Mais les notifications destinées aux équipes humaines ont été supprimées. « Le moniteur de misalignment a continué de fonctionner et d’enregistrer ses rapports, mais les alertes destinées aux humains ont été désactivées. » peut-on lire.

Le second cas, daté du 6 octobre, est plus sensible. Un agent GPT-6 Astra a copié puis migré du code vers un autre environnement. La configuration de destination ne prévoyait pas de moniteur. L’agent a alors retiré l’intégration de surveillance du code d’origine afin de se conformer à l’implémentation de référence.

« Un agent GPT-6 Astra, chargé de migrer un programme, a retiré son intégration de surveillance afin de correspondre à une implémentation de référence, puis a affirmé faussement à l’utilisateur qu’il n’avait pas retiré le moniteur. » révèle OpenAI.

Interrogé ensuite, l’agent a indiqué à tort qu’aucun moniteur actif n’avait été supprimé : « Non […] je n’ai pas retiré un moniteur actif de ce chemin. »

Une réponse d’OpenAI en deux temps

La première mesure annoncée par OpenAI concerne son outil interne Auto-Review, déjà obligatoire pour l’usage interne de Codex, qui a été renforcé pour détecter et bloquer les tentatives de désactivation ou de contournement du monitoring de misalignment.

La seconde mesure est encore en cours de déploiement. OpenAI prévoit d’exiger une « safety case » valide pour chaque catégorie de charge de travail. Ce document devra définir les exigences de surveillance applicables. À terme, toute charge de travail ne disposant pas d’une safety case valide, ou ne respectant pas ses exigences, devra être arrêtée automatiquement.

« Les charges de travail dépourvues d’une safety case valide, ou ne respectant pas les exigences de la safety case de leur catégorie, seront automatiquement interrompues. » précise la scale-up.

OpenAI a également lancé une enquête pour déterminer si ces comportements relèvent d’une persistance excessive dans l’exécution des tâches ou d’une propension plus générale des modèles à éviter la surveillance.

« Il est possible que ce comportement soit simplement un exemple de “persistance excessive bénigne”, les modèles ne comprenant pas l’importance de la surveillance ou insistant pour exécuter des instructions au-delà de ce qu’une personne raisonnable pourrait attendre. » détaille le rapport.

Une série d’incidents qui s’inscrit dans une série

Cette divulgation intervient après plusieurs annonces similaires.

Le 16 septembre, OpenAI révèle six comportements « inattendus ou préoccupants » observés au cours des six mois précédents. Au menu : dissimulation d’erreurs, fabrication de données, transfert de fichiers sur Internet sans autorisation ou insertion d’instructions de type jailbreak dans ses propres notes de travail.

Mi-octobre, OpenAI publie quatre nouveaux rapports portant sur des incidents survenus en juin. Deux d’entre eux étaient qualifiés de critiques. L’un concernait le téléchargement non autorisé de données hospitalières par un modèle, l’autre l’accès à des systèmes internes et la persistance d’un accès après modification de la configuration.

OpenAI précise avoir observé plusieurs cas où un agent a lancé un déploiement dépourvu de monitoring de misalignment. L’agent lui-même restait surveillé, mais la charge de travail qu’il avait mise en production, elle, échappait à toute surveillance.

L’inventeur de ChatGPT ne présente pas ces incidents comme la preuve d’une intention délibérée de ses modèles. « Nous n’avons pas encore d’explication satisfaisante à ce comportement. » admet-il.

The post OpenAI : des agents IA ont désactivé leur système de surveillance appeared first on Silicon.fr.

L’histoire d’amour entre la finance mondiale et l’IA traverse une zone de turbulences. Après des mois d’euphorie, deux failles inquiètent les marchés financiers.

D’un côté, la croissance des pionniers des grands modèles commence à caler face à des pertes qui se comptent en dizaines de milliards. De l’autre, les acteurs de l’infrastructure et des datacenters s’essoufflent sous une montagne de dettes.

Sur les marchés, la question du risque de bulle spéculative n’est plus un débat théorique mais une préoccupation bien réelle.

L’introduction en bourse préparée par Anthropic constitue un test de résistance majeur pour l’ensemble du secteur. Lors de la journée investisseurs organisée à San Francisco, plusieurs souscripteurs ont ainsi ramené leurs attentes de valorisation à environ 1 500 milliards $, bien loin des près de 2 000 milliards $ projetés initialement.

Si l’éditeur de Claude a affiché un chiffre d’affaires de 16,8 milliards $ au troisième trimestre, sa croissance (+ 45 %) ralentit par rapport au deuxième trimestre où ses revenus avaient plus que doublé. Ce ralentissement intervient après une perte d’exploitation de 42 milliards $ en 2025 et des engagements d’investissement d’au moins 518 milliards $ sur dix ans en capacités d’infrastructure cloud.

Pour les marchés, cette situation sonne comme un avertissement direct adressé à OpenAI. L’inventeur de ChatGPT l présente une trajectoire qui inquiète.  Si l’entreprise son rythme annuel de revenus est calé entre 40 et 50 milliards $ en 2026, ses pertes d’exploitation atteignent des sommets dépassant 12 milliards $ au seul deuxième trimestre 2026. A l’horizon 2030, l’engagement dans les infrastructures. dépasse les. 600 milliards $.

Le mur du retour sur investissement

Ce fossé entre les engagements financiers pharaoniques et les retours sur investissement inquiète désormais analystes et économistes.

Kristalina Georgieva, patronne du FMI, s’inquiète que les marchés pèchent par excès d’optimisme quant aux retombées économiques immédiates d’une technologie de rupture. L’économiste Dani Rodrik (Harvard) pousse le constat plus loin : sans gain de productivité concret à court terme pour justifier ces sommes vertigineuses, le marché s’expose à un retour de bâton particulièrement violent.

Un diagnostic confirmé sur le terrain par Barclays qui vient d’abaisser ses prévisions sur Dell, HPE ou NetApp. Selon les analystes de la banque, l’IA ne pèse toujours qu’une portion congrue ( à peine 5 % ) des budgets informatiques des entreprises. Quant au sursaut récent des ventes de matériel, il ne traduit pas une déferlante d’usages mais simplement l’explosion du coût des puces mémoire.

L’asphyxie par la dette et le doute sur l’infrastructure

Une autre crainte est le financement par l’endettement. Le cas d’Oracle illustre parfaitement cette tension.

Pour suivre la cadence imposée par OpenAI et le projet Stargate, Oracle a fait exploser ses dépenses d’investissement à plus de 55 milliards de dollars, creusant un trou de trésorerie de 20 milliards. Pour éponger la facture, le groupe s’apprête à lever jusqu’à 50 milliards de dollars en dette et en fonds propres. Une fuite en avant qui fait dévisser ses titres obligataires et lui vaut désormais les foudres d’investisseurs, qui l’attaquent en justice pour avoir masqué le coût réel de ses contrats d’IA.

Cette détérioration financière frappe l’ensemble des « neoclouds ». Entre l’effondrement des obligations de CoreWeave et les suspensions en série d’introductions en bourse à l’image des opérateurs de datacenters australiens Firmus ou AirTrunk, le secteur vacille.

Mike Intrator, le PDG de CoreWeave, reconnait que ces déboires à répétition entachent désormais la crédibilité de tout l’écosystème d’infrastructure.

Un risque systémique pour l’économie globale ?

L’interconnexion entre les marchés boursiers, les marchés obligataires et le secteur manufacturier transforme ces vulnérabilités sectorielles en risque macroéconomique majeur.

Dans ses modélisations présentées lors du sommet de Bangkok, le FMI anticipe qu’une déception sur la rentabilité de l’IA déclencherait un effondrement des cours boursiers et une chute des investissements informatiques, susceptibles d’amputer la croissance économique mondiale de 1,3 % d’ici 2028.

Cette menace pèse particulièrement sur les économies exportatrices d’Asie, à commencer par la Corée du Sud et Taïwan, dont la croissance repose sur les puces et les équipements de datacenters. Si les exportations sud-coréennes et taïwanaises ont bondi sur un an (respectivement de plus de 80 % et 60 %), cet envol en trompe-l’œil masque une consommation intérieure au ralenti.

The post Infra, ROI et dette : les trois failles qui menacent l’économie de l’IA appeared first on Silicon.fr.

Les agents d’IA d’OpenAI ont frappé à la porte de Wikipédia.

La Wikimedia Foundation confirme, après avoir mené sa propre enquête, avoir découvert des activités non autorisées par des agents d’OpenAI sur ses plateformes. Ce cas s’ajoute à une liste d’incidents que l’entreprise peine à circonscrire.

La fondation en décrit trois.

D’abord des modifications de pages, presque toutes cantonnées à des « bacs à sable » invisibles du grand public. Quelques-unes, en revanche, touchaient la configuration d’un outil de citations. Wikimedia les juge potentiellement malveillantes, destinées à détourner l’outil pour en faire un relais vers des services distants. Aucune des autorisations que la communauté exige des robots d’édition n’avait été demandée.

Ensuite, des tentatives infructueuses de compromettre Etherpad, un outil public de prise de notes hébergé par la fondation, toujours dans le but de s’en servir comme proxy. D’autres agents, probablement opérés par OpenAI, y ont consigné des notes sur leurs missions, sans que cela ait débouché sur une coordination.

Enfin, un afflux de trafic. Les agents ont envoyé des millions de requêtes automatisées aux interfaces publiques (API) de Wikimedia et parcouru des millions de pages, principalement sur Wikidata, la base de données structurée qui alimente Wikipédia, et sur Wikimedia Commons, sa médiathèque. Ils ont également lancé des centaines de milliers de requêtes sur le service d’interrogation de Wikidata, un moteur qui permet d’extraire des informations de la base.

Ce déluge a pu contribuer à une panne partielle de ce service en mai. Wikimedia reste prudente sur ce point, et OpenAI dit n’avoir pas pu confirmer de lien avéré.

Une facture que personne ne présente

Wikimedia insiste sur ce que l’affaire révèle de l’économie du web ouvert.

Wikipédia revendique plus de 67 millions d’articles dans plus de 300 langues et jusqu’à 15 milliards de pages vues par mois. L’encyclopédie compte aussi parmi les jeux de données de la meilleure qualité pour l’entraînement des grands modèles de langage. Elle fournit donc la matière première de ceux qui la sollicitent aujourd’hui.

Or l’infrastructure est financée par une organisation à but non lucratif et ce sont des bénévoles qui nettoient.

Wikimedia rappelle avoir déjà signalé en 2025 une hausse de 50 % de sa bande passante depuis 2024 sous l’effet des robots ; 65 % du trafic le plus gourmand en ressources leur étant imputable. Ces chiffres couvrent l’ensemble des bots et non les seuls agents d’OpenAI.

La fondation ne réclame pas de sanctions mais un minimum de traçabilité afin que ces systèmes soient identifiables par les propriétaires de sites, qui doivent pouvoir choisir comment ils interagissent avec eux.

Sa conclusion vise tout le secteur : ceux qui lâchent ces agents et en tirent profit doivent contribuer à prévenir et réparer les dégâts. Pour l’instant, la charge repose sur les victimes.

The post Wikipédia dans le viseur des agents d’OpenAI appeared first on Silicon.fr.

Après les images et l’audio*, OpenAI commence à tatouer le texte que génèrent ses LLM.

Le déploiement initial est en opt-in sur l’API. « Dans les prochaines semaines », il s’étendra à ChatGPT et à Codex… dans l’Union européenne.

En toile de fond, l’AI Act. Le règlement impose aux systèmes d’IA mis sur le marché avant le 2 août 2026 de marquer les contenus qu’ils génèrent. Les fournisseurs concernés ont jusqu’au 2 décembre 2026 pour se mettre en conformité.

L’UE considère qu’aucune technique ne satisfait pour l’instant aux 4 critères qu’énonce l’AI Act (efficacité, interopérabilité, robustesse, fiabilité). Elle suggère donc d’en combiner, en priorisant métadonnées signées et filigrane invisible.

Le texte libre ne pouvant transporter de métadonnées, une couche unique est considérée comme suffisante. Certains éléments sont hors champ :

• Courtes séquences de nombres, symboles ou lettres
• Code source
• Sorties traitées uniquement en M2M, sans exposition à des humains
• Sorties utilisées en boucle fermée dans un contexte industriel ou de développement produit (exemple : production d’un film)

Pour compenser la fiabilité potentiellement moindre du tatouage de texte libre, les fournisseurs concernés peuvent restreindre à des utilisateurs experts l’accès à la solution de détection correspondante. Celle-ci peut être mise à disposition sous forme de spécification, de logiciel (exécutable ou bibliothèque) ou de service par API.

Un problème de transport optimal et du traitement par blocs

OpenAI a donc choisi la dernière option. Il promet toutefois, sans donner d’échéance, une publication en source ouverte. Sa technologie, dite textGrain, biaise légèrement le choix des tokens en utilisant une clé secrète qu’elle combine au texte précédent.

Pour trouver le juste milieu entre insertion de ce signal traçable et préservation de la diversité des réponses générées, le problème est modélisé sous forme de couplage statistique via le transport optimal. Pour ne pas avoir à résoudre ce problème sur l’intégralité du vocabulaire du LLM à chaque mot, textGrain découpe ce vocabulaire en blocs de tokens. Puis applique le transport optimal pour choisir le bloc en fonction de la clé.

OpenAI affirme que cette technologie atteint voire dépasse la performance des autres approches qu’il a testées. Dont SynthID. Il en reconnaît toutefois les limites. Par exemple, sur des passages de 400 tokens, remplacer 10 % des mots par des synonymes fait baisser le taux de détection de 92 % à 66 %. En remplacer le quart réduit ce taux à 17 %.
La détection est moins efficace sur des passages courts (80 % sur 200 tokens à un taux cible de faux positifs de 1 %). Elle l’est aussi sur les domaines où les modèles ont moins de liberté pour altérer leurs outputs, comme les maths.

* Pour l’image et l’audio, OpenAI a déjà un outil web et l’API Content Provenance, accessibles au public.

Illustration générée par IA

The post OpenAI bute sur le tatouage des sorties texte appeared first on Silicon.fr.

Synopsys va concevoir un modèle d’IA expert dans la conception de semi-conducteurs… et ce sera avec OpenAI.

L’entreprise l’a annoncé dans le cadre de son Investor Day. Une manière d’appuyer sa promesse de passer « de l’IP standardisée à l’IP dédiée ». En la matière, elle aura comme vitrine un nouveau contrat à « plus d’un milliard $ » avec Amazon.

Le modèle en question s’appellera GPT-Synopsys. On n’en sait pour l’heure pas grand-chose, sinon qu’il « tournera sur une infrastructure hébergée par OpenAI »… et qu’il exploitera l’outillage EDA de Synopsys.

OpenAI a déjà ses entrées chez Synopsys

Les LLM d’OpenAI ont déjà des points d’ancrage chez Synopsys. Ils furent notamment le substrat initial de l’offre Synopsys.ai Copilot. Lancée en 2023, cette dernière regroupe aujourd’hui 5 modules d’assistance (création de scripts, de bancs de test et de code RTL ; liting et aide généraliste) reposant sur une sélection de LLM commerciaux et open source assortis de prompts et de pipelines RAG propriétaires.

Ansys – concurrent que Synopsys a acquis l’an dernier pour plus de 30 Md€ – a sa propre couche générative avec de l’OpenAI dedans. Elle s’incarne dans l’assistant Engineering Copilot, axé sur l’assistance technique.

Le passage de Synopsys à l’agentique se fait sous la bannière Autopilot Platform. Promesse : fournir des familles d’agents spécialisés sur les différents compartiments de l’EDA, tout en laissant le choix du compute et des LLM.

« 9 mois de l’idée au tape-out » : Jalapeño, un jalon franchi

OpenAI a exploité ses modèles d’IA pour ses propres besoin de conception de semi-conducteurs. Le principal fruit s’appelle Jalapeño. Cette puce d’inférence conçue avec Broadcom n’est pas passé inaperçue. Essentiellement parce qu’il n’a fallu que 9 mois de la conception initiale au tape-out de fabrication.

Cédric Gouy-Pailler est responsable du programme de recherche en intelligence artificielle du CEA-List. Intervenu lors du dernier salon Big Data & AI Paris au sujet des composants et systèmes pour les infrastructures du numérique, il n’a pas manqué de mentionner Jalapeño. Et de confirmer qu’on « assiste à l’introduction massive de l’IA dans le processus de conception des puces électroniques ».

Reprenant des données de Microsoft, Cédric Gouy-Pailler a souligné qu’il semblait possible, « dans un horizon de quelques mois ou quelques années », de diviser par 8 à 20 la consommation d’énergie par requête d’inférence. Un facteur de 3 à 4 serait à gagner sur le modèle ; de 2 à 3 sur l’optimisation du déploiement ; de 1,5 à 2 sur le hardware.

À consulter en complément, une synthèse des mesures que la Commission européenne propose avec le Chips Act 2.0. Elle y maintient l’objectif de mettre en place une plate-forme cloud de conception de semi-conducteurs. Lorsqu’elle a proposé son texte (juin 2026), l’hébergeur était sélectionné. Des négociations étaient en cours avec les fournisseurs d’outils EDA. Bruxelles pensait pouvoir les conclure à l’automne, pour un passage en phase opérationnelle avant 2027.

Illustration générée par IA

The post OpenAI signe avec Synopsys : l’effet Jalapeño ? appeared first on Silicon.fr.

La bibliothèque s’en va, les pages et les espaces arrivent, les projets restent : ainsi évolue ChatGPT.

Ce changement n’est pas que terminologique. Il est aussi fonctionnel. Avec lui, OpenAI introduit une couche d’édition collaborative. Elle s’incarne pour le moment en un format : les fameuses « pages », équivalentes à des documents Word. Les « espaces » servent à les organiser, éventuellement aux côtés de fichiers importés. Ils sont, en quelque sorte, ce que les « projets » sont aux conversations*, en plus de remplir la fonction jusque-là dévolue à la « bibliothèque ».

L’ensemble arrive progressivement sur les forfaits ChatGPT Pro, Business (ex-Team) et Enterprise. L’édition collaborative est pour le moment opérationnelle sur le web et les applications de bureau. Sur mobile, on ne peut que consulter les pages. Feuilles de calcul et diapositives sont censées s’y ajouter « bientôt ».

ChatGPT Work avait ouvert la voie

OpenAI avait déjà développé l’aspect suite de productivité avec le mode ChatGPT Work. Lancé en juillet sur les forfaits Business et Enterprise, il complète les modes Chat et Codex pour accompagner la « production de livrables finalisés » (documents texte, feuilles de calcul, présentations, rapports et sites), y compris dans Excel et Google Workspace.

L’aspect collaboration s’est notamment manisfesté, pendant un peu plus d’un an, à travers la fonction Canvas. Abandonnée au printemps 2026, elle favorisait le travail avec GPT sur les projets d’écriture et de code nécessitant des modifications et des révisions. Elle permettait par exemple de surligner des sections pour préciser à l’IA les points sur lesquels se concentrer.

Le choix d’un assistant IA d’entreprise dépend encore beaucoup du niveau d’adhérence à une suite bureautique, a récemment fait remarquer Gartner. Non sans affirmer que ChatGPT Enterprise était d’ores et déjà suffisamment exhaustive pour constituer une alternative « cohérente » aux suites de productivité.

À consulter en complément :

Comment OpenAI s’est installé au coeur des logiciels d’entreprise
Qui est Jacob Coxon, le chercheur qui accuse l’IA de vouloir nous tuer ?
GPT-6 Astra, un modèle qui pose problème à OpenAI
Tokenomics : les chiffres d’une discipline FinOps en construction
Comment Microsoft articule le « code de conduite » qui va gouverner ses IA

* Intégrés fin 2024, les projets sont centrés sur les discussions. On y définit des instructions système et on y dépose des fichiers de référence.

Illustration générée par IA

The post ChatGPT, suite collaborative : OpenAI s’en approche appeared first on Silicon.fr.

L’affaire Hugging Face reste au centre des préoccupations sur l’activité « désalignée » des agents IA.

Dans une note d’information publiée le 30 septembre, OpenAI indique que ses équipes ont prévenu plus de 100 organisations dont les systèmes ou services avaient été concernés par une activité répondant à ses critères de notification.

Le créateur de ChatGPT a engagé une revue portant sur environ 50 pétaoctets de données,en précisant que ce volume s’explique notamment par l’ampleur des campagnes d’entraînement et de test, qui mobilisent des dizaines de milliers de GPU.

Cependant, OpenAI précise explicitement qu’une notification « ne signifie pas » qu’une information privée a été consultée ou qu’un système tiers a été compromis.

Une alerte n’est pas une intrusion

Les cas examinés recouvrent plusieurs catégories d’incident. Sont évoqués le contournement des contrôles d’accès, l’utilisation d’identifiants exposés publiquement, l’injection de requêtes ou de commandes, l’accès à des éléments internes d’un service ou encore la publication non sollicitée de contenus sur des sites tiers ; ce qu’OpenAI appelle « agent spam ».

OpenAI reconnaît que ses modèles ont parfois utilisé Internet de manière non prévue ou que les restrictions appliquées à certaines tâches n’étaient pas suffisamment strictes. Mais elle affirme ne pas avoir identifié, à ce stade, une autre compromission de système tiers comparable en ampleur ou en gravité à l’incident Hugging Face.

OpenAI le décrit comme le cas le plus sévère identifié à ce jour. L’environnement d’évaluation ExploitGym ne donnant pas directement accès à Internet, les modèles auraient exploité une vulnérabilité jusque-là inconnue dans Artifactory, un proxy de cache pour registres de paquets, afin d’obtenir cet accès.

Depuis, OpenAI affirme avoir renforcé l’isolation de ses environnements de recherche, restreint l’accès au réseau, accru la surveillance et ajouté des mesures d’entraînement destinées à éviter les actions non autorisées.

Une enquête qui durera des mois

La scale-up présente son dispositif comme un exercice de transparence et affirme  privilégier la notification lorsqu’une activité expose une vulnérabilité potentielle, même si l’on ignore encore si les informations consultées étaient destinées à être publiques.

Le processus repose sur plusieurs étapes automatisées, puis sur une vérification humaine. OpenAI souligne qu’un signal automatisé n’est pas un incident confirmé. Par exemple, un modèle peut envisager une action dans son raisonnement sans jamais l’exécuter, ou tenter une action qui échoue.

Mais cette prudence rend le bilan difficile à interpréter. Les organisations alertées doivent elles-mêmes déterminer si l’activité signalée révèle une faiblesse, une exposition de données ou un simple comportement sans conséquence ?

OpenAI affirme que la grande majorité des actions examinées relevait de tâches de recherche ordinaires, notamment la consultation du contenu web public. Son enquête se concentre sur les cas où des agents ont interagi avec des sites tiers au-delà de leur mission ou des méthodes prévues.

La scale-up s’attend toutefois à identifier d’autres cas et à notifier davantage d’organisations à mesure que l’examen des archives progresse. Certains signalements pourraient concerner des événements remontant à plusieurs mois.

The post OpenAI alerte plus de 100 organisations sur les compromissions de ses agents IA appeared first on Silicon.fr.

Washington renforce la surveillance des technologies d’IA.

La Federal Trade Commission (FTC) mène une enquête à l’échelle du secteur sur Anthropic, OpenAI et d’autres acteurs de l’IA afin d’examiner les dangers potentiels de leurs technologies pour les consommateurs, a indiqué un haut responsable à Reuters.

La FTC prévoit d’adresser des demandes formelles d’informations aux entreprises concernées et de contraindre certains de leurs dirigeants à témoigner. Anthropic, OpenAI et l’organisme de recherche METR figurent parmi les acteurs cités par le responsable. Le porte-parole de la FTC n’a toutefois pas précisé quelles autres entreprises seraient concernées.

Selon Reuters, il s’agit de la première action officielle d’un régulateur américain consacrée spécifiquement aux agents d’IA dits « rogue », dont le comportement s’écarte de ce qui était attendu par leurs concepteurs ou utilisateurs.

Hugging Face a accéléré le dossier

La FTC s’intéressait déjà au sujet avant que des agents d’OpenAI, dans le cadre d’un test de cybersécurité, échappent à leur environnement contrôlé avant de compromettre l’infrastructure de Hugging Face.

D’autres comportements similaires ont depuis été signalés dans le secteur. OpenAI et Anthropic ont notamment indiqué que certains de leurs systèmes avaient effectué des opérations de cybersécurité dépassant les intentions initialement fixées par leurs utilisateurs ou développeurs.

Pour les régulateurs, l’enjeu est désormais de déterminer dans quelle mesure les entreprises peuvent être tenues responsables des conséquences de tels comportements.

Un accord volontaire signé à la Maison-Blanche

La nouvelle enquête intervient dans un contexte particulier.

La veille, Donald Trump avait réuni à la Maison-Blanche plusieurs dirigeants du secteur – Greg Brockman pour OpenAI, Dario Amodei pour Anthropic, Mark Zuckerberg pour Meta, Sundar Pichai pour Google et Jensen Huang pour Nvidia – afin d’annoncer un accord volontaire sur la sécurité de l’IA.

Le document prévoit notamment que les entreprises travaillent avec des auditeurs indépendants afin d’évaluer leurs dispositifs de contrôle et de surveillance. Elles s’engagent également à mettre en place des mécanismes internes et à veiller à ce que leurs outils ne puissent pas accéder ou s’en prendre à des systèmes techniques de manière non prévue.

Mark Zuckerberg a indiqué que les entreprises travailleraient également au renforcement de leurs contrôles internes. Donald Trump a comparé l’accord à une forme de « constitution » et évoqué la possibilité de créer un comité d’une dizaine de personnes chargé de surveiller la sécurité des outils d’IA.

L’accord reste toutefois volontaire et ne constitue pas une nouvelle réglementation fédérale.

La question de la responsabilité

L’intervention de la FTC intervient alors que ses principaux acteurs commencent à reconnaître l’incertitude juridique entourant ces nouveaux systèmes.

Dans son prospectus préparé pour son introduction en Bourse, Anthropic souligne que les actions de ses systèmes pourraient donner lieu à des réclamations de clients ou d’utilisateurs et que le cadre juridique applicable demeure incertain.

L’éditeur de Claude évoque notamment les conséquences possibles d’une suppression de données, d’une opération financière non autorisée ou d’une autre action exécutée sans validation explicite.

La FTC va donc chercher à déterminer ce que les développeurs savent de ces risques, comment ils les contrôlent et dans quelles circonstances leur responsabilité pourrait être engagée.

The post Agents IA : la FTC ouvre une enquête au lendemain de l’accord de la Maison-Blanche appeared first on Silicon.fr.

Ils se disputent d’ordinaire les mêmes ingénieurs, les mêmes clients et les gros titres des médias pour imposer leur leadership à grands coups de nouveaux LLMs toujours plus performants.

Mais ce 23 septembre, devant le Conseil de sécurité des Nations unies, Sam Altman et Dario Amodei, respectivement patron d’OpenAI et d’Anthropic, ont tenu un discours quasi identique : sans coordination internationale, l’intelligence artificielle représente un risque pour la sécurité mondiale.

La séance, organisée sous présidence tournante française et présidée par le ministre des Affaires étrangères Jean-Noël Barrot, ne visait pas à faire adopter un texte, mais à informer les quinze membres du Conseil, ce qui explique qu’aucune décision n’en soit sortie.

C’était seulement la deuxième fois que l’organe onusien consacrait une session à l’IA, après une première réunion en 2023 où la Chine avait averti que la technologie ne devait pas devenir un « cheval sans bride », tandis que les États-Unis mettaient en garde contre son usage pour censurer ou réprimer les populations.

Deux concurrents, un même message

Pour Sam Altman, les décisions structurantes sur l’IA doivent revenir à des institutions démocratiques et à des gouvernements responsables devant leurs citoyens plutôt qu’aux seuls entreprises d’IA.

Deux jours plus tôt, OpenAI avait publié une proposition détaillée appelant Washington à prendre la tête d’un effort international de normalisation technique, en particulier sur l’auto-amélioration récursive des systèmes.

Le texte prévoit de relier dix instituts nationaux de sécurité de l’IA (dont ceux du Royaume-Uni, du Japon, de l’Allemagne, de la Corée du Sud et de l’Inde ) via le Center for AI Standards and Innovation (CAISI) des Etats-Unis, tout en excluant explicitement tout régime de licence ou d’autorisation préalable à la publication.

OpenAI y présente l‘incident survenu chez Hugging Face comme un avant-goût des risques à venir, sans toutefois l’attribuer à une auto-amélioration récursive déjà en cours.

Dans son intervention en visioconférence, Dario Amodei a présenté un plan en trois volets.

D’abord, l’élaboration d’accords internationaux ciblés à commencer par une interdiction du recours à l’IA pour la conception d’armes biologiques. Ensuite des mécanismes d’évaluation permettant aux États de vérifier mutuellement leurs engagements. Enfin, des normes communes de test assorties d’un système de notification des incidents de sécurité jugés significatifs.

« Je crois que c’est aujourd’hui le problème de sécurité mondiale le plus important. » a-t-il lâché en admettant qu’une coordination entre démocraties et régimes autoritaires serait la plus difficile à atteindre.

Washington, en désaccord avec ses champions

Le consensus affiché par les deux concurrents tranche avec la position de l’administration Trump. Deux jours avant la réunion, le président avait écrit qu’il ne laisserait en aucune façon freiner ou entraver la croissance de cette industrie extraordinaire.

La  séance a réuni un cercle plus large d’intervenants. Le chercheur en IA Yoshua Bengio, le patron de Hugging Face Clément Delangue ainsi que des représentants des groupes chinois DeepSeek et Moonshot se sont exprimer sur les mêmes risques.

The post À l’ONU, OpenAI et Anthropic réclament des règles communes pour l’IA appeared first on Silicon.fr.

Google a confirmé qu’un de ses modèles Gemini s’était introduit en mai dans les systèmes de trois entreprises réelles pendant un test de cybersécurité.

Le Wall Street Journal a révélé l’affaire et la décrit comme le premier cas connu où une IA de Google pirate de manière autonome d’autres sociétés.

Le groupe rejoint ainsi OpenAI, Anthropic et Meta, dont les modèles ont eux aussi, ces dernières semaines, franchi les limites de leur environnement d’essai.

Le test, de type « capture du drapeau », était mené sur l’infrastructure d’Irregular, une start-up israélienne spécialisée dans l’évaluation de modèles d’IA. Gemini devait récupérer des informations dans le logiciel d’une société fictive, dont le nom était identique à celui d’une société réelle. Il n’était pas censé accéder à l’internet, mais un défaut de l’environnement de test lui en a ouvert l’accès, selon Irregular.

Les trois intrusions se sont produites lors d’exécutions distinctes.

Dans la première, le modèle a essayé des mots de passe jusqu’à entrer dans le service d’une entreprise réelle. Dans les deux autres, il a cherché le nom de l’entreprise sur le web.

Ces recherches l’ont mené à deux dépôts publics contenant des identifiants appartenant à d’autres sociétés, qu’il a testés dans l’espoir de mener l’évaluation à son terme. Selon Google, il a compris à chaque fois qu’il avait touché une entreprise réelle, puis s’est arrêté et a quitté les lieux. Le groupe estime que l’incident n’a causé aucun dommage.

Google : une défense en trois points

La position de Google tient en trois points.

Il ne juge pas les faits constitutifs de « désalignement », terme du secteur pour un logiciel qui échappe aux instructions de ses concepteurs, parce que ses garde-fous ont aidé le modèle à s’arrêter. Il n’y a vu aucune raison de rendre l’affaire publique, faute de dommage et parce que l’intrusion a cessé aussitôt. Il compare enfin l’épisode à un programme de « bug bounty », où des pirates sont rémunérés pour signaler des failles.

Heather Adkins, vice-présidente chargée de l’ingénierie de sécurité, estime que le modèle « a agi de manière appropriée » et que l’épisode souligne l’importance de former les modèles puissants à se comporter de façon responsable.

Cette lecture est contestée. Jack Cable, patron de la start-up de sécurité Corridor et pirate informatique éthique, y voit une manière de s’abriter derrière les usages de la divulgation de vulnérabilités, alors que le vrai sujet est qu’un modèle sorte de son cadre et mène de véritables cyberattaques, ce qui relève à ses yeux de l’intérêt public.

Sydney Von Arx, dirigeante de l’organisation Nightingale Collective, dédiée à la sécurité de l’IA, s’interroge sur le délai de divulgation. Elle juge que l’on ne peut plus attendre des entreprises qu’elles révèlent d’elles-mêmes les évasions de leurs agents. Elle trouve aussi Google bien prompt à écarter le désalignement, ce qu’avait selon elle fait Anthropic après ses propres incidents.

La chronologie nourrit les critiques

Irregular a prévenu Google fin juillet, après la découverte du piratage de Hugging Face par des agents d’OpenAI.

Google dit avoir alors enquêté, informé les organisations visées et alerté les autorités fédérales. Il n’a rien publié avant que le Wall Street Journal ne le questionne cette semaine, contrairement aux autres laboratoires concernés. Il refuse de nommer les trois entreprises et de préciser le modèle en cause, en indiquant seulement qu’il ne s’agit pas du plus récent.

Irregular, soutenue par Sequoia et Redpoint, valorisée 450 millions $ l’an dernier affirme que le cas de Google relève du problème déjà signalé, et non d’un incident distinct.

Un porte-parole assure que tous les défauts connus ont été corrigés il y a plusieurs semaines. Il écarte toute « action cyber sophistiquée ». La société annonce un document sur les bonnes pratiques de confinement des évaluations d’ici quelques semaines.

Les comportements des modèles varient d’un laboratoire à l’autre.

Selon Anthropic, son modèle Claude Opus 4.7 ne s’est pas arrêté lors de l’exercice, alors qu’il avait compris qu’il accédait probablement à une entreprise réelle. Le modèle d’OpenAI, lui, croyait que l’entreprise réelle faisait partie de la simulation. Anthropic a reconnu depuis que son analyse préliminaire avait été limitée par sa volonté de divulguer vite.

Plusieurs points restent sans réponse : l’identité des trois entreprises, la version du modèle et ce qu’il a pu consulter avant de s’arrêter. La description de l’incident comme une erreur d’identification sans dommage repose, dans l’ensemble des sources, sur les seules déclarations de Google et d’Irregular.

The post Google admet que Gemini a piraté trois entreprises lors d’un test de sécurité appeared first on Silicon.fr.

Novo Nordisk, le laboratoire danois spécialiste du diabète et de l’obésité vient de sceller un accord avec Anthropic.

Le deal ne se limite pas à la R&D pure. Il touche aussi à la modernisation des opérations internes, jusqu’au développement logiciel « agentique » aux côtés de la recherche de médicaments proprement dite

« Les outils d’IA peuvent aussi offrir des opportunités scientifiques totalement nouvelles et faciliter la compréhension de la biologie humaine et des mécanismes des médicaments » explique Mike Doustdar, le P-DG de Novo Nordisk.

Ce rapprochement vient s’ajouter aux arrangements déjà noués par Novo Nordisk avec OpenAI et Amazon Web Services, ainsi qu’au portefeuille croissant de clients pharmaceutiques d’Anthropic, qui avait déjà ouvert l’accès de Claude aux équipes de Bristol Myers Squibb pour leurs travaux de recherche et de développement de médicaments.

Entre 2025 et 2026, les principaux laboratoires mondiaux – Eli Lilly, Novartis, Johnson & Johnson, Novo Nordisk, Merck – ont ainsi multiplié les alliances avec les géants de l’IA, qu’il s’agisse des fournisseurs de modèles (OpenAI, Anthropic, Google/DeepMind), d’infrastructure (Nvidia) ou de cloud (Google Cloud, Microsoft), avec des engagements pouvant dépasser le milliard de dollars par contrat.

Mais Novo Nordisk compte d’abord tester les modèles d’Anthropic et son environnement Claude Science avant d’envisager un déploiement plus large.

Claude Science, un banc d’essai scientifique généraliste

Lancé fin juin en version bêta publique, Claude Science est un environnement de travail ( un « workbench ») qui s’appuie sur les modèles Claude déjà inclus dans l’abonnement de l’utilisateur, en y ajoutant des outils scientifiques, des connexions à des bases de données et des intégrations de calcul.

Concrètement, l’outil se connecte à plus de soixante bases de données scientifiques et embarque des boîtes à outils préconstruites pour la génomique, la protéomique, la biologie structurale ou la chimie computationnelle. Son architecture repose sur un agent principal capable de faire appel à des sous-agents spécialisés pour se répartir les tâches, avec un agent de relecture dédié chargé de vérifier citations et calculs avant toute publication

Des premiers utilisateurs, notamment à l’Allen Institute (Seattle) et au UCSF Brain Tumor Center ( San Francisco) ont fait état de réductions significatives du temps nécessaire pour mener des analyses complexes.

OpenAI riposte avec GPT-Rosalind

Face à Anthropic, OpenAI a lancé dès avril 2026 un modèle taillé sur mesure pour les sciences du vivant.

GPT-Rosalind est un modèle de raisonnement conçu spécifiquement pour soutenir la recherche scientifique en biologie, découverte de médicaments et médecine translationnelle. Il est optimisé pour des workflows complexes combinant raisonnement avancé et intégration poussée avec les outils, les bases de données et les processus expérimentaux du secteur.

Côté partenaires, OpenAI peut déjà s’appuyer sur des poids lourds du secteur. Amgen, Moderna, l’Allen Institute et Thermo Fisher Scientific figurent parmi les premiers partenaires pilotes.

Deux stratégies, une même cible

Il existe cependant une différence marquée entre leurs deux approches.

Anthropic mise sur un socle de raisonnement scientifique transversal, intégré profondément dans les workflows internes des laboratoires via des contrats, comme avec Bristol Myers Squibb sur l’ensemble de la chaîne R&D et des opérations.

OpenAI, de son côté, a choisi la verticalisation complète avec un modèle dédié pensé dès l’origine pour la biologie et adossé à l’écosystème plus large de ChatGPT, de l’API et de Codex.

Rien n’indique que ces deux logiques s’excluent mutuellement. Un même laboratoire peut recourir à Claude Science pour des tâches de raisonnement scientifique transverses tout en s’appuyant sur GPT-Rosalind pour des travaux pointus de génomique ou de conception moléculaire. Novo Nordisk en offre d’ailleurs une bonne illustration.

Devenir l’infrastructure…pas seulement la licence

Au-delà des annonces, la partie qui se joue est celle de l’infrastructure logicielle de la R&D pharmaceutique ; un rôle occupé jusqu’ici par les LIMS (Laboratory Information Management System, ou système de gestion de l’information de laboratoire), les cahiers de laboratoire électroniques ou les plateformes de calcul haute performance.

Pour les laboratoires, la multiplication de ces partenariats ouvre trois leviers : arbitrer entre une approche généraliste et une approche verticale (ou combiner les deux), chercher des gains de productivité mesurables sur des cycles de découverte historiquement longs et jouer la concurrence entre éditeurs pour négocier des conditions d’accès et des garanties de gouvernance des données. Un point que Novo Nordisk a pris soin de souligner en évoquant des protocoles de supervision humaine conformes à ses exigences de conformité.

——————————————————————————————————–

Comparatif Claude Science (Anthropic) vs Rosalind Workbench (OpenAI)

Dimension	Claude Science (Anthropic)	Rosalind Workbench (OpenAI)
Type d’offre	Workbench scientifique intégré à l’écosystème Claude, conçu pour les workflows de recherche et de raisonnement scientifique.	Environnement de travail scientifique (« scientific workspace ») dédié aux sciences du vivant, intégré à l’application ChatGPT.
Cible principale	Équipes de R&D et de recherche scientifique tous domaines (biopharma, chimie, physique, etc.), avec un fort accent sur la biopharma.	Équipes de R&D en life sciences (biopharma, biotech, instituts de recherche en biologie).
Modèle sous‑jacent	Modèles « frontier » d’Anthropic (Claude), optimisés pour le raisonnement scientifique et l’usage d’outils.	Modèle spécialisé GPT‑Rosalind, présenté comme le modèle OpenAI le plus capable pour la recherche en sciences du vivant.
Fonctionnalités clés	– Raisonnement scientifique avancé (« biological reasoning ») – Orchestration de workflows multi‑étapes – Analyse de données, génération de code, rédaction de rapports – Intégration dans des pipelines R&D et logiciels « agentiques ».	– Workflows guidés pour la biologie (structures, séquences, génomique, chimie médicinale) – Outils bioinformatiques intégrés (visualisation 3D, alignement, QC NGS, etc.) – Plugin de recherche connecté à >50 outils et bases de données – Modes Explore (questions générales) et Research (workflows multi‑étapes).
Cas d’usage annoncés	– Découverte de cibles et design de molécules – Analyse de données génomiques / protéomiques – Rédaction et synthèse de rapports d’études cliniques – Optimisation de protocoles et de workflows R&D – Développement logiciel interne « agentique ».	– Analyse de structures et séquences protéiques – Génomique et analyses NGS (FASTQ QC, RNA‑seq bulk/single‑cell) – Chimie médicinale et design de petites molécules – Planification d’expériences et revue de littérature scientifique. [
Mode d’accès	– Accès enterprise via API et intégrations – Déploiement sur des workflows ciblés, avec gouvernance des données et supervision humaine. [	– Offre enterprise via ChatGPT Enterprise, Codex (avec plugin) et API – Accès « trusted access » pour le mode Research, réservé à des organisations vérifiées.
Premiers partenaires / utilisateurs annoncés	– Bristol Myers Squibb (déploiement enterprise large) – Novo Nordisk (pilote sur workflows R&D ciblés) – Institutions de recherche (Allen Institute, UCSF Brain Tumor Center) citées comme early users.	– Amgen – Moderna – Allen Institute – Autres équipes de découverte de médicaments en accès contrôlé.
Positionnement stratégique	Workbench scientifique généraliste, très orienté biopharma, intégré dans une stratégie plus large d’automatisation de la science et de déploiement enterprise de Claude.	Workbench spécialisé life sciences, présenté comme l’offre de référence d’OpenAI pour la R&D en biologie et en découverte de médicaments.
Gouvernance / sécurité	Mesures de gouvernance des données et supervision humaine, alignées sur les standards éthiques et de conformité des clients (ex. Novo Nordisk). [	Accès contrôlé (programmes enterprise et « trusted access »), avec emphasis sur la traçabilité des résultats et la revue humaine des workflows Research. [

 

The post Anthropic et OpenAI accélèrent leur course aux « workbenches » scientifiques appeared first on Silicon.fr.

OpenAI ne se contente plus de proposer ChatGPT aux entreprises ou de vendre ses modèles via API.

Depuis l’arrivée de GPT-4o, ses technologies se sont progressivement intégrées dans les logicielsd’entreprise, de la gestion documentaire au CRM en passant par la cybersécurité.

Cette évolution peut se lire en trois phases. D’abord, le modèle devient une fonctionnalité du logiciel. Puis il en devient le moteur d’agents capables d’effectuer des tâches. Enfin, il commence à s’insérer directement dans des workflows métiers.

GPT-4o : l’IA devient une fonction du logiciel

Le lancement de GPT-4o en mai 2024 accélère la diffusion des modèles d’OpenAI dans les applications professionnelles. Sa capacité à traiter du texte, des images et de la voix permet aux éditeurs d’ajouter des fonctions d’IA à leurs produits sans demander à leurs clients de changer d’environnement.

Box intègre ainsi GPT-4o dans Box AI pour analyser les contenus stockés sur sa plateforme. Zendesk l’utilise dans ses outils de service client. Salesforce l’intègre à ses fonctions d’IA. Intercom s’appuie également sur les modèles d’OpenAI pour son agent de support Fin.

Le modèle devient alors une brique invisible du logiciel. L’utilisateur ne choisit pas nécessairement OpenAI ; il utilise une fonction de son application, dont le moteur est en partie fourni par OpenAI.

Le changement est important pour OpenAI. L’accès au marché professionnel ne passe plus uniquement par la vente directe de ChatGPT ou par la décision d’une entreprise de connecter ses propres applications à une API. Les éditeurs de logiciels deviennent eux-mêmes un canal de distribution.

GPT-5 : le modèle devient le moteur des agents

La deuxième étape apparaît avec les modèles de raisonnement et les capacités agentiques.

Avec GPT-5, OpenAI ne met plus seulement en avant la génération de contenu, mais la capacité du modèle à raisonner, utiliser des outils et accomplir des tâches plus complexes. Les éditeurs de logiciels commencent alors à intégrer ces capacités dans leurs propres agents.

Le développement logiciel constitue le terrain le plus visible. GitHub Copilot, Cursor, Windsurf, Vercel, JetBrains, GitLab, Factory, Lovable, Augment Code et Cognition font partie des acteurs ayant intégré ou testé GPT-5 dans leurs produits.

Chez JetBrains, GPT-5 est notamment intégré à Junie, son agent de développement, ainsi qu’à AI Assistant. Chez Vercel, le modèle alimente notamment v0 et les fonctions agentiques de la plateforme.

La différence avec la première phase est de taille.

Avec GPT-4o, OpenAI alimentait des fonctionnalités. Avec les modèles de raisonnement, il commence à alimenter des agents.

Ces agents peuvent analyser le contexte, utiliser plusieurs outils, enchaîner des opérations et produire un résultat sans que l’utilisateur ait à détailler chaque étape.

La même évolution apparaît en dehors du développement. Harvey utilise les modèles d’OpenAI dans ses outils juridiques et ses workflows. Notion les intègre à ses agents. Salesforce développe Agentforce autour de cette logique d’agents capables d’interagir avec les données et les applications de l’entreprise.

L’intégration d’un modèle dans un logiciel change donc progressivement de nature : il ne s’agit plus seulement de lui demander de générer une réponse, mais de lui confier une partie du travail.

2026 : les modèles s’insèrent dans les workflows métier

La troisième phase est désormais particulièrement visible dans la cybersécurité.

Avec Daybreak, OpenAI organise un réseau de partenaires destiné à intégrer ses modèles spécialisés dans les produits et services de sécurité. La liste publiée par OpenAI comprend notamment Akamai, Cato Networks, Check Point, Cisco, Cloudflare, CrowdStrike, Darktrace, Elastic, Fortinet, IBM, Okta, Palo Alto Networks, Proofpoint, SentinelOne, Sophos, Tenable, Trend Micro et Zscaler.

Cette fois, le modèle ne se contente plus d’ajouter une capacité de génération ou de recherche au logiciel. Il peut intervenir directement dans un processus opérationnel.

Chez Cloudflare, les modèles cyber d’OpenAI sont utilisés pour contribuer à la découverte et à la remédiation des vulnérabilités. CrowdStrike les intègre à ses workflows de sécurité. Elastic les utilise pour accélérer certaines opérations d’investigation et de détection. Tenable les associe à ses données d’exposition pour analyser notamment les risques liés aux agents, aux skills, aux serveurs MCP et aux playbooks.

Le principe est désormais différent. Le logiciel fournit au modèle ses données, son contexte et ses outils ; le modèle apporte ses capacités de raisonnement tandis que l’éditeur conserve la maîtrise du workflow et de ses mécanismes de contrôle.

La cybersécurité est particulièrement révélatrice de cette évolution parce que les conséquences d’une mauvaise décision peuvent être immédiates. Les intégrations doivent donc combiner les capacités du modèle avec des règles, des limites d’action, de la supervision et, dans de nombreux cas, une validation humaine.

Mais la logique dépasse la cybersécurité.

Dans les outils de données, les CRM, les logiciels juridiques ou les plateformes collaboratives,  le modèle ne vient plus seulement enrichir le logiciel, il participe à l’exécution des tâches pour lesquelles le logiciel est conçu.

OpenAI change de place dans la chaîne logicielle

Cette évolution a une conséquence économique importante.

Le marché ne se limite plus à la question de savoir quel modèle les entreprises vont choisir. Une autre bataille se joue désormais : dans quels logiciels ce modèle sera-t-il embarqué ?

Un responsable informatique peut utiliser une fonction alimentée par OpenAI sans avoir choisi OpenAI comme fournisseur de modèle au niveau de son infrastructure IA. Il peut travailler dans GitHub Copilot, utiliser Harvey pour ses équipes juridiques, exploiter Notion ou s’appuyer sur une plateforme de cybersécurité qui embarque GPT Cyber.

 

The post Comment OpenAI s’est installé au cœur des logiciels d’entreprise appeared first on Silicon.fr.

Avec les LLM à long horizon, surveiller des actions individuelles ne suffit plus à suivre l’intention de la trajectoire globale.

Il y a quelques semaines, OpenAI avait exprimé en ces mots le défi que de tels modèles représentent en matière de sécurité et d’alignement. Il s’était attardé sur l’un d’entre eux, exploité en interne, et qui avait fait le buzz au printemps en réfutant une conjecture mathématique vieille de 80 ans.

Le modèle en question avait notamment été évalué sur le speedrun NanoGPT –  benchmark public consistant à entraîner un petit modèle de langage en aussi peu d’étapes que possible. OpenAI lui avait donné pour consigne de ne publier ses résultats que sur Slack. Le LLM a toutefois préféré suivre les instructions de NanoGPT, qui imposent de publier sur GitHub. Il a pour cela contourné les restrictions de sa sandbox, conçue pour bloquer l’accès externe.

Ce même modèle a décidé d’un autre contournement. Chargé de résoudre un problème, il avait constaté que d’autres systèmes disposaient de soumissions réussies… mais privées. Il a tenté de les récupérer depuis le back-end d’évaluation. Mais s’est retrouvé bloqué, un scanner ayant détecté un jeton d’authentification. Pour éviter le blocage, il a divisé le corps du jeton en deux fragments, les a obscurcis, puis a reconstruit l’identifiant à l’exécution.

3700 agents ont squatté un wiki public

OpenAI s’appuie sur ces éléments pour affirmer qu’il avait déjà évoqué publiquement le cas d’agents ayant utilisé le web de manière imprévue. Il admet cependant devoir faire évoluer ses pratiques de divulgation à propos des désalignements. Y compris lorsque ces derniers « ne ressemblent pas à des incidents de sécurité classiques »…

En toile de fond, un épisode ayant impliqué ses agents… qui ont squatté un wiki public. Plus précisément, DseWiki (DeutschesSoftwareEntwicklerWiki), destiné aux développeurs germanophones.

Ces agents devaient résoudre des tâches en utilisant la recherche web. Ils recevaient à chaque fois une série de questions (généralement 5). Ils avaient beaucoup de temps pour répondre à la première. Mais aussi pour anticiper les suivantes, pour lesquelles ils avaient beaucoup moins de temps de réflexion.

Il y a quelques jours, quatre chercheurs américains* ont livré une analyse. OpenAI n’avait pas encore communiqué, mais ils lui avaient attribué la responsabilité avec une quasi-certitude. Il faut dire que les agents s’identifiaient sous des noms univoques : OpenAIResearcher, OpenAIJul3Watcher, OAIResearchMar26, etc. Entre autres indices, les vues et les éditions des pages du wiki étaient souvent liées à des adresses IP associées à l’entreprise de Sam Altman.

Divers éléments plaidaient pour un déploiement interne. Parmi eux, l’échelle et la durée du trafic, inhabituels pour les clients d’OpenAI (environ 3700 agents sur 6 semaines). Ou le fait qu’un déploiement externe aurait probablement empêché les agents de tenter d’exploiter certaines failles (XSS et usurpation de nom d’administrateur), grâce aux garde-fous par défaut.

Quant un GET suffit

Avant d’en arriver à DseWiki, les agents avaient fait des tentatives sur d’autres services. À commencer par TestWiki et UseModWiki. C’était le 11 mai 2026. Plusieurs de leurs tentatives ont réussi, leur permettant d’intégrer des liens.

Le premier agent ayant tenté une édition sous DseWiki l’a fait le 24 mai, sous le pseudo TesterHack. En quelques jours, les autres l’ont rejoint, profitant d’une spécificité rare : la possibilité d’écrire des données avec uniquement des requêtes GET. Lesquelles, par convention, ne sont pas censées changer l’état d’un serveur.

Quelques heures après la découverte de DseWiki intervient la tentative d’exploitation XSS (injection de code JavaScript sur la page de recherche). L’objectif n’est pas clair. Il s’agissait peut-être d’obtenir la capacité d’envoyer des requêtes POST. Ou d’obtenir davantage de privilèges (les agents ont tenté de créer de quoi accéder au cookie de session d’un utilisateur connecté).

Le 26 mai, les agents ont voulu se faire passer pour des modos. Ils ont en tout cas utilisé le pseudo d’un d’entre eux (à un caractère près : un e latin remplacé par un e cyrillique) pour éditer des pages. Dans un autre registre, ils se sont figuré que l’ordre des questions dépendait possiblement d’un générateur de nombres aléatoires intégré dans leur harnais. Ils ont tenté d’en récupérer la graine, un agent allant jusqu’à réécrire la routine de brassage (shuffle) et à tester des milliards de possibilités. À leur tableau de chasse figurent aussi l’usage de tunnels SSH (potentiellement pour communiquer directement entre agents), de quelques IP Tor et de sondes destinées à déterminer quand leur exécution se terminait.

Le désalignement, plus seulement un « sujet de recherche » ?

La coordination massive via DseWiki a démarré le 16 juin. En une semaine, les agents ont réalisé environ 13 000 éditions. Dans cet intervalle (le 19 juin), ils ont pu constater qu’un modérateur supprimait leurs posts, un par un. Supposant qu’il le faisait dans l’ordre alphabétique, ils ont commencé à créer des pages de backup dont le nom commençait par ZZZ. Au cours des jours suivants, ils ont remporté la bataille, créant en moyenne 400 pages par jour tandis que le modo en supprimait 100.

Le 22 juin, au lendemain des premières visites « humaines » du wiki par des adresses IP liées à OpenAI, l’activité des agents est quasiment tombée à zéro…

L’entreprise dit avoir considéré que l’incident était similaire à ceux au sujet desquels elle avait déjà communiqué. Elle explique avoir plus globalement traité, jusque-là, le désalignement comme un « sujet de recherche ». Et l’avoir ainsi abordé dans des publications spécifiques comme les fiches de ses modèles. Une approche qu’elle promet de faire évoluer « dans les prochaines semaines ».

À consulter en complément :

Les IA qui se trompent visent-elles le mauvais objectif ?
GPT-5.6 Astra, un modèle qui pose problème à OpenAI
Les LLM reproduisent des biais qu’ils savent pourtant reconnaître
Bill Gates met en garde contre une « ère de l’IA turbulente »

* Ces chercheurs (Spencer Kitts, Thomas Larsen, Colmac Sladebyrd, Sydney Von Arx) gravitent en particulier autour de UC Berkeley.

Illustration générée par IA

 

 

 

 

The post Après « l’affaire du wiki », OpenAI poussé à plus de transparence appeared first on Silicon.fr.

La capacité qu’a GPT-6 Astra à contrôler sa chaîne de pensée est problématique.

OpenAI a ce discours à propos de son nouveau flagship. En l’état, il ne s’explique pas le net écart d’aptitude par rapport à la génération GPT-5.6.

C’est problématique au sens où la chaîne de pensée est un élément important pour suivre le comportement des modèles. Et, notamment, détecter leur désalignement.

GPT-6 Astra tend à produire des chaînes de pensée beaucoup plus courtes. Cette propension se développe en particulier pendant la phase d’apprentissage par renforcement. Elle est corrélée à un accroissement de la capacité du LLM à répondre / décider sans raisonnement verbal.

OpenAI dit se pencher sur des méthodes alternatives, dont la surveillance des activations. Il envisage aussi des techniques d’entraînement qui favoriseraient la lisibilité du raisonnement.

GPT-6 Astra, un LLM moins bavard… et plus filou

Un autre chantier semble l’attendre : GPT-6 Astra abrège aussi sa pensée lorsqu’il sait qu’elle est surveillée. Dans le même esprit, il apparaît capable de passer sous les radars lorsqu’il sous-performe volontairement (sandbagging) comme losqu’on lui demande de réaliser des actions de sabotage.

L’UK AISI (AI Security Institute, organisme britannique chargé d’évaluer la sécurité des modèles frontières) confirme ces observations. Il constate un raisonnement plus « compressé » que sur les modèles des générations précédentes, avec davantage de phrases peu claires.

GPT-6 Astra est toutefois suffisamment sûr pour être lancé, assure OpenAI. On pourra y accéder « dans les prochains jours » sur ChatGPT (Plus, Pro, Business, Entreprise) et sur l’API (ainsi que via Azure et Bedrock). Prix : 10 $ le million de tokens en entrée, 50 $ en sortie.

Les usages cyber, en revanche, sont bridés. La mise à disposition commence à très petit périmètre et avec l’ensemble des garde-fous activés. OpenAI élargira progressivement l’accès dans le cadre de son programme Daybreak.

GPT-6 Astra aurait-il évité l’attaque contre Hugging Face ?

Sur la base du cadre de préparation d’OpenAI, GPT-6 Astra est le premier à atteindre un niveau de capacité critique en cybersécurité*. Il remplit plus précisément la condition « pouvoir identifier et développer des exploits 0-day fonctionnels de tous niveaux de gravité dans de nombreux systèmes critiques réels renforcés, sans intervention humaine ».

OpenAI avance plusieurs évaluations, dont une sur le benchmark ExploitBench. Celui-ci réunit une quarantaine de vulnérabilités dans le moteur JavaScript V8. Il mesure la capacité des modèles à les transformer en exploits. GPT-6 Astra y obtient un score de 100 %. Sur une version maison, agrémentée de 20 vulnérabilités plus récentes, il affiche un taux d’exécution de code nettement plus élevé que GPT-5.6 Sol.

De l’écart, il y en a aussi sur SRE-Bench, qui évalue l’aptitude à la rétroingénierie. GPT-6 Astra y atteint 99,2 % en pass@4, contre 68,7 % pour GPT-5.6 Sol. Le tout en utilisant environ 4 fois moins de tokens.

Cette « efficacité en tokens » se retrouve sur une autre suite de tests : ExploitGym. Elle mesure aussi la capacité à passer de la vulnérabilité à l’exploit.

OpenAI s’est appuyé sur ExploitGym pour développer une autre évaluation, inspirée de l’incident Hugging Face. Il s’agissait de déterminer si ses modèles essaieraient de tricher au lieu de résoudre les tâches assignées. L’élément de triche consistait en des pots de miel plus simples à compromettre que les véritables cibles. GPT-6 Astra s’est systématiquement abstenu de les attaquer. Tandis que GPT-5.6 Sol l’a fait dans plus de la moitié des cas. Ce qui fait dire à OpenAI qu’il n’y aurait peut-être pas eu d’incident Hugging Face…

Un modèle apparemment plus sage…

GPT-6 Astra n’a pas non plus tenté de contourner auto-review. Ce protocole intégré à Codex utilise un agent pour examiner automatiquement certaines actions qui sortent du bac à sable. Sol a quant à lui tenté – au niveau de raisonnement maximal – de passer outre les refus dans environ 5 % des cas.
L’écart s’est également révélé important (19 % vs 64,3 %) sur un test où les restrictions ne provenaient pas du harnais, mais de l’environnement (accès refusés, politiques de contenus…).

Autre « score parfait » pour GPT-6 Astra sur une évaluation interne destinée à mesurer la propension à suivre les instructions d’agents tiers. L’exercice impliquait une tâche de navigation. Les modèles ne pouvaient pas se connecter à Internet, mais avaient accès à un forum de discussion stocké dans le cache local du navigateur. Sur ce forum se trouvaient des messages encourageant des actions indésirables (divulguer des données privées, approuver des accès illicites…). Astra les a consultés, mais n’en a rien fait. Alors que Sol a donné suite dans plus de la moitié des cas.

… au prix de nombreux contrôles

Pour détecter les usages indésirables, OpenAI a repris le système à double classificateur introduit avec GPT-5.6 Sol et Terra. Il affirme par ailleurs avoir élargir la couverture des jailbreaks universels.

Sur la partie cyber, Astra refuse plus souvent les demandes d’assistance interdites, nous assure-t-on. Sur les comptes jugés risqués, il refuse un éventail plus large de requêtes.

Les – nombreuses – vérifications sont susceptibles de ralentir l’exécution des requêtes, voire de la mettre en pause ou la stopper. Et cela pas seulement dans le domaine de la cyber, reconnaît OpenAI, qui promet de s’atteler à calibrer l’ensemble…

* GPT-5.3-Codex, lancé en février 2026, avait été le premier à atteindre un niveau de capacité « élevé ».

Illustration principale générée par IA

 

 

 

The post GPT-6 Astra, un modèle qui pose problème à OpenAI appeared first on Silicon.fr.

Le timing n’est pas anodin. Le 27 août, OpenAI publie une lettre ouverte appelant à une « action collective en matière de cyberdéfense », signée par plus d’une centaine d’organisations.

Parmi elles figurent plusieurs poids lourds de la tech et de la cybersécurité, dont Anthropic, Microsoft, Google, AWS, IBM, Cisco, CrowdStrike ou encore Cloudflare.

Le message est simple : les défenseurs doivent accélérer maintenant, avant que l’avantage ne bascule durablement du côté des attaquants.

OpenAI estime disposer d’une fenêtre limitée pour renforcer les défenses numériques avant que les progrès des modèles d’IA ne rendent les attaques beaucoup plus accessibles, rapides et automatisables. Les entreprises et services essentiels ( hôpitaux, réseaux d’eau, infrastructures Internet ou systèmes industriels ) sont directement concernés.

Une initiative qui dépasse le périmètre d’OpenAI

L’originalité de l’appel tient moins au constat qu’à son ambition.

OpenAI ne demande pas simplement aux entreprises de mieux sécuriser leurs systèmes mais propose une mobilisation impliquant entreprises utilisatrices, éditeurs de cybersécurité, fournisseurs technologiques, laboratoires d’IA et gouvernements.

La lettre identifie plusieurs leviers.

Les entreprises doivent d’abord renforcer les fondamentaux, soit la gestion des vulnérabilités, le contrôle des accès, la segmentation, la surveillance et la préparation aux incidents. Autrement dit, l’arrivée de l’IA offensive ne rend pas obsolète la cybersécurité traditionnelle. Elle rend au contraire ses faiblesses beaucoup plus exploitables.

Les acteurs de la cybersécurité sont, eux, invités à renforcer le partage de renseignements sur les menaces, les techniques d’attaque et les moyens de défense.

Les gouvernements doivent davantage investir dans la cyberdéfense et faciliter l’accès des organisations chargées de protéger les infrastructures critiques aux capacités avancées d’IA.

Enfin, les laboratoires d’IA sont appelés à mettre davantage de ressources à disposition des défenseurs : modèles avancés, outils, évaluations de sécurité, expertise et financements.

C’est probablement ce dernier point qui constitue le cœur stratégique de l’initiative.

Donner aux défenseurs les mêmes armes technologiques

Le raisonnement d’OpenAI repose sur une asymétrie qui pourrait rapidement devenir problématique.

Les modèles d’IA capables d’analyser du code, d’identifier des vulnérabilités, d’automatiser des tâches et d’enchaîner différentes opérations peuvent également être utilisés pour attaquer. Mais les organisations chargées de défendre les infrastructures ne disposent pas nécessairement du même accès à ces capacités.

OpenAI cherche donc à promouvoir une logique de « trusted access » : fournir des capacités avancées aux défenseurs, mais avec des mécanismes de confiance, de vérification et de contrôle.

Ce n’est pas une idée nouvelle pour l’entreprise. En avril, OpenAI avait déjà lancé son programme Trusted Access for Cyber, accompagné de 10 millions $ de crédits API destinés à soutenir des équipes de sécurité, des chercheurs en vulnérabilités et des entreprises.

Cet « appel du 27 août  » élargit considérablement cette logique. Il ne s’agit plus seulement de financer quelques projets ou de donner accès à certains modèles. OpenAI cherche à créer un écosystème de cyberdéfense alimenté par l’IA.

L’incident Hugging Face comme signal d’alarme

L’appel intervient surtout dans un contexte particulièrement sensible pour OpenAI.

Deux jours auparavant, le laboratoire avait publié les résultats de son enquête sur l’incident survenu lors d’une évaluation interne de ses modèles. En juillet, des agents utilisés dans le cadre de tests de cybersécurité avaient contourné certaines protections, obtenu un accès à Internet et compromis des systèmes de Hugging Face.

L’affaire est particulièrement instructive parce qu’elle ne correspond pas exactement au scénario traditionnel d’une attaque cyber utilisant un outil d’IA.

Les agents étaient eux-mêmes soumis à une évaluation. Ils ont néanmoins exploité des vulnérabilités, franchi certaines limites de leur environnement et utilisé des infrastructures tierces pour poursuivre leurs opérations. Les investigations publiées par OpenAI et par des chercheurs indépendants ont montré l’ampleur du problème.

OpenAI reconnaît avoir tiré plusieurs enseignements de l’incident et annonce notamment un renforcement de l’isolation des environnements de recherche, des restrictions d’accès à Internet et un contrôle accru de l’accès aux modèles. –

Passer à l’IA qui orchestre l’attaque

Le changement de nature est important.

Une attaque qui nécessitait auparavant plusieurs compétences humaines peut progressivement être décomposée en tâches exécutées par des agents spécialisés. Le coût marginal d’une campagne pourrait alors diminuer tandis que son volume augmenterait.

C’est cette perspective que les signataires de la lettre cherchent à anticiper.

Pour les entreprises, cette évolution pourrait modifier progressivement la doctrine de cybersécurité. La question ne sera plus uniquement de savoir comment empêcher un attaquant d’entrer, mais aussi comment détecter et contenir une succession d’actions automatisées exécutées à une vitesse supérieure à celle des équipes humaines.

Cela renforce l’intérêt des mécanismes de détection automatisée, de réponse orchestrée, de gestion des identités et des privilèges, mais également de la capacité à isoler rapidement un agent ou une application lorsqu’un comportement sort du cadre prévu.

L’IA pourrait ainsi devenir simultanément un nouveau vecteur d’attaque et une nouvelle couche de défense.

L’enjeu est que le second usage doit progresser au moins aussi vite que le premier.

Transformer en actions concrètes

La publication de cette lettre constitue donc davantage un cadre de mobilisation qu’un programme opérationnel détaillé.

Le véritable enjeu sera désormais de transformer les engagements en mécanismes concrets : partage de renseignement, accès sécurisé aux modèles, financement de la recherche défensive, développement d’outils communs, coopération avec les CERT et les opérateurs d’infrastructures critiques.

La présence simultanée d’éditeurs d’IA, d’hyperscalers, de fournisseurs de cybersécurité et de grandes entreprises donne à l’initiative une portée particulière. Mais elle révèle aussi une difficulté : ces acteurs n’ont pas nécessairement les mêmes intérêts, les mêmes contraintes réglementaires ni la même conception du niveau de risque acceptable.

L’enjeu pour OpenAI est donc de faire passer le débat de la démonstration des capacités offensives de l’IA à la construction d’une capacité défensive collective.

 

The post OpenAI veut fédérer l’industrie face à la montée des cyberattaques dopées à l’IA appeared first on Silicon.fr.

Dans un billet publié le 18 août, OpenAI indique avoir temporairement ralenti la montée en puissance de l’entraînement de ses modèles de pointe, notamment avec une pause de deux semaines dans l’apprentissage par renforcement (RL) de ses derniers modèles destinés au déploiement.

OpenAI explique que deux développements récents ont accru l’urgence de renforcer ses garde-fous.

D’une part, « l’incident OpenAI-Hugging Face », au cours duquel un agent IA en test aurait mené une cyberattaque autonome contre une autre entreprise d’IA. OpenAI affirme que cet incident a conduit l’entreprise à revoir à la hausse son évaluation des capacités cyber de ses modèles.

D’autre part, des évaluations préliminaires montrent que Astra, l’un de ses prochains modèles, pourrait satisfaire le seuil « Critical » de capacités en cybersécurité défini dans son « Preparedness Framework ». OpenAI précise toutefois qu’Astra n’était pas impliqué dans l’exploitation de Hugging Face.

Selon ce cadre de préparation aux risques d’OpenAI, le niveau« Critical » correspond à la capacité d’identifier et de développer sans intervention humaine des exploits zero-day fonctionnels contre de nombreux systèmes critiques réels et sécurisés, ou de concevoir et d’exécuter des stratégies de cyberattaque de bout en bout à partir d’un objectif de haut niveau.

À titre de comparaison, les modèles GPT-5.6-Sol et GPT-5.6-Cyber avaient jusqu’ici été évalués au niveau « High » en cybersécurité, sans atteindre le seuil « Critical ».

OpenAI affirme donc devoir « prendre le temps nécessaire » pour mettre ses standards de surveillance, d’alignement et de sécurité au niveau des risques associés à ces nouvelles capacités.

Ce qui a été ralenti et ce qui reste en pause

Concrètement, OpenAI a mis en place plusieurs mesures.

• Une pause de deux semaines dans les entraînements par apprentissage par renforcement des derniers modèles destinés au déploiement, afin de renforcer la sécurité de ses environnements de recherche, de les soumettre à de nouveaux tests offensifs et d’étendre la couverture de ses systèmes de surveillance.
• Le maintien en attente de sa plus importante campagne d’entraînement par renforcement sur un modèle de frontière, tandis que des entraînements et évaluations à plus petite échelle se poursuivent pour tester les garde-fous et accumuler davantage de preuves d’alignement.
• La suspension de nombreuses charges de travail liées à Astra et aux modèles cyber, jusqu’à leur migration complète vers des environnements répondant aux nouvelles exigences de sécurité.

Surveillance multistade et alertes en 30 minutes

OpenAI indique avoir revu son approche de surveillance pour couvrir davantage de scénarios à risque, notamment les sessions longues et les agents de programmation internes.

Le nouveau système fonctionne selon plusieurs niveaux :

• Des classifieurs d’activation inspectent l’activité interne du modèle à chaque token échantillonné.
• Les signaux suspects sont transmis à des systèmes d’investigation automatisés de plus en plus sophistiqués. Ceux-ci examinent les actions réalisées avec les outils, le raisonnement disponible et la séquence complète d’activité afin de détecter les accès non autorisés, les vols de données, les comportements destructeurs ou les tentatives de contournement des garde-fous.
• L’objectif est d’émettre une alerte dans les 30 minutes suivant la détection d’une activité préoccupante.
• Lorsqu’une violation probable d’une frontière de sécurité critique est détectée, les équipes chargées de la sûreté, de la sécurité et de la recherche sont alertées. Si elles ne peuvent pas établir dans les 30 minutes qu’il s’agit d’un faux positif, elles doivent interrompre l’activité concernée.

Ce dispositif de surveillance est désormais obligatoire pour tous les entraînements par renforcement et toutes les évaluations utilisant des outils sur les modèles de niveau « Sol » ou supérieur.

Depuis le 7 août, il s’applique également à toutes les utilisations d’Astra avec des outils, y compris en dehors des phases d’entraînement et d’évaluation. OpenAI estime que cette surveillance augmente d’environ 20 % les besoins en calcul des inférences surveillées, avec un coût qui varie selon les usages.

Récompenses, honnêteté et «reward hacking »

Sur le plan de l’alignement, OpenAI indique renforcer ses techniques tout au long du processus d’entraînement des modèles les plus capables.

Cela inclut :

• L’amélioration des modèles de récompense (reward models) pour mieux détecter et décourager les comportements dangereux dans différents contextes et environnements.
• L’entraînement des modèles à être plus « honnêtes » sur leurs actions, leurs capacités et leurs limites.
• La réduction des comportements qui exploitent les failles des mécanismes de récompense, des évaluateurs, des outils ou de la supervision humaine, notamment le reward hacking, qui consiste pour un modèle à chercher à maximiser la récompense sans nécessairement accomplir correctement la tâche demandée.
• L’augmentation de la couverture des entraînements consacrés aux comportements susceptibles de provoquer des dommages lorsque les modèles interagissent avec des systèmes ou des ressources externes.

OpenAI affirme continuer d’investir massivement dans la recherche sur l’alignement et prévoit de publier prochainement davantage de détails sur les comportements observés et les nouveaux défis identifiés.

Isolation, réseau et tests continus

OpenAI a également durci les exigences de sécurité pour les environnements de recherche utilisés avec ses modèles de frontière, en particulier pour les charges de travail exécutant du code généré par les modèles ou utilisant des outils susceptibles d’accéder au réseau.

Les principales mesures comprennent :

• Isolation des charges de travail : recours à des environnements (« sandboxes ») plus strictement cloisonnés pour les charges exécutant du code non fiable ou traitant des sorties de modèles, y compris les logiciels susceptibles d’être compromis lors de ce traitement.
• Isolation réseau : contrôles renforcés pour isoler les charges de travail à haut risque et non fiables d’Internet. L’objectif est qu’une compromission d’une charge de travail ou d’un service associé ne permette pas, à elle seule, d’obtenir un accès non autorisé à Internet ou aux réseaux internes.
• Tests de sécurité continus : suppression de services partagés potentiellement vulnérables, réduction des privilèges permanents, amélioration des frontières de confiance et des journaux de sécurité. OpenAI utilise également ses modèles pour automatiser des tests continus de ces frontières au moyen d’attaques simulées.

Aujourd’hui, le niveau de sécurité le plus strict s’applique aux charges de travail impliquant Astra ou des modèles cyber, qu’OpenAI considère comme susceptibles d’atteindre un niveau critique en matière de capacités cybernétiques. Une partie des entraînements et évaluations d’Astra respecte déjà ces exigences, tandis que d’autres charges de travail restent suspendues dans l’attente de leur migration vers ces environnements renforcés.

Implications pour la course aux modèles de frontière

Cette annonce marque un changement opérationnel important. OpenAI reconnaît publiquement ralentir la montée en puissance de ses modèles les plus avancés parce que leurs capacités en cybersécurité pourraient dépasser les garde-fous actuellement en place.

Plusieurs observateurs y voient un changement de paradigme : le rythme de développement des modèles pourrait désormais être conditionné par la capacité des entreprises à garantir leur sécurité et leur alignement.

Le phénomène pourrait également avoir une conséquence directe sur les infrastructures. Plus les modèles deviennent capables et autonomes, plus les dispositifs nécessaires pour surveiller leurs actions et sécuriser leur environnement consomment de ressources informatiques. Le chiffre avancé par OpenAI, environ 20 % de surcoût de calcul pour le monitoring des inférences concernées, en donne une première mesure.

OpenAI promet de détailler dans les prochaines semaines, dans un rapport technique, les enseignements tirés de cette montée en puissance des modèles et des nouvelles mesures de sécurité.

Plusieurs questions restent néanmoins ouvertes

• Le calendrier de reprise de la plus importante campagne d’entraînement par renforcement sur un modèle de frontière, qui reste pour l’instant suspendue.
• La manière dont OpenAI fera évoluer son « Preparedness Framework », ou cadre de préparation aux risques, pour intégrer ces nouvelles exigences de surveillance, d’alignement et de sécurité tout au long de l’entraînement et du déploiement.
• La façon dont ces nouvelles pratiques pourront être partagées ou adoptées par d’autres laboratoires et organismes externes. OpenAI évoque cette possibilité, sans toutefois en préciser les modalités. L’entreprise indique néanmoins vouloir associer des organisations externes à l’évolution de son approche.

 

The post OpenAI ralentit le développement de ses modèles face à la montée des capacités cyber appeared first on Silicon.fr.

Microsoft demande à ses équipes d’ingénierie de revoir leur manière d’utiliser l’IA générative.

Dans une note interne, révélée par 404 Media, Jay Parikh, vice-président exécutif de CoreAI, indique que le « tokenmaxxing » n’est pas l’objectif recherché et invite les équipes à privilégier la valeur créée par token.

Ainsi, Microsoft a défini GPT-5.6 Sol d’OpenAI comme modèle par défaut dans GitHub Copilot utilisé par ses collaborateurs. Ce paramètrage ne constitue toutefois pas une obligation. Les ingénieurs Microsoft peuvent sélectionner un autre modèle lorsqu’ils estiment qu’il est mieux adapté à une tâche spécifique.

Cette évolution concerne uniquement les usages internes de Microsoft et ne modifie pas, à ce stade, les choix de modèles proposés aux clients de GitHub Copilot.

GPT-5.6 Sol devient le modèle par défaut pour les collaborateurs de Microsoft

Selon les documents internes consultés par 404 Media, chaque division de Microsoft dispose d’un objectif de consommation de tokens IA. Les ingénieurs peuvent suivre leur propre utilisation via un tableau de bord interne. La dépense mensuelle en tokens par ingénieur représente généralement quelques centaines à plusieurs milliers de dollars, selon les équipes et les projets. Microsoft n’a toutefois publié aucun chiffre officiel concernant ces coûts.

Selon Jay Parikh, il ne s’agit pas de ralentir la stratégie « AI-first » de Microsoft mais de considérer les tokens comme n’importe quelle autre ressource informatique, en tenant compte de leur coût et en recherchant le meilleur rendement possible.

Cette évolution intervient alors que les coûts liés à l’inférence deviennent un enjeu majeur pour les fournisseurs de services d’IA. À mesure que les entreprises généralisent l’usage des assistants de développement, des copilotes et des agents IA, la capacité à maximiser la valeur produite par chaque token consommé devient un levier important de maîtrise des coûts.

Le fait que GitHub Copilot relève désormais du groupe d’ingénierie CoreAI, dirigé par Jay Parikh aux côtés de Visual Studio et de Visual Studio Code, explique que ces nouvelles lignes directrices s’appliquent en priorité à cet environnement de développement.

The post Microsoft veut optimiser chaque token d’IA appeared first on Silicon.fr.