SlideShare une entreprise Scribd logo
1  sur  58
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
Rejoignez les 80
entreprises adhérentes
et plus de 100 membres
actifs sur urba-ea.org
Rejoignez les 80
entreprises adhérentes
et plus de 100 membres
actifs sur urba-ea.org
© 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
© 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
© 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
© 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 !
© 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
© 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
© 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 ?
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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)
© 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.
© 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
© 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.
© 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.
© 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
© 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
© 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)
© 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
© 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
© 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
© 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
© 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.
© 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
© 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é
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© Club Urba-EA 44
Les éditeurs de solutions d’API Management
Le point de vue des analystes
© 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
© 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
© 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
© 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
© 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.
© 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.
© 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
© 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.
© 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
© 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
© 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 !
© 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 !
© 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 !
© 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 !

Contenu connexe

Tendances

La Gestion de Projet Agile
La Gestion de Projet AgileLa Gestion de Projet Agile
La Gestion de Projet Agilebcollet
 
Le serious game et l'accompagnement au changement
Le serious game et l'accompagnement au changementLe serious game et l'accompagnement au changement
Le serious game et l'accompagnement au changementFFFOD
 
Presentation DevOps : enjeux , objectifs, consequences
Presentation DevOps : enjeux , objectifs, consequencesPresentation DevOps : enjeux , objectifs, consequences
Presentation DevOps : enjeux , objectifs, consequencesStéphane Di Cioccio
 
Le PMBOK n'est pas agile ?, ben voyons donc !!!
Le PMBOK n'est pas agile ?, ben voyons donc !!! Le PMBOK n'est pas agile ?, ben voyons donc !!!
Le PMBOK n'est pas agile ?, ben voyons donc !!! PMI-Montréal
 
Méthodes Agiles, L’essentiel de KANBAN.
Méthodes Agiles, L’essentiel de KANBAN.Méthodes Agiles, L’essentiel de KANBAN.
Méthodes Agiles, L’essentiel de KANBAN.aettarrouzi
 
eServices-Chp5: Microservices et API Management
eServices-Chp5: Microservices et API ManagementeServices-Chp5: Microservices et API Management
eServices-Chp5: Microservices et API ManagementLilia Sfaxi
 
Developer Experience at Zalando - CNCF End User SIG-DX
Developer Experience at Zalando - CNCF End User SIG-DXDeveloper Experience at Zalando - CNCF End User SIG-DX
Developer Experience at Zalando - CNCF End User SIG-DXHenning Jacobs
 
ERP et conduite du changement
ERP et conduite du changementERP et conduite du changement
ERP et conduite du changementFaurie Christophe
 
Les fondamentaux de la gestion de projet
Les fondamentaux de la gestion de projetLes fondamentaux de la gestion de projet
Les fondamentaux de la gestion de projetCOMPETENSIS
 
MICRO APPS - BREAKING THE MOBILE APP MONOLITH AND DELIVERING OMNICHANNEL EXPE...
MICRO APPS - BREAKING THE MOBILE APP MONOLITH AND DELIVERING OMNICHANNEL EXPE...MICRO APPS - BREAKING THE MOBILE APP MONOLITH AND DELIVERING OMNICHANNEL EXPE...
MICRO APPS - BREAKING THE MOBILE APP MONOLITH AND DELIVERING OMNICHANNEL EXPE...Nischal Reddy
 
Présentation du Business Model Canvas
Présentation du Business Model CanvasPrésentation du Business Model Canvas
Présentation du Business Model CanvasArnaud Casalis
 
Product Management and Metrics by Amazon Sr PM
Product Management and Metrics  by Amazon Sr PMProduct Management and Metrics  by Amazon Sr PM
Product Management and Metrics by Amazon Sr PMProduct School
 
L'audit comme outil d'amélioration des projets agiles - Agile Tour Paris
L'audit comme outil d'amélioration des projets agiles - Agile Tour Paris L'audit comme outil d'amélioration des projets agiles - Agile Tour Paris
L'audit comme outil d'amélioration des projets agiles - Agile Tour Paris ENSIBS
 
Jeu du kanban 2013
Jeu du kanban 2013Jeu du kanban 2013
Jeu du kanban 2013CIPE
 
La prospection commerciale
La prospection commerciale La prospection commerciale
La prospection commerciale arlhe
 

Tendances (20)

La Gestion de Projet Agile
La Gestion de Projet AgileLa Gestion de Projet Agile
La Gestion de Projet Agile
 
Le serious game et l'accompagnement au changement
Le serious game et l'accompagnement au changementLe serious game et l'accompagnement au changement
Le serious game et l'accompagnement au changement
 
LE BUSINESS PLAN
LE BUSINESS PLANLE BUSINESS PLAN
LE BUSINESS PLAN
 
