Résumé

  • Prosimo a été fondée en 2019 et a levé au moins 55 millions de dollars lors des tours de financement de série A en 2021 et de série B en 2022; les revenus audités, la valorisation et le prix d'acquisition n'ont pas été divulgués.
  • AXI utilise une couche centrale d'intention, de topologie et d'analyse associée à des périphériques distribués pour découvrir les actifs cloud, connecter les applications, insérer des services de sécurité et collecter la télémétrie, sans posséder de réseau fédérateur physique.
  • L'intégration de la gamme VM-Series, annoncée en juin 2024, précède l'intégration de Prosimo dans Palo Alto Networks aux alentours de février 2025; les sources publiques ne fournissent pas de date précise, de prix ni de correspondance avec les produits actuels.
  • Le contrôle reste réparti entre l'entreprise, le logiciel d'orchestration, les fournisseurs de cloud et Palo Alto Networks; la transférabilité de la topologie, des informations d'identification, des politiques et des autorisations de routage est le test le plus critique pour les clients.

L'entreprise a disparu, les problèmes non

Décrire Prosimo comme un fournisseur encore indépendant en 2026 est inexact. Les profils professionnels publics montrent que son fondateur et plusieurs employés ont rejoint Palo Alto Networks vers février 2025. La page de l'entreprise Prosimo est marquée comme acquise, et l'ancien directeur technique Nehal Bhau a déclaré par la suite que la technologie avait été intégrée aux produits de Palo Alto Networks.

Ces preuves suffisent à confirmer un changement de contrôle et une continuité de valeur de la technologie; elles ne permettent pas de confirmer la date de conclusion de l'accord, la date de clôture, la forme juridique ou le prix de la transaction.

Ce fait doit être énoncé d'emblée, car il détermine le temps à utiliser pour toutes les descriptions de produits. AXI, Network Transit, App Transit, Application-driven Intelligent Results et Nebula sont des capacités bien documentées de la période d'indépendance de Prosimo. Tant que Palo Alto Networks n'a pas publié la correspondance avec les produits et le support actuels, il ne faut pas les présenter comme des produits commercialisés en propre sous le nom de Prosimo.

L'architecture historique peut persister après l'acquisition sous forme de code intégré, de services partagés, de modules produits ou d'actifs d'ingénierie internes, ces formes n'étant pas équivalentes.

La disparition de la marque ne signifie pas que les problèmes sous-jacents sont dépassés. Les entreprises continuent de répartir leurs charges de travail entre Amazon Web Services, Microsoft Azure, Google Cloud, des centres de données privés, des installations de colocation, des plateformes SaaS et des utilisateurs distants. Chaque environnement a ses propres règles de routage, de passerelle, de points de terminaison privés, de contrôle d'identité, de services de sécurité, de quotas et de facturation.

Même en possédant tous les comptes, une entreprise n'a pas nécessairement une vue unifiée de la façon dont les requêtes circulent entre ces environnements. L'importance de Prosimo réside dans sa tentative de maîtriser cette vue.

Par conséquent, l'acquisition n'est pas une note de fin, mais la trame de tout l'article. Prosimo a construit une couche de contrôle inter-cloud capable de découvrir les actifs, d'interpréter le contexte applicatif et d'acheminer le trafic vers les services de sécurité. Palo Alto Networks est d'abord apparu comme partenaire technologique, ses pare-feu VM-Series pouvant être insérés dans ces chemins; puis il est devenu propriétaire de la technologie. La frontière qui se trouvait entre l'orchestration du routage et l'inspection profonde a été absorbée au sein d'une même plateforme de cybersécurité.

La bataille du routage multicloud porte en réalité sur le contexte

Une table de routage peut indiquer si un préfixe est accessible via un prochain saut. Mais elle ne peut pas dire, par elle-même, à quelle application l'utilisateur veut accéder, si le demandeur est digne de confiance, si le trafic doit être inspecté, si un point de terminaison privé est disponible, si un chemin cloud est plus coûteux ou pourquoi une transaction échoue après l'arrivée des paquets. L'exploitation multicloud transforme ces questions en un problème de contrôle partagé.

Prosimo a estimé que le droit de routage ne devait pas se baser uniquement sur l'accessibilité de niveau 3. Elle a tenté de combiner l'inventaire des actifs cloud, l'état du réseau, l'identité des applications, l'identité des utilisateurs, les risques, les performances et la télémétrie des transactions. Ce contexte permet des politiques plus spécifiques: connecter une application, isoler un segment, choisir un point d'entrée ou faire transiter un trafic spécifique par un pare-feu. La valeur ne résidait pas dans la création d'un nouveau chemin optique, mais dans la capacité à décider comment combiner les chemins et services existants.

Cela explique aussi pourquoi Prosimo utilisait l'expression « application experience infrastructure - infrastructure d'expérience applicative ». La requête applicative était placée au-dessus des objets réseau individuels; les VPC, VNet, sous-réseaux, hubs de transit ou liens privés n'étaient qu'un composant du chemin de bout en bout, et non l'objet final de la gestion. Cette approche faisait tomber le produit simultanément dans plusieurs marchés: réseau cloud, livraison applicative, accès Zero Trust, assurance réseau, optimisation des coûts et insertion de services de sécurité.

Cette amplitude fonctionnelle créait des opportunités, mais aussi des ambiguïtés. Une plateforme couvrant plusieurs équipes peut résoudre des défaillances de coordination qu'aucune équipe isolée ne gère; mais elle est aussi plus difficile à évaluer, car les équipes réseau, sécurité, cloud, applicatives et financières utilisent des critères de succès différents. Prosimo devait prouver que le modèle unifié améliorait l'exploitation, et non qu'il devenait une couche centralisée supplémentaire dotée de privilèges élevés, capable d'impacter tous les environnements en cas d'erreur unique.

Ce que Prosimo était réellement, et ce qu'il en reste aujourd'hui

Prosimo était une société privée de logiciels de réseau cloud fondée en 2019 et basée dans la région de la baie de San Francisco. Ramesh Prabagaran était co-fondateur et PDG durant la période d'indépendance, et Nehal Bhau co-fondateur et directeur technique. Les profils publics associent également Linus Aranha et Pradeep Aragonda aux travaux de fondation ou de direction technique, mais leurs postes précis doivent être vérifiés par des sources datées.

La plateforme principale s'appelait Application eXperience Infrastructure, ou AXI. AXI gérait l'intention, la topologie, l'analyse et l'orchestration via une couche logicielle centrale, en déployant des AXI Edge distribués dans les régions cloud, les colocations ou les infrastructures sur site à proximité. Par la suite, Prosimo a réorganisé son offre sous le nom de Full-Stack Cloud Transit, avec Network Transit et App Transit traitant différentes catégories de connectivité. AIR analysait la télémétrie et produisait des informations opérationnelles; Nebula a ajouté l'interaction en langage naturel en 2024.

