Résumé

  • Fondée en 2019, Prosimo a levé au moins 55 millions de dollars lors d’un tour A en 2021 et d’un tour B en 2022; les revenus audités, la valorisation ou le prix d’acquisition n’ont pas été divulgués.
  • AXI combinait intention, topologie, analyses centralisées et périphériques distribués pour découvrir les actifs cloud, connecter les applications et intégrer les services de sécurité, sans posséder d’infrastructure physique.
  • L’intégration VM-Series annoncée en juin 2024 a précédé le passage de Prosimo chez Palo Alto Networks vers février 2025; aucune source ne précise la date d’acquisition, le prix ou la feuille de route actuelle des produits.
  • Le contrôle reste réparti entre les entreprises, les logiciels d’orchestration, les fournisseurs de cloud et Palo Alto Networks; la portabilité de la topologie, des données, des politiques et de l’autorité de routage devient donc le test critique pour les clients.

L’entreprise a disparu avant que le problème ne disparaisse

On ne peut pas présenter Prosimo comme un fournisseur indépendant actif en 2026. Les profils professionnels publics montrent que ses fondateurs et plusieurs employés ont rejoint Palo Alto Networks aux alentours de février 2025. L’identité de l’entreprise porte également la mention « acquise », et l’ancien directeur technique Nehal Bhau a écrit par la suite que sa technologie avait été intégrée aux produits Palo Alto Networks. Les preuves confirment le changement de contrôle et la valeur technique persistante, mais pas la date précise de signature ou de clôture, ni la forme juridique ou le prix de la transaction.

Cette correction doit être placée en préambule car elle change le temps de chaque affirmation relative au produit. AXI, Network Transit, App Transit, Application-driven Intelligent Results et Nebula étaient des capacités documentées de Prosimo durant sa période d’indépendance. Il ne faut pas les présenter comme des produits actuels vendus séparément, à moins que Palo Alto Networks ne publie une feuille de route contemporaine des produits et du support.

L’architecture historique peut subsister après l’acquisition sous forme de code intégré, de service partagé, de module logiciel ou d’actif d’ingénierie interne; ces résultats ne sont pas équivalents.

La disparition de la marque ne rend pas le problème sous-jacent obsolète. Les entreprises continuent de répartir leurs charges de travail entre Amazon Web Services, Microsoft Azure, Google Cloud, les centres de données privés, les sites de colocation, les plateformes SaaS et les utilisateurs distants. Chaque environnement a ses propres chemins, passerelles, terminaux, contrôles d’identité, services de sécurité, quotas et règles de facturation. L’entreprise peut posséder les comptes sans avoir une vue unifiée de la manière dont le trafic transite entre eux. L’importance de Prosimo réside dans sa tentative de posséder cette visibilité.

C’est pourquoi l’acquisition constitue l’épine dorsale de l’histoire, et non sa fin. Prosimo a créé une couche de contrôle cross-cloud capable de découvrir les actifs, d’interpréter le contexte applicatif et d’acheminer 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, avant de devenir propriétaire de la technologie. La frontière entre orchestration du routage et inspection approfondie s’est alors déplacée au sein d’une plateforme de cybersécurité unique.

Le routage multi-cloud est une lutte de contexte

Une table de routage peut indiquer si un préfixe donné est joignable via un prochain saut spécifique. Mais elle n’explique pas, à elle seule, quelle application l’utilisateur souhaitait atteindre, si le demandeur est digne de confiance, si un service d’inspection devrait voir le trafic, si un point de terminaison privé est disponible, si un chemin cloud coûte plus cher qu’un autre, ou si la transaction échoue après l’arrivée du paquet. Les opérations multi-cloud transforment ces questions en un problème de contrôle partagé.

La thèse de Prosimo était que l’autorité de routage devait reposer sur des informations allant au-delà de la joignabilité de couche 3. Son logiciel visait à rassembler l’inventaire cloud, l’état du réseau, l’identité de l’application, l’identité de l’utilisateur, les risques, les performances et la télémétrie des transactions. Ce contexte plus large permettait d’exprimer des politiques comme connecter une application spécifique, isoler un segment, choisir un point d’entrée ou acheminer du trafic sélectionné à travers un pare-feu.

La valeur ne venait pas de la création d’un nouveau chemin en fibre, mais de la décision sur la manière d’assembler les chemins et services existants.

Cette distinction explique l’utilisation par l’entreprise de l’expression « infrastructure d’expérience applicative ». Elle plaçait la demande applicative au-dessus du composant réseau individuel. Un VPC, un VNet, un sous-réseau, un hub de transit ou une liaison privée devenaient un composant d’un chemin de bout en bout, et non l’objet final de la gestion. L’approche a également projeté le produit sur plusieurs marchés simultanément: réseau cloud, fourniture d’applications, accès zero trust, assurance réseau, optimisation des coûts et intégration des services de sécurité.

Cette largeur a engendré à la fois une opportunité et une ambiguïté. Un produit touchant plusieurs équipes peut résoudre des échecs de coordination qu’aucune équipe isolée ne possède. Mais il devient aussi difficile à évaluer, car les équipes réseau, sécurité, cloud, applications et finances utilisent des définitions de succès différentes. Prosimo devait démontrer qu’un modèle cross-cloud unique améliorait les opérations sans devenir une couche de privilège supplémentaire dont les erreurs impacteraient tous les environnements.

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

Prosimo était une entreprise privée de logiciels de mise en réseau cloud, fondée en 2019 et basée dans la région de la baie de San Francisco. Ramesh Prabagaran était cofondateur et PDG, et Nehal Bhau cofondateur et directeur technique durant la période d’indépendance. Les registres publics mentionnent également Linus Aranha et Pradeep Aragonda dans des rôles fondateurs ou d’ingénierie de haut niveau, mais leurs titres exacts doivent être liés à des parcours professionnels datés.

La plateforme principale était Application eXperience Infrastructure (AXI). AXI utilisait une couche logicielle centralisée pour l’intention, la topologie, l’analyse et l’orchestration, avec des instances AXI Edge distribuées dans les régions cloud, les environnements de colocation ou l’infrastructure locale adjacente. L’entreprise a ensuite organisé son offre sous le nom de Full-Stack Cloud Transit, où Network Transit et App Transit traitaient différentes catégories de connectivité. AIR analysait la télémétrie et fournissait des informations opérationnelles, tandis que Nebula ajoutait une interface conversationnelle en 2024.

Prosimo n’était pas un fournisseur de transport cloud. Elle ne possédait pas de dorsale mondiale en fibre reliant toutes les régions. Le chemin pouvait emprunter les dorsales des fournisseurs de cloud, l’Internet public, des circuits dédiés, des liaisons de colocation ou des réseaux d’entreprise. Elle n’était pas non plus un fournisseur de pare-feu au même titre que Palo Alto Networks. Son rôle dans l’intégration de 2024 était la découverte, la segmentation et le routage, tandis que VM-Series assurait l’inspection de sécurité approfondie.

