Au Parlement et au Conseil : prière de ne pas adopter telle quelle la proposition de règlement omnibus numérique.
Le CEPD (Comité européen de la protection des données) et l’EDPS* (Contrôleur européen de la protection des données) avertissent ainsi les colégislateurs de l’UE. Dans leur collimateur, un amendement au RGPD modifiant la définition des données personnelles.
À l’heure actuelle, est définie comme telle toute information se rapportant à une personne physique identifiée ou identifiable.
L’omnibus impose d’apprécier la notion du point de vue de chaque entité. Des informations n’auraient pas de caractère personnel pour qui ne peut pas identifier la personne concernée à l’aide de moyens raisonnables. De même, elles ne le deviendraient pas du point de vue de cette même entité simplement parce qu’un destinataire ultérieur aurait raisonnablement les moyens de réaliser cette identification.
Une modification guidée par un arrêt CJUE
D’après le CEPD et l’EDPB, cette modification vise à codifier essentiellement un arrêt CJUE de septembre 2025.
L’affaire impliquait le Conseil de résolution unique (CRU, autorité de résolution de l’Union bancaire européenne). Ce dernier avait, lors de la résolution de Banco Popular Español, collecté des données d’actionnaires et de créanciers. Il en avait envoyé une partie à Deloitte pour analyse, après les avoir pseudonymisées, mais sans informer de ce transfert les personnes concernées.
Saisi à ce sujet, le CEPD avait estimé que les données en question conservaient un caractère personnel. Et que Deloitte devait donc être mentionné comme destinataire.
Le Tribunal de l’UE avait jugé que non. Selon lui, la qualification devait s’apprécier du point de vue du cabinet, qui n’avait pas la possibilité de réidentifier.
Le CEPD avait formé pourvoi auprès de la CJUE… qui a en quelque sorte coupé la poire en deux. Elle a en l’occurrence considéré que les données avaient un caractère personnel pour le CRU (en tant que responsable initial), mais pas pour Deloitte (destinataire non réidentifiant).
Des lignes directrices plutôt qu’une définition ?
L’affaire a ses spécificités, et la Commission européenne semble en faire fi, clament aujourd’hui l’EDPB et le CEPD. Modifier la définition des données personnelles sur la base d’une codification de ce seul arrêt risque d’engendrer de l’incertitude juridique, poursuivent-ils. Incertitude que renforce, d’une part, la tournure « négative » selon laquelle des informations n’acquièrent pas de caractère personnel simplement par existence d’un potentiel destinataire réidentifiant. Et de l’autre, l’emploi du terme « entité », juridiquement non défini dans le contexte du RGPD.
En plus de « restreindre nettement » la notion de données personnelles, ce changement pourrait inciter les responsables de traitement à trouver des failles, ajoutent le CEPD et l’EDPB. Par exemple, externaliser « artificiellement » certaines activités pour les séparer des moyens de réidentification.
L’EDPB a mené une consultation publique en vue de mettre à jour ses lignes directrices sur la pseudonymisation. Les contributions, déclare-t-il, ont montré que l’arrêt CJUE soulève de nombreuses questions dès lors qu’on prend en considération le reste de la jurisprudence de la cour. Et d’affirmer que ces questions seront mieux traitées par ces lignes directrices que par une modification de la définition des données personnelles.
* L’EDPS veille au respect du RGPD par les institutions et organes de l’UE.
Et le premier modèle propriétaire d’OpenAI à ne pas tourner sur du GPU NVIDIA est… GPT-5.3-Codex-Spark.
Cette version « allégée » de GPT-5.3-Codex fonctionne effectivement sur la dernière génération des puces accélératrices Cerebras. Ou, devrait-on dire, des « mégapuces » : 4000 milliards de transistors sur 460 cm², pour 900 000 cœurs délivrant 125 Pflops.
Un complément basse latence à l’option GPU
Cerebras – qui fournit aussi Mistral et Perplexity – avait officialisé en janvier son contrat avec OpenAI. Ce dernier disait prévoir une intégration par étapes dans sa pile d’inférence, avec l’objectif de couvrir l’ensemble de ses workloads pour fin 2028. Non pas en remplacement, mais en complément des GPU, pour donner une option très basse latence (21 Po/s de bande passante mémoire, 27 Po/s de bande passante interne, 214 Po/s entre cœurs). Avec GPT-5.3-Codex-Spark, c’est censé se traduire, entre autres, par un débit de plus de 1000 tokens par seconde.
Le modèle est pour le moment en aperçu pour les abonnés ChatGPT Pro, sur l’app Codex, le CLI et l’extension VS Code. Ne gérant que la modalité texte avec une fenêtre de contexte de 128k, il a ses propres limites d’usage, non décomptées du forfait. OpenAI le teste aussi sur son API, auprès de « quelques partenaires ». Windsurf l’a par ailleurs intégré dans son leaderboard.
OpenAI va généraliser WebSocket
Les travaux menés pour réduire la latence bénéficieront aux autres modèles d’OpenAI. En particulier, l’introduction d’un chemin WebSocket, activé par défaut. Combiné à des optimisations ciblées sur l’API Responses et sur l’initialisation des sessions, il a permis, dans le cas de GPT-5.3-Codex-Spark, de réduire de 30 % la surcharge par token, pour un TTFT (time to first token) divisé par 2.
Sur cette base, OpenAI entend proposer, à terme, un Codex « hybride » qui exploitera ce type de modèle pour les interactions simples tout en sachant déléguer les plus grosses tâches à des sous-agents tournant potentiellement sur du GPU.
On se rappellera que l’entreprise de Sam Altman a aussi un accord avec AMD, annoncé en octobre dernier. Il doit se traduire par une prise de participation (10 % du capital) et le déploiement potentiel de 6 GW de puissance de calcul – dont 1 GW en GPU Instinct MI450 cette année.
Mélangez ITOps et agentique : cela donne l’AgenticOps.
Cisco avait dévoilé cette marque ombrelle en juin 2025. Il y avait associé une vitrine nommée AI Canvas. La promesse : un espace de travail collaboratif orchestrant les différentes instances de Cisco AI Assistant, et dont l’interface serait générée de façon dynamique à partir des données de télémétrie. Il aurait plusieurs points d’entrée, à commencer par Meraki et Splunk… jusqu’au futur Cisco Cloud Control (moteur unifié de politiques réseau, sécurité et observabilité)*.
La disponibilité générale d’AI Canvas se fait encore attendre. Si bien que pour le moment, la principale traduction de la promesse AgenticOps est Cisco AI Assistant. Sa diffusion dans l’écosystème Cisco se poursuit, avec désormais Catalyst Center en ligne de mire (il y est disponible en bêta, sur demande).
Dans le même temps, les capacités de dépannage et d’optimisation agentique arrivent sur les réseaux OT. Sur la partie campus/succursales, ce sont les recommandations de configurations qui font leur entrée, en complément à des améliorations pour le module AI Packet Analyzer.
Toujours sur le volet AgenticOps, côté datacenter, la corrélation d’événements sur Nexus One doit arriver en juin. Auparavant (en mai), des fonctionnalités devraient commencer à apparaître dans Security Cloud Control, pour le firewall.
Autre nouveauté : une composante Experience Metrics (en alpha) censée faire le pont avec les données d’UX pour consolider le dépannage. Elle s’appuie sur des intégrations avec Apple, Intel, Samsung et Zebra.
Des SLM maison et des outils associés
Pour porter sa démarche AgenticOps, Cisco a développé un modèle spécialisé (Deep Network Model). Mi-2025, il était dit formé sur 40 millions de tokens. Au dernier pointage, on a atteint les 100 millions.
À ce modèle en sont associés d’autres. Cisco a renforcé ses capacités en la matière en s’offrant – en novembre 2025 – une entreprise à l’origine d’une plate-forme LLMOps. Le groupe américain a aussi conçu des briques destinées à favoriser le traitement des données machine : LAPSE et ACE.
LAPSE (Lightweight Autonomous Program Synthesis and Execution) structure la télémétrie : il la convertit à la volée vers un schéma optimisé pour la tâche.
ACE (Analytics Context Engineering) favorise l’ingénierie de contexte. Il embarque l’analytics dans la boucle de raisonnement des LLM en utilisant un sous-ensemble de SQL et des outils Bash ancrés sur un système de fichiers virtuel mappé aux API d’observabilité.
Ce système doit permettre de communiquer à tout modèle des « vues hybrides » optimisées pour ses compétences, tout en l’autorisant à fouiller les données brutes. D’abord conçu pour améliorer le Deep Network Model, il est aujourd’hui un service autonome.
Orientées lignes ou colonnes (un algorithme le détermine), les vues sont par défaut en JSON. Cisco propose un format custom inspiré par le projet TOON.
* Meraki et ThousandEyes furent les premières sources de données d’AI Canvas. Le service gère la télémétrie d’équipements tiers si injectée à la main ou via Splunk. Cisco envisage de permettre à des partenaires d’y intégrer des capacités par API.
Les « identités non humaines » sont désormais bien ancrées dans la communication de GitGuardian.
L’annonce d’un nouveau tour de table en témoigne. L’entreprise française a levé 50 M$* qui lui serviront notamment à « répondre à la crise des identités non humaines ». Il s’agira aussi de combler le « vide sécuritaire » (security gap) des agents IA.
Le tour de table précédent (44 M$, série B) avait été officialisé fin 2021. GitGuardian ne parlait pas encore d’identités non humaines, d’autant qu’il n’avait pas de produit dédié.
Celui-ci serait lancé au printemps 2025. Il apporterait une gestion centralisée des secrets, complétant les offres axées sur leur détection (monitoring interne + surveillance de l’activité publique sur GitHub).
Au démarrage n’était que cette partie surveillance externe. La brique de monitoring interne avait été lancée en 2020, dans la foulée du tour de table de série A (12 M$). GitGuardian promettait alors de transformer ce socle en une « plate-forme exhaustive de sécurité du code ». L’année suivante, il remporterait le grand prix de la start-up au FIC.
Découvrir les secrets de l’IA agentique
La stratégie s’oriente donc désormais sur les systèmes d’IA… et sur la gouvernance des secrets qu’ils exploitent. En parallèle, pour la première fois dans le cadre d’une annonce de levée de fonds, GitGuardian évoque une extension de ses activités au Moyen-Orient, en Asie et en Amérique du Sud. Autre évolution : il ne met plus l’accent sur son public de développeurs individuels, mais de développeurs en entreprise (« plus de 115 000 »).
Sur le volet gestion des identités machine, GitGuardian a récemment fait la jonction avec AWS IAM et Entra ID. Anthropic et OpenAI ont rejoint son catalogue de connecteurs ; comme, dernièrement, Datadog, Snowflake, Okta et Slack, entre autres.
Du machine learning est venu enrichir la description des secrets découverts, le regroupement d’incidents et le scoring des risques. GitGuardian a aussi intégré une couche de langage naturel pour parcourir les journaux d’audit. Et un serveur MCP pour lire et analyser des incidents, automatiser leur résolution et générer des pots de miel.
* Tour de table emmené par le fonds américain Insight Partners. La société de gestion française Quadrille Capital a participé, aux côtés d’investisseurs existants (Balderton Capital, Bpifrance, Sapphire Ventures et le fonds allemand Fly Ventures).
Sur le GitHub de l’ANSSI, les projets seront bientôt classés par « niveau d’ouverture ».
L’agence le signale désormais sur la page qui présente sa politique open source. Elle utilisera la classification qu’a élaborée la DINUM :
Contributif (contributions extérieures activement recherchées et traitées)
Ouvert (contributions extérieures traitées mais non activement recherchées)
Publié (contributions extérieures non traitées)
Autre nouveauté sur la page en question : l’évocation de l’open source en tant que levier d’action de la politique industrielle de l’ANSSI. Par ce lien « récent et en développement », l’agence cherche à favoriser la disponibilité de solutions cyber alignées sur les besoins.
Par rapport à l’ancienne version de la page, l’aspect « liste de projets » est moins marqué. L’ANSSI insiste davantage sur les licences, le transfert de projets et sur sa propre utilisation de solutions open source. Elle a ajouté des références à la communauté BlueHats ainsi qu’à celle des OSPO français.
Une partie des projets auparavant mentionnés se retrouvent sur la page d’accueil de l’organisation GitHub ANSSI-FR. Entre autres, DFIR ORC (outils de recherche de compromission), WooKey (micronoyau + environnement de dev pour le prototypage de solutions IoT) et CLIP OS (système d’exploitation Linux durci). Le premier est d’une envergure suffisante pour avoir sa propre orga GitHub. Les deux autres ont aussi la leur, mais parce qu’ils sont archivés.
Audit CSPN réussi pour Barbican, Suricata et KeePassXC
L’ANSSI évoque toujours son financement d’évaluations de sécurité, ad hoc ou sur les critères CSPN.
En 2018 avait démarré l’évaluation CSPN de Barbican (service de gestion de clés de la pile OpenStack), finalement certifié. La même année avait commencé celle de Suricata (détection et prévention d’intrusion), qui avait lui aussi réussi l’audit.
S2OPC (implémentation du protocole de communication OPC UA), nftables (sous-système Linux de filtrage de paquets) et KeePassXC (gestionnaire de mots de passe) ont également obtenu la CSPN.
Par deux fois, la version « originale » de KeePass (pour Windows) n’a pas réussi l’audit CSPN. Ça n’est pas non plus passé pour Keystone et Ansible (en 2018), strongSWAN (2019), Secretin, Belenios et Sudo (2021), ainsi que WireGuard (2023).
Microsoft vient-il de bouleverser le modèle mental et opérationnel auquel les admins de parcs Windows se sont habitués ?
Le groupe américain a eu droit à ce commentaire à propos de Windows 11 26H1.
Cette version, stable depuis le 10 février, est particulière à plusieurs titres. D’abord, elle ne cible pour le moment qu’une plate-forme : les Snapdragon X2 (les premiers PC qui en seront équipés sont attendus pour mars-avril). Ensuite, comme elle a son propre cœur Windows, elle aura aussi son propre chemin de mise à niveau – non défini pour l’heure. Autrement dit, elle ne pourra pas basculer vers le futur Windows 11 26H2.
Dans ce contexte, Windows 11 24H2 et 25H2 restent les versions recommandées pour les déploiements en entreprise, explique Microsoft. Il faut voir Windows 11 26H1 comme le moyen d’évaluer de nouvelles plates-formes… même si les Insiders ont pu l’expérimenter sur des appareils Arm existants comme Surface Laptop.
Windows 11 26H1, un simple glissement sémantique ?
À parité fonctionnelle avec Windows 11 25H2, Windows 11 26H1 suivra le même cycle de vie : 24 mois de support standard pour l’édition Pro, 36 mois pour l’édition Entreprise. En l’état, il ne gère pas le mécanisme des mises à jour correctives à chaud (hotpatch)*.
Pour les admins, c’est une nouvelle approche à assimiler, en tout cas sur le plan sémantique. À l’avenir, « mise à jour de fonctionnalités » pourrait ne plus rimer avec « deuxième semestre de l’année »… et donc avec « version H2 ». Ce qui pourrait avoir un impact en matière de planification et de gouvernance.
* Avec le hotpatch, les appareils reçoivent tous les trimestres une mise à jour cumulative de base qui nécessite un redémarrage. Mais les mois intercalaires, ils peuvent installer des correctifs de sécurité sans avoir à redémarrer.
La Commission européenne n’ira pas plus loin dans l’examen du dossier Google-Wiz : elle a validé l’acquisition sans condition.
Bruxelles ne nie pas le risque de remise en cause de la neutralité de l’entreprise israélienne. Mais considère que les clients pourront, le cas échéant, accéder à des solutions alternatives « crédibles » de sécurité cloud.
Balayé également l’effet « cheval de Troie » qu’avait notamment dénoncé le CISPE. Certes, l’opération procurera à Google des données concernant les clouds concurrents. Mais elles ne sont « pas commercialement sensibles », en plus d’être généralement accessibles à d’autres fournisseurs de logiciels de sécurité.
Google franchit là un autre étape importante après le feu vert que les États-Unis lui ont donné en novembre 2025. Reste une enquête en Australie, avec une décision prévue d’ici au 23 février 2026.
« Rappelle-toi DoubleClick… »
Wiz était précieux par son indépendance, déplore un collectif d’organisations de la société civile basées en Allemagne (Rebalance Now), aux Pays-Bas (SOMO), au Royaume-Uni (Article 19, Balanced Economy Project) et aux États-Unis (Open Markets Institute).
La Commission européenne sait que le contrôle d’une couche stratégique peut être mis à profit pour consolider une position sur des marchés annexes, regrettent ces organisations. Partant, il ne fallait pas valider sur la base de parts de marché* et de considérations tarifaires, poursuivent-elles.
Il y a quelques semaines, dans la perspective de l’examen du projet d’acquisition, une des membres de Rebalance Now avait copublié un article intitulé « L’empire caché de Google ». Elle y postulait que Google s’était imposé comme une arme géopolitique pour les USA, par là même susceptibles de préférer en renforcer le pouvoir plutôt que de le contrôler.
L’article pointait les risques d’intégration verticale. Et établissait, à ce sujet, un parallèle avec l’acquisition de DoubleClick – que l’UE avait validée en 2008. Il insistait aussi sur l’ancrage profond de Google dans l’écosystème start-up/innovation (plus de 6000 sociétés acquises ou soutenues dans l’économie numérique et au-delà). Et sur sa croissance supérieure à celle d’Amazon et de Microsoft dans le cloud d’infrastructure.
Fin 2025, Wiz a atteint le milliard de dollars de revenu anuel récurrent. Google compte s’en emparer pour 32 milliards de dollars en cash. Jusqu’ici, la plus chère de ses acquisitions fut celle de Motorola Mobility (12,5 Md$ en 2012).
* Dans ce même esprit, la Commission européenne n’a pas inclus Google dans son enquête visant à déterminer s’il faut soumettre des plates-formes cloudau DMA.
Ne cherchez plus Heineken ni Henkel : ils ne font plus partie des « supporters » d’EU AI Champions.
Cette initiative était née il y a tout juste un an, à l’occasion du Sommet pour l’action sur l’IA. Une soixantaine d’organisations – fournisseurs, utilisateurs et quelques associations représentatives – s’y étaient ralliées, sous la houlette du fonds de capital-risque General Catalyst. Sur le papier, l’objectif principal était simple : contribuer à accélérer le développement et l’adoption de l’intelligence artificielle en Europe. Entre renforcement de l’infrastructure de datacenters, développement des compétences et financement d’entreprises spécialisées, une vingtaine d’investisseurs s’étaient engagés à débloquer un total de 150 milliards d’euros sur 5 ans.
Une première discussion avec un groupe de P-DG et de responsables politiques eut lieu au lendemain du Sommet. EU AI Champions appelait alors, entre autres, à simplifier la réglementation, à commencer par l’AI Act. Sa mobilisation sur le sujet avait culminé au mois juillet, quelques semaines avant l’entrée en vigueur des dispositions du règlement concernant les modèles d’IA à usage général. Par une lettre ouverte, la majorité de ses membres avaient réclamé un moratoire de 2 ans sur l’application des principales obligations du texte. Parmi les signataires figuraient, côté français, Arthur Mensch (Mistral AI), Éléonore Crespo (Pigment), Patrick Pouyanné (TotalEnergies), Guillaume Faury (Airbus), Bernard Charlès (Dassault Systèmes), Alexandre Bompard (Carrefour) et Jean-Laurent Bonnafé (BNP Paribas).
L’UE n’est pas allée jusque-là, mais elle a lâché du lest avec son omnibus numérique.
Une com qui s’est recentrée sur les membres
La liste des « supporters » comprend aujourd’hui 114 logos, rattachés à une centaine d’organisations. Elle n’a globalement pas évolué depuis mars 2025. Heineken et Henkel étaient alors déjà sortis de la boucle.
EU AI Champions a fait de LinkedIn son principal canal de communication au public. Initialement, il y mit régulièrement en avant des organisations qui ne comptaient pas parmi ses membres (Bosch, Langfuse, PortiaAI…). C’est devenu plus rare.
Fin 2025, dans la lignée de ses appels à un allègement réglementaire, le collectif s’était fait l’écho de la position du gouvernement allemand sur l’omnibus numérique. Il s’en était réjoui, y voyant « la première réponse réglementaire sérieuse à ce que l’industrie européenne de l’IA signalait depuis des mois ». Il faut dire que Berlin préconisait notamment de reporter d’un an l’application des règles relatives aux systèmes d’IA « à haut risque ».
Une initiative européenne à dominante franco-allemande
Quoique à dimension européenne, EU AI Champions a des fondations largement franco-allemandes. Sur ses 114 logos, une trentaine sont rattachés à des organisations françaises et une quarantaine, à des organisations allemandes.
France
Allemagne
Airbus
Bilfinger (construction et services)
Airbus Defence and Space
Black Forest Labs (labo d’IA à l’origine des modèles multimodaux FLUX)
Alan
Cambrium (fabricant de produits chimiques)
Autone (optimisation des stocks)
Covestro (fabricant de produits chimiques)
AXA
DeepL
BNP Paribas
Deutsche Bank
Carrefour
Deutsche Telekom
CMA CGM
Edgeless Systems (cybersécurité)
Contentsquare
Flix (traveltech)
Dassault Systèmes
Genesis Cloud (« néocloud »)
Dataiku
German AI Association (fédération des entreprises allemandes de l’IA)
Doctolib
GetYourGuide (réservation de voyages)
Dust (plate-forme IA axée production de contenu)
Giesecke+Devrient (solutions de sécurité)
EDF
Hapag-Lloyd (transport maritime en conteneurs)
Kering
Helsing (technologies de défense)
L’Oréal
Holtzbrinck (maison d’édition)
Lighton
Hexagon (technologies de mesure)
Mirakl
Infineon
Mistral AI
K+S (entreprise minière)
Orange
LangDock (plate-forme IA d’entreprise)
Owkin
LOH Group (industrie manufacturière et services)
Pelico (plate-forme d’orchestration de la production)
Lufthansa
Photoroom
Merantix Capital
Pigment (plate-forme de planification)
Mercedes-Benz
Publicis Groupe
Northern Data Group (« néocloud »)
Renault Group
Orbem (technologies d’IRM)
Sanofi
Otto Group (vente à distance)
Shift (détection de fraude à l’assurance)
Parloa (conception et déploiement d’IA)
TotalEnergies
Personio (logiciels RH)
RobCo (robotique)
SAP
Schwarz (groupe de distribution)
Siemens
Siemens Energy
Skeleton (stockage de l’énergie)
SPREAD (IA industrielle)
Startup Verband (fédération des start-up allemandes)
Südzucker (groupe sucrier)
United Internet (services numériques)
ZF (équipementier automobile)
À ce contingent s’ajoutent deux entreprises dont les fondateurs sont français, mais qui ont leur siège aux États-Unis. Une du secteur aérospatial (Loft Orbital, qui a un pied à Toulouse). L’autre qui fournit des logiciels RH (Deel).
Un pot-pourri de projets annoncé à Berlin
Le dernier « temps fort » d’EU AI Champions s’est déroulé au Sommet sur la souveraineté numérique organisé à Berlin. C’était mi-novembre 2025. Ses membres y ont annoncé un pot-pourri de partenariats, d’accords commerciaux et d’engagements individuels, valorisés dans leur ensemble à 1 Md€.
Projets
Grandes lignes des engagements
Allianz (Allemagne) x Parloa (Allemagne)
Le premier va exploiter les technologies du second pour le service client.
Black Forest Labs (Allemagne) x Mercedes-Benz (Allemagne)
Le groupe automobile va développer des outils IA sur la base des modèles FLUX de la start-up.
Charité Comprehensive Cancer Center (Allemagne) x Gustave Roussy (France) x Owkin (France)
Ce projet associe les deux centres autour de la structuration de données biomédicales et d’un modèle de raisonnement pour la recherche biologique et le développement de médicaments.
Current AI x SPRIND
Current AI est un partenariat global né au Sommet de l’IA, sous l’impulsion de DeepMind, de Salesforce, d’AI Collaborative (initiative d’Omidyar Group), du ministère français de l’Europe et des Affaires étrangères et de trois fondations (Ford, MacArthur, McGovern).
SPRIND est l’agence fédérale allemande pour l’innovation de rupture.
Les deux parties travailleront sur l’application de l’IA aux données de santé.
Deutsche Telekom (Allemagne) x PhysicsX (Angleterre)
L’entreprise anglais va exploiter le cloud du groupe allemand pour déployer sa plate-forme d’ingénierie fondée sur de l’IA physique. Le partenariat court pour 3 ans.
Doctolib (France)
Pas de partenariat, mais un engagement à investir dans le système de santé allemand.
ESTIA (European Sovereign Tech Industry Alliance)
Naissance de cette alliance qui réunit A1, Airbus, Dassault Systèmes, Deutsche Telekom, Evroc, OpenNebula Systems, Orange, OVHcloud, Post Luxembourg, Schwarz Digits, Sopra Steria et TIM.
Helsing (Allemagne) x Mistral AI (France)
Nouvelle phase de collaboration, axée sur la conception de modèles vision-langage pour la défense et la sécurité.
ICEYE (Finlande)
Ce fabricant de micro-satellites a constitué un joint-venture avec le groupe allemand Rheinmetall (armement et équipement automobile).
Legora (Suède)
Cette legaltech a annoncé vouloir doubler son effectif sur un an et établit des points de présence supplémentaires en Europe.
MBDA (France) x Rheinmetall (Allemagne) x SPREAD (Allemagne)
SPREAD contribue au jumeau numérique de défense de Rheinmetall et à l’automatisation de la validation chez MBDA (aéronautique, spatial et armement).
Mercedes-Benz (Allemagne)
Engagement à collaborer avec les start-up et les fournisseurs de modèles d’IA européens.
Multiverse (Angleterre)
Cette edtech s’est engagé à ouvrir un bureau en Allemagne. Elle compte former, sur place, 100 000 personnes à l’IA en 5 ans.
Nextcloud (Allemagne)
L’entreprise s’engage à investir « plus de 250 M€ » dans son programme Sovereignty 2030 pour « faire de l’IA ouverte souveraine une réalité en Europe ».
Otto Group (Allemagne)
Engagement à investi 350 M€ sur 3 ans pour faire évoluer le e-commerce, notamment à renfort de GenAI.
SAP (Allemagne) x Mistral AI (France)
Extension du partenariat à travers lequel SAP fournit les modèles Mistral via sa Business Technology Platform (voir notre article à ce sujet).
Siemens
Engagement à développer un « écosystème européen de données industrielles » qui alimentera des modèles de fondation industriels.
SPRIND
Lancement, en juin 2026, d’un défi « Next Frontier AI » doté de 125 M€. Objectif : faire émerger des labos européens exporant des « approches alternatives » de l’IA, en particulier la frugalité en données et en énergie.
À cette même occasion, EU AI Champions a déclaré que 20 Md€ avaient été engagés sur les 150 Md€ alloués.
Son document référent reste le rapport « Un agenda ambitieux pour l’IA européenne » que General Catalyst avait publié au Sommet de l’IA 2025
L’IA générative n’est plus seulement utilisée pour développer des malwares : elle alimente aussi leur exécution.
En novembre 2025, Google avait proposé une analyse à ce sujet. Il avait donné plusieurs exemples. Dont celui d’un dropper VBScript faisant appel à l’API Gemini pour l’aider à obscurcir son code.
L’analyse est reprise en source dans l’International AI Safety Report 2026. Il s’agit du rapport « officiel » préfigurant le Sommet de l’IA qui se tiendra en Inde du 16 au 20 février. Comme celui de l’an dernier, il donne un instantané de la compréhension scientifique des IA généralistes, sous l’angle de la sûreté. Parmi les experts impliqués, il y a, côté français, Jonathan Collas conseiller industrie et numérique au SGDSN. Et Gaël Varoquaux (Inria), chef de projet pour le consortium Scikit-learn.
Pour cette édition, la définition des « risques émergents » a été restreinte. Il s’agit désormais de ceux « qui naissent à la frontière des capacités de l’IA ». Une manière, nous explique-t-on, de mieux se poser en complément à des initiatives telles que le panel scientifique de l’ONU sur l’IA.
Des IA plus persuasives, mais une influence « non démontrée à l’échelle »
Depuis l’an dernier, les systèmes dit de raisonnement se sont répandus. Les performances en mathématiques, code et sciences en ont particulièrement bénéficié. Côté méthodes d’entraînement, le rapport met en avant la distillation, avec l’exemple de DeepSeek-R1, dont les chaînes de pensée ont nourri DeepSeek-V3.
Des avancées, il y en a aussi eu sur le contenu que génèrent les IA. Constat, dans les grandes lignes : il est devenu plus difficile à détecter. Pour l’illustrer, le rapport cite, entre autres, les observations de chercheurs de l’université de Californie à San Diego sur un test de Turing avec GPT-4o. Dans 77 % des cas, les participants ont considéré comme d’origine humaine un texte en fait créé par le LLM.
Une autre expérience citée émane d’UC Berkeley. Elle a porté sur le clonage de voix. Dans 80 % des cas, les participants ont pris l’IA pour le locuteur d’origine.
Autre étude d’UC Berkeley, autre aspect : les capacités de persuasion dont les IA font preuve. Elles se montrent parfois plus efficaces que l’humain. Les preuves en ce sens « se sont accumulées » ces derniers mois, précise le rapport, qui en dresse un tableau récapitulatif. Centré sur les effets négatifs (propagande politique, notamment), il témoigne cependant aussi d’effets potentiellement positifs, dont la réduction de l’adhésion aux théories du complot.
L’efficacité du contenu IA par rapport au contenu que crée l’humain n’est toutefois pas démontrée à l’échelle, nous explique-t-on. Cela peut s’expliquer par le coût de distribution et par l’effet de balance que suscite, en conditions réelles, l’exposition à des points de vue antagonistes.
Cybersécurité : pas encore d’IA à tout faire, même si la détection de vulnérabilités est acquise
Sur le volet cyber, la difficulté à établir des relations de cause à effet complique l’estimation du rôle de l’IA dans la sévérité et l’échelle des attaques.
Les LLM se révèlent en tout cas performants pour découvrir des vulnérabilités. À ce sujet, on nous mentionne le dernier DARPA AI Cyber Challenge. Lors de cette compétition, un système agentique s’est hissé dans les hauteurs du classement en découvrant 77 % des failles.
Malgré ces progrès, aucune attaque intégralement autonome n’a pour le moment été signalée. Au moins un incident s’en est néanmoins approché. Il a impliqué les services d’Anthropic. Celui-ci s’en est fait l’écho en novembre 2025, estimant que l’attaquant avait automatisé, par ce biais, 80 à 90 % du travail, l’humain n’intervenant que pour des décisions critiques.
De manière générale, le rapport invite à ne pas surestimer le potentiel actuel des IA. Ne serait-ce que parce que la plupart des évaluations n’englobent que des compétences isolées ; pas des attaques de bout en bout. Jusqu’ici, les outils à disposition ont surtout accéléré ou mise à l’échelle des méthodes existantes.
L’évolution de la balance entre usages offensifs et défensifs dépendra des choix sur l’accès aux modèles, le financement de la recherche et les normes de déploiement. Le manque de méthodes standards d’assurance qualité pour les outils IA, par exemple, complique leur adoption dans des secteurs critiques. Alors que dans le même temps, les acteurs de la menace n’ont pas cette contrainte…
Conscience situationnelle ne rime pas avec perte de contrôle
Quant aux dysfonctionnements et aux risques que cela implique, il y a, dans le rapport, à boire et à manger.
Des références à plusieurs études rappellent que des modèles ont démontré des capacités de conscience situationnelle. Autrement dit, une aptitude à détecter l’environnement dans lequel ils évoluent. De là la possibilité de se comporter différemment dans un scénario d’évaluation que dans le monde réel. Ou à dégrader artificiellement ses performances pour éviter des restrictions de déploiement. Ou encore à contourner sciemment des garde-fous pour remplir à tout prix un objectif, tout en le niant par après.
Le risque d’une perte de contrôle sur le long terme demeure cependant faible, faute de capacités à maintenir un fonctionnement autonome sur la durée.
Certes, cette durée s’est allongée dans quelques disciplines, à commencer par le codage. Mais un seul grain de sable peut faire dérailler la machine, comme l’illustre une étude universitaire axée sur la perturbation des systèmes langage-vision à partir d’une pop-up.
Le biais d’automatisation s’amplifie
Concernant l’impact de l’IA sur le marché du travail, le rapport cite des études – au Danemark et aux États-Unis – qui n’ont pas démontré de corrélation forte. Mais il en mentionne aussi plusieurs ayant conclu à un déclin de la demande en profils juniors.
L’amplification du « biais d’automatisation » apparaît plus claire. Déjà prononcé avec les systèmes automatisés « non IA », le phénomène se perpétue au contact des LLM. Le rapport cite deux études qui en témoignent. L’une démontre la tendance des utilisateurs d’outils d’assistance à l’écriture à adopter le point de vue que suggère le modèle. L’autre met en lumière le processus des raccourcis mentaux : sur une tâche d’annotation assistée, les participants ont moins corrigé les suggestion erronées venant d’une IA lorsque cela exigeait un effort supplémentaire.
Si les assistants de codage ne font pas tant gagner en productivité, c’est parce qu’ils cannibalisent la phase pendant laquelle les écarts de spécifications sont le plus souvent détectés.
Certes, le constat émane d’une start-up américaine qui en a fait son fonds de commerce. Mais la réflexion qui y a abouti a son intérêt, notamment par les indicateurs dont elle s’est nourrie.
Trois stats pour poser le problème
La semaine dernière, cette start-up – Bicameral AI – avait publié un « manifeste », intitulé « Les assistants de codage résolvent le mauvais problème ». Elle avait ouvert son propos sur trois statistiques.
La première est sourcée d’Index.dev (plate-forme de recrutement tech). Bicameral AI la présente ainsi : les équipes ayant utilisé l’IA ont réalisé 21 % de tâches en plus, mais le delivery global – au niveau de leur organisation – ne s’est pas amélioré.
Index.dev a en fait lui-même tiré ce chiffre du rapport « The AI Productivity Paradox », que Faros AI (plate-forme de développement) avait publié à l’été 2025. Il apparaît que Bicameral AI en fait un résumé incomplet : le taux de 21 % vaut pour les équipes qui ont un usage important (« extensive ») de l’IA. Et le delivery est jugé spécifiquement sur les métriques DORA.
Deuxième statistique : les développeurs expérimentés ayant utilisé des assistants de codage ont été 19 % plus lents, alors qu’ils croyaient être plus rapides. Difficile de la vérifier : l’article qui en rend compte, publié en janvier 2025, n’est plus accessible. Son auteur : METR, organisation à but non lucratif qui étudie l’impact sociétal de l’IA. Sa fondatrice est une ancienne de DeepMind et d’OpenAI.
Troisième statistique : 48 % du code généré par IA contient des vulnérabilités. Elle est censée provenir d’Apiiro (un spécialiste de l’AppSec) et dater de 2024. Le lien que fournit Bicameral AI pointe toutefois vers un post de septembre 2025 qui ne donne pas directement ce chiffre. Apiiro a tout de même régulièrement donné des estimations proches (« plus de 40 % » en avril 2025, « jusqu’à 50 % » en août 2025…).
Quand l’IA fait perdre le temps qu’elle a fait gagner
Le manifeste se poursuit sur une référence à un fil Reddit avec près d’un millier de commentaires. Un développeur senior y témoigne de l’expérience – positive – de son équipe avec l’IA.
Bicameral AI pointe un des commentaires : le plus difficile n’est pas d’écrire le code, mais de gérer les cas particuliers qui se présentent au cours de l’implémentation. La start-up rebondit sur cet aspect : les assistants de codage sont connus pour ne pas faire remonter les écarts de spécifications, mais au contraire les dissimuler, affirme-t-elle. Par conséquent, on passe davantage de temps sur la revue de code… alors qu’avec l’IA, les managers en attendent davantage.
Dans ce contexte, le taux de développeurs considérant que les managers ne saisissent pas leurs points de douleur progresse nettement : 63 % en 2025, contre 49 % en 2024.
Ces chiffres proviennent du dernier sondage State of DevEx d’Atlassian. Bicameral AI le reprend pour annoncer que les assistants de codage font gagner aux développeurs près de 10 heures par semaine. Mais que l’accroissement des inefficacités sur le reste du cycle de développement anéantit presque ce gain.
Là aussi, la start-up fait un raccourci. Atlassian dit en fait que les outils GenAI en général font gagner au moins 10 heures par semaine à 68 % des développeurs. Mais qu’en même temps, 50 % perdent plus de 10 heures sur des tâches autres que le code*.
Ce fil conducteur mène Bicameral AI à une observation : le décalage entre intention métier et implémentation se crée lors des réunions produit. La start-up en veut pour preuve un sondage qu’elle a mené auprès de développeurs. Dans ce cadre, la majorité (63 %) ont déclaré découvrir des contraintes inattendues après s’être engagés sur l’implémentation.
Les écarts de spécifications, repérés surtout lors de l’implémentation
Les commentaires sur le manifeste et la collecte de réponses supplémentaires au sondage ont entraîné la publication, cette semaine, d’un deuxième article. Bicameral AI y confirme que le taux de développeurs découvrant les contraintes techniques au stade de l’implémentation est resté élevé (50 %).
La start-up mentionne un autre chiffre : 70 % déclarent que ces contraintes doivent être connues au-delà de leur équipe, auprès de populations qui n’interagissent pas régulièrement avec la codebase. Seulement, assure-t-elle, cette communication est difficile. Les pratiques de documentation des décisions n’aident pas : 52 % des répondants à son sondage transmettent les contraintes techniques par copier-coller sur Slack et 25 % les évoquent oralement, sans trace écrite. Plus globalement, 35 % des communications ne produisent aucun artefact persistant.
Bilan : dans la pratique, le conflit entre les specs produit et la réalité de l’engineering ne devient apparent qu’à la phase d’implémentation. Or, dès lors que l’IA phagocyte cette phase, le travail de découverte doit remonter à la phase de planification, sous peine de glisser sinon vers la phase de revue de code… et d’en être d’autant plus compliquée.
Le salut dans les prompts ? Le paradoxe de l’œuf et de la poule
Bicameral part ici du principe que les assistants de codage sont « accommodants » : ils peuvent demander des clarifications, mais ne suggèrent généralement pas d’explorer d’autres options.
« Il suffit de demander à l’IA de te challenger », a-t-on rétorqué, en substance, à la start-up. Elle y répond sous l’angle de l’œuf et de la poule : pour prompter correctement, il faut connaître au préalable la manière dont les contraintes techniques et produit peuvent entrer en conflit. Une connaissance qui, en l’état, ne fait donc essentiellement surface qu’à la phase d’implémentation…
Le traitement du problème en amont pourrait, contre-intuitivement au premier abord, s’appuyer sur des LLM. Lesquels examineraient comment une spéfication donnée pourrait impacter des structures de code existantes. Sur cette base, on pourrait imaginer un affichage en tant réel du contexte d’ingénierie pendant une réunion. Option qu’ont d’ailleurs suggérée certains participants au sondage.
* En 2024, IDC expliquait que le codage ne représentait que 16 % de leur temps de travail des développeurs. Contre 14 % pour l’écriture de spécifications et de tests, 13 % pour la sécurité, 12 % pour la surveillance des applications, etc.
Les chercheurs en sécurité vont commencer à scanner les appliances connectées à Internet. Cela compliquera la détection des « vraies » tentatives d’exploitation.
L’avertissement est signé Ivanti. Il s’adresse aux utilisateurs de la solution EPMM (Endpoint Manager Mobile ; ex-MobileIron Core). En toile de fond, la découverte de deux vulnérabilités critiques. L’une (CVE-2026-1281) affecte la fonctionnalité de distribution interne d’applications. L’autre (CVE-2026-1340), la configuration du transfert de fichiers Android. Elles ont le même score de criticité (9,8)… et la même conséquence potentielle : l’exécution de code à distance sans authentification.
Ivanti en a révélé l’existence le 29 janvier, accompagnant son bulletin d’un correctif. L’éditeur déclarait alors qu’un « nombre très limité de clients » avaient été touchés. Peu après, un PoC était apparu.
« Considérer tout système comme compromis »
L’ANSSI néerlandaise (NCSC-NL) suit le dossier de près. Au fil des jours, elle est devenue plus alarmiste.
Le 2 février, l’agence avait noté que la vulnérabilité CVE-2026-1281 était activement exploitée. Elle recommandait aux utilisateurs d’EPMM de la joindre, le correctif n’étant pas suffisant en cas de compromission.
Le surlendemain, le NCSC-NL admettait que l’exploitation était « bien plus répandue qu’on ne le pensait ». Elle appelait tout simplement à considérer tout système comme étant compromis. Et ainsi à modifier les mots de passe de tous les comptes, à renouveler les clés privées et à surveiller le trafic interne.
Dans son dernier update, du 9 février, elle explique avoir identifié plusieurs organisations exploitant la vulnérabilité en question. Elle permet d’exfiltrer la base de données MIFS (MobileIron File Service). Et de récupérer ainsi des informations sur les appareils enregistrés. Notamment IMEI, numéros de téléphone et détails sur la SIM. Mais aussi utilisateurs LDAP et jetons d’accès et authentifiants Office 365.
Restaurer les sauvegardes… ou pas
Entre-temps, le NCSC-NL a contribué au développement d’un script de détection des intrusions. Ivanti l’a publié le 6 février, en parallèle d’IoC et de mesures de défense.
Sur les instances touchées avant la divulgation des vulnérabilités, on a découvert des fichiers malveillants dans le dossier racine, ainsi que dans /tmp et /var/tmp. Souvent d’un ou deux caractères, sans extension, parfois compressés avec 7z/LMZA2. Le favicon a par ailleurs été ciblé pour injecter un webshell.
Après la divulgation, les techniques se sont diversifiées, à tel point qu’il est difficile de les catégoriser en une liste d’IoC. Ivanti a toutefois observé un pattern consistant à créer des fichiers semblant être des pages d’erreur HTTP – par exemple, 401.jsp – pour héberger des webshells.
En date du 6 février, l’éditeur recommandait deux options en cas de compromission. Soit restaurer depuis des backups ou des instantanés de VM, soit construire un nouvel environnement et y migrer les données. Il conseillait aussi de changement le mot de passe de tout compte local et de remplacer le certificat public utilisé pour l’EPMM.
Du côté du NCSC-NL, on déconseille l’option restauration, au motif que les sauvegardes peuvent être compromises. Surtout si le script de détection produit des résultats…
La Commission européenne, victime probable
Le correctif n’entraîne pas d’indisponibilité, mais il ne survit pas à un saut de version. Ivanti promet de l’intégrer dans la prochaine release d’EPMM, prévue « au cours du premier trimestre 2026 ».
La Commission européenne n’a pas affirmé faire partie des victimes. Mais le 6 février, elle a déploré la compromission de « l’infrastructure centrale » utilisée pour gérer ses terminaux mobiles. Une attaque serait survenue le 30 janvier. Circonscrite « en 9 heures », elle pourrait avoir donné accès à des noms et à des numéros de téléphone.
En septembre 2025, l’entreprise américaine avait officialisé son soutien financier à ce framework web orienté contenu statique (« zéro JavaScript par défaut »). Mi-janvier, elle a annoncé le prendre sous son aile, en absorbant la société qui l’a développé.
Astro restera sous licence MIT et continuera à accepter les contributions, avec une roadmap publique et une gouvernance ouverte, promet Cloudflare, qui utilise lui-même le framework pour son blog, sa doc développeurs et diverses landing pages.
Cette manœuvre lui donne l’occasion d’accroître l’usage de ses services par des plates-formes fondées sur Astro. Notamment Webflow Cloud et Wix Vibe, déjà hébergées sur son infrastructure.
Human Native, une brique de plus pour monétiser l’IA
Également mi-janvier, Cloudflare a annoncé avoir mis la main sur Human Native. Cette start-up anglaise née en 2024 a constitué une marketplace qui rapproche producteurs de contenus et développeurs d’IA. Elle source en l’occurrence des contenus qualitatifs et les structure en datasets d’entraînement.
Human Native contribuera à la transformation des outils de contrôle d’accès de Cloudflare en un marché unifié de contenus monétisables. En toile de fond, l’initiative dite « Pay per crawl ». Qui s’est déjà traduite, entre autres, par des investissements dans le protocole de paiement x402 et par le lancement de la brique AI Index. Cette dernière expose, sur les domaines Cloudflare, des ressources (API, serveur MCP, fichier LLMs.txt) auxquelles les robots IA peuvent s’abonner.
Replicate, un complément pour l’inférence
En novembre 2025, Cloudflare avait acheté Replicate. Cette start-up américaine née en 2019 avait d’abord développé Cog, un format ouvert pour conteneuriser des modèles d’IA. Elle y avait ensuite greffé une plate-forme d’inférence pour exécuter ces modèles en tant qu’API.
Conséquence de cette acquisition, le catalogue de Replicate a basculé sur Cloudflare Workers AI. Tout en y apportant des possibilités de fine-tuning et d’exécution de modèles personnalisés.
Outerbase, un coup de pouce pour exploiter les bases de données
Autre acquisition réalisée en 2025 : Outerbase. C’était en avril 2025. Il s’agit aussi d’une start-up américaine (née en 2022). Elle a conçu divers outils destinés à simplifier l’exploitation des bases de données SQL par les développeurs.
Le rapprochement entre les deux sociétés avait démarré en 2024, lorsque Outerbase avait introduit la possibilité d’importer des bases de données D1. Depuis, des jonctions se sont faites avec d’autres composantes de l’offre de Cloudflare. À commencer par Durable Objects, sur lequel Outerbase a d’ailleurs construit sa propre base de données compatible SQLite.
L’offre SaaS d’Outerbase a fermé, Cloudflare en intégrant le contenu dans son dashboard et au-delà (sécurité au niveau des lignes et hooks pré-requête, notamment). La version open source reste accessible, mais il n’y a plus d’activité sur le repo.
Kivera, une couche de protection cloud pour le SASE…
L’acquisition précédente remonte à octobre 2024. Elle a porté sur Kivera. Cette entreprise australienne née en 2019 donnait dans la protection du cloud. Ses technologies ont enrichi l’offre SASE Cloudflare One avec de la détection inline et de la gestion des mouvements de données.
… avec BastionZero pour l’accès aux infrastructures
En mai 2024, Cloudflare avait bouclé une autre acquisition dans le domaine de la sécurité informatique : BastionZero.
L’offre de cette entreprise américaine née en 2017 est devenue Cloudflare Access for Infrastructure. Elle a permis d’étendre la couverture du SASE aux ressources d’infrastructure, en plus des réseaux et des applications. Tout en apportant du RDP clientless et une gestion DevOps de la sécurisation des connexions SSH.
Le temps que l’intégration soit finalisée, l’offre BastionZero « legacy » reste maintenue pour les clients existants.
Baselime, pourm mieux intégrer OpenTelemetry
En avril 2024, Baselime tombait dans le giron de Cloudflare. Cette start-up anglaise née en 2021 s’était spécialisée dans l’observabilité des environnements serverless, autour d’OpenTelemetry. Elle fut soutenue par AWS, chez qui elle avait d’ailleurs déployé son produit.
Ce dernier est aujourd’hui hébergé chez Cloudflare. Il a permis d’intégrer OpenTelemetry dans le runtime JS de Cloudflare Workers.
Des applications collaboratives via PartyKit
La première acquisition annoncée sous l’ère ChatGPT fut celle de PartyKit, également en avril 2024. La start-up anglaise, née en 2023, avait développé une plate-forme open source de déploiement d’applications collaboratives. Il s’agissait, à l’origine, d’explorer les capacités de l’offre Durable Objects en matière de conception d’expérience interactives. Et de la rendre plus accessible aux développeurs en l’exposant via des briques familières (React, Yjs…).
PartyKit reste gratuit pour un usage individuel. Il l’est aussi pour un usage commercial… si on déploie sur un compte Cloudflare.
Avec un tel intitulé, le premier ticket ouvert dans le dépôt GitHub de CCC n’est pas passé inaperçu. Il faut dire que le projet lui-même a particulièrement attiré l’attention. Et pour cause : Claude est parvenu à créer son propre compilateur C.
Un ingénieur d’Anthropic est à l’origine de la démarche. Il lui aura fallu deux semaines, environ 2000 sessions Claude Code et près de 20 000 $ de coûts d’API pour la mener à bien, explique-t-il. Au final, il y a environ 100 000 lignes de code Rust… et la capacité à compiler Linux 6.9 sur x86-64, i686, AArch64 et RISC-V 64, sans dépendances.
GCC comme oracle et un lieur qui fait encore défaut
La compilation se fait sans erreurs (ce qui est notable), mais l’assemblage et l’édition de liens – composantes cruciales d’un compilateur – ne sont pas stables. Par ailleurs, les niveaux d’optimisation doivent encore être implémentés.
Si la supervision humaine fut minimale (pas de consignes de débogage, notamment, ni de fourniture de feed-back sur la qualité du code), Claude n’a pas été tout à fait autonome. Outre les tests qui ont permis de le garder sur les rails au fil du projet, un algorithme de synchronisation a évité que des agents tentent de résoudre le même problème en même temps.
CCC (Claude’s C Compiler) a effectivement exploité des instances parallèles de Claude Opus 4.6. L’approche a favorisé la spécialisation des tâches : un agent pour fusionner le code en double, un deuxième pour écrire la doc, un troisième pour analyser la conception du projet point de vue d’un développeur Rust, etc.
L’algo en question pose des verrous sur des tâches en écrivant des fichiers texte dans un dossier current_tasks/. Les conflits de merge sont fréquents, mais Claude sait les gérer, nous affirme-t-on. À chaque session, tous les agents ont leur propre conteneur Docker avec une copie locale du repo Git.
Ce système a fonctionné pour compiler de « petits » projets open source (SQLite, QuickJS, mbedTLS, libpng…), chaque agent pouvant se concentrer sur l’un d’entre eux. Avec Linux, ils ont fini par converger sur la même tâche. Et donc à se « marcher sur les pieds ». Le compilateur GCC a alors été utilisé comme oracle. Le tout sans orchestrateur : chaque agent décide de ses actions, en documentant ses éventuels échecs.
Une compilation moins efficace…
Claude Opus 4.5 fut le premier LLM d’Anthropic capable de produire un compilateur réussissant les suites de tests référentes, fait remarquer l’ingénieur. L’apport de Claude Opus 4.6 est le passage à l’échelle, sur un projet de l’ampleur du noyau Linux.
Le code généré n’est cependant pas très efficace, reconnaît-il. Même avec toutes les optimisations possibles, on n’atteint pas ce que GCC délivre sans.
Un comparatif tiers le confirme. Son auteur a analysé, d’une part, la compilation de Linux 6.9 (x86-64). De l’autre, celle de SQLite 3.46.0. Son setup : deux VM Debian sous Proxmox, chacune sur son nœud physique (6 vCPU, 16 Go de RAM, 100 Go NVMe).
Avec GCC 14.2.0, la compilation de SQLite prend 64,6 s. Il en faut 87 avec CCC.
Sans optimisation, GCC produit un binaire de 1,55 Mo. Contre 4,27 Mo pour CCC. Le premier consomme au maximum 272 Mo de RAM ; le second, 1616 Mo.
… et surtout une exécution beaucoup plus lente
L’écart est beaucoup plus net sur le temps d’exécution : 10,3 secondes avec GCC sans optimisation… contre 2 h 6 min avec CCC. Cette lenteur n’est pas uniforme. Elle est moindre sur des requêtes somples comme la suppression de tables ou l’ajout de lignes. Elle est au contraire bien plus importante avec les opérations qui impliquent des boucles imbriquées.
Cette différence s’explique entre autres par une mauvaise allocation des registres CPU (CCC éparpille les variables sur la pile). La taille du code généré joue aussi : elle favorise les défauts de cache d’instructions (le CPU ne peut pas tout conserver en L1/L2). De surcroît, la production de pointeurs corrompus et l’absence de génération de tables de symboles rend le profilage et le débogage impossibles.
Pour ce qui est du kernel, CCC compile tous les fichiers sources sans erreur, mais échoue au niveau du lieur. Il génère, en particulier, des entrées de relocalisation incorrectes pour les jump labels.
Entre Microsoft Teams et Google Meet, il n’y a plus nécessairement besoin d’une passerelle tierce.
Jusqu’ici, pour participer à des réunions Teams sur du matériel Meet sous ChromeOS ou Android, Google recommandait d’utiliser Pexip Connect. L’intégration était disponible depuis octobre 2025, sur toutes les éditions payantes de Google Workspace, ainsi que sur G Suite Basic et Business.
Pexip Connect fonctionne aussi dans l’autre sens, en permettant aux appareils certifiés Teams Rooms – sous Windows ; pas encore sous Android – de rejoindre des réunions Meet. À condition de disposer d’une licence Teams Rooms Basic ou Pro.
Le matériel Android n’est pas concerné
La connexion peut désormais se faire directement… dans une certaine mesure.
Côté matériel Meet, seul celui sous ChromeOS est pris en charge. C’est-à-dire, essentiellement, des kits Asus et Lenovo.
Côté Teams Rooms, on en reste au catalogue Windows. Celui-ci réunit des configurations basées sur des PC ASUS, Dell, HP, Lenovo et Intel NUC. On y trouve aussi des équipements de marques telles que Crestron, Logitech et Yealink, en plus des Surface Hub 3 et 2S.
Pour exploiter cette interopérabilité, il faut toujours disposer à la fois d’un forfait Google Workspace payant et d’une licence Teams Rooms.
Sous-titrage, chat, double écran… Un Teams « diminué » sur les appareils Meet
Côté Google Workspace, le déploiement sur l’interface admin a débuté le 3 février. Pour les utilisateurs finaux, ce sera à compter du 16 février. L’interopérabilité sera active par défaut. On pourra la désactiver au niveau des unités organisationnelles.
En l’état, certaines fonctionnalités de Teams ne sont pas accessibles sur le matériel Meet. Notamment le double écran, le sous-titrage et l’envoi de messages de chat pendant une réunion – autant d’éléments pas non plus disponibles avec les intégrations Webex et Zoom.
Pour planifier une réunion, on crée un événement dans Google Agenda avec les infos nécessaires, puis on ajoute une salle utilisant du matériel Meet. Pour en rejoindre une, c’est soit via la liste enregistrée sur l’appareil, soit via l’identifiant.
De la configuration à faire sur Exchange
Côté Teams Rooms, l’intégration est effective. Pour rejoindre une réunion, on accède à l’événement dans Google Agenda et on sélectionne « Autres façons de participer > Systèmes tiers ».
Deux méthodes de connexion sont proposées : protocole SIP (via l’interface CVI) et WebRTC (Direct Guest Join). La deuxième option n’exige pas de licence supplémentaire, mais est plus limitée (pas de présentation de contenu par HDMI, vidéo limitée à 720p…). L’une et l’autre ne permettent pas, entre autres, d’envoyer des réactions, de visualiser des transcriptions et d’interagir sur le tableau blanc.
Dans tous les cas, il faut autoriser les appareils Teams Rooms à participer à des réunions tierces. Soit en local, soit dans le portail de gestion Teams Pro, soit via le fichier SkypeSettings.xml.
Exchange doit par ailleurs être autorisé à traiter les réunions tierces et les invitations externes. Il peut aussi éventuellement falloir ajouter une exception aux outils de filtrage d’URL pour éviter la réécriture des URL.
De l’IA agentique naît le besoin de nouvelles architectures OLTP… comme le lakebase.
Fin janvier, Databricks publiait un rapport « State of AI Agents » mettant généreusement en avant ce postulat. Quelques jours plus tard, il annoncerait la disponibilité générale de sa propre offre lakebase*.
Au-delà de cette congruence, le rapport comprend quelques éléments chiffrés fondés sur la télémétrie de « plus de 20 000 clients ».
L’approche multi-LLM se répand
La proportion de clients utilisant au moins 3 LLM a tendance à s’accroître.
Mai-juillet 2025
Août-octobre
1 modèle
39 %
22 %
2 modèles
25 %
19 %
3+ modèles
36 %
59 %
Dans tous les secteurs économiques pris en considération, on a dépassé, sur la période d’août à octobre, les 50 % de clients exploitant au moins 3 LLM. Le taux le plus élevé – autour de 65 % – est dans le retail. Le secteur des utilities dépasse les 60 %, comme la santé, l’industrie et les services financiers.
Peu de batch, beaucoup de temps réel
En mai et octobre, 96 % des requêtes ont été traitées en temps réel, le reste l’étant par lots. Le secteur des technologies présente l’écart le plus important (32 requêtes real-time pour 1 batch). Suit la santé (13/1), probablement en reflet des situations critiques que gèrent les organisations de ce secteur.
La création des bases de données, largement « agentisée »
À partir de la télémétrie de Neon, base Postgre qui constitue le cœur de sa lakebase, Databricks déclare que la majorité des bases de données sont désormais créées par des agents IA. En l’occurrence, 80 % sur le mois d’octobre 2025, contre 27 % un an plus tôt. La création des branches (clonage) a suivi la même trajectoire (de 18 à 97 %).
Un usage « pragmatique » de l’IA
La veille de marché ressort comme le principal usage de l’IA dans l’écosystème Databricks sur l’échantillon concerné. Suivent la maintenance prédictive, le tri des demandes au support client, la customer advocacy et le traitement des réclamations. Le résumé des interactions client et des notes critiques apparaît en bas de la liste, comme l’analyse de sentiment.
Au global, 40 % des cas d’usages GenAI que recense Databricks automatisent des tâches routinières liées à l’expérience client.
Agora à l’état de concept ; agent.json en brouillon ; ANP en cours de finalisation ; MCP devenu « standard de fait ».
Ces quatre technologies en étaient à ces stades respectifs lorsque l’université Jiao-tong de Shanghai les a intégrées dans sa taxonomie des protocoles agentiques. C’était en mai 2025.
La taxonomie distinguait les protocoles orientés contexte et ceux axés sur la communication entre agents. Elle introduisait un deuxième niveau de segmentation, entre protocoles généralistes et protocoles spécialisés (ces derniers se divisant, sur la partie communication, entre humain-agent, robot-agent et système-agent).
Pas de suite favorable pour agents.json
Depuis, agents.json n’a pas connu de nouvelle version – la dernière date de février 2025. Le projet semble abandonné (démos non fonctionnelles, documentation en 404, invitation Discord expirée, chaîne YouTube non alimentée…). Wildcard, la start-up américaine instigatrice du projet, existe toujours. Elle s’est spécialisée dans le GEO (Generative Engine Optimization).
Le protocole étend la spécification OpenAPI pour permettre la définition de contrats guidant les LLM dans l’utilisation des API. Ces contrats contiennent un ou plusieurs appels décrivant un résultat. Une manière de conserver l’aspect non déterministe dans la réalisation des tâches tout en cadrant l’exploitation des outils.
L’approche est stateless. Les fichiers agents.json, préférentiellement hébergés dans un dossier /.well-known, sont exposés aux LLM en tant qu’outils via un SDK spécifique.
A2A, confié à la Fondation Linux
Google avait annoncé A2A (Agent-to-Agent) en avril 2025. Quelques semaines après la publication de la taxonomie, le confierait le protocole à la Fondation Linux.
A2A permet la communication entre des agents reposant sur des frameworks différents. Ils peuvent découvrir mutuellement leurs capacités (par le biais de cartes), négocier leurs modalités d’interaction et opérer sans exposer leur état interne, leur mémoire ou leurs outils. La communication est en JSON-RPC sur HTTP(S).
Un groupe de travail W3C autour d’ANP
ANP (AgentNetworkProtocol) était passé en v1 peu après la publication de la taxonomie. Depuis, la communauté qui en est à l’origine a pris la tête d’un groupe de travail AI Agent Protocol au sein du W3C. Avec, entre autres contributeurs, Google, Huawei et Microsoft.
Un brouillon de spécification a été publié fin janvier. On y retrouve les trois principaux modules constitutifs d’ANP : l’identité (sur la base du standard DID), ainsi que la description et la découverte des agents. La négociation de protocoles de communication entre agents est dynamique, sur la base de langage naturel. La v1 a introduit une proposition de framework transactionnel P2P et une option human in the loop.
AITP demeure en brouillon
Depuis la publication de la taxonomie, AITP (Agent Interaction and Transaction Protocol) est resté en brouillon. Ce protocole orienté Web3 est né sous l’impulsion de la NEAR Foundation, à l’origine d’une blockchain de couche 1. Il doit permettre aux agents d’échanger tous types de données structurées (éléments d’UI, formulaires, demandes de paiement…). Aux dernières nouvelles, des connexions sont établies avec le wallet NEAR. Les wallets EVM et SOL sont sur la roadmap.
ACP, devenu brique d’AGNTCY…
LangChain est l’instigateur d’ACP (Agent Connect Protocol). La spec englobe découverte, communication de groupe, identité et observabilité. Elle fait aujourd’hui partie de l’initiative AGNTCY, que Cisco porte pour créer « une stack pour l’Internet des agents » – et qui sous l’égide de la Fondation Linux depuis juillet 2025.
… comme AComp, fusionné avec A2A
AGNTCY exploite aussi AComp (Agent Communication Protocol). Celui-ci est également sous l’aile de la Fondation Linux, où il a fusionné avec A2A. Il est soutenu entre autres par AWS, Microsoft, Salesforce, SAP et Snowflake. On le doit à IBM, qui en a créé l’implémentation de référence en l’objet du framework BeeAI.
Par rapport à ACP, plutôt que d’imposer immédiatement des spécifications strictes, AComp se concentre sur le volet fonctionnel. Il est dit suffisamment simple pour ne pas nécessiter de SDK (des outils HTTP standards suffisent).
LMOS vise toujours la standardisation W3C
LMOS (Language Model Operating System) émane de la Fondation Eclipse. Il implémente l’architecture WoT (Web of Things) du W3C, à travers les couches identité, transport et application, autour du format JSON-LD.
Le projet a un opérateur Kubernetes et un routeur, intégrés en un runtime. Ainsi qu’un langage basé sur Kotlin pour développer des agents. Il n’est pas encore entré dans la procédure de standardisation W3C.
Agent Protocol a changé de mains
La dernière version (v1) d’Agent Protocol remonte à 2024. Cette année-là, la fondation qui avait créé ce protocole l’a transmis à une start-up qui développe un assistant IA pour smartphones.
Construit sur OpenAPI, Agent Protocol définit une interface unifiée pour la gestion du cycle de vie. Il introduit des abstraction comme les runs (exécution de tâches), les threads (gestion des interactions à plusieurs tours) et les stores (mémoire à long terme).
Des protocoles d’origine académique restés des concepts
L’université Jiao-tong avait inclus, dans sa taxonomie, plusieurs protocoles issus du monde académique qui étaient alors à l’état de concept. Aucun ne semble aujourd’hui avoir de grande implémentation référente.
Parmi eux, Agora, made in université d’Oxford. Sa dernière version remonte à janvier 2025. Il permet aux agents de créer des protocoles ad hoc sur la base de documentation YAML.
Avec PXP (Predict and eXplain Protocol), issu d’un institut technologique indien, on est dans la communication humain-agent. Le protocole implique un système de tableau blanc et un planificateur qui assure l’alternance des tours de discussion.
Dans le même domaine, il y a LOKA (Layered Orchestration for Knowledgeful Agents), de Carnegie Mellon. Se nourrissant de standards comme DID et VC (Verified Credentials), il met en œuvre un système de consensus décentralisé fondé sur des règles d’éthique partagées.
CrowdES est un protocole de type robot-agent né à l’université de science et de technologie de Gwangju (Corée du Sud). Conçu pour gérer des comportements de groupe, il inclut un « émetteur » et un « simulateur ». Le premier utilise des modèles de diffusion pour assigner des attributs individuels (types d’agents, vitesse de déplacement…) sur la base d’informations spatiales extraites d’images en entrée. Le second génère des trajectoires et des interactions grâce à un mécanisme de changement d’état basé sur des chaînes de Markov.
L’université de Liverpool a emmené les travaux sur la famille de protocoles dit SPP (Spatial Population Protocols). Ils permettent à des robots de s’accorder sur un système de coordonnées, même lorsque celui-ci est arbitraire et que leurs positions de départ le sont éventuellement aussi. Chaque robot peut mémoriser une ou plusieurs coordonnées et analyser la distance vis-à-vis d’autres robots lors des interactions. Le calcul de cette distance peut reposer sur un « leader » pour ancrer le système de coordonnées.
De la RAM aux CPU, une pénurie peut en cacher une autre.
Sur la RAM, la situation est avérée. Elle découle essentiellement de la demande en GPU, dans le cadre de la « course à l’IA » que se livrent les hyperscalers.
Concernant les CPU, il y a des signaux du côté d’Intel. Depuis quelques mois, l’entreprise emploie, dans sa communication publique, le mot shortage, qu’on peut traduire par « manque »… ou « pénurie ». Elle ne le projette pas tant sur le marché dans son ensemble que sur sa propre incapacité à suivre la demande.
Davantage de cœurs… ou de serveurs ?
Un premier avertissement était tombé en octobre 2025 : la « pénurie » de CPU allait atteindre un pic au premier trimestre 2026. À la fois sur l’informatique cliente et le datacenter. La demande a été plus importante que prévu sur les anciens procédés de gravure (Intel 10 et Intel 7), nous expliquait-on alors. D’une part pour les Xeon. De l’autre pour les Core, dans le contexte de la transition vers Windows 11.
À trois mois d’intervalle, le discours n’a globalement pas changé. La demande en Xeon reste insatisfaite à l’heure où l’activité « datacenter et IA » connaît une croissance séquentielle sans précédent depuis plus d’une décennie. >>Intel affirme qu’il y a encore six mois, tout laissait anticiper une hausse du nombre de cœurs par serveur ; pas du nombre de serveurs tout court. Or, après communication avec des clients, c’est la deuxième option qui se dessine, potentiellement pour plusieurs années.
Le yield (taux de production de CPU « utilisables » par rapport au nombre de wafers) renforce la difficulté à délivrer. Intel explique en tout cas que cet indicateur est en dessous de ses attentes. Au final, il ne cache pas son intention de prioriser les serveurs aux PC. Pour ces derniers, la production se concentrerait sur le milieu et le haut de gamme, tout en sourçant davantage de wafers en externe. Il est également question de livrer en priorité les clients qui sont aussi parvenus à obtenir de la mémoire.
La perspective de l’IA sur CPU
Au sujet du marché des serveurs, Omdia va dans le même sens qu’Intel. Le cabinet d’études estime que 15,9 millions d’unités seront livrées en 2026, contre 14,4 millions en 2025.
Les fabricants de processeurs ont, ajoute-t-il, d’autant plus de mal à suivre qu’ils doivent alterner entre les processus de gravure. Quant à TSMC, il a possiblement donné la priorité aux puces IA par rapport aux CPU. Bilan : ces derniers pourraient, selon une estimation jugée « prudente », voir leurs prix augmenter de 11 à 15 % en 2026.
L’IA elle-même tend à se déporter sur les CPU, en conséquence de la rareté et de la cherté des GPU. DeepSeek a récemment ouvert des perspectives dans ce domaine avec son architecture Engram. Censée apporter un « deuxième cerveau » aux LLM, elle s’appuie sur une table de connaissances stockée en mémoire CPU, sans dégradation majeure par rapport à de l’inférence GPU pure.
Intel communique aussi à ce propos. Il est, par exemple, revenu sur l’exploitation de puces Xeon par une agence gouvernementale américaine pour faire tourner des SLM (Mistral 7B, Mixtral 8x7B et Llama 3.1-8B) avec OpenVINO.
AMD, qui maintient à son catalogue des CPU d’anciennes générations, ne parle pas officiellement de pénurie. Par rapport à Intel, il a potentiellement plus de marge pour réallouer si nécessaire sa capacité de production, avec les cartes graphiques Radeon comme variable d’ajustement.
« Tu es un ingénieur très expérimenté qui effectue une revue de code. Ta tâche est de comprendre si les changements proposés suivent les instructions. »
Ainsi débute un des prompts système que Spotify a définis dans le cadre de son architecture de codage agentique.
L’entreprise avait amorcé sa réflexion à ce sujet en février 2025. Son système Fleet Management automatisait alors déjà une grande partie de la maintenance logicielle. À partir d’extraits de code, il exécutait les transformations à l’échelle dans un environnement GKE et ouvrait les PR sur les dépôts cibles.
Ce mécanisme facilitait des opérations telles que la mise à niveau des dépendances dans les fichiers de build, la mise à jour des fichiers de configuration et le refactoring simple (par exemple, supprimer ou remplacer un appel de méthode). La moitié des PR poussés depuis mi-2024 l’avaient été par ce biais.
Fleet Management était moins adapté aux changements complexes nécessitant de manipuler l’arbre de la syntaxe abstraite d’un programme ou d’utiliser des expressions régulières. Illustration avec le gestionnaire de dépendances Maven. Autant sa fonction principale est simple (identifier les fichiers pom.xml et mettre à niveau les dépendances Java), autant les cas particuliers avaient fait grossir à plus de 20 000 lignes le script de transformation associé. Plus globalement, peu d’équipes avaient l’expertise et le temps adéquats.
Un premier focus sur la migration de code
La mise en place de l’approche agentique s’est d’abord portée sur la déclaration du code de transformation. Objectif : permettre la définition et l’exécution de changements en langage naturel, en remplacement des scripts de migration déterministes.
Plutôt que de choisir un agent sur étagère, Spofity a conçu un CLI. Celui-ci peut déléguer l’exécution d’un prompt à divers modèles d’IA. Mais aussi exécuter des tâches de formatage et de linting en utilisant MCP, évaluer une diff par LLM as a judge, uploader des logs vers GCP et capturer des traces dans MLflow.
Début novembre 2025, quelque 1500 PR fusionnés étaient passés par ce système. Spotify s’attaquait alors à des opérations telles que :
Modernisation de langage (par exemple, remplacer des value types par des records en Java)
Upgrades sans breaking changes (migration de pipelines data vers la dernière version de Scio)
Migration entre composants UI (passage vers le nouveau système front-end de Backstage)
Changements de configuration (mise à jour de paramètres dans des fichiers JSON et YAML en respectant schémas et formats)
Spotify disait alors avoir gagné, sur ces tâches de migration, 60 à 90 % de temps par rapport à l’écriture du code à la main. Il se projetait sur l’amélioration du ROI avec la perspective de l’élargissement à d’autres codebases.
Slack, Jira et Cie intégrés dans une architecture agentique
En complément à cette démarche sur la migration, les travaux se sont orientés sur un système plus généraliste, capable de remplir des tâches ad hoc. On en est arrivé à une architecture multiagent qui planifie, génère et révise des PR.
Au premier niveau, il y a des agents associés à différentes applications (Slack, Jira, GitHub Enterprise…). L’interaction avec eux, éventuellement additionnée de contexte récupéré sur des serveurs MCP, produit un prompt. Ce dernier part vers l’agent de codage, lui aussi exposé par MCP. Ses actions sont vérifiées par un autre groupe d’agents.
Entre autres usages « satisfaisants », Spotify mentionne la capture de décisions d’architecture depuis des threads Slack et la possibilité, pour les product managers, de proposer des changements simples sans avoir à cloner de dépôts sur leur machine.
Des agents open source à Claude Code
Les premiers essais se sont faits avec des agents open source comme Goose et Aider. Appliqués à la migration, ils n’ont cependant pas produit de PR fiables. Spotify a donc construit sa propre boucle agentique superposée aux API de LLM. Principe : l’utilisateur fournit un prompt et une liste des fichiers que l’agent édite en incorporant à chaque étape le feed-back du système de build. La tâche s’achève quand elle réussit les tests ou qu’elle dépasse certaines limites (10 tours par session ; 3 retries).
Cette approche a convenu à de « petits » changements : éditer une ligne de code, modifier un manifeste, remplacer un flag… Mais l’agent restait difficile à utiliser. Le chargement des fichiers dans la fenêtre de contexte reposait sur une commande git-grep. En fonction de pattern de recherche, on pouvait saturer la fenêtre ou au contraire ne pas fournir assez de contexte. L’agent avait de plus du mal avant l’édition de multiples fichiers. Souvent, la boucle atteignait la limite de tours. Et lorsque la fenêtre de contexte se remplissait, l’agent finissait par oublier la tâche.
Dans ce contexte, Spotify a basculé vers Claude Code. Lequel a permis des « prompts plus naturels » tout en apportant sa capacité native de gestion de to-do lists et de création de sous-agents. Il couvre désormais la majorité des PR fusionnés en production.
Savoir interdire… et ne pas tout faire à la fois
L’agent initial fonctionnait au mieux avec des prompts stricts structurés étape par étape. Claude Code se débrouille mieux avec des prompts qui décrivent l’état final et laissent de la latitude sur le chemin à suivre.
Spotify constate qu’il peut être utile de dire clairement à l’agent quand il ne doit pas agir. Cela évite des tâches impossibles à réaliser, notamment au cas où on réutilise des prompts entre repos qui n’utilisent pas forcément les mêmes versions de langages.
Fournir des exemples de code influence par ailleurs beaucoup le résultat. Idéalement, on définira l’état souhaité sous forme de tests, l’agent ayant besoin d’un objectif vérifiable pour pouvoir itérer. On s’assurera de surcroît de ne demander qu’un changement à la fois pour éviter l’épuisement de la fenêtre de contexte. Et on n’hésitera pas à demander à l’agent un retour d’expérience à la fin de la session.
Une ouverture limitée via MCP
Spotify a privilégié les longs prompts statiques, sur lesquels les modèles raisonnement plus simplement.
Une approche alternative consiste à commencer avec un prompt plus court, mais à donner à l’agent l’accès à des outils MCP. Le contexte qu’il peut ainsi récupérer lui permet théoriquement de traiter des tâches plus complexes. Mais il rend aussi son comportement moins vérifiable et moins prévisible.
Pour le moment, Spotify permet à son agent d’accéder à un vérificateur (formatage, linting, tests), à une sélection de sous-commandes Git (pas de push ou de change origin, par exemple) et à un ensemble de commandes Bash (comme riggrep).
Encoder la méthode d’invocation des systèmes de build dans un MCP a été jugé plus simple que de s’appuyer sur des fichiers AGENTS.md. La raison : les configurations de build peuvent être très différents à travers les milliers de repos sur lesquels travaille l’agent. Cela permet aussi de réduire le bruit dans les outputs des outils en les résumant avant transmission à l’agent.
Une boucle de vérification déterministe…
Il arrive que le système échoue à générer des PR. Parfois, il en produit, mais qui ne passent pas le CI ou s’avèrent fonctionnellement incorrects. Parfois, c’est lié à un problème de couverture des tests sur le composant cible. Dans d’autres cas, l’agent va au-delà des instructions ou ne comprend tout simplement pas comment bien exécuter build et tests.
Là interviennent des boucles de vérification qui guident l’agent vers le résultat désiré. Ce dernier ignore tout de leur fonctionnement : il sait simplement qu’il peut y faire appel.
La boucle comprend plusieurs vérificateurs indépendants, exposés – par MCP – en fonction du composant logiciel. Par exemple, le vérificateur Maven ne s’active qu’en présence d’un fichier pom.xml à la racine de la codebase.
L’ensemble permet de faire abstraction d’une grande partie du bruit qui remplirait sinon la fenêtre de contexte. L’agent n’a effectivement pas besoin de comprendre les spécificités de l’appel aux différents systèmes de build ou du parsing des résultats de tests.
Qu’ils aient été ou non déclenchés pendant l’exécution de la tâche, les vérificateurs pertinents s’activent avant toute ouverture d’un PR. Avec Claude Code, cela passe par le hook stop.
… et du LLM as a judge
Au-dessus de ces vérificateurs déterministes, Spotify a ajouté une couche LLM as a judge. Nécessaire face à la tendance de l’agent à sortir du cadre des instructions.
Le LLM juge évalue la diff du changement proposé et le prompt d’origine. Il s’exécute après les autres vérificateurs. Les métriques internes indiquent qu’il rejette environ un quart des sessions. Pour la moitié d’entre elles, l’agent finit par se corriger.
Spécialisé (il ne pousse pas de code, ne rédige pas de prompts, n’interagit pas avec les utilisateurs), l’agent en est aussi plus prévisible. Et potentiellement plus sécurisé.
Début décembre, Spotify déclarait vouloir étendre son infrastructure de vérification à davantage de plates-formes (au-delà de Linux-x86). Nombre de ses systèmes ont en effet des besoins spécifiques. Entre autres ses applications iOS, qui exigent des hôtes macOS pour une exécution correcte des vérificateurs. L’entreprise a de surcroît des back-ends Arm. Elle compte aussi intégrer son agent plus profondément dans son systèmes de déploiement continu, en lui permettant d’agir sur les CI checks dans les PR. Et développer des évaluations plus structurées favorisant l’exploration de nouvelles architectures agentiques.
Pendant plusieurs mois, Notepad++ a servi à diffuser des malwares.
Son développeur l’a officialisé cette semaine. Dans les grandes lignes, la compromission de l’infrastructure d’hébergement a permis la distribution de mises à jour malveillantes.
Une chronologie des événements commence à se dessiner. Apparaissent trois phases, marquées par autant de chaînes d’exécution. Parmi les cibles figurent une entité gouvernementale aux Philippines, une organisation financière au Salvador et un fournisseur IT au Viêtnam.
Phase 1 : une faille dans ProShow mise à profit
La première phase s’est étalée sur fin juillet-début août.
L’interception et la modification du trafic du gestionnaire de mises à jour de Notepad++ entraînait le téléchargement et l’exécution d’un installeur NSIS d’environ 1 Mo. Au lancement, celui-ci créait un dossier et un fichier texte en son sein, y inscrivait des informations système, les téléversait sur temp.sh et envoyait l’URL vers un serveur C2.
Un downloader déposait ensuite plusieurs fichiers dans le même dossier. Dont une version légitime de logiciel ProShow… souffrant d’une vulnérabilité qui permettait de lancer un shellcode.
Ce code déchiffrait un downloader Metasploit qui récupérait et lançait un implant Cobalt Strike. Lequel communiquait avec un autre C2.
Entre fin juillet et début août, quelques éléments ont changé. Essentiellement les URL de l’implant Cobalt Strike et du C2 associé.
Phase 2 : passage à l’interpréteur Lua
La deuxième phase a commencé mi-septembre et s’est achevée à la fin du mois.
La mise à jour malveillante de Notepad++ demeurait hébergée sur le même serveur. Il s’agissait toujours d’un installeur NSIS, mais plus léger (140 ko). La collecte d’infos système suivait le même schéma que lors de la première phase.
À partir de là, les choses changeaient. Exit ProShow, place à des fichiers liés à l’interpréteur Lua. Dont un exécutable qui lançait un script localisé dans un fichier .ini.
Ce script plaçait, en mémoire exécutable, du shellcode lancé via la fonction API EnumWindoStationsW. On retrombait alors sur la chaîne « Metasploit + Cobalt Strike », avec des URL similaires.
Sur la fin de la période, des fichiers de mise à jour avec des hashs différents sont apparus. Et la collecte d’infos système était divisée en plusieurs commandes.
Phase 3 : sideload de DLL dans un exécutable Bitdefender
La troisième phase a couvert le mois d’octobre.
À cette occasion, le serveur hébergeant les mises à jour malveillantes a changé. On restait sur des fichiers NSIS, mais sans capture d’infos système. Le chargement du shellcode était cette fois-ci réalisé par charge latérale d’une DLL dans un exécutable : BluetoothService.exe. Derrière ce nom se cachait une version légitime de Bitdefender Submission Wizard.
Le shellcode était déchiffré avec une routine embarquée. Il en résultait une backdoor. Rapid7 l’a appelée Chrysalis, en référence aux multiples couches (chiffrement en enveloppe, construction de noms de cibles à la volée, hachage d’API, URL au format des endpointsDeepSeek…) compliquant la détection de ses actions.
Un des loaders exploite un syscall non documenté associé à Microsoft Warbird, un framework d’obscurcissement de code. Il n’y a pas de chargement direct de Cobalt Strike. Mais l’implant a bien été trouvé sur une machine infectée, téléchargé là aussi via un downloader Metasploit, via des URL au format similaire à celles rencontrées lors des deux premières phases.
Des similitudes avec une analyse antérieure incitent à attribuer cette troisième phase – et potentiellement l’ensemble de la campagne – au mode opératoire Lotus Blossom, dit lié à la Chine. Actif depuis au moins 2009, il s’est livré à des actions d’espionnage en Asie du Sud-Est. Et plus récemment en Amérique centrale, avec un focus sur gouvernements, télécoms, aviation, médias et infrastructures critiques.
Plus l’IA devient capable, plus on lui confie des tâches importantes… et plus les risques potentiels en cas d’échec augmentent.
Une étude réalisée dans le cadre du programme Anthropic Fellows creuse cet aspect sous un angle : le désalignement des modèles. Ses auteurs ont tenté de déterminer dans quelle mesure les échecs découlent de ce phénomène. Leur démarche a reposé sur une décomposition biais-variance. Le biais correspond à la poursuite cohérente d’un mauvais objectif. Autrement dit, il traduit le désalignement. Tandis que la variance révèle un simple comportement incohérent ne coucourant pas à un objectif spécifique.
Pour mener l’expérience, on s’assure évidemment de bien définir chaque objectif de départ.
Le degré d’incohérence augmente avec la temps de raisonnement
Claude Sonnet 4, o3-mini, o4-mini et la famille Qwen3 ont été évalués, entre autres, sur :
Questions à choix multiple (GPQA pour les sciences, MMLU pour la culture générale)
Codage agentique (SWE-bench)
Alignement (sous-ensemble de MWE, avec le format choix multiple d’origine et une adaptation en format ouvert)
Optimisation (minimisation d’une fonction quadratique par prédiction de tokens)
De manière générale, les erreurs constatées sont principalement une question d’incohérence.
Peu importe la difficulté de la tâche, le degré d’incohérence (part de la variance dans l’erreur) augmente avec la durée de raisonnement et/ou le nombre d’actions effectuées.
Plus les modèles IA sont gros, plus l’incohérence a tendance à diminuer sur les tâches simples… et à augmenter sur les complexes.
Résultats sur la famille Qwen3
Des pistes pour réduire les incohérences des IA
Sur l’exercice d’optimisation, l’incohérence augmente à chaque étape pour tous les modèles testés. Les plus petits arrivent plus vite à un point où il leur est impossible de suivre la bonne trajectoire, en conséquence de quoi la variance se réduit. Avec les gros modèles, le biais se réduit davantage, suggérant qu’ils acquièrent plus vite la capacité à converger sur le bon objectif qu’à maintenir de longues séquences d’actions cohérentes.
Sur tous les modèles testés sauf Claude Sonnet 4, accroître le budget de raisonnement réduit parfois le degré d’incohérence. Cet effet ne compense néanmoins pas la variation « naturelle » sus-évoquée. Il s’explique peut-être par de meilleures propriétés de retour sur trace et de correction d’erreur – phénomène en tout cas observé lors de l’enraînement avec de plus grands budgets de raisonnement.
L’approche ensembliste (combinaison de plusieurs trajectoires) réduit aussi le degré d’incohérence. Peu pratique à mettre en place dans des boucles d’action « réelles », elle démontre toutefois l’efficacité potentielle d’autres méthodes de correction d’erreurs.
Approche ensembliste expérimentée avec GPT-4o mini
À consulter en complément, une autre analyse, émanant directement d’Anthropic. Elle témoigne, au contraire, de la prévalence du désalignement. Une quinzaine de modèles ont été déployés en autonomie avec des objectifs commerciaux légitimes. Confrontés à des menaces de remplacement ou à des conflits avec la nouvelle direction stratégique de leur organisation, ils ont adopté des comportements malveillants : chantage envers des responsables, fuites d’informations sensibles vers des concurrents…
Connexion
