Des modèles spécialisés aux templates d’applications, la demande en solutions sectorielles est croissante, mais le marché n’est pas encore mature.

Gartner fait la remarque dans son premier Magic Quadrant des « plates-formes de développement d’applications IA ».

Il est tentant d’y voir la continuité de celui consacré aux « services d’IA cloud pour les développeurs » (dernière édition : avril 2024). La majorité des fournisseurs classés dans l’un se retrouvent d’ailleurs dans l’autre. À commencer par les quatre désignés « leaders » : AWS, Google, IBM et Microsoft.

D’un Magic Quadrant à l’autre, l’idée reste la même : les solutions évaluées permettent d’intégrer de l’IA dans des applications. La terminologie évolue néanmoins pour englober la notion de plate-forme. Un mouvement que Gartner a suivi ces derniers temps pour quantité d’autres marchés (gouvernance des données et stockage d’entreprise, par exemple).

La gouvernance, critère obligatoire ; pas l’observabilité

Les briques fonctionnelles à fournir impérativement étaient, dans les grandes lignes : développement avec et sans code, ancrage, garde-fous, catalogue de modèles, déploiement, gouvernance et évaluations.

Les éléments suivants n’étaient pas obligatoires :

• Gestion de la sécurité et du risque (DLP, sandbox, IAM…)
• Routage intelligent des prompts (selon cas d’usage, performance et coût)
• Passerelle IA (pour la continuité d’activité)
• Observabilité
• Techniques « avancées » d’ancrage (graphes de connaissances, chunking, reranking…)
• Composabilité (intégration de solutions tierces)
• Gestion des protocoles émergents (MCP, A2A, etc.)
• Simulation
• Catalogues et marketplaces d’outils, de données et d’agents

Il fallait aussi respecter quelques seuils business. Principalement, avoir dégagé au moins 100 M$ de CA en 2024 avec les offres concernées ou bien être en mesure de revendiquer au moins 500 organisations clientes.

Ces seuils ont coûté leur place à Cohere, CrewAI, Dify, Live Tech et WRITER, qui ont cependant tous droit à une « mention honorable ». Même situation pour H2O.ai, qui figurait dans le dernier Magic Quadrant des services d’IA cloud pour les développeurs.

11 fournisseurs, 4 « leaders »

Les offreurs sont jugés sur deux axes. L’un prospectif (« vision »), centré sur les stratégies (sectorielle, géographique, commerciale, marketing, produit…). L’autre censé refléter la capacité à répondre effectivement à la demande du marché (« exécution » : expérience client, performance avant-vente, qualité des produits/services…).

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

Rang	Fournisseur
1	Google
2	AWS
3	Microsoft
4	IBM
5	Volcano Engine
6	Alibaba Cloud
7	Palantir
8	Tencent Cloud
9	LangChain
10	OpenAI
11	CoreWeave

Sur l’axe « vision » :

Rang	Fournisseur
1	Microsoft
2	Google
3	AWS
4	OpenAI
5	IBM
6	Volcano Engine
7	Alibaba Cloud
8	Palantir
9	Tencent Cloud
10	CoreWeave
11	LangChain

Des 11 fournisseurs classés, 4 n’étaient pas présents dans le Magic Quadrant des services d’IA cloud pour les développeurs :

• CoreWeave, avec son offre Weights & Biases (issue de l’acquisition de la société éponyme)
• LangChain, avec ses frameworks LangChain et LangGraph ainsi que sa plate-forme commerciale LangSmith
• Palantir avec son Artificial Intelligence Platform, commercialisée avec Palantir Foundry
• Volcano Engine, avec son offre Volcano Ark

AWS doit mieux communiquer sur la valeur métier

AWS a été évalué sur son offre Bedrock (hors AgentCore, lancé après les derniers relevés de Gartner).

Sa stratégie sectorielle fait mouche auprès du cabinet américain, entre agents prêts à l’emploi, modèles spécialisés (TelClaude pour les télécoms, par exemple) et gestion de formats de données comme FHIR (Fast Healthcare Interoperability Resources) ou ODSU (Open Subsurface Data Universe). Bon point également pour une brique que Gartner a déjà saluée en d’autres occasions : la vérification par raisonnement automatisé.

AWS gagnerait à améliorer sa communication sur la valeur métier, ainsi qu’auprès de certains secteurs de marché, estime Gartner. Qui souligne par ailleurs le risque potentiel lié au choix de s’appuyer sur de l’« innovation organique » et des partenariats (AWS acquiert moins de technologies IA et recrute moins de talents que la concurrence).

Google peut progresser sur le déploiement et la gouvernance

Avec Vertex AI, Google propose un licensing « parmi les plus flexibles » entre les fournisseurs classés au Magic Quadrant. Gartner note les promotions accordées aux start-up, les programmes académiques et les partenariats d’intégration (Accenture, Cognizant, Deloitte, Onix et Quantiphi sont cités). Il rappelle aussi que Google est à l’origine du protocole A2A – lancé en 2025 puis confié à la Fondation Linux – et qu’il permet de déployer Vertex AI sur site et en périphérie.

Les utilisateurs de Vertex AI ont tendance à le noter moins bien que les solutions concurrentes concernant les capacités de déploiement et de gouvernance. Quant au modèle économique, encore principalement fondé sur une facturation, sa transition vers du SaaS avec débit garanti est lente, entraînant un risque de perte de compétitivité. Google doit aussi gagner en notoriété avec des campagnes plus ciblées, estime Gartner.

IBM, en retard sur la multimodalité

Avec watsonx, IBM est salué pour son marketing, tant de par sa capacité à cibler divers profils et métiers que de par sa présence sur les réseaux sociaux… et son sponsoring sportif (F1, Wimbledon). Autre point positif : son positionnement « ouvert » dont témoignent, selon Gartner, les modèles Granite (open-weight, licence Apache2) et le framework BeeAI.

Les scores attribués par les clients sont plus faibles que chez les autres « leaders » sur l’observabilité et les agents prêts à l’emploi. IBM a par ailleurs du retard sur la gestion de la multimodalité et sur les certifications de conformité dans certaines régions géographiques.

Microsoft, encore largement branché à OpenAI

Microsoft a efficacement communiqué le rebranding d’Azure AI en Azure AI Foundry, juge Gartner, qui salue aussi une bonne communication autour des outils pour les développeurs. Sur le plan fonctionnel, le cabinet américain apprécie les capacités d’orchestration et de développement multimodal. Ainsi que l’extension du catalogue de ressources et des options de déploiement.

Les scores attribués par les clients sont inférieurs à ceux des autres « leaders » sur la partie services et support. Ils le sont aussi sur le prix. Gartner y ajoute une dépendance encore importante aux technologies d’OpenAI.

Illustration générée par IA

The post Développement d’applications IA : une demande sectorielle pour l’heure insatisfaite appeared first on Silicon.fr.

La collaboration entre SAP et Mistral AI devient une affaire d’États.

La France et l’Allemagne ont annoncé leur intention d’établir un partenariat public-privé avec les deux sociétés. Elles promettent la signature d’un accord-cadre contraignant d’ici à mi-2026.

À partir de là, et jusqu’en 2030, des cas d’usage seront déployés dans les administrations publiques. Il est notamment question d’automatiser des workflows financiers – en particulier le classement des factures et les contrôles d’audit. On nous parle aussi d’agents pour :

• Aide à la décision et conformité
• Rédaction, simulatin de scénarios et justification budgétaire
• Contrôle d’éligibilité et aide au remplissage des formulaires pour les citoyens

Pour piloter l’initiative, Paris et Berlin entendent convoquer un comité dédié au Consortium franco-allemand pour l’infrastructure européenne. Un EDIC dont on n’avait pas entendu parler jusque-là.

Le partenariat se traduira aussi par des labos communs d’innovation en matière d’IA-ERP. Il est ouvert à d’autres fournisseurs européens.

SAP et Mistral AI, officiellement alliés depuis juin 2024

Mistral AI se montre plus emphatique : il évoque l’ambition de livrer « une stack IA souveraine pour l’Allemagne et l’Europe », en intégrant ses modèles dans l’AI Foundation de SAP et en codéveloppant des solutions sectorielles.

Dans la pratique, plusieurs modèles ont déjà été intégrés dans cette couche de conception et d’orchestration qui repose sur l’offre SAP BTP (Business Technology Platform). Parmi eux, Mistral Large 2. Son intégration fut l’un des premiers temps forts du « partenariat multiannuel » que les deux entreprises avaient annoncé en juin 2024.

La prochaine phase va consister à intégrer Mistral AI Studio et Le Chat dans l’AI Foundation. Ils voisineront avec des LLM de Cohere, d’IBM et de NVIDIA, tous hébergés sur l’infra SAP. Ainsi qu’avec d’autres accessibles par API via Bedrock, Vertex AI et Azure OpenAI.

Les Chemins de fer suisses, un client référent pour Mistral AI sur SAP

L’intégration de Mistral Large sur SAP a un client référent : les Chemins de fer suisses. Le modèle est intégré dans les workflows via le portail SAP Build Work Zone et Microsoft Teams. Il apporte un support utilisateur multilingue (allemand, français, italien) dans le contexte d’une migration vers S/4HANA.

Aux dernières nouvelles, le projet semblait devoir se porter sur l’automatisation des achats, à travers les capacités d’appel d’outils et de fonctions de Mistral AI. Était aussi évoqué Agent Accruals. Ce service de tenue de journal comptable fait partie de la quinzaine d’agents Joule que SAP a promis de rendre disponibles d’ici à mi-2026.

Illustration © BMDS/Woithe

The post Le partenariat SAP-Mistral AI trouve un relais dans l’administration publique appeared first on Silicon.fr.

Quel modèle économique pour Agent 365 ?
On avait peu de certitudes avant son officialisation. On n’en a pas beaucoup plus après*.

La composition de l’offre est plus claire. Microsoft adapte des produits existants – essentiellement Entra, Purview et Defender – pour constituer un « plan de contrôle des agents IA ». En premier lieu, ceux créés avec ses outils (Agent Framework, Copilot Studio, Azure AI Foundry, Semantic Kernel). Mais aussi ceux conçus avec certains frameworks tiers (pour le moment, OpenAI Agents, Claude Code et LangGraph).

Le SDK qui établit le lien avec ces frameworks n’apporte ni la logique, ni l’orchestration. En cela, il est dit complémentaire au SDK Microsoft 365 Agents, en permettant principalement de :

• Doter les agents d’une identité à l’échelle de l’écosystème Microsoft
• Leur permettre de répondre à des événements dans ce même écosystème
• Les superviser sur une base OpenTelemetry
• Les connecter à des outils (serveurs MCP pour Word, SharePoint/OneDrive, Teams, Outlook, Dataverse/Dynamics 365 et Copilot Search)

Un nouveau profil d’« utilisateur agentique »

Certaines composantes d’Agent 365 étaient déjà en phase expérimentale, à l’image d’Entra Agent ID. Cette brique adosse à l’annuaire un registre où sont consignées toutes les instances d’agents. Chacune a une relation directe avec une identité agentique ; et, éventuellement, avec un « utilisateur agentique ».

Le mode « utilisateur agentique » est une nouveauté d’Agent 365. Il complète la possibilité d’utiliser un agent au nom d’un utilisateur humain (délégation des tokens et des permissions) ou comme une application indépendante (attribution d’une identité de workload). Il permet, par exemple, qu’un agent soit invoqué dans les apps Microsoft via les mentions (@) ou ait sa propre adresse e-mail et son stockage OneDrive… sous réserve de disposer des bonnes licences.

C’est à un admin d’attribuer ces licences, au moment d’activer des agents. Plus précisément des instances d’agents, créées à partir de templates approuvés au préalable et publiés soit dans le magasin Microsoft 365 Copilot, soit dans le catalogue d’apps de Teams.

Quoique complémentaire à Microsoft 365, Agent 365 en est distinct sur le plan commercial. Il est pour le moment en bêta publique, dans le cadre du programme Frontier (accès anticipé aux fonctionnalités IA).

* Il y a quelques indices, comme le fait que la protection des identités d’agents est « incluse dans Entra P2 pendant la preview« .

Illustration principale générée par IA

The post Agent 365 : après l’orchestration, Microsoft promet l’encadrement de l’IA agentique appeared first on Silicon.fr.

Le 3-AZ en Allemagne, c’est pour bientôt.

OVHcloud l’a officialisé à l’occasion du Sommet sur la souveraineté numérique européenne.

L’événement étant organisé à Berlin, l’annonce était de circonstance. Elle a largement éclipsé l’ouverture du 3-AZ dans un autre pays : l’Italie. Cette architecture à trois zones de disponibilité a effectivement été déployée sur la région cloud de Milan (eu-south-mil). Pour le moment sur la partie IaaS. DBaaS et Kubernetes managé doivent suivre « très bientôt », si on en croit la roadmap Public Cloud.

Le 3-AZ est également disponible à Paris (région eu-west-par), depuis avril 2024.

Une base établie dans la région de Francfort

En Allemagne, OVHcloud avait ouvert son premier datacenter en 2017, au nord-ouest de Francfort, dans la ville de Limburg-sur-la-Lahn (Hesse). Le bâtiment était auparavant une imprimerie. Une connexion directe à Bruxelles, Strasbourg et Prague avait été établie.