Prosimo n'était pas un opérateur cloud et ne possédait pas de réseau fédérateur mondial en fibre optique reliant toutes les régions. Les chemins pouvaient emprunter le backbone des fournisseurs cloud, l'Internet public, Direct Connect ou ExpressRoute, des liaisons de colocation, des circuits opérateurs et le réseau de l'entreprise. Ce n'était pas non plus un fournisseur de pare-feu du même type que Palo Alto Networks. Dans l'intégration de 2024, Prosimo assurait la découverte, la segmentation et l'acheminement, tandis que VM-Series effectuait l'inspection de sécurité approfondie.

Depuis l'acquisition, le terme le plus approprié est « lignage technologique ». Les déclarations ultérieures d'intégration mettent l'accent sur la découverte d'actifs multicloud et l'accélération du déploiement des pare-feu logiciels pour le trafic entrant, sortant et est-ouest. Cela prouve que des composants importants de Prosimo subsistent, mais pas que l'intégralité du catalogue historique de produits AXI, de l'emballage commercial et des modèles de support est restée inchangée.

Le nouveau problème apparu après le SD-WAN

L'équipe fondatrice possédait une expérience à grande échelle dans les réseaux, la livraison d'applications et l'infrastructure cloud. Prosimo est également issu d'un écosystème plus large de fondateurs et d'ingénieurs liés à Viptela, qui a contribué à faire du SD-WAN une catégorie bien identifiée sur le marché des entreprises. Mais le problème suivant était différent. Le SD-WAN peut simplifier la relation entre les succursales et le réseau ou les applications, mais il ne crée pas automatiquement un modèle opérationnel unifié couvrant 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 managé dans un autre, d'un fournisseur d'identité situé en dehors de ces deux environnements, de liaisons privées reliant les centres de données et d'inspections de sécurité déployées à des périmètres spécifiques. Chaque dépendance peut être représentée par des objets cloud natifs différents.

L'équipe réseau voit des préfixes et des hubs de transit; l'équipe cloud voit des comptes et des ressources; le responsable applicatif voit des noms de domaine et des transactions; l'équipe de sécurité voit des zones et des politiques d'inspection.

Prosimo partait de la requête, et non de la succursale. La véritable question était: comment un utilisateur ou une charge de travail doit-il accéder à l'application avec une sécurité, une performance, une disponibilité et un coût acceptables? Ainsi, l'objet du routage s'élargissait du préfixe de destination à une transaction porteuse du contexte d'identité et d'application. La plateforme devait aussi collecter et maintenir bien plus d'informations qu'un routeur traditionnel.

Le timing du marché était également favorable. AWS, Azure et Google Cloud développaient leurs services de transport natif et de connectivité privée. Les entreprises pouvaient construire des réseaux complexes au sein d'un seul cloud, mais les API, les modèles d'objets et de politiques restaient différents. L'opportunité de Prosimo n'était pas de remplacer cela par un backbone privé, mais d'orchestrer ces capacités cloud natives.

De la fondation en 2019 au lancement public en 2021

Prosimo a été fondée en 2019, mais n'a été lancée publiquement que le 6 avril 2021. General Catalyst a mené un financement de série A de 25 millions de dollars lors du lancement. L'investisseur décrivait l'opportunité comme la livraison d'une expérience applicative à travers le multicloud, ce qui correspondait à l'objectif de l'équipe fondatrice de dépasser la simple connectivité des succursales pour créer une nouvelle catégorie.

Le marché au moment du lancement était à la fois encombré et encore non stabilisé. Les fournisseurs de cloud réduisaient les barrières à l'utilisation de leurs services réseau; les fournisseurs de SD-WAN et de SASE étendaient leurs politiques vers le cloud; les fournisseurs de livraison d'applications pouvaient optimiser les requêtes; les fournisseurs de sécurité pouvaient inspecter le trafic. Prosimo devait démontrer que ces capacités pouvaient fonctionner ensemble dans une architecture orientée cloud, sans prétendre remplacer tous les systèmes environnants.

Le financement a permis de développer les intégrations, les Edge logiciels, les systèmes d'analyse, l'équipe commerciale et les canaux de partenariat. Mais le financement ne prouvait pas à lui seul l'adéquation produit-marché, la taille du chiffre d'affaires ou la différenciation à long terme. Les documents disponibles ne fournissent pas de revenus audités, de revenu récurrent annuel, de nombre total de clients ou de valorisation. Les levées de fonds attestent de l'engagement des investisseurs dans un jugement de marché, pas d'un bilan opérationnel complet.

En 2022, Prosimo a réalisé un tour de table de 30 millions de dollars, décrit comme sursouscrit. En additionnant les deux tours clairement identifiés, le montant total vérifié s'élève à au moins 55 millions de dollars. Certaines bases de données peuvent afficher des chiffres plus élevés en raison d'annonces en double ou d'entrées liées; ces chiffres ne doivent pas être utilisés sans vérification préalable des événements sous-jacents.

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

L'architecture AXI répartissait le travail entre une couche centrale de contrôle et d'analyse, et des Edge logiciels distribués. La couche centrale conservait les intentions applicatives et réseau, découvrait les actifs, assemblait la topologie, intégrait l'identité, analysait la télémétrie et orchestrait les modifications. Les AXI Edge étaient déployés à proximité des charges de travail ou des utilisateurs, évitant ainsi que la politique ne dépende d'un centre physique distant pour son exécution.

Cette séparation est similaire à d'autres systèmes définis par logiciel, mais elle traitait des objets cloud natifs dotés d'une sémantique applicative. Le contrôleur devait accéder aux comptes cloud et aux API; les Edge devaient s'interfacer avec les services de transport natifs, les réseaux des charges de travail, les points de terminaison privés ou les chemins externes. La puissance de la plateforme venait de la combinaison de ces deux vues: une intention globale au-dessus du cloud, et une exécution locale proche du trafic.

L'architecture imposait aussi des limites opérationnelles concrètes. Chaque Edge consommait des ressources cloud, nécessitait une conception haute disponibilité, et devait être mis à jour, surveillé et protégé. 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 gagnait un flux de travail unifié, mais ajoutait un système de gestion dont la disponibilité et la justesse pouvaient impacter la connectivité de production.

Prosimo utilisait parfois l'expression « réseau cloud autonome ». Les preuves étayent l'automatisation, les recommandations et l'orchestration via API, mais pas un réseau fonctionnant indépendamment des politiques humaines, des services cloud et du transport sous-jacent. Les opérateurs devaient toujours définir les intentions, approuver les accès, traiter les exceptions et assumer la responsabilité des résultats.

AXI Edge était un choix de positionnement, pas un appliance virtuel générique

L'AXI Edge pouvait être déployé dans un VPC ou VNet cloud, un environnement de colocation ou une infrastructure de proximité. Une documentation technique AWS montrait un Edge VPC connecté aux VPC de charge de travail via Transit Gateway, avec la possibilité d'insérer un pare-feu en série, tout en connectant les sites sur site ou les utilisateurs distants. Le point d'exécution se trouvait à l'intérieur de la topologie cloud, et non à un périmètre d'entreprise distant.