Après l’acquisition, la description la plus sûre est celle d’une « lignée technologique ». La déclaration post-intégration met en avant la découverte des actifs multi-cloud et l’accélération du déploiement de pare-feu logiciels pour l’inspection du trafic entrant, sortant et est-ouest. Cela prouve la survie de composants importants de Prosimo, et non la continuité intégrale du catalogue historique AXI, de son packaging commercial ou de son modèle de support client.

Le problème venu après le SD-WAN

L’équipe fondatrice était issue d’expériences dans les réseaux étendus, la fourniture d’applications et l’infrastructure cloud. Prosimo est également née d’un écosystème plus large de fondateurs et d’ingénieurs liés à Viptela, la société qui a contribué à établir le SD-WAN comme catégorie d’entreprise. Mais le problème suivant était différent. Le SD-WAN simplifie l’accès des succursales aux réseaux et aux applications, mais il ne crée pas un modèle opérationnel unique à l’intérieur et entre plusieurs clouds publics.

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 managé dans un autre, d’un fournisseur d’identité extérieur aux deux, d’une connectivité privée vers un centre de données et d’une inspection de sécurité à des frontières choisies. Chaque dépendance peut être représentée par un objet natif différent. L’équipe réseau voit les préfixes et les hubs de transit, l’équipe cloud voit les comptes et les objets de ressources, le propriétaire applicatif voit les domaines et les transactions, et l’équipe sécurité voit les zones et la politique d’inspection.

Prosimo est partie de la demande, pas de la succursale. La question était: comment un utilisateur ou une charge de travail doit-il accéder à une application avec un niveau acceptable de sécurité, de performance, de disponibilité et de coût? Ce cadrage a fait passer l’objet du routage du seul préfixe de destination à une transaction porteuse d’un contexte d’identité et d’application. Il a également obligé la plateforme à collecter et maintenir bien plus d’informations qu’un routeur traditionnel n’en a besoin.

Le timing était favorable. AWS, Azure et Google Cloud étendaient leurs services natifs de transit et de connectivité privée. Les entreprises pouvaient construire des réseaux sophistiqués chez chaque fournisseur, mais les API, les objets et les modèles de politique restaient spécifiques à chaque fournisseur. L’opportunité de Prosimo était d’orchestrer ces services, plutôt que de forcer chaque client à les remplacer par une dorsale privée distincte.

De la fondation 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 mené un tour de table de série A de 25 millions de dollars lors du lancement. L’investisseur décrivait l’opportunité sous l’angle de la fourniture d’expérience applicative à travers les clouds, en cohérence avec la tentative des fondateurs de définir une catégorie dépassant la connectivité traditionnelle des succursales.

Le lancement a placé l’entreprise sur un marché encombré et aux frontières instables. Les fournisseurs de cloud facilitaient la consommation de leurs propres services réseau. Les fournisseurs de SD-WAN et de SASE étendaient les politiques aux environnements cloud. Les sociétés de fourniture d’applications pouvaient optimiser les demandes, tandis que les sociétés de sécurité réseau pouvaient les inspecter. L’argument de Prosimo reposait sur le regroupement de ces fonctions dans une architecture cloud-native, sans prétendre remplacer tous les systèmes existants.

Le financement a donné à l’entreprise l’espace pour développer les intégrations, les périphériques logiciels, l’analytique, l’organisation commerciale et les relations avec les partenaires. Mais il ne prouvait pas l’adéquation produit-marché, l’ampleur des revenus ou une différenciation durable. Les preuves présentées n’incluent pas de revenus audités, de revenus récurrents annuels, de nombre de clients ou de valorisation. L’historique de financement montre l’engagement des investisseurs envers une thèse, et non une image complète de la performance opérationnelle.

En 2022, Prosimo a bouclé un tour de série B de 30 millions de dollars décrit comme sursouscrit. Le cumul de ces deux tours bien documentés donne un total de 55 millions de dollars minimum. Certaines bases de données agrègent un chiffre plus élevé en additionnant des annonces ou des enregistrements connexes; ces totaux ne doivent pas être utilisés sans rapprochement des événements sous-jacents.

AXI plaçait la politique au-dessus des clouds, et l’exécution près des charges de travail

L’architecture AXI divisait le travail entre une couche centralisée de contrôle et d’analyse, et des périphériques logiciels distribués. La couche centralisée conservait l’intention applicative et réseau, découvrait les actifs, construisait la topologie, reliait l’identité, analysait la télémétrie et orchestrait les changements. Les AXI Edges étaient déployés près des charges de travail ou des utilisateurs, appliquant la politique sans forcer chaque chemin à revenir vers un hub physique distant.

Cette séparation rappelle d’autres systèmes software-defined, mais les objets étaient cloud et orientés application. Le contrôleur avait besoin d’accéder aux comptes cloud et à leurs API, tandis que la périphérie devait se connecter aux services de transit natifs, aux réseaux de charge de travail, aux points privés ou aux chemins externes. L’autorité de la plateforme provenait de la réunion de deux visibilités: une intention globale au-dessus des clouds, et une exécution locale proche du trafic concerné.

L’architecture définissait également une limite pratique pour le déploiement. Chaque périphérique consommait des ressources cloud, nécessitait une conception de haute disponibilité, et devait être mis à jour, surveillé et sécurisé. La couche de contrôle avait besoin de privilèges suffisants pour découvrir les actifs et modifier l’état du réseau. L’entreprise obtenait un flux de travail commun, mais ajoutait un nouveau système de gestion dont la disponibilité et la santé impactaient l’accès en production.

Prosimo utilisait parfois l’expression « réseau cloud autonome ». Les preuves corroborent l’automatisation, les recommandations et l’orchestration basée sur API, mais pas un réseau fonctionnant indépendamment de la politique humaine, des services du fournisseur cloud ou du transport sous-jacent. Les opérateurs continuaient de définir l’intention, d’approuver l’accès, de traiter les exceptions et de porter la responsabilité du résultat.

AXI Edge était une décision de localisation, pas une appliance virtuelle générique

Un AXI Edge pouvait être déployé dans un VPC ou VNet cloud, un environnement de colocation ou une infrastructure adjacente. Une explication technique AWS montrait un VPC périphérique relié aux réseaux de charge de travail via Transit Gateway, avec la possibilité d’insérer un pare-feu et de donner accès aux utilisateurs distants ou aux sites locaux. La conception plaçait le point d’exécution Prosimo à l’intérieur de la topologie cloud, et non à une périphérie d’entreprise distante.

