Résumé

  • Fondée en 2019, Prosimo a levé au moins 55 millions de dollars lors de sa série A de 2021 et de sa série B de 2022 ; chiffre d’affaires audité, valorisation et prix d’acquisition restent inconnus.
  • AXI associait intention, topologie et analytique centrales à des nœuds distribués qui découvraient les actifs cloud, reliaient les applications et inséraient la sécurité sans posséder le réseau physique.
  • L’intégration VM-Series annoncée en juin 2024 a précédé le passage de Prosimo chez Palo Alto Networks vers février 2025 ; aucune source ne précise la date, le prix ni la cartographie actuelle des produits.
  • Le contrôle reste partagé entre entreprises, logiciel d’orchestration, fournisseurs cloud et Palo Alto Networks ; la portabilité de la topologie, des identifiants, des politiques et des routes devient donc le test décisif.

L’entreprise a disparu avant le problème

Il serait inexact de présenter Prosimo comme un fournisseur indépendant actif en 2026. Les parcours professionnels publics montrent ses fondateurs et plusieurs employés rejoignant Palo Alto Networks autour de février 2025. La page de l’entreprise Prosimo est marquée comme ayant été acquise, et l’ancien directeur technique Nehal Bhau a écrit par la suite que sa technologie avait été intégrée aux produits de Palo Alto Networks. Ces éléments établissent un changement de contrôle et la continuité de sa valeur technique.

Ils ne permettent pas de déterminer la date exacte de signature ou de finalisation, la forme juridique ni le prix de la transaction.

Cette correction doit ouvrir le récit, car elle modifie le temps grammatical de chaque affirmation sur les produits. AXI, Network Transit, App Transit, Application-driven Intelligent Results et Nebula étaient des capacités Prosimo documentées pendant la période d’indépendance. Elles ne doivent pas être présentées comme des produits actuels vendus séparément tant que Palo Alto Networks n’a pas publié une cartographie actuelle des produits et du support.

Après une acquisition, une architecture historique peut subsister sous forme de code intégré, de service partagé, de module ou d’actif d’ingénierie interne ; ces situations ne sont pas équivalentes.

La disparition de la marque ne rend pas le problème obsolète. Les entreprises répartissent toujours leurs charges entre Amazon Web Services, Microsoft Azure, Google Cloud, des centres de données privés, des sites de colocation, des plateformes SaaS et des utilisateurs distants. Chaque environnement possède ses propres routes, passerelles, points de terminaison privés, contrôles d’identité, services de sécurité, quotas et règles de facturation. Une entreprise peut être propriétaire de tous ses comptes sans disposer d’une vision unique du trajet suivi par une requête.

L’importance de Prosimo réside dans sa tentative de contrôler cette vue d’ensemble.

L’acquisition constitue donc l’axe narratif, et non une simple note finale. Prosimo avait construit une couche de contrôle transversale capable de découvrir les actifs, d’interpréter le contexte applicatif et d’orienter le trafic vers des services de sécurité. Palo Alto Networks est d’abord apparu comme un partenaire technique dont les pare-feu VM-Series pouvaient être insérés dans ces chemins, avant de devenir propriétaire de la technologie. La frontière qui séparait l’orchestration du routage de l’inspection approfondie s’est déplacée à l’intérieur d’une même plateforme de cybersécurité.

Le routage multicloud est une bataille pour le contexte

Une table de routage peut indiquer si un préfixe est joignable via un prochain saut. À elle seule, elle ne peut pas expliquer quelle application l’utilisateur cherchait à atteindre, si le demandeur est digne de confiance, si un service d’inspection doit voir le trafic, si un point de terminaison privé est disponible, si un chemin cloud coûte davantage qu’un autre ou si la transaction échoue après l’arrivée du paquet. Les opérations multicloud transforment ces questions en un problème de contrôle partagé.

La thèse de Prosimo était que l’autorité de routage devait s’appuyer sur davantage que la joignabilité de couche 3. Son logiciel tentait de combiner inventaire cloud, état du réseau, identité de l’application, identité de l’utilisateur, risque, performance et télémétrie transactionnelle. Ce contexte permettait d’exprimer des politiques telles que connecter une application définie, isoler un segment, choisir un point d’entrée ou diriger un trafic sélectionné vers un pare-feu. La valeur ne venait pas de l’invention d’un nouveau chemin de fibre, mais de la décision sur la manière d’assembler des chemins et services existants.

Cette distinction explique l’expression « application experience infrastructure ». Elle plaçait la requête applicative au-dessus de chaque objet réseau. Un VPC, un VNet, un sous-réseau, un hub de transit ou un lien privé devenait une composante d’un chemin de bout en bout plutôt que l’objet final de gestion. L’approche situait aussi le produit au croisement de 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 étendue fonctionnelle créait à la fois une occasion et une ambiguïté. Un produit utilisé par plusieurs équipes peut résoudre des défaillances de coordination dont aucune équipe n’est seule responsable. Il peut aussi être difficile à évaluer, car les équipes réseau, sécurité, cloud, applicatives et financières n’emploient pas les mêmes critères de réussite. Prosimo devait démontrer qu’un modèle transversal améliorait les opérations sans devenir une nouvelle couche privilégiée dont les erreurs toucheraient tous les environnements.

Ce qu’était Prosimo — et ce qui subsiste

Prosimo était une société privée de logiciels de réseau cloud fondée en 2019 dans la baie de San Francisco. Ramesh Prabagaran en était le cofondateur et directeur général, tandis que Nehal Bhau occupait le poste de cofondateur et directeur technique pendant la période d’indépendance. Des historiques publics identifient également Linus Aranha et Pradeep Aragonda dans des fonctions fondatrices ou de direction de l’ingénierie, mais leurs titres précis doivent rester liés à des biographies datées.

Sa plateforme principale s’appelait Application eXperience Infrastructure, généralement abrégée AXI. AXI associait une couche logicielle centrale pour l’intention, la topologie, l’analyse et l’orchestration à des AXI Edges distribués dans les régions cloud, les environnements de colocation ou des infrastructures sur site adjacentes. L’offre a ensuite été organisée sous le nom Full-Stack Cloud Transit, Network Transit et App Transit prenant en charge des classes différentes de connectivité. AIR analysait la télémétrie et produisait des indications opérationnelles ; Nebula a ajouté une interface conversationnelle en 2024.