Le positionnement impactait non seulement la latence, mais déterminait aussi où le trafic entrait dans le domaine de politique, quel segment de backbone cloud ou de chemin Internet était utilisé, où se produisaient le chiffrement et l'inspection, et quelle télémétrie la plateforme pouvait observer. Un mauvais positionnement pouvait entraîner des détours ou des coûts supplémentaires; un bon positionnement pouvait raccourcir les chemins et rapprocher le trafic des charges de travail.

Le déploiement distribué augmentait les domaines de défaillance. La capacité, les versions logicielles, la conception des zones de disponibilité, la convergence de routage et les droits d'accès pouvaient varier d'une région à l'autre. La haute disponibilité ne se limite pas à exécuter deux instances: le contrôleur, les tables de routage cloud, les services de sécurité et les chemins de retour doivent aussi avoir une vision cohérente de l'état de basculement.

L'Edge fait donc partie d'un système opérationnel plus vaste. Sa valeur dépend de la cohérence de la découverte des actifs, de la topologie, des politiques et de l'analyse avec les environnements cloud environnants. Le considérer comme un appliance virtuel isolé ferait manquer l'architecture que Prosimo vendait réellement.

Le transport sous-jacent a toujours appartenu à d'autres acteurs

Prosimo orchestrait le transport, mais ne possédait pas les chemins physiques. Le trafic applicatif pouvait emprunter le backbone d'AWS ou d'autres fournisseurs cloud, l'Internet public, Direct Connect, ExpressRoute, des connexions de colocation, des circuits opérateurs ou le réseau propre de l'entreprise. La plateforme pouvait choisir et orchestrer parmi les options disponibles, mais ne pouvait pas éliminer la latence, la perte de paquets, les domaines de défaillance ou les règles de facturation propres à ces fournisseurs.

Cette limite est essentielle pour comprendre les promesses de performance. Le contrôleur pouvait choisir un chemin observé comme meilleur, ou placer le point d'entrée plus près de l'utilisateur; mais il ne pouvait pas garantir qu'un opérateur ne tomberait pas en panne, qu'une région cloud ne subirait pas d'interruption, ni que les dépendances externes répondraient toujours rapidement. L'expérience applicative est également influencée par le DNS, le traitement du serveur, le stockage, le comportement du navigateur et les services tiers, qui échappent partiellement au contrôle d'un contrôleur réseau.

Ne pas posséder de backbone privé n'était pas seulement une faiblesse. Prosimo pouvait utiliser l'infrastructure que l'entreprise avait déjà acquise et bénéficier des investissements des fournisseurs cloud; elle pouvait pénétrer davantage de régions sans avoir à déployer de fibre, et orchestrer des systèmes natifs comme AWS Cloud WAN. Le prix à payer était la dépendance à la stabilité des API, aux quotas de service, aux conditions commerciales et à la sémantique propre à chaque fournisseur.

La proposition de Prosimo portait donc sur le contrôle opérationnel, pas sur la propriété physique. Elle tentait de faire fonctionner un underlay hétérogène sous un modèle de gestion unifié, tout en conservant les avantages natifs de chacun. La question de savoir si cette abstraction réduit la dépendance envers un fournisseur ou la transfère au contrôleur dépend de la portabilité des politiques, de la topologie et du déploiement des Edge.

Network Transit traitait l'accessibilité entre objets réseau

Network Transit s'adressait aux VPC, VNet, sous-réseaux, régions, sites et segments. Il orchestrait les hubs de transit natifs du cloud et les objets de routage, permettant aux équipes d'établir des connexions via un flux de travail unifié, plutôt que de configurer chaque cloud séparément. Il répondait à un besoin réseau classique: une source ou un segment doit pouvoir atteindre une destination via un chemin autorisé.

Cela ne faisait pas disparaître les différences entre clouds. AWS, Azure et Google Cloud exposent des objets, des quotas et des comportements de routage différents. Les chevauchements d'adresses, les chemins asymétriques, les points de terminaison privés et les limitations des services des fournisseurs nécessitent toujours un traitement technique. Prosimo pouvait normaliser les opérations courantes et afficher les relations, mais les systèmes sous-jacents conservaient leurs propres contraintes.

Network Transit gérait également la segmentation. Les domaines de routage et les politiques pouvaient isoler les environnements ou restreindre l'accessibilité. Le contrôleur devait comprendre comment un segment donné se manifeste dans plusieurs clouds, et comment les objets natifs mettent en œuvre cette frontière. Une politique unifiée pouvait encore se traduire par plusieurs ensembles de modifications spécifiques à chaque fournisseur.

L'interface d'intention unifiée est un avantage, la traduction est un risque. Si la politique commune diverge de la configuration réelle du cloud, l'entreprise peut croire qu'un segment est protégé alors que l'état réel est différent. La réconciliation, l'audit et les états de défaillance explicites sont aussi importants que la configuration initiale.

App Transit faisait de l'application elle-même un objet de routage

App Transit étendait le modèle du sous-réseau à l'application. Il pouvait décider, en fonction du nom de domaine de l'application, de son identité, du type de requête, de la santé de la transaction, des risques et des performances, comment un utilisateur ou une charge de travail devait accéder au service. C'était l'une des distinctions les plus claires entre Prosimo et un routeur cloud traditionnel.

La perspective applicative est précieuse parce que les services modernes ne correspondent pas toujours à des adresses stables. Les plateformes managées, les points de terminaison SaaS et les composants distribués changent, mais l'identité applicative reste pertinente. Une politique centrée sur le service ou l'utilisateur peut être plus durable que des règles écrites uniquement autour des adresses et des ports.

Ce modèle exigeait une découverte précise. Le contrôleur devait savoir quels noms de domaine et points de terminaison appartenaient à une application, quelles dépendances étaient essentielles, et quelles revendications du fournisseur d'identité étaient fiables. Une cartographie obsolète pouvait acheminer les requêtes par un mauvais chemin ou leur appliquer une politique erronée. L'abstraction applicative ne supprimait pas le besoin de comprendre l'état du réseau, elle ajoutait simplement une couche sémantique par-dessus.

La combinaison de Network Transit et d'App Transit reconnaissait que deux types de systèmes coexistent dans l'entreprise: les charges de travail IP traditionnelles et les sous-réseaux privés subsistent, tandis que les nouvelles applications dépendent de noms de domaine, d'identités et de services managés. L'intérêt de Full-Stack Cloud Transit était de placer les deux modèles dans le même cadre opérationnel, sans forcer l'un à remplacer l'autre.

L'identité élargit la décision de routage, et la surface de confiance

L'accès sensible à l'application nécessitait une intégration d'identité. La plateforme pouvait décider d'établir une connexion et du chemin à utiliser en fonction du contexte de l'utilisateur ou de la charge de travail. Cela permettait une politique de type Zero Trust: la localisation seule ne suffisait pas à prouver le droit d'accès.

