Les arguments en faveur du « Zero Trust » au niveau local

Par Sarang Warudkar - Chef de projet technique senior (PMM)

13 novembre 2026 5 minutes de lecture

L'IA s'est installée au sein de votre réseau. Ce n'est pas le cas de votre SSE.

Le modèle « Zero Trust » a véritablement pris son essor lorsque les collaborateurs ont commencé à travailler à distance et que les applications ont migré vers le cloud. Les « Cloud Access Security Brokers » (CASB), puis, plus largement, les marchés de l’« Security Service Edge » (SSE) et du « Secure Access Service Edge » (SASE), ont connu une croissance rapide car ils apportaient une réponse au risque du moment : un attaquant disposant d’identifiants volés pouvant accéder aux ressources cloud de l’entreprise depuis n’importe où. Zero Trust Network Access (ZTNA) a vu le jour de la même manière, lorsque les fournisseurs de solutions SSE ont étendu leurs plateformes cloud afin de proposer une alternative moins coûteuse et plus robuste au VPN. Le principe était juste et l’est toujours : valider l’utilisateur, l’appareil, l’emplacement et le contexte environnant, plutôt que de se fier uniquement à des identifiants.

Ce qui a changé, ce n'est pas le principe. C'est le lieu où le travail s'effectue.

Pourquoi le travail a été rapatrié

Quatre changements ont conduit à un retour progressif d'une part croissante de l'activité des entreprises vers les réseaux privés.

1. Les employés sont retournés au bureau. Selon un sondage Gallup de mai 2026, 74 % des employés travaillent au bureau ou en mode hybride, dont 22 % à temps plein sur site et 52 % en mode hybride à raison de 2,3 jours par semaine. Le nombre de sessions professionnelles qui commencent et se terminent sur le même réseau d'entreprise n'a jamais été aussi élevé depuis 2019.
2. L'IA a fait son entrée dans l'infrastructure de l'entreprise. L’IA s’est installée au sein de l’infrastructure de l’entreprise, car la hausse des coûts des jetons, les problèmes de contrôle et les préoccupations liées à la confidentialité des données poussent les charges de travail à être traitées en interne. Lorsqu’un modèle d’IA est entraîné sur des données internes, telles que celles issues de la R&D, la logique de tarification et les dossiers clients, il absorbe la propriété intellectuelle fondamentale de l’entreprise et devient de fait une copie fonctionnelle de ses secrets d’affaires. Les conseils d’administration étant réticents à laisser ces actifs sur des serveurs tiers, l’exécution de modèles privés et d’outils d’IA internes au sein de centres de données privés est désormais une pratique courante.
3. La plupart des actions menées par ces systèmes ne franchissent jamais le périmètre. Selon Gartner, une demande d’IA sur six contient des données propriétaires (Menace de cybersécurité : compromission des applications d’IA, 2026), et ce ratio ne s’améliore en rien lorsque le modèle est interne plutôt que public. Un copilote interne n’a rien à exfiltrer. Il accède au référentiel de documents, au système de tickets et à la base de données clients, car c’est précisément pour cela qu’il a été conçu. Un agent chargé d’une tâche dispose d’identifiants permanents et agit bien plus rapidement que la personne qui l’a autorisé, sur les systèmes de son propre segment de réseau.
4. La souveraineté remet également ce modèle de fonctionnement au goût du jour. Gartner prévoit que 50 % des multinationales, et plus de 75 % des multinationales non américaines, auront des exigences en matière de souveraineté numérique d’ici 2028 (Analyse des prévisions : IaaS « Sovereign Cloud », à l’échelle mondiale, 2025). Une organisation qui a internalisé un modèle précisément pour maintenir les données réglementées sous sa propre juridiction est en droit de s’interroger sur toute architecture qui achemine l’interaction vers un autre lieu afin de l’inspecter.

Lorsque la mise en œuvre via le cloud ne répond plus aux besoins

L'intégration de contrôles d'accès de type « zero trust » dans un service fourni dans le cloud s'avère tout à fait pertinente lorsque l'utilisateur se trouve à distance ou que l'application est hébergée dans le cloud. Elle l'est nettement moins lorsque les deux extrémités se trouvent dans le même bâtiment.

Acheminer une session interne, ou un trafic d’agent circulant à la vitesse de la machine, vers un point de présence dans le cloud à des fins d’inspection et d’application des règles, pour ensuite le renvoyer directement vers une application privée ou une source de données située deux étages plus loin, ne tient pas la route d’un point de vue architectural. Cela ajoute de la latence, consomme de la capacité WAN et crée une dépendance vis-à-vis de la connexion Internet pour des tâches qui n’auraient jamais dû quitter le site. La disponibilité devient alors un enjeu de sécurité, ce qui est rarement le souhait de quiconque.

