Les objets d’une plateforme
API, proxy, policy, flow, produit, application, souscription : le modèle que toute plateforme d’API management implémente, sous des noms différents selon l’éditeur.
Toutes les plateformes d’API management manipulent les mêmes objets. Les noms changent d’un éditeur à l’autre, les écrans aussi, mais le modèle est le même partout, et le connaître fait gagner la moitié d’une formation produit. C’est aussi le vocabulaire du reste de ce guide.
Deux chaînes se croisent. Celle de l’exposition, qui va d’un service à une API publiée. Celle de la consommation, qui va d’un consommateur à un droit d’appeler.
Exposition
Ce que la plateforme publie
Service
Votre implémentation
Proxy
L’API telle qu’elle est exposée
Produit
Un ou plusieurs proxys, avec des conditions
Consommation
Qui a le droit d’appeler
Application
Le client déclaré, porteur des identifiants
Consommateur
L’équipe, le partenaire, l’agent
Du service à l’API publiée
Le service est votre implémentation. La plateforme ne le connaît que par son adresse et son contrat. Il peut changer de langage, de version ou d’hébergement sans que rien ne bouge devant.
Le proxy est l’API telle que la plateforme l’expose. C’est l’objet central, et son nom varie beaucoup selon les produits : proxy, API, façade, service virtuel. Il porte l’adresse publique, la version, le routage vers le service, et la chaîne de traitement appliquée à chaque appel. Un proxy n’est pas un service de plus : c’est une déclaration qui dit comment une API existante est présentée au monde.
Cette indirection est ce qui permet de changer l’implémentation sans prévenir les consommateurs, et c’est la première raison d’avoir une plateforme.
La policy et le flow
Une policy est une règle appliquée à un appel. Vérifier un jeton, compter un quota, réécrire un en-tête, mettre en cache, masquer un champ. Chacune est unitaire, configurable, et fournie par le produit. En écrire une à la main est possible partout et devrait rester rare, voir ce qu’il faut refuser à la gateway.
Un flow est la suite ordonnée de policies qu’un appel traverse. Toutes les plateformes en distinguent au moins deux, et souvent trois.
| Flow | Quand il s’exécute | Ce qu’on y met |
|---|---|---|
| Entrant | À la réception de l’appel, avant le service | Authentification, quotas, validation, filtrage |
| Sortant | Au retour du service, avant le consommateur | Masquage, mise en forme, en-têtes de cache |
| Erreur | Quand quelque chose échoue | Message normalisé, journalisation, code de retour |
L’ordre compte autant que le contenu. Un quota compté après l’appel au service protège le contrat mais pas la capacité. Une validation de schéma placée après une transformation valide le mauvais document. C’est la première chose à lire dans une configuration existante, et la première à écrire dans une nouvelle.
La portée compte aussi. Une policy peut s’appliquer à tout le trafic de la plateforme, à un produit, à un proxy, ou à une seule opération. Les policies de sécurité et de protection se posent le plus haut possible, pour qu’une nouvelle API en hérite sans que personne y pense.
Le produit, l’application, la souscription
Ces trois-là forment le modèle commercial de la plateforme, et c’est ce qui se comprend le plus mal, y compris en interne.
Un produit d’API regroupe une ou plusieurs API assorties de conditions d’usage : quotas, niveau de service, tarif éventuel, documentation associée. C’est l’unité qu’un consommateur souscrit, pas l’API. La distinction sert dès qu’une même API entre dans une offre gratuite limitée et dans une offre payante généreuse : un proxy, deux produits.
Une application est le client déclaré, celui qui porte les identifiants : clé d’API, ou identifiant et secret OAuth. Elle appartient à un consommateur, équipe interne, partenaire, ou agent. Ce n’est pas une personne, et une même équipe en déclare plusieurs, une par environnement au minimum.
Une souscription lie une application à un produit. Elle est l’objet que la gateway consulte à chaque appel pour répondre à deux questions : cet appelant a-t-il le droit d’appeler cette API, et où en est-il de son quota. Elle porte aussi l’état, en attente, active, révoquée, ce qui donne le geste de coupure.
Proxy
Une API exposée
Produit
Conditions et quotas
Application
Identifiants du consommateur
Le test qui vérifie qu’une organisation tient ce modèle : combien de temps faut-il pour répondre à « qui appelle cette API, et depuis quand ». Avec le modèle en place, c’est une requête. Sans lui, c’est une enquête dans des journaux, par adresse IP, avec des trous.
Les noms qui changent selon le produit
Le même objet porte des noms différents. Ce tableau évite de refaire la traduction à chaque avant-vente.
| Ici | Aussi appelé |
|---|---|
| Proxy | API, façade, service virtuel, API proxy |
| Policy | Policy, règle, filtre, plugin, module |
| Flow | Pipeline, chaîne, request/response flow, pre/post |
| Produit | Plan, offre, API product, package |
| Application | Client, app, consommateur applicatif |
| Souscription | Abonnement, contrat, subscription, credential |
Deux pièges reviennent. Certains produits appellent « API » ce que d’autres appellent « produit », ce qui change le sens d’un écran entier. Et le mot « contrat » désigne selon les cas le contrat d’interface, l’OpenAPI, ou le contrat de consommation, la souscription. Demander lequel est en jeu évite une réunion.
Ce que ça change à la lecture du reste
Ces objets se répartissent entre les trois composants. Les proxys, les produits et les policies se déclarent dans le control plane. La gateway les applique. Le portail expose les produits, enregistre les applications et recueille les souscriptions.
Un produit d’API management se juge en grande partie sur la propreté de ce modèle. Trois questions suffisent à le savoir. Un proxy peut-il appartenir à plusieurs produits ? Une souscription porte-t-elle son propre quota, ou seulement celui du produit ? Et la même souscription vaut-elle pour une API, un flux d’événements et un outil d’agent, ou faut-il trois écrans ?
Mis à jour en août 2026.