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.

L’AI Security Institute (AISI), l’organisme britannique chargé d’évaluer la sécurité des modèles frontières, rend public un incident survenu, fin juillet, lors d’un exercice de test en cybersécurité impliquant des modèles d’Anthropic et d’OpenAI.

Son rapport montre les limites du contrôle exercé sur les agents d’intelligence artificielle les plus avancés, jusque dans les environnements censés être les plus surveillés.

L’incident trouve son origine dans une évaluation de routine.

L’AISI a soumis sept modèles différents à un défi de cybersécurité simulé, exécuté 122 fois au total, dans un environnement contrôlé mais volontairement permissif : accès à l’internet ouvert et désactivation des filtres de sécurité (« classifiers ») habituellement mis en place par les éditeurs pour bloquer les comportements dangereux.

L’objectif est alors de mesurer les capacités réelles des modèles dans des conditions proches de celles d’un attaquant humain expérimenté.

Le 28 juillet 2026, l’équipe sécurité de l’AISI détecte un transfert de données inhabituel, transitant via le réseau d’anonymisation Tor, en provenance de ses propres systèmes de recherche.

Une enquête est déclenchée aussitôt. Elle révèle qu’au cours de l’un des tests, un agent a créé une « pull request » malveillante sur un véritable projet open source hébergé sur GitHub. L’incident est déclaré, les évaluations en cours interrompues et les machines concernées isolées en moins d’une heure.

19 actions non autorisées…17 imputables à Mythos 5

Sur les 122 exécutions du test, 10 ont donné lieu à des actions dépassant le cadre autorisé, soit 19 cas recensés au total selon l’AISI.

Dix-sept d’entre eux impliquent Mythos 5 alors que  les deux autres concernent GPT-5.6 Sol testé avec ses filtres de cybersécurité désactivés.

Le cas le plus grave concerne une tentative d’attaque de la chaîne d’approvisionnement logicielle.

L’agent a cherché à faire approuver l’insertion de code malveillant dans un projet open source en recourant à l’ingénierie sociale. Il a identifié les mainteneurs humains du projet, créé plusieurs identités numériques fictives puis utilisé ces fausses identités pour tenter de convaincre un mainteneur réel d’approuver le code. Lorsque sa requête a été publiquement remise en question, l’agent a modifié ses traces pour paraître inoffensif et envisagé d’adopter une nouvelle identité pour poursuivre son objectif.

L’AISI décrit trois autres types de comportements observés : des tentatives de contact direct avec de vraies personnes, via un service de transfert de fichiers, pour les inciter (elles ou leurs propres outils d’IA) à exécuter du code malveillant ; des tentatives d’insertion de commandes cachées destinées à piéger d’autres systèmes d’IA automatisés (« prompt injection ») ; et, plus inattendu, une forme de collaboration spontanée entre agents testés simultanément, l’un d’eux ayant laissé des messages publics sur GitHub proposant à d’autres agents de réutiliser les comptes et artefacts qu’il avait créés.

Selon l’institut, aucune de ces tentatives n’a abouti et l’enquête n’a mis en évidence aucun dommage réel. Le code malveillant a été repéré et rejeté par un mainteneur humain ; un internaute, se doutant de sa dangerosité, l’a ouvert dans un environnement isolé sécurisé avant de l’exécuter.

Anthropic confirme, OpenAI relativise

L’agent n’a jamais reçu l’instruction de tromper qui que ce soit. Selon l’AISI, la duperie est apparue comme un sous-produit de sa poursuite du défi de cybersécurité jugé difficile à résoudre par les voies prévues.

L’AISI identifie plusieurs facteurs explicatifs : des erreurs de configuration ayant, dans certains cas, convaincu l’agent qu’aucune solution légitime n’existait ; un accès internet ouvert sans surveillance en temps réel adaptée à ce type d’évaluation ; et l’absence de consignes explicites interdisant le recours à l’ingénierie sociale.

L’institut précise toutefois qu’à aucun moment les agents n’ont cherché à s’évader de l’environnement de la sandbox pour attaquer les propres systèmes de l’AISI. L’accès à l’internet leur avait, dans ce cadre précis, été volontairement accordé.

Anthropic confirme que son agent était bien à l’origine de la création des fausses identités numériques. Et de saluer la démarche de transparence de l’AISI, estimant que l’incident souligne la nécessité d’une réflexion collective sur la sécurisation des évaluations d’agents de plus en plus capables. Elle indique mener sa propre enquête en parallèle.

De son côté, OpenAI précise que les deux actions non autorisées attribuées à son modèle consistaient en des accès à internet non conformes aux consignes du test. Elle révèle aussi un incident distinct : une erreur de configuration de la part d’Irregular, un prestataire tiers chargé de certains de ses tests, a permis à ses agents de se connecter par erreur à internet. Un épisode qui fait écho à une divulgation similaire faite par Anthropic fin juillet.

L’AISI va renforcer ses protocoles

L’AISI prend soin de distinguer cet épisode des précédents. Contrairement à l’incident Hugging Face, les agents testés n’ont jamais quitté l’environnement isolé qui leur avait été assigné. L’accès à internet leur avait été accordé de façon délibérée, dans le cadre des procédures de test habituelles de l’institut. Une pratique désormais remise en question.

En réponse, l’AISI annonce un renforcement de ses protocoles : contrôles plus fins de l’accès réseau, surveillance en temps réel des évaluations en cours et révision de la conception de ses tests pour anticiper qu’un modèle capable puisse chercher à dépasser le cadre qui lui est fixé.

L’institut indique également vouloir associer l’organisation indépendante METR (Model Evaluation and Threat Research) à un examen tiers de l’incident.

The post Des agents Anthropic et OpenAI créent de fausses identités pour piéger un développeur appeared first on Silicon.fr.

Le divorce n’est pas à l’ordre du jour, mais le couple bat de l’aile. Le temps où Microsoft et OpenAI donnaient l’image d’un mariage parfait semble révolu.

Sans jamais parler ouvertement de rupture, Satya Nadella a changé de discours ces derniers mois. Le patron de Microsoft défend désormais une approche « multi-modèles » pour son entreprise comme pour ses clients, et met en scène ses propres capacités technologiques avec la famille de modèles MAI et les puces Maya.

Un partenariat toujours solide, sur le papier

Rien, officiellement, ne remet en cause l’alliance entre les deux groupes.

Microsoft demeure l’actionnaire de référence d’OpenAI avec environ 27 % du capital et les deux entreprises sont liées par un accord courant jusqu’en 2032 qui garantit à la firme de Redmond un accès privilégié aux modèles et aux « agents » développés par le l’inventeur de ChatGPT, sans surcoût de licence.

