Design API-first pour Business Analysts (Course #api-design-thinking)
For business analysts, product managers.
À la fin, vous saurez
À l'issue de cette formation, vous serez capable de spécifier des exigences prêtes à l'API — revues RAML/OAS, critères d'acceptation, vérification sur mock — afin de maintenir les reprises sous 5 % de l'effort de sprint.
Cas fil rouge
La banque Norvia doit exposer 120 API comptes, paiements et KYC à des partenaires fintech sous une échéance open banking de 14 mois. Aujourd'hui, les specs circulent en Word, la recette détecte les ruptures avec des semaines de retard et trois squads ont déjà développé deux fois la même API client. Cibles : chaque endpoint mocké avant le sprint planning, fuite de défauts < 5 %, zéro rupture après la v1.0.
Programme chaque ligne est quelque chose que vous faites
4 modules · 12 sujets · dans l'ordre du cours
-
Module 1
Des user stories aux contrats
Objectif. Extraire les candidats API du domaine Norvia et cadrer chacun comme un produit doté de consommateurs nommés et d'objectifs de service mesurables.
- Extraire les candidats API des journey maps et événements métier, chiffrés en charge attendue, p. ex. paiement à 50 TPS en pointe
- Traiter chaque API comme un produit : consommateurs, niveaux de SLA et intention de dépréciation posés sur un canevas avant tout modèle OAS 3.x
- Rédiger des exigences générables telles quelles : ressources, paramètres de requête, payloads d'erreur — prêts pour RAML 1.0 ou OAS 3.x
-
Module 2
Lire une spec comme un architecte
Objectif. Évaluer une spécification RAML 1.0 ou OAS 3.x avant le sprint planning et écarter toute ambiguïté bloquante, constats à l'appui.
- Naviguer un document OAS avec intention : paths, components/schemas, responses, securitySchemes — et ce que chaque section engage
- Confronter RAML 1.0 et OAS 2.0 vs 3.x : links, callbacks, webhooks, sémantique des $ref — et ce que chaque format ne peut pas exprimer
- Passer une checklist de revue en 10 points — nommage, pagination, modèle d'erreur (RFC 7807), exemples — et consigner les défauts avant le sprint
-
Module 3
Critère passé, code commencé
Objectif. Spécifier des critères d'acceptation testables par endpoint et les éprouver contre le mocking service avant toute implémentation.
- Définir des critères Given/When/Then par endpoint, avec règle de clé d'idempotence sur POST /payments pour fiabiliser les retries client
- Spécifier classes de statuts, schémas de payload et contrats d'erreur par mode de panne, p. ex. 429 avec Retry-After en cas de throttling
- Éprouver le mocking service de Design Center contre chaque critère et transformer les écarts en défauts avant tout code
-
Module 4
Réutiliser avant de développer
Objectif. Auditer Anypoint Exchange avant chaque exigence et chiffrer le gain de réutilisation pour exclure les doublons du backlog.
- Rechercher dans Anypoint Exchange par capacité, tag et propriétaire ; présélectionner sur dernière version, doc et usage réel
- Contester un doublon chiffré à l'appui, p. ex. réutiliser l'API Client économise ≈ 40 jours-dev et une dette de maintenance à vie
- Convertir les conclusions en décisions de backlog — adopter, étendre ou wrapper une API existante — avec l'impact version énoncé (mineur/majeur)
Références & documentation officielle chaque affirmation ci-dessus a une source
Module 1
- Présentation d'APIkitDoc MuleSoft
Module 2
- Spécification OpenAPI v3.1.2Spécification
- RFC 9457 — Problem Details pour les API HTTPSpécification
- Présentation d'Anypoint API GovernanceDoc MuleSoft
Module 3
Module 4
- Versions des assetsDoc MuleSoft
- Rechercher des assetsDoc MuleSoft