Alphabet, maison mère de Google, a retiré sa plainte antitrust déposée auprès de la Commission européenne contre les pratiques cloud de Microsoft, une semaine après l’ouverture par Bruxelles de trois enquêtes de marché sur AWS et Microsoft Azure dans le cadre du Digital Markets Act (DMA).
Désormais, Google affirme vouloir contribuer aux travaux des autorités dans ce cadre plus large, et indique rester engagé dans le dialogue avec les décideurs publics pour faire évoluer les règles de concurrence et les conditions de licences dans le cloud.
Google avait saisi la Commission européenne en 2024 en accusant Microsoft d’utiliser des conditions de licences logicielles pour enfermer les clients dans sa plateforme Azure. La plainte mettait en avant des pénalités financières, des restrictions d’usage de Windows Server et des obstacles d’interopérabilité pour les entreprises souhaitant exécuter les logiciels Microsoft sur des clouds concurrents ou migrer leurs charges de travail hors d’Azure.
Ces griefs faisaient écho à des préoccupations déjà exprimées par l’association professionnelle CISPE, soutenue par Amazon, qui avait elle-même déposé puis retiré une plainte contre Microsoft après un accord transactionnel en 2024.
Enquêtes de l’UE sur le cloud
Les enquêtes ouvertes par la Commission visent à déterminer si AWS et Azure doivent être désignés comme « contrôleurs d’accès » (gatekeepers) pour leurs services cloud, alors même qu’ils ne remplissent pas automatiquement tous les seuils chiffrés prévus par le DMA. Bruxelles veut évaluer si certaines caractéristiques du secteur (effets de verrouillage, coûts de sortie, barrières techniques au multicloud) renforcent le pouvoir de marché de ces hyperscalers au détriment de la concurrence.
Une troisième enquête examinera si les dispositions actuelles du DMA suffisent à traiter les pratiques susceptibles de limiter la contestabilité et l’équité dans le cloud, ou si des ajustements réglementaires sont nécessaires. La Commission a indiqué que ces travaux s’inscrivent dans un effort plus large pour adapter les outils de concurrence numérique aux spécificités de l’informatique en nuage dans l’UE.
Les grandes entreprises combinent plusieurs clouds pour répartir les workloads, optimiser les coûts, rapprocher les données des utilisateurs et limiter les risques de dépendance à un seul fournisseur. Jusqu’ici, relier ces environnements impliquait soit l’usage d’Internet public sans garanties de bande passante, soit des montages de connectivité privée complexes, longs à déployer et coûteux à exploiter.
L’alliance entre AWS et Google Cloud combine le nouveau service AWS Interconnect- multicloud et Google Cloud Cross-Cloud Interconnect pour proposer une connectivité privée et automatisée entre les deux environnements. Elle fournit une connectivité entre VPC AWS et VPC/VPC‑SC Google Cloud, intégrée de manière native aux consoles et APIs des deux fournisseurs.
Google Cloud avait déjà positionné Cross-Cloud Interconnect comme brique clé de son architecture “Cross-Cloud Network”, permettant de relier Google Cloud à AWS, Azure, Oracle Cloud Infrastructure et d’autres MSP via des liens privés à haut débit.
Les deux acteurs mettent en avant une automatisation poussée : les clients peuvent réserver de la capacité dédiée à la demande et établir la connectivité en quelques minutes, sans gérer directement le câblage, les circuits ni l’infrastructure physique sous‑jacente.
L’annonce inclut une spécification ouverte pour l’interopérabilité réseau entre clouds décrite comme un standard commun de connectivité privée qui vise à réduire la complexité de l’adressage, du routage et de la gestion des politiques réseau entre environnements AWS et Google Cloud.
L’objectif est de permettre à d’autres fournisseurs de cloud d’implémenter le même modèle, afin d’étendre ce socle d’interopérabilité au‑delà du seul duo AWS–Google Cloud. Cette ouverture pourrait favoriser l’émergence d’un écosystème où les clouds majeurs s’alignent sur des standards communs de connectivité privée, à l’image de ce qui existe déjà pour certains protocoles réseau et interfaces de peering.
Caractéristiques techniques mises en avant
Sur le plan technique, Cross-Cloud Interconnect fournit des liaisons privées avec des capacités de 10 ou 100 Gbit/s dans de nombreux sites mondiaux, gérées par Google côté physique, avec des métriques de performance détaillées (latence, pertes de paquets, temps de trajet aller‑retour).
Les documents techniques de Google décrivent un modèle de double attachement (primaire et redondant) et l’utilisation de BGP pour l’échange de routes entre Google Cloud et AWS, avec des exigences de haute disponibilité.
AWS Interconnect-multicloud, en préview, est présenté comme un service managé offrant des connexions privées simples, résilientes et à haut débit vers d’autres clouds, intégrées avec les outils réseau et d’observabilité AWS.
L’intégration avec Cross-Cloud Interconnect vise à abstraire la gestion des ports, des circuits et des délais de provisioning, en exposant une expérience de type “cloud‑native” dans les deux consoles.
Cas d’usage et bénéfices clients
L’alliance cible des scénarios où les données ou applications sont réparties entre AWS et Google Cloud, par exemple pour des plateformes analytiques, des charges IA/ML, ou l’intégration de SaaS opérant sur plusieurs clouds.
Un exemple cité concerne l’intégration de Salesforce Data 360, qui nécessite des ponts privés robustes entre différents environnements pour alimenter des cas d’usage d’IA et d’analytique sur des données réparties.
Pour les clients, les bénéfices mis en avant sont la réduction du temps de mise en service des liaisons, la simplification opérationnelle (moins de gestion d’infrastructure physique) et de meilleures garanties de performance que l’Internet public. L’approche standardisée doit aussi faciliter la gouvernance réseau et la sécurité dans des environnements multicloud complexes, où les architectures doivent concilier segmentation, conformité et performance de bout en bout.
Sous le feu des critiques des associations professionnelles et scrutés par les régulateurs, les deux grands CSP américains engagent un mouvement vers un modèle où la connectivité inter‑cloud devient un service managé de première classe, au même titre que le compute ou le stockage, plutôt qu’un assemblage de liens télécoms et de configurations spécifiques.
Reste à observer dans quelle mesure les autres fournisseurs adopteront la spécification proposée et comment les intégrateurs réseau et opérateurs télécoms adapteront leurs offres face à cette montée en puissance de la connectivité multicloud native.
HSBC a signé un accord pluriannuel avec Mistral AI afin d’intégrer des outils d’intelligence artificielle générative dans l’ensemble de la banque.
HSBC déploiera les modèles commerciaux de Mistral ainsi que leurs futures mises à jour sur une infrastructure auto-hébergée. Cette approche permettra de combiner les capacités technologiques internes du groupe bancaire avec l’expertise de Mistral dans la conception de modèles d’IA.
Les deux entreprises collaboreront au développement de solutions d’IA couvrant plusieurs usages : analyse financière, traduction multilingue, évaluation des risques ou encore communications personnalisées avec les clients.
Selon HSBC, ces outils pourraient réduire de manière significative le temps consacré par les employés aux tâches routinières ; par exemple, les équipes crédit et financement pourront analyser plus rapidement des dossiers complexes et volumineux.
HSBC utilise déjà des centaines de cas d’usage d’IA dans le monde, notamment en matière de détection de fraude, de surveillance des transactions, de conformité et de service client. La banque estime que l’accord avec Mistral AI permettra d’accélérer ses cycles d’innovation et de lancer plus rapidement de nouvelles fonctionnalités reposant sur l’IA.
Le rapport intitulé “The State of Generative AI 2025” édité par Palo Alto Networks le montre : les cas d’usage des IA génératives ont explosé en 2024. Le trafic vers ces services s’est accru de 890 % en 2024 et une grande organisation exploite 66 applications d’IA générative en moyenne, dont 10 % peuvent être qualifiées à haut risque.
Qu’il s’agisse de services de traduction, de synthèse de documents, mais aussi de chatbots, moteurs de recherche et outils dédiés aux développeurs, ces IA sont désormais adoptées dans tous les secteurs d’activité.
Pierre Jacob, DG de Magellan Sécurité.
Sécuriser ces infrastructures présente quelques spécificités. Les IA restent des workloads IT standards avec des conteneurs logiciels qu’il faut protéger, mais les LLM présentent des vulnérabilités intrinsèques à l’apprentissage machine. « Pour les entreprises qui souhaitent réaliser l’entraînement de leurs modèles, il est extrêmement important de sécuriser la chaîne d’alimentation des modèles » explique Pierre Jacob, DG de Magellan Sécurité.
Le consultant estime qu’il est relativement facile d’empoisonner un modèle et introduire des biais importants dans son comportement : « Il ne faut qu’un pourcentage finalement assez faible de données pour faire dérailler un modèle. Il est donc extrêmement important de sécuriser soigneusement les infrastructures d’entraînements. »
La Cyber s’invite dans les infrastructures NVidia
NVidia a pleinement pris conscience des risques pesant sur les IA entraînées et exécutées sur ses infrastructures. Le californien a implémenté des fonctions d’informatique confidentielle sur ses architectures Nvidia Hopper et Blackwell, avec la capacité d’entraîner les IA sur des données chiffrées de bout en bout. De même, les fournisseurs de solution de sécurité sont invités à déployer leurs briques de sécurité sur les infrastructures IA.
Au début de l’été, Crowdstrike annonçait l’intégration de sa plateforme Falcon Cloud Security avec les microservices LLM NIM de NVidia, ainsi qu’à NeMo, sa plateforme de développement d’IA. On retrouve cette même volonté de rapprochement avec Nvidia chez Check Point.
Adrien Merveille, CTO France de Check Point Software
« Nous avons signé un partenariat avec Nvidia pour venir directement dans les GPU qui vont assurer l’apprentissage des moteurs d’IA » explique Adrien Merveille, CTO France de Check Point Software. « Cela va permettre d’appliquer les règles de sécurité à la fois pour segmenter les données d’entraînement, contrôler l’accès par les administrateurs et les manipulations mémoire pour éviter les attaques de type Prompt Injection. »
De même, l’éditeur a intégré à son WAF les protections du Top 10 WASP LLM pour protéger les IA contre les types d’attaques connus. Ce classement référence les 10 types d’attaque les plus fréquents sur les LLM, depuis la Prompt Injection, le Data Poisoning, mais aussi le vol de modèle et les vulnérabilités sur la chaîne d’alimentation en données des modèles en phase d’apprentissage ou en production.
Éric Vedel, CISO de Cisco, rappelle que même des LLM téléchargés sur Hugging Face peuvent avoir été piégés et doivent être vérifiés avant d’être mis en production. Cisco pousse en avant sa solution Cisco AI Defence afin de détecter les vulnérabilités dans les modèles. Celle-ci a été officiellement lancée le 15 janvier 2025, mais elle est issue de l’acquisition de l’éditeur Robust Intelligence quelques mois plus tôt.
Éric Vedel, CISO de Cisco
« Cette éditeur avait déjà mis en place ses moyens de protection chez de très gros clients pour lutter contre le Shadow AI en accroissant la visibilités sur les usage de l’IA en interne, de la détection des vulnérabilités dans les modèles mis en œuvre et la mise en place de garde-fous et contremesures contre ces risques liés à l’IA. Chose unique sur le marché, nous avons embarqué cette offre au sein de notre offre SSE (Secure Access Security Edge). »
Cette solution s’inscrit dans la mouvance des solutions d’AI SPM apparues pour sécuriser les modèles et les données.
Palo Alto Networks a récemment pris position sur ce marché avec une plateforme complète entièrement dédiée aux IA et couvrir tous les risques recensés par l’OWASP : « Pour couvrir l’ensemble de ces risques, nous avons fait le choix de créer une nouvelle plateforme, Prisma AIRS » explique Eric Antibi, directeur technique de Palo Alto Networks. « Celle-ci amène tout un ensemble de solutions conçues pour la sécurité de ces architectures complexes et des risques spécifiques qui pèsent sur la GenAI. »
Eric Antibi, directeur technique de Palo Alto Networks.
La suite intègre un module de Model Scanning pour trouver des vulnérabilités dans les modèles, un module de Posture Management pour identifier tout problème de configuration dans l’architecture. Le module de Red Teaming teste en permanence les modèles pour s’assurer que de nouvelles vulnérabilités ne sont pas apparues à l’occasion de mises à jour, par exemple.
Enfin, des modules assurent la sécurité runtime des IA ainsi que celle des agents intelligents. « Prisma AIRS est une plateforme à part entière, néanmoins, la composante réseau est importante dans la sécurité de ces infrastructures, notamment pour surveiller les échanges entre les datasets et les moteurs de LLM. De ce fait, la console d’administration de notre plateforme Network Security est utilisée, mais cela reste des modules différents. »
Si les solutions d’AI SPM sont encore assez nouvelles et encore peu répandues, les équipes sécurité et IA doivent s’en emparer et commencer à monter en maturité et faire évoluer vers le haut leurs politiques de sécurité vis-à-vis des IA.
Pierre Jacob, DG de Magellan Sécurité : «Ne pas s’arc-bouter sur une position unique. »
« Il faut adapter ses choix de LLM aux usages et aux risques. Il est possible de déployer un LLM ou un SLM sur un poste de travail si le cas d’usage impose d’être en mode déconnecté. Les machines Apple se prêtent assez bien au déploiement de SLM en local par exemple. De même, il ne faut pas rejeter un LLM parce qu’il est dans le Cloud public. Il faut avoir une vision architecture et penser la sécurité by design et être capable de jongler avec les modèles, mettre en place des architectures applicatives à base de microservices capables de consommer ses modèles sans en être dépendantes. »
Connexion