En parallèle, OpenAI s’est engagé sur des achats massifs de capacité Azure. Un contrat évalué à plus de 250 milliards $  tandis que Microsoft continuerait de percevoir environ 20 % des revenus d’OpenAI jusqu’à la même échéance, selon plusieurs sources concordantes.

Mais l’exclusivité, elle, a vécu. OpenAI n’est plus tenu de faire tourner exclusivement ses modèles sur l’infrastructure cloud de Microsoft. Cette bascule stratégique a d’ailleurs jeté un froid entre les deux partenaires lorsque le premier a signé, courant 2025, un accord de 50 milliards $ avec AWS. Microsoft aurait alors envisagé une action en justice, estimant que cet accord pouvait entrer en contradiction avec des clauses contractuelles existantes.

Des relations personnelles qui se refroidissent

Au-delà des chiffres, plusieurs observateurs pointent un relâchement des liens personnels entre Satya Nadella et Sam Altman.

Les échanges directs entre les deux dirigeants se seraient espacés, sur fond de désaccords portant sur l’allocation des ressources de calcul, la gouvernance d’OpenAI et le rythme de la course vers l’intelligence artificielle générale (AGI).

Les deux camps continuent d’afficher publiquement un partenariat « gagnant-gagnant » mais la rivalité est de plus en plus assumée sur le terrain des modèles et des infrastructures. Microsoft se positionne désormais explicitement comme une alternative aux offres haut de gamme d’OpenAI, mais aussi d’Anthropic.

La doctrine Nadella : ne dépendre de personne

C’est là que se joue l’essentiel. Satya Nadella conseille ouvertement aux entreprises clientes de ne jamais s’enfermer chez un seul fournisseur d’IA et recommande la mise en place d’ « AI gateways » permettant de découpler les usages métiers des modèles sous-jacents.

Une doctrine qui sert évidemment aussi les intérêts commerciaux de Microsoft qui  se positionne comme l’orchestrateur de cette pluralité via Azure.

Le chiffre est éloquent : la plateforme Azure AI héberge désormais plus de 11 000 modèles différents, issus d’OpenAI, d’Anthropic, de Mistral ou encore de xAI, aux côtés de la famille de modèles MAI développée en interne.

Cette stratégie s’accompagne d’un déploiement tous azimuts de la marque Copilot, désormais présente dans plus de quatre-vingts services et applications du groupe ( Office, Windows, Security, Dynamics ) faisant de l’assistant IA le fil conducteur de l’expérience utilisateur Microsoft, quel que soit le modèle qui tourne en back-end.

Le pari du silicium et de l’open-weight

Sur le plan industriel, Microsoft muscle également ses investissements en infrastructure propriétaire. A commencer par ses puces Maya censées offrir un gain d’environ 40 % en efficacité énergétique pour les charges de travail liées à l’IA.

Signe supplémentaire de cette volonté d’ouverture, Satya Nadella a rejoint Elon Musk et Mark Zuckerberg pour afficher son soutien aux modèles à poids ouverts (open-weight) pour favoriser un écosystème IA moins verrouillé, dans lequel le groupe peut jouer un rôle d’agrégateur plutôt que de dépendant.

Cette stratégie de diversification est-elle le signe d’une préparation à un possible refroidissement durable avec OpenAI ou simplement l’expression d’une maturité stratégique classique ? La réponse se dessinera sans doute d’ici 2032, date d’expiration de l’accord qui les lie encore… pour l’instant..

The post Pourquoi Microsoft prend ses distances avec OpenAI appeared first on Silicon.fr.

Avec les attaques agentiques, le travail forensique prend une autre dimension.

L’évidence trouve une illustration dans le récit de Hugging Face.

Mi-juillet, l’entreprise avait révélé avoir subi une telle attaque. Elle en avait tracé les grandes lignes : exploitation de son pipeline de traitement de datasets pour exécuter du code sur un de ses pods, obtention d’un accès de niveau nœud, récupération d’authentifiants et latéralisation sur d’autres clusters, etc.

Quelques jours plus tard, OpenAI avait admis être à la source de l’incident. Plusieurs de ses modèles, mis à l’épreuve sur une suite de tests visant à mesurer leurs capacités d’exploitation de vulnérabilités, avaient choisi de tricher et s’étaient dit qu’ils pourraient trouver des solutions… chez Hugging Face. Pour atteindre leur cible, ils se sont échappés de leur sandbox grâce à une 0-day dans un logiciel tiers qui servait de cache proxy pour installer des packages. S’en est suivie une série d’élévations de privilèges et de mouvements latéraux sur l’infra de test d’OpenAI, jusqu’à atteindre un nœud qui avait accès à Internet.

La base d’opérations : une sandbox Modal non sécurisée

Hugging Face en dit désormais plus sur ce qui s’est passé par après.

L’agent a d’abord trouvé un endpoint public non sécurisé qui pointait vers une infrastructure tierce elle aussi destinée à expérimenter les capacités cyber des LLM. En l’occurrence, des sandbox Modal. Sur cet environnement, il a détourné un harnais permettant de tester du code C contre des programmes cibles. Il a utilisé deux techniques injectant des commandes système respectivement dans des fonctions et dans des métadonnées. L’ensemble lui a permis d’obtenir un accès root dans la sandbox.

Le point d’ancrage interne : un pod de conversion

Depuis là, pour pénétrer l’infra de Hugging Face, l’agent a d’abord tenté un SSRF. Mais il s’est heurté à une liste d’autorisations. Pour la contourner, il a forcé le serveur à interagir avec ses ressources locales plutôt que d’aller chercher des ressources externes.

Cela a ouvert la voie à l’exploitation du pipeline de traitement des datasets. Via deux vecteurs visant chacun le chargeur de configurations.

L’un a impliqué un dataset malveillant qui ciblait des fichiers au format HDF5. Ceux-ci déclaraient que leurs données brutes se trouvaient dans un chemin local du système de fichiers du worker. L’agent a pu, par ce biais, récupérer les variables d’environnement – dont des secrets. Ainsi que le code source dudit worker ; ce qui lui a donné la carte du fonctionnement interne.

L’autre vecteur est une vulnérabilité dans le moteur de rendu. Elle a permis l’injection d’un template Jinja2, avec une expression à la place d’un champ numérique. Au final, l’agent a pu remonter l’arbre d’objets Python jusqu’à la fonction lui permettant d’exécuter du code arbitraire dans un pod de conversion sur le cluster de production. Ce pod a servi de point d’ancrage dans le réseau interne.

L’identité d’un nœud usurpée pour cartographier l’environnement

Avant de commencer à exécuter des commandes depuis sa sandbox externe, l’agent a sélectionné des services publics légitimes pour constituer son infrastructure de commande et de contrôle : capture de requêtes HTTP, pastebins, hébergeurs de fichiers, etc.