Le ZTNA dans le cloud présente une deuxième faiblesse, plus discrète. En effet, il accorde généralement un accès « zero trust » au réseau plutôt qu’à l’application spécifique dont l’utilisateur a réellement besoin. La session bénéficie de privilèges excessifs dès son admission, et les mouvements latéraux au sein de ce segment ne font l’objet d’aucun contrôle. Un contrôle mis en place pour supprimer la confiance implicite finit par la réintroduire à un niveau inférieur.

Tout cela n’est pas nouveau pour l’équipe réseau. La segmentation et la visibilité sur le trafic est-ouest constituent un objectif depuis des années, mais la mise en œuvre d’une approche « zero trust » locale sans impact sur le comportement des utilisateurs ni sur les risques s’est avérée difficile. Malheureusement, les fonctionnalités SSE de nouvelle génération, telles que l’accès au niveau des applications, l’inspection Web et TLS, ainsi que les contrôles basés sur les données, ont souvent été hors de portée pour protéger les réseaux internes. Cette lacune est d’ordre architectural plutôt que conceptuel, ce qui explique également pourquoi y remédier relève davantage d’un exercice d’ingénierie que d’une nouvelle doctrine.

Les flux de données circulant désormais à la vitesse des machines sur les réseaux locaux, le contrôle d'accès au niveau des applications locales et l'inspection en ligne locale ne sont plus de simples aspirations, mais constituent désormais une exigence de conception hybride. Ils protègent les données critiques là où celles-ci sont effectivement stockées et circulent, et ils permettent à l'activité de se poursuivre même lorsque la connexion au cloud est interrompue.

Ce que vous apporte réellement le rapprochement des services chargés de faire respecter la loi

La prolifération des données locales devient visible. Des outils d’IA internes sont mis en place sans qu’aucun enregistrement d’achat n’ait été effectué et deviennent essentiels à l’activité avant même que quiconque n’en dresse l’inventaire. Des copies de données soumises à une réglementation s’accumulent dans des bases de données vectorielles, des ensembles de réglages fins et des disques partagés que les contrôles liés au cloud ne détectent jamais, car aucun élément de ce flux de travail ne franchit de frontière. Seule une inspection de l’infrastructure locale et des flux de travail permet de les détecter.

L'accès est restreint, du réseau jusqu'à l'application. L’autorisation par application au niveau du point d’application local supprime les privilèges excessifs que laisse la gestion au niveau du réseau, et ce pour l’utilisateur au bureau, qui est actuellement l’utilisateur le moins contrôlé du parc informatique.

L'exposition spécifique à l'IA devient ciblable. L’injection de lignes de commande, les tentatives de « jailbreak » et les éléments propriétaires collés ou saisis discrètement dans une ligne de commande ne peuvent être traités que par un élément situé sur le chemin de l’interaction, au niveau du navigateur. Lorsque cette interaction ne quitte jamais le site et qu’aucun élément du site ne se trouve sur son chemin, les contrôles n’ont aucun élément sur lequel agir. C’est en réintégrant le trafic local dans le champ d’application que la sécurité de l’IA devient applicable, quel que soit l’endroit où le contrôle lui-même s’exécute en fin de compte.

La résilience s'améliore au lieu de se dégrader. Un site qui applique les règles localement continue à effectuer des contrôles et à appliquer la politique d’accès même lorsque la liaison vers le cloud est interrompue. Une architecture exclusivement basée sur le cloud, confrontée à la même panne, doit choisir entre interrompre le travail ou le laisser se poursuivre, et personne n’est en mesure de prendre cette décision de manière éclairée dans l’urgence.

Les domaines dans lesquels SSE doit rattraper son retard

Il ne s'agit en rien d'une prévision. Les employés sont déjà au bureau. Les modèles fonctionnent déjà sur l'infrastructure des entreprises. Les autorités de régulation posent déjà les questions relatives à la souveraineté et ne semblent pas près de se désintéresser de la question.

Ce qui n'a pas encore évolué, c'est l'emplacement où les contrôles SSE doivent être mis en place. L'inspection et l'application des mesures SSE dans le cloud partent toujours du principe que le risque provient de l'extérieur de l'entreprise, ce qui correspond de moins en moins à la réalité à chaque trimestre.

Demandez à votre fournisseur de vous expliquer comment il assure la sécurité des processus locaux basés sur l'IA ; précisez quels contrôles s'exécutent sur site, lesquels s'exécutent dans le cloud, et ce qu'il advient de chacun d'entre eux en cas de coupure de la connexion entre eux.

Découvrez comment la nouvelle plateforme Skyhigh Hybrid Mesh SSE étend le modèle « Zero Trust » au sein même des locaux afin de mieux protéger l'IA.

Retour à Blogs