L'identité améliorait la précision des politiques, mais introduisait une nouvelle dépendance. Les politiques de routage ou d'application dépendaient désormais du fournisseur d'identité, de ses revendications, de l'état de session et des données de groupe. Même si les routeurs et les Edge étaient sains, l'indisponibilité du service d'authentification ou un changement d'attribut pouvait provoquer la défaillance du chemin. Le dépannage devait alors franchir les frontières entre l'exploitation réseau et l'exploitation de l'identité.

Le contrôleur centralisait également un contexte sensible. Il pouvait conserver la topologie, les relations applicatives, les attributs utilisateur, les signaux de risque et les résultats de politique. Ces données facilitaient le diagnostic et l'optimisation, mais rendaient les conséquences d'un accès non autorisé plus graves. Le principe du moindre privilège, la durée de rétention, l'audit et la séparation des tâches devenaient donc des exigences architecturales, et non des tâches de gestion supplémentaires.

Prosimo reflétait une évolution plus large de l'infrastructure: les décisions de routage et d'accès dépendent de plus en plus de l'identité et de la sémantique applicative. Plus le contrôleur voit de contexte, plus ses décisions peuvent être utiles, et plus ses privilèges exigent une gouvernance stricte.

La découverte d'actifs construisait la carte dont dépendent toutes les décisions ultérieures

Un contrôleur inter-cloud ne peut pas gérer ce qu'il ne voit pas. Prosimo a développé la découverte et la cartographie des actifs cloud pour représenter les VPC, VNet, sous-réseaux, applications, connexions et relations de sécurité. Ces vues servaient à la conception, au dépannage et aux politiques.

Cette capacité de découverte était cruciale car les environnements cloud changent souvent en dehors des processus réseau centraux. Les équipes applicatives peuvent créer des comptes, des réseaux, des points de terminaison et des services managés avec leurs propres automatismes. Les schémas maintenus manuellement deviennent rapidement obsolètes. Les inventaires pilotés par API sont généralement plus à jour, mais leur exhaustivité dépend encore de la couverture des comptes, des autorisations, de la logique d'analyse et des API cloud.

Cette carte ne servait pas uniquement à la documentation. Le routage, la segmentation, l'insertion de services et l'optimisation pouvaient s'appuyer sur elle. L'absence d'un actif ou d'une dépendance pouvait fausser les conclusions de niveau supérieur. C'est pourquoi la topologie devait conserver la trace de sa provenance: quand elle avait été collectée, depuis quel compte, quelles régions couvertes, et si des requêtes avaient échoué.

Cela éclaire aussi l'acquisition. Palo Alto Networks ne peut déployer efficacement des capacités de sécurité que s'il sait où se trouvent les charges de travail et les chemins de trafic. Un système capable de découvrir les actifs cloud et de modifier le routage peut réduire le délai entre l'achat d'un pare-feu logiciel et son placement au bon endroit. Les déclarations ultérieures de Bhau soulignent précisément la découverte d'actifs et l'accélération du déploiement des pare-feu logiciels.

AIR transformait la télémétrie des Edge en recommandations opérationnelles

Application-driven Intelligent Results (AIR) analysait la télémétrie collectée par les AXI Edge. Une documentation technique AWS mentionnait le temps d'aller-retour, le temps de traitement, le temps de réponse applicatif, le type de transaction, les risques et les résultats de politique. La plateforme pouvait corréler les observations de l'utilisateur, du réseau et de l'application, au lieu de se contenter d'afficher des compteurs d'équipement isolés.

Cette corrélation répondait à un problème opérationnel courant: le ralentissement d'une transaction peut provenir du chemin utilisateur, de l'Edge, du backbone cloud, du service de sécurité ou de l'application elle-même. Une vue inter-couches peut réduire le champ d'investigation plus rapidement que plusieurs consoles indépendantes, et peut aussi fournir des recommandations sur les chemins, les emplacements, les risques et les coûts.

La qualité des recommandations dépendait de la couverture de la télémétrie et du modèle d'interprétation. L'Edge ne voyait que le trafic qui le traversait; les dépendances applicatives externes et l'état interne des fournisseurs cloud pouvaient rester invisibles. Une recommandation pouvait donc avoir une valeur directionnelle sans certifier la cause racine.

La télémétrie a aussi une valeur de gouvernance. Les données historiques peuvent expliquer pourquoi une route ou une politique a changé, mais elles peuvent aussi exposer l'utilisation sensible des applications et le comportement des utilisateurs. Aucune documentation publique ne décrit complètement la rétention des données et la gouvernance post-acquisition; ces questions relèvent donc encore de la diligence raisonnable du client.

AWS a fourni l'exemple d'implémentation le plus clair parmi les documents publics

La collaboration de Prosimo avec AWS a produit les preuves techniques publiques les plus solides. Prosimo s'intégrait avec AWS Transit Gateway, Cloud WAN, PrivateLink et la Marketplace pour Containers Anywhere. AWS a publié des flux de travail détaillant le positionnement de l'AXI Edge, l'accès applicatif, l'identité, la sécurité et l'optimisation.

AWS Cloud WAN est particulièrement important. Il fournit un backbone natif avec des capacités de segmentation, que Prosimo orchestrait sans le remplacer. La division des rôles était claire: AWS possédait le réseau natif et l'infrastructure mondiale; Prosimo fournissait l'intention inter-cloud, le contexte applicatif, le logiciel Edge et l'analyse.

Le workflow de la Marketplace simplifiait le déploiement initial, mais n'éliminait pas les questions de permissions de compte, de conception de routage, de haute disponibilité, de capacité et d'exploitation à long terme. L'automatisation du Jour 0 pouvait réduire les frictions d'installation, mais ne remplaçait pas la gouvernance continue.

Les documents de Prosimo citaient également le témoignage client de Flexport pour étayer le cas d'usage AWS Cloud WAN. Cela prouve qu'un client d'entreprise était prêt à cautionner cette architecture, mais ne constitue pas un audit indépendant de l'échelle de déploiement, des économies réalisées ou de la disponibilité. Les témoignages clients doivent être considérés comme des exemples d'adoption, et non comme une preuve de performance universelle.

Azure et Google Cloud complétaient la proposition multicloud

Prosimo prenait également en charge Microsoft Azure et Google Cloud. Les documents produits décrivaient l'orchestration autour d'Azure Virtual WAN et des services réseau et privés de Google Cloud. L'objectif était de fournir un modèle opérationnel unifié tout en conservant les réseaux natifs de chaque cloud.

La prise en charge ne signifiait pas une parité fonctionnelle complète. Les API cloud évoluent à des rythmes différents, et des noms de produits similaires peuvent cacher des sémantiques différentes. Le routage, la segmentation, les points de terminaison privés ou l'insertion de services peuvent exiger un traitement spécifique au fournisseur. Les preuves existantes ne permettent pas de reconstituer un tableau comparatif fonction par fonction couvrant toutes les régions et versions.

L'abstraction multicloud fonctionnait donc davantage comme un système de traduction. Elle pouvait normaliser les intentions communes et les flux de travail, mais devait préserver les différences ayant un impact sur la sécurité, les coûts et les défaillances. L'abstraction devient dangereuse lorsque l'interface semble unifiée alors que les différences d'implémentation restent invisibles pour l'opérateur.