Prosimo n’était pas un opérateur cloud. L’entreprise ne possédait pas une dorsale mondiale en fibre reliant toutes les régions. Les chemins pouvaient emprunter les dorsales des fournisseurs de cloud, l’internet public, des circuits directs, des liaisons de colocation et les réseaux de l’entreprise. Elle n’était pas non plus un fournisseur de pare-feu au même sens que Palo Alto Networks. Dans l’intégration de 2024, son rôle consistait à découvrir, segmenter et orienter ; VM-Series fournissait l’inspection approfondie de sécurité.

Après l’acquisition, la description la plus prudente est celle d’un « héritage technologique ». La déclaration ultérieure sur l’intégration met en avant la découverte d’actifs multicloud et le déploiement plus rapide de pare-feu logiciels pour les flux entrants, sortants et est-ouest. Elle prouve que des composantes importantes de Prosimo ont survécu. Elle ne prouve pas que tout le catalogue AXI historique, son mode de commercialisation ou son modèle de support ont continué sans changement.

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

L’équipe fondatrice possédait une expérience des réseaux à grande échelle, de la livraison applicative et de l’infrastructure cloud. Prosimo provenait aussi de l’écosystème plus large de fondateurs et d’ingénieurs associé à Viptela, société qui avait contribué à établir le SD-WAN comme catégorie d’entreprise. Le problème suivant était différent. Le SD-WAN pouvait simplifier la relation entre les succursales et les réseaux ou applications, mais il ne créait pas un modèle d’exploitation 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 connectivité privée vers un centre de données et d’une inspection de sécurité placée à certaines frontières. Chaque dépendance peut être représentée par un objet natif différent. L’équipe réseau voit des préfixes et des hubs de transit ; l’équipe cloud voit des comptes et des ressources ; le propriétaire de l’application voit des domaines et des transactions ; l’équipe sécurité voit des zones et des politiques d’inspection.

Prosimo partait de la requête plutôt que de la succursale. La question utile était de savoir comment un utilisateur ou une charge de travail devait atteindre une application avec un niveau acceptable de sécurité, de performance, de disponibilité et de coût. Ce cadrage transformait l’objet du routage : du seul préfixe de destination vers une transaction porteuse d’identité et de contexte applicatif. Il obligeait aussi la plateforme à collecter et entretenir bien plus d’informations qu’un routeur classique.

Le moment était favorable. AWS, Azure et Google Cloud enrichissaient leurs services natifs de transit et de connectivité privée. Les entreprises pouvaient construire des réseaux sophistiqués chez chaque fournisseur, mais les API, objets et modèles de politique demeuraient spécifiques. L’occasion pour Prosimo consistait à coordonner ces services sans contraindre chaque client à les remplacer par une dorsale propriétaire distincte.

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

Prosimo a été fondée en 2019, mais son lancement public n’a été annoncé que le 6 avril 2021. General Catalyst a mené une série A de 25 millions de dollars au moment du lancement. L’investisseur présentait l’occasion comme la fourniture d’une expérience applicative à travers plusieurs clouds, en accord avec la volonté des fondateurs de définir une catégorie allant au-delà de la connectivité classique des succursales.

Le lancement plaçait l’entreprise sur un marché dense et encore mal défini. Les fournisseurs de cloud facilitaient la consommation de leurs propres services réseau. Les vendeurs de SD-WAN et de SASE étendaient leurs politiques aux environnements cloud. Les fournisseurs de livraison applicative pouvaient optimiser les requêtes, tandis que les sociétés de cybersécurité pouvaient les inspecter. La proposition de Prosimo reposait sur la réunion de ces fonctions dans une architecture orientée cloud, sans prétendre remplacer tout le système environnant.

Le financement a permis de développer des intégrations, des edges logiciels, des analyses, une organisation commerciale et des relations de partenariat. Il ne prouvait ni l’adéquation au marché, ni l’échelle du chiffre d’affaires, ni une différenciation durable. Aucun chiffre d’affaires audité, revenu récurrent annuel, nombre de clients ou valorisation n’est publié dans les éléments fournis. Le financement montre l’engagement d’investisseurs envers une thèse, pas un compte rendu complet de la performance opérationnelle.

En 2022, Prosimo a réalisé une série B de 30 millions de dollars, présentée comme sursouscrite. L’addition des deux tours clairement identifiés donne un total vérifié d’au moins 55 millions de dollars. Certaines bases de données peuvent afficher davantage lorsqu’elles dupliquent des annonces ou des enregistrements liés ; ces totaux ne doivent pas être employés sans résolution des événements sous-jacents.

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

L’architecture AXI répartissait le travail entre une couche centrale de contrôle et d’analyse et des edges logiciels distribués. La couche centrale détenait 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. Les AXI Edges étaient déployés près des charges ou des utilisateurs pour appliquer les politiques sans obliger chaque chemin à passer par un hub physique éloigné.

Cette séparation rappelle d’autres systèmes définis par logiciel, mais les objets étaient propres au cloud et conscients des applications. Le contrôleur avait besoin d’un accès aux comptes cloud et à leurs API, tandis que l’edge devait se connecter aux services natifs de transit, aux réseaux de charges, aux points de terminaison privés ou aux chemins externes. L’autorité de la plateforme venait de la combinaison de ces vues : intention globale au-dessus des clouds et exécution locale près du trafic concerné.

L’architecture créait également une frontière de déploiement concrète. Chaque edge consommait des ressources cloud, nécessitait une conception de haute disponibilité et devait être mis à jour, surveillé et sécurisé. La couche de contrôle exigeait des identifiants disposant de privilèges suffisants pour découvrir les actifs et modifier l’état du réseau. L’entreprise gagnait un flux de travail commun, mais ajoutait un système de gestion dont la disponibilité et la fiabilité devenaient essentielles pour la joignabilité de la production.

Prosimo employait parfois le vocabulaire du « réseau cloud autonome ». Les preuves étayent l’automatisation, les recommandations et l’orchestration par API. Elles ne décrivent pas un réseau indépendant des politiques humaines, des services des fournisseurs de cloud ou du transport sous-jacent. Les opérateurs définissaient toujours l’intention, approuvaient les accès, traitaient les exceptions et restaient responsables du résultat.

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

Un AXI Edge pouvait être déployé dans un VPC ou un VNet cloud, un environnement de colocation ou une infrastructure adjacente. Le guide technique d’AWS montrait un VPC d’edge relié aux VPC de charges par Transit Gateway, avec chaînage optionnel d’un pare-feu et accès depuis des utilisateurs distants ou des sites sur site. L’exécution de Prosimo se trouvait ainsi dans la topologie cloud plutôt qu’à un périmètre d’entreprise éloigné.

