Résumé

  • Prosimo a été fondée en 2019 et a levé au moins 55 millions de dollars américains lors d’une série A en 2021 et d’une série B en 2022. Le chiffre d’affaires audité, la valorisation et le prix d’acquisition n’ont pas été divulgués.
  • AXI combinait une couche centrale d’intention, de topologie et d’analyse avec une périphérie distribuée pour assurer la découverte des actifs cloud, la connectivité des applications, l’insertion de sécurité et la collecte de télémétrie, sans posséder de dorsale physique.
  • Après l’annonce de l’intégration VM-Series en juin 2024, Prosimo est passée sous la coupe de Palo Alto Networks vers février 2025, mais la date exacte d’acquisition, le prix et la correspondance avec les produits actuels ne sont pas précisés.
  • Le contrôle est réparti entre l’entreprise, le logiciel d’orchestration, les fournisseurs cloud et Palo Alto Networks. La capacité de migrer la topologie, les informations d’identification, les politiques et les autorisations de changement de routage est un critère important pour les clients.

Même si l’indépendance de l’entreprise a disparu, le problème subsiste

Présenter Prosimo en 2026 comme un fournisseur indépendant en activité ne serait pas exact. Les historiques professionnels publics montrent que le fondateur et plusieurs employés ont rejoint Palo Alto Networks vers février 2025. La page société de Prosimo indique qu’elle a été acquise, et l’ancien directeur technique, Nehal Bhau, a indiqué plus tard que sa technologie avait été intégrée aux produits Palo Alto Networks. Ces preuves attestent d’un transfert de contrôle et de la continuité de la valeur technique, mais ne précisent pas la date de signature du contrat, la date de clôture, la forme juridique ni le prix.

Cette correction liminaire est nécessaire car elle change le temps de toutes les descriptions de produits. AXI, Network Transit, App Transit, Application-driven Intelligent Results et Nebula sont documentés en tant que fonctionnalités de l’ère indépendante de Prosimo. À moins que Palo Alto Networks ne publie une table de correspondance des produits et du support actuels, il ne faut pas les présenter comme des produits actuels disponibles séparément. L’architecture passée peut survivre après l’acquisition sous forme de code intégré, de services partagés, de modules ou d’actifs d’ingénierie internes, mais sous une forme différente.

La disparition d’une marque ne signifie pas que les problèmes sous-jacents ont disparu. 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 sites de colocation, des SaaS et des utilisateurs distants. Chacun de ces environnements possède des routes, des passerelles, des points de terminaison privés, des contrôles d’identité, des services de sécurité, des limites et des règles de facturation qui lui sont propres.

Même lorsqu’une entreprise détient les comptes, il lui arrive de ne pas pouvoir visualiser sur un seul écran comment une requête transite d’un environnement à l’autre. L’importance de Prosimo tient au fait qu’elle a cherché à saisir et à contrôler cette vue d’ensemble au moyen d’une couche opérationnelle unique.

L’acquisition n’est donc pas une simple note de fin, mais le fil conducteur de tout l’article. Prosimo a construit une couche de contrôle inter‑cloud capable de découvrir des actifs, d’interpréter le contexte applicatif et de diriger le trafic vers les services de sécurité. Palo Alto Networks est d’abord apparu comme un partenaire technique insérant le pare‑feu VM‑Series dans ces chemins, avant d’en devenir le propriétaire. La frontière qui séparait l’orchestration du routage de l’inspection profonde s’est déplacée à l’intérieur d’un même socle de cybersécurité.

Le routage multicloud est une concurrence autour du contexte

Une table de routage peut indiquer qu’un préfixe est joignable via un autre saut suivant. Mais elle ne dit pas à quelle application l’utilisateur voulait accéder, si le demandeur est digne de confiance, s’il faut passer par un service d’inspection, si un point de terminaison privé est disponible, quel chemin cloud est le plus coûteux, ni si la transaction échoue après l’arrivée du paquet. L’exploitation multicloud rassemble toutes ces questions en un seul problème de contrôle.

Prosimo affirmait que l’autorité de routage ne devait pas reposer uniquement sur l’accessibilité de couche 3. Son logiciel cherchait à combiner l’inventaire des actifs cloud, l’état du réseau, l’identité applicative, l’identité utilisateur, le risque, la performance et la télémétrie transactionnelle, afin d’exprimer des politiques telles que connecter une application particulière, isoler un segment, choisir un point d’entrée ou faire passer un trafic sélectionné par un pare‑feu. La valeur ne résidait pas dans l’invention de nouveaux chemins en fibre optique, mais dans la décision de la manière de combiner les chemins et services existants.

Cette distinction explique pourquoi l’entreprise a utilisé l’expression « application experience infrastructure ». Le centre de gestion n’était pas l’élément de réseau individuel, mais la demande applicative. Les VPC, VNet, sous‑réseaux, hubs de transit et Private Link deviennent des maillons du parcours de bout en bout et non les unités finales à gérer. Cette approche a fait entrer simultanément le produit dans plusieurs marchés: le réseau cloud, la distribution d’applications, l’accès Zero Trust, l’assurance réseau, l’optimisation des coûts et l’insertion de services de sécurité.

Ce large périmètre a créé à la fois des opportunités et de l’ambiguïté. Un produit qui couvre plusieurs équipes peut résoudre des dysfonctionnements de coordination que personne ne possède seul. En revanche, il est difficile à évaluer, car les équipes réseau, sécurité, cloud, applicatives et financières ne partagent pas la même définition du succès. Prosimo devait démontrer que son modèle inter‑cloud améliorait l’exploitation sans devenir une nouvelle couche privilégiée dont les erreurs se répercutent dans tous les environnements.

Ce qu’était Prosimo, ce qui en reste

Prosimo était une société non cotée fondée en 2019, basée dans la baie de San Francisco, éditrice de logiciels de réseau cloud. Pendant son indépendance, Ramesh Prabagaran en était le cofondateur et PDG, et Nehal Bhau le cofondateur et directeur technique. Les historiques publics mentionnent également Linus Aranha et Pradeep Aragonda comme fondateurs ou cadres supérieurs d’ingénierie, mais les intitulés exacts doivent être alignés sur des documents d’expérience datés.

La plateforme principale s’appelait Application eXperience Infrastructure, ou AXI. Elle associait une couche logicielle centrale chargée de l’intention, de la topologie, de l’analyse et de l’orchestration, et des AXI Edge distribués, déployés dans les régions cloud, les environnements de colocation ou l’infrastructure sur site adjacente. Par la suite, l’offre a été structurée sous le nom Full‑Stack Cloud Transit, Network Transit et App Transit traitant différents types de connectivité. AIR analysait la télémétrie pour produire des recommandations opérationnelles, et Nebula a ajouté une interface conversationnelle en 2024.

