WHITEPAPER

API-led Connectivity
Une nouvelle étape dans
l’évolution de l’approche SOA
Sommaire

Résumé  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
Principaux défis  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
Recommandations  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3

L'impératif de la transformation digitale .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4

API-led connectivity: une nouvelle évolution de

l’approche SOA  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   8

Architecture API-led Connectivity à « trois couches »  . . . . . .   11

Avantages de l'API-led Connectivity .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   13

Entreprise .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   13
Technique  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   13

Parcours des clients vers l'API-led Connectivity  .. . . . . . . . . . . . . . . . . .   15

Étude de cas : PetSmart  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   16
Étude de cas : Wells Fargo  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   17
MuleSoft : la plateforme API-led Connectivity  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   19

À propos de MuleSoft  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   21
Résumé

Principaux défis
Les entreprises doivent se lancer dans la transformation
digitale pour continuer de répondre aux attentes de leurs
clients et ne pas risquer de perdre des parts de marché face à
des concurrents capables de s’adapter plus rapidement.
La transformation digitale pousse fondamentalement les
entreprises à redéfinir leurs relations avec leurs clients,
fournisseurs et collaborateurs grâce à de nouvelles
technologies qui leur permettent de communiquer par des
moyens jusqu'ici inaccessibles.
Ces nouvelles technologies, qu'elles soient SaaS, mobiles ou
IoT (Internet of Things), exigent un niveau de connectivité inédit
impossible à atteindre avec les approches d'intégration d'hier.

Recommandations
›› Construire un réseau d'applications en adoptant une
approche API-led Connectivity qui regroupe les services de
connectivité et d'orchestration sous-jacents en éléments
constitutifs API facilement réutilisables.
›› Structurer ces éléments constitutifs autour de couches de
systèmes, processus et expériences distinctes afin de
parvenir à une plus grande souplesse organisationnelle et à
un meilleur contrôle.
›› Diriger ce changement technologique de manière holistique
à travers les personnes, processus et systèmes.

3
L'impératif de la transformation digitale

Nous sommes au cœur d'une phase de transformation digitale

sans précédent. Les hôpitaux ne se contentent plus de
prodiguer des soins dans leur enceinte ; les établissements
non bancaires stimulent l'innovation dans le domaine des
paiements ; les sociétés de distribution médiatique s'orientent
vers la production.
Ces changements remodèlent irrévocablement les frontières
sectorielles et les modèles commerciaux entraînant l’évolution
rapide des rapports concurrentiels.
La technologie est un instrument clé de cette transformation
digitale. Les technologies mobiles et cloud sont désormais des
facteurs de perturbation avérés des activités IT, à l'intérieur
comme à l'extérieur de l'entreprise. Autrefois considérées
comme des outils destinés aux programmeurs, les APIs se
présentent aujourd'hui comme de véritables stratégies
d'entreprise offrant une nouvelle voie d'accès au marché à une
nouvelle gamme de produits et services digitaux. Les
responsables commerciaux et IT doivent agir au plus vite pour
protéger l'efficacité et la compétitivité de leur entreprise. Les
clients ont les moyens d'identifier et de choisir rapidement les
entreprises les plus à même de répondre à leurs besoins. Les
entreprises qui ne réagissent pas aujourd'hui se
feront distancer.
La transformation digitale demeure toutefois un objectif
difficilement atteignable. Elle ne résulte pas de la mise en
œuvre d'une seule application ou d'une seule technologie. Au
contraire, c'est uniquement lorsqu'une entreprise est capable
de réunir plusieurs technologies permettant de créer des
propositions réellement distinctes et différenciées que cette
transformation digitale peut être réalisée.
Pour ce faire, elle doit mettre ses données provenant de
différentes sources à la disposition d'intervenants multiples,