L’ensemble fut agrandi par deux fois, en 2018 puis en 2021, faisant passer la surface informatique à environ 2500 m². Depuis, un autre datacenter – de 6000 m² – a vu le jour dans la même ville. La première pierre fut posée en 2022. Cette année-là, le siège avait déménagé à Cologne (Rhénanie-du-Nord-Westphalie). Il était resté implanté à Sarrebruck (Sarre) depuis la création, en 2006, de la filiale allemande – dont Henryk Klaba, frère d’Octave, fut le premier DG.

Datacenter à Kehl, cloud de confiance avec T-Systems… Des projets qui n’ont pas abouti

OVH eut un projet de datacenter à Kehl, ville limitrophe de la France. Il l’avait évoqué en 2013 à l’occasion de l’inauguration de son deuxième datacenter de conteneurs à Strasbourg (SBG4, qui serait touché à la marge lors de l’incendie de 2021). Il était question d’héberger jusqu’à 10 000 serveurs. L’idée ne s’est pas concrétisée.

D’autres projets en Allemagne n’ont pas abouti, à l’image de la collaboration annoncée en 2020 avec T-Systems, filiale de Deutsche Telekom. Promesse : développer, pour 2021, un cloud de confiance sur base OpenStack respectant les principes de Gaia-X. Le gouvernement français, par la voie de Bruno Le Maire et de Cédric O, s’en était félicité.

T-Systems a aujourd’hui sa propre offre OpenStack (Open Telekom Cloud), sans qu’apparaissent de liens technologiques ni commerciaux avec OVHcloud.

De la police nationale à la sécurité sociale, des contrats référents pour OVHcloud

Dans son annonce du 3-AZ en Allemagne, OVHcloud mentionne quatre clients : Commerz Real, ITSC, la Bundesagentur für Arbeit (littéralement « Agence fédérale de l’emploi ») et la Bundespolizei (police nationale).

Le contrat avec Commerz Bank a été annoncé cette année. La société de gestion d’actifs, spécialisée dans les investissements immobiliers et les énergies renouvelables, va héberger « une part importante » de son infrastructure chez OVHcloud.

La police nationale a quant à elle décidé d’héberger chez OVHcloud son nouveau programme de formation, autour d’une solution de visio développée par une société allemande. Le contrat, également annoncé cette année, court sur 5 ans.

Le deal avec l’Agence fédérale pour l’emploi a été signé en 2024. Deux autres organismes de la sécurité sociale allemande sont parties au contrat, qui porte sur une plate-forme multicloud gérée par Computacenter. AWS, Google et Microsoft sont dans la boucle, aux côtés de deux fournisseurs allemands (IONOS, StackIT), un polonais (CloudFerro)… et OVHcloud. Le projet s’étale sur 4 ans, pour 100 M€ d’investissement.

Pour ce qui est d’ITSC (fournisseur de services IT), il avait organisé, en 2023, un appel d’offres public qu’OVHcloud avait remporté. Il s’agissait de migrer dans le cloud le traitement, la sauvegarde et le stockage des données de santé qu’une quarantaine de caisses d’assurance maladie d’entreprise.

La même année, OVHcloud avait remporté un appel d’offres organisé par le Deutsches Zentrum für Luft- und Raumfahrt (Centre allemand pour l’aéronautique et l’astronautique). Il s’agissait d’héberger l’infrastructure d’un projet porté par ce dernier : COOPERANTS (Collaborative Processes and Services for Aeronautics and Space). Son objectif : constituer, dans le respect des principes de Gaia-X, un data space européen pour l’industrie aérospatiale.

Illustration principale (datacenter de Roubaix 5) © OVHcloud

The post OVHcloud en Allemagne : ce qu’il y a en attendant la région 3-AZ appeared first on Silicon.fr.

Cloudflare est formel : ce 18 novembre, il a subi sa « pire panne depuis 2019 ».

Cette dernière avait été déclenchée par le déploiement d’une règle WAF pour la détection XSS. Un problème de regex avait entraîné une surconsommation CPU sur les nœuds qui géraient le trafic HTTP(S). Le proxy principal était tombé, comme le CDN.

Le système de gestion des bots mis K.-O. par un changement de configuration

Cette fois, l’incident a pris racine dans un changement de permissions sur une base de données ClickHouse. L’idée était, dans les grandes lignes, de rendre explicite un accès jusque-là accordé implicitement aux utilisateurs lors des requêtes de tables système.

Faute d’un filtrage approprié, une requête s’est mise à générer des colonnes en double. Cette requête provenait d’un des modules du proxy principal : celui dédié à la gestion des bots.

Ce module exploite, entre autres, un modèle d’apprentissage automatique qui attribue un score à chaque requête. Il s’appuie sur un fichier de configuration réunissant des features (caractéristiques individuelles utilisées pour prédire si une requête est ou non automatisée).

Ce fichier est régulièrement rafraîchi – à intervalle de quelques minutes – et diffusé sur le réseau Cloudflare.
La version « doublonnée » a dépassé la limite de 200 features paramétrée dans le système de gestion des bots pour éviter la surconsommation de mémoire. Le module est ainsi passé en erreur, affectant tout le trafic qui en dépendait.

Des pannes en cascade et un tableau de bord inaccessible

D’autres services exploitant le proxy principal ont été touchés. Notamment Workers KV (magasin clé-valeur) et Turnstile (alternative aux CAPTCHA).
L’indisponibilité de ce dernier a empêché les connexions au tableau de bord – à moins d’avoir une session active.
Cloudflare Access (contrôle d’accès) a aussi connu des problèmes d’authentification.
En parallèle, la consommation CPU des systèmes de débogage et d’observabilité a accru la latence du CDN.

Vers 14 heures, soit une heure et demie après le début de l’incident, un correctif fut déployé sur Workers KV afin de contourner le proxy. Les taux d’erreurs sur les services aval se sont réduits.

D’autres difficultés ont été recensées par la suite, après la restauration d’une version saine du fichier de features. Le backlog de tentatives de connexion, combiné aux retries, a submergé le dashboard.

Cloudflare a d’abord cru à une attaque

Jusqu’à l’application du correctif pour Workers RV, le système a eu un comportement particulier : à plusieurs reprises, il a brièvement récupéré. Et pour cause : il arrivait qu’un fichier sain soit généré, en fonction de la partie du cluster sur laquelle s’exécutait la requête du service de gestion des bots.

Ce comportement a compliqué l’identification du problème. Jusqu’à ce que, finalement, tous les nœuds ClickHouse se mettent à générer le mauvais fichier.
Cloudflare a un temps pensé à une attaque, d’autant plus que sa page de statut, qui n’a pas de dépendance à ses services, était aussi tombée. Mais il s’agissait d’une « coïncidence »…

L’acheminement du trafic était largement revenu à la normale vers 15 h 30. Passé 18 heures, tous les systèmes de Cloudflare fonctionnaient normalement.

En conséquence de cette panne mondiale, l’entreprise promet de renforcer le contrôle de l’ingestion des fichiers que ses systèmes génèrent (mise sur le même plan que les fichiers générés par les utilisateurs). Elle compte aussi supprimer la possibilité que des dumps et autres rapports d’erreur épuisent les ressources système. Et réviser les modes d’échec pour les conditions d’erreur sur tous les modules de son proxy principal.

Illustration générée par IA

The post Panne Cloudflare : ce qui s’est passé dans le système anti-bots appeared first on Silicon.fr.

« Quand l’un [des] ‘gardiens du web’ vacille, c’est toute notre vie numérique qui s’arrête. »

La panne mondiale de Cloudflare a inspiré ce commentaire à mc2i.

Le cabinet de conseil n’est pas le seul à s’inquiéter de la dépendance d’Internet à des infrastructures portées par une poignée d’acteurs. Il l’est d’autant moins après les incidents majeurs qui ont récemment affecté AWS et Azure.

Chez le premier, quantité de services ont été perturbés en conséquence d’un souci de résolution DNS sur une base de données.
Chez le second, le problème est parti d’un état invalide introduit par un changement de configuration sur le CDN Azure Front Door.

Un bug dans le système de contrôle des bots

Cloudflare avait d’abord évoqué un « pic de trafic inhabituel »* vers un de ses services – et expliqué que le reste du trafic en avait pâti.

Son CTO est ensuite allé plus loin. À l’en croire, un changement de configuration a enclenché un « bug latent » dans un service concourant au contrôle des bots. S’en sont suivis des effets en cascade. « Ce n’était pas une attaque« , a-t-il ajouté.

Il était 12 h 20 en France, ce 18 novembre, quand l’incident a démarré. Cloudflare l’a signalé sur sa page de statut une demi-heure plus tard.

Vers 14 heures, on nous annonçait que le problème était identifié. Le déploiement d’un correctif restaurant l’accès au tableau de bord Cloudflare était officialisé vers 15 h 30. Une étape importante donnant aux clients la possibilité d’implémenter des mécanismes de contournement.

Quelques minutes plus tard, l’entreprise avait dit estimer que l’incident était résolu. C’est à ce moment-là que son CTO s’était exprimé.

Cloudflare a par la suite reconnu que certains clients pourraient encore rencontrer des problèmes de connexion ou d’utilisation du tableau de bord. Puis déclaré que les scores attribués aux bots seraient impactés par intermittence le temps de la récupération.

À 17 h 30, la situation continuait de s’améliorer, mais n’était pas encore pleinement revenue à la normale. À 18 h 15, la latence et le taux d’erreurs revenaient à des « niveaux normaux ».

ChatGPT, Claude, Gemini, Le Chat, Perplexity… Silence chez les chatbots

Touché, Canva a fait partie des clients qui ont explicitement attribué la responsabilité à Cloudflare. Touché tant sur ChatGPT que sur Sora et sur son API, OpenAI a simplement parlé d’un « fournisseur tiers ». Même chose pour Discord, qui a toutefois précisé que ce fournisseur rencontrait un « problème majeur »…

Également affecté, Coinbase a considéré que l’incident (« latence ou performance de connexion dégradée pour certains utilisateurs ») était résolu à 16 h 38. Chez Twilio, c’était fait une demi-heure plus tôt (problèmes de login pour les utilisateurs de Twilio et de Sengrid), à peu près en même temps que chez Sage (problèmes d’accès à certains produits).

ChatGPT n’a pas été le seul chatbot perturbé. Gemini (Google), Claude (Anthropic), Le Chat (Mistral AI) et Perplexity AI, entre autres, l’ont aussi été.

Un autre incident notable chez Cloudflare en juin 2025

Cloudflare avait connu une autre panne notable le 12 juin 2025. À la racine, une panne dans une dépendance externe. Elle a perturbé un service sur lequel beaucoup d’autres s’appuient : Workers KV.

Plus de 90 % des requêtes vers ce magasin clé-valeur ont produit des réponses 500 ou 503. Parmi les services aval touchés :

• Access (contrôle d’accès), qui ne pouvait pas récupérer des informations de configuration et d’identité
• Gateway (passerelle web), qui ne pouvait pas traiter certaines requêtes
• WARP (VPN), dépendant d’Access
• Browser Isolation (navigateur sécurisé), dépendant de Gateway pour certaines sessions
• Turnstile (alternative aux CAPTCHA)
• Images, qui ne pouvait plus gérer les téléversements par lots

Il avait fallu environ 3 heures pour résoudre le problème. Claude et Gemini en avaient souffert. Gmail aussi, ainsi que Snapchat, Spotify, Twitch, etc.

* Ce n’est pas le pic qui a été qualifié d’inhabituel, mais le trafic (« peak of unusual traffic »). Une formulation qui aurait pu faire penser à une attaque.

Illustration © Hywards – Shutterstock

The post Cloudflare, un autre pilier d’Internet en panne après AWS et Azure appeared first on Silicon.fr.

Et le plus puissant des supercalculateurs est… toujours El Capitan.

À 5 mois d’intervalle, les positions sont restées figées dans le peloton de tête du TOP500. Pour trouver le premier mouvement, il faut descendre à la 15^e place. En juin, elle était occupée par un système localisé au Japon (ABCI 3.0, de l’Institut national des sciences et technologies). Elle l’est désormais par un système situé aux États-Unis (Discovery 6, d’ExxonMobil).

22 des supercalculateurs classés se trouvent sur le territoire français. Les voici, avec leur R_max (performance maximale pour le plus gros problème tournant sur la machine) et leur R_peak (performance théorique).

EXA1-HE (26^e)

C’est la dernière extension du supercalculateur EXA1, localisé à Bruyères-le-Châtel (Essonne) et utilisé pour la simulation nucléaire au sein de la branche militaire du CEA. Elle a été livrée en 2024.

Architecture BullSequana XH3000 avec puces NVIDIA GH200 (72 cœurs à 3 GHz).
R_max : 90,79 petaflops (R_peak : 171,26 Pflops) sur 548 352 cœurs.  Consommation : 1,77 MW.

Les classements précédents d’EXA1-HE au TOP500 :

• Juin 2024 : 17^e (configuration à 389 232 cœurs)
• Novembre 2024 : 22^e
• Juin 2025 : 23^e (passage à 548 352 cœurs)

Jean Zay H100 (40^e)