Le placement influençait plus que la latence. Il déterminait le point d’entrée du trafic dans le domaine de politique, la dorsale cloud ou le chemin internet emprunté, l’endroit du chiffrement et de l’inspection, ainsi que la télémétrie accessible. Un edge mal placé pouvait créer un détour ou un coût ; un placement adapté pouvait raccourcir le chemin ou maintenir le trafic près de la charge.

La distribution multipliait les domaines de panne. La capacité, les versions logicielles, la conception des zones cloud, la convergence des routes et les autorisations pouvaient varier selon les régions. La haute disponibilité ne se résumait pas à deux instances : le contrôleur, les tables de routage cloud, les services de sécurité et les chemins de retour devaient eux aussi s’accorder sur l’état de basculement.

L’edge faisait donc partie d’un système d’exploitation plus large. Sa valeur dépendait de la cohérence entre la découverte d’actifs, la topologie, les politiques, l’analyse et l’environnement cloud. Le traiter comme une appliance virtuelle autonome ferait perdre de vue l’architecture que Prosimo cherchait à vendre.

Le transport sous-jacent appartenait toujours à quelqu’un d’autre

Prosimo coordonnait le transport sans posséder le chemin physique. Une connexion applicative pouvait utiliser la dorsale d’AWS ou d’un autre cloud, l’internet public, Direct Connect ou ExpressRoute, un service de colocation, un circuit d’opérateur ou le réseau de l’entreprise. La plateforme pouvait sélectionner et orchestrer les options disponibles ; elle ne pouvait pas supprimer la latence, la perte de paquets, les domaines de panne ou les règles tarifaires créés par ces fournisseurs.

Cette frontière est essentielle pour évaluer les promesses de performance. Un contrôleur peut choisir un meilleur chemin observé ou rapprocher le point d’entrée de l’utilisateur. Il ne peut garantir qu’un opérateur ne connaîtra pas de panne, qu’une région cloud restera disponible ou qu’une dépendance externe répondra rapidement. L’expérience applicative inclut aussi le DNS, le traitement des serveurs, le stockage, le comportement du navigateur et les services tiers, hors de l’autorité complète du contrôleur réseau.

L’absence de dorsale propriétaire n’était pas uniquement une faiblesse. Elle permettait à Prosimo d’utiliser une infrastructure déjà achetée par les entreprises et de profiter des investissements des fournisseurs de cloud. L’entreprise pouvait atteindre de nouvelles régions sans construire de fibre et coordonner des systèmes natifs comme AWS Cloud WAN. En échange, elle dépendait de la stabilité des API, des quotas, des conditions commerciales et des sémantiques propres à chaque fournisseur.

La proposition concernait donc le contrôle opérationnel, et non la propriété physique. Prosimo cherchait à faire fonctionner des underlays hétérogènes comme un système géré unique tout en conservant leurs avantages natifs. La question de savoir si cette abstraction réduisait le verrouillage ou le déplaçait dépendait de la portabilité des politiques, de la topologie et du déploiement des edges.

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

Network Transit se concentrait sur les VPC, VNet, sous-réseaux, régions, sites et segments. Il coordonnait les services natifs de transit et les objets de routage afin que les équipes puissent construire la connectivité par un flux de travail commun, plutôt que de configurer chaque fournisseur séparément. Le produit répondait au besoin réseau classique : une source ou un segment doit atteindre une destination par un chemin autorisé.

Il ne prétendait pas que les différences entre clouds avaient disparu. AWS, Azure et Google Cloud exposent des objets, quotas et comportements de routage différents. Les espaces d’adresses qui se chevauchent, les chemins asymétriques, les points de terminaison privés et les limites de services exigeaient toujours de l’ingénierie. Prosimo pouvait normaliser des opérations communes et afficher les relations, mais les systèmes sous-jacents conservaient leurs contraintes.

Network Transit portait aussi la segmentation. Des domaines de routage et des politiques pouvaient séparer des environnements ou limiter la joignabilité. Le contrôleur devait comprendre où un segment existait à travers les clouds et comment les objets natifs matérialisaient cette frontière. Une politique écrite une seule fois pouvait encore produire plusieurs changements spécifiques aux fournisseurs.

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

App Transit faisait de l’application un objet de routage

App Transit étendait le modèle au-delà des sous-réseaux. Il pouvait tenir compte du domaine applicatif, de l’identité, du type de requête, de la santé transactionnelle, du risque et de la performance pour décider comment un utilisateur ou une charge atteignait un service. C’était la tentative la plus claire de Prosimo pour se distinguer d’un routeur cloud classique.

La vue applicative était utile parce que les services modernes ne sont pas toujours représentés par des adresses fixes. Les plateformes managées, les points de terminaison SaaS et les composants distribués peuvent changer alors que l’identité du service reste stable. Une politique faisant référence à l’application ou à l’utilisateur peut durer plus longtemps qu’une règle construite uniquement autour d’adresses et de ports.

Le modèle exigeait une découverte exacte. Le contrôleur devait savoir quels domaines et points de terminaison appartenaient à une application, quelles dépendances étaient nécessaires et quelles affirmations du fournisseur d’identité étaient fiables. Une cartographie périmée pouvait orienter la requête vers le mauvais chemin ou appliquer une mauvaise règle de sécurité. L’abstraction applicative ne supprimait pas la nécessité de comprendre l’état du réseau ; elle ajoutait une couche sémantique au-dessus.

La réunion de Network Transit et App Transit reconnaissait la coexistence des deux mondes dans l’entreprise. Les systèmes hérités, sous-réseaux privés et contrôles IP restent présents, tandis que les applications récentes reposent sur les domaines, l’identité et les services managés. Full-Stack Cloud Transit était le nom donné à l’exploitation conjointe de ces modèles, sans obliger l’un à remplacer l’autre.

L’identité élargissait la décision de routage et le périmètre de confiance

L’accès conscient des applications nécessitait une intégration de l’identité. La plateforme pouvait utiliser le contexte d’un utilisateur ou d’une charge pour décider si une connexion devait être établie et selon quel chemin. Cela soutenait une politique de type zero trust dans laquelle l’emplacement ne suffisait pas à prouver l’autorisation.

