Une application moderne n’est plus un bloc posé sur un serveur. Elle vit désormais en morceaux, répartie entre des charges de travail, des conteneurs, des services managés, des identités et du code d’infrastructure qui se déploie de lui-même. Ce que l’on appelait autrefois « l’application » est devenu un ensemble mouvant de composants qui s’exécutent à des endroits différents, changent plusieurs fois par jour et dépendent les uns des autres sans jamais se trouver au même endroit. C’est dans ce paysage éclaté que le terme CNAPP a fait son apparition, moins comme une catégorie de produit que comme une réponse à une question devenue difficile, celle de savoir où se situe réellement le risque.
Le problème tient justement à cette dispersion. Quand une application se répartit sur des dizaines de couches, aucun point d’observation unique ne voit l’ensemble. Chaque équipe regarde sa portion, chaque outil surveille son domaine, et aucune équipe ne dispose d’une image complète de ce qui tourne, avec quels droits et exposé à quoi. La visibilité fragmentée n’est pas un détail opérationnel, c’est la difficulté centrale de la sécurité cloud-native. On ne protège pas bien ce que l’on ne voit qu’en fragments.
Comment une seule application s’est répartie sur des dizaines de couches
Pour comprendre pourquoi la sécurité est devenue si difficile à cadrer, il faut regarder comment ces applications sont construites. Les technologies cloud-native reposent sur des composants faiblement couplés, conteneurs, microservices, maillage de services et infrastructure immuable, assemblés pour s’exécuter dans des environnements cloud dynamiques et se mettre à l’échelle à la demande. Chaque service est petit, autonome et remplaçable. Cette modularité fait la force du modèle, elle apporte de la vitesse et de la résilience, mais elle multiplie aussi le nombre de pièces à surveiller et de liens entre elles.
La dispersion ne s’arrête pas au code. Elle traverse aussi l’organisation elle-même, ses accès distants, ses sites et l’architecture réseau des organisations distribuées qui relie tout cela. Les identités humaines et machines se comptent par milliers, les permissions s’accumulent, l’infrastructure se décrit sous forme de code versionné, et une partie de l’exécution se déroule dans des services managés, ce qui ajoute encore une couche à surveiller. L’application n’est plus un objet, c’est un territoire.
Pourquoi des outils séparés perdent le fil du contexte
À ces couches s’ajoute encore celle de la fabrication. Le logiciel n’arrive pas en production d’un seul coup, il passe par la chaîne de livraison logicielle et ses pipelines d’intégration et de déploiement continus, où le code est construit, testé, empaqueté puis publié. Cette chaîne est un maillon de sécurité à part entière, avec ses propres risques, et les pratiques DevSecOps cherchent précisément à y intégrer les contrôles au fil de l’eau plutôt qu’à la toute fin. Sécuriser une application cloud-native, c’est donc aussi sécuriser la manière dont elle est produite.
Face à cette accumulation de couches, la réponse habituelle a consisté à ajouter un outil par domaine. Un scanner pour les configurations, un autre pour les conteneurs, un troisième pour les identités, un quatrième pour le code. Chacun fait bien son travail sur son périmètre, mais aucun ne voit les liens qui rattachent sa couche aux autres. Le problème dépasse alors le simple volume d’alertes. Une vulnérabilité remonte à l’équipe applicative, une permission trop large à l’équipe qui gère les accès, une configuration douteuse à celle qui exploite l’infrastructure. Trois signaux qui appartiennent au même risque sont lus par trois équipes distinctes, dans trois outils distincts, avec trois échelles de gravité distinctes. Chacune traite sa part sans que la séquence complète apparaisse quelque part, et le contexte se perd précisément là où il faudrait le reconstituer.
Le risque vit entre les couches, pas dans une seule
C’est là que se joue l’essentiel. Un risque sérieux prend rarement la forme d’un défaut isolé. Il naît le plus souvent d’un enchaînement, une configuration trop permissive, une permission plus large que nécessaire et une charge de travail joignable depuis l’extérieur. Prise séparément, chacune de ces conditions peut paraître mineure. Mises bout à bout, elles dessinent un chemin praticable. Un outil qui n’examine qu’une seule couche voit trois signaux anodins là où il existe en réalité une trajectoire complète.
La bonne question n’est donc pas de savoir combien de problèmes existent, mais lesquels se rejoignent. Une masse de vulnérabilités classées par gravité théorique aide peu si elle ignore la façon dont ces éléments se connectent. Raisonner par chemins plutôt que par listes change la décision elle-même. L’action utile n’est plus de corriger d’abord l’alerte la plus bruyante, mais de rompre la séquence dangereuse là où l’intervention sera la plus efficace. Réduire une permission, fermer une exposition, corriger une configuration ou bloquer un déploiement risqué peut suffire à neutraliser tout un chemin, parfois sans même toucher au défaut qui semblait le plus grave. La priorité se déplace de ce qui fait le plus de bruit vers ce qui protège vraiment.
Ce qu’une vue unifiée permet de réunir
C’est précisément cette corrélation qu’une plateforme dédiée cherche à apporter. Plutôt que de juxtaposer des vues partielles, une CNAPP rassemble dans un même cadre les signaux venus du code, des configurations, des identités, des charges de travail et de l’exécution. L’objectif n’est pas de regarder chaque couche l’une après l’autre, mais de les mettre en relation, du code jusqu’au runtime, pour faire apparaître les trajectoires que les outils isolés laissaient dans l’ombre.
L’intérêt d’une telle plateforme ne tient pas au fait d’ajouter un scanner de plus. Il tient à ce qu’elle fait des données déjà disponibles, les recouper, les remettre en contexte et hiérarchiser ce qui mérite attention. Son effet le plus concret est peut-être organisationnel. Quand la sécurité raisonne en chemins de risque, les équipes plateforme en évolutions d’architecture et les équipes de livraison en flux de déploiement, elles décrivent souvent la même réalité dans des langages incompatibles. Une vue partagée leur donne un point de référence commun, où l’on débat d’un même problème au lieu de comparer des listes qui ne se recoupent pas. La clarté ne sert pas seulement à trier des alertes, elle sert à aligner des équipes qui, jusque-là, regardaient chacune un fragment.
Pourquoi une vue unifiée ne décide pas à votre place
Reste une limite qu’aucun outil ne franchit. Une CNAPP peut montrer le risque et le relier, mais elle ne tranche pas à votre place, et les décisions qui comptent restent humaines. Il faut encore décider à quelle équipe revient telle correction, quel risque peut être toléré quelque temps faute de mieux, quel arbitrage d’architecture justifie de ralentir une livraison, quels systèmes sont réellement critiques pour l’activité, et surtout quelle capacité de remédiation les équipes ont vraiment dans les jours qui viennent. Une vue unifiée peut rendre ces choix plus visibles, mieux documentés et moins arbitraires. Elle ne peut pas les transformer en réponse automatique, parce qu’ils dépendent d’un contexte métier qu’aucun graphe de risque ne contient.
La plateforme peut donc recomposer une image que l’architecture avait éparpillée. C’est déjà beaucoup, et c’est utile. Mais recomposer la vue n’est pas la même chose que décider quoi en faire. La visibilité se déploie, la stratégie se construit. La première peut s’acquérir, la seconde reste une décision que l’entreprise prend elle-même, à mesure que son architecture continue de se transformer.