Résumé

  • Prosimo a été fondée en 2019 et a levé au moins 55 millions de dollars lors de ses tours de table série A en 2021 et série B en 2022; elle n’a publié ni revenus audités, ni valorisation, ni prix d’acquisition
  • AXI combinait intention, topologie et analyse centrales avec des nœuds distribués qui découvraient les actifs cloud, connectaient les applications et inséraient des services de sécurité sans posséder l’infrastructure physique
  • L’intégration avec VM-Series annoncée en juin 2024 a précédé le rattachement de Prosimo à Palo Alto Networks vers février 2025; la date exacte, le prix et le panorama actuel des produits n’ont pas été rendus publics
  • Le contrôle reste réparti entre les entreprises, le logiciel d’orchestration, les fournisseurs cloud et Palo Alto Networks; la portabilité de la topologie, des identifiants, des politiques et de l’autorité sur les routes constitue le test décisif pour les clients

La marque a disparu, mais le problème est resté

En 2026, il n’est plus exact de décrire Prosimo comme un fournisseur indépendant actif. Les historiques professionnels publics montrent ses fondateurs et plusieurs employés rejoignant Palo Alto Networks autour de février 2025. L’identité corporative de Prosimo apparaît comme acquise, 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 établissent un changement de contrôle et la continuité de la valeur technique. Elles n’établissent pas la date exacte de signature ou de clôture, la forme juridique ni le prix de la transaction.

Cette précision doit apparaître au début car elle modifie le temps verbal de toutes les affirmations sur les produits. AXI, Network Transit, App Transit, Application-driven Intelligent Results et Nebula étaient des capacités documentées durant la phase indépendante. Elles ne doivent pas être présentées comme des produits actuels vendus séparément tant que Palo Alto Networks ne publie pas une correspondance contemporaine produit et support. Après une acquisition, une architecture peut subsister comme code intégré, service partagé, module ou actif interne d’ingénierie; ces résultats ne sont pas équivalents.

La disparition de la marque n’a pas éliminé le problème sous-jacent. Les entreprises continuent de répartir les charges entre Amazon Web Services, Microsoft Azure, Google Cloud, les centres de données privés, les installations de colocation, les plateformes SaaS et les utilisateurs distants. Chaque environnement possède ses propres routes, passerelles, terminaisons privées, contrôles d’identité, services de sécurité, quotas et règles de facturation. Une entreprise peut être propriétaire de tous les comptes sans pour autant disposer d’une vision cohérente du parcours d’une requête.

L’importance de Prosimo réside dans sa tentative de rassembler cette vision en une couche de contrôle commune.

C’est pourquoi l’acquisition constitue l’axe narratif et non un simple épilogue. Prosimo a construit une couche de contrôle transversale capable de découvrir des actifs, d’interpréter le contexte applicatif et de diriger le trafic vers des services de sécurité. Palo Alto Networks est d’abord apparu comme partenaire technique dont les pare-feu VM-Series pouvaient être insérés dans ces routes; il est ensuite devenu propriétaire de la technologie. La frontière séparant l’orchestration du routage de l’inspection profonde s’est retrouvée au sein d’une plateforme unique de cybersécurité.

Dans le routage multicloud, c’est le contexte qui décide

Une table de routage peut indiquer si un préfixe est joignable via un prochain saut. Seule, elle n’explique pas quelle application l’utilisateur voulait atteindre, si l’utilisateur ou la charge est de confiance, si un service d’inspection doit voir le trafic, s’il existe une terminaison privée, si une route cloud coûte plus cher qu’une autre ou si la transaction échoue une fois le paquet arrivé. Les opérations multicloud 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 autre chose que la simple connectivité de couche 3. Son logiciel cherchait à combiner l’inventaire cloud, l’état du réseau, l’identité des applications, l’identité des utilisateurs, le risque, la performance et la télémétrie transactionnelle. Ce contexte permettait d’exprimer des politiques telles que connecter une application spécifique, isoler un segment, choisir un point d’entrée ou rediriger un trafic sélectionné vers un pare-feu.

La valeur ne provenait pas de l’invention d’une nouvelle route en fibre, mais de la capacité à assembler les routes et les services existants.

Cette différence explique l’expression « infrastructure d’expérience applicative ». La requête applicative se situait au-dessus de l’objet réseau individuel. Un VPC, un réseau virtuel, un sous-réseau, un hub de transit ou une liaison privée devenaient des composants du parcours de bout en bout, et non l’objet final de la gestion. La proposition plaçait également le produit sur plusieurs marchés simultanément: réseaux cloud, fourniture d’applications, accès zero trust, vérification opérationnelle du réseau, optimisation des coûts et insertion de services de sécurité.

Cette ampleur générait à la fois des opportunités et de l’ambiguïté. Un produit qui croise plusieurs équipes peut résoudre des défaillances de coordination qui ne relèvent pas d’un seul responsable. Il peut aussi être difficile à évaluer car les équipes réseau, sécurité, cloud, applications et finances utilisent des définitions différentes du succès. Prosimo devait démontrer qu’un modèle transversal améliorait l’exploitation sans devenir une autre couche privilégiée dont les erreurs affecteraient tous les environnements.

Ce qu’était Prosimo et ce qui est resté de sa technologie

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 était cofondateur et PDG; Nehal Bhau était cofondateur et directeur technique pendant la phase indépendante. Les historiques publics placent également Linus Aranha et Pradeep Aragonda dans des rôles fondateurs ou d’ingénierie senior, bien que leurs titres exacts doivent être liés à des biographies datées.

Sa plateforme principale était Application eXperience Infrastructure, habituellement abrégée AXI. AXI utilisait une couche logicielle centrale pour l’intention, la topologie, l’analyse et l’orchestration, ainsi que des nœuds AXI Edge distribués dans les régions cloud, les environnements de colocation ou l’infrastructure locale proche. Plus tard, l’offre a été organisée en Full-Stack Cloud Transit, avec Network Transit et App Transit pour différentes classes de connectivité. AIR analysait la télémétrie et produisait des informations opérationnelles; Nebula a ajouté une interface conversationnelle en 2024.