L’identité améliorait la précision, mais ajoutait une dépendance. La politique de route ou d’application reposait désormais sur le fournisseur d’identité, ses affirmations, l’état de session et les données de groupe. Un chemin pouvait échouer parce que l’authentification était indisponible ou qu’un attribut avait changé, alors que les routeurs et les edges restaient sains. Le diagnostic devait franchir la frontière entre réseau et gestion des identités.

Le contrôleur devenait aussi un point de concentration pour des informations sensibles. Il pouvait détenir topologie, relations applicatives, attributs d’utilisateurs, signaux de risque et résultats de politiques. Ce jeu de données améliorait le diagnostic et l’optimisation, tout en aggravant les conséquences d’un accès non autorisé. Le moindre privilège, la conservation, l’audit et la séparation des tâches relevaient donc de l’architecture, pas d’une simple administration.

L’approche de Prosimo illustre une évolution plus générale : le routage et l’accès dépendent de plus en plus de l’identité et de la sémantique applicative. Plus une plateforme voit de contexte, plus ses décisions peuvent être utiles — et plus son autorité doit être gouvernée avec soin.

La découverte d’actifs créait le graphe dont dépendaient les décisions

Un contrôleur transversal ne peut gouverner ce qu’il ne voit pas. Prosimo développait une découverte d’actifs cloud et des cartes représentant VPC, VNet, sous-réseaux, applications, connectivité et relations de sécurité. Ces vues servaient à l’intégration, à la conception, au diagnostic et à la politique.

La découverte était stratégique, car les environnements cloud évoluent hors des processus centraux du réseau. Les équipes applicatives peuvent créer des comptes, réseaux, points de terminaison et services managés par leur propre automatisation. Un diagramme tenu à la main devient obsolète. Un inventaire fondé sur les API peut fournir un graphe plus récent, mais sa complétude dépend toujours des comptes couverts, des autorisations, des parsers et des API des fournisseurs.

Le graphe n’était pas seulement documentaire. Il constituait la structure à partir de laquelle le routage, la segmentation, l’insertion de services et l’optimisation pouvaient être calculés. Si un actif ou une dépendance manquait, toutes les conclusions construites au-dessus pouvaient être fausses. La topologie avait donc besoin d’une provenance : date de collecte, compte source, régions couvertes et éventuels échecs de requête.

Ce graphe contribue aussi à expliquer l’acquisition. Palo Alto Networks crée de la valeur de sécurité lorsqu’il sait où se trouvent les charges et les chemins de trafic. Un système capable de découvrir les actifs et de modifier les routes réduit la distance entre l’achat d’un pare-feu logiciel et son bon placement. La déclaration ultérieure de Nehal Bhau sur l’intégration insistait précisément sur 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 edges en recommandations

Application-driven Intelligent Results, ou AIR, analysait la télémétrie collectée par les AXI Edges. Le guide d’AWS décrivait une visibilité sur le temps aller-retour, le temps de traitement, le temps de réponse applicatif, le type de transaction, le risque et les résultats des politiques. La plateforme pouvait corréler les observations de l’utilisateur, du réseau et de l’application au lieu de présenter des compteurs isolés.

Cette corrélation répondait à un problème opérationnel courant. Une transaction lente peut être causée par le chemin utilisateur, l’edge, la dorsale cloud, un service de sécurité ou l’application. Une vue transversale peut réduire le temps de recherche par rapport à des consoles séparées. Elle peut également soutenir des recommandations sur le chemin, le placement, le risque ou le coût.

La qualité d’une recommandation dépendait de la couverture de la télémétrie et du modèle d’interprétation. Un edge ne voyait que le trafic qui le traversait. Les dépendances externes de l’application et certaines conditions internes au fournisseur pouvaient rester invisibles. Une recommandation pouvait être utile sans démontrer la cause racine.

La télémétrie avait aussi une valeur de gouvernance. Les observations historiques pouvaient expliquer pourquoi une route ou une politique avait changé. Elles pouvaient également exposer des usages applicatifs et des comportements d’utilisateurs sensibles. Les informations publiques ne donnent pas une description complète de la conservation ou de la gouvernance des données après l’acquisition ; ces questions restent donc dans le champ de la diligence client.

AWS a fourni l’implémentation publique la mieux documentée

Les travaux de Prosimo avec AWS constituent les preuves techniques publiques les plus solides. L’entreprise s’est intégrée à AWS Transit Gateway, Cloud WAN, PrivateLink et au workflow Marketplace for Containers Anywhere. AWS a publié un guide sur le placement des AXI Edges, l’intégration des applications, l’identité, la sécurité et l’optimisation.

AWS Cloud WAN était particulièrement important. Il fournissait une dorsale native et un service de segmentation que Prosimo pouvait orchestrer plutôt que remplacer. L’architecture montrait le modèle coopératif : AWS possédait le réseau natif et l’infrastructure mondiale ; Prosimo apportait l’intention multicloud, le contexte applicatif, le logiciel d’edge et les analyses.

Le workflow Marketplace simplifiait la première étape en fournissant AXI Edge par un canal approuvé. Il ne supprimait pas le travail ultérieur sur les autorisations des comptes, la conception des routes, la haute disponibilité, la capacité et les opérations. L’automatisation du jour zéro peut réduire la friction d’installation tout en laissant intact le problème de contrôle à long terme.

Une référence nommée à Flexport soutenait le cas AWS Cloud WAN dans les documents de l’entreprise. Elle montre qu’un client d’entreprise acceptait de recommander l’architecture, mais ne constitue pas un audit indépendant de l’échelle, des économies ou de la disponibilité. Les citations de clients doivent servir d’exemples d’adoption, pas de preuve universelle de performance.

Azure et Google Cloud complétaient la promesse multicloud

Prosimo prenait également en charge Microsoft Azure et Google Cloud. Ses documents évoquaient l’orchestration autour d’Azure Virtual WAN et des objets de réseau et de service privé de Google Cloud. L’objectif était de présenter un modèle d’exploitation unique tout en laissant le réseau natif de chaque fournisseur en place.

La prise en charge ne prouve pas une parité de fonctions. Les API cloud mûrissent à des rythmes différents et des noms de produits similaires peuvent masquer des sémantiques distinctes. Une route, un segment, un point de terminaison privé ou une insertion de service peut nécessiter un traitement propre au fournisseur. Les sources fournies ne reconstituent pas une matrice de parité fonction par fonction pour chaque région et version.