4
comme ses clients, fournisseurs ou collaborateurs, en toute
sécurité et à l'échelle. C'est dans ce contexte que la
connectivité doit être considérée comme une problématique à
traiter au niveau exécutif, ce qui explique pourquoi le DSI est
aujourd'hui désigné comme la personne la plus à même
d'occuper le rôle de « responsable en chef de l'intégration »,
dont la priorité principale est la transformation digitale. En fin
de compte, la connectivité n'est pas seulement un catalyseur
essentiel de la transformation digitale ; elle en est aussi sans
doute le facteur de réussite le plus déterminant.
Malgré son importance, trop nombreuses sont encore les
entreprises qui n'abordent pas la connectivité selon cette
approche stratégique. Soit elles ne l'envisagent pas du tout
(imaginez un responsable de services multipliant les achats
d'applications SaaS sans réfléchir à la manière dont il reliera
ces applications aux systèmes ERP sous-jacents), soit elles ne
l'envisagent qu'à court terme, faisant passer la réussite d'un
projet individuel avant celle de l'organisation
dans son ensemble.
Les méthodes traditionnelles appliquées aux applications
d'intégration ne fonctionnent pas pour la transformation
digitale. Conçues à une époque où les terminaux étaient moins
nombreux et où les délais étaient plus longs, ces approches
sont souvent incapables d'évoluer assez rapidement pour
répondre aux besoins des entreprises d'aujourd'hui.
L'intégration point à point des applications peut être précaire
et coûteuse à entretenir. En théorie, les approches SOA
(architecture orientée services) offrent un modèle à suivre,
mais leur mise en œuvre pratique laisse à désirer. Les
principes de l'architecture SOA sont bien fondés : des services
bien définis, facilement détectables et réutilisables. Pourtant,
ces principes sont rarement respectés dans la pratique. L'envie
de se doter d'interfaces correctement définies a abouti à des
initiatives top-down sorties de nulle part, qui se sont
rapidement enlisées dans les processus. Trop peu d'attention,

5
voire aucune, a été attachée à la recherche et à l'utilisation des
services. Par ailleurs, l'utilisation de la technologie de services
Web SOAP pour la mise en œuvre d'une architecture SOA s'est
avérée trop pesante et mal adaptée à l'époque, et encore plus
inadaptée aux applications mobiles actuelles.
Les responsables IT doivent atteindre deux objectifs
d'apparence contradictoires : assurer la stabilité et le contrôle
des systèmes de base, tout en encourageant l'innovation et
l'itération rapide des applications qui accèdent à ces systèmes.
Pour décrire ce phénomène, on parle aujourd'hui d'IT bimodal
ou à deux vitesses. Les approches de connectivité existantes
ne sont pas adaptées à ces nouveaux défis.
La transformation digitale oblige non seulement les entreprises
à adopter un nouvel ensemble de technologies, mais aussi à
instaurer un nouveau niveau de connectivité. Il convient de
trouver une nouvelle approche capable d'exploiter les
investissements existants et de laisser l'IT saisir les
opportunités du moment pour réussir cette transformation
digitale, de façon à stimuler l'agilité tout en permettant à l'IT de
garantir la visibilité et le contrôle. Cette nouvelle approche
représente un parcours qui exige de s'écarter de l'exécution de
projets classique pour se concentrer sur la fourniture d'assets
en tant que services, permettant aux secteurs d'activité et à l'IT
de créer et d'utiliser en libre-service leurs propres connexions,
processus et applications, tout en confiant au service IT central
la gestion de l'accès, des SLAs et de la qualité des données. En
résumé, l'IT doit devenir un catalyseur pour l'entreprise.
Ce livre blanc propose une nouvelle approche de l'intégration,
l' « API-led Connectivity », qui étend les approches orientées
service traditionnelles pour les adapter aux besoins actuels en
manière de connectivité. Nous aborderons en détail cette
approche et les défis liés à sa mise en œuvre, ainsi que la
manière dont les responsables IT peuvent concrétiser cette
vision dans leur propre organisation.

6
Microservices
Les microservices continuent de faire parler d’eux parmi les
responsables d’architectures d’entreprise. De notre point de vue, les
microservices entérinent non seulement l'approche orientée services,
mais ils illustrent en outre la manière dont cette approche devrait être
mise en œuvre, en mettant l'accent sur la nécessité de disposer de
services bien définis et réutilisables. Ce faisant, cette approche souligne
l'importance de la gouvernance et le fait qu'une mise en œuvre réussie
doit également tenir compte de facteurs non technologiques comme
les processus et les méthodologies de développement. De cette
manière, les principes et l'approche qui sous-tendent l'API-led
Connectivity sont tout à fait compatibles avec les
microservices, et inversement.