Prosimo n’était pas un opérateur cloud. Elle ne possédait pas de réseau mondial en fibre connectant toutes les régions. Les routes pouvaient emprunter les réseaux fédérateurs des fournisseurs, l’internet public, des circuits directs, des liaisons de colocation et des réseaux d’entreprise. Elle n’était pas non plus un fournisseur de pare-feu au même sens que Palo Alto Networks. Dans l’intégration de 2024, Prosimo découvrait, segmentait et dirigeait; VM-Series assurait l’inspection profonde.

Après l’acquisition, la description la plus prudente est « lignée technologique ». La déclaration d’intégration ultérieure met en avant la découverte d’actifs multicloud et un déploiement plus rapide des pare-feu logiciels pour le trafic entrant, sortant et est-ouest. C’est une preuve que des composants importants ont survécu. Cela ne démontre pas que l’ensemble du catalogue historique AXI, son packaging commercial ou son modèle de support aient été maintenus sans changement.

Le problème après le SD-WAN

L’équipe fondatrice possédait de l’expérience dans les réseaux à grande échelle, la fourniture d’applications et l’infrastructure cloud. Prosimo est également issue de l’écosystème plus large de fondateurs et d’ingénieurs associé à Viptela, société qui a contribué à établir le SD-WAN comme catégorie d’entreprise. Le problème suivant était différent. Le SD-WAN pouvait simplifier la relation entre une succursale et le réseau, mais il ne créait pas un modèle opérationnel unique à l’intérieur et à travers plusieurs clouds publics.

Une application multicloud 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é en dehors des deux, d’une connectivité privée vers un centre de données et d’une inspection de sécurité placée à des limites précises. Chaque dépendance peut être représentée par 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 ressources; le propriétaire de l’application voit des domaines et des transactions; la sécurité voit des zones et des politiques d’inspection.

Prosimo partait de la requête, pas de la succursale. La question était de savoir comment un utilisateur ou une charge devait atteindre une application avec une sécurité, une performance, une disponibilité et un coût acceptables. Cette approche élargissait l’objet du routage du préfixe de destination à une transaction dotée d’identité et de contexte applicatif. Elle obligeait également à collecter et maintenir bien plus d’informations qu’un routeur classique.

Le moment était favorable. AWS, Azure et Google Cloud développaient leurs propres systèmes de transit et de connectivité privée. Les entreprises pouvaient construire des réseaux sophistiqués au sein de chaque fournisseur, mais les API, les objets et les modèles de politique restaient spécifiques. L’opportunité de Prosimo consistait à coordonner ces services, et non à obliger chaque client à les remplacer par un réseau fédérateur propriétaire.

De la fondation en 2019 au lancement public de 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 série A de 25 millions de dollars lors du lancement. L’investisseur a décrit l’opportunité en termes de fourniture d’expérience applicative entre clouds, en phase avec la volonté de définir une catégorie plus large que la simple connectivité de succursale.

Le lancement a placé l’entreprise sur un marché encombré et encore instable. Les fournisseurs cloud facilitaient la consommation de leurs services réseau. Les vendeurs SD-WAN et SASE étendaient la politique vers le cloud. Les fournisseurs de fourniture d’applications pouvaient optimiser les requêtes et les entreprises de sécurité pouvaient les inspecter. Le positionnement de Prosimo dépendait de sa capacité à réunir ces fonctions dans une architecture orientée cloud sans prétendre remplacer tout ce qui l’entourait.

Le financement a permis de construire des intégrations, des nœuds de périphérie logiciels, de l’analyse, une organisation commerciale et des relations de partenariat. Il ne prouvait pas l’adéquation produit-marché, l’échelle des revenus ni une différenciation durable. Les preuves fournies ne contiennent pas de revenus audités, de revenu annuel récurrent, de nombre de clients ou de valorisation. Le registre de financement montre un soutien des investisseurs à une thèse, pas un rapport complet de performance opérationnelle.

En 2022, Prosimo a bouclé une série B de 30 millions de dollars décrite comme sursouscrite. L’addition des deux tours clairement identifiés donne un total vérifié d’au moins 55 millions. Certaines bases de données peuvent afficher un montant plus élevé si elles dupliquent des annonces ou des enregistrements liés; il ne faut pas les utiliser sans résoudre les événements sous-jacents.

AXI plaçait les politiques au-dessus des clouds et l’exécution près des charges

L’architecture AXI répartissait le travail entre une couche centrale de contrôle et d’analyse et des nœuds de périphérie distribués. La couche centrale maintenait l’intention réseau et applicative, découvrait les actifs, assemblait la topologie, intégrait l’identité, analysait la télémétrie et orchestrait les changements. Les nœuds AXI Edge étaient déployés près des charges de travail ou des utilisateurs pour appliquer la politique sans contraindre toutes les routes à passer par un hub physique distant.

La séparation ressemble à d’autres systèmes définis par logiciel, mais les objets étaient spécifiques au cloud et conscients de l’application. Le contrôleur avait besoin d’accéder aux comptes et aux API, tandis que le nœud de périphérie avait besoin de connectivité avec le transit natif, les réseaux de travail, les terminaisons privées ou les routes externes. L’autorité naissait de la combinaison des deux vues: une intention globale par-dessus les clouds et une exécution locale proche du trafic.

L’architecture créait aussi une limite opérationnelle. Chaque nœud de périphérie consommait des ressources cloud, nécessitait une haute disponibilité et devait être mis à jour, supervisé et sécurisé. La couche centrale exigeait des identifiants ayant suffisamment de privilèges pour découvrir les actifs et modifier l’état du réseau. L’entreprise gagnait un flux commun, mais ajoutait un système de gestion dont la disponibilité et la justesse affectaient la connectivité de production.

