AirDrop et Quick Share sont désormais interopérables.

Apple n’en fait pas grande publicité. Au contraire de Google, même si la prise en charge se limite pour le moment à la gamme Pixel 10 et au mode « tout le monde » (pas possible de restreindre les échanges de fichiers aux contacts seulement).

Vers la fin d’un protocole propriétaire

Si Apple est discret, c’est que cette interopérabilité lui a été imposée par l’Europe, en application du DMA. La consigne, dans les grandes lignes : proposer aux tiers une solution de partage Wi-Fi P2P aussi efficace que celle implémentée pour ses propres appareils et services.

Sur iOS et iPadOS (les plates-formes Apple encadrées par le DMA), deux protocoles peuvent être utilisés. L’un ouvert (le standard Wi-Fi Aware), l’autre propriétaire (AWDL, Apple Wireless Device Link).

Apple a choisi de proposer l’interopérabilité via Wi-Fi Aware plutôt que d’ouvrir AWDL. Ce dernier se trouve donc condamné à terme. En attendant, il pourrait tout de même falloir le rendre interopérable dès lors qu’il existerait un écart fonctionnel avec l’implémentation Wi-Fi Aware. De même, les puces Wi-Fi des iPhone et des iPad devront pouvoir gérer deux connexions P2P concurrentes. Une demande que la Commission européenne a maintenue malgré l’opposition d’Apple. Elle persiste aussi à lui demander d’implémenter la prochaine version majeure de Wi-Fi Aware (5.0) dans les 9 mois suivant sa publication. Et à ne pas empêcher que des fonctionnalités d’AWDL soient intégrées dans ce standard.

Wi-Fi Aware : ce qui est attendu d’Apple

L’implémentation Wi-Fi Aware doit notamment permettre :

• D’établir une connexion à la demande, sans davantage d’interventions de l’utilisateur que ce qui est nécessaire entre appareils Apple
• De maintenir en parallèle une connexion Wi-Fi infrastructure
• D’accéder aux mêmes métadonnées de connexion et de configurer les mêmes paramètres

L’accès aux mêmes métadonnées doit, entre autres, permettre de stocker et d’ouvrir les fichiers reçus dans des apps spécifiques, comme le permet AirDrop.

Par « mêmes paramètres », il faut notamment entendre la possibilité de faire confiance à un appareil via l’OS dans des conditions équivalentes à celles d’AirDrop. Et de restreindre la découverte d’appareils à ceux préalablement désignés comme étant de confiance.

L’interopérabilité du partage WI-Fi P2P suppose aussi des obligations en matière d’accessibilité. Parmi elles :

• Traitement équitable par rapport à AirDrop dans le menu de partage d’iOS
• Lancement de transferts sans avoir à ouvrir d’application tierce
• Capacité à exploiter l’UI système pour le transfert de fichiers
• Découverte d’appareils destinataires même si la solution de transfert n’y est pas installée (l’utilisateur doit alors être alerté des fichiers entrants et guidé vers l’app store approprié)

Les solutions tierces de transfert doivent par ailleurs pouvoir changer dynamiquement de protocole de communication, comme AirDrop le fait entre P2P, infrastructure, Bluetooth et réseau cellulaire.

À consulter en complément :

iOS face au DMA : les 12 travaux d’Apple
Révision du DMA : quelques pistes d’action
Apple demande l’abrogation du DMA

Illustration générée par IA

The post Le DMA rend iOS et Android un peu plus interopérables appeared first on Silicon.fr.

Continuité d’activité, planning de rotation, veille médiatique… Toutes ces notions sont désormais définies dans le référentiel PRIS (prestataires de réponse aux incidents de sécurité).

En toile de fond, l’intégration d’une nouvelle activité : la gestion de crise d’origine cyber. Sous le code CRISE, elle rejoint :

• Recherche d’indicateurs de compromission (REC)
• Investigation numérique (INV)
• Analyse de codes malveillants (CODE)
• Pilotage et coordination des investigations (PCI)

La gestion de crise était déjà présente dans la version précédente du référentiel (juillet 2024), mais à la marge. Essentiellement à travers une recommandation à sensibiliser les commanditaires sur la mise en place d’un tel dispositif.

Une marge de manœuvre pour déléguer

La prestation peut être effectuée indépendamment des autres – alors que, par exemple, PCI ne peut être livré sans REC et INV, eux-mêmes indissociables.

L’ANSSI laisse la possibilité de déléguer à un autre profil que le gestionnaire de crise certaines tâches d’appui :