7
API-led connectivity: une nouvelle
évolution de l’approche SOA

Alors que les exigences en matière de connectivité ont évolué,

les principes fondamentaux de la SOA demeurent identiques,
puisqu'il s'agit toujours de distiller les logiciels dans des
services définis, réutilisables et détectables.
Cette vision est peut-être encore plus importante compte tenu
de la prolifération des terminaux. Fournir à de multiples
intervenants des vues personnalisées d'une même source de
données sous-jacente, qu'il s'agisse d'un système bancaire
central ou d'un système ERP, est une démarche dont la
complexité augmente exponentiellement avec le nombre de
canaux à travers lesquels ces données doivent transiter. Cette
vision met également en exergue à quel point il est important
que les données au point de consommation soient découplées
et indépendantes du système existant.
Cette préoccupation est compatible avec une approche
orientée services, dans laquelle la logique applicative est
divisée en services individuels, avant d'être réutilisée sur
plusieurs canaux. Pourtant, les mises en œuvre top-down
pesantes mentionnées précédemment ne sont pas adaptées
aux critères de souplesse qu'exigent les initiatives de
transformation digitale actuelles.
Bâtie selon les piliers de la SOA, l'API-led Connectivity revisite
toutefois sa mise en œuvre pour relever de nouveaux défis
uniques. L'API-led-Connectivity est une approche qui définit
des méthodes de connexion et d'exposition de vos assets. Elle
change le mode opératoire de l'IT et favorise un accès
décentralisé aux données et capacités, sans pour autant
mettre la gouvernance en péril. L'API-led Connectivity donne
lieu à un réseau d'applications : un réseau de données,
d'appareils et d'applications qui sont « enfichables » et

8
fournissent l'agilité exigée par l'évolution rapide de la
transformation digitale d'aujourd'hui.
L'API-led Connectivity requiert un élément constitutif de la
connectivité distinct qui renferme trois composantes :
›› Interface : présentation des données dans une démarche
respectueuse de la sécurité et de la gouvernance.

›› Orchestration : application d'une logique à ces données,

par exemple de transformation et d'enrichissement.

›› Connectivité : accès aux données sources, aussi bien à

partir de systèmes physiques que de services externes.

1 2 3

Interface Orchestration Connectivité

Présentation des données Application d'une logique à ces Accès aux données sources,
dans une démarche données, par exemple aussi bien à partir de systèmes
respectueuse de la sécurité et de transformation et physiques que de services
de la gouvernance. d'enrichissement. externes.

Figure 1: Anatomie de l'API-led Connectivity

Conçues avant tout pour l'utilisation des données, les APIs sont
les instruments qui fournissent un moyen à la fois
consommable et contrôlé d'accéder à la connectivité. Elles
servent de contrat entre l'utilisateur de données et le
fournisseur de celles-ci. Ce contrat constitue à la fois une limite
de démarcation et un point d'abstraction, dissociant les deux
parties et leur permettant de travailler indépendamment l'une
de l'autre (tant qu'elles continuent d'être liées par le contrat de
l'API). Enfin, les APIs jouent également un rôle de gouvernance
9
important dans la sécurisation et la gestion de l'accès à
cette connectivité.
Toutefois, l'application d'intégration ne doit pas être une simple
API. Cette dernière peut uniquement servir de couche de
présentation si elle recouvre un ensemble de flux
d'orchestration et de connectivité. Cette orchestration et cette
connectivité sont essentielles, car sans elles, la connectivité
API-à-API n'est plus qu'un moyen de plus d'établir une
intégration point à point. Ces APIs exécutent des fonctions
spécifiques et fournissent l'accès à des données non centrales.
Elles peuvent être construites par l'IT central ou l'IT sectoriel.

Comparaison entre APIs et API-led Connectivity