L’emplacement influençait plus que la latence. Il déterminait où le trafic entrait dans le domaine de la politique, quelle dorsale cloud ou quel chemin Internet il utilisait, où le chiffrement et l’inspection se produisaient, et quelles métriques la plateforme pouvait collecter. Un périphérique mal placé pouvait entraîner des contournements ou des coûts, tandis qu’un périphérique bien positionné raccourcissait le chemin ou maintenait le trafic proche de la charge de travail.

Le déploiement distribué augmentait le nombre de domaines de défaillance à gérer. La capacité, la version logicielle, la conception de la région cloud, la proximité des chemins et les autorisations d’accès pouvaient varier selon la région. La haute disponibilité exigeait plus que deux instances; le contrôleur, les tables de routage, les services de sécurité et les chemins de retour devaient s’accorder sur l’état de basculement.

Le périphérique faisait donc partie d’un système opérationnel plus vaste. Sa valeur dépendait de la cohérence de la découverte des actifs, de la topologie, des politiques et de l’analytique avec l’environnement cloud environnant. Le traiter comme une appliance virtuelle autonome revient à passer à côté de l’architecture que Prosimo tentait de vendre.

L’infrastructure sous-jacente a toujours appartenu à quelqu’un d’autre

Prosimo orchestrait le transport, mais ne possédait pas le chemin physique. Le chemin d’une application pouvait utiliser la dorsale d’AWS ou d’un autre cloud, une connexion Internet publique, Direct Connect ou ExpressRoute, un service de colocation, un circuit de transporteur, ou un réseau d’entreprise. La plateforme pouvait choisir et coordonner parmi les options disponibles, mais elle ne pouvait pas éliminer la latence, les pertes de paquets, les pannes ou les règles de tarification créées par ces acteurs.

Cette limite est importante pour évaluer les allégations de performance. Le contrôleur peut choisir un chemin mesuré plus performant ou rapprocher le point d’entrée de l’utilisateur. Mais il ne peut garantir qu’un transporteur 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, autant d’éléments hors du contrôle complet du contrôleur.

L’absence de dorsale propriétaire n’était pas seulement une faiblesse. Elle permettait à Prosimo d’utiliser l’infrastructure déjà achetée par les entreprises et de tirer parti des investissements des fournisseurs cloud. Elle pouvait accéder aux régions sans poser de fibre, et orchestrer des systèmes natifs comme AWS Cloud WAN. La contrepartie était la dépendance à la stabilité des API, aux quotas de service, aux conditions commerciales et à la sémantique de chaque fournisseur.

La promesse de la plateforme portait donc sur le contrôle opérationnel, pas sur la propriété physique. Elle tentait de faire fonctionner des couches hétérogènes comme un seul système géré, tout en conservant leurs avantages natifs. La question de savoir si cette abstraction réduisait la dépendance envers un fournisseur, ou ne faisait que la déplacer, dépendait de la portabilité de la politique, de la topologie et du déploiement des périphériques.

Network Transit gérait la joignabilité entre objets réseau

Network Transit se concentrait sur les VPC, VNets, sous-réseaux, régions, sites et segments. Il orchestrait les services de transit et les chemins cloud natifs pour que les équipes construisent la connectivité via un flux de travail commun, plutôt qu’en configurant chaque fournisseur séparément. Cela répondait au besoin réseau traditionnel: un préfixe ou un segment source doit atteindre une destination via un chemin autorisé.

Cela ne signifiait pas que les différences entre clouds avaient disparu. AWS, Azure et Google Cloud proposent des objets, des quotas et des comportements de routage différents. Les espaces d’adressage chevauchants, les chemins asymétriques, les points privés et les limites de service propres à chaque fournisseur nécessitaient toujours de l’ingénierie. Prosimo pouvait standardiser les opérations courantes et montrer les relations, mais les systèmes sous-jacents conservaient leurs contraintes.

Network Transit incluait aussi la segmentation. Des domaines de routage et des politiques pouvaient séparer les environnements ou restreindre l’accès. Le contrôleur devait comprendre où se trouvait un segment à travers les clouds et comment les objets natifs appliquaient la frontière. Une politique posée une fois pouvait se traduire en plusieurs modifications spécifiques au fournisseur.

Le bénéfice était une surface d’intention unifiée. Le risque était la traduction. Si la politique commune se désynchronisait de la configuration cloud, l’entreprise pouvait croire un segment protégé alors que l’état du fournisseur disait le contraire. La réconciliation, l’audit et la remontée explicite des échecs étaient donc aussi importants que le provisionnement initial.

App Transit faisait de l’application un objet de routage

App Transit étendait le modèle au-delà des sous-réseaux. Il pouvait utiliser le domaine applicatif, l’identité, le type de requête, la santé de la transaction, le risque et la performance pour décider comment un utilisateur ou une charge de travail atteignait un service. C’était la tentative la plus claire de Prosimo pour différencier sa plateforme d’un routeur cloud traditionnel.

La visibilité applicative était utile car les services modernes ne se résument pas toujours proprement à des adresses statiques. Les plateformes managées, les points de terminaison SaaS et les composants distribués peuvent changer, alors que l’identité de l’application reste significative. Une politique qui fait référence au service ou à l’utilisateur peut survivre plus longtemps qu’une règle basée uniquement sur des adresses et des ports.

Le modèle nécessitait une découverte précise. 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. Une cartographie périmée pouvait envoyer une requête par un mauvais chemin ou appliquer une règle de sécurité incorrecte. L’abstraction applicative ne supprimait pas le besoin de comprendre l’état du réseau; elle ajoutait une couche sémantique supplémentaire.

La réunion de Network Transit et d’App Transit reconnaissait l’existence de deux mondes dans les entreprises. Les systèmes legacy, les réseaux privés et les contrôles basés IP persistent, tandis que les applications plus récentes dépendent de domaines, d’identité et de services managés. Full-Stack Cloud Transit était le nom produit pour faire fonctionner les deux modèles ensemble, plutôt que de forcer l’un à remplacer l’autre.

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

L’accès orienté application nécessitait une intégration de l’identité. La plateforme pouvait utiliser le contexte de l’utilisateur ou de la charge de travail pour décider si une connexion devait être établie et comment. Cela permettait une politique de type zero trust, où la localisation seule ne prouvait pas l’autorisation.

L’identité améliorait la précision, mais ajoutait une dépendance de plus. La politique de chemin ou d’application devenait tributaire du fournisseur d’identité, de ses assertions, de l’état de session et des données de groupe. Un chemin pouvait échouer parce que l’authentification était indisponible ou qu’un attribut avait changé, même si les routeurs et les périphériques étaient sains. Le diagnostic devait franchir la frontière entre opérations réseau et identité.

