Workday vient d’annoncer un changement de direction spectaculaire. Aneel Bhusri, co-fondateur de l’éditeur, reprend immédiatement les commandes en tant que CEO, remplaçant Carl Eschenbach. Une décision qui intervient après une année désastreuse en Bourse : le titre a plongé de 41% sur douze mois.
Carl Eschenbach quitte non seulement son poste de directeur général mais également son siège au conseil d’administration. Il restera néanmoins conseiller stratégique auprès de Bhusri. Son départ lui vaudra une indemnité de 3,6 millions $, assortie d’une acquisition accélérée de ses stock-options en cours.
Pour Aneel Bhusri, le retour se monnaie cher : 135 millions $ en actions, soumises à des conditions de temps et de performance, auxquels s’ajoute un salaire de base de 1,25 million $, selon les documents transmis à la SEC.
Une histoire de succession complexe
L’histoire récente de Workday ressemble à un jeu de chaises musicales. Bhusri avait co-fondé l’entreprise en 2005, exercé seul la fonction de CEO entre 2014 et 2020, avant d’accepter un partage du pouvoir. Eschenbach avait été nommé co-CEO fin 2022, aux côtés du fondateur, avant que ce dernier ne se retire en 2024.
« Nous entrons dans l’un des moments les plus décisifs de notre histoire. L’IA est une transformation plus importante que le SaaS – et elle définira la prochaine génération de leaders du marché », déclaré Aneel Bhusri dans un communiqué officiel.
Workday, spécialisé dans les logiciels de gestion des ressources humaines et autres tâches administratives, fait partie de ces éditeurs d’applications qui peinent à convaincre Wall Street à l’ère de l’intelligence artificielle. Sous la direction d’Eschenbach, l’entreprise avait affiché une nouvelle priorité à la rentabilité, annonçant des suppressions de postes et promettant d’utiliser l’IA pour rationaliser ses propres opérations.
La semaine dernière encore, Workday avait annoncé le licenciement d’environ 400 employés, soit 2% de ses effectifs de 20.600 personnes fin octobre, dans le but de mieux investir dans ses domaines prioritaires.
Le retour de Bhusri apparaît comme un pari : celui de retrouver l’ADN entrepreneurial et l’agilité technologique face aux bouleversements de l’IA. Reste à savoir si cette cure de jouvence suffira à reconquérir les investisseurs.
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.
Cette fois c’est certain, la Plateforme des données de santé, couramment appelée Health Data Hub, va quitter Microsoft Azure pour un hébergeur labellisé SecNumCloud.
En avril dernier, Clara Chappaz, l’ex ministre déléguée chargée de l’intelligence artificielle et du numérique, s’était engagée à lancer un appel d’offres pour trouver un fournisseur de services Cloud à la plateforme de Microsoft.
Initialement prévue en deux temps avec une solution intercalaire puis une solution cible, la migration a été simplifiée. Selon un communiqué officiel, la mission d’expertise mobilisée par le Gouvernement a confirmé qu’il est techniquement possible d’engager immédiatement la migration complète vers la solution cible. L’appel d’offres lancé à l’été 2025 pour la solution intercalaire a donc été abandonné.
Une nouvelle plateforme sélectionnée fin 2026
Une copie complète de la base principale du Système national des données de santé sera hébergée d’ici fin 2026. Les fournisseurs de services cloud seront sollicités via le marché « Nuage Public », avec une attribution prévue fin mars 2026.
La Plateforme des données de santé a été créée pour faciliter l’accès sécurisé aux données de santé au service de la recherche, de l’innovation et du pilotage des politiques publiques. À ce jour, elle a accompagné plus de 233 projets et contribué à l’organisation de 29 appels à projets en partenariat avec de nombreux acteurs publics et privés.
Le choix de Microsoft Azure, bien que certifié HDS (Hébergeur de données de santé), a suscité de vives critiques. Plusieurs associations, la CNIL et le Conseil d’État avaient exprimé leurs inquiétudes concernant la dépendance envers un acteur soumis au droit américain, en particulier au Cloud Act, qui autorise les autorités américaines à accéder à certaines données hébergées par des entreprises basées aux États-Unis.
Du côté des acteurs publics et privés, la mesure est globalement saluée. L’Alliance pour le numérique en santé (ANS) souligne qu’elle offrira « un cadre clair pour les coopérations et les projets d’intelligence artificielle médicale ».
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.
Pendant des décennies, le Shadow IT se résumait à des applications SaaS non approuvées ou à des serveurs de stockage personnels. Aujourd’hui, le phénomène a muté en une force bien plus disruptive : le Shadow AI. Le constat est sans appel : alors que les directions informatiques s’interrogent encore sur les protocoles, les collaborateurs, eux, ont déjà intégré l’IA générative dans leur quotidien.
Selon les analystes de Forrester, le « Bring Your Own AI » (BYOAI) est devenu la norme, car les employés privilégient l’efficacité immédiate à la conformité procédurale.
Pour le DSI, l’enjeu dépasse la simple gestion de parc logiciel. Il s’agit désormais de protéger la propriété intellectuelle tout en ne devenant pas le goulot d’étranglement de la productivité. Comme le souligne Gartner, « le Shadow AI est le résultat d’un décalage entre la vitesse de l’innovation en IA et la vitesse de la gouvernance informatique. »
Sortir de l’illusion du blocage
Le premier réflexe de nombreuses organisations a été la restriction pure et simple. Pourtant, cette stratégie est aujourd’hui jugée non seulement inefficace, mais dangereuse. En bloquant l’accès aux LLM (Large Language Models) sur le réseau d’entreprise, la DSI ne supprime pas l’usage ; elle le rend invisible. Les collaborateurs se tournent vers leurs terminaux personnels, créant une zone grise où aucune politique de sécurité ne s’applique.
Cette transition impose au DSI d’évoluer vers un rôle de « facilitateur de confiance ». L’idée maîtresse est de passer d’une gouvernance prohibitive à une gouvernance adaptative. Michele Goetz, analyste chez Forrester, résume parfaitement cette bascule : « La gouvernance ne consiste pas à dire non, elle consiste à définir comment. »
Au-delà de la fuite de données, le risque majeur réside dans la fragmentation technologique. Si chaque département adopte son propre outil d’IA de manière isolée, l’entreprise se retrouve face à une explosion de la dette technique et une incapacité totale à harmoniser ses processus. Le rôle du DSI est donc de centraliser cette demande diffuse pour proposer des solutions qui répondent aux besoins métiers tout en garantissant l’auditabilité des décisions prises par l’IA.
Éduquer plutôt que sanctionner
Une gouvernance réussie ne peut être uniquement technologique ; elle doit être culturelle. Le Shadow AI prospère souvent sur l’ignorance des risques et non sur une volonté de nuire. Pour y remédier, le DSI doit instaurer un véritable contrat social avec les utilisateurs : la charte de bonne conduite.
L’enjeu est de transformer chaque collaborateur en un maillon de la chaîne de cybersécurité. Cela passe par une compréhension fine du concept de « Human-in-the-loop ». Forrester avertit d’ailleurs que « le plus grand risque de l’IA générative n’est pas ce qu’elle fait, mais ce que les humains font avec elle sans supervision. » La charte doit donc insister sur la responsabilité éditoriale : l’IA propose, mais l’humain dispose et vérifie.
La transparence devient ici une valeur cardinale. En encourageant les employés à déclarer leurs usages plutôt qu’à les cacher, la DSI peut identifier les cas d’usage à fort ROI. Cette approche pédagogique permet également de lutter contre les biais et les hallucinations, en rappelant que l’IA est un outil probabiliste et non une source de vérité absolue. C’est en accompagnant l’utilisateur dans son « AI Literacy » (sa culture de l’IA) que le DSI réduit naturellement le recours aux solutions de l’ombre.
L’architecture du « Safe Harbor »
Pour rendre la solution officielle plus attractive que le Shadow AI, le DSI doit bâtir un environnement qui surclasse les outils grand public. C’est ici qu’intervient le concept de Sandbox IA, ou « port sécurisé ». Techniquement, cette infrastructure repose sur le déploiement d’instances privées via des services comme Azure OpenAI ou AWS Bedrock, garantissant que les données saisies ne sortent jamais du périmètre de l’entreprise et ne servent jamais à l’entraînement de modèles tiers.
L’innovation majeure de ces environnements réside dans la couche de Data Guardrails. Contrairement à une interface publique, la sandbox d’entreprise intègre des filtres de Data Loss Prevention (DLP) qui interceptent et anonymisent les informations sensibles avant qu’elles n’atteignent le LLM. De plus, l’intégration du RAG (Retrieval-Augmented Generation) permet à l’IA d’interroger les documents internes de l’entreprise (bases de connaissances, archives, rapports) avec une précision que les outils publics ne peuvent égaler.
Enfin, cette approche offre au DSI une visibilité indispensable via le FinOps. En monitorant la consommation de « tokens » par département, la DSI peut non seulement contrôler les coûts, mais aussi prioriser les investissements sur les projets les plus créateurs de valeur.
Selon Gartner, « d’ici 2026, 75 % des organisations auront établi une stratégie de gouvernance de l’IA, contre moins de 5 % aujourd’hui. » La sandbox n’est pas seulement un outil technique, c’est le laboratoire où se prépare l’avenir de l’entreprise.
——————————————————————————————————————————–
Charte d’utilisation de l’IA Générative : innover en toute sécurité
L’intelligence artificielle générative est un levier de productivité puissant. Pour nous permettre d’innover tout en protégeant les actifs numériques de l’entreprise, chaque collaborateur s’engage à respecter les principes suivants.
1. Protection du patrimoine informationnel
C’est le pilier central. Les modèles d’IA publics (ChatGPT, Claude, Gemini version gratuite) utilisent vos données pour s’entraîner.
Interdiction formelle : Ne jamais saisir de données sensibles, de secrets commerciaux, de codes sources non publics ou d’informations personnelles (RGPD) dans un outil d’IA non validé par la DSI.
Réflexe de sécurité : Utilisez exclusivement les instances « Enterprise » mises à disposition par l’entreprise (ex: notre portail IA interne), car elles garantissent la confidentialité de vos données.
2. Le principe du « Humain-au-centre » (Human-in-the-Loop)
L’IA est un assistant, pas un remplaçant. Vous restez l’unique responsable de vos livrables.
Vérification systématique : L’IA peut « halluciner » (inventer des faits crédibles mais faux). Chaque information générée doit être vérifiée par vos soins avant d’être utilisée.
Responsabilité éditoriale : Tout document produit ou assisté par l’IA engage votre responsabilité professionnelle, comme si vous l’aviez rédigé seul.
3. Transparence et éthique
L’honnêteté intellectuelle est la base de notre collaboration.
Mention d’usage : Si un document client ou une analyse stratégique a été produit de manière significative par une IA, mentionnez-le (ex : « Ce document a été préparé avec l’assistance d’une IA générative »).
Lutte contre les biais : Soyez vigilants face aux stéréotypes ou biais que l’IA pourrait reproduire dans ses réponses. Gardez un esprit critique.
4. Propriété intellectuelle et droits d’auteur
L’IA génère parfois du contenu qui peut ressembler à des œuvres protégées.
Vigilance créative : Pour les visuels ou les textes destinés à l’externe, assurez-vous que les sorties de l’IA ne violent pas de droits d’auteur existants.
Code Source : L’utilisation d’IA pour générer du code doit suivre les protocoles de sécurité logicielle de la DSI pour éviter l’introduction de vulnérabilités ou de licences incompatibles.
——————————————————————————————————————————–
Architecture de la sandbox sécurisée
Pour passer de la théorie à la pratique, la DSI doit fournir un « Port de Sécurité » (Safe Harbor). C’est le rôle de la Sandbox IA, un environnement de test qui offre la liberté d’expérimenter sans compromettre le SI.
Les Composantes de l’Infrastructure
Une sandbox efficace ne se limite pas à un accès API ; elle repose sur une architecture robuste :
Isolation VPC et API Gateway : Les modèles (Azure OpenAI, AWS Bedrock, etc.) sont déployés dans un Cloud Privé Virtuel. Les données ne sortent jamais du périmètre de l’entreprise et ne servent jamais à entraîner les modèles publics des fournisseurs.
Couche de Filtrage (DLP & Guardrails) : Une passerelle intelligente scanne les prompts en temps réel. Elle bloque ou anonymise automatiquement les données sensibles (PII, codes sources confidentiels) avant qu’elles ne parviennent au modèle.
Observabilité et FinOps : Le CIO dispose d’un tableau de bord centralisé pour monitorer l’usage, détecter les comportements atypiques et gérer les coûts par jeton (tokens) par département.
Vers le RAG (Retrieval-Augmented Generation)
Le véritable avantage de cette infrastructure interne est sa capacité à connecter l’IA aux données froides de l’entreprise. En offrant un outil capable d’interroger la base de connaissances interne en toute sécurité, le CIO rend le Shadow AI obsolète car moins pertinent que l’outil officiel.
Les régulateurs de la concurrence de l’Union européenne ont franchi ce lundi une nouvelle étape dans leur bras de fer avec Meta.
La Commission européenne a envoyé une communication des griefs au groupe américain et envisage d’imposer des mesures provisoires pour éviter un « préjudice grave et irréparable », aux concurrents, une démarche similaire à celle adoptée par l’autorité italienne de la concurrence en décembre.
« Nous devons protéger une concurrence effective dans ce domaine dynamique, ce qui signifie que nous ne pouvons pas permettre aux entreprises technologiques dominantes d’exploiter illégalement leur position pour s’octroyer un avantage déloyal », a déclaré Teresa Ribera, commissaire européenne à la concurrence, dans un communiqué.
Meta a mis en œuvre sa nouvelle politique le 15 janvier, n’autorisant que son propre assistant Meta AI sur WhatsApp conteste fermement l’intervention de Bruxelles. « Il existe de nombreuses options d’IA et les utilisateurs peuvent y accéder via les app stores, les systèmes d’exploitation, les appareils, les sites web et les partenariats industriels », a répondu un porte-parole de Meta. « La logique de la Commission suppose à tort que l’API WhatsApp Business est un canal de distribution clé pour ces chatbots. ».
Une enquête aux enjeux considérables
La décision d’imposer ou non des mesures provisoires dépendra de la réponse de Meta et de l’exercice de ses droits de défense, a précisé l’autorité de régulation. Teresa Ribera a justifié cette démarche : « C’est pourquoi nous envisageons d’imposer rapidement des mesures provisoires à Meta, afin de préserver l’accès des concurrents à WhatsApp pendant l’enquête et d’éviter que la nouvelle politique de Meta ne nuise irrémédiablement à la concurrence en Europe. »,
Selon les règles européennes, les régulateurs peuvent ordonner aux entreprises de cesser temporairement des pratiques commerciales suspectes, bien que ces demandes puissent être contestées devant les tribunaux luxembourgeois de l’UE.
Les amendes éventuelles pour violation du droit antitrust européen peuvent atteindre 10% du chiffre d’affaires annuel mondial, même si elles atteignent rarement ce niveau, particulièrement lorsque les infractions présumées sont de courte durée.
Un tribunal brésilien a suspendu le mois dernier une mesure provisoire de l’agence antitrust du pays contre Meta sur la même question. Parallèlement, les flux d’informations sur la plateforme de messagerie WhatsApp sont tombés sous le coup des règles européennes de modération de contenu le mois dernier, lorsque la Commission a désigné ces canaux ouverts comme une « très grande plateforme en ligne » au titre du Digital Services Act.
Le Super Bowl ne se joue pas seulement sur le terrain. Cette année, c’est une bataille d’intelligences artificielles qui s’est également disputée à la mi‑temps.
Anthropic, le créateur du modèle Claude, a diffusé une publicité de 60 secondes vivement commentée, dénonçant avec ironie l’intégration croissante de contenus sponsorisés dans ChatGPT, le produit vedette d’OpenAI.
Le spot d’Anthropic, titré « Keep the Signal Clear », illustrait un utilisateur s’adressant à une IA dont les réponses deviennent progressivement parasitées par des messages commerciaux. La voix off concluait : « Une IA devrait vous écouter, pas vous vendre. »
Sans jamais nommer OpenAI, la référence était évidente : depuis janvier 2026, OpenAI teste aux États‑Unis des “réponses sponsorisées” dans ChatGPT, en partenariat avec plusieurs marques. Cette initiative, présentée comme « une manière d’assurer la durabilité du service », a suscité de vifs débats sur la neutralité de l’IA conversationnelle.
OpenAI défend son modèle économique
Dans un communiqué post‑Super Bowl, OpenAI a réaffirmé sa volonté de « maintenir un équilibre entre accessibilité et soutenabilité », estimant que la publicité contextuelle pouvait financer l’usage gratuit sans compromettre la qualité des réponses. L’entreprise a précisé que les contenus sponsorisés resteraient « clairement identifiés » et « non intrusifs ».
Mais cette explication ne convainc pas tout le monde. De nombreux observateurs estiment que la confiance dans les assistants IA repose sur leur impartialité perçue, un capital symbolique qu’une banalisation de la publicité pourrait fragiliser.
Anthropic sur la ligne « éthique »
En misant sur cette campagne coûteuse (estimée à près de 14 millions $ pour une minute d’antenne), Anthropic cherche autant à renforcer sa notoriété grand public qu’à se positionner comme la conscience morale du secteur. L’entreprise met en avant un modèle économique centré sur les abonnements professionnels et les partenariats sans publicité.
Selon ses dirigeants, le message visait à rappeler qu’« une IA responsable doit être un outil de pensée libre de toute influence commerciale ». Une pique qui, dans le contexte actuel d’une course effrénée à la rentabilité des modèles, tombe à point nommé.
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.
Il n’y aura plus de nouvelles fonctionnalités sur Heroku.
Le produit passe en mode maintenance… sans changements sur le cœur fonctionnel ni sur la tarification, nous assure-t-on. En revanche, l’offre Enterprise et le support associé ne sont plus commercialisés. Les contrats existants iront à terme et restent renouvelables.
Sous l’aile de Salesforce (propriétaire d’Heroku depuis 2011), les investissements vont s’orienter vers « des éléments [susceptibles de] délivrer la plus grande valeur sur le long terme, [notamment] aider à construire et à déployer [l’IA] ». Voilà un peu plus d’un an que le PaaS a pris ce virage, avec une nouvelle architecture fondée sur Kubernetes.
Le dernier sondage annuel Stack Overflow donne un indicateur de popularité pour Heroku. Dans la catégorie des plates-formes cloud, lorsqu’on demande aux répondants quelles technologies ils utilisent activement et souhaitent continuer à utiliser, 5,4 % répondent Heroku. Contre 8,2 % en 2024, 12,02 % en 2023, 19,98 % en 2022 et 24 % en 2021.
Ses principaux concurrents (Fly.io, Railway, Render…) n’ont pas dépassé les 2-3 % ces dernières années.
» Nous ne voulons pas de subventions…nous avons besoin de commandes publiques « . Combien de fois n’avons-nous pas entendu cette revendication chez les éditeurs français de logiciels et les startups de la French Tech ?
La donne est peut-être en train de changer à la faveur d’un nouveau paradigme : ériger la souveraineté en critère structurant des achats de l’État, au même niveau que la performance, la sécurité ou les coûts.
Une circulaire doit être signée très prochainement par le Premier ministre pour valider ce principe même si le texte laisse encore de larges marges d’interprétation. L’objectif affiché est de mieux maîtriser les dépendances technologiques de l’administration et utiliser les 4,5 milliards € annuels de commande publique comme levier de structuration de l’offre française et européenne.
Cette circulaire fait suite à plusieurs mois de concertation interministérielle et de dialogue avec la filière industrielle du numérique, qui réclamait un cadre plus lisible.
Mutualiser d’abord, développer en dernier recours
Le texte consacre un principe de sobriété et de rationalisation. Avant tout achat, les services de l’État devront suivre trois étapes obligatoires : rechercher d’abord une solution déjà disponible au sein du secteur public, dans une logique de mutualisation entre administrations. À défaut, se tourner vers le marché en appliquant les nouveaux critères de sélection. Et seulement en dernier ressort, lancer un développement « à façon ».
Cette hiérarchie vise à limiter la prolifération de projets sur mesure, jugés coûteux et redondants. Elle s’articule avec la doctrine « Cloud au centre de l’État » et s’appuie sur des outils opérés par l’administration comme Tchap, Visio ou FranceTransfert, basés sur des logiciels libres.
La souveraineté en tête de liste
Changement majeur : dans la grille de sélection des offres logicielles, la souveraineté apparaît désormais en première position, devant la performance, la sécurité, les coûts, la réversibilité, la maintenabilité et la durabilité. Un renversement symbolique qui place la maîtrise des dépendances technologiques au cœur de la décision.
Selon Bercy, cette souveraineté se décline en trois dimensions : l’immunité aux droits extraterritoriaux, pour limiter les risques liés aux législations étrangères ; la capacité de substitution, garantissant la réversibilité et évitant l’enfermement propriétaire ; et la maîtrise technologique, privilégiant les technologies placées sous contrôle de l’État ou d’acteurs alignés avec ses objectifs.
Le texte ne consacre pas formellement de préférence européenne, alors qu’Anne Le Hénanff, ministre déléguée chargée de l’Intelligence artificielle et du Numérique, la défend dans ses interventions publiques. Une ambiguïté qui laisse une marge d’interprétation aux acheteurs tout en envoyant un signal aux industriels du Vieux Continent.
Un cadre sans mode d’emploi précis
L’ambition affichée se heurte toutefois à une limite majeure : l’absence de barème. Aucune pondération chiffrée n’est associée aux critères fixés, notamment la souveraineté. Chaque acheteur public conserve donc une large autonomie pour apprécier l’importance de ce critère, ce qui pourrait conduire à des pratiques hétérogènes entre ministères et opérateurs.
La question du contrôle et du suivi reste également peu encadrée. Les dispositifs actuels, comme l’avis préalable de la DINUM pour les projets dépassant 9 millions d’euros, sont déjà partiellement contournés ou appliqués après coup.
Par ailleurs, la doctrine doit encore s’aligner avec les textes européens en préparation sur la commande publique, notamment la révision de la directive de 2014 qui vise elle aussi des objectifs d’autonomie stratégique. Les acheteurs devront arbitrer entre ces orientations nationales, les contraintes budgétaires et la pression opérationnelle.
Une opportunité pour l’écosystème français
Pour les éditeurs français et européens, cette circulaire constitue néanmoins un signal politique majeur. L’État annonce qu’il privilégiera les solutions maximisant l’immunité juridique, la réversibilité et la maîtrise technologique, sans exclure les acteurs extra-européens. Les fournisseurs capables de démontrer ces atouts par leur modèle d’hébergement, leur gouvernance ou leurs engagements de portabilité disposeront d’un argument différenciant.
Pour les acheteurs publics, le cadre de décision devient plus lisible, tout en préservant une part d’appréciation dans la mise en œuvre. Ils devront intégrer cette dimension de souveraineté dans leurs stratégies de sourcing et documenter davantage leurs choix pour sécuriser juridiquement leurs décisions.
La réussite de cette doctrine se mesurera à double titre : à la montée en puissance de l’écosystème numérique français et européen dans les marchés publics, et à la capacité de l’administration à réduire ses dépendances critiques sans sacrifier l’innovation ni la qualité de service.
Le Groupe Alain Afflelou a migré l’intégralité de son infrastructure depuis VMware ESXi vers l’hyperviseur Nutanix AHV. Une opération menée tambour battant en 2024, motivée par les incertitudes liées au rachat du champion de la virtualisation par Broadcom et l’augmentation des coûts.
Avec près de 1 500 points de vente répartis dans 19 pays (principalement France, Espagne, Belgique, Suisse et Portugal), le groupe d’optique et d’appareils auditifs fait face à une complexité IT particulière. Son modèle largement basé sur la franchise complique l’unification des environnements informatiques. La DSI, dirigée par Ludovic Tassy depuis 2006, s’appuie sur une expertise interne solide et des partenaires de confiance pour accompagner la croissance.
C’est dans ce contexte que la décision de quitter VMware s’est imposée. « Le passage à Nutanix a marqué un tournant : nous avons pu basculer notre infrastructure sans perturber les utilisateurs, tout en gagnant en performance et en visibilité », souligne le DSI.
Trois semaines pour tout migrer
La migration a été réalisée en trois semaines avec l’accompagnement de l’intégrateur SPIE, en s’appuyant sur Nutanix Cloud Infrastructure et l’outil Move. Bilan : près de 200 machines virtuelles et 200 To de données transférées sans interruption de service.
Le nouvel environnement repose sur deux clusters de trois nœuds chacun et un site témoin. Les gains sont au rendez-vous : performances applicatives multipliées par deux à trois sur certaines chaînes de traitement, compression des sauvegardes améliorée de 20 % et simplification de la gouvernance grâce aux fonctionnalités Prism, qui facilitent l’automatisation et le pilotage de l’exploitation.
Pour Nicolas Crochet, Responsable technique & Pôle Infrastructures, Nutanix s’est imposé comme la meilleure réponse aux enjeux de l’entreprise, en combinant maturité technologique, simplicité d’exploitation et efficacité opérationnelle. Ce choix offre à la DSI une infrastructure plus agile et réduit la dépendance aux modèles économiques imposés par les acteurs historiques du marché.
Cap sur 2026 : datacenter et convergence optique-audio
Le Groupe Alain Afflelou a déjà étendu ce déploiement en Espagne et prépare plusieurs projets complémentaires pour 2026 : refonte des cœurs de réseau et déménagement d’un datacenter.
Ces évolutions s’inscrivent dans une ambition plus large : harmoniser les logiciels de points de vente et consolider la donnée, afin de soutenir la convergence des activités optique et audio et de renforcer la qualité de service auprès des franchisés et des clients finaux.
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.
Le Vibe Coding bouleverse les pratiques de développement informatique. En mêlant intelligence artificielle générative et langage naturel, cette approche hybride permet de produire du code à partir de simples instructions textuelles. Si elle promet accessibilité et productivité, elle soulève aussi des interrogations majeures en matière de sécurité, de maîtrise, de souveraineté numérique et de gestion des compétences.
À l’heure où l’IA entre dans la chaîne de production logicielle, les entreprises doivent repenser leur gouvernance du développement.
Derrière la promesse d’un développement plus rapide et plus accessible, le Vibe Coding introduit des enjeux structurants pour les entreprises : sécurité des applications, maîtrise des dépendances technologiques, souveraineté des environnements numériques et transformation profonde des compétences IT.
Cette approche s’appuie sur la capacité des grands modèles de langage à traduire une intention métier exprimée en langage naturel en code exécutable, un changement de paradigme qui appelle autant d’enthousiasme que de vigilance.
Le Vibe Coding redéfinit les pratiques de développement
Le Vibe Coding désigne la pratique avec laquelle une intelligence artificielle génère automatiquement du code à partir d’une intention exprimée en langage naturel. Pensé à l’origine pour des profils non techniques, il permet de créer des prototypes, des interfaces ou même des micro-applications sans passer par les langages de programmation traditionnels.
Contrairement aux outils no-code classiques qui reposent sur des interfaces visuelles, le Vibe Coding abaisse encore la barrière technique : c’est la formulation de l’idée qui suffit. Cela en fait une porte d’entrée puissante pour les porteurs de projets, les métiers ou les designers qui souhaitent tester une fonctionnalité sans dépendre d’une équipe de développement.
En entreprise, un levier d’agilité sous conditions
Si cette approche séduit les profils métiers, elle attire aussi l’attention des entreprises. Le Vibe Coding peut accélérer les phases de prototypage, réduire le time-to-market et fluidifier les échanges entre les métiers et la DSI.
Dans un contexte B2B, il peut par exemple être utilisé pour générer rapidement une base de code fonctionnelle à partir d’un cahier des charges, ou créer une interface de test pour valider une hypothèse utilisateur. Il devient alors un outil d’itération rapide, particulièrement pertinent dans les démarches agiles ou les POC.
Mais pour en tirer pleinement parti, il faut en maîtriser les risques. Car si l’IA est capable de produire du code, elle ne garantit ni sa robustesse, ni sa sécurité, ni sa conformité aux standards d’entreprise. Il faut également parler de la qualité du prompt. Pour avoir un résultat probant, la demande doit être claire et précise.
Encadrer la pratique, un impératif pour l’IT
Le code généré automatiquement peut introduire des vulnérabilités non intentionnelles, intégrer des patterns obsolètes ou contourner des règles critiques de sécurité. Si le prompt inclut des données sensibles, on court aussi le risque d’une fuite ou d’une réutilisation non maîtrisée par le modèle. Dans ce contexte, la sécurité-by-design ne peut pas être optionnelle.
Les organisations doivent intégrer, dès la production du code généré, des outils d’analyse statique de sécurité (SAST) et d’analyse de composition logicielle (SCA) au sein de leur pipeline CI/CD, afin d’auditer en continu la qualité et la sécurité du code.
La question de la traçabilité et de la gouvernance est également centrale. L’usage de modèles propriétaires, souvent hébergés sur des plateformes cloud externes, pose des problématiques de propriété intellectuelle, de souveraineté sur le code produit, et de biais algorithmique. Les DSI doivent établir une stratégie IA claire, incluant l’évaluation juridique des outputs, l’adoption potentielle de modèles open source internes, et la définition de politiques de confidentialité sur les prompts.
Conserver la maîtrise du code (output)
Il est essentiel que les développeurs conservent la maitrise du code. Le comprendre, le maitriser pour le valider et le faire évoluer.
Avec l’adoption massive du Vibe Coding, le risque serait d’engendrer une érosion des compétences techniques, en particulier chez les développeurs juniors. Une dépendance excessive aux suggestions de l’IA peut freiner l’apprentissage des fondamentaux : debug, optimisation, conception d’architectures robustes, ou gestion fine des performances.
La formation continue doit donc évoluer : elle ne doit plus uniquement porter sur la production de code, mais sur sa lecture critique, sa revue structurée, sa mise en conformité et son optimisation. Le développeur devient architecte-validateur, garant de la qualité globale du système. Des pratiques comme le pair programming augmenté par IA ou la revue croisée de code généré doivent être intégrées dans les workflows.
Le Vibe Coding constitue une évolution naturelle des outils d’assistance au développement. Bien intégré dans une démarche outillée et encadrée, il peut faire gagner un temps précieux, favoriser la co-création avec les métiers, et ouvrir la production logicielle à de nouveaux profils.
Sa mise en œuvre implique de repenser les processus de développement, les outils de sécurité, la gouvernance des modèles d’IA et la stratégie de formation. Comme souvent avec les technologies émergentes, ce n’est pas la promesse qui compte, mais la maturité avec laquelle on l’implémente.
* Ghali MOUSSAOUI est directeur solutions applicatives chez Intelcia Tech
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.
Dassault Systèmes et Nvidia annoncent un partenariat de long terme pour construire une plateforme d’IA industrielle destinée à renforcer les jumeaux virtuels et à développer des « Industry World Models ».
Leur vision commune est de faire de l’IA un composant essentiel de l’ingénierie, de la production et de la recherche, au-delà des simples preuves de concept. Il prolonge une collaboration de plus de 25 ans entre les deux groupes, initiée autour du logiciel de modélisation 3D, Catia, sur GPU et étendue progressivement à la simulation physique accélérée.
L’ambition affichée est de définir une architecture industrielle partagée pour une IA qualifiée de « mission-critique », ancrée dans la physique, les contraintes techniques et le savoir industriel plutôt que dans des données généralistes.
Un socle technologique combinant Virtual Twin et Omniverse
Dassault Systèmes apporte sa plateforme 3DEXPERIENCE et ses technologies de Virtual Twin, qui couvrent la conception avec Catia, la fabrication avec Delmia et l’ingénierie système. Nvidia fournit son infrastructure d’IA comprenant GPU, CUDA et RTX, ses modèles ouverts Nemotron, ses bibliothèques logicielles accélérées, ainsi que sa plateforme Omniverse dédiée à la simulation physique et à la collaboration 3D.
Les deux entreprises évoquent le concept de « physical AI », une intelligence artificielle capable de comprendre et de raisonner sur le monde physique en s’appuyant sur des modèles validés scientifiquement et des contraintes de domaine. Les bibliothèques d’IA physique d’Omniverse seront intégrées dans les jumeaux virtuels Delmia pour permettre des systèmes de production autonomes et « software-defined ».
Des Industry World Models et des assistants virtuels
Les Industry World Models, des modèles de référence par secteur combinant jumeaux virtuels, données opérationnelles et modèles d’IA, sont destinés à servir de base pour la conception, la simulation et le pilotage de systèmes dans divers secteurs : aéronautique, automobile, sciences de la vie, robotique ou matériaux.
Sur la plateforme 3DEXPERIENCE, ces Industry World Models alimenteront des « Virtual Companions », des agents IA intégrés aux outils métier et capables de fournir des recommandations contextualisées. Basés sur les modèles Nemotron de Nvidia et les modèles de domaine de Dassault, ces assistants sont conçus pour aider ingénieurs, chercheurs et opérateurs à explorer des scénarios, optimiser des conceptions ou ajuster des paramètres de production en temps réel.
Des « AI factories » sur trois continents
Le partenariat inclut un volet infrastructure avec le déploiement d’« AI factories » sur trois continents via Outscale, le cloud de Dassault Systèmes. Ces centres seront équipés de technologies Nvidia pour entraîner et exécuter les modèles d’IA utilisés par les jumeaux virtuels, tout en répondant aux exigences de souveraineté des données, de protection de la propriété intellectuelle et de conformité réglementaire.
De son côté, Nvidia utilisera les outils de modélisation et d’ingénierie système de Dassault pour concevoir ses propres AI factories, notamment celles basées sur la future plateforme Rubin, en s’appuyant sur l’architecture Omniverse DSX Blueprint. Cette réciprocité illustre une approche où chacun applique les modèles et outils de l’autre à ses propres infrastructures.
Plusieurs entreprises sont déjà présentées comme « early adopters » de cette convergence entre Virtual Twin et IA accélérée : Lucid Motors, Bel, l’OMRON Group ou encore le National Institute for Aviation Research. Dans le secteur automobile, l’objectif est d’accélérer le passage du concept à la production tout en améliorant la précision prédictive des simulations de véhicules et de chaînes de traction.
L’intelligence artificielle générative n’est pas seulement un outil de productivité pour les entreprises. Selon une étude publiée par l’ANSSI, elle est une arme supplémentaire dans l’arsenal des cybercriminels et des groupes d’espionnage étatiques.
L’agence nationale de la sécurité des systèmes d’information s’est penchée exclusivement sur les intelligences artificielles génératives. Parmi eux, les fameux grands modèles de langage (LLM) incarnent ce qu’on appelle l’usage dual de l’IA : un même outil peut servir à défendre comme à attaquer.
Certes, l’ANSSI n’a pas encore identifié de cyberattaque totalement autonome pilotée par une IA contre des cibles françaises. Mais l’agence le dit clairement : l’IA permet déjà aux attaquants d’améliorer « significativement le niveau, la quantité, la diversité et l’efficacité » de leurs opérations, surtout contre les systèmes mal protégés. Les modèles sont désormais utilisés tout au long de la chaîne d’attaque, de la reconnaissance initiale jusqu’à l’exploitation finale des données volées.
Des faux profils générés en masse
Les opérateurs de modes opératoires d’attaque (MOA) réputés liés à l’Iran auraient utilisé l’IA générative Gemini de Google à des fins de reconnaissance contre des experts et organisations d’intérêt. En 2024, les opérateurs du MOA Charcoal Typhoon, réputé lié à la Chine, auraient quant à eux utilisé des services d’IA générative pour générer du contenu d’hameçonnage, ciblant notamment Taïwan, la Thaïlande, la Mongolie, le Népal et la France.
Entre 2024 et 2025, les opérateurs du MOA Lazarus, réputé lié à la Corée du Nord, auraient également eu recours à l’IA générative pour créer de faux profils d’entreprises et d’employés sur les réseaux sociaux. L’ANSSI a par ailleurs observé plusieurs sites Internet apparemment générés par IA, servant à héberger des charges malveillantes ou à effectuer de la caractérisation, c’est-à-dire du profiling des internautes. De nombreux cybercriminels exploitent également des services de deepfakes pour quelques dizaines de dollars à des fins d’usurpation d’identités.
Malwares « intelligents »
En 2024, le MOA TA547 aurait utilisé un script PowerShell généré par un LLM pour compromettre une entreprise allemande. Des chercheurs de l’université de New York ont par ailleurs développé PromptLock, un prototype de rançongiciel utilisant dynamiquement des prompts pour générer des scripts à l’exécution, permettant d’exfiltrer et de chiffrer les données.
Google a également identifié Promptflux, un code malveillant polymorphique particulièrement sophistiqué qui prompte l’API Gemini pour réécrire entièrement son code source toutes les heures afin d’éviter la détection. Le développement de tels codes suggère cependant des capacités relativement sophistiquées de la part des développeurs.
En février 2025, le département de cyberdéfense ukrainien a affirmé que des opérateurs russes auraient utilisé des services d’IA générative pour analyser massivement les données exfiltrées de leurs victimes et identifier les informations d’intérêt.
L’IA n’est pas encore autonome… mais ça progresse vite
L’utilisation de l’IA générative pour certaines étapes complexes de la chaîne d’infection, comme la recherche de vulnérabilités, reste limitée. Pour l’instant. L’identification d’une faille de sécurité et le développement de la preuve de concept associée dépendent encore largement de compétences humaines. La plupart des systèmes d’IA générative commerciaux restent trop instables et trop limités pour identifier des vulnérabilités jour-zéro rapidement et en quantité. À l’heure actuelle, aucun cas avéré d’exploitation de vulnérabilité jour-zéro découverte grâce à un modèle d’IA générative n’a été documenté.
Mais les choses bougent très vite. En novembre 2024, le système BigSleep a démontré son efficacité pour la recherche de vulnérabilités dans des codes sources. Plus inquiétant encore, en juin 2025, le système XBOW, développé par d’anciens ingénieurs de GitHub, a soumis des centaines de vulnérabilités, dont certaines critiques, sur différents programmes de bug bounty, après avoir scanné simultanément des milliers d’applications web. La course est lancée.
42 groupes de hackers d’État utilisent déjà l’IA
Un large spectre d’acteurs offensifs utilise désormais les services d’IA générative. En janvier 2025, Google révélait que son modèle Gemini avait été utilisé entre 2023 et 2024 par des groupes cybercriminels ainsi que par au moins 10 modes opératoires d’attaque liés à l’Iran, 20 liés à la Chine, 9 liés à la Corée du Nord et 3 liés à la Russie.
L’utilisation de ces technologies varie considérablement selon les objectifs et le niveau de maturité des acteurs. Pour les groupes les plus sophistiqués, l’IA générative devient un nouveau cadre pratique, similaire à l’utilisation d’outils malveillants génériques comme Cobalt Strike ou Metasploit. Elle leur permet notamment de générer du contenu en masse dans plusieurs langues, de développer du code non signant, d’effectuer des recherches sur des cibles plus rapidement, et potentiellement d’automatiser complètement une chaîne d’attaque à court ou moyen terme.
Pour les hackers moins expérimentés, l’IA générative constitue avant tout un formidable outil d’apprentissage et offre un gain de productivité en répondant à des questions techniques. Dans tous les cas, le verdict est sans appel : l’IA générative permet aux acteurs malveillants d’agir plus rapidement et à plus grande échelle.
WormGPT et FraudGPT
Les modèles d’IA générative comme ChatGPT disposent de garde-fous techniques empêchant leur utilisation à des fins illégales. Les acteurs malveillants cherchent néanmoins à contourner ces limitations par des méthodes d’ingénierie de prompt incluant des formulations ambiguës, des mots-clés spécifiques ou l’utilisation de scénarios fictifs. Ces techniques évoluent constamment et constituent un défi majeur pour les développeurs.
Le « jailbreak » : contourner les barrières morales de l’IA
Dès 2023, des chercheurs en sécurité parvenaient déjà à détourner ChatGPT pour développer un code malveillant polymorphique. En 2024, la situation s’est aggravée avec l’apparition de services de jailbreak-as-a-service comme EscapeGPT ou LoopGPT sur les forums cybercriminels. Moyennant quelques dollars, n’importe qui peut désormais accéder à des prompts préfabriqués pour faire cracher à ChatGPT ce qu’il refuse normalement de produire.
Les IA « débridées » du crime organisé
Mais pourquoi se fatiguer à contourner les protections quand on peut acheter une IA sans aucune limite ? Dès 2023, des services d’IA générative sans garde-fous tels que WormGPT, FraudGPT ou EvilGPT ont fleuri sur les forums cybercriminels ou via des canaux Telegram. Le prix du ticket : environ une centaine de dollars par mois. Des modèles plus récents comme WormGPT 4 seraient même directement entraînés sur des jeux de données spécifiques aux activités cybercriminelles, incluant du code malveillant et des modèles d’hameçonnage. L’industrialisation du crime numérique est en marche.
Quand l’IA devient elle-même la cible : les nouvelles vulnérabilités
Les catégories d’acteurs malveillants susceptibles de cibler spécifiquement les systèmes d’IA semblent similaires à celles qui s’attaquent aux systèmes d’information conventionnels. Mais les systèmes de LLM pourraient être vulnérables à de nouveaux vecteurs d’attaque inédits.
Lors de l’entraînement du modèle, des attaquants peuvent introduire des données corrompues ou fausses. Lors de l’intégration du modèle, il est possible d’y implémenter des portes dérobées. Enfin, lors de l’interrogation du modèle, également appelée inférence, des acteurs malveillants peuvent injecter de fausses informations pour altérer la réponse ou récupérer des informations confidentielles.
« Empoisonnement » des modèles : 250 documents suffisent pour corrompre une IA
Bien qu’aucun incident majeur n’ait été porté à la connaissance de l’ANSSI, le risque est réel et documenté. Des acteurs malveillants pourraient manipuler, modifier et interagir avec les données d’entraînement d’une IA générative. Une telle compromission pourrait mener à l’utilisation de ces modèles à des fins d’altération de données ou au sabotage de systèmes opérationnels.
Le plus inquiétant ? La multiplication de contenus fallacieux générés par IA sur Internet pourrait progressivement polluer les données d’entraînement des modèles et contribuer à diffuser de fausses informations à grande échelle. Une analyse conjointe du UK AI Security Institute et du Alan Turing Institute a d’ailleurs démontré une faille vertigineuse : il serait possible d’empoisonner des modèles d’IA générative à partir de seulement 250 documents malveillants. Pire encore, ce nombre resterait stable indépendamment de la taille des données d’apprentissage du modèle. Autrement dit, corrompre GPT-4 ou GPT-5 nécessiterait le même effort.
L’ANSSI a également observé certains modèles d’IA intégrant dès leur conception des limitations ou des éléments de censure. Dans le cadre du sommet pour l’IA 2024, Viginum a par ailleurs publié un rapport sur les défis et opportunités de l’IA dans la lutte contre les manipulations de l’information.
Attaques par la chaîne d’approvisionnement : le cheval de Troie version IA
Certaines attaques à l’encontre de modèles d’IA pourraient constituer une nouvelle forme redoutable d’attaque par chaîne d’approvisionnement. Des modèles d’IA générative disponibles en sources ouvertes et spécialisés dans la génération de code peuvent être malveillants ou compromis dès le départ, et exécuter du code arbitraire pour installer une porte dérobée dès leur téléchargement. Un piège parfait pour les développeurs pressés.
Les attaquants peuvent également exploiter des failles au sein d’agents Model Context Protocol (MCP), utilisés pour connecter les LLM à des outils externes et à des sources de données. Ces serveurs, qu’ils fonctionnent en local ou à distance, peuvent étendre dangereusement la surface d’attaque s’ils ne sont pas suffisamment sécurisés.
Pratique émergente et particulièrement sournoise, le slopsquatting, consiste à récupérer des noms de paquets imaginés par des IA lors d’hallucinations, puis à en diffuser des versions malveillantes. Les attaquants exploitent ainsi les erreurs de l’IA pour introduire des paquets malveillants dans la chaîne d’approvisionnement logicielle. Quand l’IA se trompe, les hackers en profitent.
100 000 comptes ChatGPT piratés
Les systèmes d’IA participent à l’augmentation de la surface d’attaque, d’autant plus lorsqu’ils sont intégrés dans des contextes logiciels plus larges, déployés dans des environnements classifiés ou utilisés dans certains flux opérationnels de l’entreprise. En l’absence d’un cloisonnement rigoureux physique et des usages, la compromission du système d’IA pourrait mener à l’atteinte à la confidentialité des données qu’il traite et à l’atteinte à l’intégrité des systèmes d’information auxquels il est connecté.
L’utilisation de comptes d’IA par les salariés dans un contexte professionnel peut exposer des informations sensibles à des risques considérables. Entre 2022 et 2023, plus de 100 000 comptes utilisateurs de ChatGPT ont été compromis par des acteurs cybercriminels à l’aide d’infostealers comme Rhadamanthys, puis revendus sur des forums.
Les employés peuvent involontairement générer des fuites de données en fournissant à l’IA des informations sensibles, voire confidentielles. L’exemple le plus emblématique ? En juin 2023, des salariés de Samsung ont divulgué des informations sensibles sur la technologie des semi-conducteurs en utilisant ChatGPT. L’enfer est pavé de bonnes intentions… et de prompts mal réfléchis.
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.
L’ancien temps est révolu. Celui où vous deviez configurer indépendamment chaque brique de votre infrastructure, effectuer manuellement le déploiement de vos environnements, et gérer jour après jour le cycle de vie de vos machines. Place à une gestion beaucoup plus agile et automatisée avec Dell Automation Platform (DAP) et Dell Private Cloud (DPC).
Le portail : Zero Touch Onboarding
Mettons-nous en situation pour comprendre concrètement à quoi ressemble le quotidien d’un administrateur dans ce nouveau modèle de gestion IT. Imaginons que vous souhaitiez déployer une infrastructure de cloud privé, mêlant des environnements VMware, pour héberger vos applications existantes, et des clusters OpenShift pour les applications cloud natives.
Vous avez commandé les serveurs Dell PowerEdge et les baies Dell PowerStore dont vous aviez besoin, puisque rappelons-le, l’approche composable vous permet de déployer indépendamment des ressources de calcul ou de stockage pour être au plus proche de vos exigences réelles. Lorsque vos équipements arrivent, vous les connectez à votre réseau… et c’est à peu près tout.
Il vous suffit ensuite d’accéder au portail Dell Automation Platform pour découvrir que vos nouveaux équipements ont été automatiquement onboardés. Le portail est le plan de contrôle qui va donner toute la visibilité sur l’inventaire matériel, l’état de santé des composants et la conformité du parc. Vous n’avez plus qu’à les assigner à l’orchestrateur pour que leurs ressources rejoignent le pool global et puissent être automatiquement allouées à vos futurs workloads. Bienvenue dans le Zero Touch Onboarding.
Le catalogue : des blueprints prêts à l’emploi
Vos ressources sont prêtes à être consommées. Dell Private Cloud lui, est prêt à entrer en jeu. Car c’est ici que l’intégration des deux solutions va apporter toute sa valeur. Dell Private Cloud va proposer un catalogue de « blueprints », c’est-à-dire un ensemble de fichiers YAML/Python basés sur le standard TOSCA (Topology and Orchestration Specification for Cloud Applications) qui décrit la topologie (serveurs, stockage, réseau, hyperviseur, etc.), les dépendances et les paramètres nécessaires.
Des blueprints existent pour déployer un cloud privé, des infrastructures IA ou encore des environnements Edge. Il est également possible de créer ses propres blueprints. Dans notre cas, vous allez pouvoir rattacher vos licences dans DAP, puis sélectionner les blueprints « Dell Private Cloud deploying VMware » et « Dell Private Cloud deploying Red Hat OpenShift », et laisser DAP faire le reste.
L’orchestrateur : des dizaines d’étapes manuelles automatisées en quelques minutes
Une fois le blueprint sélectionné dans l’interface de DPC, c’est l’orchestrateur de DAP qui entre en scène en arrière-plan. L’orchestrateur constitue le plan de gestion et va exécuter le scénario de déploiement complet décrit dans le blueprint. Par exemple : création d’un cluster vSphere sur PowerEdge, configuration du stockage Dell, mapping des LUN, intégration aux outils de management, etc. Il élimine ainsi le risque d’erreur humaine et remplace des dizaines d’étapes manuelles par un workflow unique et automatisé, déroulé en seulement quelques minutes.
Mais son rôle ne s’arrête pas là : il assure également la gestion du « Jour 2 ». Si une mise à jour de firmware est nécessaire ou si vous devez étendre votre cluster, l’orchestrateur pilote l’opération en toute transparence, garantissant que votre infrastructure reste toujours performante et sécurisée.
Plein cap sur l’après HCI
Dell Automation Platform et Dell Private Cloud sont donc les deux piliers de la nouvelle infrastructure composable qui vient bousculer l’hyperconvergence. Ensemble, les deux logiciels vont permettre aux entreprises de considérablement simplifier et accélérer la modernisation de leur IT, en automatisant les opérations de déploiement, de configuration et de gestion.
Mais ils vont en plus garantir la pérennité des investissements. Grâce à l’agnosticité vis‑à‑vis des systèmes d’exploitation et hyperviseurs tiers, qui évite tout verrouillage technologique, la même infrastructure Dell PowerEdge peut être réutilisée et accueillir de nouvelles images au fil du temps. C’est une nouvelle ère qui commence en 2026.
Connexion