Prosimo n’était pas un opérateur cloud. Elle ne possédait pas de dorsale fibre optique mondiale reliant toutes les régions. Les chemins pouvaient emprunter les dorsales des fournisseurs cloud, l’internet public, des liaisons dédiées, des interconnexions de colocation ou des réseaux d’entreprise. Ce n’était pas non plus un fournisseur de pare‑feu au même sens que Palo Alto Networks. Dans l’intégration de 2024, le rôle de Prosimo était la découverte, la segmentation et le pilotage, tandis que l’inspection approfondie était assurée par VM‑Series.

Après l’acquisition, la formulation la plus prudente est celle de « filiation technique ». Les déclarations d’intégration ultérieures ont mis l’accent sur la découverte d’actifs multicloud et l’accélération du déploiement de pare‑feux logiciels pour l’inspection entrante, sortante et est‑ouest. Cela prouve que des composants importants de Prosimo subsistent, mais pas que l’ancienne gamme AXI, les packages commerciaux et le modèle de support client aient perduré tels quels.

Le problème apparu après le SD‑WAN

L’équipe fondatrice possédait une expérience des réseaux à grande échelle, de la distribution d’applications et de l’infrastructure cloud. Prosimo est également issue du vivier de fondateurs et d’ingénieurs liés à Viptela, qui a joué un rôle majeur dans l’établissement du SD‑WAN en tant que segment du marché entreprise. Mais le problème suivant était différent: si le SD‑WAN pouvait simplifier la connectivité des succursales vers le réseau et les applications, il ne créait pas un modèle opérationnel unique à l’intérieur et entre 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é extérieur aux deux, d’une connexion privée vers un centre de données et d’une inspection de sécurité à des frontières choisies. Chaque dépendance est représentée par des éléments natifs différents. L’équipe réseau voit des préfixes et des hubs de transit, l’équipe cloud voit des comptes et des objets de ressource, le propriétaire applicatif voit des domaines et des transactions, et l’équipe sécurité voit des zones et des politiques d’inspection.

Prosimo partait de la requête et non de la succursale. La question était: comment un utilisateur ou une charge de travail atteint-il une application avec des conditions suffisantes de sécurité, de performance, de disponibilité et de coût? Ce cadre élargissait l’objet du routage, passant d’une simple destination préfixe à une transaction dotée d’une identité et d’un contexte applicatif. Il a donc fallu collecter et maintenir beaucoup plus d’informations qu’un routeur classique.

Le contexte du marché était également propice. AWS, Azure et Google Cloud enrichissaient leurs services de transit et de connectivité privée natifs. Les entreprises pouvaient désormais construire des réseaux avancés à l’intérieur de chaque cloud, mais les API, les objets et les modèles de politique différaient d’un fournisseur à l’autre. L’opportunité de Prosimo n’était pas de remplacer ces services par une dorsale propriétaire, mais de les faire fonctionner ensemble.

De la fondation en 2019 au lancement public en 2021

Prosimo a été fondée en 2019, mais n’a annoncé son lancement officiel que le 6 avril 2021. La série A de 25 millions de dollars annoncée à cette occasion était menée par General Catalyst. L’investisseur a souligné l’opportunité de fournir une expérience applicative à travers plusieurs clouds, en phase avec la vision des fondateurs qui cherchaient à définir un espace au‑delà de la simple connectivité de succursale.

À ce moment‑là, le marché était encombré et les frontières floues. Les fournisseurs cloud rendaient leurs propres services réseau plus faciles à utiliser. Les acteurs du SD‑WAN et du SASE étendaient leurs politiques vers le cloud, les spécialistes de la distribution applicative optimisaient les requêtes, et les entreprises de sécurité réseau pouvaient les inspecter. La force de persuasion de Prosimo reposait sur sa capacité à lier ces fonctions dans une architecture orientée cloud, sans prétendre tout remplacer autour d’elle.

Le financement a donné les moyens de construire des intégrations, des périphériques logiciels, des analyses, une force commerciale et des partenariats. Mais il ne prouve pas l’adéquation produit‑marché, le volume des ventes ni une différenciation durable. La documentation disponible ne fournit ni chiffre d’affaires audité, ni revenu récurrent annuel, ni nombre de clients, ni valorisation. Les levées de fonds montrent que des investisseurs ont misé sur une hypothèse, pas un tableau complet de la performance.

En 2022, Prosimo a clôturé une série B de 30 millions de dollars, décrite comme sursouscrite. En cumulant les deux tours clairement identifiés, le total des fonds levés s’élève à au moins 55 millions de dollars. Certaines bases de données agrègent les annonces ou des enregistrements liés pour afficher des montants plus élevés; il ne faut pas les utiliser sans vérifier les opérations d’origine.

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

L’architecture AXI séparait les rôles entre une couche centrale de contrôle et d’analyse et une périphérie logicielle distribuée. La couche centrale conservait l’intention applicative et réseau, découvrait les actifs, assemblait la topologie, intégrait l’identité, analysait la télémétrie et orchestrait les changements. L’AXI Edge, placé près des charges de travail ou des utilisateurs, appliquait les politiques sans obliger tout le trafic à revenir vers un hub physique distant.

Cette séparation ressemble à d’autres systèmes définis par logiciel, mais ciblait spécifiquement le cloud et était sensible aux applications. Le contrôleur avait besoin d’accéder aux comptes cloud et aux API, tandis que la périphérie nécessitait une connectivité aux services de transit natifs, aux réseaux de charge de travail, aux points de terminaison privés et aux chemins externes. En combinant une intention globale au‑dessus du cloud et une exécution locale près du trafic concerné, l’ensemble créait une forme d’autorité infrastructurelle.

Il créait aussi des limites de mise en œuvre. Chaque périphérie consommait des ressources cloud, exigeait une conception haute disponibilité et devait être mise à jour, surveillée et protégée. La couche de contrôle nécessitait des informations d’identification suffisamment puissantes pour découvrir des actifs et modifier l’état du réseau. Les entreprises gagnaient un flux de travail commun, mais ajoutaient un nouveau système de gestion dont la disponibilité et l’exactitude affectaient directement l’accessibilité en production.

Prosimo parlait parfois de réseau cloud autonome. Ce que les preuves étayent, c’est de l’automatisation, des recommandations et une orchestration pilotée par API. Pas un réseau fonctionnant indépendamment des politiques humaines, des services des fournisseurs cloud et des chemins de transport sous‑jacents. Les exploitants continuaient à définir l’intention, à approuver les accès, à traiter les exceptions et à assumer la responsabilité des résultats.

L’AXI Edge n’était pas un appareil universel, mais une décision de placement

L’AXI Edge pouvait être déployé dans un VPC ou VNet cloud, un environnement de colocation ou une infrastructure adjacente. La documentation technique AWS décrivait une configuration où un VPC périphérique se connectait aux VPC de charge de travail via Transit Gateway, chaînant éventuellement des pare‑feux, et accessible depuis des utilisateurs distants ou des sites sur site. Le point d’exécution de Prosimo se trouvait donc à l’intérieur de la topologie cloud, pas à une frontière d’entreprise éloignée.

