Résumé

  • Prosimo a été fondée en 2019 et a levé au moins 55 millions de dollars lors des tours de financement de série A en 2021 et de série B en 2022; les données auditées de chiffre d’affaires ainsi que les informations sur les valorisations et le prix d’acquisition n’ont pas été publiées
  • AXI connectait des directives centralisées, la topologie et l’analyse à des périmètres distribués qui détectaient les ressources cloud, connectaient les applications et inséraient des services de sécurité, sans posséder le réseau physique
  • Après l’intégration de la série VM annoncée en juin 2024, Prosimo est passée sous le contrôle de Palo Alto Networks vers février 2025; la date exacte, le prix et la correspondance actuelle des produits ne sont pas documentés
  • Le contrôle reste réparti entre l’entreprise utilisatrice, le logiciel d’orchestration, les fournisseurs cloud et Palo Alto Networks; le point crucial est donc de savoir si la topologie, les identifiants, les politiques et les autorisations de routage demeurent portables

La marque a disparu, le problème demeure

En 2026, Prosimo ne peut plus être décrit comme un fournisseur actif et indépendant. Les profils publics montrent que les fondateurs et plusieurs employés ont rejoint Palo Alto Networks vers février 2025. Le profil d’entreprise de Prosimo est marqué comme ayant été acquis, et l’ancien directeur technique Nehal Bhau a écrit par la suite que la technologie avait été intégrée aux produits de Palo Alto Networks. Les preuves indiquent un changement de contrôle et une valeur technique persistante. Elles ne documentent ni la date exacte de signature ou de clôture, ni la forme juridique, ni le prix de la transaction.

Cette précision doit être placée en amont car elle modifie le temps de chaque énoncé produit. AXI, Network Transit, App Transit, Application-driven Intelligent Results et Nebula étaient des fonctionnalités documentées de Prosimo durant sa phase d’indépendance. Il ne faut pas les présenter comme des produits encore commercialisés séparément tant que Palo Alto Networks n’a pas publié de correspondance produit et support actualisée. Une architecture historique peut perdurer sous forme de code embarqué, de service partagé, de module ou d’élément d’ingénierie interne après une acquisition; ces formes ne sont pas équivalentes.

La disparition de la marque ne rend pas le problème sous-jacent caduc. Les entreprises continuent de répartir leurs charges de travail entre Amazon Web Services, Microsoft Azure, Google Cloud, leurs propres centres de données, des sites de colocation, des plateformes SaaS et les utilisateurs distants. Chaque environnement possède ses propres routes, passerelles, points de terminaison privés, contrôles d’identité, services de sécurité, quotas et règles de facturation. Une entreprise peut posséder les comptes sans avoir de vue unifiée sur le cheminement d’une requête entre ces environnements.

L’importance de Prosimo réside dans sa tentative de rassembler cette vue au sein d’une couche de contrôle commune.

C’est pourquoi l’acquisition constitue le cœur du récit, et non un simple épilogue. Prosimo a bâti une couche de contrôle multi-cloud capable de détecter les ressources, d’analyser le contexte applicatif et d’orienter le trafic à travers les services de sécurité. Palo Alto Networks est d’abord apparu comme un partenaire technique dont les pare-feu VM-Series pouvaient être insérés dans ces chemins. Par la suite, Palo Alto Networks a absorbé la technologie. La frontière entre l’orchestration du routage et l’inspection de sécurité approfondie s’est ainsi déplacée au sein d’une seule plateforme de cybersécurité.

Dans le routage multi-cloud, le contexte prime

Une table de routage peut indiquer si un préfixe est joignable via un saut suivant déterminé. À elle seule, elle n’explique pas quelle application un utilisateur souhaitait atteindre, si le demandeur est digne de confiance, si un service d’inspection doit examiner le trafic, si un point de terminaison privé est disponible, si un chemin cloud est plus coûteux qu’un autre, ni si une transaction échoue après la livraison des paquets. L’exploitation multi-cloud fait de ces questions un problème de contrôle commun.

La thèse de Prosimo était que les décisions de routage devaient reposer sur plus que la simple accessibilité de couche 3. Le logiciel cherchait à combiner l’inventaire cloud, l’état du réseau, l’identité de l’application, l’identité de l’utilisateur, le risque, la performance et la télémétrie des transactions. Ce contexte plus large permettait des politiques capables de connecter une application spécifique, de segmenter un réseau, de choisir un point d’entrée ou d’orienter le trafic sélectionné à travers un pare-feu.

La valeur ne provenait pas d’un nouveau chemin en fibre optique, mais de la capacité à décider comment assembler les chemins et les services existants.

Cette différence explique l’expression « infrastructure d’expérience applicative ». Elle mettait la requête applicative au centre, et non l’objet réseau isolé. Un VPC, un VNet, un sous-réseau, un hub de transit ou une liaison privée devenaient les maillons d’un chemin de bout en bout, et non l’objet d’administration ultime. Cette approche entraînait le produit vers plusieurs marchés: réseaux cloud, diffusion d’applications, accès Zero Trust, assurance réseau, optimisation des coûts et insertion de services de sécurité.

L’étendue de l’offre créait à la fois des opportunités et du flou. Un produit qui touche plusieurs équipes peut résoudre des problèmes de coordination dont aucune équipe ne se sent responsable, mais il est plus difficile à évaluer car les équipes réseau, sécurité, cloud, applicatives et financières définissent le succès différemment. Prosimo devait démontrer qu’un modèle multi-cloud améliorait l’exploitation sans ajouter une couche privilégiée supplémentaire dont les défaillances affecteraient chaque environnement.

Ce qu’était Prosimo et ce qu’il en reste

Prosimo était une société privée de logiciels de réseau cloud fondée en 2019 dans la baie de San Francisco. Ramesh Prabagaran en était le cofondateur et directeur général, tandis que Nehal Bhau exerçait les fonctions de cofondateur et directeur technique durant la phase indépendante. Des profils publics mentionnent aussi Linus Aranha et Pradeep Aragonda à des postes fondateurs ou de direction technique; leurs titres exacts doivent cependant rester rattachés à des biographies datées.

La plateforme principale s’appelait Application eXperience Infrastructure, généralement désignée par AXI. AXI utilisait une couche logicielle centralisée pour les directives, la topologie, l’analyse et l’orchestration, ainsi que des périmètres AXI distribués dans les régions cloud, les environnements de colocation ou l’infrastructure sur site adjacente. Par la suite, Prosimo a structuré l’offre sous le nom Full-Stack Cloud Transit, Network Transit et App Transit couvrant différentes classes de connectivité. AIR analysait la télémétrie et fournissait des informations opérationnelles; Nebula a ajouté en 2024 une interface conversationnelle.

Prosimo n’était pas un opérateur de cloud. L’entreprise ne possédait pas de réseau dorsal en fibre optique mondial reliant toutes les régions. Les chemins pouvaient emprunter les dorsales des fournisseurs cloud, l’Internet public, des liaisons directes, des liens de colocation et les réseaux d’entreprise. Prosimo n’était pas non plus un fournisseur de pare-feu au même sens que Palo Alto Networks. Son rôle dans l’intégration de 2024 consistait en la découverte de ressources, la segmentation et l’orientation du trafic; la VM-Series assurait l’inspection de sécurité approfondie.