Cela reste vrai après l'acquisition. Palo Alto Networks peut utiliser une carte unifiée pour placer la sécurité à travers les clouds, mais les fournisseurs de cloud contrôlent toujours les objets natifs par lesquels les chemins sont mis en œuvre. Posséder la couche d'orchestration n'équivaut pas à posséder l'underlay cloud.

Le produit s'est étendu de la connectivité à l'ensemble du cycle de vie opérationnel

En 2023, Prosimo décrivait son produit comme un flux de travail complet pour la conception, la construction, le dépannage et la gestion des réseaux multicloud, et plus seulement comme des tunnels ou des passerelles. La découverte d'actifs aidait à la conception, l'orchestration créait les connexions, la cartographie et la télémétrie servaient au diagnostic, les politiques et l'historique d'état soutenaient la gestion continue.

Ce positionnement élargissait le bassin d'acheteurs potentiels. Les équipes réseau utilisaient la topologie et l'analyse de chemin; les équipes de plateforme cloud accédaient aux comptes et aux services; les équipes de sécurité examinaient la segmentation et les chemins d'inspection; les équipes de migration planifiaient les changements; les équipes FinOps évaluaient les coûts de sortie et les chemins. La valeur de la plateforme augmentait lorsque plusieurs équipes partageaient les mêmes preuves.

Le partage des preuves pouvait aussi provoquer des conflits de gouvernance. Une plateforme centrale peut découvrir que la configuration native de l'équipe cloud est incohérente avec la politique d'entreprise. L'organisation doit alors décider quel système fait autorité, et qui peut approuver les corrections. Le logiciel seul ne peut pas résoudre ce problème institutionnel.

La narration centrée sur le cycle de vie augmentait également les coûts de changement. Une fois que le contrôleur conserve la carte des actifs, les politiques, la télémétrie, les emplacements des Edge et les intégrations automatisées, le remplacer ne consiste pas seulement à changer des câbles, mais à exporter ou reconstruire le modèle opérationnel. Prosimo résolvait la fragmentation du cloud, mais pouvait aussi créer une dépendance au contrôleur.

La segmentation s'étendait de l'accessibilité de niveau 3 à la politique applicative de niveau 7

Prosimo décrivait une segmentation couvrant les couches 3 à 7. Au niveau réseau, les domaines de routage et les segments déterminaient quels sous-réseaux ou sites pouvaient communiquer; aux niveaux supérieurs, l'identité applicative, le contexte utilisateur et les attributs de transaction pouvaient restreindre davantage les règles.

Ce modèle pouvait réduire la distance entre la zone réseau et la politique applicative. Un service métier spécifique pouvait être autorisé, tandis que l'interconnexion généralisée des sous-réseaux restait bloquée; inversement, un chemin réseau pouvait être accessible mais refusé si le contexte d'identité ou applicatif ne correspondait pas.

Cela ne transformait pas Prosimo en pare-feu nouvelle génération complet. L'intégration avec Palo Alto en 2024 établissait une division claire: Prosimo s'occupait de l'acheminement, de la segmentation et de l'insertion de services, tandis que VM-Series effectuait l'inspection approfondie. L'acheminement de la politique et l'exécution de la sécurité ont des modes de défaillance différents; il ne faut pas les confondre.

La segmentation n'est efficace que si tous les chemins pertinents sont représentés. Une route inconnue, une exception cloud native ou un échec d'insertion de service peuvent contourner le contrôle. La garantie exige de confronter la politique déclarée, l'état réel du cloud et le trafic observé, et non de se fier uniquement à la configuration affichée sur la console.

L'insertion de services reliait le contrôle du routage à l'économie des pare-feu

La conception de la sécurité cloud oblige à décider où l'inspection a lieu. Un pare-feu centralisé simplifie la politique et réduit le nombre d'instances, mais peut entraîner du backhauling, un risque de concentration et une pression sur la capacité. Des pare-feu distribués proches des charges de travail accélèrent l'inspection, mais multiplient les déploiements, les licences, les mises à niveau et les opérations de politique.

L'intégration VM-Series de Prosimo supportait les deux modèles. La politique pouvait aiguiller un trafic spécifique vers un point d'inspection centralisé, ou vers des pare-feu déployés en distribué dans le VPC de l'application. Prosimo modifiait le routage environnant, Palo Alto Networks fournissait l'inspection.

Cette architecture rendait l'orchestration du routage commercialement précieuse pour un fournisseur de sécurité. Un pare-feu logiciel ne peut pas protéger un trafic qui ne le traverse jamais. La découverte, le positionnement et les mises à jour de routage peuvent réduire le délai entre l'achat d'une capacité de sécurité et son insertion réelle dans le chemin de production. C'est l'une des motivations stratégiques logiques de l'acquisition de la technologie Prosimo par Palo Alto Networks.

En contrepartie, le rayon de panne du contrôleur s'élargissait. Une politique erronée pouvait contourner l'inspection, créer des boucles, générer un routage asymétrique ou interrompre l'application. Les contrôles de santé, les modifications par étapes, la simulation, l'audit et le retour arrière deviennent nécessaires, car une erreur d'insertion de services est à la fois un incident réseau et un incident de sécurité.

Le partenariat de 2024 ne doit pas être rétroactivement interprété comme une acquisition réalisée

Prosimo et Palo Alto Networks ont annoncé l'intégration VM-Series le 12 juin 2024. L'annonce décrivait une solution technique et commerciale conjointe, sans déclarer que Palo Alto Networks avait acquis Prosimo. Présenter ce partenariat comme une preuve de propriété confondrait deux événements distincts.

Le partenariat a indéniablement jeté un pont. Prosimo pouvait montrer comment son système de routage et de politiques simplifiait le déploiement inter-cloud de VM-Series; Palo Alto Networks pouvait évaluer la technologie dans une intégration réelle. Aucun document public ne décrit le processus d'acquisition; on ne peut donc pas déduire que ce partenariat était formellement une étape pré-acquisition.

Début 2025, les profils professionnels du fondateur et des employés ont changé; la page de l'entreprise a ensuite été marquée comme acquise; fin 2025, Bhau a déclaré que la technologie était entièrement intégrée. Ces trois types de preuves, combinés, suffisent à conclure à une acquisition, sans pour autant combler le manque de détails juridiques sur la transaction.

Cette chronologie est également importante pour les clients. Un partenariat implique deux fournisseurs, deux systèmes de support et une frontière d'intégration claire. Une acquisition peut transférer la feuille de route, les données, les contrats et les autorisations vers une seule entreprise. Même si le chemin technique semble similaire en surface, les implications de gouvernance ont changé.

Nebula transformait la carte topologique en interface conversationnelle

Prosimo a lancé Nebula en février 2024, dans le cadre de l'AI Suite pour le réseau multicloud. Il était conçu pour répondre en langage naturel à des questions sur les chevauchements d'adresses, les coûts, la santé du routage, les violations de politiques de sécurité, etc., toutes ces questions reposant sur la carte et la télémétrie de la plateforme.