Ce placement affectait la latence, mais aussi le point d’entrée du trafic dans le domaine de politique, le choix de la dorsale cloud ou du chemin internet, le lieu du chiffrement et de l’inspection, et la télémétrie collectable. Un mauvais placement créait des détours et des coûts; un bon placement raccourcissait les chemins et gardait le trafic près des charges de travail.

Le déploiement distribué multipliait les domaines de défaillance à gérer. La capacité, la version logicielle, la conception de zone cloud, la convergence de routage et les droits d’accès pouvaient varier d’une région à l’autre. La haute disponibilité ne se résumait pas à faire tourner deux instances: le contrôleur, les tables de routage cloud, les services de sécurité et le chemin de retour devaient partager le même état de basculement.

La périphérie faisait donc partie d’un système opérationnel plus vaste. Sa valeur dépendait de l’alignement entre la découverte des actifs, la topologie, les politiques et l’analyse avec l’environnement cloud environnant. La traiter comme un simple appliance virtuel autonome ferait perdre de vue l’architecture que Prosimo essayait de vendre.

La sous‑couche a toujours appartenu à quelqu’un d’autre

Prosimo orchestrait le transport, mais ne possédait pas les chemins physiques. Les itinéraires applicatifs pouvaient utiliser les dorsales cloud comme celle d’AWS, l’internet public, Direct Connect ou ExpressRoute, des services de colocation, des liaisons d’opérateur ou des réseaux d’entreprise. La plateforme pouvait choisir et relier les chemins disponibles, sans pour autant faire disparaître la latence, la perte de paquets, les domaines de défaillance ou les règles tarifaires propres à chaque fournisseur.

Cette frontière est importante pour évaluer les affirmations de performance. Le contrôleur peut sélectionner un chemin empiriquement meilleur et rapprocher le point d’entrée de l’utilisateur. Il ne peut pas garantir qu’une panne d’opérateur, une interruption de région cloud ou une dégradation externe ne se produira pas. L’expérience applicative intègre en outre le DNS, le traitement serveur, le stockage, le comportement du navigateur et les services tiers, autant d’éléments qui échappent au pouvoir du contrôleur réseau.

Ne pas posséder de dorsale n’était pas qu’une faiblesse. Cela permettait d’exploiter l’infrastructure déjà achetée par les entreprises et de bénéficier des investissements des fournisseurs cloud. On pouvait atteindre une région sans poser de fibre et composer avec des systèmes natifs comme AWS Cloud WAN. En contrepartie, il fallait dépendre de la stabilité des API, des quotas, des conditions commerciales et de la sémantique propre à chaque fournisseur.

La revendication portait donc sur le contrôle opérationnel, pas sur la propriété physique. Il s’agissait de faire en sorte que des sous‑couches hétérogènes se comportent comme un seul système de gestion, tout en conservant leurs avantages natifs. La question de savoir si cette abstraction réduisait le verrouillage ou ne faisait que le déplacer dépendait de la portabilité des politiques, de la topologie et du placement des périphériques.

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

Network Transit se concentrait sur les VPC, VNet, sous‑réseaux, régions, sites et segments. Il orchestrait les configurations de transit et de routage natives du cloud pour créer des connexions via un flux de travail commun, au lieu de paramétrer chaque fournisseur séparément. Il aidait à satisfaire le besoin réseau fondamental: qu’un préfixe ou segment source puisse atteindre une destination par un chemin autorisé.

Cela ne prétendait pas effacer les différences entre clouds. AWS, Azure et Google Cloud ont des objets, des quotas et des comportements de routage différents. Les espaces d’adressage qui se chevauchent, les chemins asymétriques, les points de terminaison privés et les limitations de service propres à chaque fournisseur exigeaient toujours une conception soignée. Prosimo pouvait normaliser les opérations communes et visualiser les relations, mais les contraintes des systèmes sous‑jacents subsistaient.

Network Transit prenait également en charge la segmentation. Les domaines de routage et les politiques permettaient d’isoler des environnements et de restreindre l’accessibilité. Le contrôleur devait comprendre où se trouvaient les segments dans plusieurs clouds et comment les configurations natives réalisaient les frontières. Une politique exprimée une fois pouvait se traduire par plusieurs changements selon le fournisseur.

L’avantage était de pouvoir traiter l’intention sur un seul plan. Le risque se situait dans la traduction: si la politique commune et les paramétrages cloud divergeaient, l’entreprise pouvait croire un segment protégé alors que l’état réel du fournisseur était différent. La réconciliation, l’audit et le signalement explicite des échecs comptaient donc autant que le provisionnement initial.

App Transit faisait de l’application un objet de routage

App Transit étendait le modèle au‑delà des sous‑réseaux. Pour décider comment un utilisateur ou une charge de travail atteint un service, il pouvait exploiter le domaine applicatif, l’identité, le type de requête, la santé transactionnelle, le risque et la performance. C’est là que Prosimo tentait de se démarquer le plus nettement d’un routeur cloud classique.

Cette vue applicative avait du sens, car les services modernes ne se résument pas à des adresses fixes. Les plateformes managées, les points de terminaison SaaS et les composants distribués changent, tandis qu’un identifiant applicatif peut garder sa signification. Une politique qui référence un service ou un utilisateur peut durer plus longtemps qu’une règle fondée uniquement sur l’adresse et le port.

Ce modèle exigeait une découverte précise. Le contrôleur devait savoir quels domaines et points de terminaison appartiennent à une application, quelles dépendances sont nécessaires et quelles assertions du fournisseur d’identité sont fiables. Un mappage obsolète risquait d’envoyer les requêtes vers le mauvais chemin et d’appliquer des règles de sécurité erronées. L’abstraction applicative ne supprimait pas le besoin de comprendre l’état du réseau, elle ajoutait une couche de sens par‑dessus.

L’association de Network Transit et d’App Transit reconnaissait que les deux mondes coexistent dans l’entreprise. Des systèmes hérités, des sous‑réseaux privés et des contrôles IP persistent, tandis que les nouvelles applications s’appuient sur des domaines, des identités et des services managés. Full‑Stack Cloud Transit était le nom commercial destiné à exploiter les deux simultanément, sans remplacer l’un par l’autre.

L’identité élargissait les décisions de routage et les frontières de confiance

L’accès sensible à l’application nécessitait une intégration d’identité. La plateforme pouvait utiliser le contexte de l’utilisateur ou de la charge de travail pour autoriser la connexion et décider comment l’établir. Cela soutenait les politiques de type Zero Trust, pour lesquelles la localisation seule ne suffit pas comme fondement de l’autorisation.

L’identité apportait de la précision mais créait de nouvelles dépendances. Une politique de routage ou d’application pouvait dépendre du fournisseur d’identité, de ses assertions, de l’état de session et des informations de groupe. Même si les routeurs et la périphérie fonctionnaient, un arrêt d’authentification ou un changement d’attribut pouvait faire échouer les chemins réseau. La réponse aux incidents devait franchir la frontière entre l’exploitation réseau et l’exploitation d’identité.