Presentation DevOps : enjeux , objectifs, consequences
Presentation DevOps : enjeux , objectifs, consequencesPresentation DevOps : enjeux , objectifs, consequences
Presentation DevOps : enjeux , objectifs, consequences
 
Le PMBOK n'est pas agile ?, ben voyons donc !!!
Le PMBOK n'est pas agile ?, ben voyons donc !!! Le PMBOK n'est pas agile ?, ben voyons donc !!!
Le PMBOK n'est pas agile ?, ben voyons donc !!!
 
Méthodes Agiles, L’essentiel de KANBAN.
Méthodes Agiles, L’essentiel de KANBAN.Méthodes Agiles, L’essentiel de KANBAN.
Méthodes Agiles, L’essentiel de KANBAN.
 
eServices-Chp5: Microservices et API Management
eServices-Chp5: Microservices et API ManagementeServices-Chp5: Microservices et API Management
eServices-Chp5: Microservices et API Management
 
Developer Experience at Zalando - CNCF End User SIG-DX
Developer Experience at Zalando - CNCF End User SIG-DXDeveloper Experience at Zalando - CNCF End User SIG-DX
Developer Experience at Zalando - CNCF End User SIG-DX
 
ERP et conduite du changement
ERP et conduite du changementERP et conduite du changement
ERP et conduite du changement
 
Les fondamentaux de la gestion de projet
Les fondamentaux de la gestion de projetLes fondamentaux de la gestion de projet
Les fondamentaux de la gestion de projet
 
MICRO APPS - BREAKING THE MOBILE APP MONOLITH AND DELIVERING OMNICHANNEL EXPE...
MICRO APPS - BREAKING THE MOBILE APP MONOLITH AND DELIVERING OMNICHANNEL EXPE...MICRO APPS - BREAKING THE MOBILE APP MONOLITH AND DELIVERING OMNICHANNEL EXPE...
MICRO APPS - BREAKING THE MOBILE APP MONOLITH AND DELIVERING OMNICHANNEL EXPE...
 
Methodes agiles
Methodes agilesMethodes agiles
Methodes agiles
 
Management de projet
Management de projetManagement de projet
Management de projet
 
Présentation du Business Model Canvas
Présentation du Business Model CanvasPrésentation du Business Model Canvas
Présentation du Business Model Canvas
 
Motivation
MotivationMotivation
Motivation
 
Product Management and Metrics by Amazon Sr PM
Product Management and Metrics  by Amazon Sr PMProduct Management and Metrics  by Amazon Sr PM
Product Management and Metrics by Amazon Sr PM
 
L'audit comme outil d'amélioration des projets agiles - Agile Tour Paris
L'audit comme outil d'amélioration des projets agiles - Agile Tour Paris L'audit comme outil d'amélioration des projets agiles - Agile Tour Paris
L'audit comme outil d'amélioration des projets agiles - Agile Tour Paris
 
Prospection
ProspectionProspection
Prospection
 
Jeu du kanban 2013
Jeu du kanban 2013Jeu du kanban 2013
Jeu du kanban 2013
 
La prospection commerciale
La prospection commerciale La prospection commerciale
La prospection commerciale
 

Similaire à API sation Travaux Club urba EA

Revolutionner le Marketing dans le secteur du bâtiment - Oracle
Revolutionner le Marketing dans le secteur du bâtiment - OracleRevolutionner le Marketing dans le secteur du bâtiment - Oracle
Revolutionner le Marketing dans le secteur du bâtiment - OracleGuillaume Laban
 
Club Urba-EA - Vers un SI "data centric"
Club Urba-EA - Vers un SI "data centric" Club Urba-EA - Vers un SI "data centric"
Club Urba-EA - Vers un SI "data centric" Club Urba-EA
 
Formation agilité dans les projets et dans les structures
Formation agilité dans les projets et dans les structuresFormation agilité dans les projets et dans les structures
Formation agilité dans les projets et dans les structuresMed Chab
 
ServiceNow : Retour d'expérience DSI Pôle emploi - Yves DALLE PIAGGE
ServiceNow : Retour d'expérience DSI Pôle emploi - Yves DALLE PIAGGEServiceNow : Retour d'expérience DSI Pôle emploi - Yves DALLE PIAGGE
ServiceNow : Retour d'expérience DSI Pôle emploi - Yves DALLE PIAGGEYves Dalle Piagge
 
Book référence Gfi - Liferay 2016
Book référence Gfi - Liferay 2016Book référence Gfi - Liferay 2016
Book référence Gfi - Liferay 2016Inetum
 
-PRES Playbook CODiLOG SAP.pdf
-PRES Playbook CODiLOG SAP.pdf-PRES Playbook CODiLOG SAP.pdf
-PRES Playbook CODiLOG SAP.pdfssusercc7dd3
 