L’abstraction multicloud est donc un système de traduction. Elle peut normaliser l’intention commune et les workflows, mais doit préserver les détails qui affectent la sécurité, le coût et les pannes. Une plateforme devient dangereuse lorsque l’interface paraît uniforme alors que les différences d’implémentation sont cachées aux opérateurs.

Le même principe vaut après l’acquisition. Palo Alto Networks peut utiliser le graphe commun pour placer la sécurité entre plusieurs clouds, mais les fournisseurs conservent le contrôle des objets natifs matérialisant le chemin. Posséder l’orchestration ne signifie pas posséder l’underlay cloud.

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

En 2023, Prosimo décrivait des workflows de conception, construction, dépannage et gestion des réseaux multicloud. Le produit allait au-delà d’un tunnel ou d’une passerelle. La découverte d’actifs soutenait la conception ; l’orchestration créait la connectivité ; les cartes et la télémétrie aidaient au diagnostic ; les politiques et l’historique soutenaient la gestion continue.

Ce cadrage élargissait l’acheteur potentiel. Un ingénieur réseau pouvait exploiter la topologie et l’analyse de chemin ; une équipe de plateforme cloud intégrer des comptes et services ; une équipe sécurité revoir la segmentation et l’inspection ; une équipe de migration planifier les changements ; une équipe FinOps examiner les conséquences de route et d’egress. La valeur augmentait lorsque plusieurs groupes utilisaient les mêmes preuves.

Des preuves communes peuvent aussi provoquer des conflits de gouvernance. Une plateforme centrale peut révéler que la configuration native d’une équipe cloud diffère de la politique d’entreprise. L’organisation doit décider quel système fait autorité et qui peut approuver la correction. Le logiciel ne résout pas seul cette question institutionnelle.

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 placements d’edges et les intégrations d’automatisation, le remplacer exige plus que déplacer un circuit. Le client doit exporter ou reconstruire son modèle d’exploitation. Prosimo vendait une réduction de la fragmentation cloud tout en créant la possibilité d’une dépendance au contrôleur.

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

Prosimo présentait une segmentation des couches 3 à 7. Au niveau réseau, domaines de routage et segments déterminaient quels sous-réseaux ou sites pouvaient communiquer. Aux niveaux supérieurs, l’identité de l’application, le contexte utilisateur et les propriétés de la transaction pouvaient préciser la règle.

Ce modèle pouvait réduire l’écart entre zone réseau et politique applicative. Un service métier pouvait être autorisé alors qu’une joignabilité large entre sous-réseaux restait bloquée. À l’inverse, un chemin réseau valide pouvait être refusé parce que l’identité ou le contexte applicatif échouait.

Cela ne transformait pas Prosimo en pare-feu de nouvelle génération complet. L’intégration avec Palo Alto Networks séparait les responsabilités : Prosimo orchestrait les routes, la segmentation et l’insertion de services ; VM-Series réalisait l’inspection approfondie. La distinction est importante, car l’orientation des politiques et l’application de la sécurité échouent de manières différentes.

Un segment n’est efficace que si tous les chemins pertinents sont représentés. Une route inconnue, une exception native ou une insertion défaillante peut contourner le contrôle. L’assurance exige donc de comparer politique déclarée, état du fournisseur et trafic observé, et non de faire confiance à l’écran du contrôleur seul.

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

La sécurité cloud doit décider où se déroule l’inspection. Des pare-feu centralisés simplifient parfois la politique et réduisent le nombre d’instances, mais peuvent créer des détours, une concentration et des pressions de capacité. Des pare-feu distribués restent proches des charges et réduisent certaines distorsions, mais multiplient le déploiement, les licences, les mises à jour et les opérations de politique.

Prosimo soutenait les deux modèles dans l’intégration VM-Series. La politique pouvait diriger un trafic sélectionné vers un point central ou vers des pare-feu distribués dans les VPC applicatifs. Le contrôleur mettait à jour les routes environnantes tandis que Palo Alto Networks fournissait l’inspection.

L’architecture rendait l’orchestration du routage précieuse pour un fournisseur de sécurité. Un pare-feu logiciel ne protège pas le trafic qui ne le traverse jamais. La découverte, le placement et les changements de routes réduisent la friction entre l’achat de capacité de sécurité et son insertion dans un chemin actif. Il s’agit d’une raison stratégique plausible pour l’absorption de la technologie Prosimo par Palo Alto Networks.

Elle élargissait aussi le rayon d’impact du contrôleur. Une mauvaise politique peut contourner l’inspection, créer une boucle, produire un routage asymétrique ou interrompre l’application. Les contrôles de santé, les changements par étapes, la simulation, l’audit et le retour arrière sont nécessaires, car une erreur d’insertion est à la fois un incident réseau et un incident de sécurité.

Le partenariat de 2024 ne doit pas être transformé rétroactivement en acquisition

Prosimo et Palo Alto Networks ont annoncé l’intégration de VM-Series le 12 juin 2024. Le communiqué décrivait une solution technique et commerciale conjointe. Il ne disait pas que Palo Alto Networks avait acquis Prosimo. Employer cette annonce comme preuve de propriété confondrait deux événements distincts.

Le partenariat a néanmoins créé un pont. Prosimo pouvait montrer comment son système de routes et de politiques facilitait le déploiement de VM-Series entre plusieurs clouds. Palo Alto Networks pouvait évaluer la technologie dans une intégration réelle avant la transition ultérieure. Les sources publiques ne décrivent pas le processus d’acquisition ; affirmer que le partenariat constituait formellement une étape préparatoire serait spéculatif.

Au début de 2025, les historiques des fondateurs et employés avaient changé. La page de l’entreprise a ensuite affiché un statut acquis. À la fin de 2025, Bhau a déclaré que la technologie était entièrement intégrée aux produits de Palo Alto Networks. Ces éléments soutiennent ensemble la conclusion d’une acquisition, tout en laissant les mécanismes juridiques non résolus.

Cette séquence est importante pour la précision éditoriale et pour les clients. Un partenariat signifie deux fournisseurs, deux structures de support et une frontière d’intégration définie. Une acquisition peut déplacer les feuilles de route, les données, les contrats et l’autorité dans une seule entreprise. La transition change davantage que la marque, même si le chemin technique paraît d’abord similaire.

Nebula transformait le graphe topologique en interface conversationnelle