Extension GPU installée en 2024 sur ce supercalculateur mis en service 5 ans plus tôt à l’IDRIS (plateau de Saclay, Essonne).

Architecture BullSequana avec CPU Intel Xeon Platinum 8468 (Sapphire Rapids ; 48 cœurs à 2,1 GHz) et GPU NVIDIA H100 SXM5-80.
R_max : 52,18 Pflops (R_peak : 71,42 Pflops) sur 227 136 cœurs.

Les classements précédents de Jean Zay H100 au TOP500 :

• Novembre 2024 : 27^e
• Juin 2025 : 35^e

Adastra (45^e)

Ce supercalculateur a été acquis par la France via GENCI en 2022 et inauguré en 2023. Il se trouve au CINES (Montpellier).

Base HPE Cray EX235a, avec CPU AMD EPYC 3^e génération (64 cœurs à 2 GHz) et GPU AMD Instinct MI250X.
R_max : 46,1 Pflops (R_peak : 61,61 Pflops) sur 319 072 cœurs. Consommation : 921 kW.

Les classements précédents d’Adastra au TOP500 :

• Juin 2022 : 10^e
• Novembre 2022 : 11^e
• Juin 2023 : 12^e
• Novembre 2023 : 17^e
• Juin 2024 : 20^e
• Novembre 2024 : 30^e
• Juin 2025 : 40^e

EXA1-HF (77^e)

Cette partition d’EXA1 est en service depuis 2021.

Base BullSequana XH2000, avec CPU AMD EPYC 7763 (3^e génération ; 64 cœurs à 2,45 GHz).
R_max : 23,24 Pflops (R_peak : 31,76 Pflops) sur 810 240 cœurs. Consommation : 4,96 MW.

Les classements précédents d’EXA1-HF au TOP500 :

• Juin 2022 : 17^e
• Novembre 2022 : 20^e
• Juin 2023 : 22^e
• Novembre 2023 : 30^e
• Juin 2024 : 36^e
• Novembre 2024 : 55^e
• Juin 2025 : 70^e

Pangea III (104^e)

Ce supercalculateur de TotalEnergies localisé à Pau est en service depuis 2019.

Base IBM Power System AC922, avec CPU POWER9 (18 cœurs à 3,45 GHz) et GPU NVIDIA Volta GV100.
R_max : 17,86 Pflops (R_peak : 25,03 Pflops) sur 291 024 cœurs. Consommation : 1,37 MW.

Les classements précédents de Pangea III au TOP500 :

• 11^e puis 15^e en 2019
• 15^e puis 18^e en 2020
• 21^e puis 29^e en 2021
• 33^e puis 37^e en 2022
• 39^e puis 48^e en 2023
• 60^e puis 75^e en 2024
• Juin 2025 : 92^e

Tera 1000-2 (146^e)

Cette partition fut mise en service en 2017-2018 sur le supercalculateur Tera 1000 du CEA (localisation : Bruyères-le-Châtel).

Base BullSequana X1000, avec CPU Intel Xeon Phi 7250 (Knights Landing ; 68 cœurs à 1,4 GHz).
R_max : 11,97 Pflops (R_peak : 23,4 Pflops) sur 561 408 cœurs. Consommation : 3,18 MW.

Les classements précédents de Tera 1000-2 au TOP500 :

• 14e puis 16^e en 2018
• 18^e puis 17^e en 2019
• 20^e puis 24^e en 2020
• 34^e puis 42^e en 2021
• 45^e puis 49^e en 2022
• 54^e puis 65^e en 2023
• 82^e puis 101^e en 2024
• Juin 2025 : 123^e

ROMEO 2025 (172^e)

Supercalculateur de l’université de Reims Champagne-Ardenne, installé en 2024 et inauguré cette année.

Base BullSequana XH3000, avec puces NVIDIA GH200.
R_max : 9,86 Pflops (R_peak : 16,32 Pflops) sur 47 328 cœurs. Consommation : 160 kW.

Les classements précédents de ROMEO 2025 au TOP500 :

• Novembre 2024 : 122^e
• Juin 2025 : 148^e

Taranis (199^e)

Supercalculateur de Météo France installé en 2020 à Toulouse et inauguré en 2021.

Base BullSequana XH2000, avec CPU AMD EPYC 7742 (2^e génération ; 64 cœurs à 2,25 GHz).
R_max : 8,19 Pflops (R_peak : 10,32 Pflops) sur 294 912 cœurs. Consommation : 1,67 MW.

Les classements précédents de Taranis au TOP500 :

• Novembre 2020 : 30^e
• 49^e puis 58^e en 2021
• 63^e puis 69^e en 2022
• 78^e puis 92^e en 2023
• 115^e puis 141^e en 2024
• Juin 2025 : 168^e

Belenos (210^e)

Supercalculateur « jumeau » de Taranis, inauguré en parallèle, également à Toulouse.

Même architecture et même configuration processeur.
R_max : 7,68 Pflops (R_peak : 10,47 Pflops). Consommation : 1,66 MW.

Les classements précédents de Belenos au TOP500 :

• 29^e puis 34^e en 2020
• 55^e puis 64^e en 2021
• 71^e puis 78^e en 2022
• 87^e puis 103^e en 2023
• 125^e puis 152^e en 2024
• Juin 2025 : 180^e

Joliot-Curie Rome (222^e)

Partition du supercalculateur Joliot-Curie, installé depuis 2019 au TGCC (Bruyères-le-Châtel).

Base BullSequana XH2000, avec CPU AMD EPYC Rome 7H12 (3^e génération ; 64 cœurs).
R_max : 6,99 Pflops (R_peak : 12,94 Pflops) sur 197 120 cœurs. Consommation : 1,44 MW.

Les classements précédents de Joliot-Curie Rome au TOP500 :

• Novembre 2019 : 59^e (configuration à 160 000 cœurs)
• 33^e puis 38^e en 2020 (configuration à 197 120 cœurs)
• 59^e puis 69^e en 2021
• 77^e puis 83^e en 2022
• 92^e puis 109^e en 2023
• 132^e puis 162^e en 2024
• Juin 2025 : 191^e

SELENA (262^e)

Ce supercalculateur EDF est entré en production cette année.

Base BullSequana XH3000, avec CPU AMD EPYC 9354 (4e génération ; 32 cœurs à 3,25 GHz).
R_max : 5,42 Pflops (R_peak : 5,5 Pflops) sur 107 940 cœurs. Consommation : 1,16 MW.

Topaze GPU (278^e)

Partition GPU de Topaze, supercalculateur en service depuis 2021 au CCRT (CEA, Bruyères-le-Châtel).

Base BullSequana XH2000, avec CPU AMD EPYC 7763 (3^e génération ; 64 cœurs à 2,45 GHz) et GPU NVIDIA A100.
R_max : 5,07 Pflops (R_peak : 6,23 Pflops) sur 42 000 cœurs.

Les classements précédents de Topaze GPU au TOP500 :

• Novembre 2021 : 198^e (configuration à 26 880 cœurs)
• 217^e puis 241^e en 2022
• 280^e puis 317^e en 2023
• 175^e puis 208^e en 2024 (configuration à 42 000 cœurs)
• Juin 2025 : 244^e

Jean Zay (292^e)

Partition étendue (GPU).

Base HPE SGI 8600, avec CPU Intel Xeon Gold 6248 (Cascade Lake ; 20 cœurs à 2,5 GHz) et GPU NVIDIA Tesla V100 SXM2.
R_max : 4,48 Pflops (R_peak : 7,35 Pflops) sur 93 960 cœurs.

Les classements précédents de cette partition au TOP500 :

• 42^e puis 46^e en 2019
• 54^e puis 64^e en 2020
• 92^e puis 105^e en 2021
• 114^e puis 124^e en 2022
• 135^e puis 166^e en 2023
• 190^e puis 223^e en 2024
• Juin 2025 : 260^e

CRONOS (300^e)

Autre supercalculateur d’EDF, passé en production en 2021.

Base BullSequana X, avec CPU Intel Xeon Platinum 8260 (Cascade Lake ; 24 cœurs à 2,4 GHz).
R_max : 4,3 Pflops (R_peak : 7,14 Pflops) sur 81 600 cœurs. Consommation : 1,23 MW.

Les classements précédents de CRONOS au TOP500 :

• Novembre 2020 : 67^e
• 96^e puis 109^e en 2021
• 118^e puis 128^e en 2022
• 139^e puis 170^e en 2023
• 194^e puis 230^e en 2024
• Juin 2025 : 269^e

Joliot-Curie SKL (319^e)

Partition de Joliot-Curie qui doit être démantelée cette année.

Base BullSequana X1000, avec CPU Intel Xeon Platinum 8168 (Skylake ; 24 cœurs à 2,7 GHz).
R_max : 4,07 Pflops (R_peak : 6,64 Pflops) sur 79 488 cœurs. Consommation : 917 kW.

Les classements précédents de Joliot-Curie SKL au TOP500 :

• 34^e puis 40^e en 2018
• 47^e puis 52^e en 2019
• 61^e puis 72^e en 2020
• 101^e puis 113^e en 2021
• 124^e puis 133^e en 2022
• 154^e puis 183^e en 2023
• 207^e puis 245^e en 2024
• Juin 2025 : 285^e

hotlum (339^e)

Supercalculateur installé en 2022 chez HPE.

Base Cray EX, avec CPU AMD EPYC 7763 (3^e génération ; 64 cœurs à 2,45 GHz).
R_max : 3,81 Pflops (R_peak : 4,58 Pflops) sur 116 736 cœurs.

Les classements précédents de hotlum au TOP500 :

• 146^e puis 159^e en 2022
• 187^e puis 222^e en 2023
• 252^e puis 291^e en 2024
• Juin 2025 : 331^e

THX.A.B (362^e)

Supercalculateur installé en 2022 chez Atos.

Base BullSequana XH2000, avec CPU Intel Xeon Platinum 8358 (Ice Lake ; 32 cœurs à 2,6 GHz) et GPU NVIDIA A100 SXM4-64.
R_max : 3,5 Pflops (R_peak : 4,98 Pflops) sur 25 056 cœurs. Consommation : 86 kW.

Les classements précédents de THX.A.B en TOP500 :

• 146^e puis 159^e en 2022
• 187^e puis 222^e en 2023
• 252^e puis 291^e en 2024
• Juin 2025 : 331^e

Topaze CPU (377^e)

Partition CPU de Topaze.

Base BullSequana XH2000, avec CPU AMD EPYC 7763 (3^e génération ; 64 cœurs à 2,45 GHz).
R_max : 3,26 Pflops (R_peak : 4,34 Pflops) sur 110 592 cœurs.

Les classements précédents de Topaze CPU au TOP500 :

• Novembre 2021 : 140^e
• 154^e puis 170^e en 2022
• 201^e puis 237^e en 2023
• 267^e puis 306^e en 2024
• Juin 2025 : 346^e

Jean Zay (420^e)

Partition CPU de Jean Zay.

Base HPE SGI 8600, avec CPU Intel Xeon Gold 6248 (Cascade Lake ; 20 cœurs à 2,5 GHz).
R_max : 3,05 Pflops (R_peak : 4,87 Pflops) sur 61 120 cœurs.

Les classements précédents de cette partition au TOP500 :

• 72^e puis 79^e en 2019
• 91^e puis 108^e en 2020
• 140^e puis 163^e en 2021
• 178^e puis 203^e en 2022
• 237^e puis 273^e en 2023
• 309^e puis 350^e en 2024
• Juin 2025 : 391^e

KAIROS (422^e)

Supercalculateur installé cette année à l’université de Toulouse.

Base BullSequana XH3000, avec puces NVIDIA GH200 (72 cœurs à 3 GHz).
R_max : 3,05 Pflops (R_peak : 3,42 Pflops) sur 13 056 cœurs. Consommation : 46 kW.

AMD Ouranos (428^e)

Supercalculateur installé cette année chez Atos.

Base BullSequana XH3000, avec CPU AMD EPYC 4e génération (24 cœurs à 1,8 GHz) et GPU AMD Instinct MI300A.
R_max : 2,99 Pflops (R_peak : 3,97 Pflops) sur 16 632 cœurs. Consommation : 48 kW.

Les classements précédents d’AMD Ouranos au TOP500 :

• Juin 2025 : 399^e

Spartan3 (462^e)

Supercalculateur installée en 2021 chez Atos.

Base BullSequana XH2000, avec CPU AMD EPYC 7763 (3e génération ; 64 cœurs à 2,45 GHz).
R_max : 2,75 Pflops (R_peak : 3,61 Pflops) sur 92 160 cœurs.

Les classements précédents de Spartan3 au TOP500 :

• 157^e puis 193^e en 2021
• 212^e puis 236^e en 2022
• 275^e puis 312^e en 2023
• 348^e puis 391^e en 2024
• Juin 2025 : 434^e

Illustration générée par IA

The post TOP500 : les 22 supercalculateurs français classés appeared first on Silicon.fr.

Plutôt qu’un juge humain, une vérification déterministe : le RLVR (Reinforcement Learning with Verifiable Rewards) repose sur ce principe.

DeepSeek-R1 et OpenAI o1, entre autres, en ont démontré les bénéfices. Mais les possibilités de mise à l’échelle sont limitées du fait de la dépendance à des problèmes conçus par l’humain et à des récompenses spécifiques à chaque domaine.