Stripe, une « API en tant que société » chargée de la désintermédiation
de l'espace de paiement, est l'archétype de l'économie des APIs. Lors
de la conférence CONNECT de MuleSoft, le PDG de Stripe, John
Collison, a déclaré : « On n'étale pas une API sur un produit comme du
beurre sur une tranche de pain ». Prise isolément, l’API n’est qu’un
élément qui cache les complexités de la connectivité et de
l’orchestration backend, et qui ne fait rien pour
résoudre ces problèmes.

La connectivité est une problématique dont les facettes sont multiples,

entre l'accès aux données, leur orchestration et leur mise à disposition.
La meilleure solution consiste à envisager ce problème de manière
globale plutôt que parcellaire. Ne tenir compte que des APIs revient à
ne relever qu'une seule partie du défi posé par la connectivité.

10
Architecture API-led Connectivity
à « trois couches »

Les grandes entreprises ont des besoins en connectivité

complexes et interdépendants qui requièrent plusieurs
éléments constitutifs de l'API-led Connectivity. Dans ce
contexte, il est essentiel de mettre en place un cadre pour la
commande et la structuration de ces éléments constitutifs.
L'agilité et la flexibilité ne peuvent provenir que d'une
architecture multiniveau contenant trois couches distinctes :
›› Couche système : à la base de toute architecture IT se
trouvent des systèmes centraux de référence (par exemple,
systèmes ERP, systèmes de gestion de clients clés et de
facturation, bases de données propriétaires, etc). Il arrive
souvent que ces systèmes ne soient pas facilement
accessibles en raison de problèmes de connectivité.
Les APIs constituent un moyen de préserver l'utilisateur de
cette complexité. Les APIs système fournissent un moyen
d'accéder aux systèmes de référence sous-jacents et
d'exposer ces données, souvent sous un format canonique,
tout en assurant une isolation en aval de toute modification
de l'interface ou rationalisation de ces systèmes. Ces APIs
changent également plus rarement, et sont régies par l'IT
central en raison de l'importance des systèmes sous-jacents.
›› Couche de processus : les processus commerciaux sous-
jacents qui façonnent ces données et interagissent avec
elles doivent être strictement encapsulés hors des systèmes
sources d'où proviennent ces données, ainsi que des canaux
cibles par lesquels elles transitent pour être distribuées. Par
exemple, dans un processus d'ordre d'achat, il existe une
logique commune à tous les produits, secteurs
géographiques et circuits de distribution qui peut et doit
être distillée au sein d'un service unique.

11
›› Couche d'expérience : les données sont désormais
utilisées sur un large éventail de canaux, chacun d'entre eux
ayant besoin d'accéder à ces mêmes données, mais sous
diverses formes. Par exemple, imaginons qu’un système de
point de vente au détail, un site de e-commerce et une
application mobile d'achat veuillent tous accéder aux mêmes
champs d'informations client, mais dans des formats bien
différents. Les APIs d'expérience permettent de reconfigurer
les données de manière à ce qu'elles soient plus facilement
utilisées par le public visé, à partir d'une source de données
commune. Ainsi, il n'est pas nécessaire de configurer des
intégrations point à point distinctes pour chaque canal.

Couche Propriété Fréquence des changements

Couche système IT central 6 à 12 mois

Couche de processus IT central et IT sectoriel 3 à 6 mois

Couche d'expérience IT sectoriel et développeurs 4 à 8 semaines, plus fréquemment pour les entreprises
d'application ayant atteint une certaine maturité

Table 1: Chaque couche d'API-led Connectivity fournit un contexte pour la fonction et la propriété

Expérience client Expérience Expérience de Expérience de Paiement Défaut

(tous les canaux : collaborateur rapports/d’analyse gestion/support APIs
par exemple, mobile,
ordinateur de bureau, d’expérience
serveur vocal interactif
Canaux
(IVR), etc.)

Accorder Découvrir Obtenir Récupérer les Rechercher Obtenir le solde Obtenir l'état Obtenir le APIs
un prêt l'emprunteur l'historique détails du dans les du compte du prêt rapport
des prêts de compte de prêt documents de prêt de crédit de processus
l'emprunteur de prêt Processus