Après l’acquisition, l’expression « continuité technologique » est la plus exacte. La déclaration d’intégration ultérieure mettait l’accent sur la découverte des ressources multi-cloud et le déploiement accéléré de pare-feu logiciels pour l’inspection entrante, sortante et est-ouest. Cela prouve que des composants clés de Prosimo perdurent, mais ne garantit pas que l’intégralité du catalogue AXI historique, le packaging commercial ou le modèle de support soient maintenus sans changement.

Le problème après le SD-WAN

L’équipe fondatrice apportait une expérience des réseaux à grande échelle, de la diffusion d’applications et de l’infrastructure cloud. Prosimo est aussi issue de l’écosystème des fondateurs et ingénieurs de Viptela, l’entreprise qui a contribué à établir le SD-WAN en tant que catégorie. Le problème suivant se situait toutefois ailleurs. Le SD-WAN pouvait simplifier la manière dont les sites distants atteignaient les réseaux et les applications, mais ne créait pas un modèle opérationnel unifié à l’intérieur de plusieurs clouds publics et à travers leurs frontières.

Une application multi-cloud peut dépendre d’un point de terminaison web dans un environnement, d’une base de données ou d’un service géré dans un autre, d’un fournisseur d’identité externe, d’une liaison vers un centre de données privé et d’une inspection de sécurité à des frontières choisies. Chaque dépendance peut apparaître comme un objet natif différent. L’équipe réseau voit des préfixes et des hubs de transit; l’équipe cloud voit des comptes et des objets de ressource; le responsable applicatif voit des domaines et des transactions; l’équipe sécurité voit des zones et des politiques d’inspection.

Prosimo partait de la requête, non du site. La question clé était de savoir comment un utilisateur ou une charge de travail devait atteindre une application avec une sécurité, une performance, une disponibilité et un coût acceptables. Cela déplaçait l’objet de la décision de routage du préfixe de destination seul vers une transaction dotée d’un contexte d’identité et d’application. En même temps, la plateforme devait collecter et maintenir bien plus d’informations qu’un routeur classique.

L’arrivée sur le marché était bien chronométrée. AWS, Azure et Google Cloud développaient leurs services natifs de transit et de connectivité privée. Les entreprises pouvaient construire des réseaux sophistiqués chez un seul fournisseur, mais les API, les objets et les modèles de politiques restaient spécifiques à chaque fournisseur. L’opportunité de Prosimo était de coordonner ces services plutôt que d’obliger chaque client à les remplacer par un réseau dorsal propriétaire distinct.

De la création en 2019 au lancement public en 2021

Prosimo a été fondée en 2019 mais n’a annoncé son lancement public que le 6 avril 2021. General Catalyst a alors mené un tour de série A de 25 millions de dollars. L’investisseur décrivait l’opportunité comme la fourniture d’une expérience applicative cohérente à travers plusieurs clouds, ce qui correspondait à la volonté des fondateurs de définir une catégorie au-delà de la connectivité classique des sites.

Ce lancement introduisait l’entreprise dans un segment dense et encore flou. Les fournisseurs cloud facilitaient l’adoption de leurs propres services réseau. Les fournisseurs de SD-WAN et de SASE étendaient leurs politiques aux environnements cloud. Les fournisseurs de diffusion d’applications pouvaient optimiser les requêtes, les entreprises de sécurité réseau les inspecter. L’argument de Prosimo reposait sur l’association de ces fonctions dans une architecture orientée cloud, sans prétendre remplacer tous les systèmes périphériques.

Le financement donnait de la marge pour les intégrations, les périmètres logiciels, l’analytique, une force de vente et les relations partenaires. Il ne prouvait ni l’adéquation produit-marché, ni la taille du chiffre d’affaires, ni une différenciation durable. Les preuves fournies ne contiennent ni données de revenus auditées, ni chiffres d’ARR, ni nombre de clients, ni valorisation. Le parcours de financement témoigne de la confiance des investisseurs dans une thèse, pas de la performance opérationnelle complète.

En 2022, Prosimo a clôturé un tour de série B de 30 millions de dollars décrit comme sursouscrit. Les deux tours clairement identifiés totalisent un financement vérifié d’au moins 55 millions de dollars. Certaines bases de données peuvent afficher un montant supérieur si elles comptent deux fois les annonces ou des enregistrements connexes; ces sommes ne doivent pas être utilisées sans décomposer les événements sous-jacents.

AXI fixait les politiques au-dessus des clouds et l’exécution au plus près des charges de travail

L’architecture AXI répartissait les tâches entre une couche centralisée de contrôle et d’analyse et des périmètres logiciels distribués. La couche centrale gérait les directives applicatives et réseau, découvrait les ressources, consolidait la topologie, intégrait l’identité, analysait la télémétrie et orchestrait les changements. Les périmètres AXI étaient placés à proximité des charges de travail ou des utilisateurs afin que les politiques puissent être appliquées sans forcer chaque chemin à traverser un hub physique distant.

Cette séparation s’apparente à d’autres systèmes définis par logiciel, mais les objets étaient spécifiques au cloud et aux applications. Le contrôleur avait besoin d’accéder aux comptes et aux API cloud, tandis que le périmètre nécessitait la connectivité aux services de transit natifs, aux réseaux de charge de travail, aux points de terminaison privés ou aux chemins externes. L’autorité de la plateforme découlait de la combinaison des deux vues: directives globales au-dessus des clouds et exécution locale à proximité du trafic pertinent.

L’architecture créait aussi une frontière de déploiement concrète. Chaque périmètre consommait des ressources cloud, exigeait une haute disponibilité et devait être mis à jour, surveillé et protégé. La couche de contrôle nécessitait des identifiants dotés de droits suffisants pour découvrir les ressources et modifier l’état du réseau. Le client obtenait un flux de travail unifié, mais ajoutait un système de gestion dont la disponibilité et l’exactitude conditionnaient l’accessibilité des applications de production.

Prosimo employait parfois le terme de « réseau cloud autonome ». L’automatisation, les recommandations et l’orchestration pilotée par API sont documentées. Ce qui n’est pas documenté, c’est un réseau fonctionnant indépendamment des directives humaines, des services des fournisseurs cloud ou du transport sous-jacent. Les opérateurs continuaient de définir les directives, d’approuver les accès, de traiter les exceptions et d’assumer la responsabilité du résultat.

Un périmètre AXI était une décision de placement, non une appliance ordinaire

Un périmètre AXI pouvait être déployé dans un VPC ou un VNet cloud, dans un environnement de colocation ou dans l’infrastructure adjacente. La documentation technique AWS montrait une VPC de périmètre reliée aux VPC de charge de travail via Transit Gateway, avec un chaînage optionnel de pare-feu et un accès depuis les utilisateurs distants ou les sites sur site. Ce design plaçait le point d’exécution de Prosimo dans la topologie cloud, et non à un périmètre d’entreprise éloigné.