Le contrôleur devenait aussi un point de concentration de contexte sensible. Il pouvait détenir la topologie, les relations applicatives, les attributs utilisateur, les signaux de risque et les résultats de politique. Cela facilitait le diagnostic et l’optimisation, mais amplifiait les conséquences d’un accès non autorisé. Le moindre privilège, la rétention, l’audit et la séparation des tâches étaient donc des exigences architecturales, et non des ajouts administratifs.

L’approche de Prosimo illustrait 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 la plateforme voyait de contexte, plus ses décisions devenaient utiles, et plus son autorité nécessitait une gouvernance fine.

La découverte des actifs créait le graphe dont dépendait chaque décision ultérieure

Un contrôleur cross-cloud ne peut pas gérer ce qu’il ne voit pas. Prosimo a développé une découverte des actifs cloud et des cartographies représentant les VPC, VNets, sous-réseaux, applications, connectivité et relations de sécurité. Ces vues alimentaient l’onboarding, la conception, le diagnostic et les politiques.

La découverte était stratégique car les environnements cloud changent en dehors des flux de travail du réseau central. Les équipes applicatives peuvent créer des comptes, des réseaux, des points de terminaison et des services managés via leur propre automatisation. Les inventaires manuels deviennent obsolètes. Un inventaire basé sur les API peut fournir une vue plus récente, mais son exhaustivité dépend de la couverture des comptes, des permissions, de la logique d’analyse et des API du fournisseur.

La cartographie n’était pas qu’une documentation. C’était la structure de données sur laquelle se calculaient les décisions de routage, de segmentation, d’insertion de services et d’optimisation. Si un actif ou une dépendance manquait, toutes les conclusions fondées sur cette base pouvaient être erronées. La topologie exigeait donc une provenance claire: quand avait-elle été collectée, quel compte l’avait fournie, quelles régions couvrait-elle, et certaines interrogations avaient-elles échoué.

Cette cartographie aide aussi à expliquer l’acquisition. Palo Alto Networks peut créer de la valeur sécurité lorsqu’elle sait où se trouvent les charges de travail et les flux de trafic. Un système qui découvre les actifs et modifie les chemins réduit la distance entre l’achat d’un pare-feu logiciel et son placement au bon endroit. La déclaration ultérieure de Bhau mettait spécifiquement l’accent sur la découverte des actifs et l’accélération du déploiement des pare-feu logiciels.

AIR transformait la télémétrie des périphériques en recommandations opérationnelles

Application-driven Intelligent Results (AIR) analysait la télémétrie collectée par les AXI Edges. Le guide AWS décrivait la visibilité sur le temps aller-retour, le temps de traitement, la latence applicative, le type de transaction, le risque et les résultats de politique. La plateforme pouvait corréler les observations utilisateur, réseau et application, au lieu d’afficher des compteurs de périphériques séparés.

Cette corrélation répondait à un problème opérationnel familier. Une transaction lente peut provenir du chemin utilisateur, du périphérique, de la dorsale cloud, d’un service de sécurité ou de l’application elle-même. Une visibilité inter-couches peut réduire le temps de diagnostic par rapport à des tableaux de bord séparés, et générer des recommandations concernant le chemin, l’emplacement, le risque et le coût.

La qualité de la recommandation dépendait de la couverture de télémétrie et du modèle utilisé pour l’interpréter. Le périphérique ne voyait que le trafic qui le traversait. Les dépendances applicatives externes et les états internes du fournisseur pouvaient rester invisibles. Une recommandation pouvait être directionnellement utile sans prouver la cause racine.

La télémétrie avait aussi une valeur de gouvernance. L’historique des observations pouvait aider l’entreprise à expliquer pourquoi un chemin ou une politique avait changé. Elle pouvait aussi révéler l’utilisation sensible d’une application et le comportement des utilisateurs. Le contenu public ne décrit pas entièrement la rétention ou la gouvernance des données après l’acquisition, et ces questions font donc partie de la due diligence des clients.

AWS a fourni la mise en œuvre documentée la plus claire

Le travail de Prosimo avec AWS a produit les preuves techniques publiques les plus solides. L’entreprise s’est intégrée à AWS Transit Gateway, Cloud WAN, PrivateLink, et au chemin de déploiement Marketplace for Containers Anywhere. AWS a publié une explication du positionnement de l’AXI Edge, de l’onboarding applicatif, de l’identité, de la sécurité et de l’optimisation.

AWS Cloud WAN était particulièrement important. Il fournissait une dorsale cloud native et un service de segmentation que Prosimo pouvait orchestrer plutôt que de remplacer. Cet arrangement illustrait le modèle de produit coopératif: AWS possédait le réseau natif et l’infrastructure mondiale, Prosimo apportait l’intention cross-cloud, le contexte applicatif, les périphériques logiciels et l’analyse.

Le chemin Marketplace simplifiait la première étape du déploiement en empaquetant AXI Edge dans un canal approuvé. Mais il ne supprimait pas le travail ultérieur sur les permissions de compte, la conception des chemins, la haute disponibilité, la capacité et les opérations. L’automatisation du jour zéro pouvait réduire la friction d’installation, sans régler le problème de contrôle à long terme.

Une référence nommée à Flexport a soutenu le cas d’usage AWS Cloud WAN dans le contenu de l’entreprise. C’est une preuve qu’un client entreprise était prêt à soutenir l’architecture, et non un audit indépendant de l’ampleur du déploiement, des économies ou de la disponibilité. Les témoignages clients doivent donc être utilisés comme exemples d’adoption, et non comme preuve de performance générale.

Azure et Google Cloud complétaient la revendication multi-cloud

Prosimo prenait également en charge les environnements Microsoft Azure et Google Cloud. Ses supports décrivaient l’orchestration autour d’Azure Virtual WAN, des réseaux Google Cloud et des objets de service privés. L’objectif était de fournir un modèle opérationnel unique tout en conservant le réseau natif de chaque fournisseur en place.

La présence du support ne prouve pas l’équivalence des capacités entre fournisseurs. Les API cloud mûrissent à des rythmes différents, et des noms de produits similaires peuvent cacher des sémantiques différentes. Un chemin, un segment, un point privé ou une insertion de service pouvait nécessiter un traitement spécifique au fournisseur. Les preuves présentées ne reconstituent pas une matrice d’équivalence fonction par fonction, région par région, version par version.

L’abstraction multi-cloud se comprend donc mieux comme un système de traduction. Elle peut unifier l’intention et le flux de travail partagé, mais doit préserver les détails ayant un impact sur la sécurité, le coût et la défaillance. La plateforme devient dangereuse lorsque l’interface paraît uniforme alors que les différences d’implémentation sont cachées aux opérateurs.

Le même principe s’applique après l’acquisition. Palo Alto Networks peut utiliser la cartographie partagée pour positionner la sécurité à travers les clouds, mais les fournisseurs cloud continuent de contrôler les objets natifs qui exécutent le chemin. La propriété de la couche d’orchestration n’entraîne pas la propriété de l’infrastructure cloud sous-jacente.

