En bref
Les examens de sécurité d'entreprise, les exigences de conformité et les règles de résidence des données bloquent l'adoption de Postman et poussent à l'abandon de cette solution. Le schéma récurrent est le même : l'architecture "cloud-first" entre en conflit avec les politiques exigeant que les données restent en interne, et Postman ne propose pas d'option auto-hébergée. Le déploiement d'entreprise auto-hébergé d'Apidog est en train de devenir l'alternative vers laquelle ces organisations se tournent.
Introduction
Postman a bâti une position dominante sur le marché des outils API pendant plus d'une décennie. Ses effets de réseau sont substantiels : 30 millions d'utilisateurs, une vaste collection d'API publiques, des intégrations avec toutes les principales plateformes CI/CD, et un ensemble de fonctionnalités qui s'est étendu bien au-delà du simple test de requêtes, englobant la conception d'API, la documentation et le monitoring.
Mais au cours des dernières années, une contre-tendance est apparue chez les clients d'entreprise. Les équipes de sécurité et de conformité examinent les outils de développement avec une nouvelle rigueur, et l'architecture "cloud-first" de Postman ne passe plus ces examens dans un nombre croissant d'organisations.
Le problème est structurel. Le produit de Postman est construit autour de la collaboration cloud. Les espaces de travail, les équipes, les environnements et la synchronisation des collections nécessitent tous que les données résident sur les serveurs de Postman. Cela avait du sens lorsque le produit visait les développeurs individuels et les petites équipes. À mesure qu'il a progressé vers les comptes d'entreprise gérant des données sensibles, la même architecture qui a permis la collaboration est devenue une vulnérabilité dans les environnements réglementés et soucieux de la sécurité.
Facteur 1 : Les examens des équipes de sécurité bloquent l'adoption
Le scénario le plus courant qui déclenche une migration de Postman est un examen de sécurité. À mesure que les organisations mûrissent leurs programmes de sécurité logicielle, les outils de développement sont soumis à la même rigueur que l'infrastructure de production.
Le processus d'examen se déroule généralement comme suit : une équipe d'ingénierie souhaite étendre l'utilisation de Postman, passer des comptes individuels à un compte d'entreprise partagé, ou l'officialiser dans la chaîne d'outils de développement. L'équipe de sécurité examine l'outil dans le cadre de l'évaluation du fournisseur. L'examen révèle que la synchronisation cloud de Postman envoie les corps de requêtes, les variables d'environnement (y compris les identifiants) et les données de réponse aux serveurs de Postman basés aux États-Unis.
L'équipe de sécurité pose une question : notre politique de gestion des données permet-elle de stocker des données de requêtes API contenant des points d'accès internes et des identifiants dans un cloud tiers ? Pour les organisations ayant une politique de classification des données qui catégorise les identifiants API et les informations de système interne comme confidentielles ou sensibles, la réponse est souvent non.
La réponse de Postman à cette préoccupation est sa certification SOC 2 Type II et sa documentation sur la sécurité d'entreprise. Pour certaines organisations, cela est suffisant. Pour d'autres, la certification ne résout pas la préoccupation sous-jacente liée à l'architecture : même un fournisseur certifié SOC 2 a accès à vos données lorsqu'elles s'exécutent dans son cloud.
La conclusion de l'équipe de sécurité est que Postman, en tant que produit SaaS "cloud-first" sans option auto-hébergée, ne peut pas être utilisé pour des travaux impliquant des systèmes internes sensibles. L'équipe d'ingénierie se retrouve à chercher une alternative qui passe l'examen.
Facteur 2 : Exigences de conformité en matière de résidence des données
Les exigences de conformité sont devenues un moteur important de la migration d'outils, en particulier dans les secteurs avec des règles strictes de résidence des données.
Organisations européennes soumises au RGPD. Le RGPD crée des frictions pour les services cloud basés aux États-Unis. Bien que les clauses contractuelles types fournissent un mécanisme juridique pour les transferts de données de l'UE vers les États-Unis, les organisations avec des données particulièrement sensibles peuvent préférer éviter cette complexité en utilisant des outils qui conservent les données en Europe. Postman n'offre pas de résidence des données dans la région de l'UE ni d'option auto-hébergée, il n'y a donc aucun moyen de maintenir les données au sein de l'UE.
Services financiers soumis aux directives FFIEC et OCC. Les régulateurs bancaires américains ont de plus en plus mis l'accent sur la résidence des données et la gestion des risques liés aux tiers. Les banques et institutions financières soumises à la supervision de l'OCC ou de la FDIC examinent si les informations système sensibles (qui peuvent inclure les identifiants API pour les systèmes financiers) doivent être stockées dans des clouds tiers.
Contractants gouvernementaux soumis au CMMC. Le programme Cybersecurity Maturity Model Certification pour les contractants de la défense américaine spécifie les exigences pour la gestion des informations non classifiées contrôlées (CUI). Le stockage de CUI dans un outil cloud commercial qui n'est pas un service autorisé par FedRAMP peut violer les exigences du CMMC. Postman ne détient pas l'autorisation FedRAMP.
Soins de santé soumis à la HIPAA. Comme discuté dans l'article sur l'examen de conformité, Postman offre un BAA pour la HIPAA, mais le modèle de synchronisation cloud signifie toujours que les PHI (Informations de Santé Protégées) dans les requêtes de test voyagent vers les serveurs de Postman. Les organisations avec des programmes HIPAA stricts peuvent préférer un outil qui élimine entièrement ce flux de données.
Le fil conducteur commun à ces contextes de conformité : l'organisation doit contrôler où ses données circulent, et l'architecture de Postman rend cela impossible.
Facteur 3 : Le coût à grande échelle
La sécurité et la conformité ne sont pas les seuls facteurs. Le coût pur est également un facteur à mesure que les organisations d'ingénierie évoluent.
Le prix d'entreprise de Postman est par utilisateur et par mois. Pour les petites équipes, le coût est négligeable. Pour les organisations d'ingénierie comptant des centaines ou des milliers de développeurs, le coût devient substantiel. Les organisations qui effectuent une analyse des coûts à grande échelle constatent parfois qu'un déploiement unique d'une alternative auto-hébergée permet des économies significatives sur une période de plusieurs années.
Cette considération de coût est particulièrement pertinente pour les organisations qui investissent déjà dans une infrastructure de plateforme interne. L'ajout d'un déploiement d'outil API à un cluster Kubernetes existant ou à une ferme de serveurs interne a un coût marginal par rapport à un abonnement SaaS récurrent par utilisateur.
Le facteur coût est rarement seul. Les organisations qui migrent pour des raisons de coût citent généralement aussi des préoccupations de sécurité ou de conformité. Le coût est le catalyseur qui déclenche l'examen formel, lequel met ensuite en évidence les problèmes de sécurité et de conformité.
Facteur 4 : La découverte de CloudSEK et ses conséquences
La découverte de CloudSEK en 2023 de plus de 30 000 espaces de travail Postman publics divulguant des clés API a eu un effet spécifique sur les équipes de sécurité d'entreprise. Elle a fourni un exemple concret d'une mauvaise configuration de Postman conduisant à une exposition généralisée des identifiants.
Lorsque les équipes de sécurité ont vu le rapport, elles ont posé à leurs propres organisations la question évidente : avons-nous des espaces de travail publics avec des identifiants ? Beaucoup ont découvert que c'était le cas. Le processus d'audit qui a suivi a conduit à une remédiation, mais aussi à une réévaluation de la compatibilité de l'architecture par défaut de Postman avec la tolérance au risque de l'organisation.
La découverte a également donné aux équipes de sécurité une preuve concrète à apporter aux conversations avec la direction de l'ingénierie concernant le risque lié aux outils de développement. Les préoccupations abstraites concernant les "identifiants synchronisés dans le cloud" sont difficiles à concrétiser. Un rapport citant des entreprises spécifiques avec des clés API exposées, avec un mécanisme pour vérifier sa propre exposition, est exploitable.
Pour certaines organisations, l'audit n'a trouvé aucun espace de travail public avec des identifiants. Elles ont renforcé leurs politiques et sont restées avec Postman. Pour d'autres, l'audit a révélé une exposition, et l'expérience de découvrir que des identifiants de production avaient été accessibles à quiconque recherchant sur le réseau API de Postman a été une motivation suffisante pour migrer.
Le modèle de migration : ce que les organisations font réellement
Les organisations qui abandonnent Postman cloud suivent un schéma reconnaissable.
Phase 1 : Déclencheur de sécurité ou de conformité. Un examen de sécurité, une découverte d'audit, une exigence de conformité ou un incident (comme la découverte d'un espace de travail exposé) déclenche une évaluation formelle des outils de développement.
Phase 2 : Collecte des exigences. L'équipe de sécurité établit les exigences. Généralement : résidence des données, pas de synchronisation cloud des identifiants, option de déploiement auto-hébergé, fonctionnalités de collaboration d'équipe, compatibilité des collections Postman (pour la migration) et support entreprise.
Phase 3 : Évaluation. Les outils candidats sont évalués par rapport aux exigences. Bruno échoue généralement à l'évaluation pour les grandes équipes car il manque de fonctionnalités de collaboration centralisées. Hoppscotch auto-hébergé est évalué mais peut être dépriorisé si l'équipe manque de capacité DevOps ou a besoin de fonctionnalités que Hoppscotch ne couvre pas. Apidog auto-hébergé est le choix le plus courant pour les équipes qui ont besoin de l'ensemble complet de fonctionnalités (conception, test, documentation, mocking) avec l'auto-hébergement.
Phase 4 : Pilote. Un sous-ensemble de l'équipe d'ingénierie exécute l'outil candidat en parallèle avec Postman pendant 30 à 90 jours. Les collections Postman sont exportées et importées. Les workflows sont validés.
Phase 5 : Migration. Les collections sont migrées, les environnements sont rétablis avec des identifiants propres (une migration est un bon moment pour faire tourner les clés), et les comptes Postman sont déprovisionnés.
Ce que ces organisations choisissent à la place
Le paysage des alternatives a mûri au point que les équipes d'entreprise disposent d'options viables.
Apidog auto-hébergé. Le choix le plus courant pour les organisations qui ont besoin de maintenir la pleine capacité de la plateforme Postman (pas seulement le test de requêtes, mais la conception d'API, la documentation et le mocking) tout en conservant les données dans leur propre infrastructure.
Le déploiement auto-hébergé fonctionne sur Docker et peut être déployé sur site, dans un cloud privé ou dans une région cloud spécifique. Les fonctionnalités de collaboration d'équipe fonctionnent de la même manière que la version cloud, mais la synchronisation se fait vers votre serveur interne. La résidence des données est entièrement sous votre contrôle.
Pour les acquisitions d'entreprise, Apidog propose un modèle de licence auto-hébergée avec un support dédié. Cela répond aux exigences de gestion des fournisseurs des grandes organisations.
Bruno pour les équipes axées sur l'ingénierie. Les organisations dotées d'une forte culture DevOps et de workflows centrés sur Git choisissent parfois Bruno parce que son approche de "collections en tant que fichiers" s'aligne sur les principes de l'infrastructure en tant que code. Les collections vivent aux côtés du code de l'application dans les mêmes dépôts. Le contrôle de version est Git. Pas de serveur à maintenir.
Bruno fonctionne mieux lorsque le besoin principal de l'organisation est le test de requêtes et que l'équipe est à l'aise avec une expérience d'outil plus minimale.
Hoppscotch auto-hébergé. Open source, auto-déployable et basé sur un navigateur. Idéal pour les organisations qui souhaitent une interface web accessible aux membres de l'équipe sans installer d'application de bureau. Nécessite un investissement opérationnel plus important que l'option auto-hébergée d'Apidog.
Ce que les migrations réussies ont en commun
Les organisations qui réussissent à migrer de Postman cloud partagent plusieurs pratiques.
Elles gèrent la migration comme un projet, et non comme une tâche accessoire. Les collections ne migrent pas d'elles-mêmes. Les variables d'environnement doivent être réintroduites avec des identifiants propres. Les scripts de test peuvent nécessiter des ajustements pour les différences dans les API de script. Allouer un temps de projet approprié conduit à des migrations plus propres.
Elles traitent la migration comme une opportunité de nettoyer les identifiants. Le processus de migration exige de réintroduire les variables d'environnement. C'est un moment naturel pour faire tourner les clés API et s'assurer que les identifiants de développeur sont correctement définis. Les organisations qui le font sortent de la migration avec une posture d'identifiants plus propre que celle qu'elles avaient au départ.
Elles forment l'équipe sur le modèle de sécurité du nouvel outil. Comprendre pourquoi l'outil a été choisi et comment son modèle de données diffère de Postman aide l'équipe d'ingénierie à prendre de bonnes décisions. Une équipe qui comprend que "nos données restent en interne parce qu'elles se synchronisent avec notre serveur" est moins susceptible de créer des brèches de sécurité qu'une équipe qui sait seulement "nous avons changé d'outil".
Elles établissent des politiques claires sur la nouvelle plateforme. La même gouvernance qui était nécessaire pour Postman est nécessaire pour le nouvel outil : qui a accès à quoi, où sont stockés les identifiants et comment est géré l'accès à l'espace de travail. La migration sans amélioration des politiques ne fait que déplacer le même risque vers une plateforme différente.
Le fossé produit que Postman n'a pas comblé
La tendance de migration des entreprises est finalement motivée par un manque de produit : Postman n'a pas construit d'option auto-hébergée.
Un Postman auto-hébergé fonctionnant sur l'infrastructure du client et synchronisant les données en interne répondrait à la préoccupation de la résidence des données tout en conservant toutes les fonctionnalités qui ont fait la domination de Postman. De nombreux clients d'entreprise ont publiquement demandé cela sur les forums de feedback de Postman au fil des ans. Le produit n'a pas évolué dans cette direction.
Le modèle commercial de Postman dépend des abonnements cloud. Une option auto-hébergée déplacerait une partie de ces revenus vers des licences uniques ou annuelles et nécessiterait la construction et la maintenance d'une infrastructure de déploiement que Postman n'a pas priorisée.
Le fossé a créé une opportunité pour Apidog et d'autres alternatives. La demande de "fonctionnalités Postman, déploiement auto-hébergé" est réelle et n'est pas satisfaite par Postman lui-même.
FAQ
Postman est-il en train de perdre activement des clients d'entreprise à cause de cela ?Le modèle des migrations motivées par les examens de sécurité est réel et documenté dans les forums de développeurs et les discussions communautaires. Les grandes organisations dotées de programmes de sécurité matures sont les plus susceptibles de rencontrer les limites architecturales de Postman. La question de savoir si Postman perd des clients nets à cause de cela est une question commerciale qui dépasse le cadre de cette analyse.
Ne peut-on pas simplement désactiver la synchronisation de Postman et l'utiliser localement ?Postman a supprimé Scratch Pad vers 2023, ce qui était la seule voie vers un fonctionnement entièrement local. Les versions actuelles nécessitent un compte connecté et synchronisent les données par défaut. Pour les entreprises ayant besoin d'un contrôle total des données, les atténuations partielles au sein de Postman ne sont pas suffisantes.
À quoi ressemble un déploiement auto-hébergé d'Apidog sur le plan opérationnel ?Il fonctionne sur Docker Compose ou Kubernetes. Il nécessite une base de données PostgreSQL et un proxy inverse pour la terminaison TLS. La charge opérationnelle est comparable à celle de l'exécution d'une application web de complexité moyenne. Les équipes avec des ingénieurs de plateforme internes peuvent le gérer.
Qu'arrive-t-il aux collections Postman existantes pendant la migration ?Les collections Postman s'exportent au format JSON. Apidog, Bruno, Hoppscotch et Insomnia importent tous le format de collection Postman. L'importation est généralement propre pour les collections. Les variables d'environnement doivent être saisies manuellement (ce qui est de toute façon une bonne pratique pour l'hygiène des identifiants).
Apidog auto-hébergé prend-il en charge le SSO et l'authentification d'entreprise ?L'offre auto-hébergée d'Apidog pour les entreprises prend en charge l'intégration SSO via SAML et OIDC. C'est une exigence pour la plupart des déploiements d'entreprise et est disponible sur le plan entreprise.
Combien de temps prend une migration Postman typique ?Pour une équipe d'ingénierie de 50 personnes avec 100 à 200 collections Postman, une migration prend généralement 4 à 8 semaines entre la décision et la bascule complète, y compris la période pilote et la formation. Les équipes plus grandes avec plus de collections prennent plus de temps.
Les entreprises qui abandonnent Postman cloud ne le font pas parce que Postman est un mauvais produit. Elles le font parce que l'architecture du produit ne correspond plus à leurs exigences, celles-ci ayant mûri. Les organisations qui réussissent avec les alternatives à Postman sont celles qui traitent la migration comme un projet avec des exigences claires, et non comme un simple échange d'outils.