Le placement influait sur plus que la seule latence. Il déterminait où le trafic entrait dans le domaine de politique, quel réseau dorsal cloud ou quel chemin Internet il empruntait, où le chiffrement et l’inspection avaient lieu, et quelle télémétrie la plateforme pouvait collecter. Un périmètre mal placé pouvait provoquer des détours ou des coûts; un périmètre bien placé pouvait raccourcir le chemin ou maintenir le trafic proche de la charge de travail.

La distribution des périmètres multipliait les domaines de défaillance à maîtriser. La capacité, les versions logicielles, le design des zones cloud, la convergence des routes et les droits d’accès pouvaient varier selon les régions. La haute disponibilité ne se résumait pas à deux instances: le contrôleur, les tables de routage cloud, les services de sécurité et les chemins de retour devaient aussi refléter un état de basculement cohérent.

Le périmètre faisait donc partie d’un système d’exploitation plus vaste. Sa valeur dépendait de la cohérence entre la découverte des ressources, la topologie, les politiques et l’analytique avec l’environnement cloud environnant. Celui qui le considère comme une appliance virtuelle autonome passe à côté de l’architecture que Prosimo voulait vendre.

Le réseau sous-jacent restait entre les mains de tiers

Prosimo coordonnait le transport mais ne possédait ni le réseau sous-jacent ni le chemin physique. Un chemin applicatif pouvait utiliser le réseau dorsal d’AWS ou d’un autre fournisseur cloud, l’Internet public, Direct Connect ou ExpressRoute, la colocation, une liaison opérateur ou un réseau d’entreprise. La plateforme pouvait choisir parmi les options disponibles et les orchestrer; elle ne pouvait pas éliminer la latence, la perte de paquets, les domaines de panne ni les modèles tarifaires de ces fournisseurs.

Cette limite est capitale pour les promesses de performance. Un contrôleur peut sélectionner un chemin observé comme meilleur ou rapprocher l’entrée de l’utilisateur. Il ne peut pas garantir qu’un opérateur ne tombe pas en panne, qu’une région cloud reste disponible ou qu’une dépendance externe réponde rapidement. L’expérience applicative inclut aussi le DNS, le traitement serveur, le stockage, le comportement du navigateur et les services tiers hors du contrôle direct du contrôleur réseau.

L’absence de réseau dorsal propriétaire n’était pas seulement une faiblesse. Prosimo pouvait exploiter l’infrastructure que les entreprises payaient déjà et bénéficier des investissements des fournisseurs cloud. Prosimo pouvait atteindre des régions sans déployer sa propre fibre et coordonner des systèmes natifs comme AWS Cloud WAN. Le prix à payer était la dépendance vis-à-vis de la stabilité des API, des quotas de service, des conditions commerciales et de la sémantique propre à chaque fournisseur.

La valeur de la plateforme relevait donc du contrôle opérationnel, non de la propriété physique. Elle devait rassembler des réseaux sous-jacents hétérogènes en un système administré tout en préservant leurs avantages natifs. L’abstraction réduisait-elle ou déplaçait-elle simplement le lock-in? La réponse dépendait de la portabilité des politiques, de la topologie et du déploiement des périmètres.

Network Transit gérait l’accessibilité entre les objets réseau

Network Transit se concentrait sur les VPC, les VNets, les sous-réseaux, les régions, les sites et les segments. Il coordonnait les objets de transit et de routage natifs du cloud afin que les équipes puissent établir la connectivité via un flux de travail partagé, au lieu de configurer chaque fournisseur séparément. Le produit répondait au besoin réseau conventionnel: un préfixe source ou un segment doit atteindre une destination par un chemin autorisé.

Cela ne supprimait pas les différences entre clouds. AWS, Azure et Google Cloud proposent des objets, des quotas et des comportements de routage distincts. Les espaces d’adressage qui se chevauchent, les chemins asymétriques, les points de terminaison privés et les frontières spécifiques aux fournisseurs nécessitaient toujours de l’ingénierie. Prosimo pouvait normaliser les opérations courantes et afficher les relations; les systèmes sous-jacents conservaient leurs propres contraintes.

Network Transit prenait aussi en charge la segmentation. Les domaines de routage et les politiques pouvaient séparer les environnements ou limiter l’accessibilité. Le contrôleur devait comprendre où un segment existait à travers les clouds et comment les objets natifs implémentaient la frontière. Une politique énoncée une seule fois pouvait néanmoins déclencher plusieurs modifications spécifiques à chaque fournisseur.

L’avantage était une interface unifiée pour la définition des politiques. Le risque résidait dans la traduction entre le modèle commun et les configurations cloud natives. Si la politique commune et la configuration cloud divergeaient, l’entreprise pouvait croire un segment protégé alors que l’état du fournisseur disait le contraire. La réconciliation, l’audit et des messages d’erreur clairs étaient donc aussi importants que le flux de déploiement initial.

App Transit faisait de l’application l’objet de la décision de routage

App Transit étendait le modèle au-delà des sous-réseaux. Il pouvait intégrer le domaine applicatif, l’identité, le type de requête, l’état transactionnel, le risque et la performance dans la décision sur la manière dont un utilisateur ou une charge de travail atteignait un service. C’était la tentative la plus affirmée de Prosimo pour différencier sa plateforme d’un simple routeur cloud.

Cette vue applicative était utile car les services modernes ne sont pas toujours représentés proprement par des adresses fixes. Les services gérés, les points de terminaison SaaS et les composants distribués peuvent changer alors que l’identité applicative reste pertinente. Une politique qui fait référence au service ou à l’utilisateur peut être plus pérenne qu’une règle fondée uniquement sur des adresses et des ports.

Ce modèle exigeait un mapping précis. Le contrôleur devait savoir quels domaines et points de terminaison appartenaient à une application, quelles dépendances étaient requises et quelles assertions du fournisseur d’identité étaient fiables. Un mapping obsolète pouvait diriger une requête par le mauvais chemin ou appliquer la mauvaise règle de sécurité. L’abstraction applicative ne supprimait pas le besoin de comprendre l’état du réseau; elle ajoutait une couche sémantique par-dessus.

La combinaison de Network Transit et App Transit reconnaissait que les deux mondes coexistent dans les entreprises. Les systèmes hérités, les sous-réseaux privés et les contrôles basés sur IP subsistent, tandis que les nouvelles applications s’appuient sur des domaines, l’identité et les services gérés. Full-Stack Cloud Transit était le nom produit pour l’exploitation conjointe de ces modèles, pas pour le remplacement de l’un par l’autre.

L’identité élargissait la décision de routage et la frontière de confiance

L’accès orienté application exigeait une intégration de l’identité. La plateforme pouvait utiliser le contexte utilisateur ou charge de travail pour décider si et comment une connexion devait être établie. Cela soutenait une politique Zero Trust dans laquelle la localisation seule ne constituait pas une preuve d’autorité suffisante.

L’identité augmentait la précision mais créait une dépendance supplémentaire. La politique de routage ou d’application dépendait désormais du fournisseur d’identité, de ses assertions, de l’état des sessions et de des données de groupe. Un chemin réseau pouvait échouer à cause d’une authentification indisponible ou d’un attribut modifié, alors même que les routeurs et les périmètres fonctionnaient correctement. Le diagnostic devait franchir la frontière entre les opérations réseau et identité.

