Apisation, Decryptage des concepts, des usages et préconisations de mise en oeuvre

1. 1
© Club Urba-EA
APIsation
Eclairage sur les concepts, les usages et
préconisations de mise en œuvre
Nicolas CHEVALIER - Glue N’DO
Bruno RIZZI - Consultant Indépendant
Projet 2016 - Rapport final

2. Rejoignez les 80
entreprises adhérentes
et plus de 100 membres
actifs sur urba-ea.org

3. Rejoignez les 80
entreprises adhérentes
et plus de 100 membres
actifs sur urba-ea.org

4. © Club Urba-EA 4
SYNTHESE
Le projet s’inscrit dans la
continuité des projets
menés depuis plusieurs
années par le Club Urba-EA
:
• dans la promotion des
vues fonctionnelles et
l’architecture en mode
service
• dans l’évolution des SI
qui accompagne la
transformation
des entreprises.
La transformation numérique des entreprises et de leur écosystème (partenaires, clients…)
nécessite de revoir les modèles de collaboration et d’échanges.
Pour faciliter l’évolutivité et la souplesse dans les recompositions de services, il devient indispensable
d’adopter des langages d’échanges des services simples et compréhensibles (on parle de
services « affordants », c’est-à-dire autoportants et directement utilisables).
Il s’agit de pouvoir opérer et s’intégrer dans des business model toujours plus coopératifs et
mouvants en considérant notamment les développeurs comme des clients.
Les API revêtent à la fois un enjeu stratégique et technique :
> Stratégique car il s’agit de pouvoir développer et s’intégrer dans le plus de business models
possible
> Technique car il s‘agit de disposer de frontaux SI sécurisés qui masquent la complexité et
permettent de valoriser aux mieux les actifs IT existants.
 Selon les cas, la mise en place des API est conduite localement par des initiatives métiers ou SI
visant à répondre à un objectif défini où s’inscrit dans des approches plus globales de
• Open data (SNCF)
• Programme de transformation digitale (ENGIE)
• Reconfiguration des écosystèmes et règles business (Banques ou assurances)
• Conversion des SI au mode service (SNCF)
• Stratégie omni-canal (Groupe Rocher)
• Simplification administrative (API.gouv.fr)

5. 5
© Club Urba-EA
GROUPE DE TRAVAIL
Bruno RIZZI Consultant indépendant
Nicolas CHEVALIER Glue N’DO
Farouk ABDOU MINISTERE DE LA DEFENSE
Eric BELOUET MNH
Richard BLONDEL ENGIE
Isabelle BOUDARD SNCF
Nicolas CHAIGNAUD EDUCATION NATIONALE
Erwan COLOMB SNCF
Malcy de LECHENAULT GENERALI
Steeve EWORE EDUCATION NATIONALE
Raphael FOUILLET GENERALI
Michel KEROMNES MINISTERE DE LA DEFENSE
Slobodan KOSUTIC BNPP
Jerome MEULAND KIABI
 Ont participé aux travaux du projet
 Animation du projet et rédaction du rapport
Gilles MULLER GIES
Pierre NENERT GROUPE ROCHER
Olivier NISSE MINISTERE DE LA DEFENSE
Max PAURON MINISTERE DES FINANCES
Remi PEYRONNET BANQUE DE FRANCE
Pierre POUJOL CREDIT AGRICOLE
Jean-Charles QUANTIN SNCF
Franck RIGAUD-CROISE LCL
Pascal SQUARCIONI INSEE
Nicolas VERNEY GDF SUEZ
Jeremy WAELKENS MNH

6. © Club Urba-EA 6
Réunion N°1
Mars
• Retours Etat de l’art API (Groupe ROCHER)
• Présentation du programme API (SNCF)
Réunion N°2
Avril
• Exploitation des matériaux et de la littérature sur les APIs
(ateliers de management visuel)
Réunion N°3
Mai
• Echanges sur les clefs de construction d’une API
Réunion N°4
Juin
• REX modélisation service (SNCF)
Mardi Urba-EA
Septembre
• « API: levier de transformation ? »
Retours d’expérience et table ronde ENGIE , La POSTE, SNCF
Réunion N°5
Octobre
• Relecture et compléments au rapport
Les conclusions du groupe
de travail s’appuient sur
des retours d’expérience et
bonnes pratiques
partagées lors de
différents événements
consacrés au sujet en
2016.
Elles s’appuient également
sur différentes ressources
documentaires
notamment
• Les rapports des
projets menés par le
Club sur des sujets
connexes
• L’étude des
publications des
sociétés de conseil,
éditeurs et acteurs
de la veille SI.
LES ENTRANTS DU PROJET

7. © Club Urba-EA 7
PRÉAMBULE : DE QUOI PARLE-T-ON ?
Les programmes API sont
dans la continuité des
services menés depuis de
longues années dans les
organisations.
Les principales différences
portent sur :
• L’ouverture vers
« web first »
• La compatibilité aux
approches cloud
• Le focus : il s’agit d’un
produit, à vendre
• L’absolu simplicité du
langage
• La sécurité, intrinsèque à
l’API
• L’utilisabilité, immédiate
UN SERVICE !

