Un regard concret sur la façon dont Jay Chaudhry et Zscaler ont utilisé la sécurité cloud, le zero trust et la distribution via partenaires pour construire une entreprise de sécurité d'entreprise de premier plan.
Ceci n’est pas une biographie de Jay Chaudhry. C’est une histoire pratique sur la manière dont Zscaler a aidé à remodeler la sécurité d’entreprise — et pourquoi ses choix (techniques et commerciaux) ont compté.
Vous apprendrez deux choses en parallèle :
La sécurité d’entreprise moderne est l’ensemble des contrôles qui permet aux employés d’utiliser Internet et les applications internes en toute sécurité, sans supposer qu’une ressource est sûre simplement parce qu’elle se trouve « à l’intérieur » d’un réseau d’entreprise. Il s’agit moins de construire un mur plus grand autour d’un centre de données que de vérifier qui se connecte, à quoi il se connecte, et si la connexion doit être autorisée — à chaque fois.
À la fin, vous pourrez expliquer le pari central de Zscaler en une phrase, reconnaître où le zero trust remplace la pensée de l’ère VPN, et voir pourquoi la stratégie de distribution peut compter autant que la conception du produit.
Jay Chaudhry est un entrepreneur en série surtout connu comme fondateur et CEO de Zscaler, une société qui a contribué à faire évoluer la sécurité d’entreprise de « protéger le réseau d’entreprise » vers « sécuriser les utilisateurs et les applications où qu’ils soient ». Avant Zscaler, il a fondé et vendu plusieurs startups de sécurité, ce qui lui a donné une vision directe de l’évolution rapide des comportements des attaquants et de l’IT d’entreprise.
Le focus de Chaudhry avec Zscaler était simple : à mesure que le travail et les applications quittaient le réseau d’entreprise (vers Internet public et les services cloud), l’ancien modèle consistant à router tout via un data center central pour inspection a commencé à s’effondrer.
Ce changement a créé un compromis douloureux pour les équipes IT :
La prémisse fondatrice de Zscaler était que la sécurité devait suivre l’utilisateur, pas le bâtiment.
Ce qui ressort, c’est la manière dont la vision produit portée par le fondateur a influencé la stratégie dès le départ :
Ce n’était pas un simple ajustement marketing ; cela a orienté les décisions produit, les partenariats et la manière dont Zscaler expliquait le « pourquoi » aux acheteurs d’entreprise conservateurs. Avec le temps, cette clarté a aidé à transformer « sécurité cloud‑délivrée » et « zero trust » en lignes budgétaires — quelque chose que les grandes entreprises pouvaient acheter, déployer et standardiser.
Pendant des années, la sécurité d’entreprise s’est construite autour d’une idée simple : garder « les choses importantes » à l’intérieur du réseau d’entreprise, et dresser un mur autour. Ce mur était généralement une pile d’appliances on‑premise — pare‑feux, proxys web, prévention d’intrusion — situées dans quelques data centers. Les employés distants accédaient via un VPN, qui « étendait » effectivement le réseau interne où qu’ils soient.
Quand la plupart des applications vivaient dans les centres de données de l’entreprise, cela fonctionnait raisonnablement bien. Le trafic web et applicatif passait par les mêmes points de passage, où les équipes de sécurité pouvaient inspecter, journaliser et bloquer.
Mais le modèle supposait deux choses qui sont devenues fausses :
À mesure que les employés sont devenus plus mobiles et que l’adoption du SaaS a accéléré, les schémas de trafic ont basculé. Des personnes dans des cafés ont besoin d’un accès rapide à Office 365, Salesforce et des dizaines d’outils basés sur le navigateur — souvent sans jamais toucher un data center d’entreprise.
Pour continuer à appliquer des politiques, de nombreuses entreprises ont « backhaulé » le trafic : envoyer les requêtes Internet et SaaS d’un utilisateur via le siège d’abord, les inspecter, puis les renvoyer. Le résultat était prévisible : performances lentes, utilisateurs mécontents et pression croissante pour ouvrir des trous dans les contrôles.
La complexité a explosé (plus d’appliances, plus de règles, plus d’exceptions). Les VPN sont devenus saturés et risqués quand ils accordaient un large accès réseau. Et chaque nouvelle agence ou acquisition signifiait un nouveau déploiement matériel, plus de planification de capacité, et une architecture plus fragile.
Ce besoin d’une sécurité cohérente sans forcer tout à passer par un périmètre physique a créé l’ouverture pour une sécurité cloud‑délivrée qui suit l’utilisateur et l’application, pas le bâtiment.
Le pari définissant Zscaler était simple à énoncer mais difficile à exécuter : délivrer la sécurité comme un service cloud, positionné près des utilisateurs, plutôt que sous forme de boîtiers à l’intérieur du réseau de l’entreprise.
Ici, « sécurité cloud » ne signifie pas protéger seulement des serveurs cloud. Cela veut dire que la sécurité elle‑même s’exécute dans le cloud : un utilisateur en agence, à la maison ou sur mobile se connecte à un point de présence (PoP) proche, et la politique est appliquée là.
« Inliner » revient à faire passer le trafic par un point de contrôle avant d’atteindre sa destination.
Quand un employé va sur un site web ou une application cloud, sa connexion est dirigée via le service d’abord. Le service inspecte ce qu’il peut (selon la politique), bloque les destinations risquées, scanne les menaces, puis transmet le trafic autorisé. L’objectif est que les utilisateurs n’aient pas besoin « d’être sur le réseau interne » pour bénéficier d’une protection de niveau entreprise : la sécurité suit l’utilisateur.
La sécurité cloud‑délivrée change la réalité quotidienne des équipes IT et sécurité :
Ce modèle s’aligne également sur la manière dont les entreprises travaillent aujourd’hui : le trafic va souvent directement vers le SaaS et Internet public, pas « retourner au siège » d’abord.
Plaquer un tiers inline soulève de vraies préoccupations à évaluer :
Le pari central n’est donc pas que technique uniquement : il s’agit d’avoir confiance opérationnelle qu’un fournisseur cloud peut appliquer les politiques de manière fiable, transparente et à l’échelle mondiale.
Le Zero Trust est un principe simple : ne jamais supposer qu’une ressource est sûre simplement parce qu’elle est “dans le réseau de l’entreprise”. Au lieu de cela, vérifier toujours qui est l’utilisateur, quel appareil il utilise, et s’il doit accéder à une application ou une donnée spécifique — à chaque fois que c’est pertinent.
La pensée traditionnelle du VPN revient à donner à quelqu’un un badge qui ouvre tout un bâtiment une fois passé la porte. Après la connexion VPN, de nombreux systèmes traitent cet utilisateur comme « interne », ce qui peut exposer plus que nécessaire.
Le Zero Trust inverse ce modèle. C’est plutôt donner à quelqu’un l’accès à une seule pièce pour une tâche. Vous ne « rejoignez pas le réseau » largement ; vous êtes autorisé à atteindre seulement l’application pour laquelle vous êtes approuvé.
Un sous‑traitant a besoin d’accéder à un outil de gestion de projet pendant deux mois. Avec le Zero Trust, il peut être autorisé dans cette seule application — sans créer accidentellement un chemin vers les systèmes de paie ou les outils d’administration interne.
Un employé utilise son propre ordinateur (BYOD) en voyage. Les politiques Zero Trust peuvent exiger des contrôles d’authentification renforcés ou bloquer l’accès si l’appareil est obsolète, non chiffré ou montre des signes de compromission.
Le travail à distance devient plus facile à sécuriser parce que la décision de sécurité suit l’utilisateur et l’application, pas un réseau de bureau physique.
Le Zero Trust n’est pas un produit unique que vous achetez et « activez ». C’est une approche de sécurité mise en œuvre via des outils et des politiques.
Ce n’est pas non plus « ne faire confiance à personne » de manière hostile. En pratique, cela signifie que la confiance se gagne en continu via des vérifications d’identité, l’état des appareils et le principe du moindre privilège — de sorte que les erreurs et les brèches ne se propagent pas automatiquement.
Zscaler se comprend le plus simplement comme un « point de contrôle » cloud placé entre les personnes et ce qu’elles essaient d’atteindre. Plutôt que de faire confiance à une frontière réseau d’entreprise, il évalue chaque connexion selon qui est l’utilisateur et quel est le contexte, puis applique la bonne politique.
La plupart des déploiements se décrivent avec quatre éléments simples :
Conceptuellement, Zscaler divise le trafic en deux voies :
Cette séparation compte : une voie concerne l’usage sûr d’Internet ; l’autre concerne l’accès précis aux systèmes internes.
Les décisions ne reposent pas sur une adresse IP de bureau de confiance. Elles reposent sur des signaux tels que qui est l’utilisateur, la santé de l’appareil (géré vs non géré, patché vs obsolète), et où/comment il se connecte.
Bien exécutée, cette approche réduit la surface d’attaque exposée, limite les mouvements latéraux en cas de problème, et transforme le contrôle d’accès en un modèle de politique plus simple et cohérent — particulièrement pertinent avec le travail à distance et les piles applicatives cloud‑first.
Quand on parle de « sécurité d’entreprise », on imagine souvent des applications privées et des réseaux internes. Mais une grande part du risque se trouve côté Internet ouvert : employés qui consultent des sites d’actualité, cliquent sur des liens dans des e‑mails, utilisent des outils navigateur ou uploadent des fichiers vers des apps web.
Une Secure Web Gateway (SWG) est la catégorie qui rend cet accès Internet quotidien plus sûr — sans forcer tout le trafic des utilisateurs à rebondir via un bureau central.
Simplement, une SWG agit comme un point de contrôle entre les utilisateurs et le web public. Plutôt que de faire confiance à ce qu’un appareil atteint, la gateway applique des politiques et de l’inspection pour réduire l’exposition à des sites malveillants, des téléchargements risqués et des fuites de données accidentelles.
Les protections typiques incluent :
L’accélération est survenue quand le travail s’est déplacé hors des bureaux fixes vers le SaaS, les navigateurs et les mobiles. Si les utilisateurs et les applications sont partout, renvoyer tout le trafic vers un périmètre unique ajoute de la latence et crée des angles morts.
La SWG cloud‑délivrée correspond à la nouvelle réalité : la politique suit l’utilisateur, le trafic peut être inspecté près du point de connexion, et les équipes sécurité obtiennent un contrôle cohérent sur sièges, succursales et télétravail — sans traiter Internet comme une exception.
Les VPN ont été conçus quand « être sur le réseau » signifiait pouvoir atteindre les applications. Ce modèle mental se casse quand les applications se répartissent sur plusieurs clouds, SaaS, et qu’il reste peu de systèmes on‑prem.
L’accès centré sur l’application inverse le défaut. Plutôt que de déposer un utilisateur sur le réseau interne (en espérant que la segmentation tienne), l’utilisateur est connecté uniquement à une application spécifique.
Conceptuellement, cela fonctionne comme une connexion brokerisée : l’utilisateur prouve qui il est et ce à quoi il a droit, puis un chemin court et contrôlé est créé vers cette application — sans publier des plages IP internes sur Internet et sans donner une visibilité interne large à l’utilisateur.
La segmentation réseau est puissante, mais fragile dans les organisations réelles : fusions, VLAN plats, applications legacy et exceptions s’accumulent. La segmentation par application est plus facile à comprendre car elle se rapproche de l’intention métier :
Cela réduit la confiance implicite et rend les politiques d’accès auditable : vous pouvez les vérifier par application et groupe d’utilisateurs plutôt qu’en retraçant des routes et des sous‑réseaux.
La plupart des équipes ne remplacent pas le VPN du jour au lendemain. Un déploiement pratique ressemble souvent à :
Quand l’accès centré sur l’application est bien fait, les gains se voient vite : moins de tickets liés au VPN, des règles d’accès plus claires que sécurité et IT peuvent expliquer, et une expérience utilisateur plus fluide — surtout pour les employés distants et hybrides qui veulent simplement que l’application fonctionne sans « se connecter au réseau » d’abord.
De bons produits de sécurité ne deviennent pas automatiquement des standards d’entreprise. En pratique, la « distribution » en sécurité d’entreprise désigne l’ensemble des voies qu’un fournisseur utilise pour atteindre, gagner et déployer avec succès au sein de grandes organisations — souvent via d’autres entreprises.
En sécurité, la distribution couvre typiquement :
Ce ne sont pas des options. Ce sont les tuyaux qui relient un fournisseur aux budgets, aux décideurs et à la capacité d’implémentation.
Les grandes entreprises achètent prudemment. Les partenaires apportent :
Pour une plateforme comme Zscaler, l’adoption dépend souvent du travail réel de migration : déplacer les utilisateurs hors des modèles VPN legacy, intégrer l’identité et affiner les politiques. Les partenaires rendent ce changement gérable.
La délivrance cloud transforme l’activité d’installations ponctuelles en abonnement, expansion et renouvellements. Cela change la distribution : les partenaires ne sont pas seulement des « clôtureurs de contrats ». Ils peuvent être des partenaires de déploiement continus dont les incitations s’alignent sur les résultats clients — si le programme est bien conçu.
Examinez attentivement les incitations partenaires, la qualité de l’habilitation des partenaires (formation, playbooks, support co‑selling), et la fluidité des rapports de réussite client après signature du contrat. Beaucoup de déploiements échouent non pas parce que le produit est faible, mais parce que la responsabilité entre fournisseur, partenaire et client devient floue.
L’achat en sécurité commence rarement par « nous avons besoin de meilleure sécurité ». Il commence habituellement par un changement réseau qui casse les anciennes hypothèses : des applications migrent vers le SaaS, des sites adoptent SD‑WAN, ou le travail à distance devient permanent. Quand le trafic ne passe plus par un bureau central, le modèle de protection au siège crée latence, exceptions et angles morts.
Zscaler est souvent cité dans les mêmes conversations que SASE et SSE parce que ces étiquettes décrivent un changement dans la manière dont la sécurité est délivrée :
Le vrai « gain traduit » n’est pas l’acronyme : c’est la simplification opérationnelle : moins de boîtiers on‑prem, des mises à jour de politique plus simples, et un accès direct aux applications sans renvoyer le trafic par un data center.
Une société évalue généralement les approches de type SSE/SASE quand :
Quand ces déclencheurs apparaissent, la catégorie « arrive » naturellement — parce que le réseau a déjà changé.
Acheter une plateforme Zero Trust est généralement la partie facile. La faire fonctionner à travers des réseaux compliqués, des applications héritées et des personnes réelles est là où les projets réussissent — ou s’enlisent.
Les applications legacy sont le récidiviste. Les anciens systèmes supposent souvent que « être sur le réseau = digne de confiance », s’appuient sur des allowlists IP codées en dur, ou cassent quand le trafic est inspecté.
Les autres frictions sont humaines : gestion du changement, refonte des politiques, et débats sur « qui possède quoi ». Passer d’un large accès réseau à des règles applicatives précises force les équipes à documenter comment le travail se fait réellement — et cela peut révéler des lacunes longtemps ignorées.
Les déploiements se passent mieux quand la sécurité n’agit pas seule. Attendez‑vous à coordonner avec :
Commencez par un groupe à faible risque (par ex. un département ou un sous‑ensemble de sous‑traitants) et définissez les métriques de succès dès le départ : moins de tickets VPN, accès aux applications plus rapides, réduction mesurable de la surface d’attaque exposée, ou meilleure visibilité.
Menez le pilote par itérations : migrez une catégorie d’apps à la fois, ajustez les politiques, puis étendez. L’objectif est d’apprendre vite sans transformer toute l’entreprise en environnement de test.
Planifiez la journalisation et le dépannage dès le jour 1 : où les logs résident, qui peut les interroger, combien de temps ils sont conservés, et comment les alertes s’intègrent à la réponse aux incidents. Si les utilisateurs ne peuvent pas obtenir d’aide quand « l’app est bloquée », la confiance chute vite — même si le modèle de sécurité est pertinent.
Un accélérateur pratique (et souvent négligé) est l’outillage interne : portails simples pour demandes d’exception, revues d’accès, inventaires d’apps, suivi des déploiements et reporting. Les équipes construisent de plus en plus ces « apps glue » légères elles‑mêmes plutôt que d’attendre la feuille de route du fournisseur. Des plateformes comme Koder.ai peuvent aider les équipes à prototyper et livrer rapidement ces outils internes via un flux de travail piloté par chat — utile quand vous avez besoin d’un dashboard React avec un backend Go/PostgreSQL, plus des itérations rapides à mesure que les politiques et processus mûrissent.
Déplacer des contrôles de sécurité d’appliances que vous possédez vers une plateforme cloud‑délivrée peut simplifier les opérations — mais cela change les modes de défaillance possibles. Une bonne décision n’est pas « Zero Trust vs legacy », mais plutôt comprendre ces nouveaux risques.
Si une seule plateforme fournit la sécurité web, l’accès aux applis privées, l’application des politiques et la journalisation, vous réduisez l’étalement des outils — mais vous concentrez aussi le risque. Un différend contractuel, un changement de tarification, ou un manque fonctionnel peut avoir un impact bien plus large que lorsque ces pièces étaient réparties.
La sécurité cloud ajoute un saut supplémentaire entre les utilisateurs et les apps. Quand tout fonctionne, les utilisateurs ne remarquent presque rien. Quand une région subit une panne, un problème de routage ou de capacité, la « sécurité » peut ressembler à « Internet est en panne ». Ce n’est pas spécifique à un fournisseur, mais c’est le coût d’une dépendance à une connectivité toujours‑disponible.
Le Zero Trust n’est pas une barrière magique. Des politiques mal dimensionnées (trop permissives, trop restrictives, ou incohérentes) peuvent soit augmenter l’exposition, soit interrompre le travail. Plus le moteur de politique est flexible, plus il faut de discipline.
Les déploiements par phases aident : commencer par un cas d’usage clair (par ex. un sous‑ensemble d’utilisateurs ou une catégorie d’apps), mesurer latence et accès, puis étendre. Définissez les politiques en langage clair, mettez en place la supervision et les alertes tôt, et planifiez la redondance (routage multi‑régions, accès de secours « break‑glass », et chemins de repli documentés).
Sachez quels types de données vous protégez (réglementées vs générales), alignez les contrôles sur les exigences de conformité, et planifiez des revues d’accès récurrentes. L’objectif n’est pas d’acheter par peur — c’est de s’assurer que le nouveau modèle échoue de façon sûre et prévisible.
La leçon répétée de Zscaler est la focalisation : déplacer l’application des politiques de sécurité vers le cloud et rendre l’accès piloté par l’identité. En évaluant des fournisseurs (ou en construisant), posez une question simple : « Quel est le pari architectural unique qui rend tout le reste plus simple ? » Si la réponse est « ça dépend », attendez‑vous à voir la complexité revenir plus tard en coûts, temps de déploiement et exceptions.
« Zero trust » a fonctionné parce que cela s’est transformé en une promesse pratique : moins de confiance implicite, moins de plomberie réseau, et un meilleur contrôle à mesure que les applications quittaient l’on‑prem. Pour les équipes, cela signifie acheter des résultats, pas des mots à la mode. Écrivez vos résultats souhaités (par ex. « aucun accès entrant », « moindre privilège aux applis », « politique cohérente pour les utilisateurs distants ») et mappez chacun à des capacités concrètes à tester.
La sécurité d’entreprise se diffuse via des réseaux de confiance : revendeurs, GSIs, MSPs et marketplaces cloud. Les fondateurs peuvent en tirer parti en rendant leur produit prêt pour les partenaires tôt : packaging clair, marges prévisibles, playbooks de déploiement, et métriques partagées. Les responsables sécurité peuvent aussi utiliser les partenaires : les employer pour la gestion du changement, l’intégration d’identité et les migrations par phases plutôt que d’essayer de monter en compétence toutes les équipes internes en même temps.
Commencez par un cas d’usage à fort volume (souvent l’accès Internet ou une application critique), mesurez avant/après, puis étendez.
Questions clés de déploiement :
Ne vous contentez pas de « vendre de la sécurité » — vendez un chemin de migration. L’histoire gagnante est souvent : douleur → première étape la plus simple → gain mesurable → expansion. Construisez l’onboarding et le reporting qui rendent la valeur visible en 30–60 jours.
Un modèle ami des fondateurs est de compléter le produit central par des apps complémentaires rapides à construire (workflows d’évaluation, trackers de migration, calculateurs ROI, portails partenaires). Si vous voulez créer ces outils sans reconstruire une grosse chaîne de dev héritée, Koder.ai est conçu pour « vibe‑coder » des apps full‑stack depuis le chat — utile pour mettre en production rapidement des outils internes ou orientés client, puis itérer à mesure que votre motion de distribution évolue.
Si vous voulez approfondir, voyez /blog/zero-trust-basics et /blog/sase-vs-sse-overview. Pour des idées de packaging, visitez /pricing.
Le Zero Trust est une approche où les décisions d'accès sont prises pour chaque requête en se basant sur l'identité, l'état de l'appareil et le contexte, plutôt que d'assumer qu'une ressource est sûre parce qu'elle est « dans le réseau ». Concrètement, cela signifie :
Un VPN traditionnel place souvent un utilisateur « sur le réseau », ce qui peut exposer involontairement plus de systèmes que nécessaire. L'accès centré sur l'application inverse le modèle :
« Inline » signifie que le trafic est acheminé par un point de contrôle de sécurité avant d'atteindre Internet ou une application cloud. Dans un modèle cloud, ce point de contrôle se trouve dans un point de présence (PoP) proche, ce qui permet de :
L'objectif est d'obtenir une sécurité cohérente sans renvoyer tout le trafic au siège.
Le renvoi (backhauling) envoie le trafic web et SaaS d'un utilisateur distant vers un centre de données central pour inspection, puis le renvoie vers Internet. Cela échoue souvent car :
Une Secure Web Gateway (SWG) protège les utilisateurs lorsqu'ils naviguent sur Internet et utilisent des applications SaaS. Les capacités courantes d'une SWG incluent :
Elle est particulièrement utile lorsque la majeure partie du trafic est dirigée vers Internet et que les utilisateurs ne se trouvent pas derrière un seul pare‑feu d'entreprise.
La sécurité fournie depuis le cloud peut simplifier les opérations, mais elle change ce dont vous dépendez. Principaux compromis à évaluer :
Un pilote à faible risque réussit généralement quand il est étroitement défini et mesurable :
L'objectif est d'apprendre rapidement sans transformer l'ensemble de l'entreprise en environnement de test.
La mauvaise configuration est fréquente parce que le passage de « l'accès réseau » à « l'accès par application/politique » oblige les équipes à définir précisément l'intention. Pour réduire les risques :
SSE couvre des contrôles de sécurité délivrés depuis le cloud (comme SWG et l'accès aux applications privées) fournis « à la périphérie », proches des utilisateurs. SASE combine ce modèle de sécurité avec l'aspect réseau (souvent SD‑WAN) pour concevoir la connectivité et la sécurité ensemble.
En termes d'achat :
Les grandes entreprises achètent souvent via des partenaires et ont besoin de capacités d'implémentation. Les partenaires (channels, SIs, MSPs) aident en :
Un écosystème de partenaires solide peut déterminer si une plateforme devient une norme ou stagne après un petit déploiement.