• Retranscription et rédaction des comptes rendus de réunions
• Mise en œuvre de l’organisation de crise et des moyens (réservation de salles de réunion et de moyens logistiques, par exemple)
• Retranscription des décisions, actions et arbitrages
• Recueil des entretiens et des aspects logistiques pour la formalisation d’un éventuel retex

Elle ne recommande cependant pas que pour une même prestation qualifiée, une personne physique cumule le rôle de gestionnaire de crise avec celui d’analyste.

Se synchroniser avec l’activité PCI

En conséquence de l’intégration de cette activité dans le référentiel, les missions du pilote d’investigation (associé à PCI) évoluent. On attend désormais formellement de lui qu’il assure une cohérence avec les priorisations de gestion de crise d’origine cyber. C’est même impératif au niveau de qualification élevé (par opposition au niveau dit substantiel) : « Lorsque des opérations d’investigation et de gestion de crise d’origine cyber sont réalisées simultanément […], le prestataire doit s’assurer de la bonne synchronisation de ces opérations sur le périmètre qui l’incombe (sic). »

Le prestataire doit être capable d’aider à identifier, en amont :

• Applications, systèmes, données et périodes critiques de l’organisation
• Impacts relatifs à l’incident de sécurité et conséquences sur l’activité du bénéficiaire
• Tiers éventuels dont l’implication pourrait être nécessaire
• Principaux enjeux à court et moyen terme et obligations juridiques applicables
• Enjeux de communication de crise

Il s’agit aussi d’accompagner la préparation des dépôts de plainte et des déclarations d’incident(s) aux autorités compétentes. Tout en établissant, avec le commanditaire, les critères et indicateurs de suivi et de sortie de crise.

Retex et restitution « à chaud » au niveau élevé de qualification

Concernant l’exécution même de la prestation, quelques éléments ne s’appliquent qu’au niveau élevé de qualification.

• Limiter les objectifs stratégiques définis dans le plan d’action et les baser « sur les priorités du contexte » ; spécifier au moins un délai de mise en œuvre pour les objectifs opérationnels qui en découlent.
• Pouvoir mettre à disposition de la cellule de crise stratégique (ou équivalent) des supports d’aide à la décision.
• Prendre en compte les conséquences et impacts permettant de justifier le déroulement des actions consignées dans le registre que doit tenir le prestataire.

Le niveau élevé de qualification implique d’organiser une restitution « à chaud » à la fin de chaque journée. Et d’être capable de formaliser un retex.

Illustration © VicenSahn – Adobe Stock

The post La gestion de crise cyber consacrée dans le référentiel PRIS appeared first on Silicon.fr.

Une application tierce compromise, et c’est la porte ouverte sur des données clients.

Salesforce s’était retrouvé dans cette situation au mois d’août. L’application concernée – un chatbot de gestion commerciale – émanait de l’éditeur américain Salesloft. Ce dernier avait été compromis au préalable (compte GitHub, puis environnement AWS) afin de récupérer des jetons d’API (tokens OAuth) utilisés par ledit chatbot pour se connecter à Salesforce.

Un incident du même type vient de se produire avec une application d’un autre éditeur américain : CS (Customer Success), de Gainsight. Celui-ci revendique, entre autres clients, GitLab, Glassdoor, GoTo, Jamf, Notion, Okta, Sonos et Zapier.

Salesforce a coupé la connexion avec Gainsight dans la matinée du 20 novembre. Il ne l’a pas rétablie depuis. D’autres éditeurs ont suivi par précaution, dont Hubspot et Zendesk.

Aux dernières nouvelles, Gainsight estime que 3 organisations ont été touchées. Ce n’est pas l’avis de Google/Mandiant, chargé d’enquêter : à l’en croire, plus de 200 instances ont potentiellement été affectées. La campagne est possiblement l’œuvre d’affiliés au collectif ShinyHunters.

Il faudra peut-être réactiver manuellement certaines règles lorsque la connexion sera rétablie, prévient Gainsight. Qui signale par ailleurs que ses plug-in pour Gmail et Outlook ne sont pas fonctionnels pour qui s’y connecte via Salesforce.

Les campagnes contre Salesforce s’accumulent

Les accès indésirables via le chatbot de Salesloft ont fait de multiples victimes dans le secteur IT (Boomi, IBM, Nutanix, OpenText, Proofpoint, Pure Storage, Rubrik, Zscaler…). Des tickets de support ont notamment été exposés… et des secrets avec.

Cet incident, combiné à d’autres, a culminé il y a quelques semaines en un leak. Sous l’enseigne SLSH (Scattered LAPSUS$ ShinyHunters), des cybercriminels ont menacé de publier des données… et de soutenir les actions en justice qui s’ensuivraient, en particulier pour violation du secret des affaires.