Prosimo a parfois employé le langage de réseau autonome dans le cloud. Les preuves étayent l’automatisation, les recommandations et l’orchestration par API. Elles ne décrivent pas un réseau fonctionnant sans politique humaine, services cloud ou transport sous-jacent. Les opérateurs continuaient à définir l’intention, approuver l’accès, résoudre les exceptions et répondre du résultat.

AXI Edge était une décision d’emplacement, pas un dispositif générique

Un AXI Edge pouvait être déployé dans un VPC ou un réseau virtuel, dans une installation de colocation ou dans une infrastructure adjacente. Le parcours technique AWS montrait un VPC de périphérie connecté au VPC de charge via Transit Gateway, avec un chaînage optionnel de pare-feu et un accès depuis les sièges ou les utilisateurs distants. Le point d’exécution se trouvait à l’intérieur de la topologie cloud, et non dans un périmètre d’entreprise éloigné.

L’emplacement déterminait plus que la latence. Il définissait où le trafic entrait dans le domaine de la politique, quel réseau fédérateur cloud ou route Internet il utilisait, où il était chiffré ou inspecté et quelle télémétrie était disponible. Un nœud de périphérie mal placé pouvait entraîner des détours ou des coûts; un nœud bien placé pouvait raccourcir la route ou maintenir le trafic près de la charge.

La distribution augmentait les domaines de défaillance. La capacité, les versions, la conception des zones, la convergence des routes et les permissions pouvaient varier d’une région à l’autre. La haute disponibilité exigeait plus que deux instances: le contrôleur, les tables de routage cloud, les services de sécurité et les routes de retour devaient s’accorder sur l’état de basculement.

Le nœud de périphérie faisait donc partie d’un système d’exploitation plus large. Sa valeur dépendait de la cohérence de la découverte, de la topologie, de la politique et de l’analyse avec l’environnement. Le traiter comme un dispositif virtuel autonome reviendrait à perdre l’architecture que Prosimo cherchait à vendre.

L’infrastructure sous-jacente restait aux mains de tiers

Prosimo coordonnait le transport mais ne possédait pas la route physique. Une connexion pouvait utiliser le réseau fédérateur d’AWS ou d’un autre fournisseur, l’internet public, Direct Connect ou ExpressRoute, un service de colocation, un circuit d’opérateur ou un réseau d’entreprise. La plateforme pouvait sélectionner et orchestrer les options disponibles; elle ne pouvait pas éliminer la latence, la perte de paquets, les domaines de défaillance ou les règles tarifaires créées par ces fournisseurs.

Cette limite importe lorsqu’on évalue les promesses de performance. Un contrôleur peut choisir une meilleure route observée 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 navigateur et les services externes hors de l’autorité totale du contrôleur.

Ne pas posséder de réseau fédérateur propre n’était pas qu’un inconvénient. Cela permettait d’utiliser l’infrastructure que les entreprises avaient déjà acquise et de tirer parti des investissements des fournisseurs cloud. Prosimo pouvait atteindre des régions sans construire de fibre et coordonner des systèmes natifs comme AWS Cloud WAN. En contrepartie, elle dépendait de la stabilité des API, des quotas, des conditions commerciales et de la sémantique de chaque fournisseur.

La proposition portait sur le contrôle opérationnel, pas sur la propriété physique. La plateforme cherchait à faire fonctionner des infrastructures hétérogènes comme un système unique, tout en conservant leurs avantages natifs. La question de savoir si cette abstraction réduisait le verrouillage ou le déplaçait dépendait de la portabilité des politiques, de la topologie et des nœuds de périphérie.

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

Network Transit se concentrait sur les VPC, les réseaux virtuels, les sous-réseaux, les régions, les sièges et les segments. Il coordonnait les services de transit natifs et les objets de routage afin que les équipes construisent la connectivité via un flux commun plutôt qu’en configurant chaque fournisseur séparément. Il répondait au besoin classique: une source ou un segment doit atteindre une destination par une route autorisée.

Il ne prétendait pas que les différences entre clouds avaient disparu. AWS, Azure et Google Cloud présentent des objets, des quotas et des comportements différents. Les chevauchements d’adresses, les routes asymétriques, les terminaisons privées et les limites de service nécessitaient toujours de l’ingénierie. Prosimo pouvait normaliser les opérations courantes et montrer les relations, mais les systèmes sous-jacents conservaient leurs contraintes.

Network Transit apportait également la segmentation. Les domaines de route et les politiques pouvaient séparer les environnements ou limiter la connectivité. Le contrôleur devait comprendre où un segment existait entre les clouds et comment il se matérialisait avec des objets natifs. Une politique exprimée une seule fois pouvait générer plusieurs modifications spécifiques à chaque fournisseur.

L’avantage était une surface d’intention unifiée. Le risque résidait dans la traduction. Si la politique commune et la configuration réelle divergeaient, l’entreprise pouvait croire qu’un segment était protégé alors que l’état du fournisseur indiquait le contraire. Le rapprochement, l’audit et les erreurs explicites étaient aussi importants que le provisionnement initial.

App Transit faisait de l’application un objet de routage

App Transit élargissait le modèle au-delà des sous-réseaux. Il pouvait utiliser le domaine de l’application, l’identité, le type de requête, l’état 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 se différencier d’un routeur cloud classique.

La vue applicative était utile car les services modernes n’ont pas toujours des adresses fixes. Les plateformes gérées, les terminaisons SaaS et les composants distribués peuvent changer tandis que l’identité du service reste significative. Une politique qui fait référence à l’application ou à l’utilisateur peut durer plus longtemps qu’une politique fondée uniquement sur des adresses et des ports.

Le modèle exigeait une découverte correcte. Le contrôleur devait savoir quels domaines et terminaisons appartenaient à une application, quelles dépendances étaient nécessaires et quelles assertions d’identité étaient fiables. Une carte obsolète pouvait diriger une requête par la mauvaise route ou appliquer une police incorrecte. L’abstraction applicative n’éliminait pas le besoin de connaître l’état du réseau; elle ajoutait une couche sémantique.

