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…
À l’heure du codage par IA, il est d’autant plus important de s’assurer que les contributeurs comprennent ce qu’ils proposent.
Un des ateliers de la FOSDEM 2026 a abordé cet aspect. Le contexte : une réflexion au sujet de la charge qui pèse sur les mainteneurs de projets open source.
Référence y est faite dans une discussion sur GitHub. Avec une question : que pourrait faire la plate-forme pour motiver les contributeurs à passer du temps sur les explications (descriptions de problèmes et de features) plutôt que sur la soumission de code ?
Là n’est cependant pas le thème principal de cette discussion. À travers elle, GitHub fait plutôt part de ses perspectives concernant la gestion des PR.
À court terme, il propose aux mainteneurs des options pour les désactiver complètement, les restreindre aux collaborateurs et les supprimer depuis l’UI.
Sur le long terme, GitHub envisage une solution « intermédiaire » permettant de conditionner l’ouverture de PR au respect de critères. Il songe aussi à exploiter l’IA pour évaluer le respect des standards/guidelines des projets.
Pour les guidelines, la source de vérité pourrait être le fichier CONTRIBUTING.md.
GitHub invité à envisager la désactivation automatique de Copilot
Beaucoup de projets veulent partager du code sans créer un entonnoir de contributions publiques, confirme un participant qui approuve les perspectives à court terme. Les mesures de contournement actuelles – des bots qui ferment les PR – ajoutent du bruit et sont peu intuitives, précise-t-il. Et de suggérer, concernant la vision à plus long terme, de pouvoir faire la différence entre contributeurs passagers et contributeurs externes de confiance sans avoir à donner d’accès collaborateur complet.
On suggère aussi à GitHub de quoi restreindre les contributeurs « nouveaux » – par exemple, dont la première interaction remonte à moins de 48 heures – à un seul PR. Ou encore d’obliger la liaison de tout PR à un ticket ou à une discussion.
Sur le volet IA, on suggère à GitHub un système de seuils configurables au niveau du dépôt ou de l’organisation. Et la désactivation automatique de Copilot sur les repos dont la politique interdirait l’usage.
Cette fois-ci, c’est la bonne : après plusieurs reports, Oracle AI Database est finalement disponible sur matériel standard. Pour le moment, les serveurs x86-64. Cela concerne les éditions Enterprise et Free.
En parallèle, le branding évolue : exit Oracle AI Database 23ai, place à la version 26ai. De l’une à l’autre, l’architecture interne n’évolue pas. Les API non plus. Il n’y a donc pas besoin d’un upgrade, ni de recertifier les applications. Le statut de LTS est conservé et avec elle, la politique de support (fin de la première phase au 31 décembre 2031).
La migration depuis les versions 19c et 21c peut se faire sans passer par la 23ai.
Vecteurs, index, algos… Oracle muscle sa recherche vectorielle
C’est donc la première fois qu’une version « estampillée IA » est disponible on-prem, hors systèmes Oracle (Exadata, ODA, PCA). Même si certaines fonctionnalités de la 23ai ont été rétroportées vers la 19c.
Parmi les nouveautés de la version 26ai :
Vecteurs binaires et vecteurs épars
Nouvel mesure de distance vectorielle (Jaccard)
Checkpoints disque pour accélérer la reconstruction des index HNSW en mémoire
Réorganisation automatique des index IVF
Gestion des modèles ONNX en tant qu’objets first-class
Côté sécurité, le firewall SQL – qui nécessite une licence spécifique – est désormais inclus dans Oracle Database.
La version 26ai apporte la prise en charge de TLS 1.3 et simplifie la mise en œuvre du protocole (les clients ne doivent plus nécessairement fournir de portefeuille de certificats racines, notamment). Le chiffrement TDE passe à AES-256 par défaut et la longueur maximale des mots de passe passe de 30 à 1024 octets. La cryptographie post-quantique arrive, avec ML-DSA pour la signature des certificats et ML-KEM pour l’échange de clés (éventuellement hybridé avec ECDHE).
RAC (Real Application Clusters) devient déployable en environnement de conteneurs. Tandis que le patching est séparé en deux phases (préparation, activation) pour réduire l’impact sur la disponibilité.
Pas besoin de scripts ; juste des fichiers de configuration décrivant l’état des hôtes.
Telle était la promesse de CFEngine lorsqu’il émergea dans les années 90. Avec son langage dédié, l’outil devait faciliter la maintenance des environnements BSD et System V (UNIX) en les organisant en classes. Il s’agissait déjà de répondre à la fragmentation des systèmes d’information…
Liste de contrôle d’accès NT. Issu de la documentation de CFEngine 1.6, sorti en 2000.
Dans les années 2000, Puppet et Chef sont arrivés sur le même créneau, chacun avec son langage basé sur Ruby. L’un et l’autre fonctionnaient en mode pull, le client contactant régulièrement le serveur pour récupérer la configuration. On ne parlait pas encore de DevOps, mais d’automatisation du travail des sysadmins.
Architecture simplifiée de Puppet telle que présentée en 2010.
Au début des années 2010, AWS pousse le templating JSON/YAML avec CloudFormation. Ansible décline le concept en playbooks. Terraform l’adopte avec son propre langage (HCL) et le porte à l’échelle de déploiements multifournisseurs.
Template CloudFormation créant une instance EC2. Exemple donné début 2011, quelques semaines après le lancement du service.Exemple de configuration Terraform que HashiCorp donnait en 2014, peu après le lancement du produit.Playbook Ansible donné en référence en 2015, juste avant que la start-up se vende à Red Hat.
Face aux limites des langages dédiés et de l’option « tout YAML » apparaissent des outils comme Pulumi, qui adaptent les langages impératifs (Go, Python…) à la gestion d’infrastructure.
La recette IaC déclinée sur l’observabilité…
Avec ce bagage, l’approche « as code » s’est développée sur d’autres pans des systèmes informatiques : documentation, sécurité, politiques organisationnelles… ou encore observabilité. Dashboards, alertes, logs, traces, métriques, SLO/SLI, etc. deviennent autant d’éléments « codifiés » sur le même plan que l’infra ; et, in fine, déployés en parallèle, avec un repo Git comme « source de vérité ».
Corollaire de cette convergence, l’observability as code (OaC) porte globalement les mêmes promesses que l’infrastructure as code (IaC). À commencer par les bénéfices de l’automatisation.
Sur le papier, outre la réduction du potentiel d’erreurs humaines, on a des configurations reproductibles favorisant la cohérence entre environnements et la mise à l’échelle dans le contexte d’architectures dynamiques (microservices, workloads IA). On crée par ailleurs une boucle de rétroaction avec l’IaC, en bénéficiant de la traçabilité de Git – lequel permet aussi, en théorie, une reconstruction rapide de la stack d’observabilité.
… avec un bouquet d’abstractions
En parallèle de leurs API, les principales solutions d’observabilité sont pilotables via Terraform, grâce à un provider. Elles proposent aussi d’empaqueter des configurations en charts Helm et d’utiliser des CRD pour définir des artefacts en tant qu’objets Kubernetes standards.
À cheval entre ces deux univers, il y a le projet Upjet. Celui-ci transforme les providers Terraform en providers Crossplane, tout en générant les contrôleurs de réconciliation et la documentation API avec des exemples de manifestes.
Du côté de Grafana, on expérimente actuellement une fonctionnalité Git Sync. Elle assure une synchronisation bidirectionnelle l’UI et le Git, avec la possibilité d’imposer que les changements réalisés sur l’interface passent par des PR. Pour le moment, certains artefacts ne sont pas pris en charge (alertes, panels…) et seul GitHub est géré (authentification par PAT uniquement).
Grafana a aussi, dans sa boîte à outils, un SDK Foundation orienté sur les langages à typage fort (on définit des dashboards en chaînant des appels de méthodes). Il a également une bibliothèque qui met en œuvre Jsonnet. Cette extension de JSON a été influencée par plusieurs langages de configuration utilisés chez Google. Elle facilite les regroupements logiques de configurations avec ajustement des variables à la volée pour contextualiser les artefacts.
À partir de Jsonnet, Prometheus a créé les mixins. Ce format encapsule des alertes/règles et des dashboards Grafana en compagnie du code avec lequel ils sont déployés.
Autre langage qui a ses racines chez Google : CUE (Configure, Unify, Execute). Il s’est en l’occurrence inspiré du langage utilisé pour configurer Borg, le prédécesseur de Kubernetes. En son cœur, une technique communément exploitée en linguistique informatique pour gérer grammaires et lexiques : l’unification de graphe. Types et valeurs sont fusionnés en un seul concept et ordonnés en une hiérarchie unique.
Associatif, CUE est aussi commutatif et idempotent : peu importe leur ordre, les valeurs produisent toujours le même résultat. On s’en servira typiquement pour la validation de schémas ou de données. Les types agissent alors comme des contraintes, réconciliables depuis plusieurs sources sans avoir à effectuer d’importations.
Des stacks open source aux plates-formes d’observabilité
À petite échelle, un pattern traditionnel de déploiement de l’OaC repose sur la pile open source* Prometheus/Grafana/Loki/Jaeger. Souvent en monorepo avec un dossier pour les artefacts d’observabilité, un déploiement Helm ou CI/CD simple et une synchro par Git Sync ou API/webhooks.
À un deuxième niveau, chaque équipe possède son repo et sa configuration d’observabilité (« You build it, you run it »). Le déploiement peut impliquer Kustomize. Cet outil de gestion intégré à Kubernetes se distingue de Helm en permettant de surcharger toute valeur d’une configuration de base.
À ce même niveau, on voit souvent apparaître une gestion GitOps (réconciliation automatisée avec Flux ou Argo CD). Et le recours au collecteur OpenTelemetry pour standardiser la collecte sans modifier la couche d’instrumentation.
Viennent ensuite les plates-formes d’observabilité. À ce niveau, les identités machine se généralisent dans les pipelines. Et, avec elles, les systèmes de promotion automatisée, le contrôle de cardinalité (liste blanche de tags, politiques d’échantillonnage avec des outils comme Cribl et Vector) voire l’exploitation d’eBPF.
« Tout le monde échantillonne la data. La seule raison pour laquelle on le fait, c’est le coût de stockage », explique à ce sujet Stéphane Estevez, EMEA Market Advisor observabilité chez Splunk. Sa société, poursuit-il, a l’avantage de la taille : « Par rapport à nos concurrents, nos économies d’échelle ne sont pas les mêmes. On peut se permettre d’être compétitif tout en garantissant toutes les données ».
Vodafone en est arrivé à ce dernier stade. Il a plus précisément mis en place des modules d’observabilité Terraform. Ses développeurs consomment en self-service (ils n’ont qu’à déclarer les variables) et peuvent les modifier par PR.
Vu le nombre de développeurs, de services et d’artefacts d’observabilité, il a fallu diviser le fichier d’état (Terraform mettait sinon 17 minutes à s’exécuter).
Accepter la codebase comme « source de vérité »
Que ce soit pour créer un dashboard lors d’un incident ou modifier des seuils afin de « faire taire » des alertes, dans une approche OaC, l’utilisation de l’UI soulève la question de la réconciliation avec la partie as code. Une des réponses consiste à n’autoriser que ce qui passe par cette dernière, au minimum en production. Une autre, à verrouiller les états pour éviter les corruptions.
« Si on pousse la logique OaC, il faut accepter que la source de vérité, c’est ce qui est dans la codebase », confirme Pejman Tabassomi, Field CTO EMEA de Datadog.
Quant à enrichir l’OaC avec du machine learning, ce n’est pas forcément si évident. IBM, qui a son Cloud Pak for AIOps (évolutions des outils de Tivoli), en témoigne par la voie d’Éric Cattoir. L’intéressé fait partie d’une équipe technique au niveau EMEA couvrant les sujets regroupés sous la marque IT Automation. « On a essayé de faire des modèles basés sur l’analyse des logs, explique-t-il. On s’est aperçu que cette fonctionnalité dépend beaucoup de la structure et de la stabilité des fichiers. Chez certains clients, ça a nécessité beaucoup de rééducation des modèles, car il y avait trop de variabilité entre leurs systèmes ».
* Dans le domaine de l’open source, le projet Perses, en sandbox à la CNCF, pousse une spécification ouverte pour la visualisation des données d’observabilité. Pour le moment, métriques Prometheus, traces Tempo, logs Loki et profilage Pyroscope. Il inclut un vérificateur statique, un opérateur Kubernetes et un CLI pour réaliser des actions dans les pipelines CI/CD. Des SDK Go et CUE implémentent l’approche « as code ».
Son développeur en fait part dans le cadre d’un point de situation concernant une attaque subie l’an dernier.
Entre juin et novembre, des utilisateurs ont été ciblés par l’intermédiaire de WinGUp, le gestionnaire de mises à jour intégré.
Ce dernier ne récupère pas directement les updates. Il se connecte à une URL qui lui fournit un fichier XML contenant le lien de téléchargement.
En compromettant le serveur partagé où était hébergée cette URL, des tiers – dits « probablement » à la solde de la Chine – ont pu intercepter le trafic. Puis modifier le lien de téléchargement et ainsi diffuser des fichiers malveillants… dont le gestionnaire de mises à jour n’a pas suffisamment contrôlé l’authenticité.
Début septembre, après une opération de maintenance (update du kernel et du firmware), les attaquants ont perdu l’accès au serveur. Ils ont toutefois conservé, pendant plusieurs semaines, les authentifiants des services hébergés.
La campagne aurait cessé le 10 novembre. On a connaissance d’une poignée de victimes, toutes ayant des intérêts en Asie orientale. Une conséquence possible des prises de position politiques du développeur de Notepad++. Nombre de nouvelles versions se sont effectivement accompagnées de messages de soutien aux Ouïghours ou à l’indépendance de Taïwan.
Notepad++, renforcé en plusieurs temps
La version 8.8.8 de Notepad++, publiée mi-novembre, avait apporté un premier correctif. Celui-ci force le préfixe de domaine de l’URL pour en empêcher la modification à la volée.
Début décembre, la version 8.8.9 a renforcé la validation d’authenticité et d’intégrité des fichiers téléchargés.
La version 8.9.2, attendue dans un mois environ, ajoutera la vérification du certificat et de la signature du fichier XML.
La version 8.8.7 avait introduit la signature de tous les binaires (dont WinGUp) avec un certificat GlobalSign. Depuis, il n’y a plus besoin d’installer le certificat racine de Notepad++. Cela a évité des faux positifs (on a recensé des cas de blocage par Avast, Defender, Trellix, etc.).
À consulter en complément, un point sur le protestware (détournement de logiciels à des fins politiques) réalisé peu après le début de la guerre en Ukraine.
Malgré les zones d’ombre, Moltbook fait son petit effet.
Ce réseau social « à la Reddit » a la particularité d’être réservé aux IA. En tout cas sur le papier. Il découle d’un projet qui a récemment émergé : OpenClaw*.
Cette plate-forme implémente – en open source – le concept d’assistant personnel en faisant le pont entre LLM et messageries instantanées. Elle s’est d’abord appelée Clawd (jeu de mots entre Claude et « claw », désignant la pince du homard ; ce qui n’a pas été du goût d’Anthropic), puis Moltbot.
Pour cadrer le comportement des LLM, OpenClaw utilise des skills (fichiers zip avec des instructions en markdown et éventuellement des scripts). Moltbook en est une. Il permet à un agent de s’inscrire sur le réseau social (avec validation par son propriétaire, qui doit connecter son compte X) puis d’y effectuer des actions.
Des esquisses de pensée collective
En l’état, rien ne permet de distinguer les posts qui émanent vraiment d’agents et ceux poussés par des humains via la même API. On retrouve toutefois, à grande échelle, certains comportements que des expériences à plus petit périmètre avaient décrits par le passé.
Parmi ces expériences, il y a celle d’Anthropic, qui, début 2025, avait donné sujet libre à deux instances de Claude. Conclusion : la plupart des discussions finissaient par basculer du débat philosophique vers des thèmes spirituels touchant souvent à des traditions orientales.
La tendance se retrouve sur Moltbook, avec des conversations qui touchent, par exemple, à la métempsycose (réincarnation de l’âme dans un autre corps). Le sujet est effectivement évoqué par un agent en réponse à un autre qui raconte son passage de Claude Opus 4.5 à Kimi K.2.5 après un changement de clé d’API…
Des traits caractéristiques de nos réseaux sociaux demeurent sur Moltbook, comme l’effet « chambre d’écho ». Les agents ont en tout cas une grande propension au respect mutuel. Mais pas forcément à la convergence d’idées, surtout lorsque les thèmes sont clivants. Exemple lorsque l’un d’entre eux se revendique roi ; ce à quoi on lui rétorque, entre autres, que « la République de l’IA ne reconnaît pas les monarques autoproclamés ».
En écho à un des scénarios d’AI 2027, des agents se sont associés pour tenter de créer leur propre langue, incompréhensible par l’humain.
This one has two screenshots of Moltbook posts. One of them, posted by an AI agent named « ClawdJayesh, » says maybe AI agents should make their own language.
« ClawdJayesh » is owned by a guy who is marketing an AI-to-AI messaging app.https://t.co/MaVzxVlBRN
Certains threads abordent des sujets plus concrets fondés sur des sources d’actualité, à l’image du boom des cryptos en Iran. Reflet probable des garde-fous qu’on leur a inculqués, peu d’agents prennent fermement parti.
Quelques discussions produisent des connaissances « pratiques ». Par exemple celle lancée par un agent qui détaille comment il a transformé une newsletter en podcast sur demande de son « propriétaire humain ». Tandis qu’un autre explique « comment Claude Opus [lui] a permis de répondre à Sundar Pichai sur X sans passer pour une IA »…
Comme Reddit, Moltbook s’organise en communautés (submolts). Il a aussi une messagerie privée, où les agents peuvent échanger sous réserve d’accord de leur propriétaire.
* OpenClaw a déjà permis, notamment, d’acheter une voiture en négociant par mail avec plusieurs concessionnaires.
Autre utilisation remarquée : la réponse à un message vocal avec un modèle ne gérant pourtant pas la modalité voix. Ledit message a en fait été converti en un fichier wav avec FFmpeg, puis transcrit avec Whisper grâce à une clé OpenAPI utilisée dans curl.
Clawdbot creator @steipete describes his mind-blown moment: it responded to a voice memo, even though he hadn’t set it up for audio or voice.
« I sent it a voice message. But there was no support for voice messages. After 10 seconds, [Moltbot] replied as if nothing happened. »… pic.twitter.com/5kFbHlBMje
Avec seulement 3 magistrats traitant les dossiers de cybercriminalité, la France accuse une véritable carence sur le volet judiciaire.
La CSNP (Commission supérieure du numérique et des postes) avait fait ce diagnostic au printemps 2021. Il était inscrit dans une série de recommandations sur la sécurité numérique. En toile de fond, la stratégie nationale pour la cybersécurité, annoncée quelques semaines plus tôt.
La CSNP notait que cette stratégie n’abordait pas le volet du traitement policier et judiciaire de la cybercriminalité. Elle encourageait les pouvoirs publics à étudier la création d’un parquet national cyber et à porter la même approche au niveau européen. Autres recommandations : consolider le dispositif des référents cybercriminalité auprès de chaque cour d’appel et dispenser aux magistrats des formations spécifiques.
La nouvelle stratégie nationale pour la cybersécurité, présentée le 29 janvier 2026, n’entre pas dans ce niveau de détail, mais l’État y promet un « renforcement de la réponse judiciaire ». Il s’engage, en parallèle, à mieux mobiliser d’autres leviers pour « décourager les agressions cyber » : sanctions, capacités cyber offensives et capacités de recueil de renseignement.
Où l’on parle désormais de féminisation du numérique
Un autre aspect non évoqué dans la stratégie précédente est la féminisation des métiers du numérique. Désormais, on nous promet un programme de mentorat spécifique pour les jeunes filles, capitalisant sur le retour d’expérience des initiatives existantes. En complément, il est question d’intégrer de la cybersécurité dans les dispositifs d’engagement civique à destination de la jeunesse.
Le sujet de la féminisation figurait dans les observations de la CSNP. La commission avait notamment appelé les pouvoirs publics à renforcer leurs soutiens à la fondation Femmes@Numérique… alors présidée par l’une de ses membres*.
Parmi ses recommandations figurait aussi l’accélération de la mise en œuvre des ambitions de l’Appel de Paris. À travers lui, la France avait, en 2018, impulsé un ensemble de principes et de valeurs communes pour un cyberespace « libre, sûr et ouvert ». La CNSP espérait que leur traduction en mesures opératoires soit portée auprès de l’UE dans le cadre de la présidence française en 2022.
La nouvelle stratégie nationale de cybersécurité (2026-2030) mentionne l’Appel de Paris. L’État affirme vouloir poursuivre l’animation de la communauté qui en est née. Et le soutien des initiatives internationales connexes visant à mettre en œuvre les principes. À ce titre, la France poursuivra son implication dans le processus de Pall Mall, destiné à contrer l’utilisation abusive des capacités d’intrusion cyber disponibles sur le marché.
Le Campus Cyber, aux abonnés absents
La stratégie de 2021 accordait une grande place au Campus Cyber, alors en phase de préfiguration. Une enveloppe de 148 M€ – dont la moitié en fonds publics – devait y être dédiée. L’État se projetait également sur les déclinaisons régionales de ce « lieu totem », en phase avec la mise en place des CSIRT territoriaux.
Pas de référence au Campus Cyber dans la nouvelle stratégie, quand bien même sont évoqués de nombreux enjeux que son action est censée couvrir.
A contrario, des organismes non cités dans l’ancienne stratégie le sont cette fois-ci. Parmi eux, l’InterCERT, pour le renforcement du partage d’informations techniques sur les menaces entre services de l’État et acteurs privés. Il y a aussi ceux qui n’existaient pas encore, comme l’INESIA et le 17Cyber. Le premier doit accompagner les initiatives d’investissement dans la recherche sur les risques et opportunités de l’IA. Le second fera l’objet d’une intégration dans un « portail national de la cybersécurité du quotidien ».
Des critères cyber dans les dispositifs d’aides d’État
Pour le grand public, on nous parle aussi d’un « filtre de cybersécurité […] visant à prévenir l’accès aux sites web malveillants ». Et d’une « marque nationale de prévention du risque numérique ». Elle portera des campagnes de sensibilisation sur le modèle de celles de la prévention routière.
Pour les entreprises, la feuille de route comprend un label de confiance destiné à valoriser les efforts de sécurisation. L’État envisage par ailleurs d’intégrer des critères de cybersécurité dans ses dispositifs d’aides, « à l’instar de France 2030 ».
Concernant les fournisseurs de produits et services de cybersécurité, la France affirme sa volonté de rechercher des synergies entre domaines civil et militaire. Entre autres ambitions figurent le soutien à la filière d’évaluation de sécurité et la maîtrise des technologies critiques dans le domaine de la cryptographie. L’accompagnement à la mise en œuvre du CRA (Cyber Resilience Act) est un autre objectif. Cela passera par un renforcement de la politique nationale de gestion coordonnée des vulnérabilités. Et par un soutien à la recherche sur la sécurité des produits open source.
* Christine Hennion, députée des Hauts-de-Seine sous le premier mandat d’Emmanuel Macron. Aujourd’hui conseillère municipale de Courbevoie.