Yieloo - presentation société
Yieloo - presentation sociétéYieloo - presentation société
Yieloo - presentation sociétéCyril Girard
 
Hébergement Oracle PeopleSoft à valeur ajoutée
Hébergement Oracle PeopleSoft à valeur ajoutéeHébergement Oracle PeopleSoft à valeur ajoutée
Hébergement Oracle PeopleSoft à valeur ajoutéeBusiness At Work
 
Agile Wake Up #1 du 01/12/2015 : L'agilité au service des projets Orange Fran...
Agile Wake Up #1 du 01/12/2015 : L'agilité au service des projets Orange Fran...Agile Wake Up #1 du 01/12/2015 : L'agilité au service des projets Orange Fran...
Agile Wake Up #1 du 01/12/2015 : L'agilité au service des projets Orange Fran...Zenika
 
20200114 - IBM Cloud Paris Meetup - DevOps
20200114 - IBM Cloud Paris Meetup - DevOps20200114 - IBM Cloud Paris Meetup - DevOps
20200114 - IBM Cloud Paris Meetup - DevOpsIBM France Lab
 
Portfolio Florian Hohweiller_Digital Project Manager
Portfolio Florian Hohweiller_Digital Project ManagerPortfolio Florian Hohweiller_Digital Project Manager
Portfolio Florian Hohweiller_Digital Project ManagerFlorian HOHWEILLER
 
Big Data Paris: Etude de Cas: KPMG, l’innovation continue grâce au Data Lake ...
Big Data Paris: Etude de Cas: KPMG, l’innovation continue grâce au Data Lake ...Big Data Paris: Etude de Cas: KPMG, l’innovation continue grâce au Data Lake ...
Big Data Paris: Etude de Cas: KPMG, l’innovation continue grâce au Data Lake ...MongoDB
 
Liferay Symposium 2015 - Liferay : la plateforme technique au coeur de la tra...
Liferay Symposium 2015 - Liferay : la plateforme technique au coeur de la tra...Liferay Symposium 2015 - Liferay : la plateforme technique au coeur de la tra...
Liferay Symposium 2015 - Liferay : la plateforme technique au coeur de la tra...RCF Radio
 
ExperienceNow - Découvrez comment Soitec modernise son IT et gagne en agilité...
ExperienceNow - Découvrez comment Soitec modernise son IT et gagne en agilité...ExperienceNow - Découvrez comment Soitec modernise son IT et gagne en agilité...
ExperienceNow - Découvrez comment Soitec modernise son IT et gagne en agilité...Devoteam
 
Qu'est ce qu'une API en 2019
Qu'est ce qu'une API en 2019Qu'est ce qu'une API en 2019
Qu'est ce qu'une API en 2019Laurent Yin
 
Reussir sa transformation vers un modele IT agile et ouvert - Livret
Reussir sa transformation vers un modele IT agile et ouvert - LivretReussir sa transformation vers un modele IT agile et ouvert - Livret
Reussir sa transformation vers un modele IT agile et ouvert - LivretAXA en France
 
STRATEGIE DIGITALE : Libérez le potentiel de votre information
STRATEGIE DIGITALE : Libérez le potentiel de votre informationSTRATEGIE DIGITALE : Libérez le potentiel de votre information
STRATEGIE DIGITALE : Libérez le potentiel de votre informationSollan France
 
Améliorez votre efficacité avec un Hébergement SAP à valeur ajoutée !
Améliorez votre efficacité avec un Hébergement SAP à valeur ajoutée !Améliorez votre efficacité avec un Hébergement SAP à valeur ajoutée !
Améliorez votre efficacité avec un Hébergement SAP à valeur ajoutée !Business At Work
 
Enginov - Alpha Engineering : Modèles et plateforme de coordination avec le C...
Enginov - Alpha Engineering : Modèles et plateforme de coordination avec le C...Enginov - Alpha Engineering : Modèles et plateforme de coordination avec le C...
Enginov - Alpha Engineering : Modèles et plateforme de coordination avec le C...ANSItunCERT
 

Similaire à API sation Travaux Club urba EA (20)

Revolutionner le Marketing dans le secteur du bâtiment - Oracle
Revolutionner le Marketing dans le secteur du bâtiment - OracleRevolutionner le Marketing dans le secteur du bâtiment - Oracle
Revolutionner le Marketing dans le secteur du bâtiment - Oracle
 
Club Urba-EA - Vers un SI "data centric"
Club Urba-EA - Vers un SI "data centric" Club Urba-EA - Vers un SI "data centric"
Club Urba-EA - Vers un SI "data centric"
 
Formation agilité dans les projets et dans les structures
Formation agilité dans les projets et dans les structuresFormation agilité dans les projets et dans les structures
Formation agilité dans les projets et dans les structures
 