La combinaison de Network Transit et App Transit reconnaissait que les entreprises contiennent les deux mondes. Des systèmes hérités, des sous-réseaux privés et des contrôles IP persistent, tandis que de nouvelles applications dépendent de domaines, d’identité et de services gérés. Full-Stack Cloud Transit était le nom donné à l’exploitation conjointe de ces deux modèles sans forcer l’un à remplacer l’autre.

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

L’accès tenant compte de l’application nécessitait l’intégration de l’identité. La plateforme pouvait utiliser le contexte d’un utilisateur ou d’une charge pour décider si une connexion devait être établie et par quel chemin. Cela soutenait une approche zero trust dans laquelle l’emplacement seul ne suffisait pas comme preuve d’autorité.

L’identité améliorait la précision, mais ajoutait une dépendance. La politique en venait à dépendre du fournisseur d’identité, de ses attributs, de la session et des groupes. Une route pouvait échouer parce que l’authentification n’était pas disponible ou parce qu’un attribut avait changé, même si les routeurs et les nœuds de périphérie fonctionnaient. Le diagnostic devait franchir la frontière entre réseau et identité.

Le contrôleur devenait en outre un point de concentration de contexte sensible. Il pouvait rassembler la topologie, les relations applicatives, les attributs utilisateur, les signaux de risque et les résultats de politique. Cet ensemble améliorait le diagnostic et l’optimisation, tout en augmentant l’impact d’un accès non autorisé. Le moindre privilège, la rétention, l’audit et la séparation des fonctions étaient des exigences architecturales.

L’approche de Prosimo illustre une tendance large: le routage et l’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 rigoureuse doit être la gouvernance de son autorité.

La découverte d’actifs construisait le graphe dont dépendait chaque décision

Un contrôleur transversal ne peut pas gouverner ce qu’il ne voit pas. Prosimo a développé des fonctions de découverte d’actifs et de cartographie des VPC, réseaux virtuels, sous-réseaux, applications, connectivité et relations de sécurité. Ces vues appuyaient l’intégration d’environnements, la conception, la résolution de problèmes et l’application de politiques.

La découverte était stratégique car les environnements changent en dehors des flux réseau centraux. Les équipes applicatives peuvent créer des comptes, des réseaux, des terminaisons et des services avec leur propre automatisation. Un diagramme manuel devient obsolète. Un inventaire par API peut être plus récent, bien que son exhaustivité dépende de la couverture des comptes, des permissions, de la logique des analyseurs et des API.

Le graphe n’était pas seulement une documentation. C’était la structure à partir de laquelle les routes, la segmentation, l’insertion de services et l’optimisation étaient calculées. Si un actif ou une dépendance manquait, les conclusions construites sur ce modèle pouvaient être erronées. La topologie exigeait une traçabilité: date de collecte, compte d’origine, régions couvertes et tout échec de collecte.

Le graphe aide à expliquer l’acquisition. Palo Alto Networks tire de la valeur lorsqu’il sait où se trouvent les charges et les routes. Un système qui découvre les actifs et modifie les routes réduit la distance entre l’achat d’un pare-feu logiciel et son placement correct. La déclaration ultérieure de Bhau a précisément souligné la découverte d’actifs et le déploiement accéléré de pare-feu.

AIR transformait la télémétrie des nœuds AXI Edge en recommandations

Application-driven Intelligent Results, ou AIR, analysait la télémétrie collectée par les nœuds AXI Edge. Le parcours AWS décrivait une visibilité sur le temps aller-retour, le traitement, la réponse applicative, le type de transaction, le risque et les résultats de politique. La plateforme pouvait corréler utilisateur, réseau et application au lieu de montrer des compteurs isolés.

Cette corrélation traitait un problème courant. Une transaction lente peut provenir du chemin de l’utilisateur, du nœud de périphérie, du réseau fédérateur cloud, d’un service de sécurité ou de l’application. Une vue transversale peut réduire la recherche plus vite que plusieurs consoles. Elle peut aussi étayer des recommandations de route, d’emplacement, de risque ou de coût.

La qualité dépendait de la couverture de télémétrie et du modèle utilisé pour l’interpréter. Un nœud de périphérie observait uniquement le trafic qui le traversait, tandis que les dépendances externes et certaines conditions internes du fournisseur pouvaient rester en dehors. Une recommandation pouvait donc être utile pour orienter l’enquête sans démontrer seule la cause racine.

La télémétrie avait aussi une valeur de gouvernance. Les enregistrements historiques pouvaient expliquer pourquoi une politique avait changé, mais ils pouvaient aussi exposer l’usage des applications et le comportement des utilisateurs. Les documents publics ne fournissent pas d’explication complète sur la rétention et la gouvernance des données après l’acquisition, de sorte que ces questions continuent de relever de la diligence due du client.

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

Le travail avec AWS a produit les preuves techniques publiques les plus solides. Prosimo s’est intégré à Transit Gateway, Cloud WAN, PrivateLink et Marketplace for Containers Anywhere. AWS a publié un parcours sur l’emplacement d’AXI Edge, l’intégration d’applications, l’identité, la sécurité et l’optimisation.

AWS Cloud WAN était particulièrement important. Il fournissait un réseau fédérateur natif et une segmentation que Prosimo pouvait orchestrer sans remplacer. L’accord illustrait le modèle coopératif: AWS possédait le réseau et l’infrastructure mondiale; Prosimo apportait l’intention multicloud, le contexte applicatif, les nœuds de périphérie et l’analyse.

Marketplace facilitait le déploiement initial via un canal approuvé, mais n’éliminait pas le travail ultérieur sur les permissions, la conception des routes, la haute disponibilité, la capacité et l’exploitation. L’automatisation de la phase initiale réduisait la friction sans résoudre le problème de contrôle à long terme.

Une référence de Flexport soutenait le cas d’usage dans le matériel d’entreprise. Elle montrait qu’un client d’entreprise acceptait de soutenir l’architecture, mais ne constituait pas un audit indépendant sur l’échelle, les économies ou la disponibilité. Les références de clients doivent être traitées comme des exemples d’adoption, pas comme une preuve universelle de performance.