Le produit s’est étendu de la connectivité au cycle de vie

En 2023, Prosimo décrivait des flux de travail pour concevoir, construire, diagnostiquer et gérer les réseaux multi-cloud. Le produit dépassait la création d’un tunnel ou d’une passerelle. La découverte des actifs alimentait la conception, l’orchestration créait la connectivité, les cartographies et la télémétrie soutenaient le diagnostic, et les politiques et l’historique soutenaient la gestion continue.

Le cadre du cycle de vie élargissait l’acheteur commercial. L’ingénieur réseau pouvait utiliser la topologie et l’analyse de chemin; l’équipe plateforme cloud pouvait embarquer les comptes et les services; l’équipe sécurité pouvait auditer la segmentation et l’inspection; l’équipe migration pouvait planifier les changements; l’équipe FinOps pouvait examiner l’impact des chemins et du trafic sortant. La valeur de la plateforme augmentait quand plusieurs groupes utilisaient le même référentiel.

Un référentiel partagé pouvait aussi créer des tensions de gouvernance. Une plateforme centrale pouvait révéler que la configuration de l’équipe cloud différait de la politique d’entreprise. L’entreprise doit alors décider quel système fait autorité, et qui approuve la correction. Le logiciel seul ne peut résoudre cette question organisationnelle.

Le récit du cycle de vie renforçait aussi le coût de transition. Quand le contrôleur détient la cartographie des actifs, les politiques, les métriques, les emplacements de périphérie et les intégrations d’automatisation, le remplacer exige plus qu’un changement de circuit. Le client doit exporter ou reconstruire le modèle opérationnel. Prosimo vendait la réduction de la fragmentation du cloud, tout en créant une dépendance potentielle au contrôleur.

La segmentation s’étendait de l’accès réseau à la politique applicative

Prosimo offrait une segmentation de la couche 3 à la couche 7. Au niveau réseau, les domaines de routage et les segments déterminaient quels réseaux ou sites pouvaient se connecter. Aux couches supérieures, l’identité applicative, le contexte utilisateur et les caractéristiques de la transaction affinaient la règle.

Le modèle multicouche pouvait réduire l’écart entre une zone réseau et une politique applicative. Un service métier pouvait être autorisé alors que l’accès large entre réseaux restait bloqué. Inversement, un chemin joignable pouvait être refusé parce que l’identité ou le contexte applicatif ne passait pas.

Cela ne transformait pas Prosimo en pare-feu de nouvelle génération complet. L’intégration de 2024 séparait les responsabilités: Prosimo orchestrait les chemins, la segmentation et l’insertion de services; VM-Series réalisait l’inspection approfondie. Cette distinction est importante, car le pilotage de politique et l’application de la sécurité échouent de manières différentes.

Un segment n’est efficace que si tous les chemins pertinents sont représentés. Un chemin inconnu, une exception cloud native ou une insertion de service défaillante pouvait contourner le contrôle prévu. L’assurance exige donc de comparer la politique déclarée avec l’état du fournisseur et le trafic observé, et non de se fier uniquement à l’écran de configuration du contrôleur.

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

La conception de la sécurité cloud doit décider où l’inspection a lieu. Les pare-feu centralisés peuvent simplifier la politique et réduire le nombre d’appliances, mais ils peuvent créer des contournements, de la concentration et des pressions sur la capacité. Les pare-feu distribués restent plus proches des charges de travail et réduisent certaines distorsions de chemin, mais ils multiplient le déploiement, les licences, les mises à niveau et les opérations de politique.

Prosimo prenait en charge les deux modèles dans l’intégration VM-Series. La politique pouvait diriger le trafic sélectionné vers un point d’inspection centralisé, ou vers des pare-feu distribués à l’intérieur des VPC d’application. Le contrôleur mettait à jour les chemins environnants, tandis que Palo Alto Networks fournissait la fonction d’inspection.

L’architecture rendait l’orchestration des chemins commercialement précieuse pour un fournisseur de sécurité. Un pare-feu logiciel ne protège pas le trafic qui ne l’atteint pas. La découverte, le positionnement et la mise à jour des chemins réduisent la friction entre l’achat d’une capacité de sécurité et son insertion dans un chemin vivant. C’est une raison stratégique plausible pour l’absorption de la technologie Prosimo par Palo Alto Networks.

Cela augmentait aussi la portée de l’impact du contrôleur. Une politique erronée pouvait contourner l’inspection, créer une boucle, produire un routage asymétrique ou interrompre une application. Les contrôles de santé, le déploiement progressif, la simulation, l’audit et la restauration sont nécessaires, car une défaillance d’insertion de service est à la fois un incident réseau et un incident de sécurité.

Le partenariat de 2024 ne doit pas être antidaté à la date d’acquisition

Prosimo et Palo Alto Networks ont annoncé l’intégration VM-Series le 12 juin 2024. La déclaration décrivait une solution technique et commerciale conjointe, et non l’acquisition de Prosimo par Palo Alto Networks. Traiter cette annonce comme une preuve de propriété fusionnerait deux événements distincts.

Le partenariat a néanmoins créé un pont. Prosimo pouvait montrer comment son système de chemins et de politiques facilitait le déploiement de VM-Series à travers les clouds. Palo Alto Networks pouvait évaluer la technologie dans une intégration réelle avant le transfert institutionnel ultérieur. Les preuves publiques ne décrivent pas le processus d’acquisition, et affirmer que le partenariat a été conçu comme une étape formelle avant l’acquisition reste une spéculation.

Début 2025, les enregistrements des fondateurs et des employés ont changé. La page de l’entreprise a ensuite porté la mention d’acquisition. Fin 2025, Bhau a déclaré que la technologie était entièrement intégrée aux produits Palo Alto Networks. Combinés, ces enregistrements confirment l’issue d’une acquisition, mais laissent le mécanisme juridique non résolu.

Cette séquence importe pour la précision éditoriale et pour les clients. Un partenariat signifie deux fournisseurs, des structures de support et une limite d’intégration connue. Une acquisition peut transférer la feuille de route, les données, les contrats et l’autorité à une seule entreprise. Le changement modifie bien plus que le nom, même si le chemin technique paraît initialement similaire.

Nebula a transformé la cartographie topologique en interface conversationnelle

Prosimo a lancé Nebula en février 2024 dans le cadre de l’AI Suite pour les réseaux multi-cloud. L’assistant était conçu pour répondre en langage naturel aux questions sur les réseaux superposés, les coûts, la santé des chemins, les violations de politique de sécurité et d’autres états représentés dans la cartographie et la télémétrie de la plateforme.