L'actif véritablement précieux n'était pas l'interface langagière elle-même, mais le contexte structuré sous-jacent. Un modèle générique ne peut pas diagnostiquer des routes privées qu'il ne voit pas. Nebula pouvait interroger les actifs, la topologie, les politiques et les données d'observation que Prosimo avait déjà collectés, de sorte que l'investissement antérieur dans une carte unifiée devenait le socle de l'AIOps.

L'accès conversationnel peut permettre à davantage d'opérateurs d'exploiter des données complexes, mais peut aussi créer une fausse confiance: la réponse peut omettre des actifs non supportés, mal interpréter la question, ou présenter une suggestion comme une action approuvée. Les modifications à haut risque exigent toujours un contrôle déterministe, des limites de permission et une revue humaine.

Prosimo avait annoncé un temps moyen de réparation (MTTR) pouvant baisser de 60 % à 80 %, et des coûts de réseau cloud pouvant diminuer de plus de 60 %. Ces chiffres proviennent d'annonces produit du fournisseur, sans méthodologie indépendante ni base de référence client démontrant leur applicabilité générale. Ils peuvent être cités comme les objectifs annoncés par Prosimo, pas comme des vérités industrielles prouvées.

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

La même annonce de 2024 décrivait également l'architecture Prosimo comme adaptée aux charges de travail d'IA. Les systèmes d'IA distribués peuvent nécessiter un accès à des données privées, une connectivité inter-cloud et inter-datacenters, des contrôles de conformité et un routage sensible au contexte applicatif. Ces besoins correspondaient aux modèles existants d'actifs, de politiques et de chemins.

L'étiquette « IA » ne changeait pas l'underlay. Prosimo dépendait toujours des réseaux cloud, des opérateurs et de l'infrastructure du client, et ne fournissait pas de calcul GPU ni de logiciels de développement de modèles. Son rôle potentiel était de fournir connectivité et sécurité autour des données et services distribués.

Ce positionnement était stratégiquement logique, car plus les données et les services sont dispersés, plus la topologie inter-cloud devient précieuse; mais c'était aussi une catégorie marketing introduite peu de temps avant la fin de l'indépendance de l'entreprise. Les preuves existantes ne contiennent pas de revenus IA séparés, de déploiements de production nommés ou de résultats audités.

Une conclusion durable est que la télémétrie multicloud peut servir d'entrée aux opérations assistées par machine. La question aujourd'hui est de savoir si Palo Alto Networks a conservé ce contexte, et comment il expose ces capacités aux clients. La documentation publique n'y répond pas entièrement.

Le modèle économique consistait à vendre du logiciel au-dessus de l'infrastructure des autres

L'activité indépendante de Prosimo reposait sur un modèle d'abonnement logiciel et de services, et non sur un modèle opérateur. Les clients déployaient l'AXI Edge dans leur propre environnement et connectaient leurs comptes cloud à la couche de contrôle. Les revenus provenaient probablement des licences ou abonnements, du support, des services professionnels et des canaux de distribution, mais les documents disponibles ne fournissent pas de prix spécifiques ni d'indicateurs contractuels.

Ce modèle permettait de passer à l'échelle sans posséder de fibre. Une plateforme unique pouvait orchestrer un grand nombre de régions et d'environnements clients. Cependant, on ne peut pas déduire la marge brute de l'architecture; le support continu des API des fournisseurs, le cycle de vie des Edge, les intégrations de sécurité et les déploiements d'entreprise peuvent être coûteux, et les ressources cloud consommées par les Edge peuvent être facturées directement au client.

Prosimo s'appuyait sur les places de marché cloud, les partenaires d'intégration, les canaux de distribution et les témoignages clients pour pénétrer les entreprises. Ces différentes relations ne sont pas équivalentes. La présence sur une marketplace prouve qu'un canal d'achat et de déploiement existe; l'intégration technique prouve que deux systèmes peuvent fonctionner ensemble dans des conditions données; une citation client fournit une référence. Aucun de ces éléments ne prouve isolément le nombre de clients payants ou le revenu récurrent.

L'étendue fonctionnelle pouvait aussi compliquer la vente. Les équipes réseau, sécurité, cloud et applicatives pouvaient toutes en bénéficier, mais la propriété budgétaire était floue. Prosimo avait besoin d'un acheteur prêt à payer pour une couche de contrôle commune, plutôt que de laisser chaque équipe continuer à opérer de manière dispersée.

Partenaires, clients et investisseurs jouaient des rôles différents

AWS était à la fois le fournisseur d'infrastructure sous-jacente et un partenaire d'intégration via la marketplace; Azure et Google Cloud étaient des environnements supportés; les fournisseurs d'identité offraient le contexte d'authentification; les fournisseurs de pare-feu assuraient l'inspection; les services de colocation et d'opérateur pouvaient héberger ou connecter les Edge; les partenaires de distribution pouvaient concevoir et gérer les déploiements.

Flexport est le client de référence nommé le plus visible, notamment dans les documents sur AWS Cloud WAN. Cela prouve qu'un client d'entreprise s'intéressait à l'architecture, mais ne renseigne pas sur l'étendue complète du déploiement, sa durée ou sa valeur commerciale, et ne peut pas être extrapolé à la taille totale de la base de clients.

General Catalyst a mené la série A et participé à la gouvernance de l'investissement. Des documents mentionnent également des investisseurs liés à WRVI/Celesta, et des informations ultérieures évoquent une participation notable liée à BlackRock, sans que la recherche n'ait pu identifier le véhicule d'investissement précis. Ces informations indiquent un solide réseau de financement, mais pas un tableau complet du capital.

Palo Alto Networks constitue la relation la plus importante. Partenaire de sécurité en 2024, il est devenu l'acquéreur début 2025. Ce parcours illustre comment la dépendance technologique peut se transformer en relation de contrôle lorsqu'un partenaire de l'écosystème achète la couche logicielle de coordination qui mène à son propre produit.

Un financement vérifié d'au moins 55 millions de dollars, mais une économie de sortie inconnue

Les financements confirmés incluent la série A de 25 millions de dollars en avril 2021 et la série B de 30 millions de dollars en 2022. Les documents disponibles ne contiennent pas de tableau de capitalisation audité, de valorisation, de titres de créance ou de tours de financement ultérieurs.

Le prix d'acquisition n'a pas été divulgué et n'a pas été vérifié indépendamment. Sans prix, on ne peut pas qualifier de manière responsable l'opération de prime stratégique, d'acquisition technologique ordinaire, d'acquisition de talents ou de vente en difficulté. Le fait que la technologie continue d'être intégrée indique qu'elle a de la valeur, mais ne dit rien du rendement réel pour les investisseurs et les fondateurs.