Prosimo a introduit Nebula en février 2024 dans une AI Suite pour le réseau multicloud. L’assistant devait répondre en langage naturel à des questions sur les réseaux qui se chevauchent, les coûts, la santé des routes, les violations de politique de sécurité et d’autres conditions représentées dans le graphe et la télémétrie.

L’actif utile n’était pas l’interface linguistique seule, mais le contexte multicloud structuré sous-jacent. Un modèle général ne peut diagnostiquer une route privée ou un segment qu’il ne voit pas. Nebula pouvait s’appuyer sur l’inventaire, la topologie, les politiques et les observations déjà collectées. L’investissement antérieur dans un graphe commun devenait ainsi pertinent pour l’AIOps.

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

Prosimo avançait des améliorations possibles, notamment une réduction de 60 à 80 % du temps moyen de résolution et de plus de 60 % du coût du réseau cloud. Ces chiffres étaient des affirmations de l’entreprise dans une annonce de produit. Aucune méthodologie indépendante ni base client fournie ne démontre qu’ils s’appliquent en général. Ils peuvent être cités comme bénéfices proposés par Prosimo, non comme faits mesurés du marché.

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

La même annonce de 2024 présentait l’architecture comme utile aux charges d’intelligence artificielle. Des systèmes d’IA distribués peuvent nécessiter un accès privé aux données, des connexions entre clouds et centres de données, des contrôles de conformité et un routage tenant compte du comportement applicatif. Ces besoins correspondaient au modèle d’actifs, de politiques et de chemins déjà développé.

L’étiquette ne changeait pas l’underlay. Prosimo dépendait toujours des réseaux cloud, des opérateurs et de l’infrastructure des clients. L’entreprise ne fournissait ni calcul GPU ni logiciel de développement de modèles. Son rôle potentiel était la connectivité et la sécurité autour de données et services distribués.

Le positionnement IA était logique, car la valeur d’une topologie transversale augmente avec la distribution des données et des services. Il constituait aussi une catégorie marketing introduite peu avant la fin de l’indépendance. Les éléments fournis n’établissent ni revenu séparé lié à l’IA, ni déploiements de production nommés, ni résultats audités.

Le point durable est que la télémétrie multicloud peut alimenter des opérations assistées par machine. La question actuelle est de savoir si Palo Alto Networks a conservé ce contexte et comment il expose la capacité. Les sources publiques disponibles à la date de coupure ne donnent pas la réponse complète.

Le modèle commercial vendait du logiciel au-dessus d’une infrastructure tierce

Prosimo fonctionnait comme une entreprise de logiciels par abonnement et de services, non comme un opérateur. Les clients déployaient des AXI Edges dans leurs environnements et reliaient leurs comptes cloud à la couche de contrôle. Les revenus auraient dépendu de licences ou abonnements, du support, de services professionnels et des canaux, mais les prix et métriques contractuelles exacts ne sont pas publiés dans les éléments fournis.

Le modèle pouvait croître sans posséder de fibre. Une plateforme logicielle pouvait coordonner de nombreuses régions et de nombreux environnements. Il n’est toutefois pas possible d’en déduire l’économie brute. Le support des API fournisseurs, le cycle de vie des edges, les intégrations de sécurité et le déploiement en entreprise peuvent être coûteux, tandis que les ressources cloud consommées par les edges peuvent être payées directement par le client.

Prosimo utilisait les marketplaces, les partenaires d’intégration, les canaux et des références clients pour atteindre les entreprises. Ces relations ne sont pas équivalentes. Une présence sur une marketplace prouve un canal d’achat et de déploiement. Une intégration technique prouve que deux systèmes peuvent fonctionner ensemble dans des conditions définies. Une citation client fournit une référence. Aucune ne révèle à elle seule le nombre de clients payants ou le revenu récurrent.

La largeur de l’offre pouvait compliquer la vente. Les équipes réseau, sécurité, cloud et applicatives pouvaient toutes en bénéficier, mais la propriété budgétaire pouvait rester floue. Le produit avait besoin d’un acheteur prêt à financer une couche de contrôle commune plutôt qu’à laisser chaque cloud et chaque équipe fonctionner séparément.

Partenaires, clients et investisseurs occupaient des positions distinctes

Amazon Web Services était à la fois un fournisseur de l’infrastructure sous-jacente et un partenaire d’intégration commerciale. Azure et Google Cloud étaient des environnements pris en charge. Les fournisseurs d’identité apportaient le contexte d’authentification. Les pare-feu fournissaient l’inspection. Les services de colocation et d’opérateurs pouvaient héberger ou relier les edges. Les partenaires de canal pouvaient concevoir et exploiter les déploiements.

Flexport figurait comme référence client dans les documents AWS Cloud WAN. La référence montre un intérêt d’entreprise pour l’architecture, mais les éléments ne donnent pas l’étendue, la durée ou la valeur commerciale complète du déploiement. Elle ne doit pas servir de substitut au nombre total de clients.

General Catalyst a mené la série A et participé à la gouvernance en tant qu’investisseur. Des investisseurs liés à WRVI ou Celesta apparaissaient dans les documents, tandis que des messages ultérieurs évoquaient d’autres participations connues, dont un nom lié à BlackRock dont le véhicule exact n’a pas été résolu. Ces éléments indiquent une base de financement bien connectée, non une table de capitalisation complète.

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

Au moins 55 millions de dollars ont été levés ; l’économie de la sortie reste inconnue

Le financement vérifié comprend une série A de 25 millions de dollars en avril 2021 et une série B de 30 millions de dollars en 2022, soit au moins 55 millions. Aucun tableau de capitalisation audité, valorisation, dette ou tour ultérieur n’est disponible dans les éléments fournis.

La contrepartie de l’acquisition n’a pas été divulguée ou vérifiée indépendamment. Sans prix, il est impossible de qualifier correctement l’opération de prime stratégique, d’achat technologique modeste, d’acqui-hire ou de vente en difficulté. La poursuite de l’intégration soutient l’idée d’une valeur technologique, mais ne révèle pas le rendement des investisseurs ou fondateurs.

Le chiffre d’affaires et l’échelle de Palo Alto Networks ne doivent pas être attribués à Prosimo après l’acquisition. La start-up ayant cessé d’être observable séparément, il n’existe plus de revenu, bénéfice ou segment client autonome à analyser. Un propriétaire plus grand peut diffuser davantage la technologie tout en rendant son économie individuelle moins visible.