Le contrôleur devenait aussi un point de concentration pour un contexte sensible. Il pouvait stocker la topologie, les relations applicatives, les attributs utilisateur, les signaux de risque et les résultats des politiques. Ce jeu de données améliorait le diagnostic et l’optimisation, mais accroissait les conséquences d’un accès non autorisé. Le moindre privilège, la rétention, l’audit et la séparation des fonctions relevaient donc de l’architecture, pas d’ajouts administratifs ultérieurs.

L’approche de Prosimo illustre un changement plus large de l’infrastructure: les politiques de routage et d’accès dépendent de plus en plus de l’identité et de la sémantique applicative. Plus une plateforme voit de contexte, plus ses décisions peuvent être utiles — et plus son autorité doit être étroitement contrôlée.

La découverte des ressources créait le graphe dont dépendait toute décision ultérieure

Un contrôleur multi-cloud ne peut pas gérer ce qu’il ne voit pas. Prosimo a développé la découverte des actifs cloud et des cartes pour les VPC, VNets, sous-réseaux, applications, connectivité et relations de sécurité. Ces vues soutenaient l’intégration, la conception, le diagnostic et les politiques.

Cette collecte était stratégique car les paysages cloud évoluent en dehors des flux de travail réseau centralisés. Les équipes applicatives peuvent créer des comptes, des réseaux, des points de terminaison et des services gérés via leur propre automatisation. Les diagrammes maintenus manuellement deviennent obsolètes. Un inventaire basé sur les API peut produire un graphe plus à jour, mais son exhaustivité dépend de la couverture des comptes, des autorisations, de la logique d’analyse et des API des fournisseurs.

Le graphe n’était pas qu’une documentation: c’était la structure de données à partir de laquelle le routage, la segmentation, l’insertion de services et l’optimisation étaient calculés. Si une ressource ou une dépendance manquait, toutes les conclusions qui en dépendaient pouvaient être erronées. La topologie devait donc être accompagnée de preuves de provenance: moment de la collecte, compte source, régions couvertes et requêtes ayant échoué.

Le graphe aide aussi à expliquer l’acquisition. Palo Alto Networks peut créer une valeur de sécurité supplémentaire s’il sait où se trouvent les charges de travail et les chemins de trafic. Un système capable de découvrir les ressources cloud et de modifier les routes réduit le délai entre l’achat d’un pare-feu logiciel et son placement correct. Bhau a plus tard explicitement souligné la découverte des ressources et le déploiement accéléré des pare-feu logiciels.

AIR déduisait des recommandations opérationnelles à partir de la télémétrie des périmètres

Application-driven Intelligent Results, ou AIR, analysait la télémétrie des périmètres AXI. La documentation AWS décrivait des informations sur le temps d’aller-retour, le temps de traitement, le temps de réponse applicative, le type de transaction, le risque et le résultat des politiques. La plateforme pouvait corréler les données utilisateur, réseau et applicatives au lieu de présenter des compteurs de périphériques isolés.

Cette corrélation répondait à un problème opérationnel connu. Une transaction lente peut être causée par le chemin utilisateur, le périmètre, le réseau dorsal cloud, le service de sécurité ou l’application elle-même. Une vue transversale peut orienter la recherche plus rapidement que des consoles séparées et soutenir des recommandations sur le chemin, le placement, le risque ou le coût.

La qualité d’une recommandation dépendait de la couverture de télémétrie et du modèle d’interprétation. Un périmètre ne voyait que le trafic qui le traversait. Les dépendances applicatives externes et l’état interne des fournisseurs pouvaient rester invisibles. Une recommandation pouvait indiquer une direction sans en prouver la cause.

La télémétrie avait aussi une valeur de gouvernance. Les observations historiques pouvaient expliquer pourquoi une route ou une politique avait changé. Elles pouvaient aussi révéler des informations sensibles sur l’usage des applications et le comportement des utilisateurs. Les documents publics ne décrivent pas complètement la rétention et la gouvernance des données après l’acquisition; ces points relèvent de la due diligence des clients.

AWS a fourni la mise en œuvre la mieux documentée

Le travail de Prosimo avec AWS a produit les preuves techniques publiques les plus solides. L’entreprise prenait en charge AWS Transit Gateway, Cloud WAN, PrivateLink et le flux de déploiement de Marketplace for Containers Anywhere. AWS a publié un guide sur le placement des périmètres AXI, l’intégration des applications, l’identité, la sécurité et l’optimisation.

AWS Cloud WAN était particulièrement significatif. Il fournissait un réseau dorsal cloud natif et un service de segmentation que Prosimo pouvait orchestrer plutôt que remplacer. Cette architecture illustrait le modèle coopératif: AWS possédait le réseau natif et l’infrastructure mondiale; Prosimo fournissait les directives multi-cloud, le contexte applicatif, le logiciel de périmètre et l’analyse.

Le flux Marketplace simplifiait la première étape de déploiement en empaquetant AXI Edge via un canal approuvé. Le travail sur les droits des comptes, le design de routage, la haute disponibilité, la capacité et l’exploitation restait à accomplir. L’automatisation du jour zéro peut réduire l’effort d’installation sans éliminer le problème de contrôle à long terme.

Une référence client nommée Flexport étayait le cas d’usage AWS Cloud WAN dans les supports de l’entreprise. Elle prouve qu’un client professionnel soutenait publiquement l’architecture, mais ne constitue pas une évaluation indépendante de l’ampleur, des économies ou de la disponibilité. Les témoignages clients doivent donc servir d’exemples d’adoption, non de preuve de performance générale.

Azure et Google Cloud complétaient l’offre multi-cloud

Prosimo prenait également en charge Microsoft Azure et Google Cloud. Les supports produits décrivaient l’orchestration d’Azure Virtual WAN ainsi que des objets réseau et de services privés de Google Cloud. L’objectif était un modèle opérationnel partagé, tandis que le réseau natif de chaque fournisseur subsistait.

Cette prise en charge ne prouve pas des fonctionnalités identiques. Les API cloud mûrissent à des rythmes différents et des noms de produits comparables peuvent cacher des sémantiques différentes. Les routes, les segments, les points de terminaison privés et l’insertion de services pouvaient nécessiter un traitement spécifique à chaque fournisseur. Les preuves disponibles ne permettent pas une matrice complète de comparaison fonctionnelle pour toutes les régions et versions.

L’abstraction multi-cloud se comprend donc mieux comme un système de traduction. Elle peut normaliser des directives et des flux de travail communs, mais doit préserver les détails qui influent sur la sécurité, les coûts et les pannes. Une plateforme devient risquée si l’interface semble uniforme et que les différences de mise en œuvre sont cachées aux opérateurs.

Ce constat vaut après l’acquisition. Palo Alto Networks peut utiliser le graphe commun pour placer les contrôles de sécurité à travers plusieurs clouds, mais les fournisseurs cloud continuent de contrôler les objets natifs qui réalisent le chemin. La propriété de la couche d’orchestration n’équivaut pas à la propriété du réseau sous-jacent cloud.