Le contrôleur devenait aussi un point de concentration de données sensibles: topologie, relations applicatives, attributs utilisateurs, signaux de risque, résultats de politiques. Ces données améliorent le diagnostic et l’optimisation, mais augmentent l’impact d’un accès illégitime. Les principes de moindre privilège, de durée de conservation, d’audit et de séparation des tâches n’étaient pas un ajout administratif, mais des exigences architecturales.

La démarche de Prosimo illustre une transformation plus large de l’infrastructure: les politiques de routage et d’accès dépendent de plus en plus de l’identité et de la sémantique applicative. Plus le contexte est riche, plus les décisions peuvent être utiles. Mais ce pouvoir appelle un contrôle plus rigoureux.

La découverte d’actifs créait un graphe qui sous‑tendait toutes les décisions suivantes

Un contrôleur inter‑cloud ne peut pas gouverner ce qu’il ne voit pas. Prosimo a développé la découverte et la cartographie des actifs cloud, représentant les VPC, VNet, sous‑réseaux, applications, connexions et relations de sécurité. Ces vues soutenaient l’intégration, la conception, le dépannage et la politique.

La découverte avait une valeur stratégique parce que les actifs cloud changent en dehors des procédures réseau centrales. Les équipes applicatives créent des comptes, des réseaux, des points de terminaison et des services managés via leur propre automatisation. Les diagrammes manuels deviennent obsolètes. Un inventaire piloté par API peut produire un graphe plus à jour, mais son exhaustivité dépend du périmètre des comptes, des autorisations, de la logique d’analyse et des API des fournisseurs.

Le graphe n’était pas qu’une documentation: c’était la structure de données servant à calculer le routage, la segmentation, l’insertion de services et l’optimisation. Un actif ou une dépendance manquants pouvaient vicier toutes les décisions construites au‑dessus. La topologie devait donc être accompagnée d’une provenance: quand elle avait été collectée, quels comptes l’avaient fournie, quelles régions étaient incluses, et si les requêtes avaient réussi.

Ce graphe explique aussi les raisons de l’acquisition. Palo Alto Networks peut créer de la valeur de sécurité à partir de la connaissance de l’emplacement des charges de travail et des chemins de trafic. Un système capable de découvrir les actifs cloud et de modifier les routes réduit l’écart entre l’achat d’un pare‑feu logiciel et son placement correct. La déclaration d’intégration ultérieure de Bhau a d’ailleurs expressément mis l’accent sur la découverte d’actifs et l’accélération du déploiement des pare‑feux logiciels.

AIR transformait la télémétrie de périphérie en recommandations opérationnelles

Application‑driven Intelligent Results (AIR) analysait la télémétrie collectée par l’AXI Edge. La documentation d’AWS décrivait une visualisation des temps aller‑retour, des temps de traitement, des temps de réponse applicative, des types de transaction, du risque et des résultats de politiques. La plateforme pouvait corréler des observations provenant de l’utilisateur, du réseau et de l’application, au lieu de se limiter à des compteurs d’équipements isolés.

Cette corrélation répond à un problème opérationnel courant. Une transaction lente peut venir du chemin utilisateur, de la périphérie, de la dorsale cloud, du service de sécurité ou de l’application elle‑même. Une vue transversale réduit le champ d’investigation plus vite que des consoles séparées, et peut aider à formuler des recommandations de chemin, de placement, de risque et de coût.

La qualité des recommandations dépendait de l’étendue de la télémétrie et du modèle d’interprétation. La périphérie ne voit que le trafic qui la traverse. Les dépendances applicatives externes ou l’état interne du fournisseur cloud peuvent rester invisibles. Les recommandations peuvent être utiles à titre indicatif sans pour autant prouver une cause racine.

La télémétrie avait aussi une valeur de contrôle. Les observations passées aident à expliquer pourquoi les routes et les politiques ont changé. Mais elles peuvent aussi révéler des usages applicatifs sensibles ou des comportements utilisateur. La documentation publique ne décrit pas complètement les durées de conservation ni le contrôle des données après l’acquisition; ces éléments restent donc des points de vigilance pour les clients.

AWS a fourni la preuve d’implémentation la plus claire

Le travail de Prosimo avec AWS a laissé les preuves techniques publiques les plus solides. L’entreprise s’est intégrée avec AWS Transit Gateway, Cloud WAN, PrivateLink et le flux de déploiement Marketplace for Containers Anywhere. AWS a publié une documentation technique décrivant le placement de l’AXI Edge, l’intégration applicative, l’identité, la sécurité et l’optimisation.

AWS Cloud WAN a été particulièrement important car il offrait un service de dorsale et de segmentation cloud natif que Prosimo pouvait orchestrer, au lieu de devoir le remplacer. Cette configuration illustre un modèle coopératif: AWS possède le réseau natif et l’infrastructure mondiale, tandis que Prosimo fournit l’intention inter‑cloud, le contexte applicatif, le logiciel de périphérie et l’analyse.

Les flux Marketplace permettaient de packager l’AXI Edge via un canal approuvé et de simplifier les premières étapes de déploiement. Mais les autorisations de compte ultérieures, la conception des routes, la haute disponibilité, la capacité et l’exploitation demeuraient. L’automatisation du jour zéro réduit les frictions d’adoption, sans éliminer les problèmes de contrôle à long terme.

La documentation commerciale mentionne le cas client Flexport en appui du cas d’usage AWS Cloud WAN. Cela prouve qu’un client entreprise a soutenu l’architecture, mais ne constitue pas un audit indépendant de la taille du déploiement, des économies réalisées ou de la disponibilité. Les commentaires clients doivent être traités comme des exemples d’adoption et non comme des preuves universelles de performance.

Azure et Google Cloud complétaient la revendication multicloud

Prosimo prenait également en charge les environnements Microsoft Azure et Google Cloud. La documentation produit décrivait l’orchestration autour d’Azure Virtual WAN, de la mise en réseau Google Cloud et des configurations de services privés. L’objectif était de conserver le réseau natif de chaque fournisseur tout en présentant un modèle opérationnel unique.

La présence de cette prise en charge ne prouve pas une fonctionnalité identique d’un fournisseur à l’autre. Les API cloud mûrissent à des rythmes différents et des noms de produits similaires peuvent cacher des sémantiques différentes. Les routes, segments, points de terminaison privés et l’insertion de services peuvent exiger un traitement spécifique à chaque fournisseur. La documentation disponible ne permet pas de reconstituer un tableau d’équivalence fonctionnelle par fonction couvrant toutes les régions et toutes les versions.

L’abstraction multicloud se comprend donc le mieux comme un système de traduction. Elle normalise une intention et des flux de travail communs, mais doit laisser apparents les détails qui influent sur la sécurité, le coût et la défaillance. Si l’écran est unifié alors que les différences de mise en œuvre restent cachées aux exploitants, la plateforme devient dangereuse.

Le même constat vaut après l’acquisition. Palo Alto Networks pourra peut‑être s’appuyer sur un graphe commun pour déployer la sécurité sur plusieurs clouds, mais les objets natifs qui implémentent les chemins restent sous le contrôle des fournisseurs cloud. Posséder la couche d’orchestration ne revient pas à posséder la sous‑couche cloud.