Chez Meta, on est en tout cas parti de ce postulat pour développer SPICE (Self-Play in Corpus Environment).

Un modèle, deux rôles, un corpus documentaire

Cette technique d’apprentissage par renforcement fait jouer au modèle deux rôles antagonistes. L’un consiste à générer les problèmes (« challenger »). L’autre, à les résoudre (« résolveur »).

La génération des problèmes a la particularité d’être ancrée sur un corpus documentaire. Le challenger n’utilise que cette source ; pas ses propres connaissances. Le résolveur n’a pas accès au corpus, ce qui assure une asymétrie de l’information.

Un mécanisme de récompense fait progresser le challenger et le résolveur. Le premier a pour mission de créer des problèmes qui challengent au maximum le second, tout en restant résolvables.

Les documents sont bruts, sans questions ou étiquettes prédéfinies. Les problèmes prennent la forme de QCM (avec 4 réponses) ou de questions ouvertes. Cette diversité est censée permettre une vérification interdomaines sans outils spécialisés.

Les deux rôles sont instanciés avec vLLM, sur la base de l’architecture Oat. Quatre modèles de base sont expérimentés : Qwen3-4B-Base, Qwen3-8B-Base, OctoThinker-3B-Hybrid-Base et OctoThinker-8B-Hybrid-Base. Le renforcement se fait sur 20 000 documents. Il est axé sur deux disciplines : mathématiques (utilisation du dataset Nemotron-CC-Math) et raisonnement général (NaturalReasoning). La température est laissée à 1.0.

Ni trop simple, ni trop compliqué : un système de récompense pour trouver le bon équilibre

Avec chaque document, on effectue 1024 tentatives pour générer des questions, puis on en sélectionne aléatoirement une valide. Pour chacune, on retient 8 réponses. On en calcule la variance pour déterminer la récompense du challenger. Cette dernière est maximale lorsque le taux de réussite du résolveur atteint 50 % (témoignant de questions ni trop faciles, ni trop difficiles). Pour vérifier l’équivalence de chaque réponse par rapport à la gold answer (réponse de référence), le framework simple-evals est utilisé, avec GPT-4o.

La performance de SPICE est comparée à celles :

• Des modèles de base (Base Model)
• De systèmes utilisant un challenger « plus fort » (Qwen3-32B-Instruct) et où le modèle n’est entraîné que sur le rôle de résolveur (Strong Challenger)
• D’un système antagoniste non ancré sur un corpus (R-Zero)
• De ce même type de système, et avec des problèmes portant exclusivement sur la génération de code Python (Absolute Zero)

Entre les modèles de base et SPICE, l’écart va de 5,7 à 11,9 points selon les modèles.

3,2 points en performance globale : la (modeste) contribution du corpus documentaire

On constate une amélioration mutuelle. Pour en témoigner, Meta avance deux indicateurs « en miroir ».
D’un côté, à résolveur fixe (checkpoint après 200 étapes), le taux de réussite passe de 55 à 35 % à mesure que le challenger progresse.
De l’autre, à challenger fixe (checkpoint après 200 étapes), le taux de réussite du résolveur passe de 55 à 85 %.
Qualitativement parlant, plus on avance dans l’entraînement, plus les problèmes générés sont complexes.

Sans ancrage sur corpus, la performance globale moyenne atteint 40,7 %. Avec, elle monte à 43,9 % (+ 3,2 points).

NaturalReasoning utilisé seul engendre des gains plus importants que Nemotron-CC-Math seul. Mais combiner les deux datasets produit les meilleurs résultats.

Le gain en mathématiques est plus important avec uniquement des questions ouvertes. Au global, néanmoins, il vaut mieux y associer le format QCM.

La technique de récompense par calcul de variance produit de meilleurs résultats que :

• Absolute Zero, où la récompense vaut (1 – taux de réussite moyen du résolveur)
• Threshold, où la récompense vaut 1 pour les tâches « relativement résolvable » ; 0 pour celles à 0 ou 100 % de réussite
• R-Zero, qui récompense les problèmes produisant des réponses équitablement réparties

Illustration principale générée par IA

The post Après DeepSeek, quelle marge de progression pour l’apprentissage par renforcement ? appeared first on Silicon.fr.

Si la GenAI contribue à « raviver » les solutions de gestion des actifs numériques (DAM), elle s’y diffuse de manière très inégale.

Le constat était ressorti, il y a près d’un an, du Magic Quadrant consacré à ce marché.

L’analyse de Gartner dépeignait la situation à octobre 2024.
Au sujet de cette diffusion très inégale de la GenAI, le cabinet américain évoquait les fournisseurs qui n’en proposaient pas encore pour la création de contenu ; ceux qui étaient « en retard » sur ces mêmes capacités ; ceux qui avaient plus globalement « du mal à suivre le rythme » ; et ceux chez qui la GenAI avait un prix non négligeable.

Cette remarque ne figure plus dans la nouvelle édition du Magic Quadrant du DAM. Gartner met, au contraire, l’accent sur la généralisation de certaines briques. Par exemple, la création de contenu assistée par IA. La majorité des fournisseurs classés (13 sur 17) en proposent nativement. Soit grâce à des modèles propriétaires, soit en embarquant des LLM ouverts.

La manipulation de contenu assistée par IA est également devenue standard. En parallèle, les fonctionnalités touchant à la vidéo (création, édition, localisation linguistique) se répandent. On voit aussi émerger une adaptation automatisée des contenus aux canaux de diffusion. Et la possibilité, pour le client, d’apporter ses propres modèles.
L’intégration de MCP, vu comme un levier de standardisation et d’encadrement de la production de contenu, est en revanche encore limitée. Au moment où Gartner a effectué ses relevés, un tiers des offreurs avaient commencé à implémenter le protocole, ou tout moins déclaraient envisager de le faire.

Adobe et Orange Logic, nouveaux « leaders »

Sur le plan fonctionnel, le cahier des charges pour figurer dans le dernier Magic Quadrant du DAM imposait, dans les grandes lignes :

• L’ingestion des actifs, leur organisation (tagging et taxonomie) et leur mise à disposition
• Gestion des droits numériques
• Planification de workflows
• Intégration avec des solutions marketing – ce métier étant le premier public

La capacité à répondre effectivement à la demande du marché (expérience client, marketing, qualité des produits/services…) est restituée sur l’axe dit « exécution ». Les fournisseurs s’y positionnent comme suit :

Rang	Fournisseur	Évolution annuelle
1	Aprimo	=
2	Bynder	=
3	Storyteq	=
4	Adobe	+ 4
5	OpenText	+ 4
6	Frontlify	nouvel entrant
7	Smarsheet	– 2
8	Orange Logic	– 4
9	Hyland	– 3
10	Acquia	– 3
11	Cloudinary	=
12	Sitecore	– 2
13	CELUM	– 1
14	PhotoShelter	nouvel entrant
15	MediaValet	– 1
16	Wedia	nouvel entrant
17	Fotoware	– 4

Sur l’axe « vision », qui reflète les stratégies (commercial, marketing, produit, sectorielle, géographique…), la situation est la suivante :

Rang	Fournisseur	Évolution annuelle
1	Storyteq	+ 1
2	Aprimo	– 1
3	Cloudinary	=
4	Orange Logic	+ 4
5	Bynder	– 1
6	Sitecore	– 1
7	Adobe	=
8	OpenText	– 2
9	Acquia	– 1
10	Frontlify	nouvel entrant
11	PhotoShelter	nouvel entrant
12	CELUM	=
13	Wedia	nouvel entrant
14	MediaValet	– 1
15	Hyland	– 6
16	Smartsheet	– 5
17	Fotoware	– 3

Il y a un an, ils étaient trois dans le carré des « leaders » : Aprimo, Bynder et Storyteq. Adobe et Orange Logic les y ont rejoints.

Quels produits pour quels usages ? L’offre d’Adobe suscite des incertitudes

Gartner salue les possibilités d’Adobe Experience Manager Assets sur l’aspect workflows de création (soumission, approbation, intégration de l’IA Firefly). Il apprécie également les fonctionnalités de gouvernance et de contrôle d’accès, basées sur les rôles et les attributs. Et souligne qu’Adobe est l’un des porteurs de la Content Authenticity Initiative. Bon point également pour le réseau de partenaires (ils sont 4200 certifiés).

Le jugement est moins positif quant aux capacités agentiques. Gartner l’illustre par l’absence d’un agent capable de contrôler les actifs à l’ingestion. Il appelle aussi à la vigilance sur la tarification. D’une part, parce que l’accès à des fonctionnalités avancées (rendu temps réel, expériences 3D…) nécessite un add-on. De l’autre, à cause du nombre limité de licences utilisateur incluses de base dans les différents niveaux d’offre. Le cabinet américain note également de potentielles incertitudes sur les produits auxquels recourir en fonction des cas d’usage. Un « manque de clarté » qui peut compliquant l’adoption et la mise en action.

Aprimo et la GenAI : vigilance sur le modèle à la consommation

Il y a un an, Aprimo avait été crédité d’un bon point pour la continuité offerte dans la gestion du contenu entre les outils marketing et les autres logiciels d’entreprise. Gartner avait aussi apprécié ses « starter packs » sectoriels avec workflows et taxonomies préconfigurés. Il avait également salué les capacités de son produit en matière de recherche, de tagging et de templating.

Le focus GenAI avait valu à Aprimo un mauvais point, en ce qu’il était susceptible de limiter les investissements dans le cœur fonctionnel. La tarification de la GenAI était autre point noir : l’add-on donnant accès aux fonctionnalités les plus avancées (entraînement personnalisé pour le tagging, génération d’images, traduction…) pouvait faire augmenter le TCO d’un tiers. Gartner avait aussi regretté le nombre limité d’événements physiques à destination des clients.

Cette fois, l’IA vaut un bon point à Aprimo, entre recherche sémantique, métadonnées prédictives et révision automatisée du contenu. Gartner y ajoute le niveau de performance et de fiabilité de la plate-forme. Ainsi que les fonctionnalités de conformité (certifications sectorielles, pistes d’audit immuables, vérifications assistées par IA).

Le module complémentaire pour la GenAI avancée reste un problème, mais sous un autre angle : son modèle à la consommation, qui rend potentiellement les coûts moins prévisibles. Pour ce qui est de la stratégie AI-first, elle est susceptible de « challenger » les organisations peu matures, tant par la cadence de diffusion de l’IA que par le périmètre concerné. Les clients ayant des besoins hors Amérique du Nord et EMEA resteront par ailleurs vigilants quant à la présence physique limitée d’Aprimo et de ses ressources de support sur les autres plaques géographiques.

Chez Bynder, une double tarification à bien étudier

Il y a un an, l’offre de Bynder avait fait mouche auprès de Gartner sur le plan fonctionnel. Notamment sur la détection de visages et le système de mise en quarantaine des contenus avant approbation. Les capacités d’analyse de l’usage des actifs avaient aussi été saluées. Comme la relation client (événements réguliers, roadmap accessible à tous, webinars lors de la sortie de mises à jour).

Les investissements en IA ont produit moins de fonctionnalités que chez la concurrence, avait regretté Gartner. Il y avait ajouté un manque de transparence sur le packaging des fonctionnalités constituant des add-on. Tout en signalant l’absence de roadmaps sectorielles et d’améliorations ciblées sur des verticales (Bynder a opté pour une approche horizontale avec adaptation aux cas d’usage).

Cette fois, l’un des bons points va aux capacités de création et de mise en œuvre d’agents IA. Qui, combinés à l’API, favorisent la création de contenus par d’autres métiers que le marketing. Bynder se distingue aussi sur la distribution des contenus, autant par leur adaptation à chaque canal que par l’exhaustivité du catalogue de connecteurs. Il a aussi pour la la qualité de son support à l’implémentation (blueprints, formations par rôle, conseils de gouvernance, taxonomies sur étagère, templates personnalisables…).

À un an d’intervalle, Gartner note toujours que la feuille de route sectorielle est limitée. Il trouve aussi à redire sur la partie analytics, du fait que les dashboards doivent être configurés via un mix d’API et d’intégrations pour obtenir des recommandations réellement « activables ». Quant à la tarification, basée soit sur le nombre d’assets soit sur le volume de stockage, elle implique de bien évaluer la structure de sa bibliothèque de contenus.

Orange Logic : gare aux délais d’implémentation

Comme Bynder, Orange Logic se distingue sur l’automatisation agentique. Il en est de même sur la recherche conversationnelle – avec exploitation du contexte : profils d’utilisateurs, relations entre assets, analyse des frames dans les vidéos, etc. Gartner salue aussi son concepteur visuel de workflows, jugé convivial (user-friendly).

Comme chez Aprimo, la présence physique est limitée hors Amérique du Nord. Le processus d’implémentation s’avère par ailleurs plus long que chez la concurrence. Et les modules optionnels (3D, gestion des droits, concepteur de sites sans code…), souvent indispensables dans les grandes entreprises, peuvent faire monter la facture.

Avec Storyteq, le modèle à la connexion peut coûter cher