L’élément utile n’était pas seulement l’interface en langage, mais le contexte structuré cross-cloud sous-jacent. Un modèle générique ne peut pas diagnostiquer un chemin privé ou un segment qu’il ne voit pas. Nebula pouvait s’appuyer sur l’inventaire des actifs, la topologie, les politiques et les observations que Prosimo collectait déjà. Cela rendait l’investissement antérieur dans une cartographie partagée pertinent pour les opérations AIOps.

L’accès conversationnel pouvait rendre des données complexes accessibles à un plus grand nombre d’opérateurs. Il pouvait aussi créer une fausse confiance si la réponse omettait un actif non pris en charge, comprenait mal la question, ou traitait une recommandation comme une action approuvée. Les changements à haut risque exigeaient toujours des garde-fous déterministes, des limites de privilèges et une revue humaine.

Prosimo a cité des bénéfices potentiels comme une réduction de 60 à 80 % du temps moyen de résolution, et de plus de 60 % du coût de réseau cloud. Il s’agissait de chiffres avancés par l’entreprise dans une annonce produit. Les preuves ne fournissent pas de méthodologie indépendante ni de référence client démontrant une applicabilité générale. On peut les citer comme un bénéfice proposé par Prosimo, non comme un fait de marché mesuré.

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

La même annonce de 2024 plaçait l’architecture de Prosimo dans le contexte des charges de travail d’intelligence artificielle. Les systèmes distribués peuvent nécessiter un accès privé aux données, une connectivité entre clouds et centres de données, des contrôles de conformité et un routage reflétant le comportement applicatif. Ces exigences étaient alignées avec le modèle existant d’actifs, de politiques et de chemins.

Le nom ne changeait pas l’infrastructure sous-jacente. Prosimo dépendait toujours des réseaux des fournisseurs cloud, des transporteurs et de l’infrastructure client, et ne fournissait pas de calcul GPU ni d’outils de développement de modèles. Son rôle potentiel était la couche de connectivité et de sécurité entourant les données et services distribués.

Le positionnement IA était stratégiquement logique car la valeur de la topologie cross-cloud augmente avec la distribution des données et des services. Mais c’était aussi une catégorie marketing introduite peu avant la fin de l’exploitation indépendante de l’entreprise. Les preuves ne montrent pas de revenus distincts pour un produit IA, de déploiements de production nommés, ou de résultats audités pour les charges de travail.

Le point durable est que la mesure du multi-cloud peut devenir un intrant pour des opérations assistées par la machine. La question actuelle est de savoir si Palo Alto Networks a conservé ce contexte, et comment elle expose la capacité. Les preuves publiques à la date d’arrêté ne fournissent pas de réponse complète.

Le modèle économique vendait du logiciel au-dessus d’une infrastructure qu’il ne possédait pas

L’activité indépendante de Prosimo reposait sur des abonnements logiciels et des services, pas sur un modèle de transporteur. Les clients déployaient les AXI Edges dans leurs environnements et connectaient les comptes cloud à la couche de contrôle. Les revenus provenaient probablement de licences ou d’abonnements, de support, de services professionnels et de canaux, mais les prix exacts et les métriques contractuelles n’ont pas été publiés dans les preuves fournies.

Le modèle pouvait évoluer sans posséder de fibre. Une plateforme logicielle unique orchestrait de nombreuses régions et plusieurs environnements clients. Mais on ne peut pas déduire l’économie globale de la seule architecture. Le support des API fournisseur, le cycle de vie des périphériques, les intégrations de sécurité et les déploiements d’entreprise pouvaient être coûteux, tandis que le client payait les ressources cloud consommées par les périphériques plutôt que le fournisseur.

Prosimo utilisait les places de marché cloud, les intégrateurs, les canaux de vente et les références clients pour atteindre les entreprises. Ces relations ne sont pas équivalentes. Une présence sur la place de marché prouve un chemin d’achat et de déploiement. Une intégration technique prouve que deux systèmes peuvent collaborer dans des conditions données. Un témoignage client fournit une référence. Aucun ne prouve isolément le nombre de clients payants ou les revenus récurrents.

L’étendue de l’entreprise a pu complexifier les ventes. Les équipes réseau, sécurité, cloud et application pouvaient toutes bénéficier, tandis que la propriété budgétaire restait floue. Le produit nécessitait un acheteur prêt à financer une couche de contrôle partagée, plutôt que de laisser chaque cloud et chaque équipe opérer séparément.

Partenaires, clients et investisseurs occupaient des positions différentes

Amazon Web Services était à la fois fournisseur d’infrastructure, partenaire d’intégration et canal de mise sur le marché. Azure et Google Cloud étaient des environnements pris en charge. Les fournisseurs d’identité apportaient le contexte d’authentification, les fournisseurs de pare-feu l’inspection, les fournisseurs de colocation et les transporteurs pouvaient héberger ou connecter les périphériques, et les partenaires de distribution pouvaient concevoir et exploiter les déploiements.

Flexport est apparu comme une référence client nommée dans le contenu AWS Cloud WAN. Cette référence prouve l’intérêt d’une entreprise pour l’architecture, mais ne révèle pas l’étendue complète, la durée ou la valeur commerciale du déploiement. Il ne faut pas en faire un substitut à la connaissance de l’ensemble de la base clients.

General Catalyst a mené le tour A et participé à la gouvernance en tant qu’investisseur. Des investisseurs liés à WRVI ou Celesta sont apparus dans les supports de l’entreprise, et des messages ultérieurs ont évoqué la participation de noms supplémentaires, dont un lié à BlackRock sans que l’entité d’investissement exacte soit résolue. Les enregistrements soutiennent l’existence d’une base de financement bien connectée, et non un tableau de propriété complet.

Palo Alto Networks occupait la relation la plus importante. Elle est passée de partenaire de sécurité en 2024 à acquéreur au début 2025. La séquence montre comment une dépendance au sein d’un écosystème peut devenir une relation de contrôle lorsqu’une partie achète la couche logicielle qui orchestre le chemin vers son produit.

Au moins 55 M$ levés, l’économie de sortie est inconnue

L’historique de financement documenté se compose de 25 M$ en tour A en avril 2021, et de 30 M$ en tour B en 2022. Le total atteint au moins 55 M$. Les preuves n’incluent pas de tableau de capitalisation audité, de valorisation, de structure de dette ou de tour ultérieur.

La contrepartie d’acquisition n’a été ni annoncée ni vérifiée indépendamment. Sans prix, on ne peut pas qualifier de manière responsable l’opération de prime stratégique, d’achat technique limité, d’acquisition d’équipe ou de vente sous pression. L’intégration continue indique que la technologie avait de la valeur, mais ne révèle pas le rendement pour les investisseurs ou les fondateurs.