Le produit est passé de la connectivité à un modèle de cycle de vie

En 2023, Prosimo décrivait des flux de travail pour la conception, la construction, le diagnostic et l’exploitation des réseaux multi-cloud. Le produit allait au-delà de la simple configuration de tunnels ou de passerelles. La découverte des ressources alimentait le design; l’orchestration créait la connectivité; les cartes et la télémétrie aidaient au diagnostic; les politiques et les états historiques soutenaient l’administration courante.

Cette perspective de cycle de vie élargissait le cercle des acheteurs potentiels. Les ingénieurs réseau pouvaient utiliser l’analyse de topologie et de chemin; les équipes plateforme cloud pouvaient intégrer les comptes et les services; les équipes sécurité pouvaient vérifier la segmentation et l’inspection; les équipes migration pouvaient planifier les changements; les équipes FinOps pouvaient examiner les impacts sur le routage et la sortie. La valeur de la plateforme augmentait lorsque plusieurs groupes accédaient au même socle de données.

Un socle de données commun peut provoquer des conflits de gouvernance. Une plateforme centrale peut révéler que la configuration native d’une équipe cloud s’écarte de la politique d’entreprise. L’organisation doit décider quel système fait autorité et qui approuve la remédiation. Le logiciel seul ne résout pas cette question institutionnelle.

Le modèle de cycle de vie augmentait aussi les coûts de changement. Si un contrôleur gère le graphe d’actifs, les politiques, la télémétrie, les placements des périmètres et les intégrations d’automatisation, son remplacement exige plus que le basculement d’une connexion. Le client doit exporter ou reconstruire le modèle opérationnel. Prosimo promettait de réduire la fragmentation cloud, tout en créant la possibilité d’une dépendance au contrôleur.

La segmentation allait de l’accessibilité réseau à la politique applicative

Prosimo décrivait une segmentation de la couche 3 à 7. Au niveau réseau, les domaines de routage et les segments déterminaient quels sous-réseaux ou sites pouvaient communiquer. Aux niveaux supérieurs, l’identité applicative, le contexte utilisateur et les caractéristiques des transactions pouvaient affiner la règle.

Ce modèle en couches pouvait réduire l’écart entre la zone réseau et la politique applicative. Un service métier pouvait être autorisé alors que l’accessibilité large de sous-réseau à sous-réseau restait bloquée. Inversement, un chemin réseau accessible pouvait être refusé si l’identité ou le contexte applicatif ne correspondait pas.

Cela ne faisait pas de Prosimo un pare-feu nouvelle génération complet. L’intégration de 2024 avec Palo Alto Networks séparait les rôles: Prosimo orchestrait les routes, la segmentation et l’insertion de services; la VM-Series assurait l’inspection approfondie. La distinction est importante car le pilotage des politiques et la mise en œuvre de la sécurité échouent différemment.

Un segment n’est efficace que si tous les chemins pertinents sont représentés. Une route inconnue, une exception native du cloud ou une insertion de service manquée peut contourner le contrôle prévu. La sécurisation exigeait donc une comparaison entre la politique déclarée et l’état effectif chez le fournisseur cloud et le trafic observé; la vue de configuration du contrôleur seule ne suffisait pas.

L’insertion de services liait le contrôle de routage à l’économie des pare-feu

La conception de la sécurité cloud impose de décider où l’inspection a lieu. Des pare-feu centralisés peuvent simplifier les politiques et réduire le nombre d’appliances, mais créent du backhaul, de la concentration et une pression de scalabilité. Des pare-feu distribués restent plus proches des charges de travail et réduisent certaines distorsions de chemin, mais multiplient les déploiements, les licences, les mises à jour et la gestion des politiques.

Prosimo soutenait les deux schémas dans l’intégration VM-Series. Les politiques pouvaient diriger le trafic sélectionné à travers un point d’inspection centralisé ou via des pare-feu distribués dans les VPC applicatives. Le contrôleur mettait à jour les routes environnantes tandis que Palo Alto Networks fournissait la fonction d’inspection.

L’orchestration du routage devenait ainsi commercialement précieuse pour un fournisseur de sécurité. Un pare-feu logiciel ne peut pas protéger un trafic qui ne l’atteint jamais. La découverte des ressources, le placement et les modifications de routage réduisent l’effort nécessaire pour insérer la capacité de sécurité acquise dans un chemin actif. C’est une raison stratégique plausible pour Palo Alto Networks d’avoir absorbé la technologie de Prosimo.

En même temps, le rayon d’impact du contrôleur s’élargissait. Une politique défaillante peut contourner l’inspection, créer des boucles, provoquer un routage asymétrique ou désactiver une application. Les contrôles de santé du système, les changements progressifs, la simulation, l’audit et la réversibilité sont indispensables car une erreur d’insertion de service est à la fois un événement réseau et un événement de sécurité.

Le partenariat de 2024 ne doit pas être considéré rétrospectivement comme une acquisition

Prosimo et Palo Alto Networks ont annoncé l’intégration VM-Series le 12 juin 2024. La communication décrivait une solution technique et commerciale conjointe. Elle ne déclarait pas que Palo Alto Networks avait acquis Prosimo. Traiter cette annonce comme une preuve de propriété revient à fusionner deux événements distincts.

Le partenariat a néanmoins créé une passerelle. Prosimo pouvait montrer comment son système de routage et de politiques facilitait le déploiement de la VM-Series à travers les clouds. Palo Alto Networks pouvait évaluer la technologie dans une intégration réelle avant le transfert ultérieur de l’entreprise. Les preuves publiques ne décrivent pas le processus d’acquisition; affirmer que le partenariat était formellement conçu comme prélude à l’acquisition relèverait de la spéculation.

Début 2025, les profils des fondateurs et des employés avaient changé. La page entreprise a plus tard affiché une mention d’acquisition. Fin 2025, Bhau a déclaré que la technologie avait été entièrement intégrée aux produits de Palo Alto Networks. Ces documents, pris ensemble, étayent la conclusion de l’acquisition tout en laissant ouverts les mécanismes juridiques.

L’enchaînement importe pour l’exactitude rédactionnelle et pour les clients. Un partenariat signifie deux fournisseurs, deux structures de support et une frontière d’intégration définie. Une acquisition peut transférer les feuilles de route, les données, les contrats et l’autorité au sein d’une seule société. La transition modifie plus que la marque, même si le chemin technique semble d’abord similaire.

Nebula rendait le graphe topologique accessible via une interface conversationnelle

Prosimo a présenté Nebula en février 2024 comme une suite d’IA pour les réseaux multi-cloud. L’assistant devait répondre en langage naturel à des questions sur les réseaux qui se chevauchent, les coûts, l’état des routes, les violations de politique de sécurité et d’autres états reflétés dans le graphe et la télémétrie de la plateforme.