Credit score Documents Signatures Prêts Service Web Données de l'emprunteur

électroniques pour APIs
l'emprunteur
système
Base de Base de IBM
Données
données données Db2
Oracle MySQL

Bureau Gestion Système d'accord Gestion des

de crédit de documents de prêt (LOS) prêts immobiliers

*
Dans cette figure, les canaux orientés client sont réunis en une seule API d’expérience client pour plus de simplicité.

Figure 2: Architecture illustrative : transformation des prêts immobiliers grâce à l'émergence d'un réseau
d'applications et à une base pour la réutilisation.

12
Avantages de l'API-led Connectivity

Envisager la connectivité sous cette perspective recèle

plusieurs avantages, dont les suivants :

Entreprise
›› L'IT comme catalyseur pour l'entreprise : en présentant
les ressources de données sous forme de services destinés
à un public plus large, l'IT peut devenir le catalyseur qui
permet aux secteurs d'activité de fonctionner
en libre-service.

›› Accroissement de la productivité des développeurs

grâce à la réutilisation : l'API-led Connectivity correspond à
une approche orientée services dans laquelle la logique est
distillée sous la forme de ses éléments constitutifs et
réutilisée dans différentes applications. Cela évite aux
développeurs de dupliquer leurs tâches et leur permet de
tirer profit des initiatives de chacun.

›› Un changement plus facile à prévoir : en modularisant la

logique d'intégration et en assurant la séparation logique
entre les modules, les responsables IT sont plus à même
d'évaluer et d'assurer l'exécution, indépendamment des
changements apportés au code. Grâce à cette architecture,
la moindre modification de champ dans une base de
données n'a plus d'impact potentiellement catastrophique
en aval, ce qui permet d'éviter les tests de
régression approfondis.

Technique
›› Approche distribuée et sur mesure : une approche
API-led Connectivity reconnaît qu'il n'existe pas
d'architecture unique adaptée à tous les cas de figure. La

13
 connectivité peut donc être envisagée à petite échelle, et
cette fonctionnalité peut être mise en avant par le biais de
l'API ou de microservices.

›› Une plus grande agilité grâce à un couplage lâche des

systèmes : au sein de l'architecture IT d'une organisation, il
existe plusieurs niveaux de gouvernance appropriés.
L’approche dite de l’intégration bimodale ou de l’IT à deux
vitesses explicite cette dichotomie : la nécessité de bien
gérer et consigner les changements apportés aux systèmes
centraux (par exemple, les changements annuels sur les
schémas des systèmes ERP) tout en conservant la flexibilité
nécessaire aux itérations rapides des systèmes utilisateurs,
comme les applications Web et mobiles pour favoriser
l’innovation continue et la rapidité de commercialisation. Des
niveaux d'API distincts autorisent des niveaux de
gouvernance et de contrôle différents pour chaque couche,
ce qui rend possible un couplage à la fois lâche et étroit.

›› Une meilleure visibilité opérationnelle : l'approche

holistique de la connectivité permet une meilleure
compréhension du fonctionnement des APIs. Non
seulement il est possible de savoir si une API ou une
interface fonctionne, mais cette approche fournit également
des informations de bout en bout, de la réception de la
demande API initiale jusqu'à la satisfaction de cette
demande conformément à une requête de base de
données sous-jacente. À chaque étape, une analyse
détaillée est possible, ce qui s'avère plus complexe lorsque
l'on envisage la connectivité de façon fragmentaire.

14
Parcours des clients vers
l'API-led Connectivity

La volonté de mettre en œuvre une vision API-led Connectivity