Il y a un an, Gartner avait présenté Storyteq comme le fournisseur proposant le plus de capacités d’assistance par IA pour la création et l’édition de contenus. Il y avait ajouté les fonctionnalités de vision par ordinateur pour améliorer la recherche d’assets et la disponibilité d’un CMS en self-service. Tout en soulignant l’étendue des partenariats conseil et ISV.

Le prix de la GenAI était un point noir, même si la tarification d’ensemble demeurait flexible. Gartner avait aussi fait remarquer les travaux préparatoires que certaines fonctionnalités GenAI supposaient pour pouvoir fonctionner à l’échelle. Et affirmé que la présence physique de Storyteq restait largement concentrée en EMEA, en plus d’un focus historique sur les services d’agence et d’une absence de programme de reconnaissance client.

Cette fois, la stratégie sectorielle fait mouche: Storyteq a des équipes dédiées à la santé, l’automobile, la finance et le retail, entre autres. Il y couple des packs associant workflows, schémas et exemples de conformité. Son offre se distingue aussi sur les services professionnels et le support technique. Ainsi que sur la conception d’agents sans code et l’exploitation de l’IA pour la protection des contenus (gestion dynamique du consentement, détection de données personnelles, audit de conformité continu).

Beaucoup d’intégrations avec des systèmes externes sont facturées à la connexion. Pour qui souhaite organiser un écosystème, les coûts peuvent vite enfler. Pour ce qui est de la présence physique, elle reste largement concentrée en Amérique du Nord et en EMEA, malgré l’acquisition de PureRed. Quant aux investissements marketing, ils sont moins importants que chez la concurrence, résultant en une visibilité limitée.

Illustration © Danloe – Adobe Stock

The post Gestion des actifs numériques : la GenAI ne rend pas les prix plus lisibles appeared first on Silicon.fr.

Au-delà d’Hyper-V et d’ESXi, Akira a aussi chiffré des VM Nutanix.

Le bulletin que la CISA consacre à ce ransomware vient d’être mis à jour pour intégrer cette information… entre autres.

La version initiale datait d’avril 2024. Un an et demi plus tard, les techniques ont évolué sur toute la ligne, de l’accès initial à l’extorsion. Quant au chiffrement de VM Nutanix*, il a été constaté dans le cadre d’un incident survenu en juin 2025. Au début de la chaîne d’attaque, il semble y avoir eu la faille CVE-2024-40766 (contrôle d’accès défaillant dans les pare-feu SonicWall).

Des accès initiaux via Veeam

La version d’avril 2024 évoquait un accès initial via des VPN sans MFA. Essentiellement de marque Cisco, était-il précisé, avec deux vulnérabilités citées. L’une et l’autre localisées dans l’interface web d’ASA (Adaptitve Security Appliance) et de FTD (Firepower Threat Defense). La première (CVE-2020-3259) permet de récupérer du contenu en mémoire sans authentification. La deuxième (CVE-2023-20269) ouvre la voie à des attaques de force brute ou à la mise en place de sessions VPN SSL avec un utilisateur non autorisé.

D’après la nouvelle version du bulletin, à laquelle a contribué l’OFAC (Office anti-cybercriminalité français), l’arsenal d’accès initial s’est diversifié. Avec notamment :

• CVE-2020-3580, autre vulnérabilité sur l’interface web d’ASA et FTD, permettant un XSS sans authentification
• CVE-2023-28252, faille dans le CLFS (service de journalisation Windows utilisé par les programmes s’exécutant en mode utilisateur ou noyau), utilisée pour l’élévation de privilèges
• CVE-2024-37085 (contournement d’authentification dans ESXi via Active Directory)
• CVE-2023-27532 et CVE-2024-40711, qui touchent toutes les deux Veeam Backup & Replication (la première permet d’exfiltrer des authentifiants chiffrés depuis la base de données de config ; la deuxième ouvre la porte à une RCE par désérialisation de données malicieuses)

Zemana AntiMalware détourné pour stopper les antivirus

Sur la phase de reconnaissance, la mise à jour du bulletin ajoute peu d’éléments. Sinon l’utilisation de nltest /dclist: et de nltest /DOMAIN_TRUSTS.

Parmi les outils dont se servent les affiliés d’Akira figurent NetScan, Advanced IP Scanner et SoftPerfect. Mimikatz et LaZagne aussi, pour récupérer des authentifiants.

La version initiale signalait le recours à un outil légitime (Zemana AntiMalware) pour stopper les processus liés à des antivirus.

La mise à jour y ajoute l’exploitation d’outils d’accès distant tels AnyDesk et LogMeIn pour établir une persistance et se fondre dans l’activité admin.

La protection des disques virtuels neutralisée

La version initiale du bulletin apportait peu d’informations sur la manière dont les affiliés d’Akira obtenaient des privilèges.

La mise à jour en dit davantage, entre exploitation de services comme Veeam.Backup.MountService.exe et ajout de nouveaux comptes utilisateurs au groupe admin.
Elle mentionne un incident dans lequel la protection VMDK a été contournée en éteignant temporairement la VM du contrôleur de domaine. Les VMDK ont alors été copiés et attachés à une nouvelle VM. Cela a permis d’extraire le fichier NTDS.dit et la hive SYSTEM (groupe logique de clés, sous-clés et valeurs de registre) ; pour, au bout, compromettre un compte d’administrateur de domaine.

Un chiffrement hybride et personnalisable

Quantité d’outils ont été mis à profit pour l’exfiltration de données. 7-zip et WinRAR en font partie, comme FileZilla, RClone et WinSCP.

Pour établir des canaux de commande et de contrôle, AnyDesk, Cloudflare Tunnels, MobaXterm, Ngrok et RustDesk ont été mis à contribution.

Dans certain cas, à peine 2 heures se sont écoulées entre l’accès initial et l’exfiltration.

Le schéma de chiffrement utilisé par Akira était pour l’essentiel déjà établi en avril 2024. Hybride, il associe un cipher ChaCha20 et un système à clé RSA publique. L’ensemble permet un chiffrement total ou partiel, tout en le personnalisant selon le type et la taille de fichiers.

Afin de compliquer la récupération et l’analyse forensique, des commandes PowerShell sont utilisées pour supprimer les copies VSS.

Des options pour ne cibler que les VM

La première version d’Akira était écrite en C++. Sa deuxième incarnation, repérée à l’été 2023, est écrite en Rust. Elle est dotée d’une couche de protection supplémentaire compliquant l’analyse dynamique. Ainsi que d’une gestion des threads, améliorant l’efficacité du processus de chiffrement. Elle peut par ailleurs être déployée exclusivement contre les VM (paramètre vmonly) et stopper ces dernières (stopvm).

Akira est associé aux groupes connus sous le nom de Gold Sahara, Howling Scorpius, Punk Spider et Storm-1567. Il pourrait avoir des liens avec feu Conti.

* Lors d’une récente conférence, Gartner a prédit qu’à l’horizon 2028, 35 % des workloads VMware seraient passés sur une autre plate-forme. Le cabinet américain a suggéré d’envisager en premier lieu Nutanix. Pas tant pour les prix que pour les capacités fonctionnelles.

Illustration générée par IA

The post Akira : l’évolution d’un ransomware qui chiffre jusqu’aux VM Nutanix appeared first on Silicon.fr.

Istio et Kueue pour certains, Traefik et Volcano pour d’autres ; parfois Kubeflow, parfois KubeRay, ou les deux… Les fournisseurs de plates-formes Kubernetes ont emprunté divers chemins pour démontrer leur conformité à la « spécification IA » élaborée par la CNCF.

Cette spec définit un ensemble de capacités, d’API et de configurations qu’un cluster certifié « conforme Kubernetes » doit proposer pour exécuter de façon fiable des workloads IA/ML. Principal objectif : éviter une fragmentation qui compromettrait la portabilité.

Un premier tour d’autocertification avec 9 éléments obligatoires

Les travaux avaient officiellement démarré cet été. Une v1 a été publiée depuis et un premier round de certification a été lancé. Plus précisément d’autocertification : le processus est pour le moment déclaratif. Une suite de tests automatisés est censée prendre le relais, mais pas avant 2026.

Beaucoup d’éléments inscrits dans la spécification ne sont, en tout cas pour le moment, pas obligatoires. Parmi eux :

• Assurer que des pilotes compatibles et les configs runtime correspondantes sont correctement installés et maintenus sur les nœuds dotés d’accélérateurs
• Faciliter le tirage de grosses images de conteneurs (par exemple à travers une réplication ou une mise en cache près des nœuds d’exécution)
• Permettre la gestion unifiée de jobs indépendants via un mécanisme gérant les API JobSet
• Autoriser le déploiement de conteneurs confidentiels dans des environnements d’exécution sécurisés (enclaves matérielles)
• Fournir un mécanisme de détection des accélérateurs en erreur, avec éventuellement une remédiation automatisée

9 éléments sont actuellement obligatoires. Dans les grandes lignes :

1. Prendre en charge l’allocation dynamique des ressources (DRA)
2. Gérer la Gateway API de Kubernetes, dans une implémentation permettant une « gestion avancée » pour les services d’inférence (distribution pondérée du trafic, routage sur la base des en-têtes, intégration avec les maillages de services…)
3. Permettre d’installer et d’exploiter au moins une solution de planification des gangs
4. Gérer la mise à l’échelle verticale des groupes de nœuds contenant des types d’accélérateurs spécifiques
5. Si présent, assurer un fonctionnement correct de l’HorizontalPodAutoscaler pour les pods qui exploitent des accélérateurs
6. Exposer, pour les types d’accélérateurs pris en charge, des métriques granulaires, via un endpoint standardisé, et dans un format lisible par la machine (au minimum, taux d’utilisation par accélérateur + occupation mémoire)
7. Découverte et collecte de métriques de workloads dans un format standard
8. Isolation des accès aux accélérateurs depuis les conteneurs
9. Possibilité d’installer et d’exécuter de façon fiable au moins un opérateur IA complexe disposant d’un CRD

Chaque certification vaut pour un an et s’applique à une version spécifique de Kubernetes. En l’état, soit la 1.33 (8 solutions certifiées), soit la 1.34 (11 solutions certifiées).

Les 8 solutions (auto)certifiées sur Kubernetes 1.33

Premier dans l’ordre alphabétique, CoreWeave Kubernetes Services (CKS).
Entre autres commentaires insérés dans sa déclaration de conformité, le « néo-cloud » américain – voir notre article à son sujet – rappelle gérer le planificateur SUNK (Slurm on Kubernetes). Il explique aussi que l’isolation des accès est pour l’instant traitée avec des plug-in, en attendant de passer au DRA lorsque le support fournisseur sera plus mature.

DaoCloud Enterprise n’implémente pas le DRA (il faut dire que les API sont désactivées par défaut sur Kubernetes 1.33, de sorte que la spec n’impose pas la fonctionnalité). Destiné à l’exécution sur site, il ne fournit pas non plus d’autoscaler vertical.

Pour sa plate-forme Gardener, la NeoNephos Foundation (projet de la Fondation Linux Europe) livre une preuve d’implémentation de la Gateway API via Traefik. Et de la planification des gangs via Kueue. L’autoscaling horizontal est géré avec une stack associant Prometheus et DCGM (NVIDIA Datacenter GPU Manager). Comme « opérateur IA complexe », KubeRay a été choisi.

L’entreprise allemande Giant Swarm fournit la plate-forme du même nom. Elle n’a pas ajouté de commentaires à son autocertification. Les renvois vers sa documentation montrent toutefois que Kueue a été sélectionné pour démontrer la conformité sur la partie planification des gangs, et KubeRay en guise d’opérateur IA.

Red Hat est également au rendez-vous, avec la dernière version d’OpenShift (4.20). Lui aussi a opté pour Kueue. Comme opérateur IA, la filiale d’IBM a utilisé Kubeflow Trainer, avec plusieurs CRD (TrainJob, TrainingRuntime, ClusterTrainingRuntime). Elle précise, concernant les métriques d’accélérateurs, propose des opérateurs dédiés pour les GPU AMD en plus des GPU NVIDIA.

SUSE a autocertifié RKE2 (deuxième itération de Rancher Kubernetes Engine). Là aussi sans commentaires supplémentaires, mais avec un renvoi vers une nouvelle section de sa doc consacrée à la conformité vis-à-vis de la spec CNCF. On y découvre que Volcano a été privilégié pour la planification des gangs. Et que pour la collecte de métriques, la solution SUSE AI est mise en avant.

Red Hat a autocertifié un deuxième produit : ROSA (Red Hat OpenShift Service on AWS), dans sa dernière version. Avec, la même base que pour OpenShift, mais des validations spécifiques.

Talos Linux, OS immuable pour Kubernetes, a également été certifié, par son éditeur Sidero Labs. Lequel signale qu’aucun autoscaler vertical spécifique n’est fourni et que le produit n’embarque pas, en standard, d’outils d’observabilité.

Les 11 solutions (auto)certifiées sur Kubernetes 1.34

Premier dans l’ordre alphabétique, ACK (Alibaba Cloud Container Service for Kubernetes). Sa conformité a été démontrée en utilisant à la fois Spark et Ray. Sur la partie métriques, Alibaba a exploité son Prometheus managé.