Azure et Google Cloud complétaient la promesse multicloud

Prosimo prenait également en charge Microsoft Azure et Google Cloud. Ses documents décrivaient l’orchestration autour d’Azure Virtual WAN et des objets de réseau et de service privé de Google Cloud. L’objectif était un modèle unique tout en conservant les réseaux natifs.

L’existence d’un support ne démontre pas la parité. Les API évoluent à des rythmes différents et des noms similaires cachent des sémantiques distinctes. Une route, un segment, une terminaison privée ou une insertion peut exiger un traitement spécifique. Les preuves ne permettent pas de reconstituer une matrice complète par région et par version.

L’abstraction doit être comprise comme un système de traduction. Elle peut normaliser l’intention et le flux de travail, mais doit conserver les détails qui affectent la sécurité, le coût et les modes de défaillance. Une interface uniforme devient dangereuse lorsqu’elle masque des différences d’implémentation pertinentes.

Il en va de même après l’acquisition. Palo Alto Networks peut utiliser le graphe commun pour placer la sécurité, mais les fournisseurs continuent de contrôler les objets natifs. Être propriétaire de l’orchestration ne signifie pas être propriétaire de l’infrastructure 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 concevoir, construire, diagnostiquer et gérer les réseaux multicloud. La plateforme n’était plus présentée comme un simple tunnel ou une passerelle: la découverte soutenait la conception, l’orchestration créait la connectivité, les cartes et la télémétrie aidaient au diagnostic, et les politiques et l’historique soutenaient la gestion continue.

Ce cadrage élargissait le nombre d’acheteurs potentiels. L’équipe réseau pouvait utiliser la topologie et l’analyse; l’équipe cloud, intégrer des comptes et des services; la sécurité, examiner la segmentation; la migration, planifier les changements; et FinOps, étudier les coûts de sortie de données et les routes. La valeur de la plateforme augmentait lorsque plusieurs groupes travaillaient sur les mêmes preuves.

La preuve partagée peut aussi générer des conflits de gouvernance. Une plateforme centrale peut révéler que la configuration native diffère de la politique d’entreprise, mais l’organisation doit décider quel système fait autorité et qui peut approuver la correction. Le logiciel peut exposer la divergence; il ne peut pas résoudre seul cette question institutionnelle.

L’approche cycle de vie augmentait également les coûts de changement. Quand un contrôleur conserve le graphe, les politiques, la télémétrie, les nœuds de périphérie et les intégrations, le remplacer exige de reconstruire une grande partie du modèle opérationnel. Prosimo vendait une réduction de la fragmentation entre clouds, mais pouvait créer une nouvelle dépendance envers le contrôleur.

La segmentation allait de la connectivité réseau à la politique applicative

Prosimo présentait une segmentation allant de la couche 3 à la couche 7. Au niveau réseau, les domaines et les segments contrôlaient la connectivité; aux couches supérieures, l’identité de l’application, de l’utilisateur et les propriétés de la transaction pouvaient préciser la règle.

Ce modèle pouvait réduire la distance entre la zone réseau et la politique applicative. Un service pouvait être autorisé tandis que la connectivité générale entre sous-réseaux restait bloquée. Inversement, une route joignable pouvait être refusée en raison de l’identité ou du contexte.

Prosimo ne devenait pas pour autant un pare-feu complet. L’intégration séparait les responsabilités: Prosimo orchestrait les routes, la segmentation et l’insertion de services, tandis que VM-Series effectuait l’inspection profonde. La distinction importe parce que la direction du trafic et l’application des contrôles peuvent échouer de différentes manières.

Un segment n’est efficace que si toutes les routes pertinentes sont représentées. Une route inconnue, une exception native ou une insertion échouée peut le contourner. La vérification opérationnelle exige de comparer la politique déclarée, l’état du fournisseur et le trafic observé.

L’insertion de services liait les routes à l’économie du pare-feu

La conception de la sécurité dans le cloud doit décider où l’inspection est réalisée. Les pare-feu centralisés peuvent simplifier les politiques et réduire le nombre d’instances, mais créent aussi du trafic de retour, de la concentration et une pression sur la mise à l’échelle. Les pare-feu distribués restent plus proches des charges de travail, mais multiplient le déploiement, les licences, les mises à jour et les opérations.

Prosimo permettait les deux modèles avec VM-Series. La politique pouvait diriger le trafic vers un point central ou vers des pare-feu distribués dans les VPC d’application. Le contrôleur mettait à jour les routes et Palo Alto fournissait l’inspection.

Cela rendait l’orchestration précieuse pour un fournisseur de sécurité. Un pare-feu ne peut pas protéger le trafic qui ne l’atteint jamais; c’est pourquoi la découverte, le placement et la mise à jour des routes réduisent la friction entre l’achat de capacité de sécurité et son insertion sur une route de production. C’est une raison stratégique plausible pour l’acquisition.

Cela élargissait aussi le rayon d’impact des erreurs. Une politique erronée pouvait contourner l’inspection, créer des boucles, provoquer des routes asymétriques ou mettre une application hors service. C’est pourquoi des vérifications préalables, des déploiements progressifs, la simulation, l’audit et des mécanismes de retour en arrière étaient nécessaires, car la défaillance touchait simultanément le réseau et la sécurité.

Le partenariat de 2024 ne doit pas être réinterprété comme une acquisition a posteriori

Prosimo et Palo Alto Networks ont annoncé l’intégration le 12 juin 2024. Le communiqué décrivait une solution conjointe et n’affirmait pas que Palo Alto Networks avait acquis Prosimo. L’utiliser comme preuve de propriété confondrait deux événements distincts.

Le partenariat a créé un pont. Prosimo pouvait démontrer que sa couche de contrôle facilitait le déploiement de VM-Series, tandis que Palo Alto Networks évaluait la technologie dans une intégration réelle avant la transition corporate. Les sources ne décrivent pas le processus d’achat, aussi affirmer que le partenariat a été une phase formelle précédant l’acquisition serait spéculatif.

