L’adoption accélérée de l’intelligence artificielle dans les environnements d’entreprise ouvre une nouvelle phase de risques dans le cloud. Il ne s’agit pas seulement d’une augmentation des charges de travail, de puissance de calcul ou de flux de données : c’est aussi l’augmentation des points d’entrée, des dépendances et de l’automatisation… pour les attaquants. Telle est la photographie esquissée par le State of Cloud Security Report 2025 de Palo Alto Networks, qui alerte sur une expansion “exponentielle” de la surface d’attaque impulsée par l’IA et sur l’écart croissant entre la vitesse de déploiement et la capacité réelle à sécuriser ce qui est mis en production.
La donnée la plus percutante du rapport est aussi la plus dérangeante : 99 % des organisations interrogées déclarent avoir subi au moins une attaque contre leurs applications et services d’IA au cours de la dernière année. La conclusion est claire : les systèmes d’IA ne sont plus des expérimentations “parallèles”, mais deviennent une cible prioritaire, surtout lorsqu’ils sont intégrés dans des processus critiques, connectés via des API, des identités ou des flux d’automatisation dans le cloud.
Quand l’IA passe en production, le cloud devient le terrain de jeu
Le rapport relie ce problème à une réalité d’entreprise évidente : à mesure que l’infrastructure cloud s’élargit pour héberger des workloads d’IA, cette même infrastructure devient une cible. Et ce, non seulement en raison de la valeur des données, mais aussi à cause de la complexité opérationnelle : modèles, pipelines, dépôts, permissions, endpoints et services qui prolifèrent pour maintenir l’IA générative et, de plus en plus, l’IA “agentique” qui agit.
Dans ce contexte, le rapport souligne un phénomène impactant directement les équipes de sécurité : l’essor du “vibe coding” assisté par l’IA, c’est-à-dire le développement soutenu par l’IA qui accélère la production de code, mais augmente aussi le volume de livrables et le risque d’introduction de logiciels vulnérables. Selon les données partagées, 99 % des répondants utilisent ce type d’approche, mais le rythme de génération de code dépasse souvent la capacité de revue et de remédiation.
Le résultat est une équation dangereuse. Parmi les équipes qui livrent du code chaque semaine (52 %), seules 18 % assurent pouvoir corriger les vulnérabilités à ce même rythme. En sécurité, cette différence n’est pas une simple nuance : elle génère une accumulation de dettes. Ce qui n’est pas corrigé à temps reste en production, s’intègre à d’autres services et finit par constituer une surface d’attaque croissante “par couches”.
APIs, identités et mouvement latéral : le nouveau trinôme du risque
Le rapport met en lumière une évolution tactique : les attaquants se tournent vers les couches fondamentales du cloud, avec un accent particulier sur l’infrastructure API, la gestion des identités et le mouvement latéral.
- Les API, au centre des attentions. Le rapport signale une augmentation de 41 % des attaques ciblant les API. La logique est simple : l’IA agentique et une grande partie des architectures modernes dépendent des API pour fonctionner, intégrer des services, consulter des données ou exécuter des actions. Plus d’API signifie souvent plus d’endpoints, davantage de permissions, ainsi qu’un risque accru d’abus sans un inventaire précis, une authentification robuste et un contrôle d’accès strict.
- L’identité reste le maillon le plus faible. 53 % des répondants reconnaissent que des pratiques IAM (gestion des identités et des accès) trop permissives constituent un de leurs principaux défis. Concrètement, cela se traduit par des permissions excessives, des réutilisations de credentiels, des rôles trop étendus ou une gouvernance insuffisante des identités machine (comptes de service, tokens, clés). Lorsqu’interviennent l’IA et l’automatisation, le problème s’amplifie : agents, services et pipelines nécessitent des permissions… et toute surcharge peut rapidement devenir un vecteur de vol de crédentiels ou d’exfiltration.
- Le mouvement latéral persiste. 28 % des sondés évoquent un accès réseau non restrictif entre workloads cloud comme une menace croissante. Il s’agit du schéma classique : une intrusion “mineure” peut devenir une crise majeure lorsqu’un attaquant parvient à se déplacer librement dans l’environnement. Dans le cloud, où la connectivité entre services peut être une force opérationnelle, cela devient une aubaine pour l’adversaire si cette capacité n’est pas contrôlée.
Outils en trop, vitesse en berne : l’urgence d’unifier cloud et SOC
Une autre thématique récurrente dans le rapport concerne le coût de la fragmentation. La complexité multivendeur et la dispersion des outils créent des zones d’ombre et ralentissent la réaction face aux incidents.
Un exemple frappant : les organisations gèrent en moyenne 17 outils de sécurité cloud provenant de cinq fournisseurs, ce qui fragmentise la vision et complique la corrélation des événements. Quand le contexte devient dispersé, les temps de réponse s’allongent : 30 % des équipes mettent plus d’un jour pour traiter un incident, d’après le rapport.
Dans ce contexte, un consensus opérationnel émerge : 97 % considèrent prioritaire la consolidation de leur “empreinte” de sécurité cloud, et 89 % estiment que la sécurité cloud et celle des applications doivent s’intégrer pleinement avec le SOC pour être efficace. Ce n’est pas simplement un slogan, mais une réponse à une réalité : si un adversaire opère à la vitesse d’une machine, le défenseur ne peut pas se limiter à des workflows manuels ou à des silos d’outils.
Le rapport insiste également sur le fait que disposer de dashboards qui “visualisent” les risques ne suffit plus si ces risques ne peuvent pas être atténués rapidement. Comme le souligne un dirigeant de Palo Alto Networks, les équipes ont besoin de quelque chose de plus : la capacité à agir aussi vite que l’adversaire.
Objectif 2026 : une sécurité “end-to-end” et des fondamentaux solides
Au-delà des considérations commerciales, le rapport délivre un message utile à toutes les organisations : l’IA n’apporte pas seulement de nouvelles capacités, elle augmente aussi la surface d’attaque. Et cette surface s’étend simultanément sur trois fronts : le code (plus rapide et plus fréquent), le cloud (avec plus de services et d’interconnexions) et les opérations (avec davantage d’alertes et une dépendance accrue à l’automatisation).
Le défi crucial réside dans le fait que nombre d’organisations déploient l’IA avant d’avoir sécurisé les fondamentaux : inventaire des API, contrôle des permissions, segmentation, gouvernance des identités non humaines, et un cycle de remédiation capable de suivre le rythme de déploiement. Si l’IA pousse le métier à évoluer plus vite, la sécurité ne peut rester en retrait : elle doit être repensée pour fonctionner au même rythme.
Questions fréquemment posées
Que signifie “l’expansion de la surface d’attaque” par l’IA dans le cloud ?
Lorsque l’on déploie des systèmes d’IA, on multiplie les API, les identités, les services et les connexions entre workloads, créant ainsi davantage de points d’entrée ou de vulnérabilités potentielles si elles ne sont pas correctement contrôlées.
Pourquoi observe-t-on une augmentation des attaques contre les API dans les environnements d’IA agentique ?
Parce que les agents et services IA dépendent aussi d’API pour accéder aux données et exécuter des actions. Un inventaire incomplet, une authentification faible ou des permissions excessives transforment ces API en cibles prioritaires.
Quels problèmes de gestion des identités et des accès (IAM) sont les plus critique lors du déploiement de l’IA dans le cloud ?
Les pratiques permissives telles que des rôles trop larges, une mauvaise gestion des crédentiels, le manque de principes de moindre privilège et une gouvernance faible des identités machine (comptes de service, tokens, clés) dans les pipelines d’IA.
Comment le “vibe coding” assisté par l’IA influence-t-il la sécurité logicielle ?
Il accélère la génération et le déploiement de code, mais peut aussi introduire des vulnérabilités ou des configurations incorrectes plus rapidement que la capacité des équipes à les vérifier et corriger, augmentant ainsi la dette technique en sécurité.
