Apigee

Ce que couvre le produit

Apigee est l’offre d’API management de Google Cloud. La documentation d’introduction, What is Apigee, présente une plateforme pour exposer des API via des proxies, leur appliquer des politiques, mesurer le trafic et le présenter à des développeurs. Deux modes de déploiement structurent le choix. Apigee, dans son mode opéré sur Google Cloud, laisse le runtime à Google. Apigee hybrid exécute le runtime dans un cluster Kubernetes que le client opère, pendant que le plan de gestion reste chez Google.

Les capacités exactes dépendent du contrat et de la version. Cette page sert à cadrer une étude, puis à vérifier chaque point dans la documentation courante.

Architecture typique

Un proxy Apigee est la façade publiée. Il porte une URL, des politiques et une ou plusieurs cibles backend. Les politiques enchaînent des contrôles : vérification d’identité, quotas, mise en forme, gestion d’erreur. Le plan de gestion conserve la configuration des proxies, les produits d’API, les applications développeur et les rapports. Le plan d’exécution traite les appels.

En mode entièrement opéré, les deux plans sont dans le cloud du fournisseur. En mode hybrid, les pods du runtime s’exécutent dans le cluster du client et synchronisent leur configuration avec le plan de gestion. Le trafic des API peut ainsi rester dans le réseau du client, ce qui répond à certaines contraintes de résidence des données, alors que la publication et l’analytique passent par le plan de gestion Google. Cette dépendance est structurelle : une coupure vers le plan de gestion n’a pas le même effet qu’une passerelle dont toute la configuration est locale.

Le portail développeur fait partie de la plateforme. Il publie la documentation des API que l’on choisit d’y exposer, et permet aux applications de s’enregistrer selon le modèle retenu. Il ne remplace pas un support humain lorsque les contrats sont instables.

Points forts et limites

Le modèle de proxy et de politiques est explicite, et l’analytique est intégrée à la plateforme plutôt qu’ajoutée après coup. Pour une organisation déjà engagée sur Google Cloud, l’identité, les journaux et le réseau se raccordent au reste du compte. Le mode hybrid donne une option lorsque le runtime ne doit pas quitter le cluster du client.

Les limites tiennent au modèle commercial et opérationnel. Le plan de gestion est celui de Google. Les fonctions, les régions et les quotas de la plateforme suivent l’offre souscrite. Le mode hybrid demande à la fois une compétence Kubernetes et une compréhension du lien avec le plan de gestion. Les politiques peuvent absorber de la logique métier, avec le même effet que sur toute autre passerelle : le proxy devient difficile à tester et à faire évoluer. Une politique de transformation volumineuse signale en général un contrat d’API qui devrait être repris dans le service.

Quand le retenir

Apigee est un candidat lorsque l’organisation veut une plateforme opérée, avec analytique et portail, et qu’elle accepte le plan de gestion Google. Le mode hybrid est à étudier lorsque les backends sont dans un cluster privé et que le trafic des API doit y rester, tout en gardant la publication dans Apigee.

Il est moins adapté lorsqu’il faut un produit installé de bout en bout sans lien avec un plan de gestion externe, ou lorsque l’hébergement de référence est un autre cloud et que l’on veut le service managé de ce cloud. La comparaison avec Azure API Management est fréquente pour cette raison. Elle est traitée dans le comparatif des solutions d’API management, aux côtés d’AWS API Gateway.

Migration et intégration

La reprise d’API existantes passe par la création de proxies alignés sur les contrats réels, pas sur une génération automatique non relue. Chaque politique de sécurité, de quota et de cache se réécrit dans le modèle Apigee. Les identifiants des applications consommatrices sont de nouveaux secrets. Les prévoir dans le plan de bascule évite une coupure le jour du changement de nom de domaine.

L’identité s’appuie souvent sur des jetons déjà émis par un fournisseur OpenID Connect, vérifiés dans le proxy. Les backends peuvent être des services du même réseau, des fonctions ou des API tierces. Les timeouts et les nouvelles tentatives se règlent par cible. Les opérations non idempotentes, en particulier les créations et les paiements, ne se rejouent pas sur une erreur ambiguë.

En mode hybrid, l’intégration comprend le cluster, les certificats, la connectivité sortante vers le plan de gestion et la supervision des pods de runtime. Ce n’est pas un détail d’infrastructure que l’on traite après la publication des API. Les environnements de test et de production restent des organisations ou des espaces séparés, avec des cibles backend distinctes. Promouvoir un proxy consiste à rejouer une configuration relue, pas à pointer un proxy de test vers un service réel pour « vérifier rapidement ».

Ce que Technocify peut prendre en charge

L’audit relève les API à exposer, les contraintes de résidence du trafic, le fournisseur d’identité et le niveau d’analytique attendu. La conception choisit entre runtime opéré et hybrid, découpe les produits d’API et fixe les politiques qui restent dans le proxy. La mise en œuvre construit les premiers proxies, le portail sur le périmètre retenu et les contrôles d’accès. Le run suit les versions de configuration, les erreurs backend et les changements de contrat.

Les équipes Technocify s’appuient sur une pratique de l’intégration et des API depuis 2009. Nos consultants sont certifiés WSO2 API Manager Practitioner V4 (2023), WSO2 API Manager Developer V3 (2021), MuleSoft Developer V4 (2022), Workato Automation Pro I, II, III (2025, valides jusqu’en 2027) et ITIL V4 (2020). Détail sur la page À propos.

Le travail se raccorde aux pages plateformes API et cloud, interopérabilité et cybersécurité.