Le produit est passé de la connectivité au cycle de vie

En 2023, Prosimo décrivait des flux de travail couvrant la conception, la construction, le dépannage et la gestion des réseaux multicloud. Le produit ne se limitait plus à l’établissement de tunnels ou de passerelles. La découverte d’actifs alimentait la conception, l’orchestration créait les connexions, la cartographie et la télémétrie soutenaient le dépannage, et les politiques et l’historique des états soutenaient la gestion continue.

Cette perspective de cycle de vie élargissait le public d’acheteurs commerciaux. Les ingénieurs réseau pouvaient utiliser les analyses de topologie et de routage, les équipes d’infrastructure cloud pouvaient intégrer les comptes et les services, les équipes sécurité pouvaient vérifier la segmentation et l’inspection, les équipes migration pouvaient planifier les changements, et les équipes FinOps pouvaient examiner l’impact des chemins et des sorties. Plus les organisations s’appuyaient sur les mêmes preuves, plus la valeur de la plateforme augmentait.

Cette preuve partagée créait aussi des tensions de gouvernance. L’infrastructure centrale pouvait révéler que les configurations natives des équipes cloud s’écartaient des politiques de l’entreprise. Les organisations devaient décider quel système fait autorité et qui approuve les corrections. Le logiciel seul ne résout pas ce problème institutionnel.

Le récit du cycle de vie renforçait aussi les coûts de changement. Lorsqu’un contrôleur détient le graphe d’actifs, les politiques, la télémétrie, les périphériques déployés et les intégrations d’automatisation, son remplacement exige plus qu’un simple basculement de circuit. Le client doit exporter son modèle opérationnel ou le reconstruire. Prosimo vendait la réduction de la fragmentation cloud, tout en créant la possibilité d’une dépendance au contrôleur.

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

Prosimo revendiquait une segmentation de la couche 3 à la couche 7. Au niveau réseau, les domaines de routage et les segments déterminaient quels sous‑réseaux et sites pouvaient communiquer. Aux niveaux supérieurs, l’identité applicative, le contexte utilisateur et les caractéristiques transactionnelles affinaient les règles.

Le modèle en couches pouvait combler le fossé entre les zones réseau et les politiques applicatives. Il était possible de bloquer une large accessibilité inter‑sous‑réseau tout en autorisant uniquement un service métier spécifique. Inversement, un chemin réseau accessible pouvait être refusé si l’identité ou le contexte applicatif ne convenait pas.

Cela ne faisait pas pour autant de Prosimo un pare‑feu nouvelle génération complet. L’intégration avec Palo Alto Networks en 2024 répartissait les responsabilités: Prosimo orchestrait les routes, la segmentation et l’insertion de services, tandis que VM‑Series effectuait l’inspection approfondie. Cette distinction est importante, car les défaillances diffèrent entre le contrôle de routage par politique et l’application de la sécurité.

Un segment n’est efficace que si tous les chemins pertinents sont exprimés. Des routes inconnues, des exceptions natives du cloud ou une insertion de service échouée peuvent contourner les contrôles prévus. L’assurance exige donc une comparaison entre les politiques déclarées, l’état du fournisseur et le trafic observé, et non une simple confiance dans l’écran du contrôleur.

L’insertion de services reliait le contrôle de routage à l’économie des pare‑feux

Dans une conception de sécurité cloud, il faut décider où placer l’inspection. Un pare‑feu central simplifie la politique et réduit le nombre d’instances, mais peut créer des détours, une concentration du trafic et une pression sur la capacité. Un pare‑feu distribué, placé près des charges de travail, réduit la distorsion des chemins, mais augmente le nombre de déploiements, de licences, de mises à jour et d’opérations de politique.

Prosimo, par son intégration VM‑Series, soutenait les deux configurations. Une politique pouvait envoyer le trafic sélectionné vers un point d’inspection central ou vers un pare‑feu distribué dans le VPC applicatif. C’est Palo Alto Networks qui fournissait la fonction d’inspection, tandis que le contrôleur mettait à jour les routes environnantes.

Cette architecture rendait l’orchestration de routage commercialement précieuse pour un fournisseur de sécurité. Un pare‑feu logiciel ne peut pas protéger du trafic qu’il n’atteint pas. La découverte, le placement et la mise à jour des routes réduisent les frictions opérationnelles entre l’achat de capacité de sécurité et son insertion dans le chemin de production. C’est une raison stratégique plausible pour que Palo Alto Networks ait intégré la technologie de Prosimo.

Dans le même temps, la surface de contrôle du contrôleur s’élargit. Une politique erronée peut contourner l’inspection, créer des boucles, générer un routage asymétrique ou interrompre les applications. L’échec de l’insertion de services est à la fois une panne réseau et un incident de sécurité, ce qui impose des contrôles de santé, des changements progressifs, des simulations, des audits et des retours arrière.

Le partenariat de 2024 ne doit pas être antidaté au moment de l’acquisition

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, mais ne mentionnait pas l’acquisition de Prosimo par Palo Alto Networks. Considérer cette annonce comme une preuve de propriété reviendrait à confondre deux événements distincts.

Le partenariat a néanmoins servi de pont. Prosimo pouvait démontrer que son système de routage et de politiques facilitait le déploiement de VM‑Series sur plusieurs clouds. Palo Alto Networks pouvait évaluer la technologie à travers une intégration réelle avant la transition ultérieure. Les informations publiques ne décrivent pas le processus d’acquisition; affirmer que le partenariat a été conçu comme une phase formelle de pré‑acquisition relèverait de la spéculation.

Début 2025, les historiques professionnels du fondateur et des employés avaient changé. Par la suite, la page société affichait « acquise ». Fin 2025, Bhau déclarait que la technologie était pleinement intégrée aux produits Palo Alto Networks. Ces éléments réunis étayent la conclusion d’une acquisition, mais les détails juridiques restent inconnus.

Cet ordre chronologique importe à la fois pour l’exactitude éditoriale et pour les clients. Dans un partenariat, il y a deux fournisseurs, deux organisations de support et des frontières d’intégration claires. Dans une acquisition, la feuille de route, les données, les contrats et l’autorité peuvent être transférés à une seule entité. Même si le chemin technique reste proche au départ, la transition ne change pas seulement la marque.

Nebula a transformé le graphe de topologie en interface conversationnelle

En février 2024, Prosimo a présenté Nebula dans le cadre d’une Suite IA pour le réseau multicloud. Cet assistant était conçu pour répondre en langage naturel à des questions sur des états représentés dans le graphe et la télémétrie de la plateforme, tels que les réseaux qui se chevauchent, les coûts, la santé des routes et les violations de politique de sécurité.

L’actif utile n’était pas l’interface langagière en elle‑même, mais le contexte structuré inter‑cloud sous‑jacent. Un modèle générique ne peut pas diagnostiquer des routes privées ou des segments qu’il ne voit pas. Nebula pouvait exploiter l’inventaire d’actifs, la topologie, les politiques et les observations que Prosimo avait déjà collectés. L’investissement préalable dans un graphe commun se connectait ainsi à l’AIOps.