SLSH avait fixé un ultimatum au 10 octobre. Il l’avait aussi soumis à Red Hat, après la compromission d’une instance GitLab liée à son activité de conseil (une mine potentielle de secrets d’infra : inventaires, topologies réseau, playbooks et blueprints, résultats d’audits de sécurité…).

Au lendemain de la date, quelques datasets issus des campagnes contre Salesforce furent publiés. Les deux plus gros – contenant l’un et l’autre des données personnelles par million – concernaient les compagnies aériennes Qantas et Vietnam Airlines. Une filiale américaine d’ENGIE était aussi dans le lot.

Dans la foulée, SLSH avait annoncé, sur son Telegram, cesser ses activités jusqu’en 2026. Il avait déclaré vouloir se concentrer sur les employés du FBI et de la NSA, probablement en réponse à la saisie des serveurs de BreachForums.
Quelques jours plus tard, des membres avait officialisé la « dissolution permanente » du groupe après l’arrestation de plusieurs administrateurs.

Illustration générée par IA

The post Nouveau vol de données Salesforce via une intégration SaaS appeared first on Silicon.fr.

Avec JUPITER, l’Europe entre dans l’ère exascale.

Cette promesse faite début septembre à l’inauguration du supercalculateur est validée dans le dernier TOP500. Le système a atteint 1 exaflops tout rond, soit un milliard de milliard d’opérations par seconde en précision 64 bits.

Une telle puissance favorise – voire conditionne – la mise en œuvre des projets qui ont obtenu du temps de calcul. Aux dernières nouvelles, ils sont une centaine, sélectionnés principalement par deux voies. D’un côté, un « programme d’accès anticipé »
porté par EuroHPC. De l’autre, une « compétition IA »
organisée par le Gauss Centre for Supercomputing (GSC), qui réunit les trois centres de calcul nationaux allemands.

Une simulation quantique à 50 qubits

L’un de ces centres – le JSC, situé à Juliers, en Rhénanie-du-Nord-Westphalie – héberge JUPITER. À l’occasion de l’inauguration, il avait mis en avant deux projets, consacrés respectivement à la simulation quantique et climatique.

Le premier vient d’atteindre son objectif : simuler un ordinateur quantique universel à 50 qubits, avec une version compilée de l’algorithme de Shor (factorisation d’entiers) et un recuit quantique du modèle de Hubbard (interaction entre électrons). Il bat ainsi le record précédent de 48 qubits, établi par une autre équipe du JSC sur le superordinateur K (aujourd’hui décommissionné ; il était localisé au Japon).

L’architecture mémoire hybride des puces NVIDIA GH200 qui composent la partition JUPITER Booster y a contribué. Le logiciel de simulation a été adapté pour en tirer parti. Plus précisément, pour permettre des débordements temporaires vers la mémoire CPU avec une perte minimale de performance.

D’autres innovations y ont été greffées. Dont une méthode d’encodage des octets divisant par 8 la quantité de mémoire nécessaire. Et un algorithme dynamique optimisant en continu les échanges de données.

Le deuxième projet doit approfondir des travaux conduits sur le supercalculateur Alps (Suisse) par l’Institut Max-Planck de météorologie. Il s’agit d’optimiser le modèle climatique ICON pour le faire passer à l’échelle sur les 24 000 GPU de JUPITER, afin d’aboutir à des simulations sur une échelle de plusieurs décennies, à une résolution de l’ordre du km, et en incluant le cycle carbone complet.

Des projets que l’exascale rend réalisables

Dans le domaine de la physique, l’exascale bénéficiera par exemple à l’université de Bonn, dans son projet d’étude de la formation des éléments lourds, vu le nombre de particules impliquées. Il s’agira, en particulier, d’explorer les propriétés des objets les plus denses de l’Univers : les étoiles à neutrons.

L’université de Cologne estime elle aussi avoir besoin d’une puissance exaflopique, dans le cadre d’un projet touchant à la dynamique des liquides biologiques. Elle souhaite comprendre l’organisation des micro-organismes actifs (algues, bactéries, spermatozoïdes…) et les structures qui se forment à des échelles bien plus grandes. Des applications sont envisagées dans la robotique en essaim, la capture du carbone et les biocarburants.

L’université de Hambourg perçoit également un bénéfice à l’exascae dans son étude de la turbulence magnétohydrodynamique (comportement d’un fluide porteur de charges électriques en présence de champs électromagnétiques), vu l’extrême gamme dynamique induite.

