Gouvernance des API à l'échelle & API Experience Hub (Course #api-governance)
For chefs de produit API, responsables de plateforme, architectes solution, responsables C4E.
À la fin, vous saurez
À l'issue de cette formation, vous serez capable de piloter la gouvernance comme une propriété mesurée de tout le patrimoine et d'exposer ce patrimoine à ses consommateurs — rulesets personnalisés, governance profiles, gates de conformité en CI, portail API Experience Hub brandé — afin que 90 % de conformité et un onboarding développeur en 30 minutes soient prouvés et non affirmés.
Cas fil rouge
Solvane Energy Group exploite ses intégrations de comptage, facturation et télémétrie réseau dans 9 pays : 340 API publiées dans Anypoint Exchange par 11 squads répartis sur 6 business groups, plus un catalogue wiki tenu à la main auquel aucun consommateur ne se fie. Une obligation d'accès aux données de comptage intelligent ouvre le patrimoine à 250 fournisseurs d'énergie externes sous 12 mois, et le premier échantillon d'audit relève 41 % de spécifications conformes à aucun standard partagé. Cibles : 90 % de conformité des spécifications face à un ruleset unique publié, zéro violation de règle de sécurité critique, time-to-first-successful-call développeur sous 30 min, p95 du portail sous 1,2 s à 4 000 développeurs simultanés.
Programme chaque ligne est quelque chose que vous faites
5 modules · 15 sujets · dans l'ordre du cours
-
Module 1
Mesurer le patrimoine avant de le corriger
Objectif. Diagnostiquer la conformité réelle du patrimoine Solvane à l'aide des governance profiles et des rulesets, et livrer le rapport de référence qui servira d'étalon à toutes les cibles suivantes.
- Appliquer les governance rulesets fournis par MuleSoft aux assets Exchange et lire de bout en bout le premier conformance summary (référence : 41 % des 340 API conformes)
- Cadrer les governance profiles par tag, catégorie et business group Exchange afin que chacun des 6 domaines soit filtré par exactement un profile actif — aucune API gouvernée deux fois, aucune laissée de côté
- Répéter en draft avant de publier : exécuter un profile à l'état draft, dénombrer les violations qu'il lèverait, et ne le passer en actif qu'une fois ce chiffre défendable
-
Module 2
Coder vos règles maison en ruleset
Objectif. Construire un governance ruleset personnalisé, le publier dans Exchange comme asset versionné, et câbler la gate CI qui arrête les specs OAS non conformes avant le merge.
- Amorcer avec anypoint-cli-v4 governance:ruleset:init, ou cloner puis durcir un ruleset MuleSoft, en codant 12 règles maison sur des documents OAS 3.x — nommage, pagination, modèle d'erreur RFC 7807, securitySchemes obligatoires
- Fixer la severity règle par règle, puis valider et livrer l'asset — governance:ruleset:validate, governance:document, exchange:asset:upload — pour que les 11 squads consomment une seule version épinglée du ruleset
- Verrouiller le pipeline sur governance:api:validate : le build échoue sur toute remontée de severity Violation, et le contrôle de spec reste sous 2 min par exécution
-
Module 3
Poser la cible, surveiller la dérive
Objectif. Évaluer la conformité de l'ensemble du patrimoine face à une cible datée et produire le backlog de remédiation attribué qui referme l'écart trimestre après trimestre.
- Lire le dashboard API Governance comme une métrique de patrimoine et non comme un verdict par API : governance coverage, services gouvernés par des controls, conformance status par business group
- S'engager sur une cible datée à l'échelle du patrimoine — 90 % de conformité sous 2 trimestres, zéro violation de règle de sécurité critique — et rattacher chaque écart restant à un propriétaire nommé et à une date
- Détecter la dérive après chaque publication : extraire le rapport de gouvernance chaque semaine et déclencher une alerte dès qu'un domaine passe plus de 5 points sous sa cible
-
Module 4
Monter le portail développeur
Objectif. Concevoir un portail API Experience Hub — organisation connectée, catalogue curé, pages brandées — qu'un consommateur externe découvre et parcourt sans aide.
- Connecter l'organisation Anypoint à Salesforce Experience Cloud, provisionner le portail depuis un template prêt à l'emploi en sandbox d'abord, et dimensionner les licences External Identity sur le volume prévu de demandes d'accès
- Curer le catalogue depuis Anypoint Exchange — API, serveurs MCP et services LLM — en n'exposant au plus que 2 versions vivantes par service, pour qu'aucun consommateur ne bâtisse sur une version vouée au retrait
- Brander les pages Home, API Catalog et API Details (logo, typographies, palette), puis tenir un p95 portail sous 1,2 s à 4 000 développeurs simultanés
-
Module 5
De la page d'accueil au premier appel
Objectif. Prouver le parcours self-service de bout en bout — demande d'accès, application cliente, premier appel réussi — et instrumenter l'entonnoir d'adoption qui juge le portail.
- Dérouler le workflow de demande d'accès en direct : un développeur demande l'accès à une instance d'API, un approbateur l'accorde, et les identifiants de l'application cliente sont émis sur le bon tier SLA
- Ramener le time-to-first-successful-call sous 30 min grâce à la documentation interactive et à un appel try-it fonctionnel sur une instance sandbox — chronométré sur un développeur qui découvre le portail
- Instrumenter l'adoption avec Google Analytics et le fil Chatter — vues du catalogue, demandes d'accès, taux d'activation — en visant 60 % des 250 fournisseurs inscrits appelant sous 30 jours
Références & documentation officielle chaque affirmation ci-dessus a une source
Module 1
- Appliquer des rulesets aux API identifiéesDoc MuleSoft
Module 2
- Spécification OpenAPI v3.1.0Spécification
- Commandes CLI pour API GovernanceDoc MuleSoft
- Créer des rulesets de gouvernance personnalisésDoc MuleSoft
Module 3
- Suivre la conformité des APIDoc MuleSoft
Module 4
- Gestion du catalogueDoc MuleSoft
- Connecter l'organisation à SalesforceDoc MuleSoft
Module 5
- Demander l'accès à une instance de serviceDoc MuleSoft