L’accès conversationnel peut ouvrir des données complexes à un plus grand nombre d’opérateurs. Mais il peut aussi créer une fausse confiance s’il omet des actifs non pris en charge dans les réponses, s’il interprète mal les questions ou s’il présente des recommandations comme des actions approuvées. Les changements à haut risque nécessitaient toujours un contrôle déterministe, des limites d’autorité et une vérification humaine.

Prosimo a avancé une réduction du temps moyen de réparation (MTTR) de 60 à 80 % et une diminution des coûts de réseau cloud de plus de 60 %. Ces chiffres proviennent des affirmations de l’entreprise lors de l’annonce produit. La documentation disponible ne contient pas de méthodologie indépendante ni de référence client démontrant une applicabilité générale. On peut les citer comme bénéfices avancés par Prosimo, mais pas comme des faits de marché mesurés.

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

La même annonce de 2024 positionnait également l’architecture de Prosimo comme utile pour les charges de travail d’intelligence artificielle. Les systèmes d’IA distribués peuvent nécessiter un accès privé aux données, une connectivité entre clouds et centres de données, des contrôles de conformité et un routage reflétant le comportement applicatif, autant d’éléments qui correspondent aux modèles existants d’actifs, de politiques et de chemins.

Changer de nom ne change pas la sous‑couche. Prosimo dépendait toujours des réseaux cloud, des opérateurs et de l’infrastructure client. Elle ne fournissait ni calcul GPU ni logiciel de développement de modèles. Son rôle présumé était d’apporter la couche de connectivité et de sécurité entourant les données et services distribués.

Le positionnement IA avait une logique stratégique: plus les données et services sont distribués, plus la valeur d’une topologie inter‑cloud augmente. Mais c’était aussi une catégorie marketing introduite juste avant la fin de l’indépendance de l’entreprise. La documentation ne montre pas de chiffre d’affaires autonome pour un produit IA, de déploiement nominal en production ni de résultats de charge de travail audités.

Le point qui perdure est que la télémétrie multicloud peut devenir une entrée pour des opérations assistées par machine. La question produit actuelle est de savoir si Palo Alto Networks a conservé ce contexte et comment il le met à disposition. À la date de l’enquête, les preuves publiques n’apportent pas de réponse complète.

Le modèle commercial vendait du logiciel sur une infrastructure qui ne lui appartenait pas

Durant son indépendance, Prosimo tirait ses revenus de souscriptions logicielles et de services, et non d’un modèle d’opérateur télécom. Les clients déployaient l’AXI Edge dans leur propre environnement et connectaient leurs comptes cloud à la couche de contrôle. Le chiffre d’affaires dépendait vraisemblablement de licences ou d’abonnements, de support, de services professionnels et de l’activité des partenaires, mais les prix et indicateurs contractuels exacts ne sont pas publics dans la documentation fournie.

C’était un modèle qui pouvait évoluer sans posséder de fibre optique. Une seule plateforme logicielle coordonne de nombreuses régions cloud et environnements clients. On ne peut toutefois pas déduire la structure de marge brute de cette seule architecture. La maintenance de la compatibilité avec les API des fournisseurs, le cycle de vie des périphériques, les intégrations de sécurité et l’accompagnement des entreprises ont un coût, et il est probable que les ressources cloud consommées par les périphériques étaient à la charge du client, non du fournisseur.

Prosimo a utilisé les places de marché cloud, les partenaires d’intégration, les canaux de vente et des exemples clients nominatifs pour atteindre les entreprises. Ces éléments ne constituent pas le même type de preuve. Une présence sur une place de marché indique un chemin d’approvisionnement et de déploiement. Une intégration technique indique que deux systèmes peuvent fonctionner ensemble dans des conditions définies. Un commentaire client montre un exemple d’adoption. Aucun ne prouve à lui seul le nombre de clients payants ou le revenu récurrent.

La largeur du périmètre a peut‑être ajouté de la complexité commerciale. Même si les équipes réseau, sécurité, cloud et applicatives en bénéficiaient, le propriétaire budgétaire n’était pas toujours évident. Le produit avait besoin d’un acheteur qui finance une couche de contrôle commune, plutôt que de laisser chaque équipe exploiter les clouds séparément.

Partenaires, clients et investisseurs occupaient des positions différentes

Amazon Web Services était à la fois un fournisseur de sous‑couche et un partenaire d’intégration pour la commercialisation. Azure et Google Cloud étaient des environnements pris en charge. Les fournisseurs d’identité apportaient le contexte d’authentification, les fournisseurs de pare‑feu apportaient l’inspection. Les opérateurs de colocation et de télécommunications pouvaient héberger et connecter les périphériques, et les partenaires de distribution pouvaient concevoir et opérer les déploiements.

Dans la documentation AWS Cloud WAN, Flexport apparaissait comme un exemple client nominatif. Ce cas montre qu’une entreprise s’est intéressée à l’architecture, mais l’étendue complète du déploiement, sa durée et sa valeur commerciale ne sont pas connues à partir de la documentation. Il ne doit pas servir d’indicateur indirect pour l’ensemble de la base client.

General Catalyst a mené la série A et, en tant qu’investisseur, participait à la gouvernance. La documentation mentionne également des investisseurs liés à WRVI ou Celesta, et les communications ultérieures de Prosimo ont évoqué des participations d’investisseurs de premier plan comportant des noms associés à BlackRock, sans que les véhicules d’investissement précis ne soient résolus par l’enquête. Ces éléments indiquent une base de financement influente, mais pas un tableau de capitalisation complet.

La relation la plus importante était celle avec Palo Alto Networks. D’un partenaire de sécurité en 2024, il est devenu l’acquéreur début 2025. Ce cheminement montre comment une dépendance d’écosystème peut se transformer en relation de contrôle lorsqu’elle achète la couche logicielle qui orchestre les chemins vers ses propres produits.

Au moins 55 millions de dollars levés, mais l’économie de la sortie est inconnue

Les levées de fonds confirmées sont une série A de 25 millions de dollars en avril 2021 et une série B de 30 millions de dollars en 2022. Le total s’élève à au moins 55 millions de dollars. La documentation ne fournit pas de tableau de capitalisation audité, de valorisations, de dettes ou de tours de financement ultérieurs.

La contrepartie de l’acquisition n’a été ni annoncée ni vérifiée de manière indépendante. Sans prix, on ne peut classer de manière fiable le résultat comme une prime stratégique, une acquisition technologique limitée, une acquisition de talents ou une vente en difficulté. Le fait que la technologie ait continué à être intégrée aux produits indique une valeur, mais ne révèle pas le rendement pour les investisseurs ou les fondateurs.

Il ne faut pas attribuer à Prosimo le chiffre d’affaires ou la taille de marché post‑acquisition de Palo Alto Networks. Dès lors qu’une start‑up n’est plus observable séparément, il n’y a pas de ventes, de bénéfices ou de segments de clientèle autonomes à analyser. Un propriétaire de grande taille peut déployer la technologie largement, tout en rendant son économie individuelle moins visible.

