Gravitee

Ce que couvre le produit

Gravitee API Management est une plateforme d’API que l’on peut installer. La documentation produit est publiée sur documentation.gravitee.io/apim. Elle décrit une passerelle, une API de gestion, une console d’administration et un portail développeur. L’édition communautaire est open source. Une édition entreprise et une offre cloud complètent le catalogue de l’éditeur. Les fonctions disponibles dépendent donc de l’édition, et c’est cette édition qu’il faut nommer dans un cadrage.

La page s’en tient au rôle des composants et aux questions d’exploitation, à recouper avec la documentation de la version installée.

Architecture typique

La passerelle est le plan de données : elle reçoit les appels et applique les politiques. La console et l’API de gestion forment le plan de pilotage : conception des API, plans d’application, publication vers le portail. Le portail présente aux consommateurs la documentation et le moyen de s’abonner, selon ce qui a été publié. Ce découpage ressemble à celui des autres plateformes complètes. Il se déploie sur machines virtuelles, en conteneurs ou sur Kubernetes, d’après les guides d’installation de l’éditeur.

La documentation met en avant les API synchrones et asynchrones. On y trouve, selon les versions, REST, WebSocket, webhooks, server-sent events et gRPC. La liste se vérifie dans la version cible. Une architecture type sépare la passerelle, que l’on réplique avec le trafic, des composants de gestion, que l’on expose à un public plus restreint. Les bases qui portent la configuration et les abonnements sont externalisées, sauvegardées, et distinctes entre environnements.

Un déploiement hybrid ou cloud existe dans l’offre de l’éditeur. Il change le responsable du plan de gestion. Le choix entre « nous exploitons tous les composants » et « le plan de gestion est opéré » se fait avant l’installation, parce qu’il détermine le réseau, les sauvegardes et le support.

Points forts et limites

La plateforme réunit passerelle, console et portail dans un produit que l’on peut héberger. Elle est pertinente lorsque ces trois pièces sont nécessaires et que l’on veut rester sur une distribution open source pour le cœur, avec une édition entreprise seulement pour les fonctions qui le justifient. Le support des styles asynchrones intéresse les échanges qui ne se réduisent pas à une requête HTTP.

Les limites sont celles d’un produit à exploiter. Montées de version, bases, certificats et surveillance restent à la charge de l’équipe, sauf à prendre l’offre opérée. L’écosystème et la disponibilité de profils sont plus étroits que ceux des services des hyperscalers. Les fonctions d’entreprise ne doivent pas être supposées présentes dans l’édition communautaire. Enfin, comme ailleurs, une politique de passerelle qui porte la règle métier devient une dette.

Quand le retenir

Gravitee est un candidat lorsqu’il faut une plateforme d’API management installée, avec portail, et une préférence pour un produit européen open source plutôt que pour le seul service managé d’un cloud. Il se compare directement à WSO2 API Manager, qui couvre un périmètre voisin, et se distingue de Kong lorsque le portail et les plans d’application font partie du premier besoin.

Il est moins adapté lorsque l’hébergement et l’identité sont déjà entièrement chez un hyperscaler et que le service managé de ce cloud suffit. Azure API Management, Apigee et AWS API Gateway sont alors les références à évaluer. Le comparatif rassemble ces critères.

Migration et intégration

La migration reprend les contrats, les plans d’accès et les backends. Les abonnés d’un ancien portail reçoivent de nouveaux identifiants. Les politiques de quota et de transformation se réécrivent dans le modèle Gravitee de la version choisie. L’analytique historique ne suit pas le changement de produit. Seuls les journaux que l’on a archivés ailleurs restent consultables.

L’identité se raccorde au fournisseur déjà en place, par clé, OAuth 2.0 ou OpenID Connect, selon les connecteurs de l’édition. Le portail publie les API que l’on marque comme publiques pour les développeurs. Une API interne peut rester sur la passerelle sans fiche de portail. Cette distinction évite de documenter publiquement un service qui ne devait pas l’être.

Les environnements se séparent par installation ou par cloisonnement net, avec des bases distinctes. Promouvoir une API consiste à rejouer une définition revue, pas à copier une base de production vers la recette.

Le raccordement des backends se décrit par des endpoints, des délais et des règles de coupure. Un service lent ne doit pas occuper indéfiniment les travailleurs de la passerelle. Les opérations qui créent un paiement, une commande ou une écriture ne sont pas rejouées automatiquement : l’appelant décide, avec l’identifiant qu’il a fourni. Les certificats clients, lorsqu’un backend exige un TLS mutuel, se gèrent comme des secrets tournants, pas comme des fichiers déposés dans l’image du conteneur.

Ce que Technocify peut prendre en charge

L’audit vérifie l’édition nécessaire, les styles d’API réellement utilisés et le mode d’hébergement. La conception place la passerelle, la console et le portail sur des réseaux adaptés, et fixe les plans d’application. La mise en œuvre installe la plateforme, publie les premières API et teste un abonnement de bout en bout. Le run couvre les mises à jour, les sauvegardes de configuration et la surveillance des erreurs amont.

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 À propos.

Voir aussi plateformes API et cloud, interopérabilité et DevSecOps.