On ne peut pas non plus attribuer à Prosimo le chiffre d'affaires et la taille de marché de Palo Alto Networks. Après l'acquisition, Prosimo n'est plus une unité économique observable séparément, sans revenus, profits ou segment de clientèle indépendants à analyser. Un propriétaire plus grand peut élargir l'usage de la technologie, tout en rendant ses caractéristiques économiques unitaires plus opaques.

L'absence d'annonce officielle d'acquisition est en elle-même un fait significatif. En temps normal, les clients, les employés et les chercheurs s'appuient sur une annonce pour comprendre le calendrier, le support et la logique stratégique. Ici, l'état des lieux a dû être reconstitué à partir des profils professionnels, du statut de la page entreprise et des déclarations ultérieures du fondateur. Cela suffit à corriger l'identité juridique, pas à inventer les conditions de la transaction.

La concurrence provenait des plateformes spécialisées, des services cloud natifs et de l'ingénierie interne

Prosimo faisait face à des plateformes de réseau multicloud spécialisées comme Aviatrix et Alkira, à des fournisseurs de réseau d'entreprise et de SASE, ainsi qu'aux services natifs d'AWS, Azure et Google Cloud. Elle était également en concurrence avec le modèle « fait maison » de l'entreprise: utilisation directe de l'Infrastructure as Code, des services de transit cloud, des tables de routage et des pare-feu. Chaque alternative résout une partie différente du problème.

Les contrôleurs spécialisés offrent une topologie et des politiques unifiées entre clouds; la conception cloud native réduit la dépendance à un tiers et reste proche du fournisseur; les services opérateurs fournissent le transport physique; les plateformes de sécurité ou SASE combinent connectivité et exécution; l'ingénierie interne échange des coûts humains et d'intégration contre du contrôle.

La différenciation de Prosimo tenait à la combinaison du transit applicatif et réseau, de l'Edge distribué, de l'orchestration cloud native, de la topologie, de la télémétrie et de l'insertion de services. Cette même étendue rendait les comparaisons difficiles. L'acheteur devait tester ses propres schémas réels de services cloud, de routage, d'identité et de sécurité, au lieu de se contenter de comparer des noms de catégories.

L'acquisition change le cadre concurrentiel. Prosimo n'a plus besoin de gagner en tant qu'entreprise indépendante; sa technologie doit faire ses preuves au sein de Palo Alto Networks. La comparaison clé devient: la découverte intégrée et l'orchestration du routage améliorent-elles le déploiement des produits de sécurité Palo Alto, et les clients acceptent-ils la dépendance de plateforme supplémentaire que cela implique?

Les services cloud natifs sont à la fois le socle et un substitut

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN et les capacités réseau de Google Cloud offrent aux entreprises de puissantes alternatives natives. Prosimo en dépendait, tout en étant en concurrence avec les clients qui choisissaient de les opérer directement.

Cette frontière est mouvante. Lorsque les fournisseurs de cloud ajoutent du routage global, de la segmentation, des services privés ou des politiques centralisées, une partie des fonctionnalités tierces devient plus facile à reproduire en natif; en même temps, chaque nouveau service natif crée de nouveaux objets que le contrôleur inter-cloud doit découvrir et coordonner. Les progrès du cloud peuvent réduire une partie de la valeur de Prosimo, ou au contraire accroître le besoin de traduction entre fournisseurs.

Le facteur décisif est, là encore, la capacité organisationnelle. Une entreprise mono-cloud disposant d'une forte ingénierie interne peut préférer les outils natifs; une entreprise multicloud aux équipes fragmentées peut avoir besoin d'une couche de contrôle unifiée; une organisation régulée peut valoriser les preuves fournies par un tiers, tout en redoutant la concentration des informations d'identification et des données.

Aucune architecture n'élimine complètement la dépendance. Les outils natifs dépendent des API et de la sémantique d'un cloud; le contrôleur inter-cloud dépend de sa carte, de ses politiques et de ses Edge. La vraie question est de savoir si la dépendance est transparente, portable et adaptée au modèle opérationnel de l'organisation.

La défaillance pouvait survenir dans le contrôleur, l'Edge, les API cloud, le système d'identité ou le réseau sous-jacent

L'architecture distribuée réduisait la dépendance à un point de trafic unique, mais créait de multiples domaines de défaillance interdépendants. Le service central pouvait être indisponible ou détenir des intentions obsolètes; l'Edge pouvait tomber en panne ou être isolé; les API cloud pouvaient rejeter une modification partielle; le système d'identité pouvait s'interrompre; l'underlay pouvait se dégrader ou changer de chemin; les pare-feu insérés pouvaient épuiser leurs ressources.

Les défaillances partielles étaient particulièrement difficiles. Un cloud accepte la mise à jour de routage, un autre la refuse, ce qui crée un écart entre l'état attendu par le contrôleur et l'état réel; le trafic peut emprunter des chemins asymétriques ou contourner l'inspection. Un système fiable doit intégrer la réconciliation, les opérations idempotentes, les modifications par étapes, les erreurs explicites et des retours arrière adaptés à chaque fournisseur.

Les preuves publiques décrivent une architecture de haute disponibilité et d'optimisation, mais sans étude indépendante d'injection de fautes, sans historique complet d'incidents ni résultats de service universels. Les conclusions sur la résilience doivent donc être limitées à l'architecture documentée ou aux preuves apportées par des clients nommés.

L'acquisition a ajouté un nouveau domaine de défaillance: la continuité des produits. Les clients doivent savoir quel ensemble de consoles, d'API, d'images Edge, de modèles de politiques et d'organisation de support remplace le système Prosimo historique. Même si l'intégration du code est techniquement une réussite, des frontières commerciales et opérationnelles floues peuvent créer un risque de migration.

Les informations d'identification cloud plaçaient le contrôleur à l'intérieur d'un plan de gestion critique

La découverte d'actifs et l'orchestration exigeaient un accès aux comptes cloud. Un inventaire en lecture seule peut utiliser des permissions limitées, tandis que les modifications de routage, de segmentation et d'insertion de services exigent des droits plus étendus. Ainsi, le contrôleur, sans posséder les charges de travail, se trouvait à l'intérieur d'un plan de gestion hautement privilégié.

Une fuite d'identifiants pourrait exposer la topologie ou permettre des modifications étendues; un défaut logiciel ou une erreur opérationnelle pourrait propager une politique à travers plusieurs clouds. Plus la plateforme gère de comptes et de services, plus le rayon de panne potentiel est grand.

Les entreprises doivent utiliser des rôles à privilège minimum, séparer les informations d'identification pour la découverte et pour l'écriture, mettre en œuvre une approbation multiple, un audit complet, une rotation, une révocation d'urgence et conserver un chemin de récupération qui ne dépende pas du même contrôleur. Aucun document public ne contient d'évaluation de sécurité externe complète; ces mesures sont donc des contrôles de déploiement nécessaires, et non des garanties vérifiées.

La carte de télémétrie est tout aussi sensible. Elle peut exposer les noms d'application, la structure réseau, les politiques, les relations utilisateur, la santé du routage et les modèles de coûts. La gouvernance post-acquisition devrait préciser où ces données sont stockées, quels produits Palo Alto Networks peuvent y accéder, et comment les droits historiques des clients sont migrés. Les sources publiques ne l'ont pas encore fait.