ne doit pas se résumer à une simple décision technologique.
Elle nécessite un changement progressif mais fondamental de
la vision architecturale de l'IT de l'entreprise, de l'approche à
l'égard du développement et de la manière dont les
développeurs appréhendent leur rôle. Le défi à relever
concerne aussi bien le changement de processus que la mise
en œuvre de la technologie.
Cependant, la concrétisation d'une vision API-led Connectivity
n'est pas un objectif distinct, mais bien un cheminement
continu. Il s'agit en outre d'un objectif qui ne peut être atteint
que par étapes incrémentielles. En travaillant en partenariat
avec des dizaines de sociétés du classement Fortune 500 pour
les accompagner dans leur cheminement vers la
transformation digitale API-led Connectivity, nous avons
répertorié les meilleures pratiques à respecter :
›› Mode de démarrage : pour qu'une vision API-led
Connectivity soit viable, elle doit être réalisée à l'échelle de
l'entreprise. Mais dans les entreprises de grande taille, il est
tout simplement impossible de faire table rase pour tout
reprendre depuis le début. C'est pourquoi le parcours du
client vers l'API-led Connectivity doit débuter par un pan
vertical de l'activité, pour un cas d'utilisation donné ou un
service de gestion particulier. En posant des limites,
l'étendue du changement est réduite et la probabilité de
réussite s'en trouve accrue. La formation et l'encadrement
sont essentiels à ce stade, car ils seront les vecteurs des
nouveaux comportements.

15
›› Faire évoluer la plateforme : une fois établis les premiers
jalons probants, ces cas d'utilisation deviendront
naturellement les exemples à suivre au sein de l'entreprise
pour renforcer la volonté commune et bénéficier d'une
plateforme sur laquelle s'appuyer pour encourager une
adoption plus large. En outre, l’approche orientée services
aboutit naturellement à la création d’assets réutilisables, se
traduisant par une augmentation exponentielle de la valeur
de la plateforme avec l’accroissement du nombre d’assets.

›› Construire un Center for Enablement (C4E) : une fois la

portée requise atteinte, il est essentiel de codifier
rapidement les meilleures pratiques, et de fournir une
plateforme d'exposition et de diffusion à travers
l'organisation. Un tel processus se traduit par une adoption
généralisée à travers l'entreprise. Les bases de ce C4E
peuvent également être établies lors de l’étape de
démarrage, et adaptées ensuite aux besoins.

Étude de cas : PetSmart

PetSmart s'est donné pour mission de consolider sa relation
avec ses clients en leur offrant une expérience omnicanale. La
société veut conquérir le cœur de ses clients en leur offrant
non seulement une gamme complète d’articles, mais aussi des
services complets pour animaux de compagnie.
Le détaillant souhaitait devenir un partenaire de confiance à
chaque instant de la vie des propriétaires d'animaux de
compagnie, en leur garantissant une expérience fluide à
chaque interaction. Si l'on considère que PetSmart compte
plus de 1 500 magasins et de nombreux sites Web, services et
applications pour animaux de compagnie, le regroupement de
tous ses produits et services s'imposait.
En partenariat avec MuleSoft, PetSmart construit des APIs
réutilisables, dont une API de profilage client, qui peuvent être
exploitées à tous les points de contact avec le client. L'API de

16
profilage client est utilisée sur plusieurs plateformes comme
l'application mobile, les services de toilettage et l'hôtel pour
animaux de compagnie de la société. Cette API permet à
PetSmart de bénéficier d'une vue précieuse de ses clients sur
plusieurs canaux. Enfin et surtout, elle assure une expérience
fluide à ses clients.
En continuant de développer son approche dirigée par les
APIs, PetSmart a accéléré sa stratégie de commercialisation,
lançant des initiatives deux fois plus rapidement que par le
passé. De plus, en réutilisant des ressources sur le réseau,
PetSmart est en mesure de concevoir des APIs qui peuvent
être exploitées sur plusieurs canaux. L'entreprise peut ainsi
offrir une expérience uniforme à ses clients.
« Désormais, l'expérience du client est la même, qu'il se rende
au salon de toilettage, au PetHotel ou au magasin. Nous
connaissons nos clients et leurs animaux de compagnie »,
explique PetSmart.

Étude de cas : Wells Fargo