8. © Club Urba-EA 8
PRÉAMBULE : DE QUOI PARLE-T-ON ?
Les solutions d’API
management aident à la
création, l’utilisation et
l’administration des APIs
Ce sont des solutions qui
sont complémentaires aux
autres solutions d’intégration
restant indispensables pour
les pans du SI qui ne seront
durablement pas gérés sous
forme d’API , à savoir :
- Les échanges de gros
volume ou nécessitant des
transformations
importantes (ETL)
- Les échanges intra-SI en
mode message ou
asynchrone ou nécessitant
des logiques
d’orchestration en mode
push (ESB)
UNE SOLUTION
D’INTEGRATION !
Source : Nexworld pour le Groupe Rocher

9. © Club Urba-EA 9
SOMMAIRE DU RAPPORT
CHAPITRE 1 API = POURQUOI FAIRE ?
CHAPITRE 2 ECLAIRAGE SUR LES PROGRAMMES D’API-SATION
CHAPITRE 3 BONNES PRATIQUES DE CONSTRUCTION D’UNE API
CHAPITRE 4 PLATEFORME D’API MANAGEMENT
CHAPITRE 5 CHANGEMENTS ET FACTEURS CLEFS DE SUCCES

10. © Club Urba-EA 10
10
CHAPITRE 1
• L’enjeu d’ouverture
• Principales motivations
• Communiquer avec les décideurs
• Parler à ces clients
Retours d’expériences : Ce qu’ils nous en disent : La poste, SNCF, ENGIE
Sommaire du chapitre
API = POURQUOI FAIRE ?

11. © Club Urba-EA 11
L’enjeu d’ouverture
Les API sont avant tout un
moyen d’ouverture des
business model et doivent
favoriser la collaboration
externe sur les chaines de
valeur et activités cœurs de
l’organisation.
Dans une vision plus en
il s’agit de pouvoir être
et activable en tant
qu’opérateur de services
dans le cadre de business
models établis dans une
étendue en écosystème
soi-même ou par d’autres).
Business
Model
INTERNALLY
CO-CREATION
ACTIVABLE SERVICE
BusinessModelN°2

12. © Club Urba-EA 12
Principales motivations
Au sein du groupe de travail, 4
familles de motivations ont été
identifiées :
- L’enrichissement des
externes : les APIs comme
moyen de sécuriser le SI et les
échanges, de promouvoir et
diffuser ses services, de
faciliter la digitalisation des
échanges
- La vision business et
: Les APIs comme une réponse
aux exigences d’ouverture
(SNCF, Banque et Assurance,.),
un enrichissement des
business models et une
meilleure résilience ou agilité
par la décomposition
business/SI
- Les motivations techniques :
levier de standardisation,
d’indépendance de
plateforme, d’efficacité du
développement, de
recomposition SI et de
simplicité des échanges.
- La collaboration interne :
Transformation
Numérique
Agilité
Obligation
légale
Efficacité du
Développement
Taux de
succès projet
Promotion de
services
Digitalisation de
la relation tiers
Surveiller et
contrôler les usages
Levier de
standardisation
Maitrise de la
sécurité
Evolution des
business model
Crowd
Sourcing
Enrichissement
des transactions
Multi
Device
Api-sation
de l’entreprise
Flexibilité SI
Développer la
transversalité
Partenariat
technologique
Intéropérabilité
Ouverture
SI
MOTIVATIONS
STRATÉGIQUES
OUVERTURE &
RELATIONS EXT.
COLLABORATION
INTERNE
MOTIVATIONS
MOTIVATIONS
SI
Open
innovation
Accès aux
données
Simplification
des relations

13. © Club Urba-EA 13
Argumentaire API
Communiquer avec ces investisseurs
La communication sur les API
devrait, selon gartner, s’articuler
suivant 3 axes de
préoccupations majeurs pour
les décideurs :
- L’appui à la stratégie et
transformation digitale : Les
comme levier et axe de
transformation
- La croissance : Les API pour
s’ouvrir de nouvelles
opportunités, de nouveaux
canaux, co-entreprendre
- L’attractivité et l’innovation :
API comme vecteur
d’acculturation interne,
d’identification et
développement de talents

14. © Club Urba-EA 14
Argumentaire API
Parler à ces clients
PRÊT A L’EMPLOI
INTERNE
EXTERNE
PARTENAIRES
SCALABILITE
ACCESSIBILITE
Une API est un produit « à
vendre » à des développeurs ;
internes ou externes,
expérimentés ou novices.
Un développeur est un client
exigeant qui :
- S’attend à être écouté
Co-construction des API !
- Va devoir être séduit
« Marketing » API !
- Veut comprendre par lui-
des API affordantes!
- Attend une offre claire et
attrayante
Portail API !
- Veut avoir des engagements
bénéficier d’une « après-
SLA API !
- Souhaite bénéficier des
innovations au moindre
Versionning API !
Quelques « arguments de ventes » …
SIMPLICITE
UTILITE RECONNU

