Dans un monde ultra connecté où doit être à portée de son écran mobile, l’API apparaît comme la clé de voûte capable de soutenir le développement des entreprises et notamment des distributeurs. De plus en plus d’entreprises s’appuient, ou cherchent à s’appuyer, sur des interfaces publiques, partenaires ou privées. Mais elles se heurtent parfois à des idées fausses.
L’intégration des API (Application Programming Interface) dans leur business model vise trois objectifs : améliorer l’accès aux données, permettre aux clients et aux fournisseurs d’interagir plus facilement avec le système d’information de l’entreprise et enfin à optimiser le traitement des transactions provenant de sources internes ou externes.
Cette vision idéale est parfois ternie par des idées fausses ou une mauvaise compréhension de “l’API economy” ».
1Idée fausse 1 : les API seront limitées à un seul secteur de mon entreprise
Avec des modèles d’intégration et des workflows préintégrés, une unité commerciale ou un département peut utiliser les mêmes données d’une API existante et les réutiliser en fonction de leurs besoins spécifiques.
Par exemple, une entreprise peut construire une API pour gérer sa stratégie de marketing en ligne. Les ressources stockées dans cette bibliothèque d’API peuvent ensuite être réutilisées ou fragmentées pour produire différentes informations nécessaires au service achats.
2Idée fausse 2 : Les API sont de nature unique
Aujourd’hui, une interface peut être utilisée pour de multiples fonctions sans avoir à modifier l’application et sans alourdir l’équipe applicative. Ces API modernes peuvent produire différents styles et formats de données en fonction des besoins des clients.
De même, une seule API peut faciliter différents besoins applicatifs en tirant différentes ressources des référentiels côté serveur.
Les API permettent également aux entreprises de se développer sur des marchés qu’elles n’avaient jamais considérés auparavant. En ouvrant les API de Watson, son programme d’intelligence artificielle, IBM a ainsi favorisé le développement de nouveaux services : recherche contre le cancer, gestion de patrimoine, recettes de cuisine...
3Idée fausse 3 : seuls les développeurs d’API peuvent y accéder ou les modifier
De nombreuses entreprises s’appuient sur des plates-formes d’API. Elles permettent d’intégrer les dernières avancées technologiques et méthodologiques (objets connectés, API Lead architecture, lean) dans des interfaces très simples.
Libéré des contraintes techniques, l’utilisateur bénéficie du meilleur de l’innovation, ce qui rend son expérience plus riche et intuitive.
Ce type de plateforme permet aussi d’instaurer une politique de gouvernance commune et donc de proposer notamment une authentification unifiée et une gestion des droits d’accès basée sur une catégorisation des API back-end selon leur niveau de confidentialité correspondant. Simplicité ne veut pas dire absence de sécurité…
Enfin, le recours à ces plateformes ne doit pas sous-estimer la surveillance du cycle de vie des API. L’équipe dédiée doit s’appuyer sur un ensemble d’hypothèses qui doivent être confirmées ou réfutées. Le recours à des outils (comme SwaggerHub, Apiary et Reprezen) lui permet de développer progressivement l’API avec des retours réguliers des parties prenantes et des clients à chaque itération. Les feedbacks permettent d’arriver à une interface très efficace.
4Idée fausse 4 : chaque changement d’API nécessite un développement du code
La gestion des versions des API est l’un des aspects les plus complexes dans un cadre de développement car l’objectif est de pouvoir en proposer plusieurs.
Les anciennes API nécessitaient un développement en code dur et donc des temps d’arrêt importants à chaque modification. Les API modernes peuvent extraire des procédures stockées ou des modèles stockés de différents référentiels sans arrêter l’application.
Au-delà de ces préjugés, l’essentiel est d’avoir la maîtrise de son écosystème d’API. C’est la clé pour améliorer la connaissance sur leur utilisation et finalement de les valoriser. Les API doivent être traitées avec la même attention et la même planification que tout service prioritaire pour une organisation.
Source : enterprisersproject