L’absence d’annonce formelle d’acquisition est elle‑même significative. Les clients, les employés et les chercheurs s’appuient normalement sur de telles annonces pour connaître le calendrier, le support et les raisons stratégiques. Ici, il a fallu reconstituer l’état à partir des profils professionnels, de l’affichage de la page société et des déclarations ultérieures du fondateur. C’est suffisant pour corriger le statut d’entreprise indépendante, mais pas pour inventer des détails de transaction.

La concurrence venait des socles spécialisés, des clouds et de l’ingénierie interne

Prosimo était en concurrence avec des socles de réseau multicloud spécialisés comme Aviatrix ou Alkira, avec les fournisseurs de réseau d’entreprise et de SASE, avec les services natifs d’AWS, Azure et Google Cloud, et avec les modèles artisanaux où les entreprises utilisent directement l’Infrastructure as Code, les services de transit des fournisseurs cloud, les tables de routage et les pare‑feux. Chaque option résout une partie différente du même problème.

Un contrôleur spécialisé peut offrir un modèle de topologie et de politique unique pour plusieurs fournisseurs. Une conception cloud native réduit la dépendance aux tiers et s’aligne étroitement sur un seul fournisseur. Les services assistés par un opérateur peuvent fournir le transport physique. Un socle SASE ou de sécurité peut unifier connectivité et application de la sécurité. L’ingénierie interne préserve le contrôle, au prix d’un effort humain et d’intégration plus important.

La différenciation de Prosimo tenait à la combinaison du transit applicatif et réseau, de la périphérie distribuée, de l’orchestration cloud native, de la topologie, de la télémétrie et de l’insertion de services. Cette même largeur rendait les comparaisons difficiles. Les acheteurs devaient tester avec les services cloud, les routes, les systèmes d’identité et les configurations de sécurité qu’ils utilisent réellement, plutôt que 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, mais sa technologie doit démontrer sa valeur à l’intérieur de Palo Alto Networks. La comparaison à mener est de savoir si la découverte et l’orchestration de routage intégrées améliorent le déploiement des produits de sécurité de Palo Alto Networks, et si les clients acceptent cette dépendance à la plateforme.

Les services cloud natifs étaient à la fois le socle et une alternative

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN et la mise en réseau Google Cloud offrent aux entreprises de puissantes options natives. Prosimo en dépendait tout en rivalisant avec la possibilité que les clients les exploitent directement.

Cette relation créait une frontière mouvante. À mesure que les fournisseurs cloud ajoutent du routage global, de la segmentation, de l’accès aux services privés et des politiques centrales, certaines fonctions tierces deviennent plus faciles à reproduire en natif. Mais chaque nouveau service natif ajoute en même temps des objets que le contrôleur inter‑cloud doit découvrir et coordonner. Les progrès du cloud pouvaient donc à la fois réduire une partie de la valeur de Prosimo et accroître le besoin de traduction entre fournisseurs.

Le facteur décisif n’était pas seulement technique, mais aussi organisationnel. Une entreprise monocloud dotée d’une forte ingénierie interne peut privilégier les outils natifs. Une entreprise multicloud avec des équipes fragmentées peut valoriser une surface de contrôle unique. Les organisations des secteurs réglementés peuvent apprécier une couche de preuve tierce, tout en s’inquiétant des informations d’identification privilégiées et de la concentration des données.

Aucune architecture n’élimine complètement le verrouillage. Les outils natifs accroissent la dépendance aux API et à la sémantique d’un cloud unique. Un contrôleur inter‑cloud accroît la dépendance au graphe, aux politiques et au logiciel de périphérie. La question utile était de savoir si cette dépendance était visible, portable et adaptée au modèle opérationnel de l’organisation.

Les défaillances pouvaient survenir au niveau du contrôleur, de la périphérie, des API cloud, de l’identité et de la sous‑couche

L’architecture distribuée de Prosimo réduisait la dépendance à un point de concentration unique, mais créait de multiples domaines de défaillance en interaction. Les services centraux pouvaient s’arrêter ou conserver une intention obsolète. La périphérie pouvait tomber en panne ou s’isoler. Les API cloud pouvaient refuser une partie des modifications. Le fournisseur d’identité pouvait tomber en panne. La sous‑couche pouvait perdre de la capacité ou emprunter des chemins inattendus. Un pare‑feu inséré pouvait épuiser ses ressources.

Les défaillances partielles étaient particulièrement difficiles. Un fournisseur acceptait une mise à jour de route, un autre la refusait, de sorte que l’état d’intention du contrôleur et l’état réel du cloud divergeaient. Le trafic pouvait alors emprunter des chemins asymétriques et contourner l’inspection. Un système fiable nécessitait une réconciliation, des opérations idempotentes, des changements progressifs, des états d’erreur explicites et des retours arrière tenant compte du comportement de chaque fournisseur.

Les preuves publiques décrivent une haute disponibilité et une optimisation, mais n’incluent pas de tests d’injection de pannes indépendants, d’historiques complets d’incidents ni d’engagements de niveau de service universels. Les affirmations de résilience doivent donc être rattachées à l’architecture documentée ou à des déploiements nominatifs de clients.

L’acquisition introduit un autre domaine de défaillance: la continuité produit. Les clients doivent savoir quelle console, quelle API, quelle image de périphérie, quel modèle de politique et quelle organisation de support remplacent l’ancien système Prosimo. Même si l’intégration du code réussit techniquement, le risque de migration demeure si les frontières commerciales et opérationnelles restent floues.

Les informations d’identification cloud faisaient du contrôleur un élément du plan de contrôle critique

La découverte et l’orchestration des actifs nécessitaient l’accès aux comptes cloud. Un inventaire en lecture seule peut être obtenu avec des droits restreints, mais la modification des routes, des segments et de l’insertion de services exige des privilèges élevés. Le contrôleur se situait donc à l’intérieur d’un plan de gestion privilégié, même s’il ne possédait pas les charges de travail.

Des informations d’identification compromises pouvaient exposer la topologie et autoriser des modifications étendues. Un bogue logiciel ou une erreur d’opérateur pouvait propager une politique sur plusieurs clouds. Plus la plateforme est utile, plus le risque est grand: plus elle gère de comptes et de services, plus le rayon d’impact potentiel s’élargit.

Les entreprises avaient besoin de rôles à moindre privilège, de la séparation des informations d’identification de découverte et de modification, de l’approbation par plusieurs personnes, d’un audit complet, de la rotation, de la révocation d’urgence et de chemins de restauration ne dépendant pas uniquement du même contrôleur. La documentation publique ne comportant pas d’évaluation de sécurité indépendante complète, ces éléments ne sont pas des garanties produit, mais des contrôles à mettre en place lors du déploiement.