Les revenus ou la capitalisation boursière de Palo Alto Networks ne doivent pas être attribués à Prosimo après l’acquisition. Dès lors que la startup a cessé d’apparaître comme une unité indépendante, il n’y a plus de revenus, de bénéfices ou de segment client séparés à analyser. Le propriétaire plus large peut déployer la technologie plus largement, tout en réduisant la lisibilité de son économie propre.

L’absence d’annonce officielle d’acquisition est en soi significative. Clients, employés et chercheurs utilisent généralement ces annonces pour repérer le timing, le support et la logique stratégique. Ici, la situation doit être reconstituée à partir des parcours professionnels, de la mention sur la page entreprise et d’une déclaration ultérieure du fondateur. Cela suffit à corriger le statut de l’entreprise, mais pas à inventer les détails de la transaction.

La concurrence venait des plateformes, des clouds et de l’ingénierie interne

Prosimo concurrençait les plateformes spécialisées dans le réseau multi-cloud comme Aviatrix et Alkira, les fournisseurs de réseau d’entreprise et de SASE, et les services natifs d’AWS, Azure et Google Cloud. Elle rivalisait aussi avec le modèle du « faites-le vous-même », où l’entreprise utilise l’infrastructure as code, les services de transit, les tables de routage et les pare-feu directement. Chaque alternative traitait une partie différente du même problème.

Un contrôleur spécialisé peut offrir une topologie et un modèle de politique uniques entre fournisseurs. Une conception native au sein d’un seul cloud réduit la dépendance à un tiers et peut s’aligner étroitement sur ce fournisseur. Un service adossé à un transporteur offre le transport physique. Une plateforme SASE ou de sécurité peut combiner connectivité et application. L’ingénierie interne garde le contrôle, au prix d’un effort de personnel et d’intégration.

La différenciation de Prosimo résidait dans la combinaison du transit applicatif et réseau, des périphériques distribués, de l’orchestration cloud native, de la topologie, de la mesure et de l’insertion de services. Cette largeur rendait la comparaison difficile. Les acheteurs devaient tester les services cloud, les chemins, les systèmes d’identité et le modèle de sécurité qu’ils utiliseraient, plutôt que de comparer des noms de catégories.

L’acquisition change le cadre concurrentiel. Prosimo n’a plus à gagner en tant qu’entreprise indépendante, mais sa technologie doit prouver sa valeur au sein de Palo Alto Networks. La comparaison pertinente devient: la découverte et l’orchestration des chemins intégrées améliorent-elles le déploiement des produits de sécurité Palo Alto, et les clients acceptent-ils de s’engager sur la plateforme résultante?

Les services cloud natifs constituaient à la fois un socle et une alternative

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN et les réseaux Google Cloud donnaient aux entreprises des options natives puissantes. Prosimo s’appuyait sur ces services, tout en concurrençant la possibilité pour les clients de les opérer directement.

La relation créait une frontière mouvante. Chaque fois qu’un fournisseur ajoutait du routage global, de la segmentation, de l’accès privé ou une politique centralisée, il devenait plus facile de reproduire certaines fonctions tierces en natif. En même temps, chaque nouveau service natif ajoutait un objet supplémentaire que le contrôleur cross-cloud pouvait découvrir et orchestrer. L’avancée du cloud pouvait réduire une partie de la valeur de Prosimo, tout en élargissant le besoin de traduction entre fournisseurs.

Le facteur décisif était autant organisationnel que technique. Une entreprise engagée sur un seul cloud avec une forte ingénierie interne peut préférer les outils natifs. Une entreprise multi-cloud avec des équipes fragmentées peut valoriser un plan de contrôle unique. Une organisation peut préférer une couche de référentiel tiers, tout en s’inquiétant des privilèges élevés et de la concentration des données.

Aucune architecture n’éliminait la dépendance. Les outils natifs augmentent la dépendance aux API et à la sémantique d’un fournisseur unique. Le contrôleur cross-cloud accroît la dépendance à sa cartographie, ses politiques et ses périphériques logiciels. La question utile est de savoir si cette dépendance est visible, portable et compatible avec le modèle opérationnel de l’entreprise.

La défaillance pouvait frapper le contrôleur, le périphérique, l’API cloud, l’identité ou le transport

L’architecture distribuée réduisait la dépendance à un hub de trafic unique, mais créait des domaines de défaillance interactifs. Le système central pouvait s’arrêter ou porter une intention obsolète. Un périphérique pouvait tomber en panne ou être isolé. Une API cloud pouvait refuser une partie du changement. Le fournisseur d’identité pouvait être indisponible. L’infrastructure sous-jacente pouvait perdre de la capacité ou emprunter un chemin inattendu. Un pare-feu inséré pouvait épuiser ses ressources.

La défaillance partielle est particulièrement difficile. Un fournisseur cloud peut accepter une mise à jour de route alors qu’un autre la refuse. L’état visé par le contrôleur diffère alors de l’état réel dans le cloud. Le trafic peut emprunter un chemin asymétrique ou contourner l’inspection. Un système fiable nécessite une réconciliation, des opérations répétables en toute sécurité, un déploiement progressif, un état d’erreur explicite et une restauration tenant compte du comportement de chaque fournisseur.

Les preuves publiques décrivent la disponibilité et l’optimisation à haut niveau, mais n’incluent pas d’étude indépendante d’injection de pannes, d’historique complet des incidents ou de résultat de service public. Les allégations de résilience doivent donc être liées à l’architecture documentée ou à une preuve client nommée.

L’acquisition ajoute un autre domaine de défaillance: la continuité du produit. Les clients ont besoin de savoir quel tableau de bord, quelle API, quelle image de périphérie, quel modèle de politique et quel point de support remplacent le système Prosimo historique. Une intégration de code techniquement réussie peut encore présenter un risque de migration si les frontières commerciales et opérationnelles ne sont pas claires.

Les identifiants cloud faisaient du contrôleur une partie du plan de gestion critique

La découverte des actifs et l’orchestration nécessitaient l’accès aux comptes cloud. Un inventaire en lecture seule pouvait utiliser des privilèges limités, mais la modification des chemins, des segments et l’insertion de services exigeaient une autorité plus forte. Le contrôleur siégeait donc dans le plan de gestion privilégié, sans posséder les charges de travail.

Une compromission des identifiants pouvait exposer la topologie, ou permettre des changements à grande échelle. Un bug logiciel ou une erreur d’opérateur pouvait déployer une politique à travers plusieurs clouds. Le risque augmentait avec l’utilité de la plateforme: plus elle gérait de comptes et de services, plus l’impact potentiel était large.

Les entreprises avaient besoin de rôles à moindre privilège, d’identifiants séparés pour la découverte et la modification, d’approbation multi-parties, d’audit complet, de rotation, de révocation d’urgence et d’un chemin de récupération ne dépendant pas du seul contrôleur. Les supports publics ne fournissent pas d’évaluation de sécurité indépendante complète, et ces mesures restent donc des contrôles de déploiement nécessaires, et non des garanties produit prouvées.

