Les trois composants
Gateway, control plane, portail : le rôle de chaque brique d’une plateforme d’API, leurs régimes de fonctionnement, et pourquoi les évaluer séparément.
Trois briques techniques portent les cinq piliers. Elles ont des régimes de fonctionnement différents, des exigences de disponibilité différentes, et la plupart des éditeurs les vendent sous un seul nom. Les séparer est la première étape d’une comparaison sérieuse.
| Composant | Régime | Rôle |
|---|---|---|
| La gateway | Chemin de données, synchrone | Applique les règles à chaque appel |
| Le control plane | Chemin de contrôle, asynchrone | Déclare les API, les policies, les contrats |
| Le portail | Côté consommateur | Documentation, identifiants, essai |
Trois criticités différentes
La gateway est sur le chemin de chaque appel : sa panne arrête le trafic. Le control plane peut s’arrêter plusieurs jours sans conséquence, à condition que la gateway conserve sa dernière configuration connue. Le portail peut s’arrêter sans effet sur la production.
Un produit qui lie les cycles de vie des trois impose la criticité la plus haute à l’ensemble : une mise à jour du portail devient une opération à risque sur le chemin de production. La question mérite d’être posée en avant-vente, elle ne l’est presque jamais.
Ce que la séparation permet
Choisir séparément. Rien n’oblige à prendre les trois chez le même éditeur. Garder une gateway en place et changer de portail est un projet courant et raisonnable. Le portail est le composant le plus visible et le plus souvent décevant.
Déployer séparément. Plusieurs gateways dans plusieurs zones réseau, un seul control plane : c’est la topologie hybride décrite dans interne et externe.
Mesurer séparément. Un incident de portail n’est pas un incident de plateforme. Les confondre fausse les chiffres de disponibilité, et les décisions qui s’appuient dessus.
Mis à jour en août 2026.