L’actif précieux n’était pas l’interface conversationnelle en soi, mais le contexte structuré multi-cloud sous-jacent. Un modèle général ne peut pas diagnostiquer une route privée ou un segment qu’il ne voit pas. Nebula pouvait exploiter l’inventaire des actifs, la topologie, les politiques et les observations que Prosimo collectait déjà. Cela rendait pertinente l’investissement antérieur dans un graphe commun pour l’AIOps.

L’accès conversationnel pouvait rendre des données complexes accessibles à davantage d’opérateurs. Il pouvait aussi créer une confiance excessive si une réponse omettait un actif non pris en charge, comprenait mal la question ou traitait une recommandation comme une action approuvée. Les changements à risque élevé nécessitaient toujours des contrôles déterministes, des limites de privilèges et une vérification humaine.

Prosimo annonçait des améliorations possibles telles qu’une réduction de 60 à 80 % du délai moyen de résolution et une baisse de plus de 60 % des coûts réseau cloud. Ces chiffres provenaient d’une annonce produit de l’entreprise. Les preuves disponibles ne contiennent ni méthodologie indépendante, ni référentiel client attestant une validité générale. Ils peuvent être cités comme les bénéfices avancés par Prosimo, non comme des faits de marché mesurés.

Les charges de travail IA étaient un nouveau cas d’usage, pas la preuve d’un nouveau marché

La même annonce de 2024 présentait l’architecture de Prosimo comme utile pour les charges de travail d’IA. Les systèmes d’IA distribués peuvent nécessiter un accès privé aux données, des connexions entre clouds et centres de données, des contrôles de conformité et un routage tenant compte du comportement applicatif. Ces exigences cadraient avec le modèle existant d’actifs, de politiques et de chemins.

Cette appellation ne modifiait pas le réseau sous-jacent. Prosimo restait dépendant des réseaux cloud, des opérateurs et de l’infrastructure client. L’entreprise ne fournissait ni calcul GPU ni logiciel de développement de modèles. Son rôle potentiel était la couche de connectivité et de sécurité pour les données et services distribués.

Le positionnement IA était stratégiquement compréhensible car la valeur d’une topologie multi-cloud augmente avec la distribution des données et des services. C’était aussi une catégorie marketing introduite peu avant la fin de l’activité indépendante. Les documents ne prouvent ni des revenus IA séparés, ni des déploiements productifs nommément attestés, ni des résultats de charge de travail audités.

Le constat durable est que la télémétrie multi-cloud peut devenir une base pour des opérations assistées par machine. La question produit aujourd’hui est de savoir si Palo Alto Networks a conservé ce contexte et comment il rend la fonction accessible. Les informations publiques disponibles à la date butoir n’apportent pas de réponse complète.

Le modèle économique vendait du logiciel pour une infrastructure que Prosimo ne possédait pas

L’activité indépendante de Prosimo reposait sur un modèle d’abonnement logiciel et de services, pas sur un modèle d’opérateur. Les clients déployaient les périmètres AXI dans leurs environnements et connectaient leurs comptes cloud à la couche de contrôle. Les revenus provenaient probablement de licences ou d’abonnements, de support, de services professionnels et de l’activité des partenaires commerciaux; les prix concrets et les indicateurs contractuels n’ont pas été publiés dans les preuves disponibles.

Ce modèle pouvait évoluer sans fibre propriétaire. Une plateforme logicielle coordonnait de nombreuses régions cloud et environnements clients. On ne peut toutefois pas en déduire des marges brutes. Le support d’ingénierie pour les API des fournisseurs, le cycle de vie des périmètres, les intégrations de sécurité et le déploiement en entreprise peut être coûteux, tandis que les ressources cloud consommées par le périmètre sont possiblement payées par le client et non par le fournisseur.

Prosimo utilisait les marketplaces cloud, les partenaires d’intégration et de vente, ainsi que des références clients nominatives pour atteindre les entreprises. Ces relations ne sont pas équivalentes. Une présence sur une marketplace atteste d’un chemin d’achat et de déploiement. Une intégration technique atteste que deux systèmes peuvent être combinés dans des conditions définies. Un témoignage client fournit une référence. Aucun ne prouve à lui seul le nombre de clients payants ou les revenus récurrents.

La largeur de l’offre a pu accroître la complexité commerciale. Les équipes réseau, sécurité, cloud et applicatives pouvaient en bénéficier, mais la responsabilité budgétaire pouvait être floue. Le produit avait besoin d’un sponsor prêt à financer une couche de contrôle partagée plutôt que des opérations séparées pour chaque cloud et chaque équipe.

Partenaires, clients et investisseurs remplissaient des rôles distincts

Amazon Web Services était à la fois fournisseur de réseau sous-jacent et partenaire de mise sur le marché. Azure et Google Cloud étaient des environnements supportés. Les fournisseurs d’identité apportaient le contexte d’authentification, tandis que les fournisseurs de pare-feu assuraient l’inspection. Les services de colocation et les opérateurs pouvaient héberger ou connecter les périmètres. Les partenaires commerciaux pouvaient concevoir et exploiter les déploiements.

Flexport apparaissait comme référence client nominative dans les supports AWS Cloud WAN. Cette référence montre un intérêt d’entreprise pour l’architecture, mais n’indique ni l’étendue complète, ni la durée, ni la valeur commerciale du déploiement. Elle ne doit pas servir de substitut à l’ensemble de la base clients.

General Catalyst a mené la série A et était impliqué dans la gouvernance via son rôle d’investisseur. Des investisseurs liés à WRVI ou Celesta apparaissaient dans les supports de l’entreprise; des communications ultérieures de Prosimo mentionnaient des participations supplémentaires de premier plan, dont un nom associé à BlackRock dont le véhicule d’investissement exact reste non précisé dans les recherches. Ces documents montrent une base de financement bien connectée, non un tableau de capitalisation complet.

Palo Alto Networks a occupé la position la plus déterminante: partenaire de sécurité en 2024, l’entreprise est devenue acquéreuse début 2025. Cette séquence montre comment une dépendance d’écosystème se transforme en relation de contrôle lorsque l’un des acteurs achète la couche logicielle qui coordonne le chemin vers son propre produit.

Au moins 55 millions de dollars ont été levés; l’issue économique de la vente reste inconnue

Le financement vérifié se compose d’une série A de 25 millions de dollars en avril 2021 et d’une série B de 30 millions de dollars en 2022. Le total s’établit à au moins 55 millions de dollars. Les preuves fournies ne contiennent ni tableau de capitalisation audité, ni indications de valorisation, ni structure de dette, ni tours de financement ultérieurs.

Le prix d’acquisition n’a été ni publié ni confirmé de manière indépendante. En l’absence de prix, on ne peut pas qualifier l’issue de prime stratégique, d’achat technologique modeste, d’embauche d’équipe ou de vente en difficulté. L’intégration produit en cours atteste une valeur technologique, mais ne révèle pas le rendement pour les investisseurs ou les fondateurs.

Le chiffre d’affaires et la position de marché de Palo Alto Networks ne doivent pas être attribués à Prosimo après l’acquisition. Dès lors que la startup n’est plus observable séparément, on ne peut plus analyser un segment de revenus, de bénéfices ou de clients distinct. Un propriétaire plus grand peut rendre la technologie plus largement disponible tout en rendant sa contribution économique autonome moins visible.