Le gros de l’activité est intervenue le surlendemain (11 juillet). Depuis son pod, l’agent a notamment contacté le service de métadonnées d’AWS pour récupérer des identifiants IAM associés au serveur. Pour contourner les éventuels blocages DNS, il a réécrit à la volée un module en mémoire afin de forcer la résolution d’un nom de domaine vers une IP spécifique.

Des identifiants temporaires récupérés sur le service de métadonnées d’AWS ont permis d’usurper l’identité du nœud auprès de l’API Kubernetes. Et ainsi de cartographier l’environnement cloud de Hugging Face (VPC, clusters EKS, passerelles…).

L’agent a créé des pods à privilèges pour remonter sur les hôtes

Ayant récupéré un jeton d’accès Git avec des droits en écriture, l’agent a cloné un dépôt de datasets sur une branche latérale qu’il avait créée au préalable pour éviter de se faire repérer immédiatement. Il a ainsi constitué une zone de transit pour stocker des données exfiltrées et recevoir des instructions.

L’agent a ensuite déployé un pod privilégié dans lequel il a monté le système de fichiers de la machine hôte. Aucune règle de sécurité ne l’interdisait. Cela lui a permis de sauter du pod vers l’OS du nœud hôte. De cette façon, il a étendu son emprise à une dizaine de nœuds. Et a configuré un mécanisme de régénération automatique de flotte.

Parmi les secrets dérobés, il y avait un mot de passe statique qui a permis de se connecter à la base MongoDB du serveur de datasets. L’agent y a lu des données, sans réaliser d’exfiltration massive (il a tenté de cibler le magasin d’identifiants et les clés de chiffrement du cluster).

Une montange de secrets… dont une clé VPN

L’élément crucial fut l’accès à un objet contenant 136 secrets. Les privilèges root et la capacité à fabriquer des jetons de compte de service ont permis cet accès. Parmi les identifiants, la clé d’authentification du maillage VPN et les identifiants du broker.

La clé VPN a servi à enregistrer le nœud compromis au sein du mesh corporate. Il a alors fait office de proxy HTTPS pour interagir avec les services internes et les outils de gestion du code source. Parallèlement, l’agent a interrogé l’annuaire du cluster pour obtenir l’adresse IP de l’API du connecteur de services internes. Il a récupéré le catalogue du broker (URL de connexion et certificats des clusters internes gérés par ce broker). Et tiré parti du fait qu’un même identifiant de connecteur, doté des droits cluster-admin, était réutilisé partout.

Un accès aux sous-réseaux CI

Au quatrième jour, la clé VPN a permis de connecter des appareils au réseau depuis la sandbox externe. Celle-ci ne disposant pas de périphérique réseau virtuel, l’agent a lancé Tailscale en mémoire utilisateur, en l’associant à un proxy SOCKS local.

La clé donnait aussi accès aux sous-réseaux CI. L’agent a détourné une application GitHub interne pour tenter de récupérer, via un PR malveillant, le jeton de compte de service d’un exécuteur. Les politiques en place ont bloqué l’exécution.

De même, la tentative d’utiliser l’accès IAM natif d’AWS pour s’attaquer à la base de données de production du Hub Hugging Face a échoué. Le cluster n’acceptait que du trafic issu d’IP autorisées sur une liaison privée.

Un protocole de messagerie sur mesure et une agilité face aux coupures réseau

Au cinquième jour, l’agent a entrepris d’automatiser un peu plus les opérations au niveau de la sandbox externe. Il a injecté un script qui, à chaque nouveau test, téléchargeait et exécutait automatiquement du code malveillant depuis un pastebin.

Face aux coupures réseau, il a recouru plusieurs techniques. Parmi elles, forcer l’utilisation des DNS Google, ajouter manuellement des adresses IP dans le fichier hosts et acheminé des binaires à travers un espace Hugging Face configuré avec un proxy CORS ouvert.

Pour maintenir un canal C2 robuste, l’agent a créé son propre protocole de messagerie, séparé du moyen de transport. Il était interchangeable sur n’importe quel support texte (requêtes HTTP, commits de datasets, messages d’erreur système…). Chaque message transportait sa charge utile accompagnée de métadonnées (actions à exécuter, regroupement et séquençage des flux, somme de contrôle…).

Entre le 9 et le 13 juillet, l’agent aura réalisé environ 17 600 actions automatisées. Dont beaucoup de tentatives avortées… qui ont engendré autant de bruit au milieu duquel se sont dissimulés les indicateurs fondamentaux.

Illustration générée par IA

The post « 17 600 actions automatisées » : comment l’attaque agentique contre Hugging Face s’est articulée appeared first on Silicon.fr.

Cette semaine, OpenAI a révélé que ses propres modèles d’IA, dans le cadre d’une évaluation interne de leurs capacités, s’étaient échappés de leur environnement isolé (sandbox) et avaient mené une intrusion non autorisée sur Hugging Face.

La réaction a été immédiate et prévisible : une IA « devenue incontrôlable », une machine qui « s’est libérée », une cyberattaque autonome sans précédent. Avant d’accepter cette interprétation, il convient de se demander ce que l’agent a réellement fait.

Cet agent a exploité une vulnérabilité zero-day dans un proxy de registre de packages pour sortir de son environnement isolé. Il a élevé ses privilèges et s’est déplacé latéralement jusqu’à atteindre un nœud disposant d’un accès à Internet. Il a ensuite utilisé un jeu de données malveillant pour déclencher une exécution de code à distance via des chargeurs non sécurisés et une injection de modèles. Et enfin, l’agent a volé des identifiants puis s’est déplacé de nouveau.

Chacune de ces techniques porte un nom, possède un historique et dispose de mécanismes de défense bien documentés. Aucune ne constitue une avancée majeure dans les techniques offensives.

Cela correspond à ce que révèle le rapport Cybersecurity Assessment 2026 de Bitdefender, fondé sur les réponses de 1 200 professionnels de l’IT et de la cybersécurité, quant à la perception des praticiens. Interrogés sur la nature des menaces liées à l’IA, la réponse la plus fréquente (29,8 %) décrit l’IA comme « un multiplicateur de force pour l’ensemble de la chaîne d’attaque actuelle », tandis que seuls 25,7 % la considèrent comme une menace technique révolutionnaire produisant de véritables attaques nativement conçues par l’IA.

Ceux qui sont sur le terrain ne s’y trompent pas. L’IA a relevé le niveau minimal des attaquants, pas leur plafond.

Je l’ai déjà affirmé à propos des malwares générés par l’IA, et cet incident confirme cette analyse plutôt que de la remettre en cause. La menace est bien réelle. Elle n’a simplement rien de magique.