Wells Fargo, l'une des plus grandes banques mondiales,
emploie environ 273 000 personnes au service de plus de
70 millions de clients répartis sur 8 500 sites et utilisant
13 000 distributeurs automatiques de billets. La banque a
entamé sa transformation digitale pour offrir une expérience
unifiée à ses clients.
Dans le cadre de cette démarche, Wells Fargo a créé Wells
Fargo Gateway, une architecture BaaS (Banking-as-a-Service)
fournissant des services clés comme la gestion des comptes,
les paiements et le change de devises, grâce à la promotion
d'APIs auprès de ses partenaires et développeurs.
En tant que fondement de cette plateforme digitale, son
approche API-led Connectivity permet la réutilisation des
mêmes APIs sur plusieurs canaux. Cette réutilisation permet
une exécution plus rapide des projets, passant de plusieurs

17
mois à tout juste quelques semaines. « L'API FX, que nous
proposons à nos partenaires, a été une révolution », explique
Sid Vyas, CTO chez Capital Markets and Investment Banking
Technology. « Ils [les partenaires] peuvent intégrer leurs
applications ou systèmes avec notre plateforme avec fluidité. »

18
MuleSoft : la plateforme API-led Connectivity
AnyPoint Platform™, par MuleSoft, est une plateforme unifiée
et unique qui permet aux entreprises de créer et de faire
évoluer rapidement des réseaux d'applications. Recueillant la
confiance de plus de 1 600 entreprises clientes dans tous les
grands secteurs, AnyPoint Platform est la solution d'intégration
leader au monde. AnyPoint Platform permet une connectivité
de bout en bout entre l'API, l'orchestration des services et
l'intégration des applications. Les développeurs peuvent ainsi
connecter, orchestrer et activer rapidement n'importe quel
point de terminaison interne ou externe. Cela se traduit par
une division par deux à cinq des délais de lancement de
nouvelles initiatives, de connexion de systèmes et de
déverrouillages de données à travers l'entreprise, ainsi que par
une réduction de 30 % des coûts d'intégration.
En outre, contrairement aux autres solutions existantes, la
plateforme Anypoint Platform de MuleSoft peut être déployée
rapidement on-prem ou sous la forme d'une solution cloud.
Les solutions de MuleSoft sont si faciles à utiliser et à
comprendre que tous les développeurs peuvent rapidement
devenir productifs, sans nécessiter de longue formation à la
technologie spécifique au fournisseur. Il en résulte un gain de
productivité de 10 % pour les collaborateurs, et de 70 % pour
les équipes de développement des applications.
Enfin, l'expérience de MuleSoft dans le partenariat avec ses
clients en vue de piloter des initiatives de transformation
digitale permet à nos équipes de “Customer Success”
d’apporter leur expertise dans la gestion du changement, la
conception organisationnelle et les bonnes pratiques de
développement IT. Cette expérience complète nos offres
technologiques et crée un véritable partenariat permettant de
favoriser la réussite. MuleSoft a développé Catalyst™ afin
d'accompagner ses clients dans leur parcours vers l'API-led
Connectivity en leur fournissant de bonnes pratiques, des
tutoriels en ligne, des modèles et des ressources, le tout

19
adapté à des clients et partenaires de tous niveaux
d'expérience. Qu'il s'agisse d'un projet unique ou d'une
initiative de transformation digitale de grande envergure, la
facilité d'utilisation de Anypoint Platform se combine à
MuleSoft Catalyst pour aider les entreprises à atteindre plus
rapidement leurs objectifs commerciaux.

20
 21

À propos de MuleSoft

MuleSoft, une société Salesforce

La mission de MuleSoft consiste à aider les organisations à
évoluer et à innover plus rapidement en facilitant la connection
des applications, des données et des appareils à travers le
monde. Grâce à son approche de la connectivité dirigée par les
APIs, la solution AnyPoint Platform de MuleSoft™, leader sur le
marché, fournit à plus de 1 600 organisations réparties dans
environ 60 pays les outils leur permettant de créer des réseaux
d'applications. En déverrouillant l'accès aux données à l'échelle
de l'entreprise grâce aux réseaux d'applications, les
organisations peuvent facilement générer de nouvelles sources
de revenus, améliorer l'efficacité opérationnelle et créer des
expériences clients différenciées.
Pour plus d’informations, rendez-vous sur mulesoft.com

MuleSoft est une marque déposée de MuleSoft LLC, une société Salesforce.
Toutes les autres marques sont celles de leurs propriétaires respectifs.

21