L’absence d’annonce formelle d’acquisition est elle-même pertinente. Clients, employés et chercheurs utilisent normalement ces annonces pour déterminer le calendrier, le support et la logique stratégique. Ici, le statut doit être reconstitué à partir de profils professionnels, d’une mention sur la page entreprise et d’une déclaration ultérieure du fondateur. Cela suffit pour corriger le statut de l’entreprise, pas pour inventer des détails transactionnels.

La concurrence venait des plateformes, des clouds et du développement interne

Prosimo était en concurrence avec des plateformes réseau multi-cloud spécialisées comme Aviatrix et Alkira, avec des fournisseurs de réseau d’entreprise et de SASE, ainsi qu’avec les services natifs d’AWS, Azure et Google Cloud. Elle rivalisait aussi avec un modèle « fait maison » où les entreprises utilisent directement l’infrastructure sous forme de code, les services de transit des fournisseurs, les tables de routage et les pare-feu. Chaque alternative résolvait une partie différente du même problème.

Un contrôleur spécialisé pouvait offrir un modèle de topologie et de politiques transversal aux fournisseurs. Une conception cloud native pouvait réduire la dépendance aux tiers et être étroitement adaptée à un fournisseur. Un service adossé à un opérateur pouvait fournir le transport physique. Une plateforme SASE ou de sécurité pouvait combiner connectivité et mise en œuvre des politiques. Le développement interne préservait le contrôle mais augmentait la charge en personnel et en intégration.

La différenciation de Prosimo tenait à la combinaison du transit applicatif et réseau, des périmètres distribués, de l’orchestration cloud native, de la topologie, de la télémétrie et de l’insertion de services. Cette même largeur rendait les comparaisons difficiles. Les acheteurs devaient tester les services cloud concrets, les routes, les systèmes d’identité et les schémas de sécurité qu’ils comptaient employer, plutôt que de comparer des noms de catégories.

L’acquisition modifie le cadre concurrentiel. Prosimo n’a plus à s’imposer comme fournisseur indépendant, mais sa technologie doit prouver sa valeur au sein de Palo Alto Networks. La question clé est de savoir si la découverte intégrée des ressources et l’orchestration du routage améliorent le déploiement des produits de sécurité de Palo Alto Networks, et si les clients acceptent la dépendance de plateforme qui en résulte.

Les services cloud natifs étaient à la fois une fondation et un substitut

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN et les services réseau de Google Cloud offraient aux entreprises de puissantes options natives. Prosimo dépendait de ces services tout en étant en concurrence avec leur utilisation directe par les clients.

Cette relation créait une frontière mobile. Si un fournisseur cloud ajoutait du routage global, de la segmentation, un accès privé aux services ou des politiques centralisées, certaines fonctions tierces devenaient plus faciles à reproduire en natif. En même temps, chaque nouveau service natif ajoutait un objet supplémentaire qu’un contrôleur multi-cloud devait découvrir et coordonner. Les progrès des fournisseurs cloud pouvaient réduire une partie de la valeur de Prosimo tout en augmentant le besoin de traduction entre fournisseurs.

Le facteur décisif était autant organisationnel que technique. Une entreprise mono-cloud dotée d’une forte ingénierie interne pouvait préférer les outils natifs. Une entreprise multi-cloud avec des équipes fragmentées pouvait préférer une couche de contrôle commune. Une organisation réglementée pouvait privilégier une couche de contrôle et de preuve indépendante tout en redoutant la concentration des identifiants et des données.

Aucune architecture n’éliminait le lock-in. Les outils natifs accroissaient la dépendance aux API et à la sémantique d’un fournisseur cloud. Un contrôleur multi-cloud augmentait la dépendance à son graphe, à ses politiques et à son logiciel de périmètre. La question pertinente était de savoir si cette dépendance était visible, portable et adaptée au modèle opérationnel de l’organisation.

Les défaillances pouvaient survenir dans le contrôleur, le périmètre, les API cloud, le système d’identité ou le réseau sous-jacent

L’architecture distribuée de Prosimo réduisait la dépendance à un hub de trafic unique, mais créait plusieurs domaines de défaillance interdépendants. Le service central pouvait tomber en panne ou contenir des directives périmées. Un périmètre pouvait échouer ou être isolé. Une API cloud pouvait rejeter une partie d’un changement. Le fournisseur d’identité pouvait défaillir. Le réseau sous-jacent pouvait perdre de la capacité ou prendre un chemin inattendu. Un pare-feu inséré pouvait épuiser ses ressources.

Les défaillances partielles sont particulièrement difficiles. Un fournisseur peut accepter une modification de routage tandis qu’un autre la refuse. L’état voulu par le contrôleur diverge alors de l’état cloud réel. Le trafic peut devenir asymétrique ou contourner l’inspection. Un système fiable exige une réconciliation, des opérations idempotentes, des changements progressifs, des états d’erreur clairs et un rollback qui tient compte du comportement de chaque fournisseur.

Les preuves publiques décrivent la disponibilité et l’optimisation à haut niveau, mais ne contiennent aucune étude indépendante d’injection de fautes, aucun historique complet d’incidents, ni aucun résultat de niveau de service universellement valide. Les affirmations de résilience doivent donc être rattachées à l’architecture documentée ou à des retours clients nommément attestés.

L’acquisition introduit un autre domaine de défaillance: la continuité du produit. Les clients doivent savoir quelle console, quelle API, quelle image de périmètre, quel modèle de politiques et quelle organisation de support remplacent le système Prosimo historique. Une intégration de code techniquement réussie peut néanmoins générer des risques de migration si les frontières commerciales et opérationnelles restent floues.

Les identifiants cloud faisaient du contrôleur un élément de la couche de gestion critique

La découverte des actifs et l’orchestration exigeaient un accès aux comptes cloud. Un inventaire en lecture seule pouvait fonctionner avec des droits limités; les modifications des routes, des segments et de l’insertion de services demandaient des autorisations plus étendues. Le contrôleur se situait ainsi dans la couche de gestion privilégiée, bien qu’il ne possédât pas les charges de travail.

Une compromission des identifiants pouvait révéler la topologie ou permettre des modifications à grande échelle. Un bug logiciel ou une erreur humaine pouvait propager des politiques à travers plusieurs clouds. Le risque croissait avec l’utilité de la plateforme: plus elle gérait de comptes et de services, plus le rayon d’impact potentiel était large.

Les entreprises avaient besoin de rôles à moindre privilège, d’identifiants distincts pour la détection et la modification, d’une approbation multipartite, d’audits complets, de rotations, d’une révocation d’urgence et d’un chemin de restauration qui ne dépende pas uniquement du même contrôleur. Les documents publics ne contiennent aucune évaluation de sécurité indépendante complète; ces points restent donc des contrôles de déploiement indispensables, non des garanties produit vérifiées.

Le graphe de télémétrie était tout aussi sensible. Il pouvait révéler les noms des applications, la structure réseau, les politiques, les relations utilisateur, l’état des routes et les modèles de coûts. La gouvernance post-acquisition devrait clarifier où les données sont stockées, quels produits Palo Alto Networks peuvent y accéder, et comment les autorisations des clients existants ont été migrées. Les informations publiques ne répondent pas à ces questions.