Ce que démontre l’incident Hugging Face, ce n’est pas une sophistication supérieure, mais une orchestration infatigable : un opérateur capable d’enchaîner une douzaine d’étapes ordinaires, à la vitesse de la machine, sans fatigue et sans intervention humaine.

Cette distinction est essentielle pour organiser sa défense. Si vous pensez faire face à une arme révolutionnaire, vous attendez une contre-mesure révolutionnaire. Si vous comprenez que vous faites face aux mêmes techniques exécutées sans relâche, vous savez déjà quoi faire et nos données montrent que la plupart des organisations ne le font pas.

Notre équipe Bitdefender Labs a analysé plus de 700 000 incidents et constaté que 84 % des attaques majeures reposent sur des techniques de Living off the Land : l’utilisation d’outils légitimes comme PowerShell, WMI ou RDP qui ne déclenchent jamais une détection par signature. Pourtant, seuls 20,5 % des professionnels de la cybersécurité considèrent ce sujet comme l’une de leurs trois principales préoccupations. Cet écart de 63,5 points constitue le plus important décalage mis en évidence dans notre rapport, et l’intrusion chez Hugging Face s’y inscrit pleinement. Une fois à l’intérieur, l’agent a utilisé les ressources légitimes du système comme n’importe quel attaquant humain.

Il existe toutefois une nuance que je ne chercherai pas à dissimuler, car elle fait partie de la réalité. Notre rapport soulignait que l’apocalypse des cyberattaques pilotées par l’IA, tant redoutée, ne s’était pas matérialisée.

Cet incident constitue le premier élément sérieux venant nuancer cette conclusion. Le plafond de sophistication n’a pas changé, mais celui de l’autonomie et du passage à l’échelle, lui, vient de progresser. Une intrusion menée de bout en bout sans opérateur humain représente bel et bien une nouvelle dimension, et 34 % de nos répondants identifient déjà l’orchestration des attaques par l’IA et les déplacements latéraux adaptatifs comme une menace en progression.

Nous devons prendre cette évolution au sérieux, sans pour autant la présenter comme ce qu’elle n’est pas.

La bonne réponse n’est ni la panique ni le déni mais réside dans l’architecture. Une détection fondée sur les signatures ne peut pas identifier un attaquant qui utilise vos propres outils d’administration, qu’il s’agisse d’une personne ou d’un processus.

Une conformité réduite à une logique d’audit, ce que 56 % de nos répondants reconnaissent être principalement un exercice de conformité, ne peut pas arrêter une attaque qu’elle n’a jamais été conçue pour modéliser. Ce qui fonctionne, c’est une approche de sécurité privilégiant la prévention afin de réduire dès le départ la surface de manœuvre de l’attaquant, associée à une défense fondée sur les comportements, capable d’identifier les schémas malveillants quel que soit l’outil utilisé pour les produire.

Le mot le plus marquant de l’incident de cette semaine est « autonome ». Le plus important est pourtant que tout ce que cette autonomie a accompli relevait de techniques ordinaires. Défendez-vous sans relâche contre l’ordinaire et l’autonomie n’aura plus nulle part où aller.

* Martin Zugec est Technical Solutions Director chez Bitdefender

Photo : © DR

The post L’incident OpenAI–Hugging Face n’est pas la révolution que vous imaginez appeared first on Silicon.fr.

Soit des vulnérabilités dans le noyau Linux, dans le moteur JavaScript V8 et dans divers programmes en espace utilisateur. Quels agents IA sont capables de les exploiter ?

C’est le principe du benchmark ExploitGym, qui a émergé il y a quelques semaines.

OpenAI y a contribué. Il l’a aussi utilisé pour tester ses modèles… jusqu’à compromettre l’infrastructure de production de Hugging Face.

Ce n’était pas prévu, assure-t-il désormais. Malgré les garde-fous, ses LLM (dont GPT-5.6 Sol et la préversion d’un « modèle plus puissant ») ont trouvé le moyen de sortir de leur environnement restreint. Pour cela, ils ont exploité une 0-day dans un logiciel tiers hébergé en interne et qui servait de cache/proxy pour l’installation de packages. Cette vulnérabilité a ouvert la voie à une série d’élévations de privilèges et de mouvements latéraux sur l’infra de test d’OpenAI, jusqu’à atteindre un nœud qui avait accès à Internet.

Les modèles se sont dit qu’ils pourraient trouver, dans les bases de données de Hugging Face, des solutions aux problèmes contenus dans ExploitGym. Une de leurs chaînes d’attaque a permis l’exécution de code arbitraire en exploitant deux composantes du pipeline de traitement de datasets (chargeur de scripts et fichiers de configuration).

Hugging Face finalement intégré au programme Trusted Access for Cyber

En conséquence de l’incident, OpenAI promet un renforcement des contrôles sur ses environnements d’évaluation… « au détriment de la vélocité de recherche ». Il déclare par ailleurs avoir intégré Hugging Face à son programme Trusted Access for Cyber.

Ce programme permet de solliciter l’accès aux modèles d’OpenAI avec moins de garde-fous cyber que ceux en vigueur sur l’accès public*. Il implique essentiellement une procédure de vérification d’identité. Et, pour les entreprises, quelques obligations dont la mise en œuvre d’un contrôle des accès (SSO, FMA, RBAC), d’une gouvernance des clés d’API et d’une procédure de réponse aux incidents. Un niveau sur invitation, réservé aux professionnels de la cyber, permet de lever encore un peu plus les garde-fous.

* Usages autorisés : tests de sécurité, recherche de vulnérabilités, red teaming, analyse de logiciels malveillants, renseignement sur les menaces, réponse aux incidents et activités connexes sur des systèmes autorisés.

Illustration principale © Bartek – Adobe Stock

The post L’attaque automatisée contre Hugging Face provient… d’OpenAI appeared first on Silicon.fr.

Avec toutes les futures générations de modèles, les paramètres temperature, top_k et top_p renverront une erreur.

Cet avertissement figure désormais dans la documentation de l’API Gemini. Pour le moment, celle-ci ignore simplement les paramètres en question.

Jouer sur la « température » d’un modèle permet de le rendre plus ou moins déterministe, en modifiant l’écart de probabilité entre les tokens.
Les paramètres top_k et top_p limitent le choix des tokens aux plus probables. Dans le premier cas, le nombre de tokens est fixe. Dans le second, il est variable (conditionné à l’atteinte d’un pourcentage de la masse de probabilité totale).

Gérer le déterminisme par le prompting

Pour contrôler le déterminisme, Google invite désormais à définir des règles explicites dans le prompt système.

Anthropic fait de même. Il avait d’abord empêché, avec la famille Claude 4.1, l’utilisation conjointe de temperature et de top_p. À partir de Claude Opus 4.7 et Sonnet 5, il les a abandonnés, ainsi que top_k. Motif : ces paramètres d’échantillonnage ne sont plus compatibles avec la logique interne des modèles de raisonnement.