L’absence d’annonce formelle d’acquisition est elle-même pertinente. Clients, employés et chercheurs utilisent normalement ces communiqués pour déterminer calendrier, support et logique stratégique. Ici, le statut doit être reconstruit à partir des parcours professionnels, d’une étiquette sur la page de l’entreprise et d’une déclaration ultérieure du fondateur. C’est suffisant pour corriger le statut, insuffisant pour inventer le détail de la transaction.

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

Prosimo concurrençait des plateformes spécialisées comme Aviatrix et Alkira, des fournisseurs de réseaux d’entreprise et de SASE, ainsi que les services natifs d’AWS, Azure et Google Cloud. Elle affrontait aussi un modèle interne dans lequel l’entreprise utilise directement l’infrastructure as code, les services de transit, les tables de routage et les pare-feu des fournisseurs. Ces alternatives résolvaient des portions différentes du même problème.

Un contrôleur spécialisé pouvait fournir une seule topologie et un seul modèle de politique. Une conception cloud native pouvait réduire la dépendance à un tiers et s’aligner étroitement sur un fournisseur. Un service porté par un opérateur pouvait fournir le transport physique. Une plateforme SASE ou de sécurité pouvait combiner connectivité et enforcement. L’ingénierie interne pouvait préserver le contrôle au prix d’un effort de personnel et d’intégration.

La différenciation de Prosimo réunissait transit applicatif et réseau, edges distribués, orchestration native, topologie, télémétrie et insertion de services. Cette étendue rendait aussi les comparaisons difficiles. Les acheteurs devaient tester les clouds, routes, identités et modèles de sécurité qu’ils comptaient réellement utiliser, plutôt que de comparer des étiquettes de catégorie.

L’acquisition modifie le cadre concurrentiel. Prosimo n’a plus à gagner en tant qu’entreprise autonome ; sa technologie doit prouver sa valeur au sein de Palo Alto Networks. La comparaison pertinente devient la capacité de la découverte et de l’orchestration intégrées à améliorer le déploiement des produits de sécurité Palo Alto, et l’acceptation par les clients de la dépendance qui en résulte.

Les services natifs des clouds étaient à la fois fondation et substitut

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN et les services réseau de Google Cloud donnaient aux entreprises des options natives puissantes. Prosimo dépendait de ces services et affrontait la possibilité que les clients les exploitent directement.

Cette relation créait une frontière mouvante. Lorsqu’un fournisseur ajoutait du routage mondial, de la segmentation, des services privés ou une politique centrale, certaines fonctions tierces devenaient plus faciles à reproduire. En même temps, chaque nouveau service natif ajoutait un objet que le contrôleur transversal pouvait découvrir et coordonner. Les progrès des clouds pouvaient réduire une partie de la valeur de Prosimo tout en augmentant le besoin de traduction entre fournisseurs.

Le facteur décisif était organisationnel autant que technique. Une entreprise centrée sur un cloud et disposant d’une forte ingénierie interne pouvait préférer les outils natifs. Une entreprise multicloud aux équipes fragmentées pouvait valoriser un plan de contrôle unique. Une organisation réglementée pouvait apprécier une couche de preuves indépendante tout en craignant la concentration des identifiants et des données.

Aucune architecture ne supprimait le verrouillage. Les outils natifs augmentaient la dépendance aux API et sémantiques d’un cloud. Un contrôleur transversal augmentait la dépendance à son graphe, ses politiques et ses edges. La question utile était de savoir si la dépendance restait visible, portable et adaptée au modèle d’exploitation.

La panne pouvait se trouver dans le contrôleur, l’edge, l’API cloud, l’identité ou l’underlay

L’architecture distribuée réduisait la dépendance à un hub de trafic unique mais créait plusieurs domaines de panne qui interagissaient. Le service central pouvait être indisponible ou conserver une intention périmée. Un edge pouvait tomber ou s’isoler. Une API cloud pouvait rejeter une partie du changement. Le fournisseur d’identité pouvait être indisponible. L’underlay pouvait perdre de la capacité ou emprunter une route inattendue. Un pare-feu inséré pouvait épuiser ses ressources.

Les pannes partielles sont particulièrement difficiles. Un fournisseur peut accepter une modification de route tandis qu’un autre la rejette. L’état voulu par le contrôleur diverge alors de l’état réel. Le trafic peut devenir asymétrique ou contourner l’inspection. Un système fiable a besoin de réconciliation, d’opérations idempotentes, de changements par étapes, d’états d’erreur explicites et d’un retour arrière adapté à chaque fournisseur.

Les sources publiques décrivent l’architecture de disponibilité et d’optimisation, mais n’incluent ni étude indépendante d’injection de pannes, ni registre complet d’incidents, ni résultat universel de niveau de service. Les affirmations de résilience doivent rester liées à une architecture documentée ou à un exemple client nommé.

L’acquisition ajoute un autre domaine de panne : la continuité du produit. Les clients doivent savoir quelle console, API, image d’edge, politique et organisation de support remplace le système historique. Une intégration de code techniquement réussie peut créer un risque de migration lorsque les frontières commerciales et opérationnelles restent floues.

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

La découverte et l’orchestration nécessitaient l’accès aux comptes cloud. Un inventaire en lecture seule pouvait utiliser des droits limités, tandis que les changements de routes, segments et services demandaient une autorité plus forte. Le contrôleur se situait donc dans le plan de gestion privilégié même s’il ne possédait pas les charges.

La compromission d’un identifiant pouvait exposer la topologie ou permettre des changements étendus. Un défaut logiciel ou une erreur d’opérateur pouvait propager une politique dans plusieurs clouds. Le risque augmentait avec l’utilité : plus la plateforme gouvernait de comptes et de services, plus le rayon d’impact potentiel était grand.

Les entreprises avaient besoin de rôles de moindre privilège, d’identifiants distincts pour la découverte et l’écriture, d’approbation multipartite, d’un audit complet, de rotation, de révocation d’urgence et d’une voie de récupération indépendante du contrôleur. Les documents publics ne fournissent pas d’évaluation de sécurité indépendante complète ; ces exigences restent donc des contrôles de déploiement nécessaires, non des garanties vérifiées.

Le graphe de télémétrie était tout aussi sensible. Il pouvait révéler noms d’applications, structure du réseau, politiques, relations d’utilisateurs, santé des routes et coûts. La gouvernance après acquisition devrait préciser où ces données sont stockées, quels produits Palo Alto Networks peuvent les utiliser et comment les autorisations des clients historiques ont été migrées. Les sources publiques ne répondent pas à ces questions.