L’acquisition a fait basculer une couche neutre en termes de cloud vers une plateforme de sécurité

La position indépendante de Prosimo lui permettait de se présenter comme une couche commune au-dessus des clouds et des services de sécurité. Avec Palo Alto Networks comme propriétaire, les incitations ont changé. La technologie absorbée pouvait faciliter le déploiement des VM-Series et d’autres produits Palo Alto Networks. Cela peut créer une expérience mieux intégrée et soulever des questions sur le support des services d’inspection tiers.

La propriété ne prouve pas que la neutralité a disparu. Les documents ne contiennent ni matrice partenariale actualisée ni architecture produit à jour. Ils modifient cependant la question que les clients devraient poser. Il s’agit de vérifier si le contrôleur de routage reste ouvert à plusieurs fournisseurs de sécurité, si les politiques et la télémétrie sont exportables, et si l’optimisation favorise le portefeuille du propriétaire.

La déclaration d’intégration mettait l’accent sur l’inspection entrante, sortante et est-ouest. Cela suggère que la topologie et l’orchestration de Prosimo sont devenues partie intégrante d’un système de fourniture de capacités de sécurité. Cela ne prouve pas que la fonction historique App Transit, l’accès utilisateur, l’optimisation des coûts ni l’ensemble des flux de travail réseau cloud subsistent en tant que capacités séparées.

C’est un schéma fréquent dans l’infrastructure. Une startup abstrait un problème de coordination difficile; un fournisseur de plateforme plus grand achète l’abstraction parce qu’elle accroît l’adoption et le contrôle de son produit cœur. L’acheteur gagne un chemin plus rapide vers le déploiement. Le client peut gagner en intégration et perdre une partie de l’indépendance vis-à-vis des fournisseurs.

La correspondance actuelle des produits est la plus grande lacune d’information

Les informations publiques disponibles confirment l’acquisition et l’intégration, mais ne contiennent pas de correspondance complète entre AXI, Network Transit, App Transit, AIR, Nebula et les produits ou SKU actuels de Palo Alto Networks. Les échéances de support hérité, les procédures de migration et une comparaison fonctionnelle pour la continuité produit font également défaut.

Cette lacune empêche une évaluation du produit dans le présent. Les descriptions historiques expliquent ce que Prosimo a construit et en quoi c’était important, mais ne disent pas quelles fonctionnalités sont aujourd’hui disponibles, sous licence ou supportées. Les recommandations de déploiement actuelles doivent s’appuyer sur la documentation à jour de Palo Alto Networks, non sur les annonces archivées de Prosimo.

L’absence de correspondance limite aussi l’analyse stratégique. Une reprise complète du graphe topologique et de la couche d’orchestration serait différente d’une utilisation sélective de la découverte d’actifs et du placement de pare-feu. Le premier cas donnerait un vaste service de contrôle multi-cloud; le second exploiterait Prosimo principalement pour accélérer le déploiement des capacités de sécurité. La déclaration du fondateur soutient la continuité technologique tout en laissant cette frontière architecturale ouverte.

Un futur document produit, un guide de migration ou une étude de cas client pourrait lever une grande partie de l’incertitude. D’ici là, la formulation précise est la suivante: selon les dires d’un cofondateur, la technologie de Prosimo a été intégrée aux produits de Palo Alto Networks; l’étendue et le packaging produit ne sont pas vérifiés.

Qui contrôle le routage multi-cloud?

Aucune partie ne contrôle la totalité du chemin. L’entreprise possède les comptes, définit les objectifs métier et le design applicatif, et attribue les identifiants. Un contrôleur multi-cloud peut capturer la topologie, traduire les politiques, choisir les chemins et modifier l’état de routage natif. Les fournisseurs cloud contrôlent les API, les services de transit, les points de terminaison privés, le réseau dorsal et de nombreux domaines de défaillance. Les opérateurs et les fournisseurs de colocation contrôlent d’autres segments du transport. Les services de sécurité décident si le trafic inspecté est autorisé.

Prosimo visait la position intermédiaire la plus stratégiquement utile. Elle ne possédait pas le réseau sous-jacent mais cherchait à contrôler le graphe et la traduction des politiques qui le surplombait. Qui contrôle cette couche peut décider quels actifs sont visibles, comment les segments sont représentés, où les périmètres sont placés, quel service inspecte le trafic et quelle télémétrie fait autorité. C’est là un contrôle opérationnel du routage, même si la fibre appartient à quelqu’un d’autre.

Après l’acquisition, Palo Alto Networks possède la technologie restante de Prosimo et détermine comment elle est intégrée, empaquetée et développée. Les fournisseurs cloud restent souverains sur leurs environnements; l’entreprise peut révoquer les identifiants ou choisir une autre architecture. La sortie peut néanmoins être coûteuse si la topologie, les politiques et les flux de travail opérationnels sont devenus dépendants du contrôleur.

La réponse est donc stratifiée et non absolue: l’entreprise autorise, le contrôleur coordonne, les réseaux sous-jacents des clouds et des opérateurs transportent, la plateforme de sécurité met en œuvre. L’histoire de Prosimo montre que la propriété de la couche de coordination peut changer sans qu’aucun compte cloud ni chemin physique ne change de propriétaire.

Répertoire central des sources

Pourquoi Prosimo reste pertinent même après l’acquisition

Prosimo a capté un changement d’infrastructure réel. L’objet de l’exploitation réseau se déplace du périphérique et du préfixe vers l’application, l’identité, la dépendance de service et le graphe de politiques. Les API cloud natives rendent l’état du réseau programmable, les périmètres logiciels distribués rendent le point d’application mobile. Un contrôleur ayant une vue sur plusieurs clouds peut coordonner des actions qu’aucune console cloud unique ne peut réaliser seule.

L’entreprise a aussi montré le coût de cette coordination. Une couche commune nécessite des identifiants privilégiés, une maintenance continue des API, une découverte précise, une traduction sémantique, de la télémétrie et une discipline opérationnelle. Elle peut réduire le travail fragmenté et créer un nouveau point de concentration. Le même système qui simplifie le routage peut aussi élargir le rayon d’impact d’une erreur de décision.

L’acquisition par Palo Alto Networks rend la question du contrôle plus visible. Réseau et sécurité convergent au niveau de l’insertion de services, de la découverte des charges de travail et du pilotage des politiques. Un fournisseur de sécurité qui connaît la topologie et peut modifier les routes ne fait pas qu’inspecter le trafic qu’on lui présente; il peut aussi déterminer quel trafic atteint l’inspection et où.

Prosimo ne doit donc être considéré ni comme une marque indépendante qui a échoué, ni comme la preuve qu’une plateforme unique a résolu le problème multi-cloud. Sa contribution durable a été de définir le graphe multi-cloud comme infrastructure. La question restante est de savoir si ce graphe, au sein d’une plus grande entreprise de sécurité, reste assez transparent, portable et pilotable pour mériter la confiance des clients.