Interne et externe
Trois régimes d’exposition, quatre topologies de gateway et leurs conséquences en exploitation, avec les deux décisions coûteuses à prendre dès le départ.
Toutes les API d’une organisation ne partagent ni le même niveau de confiance ni le même rythme de changement. Décider combien de gateways servent quels flux est la décision d’architecture la plus structurante d’une plateforme, et la plus coûteuse à changer : ses effets sont visibles des consommateurs.
Trois régimes
| Interne | Partenaire | Public | |
|---|---|---|---|
| Consommateur | Équipes de l’organisation | Entreprises sous contrat | Inconnu, libre inscription |
| Authentification | Jeton de service, mTLS | OAuth2 client credentials, mTLS | OAuth2, clés d’API |
| Débit | Généreux, protection contre l’erreur | Contractuel | Strict, défensif |
| Changement | Rapide, négociable | Avec préavis contractuel | Lent, versionné |
| Enjeu dominant | Découplage | Engagement de service | Abus et coût |
Servir les trois avec une configuration unique force à choisir la plus contraignante. Les équipes internes héritent de quotas conçus pour des inconnus, contournent la plateforme, et la visibilité disparaît avec elles.
Quatre topologies
Gateway unique. Simple à exploiter, mais le régime le plus strict s’applique à tous, le trafic interne traverse la zone d’exposition, un pic public dégrade l’interne. Défendable en démarrage.
Deux gateways séparées. Une interne, une externe, souvent deux produits. Pannes et règles isolées, mais deux plateformes à exploiter et un risque de divergence entre deux définitions de la même API. La plus répandue dès qu’un flux partenaire existe.
Control plane unique, data planes multiples. Les API et policies se définissent une fois, des gateways se déploient par zone.
Control plane
API, policies, contrats, une seule fois
Data planes
Gateway interne
Réseau privé
Gateway partenaire
DMZ
Gateway cloud
Au plus près des services
Chaque zone garde des règles adaptées sans dupliquer les définitions. Le modèle exige une capacité d’exploitation multi-déploiements, et une lecture du contrat de licence : plusieurs éditeurs facturent par data plane. C’est la topologie vers laquelle convergent les plateformes matures.
Gateway externe et service mesh interne. L’exposition passe par la gateway, les appels entre services par un maillage. Le partage précis des rôles est traité dans gateway et service mesh.
Deux décisions à ne pas repousser
Les noms de domaine. Si trafic interne et externe partagent un nom, les séparer plus tard impose une migration à tous les consommateurs. Des domaines distincts dès le départ, même servis par une seule gateway, rendent la bascule invisible.
La frontière d’authentification. Fixer tôt où le jeton est validé et ce qui est transmis derrière, voir accès. Déplacer cette frontière touche tous les services à la fois.
La gateway comme aiguillage
Le point d’indirection sert aussi aux migrations : remplacer un système existant route par route, en déplaçant la règle de routage au fil des livraisons, sans bascule à date unique. La règle se pilote par route, par consommateur ou par pourcentage, et le retour arrière tient en une opération. Le piège de ces migrations est organisationnel, les routes difficiles restent et l’organisation finit par exploiter deux systèmes : une date de retrait de l’ancien, fixée au lancement et tenue, est le seul garde-fou qui fonctionne.
Le test qui juge une topologie tient en une question : si la gateway externe tombe, les équipes internes peuvent-elles encore travailler ? Si la réponse est non, le découpage est mauvais, quel que soit le produit.
Mis à jour en août 2026.