API Management Platform - Partie 1 : Contexte et Besoin Business
Le Contexte
Chez Sodexo, le groupe avait standardisé sur Azure API Management (APIM) comme solution d’entreprise pour exposer et gérer les APIs de toutes les Business Units. Chaque BU devait pouvoir publier ses APIs de manière sécurisée, gouvernée et standardisée.
Choix d’Architecture : APIM Partagée
Décision Clé
Une instance APIM mutualisée (partagée) pour toutes les Business Units.
Pourquoi Partagée ?
1. Gestion des Coûts
- Une instance APIM Premium coûte plusieurs milliers d’euros/mois
- Une instance par BU = coûts prohibitifs (15+ BUs)
- APIM Partagée = coûts divisés par le nombre de BUs
2. Gouvernance Centralisée
- Politiques de sécurité uniformes
- Gestion centralisée des certificats
- Monitoring consolidé
3. Simplification Opérationnelle
- Une seule instance à maintenir
- Pas de multiplication des configurations
- Gestion des mises à jour simplifiée
Implications Techniques
L’architecture Partagée impose des contraintes techniques fortes :
- Isolation logique : Chaque BU a son propre Product APIM
- Subscriptions dédiées : Clés API par BU
- Nommage strict : Conventions pour éviter les collisions
- Quotas : Limitation par BU pour éviter la saturation
Le Besoin
Objectif
Créer un système permettant aux Business Units autonomes de publier leurs APIs sur l’instance APIM Partagée sans créer de goulot d’étranglement centralisé.
Contraintes Identifiées
- ✅ Self-service : Les équipes doivent être autonomes
- ✅ Isolation : Chaque BU ne voit que ses ressources
- ✅ Sécurité : Pas de credentials en clair
- ✅ Standardisation : Patterns identiques pour toutes les BUs
- ✅ Scalabilité : De 1 à N Business Units sans friction
- ✅ Gestion des coûts : Partage de l’infrastructure
Feuille Blanche
Point important : Il n’y avait aucun processus existant à améliorer.
Nous sommes partis d’une page blanche pour concevoir un système complet d’onboarding automatisé sur une infrastructure Partagée. Cela nous a permis de :
- Concevoir l’architecture idéale sans contrainte d’existant
- Choisir les bonnes technologies (Azure DevOps Extensions, Marketplace)
- Définir les patterns de bout en bout
- Anticiper les besoins de scalabilité