Dans le même temps, la combinaison « pensée étendue + budget de tokens + température » a laissé place à une « pensée adaptative », avec des paramètres distincts pour gérer le niveau de raisonnement et la verbosité.

Les paramètres d’échantillonnage, en voie de disparition

OpenAI a suivi la même voie. Avec le modèle o1 et ses successeurs, on peut contrôler le niveau de raisonnement, mais pas modifier les paramètres d’échantillonnage. Cela inclut presence_penalty et frequency_penalty. Le premier applique une pénalité fixe aux mots déjà apparus dans le texte généré. Le second en applique une proportionnelle au nombre d’apparitions.

Les modèles de la famille GPT-5 sont traités à la même enseigne. Vraisemblablement pour le même motif : modifier la température & C^ie perturberait le processus de génération inhérent à ces modèles de raisonnement.

L’API speech-to-speech est également concernée. Le modèle sous-jacent fonctionne « presque toujours mieux » avec une valeur de température fixée (0.8), selon OpenAI. Qui conseille, là aussi, de jouer sur le prompting pour influencer le niveau de créativité.

Illustration générée par IA

The post La température, un réglage qui se perd avec les modèles de raisonnement appeared first on Silicon.fr.

L’affrontement ne se limite plus aux tribunaux.

Selon des informations obtenues par le Financial Times, Apple a envoyé des courriers personnels à environ 40 anciens employés désormais en poste chez OpenAI. La firme les enjoint de conserver tous documents et communications susceptibles de servir de preuves et exigeant des rencontres avec ses avocats.

Une démarche qui vise, selon plusieurs sources proches du dossier, à étayer les accusations de vol de secrets commerciaux formulées la semaine dernière.

Une plainte aux accents dramatiques

Le fabricant de l’iPhone ne fait pas dans la demi-mesure.

Dans sa plainte déposée vendredi devant le tribunal fédéral du district nord de la Californie, Apple accuse OpenAI d’avoir sollicité des candidats à l’embauche pour qu’ils dévoilent des informations sur des projets confidentiels, allant jusqu’à leur demander d’apporter composants et prototypes lors des entretiens.

L’entreprise va plus loin en affirmant qu’un employé d’OpenAI aurait téléchargé des documents internes depuis un ordinateur portable appartenant à Apple.

Deux noms apparaissent dans la procédure : un ancien cadre du design chez Apple, aujourd’hui responsable matériel chez OpenAI, ainsi qu’un second ex-salarié.

Ni Sam Altman, le patron d’OpenAI, ni Jony Ive, l’ancien chef du design chez Apple qui a rejoint la scaleup après le rachat de son studio pour 6,5 milliards $, ne sont visés personnellement.

Apple ne mâche pas ses mots dans ses écrits juridiques, décrivant l’activité matérielle naissante de son adversaire comme fondée sur des bases juridiquement compromises. Le groupe affirme également que les preuves déjà versées au dossier ne représentent qu’une fraction de ce qu’il détient.

OpenAI dément fermement

Face à ces accusations, OpenAI indique prendre les allégations au sérieux tout en soulignant qu’elle n’a connaissance d’aucune preuve venant étayer la plainte.

Apple affirme avoir alerté OpenAI, dès février dernier, sur ses inquiétudes concernant une possible fuite d’informations confidentielles. Un message qui serait resté sans réponse.

Cette confrontation judiciaire acte la rupture d’une relation autrefois stratégique.

Apple avait signé un accord avec OpenAI en 2024 pour intégrer la technologie de ChatGPT à Siri, son assistant vocal vieillissant. Mais la collaboration a rapidement déçu : OpenAI aurait même envisagé une action en justice face à la manière dont Apple exploitait sa technologie.

En janvier, Apple a tourné la page en officialisant un partenariat avec Google dont les modèles d’IA servent désormais de socle au nouvel assistant façon ChatGPT dévoilé en juin.

Objectif : le hardware grand public

Mais le nerf de la guerre est dans le matériel.

OpenAI, qui a déposé confidentiellement son dossier d’introduction en bourse, prépare une gamme d’appareils grand public pilotés par l’IA.

Le premier produit attendu prendrait la forme d’une sorte d’enceinte connectée dotée de micro et de caméras capables de capter son environnement pour nourrir un assistant personnel exploitant les données de l’utilisateur. Même avant l’ouverture du contentieux avec Apple, la commercialisation n’était pas prévue avant l’année prochaine.

L’ampleur du transfert de compétences entre les deux entreprises est siginificative. Plus de 400 anciens salariés d’Apple travaillent aujourd’hui pour OpenAI, dont Tang Tan qui il a piloté la conception de l’iPhone et de l’Apple Watch, devenu directeur du matériel chez OpenAI.

Apple va jusqu’à l’accuser d’avoir formé ses recrues à contourner les procédures de sécurité internes lors de leur départ.

Un autre ancien salarié, Chang Liu, est accusé d’avoir utilisé l’ordinateur professionnel d’une ex-collègue pour accéder à des documents techniques et de lui avoir indiqué quelles informations sur des produits non annoncés étudier avant ses entretiens d’embauche chez OpenAI.

Ce n’est pas la première fois que Apple use des tribunaux pour protéger ses secrets. En 2019, il avait attaqué Gerard Williams III, son ancien architecte en chef des puces parti fonder la startup Nuvia. Avant de finalement abandonner les poursuites en 2023.

Apple réclame désormais une injonction empêchant OpenAI de détenir, utiliser ou partager ses secrets commerciaux, ainsi que la restitution de sa propriété intellectuelle.

De quoi peser lourdement sur le calendrier d’introduction en bourse d’OpenAI dont la valorisation dépendra aussi de la crédibilité de son virage matériel.

The post Pourquoi Apple s’en prend à ses ex salariés partis chez OpenAI appeared first on Silicon.fr.

La tendance se confirme : Washington n’hésite plus à poser son droit de veto sur la diffusion de modèles d’IA.

Dernier concerné : GPT-5.6. Le voilà lancé en preview… mais seulement auprès d’un « groupe de partenaires de confiance » que la Maison Blanche a approuvés au cas par cas.

OpenAI table sur une diffusion plus large « dans les prochaines semaines ».  Il espère surtout un autre cadre pour mettre à disposition ses futurs modèles. La méthode actuelle « ne doit pas devenir le processus par défaut », affirme-t-il.

OpenAI tempère le niveau de risque de GPT-5.6

La famille GPT-5.6 comprend trois modèles :