L'acquisition a placé une couche de contrôle perçue comme neutre à l'intérieur d'une plateforme de sécurité

Indépendante, Prosimo pouvait se décrire comme une couche de contrôle commune, transverse aux clouds et aux services de sécurité. Maintenant que Palo Alto Networks en est propriétaire, la structure d'incitation change. La technologie acquise peut faciliter le déploiement de VM-Series et d'autres produits Palo Alto. Cela peut apporter une intégration plus étroite, mais soulève aussi la question de savoir si les services d'inspection tiers continueront d'être supportés de manière équitable.

Le changement de propriété ne prouve pas la disparition de la neutralité. Les documents disponibles ne fournissent pas la matrice actuelle des partenaires ni l'architecture complète. Mais la question que les clients doivent poser a changé: le contrôleur continue-t-il à supporter plusieurs fournisseurs de sécurité, les politiques et la télémétrie sont-elles exportables, et la logique d'optimisation privilégie-t-elle le portefeuille de produits du propriétaire?

Les déclarations d'intégration mettent l'accent sur l'inspection du trafic entrant, sortant et est-ouest. Cela indique que la topologie et l'orchestration de Prosimo pourraient devenir un élément du système de déploiement de la sécurité, sans prouver que les flux de travail historiques App Transit, d'accès utilisateur, d'optimisation des coûts et de réseau cloud subsistent tous en tant que fonctions indépendantes.

C'est un schéma récurrent dans l'infrastructure: une start-up abstrait un problème de coordination complexe; un grand fournisseur de plateforme achète cette couche d'abstraction pour accroître le déploiement et le contrôle de ses produits principaux. Le client peut y gagner une meilleure intégration, tout en perdant une partie de son indépendance vis-à-vis des fournisseurs.

La correspondance avec les produits actuels est le fait manquant le plus important

Les documents publics confirment l'acquisition et l'intégration, mais ne précisent pas quels produits ou SKU Palo Alto Networks actuels correspondent respectivement à AXI, Network Transit, App Transit, AIR et Nebula. Ils ne divulguent pas non plus la durée de support des anciens systèmes, le processus de migration ni un tableau de continuité fonctionnelle fonction par fonction.

Il est donc impossible de rédiger une évaluation de produit au présent. Les documents historiques peuvent expliquer ce que Prosimo a construit et pourquoi c'était important, mais ne peuvent pas dire quelles capacités sont disponibles aujourd'hui, comment elles sont concédées sous licence ni par qui elles sont supportées. Toute recommandation de déploiement actuelle doit s'appuyer sur la documentation actuelle de Palo Alto Networks, et non sur les annonces archivées.

L'absence de correspondance limite également l'analyse stratégique. Absorber complètement la carte topologique et la couche d'orchestration, ou n'utiliser que la découverte d'actifs et le positionnement des pare-feu, sont deux résultats différents. Le premier pourrait former un vaste service de contrôle multicloud; le second servirait principalement à accélérer le déploiement de la sécurité. La déclaration du co-fondateur confirme la continuité technologique, mais ne résout pas cette frontière architecturale.

De futurs documents produits, des guides de migration ou des études de cas clients pourraient clarifier la plupart de ces questions. D'ici là, la formulation exacte est la suivante: selon l'un des co-fondateurs, la technologie Prosimo a été intégrée aux produits de Palo Alto Networks, mais la portée et le packaging n'ont pas été vérifiés publiquement.

Qui contrôle le routage multicloud?

Aucune entité ne contrôle seule le chemin complet. L'entreprise contrôle la propriété des comptes, l'intention métier, la conception des applications et les informations d'identification accordées. Le contrôleur inter-cloud peut découvrir la topologie, traduire les politiques, choisir les chemins et modifier les états de routage natifs.

Les fournisseurs de cloud contrôlent les API, les services de transport, les points de terminaison privés, le backbone et de nombreux domaines de défaillance; les opérateurs et les services de colocation contrôlent d'autres segments de transport; les services de sécurité déterminent si le trafic inspecté est autorisé.

Prosimo avait visé la position intermédiaire la plus stratégique. Elle ne possédait pas l'underlay, mais tentait de maîtriser la carte et la traduction des politiques au-dessus de celui-ci. Celui qui contrôle cette couche peut décider quels actifs sont visibles, comment la segmentation est représentée, où les Edge sont placés, quel service inspecte le trafic, et quel ensemble de télémétrie fait autorité. Même si quelqu'un d'autre possède la fibre, c'est là le véritable pouvoir de routage.

Après l'acquisition, Palo Alto Networks possède la technologie restante de Prosimo et décide de son intégration, de son packaging commercial et de son orientation de développement. Les fournisseurs de cloud restent dominants dans leur propre environnement, et l'entreprise peut révoquer les informations d'identification ou choisir une autre architecture; mais si la topologie, les politiques et les flux de travail opérationnels dépendent du contrôleur, le coût de sortie peut être élevé.

La réponse est donc stratifiée: l'entreprise autorise, le contrôleur coordonne, les fournisseurs de cloud et d'underlay transportent, la plateforme de sécurité exécute. L'histoire de Prosimo montre que même si les comptes cloud et les chemins physiques ne changent pas de mains, la propriété de la couche de coordination peut, elle, changer.

Principales sources documentaires

Pourquoi Prosimo mérite encore l'attention après l'acquisition

Prosimo a capté un changement réel. Les unités opérationnelles réseau passent des équipements et des préfixes aux applications, à l'identité, aux dépendances de service et aux cartes de politiques. Les API cloud natives rendent l'état du réseau programmable, et les Edge logiciels distribués rendent le lieu d'exécution mobile. Un contrôleur capable de voir plusieurs clouds peut coordonner des actions qu'une console de cloud unique ne peut pas accomplir.

L'entreprise a aussi exposé le coût de la coordination: une couche de contrôle commune nécessite des informations d'identification hautement privilégiées, une maintenance continue des API, une découverte précise, une traduction sémantique, une télémétrie et une discipline opérationnelle. Elle peut réduire le travail en silos, tout en créant de nouveaux points de concentration; le même système qui simplifie le routage peut aussi amplifier l'impact d'une seule erreur.

L'acquisition par Palo Alto Networks rend le problème de contrôle encore plus visible. 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 comprend la topologie et peut modifier le routage ne se contente pas d'inspecter le trafic qu'on lui envoie; il peut aussi contribuer à décider quel trafic atteint quel point d'inspection.

Prosimo ne doit donc pas être simplement mémorisé comme une marque indépendante disparue, ni considéré comme la preuve qu'une plateforme a résolu le problème multicloud. Sa contribution durable est d'avoir défini la carte inter-cloud comme une infrastructure. La question restante est de savoir si cette carte, une fois entrée dans une grande entreprise de sécurité, reste suffisamment transparente, portable et gouvernable pour mériter la confiance des clients.