La cartographie de télémétrie était également sensible. Elle pouvait révéler les noms d’applications, la structure réseau, les politiques, les relations utilisateur, la santé des chemins et les schémas de coûts. La gouvernance post-acquisition devrait clarifier où ces données sont stockées, quels produits Palo Alto peuvent les utiliser, et comment les autorisations des anciens clients ont été transférées. Les preuves publiques à la date d’arrêté ne répondent pas à ces questions.

L’acquisition a transféré une couche neutre pour le cloud vers une plateforme de sécurité

La position indépendante de Prosimo lui permettait de se présenter comme une couche partagée entre clouds et services de sécurité. Une fois devenue la propriété de Palo Alto Networks, les incitations ont changé. La technologie acquise peut faciliter le déploiement de VM-Series et d’autres produits Palo Alto. Cela peut produire une meilleure intégration, tout en soulevant des questions sur le support des services d’inspection tiers.

La propriété ne prouve pas la disparition de la neutralité. Les preuves ne fournissent pas de matrice de partenaires actuelle ni d’architecture produit contemporaine. Mais cela change ce que le client doit demander: le contrôleur de chemins reste-t-il ouvert à plusieurs fournisseurs de sécurité, les politiques et métriques peuvent-elles être exportées, et l’optimisation favorise-t-elle 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 entrées dans un système de déploiement de sécurité. Mais cela ne prouve pas que l’App Transit historique, l’accès utilisateur, l’optimisation des coûts ou tous les flux de travail réseau cloud ont perduré en tant que capacité distincte.

C’est un schéma familier dans l’infrastructure. Une startup abstrait un problème d’orchestration difficile, puis une plateforme plus grande achète cette abstraction parce qu’elle augmente la consommation et le contrôle de son produit cœur. L’acquéreur obtient un chemin vers le déploiement. Le client peut gagner en intégration, et perdre une partie de son indépendance vis-à-vis du fournisseur.

La feuille de route actuelle des produits est le plus grand fait manquant

Le dossier public confirme l’acquisition et l’intégration, mais ne précise pas de feuille de route complète depuis AXI, Network Transit, App Transit, AIR et Nebula vers les produits ou unités de vente Palo Alto Networks actuels. Aucune date de fin de support historique, procédure de migration ou calendrier de continuité fonction par fonction n’est publié.

Cette lacune empêche une revue de produit au présent. Les descriptions historiques peuvent expliquer ce que Prosimo a construit et pourquoi c’était important, mais elles ne disent pas à l’acheteur quelles capacités sont disponibles, sous licence ou supportées aujourd’hui. Les conseils de déploiement contemporains doivent s’appuyer sur la documentation actuelle de Palo Alto Networks, et non sur les fiches archivées de Prosimo.

La feuille de route manquante limite aussi l’analyse stratégique. Absorber intégralement la cartographie et la couche d’orchestration diffère d’une utilisation sélective pour la découverte des actifs et le placement des pare-feu. Le premier crée un service de contrôle étendu, le second utilise Prosimo principalement pour accélérer le déploiement de la sécurité. La déclaration du fondateur soutient la persistance de la technologie, et laisse cette frontière architecturale non résolue.

Un document produit, un guide de migration ou une étude de cas client ultérieure pourrait lever une grande partie de l’incertitude. D’ici là, la formulation exacte est que la technologie Prosimo a été intégrée aux produits Palo Alto Networks selon un cofondateur, l’étendue et le packaging n’étant pas vérifiés.

Qui contrôle le routage multi-cloud?

Aucune partie ne contrôle l’intégralité du chemin. L’entreprise maîtrise la propriété des comptes, l’intention métier, la conception applicative et les identifiants qu’elle accorde. Un contrôleur cross-cloud peut découvrir la topologie, traduire la politique, choisir les chemins et modifier l’état de routage natif. Les fournisseurs de cloud contrôlent les API, les services de transit, les points privés, la dorsale et de nombreux domaines de défaillance. Les transporteurs et 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 utile. Elle ne possédait pas l’infrastructure, mais tentait de posséder la cartographie et la traduction des politiques par-dessus. Celui qui contrôle cette couche peut décider quels actifs sont visibles, comment les segments sont représentés, où les périphériques sont placés, quel service inspecte le trafic, et quelle métrique fait référence. C’est un pouvoir opérationnel sur le routage, même quand la fibre appartient à d’autres.

Après l’acquisition, Palo Alto Networks détient la technologie survivante et décide comment l’intégrer, la packager et la faire évoluer. Les fournisseurs cloud restent souverains dans leurs environnements, et l’entreprise peut révoquer les identifiants ou choisir une autre architecture. Mais la sortie peut être coûteuse si la topologie, les politiques et les flux de travail sont devenus dépendants du contrôleur.

La réponse est stratifiée, non binaire: l’entreprise délègue, le contrôleur orchestre, les couches cloud et de transport acheminent, la plateforme de sécurité applique. L’histoire de Prosimo importe parce qu’elle montre que la propriété de la couche d’orchestration peut changer sans que change la propriété du compte cloud ou du chemin physique.

Registre des sources clés

Pourquoi Prosimo reste important après l’acquisition

Prosimo a capté un changement réel de l’infrastructure. L’unité opérationnelle réseau passe du périphérique et du préfixe à l’application, l’identité et la dépendance de service, ainsi qu’à la cartographie des politiques. Les API cloud rendent l’état du réseau programmable, et les périphériques distribués rendent le point d’application mobile. Un contrôleur qui voit plusieurs clouds peut orchestrer des actions qu’un tableau de bord cloud unique ne peut accomplir seul.

L’entreprise a également révélé le coût de cette orchestration. La couche partagée nécessite des identifiants à privilèges élevé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é tout en créant un nouveau point de concentration. Le système lui-même peut simplifier le routage et élargir la portée d’une décision erronée.

L’acquisition par Palo Alto Networks rend la question du contrôle plus claire. Le réseau et la sécurité convergent autour de l’insertion de services, de la découverte des charges de travail et des politiques. Un fournisseur de sécurité qui connaît la topologie et modifie les chemins ne fait pas qu’inspecter le trafic qui lui est présenté; il peut contribuer à décider quel trafic atteint l’inspection, et où.

Prosimo ne doit donc pas rester dans les mémoires comme une marque indépendante qui a échoué, ni comme la preuve qu’une plateforme unique a résolu le multi-cloud. Sa contribution durable a été de définir la cartographie cross-cloud comme une infrastructure. La question restante est de savoir si cette cartographie, une fois entrée dans une grande entreprise de sécurité, reste suffisamment transparente, portable et gouvernée pour mériter la confiance des clients.