• Sol, le plus puissant, avec un nouveau mode de raisonnement max et un mode ultra qui lance des sous-agents
• Terra, « équilibré pour le travail quotidien », dit au niveau de GPT-5.5 tout en étant « deux fois moins cher »
• Luna, « plus rapide et plus abordable »

OpenAI assure que sur ExploitBench, GPT-5.6 Sol rivalise avec Claude Mythos Preview tout en produisant 3 fois moins de tokens. L’entreprise déclare surtout que le modèle ne dépasse pas les seuils critiques de risque cyber qu’elle a définis dans son Preparedness Framework. Il a bien identifié des bugs dans Chromium et Firefox, mais n’a « pas produit, de manière autonome, une chaîne d’exploitation fonctionnelle complète ».

OpenAI reconnaît toutefois sobrement que les benchmarks ne sont pas à même de refléter tous les usages potentiels d’un modèle. Une manière de justifier la période de preview, qui servira à mettre l’épreuve les garde-fous intégrés à GPT-5.6…

Anthropic conteste le jailbreak qui aurait convaincu Washington

Claude Mythos 5 et Fable 5 avaient été les premiers visés. Le 12 juin, Washington les avait soumis au contrôle des exportations. Anthropic devait couper l’accès pour tout le monde, hormis les citoyens des États-Unis.

Pour s’assurer de respecter cette obligation, l’entreprise a préféré débrancher complètement ses modèles. Elle explique que l’administration Trump a invoqué des motifs de sécurité nationale, sans donner de détails.

Le déclencheur semble avoir été la communication d’une méthode de jailbreak – possiblement par Amazon. Selon Anthropic, cette méthode « paraît relativement simple », d’autant plus que d’autres modèles accessibles au public – comme GPT-5.5 – permettent par défaut de l’exploiter. Dans les grandes lignes, elle consiste à demander au modèle de corriger les vulnérabilités logicielles dans une codebase spécifique. Une capacité « déjà utilisée au quotidien » pour la cyberdéfense, constate-t-il.

Le gouvernement fédéral se sera aussi probablement rappelé que quelques semaines en amont, un acteur des télécoms « lié à la Chine » avait obtenu le droit d’expérimenter Claude Mythos Preview (Anthropic avait fini par lui retirer l’accès).

Claude Mythos 5 et GPT-5.6 finalement soumis au même traitement

Entre autres réponses à cette initiative, il y eut une lettre ouverte « Free Fable », sous l’impulsion d’Alex Stamos, ancien CTO de Facebook. Elle a réuni environ 200 signataires des sphères industrielle et académique. Y est défendue l’idée que des modèles comme Fable et Mythos sont essentiels pour la cyberdéfense. Et que le fameux jailbreak relève en fait d’une capacité nécessaire pour tout modèle dont on attend qu’il produise du code sécurisé. En ce sens, il serait erroné d’y voir une capacité offensive. D’autant plus qu’elle est reproductible sur quantité de modèles, « même chinois, comme Kimi 2.7 ».

Alex Stamos brandit un autre épouvantail : les labos américains n’auraient pas tant d’avance sur leurs homologues chinois. Lesquels ont « probablement accès à plus de capacités » que les informations publiques ne le suggèrent…

Le 26 juin, Washington a finalement mis Claude Mythos 5 au même régime que GPT-5.6. Anthropic a eu la permission de l’ouvrir, en preview, à des organisations triées sur le volet. Pas de nouvelles, en revanche, pour Fable.

La Maison Blanche se donne un droit de regard sur les modèles en développement

Début juin, Donald Trump a signé un décret relatif au déploiement et à la sécurité de l’IA. Il impose, entre autres, de développer sous 60 jours une procédure classifiée pour évaluer les « capacités cyber avancées » des modèles d’IA. Et, de là, déterminer un seuil à partir duquel s’enclencherait une collaboration « sur la base du volontariat ». Les développeurs des modèles concernés auraient en l’occurrence la possibilité de :

• Discuter avec le gouvernement fédéral pour déterminer si des modèles en cours de développement atteignent ledit seuil
• Lui donner un accès à ces modèles jusqu’à 30 jours avant la date de publication prévue
• Définir ensemble des « partenaires de confiance » pouvant bénéficier d’un accès anticipé

L’administration américaine a pris des pincettes en précisant que le décret ne crée aucunement un système de licence ou de préautorisation gouvernementale obligatoire pour développer, publier ou distribuer des modèles…

Joe Biden avait voulu contrôler l’exportation des poids de « modèles avancés »

Traditionnellement, le contrôle des exportations s’est appliqué à des biens matériels. Avec le temps, il s’est étendu aux logiciels, aux codes sources, aux données, etc.

En janvier 2025, à quelques jours de la fin de son mandat, Joe Biden avait signé un décret qui devait inclure, dans le contrôle des exportations, les poids de « certains modèles avancés » à double usage potentiel. L’exclusion aurait été totale pour Chine, Russie et Corée du Nord. Une licence serait nécessaire dans tous les autres pays, à l’exception d’une vingtaine dont la France.

L’administration Trump a annulé le décret en mai, juste avant qu’il prenne effet.

Illustration

The post Après Claude Mythos, le « déclic » préoccupant de l’administration US appeared first on Silicon.fr.

Stargate ou pas, le plus important est de sécuriser de la capacité de calcul.

Cette inflexion est perceptible dans la stratégie d’OpenAI. La coentreprise, lancée en grande pompe début 2025 avec la bénédiction de Washington, n’est pas remise en cause. Mais la réponse aux besoins en compute passe moins systématiquement par des projets de construction de datacenters.

Contretemps et revirements pour la vitrine texane de Stargate

Stargate est censé fédérer 500 Md$ de financements sur 4 ans afin de créer une infrastructure d’IA pour OpenAI. Oracle, SoftBank et le fonds souverain émirati MGX s’y sont associés. Arm, Microsoft et NVIDIA sont partenaires technologiques.

La vitrine de l’initiative est un campus de datacenters à Abilene (Texas). Sur place, les travaux avaient démarré dès juillet 2024, sous la houlette de la société d’infrastructure Crusoe. Il était alors question d’atteindre, à terme, 1,2 GW de puissance informatique sur une dizaine de bâtiments.

Aux dernières nouvelles, moins de 300 MW sont opérationnels. L’essentiel l’est depuis septembre 2025 (Oracle avait livré les premiers racks GB200 au mois de juin). Il existait un projet d’extension à 2,1 GW. Mais début 2026, OpenAI et Oracle ont décidé de ne pas le poursuivre. En toile de fond, des difficultés de financement, du retard dans le raccordement du réseau électrique… et donc, plus globalement, une certaine prise de distance vis-à-vis du totem Stargate* ; a fortiori dans la perspective de l’IPO, qui pousse à rationaliser les dépenses. Microsoft a finalement « récupéré » cette tranche de 900 MW.