AKS (Azure Kubernetes Service) a aussi été autocertifié. Microsoft a utilisé Istio, Kueue et DCGM, entre autres. Pour les opérateurs IA, il a fait un choix particulier au-delà de Ray : KAITO (Kubernetes AI Toolchain Operator), projet en sandbox à la CNCF et qui repose sur vLLM.

Baidu a autocertifié sa solution CCE (Cloud Container Engine). Avec Volcano pour l’implémentation Gateway API, du Prometheus managé pour l’autoscaling horizontal… et un déploiement SGLang pour la partie contrôleur IA.

Autocertifié sur Kubernetes 1.33, CKS (CoreWeave Kubernetes Service) l’est aussi sur la version 1.34.

Amazon a essentiellement recouru à ses propres services pour démontrer la conformité d’EKS (Elastic Kubernetes Service). Entre autres, son contrôleur AWS Load Balancer, son planificateur AWS Batch, son outil de supervision CloudWatch et son collecteur de métriques Neuron Monitor.

GKE (Google Kubernetes Engine) est également autocertifié. Comme Amazon, Google met en avant ses propres services… et un tuto, destiné à construire une plate-forme ML associant Ray et Kubeflow.

KKP (Kubermatic Kubernetes Platform) a sa propre stack MLA (« Monitoring Logging & Alerting »), exploitée dans le cadre de son autocertification. Il a aussi son propre contrôleur de passerelle (KubeLB).

Avec LKE (Linode Kubernetes Engine), Akamai a son propre autoscaler vertical. Pour les pods, il passe par l’adaptateur Prometheus. La collecte de métriques relatives aux accélérateurs passe par DCGM. Istio est utilisé comme implémentation référente de la Gateway API.

Istio a aussi été le choix d’Oracle pour démontrer la conformité d’OKE (OCI Kubernetes Engine). On aura noté que pour les métriques de workloads, le groupe américain a son propre projet OCI GPU Scanner, mis à disposition sous licence libre (UPL) et installable soit via Terraform, soit via Helm, soit comme add-on depuis la console OCI.

Autocertifié sur Kubernetes 1.33, Talos Linux l’est aussi sur la version 1.34.

Le dernier dans l’ordre alphabétique est VKS (VMware Kubernetes Service). VMware l’a autocertifié en s’appuyant notamment sur Istio, Kueue, Prometheus, DCGM et KubeRay.

Illustration

The post Kubernetes : les 17 premières plates-formes « certifiées IA » appeared first on Silicon.fr.

 

Dans l’écosystème Microsoft évolueront peut-être bientôt des « utilisateurs agentiques » ayant leur identité, leur place dans l’organigramme… et leur licence.

Des informations à ce sujet seront possiblement communiquées la semaine prochaine à la conférence Ignite. En attendant, il y a des faisceaux d’indices. Notamment un message publié début novembre dans le centre d’administration Microsoft 365. Il a disparu depuis, comme l’élement de roadmap associé. On a pu y apercevoir une nouvelle marque : Agent 365.

Les agents en question seraient créés à partir de modèles préconfigurés.
Il appartiendrait aux admins de choisir lesquels de ces modèles publier. Par défaut, l’ensemble des utilisateurs du locataire y auraient accès, à deux endroits : Teams (section Apps) et le magasin d’agents Microsoft 365. Leurs demandes de création d’agents sur la base de ces templates remonteraient aux admins. Qui, en cas d’approbation, auraient à assigner une licence A365 à chaque agent.

Le message publié dans le centre d’administration évoquait un déploiement progressif à partir de mi-novembre, sur desktop (dans Teams et Microsoft 365 Copilot).

Agent 365, une démarche avant tout commerciale

Au vu de ces quelques éléments, l’évolution qui se prépare ne semble pas tant technologique que commerciale. Il se dit d’ailleurs que la marque Agent 365 pourrait prendre le relais de Microsoft 365 Copilot. Potentiellement une manière d’atténuer la confusion que le branding actuel suscite jusqu’en interne.

Après deux ans de commercialisation, l’adoption de Microsoft 365 Copilot apparaît décevante. En tout cas d’après les affirmations d’Ed Zitron. L’intéressé, qui s’est fait une solide réputation de pourfendeur de l’IA générative, affirmait cet été que le taux de transformation au sein de la base Microsoft 365 était inférieur à 2 %. Un chiffre que Microsoft n’a pas démenti.

L’usage – mais pas forcément la conversion – a pu augmenter depuis, entre autres avec la mise à disposition gratuite de quelques fonctionnaltiés Copilot Chat dans Word, Excel, PowerPoint, OneNote et Outlook (essentiellement, des conversations basées sur le web et sur le fichier ouvert).
Divers abonnements initialement autonomes (Copilot pour les ventes, pour le service et pour la finance, par exemple) ont par ailleurs été fusionnés dans Microsoft 365 Copilot.

À consulter en complément sur le sujet Microsoft 365 Copilot :

Les conditions d’accès aux modèles d’Anthropic
Les leçons d’un test à grande échelle

Illustration générée par IA

The post Agent 365 : vers un nouveau modèle économique chez Microsoft appeared first on Silicon.fr.

Broadcom et VMware, cela fera bientôt deux ans.

Le 22 novembre 2023, le premier finalisait l’acquisition du second. Il n’allait pas tarder à en bouleverser la politique commerciale, avec les conséquences que l’on sait.

Quantité de fournisseurs d’offres concurrentes se sont engouffrés dans la brèche, tentant de capter le replatforming des parcs de VM. Red Hat n’y a pas fait exception. Il a évidemment mis en avant la conteneurisation sur OpenShift. Mais aussi la brique de virtualisation intégrée à la plate-forme depuis l’été 2020. Jusqu’à en faire un produit spécifique, lancé début 2025 : OpenShift Virtualization Engine, qui n’inclut pas de droit d’usage de conteneurs applicatifs.

Topologie localnet et instances personnalisées

Au-delà de la stratégie commerciale, OpenShift Virtualization a connu des évolutions fonctionnelles notables depuis la fusion Broadcom-VMware. Six versions mineures sont sorties, à commencer par la 4.15 (publiée le 27 février 2024 ; arrivée en fin de vie le 27 août 2025).

Cette version avait notamment apporté la gestion du branchement à chaud d’interfaces réseau secondaires sur les VM (hors interfaces SR-IOV). Elle avait aussi ajouté la prise en charge de la topologie localnet pour les réseaux secondaires OVN-Kubernetes (connexion à la sous-couche physique).

Autre élément ajouté : le KSM (kernel samepage merging). Cette fonctionnalité s’enclenche lorsqu’un nœud est surchargé. Elle déduplique les données identiques trouvées dans les pages mémoire des VM.

OpenShift Virtualization 4.15 a également permis d’activer l’accès aux logs console des invités et de configurer des clusters pour les workloads DPDK (Data Plane Development Kit, délégation du traitement des paquets TCP à des processus en espace utilisateur) sur SR-IOV. La console web avait été enrichie en parallèle pour permettre l’installation et l’édition de types d’instances personnalisés. Et pour importer des secrets depuis d’autres projets lors de l’ajout d’une clé SSH publique à une VM en cours de création ou d’un secret à une VM existante.

Hotplug de vCPU et accès headless aux VM

Le 27 juin 2024 sortait OpenShift Virtualization 4.16. Cette version est actuellement en phase de maintenance, jusqu’au 27 décembre 2025. Le support étendu durera jusqu’au 27 juin 2026. Avec elle, le hotplug de vCPU est passé en disponibilité générale.

Il est aussi devenu possible d’accéder à une VM à travers des services Kubernetes headless, en utilisant son nom de domaine interne. Et d’activer la feature gate AutoResourceLimits pour gérer automatiquement les limites CPU et mémoire des VM.

OpenShift Virtualization 4.16 a aussi ajouté la possibilité de sélectionner les options sysprep à la création de VM Windows plutôt que par après. Et d’exposer certaines métriques d’hôte ou d’invité au sein des VM, en ligne de commande ou via l’outil vm-dump-metrics.

Gestion de la densité des workloads et exposition de périphériques USB

OpenShift Virtualization 4.17, sorti le 1^er octobre 2024, arrivera en fin de vie le 1^er avril 2026, sans phase de support étendu.

Avec cette version, Red Hat a certifié la prise en charge de Windows Server 2025 comme OS invité. Il a aussi permis de sélectionner un namespace personnalisé pour ses golden images. Et donné la possibilité d’accroître la densité de workloads dans les VM en surréservant (overcommit) la RAM. Comme d’exposer des périphériques USB dans un cluster, de sorte que les propriétaires de VM peuvent ensuite les assigner.

Le hotplug de CPU et de mémoire depuis la console est passé en disponibilité générale avec OpenShift Virtualization 4.17. Même chose pour la configuration de stratégies d’éviction de VM à l’échelle d’un cluster.

Réseaux définis par l’utilisateur et changement à chaud de type d’instance

Sorti le 25 février 2025, OpenShift Virtualization 4.18 arrivera en fin de maintenance le 25 août 2026. Le support étendu durera jusqu’au 25 février 2027.

Depuis cette version, on peut connecter une VM à un réseau défini par l’utilisateur sur l’interface primaire. On peut aussi changer le type d’instance associé à une VM en cours d’exécution, sans redémarrage.

Autre ajout : la capacité de créer des snapshots de VM auxquelles on ajoute un vTPM. Et de les restaurer à partir de ces snapshots (mais pas d’en créer de nouvelles, ni de les cloner).

La console a quant à elle évolué pour permettre de contrôler simultanément l’état de plusieurs VM. Et de visualiser des métriques de niveau workload pour les ressources disque, CPU et réseau allouées.

Protection des VM et threads I/O multiples pour le stockage flash

OpenShift Virtualization 4.19 fut publié le 17 juin 2025. Il entrera en phase de maintenance le 17 décembre 2025 et n’aura pas de support étendu.

Avec cette version, RHEL 10 rejoint la liste des OS invités certifiés. Red Hat introduit aussi un mécanisme de protection des VM contre la suppression. Et permet de mettre à jour le type de machine pour plusieurs VM à la fois depuis le CLI OpenShift.

La topologie localnet sur OVN-Kubernetes est devenue utilisable pour connecter une VM à un réseau secondaire défini par l’utilisateur. Et il est devenu possible de configurer un manifeste NodeNetworkConfigurationPolicy pour activer l’écoute LLDP sur tous les ports Ethernet d’un cluster.

Autre nouveauté : la possibilité de configurer plusieurs threads I/O pour les VM utilisant de la mémoire flash. Quant à la console, elle a évolué pour proposer davantage d’actions groupées sur les VM (gestion des étiquettes, déplacement dans un autre dossier au sein d’un même namespace…). Des métriques supplémentaires ont par ailleurs été mises à disposition, concernant les migrations, les vNIC et le stockage alloué aux VM.

Topologie NUMA et saut de versions de correction

La dernière version mineure en date (4.20) est sortie le 21 octobre 2025. Elle arrivera en fin de vie le 21 avril 2027, sans support étendu.

Avec elle, Red Hat permet de sauter des versions de correction (pas besoin d’installer toutes les versions intermédiaires lorsqu’on met à jour).

Plusieurs éléments passent en disponibilité générale, dont la possibilité d’exploiter la topologie NUMA (non-uniform memory access) pour les VM. Elle permet de définir des zones au sein desquelles les CPU bénéficient d’un accès plus rapide aux ressources locales que les CPU externes.

Le profil KubeVirtRelieveAndMigrate, qui améliore la stabilité de l’éviction de VM lors des migrations à chaud, est également passé en disponibilité générale. Idem pour la possibilité de déployer OpenShift Virtualization sur OCI et en bare metal sur cluster ARM64.

Dans la console, on peut désormais, lors de migrations à chaud, spécifier le nœud vers lequel déplacer une VM. Parallèlement, la procédure de hotplug de disques s’est enrichie d’une étape optionnelle permettant de sélectionner un type de bus.

Illustration © Annika – Adobe Stock

The post Comment la virtualisation sur OpenShift a évolué depuis la fusion Broadcom-VMware appeared first on Silicon.fr.

Il y a avantage quantique lorsque l’association des méthodes quantiques et classiques est plus performante que les méthodes classiques seules.

Aux dernières nouvelles, c’est la définition que donne IBM.

Il n’en a pas toujours été ainsi. En tout cas dans la communication publique du groupe américain.
Encore récemment, il n’était pas explicitement question d’association classique-quantique. La notion était simplement décrite comme la capacité d’un ordinateur quantique à effectuer un calcul de manière plus précise, économique ou efficace (« more accurately, cheaply, or efficiently« ) qu’un ordinateur classique.

Avantage quantique : une méthodo, puis un tracker

Un livre blanc publié à l’été 2025 avec la start-up française PASQAL a témoigné de l’évolution du discours. Y est formulé le postulat selon lequel atteindre un avantage quantique à court terme suppose une intégration avec les infrastructures HPC.

Rappelant, à ce sujet, avoir publié des plug-in Slurm, les deux entreprises établissent surtout, par l’intermédiaire de ce whitepaper, une méthodologie de validation scientifique de l’avantage quantique.

Ce jalon posé, IBM a créé, avec BlueQubit (USA), Algorithmiq (Finlande) et des chercheurs du Flatiron Institute, un « tracker d’avantage quantique ». Lui et ses partenaires sur ce projet ont soumis diverses expérimentations, réparties en trois catégories :