L’acquisition a déplacé une couche réputée neutre dans une plateforme de sécurité

La position indépendante de Prosimo lui permettait de se présenter comme une couche commune entre clouds et services de sécurité. Lorsque Palo Alto Networks est devenu propriétaire, les incitations ont changé. La technologie acquise pouvait faciliter le déploiement de VM-Series et d’autres produits Palo Alto. Cela peut produire une meilleure intégration tout en soulevant des questions sur la prise en charge d’inspections tierces.

La propriété ne prouve pas que la neutralité a disparu. Les éléments fournis ne contiennent pas de matrice actuelle de partenaires ou d’architecture. Ils changent toutefois la question à poser. Les clients doivent savoir si le contrôleur reste ouvert à plusieurs fournisseurs, si les politiques et la télémétrie sont exportables et si l’optimisation favorise le portefeuille du propriétaire.

La déclaration d’intégration mettait l’accent sur l’inspection des flux entrants, sortants et est-ouest. Cela suggère que la topologie et l’orchestration sont devenues une partie d’un système de déploiement de sécurité. Cela ne prouve pas que les fonctions historiques d’App Transit, d’accès utilisateur, d’optimisation des coûts ou chaque workflow réseau aient survécu séparément.

Il s’agit d’un schéma fréquent dans l’infrastructure. Une start-up abstrait un problème de coordination difficile ; un grand fournisseur rachète l’abstraction parce qu’elle augmente l’usage et le contrôle de son produit principal. L’acquéreur obtient un chemin vers le déploiement. Le client peut gagner en intégration et perdre en indépendance fournisseur.

La cartographie du produit actuel est le principal fait manquant

Le dossier public confirme l’acquisition et l’intégration, mais ne fournit pas une correspondance complète entre AXI, Network Transit, App Transit, AIR et Nebula et les produits ou offres actuels de Palo Alto Networks. Il ne publie ni dates de fin de support, ni procédures de migration, ni tableau de continuité fonctionnelle.

Cette lacune empêche une revue produit au présent. Les descriptions historiques expliquent ce que Prosimo avait construit et pourquoi cela comptait. Elles ne disent pas quelles capacités sont aujourd’hui disponibles, sous licence ou supportées. Tout conseil de déploiement contemporain doit se fonder sur la documentation actuelle de Palo Alto Networks, non sur les anciennes annonces Prosimo.

L’absence de cartographie limite aussi l’analyse stratégique. L’absorption complète du graphe et de l’orchestration serait différente d’un usage sélectif de la découverte d’actifs et du placement de pare-feu. Le premier cas créerait un large service de contrôle multicloud ; le second utiliserait Prosimo surtout pour accélérer le déploiement de la sécurité. La déclaration du cofondateur confirme la continuité technologique sans résoudre cette frontière.

Un futur document produit, guide de migration ou cas client pourrait lever une grande partie de l’incertitude. En attendant, la formulation précise est que la technologie Prosimo a été intégrée aux produits de Palo Alto Networks selon un cofondateur, tandis que son périmètre et son mode de commercialisation restent non vérifiés.

Qui contrôle le routage multicloud ?

Aucun acteur ne contrôle seul le chemin complet. L’entreprise contrôle la propriété des comptes, l’intention métier, la conception applicative et les droits qu’elle accorde. Un contrôleur transversal peut découvrir la topologie, traduire les politiques, choisir les chemins et modifier l’état natif des routes. Les clouds contrôlent leurs API, services de transit, points privés, dorsales et de nombreux domaines de panne. Les opérateurs et sites de colocation contrôlent d’autres portions. Les services de sécurité décident si le trafic inspecté est autorisé.

Prosimo recherchait la position intermédiaire la plus stratégique. Sans posséder l’underlay, elle voulait posséder le graphe et la traduction des politiques au-dessus. Celui qui contrôle cette couche décide quels actifs sont visibles, comment les segments sont représentés, où les edges sont placés, quel service inspecte le trafic et quelle télémétrie fait autorité. C’est un pouvoir de routage pratique même lorsque la fibre appartient à un tiers.

Après l’acquisition, Palo Alto Networks possède la technologie survivante et détermine son intégration, son mode de commercialisation et son développement. Les clouds restent souverains dans leurs environnements, et l’entreprise peut révoquer les identifiants ou choisir une autre architecture. La sortie peut toutefois être coûteuse si la topologie, les politiques et les workflows sont devenus dépendants du contrôleur.

La réponse est donc distribuée : l’entreprise autorise ; le contrôleur coordonne ; les infrastructures sous-jacentes des clouds et des opérateurs transportent ; la plateforme de sécurité applique. L’histoire de Prosimo montre que la propriété de la couche de coordination peut changer sans qu’aucun compte cloud ou chemin physique ne change de mains.

Registre principal des sources

Pourquoi Prosimo reste pertinent après l’acquisition

Prosimo a saisi une évolution réelle de l’infrastructure. L’unité des opérations réseau se déplace du dispositif et du préfixe vers l’application, l’identité, la dépendance de service et le graphe de politique. Les API natives rendent l’état du réseau programmable, tandis que les edges logiciels distribués permettent de déplacer les points d’application des politiques. Un contrôleur voyant plusieurs clouds peut coordonner des actions qu’aucune console individuelle ne peut accomplir seule.

L’entreprise a aussi révélé le coût de cette coordination. Une couche commune exige des identifiants privilégiés, une maintenance continue des API, une découverte exacte, une traduction sémantique, de la télémétrie et une discipline opérationnelle. Elle peut réduire le travail fragmenté tout en créant un nouveau point de concentration. Le même système qui simplifie le routage peut agrandir le rayon d’impact d’une mauvaise décision.

L’acquisition par Palo Alto Networks rend la question du contrôle plus visible. Réseau et sécurité convergent autour de l’insertion de services, de la découverte de charges et de la politique. Un fournisseur qui connaît la topologie et peut modifier les routes ne se contente pas d’inspecter le trafic qu’on lui présente ; il peut contribuer à décider quel trafic atteint l’inspection et où.

Prosimo ne doit donc être retenu ni comme une marque autonome qui aurait simplement échoué, ni comme la preuve qu’une plateforme a résolu le multicloud. Sa contribution durable fut de définir le graphe transversal comme infrastructure. La question restante est de savoir si ce graphe, désormais dans une grande entreprise de sécurité, reste suffisamment transparent, portable et gouvernable pour inspirer confiance.