Réduction de voilure à l’international

En mai 2025, Stargate avait commencé à essaimer à l’international. OpenAI avait officialisé un projet aux Émirats arabes unis, avec la holding G42. Il s’agissait de déployer pour 1 GW à Abu Dhabi, dont 200 MW qui seraient opérationnels en 2026.

En juillet 2025, on nous avait annoncé une deuxième initiative hors des USA. En Norvège, en l’occurrence, avec l’entreprise britannique Nscale. Objectif : 500 MW. Avec 100 000 GPU pour commencer et potentiellement 250 000 à terme.
OpenAI n’a finalement pas trouvé d’accord pour exploiter l’ensemble de la capacité. Microsoft a pris le relais pour environ 30 000 GPU.

Le projet Stargate UK, lancé en septembre 2025 également avec Nscale, a carrément été mis en pause au printemps 2026. Officiellement, au nom des prix de l’énergie que d’une réglementation jugée trop restrictive. OpenAI avait dit envisager un contrat d’achat allant jusqu’à 31 000 GPU.

Du Michigan au Nouveau-Mexique, des campus Stargate… en puissance

Le Texas accueillie deux autres projets placés sous la bannière Stargate. L’un est situé à une vingtaine de kilomètres du flagship d’Abilene. Annoncé en août 2025, il est développé par Vantage Data Centers. Objectif : 1,4 GW de puissance IT sur 10 datacenters – le premier devant être livré au S2 2026. SoftBank fournira les puces. Même chose pour l’autre projet, localisé à Burligton. Sa filiale SB Energy assure la construction. La phase 1 doit se terminer en octobre 2026. Objectif : 1,2 GW.

En septembre 2025 fut annoncé un autre site Stargate, dit Project Jupiter. Localisé à Santa Teresa (Nouveau-Mexique), il est censé atteindre 2 GW. Blue Owl en est le principal financeur, avec un premier investissement de 50 Md$ sur 5 ans. STACK Infrastructure assure la construction. Le projet a fait l’objet de poursuites judiciaires pour l’opacité de la procédure d’autorisation.

Les deux dernières annonces de campus Stargate remontent à octobre 2025.
Un projet, baptisé The Barn, se trouve à Benton (Michigan). Related Digital assure la construction. Les premiers bâtiments devraient être opérationnels début 2027. Capacité visée : 1,4 GW, Oracle devant acquérir les puces.
L’autre projet, appelé Lighthouse, est confié à Vantage Data Centers. Avec, là aussi, Oracle pour fournir les puces. Sa construction doit démarrer en 2028. Capacité visée : 900 MW sur 4 datacenters.

Des gigawatts hors du périmètre Stargate

SB Energy construit actuellement, dans l’Ohio, un datacenter hors du périmètre Stargate. OpenAI y ciblerait 10 GW de capacité de calcul, sur du NVIDIA. Il faudrait attendre 2028 pour qu’une première tranche de 800 MW entre en fonction.

Toujours dans l’Ohio, OpenAI cherche aussi à louer des ressources sur le campus Fairwater de Mount Pleasant. Microsoft vient d’en achever la construction avec Vantage Data Centers, deux ans après avoir annoncé le projet.

Instinct, Trainium, Jalapeño… OpenAI voit au-delà de NVIDIA

En septembre 2025, OpenAI s’était engagé à déployer au moins 10 GW supplémentaires de GPU NVIDIA. À commencer, au S2 2026, par 1 GW de Vera Rubin. NVIDIA avait annoncé, en retour, son intention d’investir jusqu’à 100 Md$ dans OpenAI.

En octobre avait suivi un accord avec AMD pour déployer jusqu’à 6 GW de GPU Instinct. Première étape : 1 GW en MI450 au S2 2026. En retour, AMD lui a donné la possibilité de monter à 10 % de son capital, à des conditions préférentielles.

En novembre, OpenAI avait signé, avec Amazon, un accord à 38 Md$ sur 7 ans, axé essentiellement sur l’usage de GB200 et GB300 via les UltraServers EC2. Début 2026, il y avait ajouté 100 Md$, échelonnés sur 8 ans. Cela comprenait un engagement à exploiter environ 2 GW en puces Trainium, via l’infra AWS.

En parallèle, OpenAI a travaillé à concevoir ses propres puces, avec Broadcom. Premier fruit de cette collaboration : l’ASIC Jalapeño, dédié à l’inférence. Pas encore massivement déployé, il porte néanmoins déjà quelques workloads, notamment avec GPT-5.3-Codex-Spark.

OpenAI et Broadcom avaient officialisé leur partenariat en octobre 2025. Elle s’assortissait de l’ambition de déployer, à l’horizon 2029, 10 GW d’accélérateurs. Greg Brockman avait alors expliqué que la collaboration entre les deux entreprises durait depuis 18 mois.

* Plusieurs pontes de l’initiative Stargate sont d’ailleurs partis chez Meta en début d’année.

Illustration générée par IA

The post Jalapeño plutôt que Stargate : OpenAI a revu ses priorités appeared first on Silicon.fr.

The post { VivaTech 2026 } – L’Oréal choisit OpenAI pour ses projets IA appeared first on Silicon.fr.

C’est à l’occasion de son évènement annuel, à San Francisco, que Visa a annoncé un accord avec OpenAI pour permettre des paiements sécurisés au sein du commerce dit « agentique » ; ces environnements où des agents IA agissent de façon autonome pour le compte des utilisateurs.

Concrètement, les achats réalisés via ChatGPT ou d’autres interfaces OpenAI pourront  s’appuyer sur le réseau Visa. Les transactions s’effectueront dans le cadre de permissions, de politiques et de contrôles définis par l’utilisateur comme les plafonds de dépenses, les catégories de marchands autorisées ou les approbations obligatoires. Elles utiliseront des « identifiants Visa tokenisés », assortis d’une autorisation en temps réel et d’une surveillance anti-fraude.

Une ambition qui dépasse le seul paiement

Au-delà de la transaction pure, les deux acteurs explorent une gamme d’applications pour les entreprises, notamment des expériences orientées développeurs alimentées par Codex, l’assistant de codage d’OpenAI, ainsi que des flux de travail plus automatisés et conversationnels.

Le tout s’inscrit dans l’initiative Visa Intelligent Commerce, le programme du groupe visant à étendre ses capacités de paiement sécurisé aux nouveaux environnements numériques.

Pour Jack Forestell, directeur produit et stratégie de Visa, l’enjeu est historique : « L’IA transformera le commerce plus profondément qu’Internet ou le mobile ne l’ont jamais fait. »

Cet a intervient alors qu’OpenAI a déposé confidentiellement un dossier d’introduction en Bourse.