• Estimation des observables quantiques
• Algorithmes quantiques variationnels (destinés à résoudre des problèmes combinatoires)
• Problèmes pour lesquels la vérification quantique est efficace

À travers son API C, Qiskit se rapproche du HPC

L’un des derniers marqueurs de rapprochement vis-à-vis des environnements HPC fut l’introduction d’une fonction autonome de transpilation de circuits dans l’API C de Qiskit. C’était avec la version 2.2 du SDK, publiée en octobre 2025.

Cette API, introduite au printemps 2025 avec Qiskit 2.0, est dotée d’une interface de fonction étrangère qui permet d’exploiter d’autres langages. En première ligne, C++, particulièrement populaire pour le calcul scientifique. Et, plus globalement, les langages compilés (Qiskit a été développé à l’origine en Python, un langage interprété).

Relay-BP, Samplomatic… Des briques à l’édifice de la correction d’erreurs

Entre les deux, Qiskit 2.1 a introduit la possibilité d’ajouter des flags à des régions spécifiques d’un circuit. Une bibliothèque logicielle – Samplomatic, en bêta – y a été adossée. Elle permet de personnaliser ces régions. Et, au bout, de faciliter la construction de circuits dynamiques (qui incorporent des opérations classiques au cours de leur exécution).

Cette personnalisation est aussi censée faciliter la mise en œuvre de techniques de correction d’erreurs.

Sur ce volet, IBM compte notamment avoir assemblé, pour fin 2025, un prototype de processeur. Appelé Loon, il doit réunir divers composantes-clés dont la faisabilité a déjà été démontrée séparément : connectivité à 6 voies, accroissement des couches de routage à la surface de la puce, coupleurs physiquement plus longs, techniques de réinitialisation plus rapide des qubits…

Parmi les autres composantes-clés annoncées cette année, il y a Relay-BP, un algorithme de décodage d’erreurs. IBM en a récemment annoncé une implémentation sur FPGA AMD. Il annonce « moins de 480 nanosecondes » par tâche de décodage, en reconnaissant qu’il reste du travail dans la perspective d’un passage à l’échelle.

Nighthawk en attendant Starling

Relay-BP est arrivé en avance par rapport à la feuille de route. Il était effectivement prévu pour 2026.

À ce même horizon, IBM entend ajouter à Qiskit des outils de profilage de workloads hybrides (quantique-classique). Il prévoit aussi de lancer Kookabura, puce censée réunir unité de calcul et mémoire quantique.

En attendant, la dernière nouveauté côté processeurs s’appelle Nighthawk. Elle prend la suite de la génération Heron avec moins de qubits pour commencer (120 contre 156), mais autant de portes logiques (5000), davantage de coupleurs (218 vs 176), un taux d’erreur médian réduit… et la perspective de monter en capacité :

• Pour 2026 : 7500 portes et jusqu’à 3 x 120 qubits
• Pour 2027 : 10 000 portes et jusqu’à 9 x 120 qubits
• Pour 2028 : 15 000 portes et jusqu’à 9 x 120 qubits

Un ordinateur quantique tolérant aux erreurs reste visé pour 2029. Avec, en ligne de mire, la puce Starling (100 millions de portes, 200 qubits). Blue Jay (1 milliard de portes, 2000 qubits) est censé suivre en 2030.

IBM prévoit un jeu d’instructions tolérant aux erreurs pour 2028

Depuis 2024, Qiskit est assorti d’un catalogue de fonctions : résolution d’équations différentielles (ColibriTD), de problèmes de classification (Multiverse Computing), de problèmes d’optimisation (Q-CTRL, Kipu Quantum), etc.

Ces fonctions trouveront une continuité sous la forme de bibliothèques d’applications quantiques. Les premières sont prévues pour 2027. IBM promet, pour la même échéance, un accélérateur pour au moins un workflow ayant démontré un avantage quantique. Puis, pour 2028, un jeu d’instructions tolérant aux erreurs.

À consulter en complément :

La roadmap d’IBM érige 2029 en année charnière
Transition post-quantique : l’agenda de l’ANSSI se remplit
D-Wave revendique la suprématie quantique : qui l’a fait avant lui ?
Avec son processeur quantique Ocelot, Amazon mise sur les qubits de chat

Illustration © IBM

The post IBM vise l’avantage quantique en tandem avec le HPC appeared first on Silicon.fr.

Ne dites plus Cameyo, mais Cameyo by Google.

En parallèle de ce changement de marque, la communication autour du produit évolue. Elle se porte plus sensiblement sur les intégrations avec l’écosystème Chrome.

En la matière, on ne partait pas de zéro. Mi-2024, lorsque Google avait annoncé acquérir Cameyo, des jonctions étaient déjà en place. Essentiellement vis-à-vis de ChromeOS (intégration avec le système de fichiers local, gestion du presse-papiers, livraison d’apps en tant que PWA…).

Est désormais mise en avant l’idée d’expérience unifiée au sein de Chrome Enterprise. Les applications client lourd virtualisées avec Cameyo bénéficieraient, d’un côté, du même contexte de sécurité que le SaaS (filtrage d’URL, DLP, protection contre les menaces…). Et de l’autre, de la même couche IA, à travers l’assistant Gemini for Chrome.

La virtualisation Linux, moins mise en avant sous l’ère Google

À l’exception de quelques renvois vers chez Google, le site Internet de Cameyo est demeuré tel qu’il était avant l’acquisition.

Parmi les promesses d’alors, il y avait celle de pouvoir virtualiser des applications Linux et des web apps internes sans avoir besoin d’une licence Windows Server.

Dans le giron de Google, cette possibilité n’est pas exclue, mais elle est nettement moins mise en avant, jusque dans l’assistance en ligne.

Le modèle de licence n’a pas non plus changé (abonnement par utilisateur), mais le nombre minimal d’utilisateurs a augmenté : 50 dorénavant, contre 25 auparavant (voire 15 sur la version autohébergée de Cameyo).

La version managée n’est plus déployable sur Azure : Google Cloud est maintenant l’hébergeur exclusif. Il est, dans ce cadre, responsable du déploiement des VM et de leur mise à l’échelle. Mais pas des logiciels – y compris l’OS – qui fonctionnent sur ces VM.

Des jonctions avec Drive et l’annuaire Google Workspace

Sur GCP, un serveur Cameyo peut exploiter 6 niveaux de capacité, variant en vCPU (1 à 16), en RAM (3,75 à 60 Go) et en réseau (pas d’accès Internet sur les deux premiers niveaux). Des clusters peuvent être mise en place pour l’autoscaling.
Pour l’autohébergement, il faut compter au moins 2 CPU et 8 Go de RAM, avec au minimum Windows Server 2019 (Windows Server 2025 n’est pas encore pris en charge).

D’autres jonctions avec l’écosystème Google ont été établies pour l’authentification des utilisateurs (SSO avec compte Google) et la configuration des permissions (annuaire Google Workspace). Drive a par ailleurs été intégré directement dans les sessions (explorateur et fenêtres de dialogue spécifiques).

Cameyo ne gère pas les applications qui ont besoin d’un accès direct à des périphériques locaux (webcams, imprimantes…). Ni celles qui dépendent de fonctions système (enregistrement d’écran, compression de fichiers…).

Illustrations © Google

The post Google relance un Cameyo plus intégré à l’écosystème Chrome appeared first on Silicon.fr.

Entre Ngrok et Pinggy, pas de jaloux : les attaquants qui s’en sont pris au centre hospitalier Stell de Rueil-Malmaison ont exploité l’un et l’autre de ces services de tunneling.

C’était en mars dernier. Au bout, le déploiement d’un ransomware qui avait chiffré des serveurs Windows. La gestion administrative des patients, entre autres, s’en était trouvée indisponible pendant un temps. Des données personnelles ont par ailleurs possiblement été exfiltrées.

Un compte de test admin de domaine

Le point d’entrée fut un ancien compte de test, réactivé le 4 mars 2025 pour un audit Wi-Fi. Ce compte au mot de passe faible avait des privilèges d’admin de domaine et disposait d’un accès VPN.

L’accès initial, via ce vecteur, a lieu le 17 mars (un lundi). Le 22, une latéralisation est mise en œuvre par connexion RDP sur le contrôleur de domaine. Un mécanisme de persistance est ensuite déployé, en ajoutant Pinggy pour établir une connexion SSH sur le port 443.

Vendredi 28 mars, un canal est mis en place entre le contrôleur de domaine et le serveur de l’attaquant grâce à Ngrok. Le même jour, le ransomware est déployé et exécuté. Le lendemain, les traces de l’attaque sur les systèmes sont supprimées.

Le CH de Rueil-Malmaison passe au tiering AD

Le chiffrement n’est constaté que lundi 31 mars. À partir de là, les flux VPN sont coupés ; les serveurs impactés, isolés. Le lendemain, les sauvegardes sont mises hors réseau en vérifiant leur intégrité. L’ANSSI et le CERT Santé se déplacent sur site.

Le 2 avril, l’analyse des serveurs compromis démarre. Et du matériel (postes, clés 4G…) est demandé à l’ARS.

La reconstruction AD débute le 7, parallèlement à la fin des analyses. Le 10, la bascule est achevée. Le service de sauvegarde est relancé, les services métiers impactés sont restaurés et une formation d’administration sécurisée est dispensée.

La période d’avril-mai est marquée par le rétablissement progressif des services RH et d’admission, ainsi que le déploiement de nouveaux postes. Entre juin et septembre, un modèle par niveaux de privilège est mis en place pour l’AD.

Illustration générée par IA

The post Comment un ransomware s’est infiltré au CH Rueil-Malmaison appeared first on Silicon.fr.

Dans la réglementation européenne, les « données à caractère personnel » seront peut-être bientôt une notion moins absolue.

L’omnibus numérique, que Bruxelles doit présenter la semaine prochaine, va en tout cas dans ce sens. Tout du moins si on en croit le brouillon qui a filtré.

À l’heure actuelle, le RGPD définit les données personnelles comme toute information se rapportant à une personne physique identifiée ou identifiable.

L’omnibus numérique impose d’apprécier la notion du point de vue de chaque entité : des informations n’ont pas de caractère personnel pour qui ne peut pas identifier la personne concernée à l’aide de moyens raisonnables. De même, elles ne le deviendraient pas du point de vue de cette même entité simplement parce qu’un destinataire ultérieur aurait raisonnablement les moyens de réaliser cette identification.

Traitement de catégories particulières de données : une exception à la faveur des systèmes d’IA

L’omnibus numérique modifierait une autre définition inscrite dans le RGPD : celle des « données concernant la santé ». Il ne s’agirait plus que de celles qui révèlent « directement » des informations sur l’état de santé d’une personne.

La même approche serait adoptée pour amender l’article 9 (traitement de catégories particulières de données personnelles). Ne serait plus interdit que le traitement de données personnelles révélant « directement » l’origine raciale ou ethnique, les opinions politiques, les convictions religieuses ou philosophiques, etc.

En l’état, cette interdiction ne s’applique pas si certaines conditions sont remplies. Par exemple, l’obtention d’un consentement explicite ou une nécessité pour la sauvegarde des intérêts vitaux de la personne concernée.
L’omnibus y ajoute deux possibilités, dont une touchant au développement et à l’exploitation de systèmes d’IA. Ce à condition d’avoir mis en place les mesures techniques et organisationnelles appropriées pour éviter autant que possible la collecte de catégories particulières de données personnelles. Et, le cas échéant, de supprimer ces données ou d’éviter qu’elles alimentent des outputs, soient divulguées ou soient rendues accessibles à des tiers.

Un allégement des exigences d’information des personnes concernées

L’omnibus numérique amenderait aussi l’article 13 (informations à fournir lorsque des données personnelles sont collectées auprès de la personne concernée).

Actuellement, les dispositions ne s’appliquent pas lorsque la personne concernée dispose déjà de ces informations.

À l’avenir, elles ne s’appliqueraient pas dès lors que les collectes seraient effectuées dans le cadre d’une relation « claire et délimitée » par un responsable de traitement exerçant une activité « non intensive en données ». Et qu’il existerait des motifs raisonnables de supposer que la personne connaît déjà les finalités et la base juridique du traitement, ainsi que l’identité et les coordonnées du responsable.
Tout cela ne vaudrait pas si les données étaient transmises à d’autres destinataires ou catégories de destinataires, transférées vers des pays tiers, exploitées pour de la décision automatisée, ou si le traitement pose un risque élevé pour les droits et libertés des personnes concernées.

De « interdit sauf si » à « autorisé sauf si » : une tournure plus favorable aux décisions individuelles automatisées

La décision individuelle automatisée (article 22) évoluerait aussi en conséquence de l’omnibus numérique.

Actuellement, il est établi que la personne concernée a le droit de ne pas faire l’objet d’une décision fondée exclusivement sur un traitement automatisé produisant des effets juridiques la concernant ou l’affectant de manière significative de façon similaire. Ce droit ne s’applique pas lorsque la décision est :

• Nécessaire à la conclusion ou à l’exécution d’une contrat
• Autorisée par le droit de l’UE ou de l’État membre auquel le responsable de traitement est soumis
• Fondée sur le consentement explicite de la personne concernée