Début 2025, les historiques professionnels des fondateurs et des employés ont changé, et la page corporate est apparue par la suite marquée comme acquise. À la fin de la même année, Bhau a déclaré que la technologie était pleinement intégrée dans les produits de Palo Alto Networks. Ensemble, ces signaux étayent la conclusion qu’il y a eu une acquisition, tout en laissant non résolus ses mécanismes juridiques.

La séquence importe pour les clients. Un partenariat implique 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é à une seule entreprise. Le changement va au-delà de la marque, même si le parcours technique semble d’abord similaire.

Nebula a rendu le graphe topologique accessible via une interface conversationnelle

Prosimo a présenté Nebula en février 2024 au sein d’une AI Suite. L’assistant devait répondre en langage naturel à des questions sur les chevauchements, les coûts, la santé des routes, les violations de sécurité et d’autres conditions représentées dans le graphe et la télémétrie.

L’actif important n’était pas seulement l’interface, mais le contexte structuré. Un modèle général ne diagnostique pas une route privée qu’il ne voit pas. Nebula s’appuyait sur l’inventaire, la topologie, la politique et les observations déjà collectées. L’investissement préalable dans un graphe commun devenait la base de l’AIOps.

L’accès conversationnel pouvait ouvrir des données complexes à davantage d’opérateurs. Il pouvait aussi créer une fausse confiance s’il omettait des actifs, comprenait mal la requête ou traitait une recommandation comme une action autorisée. Les changements à haut risque exigeaient toujours des contrôles déterministes, des permissions et une révision humaine.

Prosimo a revendiqué des réductions potentielles de 60 à 80 % du MTTR et de plus de 60 % du coût des réseaux cloud. Il s’agissait de chiffres du fournisseur dans un document produit. Il n’existe pas de méthodologie indépendante ni de base de clients démontrant une application générale. On peut les citer comme des bénéfices proposés, non comme des faits mesurés.

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

La même note a présenté l’architecture pour l’IA. Les systèmes distribués peuvent nécessiter un accès privé aux données, des liaisons entre clouds et centres, de la conformité et des routes tenant compte de l’application. Ces exigences s’inscrivaient dans le modèle existant d’actifs, de politique et de routes.

L’étiquette ne changeait pas l’infrastructure sous-jacente. Prosimo continuait de dépendre des réseaux cloud, des opérateurs et de l’infrastructure client. Elle ne fournissait pas non plus de GPU ni d’outils de développement de modèles. Son rôle possible était la connectivité et la sécurité autour de données et de services distribués.

La position était stratégiquement logique car la valeur de la topologie augmente avec la distribution. C’était aussi une catégorie marketing introduite peu avant la fin de la phase indépendante. Les preuves n’établissent pas de revenus liés à l’IA, de déploiements nommés ou de résultats audités.

La conclusion durable est que la télémétrie multicloud peut alimenter des opérations assistées par des systèmes automatisés. La question aujourd’hui est de savoir si Palo Alto a conservé ce contexte et comment il l’expose. Les sources n’offrent pas de réponse complète.

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

Prosimo était une offre de logiciel par abonnement et services, pas un opérateur. Les clients déployaient des nœuds AXI Edge et connectaient leurs comptes à la couche centrale. Les revenus auraient dépendu des licences, du support, des services professionnels et du canal, bien que les prix et les indicateurs n’aient pas été publiés dans les preuves.

Elle pouvait monter en échelle sans fibre propre. Une plateforme pouvait coordonner de nombreuses régions. Cependant, l’architecture ne permet pas d’inférer les marges. Maintenir les API, les nœuds de périphérie, les intégrations et le déploiement en entreprise peut être coûteux; les ressources cloud consommées par chaque nœud de périphérie peuvent être payées par les clients.

Prosimo a utilisé des marketplaces, des intégrateurs, des canaux et des références de clients pour atteindre le marché des entreprises. Ces relations ne sont pas équivalentes: une présence sur une marketplace démontre un canal d’achat et de déploiement; une intégration technique démontre la compatibilité sous certaines conditions; un témoignage apporte une référence commerciale. Aucun de ces éléments ne révèle à lui seul le nombre de clients payants ni les revenus récurrents.

L’ampleur pouvait compliquer la vente. Les équipes réseau, sécurité, cloud et applications en tiraient profit, mais le budget pouvait ne pas avoir de propriétaire identifié. Le produit avait besoin d’un acheteur prêt à financer une couche de contrôle commune.

Partenaires, clients et investisseurs occupaient des positions différentes

AWS était à la fois un fournisseur d’infrastructure et un partenaire d’intégration, tandis qu’Azure et Google Cloud figuraient comme environnements compatibles. Les fournisseurs d’identité apportaient le contexte d’authentification; les pare-feu, la capacité d’inspection; et les services de colocation et les opérateurs pouvaient héberger ou connecter les nœuds de périphérie. Les partenaires de canal pouvaient concevoir, déployer et gérer les solutions.

Flexport apparaissait comme référence dans le matériel AWS Cloud WAN. Cela montre un intérêt d’entreprise, mais ne révèle pas l’étendue, la durée ni la valeur. Ne doit pas être transformé en substitut du nombre de clients.

General Catalyst a mené la série A et a participé en tant qu’investisseur. Les documents citaient aussi WRVI ou Celesta et, plus tard, une participation liée à BlackRock dont le véhicule exact n’a pas été résolu. Cela démontre une base de financement bien connectée, pas un tableau de capitalisation complet.

Palo Alto Networks a été la relation décisive: partenaire en 2024, acheteur en 2025. La séquence montre comment une dépendance d’écosystème se transforme en contrôle lorsqu’un entité achète la couche qui coordonne la route vers son produit.

Au moins 55 millions ont été vérifiés; les conditions économiques de la sortie restent inconnues