ServiceNow : Retour d'expérience DSI Pôle emploi - Yves DALLE PIAGGE
ServiceNow : Retour d'expérience DSI Pôle emploi - Yves DALLE PIAGGEServiceNow : Retour d'expérience DSI Pôle emploi - Yves DALLE PIAGGE
ServiceNow : Retour d'expérience DSI Pôle emploi - Yves DALLE PIAGGE
 
Book référence Gfi - Liferay 2016
Book référence Gfi - Liferay 2016Book référence Gfi - Liferay 2016
Book référence Gfi - Liferay 2016
 
-PRES Playbook CODiLOG SAP.pdf
-PRES Playbook CODiLOG SAP.pdf-PRES Playbook CODiLOG SAP.pdf
-PRES Playbook CODiLOG SAP.pdf
 
Yieloo - presentation société
Yieloo - presentation sociétéYieloo - presentation société
Yieloo - presentation société
 
Hébergement Oracle PeopleSoft à valeur ajoutée
Hébergement Oracle PeopleSoft à valeur ajoutéeHébergement Oracle PeopleSoft à valeur ajoutée
Hébergement Oracle PeopleSoft à valeur ajoutée
 
Agile Wake Up #1 du 01/12/2015 : L'agilité au service des projets Orange Fran...
Agile Wake Up #1 du 01/12/2015 : L'agilité au service des projets Orange Fran...Agile Wake Up #1 du 01/12/2015 : L'agilité au service des projets Orange Fran...
Agile Wake Up #1 du 01/12/2015 : L'agilité au service des projets Orange Fran...
 
20200114 - IBM Cloud Paris Meetup - DevOps
20200114 - IBM Cloud Paris Meetup - DevOps20200114 - IBM Cloud Paris Meetup - DevOps
20200114 - IBM Cloud Paris Meetup - DevOps
 
Portfolio Florian Hohweiller_Digital Project Manager
Portfolio Florian Hohweiller_Digital Project ManagerPortfolio Florian Hohweiller_Digital Project Manager
Portfolio Florian Hohweiller_Digital Project Manager
 
Big Data Paris: Etude de Cas: KPMG, l’innovation continue grâce au Data Lake ...
Big Data Paris: Etude de Cas: KPMG, l’innovation continue grâce au Data Lake ...Big Data Paris: Etude de Cas: KPMG, l’innovation continue grâce au Data Lake ...
Big Data Paris: Etude de Cas: KPMG, l’innovation continue grâce au Data Lake ...
 
Liferay Symposium 2015 - Liferay : la plateforme technique au coeur de la tra...
Liferay Symposium 2015 - Liferay : la plateforme technique au coeur de la tra...Liferay Symposium 2015 - Liferay : la plateforme technique au coeur de la tra...
Liferay Symposium 2015 - Liferay : la plateforme technique au coeur de la tra...
 
ExperienceNow - Découvrez comment Soitec modernise son IT et gagne en agilité...
ExperienceNow - Découvrez comment Soitec modernise son IT et gagne en agilité...ExperienceNow - Découvrez comment Soitec modernise son IT et gagne en agilité...
ExperienceNow - Découvrez comment Soitec modernise son IT et gagne en agilité...
 
Qu'est ce qu'une API en 2019
Qu'est ce qu'une API en 2019Qu'est ce qu'une API en 2019
Qu'est ce qu'une API en 2019
 
Reussir sa transformation vers un modele IT agile et ouvert - Livret
Reussir sa transformation vers un modele IT agile et ouvert - LivretReussir sa transformation vers un modele IT agile et ouvert - Livret
Reussir sa transformation vers un modele IT agile et ouvert - Livret
 
STRATEGIE DIGITALE : Libérez le potentiel de votre information
STRATEGIE DIGITALE : Libérez le potentiel de votre informationSTRATEGIE DIGITALE : Libérez le potentiel de votre information
STRATEGIE DIGITALE : Libérez le potentiel de votre information
 
Améliorez votre efficacité avec un Hébergement SAP à valeur ajoutée !
Améliorez votre efficacité avec un Hébergement SAP à valeur ajoutée !Améliorez votre efficacité avec un Hébergement SAP à valeur ajoutée !
Améliorez votre efficacité avec un Hébergement SAP à valeur ajoutée !
 
Presentation de Scub
Presentation de ScubPresentation de Scub
Presentation de Scub
 
Enginov - Alpha Engineering : Modèles et plateforme de coordination avec le C...
Enginov - Alpha Engineering : Modèles et plateforme de coordination avec le C...Enginov - Alpha Engineering : Modèles et plateforme de coordination avec le C...
Enginov - Alpha Engineering : Modèles et plateforme de coordination avec le C...
 

API sation Travaux Club urba EA

  • 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 !