Pour l’université de Ratisbonne, un supercalculateur exaflopique est synonyme de boîtes spatio-temporelles plus grandes pour l’étude de la physique des quarks et des gluons. Et de précision accrue à basse énergie.

Davantage de précision spatiale et temporelle

À l’université de technologie de Darmstadt, on s’intéresse à la dynamique de combustion de l’hydrogène, très différente de celle des carburants conventionnels. L’exascale doit permettre de descendre à l’échelle de la nanoseconde et de capturer la structure des flammes turbulentes au micromètre près.

De par les échelles de temps qu’implique son projet d’étude de l’interaction onde de choc – couche limite, l’université de Stuttgart entend aussi trouver un bénéfice dans l’exascale. Comprendre ce phénomène est crucial pour améliorer la conception des cellules et des systèmes de propulsion des aéronefs… et, au bout, réduire l’empreinte carbone.

L’Institut Max-Planck de biophysique mise sur JUPITER pour la simulation dynamique des pores nucléaires, qui font partie des plus grands complexes protéiques. Comprendre comment y est régulé le transport moléculaire promet des débouchés thérapeutiques et dans les nanotechnologies.

JUPITER va former une flopée de LLM

Quelques projets sélectionnés par EuroHPC visent à développer des modèles d’IA. Par exemple à l’université Louis-et-Maximilien de Munich : des modèles de diffusion « légers » pour générer de la vidéo. L’exascale doit permettre d’entraîner sur de gros datasets et ouvrir la voie à des LLM capables de généraliser bien au-delà de leurs données d’entraînement.

Des projets de LLM, il y en a à foison parmi ceux qu’a retenus le GSC. Celui que projette la PME française Dragon LLM (ex-Lingua Custodia ; voir notre article à son sujet) en fait partie. Celui de Tilde aussi. L’entreprise lettone vise un LLM focalisé sur les langues baltiques et d’Europe de l’Est. Elle mise sur JUPITER pour générer des données synthétiques grâce à des modèles open weight.

L’université d’Édimbourg attend elle aussi beaucoup en matière de génération de données synthétiques. En particulier de longs documents et de chaînes de pensée, son projet étant censé produire des modèles de raisonnement.

Du côté de la Bibliothèque nationale de Suède, on projette un LLM spécial langues scandinaves. On compte sur JUPITER pour pouvoir entraîner de plus gros modèles et exploiter de plus gros datasets.

Chez Multiverse Computing (Espagne), on travaille sur des techniques de compression des modèles, avec un focus sur DeepSeek-R1 (671 milliards de paramètres). Textgain (Belgique) s’appuie quant à lui sur le projet CaLICO (modèle de modération de contenu) pour développer des encodeurs de texte capables de créer efficacement des représentations contextualisées. Il espère que la puissance de JUPITER lui permettra d’aller chercher des sources qu’il n’a pas exploitées jusque-là, comme les réseaux sociaux.

Le GSC a aussi sélectionné le Centre européen pour les prévisions météorologiques à moyen terme (ECMWF), qui porte un projet de modélisation de la Terre à résolution kilométrique. Il a également accordé du temps de calcul à l’université Sapienza de Rome et au Cryprus Institute. La première a un projet d’étude de l’échauffement et de la traînée aérodynamique dans les véhicules super et hypersoniques. Le second s’intéresse à la chromodynamique quantique pour analyser la structure des constituants fondamentaux de la matière.

La partition Rhea toujours en attente

La construction de JUPITER avait démarré en décembre 2023.

Au printemps 2024, un « modèle réduit » (JEDI, JUPITER Exascale Development Instrument) avait été mis en service. Ayant permis de développer la stack de gestion du supercalculateur, il a fini par se hisser en tête du Green500, à 72,7 Gflops/W.

Un premier stade d’évolution avait été atteint fin 2024 avec la mise en service de JETI (JUPITER Exascale Transition Instrument). Cette itération à 10 racks représentait 1/12 de la puissance finale attendue. Elle avait atteint 83 Pflops au TOP500, se classant 18^e.

La partition Booster était apparue dans ce même TOP500 en juin 2025, avec une performance de 793 Pflops.

Une partition Cluster, fournie par ParTec (Allemagne), doit encore être ajoutée. Elle a pris du retard, concomitamment au processeur censé l’équiper : le Rhea-1 du français SiPearl.

Illustration © Forschungszentrum Jülich / Sascha Kreklau

The post JUPITER atteint l’exascale : que fait-on avec ce supercalculateur ? appeared first on Silicon.fr.

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.