La Commission européenne prévoit de suspendre temporairement certaines dispositions de sa législation phare sur l’intelligence artificielle (IA), dans un contexte de fortes pressions exercées par les grandes entreprises technologiques et le gouvernement américain, rapporte le Financial Times (FT).
Selon le FT, Bruxelles devrait alléger une partie de son règlement numérique, notamment l’AI Act, qui est entré en vigueur en août 2024, lors de l’adoption d’un « paquet de simplification » prévue le 19 novembre. Cette initiative s’inscrit dans les efforts de l’UE pour renforcer sa compétitivité face aux États-Unis et à la Chine.
Le projet de proposition intervient alors qu’un débat plus large oppose les autorités européennes à la manière dont elles devraient appliquer les règles numériques, face à une vive opposition des géants de la technologie soutenus par l’ancien président américain Donald Trump. L’UE a également dû gérer des pressions de la part de groupes européens inquiets des effets de l’AI Act, considéré comme le régime de régulation de l’IA le plus strict au monde.
D’après un responsable européen cité par le FT, l’UE a « engagé des discussions » avec l’administration Trump sur des ajustements à l’AI Act et à d’autres régulations numériques dans le cadre du processus de simplification.
Un délai supplémentaire pour appliquer les sanctions prévues dans l'IA Act
Bien que la législation soit entrée en vigueur, de nombreuses dispositions ne prendront effet que dans les années à venir. Les principales obligations pour les systèmes d’IA susceptibles de présenter des « risques sérieux » pour la santé, la sécurité ou les droits fondamentaux des citoyens sont prévues pour août 2026.
Le projet de la Commission, consulté par le FT, envisage d’accorder aux entreprises enfreignant les règles sur les usages d’IA les plus risqués un délai de grâce d’un an. Cette mesure pourrait concerner les fournisseurs de systèmes d’IA générative déjà commercialisés avant la date de mise en œuvre, afin de leur laisser « le temps de s’adapter sans perturber le marché ».
Bruxelles propose également de reporter l’imposition d’amendes pour violation des nouvelles règles de transparence jusqu’en août 2027, pour « permettre aux fournisseurs et utilisateurs d’IA de s’adapter ». Le projet vise en outre à simplifier le fardeau réglementaire pour les entreprises et à centraliser l’application de la loi via un bureau européen de l’IA.
Une porte-parole de la Commission a précisé au FT que « plusieurs options sont à l’étude » concernant un éventuel report de certaines dispositions de l’AI Act, tout en affirmant que l’UE reste « pleinement attachée à la loi et à ses objectifs ».
Prière de ne plus faire passer Comet pour Google Chrome.
Amazon l’intime à Perplexity… entre autres doléances consignées dans une lettre de mise en demeure rendue publique.
En toile de fond, la confrontation de deux conceptions du commerce agentique, à cheval entre liberté et protection du consommateur.
(In)satisfaction client et (in)sécurité
Amazon appelle Perplexity à cesser, sans délai, d’utiliser les agents IA de son navigateur Comet pour « s’introduire secrètement » dans son périmètre e-commerce. Il lui demande d’identifier lesdits agents de manière transparente, au nom du droit des fournisseurs de services à superviser l’activité agentique.
Ce droit de supervision doit permettre d’empêcher les comportements qui dégradent l’expérience d’achat et la confiance du client avec, tout en créant des risques pour ses données.
Avec la technologie de Perplexity, l’expérience d’achat n’est pas adéquate, affirme Amazon : Comet ne peut pas sélectionner le meilleur prix, la meilleure méthode de livraison et les recommandations. Il ne donne pas non plus la possibilité d’ajouter des produits à des commandes déjà effectuées.
Quant à la sécurité des données des clients, c’est portes ouvertes, d’après Amazon. Preuve en serait des conditions d’utilisation et la notice de confidentialité de Perplexity, qui lui donnent le droit de collecter mots de passe, clés de sécurité, méthodes de paiement, historiques d’achats et autres données sensibles… tout en excluant toute responsabilité.
Amazon pointe des contournements répétés
Les premiers faits que le groupe américain juge répréhensibles remontent au moins à novembre 2024. À partir de là, à travers la fonctionnalité « Buy with Pro », des commandes ont été réalisées au nom d’utilisateurs, en exploitant une poignée de comptes Amazon – dont des comptes Prime – gérés par Perplexity.
En plus de violer les conditions d’utilisation de Prime, cette pratique aurait engendré une mauvaise expérience client. Par exemple en compliquant les retours de produits.
Perplexity avait fini par accepter d’y mettre un terme. Et, plus globalement, de ne pas déployer d’autres agents dans le Store jusqu’à négociation d’un accord. Il aurait, depuis, renié cette promesse, en changeant de tactique, avec des agents qui se connectent aux comptes des utilisateurs.
Amazon explique avoir découvert cette activité en août. N’étant pas parvenu à faire entendre raison à Perplexity, il avait coupé l’accès à Comet… qui, dans les 24 heures, avait contourné le blocage. Les relances ultérieures n’ont pas plus porté leurs fruits, Perplexity continuant à « déguiser » ses agents en instances Chrome.
Pour Amazon, cette opacité est d’autant plus troublante que les preuves de vulnérabilité de Comet aux injections de prompts se sont accumulées ces derniers temps.
Le groupe américain regrette aussi d’avoir dû dédier des ressources aux investigations et à implémentation de contre-mesures. Soulignant que le risque s’accroîtra probablement maintenant que Comet est ouvert au grand public, il réclame des mesures injonctives et une compensation financière. Non sans prétendre qu’il y a infraction aux Codes pénaux des États-Unis et de Californie.
Perplexity brandit la liberté du consommateur
En réponse, Perplexity ne mâche pas ses mots : cette offensive juridique est « une menace pour tous les internautes ».
De son avis, Amazon devrait se montrer favorable à Comet : une expérience d’achat plus simple signifie davantage de transactions et des clients plus heureux. S’il ne réagit pas ainsi, c’est parce que « son intérêt est de vous servir de la publicité, des résultats sponsorisés, et influencer vos décisions d’achat avec […] des offres embrouillantes ».
Rappelant en filigrane que les authentifiants qu’utilise Comet ne sont jamais stockés sur ses serveurs, Perplexity appelle à ne pas confondre « expérience du consommateur » avec « exploitation du consommateur ». Les utilisateurs veulent des assistants IA qui travaillent pour eux pour pour personne d’autre, ajoute-t-il. Non sans laisser comprendre qu’Amazon, dans sa volonté de travailler à terme avec des fournisseurs d’agents, chercherait d’abord à en encadrer le fonctionnement.
Or, l’IA agentique est justement l’occasion, pour les utilisateurs, de reprendre le contrôle de leurs expériences en ligne, veut croire Perplexity. En ce sens, et au nom de la liberté de choix, une entreprise n’aurait aucunement le droit de discriminer les utilisateurs sur la base des IA qu’ils choisissent pour les représenter.
Perplexity veut croire que de telles aspirations font de lui une cible idéale à intimider. Il invite en tout cas Amazon à ne pas oublier les combats qu’il a lui-même menés pour en arriver là, précisément au nom de la liberté du consommateur et avec la même conviction d’avoir un « produit qui change le monde ». Et de conclure : « Le commerce agentique est une évolution naturelle et les gens en sont demandeurs. Nous exigeons de pouvoir l’offrir.«
Un gatekeeper remis en cause ?
Certains auront fait remarquer que Perplexity est gonflé, vu le contenu de ses propres conditions d’utilisation (l’usage de spiders, de crawlers, de scrapers et autres robots ou « processus automatisés » y est très largement proscrit).
D’autres se réjouissent au contraire de cette résistance, y voyant un moyen de remettre en cause le monopole qu’Amazon aurait sur la recherche de produits sur sa marketplace. Et par là même la position de force dans laquelle il est vis-à-vis des vendeurs tiers.
En intercalant des IA entre lui et le client, Amazon verrait plus globalement son rôle de gatekeeper un tant soit peu remis en cause. Au risque de perdre, infine, du business.
Entre autres arguments, circule aussi celui selon lequel les logiciels avec lesquels l’utilisateur accède à un service ne regardent que lui. À l’inverse, certains estiment que tout propriétaire de site(s) e-commerce doit pouvoir ne pas autoriser des IA dans son écosystème.
Databricks voisinera bientôt avec Snowflake dans le périmètre SAP Business Data Cloud.
L’éditeur allemand avait lancé cette offre SaaS en février 2025. La promesse : pouvoir créer des produits de données entièrement gérés, autour d’un catalogue unifié.
Datasphere, Analytics Cloud et Business Warehouse en sont les principales composantes. Avec, par-dessus, la brique Insight apps (devenue Intelligent applications) : des apps low code embarquant leurs dashboards et leurs modèles sémantiques.
Databricks intégré depuis mai 2025 ; Snowflake pour début 2026
À cet assemblage s’est ajouté, début mai, SAP Databricks*, une édition spécifique déployée en tant qu’extension Business Data Cloud. Puis est arrivé un connecteur (Business Data Cloud Connect) pour faire la jonction avec les instances Databricks externes – là aussi sans ETL, grâce notamment aux partages Delta.
Le même type d’approche va être mis en place avec Snowflake. L’édition spécifique est prévue pour le premier trimestre 2026. Le connecteur, pour le premier semestre.
En attendant, l’éventail des sources de données s’est élargi avec, en particulier, SAP Customer Data Plaform (intégré en juillet) et SuccessFactors (octobre). L’offre a par ailleurs été déployée sur Azure (4 régions dont Amsterdam) et GCP (4 régions dont Francfort) en plus d’AWS (7 régions dont Francfort).
SAP étend ainsi le terrain de jeu potentiel de Joule… et probablement de ses technologies d’automatisation, comme Signavio.
* SAP Databricks fait l’impasse sur certaines fonctionnalités (la fédération de lakehouses, entre autres), tandis que des briques sont remplacées par celles du groupe allemand (la BI par Analytics Cloud, par exemple).
Microsoft a engagé plus de 60 milliards $ auprès « neo-clouds » pour sécuriser la capacité de calcul nécessaire à ses projets d’intelligence artificielle, selon des informations rapportées par Bloomberg.
Cette somme marque une nette accélération des investissements du groupe dans les infrastructures externes, dans un contexte de forte demande pour les services liés à l’IA.
La part la plus importante de ces engagements — environ 23 milliards $— concerne la scale-up britannique Nscale. Cet accord donnera à Microsoft accès à environ 200 000 puces GB300 de Nvidia sur plusieurs sites situés au Royaume-Uni, en Norvège, au Portugal et au Texas.
Depuis le début du mois d’octobre, les engagements financiers de Microsoft envers de » neo-clouds » ont presque doublé, en totalisant les deux derniers accords, totalisant plus de 10 milliards $. : 9,7 milliards avec la société australienne Iren et un contrat de plusieurs milliards avec Lambda La plupart de ces contrats sont conclus pour une durée de cinq ans.
Ces contrats permettent à Microsoft d’accélérer le déploiement de capacités de calcul sans attendre la construction de ses nouveaux centres de données.
Lors de sa dernière communication financière, Microsoft a annoncé une hausse de ses dépenses d’investissement, qui ont atteint près de 35 milliards $ au dernier trimestre, principalement pour des baux de centres de données et des équipements serveurs.
Lorsque vous créez vos index, pensez aux vecteurs binaires.
Une forme de consensus s’est dessinée à ce sujet sur Hacker News, en réaction au retour d’expérience d’un ingénieur américain. L’intéressé y pointe les limites de pgvector… et suggère de lui préférer une base de données vectorielle.
À chaque index ses inconvénients
L’extension donne, rappelle-t-il, le choix entre deux types d’index : IVFFlat (Inverted File with Flat quantization) et HNSW (Hierarchical Navigable Small World). Le premier partitionne l’espace vectoriel en clusters. Le second construit un graphe.
Avec IVFFlat, la création d’index est plus rapide, en plus d’une consommation mémoire inférieure. Et les performances sont acceptables pour de nombreux cas d’usage.
Il est toutefois impératif de spécifier au préalable le nombre de clusters. Ce nombre a une nette influence sur la latence des requêtes. Comme sur la qualité du rappel, qui peut par ailleurs varier en fonction de la distribution des données.
Avec HNSW, le rappel est meilleur sur la plupart des datasets. La performances des requêtes est globalement plus consistante et le système passe bien à l’échelle.
La construction des index nécessite cependant beaucoup de mémoire et peut se révéler lente (plusieurs heures quand on atteint des millions de vecteurs).
Reconstructions et mises à jour
Avec IVFFlat, la clusterisation de nouveaux vecteurs se base sur la structure existante (distribution telle qu’elle était quand on a construit l’index). Avec le temps, il peut en résulter une sous-optimisation. D’où la nécessité de reconstruire régulièrement l’index. Et donc de tolérer une dégradation de la qualité de recherche voire une indisponibilité. Ou bien d’accepter de mettre en place un mécanisme de contournement, tels le provisionnement d’une grande quantité de RAM ou la mise en place d’un index séparé depuis lequel on réalise un échange atomique. S’y ajoute le besoin de gérer les insertions effectuées dans ce laps de temps.
Avec HNSW, chaque insertion exige de mettre à jour le graphe. Donc d’effectuer une traversée pour intégrer le nœud et actualiser les connexions, au risque d’engendrer des contentions de verrou si le taux d’écritures est suffisamment élevé.
Le dilemme du filtrage des recherches
Autre aspect à prendre en compte : les métadonnées, stockées dans d’autres tables ou tout du moins dans d’autres colonnes, et qu’il faut garder synchronisées. Pas si évident avec des reconstructions qui peuvent durer.
Quant aux filtres, faut-il les appliquer avant ou après la recherche vectorielle ? L’une et l’autre méthode ont leurs avantages… et leurs inconvénients.
L’option « avant » fonctionne bien lorsque le filtre est très sélectif. Elle assure une bonne qualité de rappel (k résultats garantis), mais la recherche peut s’avérer lente.
L’option « après » est au contraire adaptée aux filtres permissifs. Elle permet une recherche rapide, mais la qualité de rappel est variable (souvent 0 résultat ou en tout cas moins que k).
D’autres questions se posent si on souhaite appliquer plusieurs filtres. Dans quel ordre le faire ? Faut-il mélanger les deux options ?… PostgreSQL a bien un planificateur, mais pas optimal, son modèle de coût n’ayant pas été élaboré pour la recherche vectorielle. Les choses ne s’arrangent pas à mesure qu’on insère de nouveaux vecteurs, à moins d’enclencher un ANALYZE, qui coûte des ressources, sans pouvoir appréhender totalement la distribution des données.
On en arrive ainsi à devoir réécrire les requêtes pour différents types d’utilisateurs, partitionner les données dans des tables distinctes ou encore à filtrer dans le code de l’application quitte à récupérer plus de données que nécessaire.
L’option pgvectorscale
Les bases de données vectorielles ont résolu ces problèmes, affirme l’ingénieur : planification adaptée, recherche hybride native, indexation en temps réel sans pics de conso mémoire, scaling et monitoring spécifiques… Il mentionne OpenSearch, dont le plug-in k-NN permet de spécifier la stratégie de filtrage ; Pinecone, qui gère automatiquement la sélectivité des filtres ; Weaviate, qui embarque des optimisations pour les patterns de filtrage communs. Et d’appeler à mesurer le coût d’opportunité de pgvector ; en l’occurrence, le temps qu’on consacre à sa maintenance plutôt qu’à d’autres projets.
Il y a sinon, dans le domaine open source, pgvectorscale. Cette version « enrichie » de pgvector ajoute un nouveau type d’index basé sur l’algorithme DiskANN de Microsoft et plus efficace en mémoire. Elle apporte également une méthode de compression améliorée par rapport à la quantification binaire standard.
Il s’agit néanmoins d’une dépendance supplémentaire à gérer et elle n’est pas disponible, entre autres, pour RDS.
Discourse allie pgvector et vecteurs binaires
Le dilemme entre pré- et post-filtrage a été résolu dans la version 0.8.0 avec les scans itératifs, fait remarquer ingénieur chez Discourse. Son entreprise, affirme-t-il, utilise pgvector en production, sur des milliers de bases de données.
Un de ses pairs, travaillant pour un fournisseur de solutions cyber, s’en étonne : à une telle échelle, dans sa société, PostgreSQL a montré ses limites. Une base de données spécialisée (Vespa) lui a donc été préférée. Elle opère un map-reduce sur tous les nœuds de graphe, limitant le nombre de traversées à effectuer.
Si Discourse n’a pas ce souci, c’est parce que chaque forum a sa base de données. Il existe donc une sorte de « sharding gratuit », où chaque instance a en moyenne moins d’un million de topics.
L’entreprise utilise aussi beaucoup la quantification : avant indexation, elle convertir les vecteurs à virgule flottante en vecteurs binaires (chaque dimension est réduite à 1 bit). La majeure partie de leur utilisée est conservée, et la qualité de rappel avec.
Dans beaucoup de solutions, attention au décalage entre le marketing de l’IA et les capacités qu’elle apporte réellement.
Gartner fait la remarque dans le dernier Magic Quadrant du DEM (Digital Experience Monitoring).
Ce marché regroupe, d’après la définition qu’en donne le cabinet américain, les outils qui supervisent la performance des applications métier, des réseaux et de l’infrastructure pour évaluer la qualité de l’expérience des utilisateurs internes et externes, comptes machine inclus.
En ce sens, le DEM est distinct du DEX (Digital Employee Experience Management). Lequel se focalise sur l’expérience des employés au niveau des applications et services approuvés par leur entreprise et avec les terminaux qu’elle leur fournit.
Aucun des 16 fournisseurs classés au Magic Quadrant du DEX n’est d’ailleurs présent dans celui du DEM. On retrouve en revanche, dans ce dernier, plusieurs acteurs que Gartner a listés dans le Magic Quadrant de l’observabilité. En l’occurrence, Datadog, Dynatrace, IBM, ITRS Group, New Relic et SolarWinds.
14 fournisseurs, 4 « leaders »
Datadog, Dynatrace et New Relic font partie des « leaders » de l’observabilité… et aussi du DEM, aux côtés d’un autre offreur, quant à lui spécialisé : Catchpoint.
Pour figurer au Magic Quadrant du DEM, il fallait impérativement fournir, au 16 juin 2025, trois capacités :
Mesurer la performance d’un système informatique sous une perspective front-end externe, par UI ou API
Afficher une représentation « de bout en bout » des requêtes et des parcours en montrant les points d’intersection avec les composants du système
Interroger le système pour déterminer l’impact que sa performance a sur l’expérience ou le comportement de l’utilisateur
Il fallait aussi couvrir au moins 3 des 5 usages suivants :
Identifier « de façon proactive » les dégradations de performance du point de vue de l’utilisateur
Comprendre le comportement et les parcours des utilisateurs
Suivre les SLA des applications importantes
Comparer les performances (benchmarking) et identifier les problèmes avant qu’ils n’affectent les utilisateurs
Identifier les opportunités d’amélioration de la performance des sites web
Seules les solutions SaaS ont été prises en considération. Les versions autohébergées étaient hors périmètre.
L’évaluation se fait sur deux axes. L’un (« exécution ») reflète la capacité à répondre effectivement à la demande du marché. L’autre (« vision ») est centré sur les stratégies.
Sur l’axe « exécution », la situation est la suivante :
Rang
Fournisseur
Évolution annuelle
1
Datadog
=
2
Dynatrace
=
3
New Relic
=
4
Catchpoint
+ 1
5
Splunk
– 1
6
Riverbed
=
7
ITRS Group
+ 1
8
Checkly
nouvel entrant
9
IBM
– 2
10
ManageEngine
+ 1
11
Conviva
nouvel entrant
12
SolarWinds
– 2
13
ip-label
– 1
14
Blue Triangle
– 5
Sur l’axe « vision » :
Rang
Fournisseur
Évolution annuelle
1
Dynatrace
+ 1
2
New Relic
– 1
3
Catchpoint
+ 1
4
Datadog
– 1
5
Riverbed
=
6
IBM
+ 1
7
Conviva
nouvel entrant
8
Splunk
+ 1
9
ITRS Group
– 3
10
ManageEngine
– 2
11
ip-label
=
12
SolarWinds
=
13
Blue Triangle
– 3
14
Checkly
nouvel entrant
Catchpoint, en retard sur le rejeu de session
Catchpoint se distingue par sa roadmap claire et sa vision priorisant l’IA. Autre bon point : l’extensibilité de son offre, que ce soit au niveau de l’API d’exportation/ingestion ou des intégrations avec les outils d’analytics et d’observabilité. Gartner apprécie également l’exhaustivité des ressources de formation et de certification.
Catchpoint est, comme sus-évoqué, le seul des « leaders » à ne pas disposer d’une solution d’observabilité. Une dimension à prendre en compte pour qui souhaiterait une solution unique corrélant DEM et télémétrie back-end/infra. Autre point de vigilance : le rejeu de sessions, jugé immature. Gartner souligne aussi l’absence de tarification publique.
Chez Datadog, la brique IPM manque d’automatisation
Bon point pour Datadog sur le modèle économique « sans limites » qui a remplacé la tarification à l’usage pour l’enregistrement de sessions. En découplant l’ingestion et l’indexation, il permet une conservation sélective. Gartner apprécie aussi la combinaison de cette brique avec le RUM, les heatmaps et l’analyse de funnels pour fournir des insights sur l’adoption des produits. Il salue par ailleurs l’usage d’IA pour la détection d’anomalies et pour la fourniture d’un résumé après corrélation.
Outre le fait qu’il n’est déployable qu’en SaaS, Datadog s’inscrit dans une plate-forme d’observabilité. Il peut ainsi se révéler trop exhaustif pour qui recherche du DEM autonome. Attention aussi sur la partie IPM (Internet Performance Monitoring) : le fonctionnement actuel, très dépendant d’analyses manuelles, contraste avec les approches plus automatisées de solutions concurrentes.
Dynatrace, pas le plus flexible sur le SSO
Dynatrace se distingue en combinant API, Terraform et son CLI Monaco pour permettre le configuration as code. Autre point fort : le masquage multicouche des PII (à la capture, au stockage et à l’affichage, avec des règles par groupes de processus ou par sources de logs). Gartner apprécie aussi les capacités d’analyse fournies sous les bannières Davis AI et Davis CoPilot.
Comme chez Datadog, l’IPM est basique. Dynatrace ne fonctionne par ailleurs pas comme un IdP pour le monitoring synthétique. Ce qui peut limiter la flexibilité pour qui a besoin d’une fédération côté fournisseurou d’une simulation avancée des flux SSO dans les tests. Quant à la flexibilité et à la richesse des insights, elles peuvent se révéler difficiles à prendre en main ; en particulier pour les propriétaires d’apps, surtout lorsqu’il s’agit de paramétrer les dashboards.
Pas d’offre DEM autonome chez New Relic
En gérant Terraform, Pulumi et GitHub Actions, New Relic permet le monitoring as code (intégration de marqueurs, de dashboards ou d’instrumentations dans les pipelies CI/CD). Il se distingue aussi sur le dépannage assisté par l’IA (résumés de sessions, provisionnement de tests synthétiques…). Et sur le niveau de prise en charge des workflows ITSM, grâce à son connecteur ServiceNow bidirectionnel.
Les possibilités d’hébergement de New Relic sont limitées (uniquement aux États-Unis ou en Allemagne), sauf à opter pour des emplacements synthétiques privés. Le modèle à la consommation, s’il est flexible, peut nécessiter une configuration technique avancée pour contrôler les pipelines. Plus globalement, le DEM de New Relic n’est pas commercialisé de manière autonome : il est englobé dans la plate-forme d’observabilité.
En l’absence d’environnement de test, autant construire un nouveau cluster plutôt que d’adapter l’ancien.
LinkedIn a suivi ce raisonnement dans le cadre de la modernisation de l’infrastructure LDAP-Kerberos sécurisant sa plate-forme Hadoop.
La démarche a eu pour contexte une migration massive vers Azure Linux, qui a remplacé CentOS 7 (voir notre article à ce sujet).
Un socle 389 Directory Server
Le cluster Hadoop de LinkedIn réunit aujourd’hui environ 10 milliards d’objets. Sa taille avoisine les 5 exaoctets. L’infrastructure LDAP-Kerberos qui lui est adossée a son propre cluster. Les deux briques sont cohébergées pour éviter les appels réseau. La première, fondée sur des serveurs 389-ds, sert de data store à la seconde.
L’ensemble gère environ 1 million de requêtes par minute, pour trois grands cas d’usage :
Stocker les principaux Kerberos du périmètre Hadoop
Effectuer les recherches d’utilisateurs et de groupes sur les hôtes Linux du cluster Hadoop
Alimenter le plan de contrôle HDFS pour mettre en œuvre les permissions d’accès aux fichiers
Divers points de défaillance unique dans l’ancienne infra
Dans l’ancienne configuration, l’infra LDAP-Kerberos se répartissait sur 2 datacenters. Un cluster comprenait :
Des instances primaires gérant les opérations d’écriture
Des workers gérant les opérations de lecture
Des hubs gérant la réplication des données des instances primaires vers les workers
Le trafic en écriture était dirigé vers une instance primaire dans un datacenter, lequel répliquait les transactions vers une instance primaire dans l’autre datacenter.
Chaque datacenter hébergeait un hub et plusieurs workers en scale-out. L’équilibrage de la charge entre les workers était assurée par HAProxy. Les clients accédaient à l’annuaire via une URL qui résolvait les adresses IP de 4 instances HAProxy en utilisant un DNS round-robin.
Ce système présentait des limites :
Points de défaillance unique au niveau des instances primaires (risque d’échec des écritures lorsque l’une d’elles tombe) et des hubs (risque de désynchronisation des workers)
Activités de maintenance complexifiées par ces points de défaillance
Instances paramétrées manuellement à l’aide d’un savoir informel
Absence d’environnement de test
Cluster utilisant RHEL/CentOS, que LinkedIn avait presque entièrement abandonné
LinkedIn adopte une topologie en étoile
Pour éliminer les points de défaillance unique, 4 instances primaires ont été configurées en étoile. Deux dans chaque datacenter, chacune répliquant vers et depuis toutes les autres. Cette architecture favorise la maintenance, ainsi que le basculement d’un datacenter à l’autre.
Chaque datacenter héberge 3 hubs. Tous réceptionnent le trafic de réplication de l’ensemble des instances primaires (pas seulement celles situées dans le même datacenter). Ils peuvent ensuite répliquer vers tous les workers de leur datacenter respectif.
Pour le trafic en lecture, LinkedIn n’a pas effectué de changements majeurs. La répartition se fait toutefois désormais à l’appui de 8 instances HAProxy (4 dans chaque datacenter).
Éviter les conflits en écriture : l’astuce CNAME
Le modèle de cohérence de LDAP proscrivait tout acheminement du trafic en écriture vers plusieurs instances primaires en simultané (risque de conflits). L’option backup de HAProxy donc a été envisagée pour le diriger systématiquement vers la même instance primaire et ne basculer vers une autre qu’en cas d’indisponibilité. Elle n’a cependant pas été retenue vu la délicatesse de faire fonctionner un serveur d’annuaire sécurisé par GSS-API (authentification Kerberos pour LDAP lui-même) derrière un load balancer.
Lorsqu’un client utilise GSS-API pour accéder à un serveur d’annuaire, il s’appuie sur un principal de service qui inclut le nom DNS du service. Ce nom, il l’obtient par une recherche inversée sur l’adresse IP finale détectée pour le serveur d’annuaire.
Pour que l’authentification du client réussisse, le serveur doit avoir un keytab qui contient le principal de service en question. Le problème pour LinkedIn a été que le client utilise le nom DNS du loadbalancer dans le principal de service, et qu’il utilise ce loadbalancer en tant que proxy. Le nom DNS du loadbalancer doit donc être présent dans le keytab.
Ce n’est pas problématique tant qu’on peut faire en sorte que la recherche DNS inversée pour toutes les adresses IP d’instances du loadbalancer résolve le même nom. Ce n’était pas possible avec le système de découverte de services par DNS mis en place chez LinkedIn.
Il a donc été décidé d’utiliser un CNAME pointant vers l’instance primaire voulue. Pour gérer les actions de maintenance et les incidents, il fallait un mécanisme automatisé par lequel ce CNAME serait « basculé » vers une autre instance primaire. LinkedIn l’a concrétisé avec un service externe qui contrôle en continu les ports kadmind (749) et ldaps (636) et bascule si nécessaire en mettant à jour le DNS.
Standardiser pour automatiser
Pour simplifier davantage la maintenance, LinkedIn a migré cette infrastructure LDAP-Kerberos sur sa stack de déploiement standardisée. Les deux composantes y ont été définies comme services, avec des commandes de contrôle utilisées par l’agent de déploiement. Cela a permis d’automatiser des tâches comme la création d’index LDAP, le paramétrage de la réplication et le rafraîchissement des certificats TLS.
La réplication est intégrée dans la commande « start » pour le service LDAP. Elle découvre automatiquement les fournisseurs pour une instance donnée en s’appuyant sur la topologie de déploiement. Ainsi, un worker tentera de découvrir les hubs situés dans le même datacenter que lui, puis de négocier avec eux des accords de réplication. Une fois la jonction établie, le fournisseur pousse régulièrement les changements vers le consommateur, de manière incrémentale.
Deux tâches cron pour superviser les workers
LinkedIn a construit un cluster de test et un cluster de préprod, ce dernier étant intégré à un CI/CD pour effectuer les tests d’intégration.
La migration a démarré par le trafic en lecture (le plus simple à gérer grâce à l’usage existant de HAProxy). Pour s’assurer que les workers de l’ancien et du nouveau cluster restent synchronisés, une réplication a été paramétrée entre l’ancienne instance primaire et la nouvelle. Le trafic a alors été progressivement redirigé en modifiant les workers enregistrés dans HAProxy.
Afin que tous les workers soient à jour, LinkedIn a introduit un mécanisme de supervision du délai de réplication. Il implique deux tâches cron. L’une horodate, toutes les 30 minutes, un enregistrement LDAP x sur l’ancienne instance primaire. L’autre s’exécute sur les workers : toutes les minutes, elle calcul le délai de réplication. La formule : temps actuel – (valeur de x dans ce worker + 30 minutes).
Une minute d’interruption pour basculer les écritures
Pour le trafic en écriture, il a d’abord été envisagé d’exploiter le dual write afin de parvenir à un basculement sans interruption. L’idée a été abandonnée à défaut d’une manière simple d’activer ce mécanisme sur TCP avec un proxy. Il s’agissait par ailleurs d’éviter la complexité d’un système de commit/rollback pour assurer la persistance des écritures entre les deux clusters.
Partant, LinkedIn a toléré une interruption d’environ 1 minute. Il s’est basé sur l’URL utilisée par les clients produisant du trafic en écriture. Cette URL contenait un enregistrement DNS A pointant vers l’adresse IP de l’ancienne instance primaire. Il a fait en sorte d’éteindre cette instance puis d’intervertir l’enregistrement DNS avec un enregistrement CNAME pointant vers le nouveau cluster. Grandes étapes de la démarche :
Réduire le TTL de l’enregistrement à 1 minute
Arrêter la réplication entre l’ancienne instance primaire et la nouvelle
Éteindre l’ancienne instance
Créer, dans le système DNS, une transaction unique qui supprime l’ancien enregistrement et crée le nouveau
Valider les écritures vers le nouveau cluster une fois les changements DNS propagés
La définition d’un TTL d’une minute a offert une forme de garantie, en facilitant le retour du trafic en écriture vers l’ancien cluster en cas de problème.
Pour couvrir le cas où il aurait fallu revenir complètement à l’ancien cluster, LinkedIn s’est appuyé sur une sauvegarde périodique du changelog de réplication des nouvelles instances primaires. Ce backup aurait contenu les transactions réalisées sur les 14 derniers jours. Un script idempotent aurait alors appliqué une diff.
Du pétrole aux algorithmes, il n’y a qu’un pas que Riyad et Abou Dhabi sont en train de franchir à grande vitesse. Les grandes compagnies pétrolières et fonds souverains du Golfe redéploient massivement leurs revenus énergétiques vers l’intelligence artificielle, redessinant au passage la carte mondiale de l’influence technologique.
Aramco et Adnoc, nouveaux champions de la tech
La mue est spectaculaire. Saudi Aramco et Abu Dhabi National Oil Company (Adnoc) ne se contentent plus d’extraire du pétrole. À Riyad, le géant pétrolier a pris une « participation minoritaire significative » dans Humain, la société d’IA lancée par le Public Investment Fund (PIF).
A Abou Dhabi, Adnoc détient 49% d’AIQ, une co-entreprise spécialisée dans l’IA pour le secteur énergétique, aux côtés de G42, le mastodonte technologique présidé par le cheikh Tahnoon ben Zayed Al Nahyan, conseiller à la sécurité nationale et frère du président des Émirats.
Les chiffres donnent le vertige. Aramco a économisé quelque 6 milliards $ en deux ans grâce à la numérisation et prévoit d’injecter 2 milliards supplémentaires dans sa filiale digitale d’ici 2028. « Nous nous considérons comme une entreprise technologique qui fournit de l’énergie », résume sans détour son directeur général, Amin Nasser. Le message est clair : le pétrole finance désormais la révolution numérique.
4 000 milliards $ en quête de rendement
Les fonds souverains du Golfe ont les reins solides. Avec plus de 4 000 milliards $ d’actifs sous gestion, du Qatar Investment Authority (QIA) à Mubadala et ADQ, ils font partie des rares investisseurs capables de financer les infrastructures colossales nécessaires à l’IA.
Le QIA vient de prendre une participation importante dans Anthropic, dans le cadre d’un tour de table de 13 milliards $ valorisant l’entreprise à 183 milliards. Le fonds qatari prévoit jusqu’à 25 nouveaux investissements technologiques d’ici fin 2026, selon son responsable du pôle TMT, Mohammed Al-Hardan.
À Riyad, les géants américains se bousculent. Humain attire l’attention de Blackstone et BlackRock, qui ont engagé des discussions préliminaires pour investir plusieurs milliards dans des centres de données et infrastructures numériques dans le royaume, en appui à la Vision 2030 du prince héritier Mohammed ben Salman.
Pour Sara Martins Gomes, directrice de l’IA et des données pour le Moyen-Orient chez Deloitte, citée par Bloomberg, la formule est frappante : « L’IA est le nouveau pétrole : elle offrira l’influence de demain. » Ces investissements servent à la fois à générer des rendements et à renforcer le poids diplomatique du Golfe dans un monde où la technologie s’impose comme un facteur de puissance.
MGX, la machine de guerre d’Abou Dhabi
L’exemple le plus frappant de cette ambition s’appelle MGX. Créé en mars 2024 par Mubadala Investment et G42, ce fonds d’investissement émirati vise à dépasser les 100 milliards $ d’actifs. Dirigé par Ahmed Yahia Al Idrissi, ancien responsable des investissements directs de Mubadala, MGX est devenu le bras armé de la stratégie d’IA d’Abou Dhabi.
Son carnet d’adresses impressionne. MGX a déjà investi dans OpenAI, xAI (la société d’Elon Musk) et Databricks. Le fonds s’est associé à BlackRock et Microsoft dans un projet de 30 milliards $ destiné à construire des entrepôts de données et des infrastructures énergétiques. MGX prévoit également de contribuer à hauteur de 7 milliards $ au programme Stargate, un projet de 100 milliards lancé par le président américain Donald Trump pour financer des infrastructures d’IA, aux côtés d’OpenAI, SoftBank et Oracle.
La force de frappe est redoutable. En combinant la puissance financière de Mubadala (330 milliards $ d’actifs) et l’expertise technologique de G42, MGX a également renforcé son équipe avec des talents venus de McKinsey, d’EQT AB et du secteur des semi-conducteurs.
Le cheikh Tahnoon ben Zayed, qui supervise un empire d’environ 1 500 milliards $, a multiplié ces derniers mois les rencontres stratégiques : Jensen Huang (Nvidia), Ruth Porat (Alphabet), Larry Fink (BlackRock) et Elon Musk. Objectif : consolider la position du Golfe dans la chaîne mondiale de valeur de l’IA.
Washington surveille, Pékin guette
Mais tout n’est pas si simple. Ces initiatives se déploient dans un contexte diplomatique délicat. Les États-Unis ont exprimé des inquiétudes quant aux liens passés de G42 avec la Chine, incitant l’entreprise à rompre toute coopération avec Pékin pour maintenir ses relations avec Washington.
Pour les États du Golfe, l’IA représente bien plus qu’une opportunité financière. C’est un instrument de souveraineté dans un monde où la puissance se mesure désormais en pétaflops autant qu’en barils. Leurs investissements massifs, soutenus par des ressources énergétiques abondantes et un coût de l’électricité particulièrement bas, leur permettent d’occuper une place stratégique dans un secteur dominé jusqu’ici par les États-Unis et la Chine.
« Construire la puissance de calcul mondiale exige des ressources énergétiques considérables or, ici, elles sont disponibles et bon marché.» affirme Sara Martins Gomes.
La Bourse, séduite par la stratégie IA de Qualcomm ? La dernière annonce a en tout cas fait mouche.
Le groupe américain a officialisé deux cartes accélératrices pour l’inférence : l’AI200 et l’AI250. Il compte commercialiser la première en 2026 ; la seconde en 2027.
Quant à la spec sheet, on repassera. Tout au plus Qualcomm met-il en avant les 768 Go de LPDDR que gérera l’AI200. Et l’architecture de l’AI250, censée procurer « une bande passante mémoire plus de 10 fois plus efficace »…
Au-delà des produits, il y a un premier client. En l’occurrence, HUMAIN, entreprise que le royaume d’Arabie saoudite a fondée cette année pour porter sa stratégie IA.
Un protocole d’entente avait été signé en mai, à l’occasion d’une visite de Donald Trump. Pour Qualcomm, il impliquait à la fois des travaux côté datacenter (développement de CPU, notamment) et en périphérie (puces Snapdragon et Dragonwing).
Voilà que le protocole d’entente devient un « programme de collaboration ». Dans ce cadre, HUMAIN vise 200 MW de capacité en AI200 et AI250… que Qualcomm semble amené à lui fournir en racks.
Face aux GPU NVIDIA, l’argument du rapport performance par watt
Pour le moment, la carte accélératrice de référence chez Qualcomm est l’AI 100 Ultra. Ses principales caractéristiques :
PCIe 4.0 x16
128 Go LPDDR4x
576 Mo SRAM
150 W
870 TOPS (INT8)
288 Tflops (FP16)
Commercialisée depuis environ un an, l’AI 100 Ultra associe 4 XPU AI 100. Ces puces, annoncées en 2019, furent livrées à partir de 2021. Cerebras Systems, en particulier, en fut client. Elles sont aujourd’hui déployées entre autres chez Cirrascale (États-Unis), Core42 (Émirats arabes unis) et chez AWS (instance EC2 DL2q).
Étant dédiée à l’inférence, l’AI 100 Ultra s’est, dans une certaine mesure, distinguée sur cet exercice vis-à-vis des GPU NVIDIA en matière de rapport performance par watt. D’autant plus que les SoC AI 100 peuvent être alloués individuellement à des workloads.
Un récent article émanant de l’université de San Diego l’illustre. Il rend compte d’une expérimentation effectuée dans le contexte du NRP (National Research Platform, socle Kubernetes utilisé par environ 300 équipes de recherche sur une centaine de sites). 12 modèles de langages open source (124M à 70B) ont été testés, avec vLLM, sur 30 configurations (deux paramètres variaient : le nombre de tokens en sortie et le nombre de requêtes concurrentes).
Les résultats à 200 tokens et 4 requêtes parallèles sont compilés dans le tableau ci-dessous. Le rapport souligne que pour les atteindre, une étape préliminaire de plusieurs heures a été nécessaire : convertir les modèles au format ONNX, puis au format propriétaire QPC (Qualcomm Program Container).
Réalisation d’un corridor de l’hydrogène, réforme du mécanisme d’ajustement carbone aux frontières, élaboration d’une feuille de route commune sur l’espace… Autant d’éléments inscrits dans le programme d’action économique franco-allemand adopté fin août.
On y trouve aussi un engagement à coopérer sur les environnements de travail numériques, les infrastructures et les biens numériques publics.
Sur le premier point, les deux pays expriment essentiellement le vœu d’aligner La Suite Numérique et openDesk pour aller vers un « écosystème commun incluant le secteur privé ». Sur le deuxième, il s’agit notamment de lancer des pilotes autour du portefeuille numérique européen. Le troisième implique, en particulier, des travaux conjoints sur la mise en œuvre d’un consortium pour les communs numériques : DC-EDIC.
La Commission européenne vient d’approuver la création de cette structure dont la France et l’Allemagne sont fondatrices aux côtés des Pays-Bas et de l’Italie. Belgique, Luxembourg, Pologne et Slovénie participent en tant qu’observateurs. Le lancement officiel est prévu le 11 décembre 2025, avec un siège statutaire à Paris.
Un deuxième EDIC basé en France
Le mécanisme de l’EDIC (European Digital Infrastructure Consortium) a été institué parallèlement au programme politique 2030 pour la décennie numérique. Il est censé « fournir un cadre juridique pour investir dans des projets multinationaux qui, compte tenu de leur ampleur, ne peuvent être mis en place efficacement par un seul État membre ». Dit autrement, permettre la mise en commun de ressources pour développer des infrastructures numériques.
Trois EDIC sont pour le moment établis : CitiVERSE, EUROPEUM-EDIC et ALT-EDIC.
CitiVERSE, basé à Valence (Espagne), se focalise sur les jumeaux numériques pour la planification urbaine. Il réunit 14 pays dont la France. Son objectif : fédérer 100 villes à l’horizon 2026.
EUROPEUM-EDIC est censé poursuivre les activités du Partenariat blockchain européen en étendant l’écosystème et les cas d’usage de l’EBSI (European Blockchain Services Infrastructure).
ALT-EDIC (Alliance for Language Technologies) est basé en France, à Villers-Cotterêts, dans le château qui abrite la Cité internationale de la langue française. Nous avions évoqué son cas en début d’année, lorsque débutait le projet OpenEuroLLM, qu’il coordonne.
La promesse du guichet unique
Les jalons de DC-EDIC avaient été posés mi-2024 avec la soumission d’une prénotification à la Commission européenne. L’Italie n’était pas encore dans la boucle – l’Estonie l’était, en revanche. Les principaux objectifs étaient alors déjà définis. En l’occurrence :
Construire une communauté européenne pour les communs numériques
Création d’un partenariat « public-civique », organisation d’événements et de réseautage, promotion des communs numériques.
Faciliter le financement de projets
Constituer un guichet unique, accompagner les levées de fonds, coordonner les appels à propositions.
Soutien au développement, à la maintenance et à la mise à l’échelle
Aide technique et juridique, fourniture de ressources (hébergement, forge, installations de test/expérimentation).
Participation à des projets de communs numériques
Les documents fondateurs de DC-EDIC furent signés en juillet 2025.
À consulter en complément, un récent point d’étape sur quelques projets lauréats, en France, de l’appel à projets « Communs numériques pour l’IA générative ».
Un an après l’annonce de son lancement, Amazon Web Services (AWS) a annoncé la mis en service de Rainier, son cluster de calcul haute performance, dont l’infrastructure est répartie sur plusieurs centres de données aux États-Unis.
Le projet s’appuie sur les puces Trainium2, développées en interne par Amazon pour l’apprentissage automatique. Environ 500 000 unités sont intégrées dans la première phase du cluster, interconnectées via un réseau à très faible latence destiné à optimiser les échanges entre nœuds de calcul.
AWS met en avant la scalabilité et la résilience multi-site de l’ensemble. Le cœur du dispositif se situe dans l’État de l’Indiana, où Amazon investit plus de 11 milliards $ dans un centre de données de nouvelle génération. D’autres installations complémentaires sont prévues sur plusieurs sites américains afin d’assurer la continuité de service et la répartition de la charge.
Anthropic, premier utilisateur du cluster
Le principal client identifié est Anthropic, concepteur du LLM Claude, qui exploitera Rainier pour l’entraînement de ses modèles de grande taille, avec un objectif d’utilisation de plus d’un million de puces Trainium2 d’ici fin 2025.
Avec Rainier, Amazon renforce son positionnement dans le cloud haute performance et les infrastructures d’IA. Le groupe entend se placer comme un fournisseur clé d’environnement d’entraînement à grande échelle, aux côtés des autres hyperscalers qui développent également leurs propres architectures dédiées.
Nvidia a franchi un nouveau cap historique, ce mercredi 29 octobre, en devenant la première société cotée en bourse à atteindre une capitalisation de 5 000 milliards $. Cette progression reflète son essor spectaculaire depuis l’émergence de l’IA générative et sa transformation d’un fabricant de puces graphiques de niche en acteur central de l’industrie mondiale de l’IA.
Son CEO, Jensen Huang, a révélé des commandes de puces d’une valeur de 500 milliards $ et annoncé la construction de sept supercalculateurs pour le gouvernement américain. Les discussions prévues entre le président américain Donald Trump et le président chinois Xi Jinping incluront également sa puce Blackwell, dont les ventes sont limitées par les contrôles à l’exportation américains.
Nvidia décolle avec le lancement de ChatGPT
Depuis le lancement de ChatGPT en 2022, le cours de l’action Nvidia a été multiplié par douze, accompagnant la progression du S&P 500 vers des niveaux record et suscitant des débats sur la possibilité d’une surévaluation du secteur technologique. La capitalisation actuelle dépasse celle du marché total des cryptomonnaies et représente environ la moitié de la valeur de l’indice européen Stoxx 600.
À la valorisation actuelle, la participation de Jensen Huang serait estimée à environ 179,2 milliards $ ce qui en ferait la huitième personne la plus riche au monde selon Forbes. Né à Taïwan et installé aux États-Unis dès l’âge de neuf ans, Huang dirige Nvidia depuis sa création en 1993.
Les analystes estiment que la hausse reflète la confiance des investisseurs dans la croissance continue des dépenses en IA, tout en mettant en garde contre des valorisations potentiellement élevées. « L’expansion actuelle de l’IA repose sur quelques acteurs dominants qui financent la capacité de chacun. Dès que les investisseurs demanderont des retours sur flux de trésorerie plutôt que des annonces de capacité, certains mécanismes pourraient s’interrompre », souligne Matthew Tuttle, PDG de Tuttle Capital Management, cité par Reuters.
La position dominante de Nvidia a également attiré l’attention des régulateurs mondiaux, les restrictions américaines sur les puces avancées en faisant un outil stratégique pour limiter l’accès de la Chine à certaines technologies IA.
En achevant sa transformation en public benefit corporation (PBC), un statut hybride qui combine finalité lucrative et mission d’intérêt général, OpenAI redéfinit la nature du lien avec Microsoft, son principal partenaire depuis 2019.
Après une négociation de près d’un an, l’accord accorde à Microsoft une participation de 27 % du capital, valorisée environ 135 milliards $, dans une entreprise estimée à près de 500 milliards $. Mais contrairement à d’autres prises de participation stratégiques, celle-ci ne confère aucun pouvoir de contrôle.
La création d’un nouvel ensemble, OpenAI Group PBC, permet désormais à l’inventeur de ChatGPT d’attirer des investisseurs tout en restant placée sous la supervision d’une structure à but non lucratif, la OpenAI Foundation, qui conserve 26 % du capital et le droit exclusif de nommer les administrateurs du conseil d’administration.
Fin de l’exclusivité pour Microsoft
Le partenariat entre les deux entreprises reposait jusqu’ici sur un modèle d’exclusivité : OpenAI hébergeait ses modèles sur le cloud Azure de Microsoft, qui disposait en retour d’un droit de premier refus sur toute collaboration future et d’un pouvoir de veto sur certaines opérations financières.
Ces clauses ont été supprimées. OpenAI pourra désormais faire appel à d’autres fournisseurs de cloud, y compris Google Cloud, Amazon Web Services ou Oracle, tout en maintenant un engagement contractuel d’investir 250 milliards $ sur Azure au cours des prochaines années, sans plus de précision.
Pour Microsoft, cette perte d’exclusivité s’accompagne de solides contreparties. Le groupe de Redmond conservera un accès garanti aux modèles et technologies d’OpenAI jusqu’en 2032, y compris à d’éventuels systèmes d’intelligence artificielle générale (AGI), et percevra 20 % des revenus de la société tant qu’un comité d’experts indépendants n’aura pas confirmé l’atteinte de ce seuil.
Public Benefit Corporation, c’est quoi ?
Créé aux États-Unis, le statut de public benefit corporation (PBC) impose aux dirigeants de prendre en compte, en plus de l’intérêt des actionnaires, celui du public et des parties prenantes.
Pour OpenAI, ce modèle permet de lever des capitaux privés tout en maintenant une obligation statutaire de poursuivre un objectif éthique : garantir que l’IA serve l’intérêt général.
Une gouvernance rééquilibrée
L’un des enjeux majeurs de la restructuration concerne la gouvernance. Les procureurs généraux du Delaware et de Californie ont approuvé le montage après avoir obtenu des garanties sur la primauté de la sécurité et de la mission caritative dans les statuts.
La fondation, rebaptisée OpenAI Foundation, est désormais la gardienne de cette mission.
Elle prévoit d’utiliser une partie de sa participation, valorisée environ 130 milliards $ pour financer des projets de recherche médicale et des programmes destinés à renforcer la sûreté des modèles d’IA.
Sam Altman, cofondateur et directeur général, a déclaré vouloir faire de la fondation « la plus grande organisation à but non lucratif au monde ». A titre de comparaison, la Fondation Gates qui figure dans le top 3 mondial disposait d’une dotation estimée à environ 77,2 milliards $ fin 2024 .
Gouvernance : la mission contre le capital
La fondation conserve le droit de nommer le conseil d’administration, mais reste minoritaire au capital.
Sa capacité à imposer des décisions contraires aux intérêts économiques des actionnaires sera l’un des tests-clés du modèle PBC appliqué à une entreprise technologique de cette envergure.
Microsoft, partenaire stratégique mais pas dominant
La nouvelle configuration transforme Microsoft en allié stratégique plutôt qu’en actionnaire dominant.
L’entreprise de Redmond conserve un accès privilégié à la technologie d’OpenAI et reste un investisseur de poids, mais sa capacité d’intervention directe est désormais limitée.
Cette évolution met fin à plusieurs mois de tensions : OpenAI souhaitait plus de souplesse pour diversifier ses partenariats, tandis que Microsoft cherchait à sécuriser l’accès à la technologie qu’elle intègre dans ses produits Copilot et Office 365.
Concurrence : un partenariat sous surveillance
La fin de l’exclusivité Azure pourrait atténuer la pression réglementaire.
Aux États-Unis comme en Europe, les autorités examinent les alliances entre grands groupes du cloud et start-up d’IA pour vérifier qu’elles ne faussent pas la concurrence.
En se repositionnant comme partenaire, Microsoft évite de tomber sous le coup d’un contrôle de type « prise de contrôle déguisée ».
Vers l’autonomie financière et une future IPO
Le passage au statut de PBC ouvre aussi la voie à de nouvelles levées de capitaux. Les investisseurs historiques — SoftBank, Thrive Capital, Andreessen Horowitz ou Sequoia — peuvent désormais détenir de véritables actions.
Cette ouverture permettra à OpenAI de financer la prochaine génération de modèles d’IA, dont les coûts de développement se chiffrent déjà en dizaines de milliards de dollars.
Une introduction en bourse est même désormais envisagée à moyen terme, même si Sam Altman affirme qu’aucune échéance n’est fixée.
La relation entre Microsoft et OpenAI entre ainsi dans une phase de coopétition maîtrisée : les deux entreprises demeurent partenaires sur les modèles et produits, mais poursuivent aussi des stratégies de développement distinctes.
Microsoft continue à investir dans ses propres technologies et à collaborer avec d’autres acteurs de l’IA, notamment Anthropic, pour ses outils Copilot.
OpenAI, de son côté, consolide sa position d’acteur indépendant capable de négocier à égalité avec les géants du numérique.
La plupart des documents sont conçus pour être lus par des humains. Partant, ils peuvent être analysés de façon plus approfondie par des modèles de vision que par des modèles de langage.
Le projet Colette repose sur ce postulat. Cofinancé par Airbus, le CNES et la société toulousaine Jolibrain, il a produit un logiciel open source de déploiement de LLM avec une brique de RAG visuel (tous les documents sont transformés et analysés sous forme d’images).
Colette s’appuie sur une architecture qui a ses racines à CentraleSupélec : ColPali. Présentée début 2025, elle met à profit un VLM entraîné pour indexer des documents purement à partir de leurs caractéristiques visuelles.
ColPali se retrouve aussi, entre autres, chez Morphik. Cette start-up Y Combinator a focalisé son offre sur le RAG. Elle a amélioré les performances en exploitant la méthode MUVERA – qui permet de contourner l’approche multivectorielle de ColPali – et la base de données vectorielle Turbopuffer.
DeepSeek-OCR : la modalité image comme moyen de compression
DeepSeek étudie également cet aspect. Il y a récemment consacré un article scientifique, sous un angle particulier : la modalité vision comme moyen de compresser l’information textuelle.
Ses travaux se matérialisent avec l’architecture DeepSeek-OCR. En son centre, DeepEncoder, qui encode les documents sous forme « tokens image ». Il exploite un modèle SAM (segmentation avec attention locale par fenêtre) et un modèle CLIP (attention globale). Avec, entre les deux, un module convolutionnel de sous-échantillonnage.
DeepEncoder compte environ 380 millions de paramètres (80 pour le SAM, 300 pour le CLIP). Il gère deux modes d’entrée. D’un côté, la résolution native (4 modes : Tiny et Small, où les images sont directement redimensionnées ; Base et Large, où on utilise du padding pour préserver le ratio d’origine). De l’autre, la résolution dynamique (combinaison de deux résolutions natives ; Gundam, par exemple, associe du 640 x 640 en attention locale et du 1024 x 1024 en attention globale).
Le décodage est dévolu à un modèle DeepSeek MoE 3B à 570 millions de paramètres actifs (6 experts actifs sur 64 + 2 experts partagés).
On a d’abord entraîné DeepEncoder, puis DeepSeek-OCR dans son ensemble, à partir de deux jeux de données. L’un comprenant des PDF dans une centaine de langues avec éventuellement des images intégrées. L’autre axé sur des éléments spécifiques : graphes, formules chimiques, figures géométriques planes…
La perspective d’un mécanisme d’oubli graduel
DeepSeek-OCR a notamment été mis à l’épreuve sur un sous-ensemble du benchmarkFox. En l’occurrence, des documents en anglais comprenant de 600 à 1300 tokens texte. C’est de là que DeepSeek tire les principaux indicateurs de performance qu’il annonce en introduction de son article.
Avec un rapport de compression de 9-10x (1 token image pour 9 ou 10 tokens texte), le décodeur avoisine 97 % de précision OCR. Au-delà, les performances baissent (90 % à 10-12x, 60 % à 20x). DeepSeek y voit deux raisons. D’une part, le rapport entre la longueur des documents et la complexité de leur disposition. De l’autre, le fait qu’aux résolutions les plus basses (Tiny et Small), les textes longs deviennent « flous ».
Le premier élément peut être résolu par un rendu sur une page à disposition unique, estime DeepSeek. Le second peut être mis à profit pour reproduire une forme de mécanisme d’oubli : l’historique « froid » serait converti en images qui seraient ensuite progressivement compressées.
L’approche est, globalement, d’autant plus intéressante qu’elle n’occasionne pas de surcharge (les systèmes multimodaux exigent intrinsèquement un encodeur de vision).
Des diapos aux journaux, la nécessité de plusieurs modes d’encodage
En « conditions réelles » (OmniDocBench), DeepSeek retient que :
Le mode Small (100 tokens) produit de meilleurs résultats que GOT-OCR2.0 avec 2,5 fois moins de tokens.
Le mode Large (400 tokens) est au niveau des modèles OCR à l’état de l’art.
Avec moins de 800 tokens, la méthode Gundam s’en sort mieux que MinerU2.0 avec environ 7000 tokens.
Certaines catégories de documents nécessitent peu de tokens pour un résultat satisfaisant. Les diapositives, par exemple (64 tokens suffisent). Pour les livres et les rapports, 100 tokens est l’idéal. Avec les journaux (4000 à 5000 tokens), le mode Gundam, voire Gundam-master, est nécessaire.
DeepSeek annonce que son architecture est capable de générer 33 millions de pages de données par jour en utilisant 20 nœuds de 8 GPU A100-40G.
Anthropic étend son accord avec Google Cloud afin d’utiliser jusqu’à un million de puces spécialisées en intelligence artificielle (IA), connues sous le nom de Tensor Processing Units (TPU), historiquement réservées à ses propres usages.
Avec cet accord, évalué à plusieurs dizaines de milliards de dollars, l’inventeur de Claude va renforcer significativement la capacité d’entraînement de ses futurs modèles.
Avec quelle puissance ? Google mettra à disposition d’Anthropic, dans laquelle il a déjà par ailleurs investi plus de 3 milliards $, plus d’un gigawatt de puissance de calcul, dont la mise en service est prévue pour 2026.
Anthropic indique avoir retenu les TPU en raison de leur rapport performance-prix et de leur efficacité énergétique, ainsi que de son expérience existante avec cette technologie pour le développement de la famille de modèles Claude.
« Cette expansion nous permettra de répondre à la demande croissante tout en maintenant nos modèles au niveau le plus avancé de l’industrie », a déclaré Krishna Rao, directeur financier d’Anthropic.
A l’instar de ses concurrents qui cherchent à sécuriser des ressources matérielles suffisantes pour soutenir la croissance de leurs modèles, Anthropic adopte une approche multi-fournisseurs pour ses infrastructures. Elle utilise déjà les plateformes de calcul de Nvidia (GPU) et d’Amazon (Trainium) qui demeure son principal fournisseur cloud et un investisseur important avec un engagement financier de 8 milliards $. et la construction d’un centre de données de 2,2 gigawatts dans l’Indiana destiné à l’entraînement de ses modèles d’IA.
En moins de huit mois, Anthropic a vu son chiffre d’affaires annualisé passer d’environ 1 milliard à plus de 5 milliards $. Cette progression accompagne une levée de fonds de 13 milliards, qui la valorise désormais à 183 milliards $.
Le groupe chinois est en tout cas parvenu, comme son compatriote en début d’année, à attirer l’attention avec un article scientifique qui touche à la frugalité de l’IA.
La planification de l’autoscaling descendue au niveau des tokens
DeepSeek avait causé un électrochoc en présentant des LLM entraînés avec nettement moins de ressources de calcul que les modèles référents du marché.
Du côté d’Alibaba, la logique est la même, mais sur la phase d’inférence. Elle implique un système de pooling GPU nommé Aegaeon.
En la matière, deux grandes approches sont traditionnellement mises en œuvre : le multiplexage et l’autoscaling.
Le multiplexage place plusieurs instances de modèles sur chaque GPU, avec un partage spatial ou temporel (technologie NVIDIA MPS). Le mécanisme est limité par la quantité de VRAM disponible.
La méthode autoscaling est plus « agressive ». Elle adapte le placement du modèle au fil du temps, en le chargeant depuis la mémoire de l’hôte ou depuis un support externe.
L’efficacité de l’autoscaling est limitée par le ratio de modèles actifs au sein des workloads. Or, la durée d’exécution des requêtes LLM fait qu’à tout moment, un grand nombre de modèles sont actifs, même si les invocations sont sporadiques. Lorsque toutes les instances GPU sont occupées par des modèles actifs, les nouvelles requêtes doivent attendre (on ne peut pas associer en un même lot des opérations de préremplissage et de décodage liées à des modèles différents). Dans ce contexte, réserver moins d’instances qu’il n’y a de modèles accroît le risque de compromettre le respect des SLO.
Pour dépasser cette limite, Alibaba a mis en place un mécanisme planification non au niveau des requêtes, mais des tokens. L’approche avait déjà été expérimentée en configuration monomodèle. En multi, elle est d’autant plus critique que le nombre de batchs augmente (puisqu’on ne peut, donc, pas batcher les requêtes de modèles différents).
Des partitions distinctes pour préremplissage et décodage
Aegaeon planifie en parallèle l’exécution d’une requête et l’autoscaling. Étant donné un ensemble d’instances GPU et des SLO cibles (TTFT, latence du premier token ; TBT, latence entre tokens), il choisit la tâche suivante (prefill ou décodage) pour chaque instance. Et opère éventuellement un autoscaling préemptif si une tâche planifiée utilise un autre modèle que celui actif.
Alibaba a opté pour une désagrégation des phases de préremplissage et de décodage. Il a ainsi divisé le pool GPU en deux partitions. La partie décodage utilise une planification en round-robin pondéré, censée maximiser le respect du TBT. Le prefill exploite un système de planification groupée : on réunit les requêtes qui visent un même modèle, tout en maintenant une approche « premier arrivée, premier servi » pour éviter tout privation de ressources. Les tâches sont ajoutées à un groupe existant si c’est possible. Sinon, Aegaeon en crée un et l’attache à la file d’attente la moins peuplée (chaque instance a sa file). La taille de batch est plafonnée à 1, vu la relative linéarité entre le nombre de tokens et le temps d’exécution – et du fait que de plus petits batchs réduisent les délais d’attente.
Réutiliser pour ne pas (tout) réinitialiser
Les solutions d’autoscaling préemptif tendent à se focaliser sur l’accélération du chargement du modèle. Alibaba Cloud s’est intéressé aux autres étapes de la procédure : réinitialisation du moteur, gestion de la mémoire et transferts du cache clé-valeur.
La réinitialisation du moteur est une séquence qui, à défaut d’optimisation, peut prendre des dizaines de secondes. Elle comprend notamment l’initialisation du cache clé-valeur, le chargement des poids, le profilage et l’optimisation (allocation d’espace pour le cache clé-valeur) et le démarrage d’orchestrateurs comme Ray destinés à distribuer l’exécution.
Alibaba s’est figuré que l’initialisation de ces différents composants pouvait être réutilisée de manière sûre entre modèles. Ainsi, Aegaeon n’initialise le moteur qu’une fois par instance, mettant tous les éléments en cache sauf poids et cache clé-valeur. Pour ce dernier, il exploite un pool préattribué dans la mémoire de l’hôte, évitant de devoir épingler des pages pendant l’autoscaling. L’ensemble réduit la latence de plus de 80 %.
Les événements CUDA mis à profit
La gestion mémoire est quant à elle rendue explicite. À l’appui, entre autres, d’un tampon VRAM autogéré et d’un cache clé-valeur « unifié » (chaque zone, en VRAM ou DRAM, est divisée en fragments de taille fixe qui accueillent différents blocs en fonction de la forme du cache).
Pour ce qui est des transferts du cache clé-valeur entre hôte et GPU, l’enjeu est de permettre leur chevauchement tout en minimisant les conditions de concurrence des données. Les événements CUDA ont été mis à contribution dans ce but, pour suivre individuellement les transferts.
De 1192 à 213 GPU pour le Model Studio d’Alibaba Cloud
Pour évaluer Aegaeon, Alibaba a choisi une config à deux nœuds de 8 GPU H80-80, avec 2 To de DRAM (DDR5) et 192 CPU Xeon Platinum 8469C. Il y a fait tourner des LLM de plusieurs familles (Qwen, Llama, InternLM, Yi, etc., essentiellement de 6 à 14 milliards de paramètres) sur le dataset ShareGPT et deux déclinaisons « augmentées » (inputs et outputs allongés). La comparaison a été faite avec MuxServer et ServerlessLLM, deux solutions qui adoptent respectivement le multiplexage et l’autoscaling.
Illustrant les limites du multiplexage, MuxServer a systématiquement refusé de placer plus de 2 modèles par GPU, en raison du manque de VRAM.
À un débit de 0,1 requête/seconde, Aegaeon soutient un débit utile doublé par rapport à ServerlessLLM. Il gère jusqu’à 70 modèles avec 10 instances de décodage. ServerlessLLM souffre de longs temps d’attente. ServerlessLLM+ (implémentation ad hoc ajoutant une planification Shortest Job First à partir d’un oracle fondé sur les longueurs d’output) atténue l’effet, mais la performance se dégrade inévitablement avec davantage de modèles actifs.
À 0,5 requête/s, l’écart de débit utile est de 2,5 par rapport à ServerlessLLM.
Cet écart se maintient sur les datasets « augmentés ». Et, quoique dans une moindre mesure, avec des SLO plus stricts laissant moins de marge de pooling. Cela se vérifie aussi sur des configs plus restreintes en hardware (par exemple, un nœud de 4 GPU A10). Pour Alibaba, c’est la preuve qu’Aegaeon est potentiellement applicable à un grand éventail de workloads.
Le système alimente, depuis quelques mois, le Model Studio d’Alibaba Cloud. Il fonctionne sur un cluster multirégion de 213 GPU H20 servant 47 modèles de 1,8 à 72 milliards de paramètres. Ces modèles étaient, à l’origine, servis par 1192 GPU H20. Le parc s’est donc réduit de 82 %.
Le taux d’utilisation GPU moyen (illustré ici sur une période de 70 heures) est passé à 48 % avec Aegaeon, sans violations observables de SLO.
Le groupe américain Veeam Software, détenu par le fonds d’investissement Insight Partners va racheter Securiti AI pour environ 1,73 milliard $ en numéraire et en actions.
L’opération, qui doit être finalisée d’ici la fin de l’année, marque une étape clé dans l’évolution de Veeam, traditionnellement centrée sur la sauvegarde et la restauration des données, vers un rôle plus large de gardien de la confiance numérique.
« Cette acquisition nous permet d’unifier la résilience, la sécurité et la gouvernance des données au sein d’une même plateforme », a déclaré le directeur général de Veeam, Anand Eswaran, précisant que l’opération devrait commencer à contribuer aux bénéfices dès le second semestre 2026.
Résilience et gouvernance des données
Historiquement, Veeam a bâti sa réputation sur la protection contre les ransomwares et les pannes informatiques. Avec Securiti AI, l’entreprise s’attaque à un nouveau champ : celui de la protection des données exploitées par les modèles d’intelligence artificielle.
L’enjeu est crucial : dans un environnement où les IA génératives manipulent d’immenses volumes d’informations, les risques de fuites, de biais ou de violations de la confidentialité explosent.
« L’intelligence artificielle d’entreprise n’est pas possible sans sécurité des données », résume Rehan Jalil, fondateur et PDG de Securiti AI, qui rejoindra Veeam en tant que président en charge de la sécurité et de l’IA.
Le communiqué officiel de Veeam détaille l’ambition technique du rapprochement : offrir un “single control plane”, c’est-à-dire un plan de contrôle unique couvrant les données de production et les données secondaires (sauvegardes, archives, environnements cloud ou SaaS).
Cette intégration permettra aux directions informatiques de cartographier l’ensemble de leur patrimoine de données, d’en contrôler les accès et d’en assurer la conformité avec les réglementations internationales.
Securiti AI apporte sa plateforme Data Command Center, fondée sur un (graphe de connaissances qui relie les informations de sécurité, de confidentialité et de gouvernance. La solution est complétée par un moteur d’automatisation “agentic AI”, un module de recherche d’entreprise sécurisé “Gencore AI”, et des fonctions avancées de Data Security Posture Management (DSPM) et de gouvernance de la donnée.
« Notre objectif est de permettre aux clients d’avoir une visibilité complète sur leurs données, qu’elles soient en production, en sauvegarde ou en transit », explique Anand Eswaran.
Répondre à la complexité des environnements IA
Selon Veeam, 70 à 90 % des données d’entreprise sont non structurées — e-mails, documents, messages clients — et 80 à 90 % des projets d’IA échouent en raison de problèmes liés à la qualité, à la confidentialité ou à la gestion des accès. En combinant ses solutions de résilience avec l’expertise de Securiti AI en sécurité des données, Veeam veut proposer une réponse complète à cette complexité croissante.
Le rachat, valorisé 1,725 milliard $, a été financé par JPMorgan Chase & Co. et conseillé par Morgan Stanley du côté de Securiti AI.Basée à San Jose (Californie), Securiti AI emploie environ 600 personnes et avait été valorisée 575 millions $ en 2023, après une levée de fonds de 75 millions $ menée par Capital One Ventures et Citi Ventures. Parmi ses investisseurs figurent General Catalyst et Mayfield.
De son côté, Veeam, rachetée en 2020 par Insight Partners pour 5 milliards $, revendique 6 000 employés et plus de 550 000 clients dans le monde, dont 67 % des entreprises du Global 2000. En décembre 2024, elle avait été valorisée 15 milliards $ lors d’une opération secondaire menée par TPG, avec la participation de Temasek et Neuberger Berman.
Vers une “data confidence platform” pour l’ère de l’IA
En combinant les savoir-faire des deux entreprises, Veeam entend créer une plateforme de confiance pour les données (“data confidence platform”), unifiant la sauvegarde, la gouvernance et la sécurité des informations dans un contexte multi-cloud.
Les premières solutions communes devraient être présentées dans les mois suivant la clôture du rachat. L’ambition est claire : faire de Veeam un pilier de la sécurité des données à l’ère de l’intelligence artificielle, où la fiabilité des modèles dépendra autant de la puissance des algorithmes que de la qualité — et de la protection — des données sous-jacentes.
Eclairage
Le “control plane” : outil central du pilotage des données
Appliqué à la donnée, le “control plane” vise à offrir une vue consolidée sur l’ensemble des informations détenues par une organisation, qu’elles soient stockées dans le cloud, sur site, en sauvegarde ou utilisées par des modèles d’IA.
Concrètement, un “control plane” unifié comme celui que veut bâtir Veeam doit permettre de :
recenser toutes les données d’entreprise, quelle que soit leur source ;
contrôler les droits d’accès et les permissions ;
surveiller les usages et détecter les comportements à risque ;
automatiser la conformité avec des réglementations comme le RGPD ou le CCPA ;
et orchestrer la sécurité de bout en bout, y compris pour les systèmes d’IA générative.
Ce concept, emprunté au monde du réseau et du cloud, devient aujourd’hui le socle d’une gouvernance de la donnée à l’ère de l’intelligence artificielle, où la frontière entre sauvegarde, sécurité et conformité tend à disparaître.
Gartner évoquait un marché devant passer de 5,1 milliards $ en 2024 à 47,1 milliards en 2030… Déjà, Visa et Mastercard proposent des solutions de commerce agentique pour permettre à des agents de réaliser des achats en ligne…
Cette nouvelle approche pose d’évidentes questions de cybersécurité. Si un attaquant venait à prendre le contrôle d’un agent autonome, il pourrait déstabiliser le fonctionnement interne d’une entreprise et, s’il s’agit d’un agent orienté B2C avoir accès aux données personnelles des clients ou vider le compte en banque des clients.
Lors du salon In Cyber 2025, Proofpoint a présenté une interaction entre deux agents sécurisée via sa solution. Xavier Daspre, Directeur technique France de l’éditeur Proofpoint explique son approche : « Les deux agents sont traités comme des postes de travail qui se connectent par échange d’email ou surtout par API vers des services Cloud public. Pour nous, l’approche reste la même. Pour l’instant, le comportement des agents est plus cadré et beaucoup plus facilement discernable, mais cela va être amené à évoluer. Dans les cas d’usage actuels, nos solutions sont déjà prêtes à protéger ce cas d’usage un peu particulier. »
Le côté obscur des agents
Les fournisseurs de services anti-DDoS sont habitués à gérer des bots depuis des années. Ils développent des algorithmes et entraînent des modèles de Machine Learning pour trier le trafic généré par les humains de celui des bots légitimes et des bots illicites.
Pour Sébastien Talha, Directeur régional des ventes de Human Security, les agents sont déjà massivement exploités par les attaquants : « 80 % des attaques utilisent aujourd’hui des robots, car les attaquants ont besoin d’agir à grande échelle » explique le responsable. « L’intervention humaine n’arrive qu’en fin d’attaque, lorsque l’attaquant a besoin de réaliser des opérations complexes. On imagine qu’avec l’IA agentique, cela va disparaître. »
Face aux bots basés sur l’IA, les mécanismes du type mesure de la vitesse de l’utilisateur au clavier, mouvements de la souris ou modèles de navigation pour détecter s’il s’agit d’un humain ou d’un robot ne seront plus suffisants. « L’attaquant peut simuler la vitesse de frappe, enregistrer des déplacements de souris et les rejouer automatiquement. »
Human Security a créé plus de 350 modèles de Machine Learning pour déjouer les attaques par bot et son capteur collecte plus de 2 500 paramètres techniques sur l’utilisateur liés à son réseau, son terminal et son comportement. Il va devoir adapter son approche pour faire face à l’arrivée d’IA agentiques « légitimes ».
MCP, pilier de la sécurisation
Son concurrent français DataDome mise beaucoup sur l’analyse comportementale pour détecter une fraude lors d’une session, en complément des paramètres techniques comme l’adresse IP, la géolocalisation, le type de terminal. « Dans les aspects comportementaux, on analyse les mouvements de souris, si le comportement, les requêtes et le cheminement de navigation dans la session ne correspond pas au comportement habituel de l’utilisateur sur le site ou l’application » explique Benjamin Barrier, Chief Strategic Officer et cofondateur de DataDome.
« Le comportemental permettra de détecter les IA illégitimes et les IA agentiques qui ont « pignon sur rue », notamment Operator d’OpenAI, mettent en œuvre des protocoles tels que MCP pour nous permettre une authentification forte des agents. C’est la combinaison de ces deux approches qui vont permettre d’atteindre une protection efficace de ces IA agentiques. »
Le prestataire a déjà commencé le référencement des opérateurs d’IA agentiques qui ont pignon sur rue, et travaille sur le protocole MCP (Model Context Protocol) pour sécuriser les échanges. Ce protocole est amené à prendre de plus en plus d’importance dans la sécurisation des IA agentiques, car c’est lui qui permet d’interagir avec l’agent, lui passer des paramètres, que ce soit d’une application vers un LLM, ou d’agent à agent.
Les meilleures pratiques de MCP recommandent l’utilisation de TLS pour les connexions distantes, une validation de tous les messages entrants, la protection des ressources, notamment avec du contrôle d’accès et une gestion stricte des erreurs
Un format simple pour un concept simple : ainsi Anthropic présente-t-il Claude Skills.
Il ne s’agit pas tant d’une fonctionnalité – le groupe américain évite d’ailleurs ce terme – que d’une façon spécifique d’apporter du contexte. En l’occurrence, par l’intermédiaire de fichiers Markdown et d’éventuelles ressources associées (code, templates, documentation, etc.).
Le fichier en question (SKILL.md) contient un en-tête YAML donnant le nom et la description de la skill. Cette approche ouvre la voie à ce qu’Anthropic appelle une « divulgation progressive », de sorte que Claude ne surcharge pas sa fenêtre de contexte.
Le modèle n’accède effectivement pas tout de suite aux skills. Il intègre d’abord leur nom et leur description dans son prompt système, puis les enclenche ou non en fonction des tâches qu’il a à accomplir.
Dans le prolongement d’AGENTS.md
Claude Skills s’inscrit dans la lignée d’AGENTS.md, un « readme pour agents de codage » qui a émergé sous l’impulsion de Google, Cursor et OpenAI, entre autres. Il y ajoute néanmoins une forme de structure arborescente, SKILL.md pouvant faire appel à d’autres fichiers Markdown situés dans le même dossier.
Si le mécanisme apparaît reproductible chez d’autres fournisseurs, son implémentation actuelle est dépendante de l’écosystème Anthropic. Elle utilise notamment l’outil Bash pour la lecture des fichiers Markdown et pour l’éventuelle exécution de scripts associés.
Tout skill enclenchée entre dans la fenêtre de contexte de Claude (ordre de grandeur : jusqu’à 5000 tokens, selon Anthropic, le nom et la description consommant quant à eux environ 100 tokens).
Trouver la complémentarité avec MCP
Le système est à l’œuvre depuis quelques semaines sur Claude.ai, portant la fonctionnalité de création de documents (Word, Excel, PowerPoint, PDF). Il est accessible sur les forfaits Pro, Max, Team et Enterprise. Un concepteur est disponible pour créer des skills… à l’aide de ce même Claude. On peut ensuite les importer au format .zip via les paramètres. Elles sont propres à chaque utilisateur.
L’usage de Claude Skills sur l’API Messages exige trois en-têtes : skills-2025-10-02 (active de la fonctionnalité), code-execution-2025-08-25 (permet aux skills de fonctionner dans l’exécuteur de code) et files-api-2025-04-04 (active les téléchargements et téléversements de fichiers).
Les skills sont à uploader via l’endpoint /v1/skills. Elles sont accessibles à toute l’organisation. Pour y faire appel, on les intègre dans le paramètre container en précisant leur identifiant, leur type et éventuellement leur version. On peut en inclure jusqu’à 8 par requête.
Les skills sont aussi disponibles avec Claude Code, y compris sous forme de plug-in. Elles peuvent être personnelles ou partagées.
Anthropic dit réfléchir à la complémentarité avec MCP, pour « apprendre aux agents des workflows plus complexes impliquant des outils externes ». Il caresse aussi l’idée que ces agents puissent un jour créer leurs propres skills de manière autonome.
Au-delà du modèle de langage, il y a l’architecture.
On retiendra volontiers cet aspect des travaux que Lingua Custodia a menés dans le cadre du Large AI Grand Challenge.
Cette compétition s’est inscrite dans le projet européen AI-BOOST, censé en organiser 6 autres à l’horizon 2027 pour encourager l’innovation scientifique ouverte dans le domaine de l’IA. L’UE l’a doté pour cela d’une enveloppe de 4 M€.
3,2 millions d’heures GPU sur deux supercalculateurs EuroHPC
Le Large AI Grand Challenge avait été lancé en novembre 2023. Le contrat, dans les grandes lignes : développer, en partant de zéro, un LLM de fondation d’au moins 30 milliards de paramètres « plus performant que les systèmes à l’état de l’art sur un certain nombre de tâches ». Les lauréats recevraient chacun un prix de 250 000 € et 2 millions d’heures GPU sur un supercalculateur EuroHPC (LUMI, localisé en Finlande, ou LEONARDO, situé en Italie).
Des lauréats, il y en eut 4 (sur 94 dossiers), annoncés en juin 2024. Nommément, Textgain (Belgique), Tilde (Lettonie), Unbabel (Portugal)… et donc Lingua Custodia.
La PME francilienne – petite entreprise selon les seuils du Code de commerce – a choisi l’option LEONARDO. Fin 2024, elle a obtenu une allocation additionnelle de 1,2 million d’heures sur un autre supercalculateur EuroHPC : JUPITER, qui se trouve en Allemagne.
Nouvelle architecture… et nouvelle marque commerciale
Dans l’absolu, le premier modèle issu de ces travaux ne respecte pas le contrat : il ne compte « que » 3,6 milliards de paramètres. Il ne s’agit, par ailleurs, que d’un modèle dit « de base ». C’est-à-dire non affiné pour, par exemple, le dialogue ou le suivi d’instructions. Et donc non utilisable comme tel en production. Il faut néanmoins le voir comme un démonstrateur de la véritable valeur ajoutée : une architecture alternative à Transformers. Son nom : Dragon. Avec elle, Lingua Custodia change de cap. Ou tout du moins ouvre un nouveau chapitre. Jusque-là, on le connaissait effectivement plutôt pour ses services de traitement documentaire (classification, extraction, traduction, résumé…), fournis tant en SaaS que par API à destination du secteur financier.
Ce changement de cap s’assortit d’un changement de marque commerciale : exit Lingua Custodia, place à Dragon LLM.
Dépasser les limites de Transformers et de Mamba à l’inférence
L’architecture Dragon combine de multiples techniques existantes pour dépasser, en particulier, les limites que le mécanisme d’autoattention de Transformers présente lors de l’inférence. En l’occurrence, une consommation de ressources croissant avec la longueur des séquences (dans l’architecture de base, pour chaque token, le modèle examine tous les tokens précédents). Ces ressources, c’est du compute. Mais aussi de la mémoire, qui en vient à constituer le principal goulet d’étranglement, essentiellement en raison des limites de bande passante.
En réaction, des versions linéaires du mécanismes d’attention ont émergé. Évitant, d’un côté, la croissance quadratique de la consommation de ressources de calcul. Et permettant, de l’autre, l’utilisation d’un budget mémoire fixe. Ce en s’appuyant sur un état caché : une matrice ne conservant pas tous les tokens, mais une forme de « résumé évolutif ».
Cette approche a l’inconvénient de diminuer la précision des modèles. Dans ce contexte est apparue une architecture alternative : Mamba. Elle remplace le composant d’attention par un mécanisme inspiré de la théorie du contrôle : les SSM (State Space Models). Avec eux, la montée en charge est linéaire. Et surtout, on permet aux paramètres SSM d’être fonction de l’input, de sorte que la sélection des informations à conserver s’opère au moment de la mémorisation – et non au moment de la remémoration, comme c’est le cas avec Transformers.
Mamba a toutefois une faiblesse qui dissuade d’abandonner complètement l’autoattention : les modèles ne pas performants sur le rappel (recall). Cette métrique traduit la proportion de résultats positifs correctement classés comme tels. Elle est à différencier de la précision, qui indique le pourcentage de prédictions correctes parmi celles faites par le modèle.
Hymba, un socle made in NVIDIA
Dragon LLM a tenu compte des ces éléments pour mener ses expérimentations. Elles ont consisté à entraîner des modèles de 120 à 770 millions de paramètres sur un maximum de 50 milliards de tokens.
Pour l’amélioration de la fonction de perte, un benchmark a été ciblé : modded-NanoGPT. Pour le rappel, SWDE (prompts de 500 tokens) et FDA (2000 tokens) ont été mobilisés. Pour la évaluer la modélisation du langage, HellaSwag a été retenu.
Ces bases posées, Dragon LLM s’est intéressé à une autre architecture : Hymba (Hybrid Mamba). Signée NVIDIA, elle combine, dans chaque couche, des têtes d’attention classiques et des têtes SSM. Elle n’utilise une attention globale que sur 3 couches. Dans les autres cas, l’attention est locale (elle se limite aux 1024 derniers tokens). Les modèles fondés sur ce socle se montrent efficaces à l’inférence : leur débit se maintient à mesure que s’agrandit le contexte. La faiblesse sur le rappel demeure, cependant. D’où un choix d’explorer les mécanismes dits d’attention différentielle. Dragon LLM en mentionne deux, émanant respectivement de DeepSeek et de Microsoft. Les résultats du premier n’ont pu être reproduits de façon fiable. Le second, qui implique un système de suppression du bruit censé permettre au modèle de mieux repérer le contexte important, a produit des améliorations marginales lorsque appliqué à toutes les couches. En revanche, circonscrit à l’attention globale, il a eu un bénéfice significatif. Possiblement, nous explique-t-on, parce qu’il aurait stimulé une spécialisation de ces couches sur le rappel.
Un peu de DeepSeek dans l’affaire
D’autres techniques ont été mises en œuvre pour améliorer les performances de l’architecture Dragon. Parmi elles, la mise à l’échelle de la normalisation. Elle a eu pour effet de stabiliser la variance dans les couches profondes, ainsi mieux entraînées.
Dragon LLM a aussi remplacé l’initialisation des paramètres de PyTorch par un schéma origine DeepSeek. Et utilisé la planification SkyLadder, qui agrandit progressivement la fenêtre d’attention au fil de l’entraînement. Il a également opéré une normalisation individuelle des têtes d’attention (amélioration de l’intégrité du signal) et repositionné les couches d’attention globale (amélioration de la perte et du rappel) tout en supprimant l’encodage positionnel pour les têtes associées. Quant à la gestion d’état interne de Mamba, elle a été remplacé par la méthode GDN (Gated Delta Net), qui garantit de meilleures performances une fois passé le seuil des 30 milliards de tokens.
Certaines techniques n’ont pas porté leurs fruits. Par exemple, sur la data efficiency, Rho-1 et SoftDedup. L’une et l’autre pondèrent les tokens : elles utilisent un petit modèle qui leur attribue un score définissant leur contribution à la fonction de perte (les tokens plus « informatifs » influencent davantage les gradients).
De même, aucun optimiseur ne s’est révélé plus efficace qu’AdamW. Sinon Ademamix, mais avec des instabilités trop difficiles à gérer.
Les performances de SmolLM3, mais en plus frugal
Pour passer à l’échelle, Dragon LLM a implémenté son architecture dans le framework Megatron-LM. Le modèle qui en résulte est dit au niveau de Qwen3-4B et de SmolLM3. En tout cas sur ARC, FDA, HellaSwag, LAMBADA, PIQA et SWDE (en 0-shot). Le tout en plus frugal. Pour l’inférence, on l’a vu (DragonLLM évoque même un déploiement sur CPU), mais aussi pour l’entraînement (3700 milliards de tokens, soit 3 fois moins que SmolLM3 et 10 fois moins que Qwen3-4B).
Dragon LLM vise désormais un entraînement sur plus de 10 000 milliards de tokens, une adaptation au suivi d’instruction et la formation de plus gros modèles. Il promet des « versions dédiées à la production […] dans les prochains mois ».
Connexion
Lors du 
Pour Sébastien Talha, Directeur régional des ventes de Human Security, les agents sont déjà massivement exploités par les attaquants : « 80 % des attaques utilisent aujourd’hui des robots, car les attaquants ont besoin d’agir à grande échelle » explique le responsable. « L’intervention humaine n’arrive qu’en fin d’attaque, lorsque l’attaquant a besoin de réaliser des opérations complexes. On imagine qu’avec l’IA agentique, cela va disparaître. »
« Le comportemental permettra de détecter les IA illégitimes et les IA agentiques qui ont « pignon sur rue », notamment Operator d’OpenAI, mettent en œuvre des protocoles tels que MCP pour nous permettre une authentification forte des agents. C’est la combinaison de ces deux approches qui vont permettre d’atteindre une protection efficace de ces IA agentiques. »