Chez Axway, nous avons compris qu’il ne suffit pas de publier quelques API pour faire naître une transformation digitale. C’est pourquoi nous accompagnons nos clients dans le temps long, et participons à leurs réflexions stratégiques, qui aboutissent souvent dans un repositionnement des activités dans ce nouveau paradigme digital.
En 2023, cette transformation digitale passe pour 70% des entreprises par un engagement plus fort de son interaction avec l’écosystème, de plus en plus riche.
Découvrez notre baromètre “Marketplace : stratégie d’exposition et gouvernance des APIs” ici.
Cet engagement nécessite une ouverture du système d’information non plus, comme on l’imaginait il y a encore 2 ans, avec de simples API (techniques ou business), mais avec des produits digitaux.
Qu’est-ce qu’un produit digital ?
Derrière ce terme de « produit digital » ne se cache pas qu’un simple changement de nom, mais une nouvelle philosophie d’exposition et d’engagement des développeurs de l’écosystème, qui recherchent toujours plus de simplicité dans l’usage de ces services.
C’était l’un des thèmes abordés récemment lorsque de notre présentation du baromètre de stratégie d’exposition et gouvernance des APIs :
Une API, c’était un bout de code, un pauvre swagger/OAS qui traînait dans un catalogue, plus ou moins bien référencé.
Passer de l’API au produit digital, c’est un peu comme passer du petit pois dans un champ à la boîte de Bonduelle sur un rayon de Monoprix. Il y a tout un processus de transformation et de marketing qui s’applique identiquement aux produits digitaux :
- Identifier et inventorier le produit.
- Sélectionner (curation)
- agréger, orchestrer (recette)
- Emballer
- Poser une notice d’utilisation, vidéo explicative
- Pricing
- Référencement
- Exposition dans une belle vitrine, un beau rayon, dans un magasin facile d’accès
Ce processus doit s’inscrire dans une chaîne de fabrication prenant en compte les « feedback » clients et donner aux producteurs comme aux consommateurs des métriques précises.
Où se passe l’assemblage des produits digitaux ?
Ceci étant dit, il me semble important de se poser la question de l’assemblage des API techniques, des bouts de code (sample, webview, etc). Cet assemblage doit-il s’effectuer au niveau de vos plateformes d’API management (en général sous la tutelle de la DSI) ou bien doit-il être l’objectif d’un nouvel outil, au-dessus de ces APIM (souvent considérées à juste titre comme trop techniques), outil que l’on nomme désormais DSM (Digital Service Marketplace).
Ces nouveaux outils de DSM ont l’avantage d’être manipulables par des métiers, internes ou externes, pour exposer et pricer les services. Mais doivent-ils être le lieu pour réaliser l’assemblage des briques techniques sous-jacentes (API, ressources, méthodes, etc. ?)
Alors, pour vous, cet assemblage doit-il être à la main des DSI dans une APIM pour créer une sorte de « super API » ou bien doit-il être le fruit d’une activité métier dans une marketplace ?
La question se pose légitimement, et dépend grandement de la granularité initialement choisie pour exposer les services (grosse API avec 50 ressources ou bien API plus granulaire).
Ces questions touchent non seulement la manière de commercialiser ces produits (qui voudrait acheter une boîte de 100 kg de petits poids pour n’en consommer que 4 assiettes). À l’inverse, commercialiser les petits poids à l’unité est tout aussi fastidieux pour le client…
Pour les services digitaux, c’est la même chose avec, en plus, des problématiques de sécurité qui impliquent une distribution de jeton peu compatible avec une vision trop fine de la granularité des services…
Ces questions d’architectures sont aujourd’hui au cœur de la réflexion de nombreuses entreprises, et il nous semble intéressant d’ouvrir le débat.
Qu’en pensez-vous donc, vous ?
Découvrez le baromètre marketplace : Stratégie d’exposition et gouvernance des API.