Études de cas

1. Contexte

Une entreprise disposant d’une infrastructure informatique traditionnelle, majoritairement hébergée sur site (on-premise), cherche à entreprendre une modernisation complète de son système pour aligner ses capacités technologiques sur les exigences actuelles du marché.

Cette transformation implique l’exposition de ses services existants - souvent encapsulés dans des applications monolithiques ou des bases de données legacy - sous la forme d’API sécurisées et utilisant le standard REST, afin de faciliter leur intégration dans des écosystèmes numériques plus larges.

Parallèlement, l’entreprise ambitionne de concevoir et de déployer de nouvelles applications Cloud-natives, construites sur des architectures microservices ou serverless (Cloud Run) et hébergées sur la plateforme Google Cloud, pour accélérer l’innovation, optimiser la scalabilité et répondre de manière agile aux évolutions des attentes clients et aux opportunités concurrentielles.

Pour garantir la sécurité de ces API, elle envisage de s’appuyer sur des mécanismes avancés, tels que l’authentification OAuth 2.0, la gestion des tokens JWT, et des politiques de contrôle d’accès granulaires, tout en surveillant les menaces comme les abus ou les attaques de type DDoS (Distributed Denial of Service).

En complément, l’entreprise planifie la mise en place d’un portail développeur dédié à ses partenaires externes, une interface centralisée offrant des fonctionnalités de découverte d’API via un catalogue interactif, des outils de test comme des environnements sandbox avec des mocks, et des mécanismes d’abonnement pour consommer ces API via des clés ou des plans de quotas.

Ce portail, potentiellement basé sur Apigee, vise à simplifier l’onboarding des partenaires, à standardiser les interactions et à encourager l’adoption de ses services numériques, tout en assurant une gouvernance rigoureuse et une traçabilité complète des usages.

Ainsi, cette stratégie...

1. Contexte

Dans ce scénario, une entreprise construit un écosystème d’applications modernes architecturées en microservices, déployées sur Google Cloud Platform (GCP) à travers une combinaison d’environnements complémentaires : Google Kubernetes Engine (GKE) pour des déploiements orchestrés de conteneurs nécessitant une gestion fine des clusters, Cloud Run pour des workloads serverless scalables avec une exécution à la demande.

La gestion centralisée et l’exposition des API de ces applications sont assurées par Apigee X, la plateforme d’API Management hébergée sur GCP, qui agit comme un point d’entrée unifié pour router, transformer et sécuriser les interactions entre ces services et les consommateurs externes.

L’entreprise adopte une approche outside-in dans son programme d’API Management, où la conception des API est guidée par des exigences métier précises, traduites en produits d’API stratégiques visant à répondre aux attentes spécifiques du marché, favorisant ainsi un alignement direct entre technologie et valeur business.

Cependant, l’exposition publique de ces API critiques - essentielles à la disponibilité et à l’intégrité des services - soulève des enjeux de sécurité majeurs, notamment face aux attaques Distributed Denial of Service (DDoS), capables de saturer les ressources et de rendre les applications inaccessibles, ainsi qu’aux bots automatisés qui menacent les services par des actions malveillantes telles que le scraping de données, les tentatives d’accès frauduleux ou l’exploitation de vulnérabilités.

Pour contrer ces risques, l’architecture intègre deux solutions de sécurité complémentaires :

1. Contexte

Dans ce scénario, une grande institution financière, opérant sous des contraintes réglementaires rigoureuses telles que le Règlement général sur la protection des données (RGPD), la norme PCI-DSS ou des lois locales sur la souveraineté des données, entreprend la modernisation de son architecture informatique pour répondre aux exigences actuelles tout en préservant la confidentialité et la localisation de ses données sensibles.

L’objectif est d’exposer ses services existants - souvent encapsulés dans des systèmes legacy comme des mainframes COBOL, des bases de données relationnelles sur site ou des applications monolithiques - sous forme d’API modernes (REST, GraphQL) afin de simplifier leur intégration avec des écosystèmes externes, tels que des applications mobiles destinées aux clients ou des plateformes de partenaires (par exemple, fintechs ou assureurs).

Cependant, cette institution doit impérativement maintenir un contrôle strict sur l’emplacement physique et le traitement de ses données critiques - telles que les informations bancaires ou les historiques de transactions - pour se conformer aux exigences de localisation imposées par les régulateurs, tout en évitant leur exposition directe à des environnements Cloud publics sans garanties suffisantes. Parallèlement, elle vise à garantir une haute disponibilité et une scalabilité des API afin de supporter des volumes de trafic variables, notamment lors de pics d’utilisation (par exemple, périodes de paiement ou consultations massives), tout en assurant une résilience face aux interruptions potentielles.

L’hétérogénéité de son paysage technologique, mêlant systèmes patrimoniaux sur site (serveurs IBM, Oracle) et composants Cloud émergents (microservices sur GCP), nécessite une solution capable d’intégrer ces environnements disparates dans une architecture cohérente.

Dans ce cadre, Apigee hybrid s’impose comme une réponse adaptée : en déployant le runtime des API Gateways localement sur des clusters Kubernetes hébergés...

1. Contexte

Dans ce scénario, une entreprise évoluant dans un secteur dynamique, comme la vente au détail, cherche à optimiser ses processus métier et à renforcer son agilité numérique en combinant une gestion avancée des API avec une orchestration fluide de ses flux d’intégration.

L’objectif est double : exposer des services internes et externes via des API sécurisées et standardisées pour répondre aux besoins des clients, partenaires et applications modernes (mobiles, web), tout en automatisant les interactions complexes entre des systèmes hétérogènes - applications SaaS (comme Salesforce ou SAP), bases de données sur site, et microservices Cloud - pour rationaliser les opérations internes.

Dans ce cadre, Apigee est envisagé comme la plateforme d’API Management pour centraliser l’exposition, la sécurisation (via OAuth 2.0, limitation de débit) et la surveillance des API, avec des fonctionnalités comme Advanced API Security pour se protéger contre les abus.

En complément, Application Integration, une solution serverless sur Google Cloud Platform (GCP), est utilisée pour concevoir et exécuter des workflows d’intégration déclenchés par des événements (par exemple, une commande client), connectant les systèmes disparates via des connecteurs préconfigurés ou personnalisés, dans une approche Low code/No code.

Ce contexte reflète une stratégie où l’entreprise doit à la fois répondre aux attentes externes via des API performantes et optimiser ses processus internes via une intégration agile, dans un environnement où la rapidité, la scalabilité et la sécurité sont essentielles face à une concurrence croissante et des volumes de données en expansion.

L’utilisation conjointe d’Apigee et d’Application Integration vise ainsi à créer une architecture unifiée qui marie exposition externe et orchestration interne, adaptée aux exigences d’un écosystème numérique complexe et en évolution rapide....