Le graphe de télémétrie était également sensible. Il pouvait révéler des noms d’applications, la structure du réseau, les politiques, les relations utilisateurs, la santé des routes et les schémas de coûts. Les contrôles post‑acquisition doivent préciser où ces données sont stockées, quels produits Palo Alto Networks peuvent y accéder, et comment les anciens droits des clients ont été migrés. À la date de l’enquête, les preuves publiques ne répondent pas à ces questions.

L’acquisition a transféré une couche cloud neutre à l’intérieur d’un socle de sécurité

En tant qu’entreprise indépendante, Prosimo pouvait se positionner comme une couche commune au‑dessus des clouds et des services de sécurité. Une fois propriété de Palo Alto Networks, les incitations changent. La technologie acquise peut faciliter le déploiement des produits Palo Alto Networks, comme VM‑Series. L’expérience intégrée peut s’améliorer, mais de nouvelles questions se posent sur la prise en charge de services d’inspection tiers.

La propriété ne suffit pas à prouver la disparition de la neutralité. La documentation ne fournit pas de liste actuelle des partenaires ni d’architecture produit. Cependant, les questions que les clients doivent poser changent. Il faut vérifier si le contrôleur de routage reste ouvert à plusieurs fournisseurs de sécurité, si les politiques et la télémétrie peuvent être exportées, et si l’optimisation favorise le portefeuille de produits du propriétaire.

Les déclarations d’intégration ont mis l’accent sur l’inspection entrante, sortante et est‑ouest. Cela suggère que la topologie et l’orchestration de Prosimo sont devenues un sous‑ensemble d’un système de déploiement de sécurité. Cela ne prouve pas pour autant que les anciennes fonctions App Transit, accès utilisateur, optimisation des coûts et tous les flux de travail réseau cloud subsistent en tant que fonctionnalités distinctes.

On retrouve ici un schéma courant dans le domaine des infrastructures: une start‑up abstrait un problème de coordination difficile; une grande plateforme l’acquiert parce que cette abstraction augmente l’utilisation et le contrôle de ses produits phares. L’acquéreur obtient un chemin de déploiement; les clients gagnent une intégration, au prix possible d’une perte d’indépendance vis‑à‑vis du fournisseur.

Le tableau de correspondance des produits actuels est la plus grande information manquante

Les sources publiques confirment l’acquisition et l’intégration, mais ne montrent pas complètement comment AXI, Network Transit, App Transit, AIR et Nebula correspondent aux produits ou SKU actuels de Palo Alto Networks. Les dates de fin de support des anciens produits, les procédures de migration et un tableau de continuité fonction par fonction ne sont pas non plus publics.

Cette lacune empêche toute revue de produit actuel. La description rétrospective peut montrer ce que Prosimo a construit et pourquoi c’était important, mais pas quelles fonctionnalités sont aujourd’hui disponibles, sous licence et supportées. Les conseils de déploiement actuels doivent s’appuyer sur la documentation actuelle de Palo Alto Networks, et non sur les annonces passées de Prosimo.

L’absence de correspondance limite aussi l’analyse stratégique. L’absorption complète du graphe de topologie et de la couche d’orchestration diffère d’une utilisation sélective centrée sur la découverte d’actifs et le placement de pare‑feux. Le premier scénario crée un vaste service de contrôle multicloud, le second accélère surtout le déploiement de la sécurité. Les déclarations des cofondateurs confirment la continuité technique, mais ne tranchent pas cette frontière architecturale.

De futurs documents produit, des guides de migration et des études de cas client pourraient dissiper une grande partie de l’incertitude. D’ici là, la formulation exacte est la suivante: selon les cofondateurs, la technologie de Prosimo a été intégrée aux produits Palo Alto Networks, mais le périmètre et le packaging n’ont pas été vérifiés.

Qui contrôle le routage multicloud?

Aucun acteur unique ne contrôle l’intégralité du chemin. L’entreprise détient les comptes, l’intention métier, la conception applicative et les informations d’identification qu’elle accorde. Le contrôleur inter‑cloud peut découvrir la topologie, traduire les politiques, choisir les chemins et modifier l’état de routage natif. Les fournisseurs cloud contrôlent les API, les services de transit, les points de terminaison privés, la dorsale et de nombreux domaines de défaillance. Les opérateurs télécom et de colocation contrôlent les autres segments de transport. Les services de sécurité décident d’autoriser le trafic inspecté.

Prosimo a visé la position intermédiaire la plus stratégique: ne pas posséder la sous‑couche, mais posséder le graphe et la traduction des politiques qui la surmontent. Celui qui contrôle cette couche décide quels actifs sont visibles, comment les segments sont exprimés, où placer la périphérie, quels services inspectent le trafic et quelle télémétrie fait autorité. Cela équivaut à une autorité de routage pratique, même si quelqu’un d’autre possède la fibre.

Après l’acquisition, Palo Alto Networks possède la technologie restante de Prosimo et décide des intégrations, du packaging et du développement. Les fournisseurs cloud gardent leur souveraineté sur leurs propres environnements, et les entreprises peuvent révoquer les informations d’identification et choisir une autre architecture. Mais si la topologie, les politiques et les flux de travail opérationnels sont devenus dépendants du contrôleur, le départ est coûteux.

La réponse est donc hiérarchique, et non absolue. L’entreprise accorde l’autorité, le contrôleur coordonne, les sous‑couches cloud et télécom transportent, et le socle de sécurité applique les politiques. L’histoire de Prosimo montre que la propriété de la couche de coordination peut changer, même quand celle des comptes cloud ou des chemins physiques ne change pas.

Sources principales

Pourquoi Prosimo reste important après l’acquisition

Prosimo a capturé un véritable changement dans l’infrastructure. L’unité de gestion du réseau est passée des équipements et des préfixes aux applications, à l’identité, aux dépendances de services et aux graphes de politiques. Les API cloud natives rendent l’état du réseau programmable, et les périphériques logiciels distribués permettent de déplacer le point d’application des politiques. Un contrôleur qui voit plusieurs clouds peut coordonner des opérations qu’une console de cloud unique ne peut pas réaliser seule.

L’entreprise a aussi montré le coût de cette coordination. Une couche commune exige des informations d’identification privilégiées, une maintenance continue des API, une découverte précise, une traduction sémantique, de la télémétrie et une discipline opérationnelle. Elle réduit la fragmentation, mais crée un nouveau point de concentration. Le même système qui simplifie le routage peut amplifier l’impact d’une seule décision erronée.

L’acquisition par Palo Alto Networks a rendu le problème de contrôle 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 connaît la topologie et peut modifier les routes intervient non seulement dans l’inspection du trafic qu’on lui présente, mais aussi dans la décision de quel trafic parvient à l’inspection et par quel chemin.

Il ne faut donc pas voir Prosimo comme un échec de marque indépendante, ni comme la preuve qu’une seule plateforme a résolu le multicloud. Sa contribution durable est d’avoir défini le graphe inter‑cloud comme un actif d’infrastructure. La question ouverte est de savoir si ce graphe, désormais à l’intérieur d’un grand groupe de sécurité, conserve la transparence, la portabilité et la gouvernabilité nécessaires pour rester digne de confiance.