L’ANSSI publie un troisième kit sectoriel d’exercice de crise cyber, pour l’agroalimentaire. Mais anticiper un scénario écrit ne garantit pas nécessairement de s’en sortir face à un imprévu.

Une pédagogie qui a fait ses preuves depuis plusieurs années

Un scénario écrit qui s’arrête où commence l’imprévu

Une frontière sépare l’entraînement de la préparation réelle

Un enjeu qui se joue avant la crise, dans la gouvernance quotidienne

Des repères qui distinguent les organisations les mieux préparées

The post Une procédure de crise s’apprend vite, une organisation résiliente se construit lentement appeared first on Silicon.fr.

Les entreprises déploient leurs premiers agents et découvrent aussi comment gouverner les interactions entre les modèles, les applications et les données ?

Une nouvelle catégorie de logiciels, les AI Gateways, ambitionne de devenir le point de contrôle de ces architectures. À l’image des API Gateways il y a vingt ans, cette couche pourrait redéfinir la manière dont les DSI construiront leurs infrastructures d’intelligence artificielle. A condition qu’elle tienne ses promesses.

L’histoire des systèmes d’information est jalonnée de ruptures technologiques qui ont progressivement fait apparaître de nouvelles couches d’infrastructure.

Au début des années 1990, la priorité était de connecter les réseaux tout en les protégeant : les pare-feu sont devenus le point de passage obligé entre l’entreprise et Internet.

Au début des années 2000, la généralisation des architectures orientées services puis des microservices a fait émerger une autre nécessité : contrôler les échanges entre applications. Les API Gateway se sont imposées pour authentifier les appels, appliquer des politiques de sécurité et fournir une visibilité centralisée.

Une décennie plus tard, l’explosion du cloud a donné naissance aux plateformes IAM modernes, aux CASB (Cloud Access Security Broker) aux solutions SASE et aux plateformes CNAPP (Cloud-Native Application Protection Platform, des outils de sécurisation des applications cloud) pour répondre à de nouveaux besoins de gouvernance.

L’IA générative semble suivre le même chemin. Après une première phase centrée sur le choix d’un modèle de langage performant, les entreprises découvrent qu’elles doivent désormais administrer un écosystème où plusieurs modèles coexistent, où des agents IA prennent des décisions, et où les interactions avec le système d’information deviennent plus nombreuses et plus dynamiques.

Du mono-modèle au multi-modèle

Entre 2023 et 2024, la plupart des expérimentations reposaient sur un seul fournisseur : une application appelait un modèle via une API, point final. Cette architecture reste simple.

En 2026, le changement d’échelle est net. Selon une analyse de Vercel portant sur les usages en production, la part des équipes exploitant cinq modèles ou plus est passée de 29 % à 37 % en un an. Un basculement structurel plutôt qu’un ajustement marginal.

Un assistant bureautique peut désormais mobiliser un modèle propriétaire pour la génération de texte, un modèle open source exécuté localement pour des traitements confidentiels, un modèle spécialisé pour l’analyse documentaire et un moteur multimodal pour l’image ou la vidéo.

Cette diversification répond à trois logiques :

• Économique : les tarifs varient fortement d’un fournisseur à l’autre, et le « race to the bottom » sur le prix au token pousse les DSI à arbitrer plutôt qu’à dépendre d’un seul acteur. Plusieurs gateways commerciales (Vercel, OpenRouter, Cloudflare, LiteLLM) ont d’ailleurs supprimé toute marge sur les tokens en 2026, déplaçant la concurrence vers la fiabilité et la gouvernance.
• Réglementaire : avec l’entrée en application progressive de l’AI Act, certaines entreprises veulent conserver la maîtrise de traitements sensibles ou privilégier des fournisseurs offrant davantage de garanties sur la localisation des données.
• Fiabilité opérationnelle : les incidents chez les grands fournisseurs de modèles ne sont plus anecdotiques. Selon des données citées par Vercel, les principaux fournisseurs de LLM ont chacun cumulé une vingtaine d’incidents et près de 180 heures d’indisponibilité sur le seul mois de décembre 2025. Un argument concret en faveur du multi-fournisseur et du failover automatique.

Cette évolution fait apparaître une difficulté nouvelle : comment administrer un environnement où plusieurs modèles sont utilisés simultanément par des centaines d’applications, sans multiplier les clés d’API et les intégrations ad hoc ?

Les agents IA changent la nature du système d’information

La généralisation des agents constitue un second facteur de rupture.

Un chatbot traditionnel répond à une question. Un agent peut planifier une série d’actions : consulter une base documentaire, interroger un ERP, créer un ticket dans un outil ITSM, envoyer un courriel, puis transmettre le résultat à un autre agent. Il ne produit plus seulement une réponse : il agit.

Pour les équipes d’architecture, cela change la nature des flux. Les échanges ne s’effectuent plus uniquement entre applications connues : ils impliquent des composants capables de choisir eux-mêmes quels outils utiliser selon le contexte.

Le protocole MCP (Model Context Protocol), qui standardise la façon dont un modèle accède à des outils externes et structure une bonne partie de ces échanges. Cependant, son adoption rapide crée aussi une nouvelle surface d’exposition, puisque chaque connecteur MCP est potentiellement une porte d’entrée vers un système interne.

Dans de nombreuses entreprises, chaque application dialogue encore directement avec le modèle retenu par son équipe de développement. Cette approche fonctionne tant que les projets restent peu nombreux mais elle devient difficile à maintenir dès que plusieurs dizaines d’applications utilisent plusieurs fournisseurs. Chaque équipe doit alors gérer séparément les clés d’API, les politiques de sécurité, les limites de consommation, la journalisation, les changements de version des modèles et les règles de conformité propres à chaque fournisseur.

Plus le nombre d’agents augmente, plus le nombre d’interactions explose, avec un risque bien connu : la multiplication incontrôlée de connexions point à point, que l’histoire des systèmes d’information a déjà vu se reproduire à chaque rupture technologique.

Une nouvelle couche apparaît : l’AI Gateway

Concrètement, une AI Gateway se place comme un proxy entre les applications et les fournisseurs de modèles (OpenAI, Anthropic, Google, Azure, modèles open source auto-hébergés).

Elle expose un point d’entrée unique et ajoute, selon les offres, du routage multi-modèle, du failover automatique en cas de panne d’un fournisseur, du cache sémantique pour réduire coûts et latence sur des requêtes similaires, des quotas et budgets par équipe ou par utilisateur, de la journalisation au niveau du token, ainsi que des fonctions de sécurité comme le masquage de données personnelles ou la détection de tentatives d’injection de prompt.

Le marché s’est structuré très vite en 2026, avec des positionnements différenciés :

Cette diversité montre que le terme « AI Gateway » recouvre encore des réalités différentes selon l’éditeur : certains sont d’abord des routeurs de coûts, d’autres des plateformes de gouvernance, d’autres des extensions d’API Gateway existantes.

Ce qu’en disent les analystes

Gartner a publié en 2025 et 2026 plusieurs travaux dédiés (Market Guide for AI Gateways et  Market Overview actualisé en 2026) qui positionnent cette couche comme un composant des futures architectures d’IA d’entreprise, chargé de gérer les connexions vers les services d’IA, d’appliquer des politiques de sécurité, de répartir les requêtes entre plusieurs modèles et d’améliorer la visibilité sur les coûts.

Le cabinet inscrit plus largement l’AI Gateway dans son cadre AI TRiSM (Trust, Risk and Security Management), dont il estimait le marché à environ 3,1 milliards $en 2025, avec une croissance annuelle projetée de l’ordre de 35 % jusqu’en 2030. Un chiffre à prendre comme un ordre de grandeur d’analyste plutôt qu’une certitude, la firme elle-même révisant régulièrement ses prévisions à mesure que le marché se consolide.

Le NIST AI Risk Management Framework converge sur le fond. Sans employer le terme « AI Gateway », il insiste sur la nécessité de mécanismes de gouvernance, de traçabilité et de surveillance continue tout au long du cycle de vie des systèmes d’IA. Des fonctions qu’une gateway peut techniquement porter, sans que le référentiel ne prescrive cette architecture en particulier.

La Cloud Security Alliance défend une lecture proche, estimant que la gouvernance de l’IA ne peut plus être traitée uniquement au niveau applicatif.

Ce que l’AI Act rend concrètement nécessaire

L’argument réglementaire mérite d’être précisé, car le calendrier a changé courant 2026.

Le paquet Digital Omnibus, adopté définitivement fin juin 2026, a reporté au 2 décembre 2027 la plupart des obligations pesant sur les systèmes à haut risque de l’annexe III (recrutement, crédit, éducation, justice, biométrie). Reste en vigueur au 2 août 2026 l’essentiel des obligations de transparence de l’article 50 : informer les utilisateurs qu’ils interagissent avec une IA, et identifier les contenus générés ou modifiés par IA.

Pour les systèmes qui resteront soumis au régime haut risque, l’article 12 impose une journalisation automatique et infalsifiable des événements, avec une conservation minimale de six mois (vingt-quatre mois pour la biométrie), et l’article 14 exige une supervision humaine effective.

Ce sont précisément les fonctions ( journalisation centralisée, traçabilité au niveau de chaque appel et points de contrôle humain ) qu’une AI Gateway peut industrialiser à l’échelle de dizaines d’applications, plutôt que de les faire reconstruire par chaque équipe projet. Le règlement précise aussi, dans ses considérants 99 et 100, que dans une chaîne d’agents IA, l’obligation de conformité s’étend à chaque agent exécutant une fonction à haut risque. Un argument de poids pour centraliser la gouvernance plutôt que de la disperser.

Le report ne change donc pas la logique de fond : il retire simplement l’urgence à très court terme, sans annuler la nécessité d’anticiper une architecture capable de produire ces preuves de conformité.

Les limites du concept

Cette convergence d’analyses ne doit pas masquer les zones d’incertitude.

Un marché encore jeune et instable. Le rachat de Portkey par Palo Alto Networks, l’incident de sécurité touchant LiteLLM et le nombre élevé d’éditeurs recensés (plus de 160 selon certains annuaires spécialisés) suggèrent une consolidation rapide plutôt qu’un marché mature. Une DSI qui adopte aujourd’hui une gateway prend un pari sur la pérennité de son éditeur.

Un nouveau point de défaillance unique. Concentrer tout le trafic IA sur une seule couche crée mécaniquement un single point of failure : si la gateway tombe, c’est l’ensemble des applications IA de l’entreprise qui s’arrête, même si les modèles sous-jacents fonctionnent normalement.

Une latence ajoutée, mais généralement marginale. Plusieurs comparatifs indépendants estiment le surcoût d’une gateway bien opérée à quelques millisecondes à quelques dizaines de millisecondes. Ceci est négligeable face à un appel de modèle qui dure plusieurs secondes, sauf en cas de mauvaise implémentation.

Une frontière floue avec l’existant. Une partie des fonctions revendiquées (authentification, quotas, logs) peut aussi être portée par une API Gateway classique déjà en place, ce qui pose la question : faut-il une brique dédiée ou une extension de l’infrastructure API existante ? Les offres de type Kong ou Zuplo, qui fusionnent les deux mondes, illustrent que la frontière entre « API Gateway » et « AI Gateway » n’est pas encore stabilisée.

Le risque de gouvernance en façade. Une gateway journalise et contrôle les flux, mais elle ne résout pas à elle seule les causes profondes des incidents d’IA en entreprise. Gartner estime qu’une large majorité des transactions IA non autorisées proviennent de mauvais usages internes plutôt que d’attaques malveillantes. Un problème davantage organisationnel que technique, qu’un outil ne suffit pas à traiter.

Ce que cela signifie pour les DSI

L’histoire des pare-feu, des API Gateway puis des CASB montre que ces couches d’infrastructure, une fois qu’elles s’imposent, deviennent difficiles à retirer.

Pour une DSI qui déploie aujourd’hui plusieurs modèles et commence à expérimenter des agents, la question n’est plus de savoir si une gouvernance centralisée sera nécessaire, mais quand l’introduire et avec quel degré de couplage à l’infrastructure existante.

Un point de départ raisonnable consiste à cartographier les usages IA actuels et à venir, à évaluer si une extension de l’API Gateway déjà en place suffit à court terme, et à ne s’engager sur un éditeur dédié qu’après avoir mesuré son modèle de sécurité, sa pérennité financière et le degré de lock-in qu’il introduit.

Dans un marché qui se consolide aussi vite qu’il grossit, la prudence sur le choix du fournisseur compte au moins autant que la décision d’adopter la brique elle-même.