15. © Club Urba-EA 15
Retours d’expériences sur les motivations
REX La POSTE :
La poste a lancé une initiative
API avec des objectifs :
- exploratoires sur l’appétence
du marché et les possibilités
de nouveaux business model
model
- de transformation sur le time
to market, le renforcement de
de la relation client, l’image,
les capacités de collaboration
collaboration et la
transformation interne

16. © Club Urba-EA 16
Retours d’expériences sur les motivations
REX ENGIE :
ENGIE positionne des enjeux
métiers et SI autour des APIs sur
sur les:
- Relation avec les SI externes
- La génération de nouveaux
business
- Les interconnections internes

17. © Club Urba-EA 17
Retours d’expériences sur les motivations
REX SNCF:
Historiquement, le sujet API
publique a été tiré par les
exigences réglementaires
d’ouverture de données (open
data).
Le programme API est construit
dans une perspective d’ouverture,
d’ouverture, d’agilité et de fluidité
des échanges avec ses
partenaires, en interne et auprès
du publique.
- Il est mené en continuité de
l’approche service SOA conduit
par la DSI.
- L’objectif business open data est
est de développer l’audience (la
(la législation ne permet pas
d’aller au-delà)
La SNCF chercher à développer de nouveaux usages sur base de l’ouverture de leurs
données et ainsi développer l’audience et faciliter l’accès à leurs services.
La SNCF construit un
programme d’API qui s’adresse
à différentes populations :
publiques, partenaires et interne
au groupe SNCF

18. © Club Urba-EA 18
CHAPITRE 2
• Principes de navigation
• Approche top-down ou bottom-up ?
• SOA et API, complémentarité
Sommaire du chapitre
ECLAIRAGE SUR LES
PROGRAMMES D’API-SATION

19. © Club Urba-EA 19
19
« L’environnement »
• Affaiblissement des frontières SI
• Evolutivité des business model
• Evolution des usages et attentes utilisateurs (UX)
• Fonctionnement en ecosystème
• Emergence de l’IoT
• Multiplication des canaux
Ce qu’il faut emmener ou maitriser
1. Les plateformes (développement,
automatisation, exécution, management)
2. L’offre produit (fait pour ces clients et répondant
à des usages)
3. La politique de sécurité
4. La gestion du cycle API
5. La contractualisation client
Les « pilotes »
• Les architectes de services
• Les responsables de produits
(propriétaires métiers)
Le « vent arrière »
• Les exigences du mode cloud
• L’offre du marché « API » (on réutilise
et on ne créé plus)
• Les initiatives business
• La réglementation
• Les programmes digitaux
Les « foils »
• La conversion des éditeurs aux APIs
• Les échanges avec les acteurs du web
• Les nouvelles architectures
d’intégration avec API management
Les « passagers »
• Les décideurs : nos investisseurs
• Les développeurs : nos clients primaires
La « trainée » (les freins)
• La résistance au changement
(surtout côté DSI)

20. © Club Urba-EA 20
Approche TOP-DOWN : L’exemple ENGIE (1/2)
REX ENGIE:
ENGIE a lancé courant 2016 un
programme de transformation
digital ambitieux et accéléré dont
dont le projet API est un des 5
projets cœurs.
Le programme d’API-sation
s’inscrit ainsi dans un cadre de
transformation portée par la
Direction générale, déclinée
dans toutes les Business Units
par des plans dédiés
business/IT.

21. © Club Urba-EA 21
Approche TOP-DOWN : L’exemple ENGIE (2/2)
REX ENGIE:
Le chantier API ENGIE est
couplé à la création des Apps
(renforce la dimension
« produit ») et s’articule autour :
autour :
- De travaux préalables autour
de fondamentaux nécessaires
à sa réussite : Business
cases, méthodes agiles,
diagnostic….
- La création de factories : de
prototypes aux plateformes
d’industrialisation
- La mise en place de standards
et préconisations groupe sur
sur le rôle de l’API factory,
l’architecture SI les aspects
juridiques, sur la sécurité, les
les achats, les RH,…
Il s’agit de s’appuyer sur ce qui
qui existe dans les BU et de
faciliter leur développement et
des réalisations rapides en
apportant une vision, des
 Plus de 100 APIs référencées
 Co-existence coordonnée et durable de plusieurs plateformes d’API management

22. © Club Urba-EA 22
Approche BOTTOM-UP: L’exemple La poste
REX LA POSTE:
La POSTE après une première
tentative a fait le choix de
construire une plateforme d’API
d’API management « from
scratch », peu chère, facile à
maitriser et à mettre en œuvre
pour ces 4 premières APIs.
Les perspectives de mise en
place de « contrats » nécessitera
nécessitera des migrations sur
des plateformes plus riches
d’API management.

23. © Club Urba-EA 23
23
Complémentarité SOA et API
 Les retours d’expérience
collectés montrent que les
initiatives autour des APIs
sont largement accélérées
par la SOA, qu’elle soit –
idéalement - existante ou
mise en place en parallèle.
 Dans ce dernier cas, les
organisations souhaitant
déployer des APIs trouvent
des solutions temporaires
ou de contournement pour
palier à l’absence
d’architecture de services, la
SOA étant une démarche de
long terme.

24. © Club Urba-EA 24
CHAPITRE 3
BONNES PRATIQUES DE
CONSTRUCTION D’UNE API
Sommaire du chapitre
• Les types d’API et leurs usages
• Qu’est-ce qu’une « bonne » API
• Commencer par le besoin métier et le business model
• La phase de design : une étape cruciale
• Implémentation et connexion aux back-ends
• Politiques de souscription et sécurité
• Au delà de la construction de l’API
• Points de vigilance

25. © Club Urba-EA 25
25
Le type d’usage des APIs les
plus fréquemment évoqué est
l’usage ouvert vers l’extérieur
(Cloud, Mobilité, OpenAPI)
Toutefois la mise en œuvre
d’API privée, en intra-SI par
exemple, permet des modes
d’intégration plus découplés et
flexibles avec à la clé des
opportunités de réductions de
coûts.
Pour autant, les APIs n’ont
vocation à se substituer à des
architectures d’intégration
traditionnelles
Les types d’API et leurs usages

26. © Club Urba-EA 26
Qu’est-ce qu’une « bonne » API
REX SNCF:
Une API doit :
- Etre pensée comme un produit
produit pour ces clients
développeurs
- Etre indépendante de la
technologie
- Prendre en charge les points
clefs d’interface: sécurité et
performance
- Etre affordante : facile à
appréhender
- Prendre en compte le contexte
contexte d’utilisation (mobile,
IoT, accès au legacy par
exemple)

27. © Club Urba-EA 27
Commencer par le besoin métier et le business model
1. Définir le besoin métier :
pourquoi ai-je besoin d’une API ?
- Le métier a la responsabilité de
définir l’usage et le périmètre de
de l’API
- Améliorer l’engagement des
clients, mieux utiliser les relations
relations avec les partenaires
pour améliorer la proposition de
de valeur, améliorer un processus
processus interne en accédant à
à des informations transverses, …
…
- Il en fixe les objectifs: quels sont
sont les résultats tangibles et
mesurables sont attendus ?
2. Choix d’un business model
- Monétisation directe ou indirecte
indirecte
- Avec ou sans rétribution des
développeurs
- Gratuit: obligation réglementaire,
réglementaire, promotion de
l’image de l’entreprise, service
interne en coûts transverse
Source : John Musser, programmableWeb

28. © Club Urba-EA 28
La phase de design : une étape cruciale
Le principe maître est Design First :
penser à l’implémentation ensuite
ensuite pour ne pas compromettre
compromettre l’expérience
développeur (DX)
- Les spécifications d’une API
doivent être compréhensibles
facilement par un humain. Elles
sont claires, précises,
cohérentes, naturelles et
intuitives.
- Une API répond à un usage. Elle
n’expose pas le modèle de
données interne dans le jargon
fonctionnel de l’entreprise.
- Les utilisateurs de l’API doivent
doivent être embarquées dans le
le processus de design et de test
test par mock-up avant
l’implémentation
- Il est conseillé d’utiliser une
structure et des patterns
réutilisables d’une API à l’autre
pour gagner du temps et en
Source : Imaginea
Ceci nécessite de porter un regard critique sur l’architecte pendant la phase de design

29. © Club Urba-EA 29
Implémentation et connexion aux back-ends
Une fois l’API définie, elle doit
être implémentée en se
connectant aux services de
end et aux applications qui
l'alimentent.
Ne pas coder en spécifique de
logique de transformation
métier ou d’orchestration dans
la couche d'API.
Ce type de raccourci est une
source de problèmes
d’évolutivité et de
maintenabilité à moyen terme.
Il faut alors s’appuyer sur les
capacités d’intégration et
d’orchestration d’une
plateforme d’intermédiation de
type ESB.
L’architecte communique avec
les équipes de réalisation qui
implémentent la partie « back-
end » pour s’assurer de la
cohérence de l’ensemble.
Consommateurs
API Management
ESB
Exposition des services Back-end
Service 1 Service 2 Service 3 Service N…
API Simple
API agrégation
technique
API avec
complexité
métier
Systèmes Back-end
• Exposition de services existants
• se comporte comme simple proxy
• Changements de présentation de
données sans logique métier
 rapide à créer et configurer
• Nécessite plusieurs systèmes back-
end potentiellement vieillissants
• Logique métier dans l’orchestration
des appels
• Transformations complexes
 utiliser L’ESB pour l'intégration et
l'orchestration
• Agrégations technique de données
sans logique métier
• transformations techniques simples
des données
 implémentation d’une API
complexe

30. © Club Urba-EA 30
Gérer les politiques de souscription et la sécurité (1/2)
Les politiques de souscriptions
permettent de définir les
conditions d’utilisation des APIS
- Quelle type d’authentification ?
?
- Quelle consommation autorisée
autorisée en volume et en
appels simultanés ?
- Quel comportement au delà de
de ces seuils?
- Etc…
Leur application permet de :
- protéger les fournisseurs de
service de pics de charge
dépassant leurs capacité,
- d’honorer les SLA envers
l’ensemble des consommateurs
consommateurs d’APIs

31. © Club Urba-EA 31
Gérer les politiques de souscription et la sécurité (1/2)
L’aspect sécurité à gérer à ce
stade regroupe principalement:
- l’authentification: l’utilisateur
bien connu du système ?
- les autorisations: a-t-il bien le
droit d’accéder à ce qu’il
demande ?
LDAP est la solution la plus
courante APIs internes et OpenID
et OAuth deviennent les
standard de fait pour les APIs
externes.

32. © Club Urba-EA 32
Au delà de construction de l’API
Le portail développeur est un outil indispensable de promotion et de management.
• C’est le point de contact et d’interaction privilégié avec les utilisateurs développeurs
La communication ne doit toutefois pas être limité à ce canal technique
• Compléter les données factuelles d’usage capturées par les systèmes de monitoring par des témoignages
utilisateurs
• Faire de la publicité et des campagnes de promotions par d’autres canaux
Utilisez toutes les informations recueillies pour mesurer l’atteinte des objectifs initialement définis et progresser
La vie d’une API commence
après sa mise en production
• Son succès dépend de son
adoption initiale par ses
utilisateurs / développeurs
• Et de leur fidélisation dans
le long terme.
• C’est donc un produit qu’il
faut marqueter, promouvoir
et faire évoluer
Il ne suffit pas de construire
API, il faut la promouvoir et
faire vivre.
Favoriser l’adoption
• Parcours de souscription simple
• Guide de démarrage rapide
• Template type « hello world »
• Documentation interactive à jour
• Outil de test en ligne
Communiquer
• Animer la communauté
• Promouvoir les API
Monitorer
• Usages réels des APIS

33. © Club Urba-EA 33
Points de vigilances
Design first : Un point clé
Etre sans compromis sur l’utilisabilité et l’expérience développeur pour maximiser les
chances d’adoption de l’API
Approche API first
Spécifier l’API puis coder ou intégrer le back-end au lieu de créer une application et de
proposer une API par-dessus
Tester tôt avec les consommateurs finaux
L’interface doit être testée sur des bouchons (mock-up) avant même le développement ou
le raccordement aux back-ends
L’API doit pouvoir être trouvée rapidement
Un Portail est nécessaire à la rendre visible, découvrable et accessible
Se focaliser sur les besoins immédiats
le futur est trop fluctuant : délivrer et répondre rapidement aux besoins avérés
Promouvoir et faire évoluer l’API en prenant en compte les retours d’expérience et les
usages constatés
Le produit API doit et peut
être envisager dans une
logique de Minimum
Valuable Product privilégié
le mondes des start-ups pour
s’assurer de son adéquation
au marché

34. © Club Urba-EA 34
CHAPITRE 4 PLATEFORME D’API MANAGEMENT
Sommaire du chapitre
• Les exigences couvertes par l’API Management
• API et ESB : différences et recouvrements
• Les fonctionnalités d’une plateforme d’API management
• Objectifs de la construction de l’API management
• Les étapes de la mise en place
• Choisir une solution
• Les éditeurs de solution
• Solution Open Source ou éditeur
• Les invariants d’un bonne plateforme d’API management
• Une architecture de plateforme en 4 couches

35. © Club Urba-EA 35
35
Les exigences couvertes par l’API management
 Les plateformes d’API
management permettent
d’exposer et de gérer
simplement sous forme
d’API des services offerts
par les Back-ends du
système d’information.
 Au-delà d’être un
point d’accès centralisé,
standardisé et sécurisé en
« run-time », elles doivent
permettre
l’administration des API
l’intégralité des
évènements du cycle de
vie de celles-ci.
 En particulier elles
permettent
l’établissement de
entre fournisseurs et
consommateurs basées
des politiques spécifiant
les SLA et les conditions
d’utilisations telles que la
volumétrie acceptable
Source : Nexworld pour le Groupe Rocher

36. © Club Urba-EA 36
36
 Les APIs, tout comme la
SOA, permettent d’exposer
des services.
 Toutefois, ces deux types
d’architectures ne sont pas en
concurrence directe et au
contraire sont
complémentaires l’une de
l’autre au sein du Système
d’informations.
L’API-sation du S.I. : Point de vue technologique
API et ESB : Différences et recouvrements
Source : Nexworld pour le Groupe Rocher

37. © Club Urba-EA 37
37
L’API management apporte
dans les S.I. des capacités
manquantes ou incomplètes
dans ESB qui ont été conçus
pour assurer une intégration
transverse entre applications
dans des conditions maîtrisées
maîtrisées a priori:
- la sécurité vis à vis d’une
exposition vers l’extérieur
- la facilité de mise en œuvre
œuvre
- la gestion des volumes de
transactions
API management et ESB
Source : Nexworld pour le Groupe Rocher

38. © Club Urba-EA 38
38
Une plateforme d’API
management est composée de
deux composants:
- La Gateway est le
de la plateforme. Elle
expose les APIs et en assure
la sécurité, l’implémentation
des SLA via les contrats et le
monitoring
- Un portail permettant
part aux fournisseurs de
publier les APIs et les
contrats d’utilisation et
d’autre part aux
consommateurs de
découvrir et de souscrire
aux APIs.
Il fournit également des
fonctions de reporting.
Les fonctionnalités d’une plateforme d’API management
Source : Nexworld pour le Groupe Rocher

39. © Club Urba-EA 39
Objectifs de la construction de l’API management
Les objectifs d’une plateforme
d’API management dépendent à
la fois du contexte de l’entreprise
et de la stratégie métier qu’elle
doit supporter:
- API internes ou OpenAPI ?
- Quels canaux pour quels
usages ?
- Déploiement local ou
international?
- Plateforme unique ou multiple,
architecture centralisée ou
fédérée ?
- Quels services et applications
back-ends à intégrer ?
Il s’agit de la mission habituelle
de l’architecte : aligner les
évolutions du système
d’information sur l’évolution du
métier qu’il supporte.
Source : Engie

40. © Club Urba-EA 40
Les étapes de la mise en place de l’API management
Bien qu’il n’existe pas plus de démarche universelle que d’architecture unique pour l’API, certaines étapes
ou jalons sont quasiment obligatoires quelque soit la démarche utilisée
 Faire émerger et cadrer les premiers besoins
• Démystifier et expliquer les APIs au delà du buzzword
• Communiquer autour des usages avec le métier
 S’outiller et faire évoluer ces plateformes
• Gestion en mode plateforme(s) évolutive(s)
• S’assurer que les plateformes de modélisation, de développement et d’éxécution sont au
niveau
 Publier des APIs prêtes à l’emploi
• L’utilisation d’un référentiel central est
primordiale. Il doit faciliter la découverte
de l'API et son accès.
• La documentation et les forums
permettent aux développeurs d'évaluer
l’adéquation d'une API à leurs besoins
et rapidement commencer à l’utiliser.
Source : MuleSoft

41. © Club Urba-EA 41
Les étapes de la mise en place de l’API management
Mettre en place une gouvernance avec le métier
 La gouvernance des APIs est intimement liée aux objectifs métiers relayés par l’IT.
• Les décisions sont prise conjointement par le métier et l’TI, en partie sur la base des
données remontées par la plateforme d’API management telles le niveau d’adoption via
les souscriptions et les contrats passés, et l’usage via les statistiques d’utilisation des
APIs et éventuellement les revenus générés.
• Doivent également être prise en compte, même s’ils sont plus difficiles à capturer, les
gains de productivité pour les équipes utilisant les API et les retours qualitatifs des
utilisateurs.
 Les orientations et les décisions issues du processus de gouvernance constituent des entrants pour
les phases de design des APIs tant pour les nouvelles versions que pour les nouvelles APIs.
 Une bonne compréhension de l’usage et de l’adoption des APIs permettent au métier d’investir avec
discernement et à l’architecture gérer les évolutions de l’infrastructure qui porte les APIs.
 Elles guident également l’établissement ou la révision des politiques de souscriptions

42. © Club Urba-EA 42
Choisir une solution logicielle d’API management
Quels que soient les objectifs et la
démarche, il est indispensable de
choisir avec soin la solution d’API
management afin de construire un
socle robuste et évolutif
Plusieurs retours d’expérience
témoignent de changements de
choix de solution logicielle
dans les deux premières années
- Question de maturité de
l’organisation au moment du
- Problème de complétude de
certaines solutions par rapport
aux besoins à couvrir
- Illusion d’un l’openSource
menant à des choix finalement
inadapté pour des contraintes
budgétaires
Certaines organisations font le
choix d’une solution développée
en interne pour des raisons à la
financières et de besoins limités du
point de vue des fonctions.
Cette approche peut permettre de
lancer une initiative autour de l’API
mais se révèle à l’usage peu

43. © Club Urba-EA 43
Les éditeurs de solutions d’API Management
 Les offres de éditeurs se sont largement étoffée et stabilisées ces dernières
années et on peut les considérer comme techniquement matures.
 Certains éditeurs indépendants ont été rachetés par des poids lourds de l'industrie
logicielle pour positionner rapidement sur un marché en forte croissance
• Mashery racheté par TIBCO
• Layer7 racheté par Computer Associates
• Apigee racheté par Google en 2016 bénéficie d’un portefeuille de
clients important
 L’offre openSource existante est crédible mais avec des limitations.
 La plupart de ces solutions sont disponibles en mode SaaS.
Google
API Connect
Layer7
WSO2
API Gateway
3Scale
AKANA
Axway
API mgt suite
Mule API Manager
TIBCO
Service Gateway

44. © Club Urba-EA 44
Les éditeurs de solutions d’API Management
Le point de vue des analystes

45. © Club Urba-EA 45
Solution Open Source ou Éditeur ?
 Pas trop de contraintes de sécurité ;
 Accepter de déployer un nouvel ESB ;
 Etre en capacité infinie de faire des développements custom pour certaines solutions
• Accepter d’être moins agile!
 La (seule) vitrine de vente pour les revendeurs OpenSource est le portail ;
 L’Open Source n’est pas gratuit ;
 Pas de vrai REX dans des environnements contraints.
Open Source éligible si et seulement si
 Répondre rapidement aux attentes en termes de sécurité et de performance
• Facilité de mise en œuvre – agilité;
 Compétences sur le marché ;
 Des clients existants avec qui dialoguer et de solides références en production;
 Accepter de dépenser à peine plus en licences.
Editeur spécialisé toujours éligible
Source : Nexworld pour le Groupe Rocher

46. © Club Urba-EA 46
Invariants d’une bonne plateforme d’API Management
Source : MuleSoft
•Médiation multi-protocoles (JMS, RMI, SOAP)
•Orchestration (adaptation de services multiples, agrégation, branches conditionnelles)Intégration API - back-end
•Gestion de la pénurie (écrêtage des pics de consommation, quotas, etc…)
•Amélioration de la performance par du cache et des mécanismes de gestion de mémoireDisponibilité et protection des backends
•Sécurisation des échanges (SSL, PKI, cryptage, signatures, détection des menaces)
•Authentification et autorisations (API key, OAuth, OpenID, SAML, LDAP, IAM propriétaires)Gestion de la sécurité
•Mesure de l’usage : globale, par application consommatrice, par API
•Support à la monétisation et à la facturationMonitoring et l’analyse du trafic
•Gestion des versions, mécanismes d’aiguillage pour la rétrocompatibilité
•Déploiement à chaudGestion cycle de vie de l’API
•Outils communautaires
•Parcours de souscription facilité (génération de Client ID/App Key , Interactive API console)
•Fonctions de découverte des APIs (Catalogue, recherche et provisionning)
Portail développeur et communication
•Outils de prototypage (OpenAPI / Swagger, RAML)
•Test d’API bouchons (mocks)
•Outils de debugging
Création et réutilisation des APIs
•Support de l’intégration Mobile (notification, géolocalisation, …)
•Déploiement Flexible et scalable (on-premise, cloud, hybride, clusters)Compatibles Cloud et mobile
•Positionnement comme une plateforme transverseAgnostique par rapport au métier

47. © Club Urba-EA 47
Une architecture de plateforme en 4 couches
Délivre l’expérience client
Repose sur des standards de fait :
Bootstrap, Angular, Cordova, Ionic
Implémenté via la composant
« gateway » de la plateforme
Les APIs proposent un « Modèle »
cachant la complexité et
l’hétérogénéité des services sous-
jacents
services « sur site » ou cloud, en
incluant le legacy
Source : Forrester

48. © Club Urba-EA 48
CHAPITRE 5 BILAN ET PERSPECTIVES
• Des défis majeurs
• Quelques challenges d’architecture
• De nouvelles gouvernances
• Retour SNCF : organisation et rôle de l’architecte de service
• Partage de bonnes pratiques
• Rôle de l’architecte de service
Sommaire du chapitre

49. © Club Urba-EA 49
Des défis majeurs
Budget
Les entreprises fonctionnement historiquement en projet et applicatifs structurés par
besoins et domaines fonctionnels dans des logiques planifiés. La transversalité et
l’investissement agile pour des API est un défi majeur.
Fonctionner en cycle court
L’enrichissement rapide et l’évolution des API dans un cadre de client/fournisseur pose le
double défi de l’agilité côté « fournisseur » et côté « client ».
Exposition et gestion du risque
Les API sont de nouveaux produits qui nécessitent de maitriser de nouveaux aspects tels
que le cadre juridique, domaine structurellement à temps long. L’anticipation, l’’exposition
mais aussi la gestion du risque sont essentiels à la conduite du programme d’API-sation.
Réconcilier les attentes
Entre les ambitions métiers, la vue opérationnel et l’évolutivité plus ou moins importante à
gérer, des décisions sont régulièrement à prendre et des compromis à trouver entre les
attentes souvent contradictoires.
Faire évoluer les organisations
L’approche service API est souvent orthogonal aux cloisements historiques entre
projet/maintenance ou entre métiers ou entre DSI et directions métiers. Leur généralisation
et bonne gestion pose des questions organisationnelles.
Les défis de financement
et de time to market
nécessitent de développer
des organisations agiles
aptes à :
- décider vite,
- expérimenter vite
- tout en garantissant le
respect ou la prise de
compte de
fondamentaux
stratégiques, juridiques,
SI,…
Pour assurer le bon niveau
de cohérence et de
subsidiarité et la liberté
d’innovation, le mode
plateforme est
indispensable.

50. © Club Urba-EA 50
Quelques challenges d’architecture 1/2
Urbanisation et gouvernance : utiliser la plateforme d’API à bon escient
Les capacités techniques de l’API management et de l’ESB se recouvrent sur l’exposition et la
composition de services. Les architectes doivent définir clairement leurs rôles respectifs et
s’assurer qu’une gouvernance efficace pilote les catalogues de services et d’API.
APIs internes, externes et déploiement à grande échelle
Un travail d’architecture technique important est fournir pour définir la bonne topologie de
déploiement de l’API management lorsque son usage s’étend en interne et en externe – avec
des usages et des bonnes pratiques différents - et à l’international. L’enjeu est de maintenir la
performance des services tout en assurant la fraicheur et la disponibilité des données sans
transiger sur la sécurité.
L’approche « service » sur le legacy
Les APIs consomment des services fournis par le SI legacy, qui peut avoir des difficultés à être
au rendez-vous, en particulier s’il n’est pas passé par la case SOA. C’est un challenge crucial
auquel il n’y a pas de solutions miracle. Le legacy devra se transformer, au meilleur rythme
possible, et les architectes devront accompagner la transformation et imaginer des solutions
de contournement temporaire si nécessaire.
Anticiper et gérer l’impact sur l’infrastructure
L’ouverture de nouveaux canaux digitaux implique un augmentation de l’utilisation de bande
passante consommée qu’il faut anticiper et gérer les conséquences techniquement et
financièrement.
La ou les plateformes
nécessaires sont des
plateformes
potentiellement
névralgiques et ne doivent
pas devenir un point
individuel de défaillance
(Single Point Of Failure).
Le plan d’APIsation du
legacy est un programme
au long court à
L’anticipation des
problématiques
techniques est essentielle.

51. © Club Urba-EA 51
Quelques challenges d’architecture 2/2
Les APIs sont dans la
continuité des approches
SOA et nécessite, dans le
cadre de programmes
d’APIsation globaux sur le
legacy, d’appréhender les
services au sein du modèle
en couche traditionnel.
L’approche retenue par la
SNCF est une approche
driven visant à modéliser le
en plateforme et cas
Les APIs sont en outre d’un
point de vue architecture SI,
des supports efficaces à la
diffusion des données.
Source = Isabelle BOUDARD - SNCF

52. © Club Urba-EA 52
De nouvelles gouvernances
Gouvernance du ou des portefeuilles d’API
Enjeu : La pertinence de l’offre API, la consolidation et fédération des initiative,
éventuellement la mise à disposition des moyens
Recensement, priorisation, consolidation ou fédération des budgets, macro-planification,
organisation, recrutement, décisions stratégiques, ecosystème de partenaires, communication
stratégique
Gouvernance des standards API
Enjeu : La cohérence des standards et des méthodes, l’expérience client
Normes et standards, veille juridique et réglementaire, compliance standards partenaires,
rôles et organisation, processus, communication technique
Gouvernance des plateformes
Enjeu : les capacités de développement et d’exposition en adéquation avec les besoins
Référencement, environnement développeur, support et expertise
Gouvernance des API unitaire
Enjeu : L’adéquation aux besoins et marchés, la complétude et la disponibilité du produit
API unitaire sur ces différents aspect : business, juridique, technique
Roadmap produit, SLA, Animation API, communication client
Les défis majeurs identifiés
nécessitent de mettre en
place des organisations et
gouvernance nouvelles sur
APIs.
4 natures de gouvernance
semblent nécessaires pour
mener à bien un programme
d’API sation.

53. © Club Urba-EA 53
53
 Mode agile
 Pré-conception & Pré-
developpement
Retour SNCF : organisation et rôle de l’architecte de service
Source = Jean charles QUANTIN - SNCF

54. © Club Urba-EA 54
Retour SNCF : organisation et rôle de l’architecte de service
Les architectes,
notamment de service
sont essentiels sur
plusieurs volets.
Volet communication
La construction et la
gestion des API nécessite
de faire dialoguer les
acteurs.
Volet référentiel
La cohérence voir la
gouvernance du
portefeuille d’API peut
être pris en charge par les
cellules d’architectures.
Volet conception
Le respect des bonnes
pratiques de conception
et l’abandon des vieux
réflexes et le rôle des
architectes.
Source = Jean charles QUANTIN - SNCF

55. © Club Urba-EA 55
Perspective = Partage de bonnes pratiques
Source = David careli – Groupe la poste
Un nécessité à rompre avec
les organisations et réflexes de
la DSI et projets traditionnels !

56. © Club Urba-EA 56
Perpective = Partage de bonnes pratiques
Source = William el kaim « Managing your API »
Un nécessité à rompre avec
les organisations et réflexes de
la DSI et projets traditionnels !

57. © Club Urba-EA 57
Perspective = Partage de bonnes pratiques
Source = William el kaim « Managing your API »
Un nécessité à rompre avec
les organisations et réflexes de
la DSI et projets traditionnels !

58. © Club Urba-EA 58
Perspective = Partage de bonnes pratiques
Source = William el kaim « Managing your API »
Un nécessité à rompre avec
les organisations et réflexes de
la DSI et projets traditionnels !