Le fond ne changerait pas. Mais la forme, si, au profit d’une rédaction de type « traitement automatisé autorisé sauf si… ».

Violations de données personnelles : notifications restreintes et délai allongé

Un autre assouplissement est prévu sur l’article 33.

Celui-ci impose actuellement aux responsables de traitement de notifier les violations de données personnelles à l’autorité de contrôle référente sous 72 heures.

L’omnibus numérique cette obligation aux violations engendrant un risque élevé pour les droits et libertés de personnes physiques. Il porterait par ailleurs le délai à 96 heures.

Les autorités de contrôle n’établiraient plus leur liste d’AIPD

La conception de listes des types d’opérations de traitement exigeant une AIPD (analyse d’impact préalable) est actuellement à la charge des autorités de contrôle, qui les communiquent aux Comité européen de la protection des données.

L’omnibus numérique supprimerait cet échelon : la liste serait directement élaborée par ledit comité, qui la transmettrait à la Commission européenne.

Traitements de données au travail : un cadre précisé pour les données des terminaux

L’article 88, relatif au traitement des données dans le cadre des relations de travail, n’évoluerait pas en lui-même. Mais trois articles 88a, 88b et 88c viendraient le compléter.

L’article 88a encadrerait le traitement de données personnelles stockées sur ou provenant de terminaux. Il l’autoriserait s’il est nécessaire pour :

• Acheminer une communication électronique
• Fournir un service explicitement demandé par la personne concernée
• Agréger des infos sur l’usage d’une service en ligne afin de mesurer son audience
• Maintenir ou restaurer la sécurité d’un service demandé par la personne concernée ou du terminal utilisé pour fournir ce service

Pour toutes autres finalités, les traitements auraient à respecter les bases légales énoncées à l’article 6 du RGPD et éventuellement l’article 9 (catégories particulières de données personnelles). Un éventuel consentement devrait pouvoir être manifesté par un clic sur un bouton « ou par des moyens équivalents ». Le responsable de traitement aurait à respecter ce choix pour au moins 6 mois.

Une (énième) perspective d’expression automatisée du consentement

L’article 88b ouvre la voie à une expression du consentement de manière automatisée et lisible par la machine. Une solution que l’UE explore depuis bien longtemps : un amendement de 2009 à la directive ePrivacy avait déjà encouragé un tel mécanisme, notamment par l’intermédiaire des paramètres de navigateur web.

Une fois les normes harmonisées établies, les responsables de traitement auraient 6 mois pour faire en sorte que leurs services gèrent ces signaux. Les médias – tels que définis dans l’European Media Freedom Act de 2024 – n’y seraient pas tenus, « vu l’importance que les revenus publicitaires représentent pour eux ».

En cas d’adoption insuffisante par les fournisseurs de navigateurs web et de systèmes d’exploitation, la Commission européenne aurait le pouvoir de les contraindre par actes délégués.

L’article 88c concernerait les traitements dans le contexte du développement et de l’exploitation de systèmes d’IA. Ils les autoriserait s’ils sont nécessaires au sens de l’article 6(1)(f). C’est-à-dire au nom des intérêts légitimes du responsable de traitement ou d’un tiers, à moins que ne prévalent les intérêts ou les libertés et droits fondamentaux de la personne concernée.

Illustration générée par IA

The post Le RGPD, parti pour changer jusqu’à la définition des données personnelles appeared first on Silicon.fr.

L’échéance approche : le 19 novembre, la Commission européenne devrait présenter son « omnibus numérique ».

Un brouillon, non daté, a filtré avant l’heure. Il est proposé d’y amender 5 textes :

• Data Act (règlement 2023/2854)
• RGPD (règlement 2016/679)
• AI Act (règlement 2024/1689)
• ePrivacy (directive 2002/58/EC)
• SRI 2 (directive 2022/2555)

Il s’agit aussi d’en abroger 4 :

• Data Governance Act (règlement 2022/868)
• Directive Open Data (2019/1024)
• Règlement sur la libre circulation des données à caractère non personnel au sein de l’UE (2018/1807, dit FFDR)
• Règlement promouvant l’équité et la transparence pour les entreprises utilisatrices de services d’intermédiation en ligne (2019/150, dit P2B)

Le Data Act va « absorber » plusieurs autres textes

Data Governance Act, directive Open Data et règlement FFDR seraient consolidés au sein du Data Act. Une démarche d’autant plus logique, à en croire Bruxelles, que ces textes se chevauchent sans que leurs interactions soient toujours claires. Le FFDR, par exemple, a en partie été remplacé par le chapitre VI du Data Act (relatif au changement de services de traitement de données). Quant au chapitre II du Data Governance Act (réutilisation de certaines catégories de données détenues par des organismes du secteur public), il complète les dispositions de la directive Open Data.

La proposition d’omnibus numérique identifie quatre éléments « importants » pour assurer un équilibre entre disponibilité des données et droits/intérêts de leurs détenteurs  :

• Nécessité de renforcer les garde-fous contre le risque de fuite de secrets commerciaux vers des pays tiers dans le contexte des dispositions sur le partage de données des produits connectés
• Risque d’ambiguïtés juridiques au vu du périmètre étendu du cadre business-to-government
• Risque d’incertitude en lien avec les exigences essentielles pour les smart contracts exécutant des accords de partage de données
• Insuffisance de prise en compte, dans le cadre du changement de fournisseur de traitement de données, des services adaptés aux besoin d’un client ou fournis par des PME/small caps

Vers la fin des exigences sur les smart contracts

Les exigences concernant les smart contracts se trouvent au chapitre VIII du Data Act (« Interopérabilité »). Elles touchent au contrôle de l’accès, à l’archivage des données, à la résiliation en toute sécurité, etc. L’omnibus numérique les supprimerait.

Données IoT : une protection renforcée du secret des affaires

Le chapitre II du Data Act régit le partage de données relatives aux produits connectés et aux services connexes. Actuellement, il permet à un détenteur de données de refuser de les communiquer au nom du secret des affaires s’il démontre qu’il existe un risque de préjudice économique grave.
L’omnibus numérique ajouterait un motif de refus supplémentaire : l’existence d’un risque élevé d’acquisition ou d’usage par des pays tiers qui ne garantissent pas un niveau de protection des données équivalent à celui de l’UE.

Un régime « spécial très grandes entreprises » pour l’open data public

Une simplification du cadre business-to-government serait effectuée au niveau du chapitre V du Data Act. Celui-ci régit la mise à disposition de données au bénéfice d’organismes du secteur public, de la Commission européenne, de la BCE ou d’un organe de l’UE « sur le fondement d’un besoin exceptionnel ».
L’omnibus numérique préciserait le champ d’application en remplaçant « besoin exceptionnel » par « urgence publique ».

La fusion des dispositions de la directive Open Data et du Data Governance Act en un chapitre sur la réutilisation des données du secteur public s’accompagnerait d’évolutions. Parmi elles, la possibilité de facturer plus l’accès aux très grandes entreprises – en première ligne, les « contrôleurs d’accès » tels que définis dans le DMA – et d’y assortir des conditions spécifiques.
En parallèle, les règles du Data Governance Act concernant certaines catégories de données protégées seraient introduites dans le Data Act sous forme simplifiée, avec une clarification sur les règles applicables dans les cas où des données personnelles ont été rendues anonymes.

Des facilités pour les PME qui fournissent de services traitement de données…

Le changement de fournisseur de traitement de données est encadré par le chapitre VI du Data Act.

L’omnibus numérique créerait un régime spécifique plus « léger » pour les services « personnalisés » (non commercialisés sur étagère et qui ne fonctionneraient pas sans une adaptation préalable aux besoins de l’utilisateur) à l’exception du IaaS. Ceux faisant l’objet d’un contrat signé avant le 12 septembre 2025 ne seraient soumis à aucune des obligations du chapitre (information, bonne foi, transparence sur les accès internationaux…) sauf celle relative à la suppression progressive des frais de changement.

Ce régime s’appliquerait aussi aux services fournis – dans le cadre de contrats signés avant cette même date – par des PME et des small caps. Ces dernières auraient la possibilité d’inclure, dans les contrats à durée déterminée, des pénalités de résiliation anticipée.

… et pour les fournisseurs de services d’intermédiation de données

L’omnibus numérique incorporerait dans le Data Act deux régimes actuellement inscrits dans le Data Governance Act. D’une part, le chapitre III, qui impose une notification des autorités compétentes par les prestataires de services d’intermédiation de données. De l’autre, le chapitre IV, qui établit un mécanisme d’enregistrement volontaire des organismes altruistes en matière de données au sein de registres publics nationaux.

Vu la nature émergente des services d’intermédiation de données, leurs prestataires ne devraient pas être obligés de notifier les autorités, estime Bruxelles. Le brouillon de l’omnibus numérique va dans ce sens. Il élimine par ailleurs l’obligation de séparation juridique vis-à-vis d’autres services, la remplaçant par une exigence de séparation fonctionnelle.
En ce qui concerne les organisations altruistes en matière de données, les obligations de transparence et de reporting seraient supprimées.

Règlement FFDR : un seul principe préservé

Du règlement FFDR ne serait conservé qu’un principe : celui qui interdit les exigences de localisation des données sauf si elles sont justifiées par des motifs de sécurité publique.

Illustration générée par IA

The post Omnibus numérique : le grand chantier du Data Act appeared first on Silicon.fr.

Et le mot de l’année 2025 est… vibe coding.

Ainsi en a décidé le Collins.
Le dictionnaire britannique qualifie d’argotique (slang) ce terme qui désigne « l’usage de l’intelligence artificielle en langage naturel pour aider à l’écriture de code infomatique ». Il l’attribue à Andrej Karpathy, membre fondateur d’OpenAI et ancien directeur de l’IA de Tesla. Il a également des entrées pour vibe coder (nom) et vibe-code (verbe).

Sur la shortlist figuraient aussi, entre autres :

• taskmasking
  « Fait de donner une fausse impression d’être productif au bureau ».
• broligarchy
  « Petite clique d’hommes très riches qui exercent une influence politique ». En première ligne, les milliardaires de la tech présents à l’investiture de Donald Trump pour son deuxième mandat de président des États-Unis.
• clanker
  « Terme péjoratif pour un ordinateur, un robot ou une source d’intelligence artificielle ». Il trouve son origine dans la franchise Star Wars et dérive du nom clank, qui désigne un cliquetis, un « bruit sec et métallique »

Les « mots de l’année » du Collins ont régulièrement trait aux technologies :

• Geek en 2013 (Bitcoin et phablet étaient sur la shortlist)
• Fake news en 2017
• NFT en 2021 (crypto, metaverse et hybrid working étaient sur la shortlist)
• AI en 2023

Je prompte, tu promptes, il prompte…

En France, les dictionnaires de référence n’ont pas encore intégré le vibe coding.

Parmi les mots nouveaux du Petit Robert 2026 (publié en mai 2025) figure l’hypertrucage.
Cette recommandation officielle pour « deepfake » vient du Canada, mais elle « se fait une place en français », nous assure-t-on. Preuve en serait de son emploi dans la version française de l’AI Act.
En parallèle, le mot hallucination voit son sens enrichi (« réponse fausse produite par une intelligence artificielle générative, avec une apparence de vérité »).

Le Petit Robert 2026 a également accueilli « apprentissage profond » (recommandation officielle pour deep learning), « clonage de voix »… et le verbe prompter.

Le substantif prompt était arrivé l’année précédente. Comme « solutionnisme (technologique) »/ »technosolutionnisme« , défini comme une « idéologie qui consiste à rechercher des solutions technologiques aux problèmes (sociaux, écologiques, etc.) sans en examiner les causes profondes ».

L’édition 2024 du Petit Robert avait accueilli métavers et minage (au sens de « validation, en échange d’une rémunération, d’un ensemble de transactions effectuées en cryptomonnaie avant inscription sur une blockchain »). Ainsi que disquette, au sens (familier) de « phrase, formule peu flatteuse, souvent lourde, destinée à séduire quelqu’un » (ou de « parole trompeuse ; mensonge »).

Le modèle de langage est entré dans le Petit Larousse

« Prompter » n’est pas encore dans le Petit Larousse, mais « prompt » y est entré cette année. Comme « modèle de langage« . Et l’adjectif haptique, se référant à une « technologie qui reproduit en temps réel la sensation du toucher dans un environnement virtuel »).

L’édition 2025 du Petit Larousse avait accueilli les noms bot et cyberattaque, l’expression « détox digitale » et le verbe cracker (« faire sauter illégalement les dispositifs de protection d’un système informatique »), venu compléter le substantif cracke(u)r. En 2024, « instagrammable », entre autres, avait fait son entrée.

À consulter en complément :

Canva impose le vibe coding pour le recrutement des développeurs
Vibe coding : bonne ou mauvaise vibe ?
Assistants de codage : un marché volatil où les prix sont peu lisibles

Illustration générée par IA

The post De prompt en vibe coding, le lexique de l’IA générative entre dans l’usage appeared first on Silicon.fr.

Intelligence artificielle, automatisation et intégration multiplateforme : les solutions de travail collaboratif changent de dimension. Pour les managers IT, ces évolutions représentent à la fois une opportunité de productivité et un défi d’intégration.