Le registre vérifié inclut une série A de 25 millions de dollars en avril 2021 et une série B de 30 millions en 2022. Il n’y a pas de tableau de capitalisation audité ni de données publiques sur la valorisation, la dette ou les tours suivants.

Le prix de l’acquisition n’a pas été divulgué ni vérifié de façon indépendante. Sans ce chiffre, il n’est pas possible de classer de manière responsable l’opération comme un achat à prime stratégique, une acquisition technologique modeste, un acqui-hire ou une vente sous contrainte. La continuité de l’intégration prouve la valeur technologique, mais ne révèle pas le retour obtenu par les investisseurs ou les fondateurs.

L’échelle financière de Palo Alto Networks ne doit pas être attribuée à Prosimo. Celle-ci n’étant plus observable, il n’existe pas de segment autonome de revenu, de bénéfice ou de clients. Un propriétaire plus grand peut étendre la portée et rendre les chiffres individuels moins visibles.

L’absence d’annonce formelle d’acquisition est également pertinente. Ce type de document précise habituellement le calendrier, le support et la logique stratégique; dans ce cas, l’état doit être reconstruit à partir des historiques professionnels, de l’étiquette de la page corporate et d’une déclaration ultérieure du cofondateur. Ces preuves suffisent pour corriger la condition corporative, mais pas pour inventer les conditions de la transaction.

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

Prosimo était en concurrence avec des plateformes spécialisées comme Aviatrix et Alkira, avec les fournisseurs de réseau d’entreprise et de SASE, avec les services natifs d’AWS, d’Azure et de Google Cloud, et avec les approches internes reposant sur l’infrastructure en tant que code, les services de transit, 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 une topologie et des politiques communes entre fournisseurs. Une solution native réduisait la dépendance externe à l’intérieur d’un seul cloud; un opérateur apportait le transport physique; une plateforme de sécurité combinait connectivité et inspection; et le développement interne préservait le contrôle en échange de plus de personnel et d’intégration.

La différenciation de Prosimo résidait dans la combinaison du transit réseau et applicatif, des nœuds de périphérie, de l’orchestration native, du graphe, de la télémétrie et de l’insertion de services. Cette ampleur rendait les comparaisons difficiles. Les acheteurs devaient tester des services, des routes, des identités et de la sécurité concrets.

L’acquisition modifie le cadre concurrentiel. Prosimo ne rivalise plus en tant qu’entreprise indépendante; sa technologie doit justifier sa place au sein de Palo Alto Networks. La question devient combien elle améliore le déploiement de sécurité et quelle dépendance supplémentaire les clients sont prêts à accepter.

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

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN et Google Cloud offraient des options puissantes. Prosimo en dépendait et rivalisait avec l’exploitation directe par le client.

La frontière était mouvante. De nouvelles fonctionnalités natives pouvaient reproduire des parties de la proposition de Prosimo, tout en ajoutant davantage d’objets qu’un contrôleur transversal devait coordonner. L’évolution des services cloud pouvait réduire la valeur de certaines fonctions et augmenter le besoin de traduction entre fournisseurs.

La décision était organisationnelle en plus d’être technique. Une entreprise mono-cloud disposant d’une forte ingénierie pouvait préférer le natif. Une entreprise multicloud fragmentée pouvait valoriser un plan commun. Une organisation régulée pouvait apprécier une preuve indépendante et craindre la concentration des identifiants.

Aucune approche n’éliminait la dépendance technologique. Les outils natifs liaient le client aux API et à la sémantique spécifiques d’un fournisseur; le contrôleur transversal le liait à son graphe, ses politiques et ses nœuds de périphérie. 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 venir du contrôleur, des nœuds de périphérie, des API cloud, du système d’identité ou de l’infrastructure sous-jacente

L’architecture distribuée réduisait la dépendance à un concentrateur unique, mais créait plusieurs domaines de défaillance. Le service central pouvait devenir obsolète; un nœud de périphérie, isolé; une API, rejeter une partie du changement; le système d’identité, cesser de répondre; l’infrastructure sous-jacente, se dégrader; ou un pare-feu, épuiser ses ressources.

Les défaillances partielles sont particulièrement difficiles à gérer. Un fournisseur peut accepter une mise à jour alors qu’un autre la rejette, de sorte que l’état désiré se sépare de l’état réel, et que des routes asymétriques ou des chemins contournant l’inspection puissent apparaître. Le système a besoin de réconciliation, d’opérations idempotentes, de déploiements progressifs, d’états d’erreur explicites et de mécanismes de retour arrière adaptés à chaque fournisseur.

Les preuves publiques ne contiennent pas de tests indépendants d’injection de défaillances, de registre complet d’incidents ni de résultats universels de niveau de service. Toute affirmation sur la résilience doit donc être liée à l’architecture documentée ou à des preuves concrètes provenant de clients.

L’acquisition ajoute un autre risque: la continuité du produit. Les clients doivent savoir quelle console, quelle API, quelle image de nœud, quel modèle de politique et quelle organisation de support remplacent le système historique. Une intégration technique réussie peut néanmoins produire une migration médiocre si les frontières commerciales et opérationnelles restent opaques.

Les identifiants cloud transformaient le contrôleur en infrastructure critique

La découverte et l’orchestration exigeaient l’accès aux comptes cloud. L’inventaire pouvait utiliser des permissions en lecture seule, tandis que les modifications de routes, de segments et d’insertion de services requéraient une autorité plus élevée. Le contrôleur faisait partie du plan de gestion privilégié même s’il n’était pas propriétaire des charges de travail.

Un identifiant compromis pouvait exposer la topologie ou permettre des modifications étendues. Un défaut ou une erreur pouvait se propager à plusieurs clouds. Le rayon d’impact augmentait avec l’utilité de la plateforme.

Les entreprises devaient appliquer le moindre privilège, des identifiants séparés, des approbations multiples, l’audit, la rotation, la révocation d’urgence et une voie de récupération indépendante du même contrôleur. Les documents publics n’incluent pas d’évaluation de sécurité indépendante et complète; ces éléments doivent donc être traités comme des contrôles nécessaires, non comme des garanties vérifiées.