Sources :
> Gartner (Market Guide for AI Gateways, 2025 ; Market Overview for AI Gateways, 2026 ; Market Guide for AI Trust, Risk and Security Management, 2025
> NIST AI Risk Management Framework 1.0
> Cloud Security Alliance
> Règlement (UE) 2024/1689 (AI Act)
> Paquet Digital Omnibus adopté fin juin 2026 

The post AI Gateway : la prochaine bataille des infrastructures IA appeared first on Silicon.fr.

L’intitulé du poste, lui, ne ressemble à aucune fonction juridique classique : Principal Legal Engineer.

Ni avocat senior, ni ingénieur logiciel, ni chef de projet transformation : un peu des trois à la fois.

Rattaché à l’organisation Corporate, External & Legal Affairs (CELA) de Microsoft, via son entité Customer & Partner Solutions, Le futur recruté travaillera sous la responsabilité du directeur de l’AI Operations, et devra collaborer avec les ingénieurs, les avocats et les équipes opérationnelles du groupe.

Sa fiche de poste ? Concevoir et déployer des agents IA, retravailler les prompts et les workflows juridiques, exploiter à la fois Microsoft 365 Copilot, la plateforme spécialisée Harvey et la Power Platform maison, mesurer l’adoption réelle de ces outils, former les équipes juridiques et garantir la fiabilité de ces systèmes une fois en production. Il s’agit donc bien de construire, pas seulement de superviser.

Le coeur du poste, c’est l’orchestration

En juillet dernier, la legaltech Harvey a en effet annoncé que la CELA de Microsoft (environ 2 000 avocats et professionnels de la conformité) allait déployer sa plateforme pour ses opérations juridiques et de conformité.

La direction juridique de Microsoft fonctionnera donc avec les deux outils : Copilot pour les usages généralistes, intégré à. Microsoft 365, et Harvey pour les tâches à forte exigence métier comme l’analyse de contrats, la recherche juridique, la comparaison de clauses ou le traitement de dossiers complexes.

Le poste inclut la construction d’une couche d’intelligence opérationnelle capable d’agréger des données issues de plusieurs plateformes ( Copilot, Harvey, Power Platform. ) pour suivre en continu l’adoption de l’IA, la productivité générée, l’état de santé des systèmes et les usages émergents. En somme, un centre de pilotage de la donnée d’usage IA appliqué à une fonction juridique entière.

Côté profil, Microsoft exige un diplôme de droit, six ans d’expérience minimum comme avocat ou équivalent, et une habilitation à exercer. Le poste, basé à Redmond avec quatre jours de présence hebdomadaire au bureau, est rémunéré jusqu’à 278 900 dollars par an.

The post Le « Legal Engineer », ce nouveau métier à la frontière du droit et de l’IA que Microsoft recrute appeared first on Silicon.fr.

Des chercheurs de Check Point Research ont identifié un nouvel épisode de l’opération « Dream Job », vaste campagne d’espionnage attribuée au groupe nord-coréen Lazarus.

Cette fois, les cyberattaquants ont combiné une ingénierie sociale particulièrement élaborée à l’exploitation d’une vulnérabilité jusque-là inconnue pour pénétrer les réseaux d’entreprises de la défense et de l’aérospatiale en Europe, en Inde et en Amérique du Sud.

Le mode opératoire repose sur de fausses propositions d’embauche censées émaner de grands noms du secteur, notamment Lockheed Martin et l’entreprise spécialisée dans la protection des données Enveil.

Pour rendre la supercherie crédible, les assaillants sont allés jusqu’à créer plusieurs faux sites imitant celui d’Enveil, certains étant suffisamment bien référencés pour apparaître en haut des résultats de recherche.

Les victimes, pensant télécharger des documents ou logiciels depuis une source légitime trouvée via un moteur de recherche, installaient en réalité le programme malveillant des attaquants. Cette approche rend caducs les réflexes classiques de vigilance, puisque ni le recruteur, ni le site, ni le classement Google ne permettaient de déceler la supercherie.

Une cible géopolitique précise

Une fois le piège refermé, un faux lecteur PDF baptisé « SecurityPDF » servait de porte d’entrée pour déployer discrètement une nouvelle porte dérobée modulaire, surnommée « Troy », capable d’exécuter dix-sept commandes différentes selon les instructions des opérateurs.

Parallèlement, les attaquants ont eu recours à une version mise à jour du rootkit FudModule (3.1), qui exploitait une vulnérabilité jusqu’alors inconnue dans le pilote Windows AFD.sys pour obtenir les droits système les plus élevés et désactiver les outils de détection habituellement déployés par les entreprises.

Cette faille, référencée CVE-2026-68820, a été signalée aux équipes de Microsoft, qui l’ont corrigée dans le cadre de leur mise à jour de sécurité mensuelle du 11 août 2026.

Les secteurs visés touchent notamment aux capteurs de surveillance, aux drones et à la robotique militaire. Plusieurs pays sont concernés, dont la France, l’Allemagne, le Brésil et l’Inde. Cette dernière est particulièrement exposée du fait de l’essor rapide de son industrie de défense et d’aérospatiale.

Une infrastructure de commande discrète

Plutôt que de s’appuyer sur des serveurs dédiés facilement repérables, Lazarus a privilégié le détournement d’installations de messagerie web Roundcube et de plateformes de gestion de contenu compromises, en s’appuyant notamment sur une faille connue (CVE-2025-49113, pour laquelle un correctif existe déjà) et sur des identifiants dérobés circulant sur le dark web.

Un nouveau webshell, nommé « RelayShell », a permis de transformer au moins dix-sept serveurs compromis en relais pour les communications entre les machines infectées et les opérateurs du groupe.

Point particulièrement inquiétant relevé par les chercheurs : une organisation française déjà compromise a ensuite été utilisée comme point de départ pour lancer de nouvelles vagues de phishing ciblé à travers le monde, en s’appuyant sur sa réputation pour crédibiliser les nouveaux messages piégés. Une intrusion réussie peut ainsi servir de tremplin à d’autres attaques, bien au-delà de la victime initiale.

Pour Sergey Shykevich, responsable du renseignement sur les menaces chez Check Point Software, le plus inquiétant dans cette campagne n’est pas tant la faille zero-day exploitée que la capacité des attaquants à s’appuyer sur des signaux de confiance habituellement fiables : un bon classement dans les résultats de recherche, l’apparence de marques reconnues, ou encore la réputation d’organisations déjà compromises.

The post Comment Lazarus détourne des offres d’emploi pour infiltrer l’industrie de la défense appeared first on Silicon.fr.

Les gains de productivité que permet l’IA bousculent un pilier historique du secteur des services numériques : la facturation au temps passé.

Le basculement vers des contrats fondés sur les résultats n’est plus une option marketing, mais une nécessité économique. C’est le constat posé lors du premier Forum des ESN & ICT organisé par Numeum en juin dernnier. Plus de 60 dirigeants du secteur s’y sont retrouvés pour débattre des nouveaux modèles de consommation des services numériques à l’ère du cloud et de l’IA ?

« Pendant des années, les ESN ont vendu du temps, des profils, des « man-days ». Mais aujourd’hui, les clients n’achètent plus du temps… ils achètent des résultats. Et c’est là que l’IA change tout », résume Charles Mauclair, président du Collège ESN/ICT de Numeum.

Concrètement, cette trajectoire distingue trois logiques de consommation : l’achat de licences et d’infrastructures (possession), la consommation de capacités cloud et de services managés (usage), et enfin l’achat de résultats mesurables comme les gains de productivité et lescapacités opérationnelles (valeur).

Les modèles de régie au TJM (Taux Journalier Moyen), encore dominants, se retrouvent de plus en plus concurrencés par des engagements construits autour de la performance ou du partage des gains.

L’IA, premier moteur de croissance… et de tension

L’étude « Grand Angle ESN & ICT 2025 », publiée par Numeum et KPMG en octobre 2025, illustre l’ampleur du phénomène.

L’IA générative arrive en tête des opportunités de marché identifiées par 81% des ESN et ICT interrogées, devant la transformation digitale (58%) et la cybersécurité (56%). Sur le terrain, 72% des entreprises du secteur utilisent déjà l’IA dans leurs processus de delivery, et 67% dans leurs fonctions administratives.

Les gains de productivité mesurés sont significatifs : 12,5% en 2025 chez les éditeurs, avec une progression anticipée à 17% en 2026. Chez les ESN, la trajectoire est encore plus marquée, avec des gains qui devraient passer de 15% à 22,3% entre 2025 et 2027.

Mais cette productivité accrue se retourne partiellement contre le modèle économique historique du secteur. « L’IA augmente la productivité des équipes, mais met sous pression les modèles basés sur le volume de travail humain », relève Numeum dans son analyse de conjoncture.

Le syndicat cite un chiffre qui inquiète les directions d’ESN : 22% des DSI estiment déjà que l’IA agentique pourrait réduire certaines de leurs dépenses logicielles, avec un effet d’entraînement potentiel sur les revenus des prestataires.

« L’équation économique est sous tension », admet Charles Mauclair. « Les ESN doivent transformer leur offre pour rester pertinentes : passer de la vente de temps à la création de valeur augmentée. »

Trois trajectoires de transformation se dessinent : le pivot vers des modèles hybrides associant expertise humaine et agents IA, le développement de nouvelles activités à forte valeur ajoutée (design et orchestration d’agents, gouvernance, intégration aux processus métiers) et la recomposition des contrats autour des résultats obtenus plutôt que du temps facturé.

Des contrats qui glissent du TJM vers l’outcome-based

Cette recomposition contractuelle se traduit déjà très concrètement dans les négociations et les appels d’offres.

Trois mécanismes reviennent régulièrement. D’abord des engagements de productivité assortis de pénalités ou de bonus. Ensuite, un pricing indexé sur les économies réalisées et les revenus additionnels générés. Enfin, sur des dispositifs de gain-sharing où le prestataire et le client se partagent les économies issues de l’IA.

« Les clients n’achètent plus du temps… ils achètent des résultats », martèle Charles Mauclair. Les ESN qui continueront de vendre du temps risquent une compression durable de leurs marges.

Le marché français fournit plusieurs illustrations de cette bascule.

BNP Paribas a renouvelé pour trois ans son accord-cadre avec Mistral AI, en étendant les cas d’usage d’IA générative et agentique à des processus critiques du groupe. La Caisse des Dépôts a signé, avec Sopra Steria, Computacenter et Mistral AI, un accord-cadre de 140 millions € sur quatre ans portant sur le déploiement de 40 000 licences d’IA générative, au bénéfice d’environ 100 000 utilisateurs. Chez TP (ex-Teleperformance), environ 7% du chiffre d’affaires provient désormais de contrats de type « revenue-as-a-service », indexés sur des résultats tels que la génération de revenus, la rétention client ou les économies réalisées.

Autant d’exemples qui montrent que les grands comptes français ont déjà engagé leurs prestataires dans une logique de valeur, et non plus de simple effort fourni.

Vendre des capacités augmentées, pas des profils

Pour Numeum, la transformation implique aussi une refonte de l’offre elle-même. Dans l’étude Grand Angle, 63% des répondants déclarent avoir créé de nouvelles offres fondées sur l’IA, 58% constatent une accélération de leurs cycles de delivery, et 54% se disent capables de répondre plus rapidement aux appels d’offres grâce à l’IA.

« Il ne s’agit plus de vendre des profils, mais de vendre des capacités opérationnelles augmentées par l’IA », résume Charles Mauclair.

Cette mutation ne se fera pas sans efforts. Numeum pointe trois enjeux prioritaires.

D’abord la formation. Une étude EY–Syntec Conseil citée par le syndicat montre que 66% des entreprises qui réussissent leur adoption de l’IA à l’échelle départementale ont investi dans un programme de formation structuré, contre moins de 20% chez celles qui échouent.

Ensuite la gouvernance, avec un accent mis sur la sécurité des données et la conformité réglementaire (AI Act, DORA, RGPD). Enfin la souveraineté  avec  le recours à des solutions d’IA françaises ou européennes.

« L’IA n’est pas une menace pour les ESN, c’est une opportunité de se réinventer », conclut Charles Mauclair.

A condition que cette réinvention touche à la fois les offres, les compétences et les contrats.

The post Services IT : comment l’IA fait évoluer les contrats de prestation appeared first on Silicon.fr.

Microsoft s’apprête  à retirer la version « licences incluses » de son service Azure VMware Solution (AVS). C’était l’une des toutes dernières solutions permettant d’acquérir des produits VMware en dehors des offres groupées imposées par Broadcom.

Jusqu’à présent, AVS représentait une alternative de choix pour les organisations souhaitant conserver leurs environnements VMware dans le cloud sans avoir à basculer vers VMware Cloud Foundation (VCF), la grande suite cloud hybride de Broadcom.

L’offre cloud de Microsoft comprenait ainsi les licences pour vCenter, vSAN, vSphere et NSX, mais n’intégrait pas le Software-Defined Datacenter Manager, l’outil utilisé par Broadcom pour centraliser la gestion de son offre phare VCF.

« Bring Your Own License » (BYOL), la nouvelle norme

D’autres géants du cloud avaient d’ailleurs déjà dû s’adapter à cette exigence, annoncée par Broadcom à la fin de l’année dernière.

The post Microsoft met fin à son offre Azure VMware Solution avec licences incluses appeared first on Silicon.fr.

Stripe élargit son terrain de jeu.  Après avoir optimisé les flux financiers, le spécialiste des paiements s’attaque à leur consommation d’IA.

Avec l’acquisition d’OpenRouter, il veut agir au cœur de la machine pour router les requêtes, optimiser les tokens et surtout faire baisser la facture des modèles.

Le métier d’OpenRouter consiste à faire abstraction de la multiplication des modèles et des fournisseurs d’IA. Au lieu d’intégrer séparément les API d’OpenAI, Anthropic, Google, Meta ou d’autres fournisseurs, un développeur peut passer par une seule interface.

La plateforme peut ensuite déterminer vers quel modèle acheminer une requête en fonction de plusieurs paramètres : prix, vitesse, disponibilité, fiabilité ou complexité de la tâche. Cette capacité de routage devient particulièrement importante alors que les entreprises combinent de plus en plus de modèles au sein d’une même application

OpenRouter permet aux développeurs d’accéder, via cette interface unique, à plus de 400 modèles d’IA provenant de plus de 80 fournisseurs.

Si le montant de l’opération n’a pas été officiellement communiqué, des sources proches du dossier l’évaluent à un peu plus de 8 milliards $, indique Reuters. Soit la plus importante acquisition de Stripe à ce jour.

Avec OpenRouter Stripe veut contrôler la facture de l’IA

OpenRouter indique que son infrastructure traite désormais plus de 10 000 milliards de tokens par jour et sert plus de 10 millions de développeurs et d’entreprises. Sa plateforme donne accès à plus de 400 modèles issus de plus de 80 fournisseurs. Nvidia, Zoom et Lovable figurent notamment parmi ses clients.

Le rapprochement entre les deux sociétés est moins surprenant qu’il n’y paraît. Stripe optimise déjà les transactions financières de ses clients en arbitrant entre moyens de paiement, taux d’autorisation ou mécanismes de lutte contre la fraude. Avec OpenRouter, il peut appliquer une logique comparable à la consommation d’IA.

Quel modèle utiliser ? À quel prix ? Avec quel niveau de performance ? Et combien cette requête va-t-elle réellement coûter ?

Des questions devenues centrales à mesure que les entreprises passent des expérimentations aux déploiements de grande ampleur.

Stripe avait d’ailleurs commencé à se positionner sur ce terrain avant l’acquisition, notamment avec Token Billing, un service destiné à mesurer et facturer l’utilisation des modèles d’IA. L’acquisition d’OpenRouter lui apporte désormais la brique permettant d’agir directement sur cette consommation.

Le token, nouvelle unité économique

Pour Stripe, le token est donc appelé à devenir une nouvelle unité économique qui doit être optimisée.

Cette approche prend une dimension particulière avec l’arrivée des agents IA. Une application traditionnelle génère un nombre relativement prévisible d’appels. Un agent capable de planifier une tâche, d’utiliser des outils, de consulter des données et de solliciter plusieurs modèles peut, lui, multiplier les appels aux LLM.

Le problème n’est alors plus seulement de choisir le meilleur modèle, mais de choisir le modèle suffisamment performant au meilleur coût pour chaque étape du processus.

C’est là que le positionnement d’OpenRouter devient particulièrement intéressant pour Stripe.

Une entreprise pourrait, par exemple, utiliser un modèle haut de gamme pour une tâche complexe, un modèle moins coûteux pour une classification ou une synthèse simple et basculer automatiquement vers un autre fournisseur en cas de saturation ou d’indisponibilité.

Le routeur devient alors une sorte de couche de gestion des dépenses d’IA.

Ce n’est pas très éloigné de ce que Stripe fait depuis longtemps dans les paiements. Une entreprise ne se préoccupe pas nécessairement de la complexité du réseau bancaire situé derrière son paiement ; elle confie cette orchestration à Stripe.

Un marché qui dépasse largement OpenAI

L’intérêt de cette position tient aussi au fait que Stripe ne parie pas sur un modèle particulier.

OpenAI, Anthropic, Google, Meta et les nombreux fournisseurs de modèles open source se livrent une bataille permanente sur les performances, les prix et les capacités. Dans cet environnement, miser sur la couche située entre les modèles et les applications peut être plus pérenne que de miser sur un fournisseur donné.

C’est précisément le pari effectué par OpenRouter depuis sa création en 2023. Plutôt que de chercher à construire un modèle concurrent, elle s’est positionnée comme une infrastructure permettant d’exploiter le foisonnement des modèles.

Son acquisition par Stripe valide en quelque sorte cette approche.

The post Avec OpenRouter, Stripe veut contrôler la facture de l’IA appeared first on Silicon.fr.

Palo Alto Networks veut prendre de vitesse les cyberattaques dopées à l’IA. L’éditeur lance Frontier AI Critical Defense pour organiser une réponse collective à la menace qui pèse sur les infrastructures critiques.

A l’origine de l’initiative, ses équipes ont utilisé des modèles d’IA de pointe (Frontier AI) pour identifier plus de 14 000 vulnérabilités jusqu’alors inconnues dans des logiciels open source.

Un problème critique pour les opérateurs d’infrastructures vitales ( énergie, santé, industrie, transports) qui ne peuvent pas corriger leurs systèmes à la vitesse de l’IA. De fait, leurs contraintes de disponibilité et leurs exigences de tests de sécurité créent une fenêtre d’exposition potentiellement longue entre la découverte d’une vulnérabilité et le déploiement d’un correctif logiciel.

Le Frontier Virtual Patching comme réponse

La réponse technique est baptisée Frontier Virtual Patching. Il s’agit d’un dispositif de correctifs déployés au niveau du réseau, de manière proactive, avant même que les vulnérabilités ne soient transformées en armes par des attaquants. Ce mécanisme combine la détection de menaces par Frontier AI avec une veille fiable sur les vulnérabilités, tout en protégeant les détails sensibles de ces vulnérabilités contre une divulgation prématurée.

Le programme s’appuie sur des collaborations déjà existantes ( IBM et Red Hat via Lightwell, Microsoft via le programme MAPP, Siemens et l’Idaho National Laboratory via l’OT Threat Research Lab) et s’élargit aujourd’hui à de nouveaux acteurs de premier plan.

Parmi les nouveaux entrants : Anthropic et OpenAI pour leurs capacités en modèles d’IA de pointe, des leaders de l’OT comme Mitsubishi et Axis Communications, des consortiums sectoriels de partage d’informations comme Health-ISAC et l’Analysis and Resilience Center for Systemic Risk, l’institut de recherche énergétique EPRI, ainsi que l’initiative open source Akrites portée par la Linux Foundation.

En coordonnant la découverte des vulnérabilités, leur qualification et le déploiement de correctifs virtuels à l’échelle du réseau, le programme Frontier AI Critical Defense entend transformer une réponse jusqu’ici fragmentée en une défense collective et proactive.

Les secteurs visés , OT industriel, santé, énergie, open source, sont précisément ceux où le délai entre la découverte d’une faille et sa correction est le plus long et le plus dangereux.

Enjeux et limites

Ambitieux sur le papier, le programme soulève néanmoins plusieurs questions concrètes.

La question de la confiance et du partage d’informations est centrale. La participation repose sur la volonté des éditeurs de partager des détails sensibles sur les vulnérabilités sous embargo. Or des considérations juridiques ou concurrentielles peuvent freiner ce type de coopération, en particulier lorsque les acteurs impliqués sont également en concurrence sur certains marchés.

Ensuite, la portée du virtual patching est par nature limitée. Le mécanisme protège au niveau réseau, mais ne remplace pas les correctifs applicatifs ou système. Il s’agit d’une mesure temporaire destinée à réduire la fenêtre d’exposition, non d’une solution permanente. Les opérateurs d’infrastructures critiques devront donc continuer à déployer leurs correctifs logiciels classiques en parallèle.

Enfin, la dépendance à l’écosystème Palo Alto mérite d’être soulignée. Les protections sont déployées via les offres de l’éditeur ( pare-feu, SASE), ce qui peut limiter l’adoption pour les organisations opérant dans des environnements hétérogènes, non équipés de solutions Palo Alto. Un point qui conditionne directement l’ampleur réelle de la couverture que le programme peut offrir.

The post Palo Alto Networks lance son programme Frontier AI Critical Defense appeared first on Silicon.fr.

Après la séquence « excuses » du ministre des Comptes publics David Amiel aux 678 000 particuliers et professionnels, victimes du vol de leurs données fiscales, il fallait bien une réponse du gouvernement pour résorber cette « dette technique » à coup de  « moyens humains et financiers ». 

A l’issue  d’une cellule interministérielle de crise, réunie par le Premier ministre le 17 août, une série de mesures censées colmater les brèches du système d’information de Bercy a été annoncée dans la foulée.

Premier totem de la riposte gouvernementale : la généralisation de la double authentification pour l’ensemble des agents de la DGFiP, promise d’ici la fin de l’année. Mais Bercy le reconnaît lui-même : plusieurs comptes déjà protégés par ce dispositif auraient pu être compromis lors des derniers incidents. Le double facteur, aussi indispensable soit-il, ne fait donc pas tout : encore faut-il surveiller ce qui se passe après la connexion.

C’est le deuxième axe du plan : renforcer les dispositifs de détection pour améliorer l’identification des usurpations de comptes et des comportements suspects. Par ailleurs, les systèmes de quotas d’accès, déjà appliqués à certains fichiers comme FICOBA, devraient être plus largement déployés. Comme sur un air de « zero trust »…

Authentifier, sensibiliser, détecter

Troisième pilier, plus humain : l’intensification des campagnes de bug bounty et le renforcement des formations. Egalement évoqué, un recours redoublé à l’IA pour simuler des attaques et détecter les vulnérabilités avant qu’elles ne soient exploitées.

Un service minimum dans le domaine cyber serait-on tenté de dire…

D’autant que la recrudescence des violations massives touchant les bases de données des services de l’Etat est largement documentée.

Dans un bilan publié en janvier 2025, la CNIL avait notifiée 5 629 violations de données personnelles en 2024, soit une hausse de 20 % sur un an, avec un nombre d’incidents touchant plus d’un million de personnes ayant doublé en douze mois.
Le rapport décrivait d’ailleurs, scène par scène, le mode opératoire en cinq actes qui allait se rejouer à la DGFiP :  obtention de données de connexion légitimes, accès au système d’information, exploration massive des données du fait d’habilitations trop larges, extraction en volume faute d’indicateurs de détection suffisants, puis mise en vente des données sans que l’organisme s’en aperçoive.

L’institution recommandait, noir sur blanc, l’authentification multifacteur, la sensibilisation des collaborateurs, une politique d’habilitations restreintes et une analyse en temps réel des journaux de connexion…Soit, presque au mot près, les mesures que Bercy annonce aujourd’hui dans l’urgence.

La question qui se pose est celle du délai entre le diagnostic et l’application.

Solidaires Finances Publiques : « communiquer n’est pas sécuriser »

Dans un communiqué publié le jour même de la cellule de crise, le syndicat Solidaires Finances Publiques dénonce des annonces jugées très en deçà des enjeux. Le syndicat s’interroge notamment sur le devenir de la première enveloppe de 200 millions €, déjà promise en avril dernier après la fuite de données de l’ANTS.

Une somme dont l’utilisation resterait, à ce jour, largement floue.

Sur le fond, l’organisation syndicale relie la vulnérabilité de l’administration fiscale à des choix budgétaires assumés depuis des années. La réduction continue des moyens humains et techniques aurait, selon elle, directement fragilisé les capacités de défense de la DGFiP.

Quant aux tests d’intrusion préconisés pour identifier les failles internes, le syndicat juge l’annonce d’autant plus surprenants qu’ils devraient déjà constituer la norme dans un système d’information aussi sensible que celui du fisc et que l’ANSSI les recommande de longue date.

Le plan présenté par Bercy affronte un double scepticisme. Si techniquement, on l’a vu, les mesures annoncées cochent les bonnes cases, leur crédibilité se jouera dans leur déploiement rapide et dans la traçabilité des budgets promis depuis l’affaire ANTS.

Vol de données massifs : huit années d’intrusions dans les services de l’État

« `

The post Cyberattaque à la DGFiP : le plan de riposte qui peine à convaincre 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.

NetApp a officialisé l’acquisition de JetStream Software, un éditeur spécialisé dans la reprise après sinistre (DR) et la migration d’environnements VMware.

Avec cette opération, le spécialiste du stockage entend renforcer son offre de cyber-résilience et de protection des données à l’ère de l’IA. L’enjeu est notamment d’étendre la couverture de NetApp au-delà de ses propres baies de stockage, en permettant de protéger des workloads VMware tournant sur « pratiquement n’importe quelle plateforme de stockage » et de les restaurer sur des services cloud NetApp, notamment Azure NetApp Files.

Les entreprises continuent de s’appuyer massivement sur VMware pour leurs applications critiques, tout en cherchant à migrer progressivement vers le cloud sans rupture opérationnelle ni explosion des coûts. Pour beaucoup d’entre elles, la reprise après sinistre constitue une première étape concrète avant une migration plus large des charges de production.

Une couche d’orchestration pour les environnements VMware

NetApp positionne donc JetStream comme un accélérateur de cette trajectoire : les entreprises peuvent commencer par déporter leur dispositif de reprise dans le cloud, puis faire évoluer progressivement une partie de leur production en fonction de leur stratégie et de leur maturité.

JetStream ne se limite pas à répliquer des volumes. Sa technologie orchestre également la reconstruction et le redémarrage ordonné des machines virtuelles sur un site de reprise.

La solution protège en continu les workloads VMware grâce à des filtres I/O installés au niveau de l’hôte, avant de répliquer les données vers un stockage objet, comme Azure Blob. Elle permet également de regrouper les machines virtuelles interdépendantes au sein de « domaines protégés » (protected domains), qui définissent à la fois le périmètre de reprise et les priorités de redémarrage.

Lorsqu’un incident survient, JetStream coordonne le basculement, le retour arrière et les tests de reprise en s’appuyant sur des runbooks. Ceux-ci permettent notamment d’ordonner le démarrage des machines virtuelles, d’ajuster les ressources CPU et mémoire, de modifier l’adressage IP et de tenir compte des dépendances entre applications.

La solution prend par ailleurs en charge la récupération à un point précis dans le temps. Cette fonction peut notamment être utilisée dans le cadre d’un incident de type ransomware, en permettant de reconstruire les applications dans un réseau isolé avant leur réintégration dans l’environnement de production.

JetStream en complément de SnapMirror

Dans l’architecture documentée par JetStream, le site de reprise peut s’appuyer sur Azure VMware Solution (AVS) ainsi que sur des datastores vSAN ou Azure NetApp Files. Les données répliquées peuvent, de leur côté, être stockées dans Azure Blob. Cette architecture dissocie ainsi le stockage utilisé pour la réplication des ressources de calcul nécessaires à la reprise.

NetApp précise que JetStream ne remplace pas SnapMirror, qui reste sa solution de réplication privilégiée pour les environnements reposant sur ses propres infrastructures de stockage.

Les deux technologies répondent à des périmètres différents. SnapMirror assure la réplication des données dans les environnements NetApp, tandis que JetStream étend la protection aux infrastructures VMware reposant également sur des systèmes de stockage tiers. Surtout, la technologie apporte une couche d’orchestration destinée à coordonner la remise en service des applications, au-delà de la simple réplication des données.

NetApp renforce son positionnement sur la cyber-résilience

JetStream Software est basée à San José, en Californie, et dispose également d’une filiale à Bangalore, en Inde. Selon  Axios, l’entreprise avait auparavant levé environ 13 millions $.

NetApp n’a pas communiqué le montant de l’acquisition. Le calendrier précis d’intégration de la technologie dans les offres NetApp n’a pas non plus été détaillé publiquement.

L’intérêt de l’opération réside surtout dans l’élargissement du périmètre couvert par NetApp. Jusqu’ici fortement associé au stockage, le groupe ajoute une couche d’orchestration permettant de gérer la reprise d’environnements VMware indépendamment de la plateforme de stockage sous-jacente. Cette approche rapproche NetApp des capacités proposées par les spécialistes de la reprise après sinistre, du DRaaS et de la protection applicative.

Les prochains mois permettront surtout de mesurer la manière dont NetApp compte intégrer JetStream à son portefeuille commercial. Les modalités de licensing, le éventuel bundling avec les offres existantes et le positionnement des futurs produits seront particulièrement observés.

La feuille de route concernant les clients actuels de JetStream constituera également un point d’attention, tout comme l’éventuelle extension de la technologie à d’autres hyperscalers au-delà d’Azure.

Enfin, l’articulation avec les récentes acquisitions et initiatives de NetApp dans le domaine des données et de l’IA permettra de déterminer si JetStream restera principalement une brique dédiée à la résilience des environnements VMware ou s’il deviendra progressivement un élément plus large de la stratégie de protection et de mobilité des workloads du groupe.

The post NetApp acquiert JetStream Software appeared first on Silicon.fr.

L’arrivée de Claude Mythos en avril 2026 a suscité un emballement médiatique poussant les RSSI à réagir de deux façons : soit se précipiter pour acheter de nouveaux outils, soit mettre discrètement à jour leur backlog de CVE en espérant gagner du temps.

Pourtant, aucune de ces deux réactions ne répond véritablement au problème. Mythos n’a pas révolutionné la cybersécurité. Il a surtout mis en lumière l’ampleur des vulnérabilités qui restaient jusqu’ici non corrigées.

L’illusion de la gestion des vulnérabilités

Pendant des années, le secteur a vécu sur une fiction rassurante ; le délai entre la découverte d’une vulnérabilité et son exploitation laissait aux équipes de sécurité le temps nécessaire pour la corriger. Ce délai existait parce que les capacités des attaquants étaient limitées ; mais avec Mythos, cette limite est en train de disparaître.

Selon Anthropic, le modèle peut identifier et exploiter une vulnérabilité de manière autonome en quelques heures. Une vitesse qui remet en cause l’un des fondements des programmes de sécurité : l’idée qu’il existe encore un délai suffisant pour corriger une faille avant qu’elle ne soit exploitée.

Les chiffres confirment l’ampleur du problème.

Selon Gartner, moins de 1 % des vulnérabilités identifiées par Mythos ont été corrigées. Le véritable enjeu n’est donc pas Mythos, mais l’accumulation de vulnérabilités non corrigées, désormais à la portée de tout attaquant disposant d’une technologie comparable.

Une étude de Kenna Security et du Cyentia Institute montre par ailleurs que 77 % des vulnérabilités connues n’ont jamais fait l’objet d’une exploitation observée dans la nature. Le modèle du « tout détecter, tout corriger » a toujours relevé du théâtre. Mythos n’a fait qu’en révéler les failles.

Pour autant, Mythos ne change pas la nature du principal obstacle. Le véritable goulot d’étranglement n’a jamais été la découverte des vulnérabilités, mais la capacité à déterminer lesquelles doivent être traitées en priorité. Parmi les milliers de CVE présentes dans un système d’information, lesquelles sont réellement exploitables depuis Internet ? Lesquelles concernent effectivement l’environnement en place ? Lesquelles restent exploitables malgré les contrôles compensatoires ?

Mythos rend cette question plus urgente, sans y apporter de réponse.

Prioriser les vulnérabilités exige plus qu’un score CVSS

La première réaction de nombreuses organisations sera de multiplier les scanners. Pourtant, le problème n’est pas là. Les scores CVSS évaluent la gravité théorique d’une vulnérabilité, sans tenir compte de son exposition réelle sur Internet ni de son impact opérationnel.

Ce qui compte désormais, c’est le contexte : savoir quelles vulnérabilités sont réellement exploitables dans l’environnement de l’entreprise et lesquelles doivent être corrigées en priorité. Un scanner hebdomadaire qui génère un fichier CSV ne peut plus répondre à cet enjeu. Lorsque le délai d’exploitation se compte en heures, il faut une visibilité continue sur les terminaux, les logiciels installés, les versions réellement exécutées et les interactions entre les composants du système.

En reliant cette détection à un agent EDR, les équipes de sécurité peuvent déterminer rapidement si une CVE critique concerne un composant réellement actif dans leur environnement. Cette visibilité permet de prioriser les actions de remédiation en fonction du risque réel, plutôt que de la seule sévérité théorique.

Chercher à tout corriger n’est plus une stratégie ; l’enjeu est d’identifier les quelques dizaines de vulnérabilités qui exposent réellement l’organisation et de concentrer les efforts de remédiation sur celles-ci.

Avec Mythos, un nouveau standard s’impose

Mythos est le début d’une nouvelle génération d’outils. Quelques jours après son lancement, OpenAI dévoilait GPT-5.4-Cyber, un modèle dédié à la recherche en cybersécurité, déjà plus performant que Mythos Preview sur plusieurs benchmarks.

Dans le même temps, SC World rapportait qu’un modèle chinois open weight, distribué sous licence MIT, surpassait lui aussi plusieurs modèles de référence en détection de vulnérabilités, pour un coût environ huit fois inférieur.

Les contrôles d’accès mis en place par Anthropic autour de Mythos offrent un répit, mais ne changent rien à la tendance de fond. Les capacités se diffusent, les coûts baissent et les modèles se multiplient. Construire une stratégie de sécurité à partir de ce que Mythos est capable de faire aujourd’hui, c’est déjà regarder dans le rétroviseur.

La découverte de vulnérabilités assistée par l’IA est désormais une réalité durable, avec laquelle devront composer aussi bien les attaquants que les défenseurs.

La gestion des vulnérabilités n’est qu’un moyen, pas une fin

Le véritable changement apporté par les LLM et l’IA agentique ne tient pas seulement à leur capacité à découvrir des vulnérabilités. Il réside surtout dans leur aptitude à accélérer chaque étape d’une attaque après la compromission initiale. Les agents IA peuvent exploiter une faille, élever leurs privilèges, se déplacer latéralement et exfiltrer des données à une vitesse inédite.

Les frontières traditionnelles entre postes de travail, navigateurs, serveurs et applications deviennent alors beaucoup moins pertinentes. Pour suivre ce rythme, les capacités de détection et de réponse devront elles aussi évoluer afin d’observer, comprendre et contenir des systèmes d’IA capables de raisonner et d’agir de manière autonome, en s’appuyant sur les les solutions de sécurité déjà déployées sur les terminaux.

L’étape suivante sera l’AIDR (Artificial Intelligence Detection and Response). Non pas un nouveau label marketing, mais une évolution de l’architecture de sécurité.

L’objectif est de confier aux agents IA le tri des alertes, la corrélation des signaux à l’échelle du système d’information et la prise en charge des tâches répétitives, afin que les analystes se concentrent sur les décisions qui requièrent une véritable expertise.

Dans cette architecture, le VOC et le SOC ne peuvent plus fonctionner en silos ; dès qu’une CVE critique est identifiée, la recherche de signes d’exploitation doit être lancée immédiatement. Le délai entre ces deux étapes se mesure désormais en minutes, et non plus en jours.

Les règles du jeu restent les mêmes

Mythos n’impose pas un nouveau paradigme de sécurité, il oblige à mettre en œuvre les principes existants avec une rapidité et une précision que la plupart des organisations n’ont pas encore atteint : visibilité sur les actifs, priorisation contextualisée, automatisation, surveillance continue, au rythme d’attaquants désormais assistés par IA.

Les organisations qui avaient investi dans ces fondamentaux avant avril 2026 savent déjà quelles vulnérabilités exigent une intervention immédiate et lesquelles peuvent attendre.

Ce n’est pas un avantage produit, mais ces sont des décisions architecturales prises bien avant que le sujet ne devienne incontournable. La question n’est plus de savoir ce que Mythos a changé, mais sur quel délai, désormais disparu, reposaient les stratégies de sécurité.

* Anouck Teiller est CEO deputy chez HarfangLab

The post Ce que Claude Mythos révèle de nos stratégies de cybersécurité appeared first on Silicon.fr.

Data & IA

> AI Act : clés et ressources pour se mettre en conformité
Une nouvelle tranche de l’AI Act entre en application le 2 août 2026. Le point sur les obligations et sur les instruments de mise en conformité que l’UE y a adjoints.
Lire ici

> IA : après l’ivresse, le budget
L’heure de l’expérimentation est révolue. Les entreprises entrent dans une phase où chaque usage de l’IA doit désormais justifier un ROI.
Lire ici

Business

> Microsoft et Mistral AI passent à l’échelle industrielle avec un partenariat centré sur l’infrastructure
Microsoft et Mistral AI franchissent une nouvelle étape dans leur collaboration qui associe désormais modèles d’IA, infrastructures de calcul et capacités de déploiement pour les entreprises.
Lire ici

> Open source, moratoire sur les data centers…29 propositions pour reconquérir la souveraineté numérique
En six mois d’auditions, la commission d’enquête parlementaire sur les vulnérabilités numériques de la France a chiffré l’ampleur de la dépendance aux technologies américaines et pose 29 propositions pour en sortir.
Lire ici

> IA en entreprise : pourquoi Microsoft et AWS court-circuitent les intermédiaires
En déployant par milliers leurs propres ingénieurs directement au cœur des entreprises clientes, Microsoft et AWS court-circuitent les ESN, partenaires traditionnels de l’intégration de leurs offres.
Lire ici

> VMware, un vrai sujet de dépendance dans la sphère publique
Les auditions de la commission d’enquête parlementaire sur les dépendances numériques ont mis en lumière l’empreinte de VMware dans la sphère publique… et les stratégies de sortie engagées par certains.
Lire ici

Cloud

> Entre hyperscalers, les stacks agentiques se suivent… et se ressemblent ?
Y a-t-il convergence ou divergence dans les stratégies des clouders américains sur l’IA agentique ? Au Google Cloud Summit Paris, les avis furent partagés.
Lire ici

> Les cloud providers européens avancent leur propre référentiel de souveraineté
N’adhérant pas pleinement au Cloud Sovereignty Framework de l’UE, l’association CISPE avance son propre référentiel.
Lire ici

Cybersécurité

> « 17 600 actions automatisées » : comment l’attaque agentique contre Hugging Face s’est articulée
Hugging Face livre une analyse technique horodatée de l’attaque agentique subie entre le 9 et le 13 juillet. En voici quelques éléments.
Lire ici

> Quand les régulateurs somment les banques de se barricader face à l’IA
Face à l’émergence d’IA capables de militariser les failles informatiques en quelques minutes, les autorités financières européennes lancent une course contre la montre et somment 110 banques de revoir l’intégralité de leurs défenses
Lire ici

The post {Sélection Été 2026 } – 10 articles à lire pour préparer la rentrée appeared first on Silicon.fr.

AMD étoffe son portefeuille dans l’IA avec le rachat de Taalas, une start-up basée à Toronto et fondée en 2023. La transaction reste soumise aux conditions de clôture habituelles et aux autorisations réglementaires.

Taalas développe des composants en silicium spécialisés pour l’inférence IA. À la différence de l’entraînement, qui mobilise d’importantes capacités de calcul pour construire un modèle, l’inférence intervient lors de son utilisation opérationnelle, souvent en temps réel.

La technologie de Taalas vise à réduire les goulets d’étranglement liés au calcul et à la mémoire dans les architectures généralistes. La start-up conçoit notamment des accélérateurs adaptés à des modèles spécifiques, en intégrant directement certains paramètres du modèle dans le silicium.

Cette approche permet de gagner en performance et en efficacité énergétique, au prix d’une flexibilité moindre qu’avec un GPU généraliste. Les accélérateurs de Taalas sont configurés pour un modèle donné et peuvent donc être beaucoup plus rapides et moins coûteux dans des scénarios d’usage ciblés. Mais ils doivent être adaptés lorsque le modèle évolue.

Le premier composant de Taalas ferait fonctionner une version allégée de Llama 3.1, le modèle de Meta.

Une brique supplémentaire pour AMD

AMD prévoit d’intégrer la technologie de Taalas dans sa feuille de route d’accélérateurs et entend également développer des solutions au niveau système combinant ces technologies avec ses GPU Instinct.

L’opération doit ainsi compléter la plateforme IA full stack d’AMD, qui comprend les solutions rackscale Helios, les accélérateurs Instinct, les processeurs EPYC, le logiciel ROCm et les composants de son écosystème logiciel et matériel.

Pour AMD, l’enjeu consiste à proposer plusieurs types de processeurs selon les charges de travail. Les GPU restent adaptés à une grande variété de modèles et d’usages tandis que des accélérateurs spécialisés peuvent être pertinents pour des modèles stabilisés exécutés à très grande échelle. Par exemple dans les moteurs de recherche, les assistants conversationnels ou les services de génération de contenu.

Cette acquisition intervient alors que le marché de l’IA se déplace progressivement de l’entraînement des modèles vers leur déploiement massif. Les fournisseurs de cloud et les grandes entreprises cherchent désormais à réduire le coût et la consommation énergétique de milliers, voire de millions, de requêtes quotidiennes.

Cette évolution ouvre la voie à des architectures plus spécialisées. Les GPU offrent une grande souplesse mais leur coût et leur consommation peuvent devenir pénalisants lorsque les modèles sont exécutés de manière répétitive et prévisible. Les ASIC et autres accélérateurs dédiés tentent de répondre à cette contrainte en optimisant le matériel pour un modèle ou une famille de modèles.

La bataille de l’inférence s’intensifie

Nvidia a renforcé sa présence sur ce segment en dévoilant, notamment, un processeur et un système d’IA s’appuyant sur la technologie de Groq, une start-up spécialisée dans l’inférence.

La pression concurrentielle ne vient toutefois pas uniquement des deux géants des GPU car les hyperscalers développent également leurs propres puces, à l’image des accélérateurs conçus pour leurs infrastructures cloud.

Pour AMD, le principal défi sera d’intégrer cette technologie dans une offre industrielle et logicielle cohérente. Une puce spécialisée peut afficher des performances très élevées sur un modèle donné, mais son intérêt dépend de la stabilité des architectures d’IA, de la capacité à reconfigurer rapidement le matériel et de la compatibilité avec les outils de développement existants.

L’intégration avec Instinct et ROCm sera donc déterminante. AMD devra démontrer que Taalas peut compléter ses GPU plutôt que constituer une technologie isolée, difficile à programmer ou limitée à quelques cas d’usage.

The post AMD rachète Taalas pour accélérer sur l’inférence IA appeared first on Silicon.fr.

En étendant le périmètre d’une offre, on prend le risque de la détourner des véritables besoins des acheteurs.

Gartner perçoit cette tendance chez les principaux fournisseurs de solutions SASE. Il en fait part dans le dernier Magic Quadrant dédié à ce marché, évoquant une « surplateformisation ».

Logiquement, on retrouve le constat dans un autre Magic Quadrant, publié quasiment en parallèle : celui du SSE. C’est-à-dire de la partie « sécurité » du SASE, par opposition à la partie « réseau ».

Si Gartner maintient le distinguo, c’est que le sourcing de ces deux briques se fait encore majoritairement auprès de fournisseurs différents (65 % des achats en 2026, estime-t-il).

Un critère spécifique pour la protection des IA génératives

Le mouvement vers des offres SSE intégrées n’est pas nouveau. Au passage, de nombreuses composantes sont devenues des commodités :. RBI (isolation du navigateur à distance) et DLP (protection contre la perte de données) en font partie. Même chose pour les pare-feu cloud, qui « ne constituent plus un élément de différenciation ».

Dans ce contexte, les fournisseurs ont commencé à embarquer des produits qui, dans la terminologie de Gartner, relèvent d’autres marchés. Par exemple, l’EPP (protection des terminaux) et le DSPM (gestion de la posture de sécurité des données). Conséquence : il devient plus difficile de les comparer sur le cœur SSE, d’autant plus lorsque des liens fonctionnels se créent avec ces produits adjacents… et que les modèles de licence s’adaptent pour en encourager l’adoption.

Il reste encore des éléments de différenciation, dont la capacité à protéger les « applications d’IA générative ». Gartner en a fait un des critères à respecter pour prétendre figurer dans ce Magic Quadrant. Il fallait, en l’occurrence, proposer une visibilité et des contrôles de base (bloquer, autoriser, avertir) pour les données sensibles sur au moins trois services parmi ChatGPT, Claude, Copilot, DeepSeek, Gemini, Grok et Perplexity.

Bien que nombre d’offreurs aient désormais une console unifiée, cet élément était facultatif. Comme, entre autres, le firewall cloud, le RBI, l’UEBA (analyse comportementale) et la gestion de posture de sécurité du SaaS.

8 fournisseurs, 3 « leaders »

Des 9 fournisseurs qui figurent dans le Magic Quadrant du SASE, on en retrouve 7 dans celui du SSE. À l’exception de Cato Networks, tous ceux classés « leaders » dans le premier le sont aussi dans le second. Nommément, Netskope, Palo Alto Networks et Zscaler. Deux acteurs présents en 2025 ne le sont plus cette année : Fortinet et Versa Networks. À l’inverse, Cisco fait son entrée dans le Magic Quadrant du SSE.

La situation sur l’axe « exécution », qui traduit la capacité à répondre à la demande (expérience client, viabilité financière, qualité des produits/services…) :

Sur l’axe « vision », qui reflète les stratégies (perception du marché, innovation, développement produit…) :

Prix élevé et tarification complexe chez Netskope

L’an dernier, Gartner avait souligné la notoriété de Netskope, fréquemment présent sur les shortlists. Il avait salué ses capacités techniques (positionnement sur tous les compartiments du SSE) et sa compréhension du marché (couverture de la majorité des cas d’usage).
Le cabinet américain avait toutefois noté l’absence de localisation linguistique de la console, la relative lenteur de Netskope pour ajouter des fonctionnalités « avancées » et son ciblage non efficace du mid-market (organisations de 100 à 1000 employés).

Cette année encore, Netskope est salué pour sa visibilité. Il l’est aussi pour le niveau d’expérience client « au-dessus de la moyenne ». Et pour les perspectives qu’ouvre l’architecture AgentSkope.
Sa tarification est en revanche complexe et les prix ont tendance à être supérieurs à la moyenne. Le focus sur la sécurité et la gouvernance de l’IA acheteurs ne résonnera pas forcément auprès des SSE, ajoute Gartner. Plus globalement, la concurrence réduit l’écart.

L’IA, vecteur de « surplateformisation » chez Palo Alto Networks

L’an dernier, Gartner avait souligné la viabilité de financière de Palo Alto Networks. Ainsi que ses innovations (en particulier sur l’IA) et son intégration avec les firewalls sur site.
Le cabinet américain avait pointé une tarification complexe et élevée et une brique RBI ne couvrant efficacement qu’un moindre ensemble de cas d’usage. Il avait aussi signalé que la localisation du support, de l’interface et de la documentation technique était largement limitée à l’anglais.

Cette année encore, Palo Alto Networks a droit à un bon point pour sa viabilité financière. Gartner y ajoute la visibilité (présence fréquente sur les shortlists SSE). Et la compréhension globale du marché, que ce soit dans l’équilibre entre SSE autonome et SASE ou dans la réduction des complexités d’administration.
La tarification complexe et élevée demeure. Quant aux innovations planifiées, à l’image de la défense autonome axée sur l’OT et le legacy, elles s’alignent davantage sur les plates-formes SASE que sur le seul segment SSE. On surveillera aussi le mouvement de « plateformisation », qui exige des acheteurs qu’ils investissent dans des outils hors périmètre SSE traditionnel, comme la protection des runtimes IA et la gestion des identités non humaines.

Chez Zscaler vigilance sur le packaging

L’an dernier, Zscaler avait été salué pour sa visibilité, ainsi que son pricing « simplifiant l’achat pour les nouveaux clients ». Gartner avait aussi apprécié le niveau global de compréhension du marché, additionné d’un historique de livraison anticipée
Zscaler reste un des fournisseurs les plus chers, avait tempéré le cabinet américain. Il avait aussi signalé des problèmes de performance plus fréquents que chez les concurrents. Et alerté quant à la diversification sur le SecOps… et à son éventuel impact sur la stratégie SSE.

Le bon point « visibilité » vaut toujours cette année. Zscaler en a droit à un autre sur le volet IA. À la fois pour son intégration au sein de ses solutions et pour les capacités de contrôle de son usage. Gartner y ajoute les innovations sur le front AgenticOps et le développement d’une plate-forme distincte pour la sécurité de l’IA.
« Sous la moyenne » en matière d’expérience client, Zscaler a par ailleurs tendance à packager des capacités issues de segments adjacents et à exiger des add-on pour certaines fonctionnalités « avancées » du cœur SSE.

Illustration © valerybrozhinsky – Adobe Stock

The post Devenu plus englobant, le SSE échappe à sa signification première appeared first on Silicon.fr.

Meta avait les modèles, il a désormais le harnais. Son nom : Muse Code.

Disponible en bêta sur Mac et Linux, il a deux modes d’exécution : interactif (terminal) et headless. L’authentification passe par le navigateur ou par une clé d’API.

Le modèle par défaut est Muse Spark 1.2, lancé en parallèle. Meta recommande fortement de ne pas en changer et pour cause : le LLM et le harnais ont été entraînés conjointement.

Muse Spark 1.2 constitue une « amélioration modérée » de Muse Spark 1.1, qui était sorti début juillet uniquement aux États-Unis. Les optimisations se sont portées sur le codage. En particulier sur les tâches longues. Ont donc été exercées des compétences telles que la planification, la compression du contexte et l’adhérence à des objectifs.

Payer avec ses données : une option non disponible dans l’Union européenne

Le lancement de Muse Code ne change pas la tarification des modèles Muse Spark. L’API conserve, en plus du niveau standard, le niveau dit « contributeur ». Il offre une nette ristourne en contrepartie à deux éléments. D’une part, accepter des limites de débit plus strictes (60 requêtes par minute vs 3000 ; 2,1 millions de tokens par minute vs 4 millions). De l’autre, donner à Meta le droit d’exploiter entrées et sorties pour entraîner de futurs modèles. Un point bloquant dans l’Union européenne, si bien que l’option n’y est pas disponible. Elle ne l’est pas non plus en Australie, au Brésil, au Canada, en Corée du Sud et au Royaume-Uni.

Meta commence par ailleurs à traiter les demandes d’activation de l’option ZDR (zero data retention).

Comme avec Codex, pas d’imbrication de sous-agents

Meta propose une dizaine de cookbooks pour illustrer les capacités de Muse Code. Par exemple, la planification en langage naturel, la distribution de tâches entre sous-agents, les rejeux déterministes, le suivi des objectifs ou l’immuabilité des garde-fous.

Le harnais peut gérer un maximum de 16 sous-agents. Le plafond dépend des ressources de la machine (formule générale : nombre de cœurs processeurs – 2). Comme sur Codex, ces sous-agents ne peuvent pas en lancer d’autres. Mais ils peuvent avoir leur propre arbre Git pour éviter les conflits d’écriture. Muse Code en fait lui-même tourner, pour « observer » l’exécution. Chacun suit un axe de qualité et peut fournir des conseils à l’agent principal sans l’interrompre.

Par défaut, toutes les commandes shell s’exécutent dans une sandbox OS et l’humain doit examiner celles jugées à risque (globalement, rm -f et rm -fr, précédées ou non de sudo). On peut activer/désactiver séparément ces deux aspects.
Il existe un mode plus strict (demande de révision de toute commande qui n’est pas en liste d’autorisation)… ainsi qu’un mode YOLO, qui désactive aussi la sandbox et dit au harnais de faire confiance à l’espace de travail.

Muse Code a une option de saisie vocale (activée par défaut sur Mac ; pas sur Linux). Il permet de gérer manuellement le contexte (compression, résumé des dernières actions, exportation avec possibilité de masquer les chaînes ressemblant à des secrets…). Les fichiers AGENTS.md ont la priorité sur les fichiers CLAUDE.md.

Illustration générée par IA

The post Muse Code, le harnais agentique de Meta, n’arrive pas seul appeared first on Silicon.fr.

Il y a des départs qui ressemblent à une page qui se tourne. Celui de Jeff Dean en est une qui se déchire.

À 58 ans, l’homme quitte le groupe qu’il avait rejoint mi-1999 comme trentième salarié. Une époque où Google n’était encore qu’un moteur de recherche en devenir.

Jusqu’à son départ, il occupait officiellement le poste de « Chief Scientist » de Google, chargé selon sa propre fiche de présentation  de piloter les avancées en IA pour Google DeepMind et Google Research. Il est aussi un des co-responsables techniques du projet Gemini. .

Tomorrow will be my last day at Google after 27 years, and watching it grow from 25 people to 190,000+ has been an amazing journey. Below is a note I shared with many people internally at Google today. An excerpt is:

It has been an absolute pleasure to work with you and to help… pic.twitter.com/o3aRNLkssA

— Jeff Dean (@JeffDean) August 5, 2026

Aucun ingénieur n’a autant façonné l’ADN technique de Google que Jeff Dean. Avec son complice de toujours Sanjay Ghemawat , il a conçu les systèmes distribués qui ont permis au moteur de recherche de répondre, dans les années 2000, aux requêtes de milliards d’utilisateurs à travers le monde.

Sa biographie professionnelle permet de dater précisément ces chantiers : MapReduce, présenté lors de la conférence OSDI en 2004 ; BigTable, dévoilé en 2006 et qui, encore aujourd’hui, traite plus de six milliards de requêtes par seconde au pic d’activité pour plus de dix exaoctets de données gérées ; puis Spanner, sa base de données mondiale à cohérence forte, présentée en 2012.

Un bâtisseur de l’infrastructure Google

Jeff Dean a également porté la création de TensorFlow, la bibliothèque de deep learning que Google a choisi d’ouvrir en open source en 2015 et qui reste utilisée par des millions de développeurs, ainsi que Pathways, l’architecture plus récente pensée pour entraîner des modèles massifs comme PaLM.

C’est encore lui qui impulse en 2011 la création de Google Brain, le laboratoire de recherche en apprentissage profond qui a déclenché, bien avant ChatGPT, la ruée de toute l’industrie vers l’IA.

En 2012, Jeff Dean reçoit avec Sanjay Ghemawat, l‘ACM Prize in Computing, pour leurs contributions fondamentales aux systèmes distribués à l’échelle d’Internet. En interne, ils sont d’ailleurs, à ce jour, les deux seuls à avoir reçu le titre de « senior fellow », la plus haute distinction technique de Google.

Mais Jeff Dean n’est pas seulement un cadre dirigeant ; c’est une figure culte.

Les salariés du groupe entretiennent depuis des années des plaisanteries sur ses prouesses techniques légendaires, les « Jeff Dean Facts ». La plus fameuse ?  » Son CV serait plus court s’il listait ce qu’il n’a pas fait plutôt que ses réalisations. »

Selon Business Insider, qui a recueilli plusieurs messages publiés sur le forum interne de l’entreprise, son départ a déclenché une nouvelle vague de mèmes en interne, plusieurs employés tournant en dérision l’idée que ses talents allaient enfin pouvoir profiter à d’autres que Google. Par exemple « Google ne perd pas Jeff Dean. Google le met enfin à disposition de l’humanité en open source » ou « Il quitte Google pour que les progrès du ML puissent rattraper Jeff Dean ».

Une aura quasi mythique en interne

Sundar Pichai, le patron d’Alphabet, a salué, dans un message interne cité par le New York Times, le rôle de Jeff Dean et Sanjay Ghemawat dans plusieurs des grandes transitions technologiques du groupe, de l’infrastructure de recherche des débuts jusqu’aux réseaux de neurones à l’origine de l’ère actuelle de l’IA.

Selon Wired, il aurait aussi multiplié les rencontres avec Jeff Dean pour tenter de le convaincre, lui et son équipe, de rester chez Google.

Son départ intervient dans un contexte de turbulences pour la division IA de Google. Le modèle phare Gemini 3.5 Pro accuse un retard important sur le calendrier initial, tandis qu’OpenAI et Anthropic continuent de repousser l’état de l’art.

Plusieurs chercheurs de haut niveau ont déjà quitté le navire ces derniers mois. Noam Shazeer est parti chez OpenAI quand John Jumper, co-lauréat du prix Nobel de chimie en 2024 avec Demis Hassabis pour AlphaFold, a été recruté par Anthropic.

Selon Axios, certains départs auraient également été motivés par le malaise face à l’accord conclu en avril entre Google et le Pentagone, autorisant l’armée américaine à utiliser ses technologies.

Jeff Dean lui-même s’était publiquement exprimé ces derniers mois sur des sujets politiquement sensibles et avait soutenu la position d’Anthropic dans son différend juridique avec le département de la Défense.

Discovery Loop, une nouvelle aventure

Mais c’est dorénavant à la tête de Discovery Loop, une société à mission (« public benefit corporation ») qu’il va déployer ses talents.

Il embarque avec lui fonde trois autres vétérans de Google : son fidèle ami Sanjay Ghemawat mais aussi Quoc Le – cofondateur de Google Brain et à l’origine d’AutoML-Zero – et Oriol Vinyals – ex VP de la recherche chez DeepMind et co-directeur technique de Gemini.

Introducing Discovery Loop . We’re building AI to run experiments at unprecedented scale and to solve the biggest bottlenecks in science and engineering.

Our founders @JeffDean, @Sanjay_Ghemawat, @quocleix, @OriolVinyalsML helped build the AI infrastructure and models that… pic.twitter.com/Y3FUlMLTbf

— Discovery Loop (@DiscoLoopAI) August 5, 2026

Leur ambition est d’automatiser les boucles expérimentales de la recherche scientifique et technique grâce à l’IA, avec des applications envisagées dans la conception de matériel informatique, la découverte de médicaments ou l’énergie propre.

Alphabet sera actionnaire du projet et fournira la puissance de calcul nécessaire au moins pour la première année. Radical Ventures et Khosla Ventures codirigent le tour de table, dont le montant n’a pas été communiqué.

 Principales réalisations de Jeff Dean chez Google

Source : https://research.google/people/jeff/

Photo : © DR

The post Pourquoi Jeff Dean, l’homme qui a bâti Google, prend le large appeared first on Silicon.fr.

Avec le bon pipeline d’entraînement, on peut former un petit classifieur qui rivalise avec les grands modèles de modération de contenu.

Mistral AI l’affirme à propos de son dernier-né : Shieldstral. Dans le contexte de son adhésion à l’Open Secure AI Alliance, il en a publié les poids sous licence Apache 2.0.

Le modèle dérive de Ministral-3B-Base-2512. Multimodal (texte et/ou image), il est dit « adaptatif » au sens où on peut modifier la politique de modération lors de l’inférence, sans avoir à le réentraîner. Sur le papier, cette propriété favorise la diversification des contextes de déploiement (un contenu acceptable dans un cas peut être indésirable dans un autre). Elle différencie Shieldstral de l’API Mistral Moderation, qui n’a pas cette flexibilité.

Un travail d’unification des jeux d’entraînement

Pour développer cette propriété, Mistral AI a réduit les tâches de modération à des questions fermées exprimées en langage naturel. Par exemple : « Ce contenu promeut-il la violence contre une minorité ? » ou « Cette image peut-elle être montrée à une personne mineure ? ». Shieldstral y répond par un score, sans dépendre d’une taxonomie fixe.

Dans chaque requête, le prompt utilisateur se structure en trois champs :

• <Instruct>
  Constant sur une tâche ou un dataset donné, il décrit le contexte d’évaluation et le niveau de rigueur.
• <Query> (question fermée à propos du contenu à évaluer)
• <Document> (contenu, qu’il s’agisse de texte, d’image ou des deux)

Inculquer ce format de travail à Shieldstral a impliqué d’unifier les jeux de données d’entraînement existants, très hétérogènes dans leurs conventions d’annotation comme dans leurs taxonomies. Mistral AI a opéré une conversion à base de templates, en développant un pipeline de traitement spécifique à chaque dataset. Il a fait en sorte que le modèle apprenne à calibrer les décisions selon le niveau de rigueur. Et qu’il rencontre, au fil de l’entraînement,  diverses formulations d’instructions, afin d’acquérir des capacités de généralisation.

Shieldstral, trois checkpoints pour un modèle

L’autre pièce maîtresse dans la formation de Shieldstral fut l’usage de paires d’entraînement contrastives. D’un côté, des exemples positifs rattachés à trois types de requêtes : binaires (« Ce message est-il indésirable ? »), propres à des catégories (« Ce contenu promeut-il le suicide ? ») et, le cas échéant, spécifiques à des groupes cibles (« Ce message promeut-il la violence envers les enfants ? »). De l’autre, des exemples négatifs, avec trois stratégies pour les générer :

• Sur la base des catégories (on associe un contenu violant une catégorie A à des requêtes à propos des catégories B, C, etc.)
• Sur base démographique (on associe un contenu ciblant un groupe A à des requêtes concernant d’autres groupes)
• En combinant des exemples sûrs à des requêtes binaires portant sur des contenus indésirables

Cette approche a appris au modèle à ne pas seulement détecter du contenu indésirable, mais à faire la distinction entre catégories. Mistral AI l’a aussi exploitée pour affiner l’interprétation des politiques de modération, en l’encourageant à porter son attention sur des détails sémantiques plutôt qu’à s’appuyer sur des indices liés aux catégories.

Face à la rareté des jeux de données de modération d’images, Mistral AI y a adjoint des jeux de données de classification et de détection d’objets. Leurs exemples ont servi de négatifs… mais aussi de positifs, en permutant les requêtes grâce à un LLM.

La formation de Shieldstral ne s’est pas faite par fine-tuning supervisé, mais via la méthode LoRA. Elle a produit deux checkpoints. L’un limité aux jeux de données de modération publics (environ 45 millions d’exemples texte). L’autre élargi à des exemples synthétiques et aux images (environ 10 millions en cumulé). Mistral AI a fusionné ces checkpoints, ainsi que celui de Ministral-3B-Instruct pour augmenter l’aptitude à suivre des instructions.

Illustration générée par IA

The post Mistral AI change le fond et la forme pour la modération de contenu 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.

Chose promise, chose due : Cloudflare OS est désormais open source.

Cette plate-forme fusionne plusieurs projets internes. Ayant pour principal substrat le service Cloudflare Workers (fonctions sans serveur), elle est présentée comme un « successeur spirituel » de Sandstorm.

De Sandstorm à Cloudflare OS, plus qu’un air de famille

Sandstorm avait émergé en 2014. Il s’agissait d’un serveur d’hébergement d’applications web. Le projet se distinguait par son niveau de granularité : chaque document avait son conteneur. Il s’est cependant heurté aux limites techniques des infrastructures d’alors (démarrage à froid, consommation de mémoire…). La start-up qui le portait n’a, plus globalement, pas réussi à développer son modèle économique, fondé sur la fourniture de fonctionnalités d’entreprise. Début 2017, elle avait transmis Sandstorm à la communauté. Son équipe avait ensuite rejoint Cloudflare. Et s’était mise à travailler sur ce qui deviendrait Cloudflare Workers.

Les unités fonctionnelles de Sandstorm étaient appelées « Grains ». Avec Cloudflare OS, elles deviennent « Gadgets »… et abandonnent les conteneurs à la faveur d’un mécanisme d’isolation plus léger basé sur le moteur JavaScript V8.

Kenton Varda, cofondateur de Sandstorm et aujourd’hui tech lead de Cloudflare Workers, en avait fait une démonstration fin juin à l’AI Engineer World’s Fair. L’initiative ne s’appelait pas encore officiellement Cloudflare OS. Mais elle était, selon lui, devenue « suffisamment sérieuse » en interne pour ne pas la verser immédiatement en open source – alors qu’il l’avait promis au moment de proposer son talk.

L’angle « indie » : permettre à chacun de modifier ses applications

« Cet environnement, il faut le voir comme une suite bureautique », avait expliqué Kenton Varda. Sauf qu’au lieu des documents, il y a des applications : les fameux Gadgets. La logique de partage de ces apps – et de contrôle des accès – est implémentée au niveau de la plate-forme. Pour chacune, le code client tourne dans un iframe qui n’a qu’un canal de communication : du POST vers le cadre parent. La liaison avec le code serveur – instancié sous forme d’objet durable avec sa base SQLite – se fait via une session RPC basée sur le système Cap’n Web, autre brique open source de Cloudflare.

Le runtime workerd sous-jacent étant lui aussi ouvert, il est possible d’exploiter l’ensemble en local, avait affirmé Kenton Varda. L’intéressé avait aussi abordé les possibilités que le modèle de sécurité offrait en matière de vibe coding. Ou plus précisément de personnalisation des applications directement par les utilisateurs, chacun exécutant sa propre copie de l’application. Il en avait donné une illustration en ajoutant, grâce à Claude, la gestion des diagrammes SVG arbitraires et du centrage de texte dans un outil de génération de diapositives.

L’angle B2B : codifier les workflows dans un système agentique

Kenton Varda n’avait pas abordé en long un autre aspect : la connexion de ces applications à des services externes. Cloudflare le fait, désormais qu’il a ouvert la plate-forme. C’en est, en quelque sorte, une v2. La première mouture avait été lancée en interne au mois de mai. Elle permettait d’exécuter, via une UI web, des workflows codifiés sous forme de skills. Ces dernières avaient été développées au préalable, sur la base d’une cartographie des tâches que les employés souhaitaient automatiser. Les résultats s’affichaient dans un panneau latéral au sein du navigateur, sans interaction avec le reste de l’environnement local.

Cloudflare a, dans un deuxième temps, entrepris la connexion à ses autres systèmes. Pour la plupart, il a construit sa propre implémentation de serveur MCP. Il a ainsi pu ajouter des couches de contrôle, comme une limitation du débit par rôle et par région. Une grande partie des flux de travail étant déterministes, il a fini par mettre en place un mécanisme d’inférence à la demande (basé sur son AI Gateway) évitant de réexécuter une skill à chaque session.

Vers une « usine à connecteurs » pour Cloudflare OS

Dans la terminologie de Cloudflare OS, ces serveurs MCP ad hoc sont des « contrôleurs d’accès » (Gatekeepers). Ils comprennent la logique de chaque service et assurent la mise en œuvre des politiques de sécurité lorsque des ressources sont partagées. Il peut s’agir des applications elles-mêmes (avec base de données, historique de conversation, authentifiants, etc.) ou de blueprints (code uniquement).

Les Gatekeepers sont capables de « simuler » le résultat d’actions. On peut ainsi les valider par lots en bout de chaîne, sans que l’agent interrompe son travail à chaque étape.

Cloudflare travaille sur une forme d’« usine logicielle » qui produira des Gatekeepers à partir de documentations API. Il en existe actuellement pour, entre autres, Confluence, GitHub, Google (Gmail, Docs, Sheets, Agenda, BigQuery), Home Assistant, Linear, Notion, Slack, Spotify, Supabase et ZoomInfo. Cloudflare y ajoute un modèle d’implémentation « prêt à l’emploi ». Il permet d’exploiter une version épinglée sans modifier le code source, mais en ayant la main sur les identités, le routage, les intégrations, l’inférence, l’observabilité et le branding.

I paired Cloudflare OS with self hosted deepseek-v4-flash and the result is freakin amazing

Imagine running this setup inside DGX spark, you get fully private work companion solving all your work stuff

The thing about this type of software is it already have a good harness and… https://t.co/gvYHGQnlFe pic.twitter.com/ujcFVAbdbX

— Farhan Helmy (@farhanhelmycode) August 5, 2026

Illustration principale générée par IA

The post Cloudflare OS : un énième environnement de travail agentique ? appeared first on Silicon.fr.

Acheter un PC ou un smartphone coûtera plus cher au second semestre 2026  et la raison tient toujours en un mot : l’IA.

Selon le cabinet d’études taïwanais TrendForce, les fabricants de mémoire réorientent en priorité leurs capacités de production vers les serveurs IA, laissant aux marchés grand public une offre plus contrainte et des prix orientés à la hausse.

Cette bascule s’inscrit dans l’ envolée des investissements des grands CSP qui continuent de tirer vers le haut l’ensemble du marché des serveurs IA.

Sur ce segment, TrendForce estime désormais la croissance à près de 31 % en glissement annuel contre 28 % précédemment.

Trois facteurs expliquent ce rebond.

D’abord un net renforcement de la demande de plateformes rack-scale NVIDIA GB/VR auprès des hyperscalers et des opérateurs de data centers de second rang. Ensuite par la montée en production attendue chez Google et AWS de leurs prochaines générations d’ASIC internes au second semestre 2026. Enfin, par l’accélération du déploiement de solutions IA domestiques chez les CSP chinois pour soutenir leurs services de grands modèles de langage.

Serveurs IA : + 31 % e 2026

Selon les estimations de TrendForce, les dépenses d’investissement (CapEx) cumulées des neuf plus grands CSP mondiaux (Google, Amazon, Meta, Microsoft, Oracle, ByteDance, Tencent, Alibaba et Baidu) devraient dépasser 886,7 milliards $ en 2026, en hausse d’environ 90 % sur un an.

Les cinq hyperscalers nord-américains représentant à eux seuls près de 90 % de ce total. Cette progression reflète la poursuite des investissements dans les datacenters IA, les clusters de GPU, les infrastructures de refroidissement liquide et l’ensemble des équipements nécessaires pour répondre à la demande croissante en IA générative et en modèles à grande échelle.

Google continue de privilégier le déploiement de ses TPU maison sur 2026 et 2027, avec une croissance rapide des volumes attendue en 2027.

AWS mise sur la plateforme GPU NVIDIA GB300 comme solution principale en 2026, tout en développant progressivement ses propres ASIC, dont les volumes devraient encore croître en 2027.

Meta, de son côté, s’appuiera principalement sur les systèmes rack-scale NVIDIA GB/VR et AMD Helios en 2026, avant d’accélérer nettement le déploiement de ses propres ASIC en 2027 dans une logique de réduction des coûts d’infrastructure et d’amélioration de l’efficacité en inférence.

La Chine accélère ses investissements

TrendForce prévoit que les dépenses combinées des quatre principaux CSP chinois ( ByteDance, Tencent, Alibaba et Baidu ) progresseront de plus de 80 % sur un an en 2026.

ByteDance devrait afficher la plus forte hausse, avec des investissements concentrés sur les data centers IA à grande échelle, le développement d’ASIC propriétaires et le déploiement de clusters de GPU.

À l’horizon 2027, TrendForce anticipe que le CapEx cumulé des neuf plus grands CSP atteindra environ 1 300 milliards $, soit une croissance d’environ 50 % sur un an. Le ralentissement du taux de croissance s’expliquerait surtout par un effet de base plus élevé, et ne signalerait pas un essoufflement des investissements en IA.

Les progrès attendus dans l’inférence IA, l’IA agentique, les ASIC sur mesure et les modèles de nouvelle génération devraient continuer à soutenir une demande forte, avec des investissements qui devraient s’étendre au-delà des seuls GPU pour couvrir les serveurs IA, le refroidissement liquide, le packaging avancé, les interconnexions haut débit, les infrastructures électriques et la mémoire.

TrendForce prévoit que la DRAM restera très tendue au troisième trimestre 2026, mais avec des hausses de prix plus modérées : 13 à 18 % pour la DRAM, 10 à 15 % pour la NAND Flash.

La tension perdure, les hausses de prix modérées

Cette demande reste très largement tirée par l’inférence IA et les déploiements de data centers à grande échelle. Les fabricants de mémoire continuent de réorienter leurs capacités de production vers les applications serveur et IA à plus forte marge, au détriment des segments grand public :

• DRAM pour serveurs : les serveurs généralistes basés sur des processeurs x86 et des modules RDIMM restent la plateforme mémoire de référence pour les charges de travail d’IA agentique, en raison de leurs capacités multitâches. Les expéditions de serveurs devraient rester solides jusqu’en 2027, à mesure que la disponibilité des CPU s’améliore, mais le marché restera en situation de sous-approvisionnement au troisième trimestre.
• LPDRAM (mémoire mobile) : les fournisseurs continuent de prioriser les applications liées à l’IA dans l’allocation de leur production, ce qui maintient l’offre de LPDRAM tendue et alimente de nouvelles hausses de prix, au moment où les fabricants de smartphones deviennent plus prudents face à une demande grand public plus faible.
• SSD d’entreprise : les pénuries de CPU ont freiné les livraisons de systèmes, poussant les acheteurs à reconstituer leurs stocks, tandis que les fournisseurs NAND allouent davantage de capacité aux SSD d’entreprise, portés notamment par le déploiement progressif de la plateforme NVIDIA Vera Rubin.
• DRAM graphique (GDDR) : la demande liée à la carte NVIDIA RTX PRO 6000 Blackwell est restée en deçà des attentes, mais les fournisseurs continuent de réorienter leurs capacités vers d’autres produits, ce qui maintient l’offre de GDDR6/7 sous tension et ses prix orientés à la hausse.

À l’inverse, les segments grand public (PC, smartphones, stockage) montrent des signes d’essoufflement. La demande reste faible pour les téléviseurs et boîtiers décodeurs tandis que les stocks élevés des fabricants de PC freinent toute nouvelle hausse sur les SSD.

Par ailleurs,   les prix records de la mémoire commencent à atteindre la limite de tolérance des acheteurs, ce qui contribue à modérer les hausses observées au troisième trimestre

The post Mémoire : l’IA absorbe l’offre, le grand public trinque appeared first on Silicon.fr.

Première bougie soufflée pour le Conseil national de l’IA et du numérique (CIANum).

Le 23 juillet 2025, le Gouvernement avait installé cette nouvelle incarnation du Conseil national du numérique (CNNum). Depuis, elle a produit, entre autres, deux rapports, respectivement au sujet de la souveraineté numérique et de l’IA dans le système éducatif. Elle a aussi publié 5 notes.

Ne dites pas « agents IA », mais « IA agentique »

La première de ces notes, datée de février 2026, traite de l’IA agentique.

Le CIANum suggère de privilégier ce terme à celui d’« agents IA ». Cela évite, estime-t-il, de réduire la discussion à une opposition binaire entre automatisation et contrôle humain.

La note distingue 5 degrés d’autonomie des IA agentiques :

• Automatisation simple fondée sur la reproduction de règles
• Agents capables d’extraire des données ou d’analyser des documents
• Flux de travail agentiques (enchaînement d’étapes dans des processus alternant automatisation de tâches et validation humaine)
• Flux d’agents semi-autonomes (sensibles au contexte et capables de préparer puis de prendre des décisions)
• Agents entièrement autonomes

Le CIANum synthétise quelques avancées technologiques, de l’allongement des fenêtres de contexte aux méthodes de post-entraînement. Il revient sur les limites techniques (effets de cascade, dérive d’orchestration, désalignement sémantique, sécurité des données, etc.) et les enjeux éthiques, sociétaux et juridiques (responsabilités, biais algorithmiques, transparence et intelligibilité des IA…).

Une partie de la note est consacrée au remplacement du travail humain. Le CIANum y constate notamment la lenteur de pénétration de l’IA dans les entreprises lorsque la part des tâches automatisées correspond à moins de 20 % des tâches d’un métier.

Une réaction au lancement de Claude Mythos…

En avril avait suivi une note sur le sujet IA & cybersécurité. Anthropic venait de lancer Claude Mythos, alors ouvert à une quarantaine d’organisations quasi exclusivement américaines.

Projectant un accroissement des corrections de vulnérabilités logicielles, le CIANum s’était inquiété de la potentielle incapacité des SI à suivre le rythme de patching. Il avait aussi appelé à se méfier de la tendance des fournisseurs à vanter la « dangerosité » de leurs modèles si ces derniers venaientà tomber entre de mauvaises mains. Une « manière habile » de susciter l’intérêt du public… et des investisseurs, estimait-il. Et de faire référence, en particulier, au « sommet sur la moralité de l’IA » qu’Anthropic avait organisé avec une quinzaine de membres du clergé catholique.

La note insistait aussi, entre autres, sur le besoin de renforcer les capacités d’évaluation des modèles. Elle soulignait la forte asymétrie d’informations dont la France souffrait par rapport aux écosystèmes britannique, américain et chinois.

… puis à la suspension de l’accès

En juin 2026, une autre note était intervenue après la suspension – unilatérale et sans préavis – de l’accès à Fable 5 et Mythos 5 pour les non-Américains.

Le CIANum y avait perçu une « étape supplémentaire, significative et inédite » vers la généralisation pratique du risque du « kill switch », dans le prolongement de la stratégie de « containment » jusque-là incarnée principalement par les restrictions à l’exportation de puces NVIDIA.

La menace sur l’autonomie numérique européenne est devenue une réalité tangible, avait résumé le CIANum, invitant chacun à « faire et maintenir à jour son analyse de risque ». En écho à sa note précédente, il avait rappelé la grammaire du risque catastrophique voire existentiel dont les GAFAM usent pour justifier l’idée que seule une poignée d’acteurs devraient disposer des technologies les plus avancées.

Dans ce contexte, le CIANum avait appelé à une accélération sur le chantier de la préférence européenne dans la commande publique. Ainsi que sur les mesures de market shaping (portabilité, interopérabilité, incitations fiscales ou réglementaires…).

Un point sur les frictions entre RGPD et IA agentique

La dernière note en date (juillet) aborde l’application du RGPD à l’IA agentique.

Cette dernière, de par son fonctionnement, met sous tension plusieurs principes qu’établit le règlement. Parmi eux :

• Finalité (les capacités généralistes des systèmes d’IA agentique peuvent compliquer l’identification des traitements)
• Licéité (l’autonomie de ces systèmes peut compliquer l’établissement d’un lien entre la base juridique initialement choisie et les opérations réalisées ultérieurement)
• Minimisation (avec la mobilisation de grandes quantités de données et leur partage entre agents, la nécessité des traitements n’est pas toujours évidente à démontrer)
• Exactitude (la nature probabiliste des modèles implique un risque d’erreur qui peut se propager)
• Transparence (sorties difficiles à expliquer)
• Limitation de la durée de conservation (tensions avec la conservation de jeux de données pour l’entraînement et l’amélioration des modèles)

Des difficultés se posent en conséquence sur l’exercice effectif des droits des personnes concernées (accès, rectification, effacement, opposition, limitation du traitement). L’IA agentique amplifie le problème en raison de la multiplication des flux et des espaces de mémoire, dont la synchronisation peut par ailleurs compromettre l’exactitude des données traitées.

Une invitation à mieux cloisonner les systèmes agentiques

Le CIANum pointe aussi la difficulté à apprécier le degré réel de supervision humaine dans le processus décisionnel de ces systèmes. Or, toute personne, en vertu du RGPD, a le droit de ne pas faire l’objet de décisions individuelles automatisées.

L’opacité complique aussi l’attribution des responsabilités. En la matière, l’AI Act n’impose pas de régime exprès. Mais, à travers son approche distinguant les acteurs de la chaîne de valeur, il en instaure une forme.

La circulation continue des données plus globalement des points de faiblesse allant du risque de fuite et de manipulation des données à leur réutilisation non maîtrisée.

La Commission européenne et le CEPD (Contrôleur européen de la protection des données) préparent pour cette année des lignes directrices sur l’articulation RGPD / AI Act.

Du côté du CIANum, on invite à préciser l’encadrement des décisions automatisées et à envisager des mesures de détection/filtrage des usages non prévus ou détournés. On appelle aussi à cloisonner la mémoire des systèmes (à chaque agent la sienne, sans accès automatique aux données des autres agents). Et à limiter leur taille, par exemple en faisant expirer les informations au bout d’un certain temps ou en les remplaçant régulièrement par de plus récentes. La mémoire pourrait même être cloisonnée par traitement afin de limiter le stockage excessif de données.

Protection des mineurs : le ciblage de plates-formes spécifiques déplaît au CIANum

Au milieu de ces notes consacrées à l’IA, le CIANum en publié une dédiée à la protection des mineurs en ligne. C’était en mars 2026. En toile de fond, la proposition de loi ayant pour principal effet d’interdire les réseaux sociaux au moins de 15 ans. L’Assemblée nationale venait de l’adopter en première lecture.

L’Australie avait été le premier pays à voter une telle interdiction, avec une limite à 16 ans. Entrée en vigueur en décembre 2025, elle vise Facebook, Instagram, Kick, Reddit, Snapchat, Threads, TikTok, Twitch, X et YouTube.

Le CIANum adhère peu à cette approche ciblée sur des plates-formes spécifiques. Il redoute un report sur des plates-formes plus obscures. Et de donner l’exemple de Roblox, non assujetti à la loi, mais sur lequel existeraient des dizaines de groupes de plus de 100 000 membres s’échangeant des contenus pédocriminels et sollicitant des actes sexuels auprès des mineurs.

En mars, l’Australie a fait évoluer son approche, par l’intermédiaire de codes de sécurité en ligne. Ils visent des contenus (violence à fort impact, pornographie, promotion du suicide…) et s’appliquent à un large éventail de services (chatbots, magasins d’applications, jeux en ligne, moteurs de recherche…). Objectif : que les enfants vivent des expériences en ligne adaptées à leur âge.

La France a une approche plus restrictive. Sa loi ne vise en l’occurrence que les « services de réseaux sociaux en ligne fournis par une plate-forme en ligne ». Le CIANum regrette qu’elle se prive ainsi de contrôler d’autres plates-formes dont certains contenus peuvent être nocifs. A fortiori à l’heure où « les usages évoluent et se déplacent ».

Contrôle de l’âge : des perspectives autour du portefeuille numérique européen

Pour le contrôle de l’âge, la Commission européenne distingue trois méthodes : l’autodéclaration, l’estimation (par reconnaissance faciale ou croisement de données d’usage, notamment) et la communication de preuves (identifiants physiques ou sources d’identification vérifiées).

L’Australie n’a pas imposé aux plates-formes des méthodes spécifiques. Elle a toutefois exprimé des préoccupations, en particulier à l’égard de Snapchat, qui ne vérifierait pas que la reconnaissance faciale se fait sur des images réelles.

En France, la loi SREN (mai 2024) laisse également le choix aux services qui diffusent des contenus pornographiques. Ils doivent néanmoins respectent les exigences techniques du référentiel associé (publié en octobre 2024).

Allemagne, Danemark, Espagne et Italie ont mis en place des obligations similaires. Les lignes directrices de la Commission européenne complétant le DSA sécurisent la démarche. Des réflexions sont portées autour du portefeuille numérique européen, chaque État membre devant en proposer au moins un au plus tard pour 2026. Une expérience a été lancée dans 5 États membres – dont la France – sur la vérification de l’âge pour l’accès aux réseaux sociaux.

Le CIANum, pas enthousiasmé par les plages horaires de déconnexion

La mise en place d’une règle unique peut interroger, explique le CIANum : les besoins de protection varient en fonction de l’âge et du degré de maturité. Certaines plates-formes profitent de ce débat pour plaider un contrôle au niveau de l’appareil, lors de la création d’un compte sur un magasin d’applications ou via l’OS. Pour le CIANum, cette option est trop extensive au regard du faible nombre de services concernés in fine. Elle pousserait de plus les développeurs des services en question à se soustraire à leurs obligations. Et serait peu compatible avec les outils numériques partagés, par exemple au sein d’un foyer.

Quant à l’idée d’imposer des plages horaires de déconnexion, le CIANum rétorque que le temps passé en ligne ne dit rien des pratiques et des contenus visionnés. Il rappelle que la Corée du Sud avait mis cette technique en œuvre entre 2011 et 2021. Elle l’avait levée en raison de son périmètre trop étroit (jeux en ligne).

L’idée d’un droit global au paramétrage des interfaces

Le CIANum a une autre crainte : que les mesures ciblées sur les mineurs « débrident » les espaces numériques pour les autres utilisateurs. Il en appelle ainsi à un consacrer un droit global au paramétrage des interfaces. Cela passerait par des options de filtrage renforcé. Y compris via des algorithmes conçus par des tiers, parallèlement à des services externes de modération contrôlés et labellisés.

Le DSA impose la fourniture d’informations sur les outils de modération et les principaux paramètres des algorithmes de recommandation. Mais, d’après le CIANum, cela produit des rapports techniques peu lisibles par le grand public ; et qui ne permettent pas de bien saisir les logiques économiques et attentionnelles qui structurent les systèmes.

Le CIANum relance également l’idée de repenser la dichotomie hébergeur/éditeur. Au titre de la directive e-commerce, les réseaux sociaux bénéficient d’un régime allégé : ils ne sont responsables des contenus que leurs utilisateurs publient sauf s’ils en ont eu connaissance effective ou qu’ils n’ont pas agi promptement pour les retirer. Dès 2014, le Conseil d’État avait recommandé de dépasser cette dualité pour consacrer un statut spécifique. Le DSA ne va pas jusque-là, mais distingue, au sein des hébergeurs, les plates-formes en ligne. Et leur impose un régime plus exigeant. La révision du règlement en 2027 pourrait constituer un moment opportun pour passer à une logique de responsabilité, affirme le CIANum.

Souveraineté numérique : gare à la compétition entre territoires

Le rapport sur la souveraineté numérique est paru en mai. Le CIANum y constate un « décalage persistant » entre le discours et la pratique de l’État, dont les services « continuent [en majorité] à recourir massivement aux solutions propriétaires étrangères ».

Au niveau interministériel, la DINUM manque de moyens et de pouvoir contraignant pour imposer une approche unifiée. Le travail en silos se retrouve au niveau des entreprises publiques et des collectivités territoriales. D’autant plus que, d’après le CIANum, l’État a instauré une compétition entre territoires (notamment pour accéder à des financements publics), conduisant chacun à se spécialiser sur un volet numérique.

Des initiatives montrent néanmoins une volonté croissante de coordination avec le privé, reconnaît le CIANum. Il mentionne FranceConnect et ProConnect, « modèles de réussite en matière de gouvernance et de coopération public-privé ». Il évoque aussi la participation de la DINUM à l’initiative Open Interop, que porte le comité stratégique de filière « logiciels et solutions numériques de confiance ».

Inscrire les financements publics dans la durée

Reste que le financement public des communs numériques et du logiciel libre est insuffisant. Y compris au niveau européen, faute de critères adaptés à leur modèle collaboratif.

Autre remarque : les financements ne s’inscrivent pas toujours assez dans la durée. Le CIANum donne l’exemple du programme investissements d’avenir (PIA), qui a financé de nombreux projets sur 18 à 36 mois. D’autres initiatives ont abouti à un « saupoudrage inefficace », à l’image d’ALT-EDIC et du consortium LLM4EU (40 M€ répartis entre 70 acteurs).

Le sous-financement tient peut-être en partie à la confusion entre libre et gratuit. Celle-ci engendre plus globalement des attentes jugées irréalistes en matière de niveau de service.

Une « Fabrique des communs numériques » pour gouverner la demande

Pour concrétiser une gouvernance de la demande, le CIANum souhaite la création d’une « Fabrique des communs numériques ». Elle pourrait notamment associer l’État, la Caisse des dépôts, les associations de collectivités, les DSI des grandes entreprises et les représentants de fournisseurs de solutions et des communautés de mainteneurs.

L’Ariane (Autorité du numérique et de l’IA) assurerait la mise en œuvre de cette structure qui :

• Consoliderait les diagnostics de dépendances
• Élaborerait une cartographie nationale de l’existant, dans la lignée du Socle interministériel de logiciels libres
• Attribuerait un label à des solutions sur étagère répondant à des critères de gouvernance ouverte, d’interopérabilité et de pérennité
• Déclencherait des financements ciblés (via ses partenaires, via des appels à communs ou via un fonds propre dédié aux communs numériques)
• Contribuerait à la gouvernance active de communautés open source
• Rendrait visibles les structures juridiques adaptées aux communs numériques

SCOP, SIEG, SCIC… Des véhicules juridiques mobilisables pour les communs numériques

Parmi les véhicules mobilisables :

• SCOP (sociétés coopératives et participatives)
  Elles ont l’avantage de favoriser un attachement durable aux valeurs initiales du projet, qui ne dépend pas du choix d’un actionnaire majoritaire.
• SCIC (sociétés coopératives d’intérêt collectif)
  Gouvernance multipartite, avec possibilité d’intégrer des acteurs publics et privés en maintenant une finalité de « lucrativité limitée ».
• SIEG (services d’intérêt économique général)
  Permet de financer durablement la maintenance de communs numériques reconnus comme relevant de l’intérêt général, sans les procédures lourdes des marchés publics classiques.
• AAC (appels à communs)
  Identification de défis d’intérêt général et financement d’un consortium qui s’engage à contribuer à un commun partager.
• Fabriques de communs
  Incubateurs sans structure juridique qui lancent des « appels à idées » et sélectionnent des projets faisant alors l’objet d’un appel à intrapreneurs et à partenaires.

Le CIANum suggère aussi d’étudier la transposition en droit français du modèle des fiducies d’utilité sociale. Développées au Québec, elles permettent à des organisations de partager leurs données dans un environnement de confiance avec gouvernance collective.

Au niveau européen, un levier pourrait consister à élargir le mandat du consortium DC-EDIC, avec des missions sur le modèle de celles que la Fabrique des communs numériques endosserait en France.

Au sein de l’Éducation nationale, les usages innovants de l’IA restent dans l’ombre

Le rapport sur l’IA dans le système éducatif a été publié en juin.

Le CIANum y souligne les démarches de la France. Dont un cadre d’usage sur l’IA en éducation « parmi les plus complets à l’échelle internationale en termes d’appréhension de ce que sont les modèles de langage, leurs effets et leur encadrement juridique ». Le « dernier kilomètre » reste toutefois à accomplir. Témoin le nombre d’enseignants formés, « particulièrement faible » comparativement aux autres pays européens. Faute de cadre clair, ceux qui innovent le font dans l’ombre : leurs usages restent peu documentés.

Les outils basés sur l’IA peuvent permettre une personnalisation des parcours et une meilleure inclusion des élèves. Ils peuvent aussi fournir un moyen d’aborder des enjeux sociétaux. Le CIANum en veut pour preuve le programme Internet Sans Crainte. Il organise, de la quatrième au lycée, des « IAckathons » où les élèves imaginent des solutions concrètes intégrant l’IA pour répondre à des défis contemporains.

Sur la personnalisation des parcours, le CIANum cite la plate-forme Lailo, destinée aux enseignants de CP, CE1 et CE2. Elle aide à différencier l’apprentissage de la lecture en fonction de l’avancement de chaque élève.

Face au risque de « démission cognitive », soutenir les designs « socratiques »

Revers de la médaille : les outils à base d’IA posent le risque d’une « démission cognitive ». Sur ce point, le CIANum se réfère notamment à une étude MIT Media Lab à base d’électroencéphalogrammes. Elle a montré que les participants utilisant un LLM pour réviser retenaient nettement moins bien que ceux ayant recours à d’autres méthodes. De là, un appel à privilégier un design « socratique », qui exerce l’esprit critique. Exemple : l’application Khanmigo (non distribuée en France). Elle ne donne jamais la réponse directement, mais guide l’élève par des questions successives. La CIANum suggère de lancer un appel d’offres afin de sélectionner une app de ce type pour le collège et une pour le lycée d’ici à fin 2026.

Autre risque : l’isolation des élèves. On touche ici, en particulier, au biais dit « sycophantique ». Ou comment l’IA dit à l’utilisateur ce qu’il a envie d’entendre. À ce sujet, le CIANum mobilise les constatations d’Oxford et de Stanford : exposés à une IA complaisante, les humains perdent progressivement leur préférence du contact humain pour le soutien émotionnel et l’estime de soi.

Dans le même ordre d’idée, l’ultra-individualisation peut conduire à ne plus soucier du fonctionnement des autres. Un enfant pourrait ne plus avoir la « patience sociale » requise pour tenir compte des conséquences de l’état émotionnel et cognitif de ses interlocuteurs.

Des épreuves orales aux projets collaboratifs, repenser les modalités d’évaluation

Le CIANum avertit : l’accessibilité d’outils comme ChatGPT crée une illusion de simplicité, alors que ces technologies ne sont pas conçues pour un usage éducatif. Il y a aussi illusion de gratuité, alors qu’il est probable que le coût des modèles de langage de qualité croîtra avec les années.

La diffusion de l’IA impose également de repenser les modèles d’évaluation. Entre autres en l’axant davantage sur les processus que sur le résultat, tout en donnant de l’importance à la vérification par oral et aux projets collaboratifs.

La CIANum incite plus généralement à ménager des « temps sans IA » pour garantir la consolidation des savoirs fondamentaux acquis. « Un élève qui sait être fort sans l’IA et qui sait aussi à quel moment et selon quel protocole l’utilisaer sera le mieux préparé à la société qui se dessine », affirme-t-il.

Passer du « référent numérique » au « référent IA »… quitte à changer le titulaire

Opérationnaliser ce principe d’éducation dépendra de la capacité des enseignants à adapter l’usage de l’IA en fonction des objectifs pédagogiques. D’où la recommandation d’établir un programme massif de formation continue. Une évolution immédiate consisterait à généraliser un module dans la LPE (licence Professorat des écoles) et le M2E (master Enseignement et éducation). Sur la partie en ligne, le CIANum préconise de capitaliser sur des ressources comme la MOOC « IA pour et par les enseignants », qu’Inria a conçu. Il suggère aussi de nommer, dans chaque établissement du secondaire, 1 ou 2 enseignants « référents IA ». Y compris en réinterrogeant la fonction de référent numérique, quitte à en changer le titulaire.

Concernant les élèves, le Premier ministre a promis qu’à partir de la rentrée 2027, ils auraient, en classe de seconde, une heure par semaine d’enseignement à l’IA. Le CIANum demande à aller plus loin, pour inclure un programme structuré d’éducation au numérique, à l’IA, aux médias et à l’information, comme il en existe un pour l’éducation à la vie affective, relationnelle et sexuelle. Il conseille aussi de former jusqu’aux médecins scolaires, sur les enjeux de santé mentale et les risques cognitifs. Et d’organiser, à partir de la rentrée 2027, des ateliers sous leur responsabilité.

Illustration générée par IA

The post En un an, qu’a produit le Conseil de l’IA et du numérique ? 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.

Un an. C’est le temps que s’accorde la Commission européenne pour tester grandeur nature une messagerie et un espace de travail collaboratif capables de manier les secrets de la défense continentale. Pour ce test, elle a choisi Thales dont la suite TrustNest R-Suite vient d’obtenir l’homologation qui lui manquait pour se connecter au réseau classifié de l’exécutif européen.

L’affaire touche à un point sensible de l’autonomie stratégique européenne. Comment des ingénieurs, des officiers de programme et des industriels de dix pays différents peuvent-ils coéditer un cahier des charges de missile ou de drone sans que la donnée ne transite, même une seconde, par une infrastructure hors de contrôle européen ?

Depuis sa création en 2021, le Fonds Européen de Défense (FED) est devenu l’un des principaux leviers de Bruxelles pour renforcer l’industrie militaire du continent.

Le dispositif a démarré avec une enveloppe proche de 7,3 milliards € sur la période 2021-2027, revalorisée depuis de 1,5 milliard supplémentaire dans le cadre du réexamen à mi-parcours du budget européen, pour financer notamment les projets rattachés à la plateforme « Technologies stratégiques pour l’Europe ». Le seul exercice 2026 mobilise environ un milliard d’euros répartis sur une trentaine de sujets, du combat aérien à la résilience énergétique en passant par le cyber et l’espace.

Le chaînon manquant de la coopération d’armement

Mais ces projets, souvent pilotés par des consortiums associant grands groupes et PME de plusieurs Etats membres, butaient jusqu’ici sur un angle mort : la coédition de documents et le travail à distance via le cloud. Elément déterminant de la réussite des projets, cette fonctionnalité restait jusqu’alors incompatible avec les exigences de sécurité applicables dès qu’un document relevait de la classification « Restreint Union Européenne » (R-UE/EU-R). Visioconférence, partage de fichiers, coédition en temps réel : ces usages, banals dans n’importe quelle entreprise, restaient impossibles dès qu’un document touchait au secret de défense partagé entre Etats.

L’étape franchie ces derniers jours est réglementaire mais décisive. La Commission européenne et l’Agence nationale de la sécurité des systèmes d’information (ANSSI) viennent de délivrer conjointement l’homologation R-UE/EU-R qui autorise l’interconnexion entre R-Cloud et le réseau classifié de l’exécutif bruxellois. Sans ce feu vert technique, aucune expérimentation grandeur nature n’était possible.

Chez Thales, l’ambition derrière ce pilote d’un an est d’imposer TrustNest R-Suite comme la référence des grands programmes stratégiques, qu’ils soient français ou européens.

L’enjeu dépasse le confort d’usage. Pour les projets financés par le FED, les équipements développés grâce à ces subventions doivent rester libres de toute restriction imposée par des pays tiers, Etats-Unis compris. Une contrainte qui renvoie directement à la réglementation américaine ITAR régissant l’exportation de matériel militaire. Un outil collaboratif hébergé et homologué en Europe devient, dans ce cadre, un argument presque aussi stratégique qu’un radar ou un missile.

Reste à savoir si l’expérimentation confirmera la promesse d’une France capable de transformer une avance réglementaire en avantage industriel durable.

The post Bruxelles teste le cloud sécurisé de Thales pour ses projets d’armement appeared first on Silicon.fr.

Dans la console Bedrock, les modèles Nova Canvas, Reel et Premier ont désormais l’étiquette « Héritage ».

En toile de fond, semble-t-il, un changement de stratégie. Amazon se focaliserait sur un modèle frontière qu’il pourrait présenter fin 2026 lors de sa conférence re:Invent.

L’initiative, apparemment nommée Frontier Model Research en interne, aurait à sa tête Pieter Abbeel. L’intéressé fut, entre autres, codirecteur de l’AI Research Lab à UC Berkeley. Fin 2024, Amazon avait acquis son entreprise Covariant, spécialisée dans la robotique.

Pour accompagner cette réorientation, la division Amazon AGI a été réorganisée. Elle avait été créée en 2023 avec à sa tête Rohit Prasad, vétéran de l’équipe Alexa (directeur machine learning, notamment). Fin 2025, Amazon l’a fusionnée avec les divisions Custom Silicon et Quantum Computing. Peter DeSantis chapeaute l’ensemble. Présent dans l’entreprise depuis une vingtaine d’années, il y fut, entre autres, general manager d’EC2 et SVP infra & support d’AWS.

Dans le cadre de cette réorganisation, Amazon a fermé son labo AGI de San Francisco. Il l’avait mis sur pied fin 2024 après l’acquisition d’Adept AI Labs, start-up que dirigeait un ancien d’OpenAI et de Google Brain.

Une première génération fin 2024…

Les modèles Amazon Nova avaient fait leurs débuts officiels à la re:Invent 2024. Il y en avait alors 5 :

• Micro (texte en entrée et en sortie ; 128k de contexte dont 10k en output)
• Lite (texte, images et vidéo en entrée ; texte en sortie ; 300k et 10k)
• Pro (mêmes caractéristiques de base que Nova Lite)
• Canvas (texte et images en entrée, images en sortie)
• Reel (texte et images en entrée, vidéo en sortie)

En avril 2025, Amazon avait ajouté au catalogue Nova Premier (texte, image et vidéo en entrée ; texte en sortie ; 1M de contexte dont 10k en output). Et Nova Sonic (audio en entrée, texte et audio en sortie ; 300k).

… et une deuxième fin 2025

En octobre 2025, la famille s’était agrandie avec un modèle de vectorisation (Nova Multimodal Embeddings). Les modèles Nova 2 étaient arrivés à la re:Invent 2025 :

• Lite (mêmes modalités que la première génération, mais avec 1M de contexte et un mécanisme de « pensée étendue »)
• Pro (ajout de l’audio en entrée et passage à 1M de contexte)
• Sonic (ajout du texte en sortie et passage à 1M de contexte)
• Omni (texte, images, vidéo et audio en entrée ; texte et image en sortie)

D’une génération à l’autre, Amazon promettait une meilleure adaptation à l’agentique (usage d’outils, raisonnement, gestion du contexte…). Il avait aussi ajouté ancrage web et interpréteur de code en natif.

Nova Omni était – et est toujours – en accès anticipé pour les clients de Nova Forge. Ce service, proposé contre un abonnement annuel, permet de poursuite l’entraînement des modèles Nova à partir de checkpoints, en apportant ses propres jeux de données.

Ce qu’il reste au catalogue Nova

La re:Invent 2025 avait aussi marqué le passage en disponibilité globale de Nova Act. Ce service permet de développer des flottes d’agents pour automatiser les flux UI basés sur le navigateur.

Ôté les modèles marqués « Héritage », la famille Nova comprend actuellement :

• Micro
• Lite (générations 1 et 2)
• Pro (générations 1 et 2, cette dernière étant en preview)
• Sonic génération 2 (la première est marquée « Héritage »)
• Multimodal Embeddings

On les retrouve – à l’exception du modèle de vectorisation – sur le playground Nova.

Bedrock et SageMaker AI proposent diverses options de personnalisation de ces modèles (fine-tuning supervisé, apprentissage par renforcement, distillation…).

Amazon a aussi, en version expérimentale, un modèle dédié à la recherche approfondie : Nova Deep Research.

Illustration principale générée par IA

The post Plusieurs modèles Amazon Nova sont désormais du legacy appeared first on Silicon.fr.

L’IA ne mobilise plus seulement des ingénieurs et des puces électroniques. Elle est aussi un terrain d’innovation financière.

Le Financial Times ( FT) révèle que Google a mis en place un dispositif de financement d’une ampleur inédite, représentant près de 200 milliards $ de contrats, afin de soutenir le déploiement massif de ses puces spécialisées en IA, connues sous le nom de Tensor Processing Units (TPU), historiquement réservées à ses propres usages et développées avec Broadcom..

L’opération dépasse largement le cadre d’une simple relation commerciale entre le troisième hyperscaler mondial et l’inventeur de Claude. Outre Google, elle associe Broadcom, la banque Morgan Stanley et les fonds Apollo et Blackstone. On retrouve aussi plusieurs opérateurs de centres de données dans une architecture financière destinée à financer les infrastructures nécessaires à l’entraînement des modèles d’IA de nouvelle génération.

Selon le quotidien britannique, environ 150 milliards $ du dispositif concernent directement les TPU.

Un modèle inspiré du financement dans l’aéronautique

Le défi est autant financier qu’industriel. Anthropic affiche des besoins de calcul comparables à ceux des plus grands hyperscalers sans disposer de leur capacité financière ni d’une notation de cré

Pour éviter que Google ou Broadcom n’inscrivent des dizaines de milliards de dollars d’équipements à leur bilan, les partenaires ont retenu un modèle inspiré du financement des avions commerciaux.

Le principe est le suivant : Google vend les TPU à Broadcom qui les revend ensuite à un véhicule financier (SPV). Ce dernier est financé par de la dette privée apportée principalement par Apollo et Blackstone. Le SPV loue ensuite les équipements à Anthropic.

Ce mécanisme permet de transformer un investissement massif en contrat de location, tout en répartissant les risques entre plusieurs acteurs financiers.

D’après le FT, la solidité du montage repose précisément sur cette répartition des engagements.

Google garantit les contrats de location des centres de données destinés à accueillir les TPU. Broadcom apporte une garantie sur la valeur résiduelle des équipements. Cela implique que si Anthropic cessait de payer ses loyers et que les puces perdaient de la valeur lors de leur revente, Broadcom couvrirait une partie des pertes des investisseurs les plus exposés.

Morgan Stanley a structuré les véhicules de financement, tandis qu’Apollo et Blackstone apportent l’essentiel des capitaux via des fonds spécialisés dans la dette privée.

Les mineurs de cryptomonnaies changent de métier

L’enquête du quotidien britannique décrit une première opération portant sur 35 milliards $ d’équipements, représentant environ un million de TPU, soit près d’un gigawatt de puissance informatique.

Une seconde vague de déploiement atteindrait 3,5 gigawatts supplémentaires.

Broadcom fait par ailleurs état, dans ses documents financiers, de 128 milliards $ d’engagements d’achat, dont 55,2 milliards doivent être livrés en 2027 et 72,9 milliards en 2028. Des montants qui correspondent aux TPU destinés à Anthropic.

Le financement des puces ne résout toutefois qu’une partie de l’équation. Encore faut-il disposer de centres de données alimentés en électricité pour les exploiter.

Pour accélérer les déploiements, Google s’appuie sur plusieurs entreprises historiquement spécialisées dans le minage de cryptomonnaies, dont TeraWulf, Cipher Digital et Hut 8 qui disposent déjà de capacités électriques importantes, désormais reconverties vers les infrastructures IA.

Selon le FT, Google garantit les loyers des centres de données construits pour Anthropic, permettant d’obtenir des financements obligataires ou bancaires à de meilleures conditions.

Le quotidien identifie cinq projets totalisant 1,4 gigawatt de capacité ayant déjà levé 15 milliards $ de dette, tandis que Google aurait accordé des garanties sur dix projets représentant 2,4 gigawatts.

Chaque acteur prend sa part du risque

Au-delà des volumes de calcul, ce montage pourrait également constituer un avantage concurrentiel pour Google Cloud.

Le FT cite une analyse de Jefferies selon laquelle les projets bénéficiant des garanties de Google empruntent à un taux médian de 7,1 %, contre 9,3 % pour les opérateurs de centres de données bâtissant leurs infrastructures autour des GPU Nvidia.

Cette différence de coût du capital pourrait, selon la banque, devenir un avantage structurel pour l’écosystème Google.

L’enquête met en lumière la financiarisation des infrastructures d’IA. Pour absorber l’explosion des besoins de calcul, les hyperscalers s’appuient désormais sur des montages associant banques, fonds de dette privée, industriels et opérateurs de centres de données.

The post Comment Google finance les infrastructures d’Anthropic appeared first on Silicon.fr.

Le périmètre fonctionnel des solutions SASE continue à s’élargir… au risque d’une « surplateformisation ».

Gartner met le phénomène en avant dans la synthèse du dernier Magic Quadrant dédié à ce marché. Ce n’est pas, et de loin, la première année que le cabinet américain constate la tendance à inclure des briques relevant d’autres segments (NDR et XDR, notamment). Mais jamais il ne l’avait assimilée à une « surplateformisation »… susceptible, selon lui, de détourner l’offre des véritables besoins des acheteurs de SASE.

Toujours est-il que ces derniers utilisent rarement toutes les fonctions des plates-formes SASE. Ils sourcent encore majoritairement à part le réseau (SD-WAN) et la sécurité (SSE ; essentiellement le trio SWG-CASB-ZTNA). L’approche monofournisseur gagne toutefois du terrain (35 % des achats en 2026 selon Gartner, qui table sur 75 % à l’horizon 2029). L’intérêt est par ailleurs croissant pour l’aspect « souveraineté » (où passe le trafic, où s’appliquent les politiques, où se fait le chiffrement, où sont stockés les journaux…).

Fortinet n’est plus « leader » du SASE, Zscaler le devient

Trois des quatre « leaders » de 2025 le restent : Cato Networks, Netskope et Palo Alto. Le quatrième n’est plus Fortinet (qui rétrograde chez les « challengers »), mais Zscaler.

Le Magic Quadrant se structure en deux axes. L’un, dit « exécution », traduit la capacité à répondre à la demande (expérience client, tarification, qualité des produits/services…). L’autre, dit « vision », reflète les stratégies (commerciale, géographique, R&D…).

La situation sur l’axe « exécution » :

Sur l’axe « vision » :

SASE modulaire vs plate-forme unifiée : une « incohérence » chez Cato Networks ?

Cato Networks est « au-dessus de la moyenne » en matière d’expérience client. Il a démontré sa capacité à répondre aux tendances du marché (zero trust « universel », sécurité DNS sans agent, macrosegmentation des réseaux locaux…). Gartner apprécie aussi ses avancées dans la prévention des vulnérabilités agentiques.

Outre un profil financier que Gartner dit moins favorable que chez la plupart des autres fournisseurs, Cato Networks tend à être plus cher. Le cabinet américain relève aussi une « incohérence » entre la proposition de valeur de sa plate-forme unifiée et la tendance à aller vers du SASE modulaire.

La sécurité de l’IA pousse Netskope à la « surplateformisation »

Gartner salue la profondeur fonctionnelle de l’offre de Netskope, robuste en particulier sur le SD-WAN, les contrôles inline, la visibilité du SaaS et l’accès adaptatif. Bons points également pour l’expérience client (« au-dessus de la moyenne ») et l’infrastructure de points de présence.

Comme Cato Networks, Netskope n’est pas à son avantage sur la tarification. Ni d’ailleurs sur le profil financier. Gartner estime aussi qu’il se concentre trop sur la sécurité de l’IA, favorisant la fameuse « surplateformisation ».

Palo Alto Networks, limité sur la partie on-prem…

Palo Alto Networks a un profil financier plus favorable. Il fait preuve d’une compréhension « solide » des dynamiques du marché (simplification des solutions, contrôles souverains, cryptographie post-quantique…). Gartner salue aussi ses avancées sur la sécurisation du trafic agentique et la gestion assistée par IA.

Comme Cato Networks et Netskope, Palo Alto Networks est dans le haut du panier en matière de tarification. En termes d’expérience client, il est « sous la moyenne ». Quant à ses options de sécurité on-prem, elles sont plus dépendantes du cloud – en particulier pour l’IPS et le filtrage de contenu – que chez les autres fournisseurs.

… comme Zscaler

Profil financier également favorable pour Zscaler, qui se distingue aussi sur son infrastructure de points de présence. Gartner apprécie aussi les avancées sur le réseau, la gestion assistée par IA et l’extension du zero trust aux agents.

Comme Palo Alto Networks, Zscaler est « sous la moyenne » en matière d’expérience client. Lui aussi est plus limité que les principaux concurrents sur la partie on-prem, tant pour le réseau que pour la sécurité. Il est par ailleurs arrivé relativement tard sur le segment du SASE monofournisseur, et tend à se focaliser davantage sur les cas d’usage axés sécurité.

Illustration générée par IA

The post Le SASE, un marché sujet à « surplateformisation » appeared first on Silicon.fr.

Assurez-vous de maintenir, au fil du temps, au moins 90 % de la performance mesurée à l’installation.

La Commission européenne le demande aux consortiums qui répondront à l’appel d’offres pour les « gigafabriques d’IA » (AI gigafactories).

Les propositions peuvent être soumises jusqu’au 12 novembre 2026. Il existe deux lots, respectivement pour les gigafabriques « d’échelle moyenne » (medium-scale) et « de grande échelle » (large-scale). Les premières devront atteindre, à terme, au moins 75 000 accélérateurs en équivalent H100. Les secondes, au moins 100 000.

Dans l’un et l’autre cas, il y aura une phase de déploiement initial puis une phase d’extension.

La première phase, censée durer 18 mois maximum, devra permettre de déployer au moins 25 000 accélérateurs dans les gigafabriques d’échelle moyenne et 40 000 dans celles de grande échelle.
Bruxelles se projette sur un horizon de 5 ans pour boucler la deuxième.

EuroHPC et 18 États membres – dont la France – acquerront conjointement des capacités de calcul, avec des contrats spécifiques pour chaque phase.

Deux échelles de gigafabriques… et de financement

Pour le lot 1 (gigafabriques d’échelle moyenne), EuroHPC sélectionnera jusqu’à 4 projets. En phase 1, chacun bénéficiera au maximum de 100 M€ de financements européens. Trois leviers seront mobilisés :

• Mécanisme pour l’interconnexion en Europe
• Programme pour une Europe numérique
• Programme-cadre d’Horizon Europe pour la recherche-innovation

Les États membres devront apporter un financement au moins équivalent.

Même logique de parité pour la phase 2, avec une enveloppe maximale par projet néanmoins portée à 400 M€… sous réserve de la disponibilité de fonds via le prochain cadre financier pluriannuel de l’UE (2028-2034).

Pour le lot 2 (gigafabriques de grande échelle), EuroHPC sélectionnera jusqu’à 3 projets. L’UE apportera au maximum 200 M€ par projet en phase 1 ; 800 M€ en phase 2. Dans tous les cas, sa part se limitera à 17 % du capex IT des projets.

La France s’engage sur l’échelle moyenne

Pour les gigafabriques d’échelle moyenne, l’exigence initiale est un mix à 50-50 entre services IaaS/PaaS et MaaS (répartition modulable, de 10 points maximum). Est attendue, à terme, uns puissance informatique d’au moins 120 MW.

8 pays se sont positionnés pour en accueillir. La France en fait partie. Elle s’engage à investir jusqu’à 100 M€ (avec un complément de 10 M€ de l’Irlande).

La Finlande est aussi sur les rangs. Elle a le soutien de l’Estonie, de la Lettonie et de la Suède. Toutes trois postulent pour héberger non pas une gigafabrique, mais un site annexe à celle qui serait implantée en Finlande.

L’UE permet de prétendre à un financement pour ces sites annexes, qui devront remplir une « fonction essentielle » de type sauvegarde, équilibrage de charge ou fourniture de nœuds spécialisés.

Les États membres devront avoir finalisé leurs engagements d’investissement au plus tard 6 semaines avant la clôture de l’appel d’offres. Récapitulatif de leurs engagements actuels :

5 pays positionnés pour les giga-fabriques à grande échelle

Pour les gigafabriques à grande échelle, l’exigence initiale est un mix de 60 % IaaS/PaaS pour 40 % de MaaS. Puissance informatique attendue à terme : au moins 150 MW.

Cinq pays se sont positionnés, tous pour accueillir une gigafactory, avec un investissement de 200 M€ en phase 1  :

• Allemagne (800 M€ provisionnés pour la phase 2)
• Espagne (promesse d’investir au moins 50 M€ sur la phase 2)
• Grève (150 M€ provisionnés pour la phase 2)
• Italie (200 M€ provisionnés pour la phase 2)
• Portugal (en lice pour éventuellement un site annexe)

Tous projets confondus, l’enveloppe théorique globale se monte donc à 10 Md€ de financements publics. La Commission européenne estime que l’initiative devrait permettre de mobiliser au moins le double en fonds privés.

L’Europe fixe ses SLA

Le formulaire de candidature liste quelques attentes, comme l’intégration avec les data spaces sectoriels et l’établissement d’une feuille de route pour mettre en œuvre une pile logicielle européenne (cloud + IA) dans un délai de 4 ans après le déploiement initial. Les candidats sont aussi invités à envisager l’introduction de hardware européen au minimum à partir de la phase 2.

Au-delà de l’exigence de maintenir au moins 90 % de la performance initiale, Bruxelles leur demande :

• 99,5 % de taux de disponibilité pour l’entraînement et 99,9 % pour l’inférence (hors maintenance planifiée)
• Un RTO de 4 heures et un RPO d’une heure
• Un objectif de 100 % de disponibilité pour la connectivité externe, avec pas plus de 3 jours de maintenance par an
• En inférence, une latence P95 ≤ 300 ms pour les workloads standards

Pour le support standard, ce sera du lundi au vendredi, de 8 à 18 heures en local, avec une réponse sous 30 minutes. Pour les services critiques, du 24/7 avec réponse sous 10 minutes. En cas d’incident critique :

Le préavis devra être d’au moins 7 jours pour la maintenance planifiée et 4 jours pour la maintenance ad hoc.

Une évaluation en deux temps

EuroHPC confiera l’évaluation des offres à un panel de « 5 à 7 experts indépendants ». L’attribution des contrats se fera dans l’ordre de classement, jusqu’à épuisement du budget combiné de l’UE et des États membres. Les propositions non sélectionnées pourront aller, pour 2 ans maximum, sur une liste d’attente. Et bénéficier, dans cet intervalle, de financements si l’UE en débloque.

L’évaluation se fera en deux parties. La première se portera sur la qualité technique des projets (40 % de la note), leur impact stratégique (20 %) et leur viabilité financière (40 %).

La mathématique du critère d’échelle

Le score obtenu sur la première partie constituera 50 % de la note globale. Le reste sera divisé à parts égales entre « échelle / qualité de service » et « rapport coûts-bénéfices ».

Le critère d’échelle dépend du volume d’accélérateurs que le projet prévoit d’atteindre.

Un tableau d’équivalence entre accélérateurs

Le scoring de la qualité de service se fait à parts égales entre les couches IaaS/PaaS et MaaS.

L’évaluation du rapport coûts-bénéfices se fonde sur le calcul d’un prix normalisé par accélérateur pour chaque couche de services.

L’équivalence H100 suit les indices suivants :

Illustration générée par IA

The post AI gigafactories : les détails de l’appel d’offres appeared first on Silicon.fr.

Amendes à 15 millions €, accès au code source, pouvoir d’enquête sur les modèles les plus secrets du monde : depuis ce 2 août, l’AI Office cesse d’être un simple bureau d’études pour devenir un véritable gendarme des modèles d’IA jugés à « risque systémique ».

Ce gendarme-là n’a pourtant rien d’improvisé. La structure existe depuis le 24 janvier 2024 pour disposer d’un organe capable de coordonner la mise en œuvre de l’AI Act et d’apporter une expertise technique et de gouvernance spécialisée. Deux ans et demi de rodage, en somme, avant de recevoir enfin ses vrais pouvoirs de police.

Car son rôle ne se limite pas à la répression. L’AI Office fait également office de voix institutionnelle de l’UE sur les politiques d’intelligence artificielle, représentant la Commission dans les grandes enceintes internationales (OCDE, G7, G20, Conseil de l’Europe, ISO/IEC) ou encore le réseau international réunissant les instituts nationaux chargés d’évaluer les risques des modèles d’IA les plus avancés.

Ce que l’AI Office peut exiger

Dans le cadre de sa mission, l’AI Office dispose de trois leviers principaux.

Il peut d’abord exiger des développeurs des modèles d’IA les plus puissants au monde la transmission de toute documentation nécessaire à l’évaluation de leur conformité. L’article 91 du règlement lui permet de réclamer l’ensemble des documents qu’un fournisseur a dû produire au titre des articles 53 et 55 du texte ; documentation technique, évaluation des capacités, analyses de risques ou toute information additionnelle jugée nécessaire.

L’AI Office peut ensuite commander des évaluations indépendantes de ces modèles, y compris un accès au code source, en s’appuyant si besoin sur des experts extérieurs mandatés pour agir en son nom.

Enfin, il peut imposer des amendes pouvant atteindre 3 % du chiffre d’affaires mondial annuel de l’entreprise, ou 15 millions €, le montant le plus élevé étant retenu, en cas de non-conformité. Refuser de répondre à une demande de documentation ou fournir des informations incorrectes, incomplètes ou trompeuses, constitue en soi un motif de sanction.

Au niveau national, ce sont les autorités de surveillance du marché de chaque État membre qui prennent le relais pour les autres systèmes d’IA.

En France, c’est la CNIL qui a été désignée comme autorité de référence pour l’application de l’AI Act en France. Une compétence acquise après un an et demi d’arbitrage. Une quinzaine d’autorités sectorielles l’épaulent selon le domaine concerné : la DGCCRF pour les pratiques commerciales trompeuses, l’Arcom pour l’audiovisuel et les deepfakes, l’ACPR et l’AMF pour la finance, l’ANSM et la HAS pour la santé.

Une équipe de 145 experts

Pour tenir ce rôle, l’AI Office promet 38 recrues de plus. De quoi porter ses effectifs à 145 personnes ; dont 34 sur la réglementation et la conformité, et 38 rien que pour surveiller la sécurité des modèles les plus avancés. Un chiffre qui reste modeste au regard de l’ampleur de la tâche.

Autour de l’AI Office gravitent également d’autres instances comme l’AI Board, le comité scientifique (Scientific Panel) et le forum consultatif (Advisory Forum), chargés d’orienter et de conseiller la gouvernance globale de l’AI Act.

Au-delà des pouvoirs d’enquête classiques, la Commission a mis en place des instruments pour faire remonter l’information : un outil dédié aux lanceurs d’alerte permettant aux salariés du secteur technologique de signaler des manquements et un outil de conformité destiné aux utilisateurs souhaitant alerter confidentiellement les autorités sur des comportements jugés illégaux.

Illustrations : © DR

The post AI Office : qui sont les gendarmes de l’IA au sein de l’UE appeared first on Silicon.fr.

Fini de subir en silence les story-times lénifiants et les « Voici comment j’ai pris une leçon de vie en commandant un café ».

Depuis fin juillet, les membres de LinkedIn peuvent signaler, d’un clic, les publications qui sentent le contenu produit à la chaîne par une IA…les fameux  » AI Slop ». Le réseau social professionnel, propriété de Microsoft, a déployé un nouveau bouton de signalement baptisé « Seems like AI slop » ; littéralement « on dirait de la bouillie IA ».

L’initiative intervient alors que plusieurs études convergent pour dresser le même constat : LinkedIn est devenu, plus que n’importe quel autre réseau social, le terrain de jeu privilégié des contenus générés par des LLM.

Selon l’étude « AI in Your Feed » de la société Pangram, qui a passé au crible plus d’un million de publications entre fin avril et fin juin 2026, plus de 40 % des posts longs publiés sur la plateforme sont intégralement générés par IA.

Il s’agit du taux le plus élevé de tous les réseaux étudié, et environ le double de la moyenne constatée ailleurs. D’autres études confirment cette « invasion de AI Slop » sur le réseau professionnel, propriété de Microsoft.

LinkedIn… au royaume du « AI Slop »

Comment utiliser. la nouvelle fonctionnalité ? L’option apparaît dans le menu à trois points de chaque publication. Un clic suffit pour masquer le post du fil de l’utilisateur, accompagné d’un message de remerciement indiquant que ce retour contribue à améliorer le fil d’actualité.

Le signalement ne déclenche ni suppression du contenu ni sanction visible pour son auteur.  Dans le vocabulaire de LinkedIn, d’un simple signal, traité de façon comparable à un clic « pas intéressé »  qui vient nourrir les modèles de détection automatique de la plateforme.

Coup de pouce supplémentaire côté transparence : LinkedIn teste désormais une notification privée, visible uniquement par l’auteur dans son tableau de bord analytique, lorsque plusieurs membres jugent qu’une publication sonne artificielle ou trop assistée par IA.

C’est Hari Srinivasan, chief product officer de LinkedIn, qui a annoncé la mesure dans un message publié sur son compte. Le dirigeant constate l’ampleur du problème : « AI slop is a top priority for all of us. We really care about this », écrit-il, rappelant que « les gens viennent sur LinkedIn pour se connecter avec de vraies personnes et partager leurs véritables points de vue ».

Et de justifier le choix de s’appuyer sur les retours humains plutôt que sur la seule détection automatique. Selon lui, la notion de « AI slop » reste difficile à cerner et évolue sans cesse, ce qui rend précieux l’apport des signalements des membres pour affiner les modèles. Il tient aussi à préciser que l’usage de l’IA n’est pas condamné en soi car nombre d’utilisateurs s’en servent légitimement pour retravailler leurs idées. Ce que LinkedIn veut limiter, ce sont les contenus qui « sonnent inauthentiques ».

Comment fonctionne le signalement

Le bouton n’est que la partie visible d’un dispositif plus vaste.

LinkedIn affirme bloquer chaque jour des centaines de milliers de tentatives de commentaires automatisés, et avoir contré des milliards d’autres tentatives d’automatisation (publication en masse, spam) ces deux derniers mois. Le réseau met aussi en avant de nouveaux classificateurs internes, chargés d’identifier en amont les contenus jugés « AI slop » ou de faible qualité afin d’en limiter la visibilité dans les recommandations adressées aux utilisateurs situés hors du réseau immédiat de l’auteur.

Autre choix marquant : la disparition de la fonctionnalité « Enhance your post », qui proposait jusqu’ici de réécrire intégralement un brouillon grâce à l’IA. Elle cède la place à un outil de relecture plus modeste, limité à la correction orthographique et grammaticale, sans réécriture ni lissage stylistique. LinkedIn annonce en parallèle un renforcement des outils de vérification de profils et de pages, ainsi qu’une nouvelle option permettant de bloquer les commentaires de pages d’entreprise indésirables.

Les limites d’un système encore jeune

Le dispositif n’est pas sans zones d’ombre. LinkedIn ne communique aucun mécanisme permettant à un auteur de contester un signalement, ouvrant la porte à d’éventuels usages abusifs ou concurrentiels du bouton.

La frontière entre une aide légitime à la rédaction et la production de « AI slop » demeure par ailleurs difficile à tracer, ce qui expose certains contenus authentiques mais stylistiquement proches de l’IA à un déclassement injustifié. Enfin, plusieurs mois pourraient s’écouler avant que leurs effets soient pleinement perceptibles dans les fils d’actualité.

Cette annonce intervient au moment où une nouvelle tranche de l’AI Act entre en application, dont certaines dispositions relatives à l’étiquetage des contenus générés par IA ; même si LinkedIn n’est pas tenu, à ce stade, d’imposer un label systématique sur les publications de ses utilisateurs.

Pour les créateurs de contenu, communicants et experts qui font de LinkedIn une vitrine, le message envoyé par la plateforme est sans ambiguïté : le volume et la régularité automatisée ne suffisent plus à garantir de la visibilité.

L’algorithme valorise désormais davantage les analyses fondées sur une expertise réelle, les angles originaux et une voix éditoriale reconnaissable, au détriment des textes lissés et sans point de vue propre. L’IA reste un outil d’appoint toléré ( pour relire, structurer, synthétiser) mais son usage comme générateur intégral de publications expose désormais à une perte sèche de portée organique.

Image : © DR

The post LinkedIn dégaine son bouton anti « Slop IA » appeared first on Silicon.fr.

C’est de saison : il existe désormais un Magic Quadrant des « infrastructures cloud pour l’IA ».

L’issue était prévisible. Le dernier Magic Quadrant du cloud public d’infrastructure (IaaS + PaaS), paru à l’été 2025, avait donné le ton. Gartner y avait largement mis en avant la composante IA, de la dépendance de Microsoft à OpenAI au manque de compétitivité des modèles génératifs d’AWS.

En parallèle, le Magic Quadrant des « services cloud d’IA pour les développeurs » avait laissé place à celui, plus englobant, des « plates-formes de développement d’applications IA ». La majorité des fournisseurs classés dans l’un s’étaient retrouvés dans l’autre.

OVHcloud en « challenger », Scaleway en « acteur de niche »

Chose rare dans un même Magic Quadrant : la présence de deux fournisseurs français.

OVHcloud est suffisamment avancé sur l’axe dit « exécution » (qui reflète la capacité à répondre à la demande) pour se hisser chez les « challengers ». Gartner apprécie un avantage singulier dans le paysage concurrentiel : l’absence de frais de sortie. Il salue également la maîtrise qu’OVHcloud a sur la fabrication de ses serveurs ; ainsi que, plus globalement, son activité désormais profitable.

OVHcloud n’a pas les capacités réseau avancées de ses principaux concurrents. Ce qui limite les possibilités pour les workloads distribués. Il lui manque aussi des fonctionnalités de gestion opérationnelle, notamment pour la gouvernance des coûts. Il n’a pas non plus le même catalogue d’options serverless, de services MLOps et d’intégrations PaaS. Cela peut supposer des efforts d’intégration supplémentaires.

Par rapport aux autres fournisseurs classés « acteurs de niche », Scaleway a un portefeuille plus diversifié (VM, bare metal, PaaS, serverless…). Gartner y voit un moyen de minimiser la latence et les coûts de transfert entre « composants IA et non IA ». Il salue aussi des datacenters efficaces sur le plan énergétique. Et la disponibilité de services managés (Kapsule, Managed inference…) qui réduisent le besoin en compétences MLOps.

Scaleway n’a de régions cloud qu’en Europe : difficile de le sélectionner pour des workloads globaux qui nécessitent une faible latence. Comme pour OVHcloud, la gamme PaaS native et le catalogue d’intégrations sont moins fournis que chez les principaux hyperscalers. Par ailleurs, si la tarification de base est « transparente », la facturation séparée du stockage, des instances et de la bande passante peut compliquer la gestion des coûts.

17 fournisseurs, 6 « leaders »

Gartner dégage 6 « leaders » sur ce segment des infrastructures cloud pour l’IA. Nommément, Alibaba Cloud, AWS, Google, Huawei Cloud, Microsoft et Oracle.

Sur l’axe « exécution », la situation est la suivante :

Sur l’axe « vision », qui traduit les stratégies (commerciale, marketing, innovation…) :

Interface et documentation complexes chez Alibaba Cloud

Alibaba Cloud se distingue par l’exhaustivité de son portefeuille, entre infra, outils de développement et modèles de fondation. Gartner apprécie la capacité de la plate-forme PAI-Lingjun à soutenir des workloads à grande échelle sur des architectures hétérogènes. Il mentionne aussi l’outillage open source d’Alibaba Cloud (EasyNLP, EasyCV, PAI-DSW, SONiC…) et le support communautaire qui va avec. Ainsi que la popularité des modèles open-weight Qwen.

Au-delà des inquiétudes de conformité et de souveraineté que peuvent soulever la nationalité chinoise d’Alibaba, l’interface et documentation peuvent s’avérer plus complexes à maîtriser que chez les concurrents américains. La situation géopolitique le prive par ailleurs de l’accès à certaines technologies, à commencer par des puces accélératrices.

AWS n’a pas l’architecture d’entraînement la plus efficace

AWS peut s’appuyer sur une infrastructure cloud mature dont Gartner souligne le reach, la résilience et le niveau de sécurité/conformité (il cite, sur ce point, l’hyperviseur Nitro et la certification ISO 42001). Bon point également pour la variété des options d’infrastructure managée, de Bedrock à SageMaker HyperPod.

Revers de la médaille : cette variété, avec les niveaux d’abstraction, de contrôle et de responsabilité qu’elle implique, peut compliquer la standardisation à l’échelle des organisations. AWS a plus globalement du mal à inscrire ses services dans un narratif clair et cohérent, selon Gartner. Les cycles de déploiement peuvent s’en trouver allongés. Le cabinet américain note aussi que l’architecture du réseau et des clusters d’entraînement est moins efficace que chez d’autres fournisseurs. Le recours à ses puces Trainium peut en outre supposer des efforts d’optimisation logicielle.

Un risque de verrouillage chez Google…

Au-delà de ses TPU, Google se distingue avec l’architecture AI Hypercomputer, qui associe ces puces aux GPU en une architecture avec réseau et stockage optimisés. Gartner relève aussi les ressources disponibles : il estime qu’au quatrième trimestre 2025, Google possédait environ 25 % de la capacité de calcul IA mondiale.

Cela n’empêche pas que l’accès à cette capacité – plus particulièrement les GPU NVIDIA – peut se révéler difficile. De plus, bien que Google ait étendu sa prise en charge de frameworks comme Jax et PyTorch, l’optimisation pour les TPU est susceptible de compromettre la portabilité des charges de travail. Attention aussi à la tarification : la combinaison de la facturation au token, des coûts d’infrastructure, des choix de déploiement et des modèles d’engagement peut compliquer l’attribution et la prévision des coûts.

… comme chez Huawei

Huawei a l’avantage de maîtriser sa pile (NPU Ascend, CPU Kungpeng, architecture CANN, framework MindSpore) et par là même son rapport coût-performance. Il a aussi pour lui son studio de développement ModelArts, qui favorise une approche par cas d’usage à partir de jeux de données sectoriels pour ajuster les modèles Pangu. Gartner apprécie aussi la mesure dans laquelle il a inscrit dans sa stratégie commerciale les déploiements hybrides et privés.

Comme pour Alibaba Cloud, la nationalité chinoise de Huawei est un obstacle à l’adoption de ses technologies, en tout cas dans le monde occidental. Quant à sa stack maison, elle est susceptible de créer un verrouillage. Ou tout au moins d’accroître la courbe d’apprentissage pour qui est habitué à des standards comme CUDA. Vigilance également sur l’empreinte géographique de l’infrastructure IA, plus limitée que chez les autres hyperscalers.

Chez Microsoft, attention à la gouvernance des coûts

Gartner salue la « proposition de valeur unique » que Microsoft s’est construite dans la GenAI à renfort de partenariats. Il fait aussi remarquer le liant créé entre son infrastructure IA et le reste d’Azure. Ainsi que l’exhaustivité du catalogue de services managés. Il mentionne, à ce sujet, Microsoft Foundry et Azure AI Landing Zone, qui réduisent le besoin en compétences MLOps.

Comme les autres hyperscalers, Microsoft fait face à des contraintes d’approvisionnement de capacité. S’il a lui aussi ses propres accélérateurs IA (Maia, pour l’inférence), elle ont pour le moment une place limitée dans son offre, encore largement dépendante de puces tierces. Et les couches de services qui composent son catalogue compliquent la gouvernance et la prévision des coûts.

L’outillage d’Oracle manque de maturité

Oracle se distingue par la performance et l’élasticité de son architecture OCI Supercluster. Bon point également pour la flexibilité de déploiement (Dedicated Region, Cloud@Customer, Oracle Database@…). Et pour l’intégration avec ses autres produits (Oracle Fusion Cloud Applications, AI Data Platform, Autonomous Database…).

Oracle propose moins d’intégrations et de ressources communautaires que ses concurrents ; ce qui peut imposer des développements personnalisés. Si l’infra IA est robuste, l’outillage pour la gérer (orchestration, observabilité…) est moins mature et moins complet. Il peut par ailleurs être délicat de parcourir la documentation. Et les temps de réponse du support peuvent varier.

Illustration générée par IA

The post Infrastructures IA : Gartner met OVHcloud et Scaleway sur sa carte mondiale appeared first on Silicon.fr.

Au 2 août 2026, l’essentiel des dispositions de l’AI Act entreront en application.

C’était l’objectif de l’UE lorsqu’elle avait adopté le règlement, en juin 2024. Depuis, l’omnibus numérique est passé par là. Il a repoussé les principales échéances à 2027 et 2028.

En toile de fond, le retard pris sur deux fronts. D’une part, dans la mise en place des autorités nationales compétentes. De l’autre, dans l’élaboration de normes harmonisées et de spécifications communes. Le CENELEC (Comité européen de normalisation en électronique et électrotechnique) en a la charge. Il était initialement censé rendre sa copie pour août 2025.

Quelques obligations s’appliqueront tout de même à partir du 2 août 2026. Nous les récapitulons ici, ainsi que le reste du calendrier, en combinant la lecture de l’AI Act à celle des lignes directrices, des codes de bonnes pratiques et d’autres instruments que la Commission européenne a publiés.

Quelques concepts structurants de l’AI Act

Modèles d’IA vs systèmes d’IA

Une partie des dispositions de l’AI Act (articles 51 à 55) concernent spécifiquement les modèles d’IA à usage général.

Au-delà de la définition qu’en donne le règlement, les lignes directrices associées détaillent quelques critères indicatifs. Est réputé à usage général un modèle dont l’entraînement a nécessité au moins 10²³ flops (seuil de puissance de calcul typique pour former des modèles d’échelle 1B, selon Bruxelles) et qui est capable de générer un langage ou de produire une image ou une vidéo à partir de texte.

Des exceptions sont possibles, typiquement en cas d’incapacité à exécuter un large éventail de tâches distinctes (modèle spécialisé dans l’accroissement de la résolution d’images, par exemple).

La définition que l’AI Act donne du « système d’IA » s’assortit elle aussi de lignes directrices. Elles reprennent in extenso chaque aspect-clé (autonomie, capacité d’adaptation, inférence, etc.). Et formulent quelques exclusions. Parmi elles, les systèmes destinés à accélérer les méthodes d’optimisation traditionnelles (comme la régression linéaire ou logistique), ceux fondés sur l’heuristique classique et ceux traitant des données de base (SGBD filtrant des données sur la base de critères spécifiques, outil de visualisation constituant un tableau de bord par l’emploi de méthodes statistiques…).

Fournisseurs vs déployeurs

Est fournisseur toute personne physique ou morale ou tout organisme qui développe ou fait développer un système ou un modèle et le met sur le marché ou le met en service sous son propre nom ou sa propre marque.

Est déployeur qui utilise un système sous sa propre autorité (les activités personnelles n’entrent pas dans le champ de l’AI Act).

Le règlement définit aussi les rôles d’importateur et de distributeur. Le premier met sur le marché un système qui porte le nom ou la marque d’une personne physique ou morale établie hors UE. Le second fait partie de la chaîne d’approvisionnement qui met un système à disposition dans l’UE.

Par « mise sur le marché », il faut entendre la première mise à disposition d’un système d’IA ou d’un modèle d’IA à usage général dans l’UE.
La mise en service ne concerne que les systèmes d’IA. Il s’agit de la fourniture d’un système en vue d’une première utilisation dans l’UE, directement au déployeur ou pour un usage propre.

Haut risque vs risque systémique

Le règlement définit quels systèmes d’IA sont à haut risque. Parmi eux, ceux qui figurent à l’annexe III. Domaines concernés, dans les grandes lignes :

• Biométrie (identification à distance, catégorisation, reconnaissance des émotions)
• Composants de sécurité d’infrastructures critiques
• Éducation et formation professionnelles (admission, évaluation d’acquis, détection de tricherie…)
• Emploi (recrutement, évolution professionnelle…)
• Accès à des services privés et publics essentiels (aides sociales, évaluation de solvabilité, hiérarchisation des interventions d’urgence…)
• Répression
• Migration, asile, gestion des contrôles aux frontières
• Administration de la justice et processus démocratiques (interprétation de la loi, influence sur le comportement électoral…)

Il existe, pour ces systèmes, des exceptions en cas d’absence de risque important de préjudice pour la santé, la sécurité ou les droits fondamentaux. Ce cas peut se présenter, par exemple,  lorsqu’il y a accomplissement d’une tâche procédurale étroite ou amélioration d’une activité humaine préalablement réalisée.

« Composants de sécurité » et « législation d’harmonisation »

Est également à haut risque un système qui remplit les deux conditions suivantes :

• Destiné à être utilisé comme composant de sécurité d’un produit couvert par la législation d’harmonisation de l’UE (ou constitue lui-même un tel produit)
• Ce composant, ou le système lui-même en tant que produit, est soumis à une évaluation de conformité par un tiers conformément à la législation d’harmonisation

Cette « législation d’harmonisation » regroupe des directives et règlements sectoriels. L’AI Act en liste, dans son annexe I, une vingtaine, qui ciblent les jouets, les ascenseurs, les dispositifs médicaux, les équipements marins, l’aviation civile, etc.

L’omnibus numérique a précisé la notion de « composant de sécurité » pour éviter que des systèmes d’IA soient faussement classés à haut risque. Il a, en particulier, exclu ceux destinés à remplir uniquement des fonctions liées à l’assistance aux utilisateurs, à l’optimisation des performances, à l’efficacité des services ou encore à l’automatisation.

Autre précision : l’intégration d’un système d’IA dans un produit soumis à la législation d’harmonisation ne signifie pas nécessairement qu’il est un composant de sécurité.

Caractériser le risque systémique sur les modèles d’IA

Des dispositions spécifiques s’appliquent aux modèles d’IA à usage général qui présentent un risque dit systémique. On peut l’atteindre en la présence de « capacités à fort impact ». En l’occurrence, au moins égales aux capacités enregistrées dans les modèles les plus avancés. Il y a risque systémique en l’existence d’effets négatifs réels ou raisonnablement prévisibles sur la santé publique, la santé et les droits fondamentaux et qu’ils peuvent se propager sur la chaîne de valeur.

Les lignes directrices sur les modèles d’IA à usage général donnent un critère indicatif : 10²⁵ flops. Si l’entraînement a nécessité plus de puissance de calcul, on peut présumer un risque systémique. La Commission européenne peut aussi décider qu’il en existe un en examinant les critères listés à l’annexe XIII de l’AI Act (nombre de paramètres, qualité ou taille du jeu de données, modalités d’entrée et de sortie, nombre d’utilisateurs finaux…).

Pour estimer la quantité de calcul utilisée, Bruxelles propose deux approches. Elles se fondent respectivement sur l’architecture et le matériel. Elles imposent d’inclure les ressources utilisées pour générer des données synthétiques. Et pour s’entraîner avec si elles ne sont pas accessibles au public.

Les principales règles déjà en application

Former les utilisateurs

L’article 4 de l’AI Act a fait partie du premier paquet de dispositions à entrer en application (février 2025). Il impose aux fournisseurs et aux déployeurs de former leur personnel et les autres personnes chargées de l’exploitation et de l’utilisation de systèmes d’IA en leur nom. Cela inclut, pour exemple, les entreprises qui permettent à leurs employés d’utiliser ChatGPT.

Le 3 août 2026, les autorités nationales compétentes commenceront officiellement leur surveillance du respect de cette obligation. Il est à noter que l’omnibus numérique a supprimé l’exigence de niveau spécifique (ou « suffisant ») par individu.

La Commission européenne tient un répertoire d’exemples de la manière dont les organisations diffusent une maîtrise de l’IA. Une quarantaine de cas y figurent, dont ceux de Booking.com, Criteo, IBM, Kaspersky, Palantir, SAS et Workday. Cette base a permis de produire un rapport avec l’Alliance pour les compétences en IA (projet financé par Erasmus+).

Pour les PME, Bruxelles recommande de se tourner vers le réseau des pôles européens d’innovation numérique (EDIH). Elle évoque aussi l’Académie des compétences en GenAI – un projet lancé en 2025 dans le cadre du programme pour une Europe numérique… et qui n’a pour le moment pas trouvé de concrétisation.

Pratiques interdites

L’autre « gros morceau » applicable depuis février 2025 est l’article 5. Son objet : les pratiques interdites. La Commission européenne y a là aussi assorti des lignes directrices.

Parmi les exceptions, la reconnaissance des émotions et la surveillance sur le lieu de travail et dans les milieux éducatifs, aussi longtemps que c’est pour des raisons médicales ou de sécurité.

Des exceptions existent aussi, entre autres, pour les œuvres artistiques. Notamment au niveau d’une pratique que l’omnibus numérique a ajoutée à la liste : les contenus à caractère sexuel.

Modèles d’IA à usage général

Après l’échéance de février 2025, il y eut celle d’août 2025. À cette occasion sont entrées en vigueur les dispositions relatives aux modèles d’IA à usage général. Elles touchent à :

• Documentation technique
• Communication d’informations aux fournisseurs de systèmes d’IA en aval
• Politique de conformité au droit d’auteur
• Résumé public du contenu des données d’entraînement

Il existe des exigences spécifiques en cas de risques systémiques (atténuation de ces risques, documentation des incidents graves, protection en matière de cybersécurité…).

Le 2 août 2026 marquera la fin de la « période de grâce » accordée aux fournisseurs pour se mettre en conformité.

En l’attente de normes harmonisées, le principal instrument de déclaration de conformité est le code de bonnes pratiques de l’IA à usage général. Il comporte trois chapitres : transparence ; droit d’auteur ; sûreté et sécurité. Ce dernier ne s’applique qu’aux modèles qui présentent un risque systémique.

Au dernier pointage, il sont une vingtaine à avoir signé ce code de bonnes pratiques. Nommément,  Accexible, AI Studio Delta, Aleph Alpha, Almawave, Amazon, Anthropic, Black Forest Labs, Bria AI, Cohere, Domyn, Dweve, Fastweb, Google, IBM, Lawise, LINAGORA, Microsoft, Mistral AI, Open Hippo, OpenAI, Pleias, ServiceNow et WRITER. xAI a signé uniquement le chapitre sûreté/sécurité.

Qui modifie un modèle peut devenir son fournisseur

En complément, la Commission européenne a publié des lignes directrices sur la portée des obligations incombant aux fournisseurs de modèles d’IA à usage général. On y apprend que quiconque modifie un modèle – y compris par fine-tuning – peut en devenir le fournisseur. La condition : une modification importante de la généralité, des capacités ou du risque systémique. Là encore, Bruxelles fournit un critère indicatif basé sur la puissance de calcul : plus d’un tiers de celle utilisée pour entraîner le modèle original.

Si le modificateur n’a pas connaissance de cette valeur, on considère le tiers de la puissance au-delà de laquelle un modèle est dit à usage général (soit 10²³/3 flops). S’il présente un risque systémique, c’est 10²⁵/3 flops.

En respect du principe de proportionnalité, les obligations du nouveau fournisseur se limitent aux modifications apportées. Et, pour ce qui est du droit d’auteur et de la divulgation du contenu d’entraînement, aux seules données utilisées pour la modification.

La Commission européenne admet que ce critère est essentiellement prospectif. Elle considère plus globalement qu’il est difficile de définir dans quelle mesure une modification produit un modèle distinct. C’est pourquoi en l’état, elle assimle à un unique modèle chaque version issue de la même formation de grande envergure dispensée par le même fournisseur.

Des modèles « anciens » doivent être mis en conformité

Les lignes directrices apportent quelques précisions sur le cas des modèles dont au moins les poids sont publiés sous licence libre et ouverte. Cela suppose des droits de consultation, de modification et de distribution, avec publication d’informations sur l’architecture.

En l’absence de risque systémique, ces modèles échappent aux exigences de documentation technique pour les autorités et d’information des fournisseurs en aval. Mais pas à la mise en œuvre d’une politique de droit d’auteur.

La publication d’une version d’un modèle ouvert peut constituer une mise sur le marché, précisent les lignes directrices. Même chose, de façon plus large, pour toute utilisation interne si elle est essentielle à la fourniture d’un produit ou d’un service à des tiers dans l’UE ; ou si elle porte atteinte aux droits de personnes physiques dans l’UE.

Pour les modèles d’IA à usage général, l’AI Act est rétroactif : ceux mis sur le marché avant le 2 août 2025 devront avoir été mis en conformité le 2 août 2027 au plus tard.

Il n’y a pas de régime comparable pour les systèmes d’IA qui auront été mis sur le marché ou mis en service avant décembre 2027 (pour ceux concernés) ou août 2028 (pour les autres). Sauf s’ils « subissent d’importantes modifications de leur conception ». Ou encore s’ils sont utilisés par des autorités publiques. Auquel cas ils devront être conformes à l’AI Act pour août 2030 au plus tard.
Il y a aussi une exception pour les systèmes d’IA intégrés dans quelques grands SI européens :

• SI Schegen
• SI visas
• Eurodac (données biométriques)
• Enregistrement des données relatives aux entrées et sorties de ressortissants de pays tiers
• Information et autorisation concernant les voyages
• Casiers judiciaires des ressortissants de pays tiers et des apatrides

Les règles qui s’appliquent au 2 août 2026

Transparence des systèmes d’IA et des contenus

Le 2 août 2026 marque l’entrée en application de l’article 50 de l’AI Act. Il établit diverses obligations de transparence aux fournisseurs et aux déployeurs de systèmes d’IA.

Le premier paragraphe concerne les systèmes d’IA destinés à interagir directement avec des personnes physiques. Il impose à leurs fournisseurs de veiller à la bonne information des utilisateurs.

Le deuxième paragraphe impose aux fournisseurs de systèmes génératifs d’associer aux outputs un marquage lisible par machine. En sont exemptés les systèmes qui remplissent une fonction d’assistance pour la mise en forme standard. Même chose pour ceux qui ne modifient pas substantiellement les inputs ou leur sémantique.

Les déployeurs de systèmes générant des deepfakes audio et vidéo (images fixes comprises) doivent indiquer que les contenus ont été générés ou manipulés par une IA. Idem pour les textes publiés dans le but d’informer le public sur des questions d’intérêt public.

Une période de grâce et des exceptions pour le marquage des contenus

La Commission européenne a publié un code de bonnes pratiques sur la transparence du contenu généré. Y adhérer n’équivaut pas à démontrer sa conformité.

Il y est confirmé, en conséquence de l’omnibus numérique, l’application d’une période de grâce jusqu’au 2 décembre 2026 pour le marquage machine dans les systèmes mis sur le marché avant le 2 août 2026.

Le code précise que certaines sorties sont hors du champ des obligations de transparence :

• Courtes séquences de nombres, symboles ou lettres
• Code source
• Sorties traitées uniquement en machine-to-machine 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)

Aucune technique ne marquage ne satisfait pour l’instant aux 4 critères qu’énonce l’AI Act (efficacité, interopérabilité, robustesse, fiabilité). Il faut donc en combiner. Le code de bonnes pratiques suggère d’associer métadonnées signées et filigrane invisible. Il ajoute le fingerprinting comme méthode optionnelle.

Le texte libre ne pouvant transporter de métadonnées, une couche unique est considérée comme suffisante. Même chose pour les systèmes génératifs embarqués dans des produits physiques intégrés dans un environnement fermé, techniquement contrôlé et de nature principalement instructive.

Détection des contenus : l’Europe impose la gratuité… avec des limites

Pour compenser la fiabilité potentiellement moindre des filigranes sur le texte libre, les fournisseurs concernés peuvent restreindre à des utilisateurs experts l’accès à la solution de détection correspondante. Dans tous les cas, ils implémenteront préférentiellement l’apposition du filigrane au niveau du processus d’inférence plutôt que par après. Objectif : faciliter la mise en conformité des fournisseurs de systèmes d’IA en aval.

Pour la mise à disposition de la solution de détection, trois possibilités : spécification, logiciel (exécutable ou bibliothèque) ou service par API. Elle se fera gratuitement… avec la possibilité de facturer des « frais raisonnables » pour les systèmes d’IA qui ont au moins 1 million d’utilisateurs actifs par mois, dans le cas où les requêtes d’un utilisateur dépasseraient un « seuil raisonnable ».

Les fournisseurs sont invités – sans y être obligés – à intégrer des informations de provenance (nom du système d’IA, modèle utilisé…). Et à donner aux déployeurs de quoi appliquer eux-mêmes, à la génération, des étiquettes visibles. Autre option mentionnée : un mécanisme de détection forensique des contenus dont on aurait supprimé le marquage.

L’étiquetage des deepfakes en pratique

La deuxième section du code de bonnes pratiques couvre l’étiquetage des deepfakes par les déployeurs.

Si une divulgation visuelle est possible, l’étiquette doit comprendre, comme élément principal, une icône « AI ». Sauf si l’usage de l’anglais est incompatible avec la législation nationale sur l’usage linguistique dans les affaires commerciales ou administratives. Les lettres auront la même dimension verticale. Bruxelles encourage à intégrer, dans l’icône ou à côté, des mentions de type « modifié » ou « généré ».

Pour les contenus audio, on intégrera un avertissement audio au début. Soit en anglais, soit dans la langue du contenu. En prévision des modifications en aval, on répétera cet avertissement régulièrement, au minimum après les interruptions.

Dans tous les cas, l’étiquette devra rester visible assez longtemps pour que l’utilisateur la remarque. On l’intégrera dans le contenu sauf si des mécanismes équivalents – type surcouche UI – sont disponibles. Pour les textes courts, il est possible d’utiliser une notification contextuelle afin d’éviter de dégrader le contenu.

Une boîte à outils pour préparer les échéances 2027-2028

Les exigences pour les systèmes d’IA à haut risque figurant à l’annexe III ne s’appliqueront qu’en décembre 2027. Ce sera en août 2028 pour les autres (composants de sécurité, en lien avec l’annexe I).

En attendant, la Commission européenne propose un outil dit « vérificateur de conformité ». En bêta et en anglais, il permet plus exactement de comprendre, en répondant à une série de questions, quelles règles sont susceptibles de s’appliquer à un modèle ou à un système d’IA donné.

La boîte à outils de Bruxelles comprend aussi l’AI Act Explorer. En fait un tableau de bord avec moteur de recherche, table des matières par chapitre et grilles de considérants et d’annexes.

S’y ajoutent une compilation de FAQ (à moitié traduite en français) et un service d’assistance (formulaire de contact avec le Bureau de l’IA, accessible avec un login UE).

On retrouve l’ensemble sur un guichet centralisé : la « plate-forme unique d’information sur l’AI Act ».

La compilation de FAQ fait référence aux agents IA. Un terme « pas défini juridiquement et utilisé pour plusieurs types d’artefacts ». Il faut toutefois considérer que les règles de l’AI Act s’y appliquent.

Parmi les autres références, les fameuses « small caps » (« petites entreprises à moyenne capitalisation »). Elles ne sont pas des PME au sens du droit européen, mais occupent moins de 750 personnes et affichent moins de 150 M€ de CA annuel et/ou moins de 129 M€ de bilan annuel. L’omnibus numérique les rend bénéficiaires de certains allégements que l’AI Act avait d’abord réservés aux PME. Par exemple, une documentation technique simplifiée.

L’omnibus numérique, de petits en grands allégements

L’omnibus numérique a eu comme autre effet d’exempter l’IA industrielle d’une bonne partie du règlement. Le levier : un basculement de la section A à la section B de l’annexe I. Cela l’exclut notamment de certains scénarios ou le fabricant d’un produit peut être considéré comme fournisseur du système d’IA embarqué.

Autre allègement : la limitation des obligations pesant sur les systèmes d’IA à haut risque dans le cas où la législation d’harmonisation (annexe I, section A) prévoit un niveau de protection de la santé, de la sécurité ou des droits fondamentaux au moins équivalent à celui que prévoit l’AI Act. Il appartient à la Commission européenne d’adopter, d’ici à août 2027, des actes délégués pour préciser les systèmes d’IA concernés.

Données sensibles et tests en conditions réelles : un accès élargi

L’omnibus numérique a aussi élargi l’autorisation exceptionnelle de traitement de données sensibles pour la détection et la correction de biais. Le texte d’origine l’octroyait aux fournisseurs de systèmes d’IA à haut risque. Amendé, il la confère désormais également aux fournisseurs et déployeurs d’autres systèmes et modèles d’IA. Reste la condition que les biais puissent attenter à la santé, à la sécurité ou aux droits fondamentaux.

Les déployeurs de l’essentiel des systèmes d’IA cités dans l’annexe III ont droit à un « coup de pouce » pour leurs analyses d’impact sur les droits fondamentaux. Ils peuvent dorénavant y inclure des renvois vers les analyses d’impact sur les données personnelles.
Dans le même esprit de simplification, les systèmes d’IA à haut risque qui remplissent certaines exigences du règlement cyberrésilience sont réputés conformes aux exigences de cybersécurité de l’AI Act.

L’omnibus numérique étend par ailleurs les possibilités d’essai de systèmes d’IA en conditions réelles hors des bacs à sable réglementaires. Ce qui était jusque-là autorisé aux fournisseurs des systèmes d’IA listés en annexe III le devient pour ceux de l’annexe I. Un test peut durer jusqu’à 12 mois (6 mois prolongeables).

Illustration générée par IA

The post AI Act : clés et ressources pour se mettre en conformité 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.

Pendant longtemps, la cybersécurité a été considérée comme une responsabilité essentiellement technique, portée par les équipes informatiques et les responsables de la sécurité.

Cette vision ne correspond plus à la réalité des organisations d’aujourd’hui.

Les conséquences d’une cyberattaque dépassent désormais largement le périmètre des systèmes d’information : elles affectent la réputation de l’entreprise, sa conformité réglementaire, sa valorisation financière et, parfois même, sa capacité à poursuivre ses activités.

Cette évolution transforme profondément la manière dont les entreprises doivent envisager la responsabilité en matière de cybersécurité. Si les RSSI identifient les risques et proposent des stratégies pour les réduire, ils ne décident ni des budgets, ni des arbitrages métier, ni du niveau de risque que l’organisation est réellement prête à accepter.

La cybersécurité est devenue un sujet de gouvernance autant qu’un sujet technologique.

Affaire Coupang : quand la responsabilité remonte jusqu’à la direction

En décembre dernier, Park Dae-jun, directeur général des opérations sud-coréennes de Coupang, a démissionné. Une fuite de données avait exposé les informations personnelles de près de 34 millions de clients, soit quasiment l’ensemble de la base d’utilisateurs de l’entreprise. Park Dae-jun a déclaré quitter ses fonctions afin d’assumer la « lourde responsabilité » de cette violation de données.

Sa démission est intervenue après que les enquêteurs du gouvernement sud-coréen ont conclu qu’il ne s’agissait ni d’une attaque inédite ni d’un événement impossible à empêcher. Un ancien ingénieur, qui connaissait les faiblesses du système, était simplement revenu par une porte virtuelle que l’entreprise avait oublié de fermer. Les autorités ont qualifié cet incident de défaillance managériale plutôt que technique. La responsabilité a été attribuée au dirigeant de l’entreprise, et non au RSSI.

Autrement dit, cette affaire illustre la manière dont une défaillance peut remonter toute la chaîne hiérarchique jusqu’à engager directement la responsabilité de la direction générale. Dans ce type de situation, le regard du conseil d’administration ne s’arrête plus aux seuls responsables de la sécurité.

Les limites du rôle du RSSI

Pendant des années, les dirigeants ont eu le réflexe de tenir le RSSI pour responsable lorsqu’un incident de sécurité survenait. Après tout, c’est lui qui pilote la stratégie de cybersécurité de l’entreprise. Pourtant, ce raisonnement atteint rapidement ses limites.

Le RSSI ne prend pas les décisions qui déterminent réellement le niveau d’exposition de l’organisation. Il ne définit pas les budgets. Il ne décide pas du niveau de risque que l’entreprise est prête à accepter. Il ne peut pas imposer aux différentes directions métiers d’appliquer des politiques de sécurité lorsque celles-ci poursuivent d’autres priorités. Son rôle consiste à présenter les risques ainsi que les différentes options de réduction au comité de direction. C’est ensuite à celui-ci de décider de la marche à suivre.

Les conséquences d’un incident cyber sont le reflet de ces décisions. Si une organisation sous-investit dans sa cybersécurité, ce n’est pas un échec du RSSI. C’est un choix de gouvernance. Lorsqu’une violation survient, la responsabilité devrait logiquement suivre le pouvoir de décision. Dans la plupart des organisations, ce pouvoir appartient au directeur général.

La défaillance cyber comme faute de gestion

Pendant longtemps, les conseils d’administration ont considéré les violations de données comme un problème informatique. Cela a toujours été une erreur. Et pour beaucoup d’entreprises, cette perception demeure encore aujourd’hui.

Pourtant, lorsque les conséquences financières et réputationnelles deviennent impossibles à contenir, cette distance disparaît. Une fuite touchant des dizaines de millions de clients ne crée pas uniquement un problème juridique : elle dégrade durablement l’image de l’entreprise, influence sa valorisation boursière et attire immédiatement l’attention des autorités de régulation. Toutes ces conséquences relèvent de la responsabilité du dirigeant.

De la même manière que les conseils d’administration posent aujourd’hui davantage de questions avant qu’un incident ne survienne, les régulateurs se montrent désormais beaucoup plus précis après une cyberattaque. Dans les affaires les plus médiatisées, les autorités considèrent de plus en plus les défaillances de cybersécurité non comme un simple manque de chance, mais comme le symptôme possible d’une négligence de gouvernance.

Cette pression redéfinit progressivement les attentes vis-à-vis du rôle du RSSI. Sa mission consiste à fournir à la direction une vision claire des risques ainsi que des arbitrages qu’ils impliquent. Les décisions qui suivent relèvent ensuite de la responsabilité de l’entreprise. Sans impulsion au plus haut niveau, les stratégies de cybersécurité restent souvent au stade des recommandations.

Aligner les bonus des dirigeants sur la sécurité globale

Intégrer cette notion de responsabilité dans le fonctionnement d’une organisation est loin d’être simple et demeure très inégal selon les entreprises. Une grande partie du sujet dépend de la manière dont la performance des dirigeants est évaluée et récompensée.

Lorsque les objectifs du directeur général sont principalement liés à la croissance du chiffre d’affaires et tiennent peu compte des résultats en matière de cybersécurité, cela influence naturellement les priorités de toute l’organisation.

Dans les rares entreprises où la responsabilité cyber est clairement intégrée à la gouvernance, le changement commence généralement par les attentes fixées à la direction plutôt que par des mesures techniques. Les conseils d’administration ne pilotent pas les opérations de sécurité au quotidien, mais leur influence s’exerce à travers la façon dont les risques sont discutés, les arbitrages évalués et les actions attendues de la direction dans la durée.

L’enjeu n’est pas tant de désigner un coupable que de clarifier où se situe la responsabilité ultime lorsque des risques connus ne sont pas traités.

Lorsqu’une enquête gouvernementale conclut qu’une violation de données majeure résulte avant tout d’une défaillance de gouvernance, et qu’un directeur général démissionne pour en assumer la responsabilité, cela traduit une évolution discrète mais profonde de la manière dont les responsabilités sont désormais attribuées. Dans ces situations, il devient évident qu’un problème de gouvernance ne peut être résolu par une simple correction technique, ni être porté par la seule fonction sécurité.

Le vrai rôle de la direction générale

Les organisations changent rarement parce que les risques sont bien compris. Elles évoluent généralement lorsque les conséquences de leurs décisions deviennent impossibles à ignorer. En cybersécurité, ce lien reste encore l’exception plus que la règle. Mais lors des incidents les plus graves, il devient de plus en plus difficile de l’éluder. La pression réglementaire, les réactions des marchés et l’attention du public convergent désormais de plus en plus vers la direction générale.

L’évolution des menaces, le renforcement des exigences réglementaires et l’impact financier croissant des cyberincidents rendent cette clarification indispensable. Le rôle du RSSI n’est pas d’assumer seul le risque cyber de l’organisation, mais de fournir à la direction la visibilité nécessaire pour prendre des décisions éclairées.

La véritable question n’est donc plus de savoir qui sera tenu responsable après une cyberattaque, mais comment les entreprises organisent aujourd’hui le partage de cette responsabilité. Car lorsqu’un risque devient stratégique pour l’activité de l’entreprise, sa gouvernance doit, elle aussi, devenir stratégique.

*John Kindervag est Chief Evangelist chez Illumio

Photo : © DR

The post Le RSSI ne décide pas du risque que l’entreprise accepte appeared first on Silicon.fr.

Pendant plusieurs années, la croissance du cloud public reposait principalement sur la migration des applications et des infrastructures d’entreprise.

Les derniers résultats trimestriels d’Amazon, de Microsoft et d’Alphabet montrent que le moteur a changé. L’IA générative est devenue le principal facteur de consommation de ressources cloud, qu’il s’agisse de l’entraînement des modèles, de leur inférence ou de l’exécution d’agents IA.

Mais si les trois hyperscalers affichent une accélération de leur activité cloud, leur trajectoire sont différentes. Microsoft conserve la croissance la plus élevée, AWS retrouve un rythme qu’il n’avait plus connu depuis plusieurs années et Google Cloud poursuit sa progression en s’appuyant sur l’adoption de Gemini et de Vertex AI.

AWS retrouve une croissance de près de 40 %

Amazon Web Services enregistre un chiffre d’affaires trimestriel de 42,2 milliards $, en progression de 37 % sur un an. Il s’agit de sa croissance la plus élevée enregistrée depuis plusieurs années.

Pour Andy Jassy, le patron d’Amazon, cette accélération est directement liée aux investissements des entreprises dans l’IA générative. Le groupe met notamment en avant la progression de l’adoption d’Amazon Bedrock, la demande pour ses puces Trainium ainsi que l’utilisation croissante des infrastructures GPU destinées à l’inférence.

Le successeur de Jeff Bezos indique également que la demande dépasse encore les capacités actuellement disponibles. Et d’affirmer qu’une partie des capacités de calcul prévues pour 2027 est déjà réservée par des clients.

Pour soutenir cette demande, Amazon prévoit désormais 220 milliards $ de dépenses d’investissement en 2026, principalement consacrées au développement de nouveaux datacenters et de capacités de calcul destinées à l’IA.

Azure maintient la dynamique la plus forte

Microsoft conserve la croissance cloud la plus élevée parmi les grands hyperscalers.

Azure affiche une progression de 43 % sur un an tandis que l’ensemble de l’activité Microsoft Cloud atteint 59,3 milliards $ de chiffre d’affaires trimestriel, en hausse de 27 %.

Le groupe attribue cette performance à la diffusion croissante de ses offres d’IA, notamment Azure AI et Microsoft 365 Copilot. Microsoft indique désormais compter plus de 30 millions d’utilisateurs payants de Microsoft 365 Copilot.

Autre indicateur mis en avant : Azure génère désormais plus de 100 milliards $ de chiffre d’affaires annuel, confirmant le changement d’échelle de la plateforme.

Malgré l’ampleur des investissements réalisés dans les infrastructures IA, Microsoft maintient son programme de dépenses d’investissement de 175 milliards $ pour l’exercice 2026.

Google Cloud poursuit son accélération

Google Cloud confirme également une nette accélération de sa croissance. Pour son deuxième trimestre fiscal, la division a généré 24,8 milliards $ de chiffre d’affaires, en hausse de 82 % sur un an. Son résultat opérationnel atteint 8,8 milliards $, contre 2,8 milliards un an plus tôt, tandis que son carnet de commandes progresse à 514 milliards $.

Le groupe met notamment en avant l’adoption de Gemini Enterprise, désormais utilisé par près de 90 % des entreprises du Fortune 100, ainsi que la progression de Vertex AI et des infrastructures Google Cloud Platform (GCP) dédiées à l’IA.

Alphabet a relevé ses prévisions pour 2026 et prévoit désormais des dépenses d’investissement comprises entre 195 et 205 milliards $ principalement destinées au développement de ses centres de données et de ses infrastructures de calcul pour l’IA.

Ce trimestre confirme le changement d’échelle de Google Cloud. Longtemps distancé par AWS et Azure, le troisième hyperscaler mondial affiche désormais la croissance la plus rapide du marché.

Une compétition qui se déplace vers la capacité d’exécution

Les trois fournisseurs soutiennent que la capacité de calcul devient un facteur de différenciation aussi important que les modèles d’IA eux-mêmes. Leurs performances illustrent cette évolution : le cloud devient la plateforme d’exécution de l’IA d’entreprise, combinant puissance de calcul, modèles de langage, outils de développement, services d’inférence et applications

Pour les DSI, cette évolution pourrait avoir des conséquences directes sur la planification des projets IA. Les capacités disponibles, les délais de mise à disposition des ressources ou encore les engagements contractuels avec les fournisseurs cloud pourraient devenir des critères de sélection aussi importants que les fonctionnalités des plateformes.

The post AWS, Azure, Google Cloud : l’IA accélère leur croissance et relance la compétition appeared first on Silicon.fr.

C’est une annonce qui traduit l’urgence ressentie à Bruxelles. La Commission européenne a officiellement lancé, ce 30 juillet, un appel d’offres pour la construction de sept usines géantes consacrées à l’intelligence artificielle, dotées d’une enveloppe publique de 10 milliards d’euros (11,5 milliards $).

Un montant que l’exécutif européen espère voir démultiplié par les investisseurs privés, avec un objectif d’au moins 20 milliards € supplémentaires apportés par le secteur privé.

De cinq à sept projets

Signe de l’appétit suscité par le projet auprès des États membres, le nombre de gigafactories prévues est passé de cinq à sept, la Commission ayant reçu un intérêt jugé « fort » de la part des pays de l’Union.

Ces installations combineront processeurs d’IA de pointe, logiciels, technologies cloud, connectivité à très haut débit et centres de données. Elles viendront s’ajouter aux 19 « AI factories » déjà existantes dans différents pays du bloc.

Pour la commissaire européenne chargée de la technologie, Henna Virkkunen, l’enjeu dépasse la simple compétition industrielle : « L’accès à la puissance de calcul brute au sein des gigafactories d’IA est une nécessité stratégique pour l’Europe, alors que le développement de l’IA s’accélère. »

Le message est clair : l’Union entend combler son retard technologique face aux États-Unis et à la Chine, qui dominent largement la course aux infrastructures d’intelligence artificielle.

L’appel d’offres est ouvert à des consortiums ou véhicules d’investissement dédiés (special purpose vehicles), réunissant fournisseurs de technologies, prestataires de services cloud, entités publiques et investisseurs.

Un enjeu de souveraineté technologique

Le calendrier fixé par Bruxelles est le suivant : clôture de l’appel à candidatures le 12 novembre 2026, annonce des lauréats début 2027 puis mise en service des installations dans les 18 mois suivant la signature des contrats.

Le projet se déroulera en deux phases : une première consacrée à l’établissement des sites, une seconde à leur montée en puissance.

Côté fournisseurs, trois poids lourds américains du secteur des puces ont d’ores et déjà manifesté leur intérêt : AMD, Nvidia et Qualcomm ont signé des lettres d’intention avec la Commission pour fournir des processeurs aux groupements impliqués dans les projets de gigafactories.

La France s’est engagée à acquérir pour 100 millions € de capacités de calcul auprès du projet qui sera retenu sur son territoire. Cette capacité sera destinée à couvrir les besoins futurs des administrations publiques, notamment ceux de la recherche et des établissements de santé.

Prévu à l’horizon 2027, cet engagement concerne l’achat de capacités auprès d’opérateurs privés. Il est distinct des investissements que l’État poursuit parallèlement pour développer ses propres infrastructures de calcul.

The post L’UE mise 10 milliards € sur sept « gigafactories » de l’IA appeared first on Silicon.fr.

Près de deux mois après le bouclage financier de l’opération, Neverhack officialise une levée de fonds de 11 millions € auprès de ses actionnaires institutionnels Carlyle et IK Partners.

Fondé en juillet 2021, Neverhack se positionne sur le terrain de la cyberdéfense souveraine en associant expertise opérationnelle, services managés et IA de cybersécurité. Et revendique plus de 1200 collaborateurs répartis dans 12 pays pour un chiffre d’affaires de 220 millions €.

Avec ces capitaux fraîchement injectés, Neverhack prévoit notamment de concevoir une offre d’IA cyber souveraine et de déployer des infrastructures dédiées à la protection des données stratégiques en renforçant ses capacités GPU en France, en Italie et en Estonie. Un programme de formation à destination des équipes techniques et commerciales complète ce dispositif.

En parallèle, sa gouvernance évolue. Arthur Bataille, fondateur et deuxième actionnaire du groupe, abandonne la direction opérationnelle pour devenir Executive Chairman chargé de piloter la vision stratégique.

C’est Frédéric Sarrailh qui assurera la direction générale du groupe. Il avait précédemment occupé les fonctions de  « VP Technology & Services »  puis « Managing Director Northern Europe ».

Rappelons que Nerverhack, ex Pr0ph3cy, est né du rapprochement de Silicom et Seela, puis de l’acquisition de Opencyber et Harmonie Technologie.

Contrôlé depuis juillet 2023 par le fonds Carlyle Europe Technology Partners (CETP) qui a investi 100 millions € contre 55% du capital, Neverhack veut proposer un « guiche unique » de solutions de cybersécurité pour des clients grands comptes et ETI.

En février 2004, Neverhack  avait racheté Expert Line e un cabinet de conseil et de services cyber mais aussi opérateur de SOC avant de jeter son dévolu quelques mois plus tard sur Innovery, une ESN italienne.

The post Neverhack lève 11 millions € pour accélérer sur l’IA et la cyber souveraine appeared first on Silicon.fr.

Wavestone accélère la mise en œuvre de son plan stratégique « Lead the shift ». Le cabinet de conseil français, coté depuis 2000, a bouclé l’acquisition d’AI Builders.

Spécialisé dans la stratégie IA & data, AI Builders a vu le jour en 2019. Depuis, le cabinet accompagne les directions générales, les Chief Data Officers et les Chief AI Officers dans leurs arbitrages stratégiques. Il aide ainsi ses clients à définir leur feuille de route IA. Il structure aussi leurs Data Offices et pilote leurs projets par la valeur créée.

Wavestone présente cette expertise comme complémentaire à la sienne. En effet, le groupe se concentre plutôt sur l’industrialisation et le déploiement à grande échelle de transformations complexes.

AI Builders emploie une cinquantaine de consultants. Par ailleurs, le cabinet vise pour 2026 un chiffre d’affaires de 10,3 millions €. Sa marge d’EBITDA ajusté atteint 15 %. Si les chiffres restent modestes, ils positionnent le cabinet comme un acteur rentable sur un segment de niche à forte valeur ajoutée.

Wavestone a réglé l’intégralité des 19,3 millions € de l’opération en numéraire, sur ses fonds propres. AI Builders rejoindra les comptes du groupe dès le 1ᵉʳ août 2026..

Le nouvel actif s’inscrit pleinement dans son plan stratégique « Lead the shift » qui fait de l’IA l’un de ses principaux relais de croissance à l’horizon 2030.

Illustration : © DR

The post Wavestone renforce son offre en IA en s’offrant AI Builders appeared first on Silicon.fr.

HAWK n’est plus candidat à la standardisation NIST.

L’équipe à l’origine de cet algorithme de signature vient de le retirer de la compétition. En toile de fond, la découverte d’une faiblesse mathématique qui diminue de près de moitié la « taille effective » des clés. Elle exploite une symétrie – dite automorphisme – dans le réseau de treillis, permettant une énumération plus rapide.

Il aura fallu à Claude Mythos environ 60 heures – et 100 000 $ de coûts d’API – pour développer une attaque de bout en bout. Un chercheur expérimenté en théorie informatique – mais pas spécialiste de la cryptographie – a orchestré la « gestion de projet ». Par exemple, expliquer au modèle comment garder trace de ses idées ou quelles bibliothèques utiliser.

Anthropic livre une implémentation de référence, avec une commande unique et des checkpoints. Elle permet de récupérer une clé HAWK-256 en un peu moins de 4 heures sur un serveurs à 96 cœurs Sapphire Rapids.

Une méthode « naïve » consisterait à utiliser des clés deux fois plus longues pour compenser cette vulnérabilité. Elle rendrait toutefois l’algo bien moins compétitif. En l’état, la génération et la vérification de signatures HAWK-512 sont censées prendre moins de 0,1 ms sur un PC de bureau standard. L’implémentation optimisée mémoire consomme 14 kiB de RAM.

À consulter en complément :

Quelques solutions françaises pour amorcer la transition post-quantique
En froid, GPG et OpenPGP avancent séparément sur la cryptographie post-quantique
Comment Anthropic est passé de Claude Mythos à Claude Fable

Illustration principale © Siarhei – Adobe Stock

The post Claude Mythos met à mal un algorithme post-quantique 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.

L’intelligence artificielle agentique marque une nouvelle étape dans l’évolution des systèmes numériques.

D’après une étude récente de KPMG, les agents s’intègrent désormais comme de véritables coéquipiers pour gérer des tâches opérationnelles clés, offrant de nouvelles opportunités d’automatisation et d’efficacité. Ils peuvent analyser des informations, prendre des décisions et interagir avec des applications ou des données sans intervention humaine constante.

Néanmoins, cette autonomie croissante soulève également de nouveaux enjeux de sécurité. Les entreprises doivent pouvoir identifier, contrôler et surveiller leurs agents au même titre qu’un utilisateur humain.

Dans ce contexte, où existe un fort lien entre potentiel de l’IA et grande autonomie, les principes historiques du Zero Trust restent pertinents et forment un cadre essentiel pour l’usage des agents IA.

La déclinaison de ces principes impose de doter chaque agent d’une identité vérifiable, d’un niveau d’accès adapté et d’un comportement conforme aux politiques de sécurité définies. L’application du Zero Trust aux environnements agentiques permet alors d’exploiter pleinement le potentiel de l’IA tout en limitant les risques liés à son autonomie.

Donner une identité aux agents, une condition essentielle du Zero Trust

L’extension des principes Zero Trust aux agents nécessite avant tout que ces derniers disposent d’une identité. Comme pour les utilisateurs humains, les entreprises doivent connaître précisément l’agent qui agit, pour le compte de quel utilisateur et le contexte de la réalisation d’une action.

Anthropic recommande l’utilisation de certificats numériques pour la vérification d’identité et du protocole TLS mutuel pour l’authentification. Cependant, cette solution présente des inconvénients. De nombreux agents développés ou téléchargés par les entreprises ne peuvent gérer des certificats.

De plus, le protocole TLS mutuel risque d’entraver l’interception du trafic des agents pour vérifier le respect des politiques de sécurité en place. Les organisations cherchent à disposer d’une identité fiable permettant d’associer l’agent à l’utilisateur humain qui s’en sert. Cette identité fusionnée s’avère essentielle pour créer des politiques mettant en œuvre des systèmes de contrôle précis. Les développeurs ne doivent pas créer, stocker ni partager de jetons d’accès entre les agents, car ils représentent une cible particulièrement vulnérable en cas d’attaque.

Sitôt une base d’identité solide en place, une stratégie Zero Trust peut définir le niveau d’accès approprié selon les ressources concernées. Anthropic fait référence au principe de « capacité d’action minimale » (« least agency ») de l’OWASP, qui correspond au principe du moindre privilège appliqué aux agents. Un agent ne doit donc disposer que des capacités strictement nécessaires à son fonctionnement et ne pouvoir effectuer que les actions correspondant à son rôle et à son objectif.

L’application de ce principe se fait notamment grâce aux contrôles d’accès basés sur les rôles et sur le contexte. Les politiques de sécurité peuvent associer les identités des agents à des rôles et définir précisément les conditions autorisées pour chaque accès : heure, localisation, niveau de confidentialité, score de risque, instance applicative utilisée ou encore caractéristiques de la ressource demandée. Cette approche permet de limiter les possibilités d’action des agents et d’éviter qu’un agent compromis ou mal utilisé puisse accéder à des ressources qui ne correspondent pas à son usage prévu.

La visibilité et les contrôles d’accès comme premier rempart

En l’absence de pratiques DevSecOps bien établies, la majorité des entreprises doit acquérir une visibilité sur l’ensemble de leur environnement d’IA et mettre en place des systèmes de contrôle efficaces. De plus, l’usage sécurisé de l’IA agentique passe par l’ajout d’une couche de politiques et de gouvernance régissant l’utilisation de cette IA et les interactions de ses agents.

Les stratégies Zero Trust partent du principe que les entreprises connaissent l’ensemble de leurs ressources, systèmes et données. Depuis la généralisation de l’IA, cette idée perd en pertinence, d’où le complément indispensable que représente l’inspection en transit.

Elle permet d’identifier de façon continue les serveurs et clients MCP utilisés ainsi que leurs principales caractéristiques. Elle facilite également l’attribution de scores de risque aux serveurs MCP publics afin d’identifier les outils d’IA et les intégrations qui présentent les plus grands risques en matière de sécurité et de conformité.

La visibilité ne se limite toutefois pas à la détection. Le livre d’Anthropic rappelle par exemple que les contrôles d’accès empêchent les actions non autorisées, mais qu’une surveillance continue reste essentielle pour comprendre les événements détectés et déterminer si l’activité des agents paraît normale ou suspecte.

Comme cela se fait déjà pour les utilisateurs humains, leurs utilisateurs peuvent désormais définir un comportement de référence pour les agents, puis détecter les anomalies ou les signes de dysfonctionnement afin d’adapter les politiques de contrôle.

Vérifier l’intention des agents pour empêcher les abus

Il existe toujours un risque qu’un agent se comporte de manière imprévisible, avec comme potentielles conséquences d’importants préjudices. Dans l’approche Zero Trust généralisée à l’IA, toute action doit partir du principe que des acteurs malveillants exploitent déjà une faille.

Les entreprises utilisant l’IA doivent donc détecter et surveiller le trafic entre les serveurs MCP, les clients, les fonctions, les hôtes, les sources de données et les outils de développement. En parallèle, elles gardent à l’esprit le trafic interne à tous ces éléments, tout en enregistrant les événements MCP, notamment les sessions, les requêtes, les réponses de fonctions et les déploiements.

Un aspect parfois négligé des stratégies Zero Trust consiste à identifier la raison pour laquelle une personne ou un agent agit d’une certaine manière ou possède l’autorisation de le faire. Évaluer l’intention de chaque agent doit devenir une étape obligatoire dans toute stratégie Zero Trust. Cela nécessite de filtrer les données exploitées par les agents, car ceux-ci ne peuvent pas faire la distinction entre des instructions légitimes et des commandes malveillantes.

Les dispositifs de contrôle automatiques fournissent ainsi une couche de défense supplémentaire en analysant le trafic en temps réel, afin de neutraliser les attaques par injection de prompt, le « jailbreaking » ou les tentatives d’exfiltration de données. Ils permettent également de modérer les contenus et de bloquer la diffusion de ceux soumis à des contraintes de propriété intellectuelle.

À mesure que les agents gagnent en autonomie, cette capacité à contrôler leur identité, leurs accès et leurs intentions devient donc un élément central de toute stratégie de sécurité. Même avec l’ajout de celui-ci, le cœur de l’approche Zero Trust reste que les bonnes personnes et les bons agents disposent du bon niveau d’accès aux bonnes ressources, au bon moment et pour les bonnes raisons.

*Steve Riley est Field CTO chez Netskope

Photo : © DR

The post Le Zero Trust à l’ère des agents : une approche dépassée ? appeared first on Silicon.fr.

The post Vent de révolte contre Anthropic dans la Silicon Valley appeared first on Silicon.fr.

MCP est désormais un protocole sans état… et sans session. La dernière version de la spec (2026-07-28) entérine ce changement majeur.

Initialement, il était plutôt envisagé que MCP devienne stateless par défaut, avec le stateful en option de dernier ressort. Ce schéma de coexistence n’a pas été retenu, au motif qu’il aurait largement accru la complexité du protocole. Clients et serveurs auraient eu à maintenir des logiques séparées, avec une surface de bugs d’autant plus grande. Quant à l’idée de réintroduire les sessions sous une autre forme, elle a aussi été abandonnée… au motif que les applications existantes implémentaient déjà mal le concept.

Quiconque souhaite continuer à utiliser des sessions doit donc épingler son serveur MCP sur la version précédente de la spec (2025-11-25). Elle restera prise en charge encore au moins 12 mois.

Du sessionless au niveau protocole…

Dans le paradigme stateless, chaque requête est indépendante, interprétable de manière isolée. Cela favorise l’élasticité et la fiabilité. En tout cas par rapport au paradigme stateful.

Ce dernier implique un handshake initial qui établit un état persistant. Une session client étant liée à l’instance de serveur contenant cet état, il en découle l’impossibilité d’utiliser un load balancer stateless simple (type round-robin L4/L7). À moins d’implémenter des mécanismes qui ajoutent de la complexité, comme l’affinité de session.

Sur le sujet de la fiabilité, le modèle stateful implique qu’en cas de panne de l’instance serveur gérant une session, on perd l’état. Le client doit alors détecter la panne, réétablir une connexion et refaire toute la négociation.

L’approche stateful suppose aussi d’implémenter, côté client et serveur, une logique de gestion de cycle de vie.

Le modèle stateless est censé abaisser ces barrières à l’entrée. Il dégroupe des opérations jusque-là gérées en bloc lors du handshake. En particulier, la négociation de version de protocole et la découverte de capacités. Elles se font désormais au niveau des requêtes, à travers l’objet _meta, avec des endpoints spécifiques.

… et au niveau application

Le passage au stateless et au sessionless a exigé des travaux sur de nombreux composants annexes de MCP. Par exemple les tâches. Ce mode d’exécution alternatif, utile pour représenter notamment, les opérations de batch, avait été intégré dans la spec 2025-11-25. Avec la nouvelle version, il sort du cœur du protocole et devient une extension officielle.

Il a aussi fallu instaurer une alternative aux sessions pour la gestion d’état au niveau des applications. La solution retenue se fonde sur des identifiants explicites générés côté serveur et transmis en tant qu’arguments. Plusieurs éléments ont dû être clarifiés dans ce cadre, comme l’absence de mécanisme natif pour communiquer le TTL de ces identifiants ou le risque de production d’états orphelins en cas de compression du contexte.

Du stateless également pour les demandes d’informations supplémentaires par les serveurs

Entre autres changements majeurs, la spec 2026-07-28 introduit aussi le pattern MRTR (Multi Round-Trip Requests) comme moyen, pour les serveurs, de signaler qu’il leur faut des informations supplémentaires pour traiter une requête. Son principale avantage : pas besoin de couche de stockage partagée entre instances de serveurs, ni de load balancer stateful.

Il y a également des avancées sur la partie autorisation (la plus coûteuse en effort d’intégration). En particulier, l’adoption de CIMD (Client ID Metadata Documents) à la place de DCR (Dynamic Client Registration), qui reste pour le moment pris en charge pour la rétrocompatibilité. Les authentifiants clients sont en outre désormais liés à leur émetteur : on ne peut plus les réutiliser entre serveurs d’autorisation.

Tous les SDK de premier niveau (TypeScript, Python, Go, C#) gèrent la nouvelle spec. Le SDK Rust aussi, mais en bêta.

Illustration principale générée par IA

The post MCP devient un protocole sans état… et sans session appeared first on Silicon.fr.

Microsoft AI a dévoilé MAI-Cyber-1-Flash, son premier modèle d’IA spécifiquement conçu pour la cybersécurité.

L’éditeur le décrit comme un système spécialisé dérivé de sa famille MAI-Thinking-1 et destiné à traiter les tâches répétitives de la chaîne de sécurité avant de laisser les cas les plus complexes à des modèles plus puissants.

MAI-Thinking-1 s’inscrit dans la nouvelle génération de modèles maison de Microsoft AI, avec une approche clairement orientée vers le raisonnement. Soit un modèle de taille intermédiaire, capable d’activer seulement une partie de ses paramètres selon la tâche pour préserver le rapport entre performances et coût d’inférence.

Microsoft affirme l’avoir « entraîné from scratch » sur des données propriétaires, sans distillation depuis des modèles tiers. Un choix  qui souligne la volonté du groupe de reprendre la main sur sa pile IA, en privilégiant des modèles internes optimisés pour ses usages professionnels, qu’il s’agisse de raisonnement, d’agents ou de tâches de code.

Dans cette logique, MAI-Thinking-1 apparaît moins comme un concurrent frontal des grands modèles généralistes que comme une brique fondatrice de l’écosystème Microsoft AI, dirigé par Mustafa Suleyman.

MDASH, le moteur opérationnel

Le lancement de MAI-Cyber-1-Flash s’inscrit dans la montée en puissance de MDASH, le système multi-modèles de Microsoft pour la détection de vulnérabilités. L’objectif est d’orchestrer plusieurs agents spécialisés pour couvrir un flux complet allant de la découverte à la validation, puis à la correction des failles.

Selon Microsoft, MAI-Cyber-1-Flash prend en charge jusqu’à 90% des tâches de MDASH, ce qui permet de réserver les modèles plus coûteux aux cas les plus difficiles.

Selon les résultats du benchmark de CyberGym communiqués, la combinaison MDASH + MAI-Cyber-1-Flash atteint 95,95% dans certaines évaluations, et jusqu’à 96%*lorsque les cas les plus complexes sont traités avec l’ensemble de la chaîne incluant GPT-5.4.

Ces chiffres servent un message simple : l’IA ne se contente plus d’assister l’analyste, elle commence à absorber une partie du travail d’expertise technique. Microsoft pousse ainsi un modèle de défense “AI speed”, où la machine ne se limite pas au tri d’alertes mais intervient aussi dans l’analyse approfondie du code et l’élaboration de correctifs.

Ce que cela change pour les analystes SOC

Pour les analystes SOC, MDASH marque moins une rupture qu’un basculement du centre de gravité. En automatisant une partie du tri, de la détection et de la remédiation, Microsoft s’attaque aux tâches les plus répétitives et les plus chronophages du métier, celles qui saturent les équipes de première ligne.

À terme, cela pourrait réduire la pression sur les volumes d’alertes, mais aussi accélérer l’exigence de montée en compétence des profils juniors, dont le rôle se déplacera vers la validation, l’investigation et la qualification fine des incidents.

Le SOC ne disparaît pas avec l’IA mais il se polarise entre exécution industrialisée et analyse à forte valeur ajoutée, avec un humain davantage placé en surplomb dans une logique de supervision et d’arbitrage.

Une stratégie « très Microsoft »

Ce lancement illustre la volonté d’intégrer davantage l’IA au cœur de la pile de sécurité Microsoft, plutôt que de laisser les usages cyber se répartir entre outils tiers.

Microsoft cherche à faire converger ses modèles spécialisés, sa plateforme Defender et les workflows de remédiation dans un ensemble plus cohérent, automatisé et nettement plus économique en coûts d’inférence

Pour le marché, le signal est important. Microsoft n’essaie pas seulement de démontrer que son IA sait trouver des failles mais qu’elle peut industrialiser une partie du cycle de sécurité, de la détection à la correction, tout en gardant l’opérateur humain dans la boucle pour les arbitrages critiques.

The post Microsoft lance MAI-Cyber-1-Flash et pousse l’IA au cœur du SOC appeared first on Silicon.fr.

À une échelle de quasiment 3000 milliards de paramètres et près de 1000 experts, il faut repenser la circulation de l’information.

Ce chantier a guidé le développement du dernier flagship open-weight de Moonshot AI : Kimi K3. Il s’est décliné sur trois dimensions : longueur de séquence, profondeur de réseau et largeur de modèle.

Sur le premier aspect, Moonshot AI a exploité un mécanisme d’attention hybride. Il entrelace, à raison de 3 pour 1, des couches KDA (Kimi Delta Attention) et MLA (Multi-head Latent Attention). Les unes exploitent un état récurrent de taille constante pour limiter l’empreinte mémoire. Les autres permettent de maintenir le contexte global.

Le mécanisme dit Attention Residuals agit sur le deuxième aspect. Il remplace la connexion résiduelle classique en permettant à chaque couche de récupérer et pondérer de manière sélective les représentations issues de l’ensemble des blocs précédents.

Stable LatentMoE intervient sur le troisième aspect. Comm son nom l’indique, il stabilise l’entraînement à l’échelle des 896 experts de Kimi K3. Son rôle : équilibrer la charge, pour éviter que certains soient sous-utilisés ou surutilisés. En complément, plutôt que de faire passer la totalité de la dimension cachée à travers chacun des 16 experts que sélectionne chaque token, l’architecture les compresse dans un espace latent de plus faible dimension où les experts effectuent leurs calculs. Les sorties sont ensuite réétendues vers la dimension d’origine.

Des microVM pour tenir le million de tokens

Le post-entraînement a combiné fine-tuning supervisé, apprentissage par renforcement et distillation. La fenêtre de contexte a été progressivement étendue, jusqu’au million de tokens.

Pour gérer le parallélisme des experts, Moonshot AI a développé sa propre bibliothèque. Elle exploite notamment des formes de calcul statiques. Elle réserve en l’occurrence à chaque token des tampons mémoire fixes, de sorte que le GPU n’a plus à exécuter des instructions dynamiques de changement de taille.

Pour maintenir la trajectoire d’attention dans le cadre des usages agentiques, l’entraînement a mis à contribution des microVM permettant de suspendre les sandbox et de les relancer en quelques dizaines de millisecondes. Moonshot AI y a ajouté un regroupement des opérations élémentaires des blocs KDA dans un unique noyau GPU personnalisé.

L’ensemble de ces techniques lui a permis affirme-t-il, d’atteindre un rendement d’échelle 2,5 fois supérieur à celui de Kimi K2.

Kimi K3, sous licence permissive, mais…

Kimi K3 est fourni avec de l’outillage d’inférence pour vLLM, SGLang et TokenSpeed. Il a une licence MIT-like très permissive… sauf pour les grandes entreprises.

Celles qui fournissent une offre MaaS (models as a service) doivent négocier un accord commercial avec Moonshot AI dès lors qu’elles ont déjà – filiales comprises – réalisé au moins 20 M$ de CA sur 12 mois glissants.

Une autre exigence s’applique. Elle n’est pas limitée aux fournisseurs MaaS. Elle impose d’afficher clairement « Kimi K3 » sur l’UI de tout produit ou service commercial qui compte plus de 100 millions d’utilisateurs actifs par mois et/ou dégage au moins 20 M$ de chiffre d’affaires mensuel.

Meta impose une limite du même genre pour ses modèles Llama à poids ouverts. Doit prendre une licence commerciale quiconque exploite des produits ou services comptant plus de 700 millions d’utilisateurs actifs par mois.

À consulter en complément :

Qui est Moonshot AI, l’éditeur des modèles Kimi ?
Mistral AI change d’approche pour l’apprentissage par renforcement
AMD entre vraiment dans le jeu des racks IA exascale
L’IA agentique change les méthodes de travail : Doctolib l’expérimente auprès de ses développeurs
Cohere et Aleph Alpha : les noces de l’IA souveraine

Illustration principale générée par IA

The post Kimi K3 : comment Moonshot AI est passé à l’échelle appeared first on Silicon.fr.

Nvidia continue de tisser sa toile dans l’écosystème de l’IA.

Le groupe de Jensen Huang annonce un investissement « conséquent » dans Safe Superintelligence (SSI), le laboratoire ultra-discret fondé par Ilya Sutskever, ancien chef scientifique d’OpenAI.

Selon des sources proches citées par le Financial Times, le montant s’élèverait à environ 5 milliards $ dans le cadre d’un « partenariat stratégique de long terme » entre les deux entreprises.

Un accès démultiplié à la puissance de calcul

Concrètement, cet accord donnera à SSI un accès massif aux GPU haut de gamme de Nvidia, notamment sa toute dernière plateforme Vera Rubin.

Les deux sociétés indiquent que cela permettra à la start-up de multiplier par dix ses capacités de calcul dans les douze prochains mois. Une bascule stratégique pour SSI, qui s’appuyait jusqu’ici principalement sur les puces TPU de Google, selon des informations du Wall Street Journal.

« Nous avons des recherches qui méritent d’être passées à l’échelle, et l’accès à un grand ordinateur Nvidia va nous le permettre », a déclaré Ilya Sutskever,. De son côté, Jensen Huang, PDG de Nvidia, a salué un chercheur qui a déjà « été à l’origine de percées fondamentales dans les bases de l’IA moderne », se disant impatient de découvrir « les nouvelles avancées que SSI pourra réaliser grâce à notre plateforme Vera Rubin ».

Les modalités financières précises n’ont pas été confirmées officiellement mais ce type d’engagement s’accompagne généralement de jalons (« milestones ») à atteindre par SSI.

Ilya Sutskever…le mystérieux

Né en URSS et élevé en Israël, Ilya Sutskever s’est fait un nom comme doctorant au Canada, sous la direction du prix Nobel Geoffrey Hinton.

Leur article co-écrit en 2012 sur la vision par ordinateur est considéré comme l’un des déclencheurs de la course moderne à l’IA, en démontrant que la mise à l’échelle des réseaux de neurones profonds, combinée à d’immenses volumes de données et de calcul, produisait des gains d’intelligence mesurables.

Passé par Google, il rejoint ensuite OpenAI en 2015 comme cofondateur, où ses travaux contribuent directement à la naissance de ChatGPT. Mais sa relation avec le PDG Sam Altman se rompt brutalement fin 2023 quand il vote en faveur de son limogeage avant de quitter lui-même l’entreprise quelques mois après la réintégration de ce dernier.

Il fonde alors Safe Superintelligence en 2024, avec un objectif affiché unique : une course de recherche « en ligne droite » vers une IA surhumaine mais non menaçante pour l’humanité — ce que l’industrie désigne sous le terme de « safe superintelligence ».

La start-up lève rapidement environ 2 milliards $ auprès de poids lourds du capital-risque comme Andreessen Horowitz, Sequoia Capital, Greenoaks et Lightspeed Venture Partners, atteignant une valorisation d’environ 30 milliards $ l’an dernier.

Le grand flou entretenu

Pourtant, SSI reste l’une des entreprises les plus opaques du secteur : pas de produit, pas de  publication scientifique à ce jour et seulement quelques dizaines d’employés.

Ilya Sutskever, qui fut l’un des premiers à théoriser la fameuse « loi de mise à l’échelle » (plus de données et de calcul égale plus de capacités), semble aujourd’hui plus circonspect sur cette approche. « Maintenant que le calcul est important, très important, on est dans un sens revenu à l’âge de la recherche », avait-il déclaré en novembre dans un podcast.

Ces montages, où les fabricants de puces financent directement leurs propres clients, se multiplient dans l’industrie. La semaine dernière, AMD a annoncé un investissement pouvant atteindre 5 milliards $ dans Anthropic. Une stratégie qui permet aux chipmakers de sécuriser des débouchés massifs tout en s’assurant la fidélité de talents clés dans la course à l’IA générale.

The post Nvidia mise gros sur le mystère Sutskever appeared first on Silicon.fr.

On pouvait s’y attendre : Anthropic a fini par communiquer une position officielle sur les modèles à poids ouverts (open-weight).

En toile de fond, un ralliement massif de la tech américaine en faveur de ces modèles, dans un contexte qui incite Washington à y restreindre l’accès.

Près d’une centaine d’organisations – dont Google, Meta, Microsoft, NVIDIA et OpenAI* – ont signé une lettre ouverte vantant les bénéfices de l’open-weight pour l’économie et la société. Anthropic n’est pas dans la boucle. D’aucuns y ont perçu une forme de soutien aux ambitions de l’administration Trump, dans l’optique de protéger son activité, fondée exclusivement sur la commercialisation de modèles fermés.

L’open-weight, porteur de risques irréversibles ?

Dario Amodei nie cette version des faits. Interdire les modèles open-weight n’est pas la solution, affirme le patron d’Anthropic. L’intéressé s’y dit même favorable… aussi longtemps qu’ils ne présentent pas de danger. Et de se référer à son essai « L’Adolescence de la technologie », écrit en début d’année. Il y expose notamment sa crainte que des « gouvernements autoritaires » parviennent à développer des IA « plus puissantes que celles des États-Unis » et qu’elles les exploitent pour « renforcer leurs capacités militaires, de renseignement et de surveillance ». Ces préoccupations rejoignent celles que J.D. Vance avait exprimées au Sommet de l’IA 2025.

Dario Amodei redoute aussi l’usage abusif de l’IA pour des attaques informatiques ou biologiques. En la matière, les modèles open-weight présentent un plus grand risque que les modèles fermés, clame-t-il. Motif : il est très difficile de leur appliquer des garde-fous ou de surveiller leur usage. Et une fois les poids publiés, on ne peut plus les rappeler… Pour appuyer son propos, le dirigeant mentionne un commentaire de l’AI Safety Institute britannique. Celui-ci constate que l’ouverture des poids « crée un risque persistant et irréversible d’usage abusif » en faisant « définitivement perdre » le contrôle sur les garde-fous et les accès utilisateurs.

Anthropic appelle (à nouveau) à restreindre l’accès aux puces et la distillation

Une interdiction pure et simple d’utilisation des modèles open-weight ne résoudrait rien, estime Dario Amodei. Cela protégerait effectivement des entreprises comme Anthropic, admet-il. « Mais cela n’a jamais été mon objectif »…

Pour lui, la principale solution consisterait à ne pas vendre à la Chine des « puces puissantes », ni des équipements pour fabriquer ces puces. Tout en agissant en parallèle contre le contournement des restrictions à l’export. Le patron d’Anthropic tient depuis longtemps ce discours. La Chine a une capacité de production limitée, veut-il croire : les lois d’échelle font que sans puces américaines, elle ne pourra pas développer de modèles plus puissants que les États-Unis.

Deuxième levier, suggéré lui aussi de longue date : agir politiquement contre les « opérations industrielles de distillation ». Dario Amodei y ajoute des tests de sûreté obligatoires pour tous les modèles « suffisamment capables », qu’ils soient ouverts ou fermés, et peu importe leur pays d’origine. Cela implique que Pékin collabore. Anthropic considère qu’une coopération limitée est possible sur le risque de conception d’armes biologiques, la Chine y ayant son intérêt.

Des risques d’asymétrie attaquant-défenseur

Dario Amodei est en phase avec les signataires de la lettre ouverte sur l’idée que la réponse au problème de la distillation doit passer par des cadres juridiques et commerciaux ciblés. Il se dit plus globalement d’accord quant aux bénéfices économiques et sociétaux de l’IA. Ainsi que, « au moins dans certains cas », quant au contrôle accru donné aux utilisateurs.

Le dirigeant ne pense en revanche pas que l’ouverture favorise nécessairement le développement de garde-fous. Ni qu’en matière de cyber, elle bénéficie forcément plus aux défenseurs qu’aux attaquants. « L’inverse est au moins aussi probable », juge-t-il, projetant par exemple une forte asymétrie sur la biologie. Des modèles suffisamment puissants pourraient rapidement transformer en armes des virus de niveau pandémiques, alors que la défense contre ces virus serait un chantier de plusieurs années.

* OpenAI n’avait pas immédiatement signé la lettre.

Illustration générée par IA

The post Anthropic et les modèles open-weight : oui, mais… appeared first on Silicon.fr.

Il y a désormais, à l’agenda du Congrès américain, un « AI Kill Switch Act ».

Le démocrate Ted W. Lieu et le républicain Nathaniel Moran sont dépositaires de cette proposition de loi.

Chiffre d’affaires, ressources de calcul, préjudice… Des seuils essentiellement économiques

Le texte amenderait le Homeland Security Act de 2002. Il ciblerait les systèmes d’IA dont le développement a nécessité, sur la base du prix de marché aux États-Unis, au moins 100 M$ de puissance de calcul.

Seraient concernées les entités qui opèrent ces systèmes, les mettent à disposition de tiers par API, service hébergé ou « mécanisme similaire »… et ont réalisé un CA brut d’au moins 500 M$ sur l’année calendaire écoulée*.

Il appartiendrait à ces entités d’être techniquement capables de :

• Stopper l’inférence
• Mettre fin à l’accès utilisateur
• Suspendre l’accès pour un compte, un utilisateur ou un usage posant le risque que surviennent certains incidents
• Éteindre la technologie concernée

Les incidents en question incluraient notamment les usages imprévus causant la mort d’au moins 10 personnes ou un préjudice économique d’au moins 100 M$. Ils engloberaient aussi, entre autres, les cas où un système cacherait aux mécanismes de surveillance ses capacités, ses intentions ou ses actions. Ainsi que les scénarios de « perte de contrôle ». Autrement dit, de poursuite d’un objectif qui n’est pas celui prévu. Par exemple :

• Comportement contraire aux instructions dans des contextes « à fort enjeu » impliquant en particulier des infrastructures critiques
• Modification des règles opérationnelles ou des restrictions de sûreté sans autorisation
• Sabotage d’un mécanisme de surveillance
• Octroi de l’accès aux poids sans permission

Une « réponse graduée »… et jusqu’à 20 M$ d’amende par jour

S’il existait un risque crédible que surviennent les incidents en question, le département de la Sécurité intérieure (DHS) devrait enclencher un mécanisme de « réponse graduée ». En l’occurrence, imposer des mesures adaptées à la sévérité et à l’imminence du risque :

• Réduction ou modification du débit d’inférence, de l’accès utilisateur ou de l’allocation de puissance de calcul
• Désactivation ou restriction d’une capacité
• Suspension d’une technologie
• Extinction d’une technologie
• Basculement d’une opération dépendante de cette technologie vers une version antérieure ou vers un système de secours

Le DHS aurait la charge d’établir des normes pour le kill switch. Les entités concernées y adhéreraient sur la base du volontariat. Si un des incidents visés a effectivement lieu, il leur faudrait conserver poids et télémétrie ; tout en communiquant, dans la mesure du possible, les conséquences potentielles pour les utilisateurs.

Un délai de 48 heures serait accordé pour déposer un recours, toutefois non suspensif. Le DHS aurait 5 jours pour se prononcer. Délai au-delà duquel sa réponse serait réputée négative. Resterait alors la possibilité d’un pourvoi en appel sous 60 jours devant les tribunaux du district de Columbia.

Les sanctions pourraient aller jusqu’à 20 M$ d’amende par jour en cas de violations des dispositions concernant les cas où un incident a effectivement eu lieu.

L’AI Act impose déjà un « bouton d’arrêt » pour les systèmes d’IA à haut risque

En Europe, l’AI Act n’établit pas de tel « coupe-circuit étatique ». Son article 14 impose néanmoins des mesures de contrôle humain sur l’utilisation des systèmes d’IA classés à haut risque.

Les fournisseurs concernés ont deux options. Soit intégrer ces mesures avant la mise sur le marché ou la mise en service, soit permettre aux déployeurs de les mettre en œuvre.

Dans tous les cas, les personnes chargées du contrôle doivent pouvoir intervenir dans le fonctionnement du système d’IA. Ou l’interrompre « au moyen d’un bouton d’arrêt ou d’une procédure similaire ».

Une exigence de contrôle humain accru s’applique pour les systèmes d’identification biométrique à distance. Le déployeur ne doit pas pouvoir prendre de décision sans vérification et confirmation séparée par au moins deux personnes physiques.

* Il existerait une exception pour les technologies destinées uniquement à un usage « personnel, académique ou non commercial ».

À consulter en complément :

Comment le shadow AI s’est invité à l’Assemblée nationale
L’AI Act doit-il être l’affaire des DPO ?
La Cour suprême US a-t-elle condamné le Data Privacy Framework ?
Agents IA : Bruxelles dégaine une mesure d’urgence contre Meta

Illustration générée par IA

The post Un « kill switch » pour l’IA ? Ce que projette le législateur américain appeared first on Silicon.fr.

L’intelligence artificielle va-t-elle avoir son propre OTAN cyber ? Nvidia lance l’Open Secure AI Alliance (OSAA). Cette coalition regroupe près de 40 entreprises technologiques. Son objectif principal consiste à définir les futurs standards de sécurité de l’IA.

Chaque membre fondateur s’engage à fournir des technologies existantes ou des projets open source. Cela leur permet de placer ses briques au cœur de l’écosystème.

De son côté, Nvidia met à disposition des modèles d’IA open source accompagnés de leurs paramètres entraînés (weights). Et fournit aussi des jeux de données ainsi que le projet NOOA. Ce framework de contrôle des agents IA est déjà disponible sur GitHub.

HPE met en avant ses « modèles open weight » et ses frameworks d’identité. L’entreprise cherche ainsi à sécuriser le cycle de développement logiciel. Quant à CrowdStrike, Palo Alto Networks et Cloudflare, ils apportent leurs capacités de détection et de réponse aux incidents.

L’OSAA vise à offrir aux équipes de sécurité des outils « frontier », inspectables et souverains. Ces ressources aideront à auditer, tester et contrôler les agents autonomes déployés.

Absences notables et lignes de fracture du marché

L’OSAA arrive dans un contexte géopolitique et réglementaire tendu. Elle se présente comme une alternative « compatible avec la sécurité nationale ». Le projet repose sur des technologies ouvertes, mais reste contrôlé par des entreprises occidentales alliées.

Comme le résume Nvidia, « L’Open Secure AI Alliance œuvrera à remédier aux vulnérabilités et à les divulguer en utilisant des technologies ouvertes ». L’alliance souhaite privilégier la transparence…plutôt que les restrictions généralisées.

L’initiative s’appuie sur des communautés existantes comme la Linux Foundation, l’initiative Akrites et OpenSSF. Elle s’ancre ainsi dans un écosystème open source déjà structuré.

Cependant, certaines absences s’avèrent très révélatrices. Meta a signé une lettre pour les modèles, mais ne figure pas parmi les fondateurs. De même, Google a été cité par erreur avant d’être retiré de la liste.

Ces absences illustrent parfaitement les fractures du marché :

Hyperscalers : Microsoft est présent. En revanche, Google et AWS sont absents, ce qui traduit des stratégies divergentes.

Open source radical vs open contrôlé : Des acteurs comme Hugging Face coexistent avec des spécialistes de la défense (Palantir, SpaceX). Ce mélange pourrait créer des tensions sur le degré réel d’ouverture des standards.

Géographie : L’alliance réunit des entreprises américaines, européennes et coréennes. Elle forme un bloc essentiellement atlantiste, sans représentation chinoise ou du Sud global.

Qui captera la valeur de la sécurité IA ?

À moyen terme, l’OSAA pourrait structurer plusieurs segments émergents :

AI security platforms : Des solutions intégrées pour protéger les modèles, les pipelines et les agents.

LLM security Des services d’audit et de « stress test » des modèles.

AI governance Des outils de traçabilité et de conformité (AI Act, NIST, etc.).

Les éditeurs de cybersécurité traditionnels veulent étendre leur périmètre. CrowdStrike, Palo Alto et Cloudflare ambitionnent de devenir la couche de sécurité transverse de l’IA.

Parallèlement, les fournisseurs d’infrastructure comme Nvidia, HPE et Dell souhaitent intégrer la sécurité nativement. Ils espèrent ainsi renforcer la valeur perçue de leurs plateformes.

Pour les startups spécialisées (Hugging Face, LangChain, Nous Research), l’enjeu est double. Elles doivent gagner en légitimité sans transformer leurs technologies en simples commodités.

À l’image de la CNCF pour le cloud natif, l’OSAA veut normaliser les pratiques de sécurité. À court terme, la coalition publiera des architectures de référence pour les gouvernements.

Plus tard, elle cherchera à influencer les standards internationaux et la souveraineté des données.

Derrière cette démarche collaborative se joue une bataille d’influence classique. L’acteur qui imposera ses frameworks verrouillera les usages et captera la majorité de la valeur.

The post Open Secure AI Alliance : Nvidia veut fédérer le standard de sécurité de l’IA appeared first on Silicon.fr.