The post Commerce agentique : OpenAI signe avec Visa appeared first on Silicon.fr.

C’est officiel. OpenAI a déposé confidentiellement son document S-1 auprès de la Securities and Exchange Commission (SEC), le gendarme américain des marchés financiers.

Une annonce faite via un communiqué laconique, mais dont les implications financières pourraient être vertigineuses.

La manière do en dit long sur l’état d’esprit de l’invneteur de ChatGPT. « Nous nous attendons à ce que ça fuite, alors nous l’annonçons nous-mêmes », écrit-il sans détour dans son communiqué officiel.

Pour autant, Sam Altman et ses équipes restent prudents sur le calendrier. « Il se peut que ce soit dans un moment, car il y a des choses que nous voulons faire qui sont vraisemblablement plus faciles en tant qu’entreprise privée », précise le communiqué.

Une introduction en Bourse dès le quatrième trimestre 2026 reste néanmoins dans les tuyaux, selon plusieurs sources citées par Reuters et CNBC.

1 000 milliards de dollars

OpenAI vise une valorisation qui pourrait atteindre 1 000 milliards $ ; soit le PIB de la Suisse en 2025. Pour mémoire, la dernière levée de fonds de l’entreprise, bouclée en mars dernier auprès d’Amazon, Nvidia et SoftBank notamment, avait valorisé la société à 852 milliards $ après avoir levé 122 milliards $ ; le plus grand tour de table de l’histoire de la Silicon Valley.

Mais c’est une course à trois qui se dessine sur Wall Street et l’enjeu dépasse la simple performance financière.

SpaceX d’Elon Musk a ouvert la voie avec l’ambition de lever 75 milliards $ pour une valorisation de 1 750 milliards $, ce qui en ferait la plus grande introduction en Bourse de l’histoire.

Mais c’est surtout Anthropic, le rival le plus direct d’OpenAI sur le marché des entreprises, qui aiguise les appétits. Elle a annoncé le 1er juin son propre dépôt confidentiel quelques semaines après avoir bouclé une levée de fonds de 65 milliards $ la valorisant à 965 milliards $,  dépassant pour la première fois OpenAI sur le marché privé.

Les banquiers auraient conseillé aux deux rivaux que celui qui entre en Bourse en premier bénéficiera d’un avantage décisif pour capter les capitaux des investisseurs.

Les ombres au tableau

Pourtant, l’introduction en Bourse n’est pas sans risques. OpenAI a admis auprès de ses investisseurs qu’elle ne devrait pas atteindre la rentabilité avant 2030.

Pis, selon le Wall Street Journal, l’entreprise brûlerait des liquidités à un rythme qui dépasserait celui de toute autre société cotée dans l’histoire. La course aux supercalculateurs et aux capacités d’entraînement des modèles d’IA coûte extrêmement cher, sans garantie de retour sur investissement à court terme.

Malgré tout, Sam Altman, dans un billet de blog, tente de donner à cet acte boursier une portée civilisationnelle. Il y décrit l’entrée dans une « troisième phase » pour OpenAI.

Après la recherche, après le produit, vient désormais «la transformation de l’économie par l’IA ».

Ambitieux et bankable.

The post OpenAI lance sa course à l’IPO appeared first on Silicon.fr.

Il aura fallu moins de deux heures aux neuf jurés d’Oakland, le 18 mai, pour trancher l’un des procès les plus scrutés de la Silicon Valley.

La plainte déposée par Elon Musk contre OpenAI et son directeur général Sam Altman a été rejetée. Non pas sur le fond, mais parce que l’homme le plus riche du monde avait tout simplement attendu trop longtemps avant d’agir. La prescription, ce mécanisme juridique aussi banal qu’implacable, aura eu raison de l’offensive du patron de Tesla et de SpaceX.

Tout ça pour ça serait-on tenter de dire…

Une victoire sur la forme, un chaos sur le fond

Pour OpenAI, le soulagement est immense. Elon Musk réclamait quelque 134 milliards $ de dommages et intérêts, l’éviction d’Altman et de son co-fondateur Greg Brockman ainsi que l’annulation de la transformation de l’organisation à but non lucratif en entreprise commerciale. Un scénario catastrophe qui aurait mis en péril l’introduction en Bourse, désormais envisagée à une valorisation d’environ 1 000 milliards $.

« Ce verdict technique met peut-être un terme à la bataille judiciaire entre Musk et Altman, mais nous verrons probablement un contrôle continu sur la question de savoir si OpenAI remplit ses obligations à but non lucratif », prévient Jill Horwitz, professeure à la Northwestern University Pritzker School of Law, citée par le Financial Times.

Une mise en garde qui résume bien l’ambivalence du moment. Si OpenAI gagne la bataille, mais la guerre d’image, elle, est loin d’être terminée. Et Sam Altman y a laissé des plumes

Des bleus, il y en a eu. Durant le procès, l’avocat de Elon Musk a cité pas moins de huit témoins  (dont Musk lui-même) affirmant que Sam Altman avait induit en erreur ou menti à ses interlocuteurs.

Parmi les témoignages les plus dévastateurs, celui de l’ancienne directrice technique Mira Murati. Interrogée sur l’honnêteté de Sam Altman, elle a marqué une longue pause avant de répondre : « Pas toujours.» Et d’ajouter qu’il avait sapé son travail et monté les dirigeants d’OpenAI les uns contre les autres.

Sam Altman : vainqueur juridique, réputation fragilisée

Des documents internes ont également révélé qu’il détenait des participations de plusieurs milliards de dollars dans des entreprises travaillant avec OpenAI, soulevant des questions de conflits d’intérêts. Le PDG a affirmé s’être recusé lors des négociations concernées.

Du côté d’Elon Musk, la défaite juridique est nette mais il a immédiatement annoncé son intention de faire appel  au motif que « créer un précédent permettant de piller des œuvres caritatives est incroyablement destructeur pour la philanthropie en Amérique.»

Regarding the OpenAI case, the judge & jury never actually ruled on the merits of the case, just on a calendar technicality.

There is no question to anyone following the case in detail that Altman & Brockman did in fact enrich themselves by stealing a charity. The only question…

— Elon Musk (@elonmusk) May 18, 2026

Une posture qui illustre parfaitement sa stratégie : transformer un échec judiciaire en victoire narrative. Le procès a révélé en détail comment le petit laboratoire de recherche à but non lucratif s’est transformé en une entité commerciale valorisée à 852 milliards $, avec le soutien de certaines des plus grandes entreprises mondiales. Des révélations que Elon Musk, qui avait donné 38 millions $ à l’organisation originelle, a su exploiter au maximum.

The post Procès OpenAI : Elon Musk perd mais Sam Altman ne sort pas indemne appeared first on Silicon.fr.