Le graphe de télémétrie était tout aussi sensible. Il pouvait révéler les 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 doit clarifier où ces données sont stockées, quels produits peuvent les utiliser et comment les permissions ont été migrées; les sources publiques ne répondent pas à ces questions.

L’acquisition a déplacé une couche neutre vis-à-vis du cloud vers une plateforme de sécurité

En tant qu’entreprise indépendante, Prosimo pouvait se présenter comme une couche commune entre les clouds et les services de sécurité. Avec Palo Alto Networks comme propriétaire, les incitations ont changé: la technologie pouvait faciliter le déploiement de VM-Series et d’autres produits du groupe, améliorant l’intégration tout en soulevant des questions sur le traitement des services tiers.

La propriété ne prouve pas à elle seule que la neutralité a disparu, mais aucune matrice de compatibilité actuelle n’a non plus été publiée. La question pour les clients devient de savoir si le support des tiers est maintenu, si les politiques et la télémétrie peuvent être exportées et si l’optimisation favorise le portefeuille du propriétaire.

La déclaration a mis l’accent sur l’inspection entrante, sortante et est-ouest. Cela suggère que la topologie et l’orchestration sont devenues partie intégrante d’un système de déploiement de sécurité, mais ne prouve pas qu’App Transit, l’accès utilisateur, l’optimisation des coûts ou tous les flux historiques aient été maintenus comme capacités séparées.

C’est un schéma classique dans l’infrastructure: une startup abstrait un problème de coordination complexe et une plateforme plus grande achète cette abstraction pour accroître l’usage de ses produits principaux. Le client peut gagner en intégration et, en même temps, perdre une part de son indépendance vis-à-vis des fournisseurs.

Le panorama actuel des produits est la plus grande information manquante

Les preuves confirment l’acquisition et l’intégration, mais n’offrent pas un panorama complet reliant AXI, Network Transit, App Transit, AIR et Nebula aux produits ou SKU actuels. Aucune date de support, procédure de migration ni tableau de continuité fonctionnelle n’ont non plus été publiés.

Cette absence empêche une évaluation du produit au présent. L’histoire explique ce qui a été construit, mais pas ce qui est vendu ou maintenu aujourd’hui. Toute recommandation de déploiement actuelle doit se baser sur la documentation en vigueur de Palo Alto Networks.

Elle limite aussi la stratégie. Une absorption complète du graphe serait différente de l’utilisation de la seule découverte d’actifs et du placement de pare-feu. La déclaration confirme une continuité technique tout en laissant la frontière non résolue.

Un document produit, un guide ou un cas futur pourrait clarifier la situation. D’ici là, la formulation précise est que, selon un cofondateur, la technologie a été intégrée aux produits de Palo Alto Networks, bien que l’étendue et le packaging ne soient pas vérifiés.

Qui contrôle le routage multicloud?

Aucun acteur ne contrôle l’intégralité de la route. L’entreprise contrôle la propriété des comptes, l’intention métier, la conception des applications et les identifiants qu’elle accorde. Le contrôleur découvre la topologie, traduit les politiques et modifie l’état des routes; les fournisseurs cloud contrôlent leurs API, leurs services de transit, leurs terminaisons privées, leurs réseaux fédérateurs 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é, de leur côté, décident si le trafic inspecté est autorisé ou bloqué.

Prosimo visait la position intermédiaire. Sans posséder l’infrastructure sous-jacente, il voulait posséder le graphe et la traduction. Qui contrôle cette couche décide ce qui est vu, comment les segments sont représentés, où les nœuds de périphérie sont placés, quel service inspecte et quelle télémétrie est rapportée. Cela constitue un pouvoir pratique sur le routage.

Après l’acquisition, Palo Alto Networks contrôle la technologie et son développement. Les fournisseurs cloud conservent l’autorité à l’intérieur de leurs propres environnements, et l’entreprise peut révoquer les identifiants ou choisir une autre architecture; néanmoins, la sortie peut être coûteuse si la topologie, les politiques et les flux opérationnels dépendent du contrôleur.

La réponse est donc stratifiée: l’entreprise autorise; le contrôleur coordonne; les fournisseurs cloud et les opérateurs transportent; la plateforme de sécurité applique les contrôles. L’histoire de Prosimo montre que le propriétaire de la couche de coordination peut changer sans que les comptes cloud ou la fibre physique ne changent de mains.

Registre principal des sources

Pourquoi Prosimo reste pertinent après l’acquisition

Prosimo a identifié un changement réel dans l’infrastructure. L’unité d’opération se déplace du dispositif et du préfixe vers l’application, l’identité, les dépendances de service et le graphe de politiques. Les API rendent l’état du réseau programmable, tandis que les nœuds de périphérie permettent de déplacer les points d’application des contrôles. Un contrôleur ayant une visibilité sur plusieurs clouds peut coordonner des actions qu’aucune console individuelle ne saurait accomplir seule.

Il a également montré le coût de cette coordination: identifiants privilégiés, maintenance continue des API, découverte précise, traduction sémantique, télémétrie et discipline opérationnelle. Une couche commune peut réduire le travail fragmenté tout en créant un nouveau point de concentration. Le même système qui simplifie les routes peut amplifier l’impact d’une mauvaise décision.

L’acquisition rend plus visible la convergence entre réseau et sécurité. Une entreprise de sécurité qui connaît la topologie et peut modifier les routes ne se limite pas à inspecter le trafic qu’elle reçoit; elle aide aussi à décider quel trafic parvient à l’inspection et où celle-ci se produit.

Prosimo ne doit pas être simplement rappelé comme une marque disparue ou comme la preuve qu’une plateforme a résolu le problème multicloud. Sa contribution durable a été de transformer le graphe transversal en une forme d’infrastructure. La question qui demeure est de savoir si ce graphe, désormais à l’intérieur d’une entreprise plus grande, restera transparent, portable et gouvernable.